[PATCH 6.1.y] drm/amdgpu/vcn: Disable indirect SRAM on Vangogh broken BIOSes

[Deucher, Alexander]

[Public]

> -----Original Message-----
> From: Guilherme G. Piccoli <gpiccoli at igalia.com>
> Sent: Wednesday, April 19, 2023 10:15 AM
> To: Deucher, Alexander <Alexander.Deucher at amd.com>
> Cc: stable at vger.kernel.org; gregkh at linuxfoundation.org;
> sashal at kernel.org; amd-gfx at lists.freedesktop.org; Zhu, James
> <James.Zhu at amd.com>; Liu, Leo <Leo.Liu at amd.com>; kernel at gpiccoli.net;
> kernel-dev at igalia.com
> Subject: Re: [PATCH 6.1.y] drm/amdgpu/vcn: Disable indirect SRAM on
> Vangogh broken BIOSes
> 
> On 19/04/2023 10:16, Deucher, Alexander wrote:
> > [...]
> >> This is quite strange for me, we have 2 commit hashes pointing to the
> >> *same* commit, and each one is present..in a different release !!?!
> >> Since I've marked this patch as fixing 82132ecc5432 originally, 6.1.y
> >> stable misses it, since it only contains 9a8cc8cabc1e (which is the same
> patch!).
> >>
> >> Alex, do you have an idea why sometimes commits from the AMD tree
> >> appear duplicate in mainline? Specially in different releases, this
> >> could cause some confusion I guess.
> >
> > This is pretty common in the drm.  The problem is there is not a good way
> to get bug fixes into both -next and -fixes without constant back merges.  So
> the patches end up in -next and if they are important for stable, they go to -
> fixes too.  We don't want -next to be broken, but we can't wait until the next
> kernel cycle to get the bug fixes into the current kernel and stable.  I don't
> know of a good way to make this smoother.
> >
> > Alex
> 
> Thanks Alex, seems quite complicated indeed.
> 
> So, let me check if I understood properly: there are 2 trees (-fixes and -next),
> and the problem is that their merge onto mainline happens apart and there
> are kind of duplicate commits, that were first merged on -fixes, then "re-
> merged" on -next, right?
> 

Each subsystem works on new features, then when the merge window opens, Linus pulls them into mainline.  At that point, mainline goes into RCs and then mainline is bug fixes only.  Meanwhile in parallel, each subsystem is working on new feature development for the next merge window (subsystem -next trees).  The trees tend to lag behind mainline a bit.  Most developers focus on them in support of upcoming features.  They are usually also where bugs are fixed.  If a bug is fixed in the -next tree, what's the best way to get it into mainline?  I guess ideally it would be fixed in mainline and them mainline would be merged into everyone's -next branch, but that's not always practical.  Often times new features depend on bug fixes and then you'd end up stalling new development waiting for a back merge, or you'd have to rebase your -next branches regularly so that they would shed any patches in mainline which is not great either.  We try and cherry-pick -x when we can to show the relationship.

> Would be possible to clean the -next tree right before the merge, using
> some script to find commits there that are going to be merged but are
> already present? Then you'd have a -next-to-merge tree that is clean and
> doesn't present dups, avoiding this.

There's no real way to clean it without rewriting history.  You'd basically need to do regular backmerges and rebases of the -next trees.  Also then what do you do if you already have a feature in -next (say Dave or Daniel have already pulled in my latest amdgpu PR for -next) and you realize that one of those patches is an important bug fix for mainline?  If the drm -next tree rebased then all of the other drm driver trees that feed into it would need to rebase as well otherwise they'd have stale history.

You also have the case of a fix in -next needing to land in mainline, but due to differences in the trees, it needs backporting to apply properly.

> 
> Disclaimer: I'm not a maintainer, maybe there are smart ways of doing that or
> perhaps my suggestion is silly and unfeasible heh But seems likely that other
> maintainers face this problem as well and came up with some solution -
> avoiding the dups would be a good thing, IMO, if possible.


No worries.  I agree.  I haven't seen anything so far that really addresses handles this effectively.

Alex

> 
> Cheers,
> 
> 
> Guilherme
>