Re: [PATCH] arm64: dts: qcom: mahua-t14s: Enable GPU and GMU

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm64: dts: qcom: mahua-t14s enables GPU/GMU without mahua.dtsi overrides
--

commit 9b4a7ddbb7e3ff673d119429fdec3506da117877
Author: Lukas Märdian <lukas.maerdian@oss.qualcomm.com>

arm64: dts: qcom: mahua-t14s: Enable GPU and GMU

This commit removes the board-level disabled status overrides for the GPU and
GMU nodes in the Lenovo ThinkPad T14s Gen 7 (LCD) device tree so that they
inherit the default enabled status from the SoC device tree.

> diff --git a/arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts b/arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts
> index 26d6d8285e040..fb913da7343fd 100644
> --- a/arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts
> +++ b/arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts
> @@ -634,15 +634,6 @@ vreg_l4h_e0_1p2: ldo4 {
>  	};
>  };
>  
> -/* GPU/GMU not fully functional yet on this platform. */
> -&gmu {
> -	status = "disabled";
> -};
> -
> -&gpu {
> -	status = "disabled";
> -};

[Severity: High]
Does enabling &gpu and &gmu in
arch/arm64/boot/dts/qcom/mahua-lenovo-thinkpad-t14s-gen7-lcd.dts cause the
ThinkPad T14s Gen 7 to probe the GPU with the wrong hardware configuration
when the prerequisite arch/arm64/boot/dts/qcom/mahua.dtsi overrides are not
yet applied?

The commit message notes that mahua.dtsi overrides the compatibles with
"qcom,adreno-44060000" and "qcom,adreno-gmu-x285.0", and the note below the
tearline mentions a dependency on "arm64: dts: qcom: mahua: Support GPU and
GMU" (https://lore.kernel.org/all/20260925-mahua-gpu-v1-0-0fa0bfd8d315@oss.qualcomm.com/).

In the current tree, drivers/gpu/drm/msm/adreno/a8xx_catalog.c already has
the a8xx_gpus[] entry for 0x44060000, but arch/arm64/boot/dts/qcom/mahua.dtsi
only includes glymur.dtsi without overriding &gpu or &gmu:

arch/arm64/boot/dts/qcom/mahua.dtsi:
    #include "glymur.dtsi"

Without those overrides in mahua.dtsi, removing status = "disabled" here
exposes the unchanged nodes from arch/arm64/boot/dts/qcom/glymur.dtsi:

arch/arm64/boot/dts/qcom/glymur.dtsi:
    gpu: gpu@3d00000 {
            compatible = "qcom,adreno-44070001", "qcom,adreno";
    ...
    gmu: gmu@3d6c000 {
            compatible = "qcom,adreno-gmu-x285.1", "qcom,adreno-gmu";

When the drm/msm driver probes gpu@3d00000 via adreno_bind() -> find_chipid(),
it matches the 0x44070001 (Adreno X2-90) entry in a8xx_gpus[] rather than the
0x44060000 (Adreno X2-85) entry in drivers/gpu/drm/msm/adreno/a8xx_catalog.c:

drivers/gpu/drm/msm/adreno/a8xx_catalog.c:
    .chip_ids = ADRENO_CHIP_IDS(0x44070001),
    .family = ADRENO_8XX_GEN2,
    .fw = {
            [ADRENO_FW_SQE] = "gen80100_sqe.fw",
            [ADRENO_FW_GMU] = "gen80100_gmu.bin",
    },
    .gmem = 21 * SZ_1M,
    ...
    .a6xx = &(const struct a6xx_info) {
            ...
            .max_slices = 4,
            .gmu_chipid = 0x8010100,

Instead of Mahua's 15.75 MiB GMEM, max_slices = 3, gmu_chipid = 0x80a0000,
and gen80100_aqe.fw, the driver will configure 21 MiB GMEM, 4 slices, and
write 0x8010100 to REG_A8XX_GMU_GENERAL_10 in a6xx_gmu_fw_start(), while also
leaving the undocumented "qcom,adreno-gmu-x285.1" compatible enabled on
gmu@3d6c000.

Should the mahua.dtsi GPU and GMU overrides be applied before enabling &gpu
and &gmu on this board?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102142812.1353199-1-lukas.maerdian@oss.qualcomm.com?part=1