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

[Christian König]

Am 03.06.21 um 09:36 schrieb Daniel Vetter:
> On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström
> <thomas.hellstrom at 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.

Christian.

> -Daniel