[Intel-xe] [PATCH] drm/xe: Update to upstream DRM scheduler code

[Lucas De Marchi]

On Wed, Oct 25, 2023 at 05:07:00PM +0000, Matthew Brost wrote:
>On Wed, Oct 25, 2023 at 08:56:17AM -0500, Lucas De Marchi wrote:
>> On Tue, Oct 24, 2023 at 09:05:20PM -0700, Matthew Brost wrote:
>> > The largest change is the message interface has been removed from the
>> > DRM scheduler. Xe still needs a message interface so it is implemented
>> > in the Xe driver by adding a Xe scheduler layer.
>>
>> can you point to the commits upstream? What commits in our branch it
>> replaces so we know what to drop when drm-xe-next is rebase... ?
>> How was this diff generated ?
>>
>
>This is based on the upstream series [1] that hopefully gets merged
>soon. To create this patch I just dropped in the new drm-scheduler code
>(copied drivers/gpu/drm/scheduler/*.c / *.h into this repo) and updated
>the Xe code as required. The DRM scheduler coded so much in the baseline
>I'm not sure if it worth trying to do fixup patches, rather we just
>merge it on tip and find a proper place these changes during the next
>rebase. Open to other ideas too.

I don't think we should do fixup patches neither, but it's important to
keep documented in the commit message how and what was changed. Like you
did now.

However I think it will be quite troublesome to rebase the branch in
future since you are also changing other parts of the code. So it's not
a matter of just dropping this one patch when we rebase.  Lately it's
usually Rodrigo who is rebasing drm-xe-next, so +Rodrigo.

One alternative that comes to mind is: can you do the rebase and post
the result to a remote branch? Assuming your remote is called xe:

	git fetch xe
	git reset --hard xe/drm-xe-next
	git rebase -i bb46e837b7e59c22a567ae6913ff4d6bf0e9211a

Then drop the patches as you see fit and add the ones from this series.

Lucas De Marchi