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@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. 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. We can also validate any conflicts in drm-tip easily before they get baked in in drm-next. So I'd just go with - drm-misc-next gets those 10 patches from Christian and the memcpy prep stuff from you, gets send to drm-next (that's probably the last feature pull for 5.14 anyway, maybe another one) - drm-intel-gt-next gets send to drm-next - topic branch with remaining i915 ttm work that's in flight on top of drm-next and we pull that into drm-misc-next and drm-intel-gt-next as needed Only thing we need for this is a few days of testing to make sure any conflicts between -misc-next and -gt-next are fully validated. Adding Dave for that so he knows too. > 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. Yeah that part I think makes sense. -Daniel > > /Thomas > > > > > > > Christian. > > > > > -Daniel > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
