On Fri, 2021-06-04 at 16:06 +0200, Christian König wrote:
Am 04.06.21 um 16:03 schrieb Thomas Hellström:
On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote:
Am 04.06.21 um 11:12 schrieb Daniel Vetter:
On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström wrote:
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.
If it's just slight conflicts then I wouldn't bother with careful merge order. Because if we do this we can get around to the i915 ttm topic branch only when we're back to -rc2.
I've just pushed the remaining 10 patches to drm-misc-next and ran into minor merge conflicts in drm-tip.
I'm working on this, but I'm not very familiar with drm-tip handling.
Christian.
Np, I'll hold off until Monday.
Ok I've fixed up drm-tip for amdgpu, but there are also merge conflicts for i915.
Can you handle those? Doesn't looks to hard, but I would prefer not to touch code I can't test.
Christian.
Hi, Christian, Unfortunately I can't (not until monday at least as I'm off for the weekend). But I did warn you twice about those.
/Thomas
/Thomas