Am 04.06.21 um 16:11 schrieb Thomas Hellström:
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.
Ok in this case I will just fix them up as best as I can.
Thanks, Christian.
/Thomas
/Thomas