* Re: [PATCH v3 2/2] interconnect: qcom: add MSM8x60 NoC driver
From: me @ 2026-06-19 8:10 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Herman van Hazendonk, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <ff72dd25-926b-4a51-99ad-4535f6025dcc@oss.qualcomm.com>
On 2026-06-17 12:36, Konrad Dybcio wrote:
> On 6/6/26 2:34 PM, Herman van Hazendonk wrote:
>> Add a Qualcomm interconnect driver for the MSM8x60 family modelling
>> the
>> four NoC fabrics (APPSS, System, MMSS, Daytona) that connect masters
>> and slaves on these Scorpion-class SoCs. The driver implements the
>> interconnect-provider API to manage bandwidth between specific masters
>> and slaves via the RPM arbitration tables.
>
> [...]
>
>
>> +/*
>> + * Minimum fabric clock rate to prevent bus starvation.
>> + *
>> + * When no consumers request bandwidth, the rate calculation yields
>> 0,
>> + * causing fabric clocks to drop to minimum. This creates bimodal
>> + * performance: fast when other subsystems (like display) happen to
>> + * request bandwidth, slow otherwise.
>> + *
>> + * 384 MHz keeps fabric fast during concurrent MDP display scanout
>> + * and USB gadget traffic. legacy vendor kernel docs: "AXI bus
>> frequency needs to be
>> + * kept at maximum value while USB data transfers are happening."
>> + * 266 MHz was insufficient - USB crashed during display activity.
>> + */
>> +#define MSM8660_FABRIC_MIN_RATE 384000000UL /* 384 MHz */
>
> Can you ensure that through a vote in the USB driver?
>
> Konrad
Hi Konrad,
I'm reworking the interconnect driver based on earlier feedback, but
running
into some regressions I need to tackle first. The driver I had was
stable,
the reworked one has some issues that I'm trying to tackle before
submitting
another version. The minimum rate will probably disappear as a result of
that
anyway.
Thanks,
Herman
^ permalink raw reply
* [PATCH v6 0/4] arm64: dts: renesas: Add RZ/G3E audio enablement
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
This is the remainder of the RZ/G3E audio enablement series. In v4, Geert
queued the clock and clock-input groundwork for v7.3, so it is not resent
here:
- dt-bindings: clock: renesas: Add audio clock inputs for RZ/V2H family
-> renesas-clk
- clk: renesas: r9a09g047: Add audio clock and reset support
-> renesas-clk
- arm64: dts: renesas: rzv2h: Add audio clock inputs
-> renesas-devel
- arm64: dts: renesas: rzg3e-smarc-som: Add I2C1 support
-> renesas-devel
This series carries only the four patches that were reviewed but not
queued. The sound node in 1/4 references the audio module clocks and
resets added by the queued clk patches, so this series depends on the
renesas-clk queue and is based on renesas-devel for v7.3.
v6 is a single fix: the Versa3 patch (2/4) now actually drops the
unconnected DIFF2 output from assigned-clocks/assigned-clock-rates, which
in v5 was described in the commit message but left in the DTS. The other
three patches are unchanged from v5.
v5:
- Resend only the four patches not queued for v7.3 (the four above are
dropped from the series).
- Sound node: hexadecimal module clock/reset numbers, lowercase 0x1f000
SSI size, SCU reg extended to 0x20000 to cover the SCU DMAC, per-line
clock/reset comments dropped.
- Versa3: document DIFF1/Ethernet, intended to drop the unconnected
DIFF2 output (the description was updated but the DTS still listed
output 5; fixed in v6).
- Pinmux: hyphenate node names, sort entries by GPIO number.
- Codec: drop the unnecessary #address-cells/#size-cells on codec@1a
(sashiko-bot); add Geert's Reviewed-by.
v4:
- Link to v4 at [1]
- Sound node: dotted clock/reset names moved to hyphenated form, legacy
rcar_sound,* sub-nodes renamed to unprefixed ctu/dvc/mix/src/ssi/ssiu,
clocks/resets reordered ascending, explanatory comment blocks dropped,
dmas continuation lines aligned, commit message corrected (snd_rzg3e).
- Versa3, pinmux, codec: no changes.
v3:
- Sound node: commit description typo fix.
- Versa3, pinmux, codec: no changes.
v2:
- Sound node: drop the 2-cells specifier on the audio DMA assignment and
stop updating DMAC #dma-cells.
- Versa3, pinmux, codec: no changes.
[1] https://lore.kernel.org/r/20260525110603.4018170-1-john.madieu.xa@bp.renesas.com
John Madieu (4):
arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
arm64: dts: renesas: rzg3e-smarc-som: Add Versa3 clock generator
arm64: dts: renesas: rzg3e-smarc-som: add audio pinmux definitions
arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec
support
arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 462 ++++++++++++++++++
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 112 +++++
.../boot/dts/renesas/rzg3e-smarc-som.dtsi | 32 ++
3 files changed, 606 insertions(+)
--
2.25.1
^ permalink raw reply
* [PATCH v6 1/4] arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
In-Reply-To: <20260619083951.3777556-1-john.madieu.xa@bp.renesas.com>
Add the snd_rzg3e node for the RZ/G3E SoC with all sub-components:
- SSI (Serial Sound Interface) units 0-9
- SSIU (Serial Sound Interface Unit) units 0-27
- SRC (Sample Rate Converter) units 0-9
- CTU (Channel Transfer Unit) units 0-7
- DVC (Digital Volume Control) units 0-1
- MIX (Mixer) units 0-1
Sub-node names follow the new RZ/G3E sound binding: unprefixed
'ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu' wrapper nodes instead of
the legacy 'rcar_sound,xxx' R-Car prefix.
Wire up all 5 DMA controllers (dmac0-dmac4) for each audio sub-node
with repeated channel names, so that the DMA core can pick the first
available controller.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Chqnges:
v6: No changes.
v5:
- Use hexadecimal CPG module clock and reset numbers, for easier
matching with the documentation.
- Use lowercase hex for the SSI reg size (0x1f000).
- Extend the scu reg region to 0x20000 to include the SCU DMAC.
- Drop the per-line clock / reset comments, as clock-names and
reset-names already serve that purpose
arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 462 +++++++++++++++++++++
1 file changed, 462 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
index 1251e329e380..881124f31849 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
@@ -912,6 +912,468 @@ rsci9: serial@12803000 {
status = "disabled";
};
+ snd_rzg3e: sound@13c00000 {
+ compatible = "renesas,r9a09g047-sound";
+ reg = <0 0x13c00000 0 0x20000>, /* SCU */
+ <0 0x13c20000 0 0x10000>, /* ADG */
+ <0 0x13c30000 0 0x1000>, /* SSIU */
+ <0 0x13c31000 0 0x1f000>, /* SSI */
+ <0 0x13c50000 0 0x10000>; /* Audio DMAC peri peri */
+ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+ clocks = <&cpg CPG_MOD 0xf5>,
+ <&cpg CPG_MOD 0x181>, <&cpg CPG_MOD 0x182>,
+ <&cpg CPG_MOD 0x183>, <&cpg CPG_MOD 0x184>,
+ <&cpg CPG_MOD 0x185>, <&cpg CPG_MOD 0x186>,
+ <&cpg CPG_MOD 0x187>, <&cpg CPG_MOD 0x188>,
+ <&cpg CPG_MOD 0x189>, <&cpg CPG_MOD 0x18a>,
+ <&cpg CPG_MOD 0x174>, <&cpg CPG_MOD 0x175>,
+ <&cpg CPG_MOD 0x176>, <&cpg CPG_MOD 0x177>,
+ <&cpg CPG_MOD 0x178>, <&cpg CPG_MOD 0x179>,
+ <&cpg CPG_MOD 0x17a>, <&cpg CPG_MOD 0x17b>,
+ <&cpg CPG_MOD 0x17c>, <&cpg CPG_MOD 0x17d>,
+ <&cpg CPG_MOD 0x172>, <&cpg CPG_MOD 0x173>,
+ <&cpg CPG_MOD 0x172>, <&cpg CPG_MOD 0x173>,
+ <&cpg CPG_MOD 0x170>, <&cpg CPG_MOD 0x171>,
+ <&cpg CPG_MOD 0xfb>, <&cpg CPG_MOD 0xfc>,
+ <&cpg CPG_MOD 0xfd>, <&cpg CPG_MOD 0xfa>,
+ <&cpg CPG_MOD 0x180>,
+ <&cpg CPG_MOD 0xf6>, <&cpg CPG_MOD 0xf7>,
+ <&cpg CPG_MOD 0x17e>,
+ <&cpg CPG_MOD 0x160>, <&cpg CPG_MOD 0x161>,
+ <&cpg CPG_MOD 0x162>, <&cpg CPG_MOD 0x163>,
+ <&cpg CPG_MOD 0x164>, <&cpg CPG_MOD 0x165>,
+ <&cpg CPG_MOD 0x166>, <&cpg CPG_MOD 0x167>,
+ <&cpg CPG_MOD 0x168>, <&cpg CPG_MOD 0x169>,
+ <&cpg CPG_MOD 0xf8>, <&cpg CPG_MOD 0xf9>;
+ clock-names = "ssi-all",
+ "ssi-0", "ssi-1",
+ "ssi-2", "ssi-3",
+ "ssi-4", "ssi-5",
+ "ssi-6", "ssi-7",
+ "ssi-8", "ssi-9",
+ "src-0", "src-1",
+ "src-2", "src-3",
+ "src-4", "src-5",
+ "src-6", "src-7",
+ "src-8", "src-9",
+ "mix-0", "mix-1",
+ "ctu-0", "ctu-1",
+ "dvc-0", "dvc-1",
+ "audio-clka", "audio-clkb",
+ "audio-clkc", "audio-clki",
+ "ssif_supply",
+ "scu", "scu_x2",
+ "scu_supply",
+ "adg-ssi-0", "adg-ssi-1",
+ "adg-ssi-2", "adg-ssi-3",
+ "adg-ssi-4", "adg-ssi-5",
+ "adg-ssi-6", "adg-ssi-7",
+ "adg-ssi-8", "adg-ssi-9",
+ "audmapp", "adg";
+ power-domains = <&cpg>;
+ resets = <&cpg 0xe1>,
+ <&cpg 0xe2>, <&cpg 0xe3>,
+ <&cpg 0xe4>, <&cpg 0xe5>,
+ <&cpg 0xe6>, <&cpg 0xe7>,
+ <&cpg 0xe8>, <&cpg 0xe9>,
+ <&cpg 0xea>, <&cpg 0xeb>,
+ <&cpg 0xec>, <&cpg 0xee>,
+ <&cpg 0xed>;
+ reset-names = "ssi-all",
+ "ssi-0", "ssi-1",
+ "ssi-2", "ssi-3",
+ "ssi-4", "ssi-5",
+ "ssi-6", "ssi-7",
+ "ssi-8", "ssi-9",
+ "scu", "adg",
+ "audmapp";
+ status = "disabled";
+
+ ctu {
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
+ };
+
+ dvc {
+ dvc0: dvc-0 {
+ dmas = <&dmac0 0x1db3>, <&dmac1 0x1db3>,
+ <&dmac2 0x1db3>, <&dmac3 0x1db3>,
+ <&dmac4 0x1db3>;
+ dma-names = "tx", "tx", "tx", "tx", "tx";
+ };
+ dvc1: dvc-1 {
+ dmas = <&dmac0 0x1db4>, <&dmac1 0x1db4>,
+ <&dmac2 0x1db4>, <&dmac3 0x1db4>,
+ <&dmac4 0x1db4>;
+ dma-names = "tx", "tx", "tx", "tx", "tx";
+ };
+ };
+
+ mix {
+ mix0: mix-0 { };
+ mix1: mix-1 { };
+ };
+
+ src {
+ src0: src-0 {
+ interrupts = <GIC_SPI 902 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1d9f>, <&dmac0 0x1da9>,
+ <&dmac1 0x1d9f>, <&dmac1 0x1da9>,
+ <&dmac2 0x1d9f>, <&dmac2 0x1da9>,
+ <&dmac3 0x1d9f>, <&dmac3 0x1da9>,
+ <&dmac4 0x1d9f>, <&dmac4 0x1da9>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src1: src-1 {
+ interrupts = <GIC_SPI 903 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da0>, <&dmac0 0x1daa>,
+ <&dmac1 0x1da0>, <&dmac1 0x1daa>,
+ <&dmac2 0x1da0>, <&dmac2 0x1daa>,
+ <&dmac3 0x1da0>, <&dmac3 0x1daa>,
+ <&dmac4 0x1da0>, <&dmac4 0x1daa>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src2: src-2 {
+ interrupts = <GIC_SPI 904 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da1>, <&dmac0 0x1dab>,
+ <&dmac1 0x1da1>, <&dmac1 0x1dab>,
+ <&dmac2 0x1da1>, <&dmac2 0x1dab>,
+ <&dmac3 0x1da1>, <&dmac3 0x1dab>,
+ <&dmac4 0x1da1>, <&dmac4 0x1dab>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src3: src-3 {
+ interrupts = <GIC_SPI 905 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da2>, <&dmac0 0x1dac>,
+ <&dmac1 0x1da2>, <&dmac1 0x1dac>,
+ <&dmac2 0x1da2>, <&dmac2 0x1dac>,
+ <&dmac3 0x1da2>, <&dmac3 0x1dac>,
+ <&dmac4 0x1da2>, <&dmac4 0x1dac>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src4: src-4 {
+ interrupts = <GIC_SPI 906 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da3>, <&dmac0 0x1dad>,
+ <&dmac1 0x1da3>, <&dmac1 0x1dad>,
+ <&dmac2 0x1da3>, <&dmac2 0x1dad>,
+ <&dmac3 0x1da3>, <&dmac3 0x1dad>,
+ <&dmac4 0x1da3>, <&dmac4 0x1dad>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src5: src-5 {
+ interrupts = <GIC_SPI 907 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da4>, <&dmac0 0x1dae>,
+ <&dmac1 0x1da4>, <&dmac1 0x1dae>,
+ <&dmac2 0x1da4>, <&dmac2 0x1dae>,
+ <&dmac3 0x1da4>, <&dmac3 0x1dae>,
+ <&dmac4 0x1da4>, <&dmac4 0x1dae>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src6: src-6 {
+ interrupts = <GIC_SPI 908 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da5>, <&dmac0 0x1daf>,
+ <&dmac1 0x1da5>, <&dmac1 0x1daf>,
+ <&dmac2 0x1da5>, <&dmac2 0x1daf>,
+ <&dmac3 0x1da5>, <&dmac3 0x1daf>,
+ <&dmac4 0x1da5>, <&dmac4 0x1daf>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src7: src-7 {
+ interrupts = <GIC_SPI 909 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da6>, <&dmac0 0x1db0>,
+ <&dmac1 0x1da6>, <&dmac1 0x1db0>,
+ <&dmac2 0x1da6>, <&dmac2 0x1db0>,
+ <&dmac3 0x1da6>, <&dmac3 0x1db0>,
+ <&dmac4 0x1da6>, <&dmac4 0x1db0>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src8: src-8 {
+ interrupts = <GIC_SPI 910 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da7>, <&dmac0 0x1db1>,
+ <&dmac1 0x1da7>, <&dmac1 0x1db1>,
+ <&dmac2 0x1da7>, <&dmac2 0x1db1>,
+ <&dmac3 0x1da7>, <&dmac3 0x1db1>,
+ <&dmac4 0x1da7>, <&dmac4 0x1db1>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src9: src-9 {
+ interrupts = <GIC_SPI 911 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da8>, <&dmac0 0x1db2>,
+ <&dmac1 0x1da8>, <&dmac1 0x1db2>,
+ <&dmac2 0x1da8>, <&dmac2 0x1db2>,
+ <&dmac3 0x1da8>, <&dmac3 0x1db2>,
+ <&dmac4 0x1da8>, <&dmac4 0x1db2>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ };
+
+ ssi {
+ ssi0: ssi-0 {
+ interrupts = <GIC_SPI 889 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi1: ssi-1 {
+ interrupts = <GIC_SPI 890 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi2: ssi-2 {
+ interrupts = <GIC_SPI 891 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi3: ssi-3 {
+ interrupts = <GIC_SPI 892 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi4: ssi-4 {
+ interrupts = <GIC_SPI 893 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi5: ssi-5 {
+ interrupts = <GIC_SPI 894 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi6: ssi-6 {
+ interrupts = <GIC_SPI 895 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi7: ssi-7 {
+ interrupts = <GIC_SPI 896 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi8: ssi-8 {
+ interrupts = <GIC_SPI 897 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi9: ssi-9 {
+ interrupts = <GIC_SPI 898 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ ssiu {
+ ssiu00: ssiu-0 {
+ dmas = <&dmac0 0x1d61>, <&dmac0 0x1d62>,
+ <&dmac1 0x1d61>, <&dmac1 0x1d62>,
+ <&dmac2 0x1d61>, <&dmac2 0x1d62>,
+ <&dmac3 0x1d61>, <&dmac3 0x1d62>,
+ <&dmac4 0x1d61>, <&dmac4 0x1d62>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu01: ssiu-1 {
+ dmas = <&dmac0 0x1d63>, <&dmac0 0x1d64>,
+ <&dmac1 0x1d63>, <&dmac1 0x1d64>,
+ <&dmac2 0x1d63>, <&dmac2 0x1d64>,
+ <&dmac3 0x1d63>, <&dmac3 0x1d64>,
+ <&dmac4 0x1d63>, <&dmac4 0x1d64>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu02: ssiu-2 {
+ dmas = <&dmac0 0x1d65>, <&dmac0 0x1d66>,
+ <&dmac1 0x1d65>, <&dmac1 0x1d66>,
+ <&dmac2 0x1d65>, <&dmac2 0x1d66>,
+ <&dmac3 0x1d65>, <&dmac3 0x1d66>,
+ <&dmac4 0x1d65>, <&dmac4 0x1d66>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu03: ssiu-3 {
+ dmas = <&dmac0 0x1d67>, <&dmac0 0x1d68>,
+ <&dmac1 0x1d67>, <&dmac1 0x1d68>,
+ <&dmac2 0x1d67>, <&dmac2 0x1d68>,
+ <&dmac3 0x1d67>, <&dmac3 0x1d68>,
+ <&dmac4 0x1d67>, <&dmac4 0x1d68>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu10: ssiu-4 {
+ dmas = <&dmac0 0x1d69>, <&dmac0 0x1d6a>,
+ <&dmac1 0x1d69>, <&dmac1 0x1d6a>,
+ <&dmac2 0x1d69>, <&dmac2 0x1d6a>,
+ <&dmac3 0x1d69>, <&dmac3 0x1d6a>,
+ <&dmac4 0x1d69>, <&dmac4 0x1d6a>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu11: ssiu-5 {
+ dmas = <&dmac0 0x1d6b>, <&dmac0 0x1d6c>,
+ <&dmac1 0x1d6b>, <&dmac1 0x1d6c>,
+ <&dmac2 0x1d6b>, <&dmac2 0x1d6c>,
+ <&dmac3 0x1d6b>, <&dmac3 0x1d6c>,
+ <&dmac4 0x1d6b>, <&dmac4 0x1d6c>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu12: ssiu-6 {
+ dmas = <&dmac0 0x1d6d>, <&dmac0 0x1d6e>,
+ <&dmac1 0x1d6d>, <&dmac1 0x1d6e>,
+ <&dmac2 0x1d6d>, <&dmac2 0x1d6e>,
+ <&dmac3 0x1d6d>, <&dmac3 0x1d6e>,
+ <&dmac4 0x1d6d>, <&dmac4 0x1d6e>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu13: ssiu-7 {
+ dmas = <&dmac0 0x1d6f>, <&dmac0 0x1d70>,
+ <&dmac1 0x1d6f>, <&dmac1 0x1d70>,
+ <&dmac2 0x1d6f>, <&dmac2 0x1d70>,
+ <&dmac3 0x1d6f>, <&dmac3 0x1d70>,
+ <&dmac4 0x1d6f>, <&dmac4 0x1d70>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu20: ssiu-8 {
+ dmas = <&dmac0 0x1d71>, <&dmac0 0x1d72>,
+ <&dmac1 0x1d71>, <&dmac1 0x1d72>,
+ <&dmac2 0x1d71>, <&dmac2 0x1d72>,
+ <&dmac3 0x1d71>, <&dmac3 0x1d72>,
+ <&dmac4 0x1d71>, <&dmac4 0x1d72>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu21: ssiu-9 {
+ dmas = <&dmac0 0x1d73>, <&dmac0 0x1d74>,
+ <&dmac1 0x1d73>, <&dmac1 0x1d74>,
+ <&dmac2 0x1d73>, <&dmac2 0x1d74>,
+ <&dmac3 0x1d73>, <&dmac3 0x1d74>,
+ <&dmac4 0x1d73>, <&dmac4 0x1d74>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu22: ssiu-10 {
+ dmas = <&dmac0 0x1d75>, <&dmac0 0x1d76>,
+ <&dmac1 0x1d75>, <&dmac1 0x1d76>,
+ <&dmac2 0x1d75>, <&dmac2 0x1d76>,
+ <&dmac3 0x1d75>, <&dmac3 0x1d76>,
+ <&dmac4 0x1d75>, <&dmac4 0x1d76>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu23: ssiu-11 {
+ dmas = <&dmac0 0x1d77>, <&dmac0 0x1d78>,
+ <&dmac1 0x1d77>, <&dmac1 0x1d78>,
+ <&dmac2 0x1d77>, <&dmac2 0x1d78>,
+ <&dmac3 0x1d77>, <&dmac3 0x1d78>,
+ <&dmac4 0x1d77>, <&dmac4 0x1d78>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu30: ssiu-12 {
+ dmas = <&dmac0 0x1d79>, <&dmac0 0x1d7a>,
+ <&dmac1 0x1d79>, <&dmac1 0x1d7a>,
+ <&dmac2 0x1d79>, <&dmac2 0x1d7a>,
+ <&dmac3 0x1d79>, <&dmac3 0x1d7a>,
+ <&dmac4 0x1d79>, <&dmac4 0x1d7a>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu31: ssiu-13 {
+ dmas = <&dmac0 0x1d7b>, <&dmac0 0x1d7c>,
+ <&dmac1 0x1d7b>, <&dmac1 0x1d7c>,
+ <&dmac2 0x1d7b>, <&dmac2 0x1d7c>,
+ <&dmac3 0x1d7b>, <&dmac3 0x1d7c>,
+ <&dmac4 0x1d7b>, <&dmac4 0x1d7c>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu32: ssiu-14 {
+ dmas = <&dmac0 0x1d7d>, <&dmac0 0x1d7e>,
+ <&dmac1 0x1d7d>, <&dmac1 0x1d7e>,
+ <&dmac2 0x1d7d>, <&dmac2 0x1d7e>,
+ <&dmac3 0x1d7d>, <&dmac3 0x1d7e>,
+ <&dmac4 0x1d7d>, <&dmac4 0x1d7e>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu33: ssiu-15 {
+ dmas = <&dmac0 0x1d7f>, <&dmac0 0x1d80>,
+ <&dmac1 0x1d7f>, <&dmac1 0x1d80>,
+ <&dmac2 0x1d7f>, <&dmac2 0x1d80>,
+ <&dmac3 0x1d7f>, <&dmac3 0x1d80>,
+ <&dmac4 0x1d7f>, <&dmac4 0x1d80>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu40: ssiu-16 {
+ dmas = <&dmac0 0x1d81>, <&dmac0 0x1d82>,
+ <&dmac1 0x1d81>, <&dmac1 0x1d82>,
+ <&dmac2 0x1d81>, <&dmac2 0x1d82>,
+ <&dmac3 0x1d81>, <&dmac3 0x1d82>,
+ <&dmac4 0x1d81>, <&dmac4 0x1d82>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu41: ssiu-17 {
+ dmas = <&dmac0 0x1d83>, <&dmac0 0x1d84>,
+ <&dmac1 0x1d83>, <&dmac1 0x1d84>,
+ <&dmac2 0x1d83>, <&dmac2 0x1d84>,
+ <&dmac3 0x1d83>, <&dmac3 0x1d84>,
+ <&dmac4 0x1d83>, <&dmac4 0x1d84>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu42: ssiu-18 {
+ dmas = <&dmac0 0x1d85>, <&dmac0 0x1d86>,
+ <&dmac1 0x1d85>, <&dmac1 0x1d86>,
+ <&dmac2 0x1d85>, <&dmac2 0x1d86>,
+ <&dmac3 0x1d85>, <&dmac3 0x1d86>,
+ <&dmac4 0x1d85>, <&dmac4 0x1d86>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu43: ssiu-19 {
+ dmas = <&dmac0 0x1d87>, <&dmac0 0x1d88>,
+ <&dmac1 0x1d87>, <&dmac1 0x1d88>,
+ <&dmac2 0x1d87>, <&dmac2 0x1d88>,
+ <&dmac3 0x1d87>, <&dmac3 0x1d88>,
+ <&dmac4 0x1d87>, <&dmac4 0x1d88>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu50: ssiu-20 {
+ dmas = <&dmac0 0x1d89>, <&dmac0 0x1d8a>,
+ <&dmac1 0x1d89>, <&dmac1 0x1d8a>,
+ <&dmac2 0x1d89>, <&dmac2 0x1d8a>,
+ <&dmac3 0x1d89>, <&dmac3 0x1d8a>,
+ <&dmac4 0x1d89>, <&dmac4 0x1d8a>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu60: ssiu-21 {
+ dmas = <&dmac0 0x1d8b>, <&dmac0 0x1d8c>,
+ <&dmac1 0x1d8b>, <&dmac1 0x1d8c>,
+ <&dmac2 0x1d8b>, <&dmac2 0x1d8c>,
+ <&dmac3 0x1d8b>, <&dmac3 0x1d8c>,
+ <&dmac4 0x1d8b>, <&dmac4 0x1d8c>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu70: ssiu-22 {
+ dmas = <&dmac0 0x1d8d>, <&dmac0 0x1d8e>,
+ <&dmac1 0x1d8d>, <&dmac1 0x1d8e>,
+ <&dmac2 0x1d8d>, <&dmac2 0x1d8e>,
+ <&dmac3 0x1d8d>, <&dmac3 0x1d8e>,
+ <&dmac4 0x1d8d>, <&dmac4 0x1d8e>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu80: ssiu-23 {
+ dmas = <&dmac0 0x1d8f>, <&dmac0 0x1d90>,
+ <&dmac1 0x1d8f>, <&dmac1 0x1d90>,
+ <&dmac2 0x1d8f>, <&dmac2 0x1d90>,
+ <&dmac3 0x1d8f>, <&dmac3 0x1d90>,
+ <&dmac4 0x1d8f>, <&dmac4 0x1d90>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu90: ssiu-24 {
+ dmas = <&dmac0 0x1d91>, <&dmac0 0x1d92>,
+ <&dmac1 0x1d91>, <&dmac1 0x1d92>,
+ <&dmac2 0x1d91>, <&dmac2 0x1d92>,
+ <&dmac3 0x1d91>, <&dmac3 0x1d92>,
+ <&dmac4 0x1d91>, <&dmac4 0x1d92>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu91: ssiu-25 {
+ dmas = <&dmac0 0x1d93>, <&dmac0 0x1d94>,
+ <&dmac1 0x1d93>, <&dmac1 0x1d94>,
+ <&dmac2 0x1d93>, <&dmac2 0x1d94>,
+ <&dmac3 0x1d93>, <&dmac3 0x1d94>,
+ <&dmac4 0x1d93>, <&dmac4 0x1d94>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu92: ssiu-26 {
+ dmas = <&dmac0 0x1d95>, <&dmac0 0x1d96>,
+ <&dmac1 0x1d95>, <&dmac1 0x1d96>,
+ <&dmac2 0x1d95>, <&dmac2 0x1d96>,
+ <&dmac3 0x1d95>, <&dmac3 0x1d96>,
+ <&dmac4 0x1d95>, <&dmac4 0x1d96>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu93: ssiu-27 {
+ dmas = <&dmac0 0x1d97>, <&dmac0 0x1d98>,
+ <&dmac1 0x1d97>, <&dmac1 0x1d98>,
+ <&dmac2 0x1d97>, <&dmac2 0x1d98>,
+ <&dmac3 0x1d97>, <&dmac3 0x1d98>,
+ <&dmac4 0x1d97>, <&dmac4 0x1d98>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ };
+ };
+
wdt1: watchdog@14400000 {
compatible = "renesas,r9a09g047-wdt", "renesas,r9a09g057-wdt";
reg = <0 0x14400000 0 0x400>;
--
2.25.1
^ permalink raw reply related
* [PATCH v6 2/4] arm64: dts: renesas: rzg3e-smarc-som: Add Versa3 clock generator
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
In-Reply-To: <20260619083951.3777556-1-john.madieu.xa@bp.renesas.com>
Add the Renesas 5P35023 (Versa3) programmable clock generator on the
I2C2 bus along with its 24MHz input clock (x2 oscillator) to feed the
audio subsystem.
The Versa3 provides the following clock outputs:
- Output 0: 24MHz (reference)
- Output 1: 12.288MHz (audio, 48kHz family)
- Output 2: 11.2896MHz (audio, 44.1kHz family)
- Output 3: 12.288MHz (audio)
- Output 4: 25MHz (DIFF1, Ethernet)
These clocks are required for the audio codec and the Ethernet
controller found on the RZ/G3E SMARC EVK.
Output 5 (DIFF2) is left out, as it is not connected on this board.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Changes:
v6:
- Actually drop Versa3 output 5 (DIFF2) from assigned-clocks and
assigned-clock-rates; v5 documented the removal in the commit
message but left the entry in the DTS.
v5:
- Document output 4 (DIFF1) in the commit message; it is needed for
Ethernet.
.../boot/dts/renesas/rzg3e-smarc-som.dtsi | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
index 15c22dbf0ad3..455ed35ae5d3 100644
--- a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
@@ -78,6 +78,12 @@ reg_vdd0p8v_others: regulator-vdd0p8v-others {
regulator-always-on;
};
+ x2: x2-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ };
+
/* 32.768kHz crystal */
x3: x3-clock {
compatible = "fixed-clock";
@@ -137,6 +143,20 @@ raa215300: pmic@12 {
interrupts-extended = <&pinctrl RZG3E_GPIO(S, 1) IRQ_TYPE_EDGE_FALLING>;
};
+
+ versa3: clock-generator@68 {
+ compatible = "renesas,5p35023";
+ reg = <0x68>;
+ #clock-cells = <1>;
+ clocks = <&x2>;
+
+ assigned-clocks = <&versa3 0>, <&versa3 1>,
+ <&versa3 2>, <&versa3 3>,
+ <&versa3 4>;
+ assigned-clock-rates = <24000000>, <12288000>,
+ <11289600>, <12288000>,
+ <25000000>;
+ };
};
&i3c {
--
2.25.1
^ permalink raw reply related
* [PATCH v6 3/4] arm64: dts: renesas: rzg3e-smarc-som: add audio pinmux definitions
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
In-Reply-To: <20260619083951.3777556-1-john.madieu.xa@bp.renesas.com>
Add pinmux definitions for SSI3/SSI4 audio interface on RZ/G3E SMARC SoM:
- sound_clk_pins: AUDIO_CLKB and AUDIO_CLKC clock outputs
- sound_pins: SSI3_SCK, SSI3_WS, SSI3_SDATA (playback) and
SSI4_SDATA (capture)
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Changes:
v6: No changes.
v5:
- Rename the sound_clk / sound pinctrl node names to use hyphens
instead of underscores.
- Sort the sound pinmux entries by GPIO number.
arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
index 455ed35ae5d3..0e6dc84e0199 100644
--- a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
@@ -352,6 +352,18 @@ sd2-pwen {
};
};
+ sound_clk_pins: sound-clk {
+ pinmux = <RZG3E_PORT_PINMUX(4, 2, 8)>, /* AUDIO_CLKB */
+ <RZG3E_PORT_PINMUX(4, 3, 8)>; /* AUDIO_CLKC */
+ };
+
+ sound_pins: sound {
+ pinmux = <RZG3E_PORT_PINMUX(0, 2, 9)>, /* SSI3_SDATA */
+ <RZG3E_PORT_PINMUX(0, 3, 9)>, /* SSI3_SCK */
+ <RZG3E_PORT_PINMUX(0, 4, 9)>, /* SSI3_WS */
+ <RZG3E_PORT_PINMUX(0, 5, 9)>; /* SSI4_SDATA */
+ };
+
xspi_pins: xspi0 {
pinmux = <RZG3E_PORT_PINMUX(M, 0, 0)>, /* XSPI0_IO0 */
<RZG3E_PORT_PINMUX(M, 1, 0)>, /* XSPI0_IO1 */
--
2.25.1
^ permalink raw reply related
* [PATCH v6 4/4] arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec support
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
In-Reply-To: <20260619083951.3777556-1-john.madieu.xa@bp.renesas.com>
RZ/G3E SMARC board has a DA7212 audio codec connected via I2C1 for
sound input/output using SSI3/SSI4 where:
- The codec receives its master clock from the Versa3 clock
generator present on the SoM
- SSI4 shares clock pins with SSI3 to provide a separate data
line for full-duplex audio capture.
Enable audio support on RZ/G3E SMARC2 EVK boards with a DA7212 audio codec.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Changes:
v6: No changes.
v5:
- Drop the unnecessary #address-cells / #size-cells from the
codec@1a node; the port child has no unit address or reg, and the
da7212 binding sets unevaluatedProperties: false.
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 112 ++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts b/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
index 6372f582a7c4..ac525b73c1bb 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
+++ b/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
@@ -32,6 +32,37 @@
#include "rzg3e-smarc-som.dtsi"
#include "renesas-smarc2.dtsi"
+/*
+ * SSI-DA7212
+ *
+ * These commands are required when Playback/Capture
+ *
+ * amixer -q cset name='Aux Switch' on
+ * amixer -q cset name='Mixin Left Aux Left Switch' on
+ * amixer -q cset name='Mixin Right Aux Right Switch' on
+ * amixer -q cset name='ADC Switch' on
+ * amixer -q cset name='Mixout Right Mixin Right Switch' off
+ * amixer -q cset name='Mixout Left Mixin Left Switch' off
+ * amixer -q cset name='Headphone Volume' 70%
+ * amixer -q cset name='Headphone Switch' on
+ * amixer -q cset name='Mixout Left DAC Left Switch' on
+ * amixer -q cset name='Mixout Right DAC Right Switch' on
+ * amixer -q cset name='DAC Left Source MUX' 'DAI Input Left'
+ * amixer -q cset name='DAC Right Source MUX' 'DAI Input Right'
+ * amixer -q sset 'Mic 1 Amp Source MUX' 'MIC_P'
+ * amixer -q sset 'Mic 2 Amp Source MUX' 'MIC_P'
+ * amixer -q sset 'Mixin Left Mic 1' on
+ * amixer -q sset 'Mixin Right Mic 2' on
+ * amixer -q sset 'Mic 1' 90% on
+ * amixer -q sset 'Mic 2' 90% on
+ * amixer -q sset 'Lineout' 80% on
+ * amixer -q set "Headphone" 100% on
+ *
+ * When Capture chained with DVC, use this command to amplify sound
+ * amixer set 'DVC In',0 80%
+ * For playback, use: amixer set 'DVC Out',0 80%
+ */
+
/ {
model = "Renesas SMARC EVK version 2 based on r9a09g047e57";
compatible = "renesas,smarc2-evk", "renesas,rzg3e-smarcm",
@@ -55,6 +86,22 @@ vqmmc_sd1_pvdd: regulator-vqmmc-sd1-pvdd {
gpios-states = <0>;
states = <3300000 0>, <1800000 1>;
};
+
+ sound_card: sound {
+ compatible = "audio-graph-card";
+
+ label = "snd-rzg3e";
+
+ dais = <&rsnd_port0>; /* DA7212 */
+ };
+};
+
+&audio_clkb {
+ clock-frequency = <11289600>;
+};
+
+&audio_clkc {
+ clock-frequency = <12288000>;
};
&canfd {
@@ -99,6 +146,35 @@ &i2c0 {
pinctrl-names = "default";
};
+&i2c1 {
+ da7212: codec@1a {
+ compatible = "dlg,da7212";
+ #sound-dai-cells = <0>;
+ reg = <0x1a>;
+
+ clocks = <&versa3 1>;
+ clock-names = "mclk";
+
+ dlg,micbias1-lvl = <2500>;
+ dlg,micbias2-lvl = <2500>;
+ dlg,dmic-data-sel = "lrise_rfall";
+ dlg,dmic-samplephase = "between_clkedge";
+ dlg,dmic-clkrate = <3000000>;
+
+ VDDA-supply = <®_1p8v>;
+ VDDSP-supply = <®_3p3v>;
+ VDDMIC-supply = <®_3p3v>;
+ VDDIO-supply = <®_1p8v>;
+
+ port {
+ da7212_endpoint: endpoint {
+ remote-endpoint = <&rsnd_endpoint0>;
+ mclk-fs = <256>;
+ };
+ };
+ };
+};
+
&keys {
pinctrl-0 = <&nmi_pins>;
pinctrl-names = "default";
@@ -280,6 +356,42 @@ &sdhi1 {
vqmmc-supply = <&vqmmc_sd1_pvdd>;
};
+&snd_rzg3e {
+ pinctrl-0 = <&sound_clk_pins &sound_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* audio_clkout */
+ #clock-cells = <0>;
+ clock-frequency = <11289600>;
+
+ /* Multi DAI */
+ #sound-dai-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rsnd_port0: port@0 {
+ reg = <0>;
+ rsnd_endpoint0: endpoint {
+ remote-endpoint = <&da7212_endpoint>;
+
+ dai-format = "i2s";
+ bitclock-master = <&rsnd_endpoint0>;
+ frame-master = <&rsnd_endpoint0>;
+
+ playback = <&ssi3>, <&src1>, <&dvc1>;
+ capture = <&ssi4>, <&src0>, <&dvc0>;
+ };
+ };
+ };
+};
+
+&ssi4 {
+ shared-pin;
+};
+
&usb3_phy {
status = "okay";
};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 04/21] pinctrl: starfive: Add StarFive JHB100 sys0 controller driver
From: Changhuang Liang @ 2026-06-19 8:41 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Emil Renner Berthing, Paul Walmsley, Albert Ou, Palmer Dabbelt,
Alexandre Ghiti, Philipp Zabel, Bartosz Golaszewski,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Lianfeng Ouyang
In-Reply-To: <CAD++jL=Qd8ADR_kX2Q7msM4Dd0xFayPGM4ZzB3uv2ufvkuybtQ@mail.gmail.com>
Hi, Linus
Thanks for the review.
I will first try making revisions according to your suggestions below. It may take some time for
the next version. If I run into any issues during the subsequent revisions, I may bother you then.
Best Regards,
Changhuang
> Hi Changhuang,
>
> thanks for your patch!
>
> On Wed, Jun 3, 2026 at 7:54 AM Changhuang Liang
> <changhuang.liang@starfivetech.com> wrote:
>
> > Add pinctrl driver for StarFive JHB100 SoC System-0(sys0) pinctrl
> > controller.
> >
> > Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
> > Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
>
> This patch adds generic infrastructure "JHB100" that is then used by several
> drivers does it not?
>
> Write something about that and some about the design in the commit
> message.
>
> > +++ b/drivers/pinctrl/starfive/pinctrl-starfive-jhb100-sys0.c
> > @@ -0,0 +1,123 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Pinctrl / GPIO driver for StarFive JHB100 SoC System-0 domain
> > + *
> > + * Copyright (C) 2024 StarFive Technology Co., Ltd.
> > + * Author: Alex Soo <yuklin.soo@starfivetech.com>
>
> Shouldn't this person be in the Signed-off-by?
>
> I guess it's not legally necessary but feels appropriate.
>
> > +static struct config_reg_layout_desc jhb100_sys0_pinctrl_crl_desc[] = {
> > + {
> > + .pin_start = 0,
> > + .pin_cnt = 4,
> > + .drive_strength_2bit = { .shift = 0, .width
> = 2 },
> > + .input_enable = { .shift =
> 2, .width = 1 },
> > + .pull_down = { .shift =
> 3, .width = 1 },
> > + .pull_up = { .shift =
> 4, .width = 1 },
> > + .slew_rate = { .shift =
> 5, .width = 1 },
> > + .schmitt_trigger_select = { .shift = 6, .width =
> 1 },
> > + .reserved = { .shift =
> 7, .width = 8 },
> > + .debounce_width = { .shift =
> 15, .width = 17 },
> > + },
> > + {
> > + .pin_start = 4,
> > + .pin_cnt = 5,
> > + .schmitt_trigger_select = { .shift = 0, .width =
> 1 },
> > + .reserved = { .shift =
> 1, .width = 31 },
> > + },
> > + {
> > + .pin_start = 9,
> > + .pin_cnt = 1,
> > + .drive_strength_2bit = { .shift = 0, .width
> = 2 },
> > + .slew_rate = { .shift =
> 2, .width = 1 },
> > + .reserved = { .shift =
> 3, .width = 29 },
> > + },
> > + {
> > + .pin_start = 10,
> > + .pin_cnt = 1,
> > + .drive_strength_2bit = { .shift = 0, .width
> = 2 },
> > + .input_enable = { .shift =
> 2, .width = 1 },
> > + .pull_down = { .shift =
> 3, .width = 1 },
> > + .pull_up = { .shift =
> 4, .width = 1 },
> > + .slew_rate = { .shift =
> 5, .width = 1 },
> > + .schmitt_trigger_select = { .shift = 6, .width =
> 1 },
> > + .reserved = { .shift =
> 7, .width = 25 },
> > + },
> > + { 0xff },
> > +};
>
> Would it be appropriate to index the different register variants with a enum
> with a good name so it is easy to understand which variant each entry in the
> array is?
>
> > +#include <linux/string.h>
> > +#include <linux/sort.h>
>
> Hm why... I guess I will see.
>
> > +#define JHB100_DEBOUNCE_WIDTH_STAGES_MAX 0x1FFFFU
>
> Is that a GENMASK(16,0)?
>
> Since it seems to have something to do with bitfield widths.
>
> > +/* i2c open-drain pull-up select */
> > +#define JHB100_I2C_OPEN_DRAIN_PU_600_OHMS 0
> > +#define JHB100_I2C_OPEN_DRAIN_PU_900_OHMS 1
> > +#define JHB100_I2C_OPEN_DRAIN_PU_1200_OHMS 2
> > +#define JHB100_I2C_OPEN_DRAIN_PU_2000_OHMS 3
>
> Very nice and to the point! It's easy to read and understand drivers that are
> writing things out explicitly like this!
>
> > +#define JHB100_NR_GPIOS_PER_BANK 32
> (...)
> > +static inline struct jhb100_gpio_bank *jhb100_gc_to_bank(struct
> > +gpio_chip *gc) {
> > + return container_of(gc, struct jhb100_gpio_bank, gc); }
> > +
> > +static unsigned int jhb100_gpio_to_pin(struct gpio_chip *gc, unsigned
> > +int gpio) {
> > + struct jhb100_gpio_bank *bank = jhb100_gc_to_bank(gc);
> > +
> > + return bank->id * JHB100_NR_GPIOS_PER_BANK + gpio; }
>
> This usually tells me that GPIO_GENERIC can be used but maybe this has been
> discussed before...
>
> > +static const struct pinctrl_ops jhb100_pinctrl_ops = {
> > + .get_groups_count = pinctrl_generic_get_group_count,
> > + .get_group_name = pinctrl_generic_get_group_name,
> > + .get_group_pins = pinctrl_generic_get_group_pins,
> > + .dt_node_to_map =
> pinctrl_generic_pins_function_dt_node_to_map,
> > + .dt_free_map = pinctrl_utils_free_map,
> > +};
>
> Nice use of the generic helpers!
>
> > +static void jhb100_set_gpioval(struct jhb100_pinctrl *sfp, unsigned int pin,
> > + unsigned int val) {
> > + const struct jhb100_pinctrl_domain_info *info = sfp->info;
> > + unsigned int offset = 4 * (pin / 32);
> > + unsigned int shift = 1 * (pin % 32);
> > + unsigned int fs_offset = 4 * (pin / 16);
> > + unsigned int fs_shift = 2 * (pin % 16);
> > + u32 func_sel_mask;
> > + u32 dout, doen, fs;
> > + void __iomem *reg_gpio_o;
> > + void __iomem *reg_gpio_oen;
> > + void __iomem *reg_gpio_func_sel;
> > + unsigned long flags;
> > +
> > + reg_gpio_o = sfp->base + info->regs->output + offset;
> > + reg_gpio_oen = sfp->base + info->regs->output_en + offset;
> > + reg_gpio_func_sel = sfp->base + info->regs->func_sel.reg +
> > + fs_offset;
>
> The part from here:
>
> > + func_sel_mask = GENMASK(info->regs->func_sel.width_per_pin -
> > + 1, 0) << fs_shift;
> (...)
> > +
> > + raw_spin_lock_irqsave(&sfp->lock, flags);
> > + fs = readl_relaxed(reg_gpio_func_sel);
> > + if (fs & func_sel_mask) {
> > + fs &= ~func_sel_mask;
> > + writel_relaxed(fs, reg_gpio_func_sel);
> > + }
>
> ..to here seems to reimplement the shortcut
> .gpio_request_enable() in struct pinmux_ops.
>
> Then this:
>
> > + dout = val << shift;
> > + doen = 0;
>
> > + dout |= readl_relaxed(reg_gpio_o) & ~BIT(shift);
> > + writel_relaxed(dout, reg_gpio_o);
> > + doen |= readl_relaxed(reg_gpio_oen) & ~BIT(shift);
> > + writel_relaxed(doen, reg_gpio_oen);
>
> Seems more like the actual code that should be here.
>
> > + raw_spin_unlock_irqrestore(&sfp->lock, flags);
>
> Please use guards for these spinlocks. They make for less bugs.
>
> guard(raw_spinlock_irqsave)(&sfp->lock);
>
> > +static const struct pinmux_ops jhb100_pinmux_ops = {
> > + .get_functions_count = pinmux_generic_get_function_count,
> > + .get_function_name = pinmux_generic_get_function_name,
> > + .get_function_groups = pinmux_generic_get_function_groups,
> > + .set_mux = jhb100_set_mux,
> > +};
>
> Implement .gpio_request_enable() (see above) and
> .gpio_set_direction() see below.
>
> Maybe also .gpio_disable_free() if you need to deconfigure stuff when a pin is
> release from GPIO.
>
> > +static const struct pinconf_ops jhb100_pinconf_ops = {
> > + .pin_config_get = jhb100_pinconf_get,
> > + .pin_config_set = jhb100_pinconf_set,
> > + .pin_config_group_get = jhb100_pinconf_group_get,
> > + .pin_config_group_set = jhb100_pinconf_group_set,
> > + .is_generic = true,
> > +};
>
> Overall this looks nice, good use of the group config!
>
> > +static int jhb100_gpio_get_direction(struct gpio_chip *gc,
> > + unsigned int gpio) {
> > + struct jhb100_gpio_bank *bank = jhb100_gc_to_bank(gc);
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + const struct jhb100_pinctrl_domain_info *info = sfp->info;
> > + unsigned int offset = 4 * bank->id;
> > + u32 doen;
> > + void __iomem *reg_gpio_oen;
> > +
> > + reg_gpio_oen = sfp->base + info->regs->output_en + offset;
> > +
> > + doen = (readl_relaxed(reg_gpio_oen) & BIT(gpio)) >> gpio;
> > +
> > + return doen == GPOEN_ENABLE ? GPIO_LINE_DIRECTION_OUT :
> > +GPIO_LINE_DIRECTION_IN; }
> > +
> > +static int jhb100_gpio_direction_input(struct gpio_chip *gc,
> > + unsigned int gpio) {
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + struct device *dev = sfp->dev;
> > + struct config_reg_layout_desc *crl_desc;
> > + unsigned int pin = jhb100_gpio_to_pin(gc, gpio);
> > +
> > + crl_desc = get_crl_desc_by_pin(sfp, pin);
> > + if (!crl_desc) {
> > + dev_err(dev, "pin %d can't not found reg layout
> descriptor\n",
> > + pin);
> > + return -EINVAL;
> > + }
> > +
> > + jhb100_padcfg_rmw(sfp, pin,
> > + RL_DESC_GENMASK(crl_desc,
> input_enable) |
> > + RL_DESC_GENMASK(crl_desc,
> schmitt_trigger_select),
> > + RL_DESC_GENMASK(crl_desc,
> input_enable) |
> > + RL_DESC_GENMASK(crl_desc,
> > + schmitt_trigger_select));
>
> Instead of doing these writes directly into the config registers, implement
> .gpio_set_direction() in struct pinmux_ops and call the pinmux generic
> back-end.
>
> > +static int jhb100_gpio_direction_output(struct gpio_chip *gc,
> > + unsigned int gpio, int
> value)
> > +{
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + struct device *dev = sfp->dev;
> > + struct config_reg_layout_desc *crl_desc;
> > + unsigned int pin = jhb100_gpio_to_pin(gc, gpio);
> > +
> > + jhb100_set_one_pin_mux(sfp, pin, 0,
> > + value ? GPOUT_HIGH :
> GPOUT_LOW);
> > +
> > + crl_desc = get_crl_desc_by_pin(sfp, pin);
> > + if (!crl_desc) {
> > + dev_err(dev, "pin %d can't not found reg layout
> descriptor\n",
> > + pin);
> > + return -EINVAL;
> > + }
> > +
> > + jhb100_padcfg_rmw(sfp, pin,
> > + RL_DESC_GENMASK(crl_desc,
> input_enable) |
> > + RL_DESC_GENMASK(crl_desc,
> schmitt_trigger_select) |
> > + RL_DESC_GENMASK(crl_desc, pull_down) |
> > + RL_DESC_GENMASK(crl_desc, pull_up),
> > + 0);
>
> Dito.
>
> > +static int jhb100_gpio_get(struct gpio_chip *gc, unsigned int gpio) {
> > + struct jhb100_gpio_bank *bank = jhb100_gc_to_bank(gc);
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + const struct jhb100_pinctrl_domain_info *info = sfp->info;
> > + unsigned int offset = 4 * bank->id;
> > + u32 doen = 0;
> > + void __iomem *reg_gpio_oen;
> > + void __iomem *reg;
> > + unsigned long flags;
> > +
> > + reg_gpio_oen = sfp->base + info->regs->output_en + offset;
> > + reg = sfp->base + info->regs->gpio_status + offset;
> > +
> > + raw_spin_lock_irqsave(&sfp->lock, flags);
> > + doen = readl_relaxed(reg_gpio_oen) | BIT(gpio);
> > + writel_relaxed(doen, reg_gpio_oen);
> > + raw_spin_unlock_irqrestore(&sfp->lock, flags);
>
> Why *on* *earth* are you read-modify-writing the output enable register in
> the *get* function? Is this a copy-on-paste error??
>
> > + return !!(readl_relaxed(reg) & BIT(gpio % 32));
>
> Also you never actuall read reg .... ehhhh this is a glaring bug.
>
> > +static int jhb100_gpio_set(struct gpio_chip *gc, unsigned int gpio,
> > +int value) {
> > + struct jhb100_gpio_bank *bank = jhb100_gc_to_bank(gc);
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + const struct jhb100_pinctrl_domain_info *info = sfp->info;
> > + unsigned int offset = 4 * bank->id;
> > + void __iomem *reg_dout;
> > + u32 dout;
> > + unsigned long flags;
> > +
> > + reg_dout = sfp->base + info->regs->output + offset;
> > + dout = (value ? GPOUT_HIGH : GPOUT_LOW) << gpio;
> > +
> > + raw_spin_lock_irqsave(&sfp->lock, flags);
> > + dout |= readl_relaxed(reg_dout) & ~BIT(gpio);
> > + writel_relaxed(dout, reg_dout);
> > + raw_spin_unlock_irqrestore(&sfp->lock, flags);
> > +
> > + return 0;
> > +}
>
> This looks right, did you only test output and not input..?
>
> > +static const struct irq_chip jhb100_irq_chip = {
> > + .irq_ack = jhb100_irq_ack,
> > + .irq_mask = jhb100_irq_mask,
> > + .irq_mask_ack = jhb100_irq_mask_ack,
> > + .irq_unmask = jhb100_irq_unmask,
> > + .irq_set_type = jhb100_irq_set_type,
> > + .irq_set_wake = jhb100_irq_set_wake,
> > + .irq_print_chip = jhb100_irq_print_chip,
> > + .flags = IRQCHIP_SET_TYPE_MASKED |
> > + IRQCHIP_IMMUTABLE |
> > + IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND
> |
> > + IRQCHIP_MASK_ON_SUSPEND |
> > + IRQCHIP_SKIP_SET_WAKE,
> > + GPIOCHIP_IRQ_RESOURCE_HELPERS, };
>
> The irqchip looks good!
>
> > +static int field_compare(const void *a, const void *b) {
> > + const struct field_info *fa = (const struct field_info *)a;
> > + const struct field_info *fb = (const struct field_info *)b;
> > +
> > + if (fa->shift < fb->shift)
> > + return -1;
> > +
> > + if (fa->shift > fb->shift)
> > + return 1;
> > +
> > + return 0;
> > +}
>
> Are you sure the kernel doesn't already have a helper like this...
>
> > + sfp->num_banks = DIV_ROUND_UP(sfp->ngpios,
> > + JHB100_NR_GPIOS_PER_BANK);
> > +
> > + for (unsigned int i = 0; i < sfp->num_banks; i++) {
> > + if (sfp->ngpios > (i + 1) *
> JHB100_NR_GPIOS_PER_BANK)
> > + sfp->banks[i].gc.ngpio = (i + 1) *
> JHB100_NR_GPIOS_PER_BANK;
> > + else
> > + sfp->banks[i].gc.ngpio = sfp->ngpios - i *
> > + JHB100_NR_GPIOS_PER_BANK;
>
> This looks completely bananas, shouldn't this be simply:
>
> sfp->banks[i].gc.ngpio = JHB100_NR_GPIOS_PER_BANK;
>
> ???
>
> What is getting assigned to ngpios looks like a gpiochip base, and have all the
> signs of a real bad AI hallucination.
>
> > +
> > + sfp->banks[i].id = i;
> > +
> > + sfp->banks[i].gc.parent = dev;
> > + sfp->banks[i].gc.label = dev_name(dev);
> > + sfp->banks[i].gc.owner = THIS_MODULE;
> > + sfp->banks[i].gc.request = pinctrl_gpio_request;
>
> Use
> gpiochip_generic_request
>
> > + sfp->banks[i].gc.free = pinctrl_gpio_free;
>
> Use
> gpiochip_generic_free
>
> These calls will do what you want, and also check that the right gpio ranges
> are available.
>
> Make sure you add GPIO ranges (the mapping between pin control pins and
> corresponding GPIO offsets) for this to work properly.
>
> I'm pretty sure you can have a generic pin config backend as well.
>
> sfp->banks[i].gc.set_config = gpiochip_generic_config;
>
> This will make config calls to the gpiochip call into the pinctrl backend = what
> you want.
>
> > + sfp->banks[i].gc.get_direction =
> jhb100_gpio_get_direction;
> > + sfp->banks[i].gc.direction_input =
> jhb100_gpio_direction_input;
> > + sfp->banks[i].gc.direction_output =
> jhb100_gpio_direction_output;
> > + sfp->banks[i].gc.get = jhb100_gpio_get;
> > + sfp->banks[i].gc.set = jhb100_gpio_set;
> > + sfp->banks[i].gc.set_config = gpiochip_generic_config;
> > + sfp->banks[i].gc.base = -1;
> > + sfp->banks[i].gc.of_gpio_n_cells = 3;
> > + sfp->banks[i].gc.of_node_instance_match =
> > + starfive_of_node_instance_match;
>
> Since you have a threecell scheme with 32 gpios
> (JHB100_NR_GPIOS_PER_BANK) per instance (right? the ngpios code above
> made me really confused....) you should be able so select GPIO_GENERIC,
> #include <linux/gpio/generic.h> and use the generic GPIO pretty much the
> same way drivers/gpio/gpio-spacemit-k1.c does it, check that driver out
> (especially spacemit_gpio_add_bank()).
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/5] Shikra: Add DT support for ice, rng and qce
From: Kuldeep Singh @ 2026-06-19 8:43 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Andy Gross, Eric Biggers
Cc: Harshal Dev, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, dmaengine
In-Reply-To: <20260521-shikra_crypto_changse-v1-0-0154cc9cc0de@oss.qualcomm.com>
On 21-05-2026 18:47, Kuldeep Singh wrote:
> This patchseries attempt to enable sdhc-ice, rng and qce on shikra
> platform similar to other platforms.
>
> Previously, the 3 dt-bindigs/DT changes were sent as individual series
> and with feedback received, clubbed them together as all belong to same
> crypto subsystem.
>
> Here's link to old patchsets.
> QCE: https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-0-80f07b345c29@oss.qualcomm.com/
Hi Eric,
As selftests issues for QCE are now fixed[1], so shikra series should be
good to proceed? as your concerns[2] are now addressed.
I am waiting for merge window to end and will send next rev post that.
[1]
https://lore.kernel.org/linux-arm-msm/20260617-qce-fix-self-tests-v3-0-ecc2b4dedcfd@oss.qualcomm.com/
[2] https://lore.kernel.org/lkml/20260522024912.GC5937@quark/
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v6 4/4] arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec support
From: sashiko-bot @ 2026-06-19 9:00 UTC (permalink / raw)
To: John Madieu; +Cc: devicetree, wsa+renesas, robh, conor+dt
In-Reply-To: <20260619083951.3777556-5-john.madieu.xa@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `&i2c1` node is missing `status = "okay";`, meaning the I2C controller and the DA7212 audio codec will not be probed.
- [Low] The patch references undefined device tree labels `audio_clkb` and `audio_clkc`, which will result in a fatal `dtc` compilation error.
--
commit e73e5f92dd2a1aa13133b29d66da034cb803fffc
Author: John Madieu <john.madieu.xa@bp.renesas.com>
arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec support
This commit adds support for the DA7212 audio codec on the RZ/G3E SMARC2 EVK
board. It enables the audio graph card and configures the codec on the I2C1 bus.
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts b/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
> index 6372f582a7c41..ac525b73c1bb1 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
[ ... ]
> + sound_card: sound {
> + compatible = "audio-graph-card";
> +
> + label = "snd-rzg3e";
> +
> + dais = <&rsnd_port0>; /* DA7212 */
> + };
> +};
> +
> +&audio_clkb {
> + clock-frequency = <11289600>;
> +};
> +
> +&audio_clkc {
> + clock-frequency = <12288000>;
> };
[Severity: Low]
Are the audio_clkb and audio_clkc labels defined in the included dtsi files?
It looks like dtc might fail with a compilation error if they are not.
[ ... ]
> &i2c0 {
> pinctrl-names = "default";
> };
>
> +&i2c1 {
> + da7212: codec@1a {
> + compatible = "dlg,da7212";
[Severity: Medium]
Does this node need a status = "okay"; property?
If the I2C controller is disabled by default in the SoC base device tree, it
looks like it will remain disabled and the codec will not be probed.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619083951.3777556-1-john.madieu.xa@bp.renesas.com?part=4
^ permalink raw reply
* [PATCH v2 0/3] phy: rockchip: inno-csidphy: fix 2500 Mbps support and add clock lane phase tuning
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
This series fixes and extends the Rockchip Innosilicon CSI D-PHY driver
to support data rates up to 2500 Mbps and adds optional board-specific
clock lane phase tuning for signal integrity.
Patch 1 fixes an off-by-one error in the rk1808 hsfreq range table:
the final entry was capped at 2499 Mbps, causing a rejection of the
maximum supported rate of 2500 Mbps.
Patches 2 and 3 add an optional rockchip,clk-lane-phase device tree
property that allows tuning the clock lane sampling phase in ~40 ps
steps to compensate for board-level signal integrity variations.
---
Changes in v2:
- dt-bindings: improve rockchip,clk-lane-phase description wording
(Conor Dooley)
- Link to v1: https://patch.msgid.link/20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net
To: Vinod Koul <vkoul@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Heiko Stuebner <heiko@sntech.de>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-phy@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Gerald Loacker (3):
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
.../bindings/phy/rockchip-inno-csi-dphy.yaml | 9 ++++++++
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 27 +++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260617-feature-mipi-csi-dphy-4k60-9879c3d1fe4f
Best regards,
--
Gerald Loacker <gerald.loacker@wolfvision.net>
^ permalink raw reply
* [PATCH v2 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of
exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this
rate.
This is essential for RK3588 reusing this array and fully supporting
rates up to 2500 Mbps.
Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy")
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index c79fb53d8ee5c..5281f8dea0ad3 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
{ 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
{ 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
{1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
- {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
+ {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
};
static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
Add support for the optional rockchip,clk-lane-phase device tree property
to allow board-specific tuning of the clock lane sampling phase for
improved signal integrity across supported data rates.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
.../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
index 03950b3cad08c..010950a8a8856 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
@@ -56,6 +56,15 @@ properties:
description:
Some additional phy settings are access through GRF regs.
+ rockchip,clk-lane-phase:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ description:
+ Clock lane sampling phase selection (hardware tap index 0–7). Each step
+ corresponds to an approximately 40 ps delay as described in the hardware
+ specification.
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
At high data rates like 4K60 (2500 Mbps), such as when using an
LT6911GXD bridge chip on an RK3588 board, fixed default timing parameters
can cause signal integrity issues and clock-data recovery failures.
The driver currently lacks a mechanism to adjust the clock lane sampling
phase to compensate for board-specific trace variations.
Resolve this by parsing and applying the optional 'rockchip,clk-lane-phase'
device tree property. This enables board-specific tuning of the clock
lane sampling phase in ~40 ps steps (range 0-7) to optimize link
stability. If the property is absent, the driver falls back to the
hardware default.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 25 ++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index 5281f8dea0ad3..3a15840e86cad 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -69,6 +69,10 @@
#define RK1808_CSIDPHY_CLK_CALIB_EN 0x168
#define RK3568_CSIDPHY_CLK_CALIB_EN 0x168
+#define CSIDPHY_LANE_CLK_3_PHASE 0x38
+#define CSIDPHY_CLK_PHASE_MASK GENMASK(6, 4)
+#define CSIDPHY_CLK_PHASE_DEFAULT 3
+
#define RESETS_MAX 2
/*
@@ -151,6 +155,7 @@ struct rockchip_inno_csidphy {
const struct dphy_drv_data *drv_data;
struct phy_configure_opts_mipi_dphy config;
u8 hsfreq;
+ int clk_phase;
};
static inline void write_grf_reg(struct rockchip_inno_csidphy *priv,
@@ -304,6 +309,13 @@ static int rockchip_inno_csidphy_power_on(struct phy *phy)
rockchip_inno_csidphy_ths_settle(priv, priv->hsfreq,
CSIDPHY_LANE_THS_SETTLE(i));
+ if (priv->clk_phase >= 0) {
+ val = readl(priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ val &= ~CSIDPHY_CLK_PHASE_MASK;
+ val |= FIELD_PREP(CSIDPHY_CLK_PHASE_MASK, priv->clk_phase);
+ writel(val, priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ }
+
write_grf_reg(priv, GRF_DPHY_CSIPHY_CLKLANE_EN, 0x1);
write_grf_reg(priv, GRF_DPHY_CSIPHY_DATALANE_EN,
GENMASK(priv->config.lanes - 1, 0));
@@ -449,6 +461,7 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct phy_provider *phy_provider;
struct phy *phy;
+ u32 phase;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -464,6 +477,18 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
return -ENODEV;
}
+ priv->clk_phase = -1;
+ if (device_property_read_u32(dev, "rockchip,clk-lane-phase",
+ &phase) == 0) {
+ if (phase >= BIT(3)) {
+ dev_err(dev,
+ "rockchip,clk-lane-phase %u out of range [0,7]\n",
+ phase);
+ return -EINVAL;
+ }
+ priv->clk_phase = phase;
+ }
+
priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node,
"rockchip,grf");
if (IS_ERR(priv->grf)) {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 06/16] iio: core: create local __iio_chan_prefix_emit() for reuse
From: Nuno Sá @ 2026-06-19 9:16 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, David Lechner, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <x3aijvc4buo7aqbchikuoyyrgiq3afidtkla37h2rg4tvfdbc3@h42qp3estg2s>
On Thu, Jun 18, 2026 at 05:14:19PM +0100, Rodrigo Alencar wrote:
> On 18/06/26 16:06, Nuno Sá wrote:
> > On Thu, Jun 18, 2026 at 02:27:22PM +0100, Rodrigo Alencar via B4 Relay wrote:
> > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > >
> > > Move logic to create a channel prefix for naming attribute files into a
> > > separate __iio_chan_prefix_emit() function for reuse.
>
> ...
>
> > > +static int __iio_chan_prefix_emit(const struct iio_chan_spec *chan,
> > > + enum iio_shared_by shared_by,
> > > + char *buf, size_t len)
> > > +{
> > > + const char *dir = iio_direction[chan->output];
> > > + const char *type = iio_chan_type_name_spec[chan->type];
> > > + int n = 0;
> > > +
> > > + switch (shared_by) {
> > > + case IIO_SHARED_BY_ALL:
> > > + buf[0] = '\0'; /* empty channel prefix */
> > > + break;
> > > + case IIO_SHARED_BY_DIR:
> > > + n = scnprintf(buf, len, "%s", dir);
> > > + break;
> > > + case IIO_SHARED_BY_TYPE:
> > > + n = scnprintf(buf, len, "%s_%s", dir, type);
> > > + if (chan->differential)
> > > + n += scnprintf(buf + n, len - n, "-%s", type);
> > > + break;
> > > + case IIO_SEPARATE:
> > > + if (chan->indexed) {
> > > + n = scnprintf(buf, len, "%s_%s%d", dir, type,
> > > + chan->channel);
> > > + if (chan->differential)
> > > + n += scnprintf(buf + n, len - n, "-%s%d", type,
> > > + chan->channel2);
> > > + } else {
> > > + if (chan->differential) {
> > > + WARN(1, "Differential channels must be indexed\n");
> > > + return -EINVAL;
> > > + }
> > > + n = scnprintf(buf, len, "%s_%s", dir, type);
> > > + }
> > > +
> > > + if (chan->modified) {
> > > + if (chan->differential) {
> > > + WARN(1, "Differential channels can not have modifier\n");
> > > + return -EINVAL;
> >
> > WARN() looks too much to me. dev_error() as we're treating it as such. I
> > guess you don't want to pass struct device but not really an issue IMHO.
>
> __iio_device_attr_init() also used WARN(), probably because it didnt have
> access to a dev pointer. It would not be a problem to add an extra param.
Hmm, fair enough. Maybe a chance to change it. Not sure how others feel
about it.
>
> >
> > > + }
> > > + n += scnprintf(buf + n, len - n, "_%s",
> > > + iio_modifier_names[chan->channel2]);
> > > + }
> > > +
> > > + if (chan->extend_name)
> > > + n += scnprintf(buf + n, len - n, "_%s", chan->extend_name);
> > > + break;
> > > + }
> > > +
> > > + if (n > 0 && n < len - 1) { /* prefix termination if not empty */
> > > + buf[n++] = '_';
> > > + buf[n] = '\0';
> > > + }
> > > +
> >
> > Can't we handle the above in the caller on kasprintf()? Then we could
> > simplify and return in place.
>
> I felt like doing this here would get a cleaner logic in the caller, which
> would have to add the '_' conditionally.
>
I think it makes things more clear in the caller given we return n
anyways but I don't feel strong about it.
- Nuno Sá
> >
> > > + return n;
> > > +}
> > > +
> > > /**
> > > * iio_device_id() - query the unique ID for the device
> > > * @indio_dev: Device structure whose ID is being queried
> > > @@ -1100,106 +1159,19 @@ int __iio_device_attr_init(struct device_attribute *dev_attr,
> > > size_t len),
> > > enum iio_shared_by shared_by)
> > > {
> > > - int ret = 0;
> > > - char *name = NULL;
> > > - char *full_postfix;
> > > + char prefix[NAME_MAX + 1];
> > > + int ret;
> > >
> > > sysfs_attr_init(&dev_attr->attr);
> > >
> > > - /* Build up postfix of <extend_name>_<modifier>_postfix */
> > > - if (chan->modified && (shared_by == IIO_SEPARATE)) {
> > > - if (chan->extend_name)
> > > - full_postfix = kasprintf(GFP_KERNEL, "%s_%s_%s",
> > > - iio_modifier_names[chan->channel2],
> > > - chan->extend_name,
> > > - postfix);
> > > - else
> > > - full_postfix = kasprintf(GFP_KERNEL, "%s_%s",
> > > - iio_modifier_names[chan->channel2],
> > > - postfix);
> > > - } else {
> > > - if (chan->extend_name == NULL || shared_by != IIO_SEPARATE)
> > > - full_postfix = kstrdup(postfix, GFP_KERNEL);
> > > - else
> > > - full_postfix = kasprintf(GFP_KERNEL,
> > > - "%s_%s",
> > > - chan->extend_name,
> > > - postfix);
> > > - }
> > > - if (full_postfix == NULL)
> > > + ret = __iio_chan_prefix_emit(chan, shared_by, prefix, sizeof(prefix));
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, postfix);
> > > + if (!dev_attr->attr.name)
> > > return -ENOMEM;
> >
> > I don't oppose the change. Looks like a nice cleanup. But bear in mind
> > this very sensible as any subtle mistake means ABI breakage.
>
> Yes! I tried to be careful... this is dangerous stuff!
>
> --
> Kind regards,
>
> Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v6 06/16] iio: core: create local __iio_chan_prefix_emit() for reuse
From: Nuno Sá @ 2026-06-19 9:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rodrigo Alencar, rodrigo.alencar, linux-iio, devicetree,
linux-kernel, linux-doc, linux-hardening, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <ajQ1bZSNHQ96pyJx@ashevche-desk.local>
On Thu, Jun 18, 2026 at 09:14:05PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 18, 2026 at 05:14:19PM +0100, Rodrigo Alencar wrote:
> > On 18/06/26 16:06, Nuno Sá wrote:
> > > On Thu, Jun 18, 2026 at 02:27:22PM +0100, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > > + dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, postfix);
> > > > + if (!dev_attr->attr.name)
> > > > return -ENOMEM;
> > >
> > > I don't oppose the change. Looks like a nice cleanup.
>
> May I oppose it? I found use scnprintf() is harder to follow in comparison to
> nice kasprintf() that takes care for the dynamically allocated buffer.
Tend to agree a bit given I was used to the older code. So matching the
old logic with the new one is an exercise, yes.
>
> Also there is a chance to get a name silently cut due to insufficient space.
> Besides that this function can't be used (again due to 'c') in kasprintf()-like
> wrapper. I do not consider this as a good approach. Have you looked at seq_buf
> instead?
Not so sure the above bothers me that much.
>
> > > But bear in mind this very sensible as any subtle mistake means ABI breakage.
>
> Which immediately raises a question of test coverage. Do we have one? If not,
> this code must be accompanied with one.
The above is the more concerning part to me.
- Nuno Sá
>
> > Yes! I tried to be careful... this is dangerous stuff!
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v6 06/16] iio: core: create local __iio_chan_prefix_emit() for reuse
From: Nuno Sá @ 2026-06-19 9:20 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Andy Shevchenko, rodrigo.alencar, linux-iio, devicetree,
linux-kernel, linux-doc, linux-hardening, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <dlisetsssjoyodmv5ubl4rzhxtla3g46mrrzv2f65nqecel5fu@dqiqsayr4aip>
On Fri, Jun 19, 2026 at 08:43:24AM +0100, Rodrigo Alencar wrote:
> On 18/06/26 21:14, Andy Shevchenko wrote:
> > On Thu, Jun 18, 2026 at 05:14:19PM +0100, Rodrigo Alencar wrote:
> > > On 18/06/26 16:06, Nuno Sá wrote:
> > > > On Thu, Jun 18, 2026 at 02:27:22PM +0100, Rodrigo Alencar via B4 Relay wrote:
> >
> > ...
> >
> > > > > + dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, postfix);
> > > > > + if (!dev_attr->attr.name)
> > > > > return -ENOMEM;
> > > >
> > > > I don't oppose the change. Looks like a nice cleanup.
> >
> > May I oppose it? I found use scnprintf() is harder to follow in comparison to
> > nice kasprintf() that takes care for the dynamically allocated buffer.
>
> In the next patch the function is reused in a sysfs attribute read handler,
> a context wich would not be nice to have dynamic allocation. vscnprintf() is
> the main building block of sysfs_emit() which limits the buffer length to
> a page size, so I used scnprintf() trying not to deviate much from that.
>
> kasprintf() it is still used in the caller, where the logic was a bit confusing
> as it tried to avoid multiple allocations.
>
> > Also there is a chance to get a name silently cut due to insufficient space.
> > Besides that this function can't be used (again due to 'c') in kasprintf()-like
> > wrapper. I do not consider this as a good approach. Have you looked at seq_buf
> > instead?
>
> NAME_MAX is not the maximum length a filename can have? I suppose there should be
> enough space for the channel-prefix. Indeed, seq_buf can be used and it cleans up
> things a bit as it tracks the the position in the buffer.
>
> >
> > > > But bear in mind this very sensible as any subtle mistake means ABI breakage.
> >
> > Which immediately raises a question of test coverage. Do we have one? If not,
> > this code must be accompanied with one.
>
> Agreed. Will see to have tests for v7.
libiio now has an emulator backend. Maybe something that can be used to
test this. But ideally we can have some kunit for validation.
- Nuno Sá
>
> > > Yes! I tried to be careful... this is dangerous stuff!
>
> --
> Kind regards,
>
> Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v2 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: sashiko-bot @ 2026-06-19 9:23 UTC (permalink / raw)
To: Gerald Loacker
Cc: olteanv, vkoul, conor+dt, linux-phy, robh, devicetree,
neil.armstrong
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-1-323356c2cc2e@wolfvision.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Valid lowest frequency ranges are incorrectly rejected because `hsfreq == 0x00` is treated as an error by the `if (!hsfreq)` check.
--
commit d7a2518a95d2ab7b8f2baea0da9f35646ffb6136
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
The rk1808 hsfreq table previously capped at 2499 Mbps, preventing a data rate
of exactly 2500 Mbps. This commit extends the final entry to 2500 Mbps to
fully support this rate, which is also essential for RK3588 as it reuses
this array.
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> index c79fb53d8ee5c..5281f8dea0ad3 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> @@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
> { 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
> { 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
> {1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
> - {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
> + {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
> };
>
> static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {
[Severity: High]
This isn't a bug introduced by this patch, but does the configuration logic
reject valid low frequency ranges?
Looking at rk3326_mipidphy_hsfreq_ranges[], the first entry configures low
data rates using 0x00:
{ 109, 0x00 }, ...
In rockchip_inno_csidphy_configure(), hsfreq is initialized to 0 and validated
with:
for (i = 0; i < drv_data->num_hsfreq_ranges; i++) {
if (drv_data->hsfreq_ranges[i].range_h >= data_rate_mbps) {
hsfreq = drv_data->hsfreq_ranges[i].cfg_bit;
break;
}
}
if (!hsfreq)
return -EINVAL;
When a low data rate is requested (e.g., <= 109 Mbps for rk3326), the loop
correctly assigns hsfreq = 0x00. However, the subsequent if (!hsfreq) check
treats this valid configuration as an error state and returns -EINVAL.
This same pattern appears in drivers/phy/rockchip/phy-rockchip-dphy-rx0.c
during rk_dphy_configure() where low-speed configurations are similarly
rejected.
Could the validation check be updated to differentiate between an uninitialized
value and a valid 0x00 configuration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net?part=1
^ permalink raw reply
* Re: [PATCH v2 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: sashiko-bot @ 2026-06-19 9:26 UTC (permalink / raw)
To: Gerald Loacker
Cc: neil.armstrong, vkoul, robh, devicetree, olteanv, linux-phy,
conor+dt
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-3-323356c2cc2e@wolfvision.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The macro `CSIDPHY_CLK_PHASE_DEFAULT` is defined but never used.
--
commit 47571c2082c0165537db96312865f3a9805e768d
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
This commit adds support for parsing the 'rockchip,clk-lane-phase' device
tree property to adjust the clock lane sampling phase. It enables
board-specific tuning to optimize link stability at high data rates, falling
back to hardware defaults if the property is absent.
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> index 5281f8dea0ad3..3a15840e86cad 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
> @@ -69,6 +69,10 @@
> #define RK1808_CSIDPHY_CLK_CALIB_EN 0x168
> #define RK3568_CSIDPHY_CLK_CALIB_EN 0x168
>
> +#define CSIDPHY_LANE_CLK_3_PHASE 0x38
> +#define CSIDPHY_CLK_PHASE_MASK GENMASK(6, 4)
> +#define CSIDPHY_CLK_PHASE_DEFAULT 3
[Severity: Low]
Is this macro intended to be used somewhere?
It appears to be defined but never used, since the driver falls back to the
hardware default by initializing priv->clk_phase to -1 in
rockchip_inno_csidphy_probe() and conditionally skipping the register write in
rockchip_inno_csidphy_power_on():
if (priv->clk_phase >= 0) {
val = readl(priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
...
}
Can CSIDPHY_CLK_PHASE_DEFAULT be safely removed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net?part=3
^ permalink raw reply
* [PATCH 0/5] hwmon: add Altera Stratix 10 SoC FPGA hardware monitor support
From: tze.yee.ng @ 2026-06-19 9:38 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
From: Tze Yee Ng <tze.yee.ng@altera.com>
This series adds hardware monitor support for Altera Stratix 10 SoC FPGA
devices. Temperature and voltage sensors are accessed through the
Stratix 10 service layer and Secure Device Manager.
Patch 1 adds the device tree binding for the hwmon node and sensor layout.
Patch 2 extends the Stratix 10 service layer binding with an optional
hwmon child node. Patch 3 adds async HWMON read commands to the service
firmware driver. Patch 4 adds the hwmon driver, using the async service
interface when available and falling back to synchronous reads otherwise.
Patch 5 enables the hwmon node on the Stratix 10 SoCDK.
Tze Yee Ng (5):
dt-bindings: hwmon: add Altera Stratix 10 hardware monitor binding
dt-bindings: firmware: svc: add hwmon property
firmware: stratix10-svc: add async HWMON read commands
hwmon: add Stratix 10 SoC FPGA hardware monitor driver
arm64: dts: socfpga: stratix10: add hwmon node
.../firmware/intel,stratix10-svc.yaml | 4 +
.../bindings/hwmon/altr,stratix10-hwmon.yaml | 164 +++++
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/stratix10-hwmon.rst | 31 +
MAINTAINERS | 9 +
.../boot/dts/altera/socfpga_stratix10.dtsi | 5 +
.../dts/altera/socfpga_stratix10_socdk.dts | 33 +
drivers/firmware/stratix10-svc.c | 12 +
drivers/hwmon/Kconfig | 10 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/stratix10-hwmon.c | 575 ++++++++++++++++++
include/linux/firmware/intel/stratix10-smc.h | 38 ++
12 files changed, 883 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
create mode 100644 Documentation/hwmon/stratix10-hwmon.rst
create mode 100644 drivers/hwmon/stratix10-hwmon.c
--
2.43.7
^ permalink raw reply
* [PATCH 1/5] dt-bindings: hwmon: add Altera Stratix 10 hardware monitor binding
From: tze.yee.ng @ 2026-06-19 9:38 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <cover.1781861409.git.tze.yee.ng@altera.com>
From: Tze Yee Ng <tze.yee.ng@altera.com>
Document the device tree binding for the Altera Stratix 10 SoC FPGA
hardware monitor, including temperature and voltage sensor nodes.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
---
.../bindings/hwmon/altr,stratix10-hwmon.yaml | 164 ++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 171 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
new file mode 100644
index 000000000000..5bd98660ee7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
@@ -0,0 +1,164 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/altr,stratix10-hwmon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera Hardware Monitor for Stratix 10 SoC FPGA
+
+maintainers:
+ - Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
+ - Tze Yee Ng <tze.yee.ng@altera.com>
+
+description: |
+ The Altera Stratix 10 SoC FPGA hardware monitor unit provides on-chip
+ voltage and temperature sensors. These sensors can be used to monitor
+ external voltages and on-chip operating conditions such as internal
+ power rails and on-chip junction temperatures.
+
+ The specific sensor configuration varies by device. Check the device
+ documentation to verify which sensors are available.
+
+ Stratix 10 voltage sensors:
+
+ page 0, channel 2 = 0.8V VCC
+ page 0, channel 3 = 1.8V VCCIO_SDM
+ page 0, channel 6 = 0.9V VCCERAM
+
+ Stratix 10 temperature sensors:
+
+ page 0, channel 0 = main die
+ page 0, channel 1 = tile bottom left
+ page 0, channel 2 = tile middle left
+ page 0, channel 3 = tile top left
+ page 0, channel 4 = tile bottom right
+ page 0, channel 5 = tile middle right
+ page 0, channel 6 = tile top right
+ page 0, channel 7 = hbm2 bottom
+ page 0, channel 8 = hbm2 top
+
+properties:
+ compatible:
+ const: altr,stratix10-hwmon
+
+ temperature:
+ description:
+ The temperature node specifies mappings of temperature sensor diodes on
+ the Stratix 10 SoC FPGA main die and tile die.
+ type: object
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+ patternProperties:
+ "^input(@[0-9a-f]+)?$":
+ description:
+ The input node specifies each individual temperature sensor.
+ type: object
+ properties:
+ reg:
+ description:
+ Sensor channel index in the lower 16-bits (0-15). For temperature
+ sensors, the page number is encoded in the upper 16-bits.
+ The driver encodes the SMC request argument as a channel
+ bitmask (1 << channel) in bits 0..15, with the page number
+ placed in bits 16..31. Channel values >= 16 are rejected to
+ avoid overlap with the page field. For example, reg = <2>
+ selects channel 2 and the driver passes 0x4 to the service layer.
+ label:
+ description:
+ A descriptive name for this channel (e.g. "Main Die" or
+ "Tile Bottom Left").
+ required:
+ - reg
+ additionalProperties: false
+ required:
+ - '#address-cells'
+ - '#size-cells'
+ additionalProperties: false
+
+ voltage:
+ description:
+ The voltage node specifies mappings of voltage sensors on the Stratix 10
+ SoC FPGA analog to digital converter of the Secure Device Manager (SDM).
+ type: object
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+ patternProperties:
+ "^input(@[0-9a-f]+)?$":
+ description:
+ The input node specifies each individual voltage sensor.
+ type: object
+ properties:
+ reg:
+ description:
+ Sensor channel index in the lower 16-bits (0-15). The driver
+ encodes the SMC request argument as a channel bitmask
+ (1 << channel). For example, reg = <2> selects channel 2 and
+ the driver passes 0x4 to the service layer.
+ label:
+ description:
+ A descriptive name for this channel (e.g. "0.8V VCC" or
+ "1.8V VCCIO_SDM").
+ required:
+ - reg
+ additionalProperties: false
+ required:
+ - '#address-cells'
+ - '#size-cells'
+ additionalProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ hwmon {
+ compatible = "altr,stratix10-hwmon";
+
+ voltage {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ input@2 {
+ label = "0.8V VCC";
+ reg = <2>;
+ };
+
+ input@3 {
+ label = "1.8V VCCIO_SDM";
+ reg = <3>;
+ };
+
+ input@6 {
+ label = "0.9V VCCERAM";
+ reg = <6>;
+ };
+ };
+
+ temperature {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ input@0 {
+ label = "Main Die";
+ reg = <0>;
+ };
+
+ input@1 {
+ label = "Tile Bottom Left";
+ reg = <1>;
+ };
+
+ input@2 {
+ label = "Tile Middle Left";
+ reg = <2>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 6aa3fe2ee1bb..678f6c429627 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -937,6 +937,13 @@ ALPS PS/2 TOUCHPAD DRIVER
R: Pali Rohár <pali@kernel.org>
F: drivers/input/mouse/alps.*
+ALTERA STRATIX 10 SoC FPGA HWMON DRIVER
+M: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
+M: Tze Yee Ng <tze.yee.ng@altera.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
+
ALTERA MAILBOX DRIVER
M: Tien Sung Ang <tiensung.ang@altera.com>
S: Maintained
--
2.43.7
^ permalink raw reply related
* [PATCH 2/5] dt-bindings: firmware: svc: add hwmon property
From: tze.yee.ng @ 2026-06-19 9:38 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <cover.1781861409.git.tze.yee.ng@altera.com>
From: Tze Yee Ng <tze.yee.ng@altera.com>
Altera Stratix 10 SoCFPGA supports hardware monitor access through the
service layer mailbox. Add an optional hwmon child node to the service
layer binding so device trees can describe the hardware monitor.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
---
.../devicetree/bindings/firmware/intel,stratix10-svc.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
index b42cfa78b28b..86ffdb10132f 100644
--- a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
+++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
@@ -62,6 +62,10 @@ properties:
$ref: /schemas/fpga/intel,stratix10-soc-fpga-mgr.yaml
description: Optional child node for fpga manager to perform fabric configuration.
+ hwmon:
+ $ref: /schemas/hwmon/altr,stratix10-hwmon.yaml
+ description: Optional child node for Stratix 10 hardware monitor.
+
required:
- compatible
- method
--
2.43.7
^ permalink raw reply related
* [PATCH 3/5] firmware: stratix10-svc: add async HWMON read commands
From: tze.yee.ng @ 2026-06-19 9:38 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <cover.1781861409.git.tze.yee.ng@altera.com>
From: Tze Yee Ng <tze.yee.ng@altera.com>
Add asynchronous Stratix 10 service layer support for hardware monitor
temperature and voltage read commands in stratix10_svc_async_send() and
stratix10_svc_async_prepare_response().
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
---
drivers/firmware/stratix10-svc.c | 12 +++++++
include/linux/firmware/intel/stratix10-smc.h | 38 ++++++++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/drivers/firmware/stratix10-svc.c b/drivers/firmware/stratix10-svc.c
index e9e35d67ef96..2cfdac31402c 100644
--- a/drivers/firmware/stratix10-svc.c
+++ b/drivers/firmware/stratix10-svc.c
@@ -1311,6 +1311,14 @@ int stratix10_svc_async_send(struct stratix10_svc_chan *chan, void *msg,
args.a0 = INTEL_SIP_SMC_ASYNC_RSU_NOTIFY;
args.a2 = p_msg->arg[0];
break;
+ case COMMAND_HWMON_READTEMP:
+ args.a0 = INTEL_SIP_SMC_ASYNC_HWMON_READTEMP;
+ args.a2 = p_msg->arg[0];
+ break;
+ case COMMAND_HWMON_READVOLT:
+ args.a0 = INTEL_SIP_SMC_ASYNC_HWMON_READVOLT;
+ args.a2 = p_msg->arg[0];
+ break;
default:
dev_err(ctrl->dev, "Invalid command ,%d\n", p_msg->command);
ret = -EINVAL;
@@ -1404,6 +1412,10 @@ static int stratix10_svc_async_prepare_response(struct stratix10_svc_chan *chan,
*/
data->kaddr1 = (void *)&handle->res;
break;
+ case COMMAND_HWMON_READTEMP:
+ case COMMAND_HWMON_READVOLT:
+ data->kaddr1 = (void *)&handle->res.a2;
+ break;
default:
dev_alert(ctrl->dev, "Invalid command\n ,%d", p_msg->command);
diff --git a/include/linux/firmware/intel/stratix10-smc.h b/include/linux/firmware/intel/stratix10-smc.h
index 935dba3633b5..4eb3a6e9659d 100644
--- a/include/linux/firmware/intel/stratix10-smc.h
+++ b/include/linux/firmware/intel/stratix10-smc.h
@@ -680,6 +680,44 @@ INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_COMPLETED_WRITE)
#define INTEL_SIP_SMC_ASYNC_POLL \
INTEL_SIP_SMC_ASYNC_VAL(INTEL_SIP_SMC_ASYNC_FUNC_ID_POLL)
+/**
+ * Request INTEL_SIP_SMC_ASYNC_HWMON_READTEMP
+ * Async call to request temperature
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_ASYNC_HWMON_READTEMP
+ * a1 transaction job id
+ * a2 Temperature Channel
+ * a3-a17 not used
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_STATUS_REJECTED
+ * or INTEL_SIP_SMC_STATUS_BUSY
+ * a1-a17 not used
+ */
+#define INTEL_SIP_SMC_ASYNC_FUNC_ID_HWMON_READTEMP 0xE8
+#define INTEL_SIP_SMC_ASYNC_HWMON_READTEMP \
+ INTEL_SIP_SMC_ASYNC_VAL(INTEL_SIP_SMC_ASYNC_FUNC_ID_HWMON_READTEMP)
+
+/**
+ * Request INTEL_SIP_SMC_ASYNC_HWMON_READVOLT
+ * Async call to request voltage
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_ASYNC_HWMON_READVOLT
+ * a1 transaction job id
+ * a2 Voltage Channel
+ * a3-a17 not used
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_STATUS_REJECTED
+ * or INTEL_SIP_SMC_STATUS_BUSY
+ * a1-a17 not used
+ */
+#define INTEL_SIP_SMC_ASYNC_FUNC_ID_HWMON_READVOLT 0xE9
+#define INTEL_SIP_SMC_ASYNC_HWMON_READVOLT \
+ INTEL_SIP_SMC_ASYNC_VAL(INTEL_SIP_SMC_ASYNC_FUNC_ID_HWMON_READVOLT)
+
/**
* Request INTEL_SIP_SMC_ASYNC_RSU_GET_SPT
* Async call to get RSU SPT from SDM.
--
2.43.7
^ permalink raw reply related
* [PATCH 4/5] hwmon: add Stratix 10 SoC FPGA hardware monitor driver
From: tze.yee.ng @ 2026-06-19 9:38 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <cover.1781861409.git.tze.yee.ng@altera.com>
From: Tze Yee Ng <tze.yee.ng@altera.com>
Add a hardware monitoring driver for Altera Stratix 10 SoC FPGA devices
that reads temperature and voltage sensors through the Stratix 10 service
layer. Use the asynchronous service layer interface when available, with
a synchronous fallback.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/stratix10-hwmon.rst | 31 ++
MAINTAINERS | 2 +
drivers/hwmon/Kconfig | 10 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/stratix10-hwmon.c | 575 ++++++++++++++++++++++++
6 files changed, 620 insertions(+)
create mode 100644 Documentation/hwmon/stratix10-hwmon.rst
create mode 100644 drivers/hwmon/stratix10-hwmon.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 8b655e5d6b68..30f533301903 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -244,6 +244,7 @@ Hardware Monitoring Kernel Drivers
sparx5-temp
spd5118
stpddc60
+ stratix10-hwmon
surface_fan
sy7636a-hwmon
tc654
diff --git a/Documentation/hwmon/stratix10-hwmon.rst b/Documentation/hwmon/stratix10-hwmon.rst
new file mode 100644
index 000000000000..61b682fe177a
--- /dev/null
+++ b/Documentation/hwmon/stratix10-hwmon.rst
@@ -0,0 +1,31 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver stratix10-hwmon
+=============================
+
+Supported chips:
+
+ * Altera Stratix 10 SoC FPGA
+
+Authors:
+ - Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
+ - Tze Yee Ng <tze.yee.ng@altera.com>
+
+Description
+-----------
+
+This driver supports hardware monitoring for Altera Stratix 10 SoC FPGA
+devices through the Secure Device Manager and Stratix 10 service layer.
+
+The following sensor types are supported:
+
+ * temperature
+ * voltage
+
+Usage Notes
+-----------
+
+The driver relies on a device tree node to enumerate sensors present on the
+specific device. See
+Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml for details
+of the device-tree node.
diff --git a/MAINTAINERS b/MAINTAINERS
index 678f6c429627..5afdf286f8f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -943,6 +943,8 @@ M: Tze Yee Ng <tze.yee.ng@altera.com>
L: linux-hwmon@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
+F: Documentation/hwmon/stratix10-hwmon.rst
+F: drivers/hwmon/stratix10-hwmon.c
ALTERA MAILBOX DRIVER
M: Tien Sung Ang <tiensung.ang@altera.com>
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 14e4cea48acc..8eff1c71a226 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2112,6 +2112,16 @@ config SENSORS_SMSC47M192
This driver can also be built as a module. If so, the module
will be called smsc47m192.
+config SENSORS_ALTERA_SOCFPGA_STRATIX10
+ tristate "Altera SoC FPGA Stratix 10 hardware monitoring features"
+ depends on INTEL_STRATIX10_SERVICE
+ help
+ If you say yes here you get support for the temperature and
+ voltage sensors of Altera SoC FPGA Stratix 10 devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called stratix10-hwmon.
+
config SENSORS_SMSC47B397
tristate "SMSC LPC47B397-NC"
depends on HAS_IOPORT
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 982ee2c6f9de..7e643de0e7d4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -217,6 +217,7 @@ obj-$(CONFIG_SENSORS_SMPRO) += smpro-hwmon.o
obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o
obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o
obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o
+obj-$(CONFIG_SENSORS_ALTERA_SOCFPGA_STRATIX10) += stratix10-hwmon.o
obj-$(CONFIG_SENSORS_SPARX5) += sparx5-temp.o
obj-$(CONFIG_SENSORS_SPD5118) += spd5118.o
obj-$(CONFIG_SENSORS_STTS751) += stts751.o
diff --git a/drivers/hwmon/stratix10-hwmon.c b/drivers/hwmon/stratix10-hwmon.c
new file mode 100644
index 000000000000..7ed1116e57b8
--- /dev/null
+++ b/drivers/hwmon/stratix10-hwmon.c
@@ -0,0 +1,575 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Altera Stratix 10 SoC FPGA hardware monitoring driver
+ *
+ * Copyright (c) 2026 Altera Corporation
+ *
+ * Authors:
+ * Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
+ * Tze Yee Ng <tze.yee.ng@altera.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/cleanup.h>
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/firmware/intel/stratix10-svc-client.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/jiffies.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define HWMON_TIMEOUT msecs_to_jiffies(SVC_HWMON_REQUEST_TIMEOUT_MS)
+#define HWMON_RETRY_SLEEP_MS 1U
+#define HWMON_ASYNC_MSG_RETRY 3U
+#define STRATIX10_HWMON_MAXSENSORS 16
+#define STRATIX10_HWMON_TEMPERATURE "temperature"
+#define STRATIX10_HWMON_VOLTAGE "voltage"
+#define STRATIX10_HWMON_CHANNEL_MASK GENMASK(15, 0)
+#define STRATIX10_HWMON_PAGE_SHIFT 16
+#define STRATIX10_HWMON_ATTR_VISIBLE 0444
+/* Temperature from SDM is signed Q8.8 millidegrees Celsius (8 fractional bits). */
+#define STRATIX10_HWMON_TEMP_FRAC_BITS 8
+#define STRATIX10_HWMON_TEMP_FRAC_DIV BIT(STRATIX10_HWMON_TEMP_FRAC_BITS)
+/* Voltage from SDM is unsigned Q16 (millivolts, 16 fractional bits). */
+#define STRATIX10_HWMON_VOLT_FRAC_BITS 16
+#define STRATIX10_HWMON_VOLT_FRAC_DIV BIT(STRATIX10_HWMON_VOLT_FRAC_BITS)
+
+#define ETEMP_INACTIVE 0x80000000U
+#define ETEMP_TOO_OLD 0x80000001U
+#define ETEMP_NOT_PRESENT 0x80000002U
+#define ETEMP_TIMEOUT 0x80000003U
+#define ETEMP_CORRUPT 0x80000004U
+#define ETEMP_BUSY 0x80000005U
+#define ETEMP_NOT_INITIALIZED 0x800000FFU
+
+struct stratix10_hwmon_priv {
+ struct stratix10_svc_chan *chan;
+ struct stratix10_svc_client client;
+ struct completion completion;
+ struct mutex lock; /* protect SVC calls */
+ bool async;
+ u32 temperature;
+ u32 voltage;
+ int temperature_channels;
+ int voltage_channels;
+ const char *temp_chan_names[STRATIX10_HWMON_MAXSENSORS];
+ const char *volt_chan_names[STRATIX10_HWMON_MAXSENSORS];
+ u32 temp_chan[STRATIX10_HWMON_MAXSENSORS];
+ u32 volt_chan[STRATIX10_HWMON_MAXSENSORS];
+};
+
+static umode_t stratix10_hwmon_is_visible(const void *dev,
+ enum hwmon_sensor_types type,
+ u32 attr, int chan)
+{
+ const struct stratix10_hwmon_priv *priv = dev;
+
+ switch (type) {
+ case hwmon_temp:
+ if (chan < priv->temperature_channels)
+ return STRATIX10_HWMON_ATTR_VISIBLE;
+ return 0;
+ case hwmon_in:
+ if (chan < priv->voltage_channels)
+ return STRATIX10_HWMON_ATTR_VISIBLE;
+ return 0;
+ default:
+ return 0;
+ }
+}
+
+static void stratix10_hwmon_readtemp_cb(struct stratix10_svc_client *client,
+ struct stratix10_svc_cb_data *data)
+{
+ struct stratix10_hwmon_priv *priv = client->priv;
+
+ if (data->status == BIT(SVC_STATUS_OK)) {
+ priv->temperature = (u32)*(unsigned long *)data->kaddr1;
+ } else if (data->kaddr1) {
+ dev_err(client->dev, "%s failed with status 0x%x, value 0x%lx\n",
+ __func__, data->status,
+ *(unsigned long *)data->kaddr1);
+ } else {
+ dev_err(client->dev, "%s failed with status 0x%x\n",
+ __func__, data->status);
+ }
+
+ complete(&priv->completion);
+}
+
+static void stratix10_hwmon_readvolt_cb(struct stratix10_svc_client *client,
+ struct stratix10_svc_cb_data *data)
+{
+ struct stratix10_hwmon_priv *priv = client->priv;
+
+ if (data->status == BIT(SVC_STATUS_OK)) {
+ priv->voltage = (u32)*(unsigned long *)data->kaddr1;
+ } else if (data->kaddr1) {
+ dev_err(client->dev, "%s failed with status 0x%x, value 0x%lx\n",
+ __func__, data->status,
+ *(unsigned long *)data->kaddr1);
+ } else {
+ dev_err(client->dev, "%s failed with status 0x%x\n",
+ __func__, data->status);
+ }
+
+ complete(&priv->completion);
+}
+
+static void stratix10_hwmon_async_callback(void *ptr)
+{
+ if (ptr)
+ complete(ptr);
+}
+
+static int stratix10_hwmon_parse_temp(long *val, u32 temperature)
+{
+ switch (temperature) {
+ case ETEMP_INACTIVE:
+ case ETEMP_NOT_PRESENT:
+ case ETEMP_CORRUPT:
+ case ETEMP_NOT_INITIALIZED:
+ return -EOPNOTSUPP;
+ case ETEMP_TIMEOUT:
+ case ETEMP_BUSY:
+ case ETEMP_TOO_OLD:
+ return -EAGAIN;
+ default:
+ /* Convert Q8.8 millidegrees Celsius to millidegrees for hwmon. */
+ *val = (long)(s32)temperature / STRATIX10_HWMON_TEMP_FRAC_DIV;
+ return 0;
+ }
+}
+
+static int stratix10_hwmon_encode_temp_arg(u32 reg, u64 *arg)
+{
+ u32 page = (reg >> STRATIX10_HWMON_PAGE_SHIFT) & STRATIX10_HWMON_CHANNEL_MASK;
+ u32 channel = reg & STRATIX10_HWMON_CHANNEL_MASK;
+
+ if (channel >= STRATIX10_HWMON_MAXSENSORS)
+ return -EINVAL;
+
+ *arg = (1ULL << channel) | ((u64)page << STRATIX10_HWMON_PAGE_SHIFT);
+ return 0;
+}
+
+static int stratix10_hwmon_encode_volt_arg(u32 reg, u64 *arg)
+{
+ u32 channel = reg & STRATIX10_HWMON_CHANNEL_MASK;
+
+ if (channel >= STRATIX10_HWMON_MAXSENSORS)
+ return -EINVAL;
+
+ *arg = 1ULL << channel;
+ return 0;
+}
+
+static int stratix10_hwmon_async_read(struct device *dev,
+ enum hwmon_sensor_types type,
+ struct stratix10_svc_client_msg *msg)
+{
+ struct stratix10_hwmon_priv *priv = dev_get_drvdata(dev);
+ struct stratix10_svc_cb_data data = {};
+ struct completion completion;
+ unsigned long wait_ret;
+ void *handle = NULL;
+ int status, index, ret;
+
+ init_completion(&completion);
+
+ for (index = 0; index < HWMON_ASYNC_MSG_RETRY; index++) {
+ status = stratix10_svc_async_send(priv->chan, msg, &handle,
+ stratix10_hwmon_async_callback,
+ &completion);
+ if (status == 0)
+ break;
+ dev_warn(dev, "Failed to send async message\n");
+ msleep(HWMON_RETRY_SLEEP_MS);
+ }
+
+ if (status && !handle)
+ return status;
+
+ wait_ret = wait_for_completion_io_timeout(&completion, HWMON_TIMEOUT);
+ if (wait_ret > 0)
+ dev_dbg(dev, "Received async interrupt\n");
+ else if (wait_ret == 0)
+ dev_dbg(dev, "Timeout occurred, trying to poll the response\n");
+
+ ret = -ETIMEDOUT;
+ for (index = 0; index < HWMON_ASYNC_MSG_RETRY; index++) {
+ status = stratix10_svc_async_poll(priv->chan, handle, &data);
+ if (status == -EAGAIN) {
+ dev_dbg(dev, "Async message is still in progress\n");
+ } else if (status < 0) {
+ dev_alert(dev, "Failed to poll async message: %d\n", status);
+ ret = status;
+ break;
+ } else if (status == 0) {
+ ret = 0;
+ break;
+ }
+ msleep(HWMON_RETRY_SLEEP_MS);
+ }
+
+ if (ret) {
+ dev_err(dev, "Failed to get async response\n");
+ goto done;
+ }
+
+ if (data.status) {
+ dev_err(dev, "%s returned 0x%x from SDM\n", __func__,
+ data.status);
+ ret = -EFAULT;
+ goto done;
+ }
+
+ if (type == hwmon_temp)
+ priv->temperature = (u32)*(unsigned long *)data.kaddr1;
+ else
+ priv->voltage = (u32)*(unsigned long *)data.kaddr1;
+
+ ret = 0;
+
+done:
+ stratix10_svc_async_done(priv->chan, handle);
+ return ret;
+}
+
+static int stratix10_hwmon_sync_read(struct device *dev,
+ enum hwmon_sensor_types type,
+ struct stratix10_svc_client_msg *msg)
+{
+ struct stratix10_hwmon_priv *priv = dev_get_drvdata(dev);
+ int ret;
+
+ reinit_completion(&priv->completion);
+
+ if (type == hwmon_temp)
+ priv->client.receive_cb = stratix10_hwmon_readtemp_cb;
+ else
+ priv->client.receive_cb = stratix10_hwmon_readvolt_cb;
+
+ ret = stratix10_svc_send(priv->chan, msg);
+ if (ret < 0)
+ goto status_done;
+
+ ret = wait_for_completion_interruptible_timeout(&priv->completion,
+ HWMON_TIMEOUT);
+ if (!ret) {
+ dev_err(priv->client.dev, "timeout waiting for SMC call\n");
+ ret = -ETIMEDOUT;
+ goto status_done;
+ }
+ if (ret < 0) {
+ dev_err(priv->client.dev, "error %d waiting for SMC call\n", ret);
+ goto status_done;
+ }
+
+ ret = 0;
+
+status_done:
+ stratix10_svc_done(priv->chan);
+ return ret;
+}
+
+static int stratix10_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int chan, long *val)
+{
+ struct stratix10_hwmon_priv *priv = dev_get_drvdata(dev);
+ struct stratix10_svc_client_msg msg = {0};
+ int ret;
+
+ if (chan >= STRATIX10_HWMON_MAXSENSORS)
+ return -EOPNOTSUPP;
+
+ switch (type) {
+ case hwmon_temp:
+ ret = stratix10_hwmon_encode_temp_arg(priv->temp_chan[chan],
+ &msg.arg[0]);
+ if (ret)
+ return ret;
+ msg.command = COMMAND_HWMON_READTEMP;
+ break;
+ case hwmon_in:
+ ret = stratix10_hwmon_encode_volt_arg(priv->volt_chan[chan],
+ &msg.arg[0]);
+ if (ret)
+ return ret;
+ msg.command = COMMAND_HWMON_READVOLT;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ guard(mutex)(&priv->lock);
+ if (priv->async)
+ ret = stratix10_hwmon_async_read(dev, type, &msg);
+ else
+ ret = stratix10_hwmon_sync_read(dev, type, &msg);
+ if (ret)
+ return ret;
+
+ if (type == hwmon_temp)
+ ret = stratix10_hwmon_parse_temp(val, priv->temperature);
+ else
+ /* Convert Q16 millivolts to millivolts for hwmon. */
+ *val = (long)priv->voltage / STRATIX10_HWMON_VOLT_FRAC_DIV;
+ return ret;
+}
+
+static int stratix10_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int chan, const char **str)
+{
+ struct stratix10_hwmon_priv *priv = dev_get_drvdata(dev);
+
+ switch (type) {
+ case hwmon_in:
+ *str = priv->volt_chan_names[chan];
+ return 0;
+ case hwmon_temp:
+ *str = priv->temp_chan_names[chan];
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops stratix10_hwmon_ops = {
+ .is_visible = stratix10_hwmon_is_visible,
+ .read = stratix10_hwmon_read,
+ .read_string = stratix10_hwmon_read_string,
+};
+
+static const struct hwmon_channel_info *stratix10_hwmon_info[] = {
+ HWMON_CHANNEL_INFO(temp,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_LABEL),
+ HWMON_CHANNEL_INFO(in,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL,
+ HWMON_I_INPUT | HWMON_I_LABEL),
+ NULL
+};
+
+static const struct hwmon_chip_info stratix10_hwmon_chip_info = {
+ .ops = &stratix10_hwmon_ops,
+ .info = stratix10_hwmon_info,
+};
+
+static int stratix10_hwmon_add_channel(struct device *dev, const char *type,
+ u32 val, const char *label,
+ struct stratix10_hwmon_priv *priv)
+{
+ if (!strcmp(type, STRATIX10_HWMON_TEMPERATURE)) {
+ if (priv->temperature_channels >= STRATIX10_HWMON_MAXSENSORS) {
+ dev_warn(dev, "Can't add temp node %s, too many channels\n",
+ label);
+ return 0;
+ }
+
+ priv->temp_chan_names[priv->temperature_channels] = label;
+ priv->temp_chan[priv->temperature_channels] = val;
+ priv->temperature_channels++;
+ return 0;
+ }
+
+ if (!strcmp(type, STRATIX10_HWMON_VOLTAGE)) {
+ if (priv->voltage_channels >= STRATIX10_HWMON_MAXSENSORS) {
+ dev_warn(dev, "Can't add voltage node %s, too many channels\n",
+ label);
+ return 0;
+ }
+
+ priv->volt_chan_names[priv->voltage_channels] = label;
+ priv->volt_chan[priv->voltage_channels] = val;
+ priv->voltage_channels++;
+ return 0;
+ }
+
+ dev_warn(dev, "unsupported sensor type %s\n", type);
+ return 0;
+}
+
+static int stratix10_hwmon_probe_child_from_dt(struct device *dev,
+ struct device_node *child,
+ struct stratix10_hwmon_priv *priv)
+{
+ struct device_node *grandchild;
+ const char *label;
+ u32 val;
+ int ret;
+
+ for_each_child_of_node(child, grandchild) {
+ ret = of_property_read_u32(grandchild, "reg", &val);
+ if (ret) {
+ dev_err(dev, "missing reg property of %pOFn\n",
+ grandchild);
+ of_node_put(grandchild);
+ return ret;
+ }
+
+ ret = of_property_read_string(grandchild, "label", &label);
+ if (ret)
+ label = grandchild->name;
+
+ stratix10_hwmon_add_channel(dev, child->name, val, label, priv);
+ }
+
+ return 0;
+}
+
+static int stratix10_hwmon_probe_from_dt(struct device *dev,
+ struct stratix10_hwmon_priv *priv)
+{
+ struct device_node *child;
+ int ret;
+
+ if (!dev->of_node)
+ return 0;
+
+ for_each_child_of_node(dev->of_node, child) {
+ ret = stratix10_hwmon_probe_child_from_dt(dev, child, priv);
+ if (ret) {
+ of_node_put(child);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int stratix10_hwmon_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct stratix10_hwmon_priv *priv;
+ struct device *hwmon_dev;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->client.dev = dev;
+ priv->client.priv = priv;
+ init_completion(&priv->completion);
+ mutex_init(&priv->lock);
+
+ ret = stratix10_hwmon_probe_from_dt(dev, priv);
+ if (ret) {
+ dev_err(dev, "Unable to probe from device tree\n");
+ return ret;
+ }
+
+ if (!priv->temperature_channels && !priv->voltage_channels) {
+ dev_err(dev, "no temperature or voltage channels in device tree\n");
+ return -ENODEV;
+ }
+
+ priv->chan = stratix10_svc_request_channel_byname(&priv->client,
+ SVC_CLIENT_HWMON);
+ if (IS_ERR(priv->chan)) {
+ ret = PTR_ERR(priv->chan);
+ if (ret == -EPROBE_DEFER)
+ dev_dbg(dev, "service channel %s not ready, deferring probe\n",
+ SVC_CLIENT_HWMON);
+ else
+ dev_err(dev, "couldn't get service channel %s: %d\n",
+ SVC_CLIENT_HWMON, ret);
+ return ret;
+ }
+
+ ret = stratix10_svc_add_async_client(priv->chan, false);
+ switch (ret) {
+ case 0:
+ priv->async = true;
+ break;
+ case -EINVAL:
+ dev_dbg(dev, "async operations not supported, using sync mode\n");
+ priv->async = false;
+ break;
+ default:
+ dev_err(dev, "failed to add async client: %d\n", ret);
+ stratix10_svc_free_channel(priv->chan);
+ return ret;
+ }
+
+ dev_info(dev, "Initialized %d temperature and %d voltage channels\n",
+ priv->temperature_channels, priv->voltage_channels);
+
+ hwmon_dev = devm_hwmon_device_register_with_info(dev, "stratix10_hwmon",
+ priv,
+ &stratix10_hwmon_chip_info,
+ NULL);
+ if (IS_ERR(hwmon_dev)) {
+ if (priv->async)
+ stratix10_svc_remove_async_client(priv->chan);
+ stratix10_svc_free_channel(priv->chan);
+ return PTR_ERR(hwmon_dev);
+ }
+
+ platform_set_drvdata(pdev, priv);
+ return 0;
+}
+
+static void stratix10_hwmon_remove(struct platform_device *pdev)
+{
+ struct stratix10_hwmon_priv *priv = platform_get_drvdata(pdev);
+
+ if (priv->async)
+ stratix10_svc_remove_async_client(priv->chan);
+ stratix10_svc_free_channel(priv->chan);
+}
+
+static const struct of_device_id stratix10_hwmon_of_match[] = {
+ { .compatible = "altr,stratix10-hwmon" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, stratix10_hwmon_of_match);
+
+static struct platform_driver stratix10_hwmon_driver = {
+ .driver = {
+ .name = "stratix10-hwmon",
+ .of_match_table = stratix10_hwmon_of_match,
+ },
+ .probe = stratix10_hwmon_probe,
+ .remove = stratix10_hwmon_remove,
+};
+module_platform_driver(stratix10_hwmon_driver);
+
+MODULE_AUTHOR("Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>");
+MODULE_AUTHOR("Tze Yee Ng <tze.yee.ng@altera.com>");
+MODULE_DESCRIPTION("Altera Stratix 10 SoC FPGA hardware monitoring driver");
+MODULE_LICENSE("GPL");
--
2.43.7
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: socfpga: stratix10: add hwmon node
From: tze.yee.ng @ 2026-06-19 9:38 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <cover.1781861409.git.tze.yee.ng@altera.com>
From: Tze Yee Ng <tze.yee.ng@altera.com>
Add an hwmon child node under the Stratix 10 service layer and describe
the SoCDK voltage and temperature sensors using the altr,stratix10-hwmon
compatible.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
---
.../boot/dts/altera/socfpga_stratix10.dtsi | 5 +++
.../dts/altera/socfpga_stratix10_socdk.dts | 33 +++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index 0d9cad0c0351..afb11e6f6813 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -78,6 +78,11 @@ svc {
fpga_mgr: fpga-mgr {
compatible = "intel,stratix10-soc-fpga-mgr";
};
+
+ temp_volt: hwmon {
+ compatible = "altr,stratix10-hwmon";
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
index e2a1cea7f3da..01a8ffe430ed 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
@@ -134,3 +134,36 @@ root: partition@4200000 {
};
};
};
+
+&temp_volt {
+ status = "okay";
+
+ voltage {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ input@2 {
+ label = "0.8V VCC";
+ reg = <2>;
+ };
+
+ input@3 {
+ label = "1.8V VCCIO_SDM";
+ reg = <3>;
+ };
+
+ input@6 {
+ label = "0.9V VCCERAM";
+ reg = <6>;
+ };
+ };
+
+ temperature {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ input@0 {
+ label = "Main Die SDM";
+ reg = <0x0>;
+ };
+ };
+};
--
2.43.7
^ permalink raw reply related
* Re: [PATCH 2/5] dt-bindings: firmware: svc: add hwmon property
From: sashiko-bot @ 2026-06-19 9:44 UTC (permalink / raw)
To: tze.yee.ng; +Cc: robh, linux-hwmon, devicetree, conor+dt
In-Reply-To: <be798fdfb7ec76e1f7d04c1fd00126c88c8a2e31.1781861409.git.tze.yee.ng@altera.com>
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Altera Stratix 10 SoCFPGA supports hardware monitor access through the
> service layer mailbox. Add an optional hwmon child node to the service
> layer binding so device trees can describe the hardware monitor.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1781861409.git.tze.yee.ng@altera.com?part=2
^ 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