On Tue, Dec 5, 2017 at 4:18 AM, Lucas Stach l.stach@pengutronix.de wrote:
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@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?
amd-staging-drm-next rebases periodically. The wip branches are not stable. I'll be sending out a pull request for 4.16 in the next day or two and that branch (drm-next-4.16) will be 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?
If you want to send patches against amd-staging-drm-next, I can pull them into our system and include them in my next pull request after we've tested them internally. At that point, you can either pull my stable branch or wait until it gets into Dave's drm-next branch.
Alex