* Re: [PATCH] arm64: tlb: Flush walk cache when unsharing PMD tables
From: Catalin Marinas @ 2026-05-22 10:13 UTC (permalink / raw)
To: Zeng Heng
Cc: yezhenyu2, zhurui3, will, akpm, npiggin, aneesh.kumar, peterz,
linux-kernel, wangkefeng.wang, linux-arm-kernel, linux-mm,
linux-arch, David Hildenbrand, zengheng4
In-Reply-To: <b7098272-a348-d918-774a-d5d2645fc7f4@huaweicloud.com>
On Fri, May 22, 2026 at 01:32:07PM +0800, Zeng Heng wrote:
> On 2026/5/21 23:15, Catalin Marinas wrote:
> > On Thu, May 21, 2026 at 04:05:07PM +0100, Catalin Marinas wrote:
> > > On Thu, May 21, 2026 at 03:30:11PM +0800, Zeng Heng wrote:
> > > > From: Zeng Heng <zengheng4@huawei.com>
> > > >
> > > > When huge_pmd_unshare() is called to unshare a PMD table, the
> > > > tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true
> > > > but the aarch64 tlb_flush() only checked tlb->freed_tables to
> > > > determine whether to use TLBF_NONE (vae1is, invalidates walk
> > > > cache) or TLBF_NOWALKCACHE (vale1is, leaf-only).
> > > >
> > > > This caused the stale PMD page table entry to remain in the walk cache
> > > > after unshare, potentially leading to incorrect page table walks.
> > > >
> > > > Fix by including unshared_tables in the check, so that when
> > > > unsharing tables, TLBF_NONE is used and the walk cache is properly
> > > > invalidated.
> > > >
> > > > Here is the detailed distinction between vae1is and vale1is:
> > > >
> > > > | Instruction Combination | Actual Invalidation Scope |
> > > > | ------------------------ | --------------------------------------------------|
> > > > | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) |
> > > > | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 |
> > > > | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) |
> > > > | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only |
> > > >
> > > > Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> > > The fix looks fine but does it need:
> > >
> > > Fixes: 8ce720d5bd91 ("mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather")
> > > Cc: <stable@vger.kernel.org>
> > >
> > > > ---
> > > > arch/arm64/include/asm/tlb.h | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
> > > > index 10869d7731b8..751bd57bc3ba 100644
> > > > --- a/arch/arm64/include/asm/tlb.h
> > > > +++ b/arch/arm64/include/asm/tlb.h
> > > > @@ -53,7 +53,8 @@ static inline int tlb_get_level(struct mmu_gather *tlb)
> > > > static inline void tlb_flush(struct mmu_gather *tlb)
> > > > {
> > > > struct vm_area_struct vma = TLB_FLUSH_VMA(tlb->mm, 0);
> > > > - tlbf_t flags = tlb->freed_tables ? TLBF_NONE : TLBF_NOWALKCACHE;
> > > > + tlbf_t flags = (tlb->freed_tables || tlb->unshared_tables) ?
> > > > + TLBF_NONE : TLBF_NOWALKCACHE;
> > > > unsigned long stride = tlb_get_unmap_size(tlb);
> > > > int tlb_level = tlb_get_level(tlb);
> > Do we need this as well?
>
> The proposed fix has been validated against the issue scenarios and
> works as expected.
>
> Per the ARM Architecture Reference Manual, whether only the last-level
> page table entry is invalidated is determined by the instruction used
> (vale1is for leaf entry only, vae1is for walk cache including leaf entry and
> non-leaf entry), rather than the TTL field. The TTL field merely specifies
> which level the leaf entry belongs to.
Ah, yes, you are right. The TTL is still 2 in this case for a huge pmd,
we just want the walk cache leading to it to be invalidated. So no need
for the additional tlb_get_level().
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v5 5/5] arm64: dts: qcom: glymur: Add GPU cooling
From: Akhil P Oommen @ 2026-05-22 10:12 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu, Akhil P Oommen,
Manaf Meethalavalappu Pallikunhi
In-Reply-To: <20260522-glymur-gpu-dt-v5-0-562c406b210c@oss.qualcomm.com>
From: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
The GPU does not throttle its speed automatically when it
reaches high temperatures. Set up GPU cooling by throttling
the GPU speed when it reaches 95°C.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 240 +++++++++++++++++++++++++++--------
1 file changed, 184 insertions(+), 56 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 01a2e32e503b..e109fb5b35a4 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -22,6 +22,7 @@
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
#include <dt-bindings/spmi/spmi.h>
+#include <dt-bindings/thermal/thermal.h>
#include "glymur-ipcc.h"
@@ -7149,13 +7150,22 @@ aoss-7-critical {
};
thermal_gpu_0_0: gpu-0-0-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 1>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu00_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu00_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-0-0-critical {
@@ -7164,16 +7174,26 @@ gpu-0-0-critical {
type = "critical";
};
};
+
};
thermal_gpu_0_1: gpu-0-1-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 2>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu01_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu01_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-0-1-critical {
@@ -7185,13 +7205,22 @@ gpu-0-1-critical {
};
thermal_gpu_0_2: gpu-0-2-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 3>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu02_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu02_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-0-2-critical {
@@ -7203,13 +7232,22 @@ gpu-0-2-critical {
};
thermal_gpu_1_0: gpu-1-0-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 4>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu10_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu10_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-1-0-critical {
@@ -7221,13 +7259,22 @@ gpu-1-0-critical {
};
thermal_gpu_1_1: gpu-1-1-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 5>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu11_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu11_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-1-1-critical {
@@ -7239,13 +7286,22 @@ gpu-1-1-critical {
};
thermal_gpu_1_2: gpu-1-2-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 6>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu12_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu12_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-1-2-critical {
@@ -7257,13 +7313,22 @@ gpu-1-2-critical {
};
thermal_gpu_2_0: gpu-2-0-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 7>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu20_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu20_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-2-0-critical {
@@ -7275,13 +7340,22 @@ gpu-2-0-critical {
};
thermal_gpu_2_1: gpu-2-1-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 8>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu21_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu21_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-2-1-critical {
@@ -7293,13 +7367,22 @@ gpu-2-1-critical {
};
thermal_gpu_2_2: gpu-2-2-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 9>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu22_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu22_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-2-2-critical {
@@ -7311,13 +7394,22 @@ gpu-2-2-critical {
};
thermal_gpu_3_0: gpu-3-0-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 10>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu30_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu30_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-3-0-critical {
@@ -7329,13 +7421,22 @@ gpu-3-0-critical {
};
thermal_gpu_3_1: gpu-3-1-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 11>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu31_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu31_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-3-1-critical {
@@ -7347,13 +7448,22 @@ gpu-3-1-critical {
};
thermal_gpu_3_2: gpu-3-2-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 12>;
+ cooling-maps {
+ map0 {
+ trip = <&gpu32_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpu32_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpu-3-2-critical {
@@ -7365,13 +7475,22 @@ gpu-3-2-critical {
};
thermal_gpuss_0: gpuss-0-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 13>;
+ cooling-maps {
+ map0 {
+ trip = <&gpuss0_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpuss0_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpuss-0-critical {
@@ -7383,13 +7502,22 @@ gpuss-0-critical {
};
thermal_gpuss_1: gpuss-1-thermal {
+ polling-delay-passive = <100>;
+
thermal-sensors = <&tsens7 14>;
+ cooling-maps {
+ map0 {
+ trip = <&gpuss1_alert0>;
+ cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
trips {
- trip-point0 {
- temperature = <90000>;
- hysteresis = <5000>;
- type = "hot";
+ gpuss1_alert0: trip-point0 {
+ temperature = <95000>;
+ hysteresis = <1000>;
+ type = "passive";
};
gpuss-1-critical {
--
2.51.0
^ permalink raw reply related
* [PATCH v5 4/5] arm64: dts: qcom: Add GPU support for Glymur
From: Akhil P Oommen @ 2026-05-22 10:12 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu, Akhil P Oommen, Konrad Dybcio
In-Reply-To: <20260522-glymur-gpu-dt-v5-0-562c406b210c@oss.qualcomm.com>
The Adreno X2 series GPU present in Glymur SoC belongs to the A8x
family. It is a new HW IP with architectural improvements as well
as different set of hw configs like GMEM, num SPs, Caches sizes etc.
Add the GPU and GMU nodes to describe this hardware.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 183 +++++++++++++++++++++++++++++++++++
1 file changed, 183 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 5e76a0d53f01..01a2e32e503b 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -3701,6 +3701,129 @@ hsc_noc: interconnect@2000000 {
#interconnect-cells = <2>;
};
+ gpu: gpu@3d00000 {
+ compatible = "qcom,adreno-44070001", "qcom,adreno";
+ reg = <0x0 0x03d00000 0x0 0x6c000>,
+ <0x0 0x03d9e000 0x0 0x2000>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem";
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommus = <&adreno_smmu 0 0x0>,
+ <&adreno_smmu 1 0x0>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ qcom,gmu = <&gmu>;
+ #cooling-cells = <2>;
+
+ interconnects = <&hsc_noc MASTER_GFX3D QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "gfx-mem";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2-adreno",
+ "operating-points-v2";
+
+ opp-310000000 {
+ opp-hz = /bits/ 64 <310000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+ opp-peak-kBps = <2136719>;
+ opp-supported-hw = <0xf>;
+ /* ACD is disabled */
+ };
+
+ opp-410000000 {
+ opp-hz = /bits/ 64 <410000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ opp-peak-kBps = <6074219>;
+ opp-supported-hw = <0xf>;
+ /* ACD is disabled */
+ };
+
+ opp-572000000 {
+ opp-hz = /bits/ 64 <572000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ opp-peak-kBps = <12449219>;
+ opp-supported-hw = <0xf>;
+ qcom,opp-acd-level = <0xe02d5ffd>;
+ };
+
+ opp-760000000 {
+ opp-hz = /bits/ 64 <760000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ opp-peak-kBps = <12449219>;
+ opp-supported-hw = <0xf>;
+ qcom,opp-acd-level = <0xc0285ffd>;
+ };
+
+ opp-820000000 {
+ opp-hz = /bits/ 64 <820000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L2>;
+ opp-peak-kBps = <16500000>;
+ opp-supported-hw = <0xf>;
+ qcom,opp-acd-level = <0xa82e5ffd>;
+ };
+
+ opp-915000000 {
+ opp-hz = /bits/ 64 <915000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ opp-peak-kBps = <16500000>;
+ opp-supported-hw = <0xf>;
+ qcom,opp-acd-level = <0x882d5ffd>;
+ };
+
+ opp-1070000000 {
+ opp-hz = /bits/ 64 <1070000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
+ opp-peak-kBps = <16500000>;
+ opp-supported-hw = <0xf>;
+ qcom,opp-acd-level = <0x882b5ffd>;
+ };
+
+ opp-1185000000 {
+ opp-hz = /bits/ 64 <1185000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
+ opp-peak-kBps = <16500000>;
+ opp-supported-hw = <0xf>;
+ qcom,opp-acd-level = <0x882a5ffd>;
+ };
+
+ opp-1350000000 {
+ opp-hz = /bits/ 64 <1350000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
+ opp-peak-kBps = <18597657>;
+ opp-supported-hw = <0xf>;
+ qcom,opp-acd-level = <0x882a5ffd>;
+ };
+
+ opp-1550000000 {
+ opp-hz = /bits/ 64 <1550000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L3>;
+ opp-peak-kBps = <18597657>;
+ opp-supported-hw = <0x7>;
+ qcom,opp-acd-level = <0xa8295ffd>;
+ };
+
+ opp-1700000000 {
+ opp-hz = /bits/ 64 <1700000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L4>;
+ opp-peak-kBps = <18597657>;
+ opp-supported-hw = <0x7>;
+ qcom,opp-acd-level = <0x88295ffd>;
+ };
+
+ opp-1850000000 {
+ opp-hz = /bits/ 64 <1850000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L5>;
+ opp-peak-kBps = <18597657>;
+ opp-supported-hw = <0x3>;
+ qcom,opp-acd-level = <0x88285ffd>;
+ };
+ };
+ };
+
gxclkctl: clock-controller@3d64000 {
compatible = "qcom,glymur-gxclkctl";
reg = <0x0 0x03d64000 0x0 0x6000>;
@@ -3712,6 +3835,66 @@ gxclkctl: clock-controller@3d64000 {
#power-domain-cells = <1>;
};
+ gmu: gmu@3d6c000 {
+ compatible = "qcom,adreno-gmu-x285.1", "qcom,adreno-gmu";
+
+ reg = <0x0 0x03d6c000 0x0 0x32000>;
+ reg-names = "gmu";
+
+ interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hfi",
+ "gmu";
+
+ clocks = <&gpucc GPU_CC_AHB_CLK>,
+ <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_GPU_GEMNOC_GFX_CLK>,
+ <&gpucc GPU_CC_HUB_CX_INT_CLK>,
+ <&gpucc GPU_CC_RSCC_HUB_AON_CLK>;
+ clock-names = "ahb",
+ "gmu",
+ "cxo",
+ "memnoc",
+ "hub",
+ "rscc";
+
+ power-domains = <&gpucc GPU_CC_CX_GDSC>,
+ <&gxclkctl GX_CLKCTL_GX_GDSC>;
+ power-domain-names = "cx",
+ "gx";
+
+ iommus = <&adreno_smmu 5 0x0>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-575000000 {
+ opp-hz = /bits/ 64 <575000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ };
+
+ opp-700000000 {
+ opp-hz = /bits/ 64 <700000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ };
+
+ opp-725000000 {
+ opp-hz = /bits/ 64 <725000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ };
+
+ opp-750000000 {
+ opp-hz = /bits/ 64 <750000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
+ };
+ };
+ };
+
gpucc: clock-controller@3d90000 {
compatible = "qcom,glymur-gpucc";
reg = <0x0 0x03d90000 0x0 0x9800>;
--
2.51.0
^ permalink raw reply related
* [PATCH v5 3/5] arm64: dts: qcom: glymur: Add GPU smmu node
From: Akhil P Oommen @ 2026-05-22 10:11 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu, Akhil P Oommen, Rajendra Nayak,
Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260522-glymur-gpu-dt-v5-0-562c406b210c@oss.qualcomm.com>
From: Rajendra Nayak <rajendra.nayak@oss.qualcomm.com>
Add the nodes to describe the GPU SMMU node.
Signed-off-by: Rajendra Nayak <rajendra.nayak@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 38 ++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index ed9aac42fcbf..5e76a0d53f01 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -3729,6 +3729,44 @@ gpucc: clock-controller@3d90000 {
#power-domain-cells = <1>;
};
+ adreno_smmu: iommu@3da0000 {
+ compatible = "qcom,glymur-smmu-500", "qcom,adreno-smmu",
+ "qcom,smmu-500", "arm,mmu-500";
+ reg = <0x0 0x03da0000 0x0 0x40000>;
+ #iommu-cells = <2>;
+ #global-interrupts = <1>;
+ interrupts = <GIC_SPI 674 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 681 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 682 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 683 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 684 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 685 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 686 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 687 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 476 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 574 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 575 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 576 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 577 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 660 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 662 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 665 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 666 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 667 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 669 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 670 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 700 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gpucc GPU_CC_GPU_SMMU_VOTE_CLK>;
+ clock-names = "hlos";
+ power-domains = <&gpucc GPU_CC_CX_GDSC>;
+ dma-coherent;
+ };
+
ipcc: mailbox@3e04000 {
compatible = "qcom,glymur-ipcc", "qcom,ipcc";
reg = <0x0 0x03e04000 0x0 0x1000>;
--
2.51.0
^ permalink raw reply related
* [PATCH v5 2/5] dt-bindings: display/msm: gpu: Document Adreno X2-185
From: Akhil P Oommen @ 2026-05-22 10:11 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu, Akhil P Oommen
In-Reply-To: <20260522-glymur-gpu-dt-v5-0-562c406b210c@oss.qualcomm.com>
Adreno X2-185 GPU found in Glymur chipsets belongs to the A8x family.
It features a new slice architecture with 4 slices, significantly higher
bandwidth throughput compared to mobile counterparts, raytracing support,
and the highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among
other improvements. Update the dt bindings documentation to describe this
GPU.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index 04b2328903ca..77caacd0fb3f 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -411,6 +411,21 @@ allOf:
- clocks
- clock-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,adreno-44070001
+ then:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+
+ reg-names:
+ minItems: 2
+ maxItems: 2
+
- if:
properties:
compatible:
@@ -434,6 +449,7 @@ allOf:
- qcom,adreno-43050a01
- qcom,adreno-43050c01
- qcom,adreno-43051401
+ - qcom,adreno-44070001
then: # Starting with A6xx, the clocks are usually defined in the GMU node
properties:
--
2.51.0
^ permalink raw reply related
* [PATCH v5 1/5] drm/msm/a8xx: Fix RSCC offset
From: Akhil P Oommen @ 2026-05-22 10:11 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu, Akhil P Oommen
In-Reply-To: <20260522-glymur-gpu-dt-v5-0-562c406b210c@oss.qualcomm.com>
In A8xx, the RSCC block is part of GPU's register space. Update the
virtual base address of rscc to point to the correct address.
Fixes: 50e8a557d8d3 ("drm/msm/a8xx: Add support for A8x GMU")
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 1b44b9e21ad8..cab4c46c6cf2 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -2357,7 +2357,12 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
goto err_mmio;
}
} else if (adreno_is_a8xx(adreno_gpu)) {
- gmu->rscc = gmu->mmio + 0x19000;
+ /*
+ * On a8xx , RSCC lives at GPU base + 0x50000, which falls
+ * inside the GPU's kgsl_3d0_reg_memory range rather than the
+ * GMU's.
+ */
+ gmu->rscc = gpu->mmio + 0x50000;
} else {
gmu->rscc = gmu->mmio + 0x23000;
}
--
2.51.0
^ permalink raw reply related
* [PATCH v5 0/5] Devicetree support for Glymur GPU
From: Akhil P Oommen @ 2026-05-22 10:11 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Will Deacon, Robin Murphy, Joerg Roedel
Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
linux-arm-kernel, iommu, Akhil P Oommen, Rajendra Nayak,
Konrad Dybcio, Dmitry Baryshkov, Manaf Meethalavalappu Pallikunhi
This series adds the necessary Device Tree bits to enable GPU support
on the Glymur-based CRD devices. The Adreno X2-85 GPU present in Glymur
chipsets is based on the new Adreno A8x family of GPUs. It features a new
slice architecture with 4 slices, significantly higher bandwidth
throughput compared to mobile counterparts, raytracing support, and the
highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among other
improvements.
This series includes patches that updates DT schema, add GPU SMMU &
GPU/GMU support. Keen-eyed readers may notice that the zap shader node
is missing. This is intentional: The Glymur-based laptop platforms
generally allow booting Linux at EL2 (yay!), which means the zap firmware
is not required here.
There is an update to the gxclkctl/drm drivers to properly support the IFPC
feature across all A8x GPUs. That series [1] is necessary to properly
support Glymur GPU:
[1] https://lore.kernel.org/lkml/20260427-gfx-clk-fixes-v2-0-797e54b3d464@oss.qualcomm.com/
Just FYI, on top of the linux-next, I had to pick below series [2] to boot
the device properly. But it is unrelated to GPU or this series:
[2] https://lore.kernel.org/all/20260331-qref_vote-v1-0-3fd7fbf87864@oss.qualcomm.com/
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Changes in v5:
- Relax contraints for reg-names property (Krzysztof)
- Drop the smmu binding doc patch as it got picked up
- Link to v4: https://lore.kernel.org/r/20260513-glymur-gpu-dt-v4-0-f83832c3bc9a@oss.qualcomm.com
Changes in v4:
- Add a new patch for passive cooling support
- Link to v3: https://lore.kernel.org/r/20260512-glymur-gpu-dt-v3-0-84232dc21c03@oss.qualcomm.com
Changes in v3:
- Add a new patch to fix RSCC base vaddr in drm-msm
- Remove interconnect property from adreno smmu dt and the binding doc
- Add a contrait in GPU binding doc to limit the reg entries for Glymur
(Krzysztof)
- Link to v2: https://lore.kernel.org/r/20260501-glymur-gpu-dt-v2-0-2f128b5596bb@oss.qualcomm.com
Changes in v2:
- Keep GPU/GMU enabled by default and drop the enablement patch (Konrad)
- Drop zap shader node from DT
- A new patch to update GPU SMMU dt schema.
- Adjust reg range in dt nodes to avoid overlap.
- Removed cx_dbgc range as it is already stable across chipsets. This
region is now part of kgsl_3d0_reg_memory range.
- Link to v1: https://lore.kernel.org/r/20260405-glymur-gpu-dt-v1-0-2135eb11c562@oss.qualcomm.com
---
Akhil P Oommen (3):
drm/msm/a8xx: Fix RSCC offset
dt-bindings: display/msm: gpu: Document Adreno X2-185
arm64: dts: qcom: Add GPU support for Glymur
Manaf Meethalavalappu Pallikunhi (1):
arm64: dts: qcom: glymur: Add GPU cooling
Rajendra Nayak (1):
arm64: dts: qcom: glymur: Add GPU smmu node
.../devicetree/bindings/display/msm/gpu.yaml | 16 +
arch/arm64/boot/dts/qcom/glymur.dtsi | 461 ++++++++++++++++++---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 7 +-
3 files changed, 427 insertions(+), 57 deletions(-)
---
base-commit: c9bd03db3e792a99e9789fde20e91898e3a29e8a
change-id: 20260226-glymur-gpu-dt-339e5092606b
prerequisite-message-id: <20260410-glymur_mmcc_dt_config_v2-v3-0-acce9d106e72@oss.qualcomm.com>
prerequisite-patch-id: f7ab29f2f0241b6536d3b0c0593f0baa0e435221
prerequisite-patch-id: 56c830b7718129323b006e492aed9822d7c30079
Best regards,
--
Akhil P Oommen <akhilpo@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v8 next 02/10] arm_mpam: Add intPARTID and reqPARTID support for Narrow-PARTID feature
From: Zeng Heng @ 2026-05-22 10:07 UTC (permalink / raw)
To: James Morse, ben.horgan, Dave.Martin, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, wangkefeng.wang, zengheng4
In-Reply-To: <763d19a5-9b1a-4243-a7d7-9484c42c32c7@arm.com>
Hi James,
On 2026/5/15 1:06, James Morse wrote:
> Hi Zeng,
>
> On 13/04/2026 09:53, Zeng Heng wrote:
>> Introduce Narrow-PARTID (partid_nrw) feature support, which enables
>> many-to-one mapping of request PARTIDs (reqPARTID) to internal PARTIDs
>> (intPARTID). This expands monitoring capability by allowing a single
>> control group to track more task types through multiple reqPARTIDs
>> per intPARTID, bypassing the PMG limit in some extent.
>>
>> intPARTID: Internal PARTID used for control group configuration.
>> Configurations are synchronized to all reqPARTIDs mapped to the same
>> intPARTID. Count is indicated by MPAMF_PARTID_NRW_IDR.INTPARTID_MAX, or
>> defaults to PARTID count if Narrow-PARTID is unsupported.
>>
>> reqPARTID: Request PARTID used to expand monitoring groups. Enables
>> a single control group to monitor more task types by multiple reqPARTIDs
>> within one intPARTID, overcoming the PMG count limitation.
>>
>> For systems with homogeneous MSCs (all supporting Narrow-PARTID), the
>> driver exposes the full reqPARTID range directly. For heterogeneous
>> systems where some MSCs lack Narrow-PARTID support, the driver utilizes
>> PARTIDs beyond the intPARTID range as reqPARTIDs to expand monitoring
>> capacity.
>>
>> So, the numbers of control group and monitoring group are calculated as:
>>
>> n = min(intPARTID, PARTID) /* the number of control groups */
>> l = min(reqPARTID, PARTID) /* the number of monitoring groups */
>> m = l // n /* monitoring groups per control group */
>>
>> Where:
>>
>> intPARTID: intPARTIDs on Narrow-PARTID-capable MSCs
>> reqPARTID: reqPARTIDs on Narrow-PARTID-capable MSCs
>> PARTID: PARTIDs on non-Narrow-PARTID-capable MSCs
>>
>> Example: L3 cache (256 PARTIDs, without Narrow-PARTID feature) +
>> MATA (32 intPARTIDs, 256 reqPARTIDs):
>>
>> n = min( 32, 256) = 32 intPARTIDs
>> l = min(256, 256) = 256 reqPARTIDs
>> m = 256 / 32 = 8 reqPARTIDs per intPARTID
>>
>> Implementation notes:
>> * Handle mixed MSC systems (some support Narrow-PARTID, some don't) by
>> taking minimum number of intPARTIDs across all MSCs.
>> * resctrl_arch_get_num_closid() now returns the number of intPARTIDs
>> (was PARTID).
>
> What you're doing here is making intPARTID the fundamental unit in MPAM. I
> don't think we should do this as its not true in the architecture: narrowing
> is a single, optional feature. We have platforms that don't support narrowing
> at all - so having to think in terms of "what is the intPARTID limit on this
> platform that doesn't have the feature" is confusing.
> Narrowing doesn't affect the monitoring, so you can't just string-replace the
> driver.
>
> The resctrl glue code is going to have to know about narrowing as it must
> either duplicate the control values for aliasing PARTID, or remap them using
> narrowing.
>
> I'd prefer it if the mpam_devices code exposed an API to make use of narrowing
> that makes sense given the MPAM architecture. (e.g. narrowing is optional!)
> Whetever resctrl needs should then be built on top of that.
>
>
> Currently the MAX PARTID/PMG are dealt with separately as we need a global value
> at the end. It was done separately as it could be a patch on its own, to try and
> keep each patch reviewable.
> But it should probably have been dealt with the same way we deal with all MSC
> features - stash them in struct mpam_msc_ris at hw_probe time, and combine them
> up to the class level handling different values with __props_mismatch().
> The global state that includes the requestors can be created after that point.
>
> I think we should do this now to add intpartid_max to struct mpam_props so that the
> resctrl glue code can find the intpartid_max per class. I don't think it makes sense as
> a global property. (we should move partid_max and pmg_max at the same time)
>
> ... I think moving partid_max would just be cleanup. The resctrl glue code needs to
> know the maximum PARTID for monitoring, but I think this would always be the global
> PARTID max value.
>
I'll have a try to look into refactoring the existing code along the
lines you've suggested.
>
>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>> index 41b14344b16f..cf067bf5092e 100644
>> --- a/drivers/resctrl/mpam_devices.c
>> +++ b/drivers/resctrl/mpam_devices.c
>> @@ -63,6 +63,7 @@ static DEFINE_MUTEX(mpam_cpuhp_state_lock);
>> * Generating traffic outside this range will result in screaming interrupts.
>> */
>> u16 mpam_partid_max;
>> +u16 mpam_intpartid_max;
>> u8 mpam_pmg_max;
>> static bool partid_max_init, partid_max_published;
>> static DEFINE_SPINLOCK(partid_max_lock);
>
> The global properties are supposed to mean "if you generate any traffic outside
> this range, you'll get an out of range error causing mpam_disable()".
>
> This doesn't hold for intPARTID.
>
> In my hypothetical system from the cover letter: {
> 64 PARTID at the L3
> 64 PARTID and narrowing to 16 at the SLC
> 64 PARTID and narrowing to 32 at the memory-controller
>
> The resctrl glue code could ignore the SLC if it wanted to use 32 PARTID, and just
> duplicate the aliasing controls at L3. (and remove the non-aliasing controls)
> }
>
>
Thanks for the example.
Best regards,
Zeng Heng
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: clemente: Remove IOB NIC TMP421 nodes
From: Mike Hsieh @ 2026-05-22 10:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Potin Lai, Mike Hsieh, Mike Hsieh
Remove the TMP421 sensor entry from the DTS, as it is no longer the
primary telemetry source.
Accessing the CX8 NIC via I2C while it is powered off causes voltage
leakage on the bus, leading to EEPROM corruption on shared I2C devices.
Removing this node prevents the BMC from initiating traffic to the NIC
during initialization, protecting the integrity of the shared bus.
Signed-off-by: Mike Hsieh <mike.quanta.115@gmail.com>
---
Remove the TMP421 sensor entry from the DTS, as it is no longer the
primary telemetry source.
Accessing the CX8 NIC via I2C while it is powered off causes voltage
leakage on the bus, leading to EEPROM corruption on shared I2C devices.
Removing this node prevents the BMC from initiating traffic to the NIC
during initialization, protecting the integrity of the shared bus.
---
.../boot/dts/aspeed/aspeed-bmc-facebook-clemente.dts | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-clemente.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-clemente.dts
index 2aff21442f11..820d39a92974 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-clemente.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-clemente.dts
@@ -443,11 +443,6 @@ i2c0mux2ch0: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
- // IOB0 NIC0 TEMP
- temperature-sensor@1f {
- compatible = "ti,tmp421";
- reg = <0x1f>;
- };
};
i2c0mux2ch1: i2c@1 {
@@ -466,11 +461,6 @@ i2c0mux2ch3: i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
- // IOB0 NIC1 TEMP
- temperature-sensor@1f {
- compatible = "ti,tmp421";
- reg = <0x1f>;
- };
};
};
@@ -637,11 +627,6 @@ i2c0mux5ch0: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
- // IOB1 NIC0 TEMP
- temperature-sensor@1f {
- compatible = "ti,tmp421";
- reg = <0x1f>;
- };
};
i2c0mux5ch1: i2c@1 {
@@ -666,11 +651,6 @@ i2c0mux5ch3: i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
- // IOB1 NIC1 TEMP
- temperature-sensor@1f {
- compatible = "ti,tmp421";
- reg = <0x1f>;
- };
};
};
};
---
base-commit: 6779b50faa562e6cca1aa6a4649a4d764c6c7e28
change-id: 20260522-clemente-dts-remove-iob-nic-tmp421-89221ba96dd7
Best regards,
--
Mike Hsieh <mike.quanta.115@gmail.com>
^ permalink raw reply related
* [PATCH 3/3] ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence
From: phucduc.bui @ 2026-05-22 10:03 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, perex, tiwai, heiko, linux-arm-kernel, linux-kernel,
linux-sound, linux-rockchip, robh, krzk+dt, conor+dt, devicetree,
bui duc phuc
In-Reply-To: <20260522100318.73474-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Enable the 'hclk' bus clock before the 'clk' controller
clock during runtime resume.
The bus clock provides the register access interface and
should be enabled before the controller clock.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/rockchip/rockchip_pdm.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_pdm.c b/sound/soc/rockchip/rockchip_pdm.c
index c69cdd6f2499..8f78f7bc1806 100644
--- a/sound/soc/rockchip/rockchip_pdm.c
+++ b/sound/soc/rockchip/rockchip_pdm.c
@@ -422,16 +422,16 @@ static int rockchip_pdm_runtime_resume(struct device *dev)
struct rk_pdm_dev *pdm = dev_get_drvdata(dev);
int ret;
- ret = clk_prepare_enable(pdm->clk);
+ ret = clk_prepare_enable(pdm->hclk);
if (ret) {
- dev_err(pdm->dev, "clock enable failed %d\n", ret);
+ dev_err(pdm->dev, "hclock enable failed %d\n", ret);
return ret;
}
- ret = clk_prepare_enable(pdm->hclk);
+ ret = clk_prepare_enable(pdm->clk);
if (ret) {
- clk_disable_unprepare(pdm->clk);
- dev_err(pdm->dev, "hclock enable failed %d\n", ret);
+ clk_disable_unprepare(pdm->hclk);
+ dev_err(pdm->dev, "clock enable failed %d\n", ret);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] ASoC: rockchip: spdif: Reorder clock enable sequence
From: phucduc.bui @ 2026-05-22 10:03 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, perex, tiwai, heiko, linux-arm-kernel, linux-kernel,
linux-sound, linux-rockchip, robh, krzk+dt, conor+dt, devicetree,
bui duc phuc
In-Reply-To: <20260522100318.73474-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Enable the 'hclk' bus clock before the 'mclk' controller
clock during runtime resume.
The bus clock provides the register access interface and
should be enabled before the controller clock.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/rockchip/rockchip_spdif.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_spdif.c b/sound/soc/rockchip/rockchip_spdif.c
index 581624f2682e..8de5b76cfe79 100644
--- a/sound/soc/rockchip/rockchip_spdif.c
+++ b/sound/soc/rockchip/rockchip_spdif.c
@@ -76,16 +76,16 @@ static int rk_spdif_runtime_resume(struct device *dev)
struct rk_spdif_dev *spdif = dev_get_drvdata(dev);
int ret;
- ret = clk_prepare_enable(spdif->mclk);
+ ret = clk_prepare_enable(spdif->hclk);
if (ret) {
- dev_err(spdif->dev, "mclk clock enable failed %d\n", ret);
+ dev_err(spdif->dev, "hclk clock enable failed %d\n", ret);
return ret;
}
- ret = clk_prepare_enable(spdif->hclk);
+ ret = clk_prepare_enable(spdif->mclk);
if (ret) {
- clk_disable_unprepare(spdif->mclk);
- dev_err(spdif->dev, "hclk clock enable failed %d\n", ret);
+ clk_disable_unprepare(spdif->hclk);
+ dev_err(spdif->dev, "mclk clock enable failed %d\n", ret);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 1/3] ASoC: dt-bindings: rockchip-spdif: Correct SPDIF clock descriptions
From: phucduc.bui @ 2026-05-22 10:03 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, perex, tiwai, heiko, linux-arm-kernel, linux-kernel,
linux-sound, linux-rockchip, robh, krzk+dt, conor+dt, devicetree,
bui duc phuc
In-Reply-To: <20260522100318.73474-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
The clock descriptions are currently swapped relative to the
clock names used by the driver.
Update the binding descriptions to match the actual clock
usage, where 'mclk' is the controller clock and 'hclk' is
the bus clock.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Documentation/devicetree/bindings/sound/rockchip-spdif.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
index 502907dd28b3..b174d7498029 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
@@ -45,8 +45,8 @@ properties:
clocks:
items:
- - description: clock for SPDIF bus
- description: clock for SPDIF controller
+ - description: clock for SPDIF bus
clock-names:
items:
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] ASoC: rockchip: Reorder clock enable sequence
From: phucduc.bui @ 2026-05-22 10:03 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, perex, tiwai, heiko, linux-arm-kernel, linux-kernel,
linux-sound, linux-rockchip, robh, krzk+dt, conor+dt, devicetree,
bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Hi all,
This series reorders the runtime resume clock enable
sequence in the Rockchip SPDIF and PDM drivers to enable
the bus clock before the functional controller clock.
It also updates the SPDIF DT binding clock descriptions to
match the actual clock usage in the driver.
Best Regards,
Phuc
bui duc phuc (3):
ASoC: dt-bindings: rockchip-spdif: Correct SPDIF clock descriptions
ASoC: rockchip: spdif: Reorder clock enable sequence
ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence
.../devicetree/bindings/sound/rockchip-spdif.yaml | 2 +-
sound/soc/rockchip/rockchip_pdm.c | 10 +++++-----
sound/soc/rockchip/rockchip_spdif.c | 10 +++++-----
3 files changed, 11 insertions(+), 11 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v14 09/44] arm64: RMI: Provide functions to delegate/undelegate ranges of memory
From: Marc Zyngier @ 2026-05-22 10:02 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Steven Price, kvm, kvmarm, Catalin Marinas, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <a81c3688-30f1-43e4-8d57-1d08a6e563af@arm.com>
On Thu, 21 May 2026 17:01:37 +0100,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
> On 21/05/2026 14:59, Marc Zyngier wrote:
> > On Wed, 13 May 2026 14:17:17 +0100,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> The RMM requires memory is 'delegated' to it so that it can be used
> >> either for a realm guest or for various tracking purposes within the RMM
> >> (e.g. for metadata or page tables). Memory that has been delegated
> >> cannot be accessed by the host (it will result in a Granule Protection
> >> Fault).
> >>
> >> Undelegation may fail if the memory is still in use by the RMM. This
> >> shouldn't happen (Linux should ensure it has destroyed the RMM objects
> >> before attempting to undelegate). In the event that it does happen this
> >> points to a programming bug and the only reasonable approach is for the
> >> physical pages to be leaked - it is up to the caller of
> >> rmi_undelegate_range() to handle this.
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> ---
> >> v14:
> >> * Split into separate patch and moved out of KVM
> >> ---
> >> arch/arm64/include/asm/rmi_cmds.h | 13 +++++++++++
> >> arch/arm64/kernel/rmi.c | 36 +++++++++++++++++++++++++++++++
> >> 2 files changed, 49 insertions(+)
> >>
> >> diff --git a/arch/arm64/include/asm/rmi_cmds.h b/arch/arm64/include/asm/rmi_cmds.h
> >> index 9078a2920a7c..eb213c8e6f26 100644
> >> --- a/arch/arm64/include/asm/rmi_cmds.h
> >> +++ b/arch/arm64/include/asm/rmi_cmds.h
> >> @@ -33,6 +33,19 @@ struct rmi_sro_state {
> >> } while (RMI_RETURN_STATUS(res.a0) == RMI_BUSY || \
> >> RMI_RETURN_STATUS(res.a0) == RMI_BLOCKED)
> >> +int rmi_delegate_range(phys_addr_t phys, unsigned long size);
> >> +int rmi_undelegate_range(phys_addr_t phys, unsigned long size);
> >> +
> >> +static inline int rmi_delegate_page(phys_addr_t phys)
> >> +{
> >> + return rmi_delegate_range(phys, PAGE_SIZE);
> >> +}
> >> +
> >> +static inline int rmi_undelegate_page(phys_addr_t phys)
> >> +{
> >> + return rmi_undelegate_range(phys, PAGE_SIZE);
> >> +}
> >> +
> >> bool rmi_is_available(void);
> >> unsigned long rmi_sro_execute(struct rmi_sro_state *sro, gfp_t
> >> gfp);
> >> diff --git a/arch/arm64/kernel/rmi.c b/arch/arm64/kernel/rmi.c
> >> index 52a415e99500..08cef54acadb 100644
> >> --- a/arch/arm64/kernel/rmi.c
> >> +++ b/arch/arm64/kernel/rmi.c
> >> @@ -12,6 +12,42 @@ static bool arm64_rmi_is_available;
> >> unsigned long rmm_feat_reg0;
> >> unsigned long rmm_feat_reg1;
> >> +int rmi_delegate_range(phys_addr_t phys, unsigned long size)
> >> +{
> >> + unsigned long ret = 0;
> >> + unsigned long top = phys + size;
> >> + unsigned long out_top;
> >> +
> >> + while (phys < top) {
> >> + ret = rmi_granule_range_delegate(phys, top, &out_top);
> >> + if (ret == RMI_SUCCESS)
> >> + phys = out_top;
> >> + else if (ret != RMI_BUSY && ret != RMI_BLOCKED)
> >> + return ret;
> >> + }
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +int rmi_undelegate_range(phys_addr_t phys, unsigned long size)
> >> +{
> >> + unsigned long ret = 0;
> >> + unsigned long top = phys + size;
> >> + unsigned long out_top;
> >> +
> >> + WARN_ON(size == 0);
> >
> > I find it odd to warn on size = 0. After all, free(NULL) is not an
> > error. But even then, you continue feeding this to the RMM.
> >
> > You also don't seem to be bothered with that on the delegation side...
> >
> >> +
> >> + while (phys < top) {
> >> + ret = rmi_granule_range_undelegate(phys, top, &out_top);
> >> + if (ret == RMI_SUCCESS)
> >> + phys = out_top;
> >
> > and size==0 doesn't violate any of the failure conditions listed in
> > B4.5.18.2 (beta2). Will you end-up looping around forever?
>
> That is not true ? It triggers, top_bound error condition, for both.
>
>
> pre: UInt(top) <= UInt(base)
> post: result.status == RMI_ERROR_INPUT
News flash, I can't read. Ignore me.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v8 next 03/10] arm_mpam: Disable reqPARTID expansion when Narrow-PARTID is unavailable
From: Zeng Heng @ 2026-05-22 9:57 UTC (permalink / raw)
To: James Morse, ben.horgan, Dave.Martin, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, wangkefeng.wang, zengheng4
In-Reply-To: <9efc30be-689b-4f42-bef0-d7d62b4392fa@arm.com>
Hi James,
On 2026/5/15 1:06, James Morse wrote:
> Hi Zeng,
>
> On 13/04/2026 09:53, Zeng Heng wrote:
>> MPAM supports heterogeneous systems where some type of MSCs may implement
>> Narrow-PARTID while others do not. However, when an MSC uses
>> percentage-based throttling (non-bitmap partition control) and lacks
>> Narrow-PARTID support, resctrl cannot correctly apply control group
>> configurations across multiple PARTIDs.
>>
>> To enable free assignment of multiple reqPARTIDs to resource control
>> groups, all MSCs used by resctrl must either: Implement Narrow-PARTID,
>> allowing explicit PARTID remapping, or only have stateless resource
>> controls (non-percentage-based), such that splitting a control group
>> across multiple PARTIDs does not affect behavior.
>
> I prefer Dave's terminology for this: aliasing and non-aliasing. It implies
> there are two controls, which stateless does not.
>
OK, count me as a fan of the terminology too.
>
>> The detection occurs at initialization time on the first call to
>> get_num_reqpartid() from update_rmid_limits(). This call is guaranteed
>> to occur after mpam_resctrl_pick_{mba,caches}() have set up the
>> resource classes, ensuring the necessary properties are available
>> for the Narrow-PARTID capability check.
>>
>> When an MSC with percentage-based control lacks Narrow-PARTID support,
>> get_num_reqpartid() falls back to returning the number of intPARTIDs,
>> effectively disabling the reqPARTID expansion for monitoring groups.
>
> No MSC has percentage based controls - that's an x86ism. The MSCs have
> fixed point fractions, bitmaps or a cost/weight.
>
Yes, thanks for head-up: it's x86ism.
>
> I think you're thinking about this the wrong way up - we should only enable
> this on a small number of platforms that don't have any controls we'd have to discard.
> (hopefully yours is such a platform!)
>
> I don't think this should be added to resctrl_arch_system_num_rmid_idx(). Please make
> this decision for resctrl at mpam_resctrl_setup() time.
>
>
>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
>> index 5f4364c8101a..56859f354efa 100644
>> --- a/drivers/resctrl/mpam_resctrl.c
>> +++ b/drivers/resctrl/mpam_resctrl.c
>> @@ -257,9 +257,50 @@ u32 resctrl_arch_get_num_closid(struct rdt_resource *ignored)
>> return mpam_intpartid_max + 1;
>> }
>>
>> +/*
>> + * Determine the effective number of PARTIDs available for resctrl.
>> + *
>> + * This function performs a one-time check to determine if Narrow-PARTID
>> + * can be used. It must be called after mpam_resctrl_pick_{mba,caches}()
>> + * have initialized the resource classes, as class properties are used
>> + * to detect Narrow-PARTID support.
>
>> + * The first call occurs in update_rmid_limits(), ensuring the
>> + * prerequisite initialization is complete.
>
> This is fragile to changes in the order resctrl makes these calls. We need these
> properties to be fixed before we call resctrl_init().
>
> (yes - I think CDP is fragile too!)
It makes sense to me.
>
>
>> + */
>> +static u32 get_num_reqpartid(void)
>> +{
>> + struct mpam_resctrl_res *res;
>> + struct mpam_props *cprops;
>> + static bool first = true;
>> + int rid;
>> +
>> + if (first) {
>> + for_each_mpam_resctrl_control(res, rid) {
>> + if (!res->class)
>> + continue;
>> +
>> + cprops = &res->class->props;
>> + if (mpam_has_feature(mpam_feat_partid_nrw, cprops))
>> + continue;
>
>
>> + if (mpam_has_feature(mpam_feat_mbw_max, cprops) ||
>> + mpam_has_feature(mpam_feat_mbw_min, cprops) ||
>> + mpam_has_feature(mpam_feat_cmax_cmax, cprops) ||
>> + mpam_has_feature(mpam_feat_cmax_cmin, cprops)) {
>
> Please make this a helper in mpam_internal.h with 'controls' and 'aliasing' in its name.
> (maybe has_aliasing_controls()).
>
> What about the priority for PRI and the proportional-stride?
>
> I don't think proportional-stride aliases properly: if I have groups with stride 1 and 2,
> I can't add a second '2' without decreasing the first groups stride from 1/3 to 1/5. If I
> halve the second groups, they each get half the bandwidth instead of sharing it.
>
> Can you check whether the priority for PRI aliases?
>
Proportional-stride is indeed a non-aliasing control, and this was an
oversight on my part (I haven't actually encountered this control option
before).
I'd argue that PRI is an aliasing control: the priority value defines a
scheduling class or identity. When multiple PARTIDs share the same
priority, it's akin to multiple users holding the same VIP tier. They
compete for resources within that same category, rather than each
receiving an independent, additive allocation.
Best regards,
Zeng Heng
^ permalink raw reply
* [PATCH] ASoC: sunxi: sun50i-dmic: Reorder clock enable sequence
From: phucduc.bui @ 2026-05-22 9:55 UTC (permalink / raw)
To: broonie
Cc: codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai, wens, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Enable the bus clock before the DMIC module clock during
runtime resume.
The bus clock provides the register access interface and
should be enabled before the module clock.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/sunxi/sun50i-dmic.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/sunxi/sun50i-dmic.c b/sound/soc/sunxi/sun50i-dmic.c
index eddfebe16616..7aff1afdf265 100644
--- a/sound/soc/sunxi/sun50i-dmic.c
+++ b/sound/soc/sunxi/sun50i-dmic.c
@@ -323,16 +323,16 @@ static int sun50i_dmic_runtime_suspend(struct device *dev)
static int sun50i_dmic_runtime_resume(struct device *dev)
{
- struct sun50i_dmic_dev *host = dev_get_drvdata(dev);
+ struct sun50i_dmic_dev *host = dev_get_drvdata(dev);
int ret;
- ret = clk_prepare_enable(host->dmic_clk);
+ ret = clk_prepare_enable(host->bus_clk);
if (ret)
return ret;
- ret = clk_prepare_enable(host->bus_clk);
+ ret = clk_prepare_enable(host->dmic_clk);
if (ret) {
- clk_disable_unprepare(host->dmic_clk);
+ clk_disable_unprepare(host->bus_clk);
return ret;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v14 04/44] arm64: RMI: Add SMC definitions for calling the RMM
From: Marc Zyngier @ 2026-05-22 9:58 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <3261b04f-1a0c-451d-8981-1e2bccc8a9ca@arm.com>
On Thu, 21 May 2026 16:33:09 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> On 21/05/2026 13:40, Marc Zyngier wrote:
> > On Wed, 13 May 2026 14:17:12 +0100,
> > Steven Price <steven.price@arm.com> wrote:
> >>
> >> The RMM (Realm Management Monitor) provides functionality that can be
> >> accessed by SMC calls from the host.
> >>
> >> The SMC definitions are based on DEN0137[1] version 2.0-bet1
> >>
> >> [1] https://developer.arm.com/documentation/den0137/2-0bet1/
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> ---
> >> Changes since v13:
> >> * Updated to RMM spec v2.0-bet1
> >> Changes since v12:
> >> * Updated to RMM spec v2.0-bet0
> >> Changes since v9:
> >> * Corrected size of 'ripas_value' in struct rec_exit. The spec states
> >> this is an 8-bit type with padding afterwards (rather than a u64).
> >> Changes since v8:
> >> * Added RMI_PERMITTED_GICV3_HCR_BITS to define which bits the RMM
> >> permits to be modified.
> >> Changes since v6:
> >> * Renamed REC_ENTER_xxx defines to include 'FLAG' to make it obvious
> >> these are flag values.
> >> Changes since v5:
> >> * Sorted the SMC #defines by value.
> >> * Renamed SMI_RxI_CALL to SMI_RMI_CALL since the macro is only used for
> >> RMI calls.
> >> * Renamed REC_GIC_NUM_LRS to REC_MAX_GIC_NUM_LRS since the actual
> >> number of available list registers could be lower.
> >> * Provided a define for the reserved fields of FeatureRegister0.
> >> * Fix inconsistent names for padding fields.
> >> Changes since v4:
> >> * Update to point to final released RMM spec.
> >> * Minor rearrangements.
> >> Changes since v3:
> >> * Update to match RMM spec v1.0-rel0-rc1.
> >> Changes since v2:
> >> * Fix specification link.
> >> * Rename rec_entry->rec_enter to match spec.
> >> * Fix size of pmu_ovf_status to match spec.
> >> ---
> >> arch/arm64/include/asm/rmi_smc.h | 448 +++++++++++++++++++++++++++++++
> >> 1 file changed, 448 insertions(+)
> >> create mode 100644 arch/arm64/include/asm/rmi_smc.h
> >>
> >> diff --git a/arch/arm64/include/asm/rmi_smc.h b/arch/arm64/include/asm/rmi_smc.h
> >> new file mode 100644
> >> index 000000000000..a09b7a631fef
> >> --- /dev/null
> >> +++ b/arch/arm64/include/asm/rmi_smc.h
> >> @@ -0,0 +1,448 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +/*
> >> + * Copyright (C) 2023-2026 ARM Ltd.
> >> + *
> >> + * The values and structures in this file are from the Realm Management Monitor
> >> + * specification (DEN0137) version 2.0-bet1:
> >> + * https://developer.arm.com/documentation/den0137/2-0bet1/
> >
> > How long is this spec going to be available on the ARM web site, which
> > has a tendency of being reorganised every other week? And there is
> > already a beta2.
>
> Obviously I can't predict the next reorganisation - but at least it's a
> link that could be fed into archive.org or similar.
I found that the PDF spec was less susceptible to creative nonsense,
and people can download it for future reference, whereas ARM has
happily *deleted* specs from the website over time (try to find PSCI
0.1, for example...).
[...]
> >> +struct realm_params {
> >> + union { /* 0x0 */
> >> + struct {
> >> + u64 flags;
> >> + u64 s2sz;
> >> + u64 sve_vl;
> >> + u64 num_bps;
> >> + u64 num_wps;
> >> + u64 pmu_num_ctrs;
> >> + u64 hash_algo;
> >> + u64 num_aux_planes;
> >> + };
> >> + u8 padding0[0x400];
> >
> > SZ_1K? And similarly all over the shop?
>
> I'm a bit less sure that makes the code more readable - these structures
> are a bit of a pain because they are somewhat sparse. I've left a
> comment where the beginning of each union is, and personally I find it
> easier to see 0x0 + 0x400 == 0x400 rather than trying to work out what
> SZ_1K is in hex. This is particularly the case in terms of:
>
> > struct rec_params {
> > union { /* 0x0 */
> > u64 flags;
> > u8 padding0[0x100];
> > };
> > union { /* 0x100 */
> > u64 mpidr;
> > u8 padding1[0x100];
> > };
> > union { /* 0x200 */
> > u64 pc;
> > u8 padding2[0x100];
> > };
> > union { /* 0x300 */
> > u64 gprs[REC_CREATE_NR_GPRS];
> > u8 padding3[0xd00];
> > };
> > };
>
> Where 0xd00 doesn't even have a correspoding SZ_ define.
Indeed, but it is (SZ_4K - SZ_256 * 3). And a lot of these structures
seem to be designed to form a 4kB blob. I'm sure we can make use of
that information (BUILD_BUG_ON?).
>
> The RMM deals with this with macro magic:
>
> > struct rmi_rec_params {
> > /* Flags */
> > SET_MEMBER_RMI(unsigned long flags, 0, 0x100); /* Offset 0 */
> > /* MPIDR of the REC */
> > SET_MEMBER_RMI(unsigned long mpidr, 0x100, 0x200); /* 0x100 */
> > /* Program counter */
> > SET_MEMBER_RMI(unsigned long pc, 0x200, 0x300); /* 0x200 */
> > /* General-purpose registers */
> > SET_MEMBER_RMI(unsigned long gprs[REC_CREATE_NR_GPRS], 0x300, 0x1000); /* 0x300 */
> > };
>
> where the offsets are just directly encoded in the macro - but it's not
> an especially robust macro and I'm not convinced it's more readable.
I think this is just as horrible, but at least it seems to take the
boundaries of the structure into account.
>
> I'm happy to hear other suggestions on how to encode this neatly.
Honestly, I wouldn't mind having the structures described in a more
abstract way and then pre-processed to generate the include files. If
the architectural MRS wasn't so huge, I would have added it to the
kernel and used that directly for KVM.
>
> > I haven't checked the details of the encodings (life is too short),
> > but I wonder how much of this exists as an MRS and could be
> > automatically generated?
>
> Automatically generating this would be good - I'm not sure whether we
> have a (public) source available to generate from at the moment. I have
> tried to methodically work through the spec when updating this file, but
> as Gavin has already pointed out there was at least one mistake (in
> currently unused definitions) this time.
I'm slightly baffled that even the RMM is written this way. Given the
formalism used in the RMM spec, I was expecting that you'd have a
bunch of JSON at hand and able to generate any output from that. Doing
this stuff by hand is both incredibly dull work *and* extremely error
prone.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCH v2 3/3] ASoC: sunxi: sun4i-spdif: Reorder clock enable sequence
From: phucduc.bui @ 2026-05-22 9:54 UTC (permalink / raw)
To: broonie
Cc: codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai, wens, bui duc phuc
In-Reply-To: <20260522095401.72915-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Enable the APB bus clock before the SPDIF module clock
during runtime resume, as register accesses depend on the
bus clock being enabled first.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/sunxi/sun4i-spdif.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index f54eb14c9ed8..102db1a2afbb 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -643,15 +643,15 @@ static int sun4i_spdif_runtime_suspend(struct device *dev)
static int sun4i_spdif_runtime_resume(struct device *dev)
{
- struct sun4i_spdif_dev *host = dev_get_drvdata(dev);
+ struct sun4i_spdif_dev *host = dev_get_drvdata(dev);
int ret;
- ret = clk_prepare_enable(host->spdif_clk);
+ ret = clk_prepare_enable(host->apb_clk);
if (ret)
return ret;
- ret = clk_prepare_enable(host->apb_clk);
+ ret = clk_prepare_enable(host->spdif_clk);
if (ret)
- clk_disable_unprepare(host->spdif_clk);
+ clk_disable_unprepare(host->apb_clk);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] ASoC: sunxi: sun4i-spdif: Use guard() for spin locks
From: phucduc.bui @ 2026-05-22 9:53 UTC (permalink / raw)
To: broonie
Cc: codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai, wens, bui duc phuc
In-Reply-To: <20260522095401.72915-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Change in v2:
- Switched from using guard() to scoped_guard()
sound/soc/sunxi/sun4i-spdif.c | 62 ++++++++++++++++-------------------
1 file changed, 28 insertions(+), 34 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index c2ec19437cd7..89eccc83a130 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -427,24 +427,21 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
struct snd_soc_dai *cpu_dai = snd_kcontrol_chip(kcontrol);
struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
u8 *status = ucontrol->value.iec958.status;
- unsigned long flags;
unsigned int reg;
- spin_lock_irqsave(&host->lock, flags);
+ scoped_guard(spinlock_irqsave, &host->lock) {
+ regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, ®);
- regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, ®);
+ status[0] = reg & 0xff;
+ status[1] = (reg >> 8) & 0xff;
+ status[2] = (reg >> 16) & 0xff;
+ status[3] = (reg >> 24) & 0xff;
- status[0] = reg & 0xff;
- status[1] = (reg >> 8) & 0xff;
- status[2] = (reg >> 16) & 0xff;
- status[3] = (reg >> 24) & 0xff;
+ regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA1, ®);
- regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA1, ®);
-
- status[4] = reg & 0xff;
- status[5] = (reg >> 8) & 0x3;
-
- spin_unlock_irqrestore(&host->lock, flags);
+ status[4] = reg & 0xff;
+ status[5] = (reg >> 8) & 0x3;
+ }
return 0;
}
@@ -455,35 +452,32 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
struct snd_soc_dai *cpu_dai = snd_kcontrol_chip(kcontrol);
struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
u8 *status = ucontrol->value.iec958.status;
- unsigned long flags;
unsigned int reg;
bool chg0, chg1;
- spin_lock_irqsave(&host->lock, flags);
-
- reg = (u32)status[3] << 24;
- reg |= (u32)status[2] << 16;
- reg |= (u32)status[1] << 8;
- reg |= (u32)status[0];
+ scoped_guard(spinlock_irqsave, &host->lock) {
+ reg = (u32)status[3] << 24;
+ reg |= (u32)status[2] << 16;
+ reg |= (u32)status[1] << 8;
+ reg |= (u32)status[0];
- regmap_update_bits_check(host->regmap, SUN4I_SPDIF_TXCHSTA0,
- GENMASK(31,0), reg, &chg0);
+ regmap_update_bits_check(host->regmap, SUN4I_SPDIF_TXCHSTA0,
+ GENMASK(31, 0), reg, &chg0);
- reg = (u32)status[5] << 8;
- reg |= (u32)status[4];
+ reg = (u32)status[5] << 8;
+ reg |= (u32)status[4];
- regmap_update_bits_check(host->regmap, SUN4I_SPDIF_TXCHSTA1,
- GENMASK(9,0), reg, &chg1);
+ regmap_update_bits_check(host->regmap, SUN4I_SPDIF_TXCHSTA1,
+ GENMASK(9, 0), reg, &chg1);
- reg = SUN4I_SPDIF_TXCFG_CHSTMODE;
- if (status[0] & IEC958_AES0_NONAUDIO)
- reg |= SUN4I_SPDIF_TXCFG_NONAUDIO;
+ reg = SUN4I_SPDIF_TXCFG_CHSTMODE;
+ if (status[0] & IEC958_AES0_NONAUDIO)
+ reg |= SUN4I_SPDIF_TXCFG_NONAUDIO;
- regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
- SUN4I_SPDIF_TXCFG_CHSTMODE |
- SUN4I_SPDIF_TXCFG_NONAUDIO, reg);
-
- spin_unlock_irqrestore(&host->lock, flags);
+ regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+ SUN4I_SPDIF_TXCFG_CHSTMODE |
+ SUN4I_SPDIF_TXCFG_NONAUDIO, reg);
+ }
return chg0 || chg1;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] ASoC: sunxi: sun4i-spdif: Resume device before kcontrol register access
From: phucduc.bui @ 2026-05-22 9:54 UTC (permalink / raw)
To: broonie
Cc: codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai, wens, bui duc phuc
In-Reply-To: <20260522095401.72915-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Accessing registers while the device is runtime-suspended
may lead to invalid hardware accesses on systems where the
APB bus clock is gated during runtime suspend.
Ensure the device is resumed before accessing registers.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/sunxi/sun4i-spdif.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index 89eccc83a130..f54eb14c9ed8 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -428,6 +428,11 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
u8 *status = ucontrol->value.iec958.status;
unsigned int reg;
+ int ret;
+
+ ret = pm_runtime_resume_and_get(cpu_dai->dev);
+ if (ret)
+ return ret;
scoped_guard(spinlock_irqsave, &host->lock) {
regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, ®);
@@ -443,6 +448,8 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
status[5] = (reg >> 8) & 0x3;
}
+ pm_runtime_put(cpu_dai->dev);
+
return 0;
}
@@ -453,8 +460,13 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
u8 *status = ucontrol->value.iec958.status;
unsigned int reg;
+ int ret;
bool chg0, chg1;
+ ret = pm_runtime_resume_and_get(cpu_dai->dev);
+ if (ret)
+ return ret;
+
scoped_guard(spinlock_irqsave, &host->lock) {
reg = (u32)status[3] << 24;
reg |= (u32)status[2] << 16;
@@ -479,6 +491,8 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
SUN4I_SPDIF_TXCFG_NONAUDIO, reg);
}
+ pm_runtime_put(cpu_dai->dev);
+
return chg0 || chg1;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] media: bcm2835-unicam: Fix pipeline wrong validation for unpacked formats
From: Dave Stevenson @ 2026-05-22 9:54 UTC (permalink / raw)
To: Eugen Hristev
Cc: Raspberry Pi Kernel Maintenance, Mauro Carvalho Chehab,
Florian Fainelli, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Hans Verkuil,
Laurent Pinchart, Maxime Ripard, Sakari Ailus, linux-media,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520-bcmpi-v1-1-41d80125a7b9@kernel.org>
Hi Eugen
Thanks for the patch.
On Wed, 20 May 2026 at 16:37, 'Eugen Hristev' via kernel-list
<kernel-list@raspberrypi.com> wrote:
>
> The commit
> 08f9794d9b79 ("media: bcm2835-unicam: Fix RGB format / mbus code association")
> introduced a check to see whether the format requested is the same as the
> fourcc in the format list.
>
> However, this breaks the case when userspace requested an unpacked fourcc,
> e.g. RG10.
>
> Unicam can work with or without unpacking pixels, e.g. pRAA or RG10, depending
> on what userspace requests.
> In the unpacking case, a dedicated register is being set.
>
> If the userspace requests pRAA, this works, because the check validates the
> pipeline:
>
> v4l2-ctl -d /dev/video0 --set-fmt-video=width=3280,height=2464,pixelformat=pRAA \
> --stream-mmap --stream-count=1 --stream-to=frame.raw
>
> but, with
> v4l2-ctl -d /dev/video0 --set-fmt-video=width=3280,height=2464,pixelformat=RG10 \
> --stream-mmap --stream-count=1 --stream-to=frame.raw
>
> unicam complains at validation level:
>
> image: format mismatch: 0x300f <=> RG10 little-endian (0x30314752)
>
> This should work, because MEDIA_BUS_FMT_SRGGB10_1X10 can be packed into either
> RG10 or pRAA depending on the packing register.
>
> To fix this, modified the condition check to also allow in the case when
> requested format (fmt->pixelformat) is equal to fmtinfo->unpacked_fourcc.
>
> Fixes: 08f9794d9b79 ("media: bcm2835-unicam: Fix RGB format / mbus code association")
> Signed-off-by: Eugen Hristev <ehristev@kernel.org>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> ---
> drivers/media/platform/broadcom/bcm2835-unicam.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
> index 8d28ba0b59a3..cc7627e9a51a 100644
> --- a/drivers/media/platform/broadcom/bcm2835-unicam.c
> +++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
> @@ -2158,7 +2158,8 @@ static int unicam_video_link_validate(struct media_link *link)
> * In order to allow the applications using the old behaviour to
> * run, let's accept the old combination, but warn about it.
> */
> - if (fmtinfo->fourcc != fmt->pixelformat) {
> + if (fmt->pixelformat != fmtinfo->fourcc &&
> + fmt->pixelformat != fmtinfo->unpacked_fourcc) {
> if ((fmt->pixelformat == V4L2_PIX_FMT_BGR24 &&
> format->code == MEDIA_BUS_FMT_BGR888_1X24) ||
> (fmt->pixelformat == V4L2_PIX_FMT_RGB24 &&
>
> ---
> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> change-id: 20260520-bcmpi-2c4850314e21
>
> Best regards,
> --
> Eugen Hristev <ehristev@kernel.org>
>
^ permalink raw reply
* [PATCH v2 0/3] ASoC: sunxi: sun4i-spdif: Cleanup and runtime PM improvements
From: phucduc.bui @ 2026-05-22 9:53 UTC (permalink / raw)
To: broonie
Cc: codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai, wens, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Hi,
This series contains a few improvements for the sun4i-spdif driver,
including guard() conversions and ensuring the device is resumed
via runtime PM before kcontrol register accesses.
Link v1:
https://lore.kernel.org/all/20260513105003.81880-1-phucduc.bui@gmail.com/
Change in v2:
- Switched from using guard() to scoped_guard()
- Added runtime PM handling for kcontrol register accesses.
Best Regards,
Phuc
bui duc phuc (3):
ASoC: sunxi: sun4i-spdif: Use guard() for spin locks
ASoC: sunxi: sun4i-spdif: Resume device before kcontrol register
access
ASoC: sunxi: sun4i-spdif: Reorder clock enable sequence
sound/soc/sunxi/sun4i-spdif.c | 76 +++++++++++++++++++----------------
1 file changed, 42 insertions(+), 34 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH] arm64: mm: call pagetable dtor when freeing hot-removed page tables
From: Vishal Moola @ 2026-05-22 9:36 UTC (permalink / raw)
To: Catalin Marinas
Cc: Andrew Morton, Alistair Popple, linux-arm-kernel, linux-kernel,
linux-mm, will, david
In-Reply-To: <ahACfQ6kCfONqz5h@arm.com>
On Fri, May 22, 2026 at 08:15:09AM +0100, Catalin Marinas wrote:
> On Thu, May 21, 2026 at 03:31:30PM -0700, Andrew Morton wrote:
> > On Thu, 21 May 2026 13:27:30 +1000 Alistair Popple <apopple@nvidia.com> wrote:
> > > Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in
> > > __create_pgd_mapping()") page-table allocation on ARM64 always
> > > calls pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type
> > > to PGTY_table, increments NR_PAGETABLE and possible allocates a PTL.
> > > However the matching pagetable_dtor() calls were never added.
> > >
> > > With DEBUG_VM enabled on kernel versions prior to v6.17 without
> > > 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page
> > > type") this leads to the following warning when freeing these pages due
> > > to page->page_type sharing page->_mapcount:
> > >
> > > BUG: Bad page state in process ... pfn:284fbb
> > > page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb
> > > flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff)
> > > page_type: f2(table)
> > > page dumped because: nonzero mapcount
> > > Call trace:
> > > bad_page+0x13c/0x160
> > > __free_frozen_pages+0x6cc/0x860
> > > ___free_pages+0xf4/0x180
> > > free_pages+0x54/0x80
> > > free_hotplug_page_range.part.0+0x58/0x90
> > > free_empty_tables+0x438/0x500
> > > __remove_pgd_mapping.constprop.0+0x60/0xa8
> > > arch_remove_memory+0x48/0x80
> > > try_remove_memory+0x158/0x1d8
> > > offline_and_remove_memory+0x138/0x180
> > >
> > > It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS
> > > is defined and incorrect NR_PAGETABLE stats. Fix this by calling
> > > pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the
> > > page to undo the effects of calling pagetable_*_ctor().
> > >
> > > Fixes: 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()")
> >
> > 6.16+, so I assume we want cc:stable here.
> >
> > > arch/arm64/mm/mmu.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > > index 8e1d80a7033e..0c24fe650e95 100644
> > > --- a/arch/arm64/mm/mmu.c
> > > +++ b/arch/arm64/mm/mmu.c
> > > @@ -1422,6 +1422,7 @@ static void free_hotplug_page_range(struct page *page, size_t size,
> > >
> > > static void free_hotplug_pgtable_page(struct page *page)
> > > {
> > > + pagetable_dtor(page_ptdesc(page));
> > > free_hotplug_page_range(page, PAGE_SIZE, NULL);
> > > }
> >
> > I'd of course prefer that arm maintainers handle this. But
> > 5e8eb9aeeda3 came via myself so convention kinda-dictates that I get to
> > fix it.
>
> That's fine but Sashiko has some points:
>
> https://sashiko.dev/#/patchset/20260521032730.2104017-1-apopple@nvidia.com
>
> The __remove_pgd_mapping() path is fine but we also have the
> vmemmap_free() path where the constructor was never called.
>
> We could pass around a bool dtor argument but I wonder whether we could
> just check it's a pgtable page:
Free_empty_tables() looks like the only way we'd ever get to
free_hotplug_pgtable_page(). I'm a little curious why we can't
consolidate unmap_hotplug_range() and free_empty_tables().
I.e. just fold unmap_hotplug_range() into the latter.
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 4c8959153ac4..9d42cbddce27 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1441,6 +1441,9 @@ static void free_hotplug_page_range(struct page *page, size_t size,
>
> static void free_hotplug_pgtable_page(struct page *page)
> {
> + if (folio_test_pgtable(page_folio(page)))
This should work.
> + pagetable_dtor(page_ptdesc(page));
> +
> free_hotplug_page_range(page, PAGE_SIZE, NULL);
In the case we presumably have a page table page (ptdesc) at this
point, we should really be freeing it with pagetable_free() as well.
Its not a big deal that we don't right now, but losing track of the
matching allocation/free sites will become a headache when separately
allocating from struct page.
> }
>
>
> --
> Catalin
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: clock: Add Amlogic A9 PLL clock controller
From: Krzysztof Kozlowski @ 2026-05-22 9:16 UTC (permalink / raw)
To: Jian Hu
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <40e83bed-e7a0-4c66-806c-c2988c5d0f33@amlogic.com>
On 22/05/2026 08:20, Jian Hu wrote:
> Hi Krzysztof,
>
> Thanks for your review.
>
> On 5/15/2026 4:09 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On Mon, May 11, 2026 at 08:47:24PM +0800, Jian Hu wrote:
>>> Add the PLL clock controller dt-bindings for the Amlogic A9 SoC family.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +++++++++++++++++++++
>>> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +++++++++++
>>> 2 files changed, 165 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>> new file mode 100644
>>> index 000000000000..4ee6013ba1a1
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>> @@ -0,0 +1,110 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-pll-clkc.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Amlogic A9 Series PLL Clock Controller
>>> +
>>> +maintainers:
>>> + - Neil Armstrong <neil.armstrong@linaro.org>
>>> + - Jerome Brunet <jbrunet@baylibre.com>
>>> + - Jian Hu <jian.hu@amlogic.com>
>>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - amlogic,a9-gp0-pll
>>> + - amlogic,a9-hifi0-pll
>>> + - amlogic,a9-hifi1-pll
>>> + - amlogic,a9-mclk0-pll
>>> + - amlogic,a9-mclk1-pll
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + '#clock-cells':
>>> + const: 1
>>> +
>>> + clocks:
>>> + items:
>>> + - description: pll input oscillator gate
>>> + - description: fixed input clock source for mclk_sel_0
>>> + - description: u3p2pll input clock source for mclk_sel_0 (optional)
>> Second clock is also optional. Drop "(optional)" comment, just
>> confusing.
>
>
> GP0 has only one parent clock, while MCLK has three.
>
> The second and third parent entries of GP0 are vacant,
>
> so they need to be marked optional.
>
> I will add the optional property for the second clock in the next revision.
How? Read the previous feedback...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] irqchip/exynos-combiner: remove useless spinlock
From: Peter Griffin @ 2026-05-22 9:20 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-arm-kernel, linux-samsung-soc, linux-rt-devel,
Thomas Gleixner, Krzysztof Kozlowski, Alim Akhtar,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt
In-Reply-To: <20260522061012.2687122-1-m.szyprowski@samsung.com>
On Fri, 22 May 2026 at 07:14, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> irq_controller_lock doesn't protect anything, it must be some leftover
> from early development or copy/paste. Remove it completely.
>
> Suggested-by: Thomas Gleixner <tglx@kernel.org>
> Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Link: https://lore.kernel.org/all/20260520220422.3522908-1-m.szyprowski@samsung.com/
> Fixes: 96031b31a4b3 ("irqchip/exynos-combiner: Switch to raw_spinlock")
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox