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@xxxxxxxxxxxxxxx> 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
