Re: [PATCH v2 10/10] [CI]drm/xe/xe_late_bind_fw: Select INTEL_MEI_LATE_BIND for CI Do not review
Hi Badal, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-xe/drm-xe-next] [also build test WARNING on next-20250606] [cannot apply to char-misc/char-misc-testing char-misc/char-misc-next char-misc/char-misc-linus drm-i915/for-linux-next drm-i915/for-linux-next-fixes linus/master v6.15] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Badal-Nilawar/mei-bus-add-mei_cldev_mtu-interface/20250607-015525 base: https://gitlab.freedesktop.org/drm/xe/kernel.git drm-xe-next patch link: https://lore.kernel.org/r/20250606175707.1403384-11-badal.nilawar%40intel.com patch subject: [PATCH v2 10/10] [CI]drm/xe/xe_late_bind_fw: Select INTEL_MEI_LATE_BIND for CI Do not review config: alpha-kismet-CONFIG_INTEL_MEI_LATE_BIND-CONFIG_DRM_XE-0-0 (https://download.01.org/0day-ci/archive/20250607/202506071532.wlvvupfu-...@intel.com/config) reproduce: (https://download.01.org/0day-ci/archive/20250607/202506071532.wlvvupfu-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202506071532.wlvvupfu-...@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for INTEL_MEI_LATE_BIND >> when selected by DRM_XE WARNING: unmet direct dependencies detected for INTEL_MEI_LATE_BIND Depends on [n]: INTEL_MEI [=n] && DRM_XE [=y] Selected by [y]: - DRM_XE [=y] && HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y] && (m [=m] && MODULES [=y] || KUNIT [=y]=y [=y]) && (INTEL_VSEC [=n] || !INTEL_VSEC [=n]) && (X86_PLATFORM_DEVICES [=n] || !X86 || !ACPI) -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v7 10/10] arm64: dts: rockchip: enable NPU on ROCK 5B
Am Freitag, 6. Juni 2025, 11:20:32 Mitteleuropäische Sommerzeit schrieb Nicolas
Frattaroli:
> Hi Tomeu,
>
> On Friday, 6 June 2025 08:28:30 Central European Summer Time Tomeu Vizoso
> wrote:
> > From: Nicolas Frattaroli
> >
> > The NPU on the ROCK5B uses the same regulator for both the sram-supply
> > and the npu's supply. Add this regulator, and enable all the NPU bits.
> > Also add the regulator as a domain-supply to the pd_npu power domain.
> >
> > Signed-off-by: Nicolas Frattaroli
> > Signed-off-by: Tomeu Vizoso
> > ---
> > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 56
> > +
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> > b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> > index
> > d22068475c5dc6cb885f878f3f527a66edf1ba70..49500f7cbcb14af4919a6c1997e9e53a01d84973
> > 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> > @@ -316,6 +316,28 @@ regulator-state-mem {
> > };
> > };
> >
> > +&i2c1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c1m2_xfer>;
> > + status = "okay";
> > +
> > + vdd_npu_s0: regulator@42 {
> > + compatible = "rockchip,rk8602";
> > + reg = <0x42>;
> > + fcs,suspend-voltage-selector = <1>;
> > + regulator-name = "vdd_npu_s0";
> > + regulator-boot-on;
> > + regulator-min-microvolt = <55>;
> > + regulator-max-microvolt = <95>;
> > + regulator-ramp-delay = <2300>;
> > + vin-supply = <&vcc5v0_sys>;
> > +
> > + regulator-state-mem {
> > + regulator-off-in-suspend;
> > + };
> > + };
> > +};
> > +
> > &i2c6 {
> > status = "okay";
> >
> > @@ -440,6 +462,10 @@ &pd_gpu {
> > domain-supply = <&vdd_gpu_s0>;
> > };
> >
> > +&pd_npu {
> > + domain-supply = <&vdd_npu_s0>;
> > +};
> > +
> > &pinctrl {
> > hdmirx {
> > hdmirx_hpd: hdmirx-5v-detection {
> > @@ -500,6 +526,36 @@ &pwm1 {
> > status = "okay";
> > };
> >
> > +&rknn_core_top {
> > + npu-supply = <&vdd_npu_s0>;
> > + sram-supply = <&vdd_npu_s0>;
> > + status = "okay";
> > +};
> > +
> > +&rknn_core_1 {
> > + npu-supply = <&vdd_npu_s0>;
> > + sram-supply = <&vdd_npu_s0>;
> > + status = "okay";
> > +};
> > +
> > +&rknn_core_2 {
> > + npu-supply = <&vdd_npu_s0>;
> > + sram-supply = <&vdd_npu_s0>;
> > + status = "okay";
> > +};
> > +
> > +&rknn_mmu_top {
> > + status = "okay";
> > +};
> > +
> > +&rknn_mmu_1 {
> > + status = "okay";
> > +};
> > +
> > +&rknn_mmu_2 {
> > + status = "okay";
> > +};
> > +
> > &saradc {
> > vref-supply = <&avcc_1v8_s0>;
> > status = "okay";
> >
> >
>
> Feel free to replace this patch with the following, if your series is
> based on linux-next or v6.16. It moves the enablement into the new
> shared ROCK 5B/5B+ dtsi, and I've added a regulator-enable-ramp-delay
> while I was at it because I've run into hard-to-reproduce problems
> relating to it before that Heiko quickly identified and fixed in his
> recent series[1] for basically all already present regulators. Remains
> to be seen if the final patch lands in that form but this should make
> it easier for people to try out as it means a bad luck roll for the
> day won't make them run into as many weird issues.
>
> [1]: https://lore.kernel.org/all/20250605185001.377055-1-he...@sntech.de/
Reading that just now reminds me to point to
https://lore.kernel.org/lkml/20250606190418.478633-1-he...@sntech.de/
As Chen Yu pointed out in the reply to v2, this is more a property of the
regulator IC itself, so likely should go into the driver.
So with a bit of luck after 6.16-rc1 all the fan53555 clones should use
somewhat hardware-accurate enable-times.
> From ff1c370a158f4340aa5dfa4ed5034e815e5371be Mon Sep 17 00:00:00 2001
> From: Nicolas Frattaroli
> Date: Tue, 3 Jun 2025 17:03:10 +0200
> Subject: [PATCH] arm64: dts: rockchip: enable NPU on ROCK 5B/+
>
> The NPU on the ROCK5B uses the same regulator for both the sram-supply
> and the npu's supply. Add this regulator, and enable all the NPU bits.
> Also add the regulator as a domain-supply to the pd_npu power domain.
>
> The 5B+'s regulator setup is identical to the 5B in this regard, so it
> goes in the shared .dtsi.
>
> Signed-off-by: Nicolas Frattaroli
> ---
> .../boot/dts/rockchip/rk3588-rock-5b.dtsi | 57 +++
> 1 file changed, 57 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dtsi
> index 51e83f0ed809..5a20cc2555fb 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dtsi
> @@ -332,6 +332,29 @@ regulator-state-mem {
> };
> };
>
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1m2_xfer>;
> + status = "o
[PATCH 0/3] Support for Adreno X1-45 GPU
Add support for X1-45 GPU found in X1P41200 chipset (8 cpu core version). X1-45 is a smaller version of X1-85 with lower core count and smaller memories. From UMD perspective, this is similar to "FD735" present in Mesa. Tested Glmark & Vkmark on Debian Gnome desktop. Signed-off-by: Akhil P Oommen --- Akhil P Oommen (3): arm64: defconfig: Enable X1P42100_GPUCC driver drm/msm/adreno: Add Adreno X1-45 support arm64: dts: qcom: Add GPU support to X1P42100 SoC arch/arm64/boot/dts/qcom/x1e80100.dtsi| 7 ++ arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 4 + arch/arm64/boot/dts/qcom/x1p42100.dtsi| 121 +- arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 38 ++ 5 files changed, 170 insertions(+), 1 deletion(-) --- base-commit: b3bded85d838336326ce78e394e7818445e11f20 change-id: 20250603-x1p-adreno-219da2fd4ca4 Best regards, -- Akhil P Oommen
[PATCH 1/3] arm64: defconfig: Enable X1P42100_GPUCC driver
In order to enable GPU support in Snapdragon X1P42100 (8 CPU core version), enable X1P42100 GPUCC driver as a module. Signed-off-by: Akhil P Oommen --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 62d3c87858e1817bac291780dff3823dacd72510..9cc473fd0d3308f7869d00425e17b114c87093b2 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1350,6 +1350,7 @@ CONFIG_CLK_X1E80100_CAMCC=m CONFIG_CLK_X1E80100_DISPCC=m CONFIG_CLK_X1E80100_GCC=y CONFIG_CLK_X1E80100_GPUCC=m +CONFIG_CLK_X1P42100_GPUCC=m CONFIG_CLK_X1E80100_TCSRCC=y CONFIG_CLK_QCM2290_GPUCC=m CONFIG_QCOM_A53PLL=y -- 2.48.1
[PATCH 3/3] arm64: dts: qcom: Add GPU support to X1P42100 SoC
X1P42100 SoC has a new GPU called Adreno X1-45 which is a smaller
version of Adreno X1-85 GPU. Describe this new GPU and also add
the secure gpu firmware path that should used for X1P42100 CRD.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi| 7 ++
arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 4 +
arch/arm64/boot/dts/qcom/x1p42100.dtsi| 121 +-
3 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index
a8eb4c5fe99fe6dd49af200a738b6476d87279b2..558d7d387d7710770244fcc901f461384dd9b0d4
100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -8245,6 +8245,13 @@ sbsa_watchdog: watchdog@1c84 {
interrupts = ;
};
+ qfprom: efuse@221c8000 {
+ compatible = "qcom,x1e80100-qfprom", "qcom,qfprom";
+ reg = <0 0x221c8000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
pmu@24091000 {
compatible = "qcom,x1e80100-llcc-bwmon",
"qcom,sc7280-llcc-bwmon";
reg = <0 0x24091000 0 0x1000>;
diff --git a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
index
cf07860a63e97c388909fb5721ae7b9729b6c586..cf999c2cf8d4e0af83078253fd39ece3a0c26a49
100644
--- a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
+++ b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
@@ -15,3 +15,7 @@ / {
model = "Qualcomm Technologies, Inc. X1P42100 CRD";
compatible = "qcom,x1p42100-crd", "qcom,x1p42100";
};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/x1p42100/gen71500_zap.mbn";
+};
diff --git a/arch/arm64/boot/dts/qcom/x1p42100.dtsi
b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
index
27f479010bc330eb6445269a1c46bf78ec6f1bd4..5ed461ed5cca271d43647888aa6eacac3de2ac9d
100644
--- a/arch/arm64/boot/dts/qcom/x1p42100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
@@ -17,15 +17,134 @@
/delete-node/ &cpu_pd9;
/delete-node/ &cpu_pd10;
/delete-node/ &cpu_pd11;
+/delete-node/ &gpu_opp_table;
/delete-node/ &pcie3_phy;
&gcc {
compatible = "qcom,x1p42100-gcc", "qcom,x1e80100-gcc";
};
-/* The GPU is physically different and will be brought up later */
+&gmu {
+ /delete-property/ compatible;
+ compatible = "qcom,adreno-gmu-x145.0", "qcom,adreno-gmu";
+};
+
+&qfprom {
+ gpu_speed_bin: gpu_speed_bin@119 {
+ reg = <0x119 0x2>;
+ bits = <7 9>;
+ };
+};
+
&gpu {
/delete-property/ compatible;
+
+ compatible = "qcom,adreno-43030c00", "qcom,adreno";
+
+ nvmem-cells = <&gpu_speed_bin>;
+ nvmem-cell-names = "speed_bin";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2-adreno",
"operating-points-v2";
+
+ opp-14 {
+ opp-hz = /bits/ 64 <14>;
+ opp-level = ;
+ opp-peak-kBps = <1650>;
+ qcom,opp-acd-level = <0xa8295ffd>;
+ opp-supported-hw = <0x3>;
+ };
+
+ opp-125000 {
+ opp-hz = /bits/ 64 <125000>;
+ opp-level = ;
+ opp-peak-kBps = <1650>;
+ qcom,opp-acd-level = <0x882a5ffd>;
+ opp-supported-hw = <0x7>;
+ };
+
+ opp-110700 {
+ opp-hz = /bits/ 64 <110700>;
+ opp-level = ;
+ opp-peak-kBps = <1650>;
+ qcom,opp-acd-level = <0x882a5ffd>;
+ opp-supported-hw = <0xf>;
+ };
+
+ opp-101400 {
+ opp-hz = /bits/ 64 <101400>;
+ opp-level = ;
+ opp-peak-kBps = <14398438>;
+ qcom,opp-acd-level = <0xa82a5ffd>;
+ opp-supported-hw = <0xf>;
+ };
+
+ opp-94000 {
+ opp-hz = /bits/ 64 <94000>;
+ opp-level = ;
+ opp-peak-kBps = <14398438>;
+ qcom,opp-acd-level = <0xa82a5ffd>;
+ opp-supported-hw = <0xf>;
+ };
+
+ opp-82500 {
+ opp-hz = /bits/ 64 <82500>;
+ opp-level = ;
+ opp-peak-kBps = <12449219>;
+ qcom,opp-acd-level = <0x882b5ffd>;
+ opp-supported-hw = <0xf>;
+ };
+
+ opp-72000 {
+ opp-hz = /bits/ 64 <72000>;
+ opp-level = ;
+
[PATCH 2/3] drm/msm/adreno: Add Adreno X1-45 support
Add support for Adreno X1-45 GPU present Snapdragon X1P42100
series of compute chipsets. This GPU is a smaller version of
X1-85 GPU with lower core count and smaller internal memories.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 38 +++
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
index
70f7ad806c34076352d84f32d62c2833422b6e5e..2db748ce7df57a9151ed1e7f1b025a537bb5f653
100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
@@ -1474,6 +1474,44 @@ static const struct adreno_info a7xx_gpus[] = {
},
},
.preempt_record_size = 3572 * SZ_1K,
+ }, {
+ .chip_ids = ADRENO_CHIP_IDS(0x43030c00),
+ .family = ADRENO_7XX_GEN2,
+ .fw = {
+ [ADRENO_FW_SQE] = "gen71500_sqe.fw",
+ [ADRENO_FW_GMU] = "gen71500_gmu.bin",
+ },
+ .gmem = SZ_1M + SZ_512K,
+ .inactive_period = DRM_MSM_INACTIVE_PERIOD,
+ .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT |
+ ADRENO_QUIRK_HAS_HW_APRIV |
+ ADRENO_QUIRK_PREEMPTION,
+ .init = a6xx_gpu_init,
+ .a6xx = &(const struct a6xx_info) {
+ .hwcg = a740_hwcg,
+ .protect = &a730_protect,
+ .pwrup_reglist = &a7xx_pwrup_reglist,
+ .gmu_chipid = 0x70f,
+ .gmu_cgc_mode = 0x00020222,
+ .bcms = (const struct a6xx_bcm[]) {
+ { .name = "SH0", .buswidth = 16 },
+ { .name = "MC0", .buswidth = 4 },
+ {
+ .name = "ACV",
+ .fixed = true,
+ .perfmode = BIT(3),
+ .perfmode_bw = 1650,
+ },
+ { /* sentinel */ },
+ },
+ },
+ .preempt_record_size = 4192 * SZ_1K,
+ .speedbins = ADRENO_SPEEDBINS(
+ { 0, 0 },
+ { 294, 1 },
+ { 263, 2 },
+ { 141, 3 },
+ ),
}
};
DECLARE_ADRENO_GPULIST(a7xx);
--
2.48.1
Re: [PATCH drm-misc-next] rockchip/drm: vop2: don't check color_mgmt_changed in atomic_enable
On Thursday, June 5th, 2025 at 10:13 PM, Diederik de Haas
wrote:
> Hi Piotr,
>
> Since kernel 6.14-rc1 I have the problem that visual output is no longer
> shown on my PineTab2 and a `git bisect` pointed to this patch/commit
> as the culprit. What is important to note is that `CONFIG_DRM=m` seems
> to be required as the problem does not occur with `CONFIG_DRM=y`.
>
> Near the end of my bisect session, something interesting occurred.
> I was booted into a 'bad' kernel (ie no visual output) and when I
> started to build my final kernel, I closed the lid of the PineTab2 which
> made it go into suspend. When my final kernel was built, I opened the
> lid again, which made it resume, to transfer my final kernel to it.
> And much to my surprise, I then did have visual output.
> When I read the (below) commit message of the 'offending' commit, it may
> not be such a surprise after all.
>
> When I build a (new) 6.14-rc1 kernel with a revert of this commit on
> top, then I did not have the above mentioned problem, confirming this
> commit was the 'bad' commit.
>
> I did try it on a Quartz64-B (also rk3566) and it did not have any issue
> (output via HDMI).
> I don't know what the cause for this issue is, hopefully you do.
>
Hi Diederik,
I tested and confirmed that this happens with drm=m but also in my case
it happened when drm=y. After some testing I found out that at boot modeset
happened twice and at short interval and since this patch allows for gamma
LUT update regardless of color_mgmt_changed state this makes DSP CTRL GAMMA
LUT EN bit to be unset twice too. It seems that VOP does not like it. I
patched vop2_vp_dsp_lut_disable function so that dsp_ctrl is set only if
GAMMA LUT EN bit is set. I checked that this also does not break the gamma
lut functionality with emphasis on out-of/into suspend behavior.
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index d0f5fea15e21..7ddf311b38c6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -897,6 +897,9 @@ static void vop2_vp_dsp_lut_disable(struct vop2_video_port
*vp)
{
u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
+ if ((dsp_ctrl & RK3568_VP_DSP_CTRL__DSP_LUT_EN) == 0)
+ return;
+
dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
}
I will wait with sending a patch because maybe Andy has something to add
to this.
Best regards, Piotr Zalewski
Re: [PATCH 2/3] drm/msm/adreno: Add Adreno X1-45 support
On Sat, Jun 07, 2025 at 07:45:00PM +0530, Akhil P Oommen wrote:
> Add support for Adreno X1-45 GPU present Snapdragon X1P42100
> series of compute chipsets. This GPU is a smaller version of
> X1-85 GPU with lower core count and smaller internal memories.
>
> Signed-off-by: Akhil P Oommen
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 38
> +++
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> index
> 70f7ad806c34076352d84f32d62c2833422b6e5e..2db748ce7df57a9151ed1e7f1b025a537bb5f653
> 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> @@ -1474,6 +1474,44 @@ static const struct adreno_info a7xx_gpus[] = {
> },
> },
> .preempt_record_size = 3572 * SZ_1K,
> + }, {
> + .chip_ids = ADRENO_CHIP_IDS(0x43030c00),
> + .family = ADRENO_7XX_GEN2,
> + .fw = {
> + [ADRENO_FW_SQE] = "gen71500_sqe.fw",
> + [ADRENO_FW_GMU] = "gen71500_gmu.bin",
Any chance of getting these and ZAP into linux-firmware?
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH 3/3] arm64: dts: qcom: Add GPU support to X1P42100 SoC
On Sat, Jun 07, 2025 at 07:45:01PM +0530, Akhil P Oommen wrote:
> X1P42100 SoC has a new GPU called Adreno X1-45 which is a smaller
> version of Adreno X1-85 GPU. Describe this new GPU and also add
> the secure gpu firmware path that should used for X1P42100 CRD.
>
> Signed-off-by: Akhil P Oommen
> ---
> arch/arm64/boot/dts/qcom/x1e80100.dtsi| 7 ++
> arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 4 +
> arch/arm64/boot/dts/qcom/x1p42100.dtsi| 121
> +-
> 3 files changed, 131 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> index
> a8eb4c5fe99fe6dd49af200a738b6476d87279b2..558d7d387d7710770244fcc901f461384dd9b0d4
> 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> @@ -8245,6 +8245,13 @@ sbsa_watchdog: watchdog@1c84 {
> interrupts = ;
> };
>
> + qfprom: efuse@221c8000 {
> + compatible = "qcom,x1e80100-qfprom", "qcom,qfprom";
> + reg = <0 0x221c8000 0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> +
> pmu@24091000 {
> compatible = "qcom,x1e80100-llcc-bwmon",
> "qcom,sc7280-llcc-bwmon";
> reg = <0 0x24091000 0 0x1000>;
> diff --git a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> index
> cf07860a63e97c388909fb5721ae7b9729b6c586..cf999c2cf8d4e0af83078253fd39ece3a0c26a49
> 100644
> --- a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> @@ -15,3 +15,7 @@ / {
> model = "Qualcomm Technologies, Inc. X1P42100 CRD";
> compatible = "qcom,x1p42100-crd", "qcom,x1p42100";
> };
> +
> +&gpu_zap_shader {
> + firmware-name = "qcom/x1p42100/gen71500_zap.mbn";
> +};
> diff --git a/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> index
> 27f479010bc330eb6445269a1c46bf78ec6f1bd4..5ed461ed5cca271d43647888aa6eacac3de2ac9d
> 100644
> --- a/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> @@ -17,15 +17,134 @@
> /delete-node/ &cpu_pd9;
> /delete-node/ &cpu_pd10;
> /delete-node/ &cpu_pd11;
> +/delete-node/ &gpu_opp_table;
> /delete-node/ &pcie3_phy;
>
> &gcc {
> compatible = "qcom,x1p42100-gcc", "qcom,x1e80100-gcc";
> };
>
> -/* The GPU is physically different and will be brought up later */
> +&gmu {
> + /delete-property/ compatible;
> + compatible = "qcom,adreno-gmu-x145.0", "qcom,adreno-gmu";
> +};
> +
> +&qfprom {
> + gpu_speed_bin: gpu_speed_bin@119 {
> + reg = <0x119 0x2>;
> + bits = <7 9>;
> + };
> +};
> +
> &gpu {
> /delete-property/ compatible;
I think, you can drop this line.
> +
> + compatible = "qcom,adreno-43030c00", "qcom,adreno";
> +
> + nvmem-cells = <&gpu_speed_bin>;
> + nvmem-cell-names = "speed_bin";
> +
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2-adreno",
> "operating-points-v2";
> +
> + opp-14 {
> + opp-hz = /bits/ 64 <14>;
> + opp-level = ;
> + opp-peak-kBps = <1650>;
> + qcom,opp-acd-level = <0xa8295ffd>;
> + opp-supported-hw = <0x3>;
> + };
> +
> + opp-125000 {
> + opp-hz = /bits/ 64 <125000>;
> + opp-level = ;
> + opp-peak-kBps = <1650>;
> + qcom,opp-acd-level = <0x882a5ffd>;
> + opp-supported-hw = <0x7>;
> + };
> +
> + opp-110700 {
> + opp-hz = /bits/ 64 <110700>;
> + opp-level = ;
> + opp-peak-kBps = <1650>;
> + qcom,opp-acd-level = <0x882a5ffd>;
> + opp-supported-hw = <0xf>;
> + };
> +
> + opp-101400 {
> + opp-hz = /bits/ 64 <101400>;
> + opp-level = ;
> + opp-peak-kBps = <14398438>;
> + qcom,opp-acd-level = <0xa82a5ffd>;
> + opp-supported-hw = <0xf>;
> + };
> +
> + opp-94000 {
> + opp-hz = /bits/ 64 <94000>;
> + opp-level = ;
> + opp-peak-kBps = <14398438>;
> + qcom,opp-acd-level = <0xa82a5ffd>;
> + opp-supported-hw = <0xf>;
> + };
> +
> + opp-82500 {
> + opp-hz = /bits/ 64 <82500>;
> + opp-level = ;
> + opp-peak-kBps = <12449219>;
> + qcom,opp-ac
Re: [PATCH 1/3] arm64: defconfig: Enable X1P42100_GPUCC driver
On Sat, Jun 07, 2025 at 07:44:59PM +0530, Akhil P Oommen wrote: > In order to enable GPU support in Snapdragon X1P42100 > (8 CPU core version), enable X1P42100 GPUCC driver as a module. ... it is used on Asus Zenbook A14 and other similar laptops. > > Signed-off-by: Akhil P Oommen > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index > 62d3c87858e1817bac291780dff3823dacd72510..9cc473fd0d3308f7869d00425e17b114c87093b2 > 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -1350,6 +1350,7 @@ CONFIG_CLK_X1E80100_CAMCC=m > CONFIG_CLK_X1E80100_DISPCC=m > CONFIG_CLK_X1E80100_GCC=y > CONFIG_CLK_X1E80100_GPUCC=m > +CONFIG_CLK_X1P42100_GPUCC=m > CONFIG_CLK_X1E80100_TCSRCC=y > CONFIG_CLK_QCM2290_GPUCC=m > CONFIG_QCOM_A53PLL=y > > -- > 2.48.1 > -- With best wishes Dmitry
Re: [PATCH v3 1/3] mm/hugetlb: Make hugetlb_reserve_pages() return nr of entries updated
On Fri, 6 Jun 2025 06:14:06 + "Kasireddy, Vivek" wrote: > > Also, patch [2/3] addresses a BUG which was introduced into 6.12. > > Presumably we want to backport the fix into -stable? If so, it's > > better to present this as a standalone patch, including the cc:stable > > tag. This is because I'd be looking to fast-track the fix into the > > 6.16-rcX cycle whereas less urgent things would be routed into > > 6.17-rc1. > Unless I merge patches #1 and #2, I don't think I can come up with a > standalone fix to address the BUG. So, I don't mind having this short > series deferred until 6.17-rc1. If I understand correctly, we have a way in which unprivileged userspace can trigger a BUG. Unless we're very lucky, this wrecks the running kernel. So fixing this in shipped kernels is very important. So if I indeed understand correctly, please try to find a minimal fix which is suitable for backporting and then, as a separate series, propose any changes which you think would improve things going forward. Thanks.
Re: [PATCH v6 01/11] mtd: core: always create master device
Hi, On Sun, Mar 02, 2025 at 04:09:11PM +0200, Alexander Usyskin wrote: > Create master device without partition when > CONFIG_MTD_PARTITIONED_MASTER flag is unset. > > This streamlines device tree and allows to anchor > runtime power management on master device in all cases. > > Signed-off-by: Alexander Usyskin Several of my qemu boot tests fail to boot from mtd devices with this patch in the mainline kernel. Reverting it fixes the problem. As far as I can see this affects configurations with CONFIG_MTD_PARTITIONED_MASTER=y when trying to boot from an mtd partition other than mtdblock0, with the mtd partition data in devicetree (.../aspeed/openbmc-flash-layout.dtsi). Is there a guidance describing the changed behavior, by any chance, and how the boot command line now needs to look like when using one of the flash partitions as root file system ? Thanks, Guenter
