Re: [Intel-gfx] Merging TTM branches through the Intel tree?

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On 6/4/21 9:51 AM, Christian König wrote:
> Am 03.06.21 um 09:36 schrieb Daniel Vetter:
>> On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström
>> <thomas.hellstrom@linux.intel.com> wrote:
>>>
>>> On 6/2/21 8:40 PM, Daniel Vetter wrote:
>>>> On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote:
>>>>> Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel):
>>>>>> On 6/2/21 10:32 AM, Christian König wrote:
>>>>>>> Uff I'm just waiting for feedback from Philip to merge a large 
>>>>>>> patch
>>>>>>> set for TTM through drm-misc-next.
>>>>>>>
>>>>>>> I'm pretty sure we will run into merge conflicts if you try to push
>>>>>>> your changes through the Intel tree.
>>>>>>>
>>>>>>> Christian.
>>>>>> OK, so what would be the best approach here?, Adding the TTM 
>>>>>> patches to
>>>>>> drm-misc-next when your set has landed?
>>>>> I think I will send out out my set to Matthew once more for 
>>>>> review, then
>>>>> push the common TTM stuff to drm-misc-next as much as possible.
>>>>>
>>>>> Then you should be able to land your stuff to drm-misc-next and 
>>>>> rebase on
>>>>> the end result.
>>>>>
>>>>> Just need to note to David that drm-misc-next should be merged to 
>>>>> drm-next
>>>>> before the Intel patches depending on that stuff land as well.
>>>> Other option (because the backmerges tend to be slow) is a topic 
>>>> branch,
>>>> and we just eat/resolve the conflicts in both drm-misc-next and
>>>> drm-intel-gt-next in the merge commit. If it's not too bad (I haven't
>>>> looked at what exactly we need for the i915 side from ttm in detail).
>>>>
>>>> But also often figuring out the topic branch logistics takes longer 
>>>> than
>>>> just merging to drm-misc-next as the patches get ready.
>>>> -Daniel
>>> Daniel: So the thing we need to get into TTM is the iterator-based
>>> move_memcpy which is more adaptable than the current one and needed to
>>> support non-linear lmem buffers, some bug-fixes and minor changes to be
>>> able to keep our short-term-pinning while on the LRU. A necessary evil.
>>>
>>> Christian: it looks like you have landed some TTM changes already, in
>>> particular the &bo->mem -> bo->resource change which is the main
>>> conflict I think.
>
> Yes, I thought that pushing this with Matthew rb should solve at least 
> a bit of the conflict.
>
>>> Is the 10 patches self-allocation series the main
>>> remaining part?
>
> Yes, exactly. I only need Matthew's, Daniel's or your ok and I'm good 
> to go as well
>
>>> That will probably cause some conflicts with already
>>> pushed i915 TTM setup code, but otherwise will not conflict with the
>>> rest of the TTM code I think, which should make it possible to bring in
>>> our TTM changes after conflict resolution with what you've already
>>> pushed. The memcpy code is pretty self-contained.
>> I think in that case topic branch on top of drm-next (once the ttm
>> bits we conflict with are there) is probably best, and then pull that
>> into drm-misc-next and drm-intel-gt-next. Merge window freeze is also
>> approach, so without topic branch we'd be stuck until like -rc2 when
>> drm-next reopens. I guess Maarten can do the topic branch logistics in
>> drm-misc.git for this.
>
> That approach sounds good to me as well.
>
> The amdgpu branch had some merge conflicts as well, but nothing we 
> couldn't fix.

OK, so this is going to be a little tricky, I guess.

 From what I can tell, the memcpy TTM stuff is resolved locally and can 
be merged to drm-misc-next immediately. It might have a very minor 
conflict with your 10 patches I think, if any.

Your 10 patches will conflict slightly with current drm-intel-gt-next I 
think.

Remaining intel patches will conflict only with current drm-misc-next.

So We could have pull order

- drm-misc-next up to bot not including your 10 patches,
- drm-intel-gt-next
- drm-misc-next from your 10 paches and onwards,
- Intel's ttm enablement topic branch.

Whether I push the ttm memcpy stuff before your 10 patches or after 
shouldn't really matter except it might take some time to resolve the 10 
patches - drm-intel-gt-next conflict in drm-tip.

So OK to merge the memcpy stuff to drm-misc-next now or do you want me 
to hold on?

I'll take a look at what's remaining to review in your series. I guess 
it's in our interest that both these series get merged asap.

/Thomas



>
> Christian.
>
>> -Daniel
>