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: stable@vger.kernel.org	# 6.5
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Konrad Dybcio <konradybcio@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
index 29107b362346..4c2f739ee9b7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
@@ -501,8 +501,6 @@ static const struct adreno_reglist a690_hwcg[] = {
 	{REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x00000222},
 	{REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x00000111},
 	{REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x00000555},
-	{REG_A6XX_GPU_GMU_AO_GMU_CGC_DELAY_CNTL, 0x10111},
-	{REG_A6XX_GPU_GMU_AO_GMU_CGC_HYST_CNTL, 0x5555},
 	{}
 };
 
-- 
2.51.2

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: stable@vger.kernel.org	# 6.5
> Cc: Bjorn Andersson <andersson@kernel.org>
> Cc: Konrad Dybcio <konradybcio@kernel.org>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---

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?

Johan

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: stable@vger.kernel.org	# 6.5
> > Cc: Bjorn Andersson <andersson@kernel.org>
> > Cc: Konrad Dybcio <konradybcio@kernel.org>
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> 
> 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?

Johan

On Wed, Jan 21, 2026 at 7:17 AM Johan Hovold <johan@kernel.org> 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: stable@vger.kernel.org  # 6.5
> > > Cc: Bjorn Andersson <andersson@kernel.org>
> > > Cc: Konrad Dybcio <konradybcio@kernel.org>
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> >
> > 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

BR,
-R

[ +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 <johan@kernel.org> 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: stable@vger.kernel.org  # 6.5
> > > > Cc: Bjorn Andersson <andersson@kernel.org>
> > > > Cc: Konrad Dybcio <konradybcio@kernel.org>
> > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > ---
> > >
> > > 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?

Johan

On Thu, Jan 22, 2026 at 1:41 AM Johan Hovold <johan@kernel.org> 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 <johan@kernel.org> 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: stable@vger.kernel.org  # 6.5
> > > > > Cc: Bjorn Andersson <andersson@kernel.org>
> > > > > Cc: Konrad Dybcio <konradybcio@kernel.org>
> > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > ---
> > > >
> > > > 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?

BR,
-R

On Thu, Jan 22, 2026 at 06:48:58AM -0800, Rob Clark wrote:
> On Thu, Jan 22, 2026 at 1:41 AM Johan Hovold <johan@kernel.org> 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 <johan@kernel.org> 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: stable@vger.kernel.org  # 6.5
> > > > > > Cc: Bjorn Andersson <andersson@kernel.org>
> > > > > > Cc: Konrad Dybcio <konradybcio@kernel.org>
> > > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > > ---
> > > > >
> > > > > 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?

-- 
With best wishes
Dmitry

On Fri, Jan 23, 2026 at 12:01 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> 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 <johan@kernel.org> 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 <johan@kernel.org> 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: stable@vger.kernel.org  # 6.5
> > > > > > > Cc: Bjorn Andersson <andersson@kernel.org>
> > > > > > > Cc: Konrad Dybcio <konradybcio@kernel.org>
> > > > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > > > ---
> > > > > >
> > > > > > 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

On 12/21/25 5:45 PM, 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.

I am squinting *very* hard and I can not recall why I only removed one
of these entries.

> 
> Fixes: 5e7665b5e484 ("drm/msm/adreno: Add Adreno A690 support")
> Cc: stable@vger.kernel.org	# 6.5
> Cc: Bjorn Andersson <andersson@kernel.org>
> Cc: Konrad Dybcio <konradybcio@kernel.org>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> index 29107b362346..4c2f739ee9b7 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> @@ -501,8 +501,6 @@ static const struct adreno_reglist a690_hwcg[] = {
>  	{REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x00000222},
>  	{REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x00000111},
>  	{REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x00000555},
> -	{REG_A6XX_GPU_GMU_AO_GMU_CGC_DELAY_CNTL, 0x10111},
> -	{REG_A6XX_GPU_GMU_AO_GMU_CGC_HYST_CNTL, 0x5555},

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

On 12/21/2025 10:15 PM, 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: stable@vger.kernel.org	# 6.5
> Cc: Bjorn Andersson <andersson@kernel.org>
> Cc: Konrad Dybcio <konradybcio@kernel.org>
> Signed-off-by: Johan Hovold <johan@kernel.org>

Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>

I fixed a similar out of bound access issue in the coredump path last
month. This pattern indicates that we should consider combining the IO
accessors of both gpu and gmu.

-Akhil

> ---
>  drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> index 29107b362346..4c2f739ee9b7 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> @@ -501,8 +501,6 @@ static const struct adreno_reglist a690_hwcg[] = {
>  	{REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x00000222},
>  	{REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x00000111},
>  	{REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x00000555},
> -	{REG_A6XX_GPU_GMU_AO_GMU_CGC_DELAY_CNTL, 0x10111},
> -	{REG_A6XX_GPU_GMU_AO_GMU_CGC_HYST_CNTL, 0x5555},
>  	{}
>  };
>