* [PATCH v2 1/2] cpufreq: dt-platdev: Add SpacemiT K1 SoC to the allowlist
From: Shuwei Wu @ 2026-04-10 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
In-Reply-To: <20260410-shadow-deps-v2-0-4e16b8c0f60e@mailbox.org>
The SpacemiT K1 SoC uses standard device tree based CPU frequency
scaling. Add it to the allowlist to instantiate the cpufreq-dt driver.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 25fd3b191b7e..31a64739df25 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -81,6 +81,7 @@ static const struct of_device_id allowlist[] __initconst = {
{ .have_governor_per_policy = true, },
},
+ { .compatible = "spacemit,k1", },
{ .compatible = "st-ericsson,u8500", },
{ .compatible = "st-ericsson,u8540", },
{ .compatible = "st-ericsson,u9500", },
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Shuwei Wu @ 2026-04-10 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
In-Reply-To: <20260410-shadow-deps-v2-0-4e16b8c0f60e@mailbox.org>
Add Operating Performance Points (OPP) tables and CPU clock properties
for the two clusters in the SpacemiT K1 SoC.
Also assign the CPU power supply (cpu-supply) for the Banana Pi BPI-F3
board to fully enable CPU DVFS.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Changes in v2:
- Add k1-opp.dtsi with OPP tables for both CPU clusters
- Assign CPU supplies and include OPP table for Banana Pi BPI-F3
---
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
3 files changed, 147 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 444c3b1e6f44..3780593f610d 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -5,6 +5,7 @@
#include "k1.dtsi"
#include "k1-pinctrl.dtsi"
+#include "k1-opp.dtsi"
/ {
model = "Banana Pi BPI-F3";
@@ -86,6 +87,38 @@ &combo_phy {
status = "okay";
};
+&cpu_0 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_1 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_2 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_3 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_4 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_5 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_6 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_7 {
+ cpu-supply = <&buck1_3v45>;
+};
+
&emmc {
bus-width = <8>;
mmc-hs400-1_8v;
@@ -201,7 +234,7 @@ pmic@41 {
dldoin2-supply = <&buck5>;
regulators {
- buck1 {
+ buck1_3v45: buck1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
new file mode 100644
index 000000000000..768ae390686d
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/ {
+ cluster0_opp_table: opp-table-cluster0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-819000000 {
+ opp-hz = /bits/ 64 <819000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1050000>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+ cluster1_opp_table: opp-table-cluster1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-819000000 {
+ opp-hz = /bits/ 64 <819000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1050000>;
+ clock-latency-ns = <200000>;
+ };
+ };
+};
+
+&cpu_0 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_1 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_2 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_3 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_4 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_5 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_6 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_7 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index 529ec68e9c23..bdd109b81730 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -54,6 +54,7 @@ cpu_0: cpu@0 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <0>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -84,6 +85,7 @@ cpu_1: cpu@1 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <1>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -114,6 +116,7 @@ cpu_2: cpu@2 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <2>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -144,6 +147,7 @@ cpu_3: cpu@3 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <3>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -174,6 +178,7 @@ cpu_4: cpu@4 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <4>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -204,6 +209,7 @@ cpu_5: cpu@5 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <5>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -234,6 +240,7 @@ cpu_6: cpu@6 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <6>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -264,6 +271,7 @@ cpu_7: cpu@7 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <7>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Herve Codina @ 2026-04-10 8:03 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Liam Girdwood, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <383635c6-0417-4333-aa9c-9056437d4a5f@sirena.org.uk>
Hi Mark, Rob,
On Thu, 9 Apr 2026 16:26:25 +0100
Mark Brown <broonie@kernel.org> wrote:
> > > I didn't want to set a particular limit related to the number of GPIOs
> > > used for thje gain value. Of course 2^32 is obviously a lot.
>
> > > What do you think about 16 for maxItems?
>
> > What is the most you are aware of? Take that and double it.
>
> > Seems to me 256 levels would be way more than a human ear could distinguish.
>
> There's plenty of gain controls with way more than 256 bits of
> resolution, though I'm not aware of any that are configured via GPIO.
> The step size and absolute values you want can vary dramatically
> depending on application, possibly in the same system (eg, a DAC that
> can be connected to both headphones or speakers) so you often end up
> making practical adjustments in a small subset of the available range
> but that subset can vary a lot for the same part.
Mark, do you think that max 16 GPIOs could be an acceptable limit?
IMHO, this value is large enough to be used as the limit.
>
> > I guess my point was that really we could deprecate simple-amplifier
> > binding because this one can handle it and more. But I'm not
> > suggesting we do that yet.
>
> That's my thinking.
Fine for me to, at the end, deprecate the simple-amplifier.
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: iio: magnetometer: Add binding for QST QMC5883P
From: Krzysztof Kozlowski @ 2026-04-10 8:06 UTC (permalink / raw)
To: Hardik Phalet
Cc: Greg Kroah-Hartman, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brigham Campbell, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-staging
In-Reply-To: <20260410-stimulating-happy-terrier-e82dcc@quoll>
On Fri, Apr 10, 2026 at 09:55:24AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Apr 09, 2026 at 09:07:29PM +0000, Hardik Phalet wrote:
> > Add the device tree binding document for the QST QMC5883P, a 3-axis
> > anisotropic magneto-resistive (AMR) sensor with a 16-bit ADC that
> > communicates over I2C. The binding exposes the required 'compatible'
> > and 'reg' properties along with an optional 'vdd-supply' for the
> > 2.5 V–3.6 V VDD rail.
>
> Drop last sentence. We can read the diff.
>
> ...
>
> > +properties:
> > + compatible:
> > + const: qst,qmc5883p
> > +
> > + reg:
> > + maxItems: 1
> > + description: I2C address of the device; the default address is 0x2c.
> > +
> > + vdd-supply:
> > + description:
> > + VDD power supply (2.5 V to 3.6 V). Powers all internal analog and
> > + digital functional blocks.
>
> Supply should be required. Devices need them to operate.
Ah, and since I expect new version, also:
A nit, subject: drop second/last, redundant "binding for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: media: Add bindings for qcom,x1p42100-camss
From: Bryan O'Donoghue @ 2026-04-10 8:06 UTC (permalink / raw)
To: Wenmeng Liu, Robert Foss, Todor Tomov, Vladimir Zapolskiy,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-1-eedcf6d9d8ee@oss.qualcomm.com>
On 10/04/2026 05:25, Wenmeng Liu wrote:
> + vdd-csiphy-0p8-supply:
> + description:
> + 0.8V supply to a PHY.
> +
> + vdd-csiphy-1p2-supply:
> + description:
> + 1.2V supply to a PHY.
> +
> + phys:
> + maxItems: 2
> +
> + phy-names:
> + items:
> + - const: csiphy0
> + - const: csiphy4
> +
So if we still can't agree to get phys = in in the next kernel cycle,
then this scheme is acceptable but with the huge caveat that one
power-rail for each PHY is known to be wrong.
And I absolutely hate to continue to knowingly do the wrong thing...
---
bod
^ permalink raw reply
* Re: [PATCH v6 00/10] Add GPCDMA support in Tegra264
From: Jon Hunter @ 2026-04-10 8:09 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Laxman Dewangan, Philipp Zabel, dmaengine,
devicetree, linux-tegra, linux-kernel, Akhil R, Frank Li
In-Reply-To: <586052f6-d415-4603-accb-be15bad80db8@nvidia.com>
Hi Vinod,
On 31/03/2026 19:06, Jon Hunter wrote:
>
> On 31/03/2026 11:22, Akhil R wrote:
>> This series adds support for GPCDMA in Tegra264 with additional
>> support for separate stream ID for each channel. Tegra264 GPCDMA
>> controller has changes in the register offsets and uses 41-bit
>> addressing for memory. Add changes in the tegra186-gpc-dma driver
>> to support these.
>>
>> v5->v6:
>> - Replace dev_err() with dev_err_probe() in the probe function for fixed
>> return values also.
>> v4->v5:
>> - Use dev_err_probe() when returning error from the probe function.
>> - Remove tegra194 and tegra234 compatible from the reset 'if' condition
>> in the bindings as suggested in v2 (which I missed).
>> v3->v4:
>> - Split device tree changes to two patches.
>> - Reordered patches to have fixes first.
>> - Added fixes tag to dt-bindings and device tree changes.
>> v2->v3:
>> - Add description for iommu-map property and update commit descriptions.
>> - Use enum for compatible string instead of const.
>> - Remove unused registers from struct tegra_dma_channel_regs.
>> - Use devm_of_dma_controller_register() to register the DMA controller.
>> - Remove return value check for mask setting in the driver as the bitmask
>> value is always greater than 32.
>> v1->v2:
>> - Fix dt_bindings_check warnings
>> - Drop fallback compatible "nvidia,tegra186-gpcdma" from Tegra264 DT
>> - Use dma_addr_t for sg_req src/dst fields and drop separate high_add
>> variable and check for the addr_bits only when programming the
>> registers.
>> - Update address width to 39 bits for Tegra234 and before since the SMMU
>> supports only up to 39 bits till Tegra234.
>> - Add a patch to do managed DMA controller registration.
>> - Describe the second iteration in the probe.
>> - Update commit descriptions.
>>
>> Akhil R (10):
>> dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional
>> arm64: tegra: Remove fallback compatible for GPCDMA
>> dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property
>> dmaengine: tegra: Make reset control optional
>> dmaengine: tegra: Use struct for register offsets
>> dmaengine: tegra: Support address width > 39 bits
>> dmaengine: tegra: Use managed DMA controller registration
>> dmaengine: tegra: Use iommu-map for stream ID
>> dmaengine: tegra: Add Tegra264 support
>> arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
>>
>> .../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 32 +-
>> .../arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 4 +
>> arch/arm64/boot/dts/nvidia/tegra264.dtsi | 3 +-
>> drivers/dma/tegra186-gpc-dma.c | 429 +++++++++++-------
>> 4 files changed, 284 insertions(+), 184 deletions(-)
>>
>
> For the series ...
>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
I am not sure if it is too late to pick this up for v7.1, but we would
like to get this into -next if you are happy with it.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: purwa-iot-evk: Add camss node
From: Bryan O'Donoghue @ 2026-04-10 8:16 UTC (permalink / raw)
To: Wenmeng Liu, Robert Foss, Todor Tomov, Vladimir Zapolskiy,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-4-eedcf6d9d8ee@oss.qualcomm.com>
On 10/04/2026 05:25, Wenmeng Liu wrote:
> nable camss node for purwa iot evk board camss tpg support.
>
> Signed-off-by: Wenmeng Liu<wenmeng.liu@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> index ad503beec1d3d8c671d3564942a74c484de762d0..eef03f1eb2a950c06294159be3f97169fb487265 100644
> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> @@ -734,6 +734,10 @@ retimer_ss2_con_sbu_out: endpoint {
> };
> };
>
> +&camss {
> + status = "okay";
> +};
Hmm.
I don't agree with this. Enabling the CAMSS node with just the TPG is of
very low value to an end-user and doesn't "prove out" the CSIPHY, TPG
and RDI path - which is the minimum entry point in upstream right now.
I don't support less than a sensor at minimum.
You guys must have a sensor you've used with this board ?
---
bod
^ permalink raw reply
* [PATCH v2 0/2] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Konrad Dybcio, Dmitry Baryshkov
Add support for IPA v5.2 which can be found in the Milos SoC. And
finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
starts working.
Depends on:
* IPA v5.2 support
https://lore.kernel.org/linux-arm-msm/20260410-ipa-v5-2-v2-0-778422a05060@fairphone.com/T/
* Describe IMEM on Milos
https://lore.kernel.org/linux-arm-msm/20260410-milos-imem-v3-0-d215385fa5ab@fairphone.com/T/
I'd like to have specified these as b4 deps but somehow b4's behaving
quite weird with this series, adding many thousands of
prerequisite-patch-id, so I guess manually will need to be enough.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v2:
- Split net patches into a separate series
- Pick up tags
- Link to v1: https://patch.msgid.link/20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com
---
Luca Weiss (2):
arm64: dts: qcom: milos: Add IPA node
arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++
arch/arm64/boot/dts/qcom/milos.dtsi | 44 ++++++++++++++++++++++++
2 files changed, 53 insertions(+)
---
base-commit: 0190c2c6dae368aeb9bf59a449ebe23f24bfa059
change-id: 20260403-milos-ipa-e5705aa87245
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: qcom: milos: Add IPA node
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260410-milos-ipa-v2-0-c699b6b8cf27@fairphone.com>
Add the description of the IPA block in the Milos SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos.dtsi | 44 +++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index a8536a873c69..9ef103d0e00c 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -1599,6 +1599,50 @@ adreno_smmu: iommu@3da0000 {
dma-coherent;
};
+ ipa: ipa@3f40000 {
+ compatible = "qcom,milos-ipa";
+
+ reg = <0x0 0x03f40000 0x0 0x10000>,
+ <0x0 0x03f50000 0x0 0x5000>,
+ <0x0 0x03e04000 0x0 0xfc000>;
+ reg-names = "ipa-reg",
+ "ipa-shared",
+ "gsi";
+
+ interrupts-extended = <&intc GIC_SPI 654 IRQ_TYPE_EDGE_RISING 0>,
+ <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH 0>,
+ <&smp2p_ipa_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_ipa_in 1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ipa",
+ "gsi",
+ "ipa-clock-query",
+ "ipa-setup-ready";
+
+ clocks = <&rpmhcc RPMH_IPA_CLK>;
+ clock-names = "core";
+
+ interconnects = <&aggre2_noc MASTER_IPA QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &cnoc_main SLAVE_IPA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "memory",
+ "config";
+
+ iommus = <&apps_smmu 0x4a0 0x0>,
+ <&apps_smmu 0x4a2 0x0>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&smp2p_ipa_out 0>,
+ <&smp2p_ipa_out 1>;
+ qcom,smem-state-names = "ipa-clock-enabled-valid",
+ "ipa-clock-enabled";
+
+ sram = <&ipa_modem_tables>;
+
+ status = "disabled";
+ };
+
remoteproc_mpss: remoteproc@4080000 {
compatible = "qcom,milos-mpss-pas";
reg = <0x0 0x04080000 0x0 0x10000>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss
In-Reply-To: <20260410-milos-ipa-v2-0-c699b6b8cf27@fairphone.com>
Configure and enable the node for IPA which enables mobile data on this
device.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
index c1899db46e71..31c6d6627619 100644
--- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
+++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
@@ -690,6 +690,15 @@ vreg_l7p: ldo7 {
/* AW86938FCR vibrator @ 0x5a */
};
+&ipa {
+ firmware-name = "qcom/milos/fairphone/fp6/ipa_fws.mbn";
+ memory-region = <&ipa_fw_mem>;
+
+ qcom,gsi-loader = "self";
+
+ status = "okay";
+};
+
&pm8550vs_c {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] arm64: dts: qcom: x1e80100-microsoft-romulus: add PM8010 camera regulators
From: Bryan O'Donoghue @ 2026-04-10 8:20 UTC (permalink / raw)
To: Oliver White, andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260409201717.108169-2-oliverjwhite07@gmail.com>
On 09/04/2026 21:17, Oliver White wrote:
> Add the PM8010 regulator outputs used by the front-facing OV02C10
> camera module on Microsoft Romulus.
>
> These rails provide the supplies referenced by the camera enablement patch.
>
> Signed-off-by: Oliver White <oliverjwhite07@gmail.com>
> ---
> .../dts/qcom/x1e80100-microsoft-romulus.dtsi | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> index 14b5663a4d48..4427ecae423f 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> @@ -857,6 +857,57 @@ vreg_l3j: ldo3 {
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
> };
> +
> + regulators-8 {
> + compatible = "qcom,pm8010-rpmh-regulators";
> + qcom,pmic-id = "m";
> +
> + vdd-l1-l2-supply = <&vreg_s5j>;
> + vdd-l3-l4-supply = <&vreg_s4c>;
> + vdd-l7-supply = <&vreg_bob1>;
> +
> + vreg_l1m_1p2: ldo1 {
> + regulator-name = "vreg_l1m_1p2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1260000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l2m_1p2: ldo2 {
> + regulator-name = "vreg_l2m_1p2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1260000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l3m_1p8: ldo3 {
> + regulator-name = "vreg_l3m_1p8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l4m_1p8: ldo4 {
> + regulator-name = "vreg_l4m_1p8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l5m_2p8: ldo5 {
> + regulator-name = "vreg_l5m_2p8";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3072000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l7m_2p8: ldo7 {
> + regulator-name = "vreg_l7m_2p8";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3072000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> + };
> };
>
> &gpu {
> @@ -867,6 +918,7 @@ &gpu_zap_shader {
> firmware-name = "qcom/x1e80100/microsoft/qcdxkmsuc8380.mbn";
> };
>
> +
> &i2c0 {
Dangling newline.
Can be fixed on application of the patch though.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
bod
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-04-10 8:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <3c57275e-0574-46e5-9893-053ae5cc22cb@kernel.org>
On 2026/4/10 下午2:42, Krzysztof Kozlowski wrote:
> On 10/04/2026 05:04, Hongliang Wang wrote:
>> Hi, Krzysztof
>>
>> On 2026/4/9 下午8:11, Krzysztof Kozlowski wrote:
>>> On 09/04/2026 14:03, Hongliang Wang wrote:
>>>> I have a question, the input clock of i2c controller can be described by
>>>> "clocks",
>>>> but there is no existing attribute can describe the divisor of the input
>>>> clock,
>>>> Can I define a new attribute named "clock-div" to describe it in DT
>>>> bindings?
>>>> or do you have any standard solutions for the divisor problem? Thank you.
>>>>
>>> You should determine/calculate the divisor in the driver code, depending
>>> on clocks and bus frequencies. You don't need a property for that, usually.
>> Not only clocks and bus frequencies, but also a third property is required.
>>
>> The frequency divison calculation formula of i2c is
>> Prcescale = clock_a/(clock_div*clock_s)-1
>>
>> There is three parameters in this formula:
>> clock_a represents the input clock, which is described by "clocks",
>> clock_s represents the i2c bus frequency, which is described by
>> "clock-frequency",
>> but there is no existing property to describe clock_div, which has
>> different value
>> on different platform (for example, it is 5 on 7a1000/7a2000, 4 on
>> 2K1000/2K2000,
>> 5.5 on 2K3000.), So I need a property to describe clock_div in this formula.
> So it is fixed per compatible? Then you do not need.
>
OK, I will fix the clock_div based on per compatible. thank you.
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH v6 05/10] clk: realtek: Add support for gate clock
From: Yu-Chun Lin @ 2026-04-10 8:19 UTC (permalink / raw)
To: bmasney
Cc: afaerber, conor+dt, cy.huang, cylee12, devicetree, eleanor.lin,
james.tai, jyanchou, krzk+dt, linux-arm-kernel, linux-clk,
linux-kernel, linux-realtek-soc, mturquette, p.zabel, robh, sboyd,
stanley_chang
In-Reply-To: <ac_RcGSpVBpt3S7C@redhat.com>
Hi Brian,
> Hi Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:52PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Introduce clk_regmap_gate_ops supporting enable, disable, is_enabled, and
> > disable_unused for standard regmap gate clocks.
>
> disable_unused is not implemented below.
>
Will remove it from commit message.
> >
> > Add clk_regmap_gate_ro_ops as a read-only variant exposing only is_enabled.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Add the headers used in c file to follow the "Include What You Use" principle.
> > ---
> > drivers/clk/realtek/Makefile | 2 +
> > drivers/clk/realtek/clk-regmap-gate.c | 69 +++++++++++++++++++++++++++
> > drivers/clk/realtek/clk-regmap-gate.h | 65 +++++++++++++++++++++++++
> > 3 files changed, 136 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-regmap-gate.c
> > create mode 100644 drivers/clk/realtek/clk-regmap-gate.h
> >
> > diff --git a/drivers/clk/realtek/Makefile b/drivers/clk/realtek/Makefile
> > index a89ad77993e9..74375f8127ac 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -2,5 +2,7 @@
> > obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
> >
> > clk-rtk-y += common.o
> > +
> > clk-rtk-y += clk-pll.o
> > +clk-rtk-y += clk-regmap-gate.o
> > clk-rtk-y += freq_table.o
> > diff --git a/drivers/clk/realtek/clk-regmap-gate.c b/drivers/clk/realtek/clk-regmap-gate.c
> > new file mode 100644
> > index 000000000000..8738d6c6f8dd
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-regmap-gate.c
> > @@ -0,0 +1,69 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2017 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com>
> > + */
> > +
> > +#include <linux/regmap.h>
> > +#include <linux/bits.h>
> > +#include "clk-regmap-gate.h"
> > +#include <linux/clk-provider.h>
>
> linux/clk-provider.h needs to be included before clk-regmap-gate.h.
>
Ack.
> Also Sashiko reports that linux/export.h should also be included.
https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> Brian
Ack.
Best Regards,
Yu-Chun.
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Jon Hunter @ 2026-04-10 8:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, pshete, linux-gpio, devicetree, linux-tegra,
linux-kernel, arnd, bjorn.andersson, conor+dt, dmitry.baryshkov,
ebiggers, geert, krzk+dt, kuninori.morimoto.gx, linusw,
luca.weiss, michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp,
sven, thierry.reding, webgeek1234
In-Reply-To: <9408f231-7a12-425c-b8de-2990d3162bb3@kernel.org>
On 10/04/2026 07:37, Krzysztof Kozlowski wrote:
> On 09/04/2026 15:13, pshete@nvidia.com wrote:
>> From: Prathamesh Shete <pshete@nvidia.com>
>>
>> Building the Pinctrl driver into the kernel image increases its size.
>
> That's obvious.
>
>> These drivers are not required during early boot, build them as a loadable
>> module instead to reduce the kernel image size.
>
> So you replace built-in into module?
>>
>> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
>> ---
>> arch/arm64/configs/defconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index dd1ac01ee29b..f525670d3b84 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
>> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
>> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
>> CONFIG_PINCTRL_SOPHGO_SG2000=y
>> +CONFIG_PINCTRL_TEGRA238=m
>> +CONFIG_PINCTRL_TEGRA264=m
>
> No, you just added as module. Why do we want them in upstream defconfig?
>
> Standard question, already asked Nvidia more than once.
Yes :-)
Prathamesh, what we need to do is ...
1. Add a patch to populate the pinctrl DT nodes for Tegra264 device.
2. In this patch, only enable pinctrl for Tegra264 because we are
lacking an upstream board for Tegra238 for that moment. In the commit
message we should add a comment to indicate with Tegra264 platform is
using this.
We can still merge the DT binding-doc changes and driver for Tegra238,
but no point to enable in the defconfig yet.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v4 2/3] thermal: spacemit: k1: Add thermal sensor support
From: Jie Gan @ 2026-04-10 8:25 UTC (permalink / raw)
To: Shuwei Wu, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Anand Moon, Troy Mitchell, Yao Zi, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-2-12c87dd063c3@mailbox.org>
On 4/10/2026 11:31 AM, Shuwei Wu wrote:
> The thermal sensor on K1 supports monitoring five temperature zones.
> The driver registers these sensors with the thermal framework
> and supports standard operations:
> - Reading temperature (millidegree Celsius)
> - Setting high/low thresholds for interrupts
>
> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
> Reviewed-by: Anand Moon <linux.amoon@gmail.com>
> Tested-by: Anand Moon <linux.amoon@gmail.com>
> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
> Reviewed-by: Yao Zi <me@ziyao.cc>
> Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
> Tested-by: Gong Shuai <gsh517025@gmail.com>
>
> ---
> Changes in v4:
> - Add 'depends on THERMAL_OF' in drivers/thermal/spacemit/Kconfig
>
> Changes in v3:
> - Align multi-line assignments as suggested by reviewer
> - Remove unnecessary variable definitions
>
> Changes in v2:
> - Rename k1_thermal.c to k1_tsensor.c for better hardware alignment
> - Move driver to drivers/thermal/spacemit/
> - Add Kconfig/Makefile for spacemit and update top-level build files
> - Refactor names, style, code alignment, and comments
> - Simplify probe and error handling
> ---
> drivers/thermal/Kconfig | 2 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/spacemit/Kconfig | 19 +++
> drivers/thermal/spacemit/Makefile | 3 +
> drivers/thermal/spacemit/k1_tsensor.c | 281 ++++++++++++++++++++++++++++++++++
> 5 files changed, 306 insertions(+)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b10080d61860..1c4a5cd5a23e 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -472,6 +472,8 @@ endmenu
>
> source "drivers/thermal/renesas/Kconfig"
>
> +source "drivers/thermal/spacemit/Kconfig"
> +
> source "drivers/thermal/tegra/Kconfig"
>
> config GENERIC_ADC_THERMAL
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index bb21e7ea7fc6..3b249195c088 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -65,6 +65,7 @@ obj-y += mediatek/
> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
> +obj-y += spacemit/
> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
> obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
> obj-$(CONFIG_LOONGSON2_THERMAL) += loongson2_thermal.o
> diff --git a/drivers/thermal/spacemit/Kconfig b/drivers/thermal/spacemit/Kconfig
> new file mode 100644
> index 000000000000..de7b5ece5af2
> --- /dev/null
> +++ b/drivers/thermal/spacemit/Kconfig
> @@ -0,0 +1,19 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +menu "SpacemiT thermal drivers"
> +depends on ARCH_SPACEMIT || COMPILE_TEST
> +
> +config SPACEMIT_K1_TSENSOR
> + tristate "SpacemiT K1 thermal sensor driver"
> + depends on THERMAL_OF
> + help
> + This driver provides support for the thermal sensor
> + integrated in the SpacemiT K1 SoC.
> +
> + The thermal sensor monitors temperatures for five thermal zones:
> + soc, package, gpu, cluster0, and cluster1. It supports reporting
> + temperature values and handling high/low threshold interrupts.
> +
> + Say Y here if you want to enable thermal monitoring on SpacemiT K1.
> + If compiled as a module, it will be called k1_tsensor.
> +
> +endmenu
> diff --git a/drivers/thermal/spacemit/Makefile b/drivers/thermal/spacemit/Makefile
> new file mode 100644
> index 000000000000..82b30741e4ec
> --- /dev/null
> +++ b/drivers/thermal/spacemit/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +obj-$(CONFIG_SPACEMIT_K1_TSENSOR) += k1_tsensor.o
> diff --git a/drivers/thermal/spacemit/k1_tsensor.c b/drivers/thermal/spacemit/k1_tsensor.c
> new file mode 100644
> index 000000000000..b742739e9019
> --- /dev/null
> +++ b/drivers/thermal/spacemit/k1_tsensor.c
> @@ -0,0 +1,281 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Thermal sensor driver for SpacemiT K1 SoC
> + *
> + * Copyright (C) 2026 Shuwei Wu <shuwei.wu@mailbox.org>
> + */
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +#include <linux/thermal.h>
> +
> +#include "../thermal_hwmon.h"
> +
> +#define K1_TSENSOR_PCTRL_REG 0x00
> +#define K1_TSENSOR_PCTRL_ENABLE BIT(0)
> +#define K1_TSENSOR_PCTRL_TEMP_MODE BIT(3)
> +#define K1_TSENSOR_PCTRL_RAW_SEL BIT(7)
> +
> +#define K1_TSENSOR_PCTRL_CTUNE GENMASK(11, 8)
> +#define K1_TSENSOR_PCTRL_SW_CTRL GENMASK(21, 18)
> +#define K1_TSENSOR_PCTRL_HW_AUTO_MODE BIT(23)
> +
> +#define K1_TSENSOR_EN_REG 0x08
> +#define K1_TSENSOR_EN_ALL GENMASK(MAX_SENSOR_NUMBER - 1, 0)
> +
> +#define K1_TSENSOR_TIME_REG 0x0C
> +#define K1_TSENSOR_TIME_WAIT_REF_CNT GENMASK(3, 0)
> +#define K1_TSENSOR_TIME_ADC_CNT_RST GENMASK(7, 4)
> +#define K1_TSENSOR_TIME_FILTER_PERIOD GENMASK(21, 20)
> +#define K1_TSENSOR_TIME_MASK GENMASK(23, 0)
> +
> +#define K1_TSENSOR_INT_CLR_REG 0x10
> +#define K1_TSENSOR_INT_EN_REG 0x14
> +#define K1_TSENSOR_INT_STA_REG 0x18
> +
> +#define K1_TSENSOR_INT_EN_MASK BIT(0)
> +#define K1_TSENSOR_INT_MASK(x) (GENMASK(2, 1) << ((x) * 2))
> +
> +#define K1_TSENSOR_DATA_BASE_REG 0x20
> +#define K1_TSENSOR_DATA_REG(x) (K1_TSENSOR_DATA_BASE_REG + ((x) / 2) * 4)
> +#define K1_TSENSOR_DATA_LOW_MASK GENMASK(15, 0)
> +#define K1_TSENSOR_DATA_HIGH_MASK GENMASK(31, 16)
> +
> +#define K1_TSENSOR_THRSH_BASE_REG 0x40
> +#define K1_TSENSOR_THRSH_REG(x) (K1_TSENSOR_THRSH_BASE_REG + ((x) * 4))
> +#define K1_TSENSOR_THRSH_LOW_MASK GENMASK(15, 0)
> +#define K1_TSENSOR_THRSH_HIGH_MASK GENMASK(31, 16)
> +
> +#define MAX_SENSOR_NUMBER 5
> +
> +/* Hardware offset value required for temperature calculation */
> +#define TEMPERATURE_OFFSET 278
> +
> +struct k1_tsensor_channel {
> + struct k1_tsensor *ts;
> + struct thermal_zone_device *tzd;
> + int id;
> +};
> +
> +struct k1_tsensor {
> + void __iomem *base;
> + struct k1_tsensor_channel ch[MAX_SENSOR_NUMBER];
> +};
> +
> +static void k1_tsensor_init(struct k1_tsensor *ts)
> +{
> + u32 val;
> +
> + /* Disable all the interrupts */
> + writel(0xffffffff, ts->base + K1_TSENSOR_INT_EN_REG);
> +
> + /* Configure ADC sampling time and filter period */
> + val = readl(ts->base + K1_TSENSOR_TIME_REG);
> + val &= ~K1_TSENSOR_TIME_MASK;
> + val |= K1_TSENSOR_TIME_FILTER_PERIOD |
> + K1_TSENSOR_TIME_ADC_CNT_RST |
> + K1_TSENSOR_TIME_WAIT_REF_CNT;
> + writel(val, ts->base + K1_TSENSOR_TIME_REG);
> +
> + /*
> + * Enable all sensors' auto mode, enable dither control,
> + * consecutive mode, and power up sensor.
> + */
> + val = readl(ts->base + K1_TSENSOR_PCTRL_REG);
> + val &= ~K1_TSENSOR_PCTRL_SW_CTRL;
> + val &= ~K1_TSENSOR_PCTRL_CTUNE;
> + val |= K1_TSENSOR_PCTRL_RAW_SEL |
> + K1_TSENSOR_PCTRL_TEMP_MODE |
> + K1_TSENSOR_PCTRL_HW_AUTO_MODE |
> + K1_TSENSOR_PCTRL_ENABLE;
> + writel(val, ts->base + K1_TSENSOR_PCTRL_REG);
> +
> + /* Enable thermal interrupt */
> + val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
> + val |= K1_TSENSOR_INT_EN_MASK;
> + writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
> +
> + /* Enable each sensor */
> + val = readl(ts->base + K1_TSENSOR_EN_REG);
> + val |= K1_TSENSOR_EN_ALL;
> + writel(val, ts->base + K1_TSENSOR_EN_REG);
> +}
> +
> +static void k1_tsensor_enable_irq(struct k1_tsensor_channel *ch)
> +{
> + struct k1_tsensor *ts = ch->ts;
> + u32 val;
> +
> + val = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
> + val |= K1_TSENSOR_INT_MASK(ch->id);
> + writel(val, ts->base + K1_TSENSOR_INT_CLR_REG);
> +
> + val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
> + val &= ~K1_TSENSOR_INT_MASK(ch->id);
> + writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
> +}
> +
> +/*
> + * The conversion formula used is:
> + * T(m°C) = (((raw_value & mask) >> shift) - TEMPERATURE_OFFSET) * 1000
> + */
> +static int k1_tsensor_get_temp(struct thermal_zone_device *tz, int *temp)
> +{
> + struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
> + struct k1_tsensor *ts = ch->ts;
> + u32 val;
> +
> + val = readl(ts->base + K1_TSENSOR_DATA_REG(ch->id));
> + if (ch->id % 2)
> + *temp = FIELD_GET(K1_TSENSOR_DATA_HIGH_MASK, val);
> + else
> + *temp = FIELD_GET(K1_TSENSOR_DATA_LOW_MASK, val);
> +
> + *temp -= TEMPERATURE_OFFSET;
> + *temp *= 1000;
> +
> + return 0;
> +}
> +
> +/*
> + * For each sensor, the hardware threshold register is 32 bits:
> + * - Lower 16 bits [15:0] configure the low threshold temperature.
> + * - Upper 16 bits [31:16] configure the high threshold temperature.
> + */
> +static int k1_tsensor_set_trips(struct thermal_zone_device *tz, int low, int high)
> +{
> + struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
> + struct k1_tsensor *ts = ch->ts;
> + u32 val;
> +
> + if (low >= high)
> + return -EINVAL;
> +
> + if (low < 0)
> + low = 0;
> +
> + high = high / 1000 + TEMPERATURE_OFFSET;
Consider passes high = INT_MAX here:
high = INT/1000 + TEMPERATURE_OFFSET == 2147761;
> + low = low / 1000 + TEMPERATURE_OFFSET;
> +
> + val = readl(ts->base + K1_TSENSOR_THRSH_REG(ch->id));
> + val &= ~K1_TSENSOR_THRSH_HIGH_MASK;
> + val |= FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, high);
K1_TSENSOR_THRSH_HIGH_MASK is a 16-bit MASK:
FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, 2147761); <- overflow happened
the maximum value here will be changed to 50609 from 65536.
We should add a check here and limit the 'high' value here to avoid
overflow:
if (high > (int)((0xFFFF - TEMPERATURE_OFFSET) * 1000))
high = (0Xffff - TEMPERATURE_OFFSET) * 1000;
high = high / 1000 + TEMPERATURE_OFFSET;
...
> +
> + val &= ~K1_TSENSOR_THRSH_LOW_MASK;
> + val |= FIELD_PREP(K1_TSENSOR_THRSH_LOW_MASK, low);
> + writel(val, ts->base + K1_TSENSOR_THRSH_REG(ch->id));
> +
> + return 0;
> +}
> +
> +static const struct thermal_zone_device_ops k1_tsensor_ops = {
> + .get_temp = k1_tsensor_get_temp,
> + .set_trips = k1_tsensor_set_trips,
> +};
> +
> +static irqreturn_t k1_tsensor_irq_thread(int irq, void *data)
> +{
> + struct k1_tsensor *ts = (struct k1_tsensor *)data;
> + int mask, status, i;
> +
> + status = readl(ts->base + K1_TSENSOR_INT_STA_REG);
> +
> + for (i = 0; i < MAX_SENSOR_NUMBER; i++) {
> + if (status & K1_TSENSOR_INT_MASK(i)) {
> + mask = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
> + mask |= K1_TSENSOR_INT_MASK(i);
> + writel(mask, ts->base + K1_TSENSOR_INT_CLR_REG);
> + thermal_zone_device_update(ts->ch[i].tzd, THERMAL_EVENT_UNSPECIFIED);
> + }
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int k1_tsensor_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct k1_tsensor *ts;
> + struct reset_control *reset;
> + struct clk *clk;
> + int i, irq, ret;
> +
> + ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
> + if (!ts)
> + return -ENOMEM;
> +
> + ts->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(ts->base))
> + return dev_err_probe(dev, PTR_ERR(ts->base), "Failed to get reg\n");
> +
> + reset = devm_reset_control_get_exclusive_deasserted(dev, NULL);
> + if (IS_ERR(reset))
> + return dev_err_probe(dev, PTR_ERR(reset), "Failed to get/deassert reset control\n");
> +
> + clk = devm_clk_get_enabled(dev, "core");
> + if (IS_ERR(clk))
> + return dev_err_probe(dev, PTR_ERR(clk), "Failed to get core clock\n");
> +
> + clk = devm_clk_get_enabled(dev, "bus");
> + if (IS_ERR(clk))
> + return dev_err_probe(dev, PTR_ERR(clk), "Failed to get bus clock\n");
> +
> + k1_tsensor_init(ts);
> +
> + for (i = 0; i < MAX_SENSOR_NUMBER; ++i) {
> + ts->ch[i].id = i;
> + ts->ch[i].ts = ts;
> + ts->ch[i].tzd = devm_thermal_of_zone_register(dev, i, ts->ch + i, &k1_tsensor_ops);
> + if (IS_ERR(ts->ch[i].tzd))
> + return PTR_ERR(ts->ch[i].tzd);
> +
> + /* Attach sysfs hwmon attributes for userspace monitoring */
> + ret = devm_thermal_add_hwmon_sysfs(dev, ts->ch[i].tzd);
> + if (ret)
> + dev_warn(dev, "Failed to add hwmon sysfs attributes\n");
> +
> + k1_tsensor_enable_irq(ts->ch + i);
should call after the devm_request_threaded_irq succeeds;
Thanks,
Jie
> + }
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + ret = devm_request_threaded_irq(dev, irq, NULL,
> + k1_tsensor_irq_thread,
> + IRQF_ONESHOT, "k1_tsensor", ts);
> + if (ret < 0)
> + return ret;
> +
> + platform_set_drvdata(pdev, ts);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id k1_tsensor_dt_ids[] = {
> + { .compatible = "spacemit,k1-tsensor" },
> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, k1_tsensor_dt_ids);
> +
> +static struct platform_driver k1_tsensor_driver = {
> + .driver = {
> + .name = "k1_tsensor",
> + .of_match_table = k1_tsensor_dt_ids,
> + },
> + .probe = k1_tsensor_probe,
> +};
> +module_platform_driver(k1_tsensor_driver);
> +
> +MODULE_DESCRIPTION("SpacemiT K1 Thermal Sensor Driver");
> +MODULE_AUTHOR("Shuwei Wu <shuwei.wu@mailbox.org>");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* RE: [PATCH v6 06/10] clk: realtek: Add support for mux clock
From: Yu-Chun Lin [林祐君] @ 2026-04-10 8:24 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <ac_UkRiqWb6fSc1I@redhat.com>
Hi Brian,
> Hi Yu-Chun and Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:53PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add a simple regmap-based clk_ops implementation for Realtek mux clocks.
> >
> > The implementation supports parent selection and rate determination
> > through regmap-backed register access.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Add the headers used in c file to follow the "Include What You Use"
> principle.
> > ---
> > drivers/clk/realtek/Makefile | 1 +
> > drivers/clk/realtek/clk-regmap-mux.c | 48
> > ++++++++++++++++++++++++++++ drivers/clk/realtek/clk-regmap-mux.h |
> > 43 +++++++++++++++++++++++++
> > 3 files changed, 92 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-regmap-mux.c
> > create mode 100644 drivers/clk/realtek/clk-regmap-mux.h
> >
> > diff --git a/drivers/clk/realtek/Makefile
> > b/drivers/clk/realtek/Makefile index 74375f8127ac..f90dc57fcfdb 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -5,4 +5,5 @@ clk-rtk-y += common.o
> >
> > clk-rtk-y += clk-pll.o
> > clk-rtk-y += clk-regmap-gate.o
> > +clk-rtk-y += clk-regmap-mux.o
> > clk-rtk-y += freq_table.o
> > diff --git a/drivers/clk/realtek/clk-regmap-mux.c
> > b/drivers/clk/realtek/clk-regmap-mux.c
> > new file mode 100644
> > index 000000000000..068b056d61f0
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-regmap-mux.c
> > @@ -0,0 +1,48 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2017 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include <linux/regmap.h>
> > +#include <linux/clk-provider.h>
>
> Sort the includes.
>
Ack.
> > +#include "clk-regmap-mux.h"
> > +
> > +static u8 clk_regmap_mux_get_parent(struct clk_hw *hw) {
> > + struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
> > + int num_parents = clk_hw_get_num_parents(hw);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(clkm->clkr.regmap, clkm->mux_ofs, &val);
> > + if (ret)
> > + return 0;
>
> This is another case where it'd be nice to get the get_parent declaration fixed.
> Stephen recently linked to some work of his from 2022 here.
>
> https://lore.kernel.org/linux-clk/177431305509.5403.15386021337517970667
> @lazor/
>
> There's nothing for you to do right now.
>
> > +
> > + val = val >> clkm->shift & clkm->mask;
>
> I know there's the order of operations, however for clarity I would just include
> some () here to make it clear the expected order.
Ack.
> > +
> > + if (val >= num_parents)
>
> Remove newline before if.
Ack.
>
> > + return 0;
> > +
> > + return val;
>
> Or you could just use a ternary operator:
>
> return val >= num_parents ? 0 : val;
>
Ack.
> > +}
> > +
> > +static int clk_regmap_mux_set_parent(struct clk_hw *hw, u8 index) {
> > + struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
> > +
> > + return regmap_update_bits(clkm->clkr.regmap, clkm->mux_ofs,
> > + clkm->mask << clkm->shift, index <<
> > +clkm->shift); }
> > +
> > +const struct clk_ops rtk_clk_regmap_mux_ops = {
> > + .set_parent = clk_regmap_mux_set_parent,
> > + .get_parent = clk_regmap_mux_get_parent,
> > + .determine_rate = __clk_mux_determine_rate, };
> > +EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ops, "REALTEK_CLK");
> > +
> > +const struct clk_ops rtk_clk_regmap_mux_ro_ops = {
> > + .get_parent = clk_regmap_mux_get_parent, };
> > +EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ro_ops, "REALTEK_CLK");
>
> rtk_clk_regmap_mux_ro_ops is exported, however the declaration is not
> actually declared in any header files.
>
> Brian
Since it is currently unused, I will drop the 'rtk_clk_regmap_mux_ro_ops'
implementation.
Best Regards,
Yu-Chun.
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Bryan O'Donoghue @ 2026-04-10 8:26 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <328b388c-438e-4f91-9384-0dad903355a5@oss.qualcomm.com>
On 10/04/2026 04:55, Taniya Das wrote:
>> Why do these two controllers have no power-domains ?
> Bryan, on Eliza the videocc and camcc are connected on CX and MXA.
Shouldn't you at least have:
power-domains = <&rpmhpd RPMHPD_CX> ?
And even
power-domains = <&rpmhpd RPMHPD_MX>,
<&rpmhpd RPMHPD_CX>;
power-domain-names = "mx",
"cx";
Konrad's suggestion to me was that MXA should have a vote in my CSIPHY
series I think he and Jagadeesh discussed it but I'm not sure if they
_concluded_ what was the right thing to do.
Right now I'm representing the dependency. MXA is always on ... and
there's nothing to do voting for it @ MX ?
---
bod
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: purwa: Fix GPU IOMMU property
From: Konrad Dybcio @ 2026-04-10 8:37 UTC (permalink / raw)
To: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Clark, Dmitry Baryshkov,
freedreno
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa-gpu-dt-fix-v1-1-4637892156cf@oss.qualcomm.com>
On 4/9/26 11:08 PM, Akhil P Oommen wrote:
> Purwa's GPU does not support SID 1, which is typically used for
> LPAC-related traffic. Remove SID 1 from the GPU node's iommus property to
> accurately describe the hardware. This fixes the splat below, seen with
> some versions of Gunyah hypervisor:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-04-10 8:37 UTC (permalink / raw)
To: krzk
Cc: Frank.Li, acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robh, sakari.ailus, wsa+renesas
In-Reply-To: <9e1093e6-18f9-4edc-8659-510245c5d6db@kernel.org>
On Fri, 10 Apr 2026 09:18:48 +0200, Krzysztof Kozlowski wrote:
> On 10/04/2026 08:57, Guenter Roeck wrote:
>> On 4/9/26 23:39, Krzysztof Kozlowski wrote:
>>> On 09/04/2026 12:57, Akhil R wrote:
>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>> SPD5118 hwmon sensor as modules to the defconfig and therefore
>>>> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
>>>> Vera platforms.
>>>
>>> git grep for "Vera" gave me zero results. Are you sure this is an
>>> upstream platform? Please point the DTS using this.
>>>
>>
>> I think this is an ACPI based system, or at least that is what Google search
>> tells me.
>
> Thanks. Following Google Vera is either a "CPU" or entire architecture
> (at least that's how they call it), so it does not have SPD5118 sensor.
SOCAMM is a Memory Module. SPD5118, as it's Kconfig mentions, is a sensor
found within such memory modules. I didn't quite get why would you state
that the SOCAMM present in Vera architecture (or CPU) does not have
SPD5118 in it.
Pasting the below from the Vera Rubin product page [1] -
"NVIDIA Vera CPUs add enhanced serviceability with small-outline
compression-attached memory modules (SOCAMM) LPDDR5X and in-system tests
for the CPU cores."
[1]: https://www.nvidia.com/en-us/data-center/technologies/rubin/
>
>
> "Nvidia vera socamm" gives me something about "rubin". It's not me who
> should be guessing all this.
>
> "nvidia vera socamm SPD5118" gives me even less, so justification is flaky.
>
> To remind, this commit msg should convince why generic kernel for
> developers affecting all possible platforms - not end users, because
> they always use distro kernels - should enable these configs. And it
> should bring me clear rule what I can or cannot remove from defconfig,
> if in 2 years I come and start pruning it from symbols.
I found little details on what we should be adding in the defconfig. It
would help if you could share some guidance. Do you mean to say that the
defconfig should include only the configs which are necessary in
development platforms and not in end-products?
Regards,
Akhil
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: purwa-iot-evk: Add camss node
From: Wenmeng Liu @ 2026-04-10 8:38 UTC (permalink / raw)
To: Bryan O'Donoghue, Robert Foss, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <765e4740-cf13-4d4e-ab69-c1abe1c39d34@linaro.org>
Hi Bryan,
On 4/10/2026 4:16 PM, Bryan O'Donoghue wrote:
> On 10/04/2026 05:25, Wenmeng Liu wrote:
>> nable camss node for purwa iot evk board camss tpg support.
>>
>> Signed-off-by: Wenmeng Liu<wenmeng.liu@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/
>> boot/dts/qcom/purwa-iot-evk.dts
>> index
>> ad503beec1d3d8c671d3564942a74c484de762d0..eef03f1eb2a950c06294159be3f97169fb487265 100644
>> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>> @@ -734,6 +734,10 @@ retimer_ss2_con_sbu_out: endpoint {
>> };
>> };
>> +&camss {
>> + status = "okay";
>> +};
>
> Hmm.
>
> I don't agree with this. Enabling the CAMSS node with just the TPG is of
> very low value to an end-user and doesn't "prove out" the CSIPHY, TPG
> and RDI path - which is the minimum entry point in upstream right now.
>
> I don't support less than a sensor at minimum.
>
> You guys must have a sensor you've used with this board ?
>
Yes we have, but both not upstreamed sensor, we currently have no plans
for sensor upstream, perhaps this work will be carried out later.
And ack comments on the previous patch.
Thanks,
Wenmeng
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
From: Konrad Dybcio @ 2026-04-10 8:39 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260410-milos-ipa-v2-2-c699b6b8cf27@fairphone.com>
On 4/10/26 10:17 AM, Luca Weiss wrote:
> Configure and enable the node for IPA which enables mobile data on this
> device.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: ipq5210: add the bootph-all property
From: Kathiravan Thirumoorthy @ 2026-04-10 8:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <8fe36a5e-1ebc-4c5f-9c3b-3c50ebd2274e@kernel.org>
On 4/9/2026 3:33 PM, Krzysztof Kozlowski wrote:
> On 09/04/2026 11:28, Kathiravan Thirumoorthy wrote:
>> Add the bootph-all property to the nodes which are utilized by the
>> bootloaders.
> Uh oh, so it started for qcom too? I really don't like how these bootph
> properties spread all over, so please provide arguments - which pure
> upstream bootloaders exactly and why exactly these nodes.
This is needed for U-Boot SPL for IPQ5210 [1].
[1] -
https://lore.kernel.org/u-boot/20260408091136.2794546-1-varadarajan.narayanan@oss.qualcomm.com/
>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts | 5 +++++
>> arch/arm64/boot/dts/qcom/ipq5210.dtsi | 10 ++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts b/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>> index 941f866ecfe9..56dbc506da78 100644
>> --- a/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>> +++ b/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>> @@ -17,6 +17,7 @@ aliases {
>>
>> chosen {
>> stdout-path = "serial0";
>> + bootph-all;
> Since when do we add bootph-all to chosen? Which broken bootloader
> ignores chosen?
>
> This really makes me wonder that you do all this for some downstream forks.
U-Boot doesn't need it, but U-Boot SPL needs it.
>> };
>> };
>>
>> @@ -41,6 +42,7 @@ qup_uart1_default_state: qup-uart1-default-state {
>> function = "qup_se1";
>> drive-strength = <6>;
>> bias-pull-down;
>> + bootph-all;
>> };
> And that's a pin, not a device. What is the point of marking it? The
> device needing this pin will have phandle which must pull the node.
This is because of the fdtgrep tool's limitations, which removes these
nodes in the final DTB if this property is not present.
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: ipq5210: add the bootph-all property
From: Krzysztof Kozlowski @ 2026-04-10 8:54 UTC (permalink / raw)
To: Kathiravan Thirumoorthy, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <9d99f3ad-e2ec-4a17-ab07-3d379dc28d55@oss.qualcomm.com>
On 10/04/2026 10:41, Kathiravan Thirumoorthy wrote:
>
> On 4/9/2026 3:33 PM, Krzysztof Kozlowski wrote:
>> On 09/04/2026 11:28, Kathiravan Thirumoorthy wrote:
>>> Add the bootph-all property to the nodes which are utilized by the
>>> bootloaders.
>> Uh oh, so it started for qcom too? I really don't like how these bootph
>> properties spread all over, so please provide arguments - which pure
>> upstream bootloaders exactly and why exactly these nodes.
>
> This is needed for U-Boot SPL for IPQ5210 [1].
Mention U-Boot SPL in commit msg and add Link for commit msg (or
changelog if other prefers that).
>
> [1] -
> https://lore.kernel.org/u-boot/20260408091136.2794546-1-varadarajan.narayanan@oss.qualcomm.com/
>
>>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts | 5 +++++
>>> arch/arm64/boot/dts/qcom/ipq5210.dtsi | 10 ++++++++++
>>> 2 files changed, 15 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts b/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>>> index 941f866ecfe9..56dbc506da78 100644
>>> --- a/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>>> +++ b/arch/arm64/boot/dts/qcom/ipq5210-rdp504.dts
>>> @@ -17,6 +17,7 @@ aliases {
>>>
>>> chosen {
>>> stdout-path = "serial0";
>>> + bootph-all;
>> Since when do we add bootph-all to chosen? Which broken bootloader
>> ignores chosen?
>>
>> This really makes me wonder that you do all this for some downstream forks.
>
> U-Boot doesn't need it, but U-Boot SPL needs it.
I understand, but let me rephrase my question better. Which bootloader
build process ignores chosen when preparing final DTB for the target?
Maybe that build process needs to be fixed.
>
>>> };
>>> };
>>>
>>> @@ -41,6 +42,7 @@ qup_uart1_default_state: qup-uart1-default-state {
>>> function = "qup_se1";
>>> drive-strength = <6>;
>>> bias-pull-down;
>>> + bootph-all;
>>> };
>> And that's a pin, not a device. What is the point of marking it? The
>> device needing this pin will have phandle which must pull the node.
>
> This is because of the fdtgrep tool's limitations, which removes these
> nodes in the final DTB if this property is not present.
fdtgrep should be fixed. I see no point in marking obvious dependencies.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset
From: Konrad Dybcio @ 2026-04-10 8:55 UTC (permalink / raw)
To: Dmitry Baryshkov, David Heidelberg
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Ulf Hansson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-clk, linux-kernel, devicetree
In-Reply-To: <xbbaffnmi6z5ohzw3p4m6ox75gasgc3nw5cf6yo7h3td2bmsrb@px2mntm74rhb>
On 4/9/26 11:24 PM, Dmitry Baryshkov wrote:
> On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
>> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
>>> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
>>>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>>>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>>
>>>>>>>>> If the OS does not support recovering the state left by the
>>>>>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>>>>>
>>>>>>>> This is not the relevant reset
>>>>>>>>
>>>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>>>>>
>>>>>>> Thanks, I prepared the fixes [1].
>>>>>>>
>>>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>>>>>
>>>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
>>>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>>>>>> place
>>>>>
>>>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
>>>>> change that to CORE behind the scene. I'd prefer David's approach.
>>>>
>>>> Back when I replied, David had a patch that removed the current RSCC
>>>> reset definition in dt-bindings (at index 0) and re-used that index
>>>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
>>>> specific commits when making comments, note to self :P
>>>
>>> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
>>> work.
>>
>> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
>>
>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
>> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
>> arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0xc88
>> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
>
> [...]
>
>>
>> These (or very similar warnings) are around sdm845 definitely 6.19+ /
>> linux-next kernels for some time, but pretty harmless.
>>
>> LLM suggested multiple fixes, but when presenting possibility of
>> implementing mdss reset it found it as most preferable [1].
>>
>> Adding MDSS reset would most likely solve it. It's not critical, but not
>> nice to see many red lines in the dmesg.
>>
>> Is there something I could experiment with to get closer to have proper MDSS reset?
>
> I don't have a sensible solution at this point. We tried using the MDSS
> reset on several SDM845 devices, but they just reset. So... I don't have
> any possible solution.
The older context talks about altering the existing dt-bindings values
and now we're at hardware (mis)behaving? What is the issue here?
Konrad
^ permalink raw reply
* Re: [PATCH 2/3] pmdomain: core: add support for power-domains-child-ids
From: Ulf Hansson @ 2026-04-10 8:57 UTC (permalink / raw)
To: Kevin Hilman
Cc: Rob Herring, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <7h4iljskvz.fsf@baylibre.com>
On Fri, 10 Apr 2026 at 02:45, Kevin Hilman <khilman@baylibre.com> wrote:
>
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
> > On Wed, 11 Mar 2026 at 01:19, Kevin Hilman (TI) <khilman@baylibre.com> wrote:
> >>
> >> Currently, PM domains can only support hierarchy for simple
> >> providers (e.g. ones with #power-domain-cells = 0).
> >>
> >> Add support for oncell providers as well by adding a new property
> >> `power-domains-child-ids` to describe the parent/child relationship.
> >>
> >> For example, an SCMI PM domain provider has multiple domains, each of
> >> which might be a child of diffeent parent domains. In this example,
> >> the parent domains are MAIN_PD and WKUP_PD:
> >>
> >> scmi_pds: protocol@11 {
> >> reg = <0x11>;
> >> #power-domain-cells = <1>;
> >> power-domains = <&MAIN_PD>, <&WKUP_PD>;
> >> power-domains-child-ids = <15>, <19>;
> >> };
> >>
> >> With this example using the new property, SCMI PM domain 15 becomes a
> >> child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
> >> WKUP_PD.
> >>
> >> To support this feature, add two new core functions
> >>
> >> - of_genpd_add_child_ids()
> >> - of_genpd_remove_child_ids()
> >>
> >> which can be called by pmdomain providers to add/remove child domains
> >> if they support the new property power-domains-child-ids.
> >>
> >> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
> >
> > Thanks for working on this! It certainly is a missing feature!
>
> You're welcome, thanks for the detailed review.
>
> >> ---
> >> drivers/pmdomain/core.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> include/linux/pm_domain.h | 16 ++++++++++++++++
> >> 2 files changed, 185 insertions(+)
> >>
> >> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
> >> index 61c2277c9ce3..acb45dd540b7 100644
> >> --- a/drivers/pmdomain/core.c
> >> +++ b/drivers/pmdomain/core.c
> >> @@ -2909,6 +2909,175 @@ static struct generic_pm_domain *genpd_get_from_provider(
> >> return genpd;
> >> }
> >>
> >> +/**
> >> + * of_genpd_add_child_ids() - Parse power-domains-child-ids property
> >> + * @np: Device node pointer associated with the PM domain provider.
> >> + * @data: Pointer to the onecell data associated with the PM domain provider.
> >> + *
> >> + * Parse the power-domains and power-domains-child-ids properties to establish
> >> + * parent-child relationships for PM domains. The power-domains property lists
> >> + * parent domains, and power-domains-child-ids lists which child domain IDs
> >> + * should be associated with each parent.
> >> + *
> >> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
> >
> > I think we should avoid returning specific error codes for specific
> > errors, simply because it usually becomes messy.
> >
> > If I understand correctly the intent here is to allow the caller to
> > check for -ENOENT and potentially avoid bailing out as it may not
> > really be an error, right?
>
> Right, -ENOENT is not an error of parsing, it's to indicate that there
> are no child-ids to be parsed.
>
> > Perhaps a better option is to return the number of children for whom
> > we successfully assigned parents. Hence 0 or a positive value allows
> > the caller to understand what happened. More importantly, a negative
> > error code then really becomes an error for the caller to consider.
>
> I explored this a bit, but it gets messy quick. It means we have to
> track cases where only some of the children were added as well as when
> all children were added. Personally, I think this should be an "all or
> nothing" thing. If all the children cannot be parsed/added, then none
> of them should be added.
>
> This also allows the remove to not have to care about how many were
> added, and just remove them all, with the additional benefit of not
> having to track the state of how many children were successfully added.
>
I fully agree, it should be all or nothing. Failing with one
child/parent should end up with an error code being returned.
That said, it still seems to make perfect sense to return the number
of children for whom we assigned parents for, no?
[...]
> >> +int of_genpd_remove_child_ids(struct device_node *np,
> >> + struct genpd_onecell_data *data)
> >> +{
> >> + struct of_phandle_args parent_args;
> >> + struct generic_pm_domain *parent_genpd, *child_genpd;
> >> + struct of_phandle_iterator it;
> >> + const struct property *prop;
> >> + const __be32 *item;
> >> + u32 child_id;
> >> + int ret;
> >> +
> >> + /* Check if both properties exist */
> >> + if (of_count_phandle_with_args(np, "power-domains", "#power-domain-cells") <= 0)
> >> + return -ENOENT;
> >> +
> >> + prop = of_find_property(np, "power-domains-child-ids", NULL);
> >> + if (!prop)
> >> + return -ENOENT;
> >> +
> >> + item = of_prop_next_u32(prop, NULL, &child_id);
> >
> > Similar comments as for of_genpd_add_child_ids().
> >
> > Moreover, I think we should remove the children in the reverse order
> > of how we added them.
>
> I'm curious why does the order matter? The children are all siblings
> (no hierarchy), so why would the order be important?
It might not be that important, but generally, it seems like a good
idea to me to reverse the order when undoing things.
>
> I'm not ware of a phandle iterator/helper to parse in the reverse, so
> that would mean iterating once to create a list, and then walking it in
> reverse. Seems unnecessary.
Sure, I leave the call to you, to see what fits best.
Kind regards
Uffe
^ 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