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. Is the 10 patches self-allocation series the main > remaining part? 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
