[PATCH 0/2] Move scheduler out of AMDGPU

Lucas Stach l.stach at pengutronix.de
Tue Dec 5 09:18:15 UTC 2017


Hi Alex,

Am Montag, den 04.12.2017, 16:47 -0500 schrieb Alex Deucher:
> On Fri, Dec 1, 2017 at 10:55 AM, Christian K├Ânig
> > <christian.koenig at amd.com> wrote:
> > Am 01.12.2017 um 16:28 schrieb Lucas Stach:
> > > 
> > > Hi all,
> > > 
> > > so this is the first step to make the marvelous AMDGPU scheduler useable
> > > for other drivers. I have a (mostly) working prototype of Etnaviv using
> > > the scheduler, but those patches need to keep baking for a while.
> > > 
> > > I'm sending this out as I want to avoid rebasing this change too much
> > > and don't want to take people by surprise when the Etnaviv implementation
> > > surfaces. Also this might need some coordination between AMDGPU and
> > > Etnaviv, which might be good to get going now.
> > > 
> > > Please speak up now if you have any objections or comments.
> > 
> > 
> > Looks good to me, but question is what is this based upon?
> > 
> > I strongly assume drm-next, so question is now if we have any patches inside
> > amd branches we should apply before doing this.
> 
> We have a bunch of changes queued up which will go usptream for 4.16.
> See amd-staging-drm-next:
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
> which is a mirror of our main development branch or:
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.16-wip
> which is what is currently queued for 4.16.

Is this branch/tag stable?

How would you like to handle the merge? Should I send out patches for
you to apply and you get me a stable branch to pull into etnaviv, or
should I provide a stable branch based on the above to pull into both
amdgpu and etnaviv?

Regards,
Lucas


More information about the dri-devel mailing list