On Fri, Jan 23, 2026 at 12:01 PM Dmitry Baryshkov <[email protected]> wrote: > > On Thu, Jan 22, 2026 at 06:48:58AM -0800, Rob Clark wrote: > > On Thu, Jan 22, 2026 at 1:41 AM Johan Hovold <[email protected]> wrote: > > > > > > [ +CC: Dave and Simona ] > > > > > > On Wed, Jan 21, 2026 at 08:59:51AM -0800, Rob Clark wrote: > > > > On Wed, Jan 21, 2026 at 7:17 AM Johan Hovold <[email protected]> wrote: > > > > > > > > > > On Wed, Jan 14, 2026 at 09:56:12AM +0100, Johan Hovold wrote: > > > > > > On Sun, Dec 21, 2025 at 05:45:52PM +0100, Johan Hovold wrote: > > > > > > > The hw clock gating register sequence consists of register value > > > > > > > pairs > > > > > > > that are written to the GPU during initialisation. > > > > > > > > > > > > > > The a690 hwcg sequence has two GMU registers in it that used to > > > > > > > amount > > > > > > > to random writes in the GPU mapping, but since commit 188db3d7fe66 > > > > > > > ("drm/msm/a6xx: Rebase GMU register offsets") they trigger a > > > > > > > fault as > > > > > > > the updated offsets now lie outside the mapping. This in turn > > > > > > > breaks > > > > > > > boot of machines like the Lenovo ThinkPad X13s. > > > > > > > > > > > > > > Note that the updates of these GMU registers is already taken > > > > > > > care of > > > > > > > properly since commit 40c297eb245b ("drm/msm/a6xx: Set GMU CGC > > > > > > > properties on a6xx too"), but for some reason these two entries > > > > > > > were > > > > > > > left in the table. > > > > > > > > > > > > > > Fixes: 5e7665b5e484 ("drm/msm/adreno: Add Adreno A690 support") > > > > > > > Cc: [email protected] # 6.5 > > > > > > > Cc: Bjorn Andersson <[email protected]> > > > > > > > Cc: Konrad Dybcio <[email protected]> > > > > > > > Signed-off-by: Johan Hovold <[email protected]> > > > > > > > --- > > > > > > > > > > > > This one does not seem to have been applied yet despite fixing a > > > > > > critical regression in 6.19-rc1. I guess I could have highlighted > > > > > > that > > > > > > further by also including: > > > > > > > > > > > > Fixes: 188db3d7fe66 ("drm/msm/a6xx: Rebase GMU register offsets") > > > > > > > > > > > > I realise some delays are expected around Christmas, but can you > > > > > > please > > > > > > try to get this fix to Linus now that everyone should be back again? > > > > > > > > > > I haven't received any reply so was going to send another reminder, > > > > > but > > > > > I noticed now that this patch was merged to the msm-next branch last > > > > > week. > > > > > > > > > > Since it fixes a regression in 6.19-rc1 it needs to go to Linus this > > > > > cycle and I would have assumed it should have be merged to msm-fixes. > > > > > > > > > > (MSM) DRM works in mysterious ways, so can someone please confirm that > > > > > this regression fix is heading into mainline for 6.19-final? > > > > > > > > Sorry, mesa 26.0 branchpoint this week so I've not had much time for > > > > kernel for last few weeks and didn't have time for a 2nd msm-fixes PR. > > > > But with fixes/cc tags it should be picked into 6.19.y > > > > > > I'm afraid that's not good enough as this is a *regression* breaking the > > > display completely on machines like the X13s. > > > > > > Regression fixes should go to mainline this cycle since we don't > > > knowingly break users' setups (and force them to debug/bisect when they > > > update to 6.19 while the fix has been available since before Christmas). > > > > > > Can't you just send a PR with this single fix? Otherwise, perhaps Dave > > > or Simona can pick up the fix directly? > > > > Maybe someone can cherry-pick to drm-misc-fixes? > > I know that there is some process for cherry-picking into > drm-misc-fixes, but I think the end result was frowned upon. Neil?
I'll send a pull request with the cherry-pick BR, -R
