* Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence
From: Konrad Dybcio @ 2026-06-17 13:03 UTC (permalink / raw)
To: Iskren Chernev, Konrad Dybcio, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
Greg Kroah-Hartman, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <6fb6f805-aea1-47e7-bb7c-bc5ecb2201ae@iskren.info>
On 6/17/26 2:48 PM, Iskren Chernev wrote:
>
>
> On 6/15/26 1:44 PM, Konrad Dybcio wrote:
>> On 6/14/26 2:29 PM, Iskren Chernev wrote:
>>>
>>>
>>> On 6/10/26 3:04 PM, Konrad Dybcio wrote:
>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>
>>>> I don't know where the existing one came from, but it's apparently
>>>> wrong, according to both docs and a downstream DT [1]. Fix it up.
>>>
>>> They came from DTB extracted from a running billie2 (OnePlus Nord N100):
>>> [1] https://mainlining.dev/wp-content/uploads/2021/02/03_dtbdump_Qualcomm_Technologies_Inc._Bengal_SoC.dts
>>>
>>> The phone was bough early after launch, so it could have been wrong/updated later.
>>
>> Good to see you're still around!
>>
>> Looks like vendor tuning. I see that even the initial commit for
>> 6115 had the init sequence I posted. And the OnePlus sources have
>> what seems like a project-specific local copy of the DTSI:
>>
>> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/qcom/bengal-usb.dtsi#L145
>> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/20882/bengal-usb.dtsi#L148
>>
>> To support that, we should add a new property to override the TUNEx
>> registers - like e.g. qcom,hstx-trim-value that's already consumed
>
> My 2 cents - I never understood why init sequences are taboo in mainline
> and widely used in downstream. I guess if it doesn't change (but across
> what and who decides) it should be in code, but if it's "tuning"
> - whatever that means, possibly depends on other components around, it
> should be "configurable" via DT.
The PHY has some electrical characteristics of its own, and then atop
that are the characteristics of what's on the other end of it. Making
all parameters configurable (i.e. raw init sequence) leads to duplication
and pure blob seqeuences, whereas making everything constant leads to
polluting the driver (if every device-specific seq was to be in C files)
I think the current model of "override as necessary" is OK, especially
since we can use the upstream leverage to require describing what the
altered parameters actually change
>> Would you like to look into that, or should I take this?
>
> You can take it, the other option is to mark a TODO, and if somebody
> feels strongly about the binary value in a usb tune register s/he can
> take up the task.
Seems like OnePlus does.. actually, a number of vendors do. Sony
does/used to do some tuning there too.
> I just wanted to point out that the number didn't come from a random
> number generator (or AI).
I'm sorry if my language was too harsh. You used the best sources
you had and had no reason to believe they were not the expected values.
Konrad
^ permalink raw reply
* Re: [PATCH v4 1/5] arm64: dts: qcom: pmk8550: add VADC node
From: sashiko-bot @ 2026-06-17 13:02 UTC (permalink / raw)
To: Neil Armstrong; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-1-4af9251731f1@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch includes a nonexistent header file `"qcom-adc5-gen3.h"` and uses undefined parameterized macros, breaking Device Tree compilation.
--
commit 9db08ecceaa2afc05462ac83976c923d21f78ce1
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: pmk8550: add VADC node
This commit adds the VADC node and the initial pmk8550 adc channels.
> diff --git a/arch/arm64/boot/dts/qcom/pmk8550.dtsi b/arch/arm64/boot/dts/qcom/pmk8550.dtsi
> index 3049eb6b46d7a..639c0b1e0c33a 100644
> --- a/arch/arm64/boot/dts/qcom/pmk8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pmk8550.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/input/linux-event-codes.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/spmi/spmi.h>
> +#include "qcom-adc5-gen3.h"
[Severity: Low]
Is this header missing from the patch? It doesn't appear to be present in
the tree, which causes the C preprocessor to fail with a 'No such file or
directory' error during Device Tree compilation.
[ ... ]
> + pmk8550_vadc: adc@9000 {
> + compatible = "qcom,spmi-adc5-gen3";
> + reg = <0x9000>, <0x9100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <0x0 0x90 0x1 IRQ_TYPE_EDGE_RISING>,
> + <0x0 0x91 0x1 IRQ_TYPE_EDGE_RISING>;
> + #io-channel-cells = <1>;
> + #thermal-sensor-cells = <1>;
> +
> + channel@0 {
> + reg = <ADC5_GEN3_REF_GND(0)>;
[Severity: Low]
Because the qcom-adc5-gen3.h header is missing, parameterized macros like
ADC5_GEN3_REF_GND remain undefined. Does this lead to dtc syntax errors
when attempting to parse these channel properties?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org?part=1
^ permalink raw reply
* [PATCH v4 3/3] arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on Radxa ROCK 5 family
From: Ricardo Pardini via B4 Relay @ 2026-06-17 12:58 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Ricardo Pardini
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-0-2bd38922d129@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
The Radxa ROCK 5B / 5B+ / 5T all carry on-board Realtek RTL8125 NICs.
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can inject mac-address
properties from its ethaddr/eth1addr env, for stable MACs across
boots that both U-Boot and the kernel agree on.
The RTL8125 on pcie2x1l2 is shared by all three variants. The ROCK 5T
additionally describes pcie2x1l1 with its second RTL8125.
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
.../arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts | 18 ++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
index bf4a1d2e55ca3..b53dfe6848cce 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
@@ -10,6 +10,7 @@
/ {
aliases {
+ ethernet0 = &rtl_eth0;
mmc0 = &sdhci;
mmc1 = &sdmmc;
mmc2 = &sdio;
@@ -482,6 +483,20 @@ &pcie2x1l2 {
reset-gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
vpcie3v3-supply = <&vcc3v3_pcie2x1l2>;
status = "okay";
+
+ pcie@0,0 {
+ reg = <0x400000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ device_type = "pci";
+ bus-range = <0x41 0x4f>;
+
+ rtl_eth0: ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x410000 0 0 0 0>;
+ };
+ };
};
&pcie30phy {
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts
index 425036146b6d9..b1a3e4b2165f9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts
@@ -8,6 +8,10 @@ / {
model = "Radxa ROCK 5T";
compatible = "radxa,rock-5t", "rockchip,rk3588";
+ aliases {
+ ethernet1 = &rtl_eth1;
+ };
+
analog-sound {
compatible = "audio-graph-card";
label = "rk3588-es8316";
@@ -76,6 +80,20 @@ &pcie2x1l1 {
reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
vpcie3v3-supply = <&vcc3v3_pcie2x1l1>;
status = "okay";
+
+ pcie@0,0 {
+ reg = <0x300000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ device_type = "pci";
+ bus-range = <0x31 0x3f>;
+
+ rtl_eth1: ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x310000 0 0 0 0>;
+ };
+ };
};
&pcie30phy {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/3] describe RTL8125 PCIe NICs on Rockchip boards (and add DT binding)
From: Ricardo Pardini via B4 Relay @ 2026-06-17 12:58 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Ricardo Pardini
Several Rockchip rk35xx boards carry on-board Realtek RTL8125 2.5GbE
NICs whose PCI function nodes are not described in the DT. Describing
them allows for stable ethernetN aliases (matching the GMAC alias
convention on these boards) and lets U-Boot's fdt_fixup_ethernet()
inject mac-address properties from its ethaddr/ethNaddr env, so MACs
stay stable across boots and U-Boot and kernel MAC match.
Patch 1 adds a DT binding for Realtek RTL8125 family PCIe Ethernet
controllers.
Patch 2 describes the on-board RTL8125 function nodes on the
FriendlyElec NanoPC-T6 (and variants).
Patch 3 describes the on-board RTL8125 function nodes on the Radxa
ROCK 5B / 5B+ / 5T family done based on lspci output provided by
helpful Armbian folks.
---
Changes in v4:
- binding: simplify the binding YAML ref Sashiko's and Krzysztof's
reviews
- binding: describe only the RTL8125 + rename to match ref Heiner's
review.
- dt: fix the bus-range according to Sashiko's review.
- Link to v3: https://patch.msgid.link/20260605-rk3588-dts-rtl-eth-describe-dt-alias-v3-0-8a8857b39daf@pardini.net
Changes in v3:
- new patch: add a DT binding for Realtek r8169 family PCIe Ethernet
controllers, per Sebastian Reichel's review (the "pciVVVV,DDDD" OF
spelling still needs a binding when used in a board DT).
- new patch for Rock5 series, and include a brief rationale in each.
- retitle the series, since it now covers a few boards and a binding
rather than just DeviceTree changes for the NanoPC-T6.
- drop the v2 "rename vcc3v3_pcie2x1l0 regulator" patch from this
series; it will be sent separately as it is not relevant to this.
- Link to v2: https://patch.msgid.link/20260529-rk3588-dts-rtl-eth-describe-dt-alias-v2-0-49700248143f@pardini.net
Changes in v2:
- fix: pcie2x1l0, not pcie2x1l1; indirectly caught by Sashiko's review [1]
- while-at-it: rename regulator vcc3v3_pcie2x1l0 to l1
- Link to v1: https://patch.msgid.link/20260525-rk3588-dts-rtl-eth-describe-dt-alias-v1-1-a6fcda563ac7@pardini.net
[1] https://sashiko.dev/#/patchset/20260525-rk3588-dts-rtl-eth-describe-dt-alias-v1-1-a6fcda563ac7%40pardini.net
To: Heiner Kallweit <hkallweit1@gmail.com>
To: nic_swsd@realtek.com
To: Andrew Lunn <andrew+netdev@lunn.ch>
To: "David S. Miller" <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Heiko Stuebner <heiko@sntech.de>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
Ricardo Pardini (3):
dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on NanoPC-T6
arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on Radxa ROCK 5 family
.../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
MAINTAINERS | 1 +
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 +++++++++++++++
.../boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 15 ++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5t.dts | 18 +++++++++
5 files changed, 107 insertions(+)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260524-rk3588-dts-rtl-eth-describe-dt-alias-c1ed187b7c50
Best regards,
--
Ricardo Pardini <ricardo@pardini.net>
^ permalink raw reply
* [PATCH v4 2/3] arm64: dts: rockchip: describe PCIe RTL8125 Ethernet on NanoPC-T6
From: Ricardo Pardini via B4 Relay @ 2026-06-17 12:58 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Ricardo Pardini
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-0-2bd38922d129@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
The FriendlyElec NanoPC-T6 carries two on-board Realtek RTL8125 NICs
behind pcie2x1l0 and pcie2x1l2.
Describe the fixed function nodes and attach ethernet0/ethernet1
aliases, so that U-Boot's fdt_fixup_ethernet() can inject mac-address
properties from its ethaddr/eth1addr env. The on-NIC EEPROMs on this
board are not pre-programmed with a unique MAC, so this gives a
stable MAC across boots that both U-Boot and the kernel agree on.
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
index 84b6b53f016ab..0c11033f9d8e4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
@@ -20,6 +20,8 @@ / {
compatible = "friendlyarm,nanopc-t6", "rockchip,rk3588";
aliases {
+ ethernet0 = &rtl_eth0;
+ ethernet1 = &rtl_eth1;
mmc0 = &sdhci;
mmc1 = &sdmmc;
};
@@ -635,6 +637,20 @@ &pcie2x1l0 {
pinctrl-names = "default";
pinctrl-0 = <&pcie2_0_rst>;
status = "okay";
+
+ pcie@0,0 {
+ reg = <0x200000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ device_type = "pci";
+ bus-range = <0x21 0x2f>;
+
+ rtl_eth0: ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x210000 0 0 0 0>;
+ };
+ };
};
&pcie2x1l1 {
@@ -651,6 +667,20 @@ &pcie2x1l2 {
pinctrl-names = "default";
pinctrl-0 = <&pcie2_2_rst>;
status = "okay";
+
+ pcie@0,0 {
+ reg = <0x400000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ device_type = "pci";
+ bus-range = <0x41 0x4f>;
+
+ rtl_eth1: ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x410000 0 0 0 0>;
+ };
+ };
};
&pcie30phy {
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/3] dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
From: Ricardo Pardini via B4 Relay @ 2026-06-17 12:58 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, Ricardo Pardini
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-0-2bd38922d129@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
controller.
The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
compatibles documented in their own bindings (e.g. microchip,lan95xx)
so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
these PCI function nodes can be validated.
Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
.../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
new file mode 100644
index 0000000000000..eee13fbc1e6a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/realtek,rtl8125.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTL8125 2.5 Gigabit PCIe Ethernet Controller
+
+maintainers:
+ - Heiner Kallweit <hkallweit1@gmail.com>
+
+description:
+ The Realtek RTL8125 is a 2.5GBASE-T Ethernet controller with a PCIe host
+ interface.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ const: pci10ec,8125
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ethernet@0,0 {
+ compatible = "pci10ec,8125";
+ reg = <0x10000 0 0 0 0>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index c8d4b913f26c1..e5fbd82946aec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -134,6 +134,7 @@ M: Heiner Kallweit <hkallweit1@gmail.com>
M: nic_swsd@realtek.com
L: netdev@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
F: drivers/net/ethernet/realtek/r8169*
8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
--
2.54.0
^ permalink raw reply related
* [PATCH v4 4/5] arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodes
From: Neil Armstrong @ 2026-06-17 12:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org>
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 277 ++++++++++++++++++++++++++++++++
1 file changed, 277 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index a3982ae22929..d4a0627ebbf6 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
@@ -158,6 +158,92 @@ platform {
};
};
+ thermal-zones {
+ skin-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ cam-flash-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX2_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wlan-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX3_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX4_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-tof-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX5_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ usb-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX4_THM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wls-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX6_THM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
vph_pwr: vph-pwr-regulator {
compatible = "regulator-fixed";
@@ -1040,27 +1126,218 @@ led@3 {
};
};
+&pm8550_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(1)>;
+ io-channel-names = "thermal";
+};
+
&pm8550b_eusb2_repeater {
vdd18-supply = <&vreg_l15b_1p8>;
vdd3-supply = <&vreg_l5b_3p1>;
};
+&pm8550b_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(7)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_c {
status = "okay";
};
+&pm8550vs_c_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(2)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_d {
status = "okay";
};
+&pm8550vs_d_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(3)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_e {
status = "okay";
};
+&pm8550vs_e_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(4)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_g {
status = "okay";
};
+&pm8550vs_g_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(6)>;
+ io-channel-names = "thermal";
+};
+
+&pm8550ve_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ io-channel-names = "thermal";
+};
+
+&pmk8550_vadc {
+ /* PM8550 Channel nodes */
+ channel@100 {
+ reg = <ADC5_GEN3_REF_GND(1)>;
+ label = "pm8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@101 {
+ reg = <ADC5_GEN3_1P25VREF(1)>;
+ label = "pm8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@103 {
+ reg = <ADC5_GEN3_DIE_TEMP(1)>;
+ label = "pm8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@144 {
+ reg = <ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
+ label = "pm8550_msm_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@145 {
+ reg = <ADC5_GEN3_AMUX2_THM_100K_PU(1)>;
+ label = "pm8550_cam_flash_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@146 {
+ reg = <ADC5_GEN3_AMUX3_THM_100K_PU(1)>;
+ label = "pm8550_wlan_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@147 {
+ reg = <ADC5_GEN3_AMUX4_THM_100K_PU(1)>;
+ label = "pm8550_pa_therm_1";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@148 {
+ reg = <ADC5_GEN3_AMUX5_THM_100K_PU(1)>;
+ label = "pm8550_rear_tof_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@18e {
+ reg = <ADC5_GEN3_VPH_PWR(1)>;
+ label = "pm8550_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ /* PM8550VS_C Channel nodes */
+ channel@203 {
+ reg = <ADC5_GEN3_DIE_TEMP(2)>;
+ label = "pm8550vs_c_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_D Channel nodes */
+ channel@303 {
+ reg = <ADC5_GEN3_DIE_TEMP(3)>;
+ label = "pm8550vs_d_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_E Channel nodes */
+ channel@403 {
+ reg = <ADC5_GEN3_DIE_TEMP(4)>;
+ label = "pm8550vs_e_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VE Channel nodes */
+ channel@503 {
+ reg = <ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ label = "pm8550ve_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_G Channel nodes */
+ channel@603 {
+ reg = <ADC5_GEN3_DIE_TEMP(6)>;
+ label = "pm8550vs_g_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550B Channel nodes */
+ channel@700 {
+ reg = <ADC5_GEN3_REF_GND(7)>;
+ label = "pm8550b_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@701 {
+ reg = <ADC5_GEN3_1P25VREF(7)>;
+ label = "pm8550b_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@703 {
+ reg = <ADC5_GEN3_DIE_TEMP(7)>;
+ label = "pm8550b_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@747 {
+ reg = <ADC5_GEN3_AMUX4_THM_100K_PU(7)>;
+ label = "pm8550b_usb_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@749 {
+ reg = <ADC5_GEN3_AMUX6_THM_100K_PU(7)>;
+ label = "pm8550b_wls_therm";
+ qcom,ratiometric;
+ /* use the default settle time */
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@78e {
+ reg = <ADC5_GEN3_VPH_PWR(7)>;
+ label = "pm8550b_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@78f {
+ reg = <ADC5_GEN3_VBAT_SNS_QBG(7)>;
+ label = "pm8550b_vbat_sns_qbg";
+ qcom,pre-scaling = <1 6>;
+ };
+};
+
&qup_i2c3_data_clk {
/* Use internal I2C pull-up */
bias-pull-up = <2200>;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/5] arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodes
From: Neil Armstrong @ 2026-06-17 12:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org>
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 277 ++++++++++++++++++++++++++++++++
1 file changed, 277 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
index eabc828c05b4..05af2913055e 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
@@ -220,6 +220,92 @@ platform {
};
};
+ thermal-zones {
+ skin-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ cam-flash-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX2_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wlan-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX3_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX4_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-tof-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX5_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ usb-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX4_THM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wls-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX6_THM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
vph_pwr: regulator-vph-pwr {
compatible = "regulator-fixed";
@@ -1041,27 +1127,218 @@ led@3 {
};
};
+&pm8550_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(1)>;
+ io-channel-names = "thermal";
+};
+
&pm8550b_eusb2_repeater {
vdd18-supply = <&vreg_l15b_1p8>;
vdd3-supply = <&vreg_l5b_3p1>;
};
+&pm8550b_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(7)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_c {
status = "okay";
};
+&pm8550vs_c_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(2)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_d {
status = "okay";
};
+&pm8550vs_d_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(3)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_e {
status = "okay";
};
+&pm8550vs_e_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(4)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_g {
status = "okay";
};
+&pm8550vs_g_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(6)>;
+ io-channel-names = "thermal";
+};
+
+&pm8550ve_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ io-channel-names = "thermal";
+};
+
+&pmk8550_vadc {
+ /* PM8550 Channel nodes */
+ channel@100 {
+ reg = <ADC5_GEN3_REF_GND(1)>;
+ label = "pm8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@101 {
+ reg = <ADC5_GEN3_1P25VREF(1)>;
+ label = "pm8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@103 {
+ reg = <ADC5_GEN3_DIE_TEMP(1)>;
+ label = "pm8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@144 {
+ reg = <ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
+ label = "pm8550_msm_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@145 {
+ reg = <ADC5_GEN3_AMUX2_THM_100K_PU(1)>;
+ label = "pm8550_cam_flash_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@146 {
+ reg = <ADC5_GEN3_AMUX3_THM_100K_PU(1)>;
+ label = "pm8550_wlan_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@147 {
+ reg = <ADC5_GEN3_AMUX4_THM_100K_PU(1)>;
+ label = "pm8550_pa_therm_1";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@148 {
+ reg = <ADC5_GEN3_AMUX5_THM_100K_PU(1)>;
+ label = "pm8550_rear_tof_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@18e {
+ reg = <ADC5_GEN3_VPH_PWR(1)>;
+ label = "pm8550_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ /* PM8550VS_C Channel nodes */
+ channel@203 {
+ reg = <ADC5_GEN3_DIE_TEMP(2)>;
+ label = "pm8550vs_c_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_D Channel nodes */
+ channel@303 {
+ reg = <ADC5_GEN3_DIE_TEMP(3)>;
+ label = "pm8550vs_d_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_E Channel nodes */
+ channel@403 {
+ reg = <ADC5_GEN3_DIE_TEMP(4)>;
+ label = "pm8550vs_e_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VE Channel nodes */
+ channel@503 {
+ reg = <ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ label = "pm8550ve_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_G Channel nodes */
+ channel@603 {
+ reg = <ADC5_GEN3_DIE_TEMP(6)>;
+ label = "pm8550vs_g_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550B Channel nodes */
+ channel@700 {
+ reg = <ADC5_GEN3_REF_GND(7)>;
+ label = "pm8550b_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@701 {
+ reg = <ADC5_GEN3_1P25VREF(7)>;
+ label = "pm8550b_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@703 {
+ reg = <ADC5_GEN3_DIE_TEMP(7)>;
+ label = "pm8550b_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@747 {
+ reg = <ADC5_GEN3_AMUX4_THM_100K_PU(7)>;
+ label = "pm8550b_usb_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@749 {
+ reg = <ADC5_GEN3_AMUX6_THM_100K_PU(7)>;
+ label = "pm8550b_wls_therm";
+ qcom,ratiometric;
+ /* use the default settle time */
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@78e {
+ reg = <ADC5_GEN3_VPH_PWR(7)>;
+ label = "pm8550b_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@78f {
+ reg = <ADC5_GEN3_VBAT_SNS_QBG(7)>;
+ label = "pm8550b_vbat_sns_qbg";
+ qcom,pre-scaling = <1 6>;
+ };
+};
+
&pon_pwrkey {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/5] arm64: dts: qcom: sm8550-hdk: add SPMI ADC channels and thermal nodes
From: Neil Armstrong @ 2026-06-17 12:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org>
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 277 ++++++++++++++++++++++++++++++++
1 file changed, 277 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
index ee13e6136a82..f19419f63e36 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
@@ -280,6 +280,92 @@ platform {
};
};
+ thermal-zones {
+ skin-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ cam-flash-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX2_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wlan-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX3_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX4_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-tof-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX5_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ usb-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX4_THM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wls-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX6_THM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
wcn7850-pmu {
compatible = "qcom,wcn7850-pmu";
@@ -1102,27 +1188,218 @@ led@3 {
};
};
+&pm8550_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(1)>;
+ io-channel-names = "thermal";
+};
+
&pm8550b_eusb2_repeater {
vdd18-supply = <&vreg_l15b_1p8>;
vdd3-supply = <&vreg_l5b_3p1>;
};
+&pm8550b_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(7)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_c {
status = "okay";
};
+&pm8550vs_c_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(2)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_d {
status = "okay";
};
+&pm8550vs_d_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(3)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_e {
status = "okay";
};
+&pm8550vs_e_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(4)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_g {
status = "okay";
};
+&pm8550vs_g_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(6)>;
+ io-channel-names = "thermal";
+};
+
+&pm8550ve_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ io-channel-names = "thermal";
+};
+
+&pmk8550_vadc {
+ /* PM8550 Channel nodes */
+ channel@100 {
+ reg = <ADC5_GEN3_REF_GND(1)>;
+ label = "pm8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@101 {
+ reg = <ADC5_GEN3_1P25VREF(1)>;
+ label = "pm8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@103 {
+ reg = <ADC5_GEN3_DIE_TEMP(1)>;
+ label = "pm8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@144 {
+ reg = <ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
+ label = "pm8550_msm_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@145 {
+ reg = <ADC5_GEN3_AMUX2_THM_100K_PU(1)>;
+ label = "pm8550_cam_flash_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@146 {
+ reg = <ADC5_GEN3_AMUX3_THM_100K_PU(1)>;
+ label = "pm8550_wlan_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@147 {
+ reg = <ADC5_GEN3_AMUX4_THM_100K_PU(1)>;
+ label = "pm8550_pa_therm_1";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@148 {
+ reg = <ADC5_GEN3_AMUX5_THM_100K_PU(1)>;
+ label = "pm8550_rear_tof_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@18e {
+ reg = <ADC5_GEN3_VPH_PWR(1)>;
+ label = "pm8550_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ /* PM8550VS_C Channel nodes */
+ channel@203 {
+ reg = <ADC5_GEN3_DIE_TEMP(2)>;
+ label = "pm8550vs_c_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_D Channel nodes */
+ channel@303 {
+ reg = <ADC5_GEN3_DIE_TEMP(3)>;
+ label = "pm8550vs_d_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_E Channel nodes */
+ channel@403 {
+ reg = <ADC5_GEN3_DIE_TEMP(4)>;
+ label = "pm8550vs_e_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VE Channel nodes */
+ channel@503 {
+ reg = <ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ label = "pm8550ve_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_G Channel nodes */
+ channel@603 {
+ reg = <ADC5_GEN3_DIE_TEMP(6)>;
+ label = "pm8550vs_g_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550B Channel nodes */
+ channel@700 {
+ reg = <ADC5_GEN3_REF_GND(7)>;
+ label = "pm8550b_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@701 {
+ reg = <ADC5_GEN3_1P25VREF(7)>;
+ label = "pm8550b_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@703 {
+ reg = <ADC5_GEN3_DIE_TEMP(7)>;
+ label = "pm8550b_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@747 {
+ reg = <ADC5_GEN3_AMUX4_THM_100K_PU(7)>;
+ label = "pm8550b_usb_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@749 {
+ reg = <ADC5_GEN3_AMUX6_THM_100K_PU(7)>;
+ label = "pm8550b_wls_therm";
+ qcom,ratiometric;
+ /* use the default settle time */
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@78e {
+ reg = <ADC5_GEN3_VPH_PWR(7)>;
+ label = "pm8550b_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@78f {
+ reg = <ADC5_GEN3_VBAT_SNS_QBG(7)>;
+ label = "pm8550b_vbat_sns_qbg";
+ qcom,pre-scaling = <1 6>;
+ };
+};
+
&pon_pwrkey {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/5] arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodes
From: Neil Armstrong @ 2026-06-17 12:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org>
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 277 ++++++++++++++++++++++++++++++++
1 file changed, 277 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index 2fb2e0be5e4c..9356b40a1850 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -205,6 +205,92 @@ platform {
};
};
+ thermal-zones {
+ skin-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ cam-flash-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX2_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wlan-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX3_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX4_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-tof-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX5_THM_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ usb-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX4_THM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wls-thermal {
+ thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX6_THM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
vph_pwr: vph-pwr-regulator {
compatible = "regulator-fixed";
regulator-name = "vph_pwr";
@@ -997,27 +1083,218 @@ led@3 {
};
};
+&pm8550_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(1)>;
+ io-channel-names = "thermal";
+};
+
&pm8550b_eusb2_repeater {
vdd18-supply = <&vreg_l15b_1p8>;
vdd3-supply = <&vreg_l5b_3p1>;
};
+&pm8550b_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(7)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_c {
status = "okay";
};
+&pm8550vs_c_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(2)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_d {
status = "okay";
};
+&pm8550vs_d_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(3)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_e {
status = "okay";
};
+&pm8550vs_e_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(4)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_g {
status = "okay";
};
+&pm8550vs_g_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(6)>;
+ io-channel-names = "thermal";
+};
+
+&pm8550ve_temp_alarm {
+ io-channels = <&pmk8550_vadc ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ io-channel-names = "thermal";
+};
+
+&pmk8550_vadc {
+ /* PM8550 Channel nodes */
+ channel@100 {
+ reg = <ADC5_GEN3_REF_GND(1)>;
+ label = "pm8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@101 {
+ reg = <ADC5_GEN3_1P25VREF(1)>;
+ label = "pm8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@103 {
+ reg = <ADC5_GEN3_DIE_TEMP(1)>;
+ label = "pm8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@144 {
+ reg = <ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
+ label = "pm8550_msm_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@145 {
+ reg = <ADC5_GEN3_AMUX2_THM_100K_PU(1)>;
+ label = "pm8550_cam_flash_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@146 {
+ reg = <ADC5_GEN3_AMUX3_THM_100K_PU(1)>;
+ label = "pm8550_wlan_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@147 {
+ reg = <ADC5_GEN3_AMUX4_THM_100K_PU(1)>;
+ label = "pm8550_pa_therm_1";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@148 {
+ reg = <ADC5_GEN3_AMUX5_THM_100K_PU(1)>;
+ label = "pm8550_rear_tof_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@18e {
+ reg = <ADC5_GEN3_VPH_PWR(1)>;
+ label = "pm8550_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ /* PM8550VS_C Channel nodes */
+ channel@203 {
+ reg = <ADC5_GEN3_DIE_TEMP(2)>;
+ label = "pm8550vs_c_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_D Channel nodes */
+ channel@303 {
+ reg = <ADC5_GEN3_DIE_TEMP(3)>;
+ label = "pm8550vs_d_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_E Channel nodes */
+ channel@403 {
+ reg = <ADC5_GEN3_DIE_TEMP(4)>;
+ label = "pm8550vs_e_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VE Channel nodes */
+ channel@503 {
+ reg = <ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ label = "pm8550ve_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_G Channel nodes */
+ channel@603 {
+ reg = <ADC5_GEN3_DIE_TEMP(6)>;
+ label = "pm8550vs_g_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550B Channel nodes */
+ channel@700 {
+ reg = <ADC5_GEN3_REF_GND(7)>;
+ label = "pm8550b_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@701 {
+ reg = <ADC5_GEN3_1P25VREF(7)>;
+ label = "pm8550b_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@703 {
+ reg = <ADC5_GEN3_DIE_TEMP(7)>;
+ label = "pm8550b_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@747 {
+ reg = <ADC5_GEN3_AMUX4_THM_100K_PU(7)>;
+ label = "pm8550b_usb_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@749 {
+ reg = <ADC5_GEN3_AMUX6_THM_100K_PU(7)>;
+ label = "pm8550b_wls_therm";
+ qcom,ratiometric;
+ /* use the default settle time */
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@78e {
+ reg = <ADC5_GEN3_VPH_PWR(7)>;
+ label = "pm8550b_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@78f {
+ reg = <ADC5_GEN3_VBAT_SNS_QBG(7)>;
+ label = "pm8550b_vbat_sns_qbg";
+ qcom,pre-scaling = <1 6>;
+ };
+};
+
&pon_pwrkey {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/5] arm64: dts: qcom: pmk8550: add VADC node
From: Neil Armstrong @ 2026-06-17 12:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org>
Add the VADC node and the initial pmk8550 adc channels.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/pmk8550.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmk8550.dtsi b/arch/arm64/boot/dts/qcom/pmk8550.dtsi
index 3049eb6b46d7..639c0b1e0c33 100644
--- a/arch/arm64/boot/dts/qcom/pmk8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmk8550.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/spmi/spmi.h>
+#include "qcom-adc5-gen3.h"
/ {
reboot-mode {
@@ -44,6 +45,35 @@ pon_resin: resin {
};
};
+ pmk8550_vadc: adc@9000 {
+ compatible = "qcom,spmi-adc5-gen3";
+ reg = <0x9000>, <0x9100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0x0 0x90 0x1 IRQ_TYPE_EDGE_RISING>,
+ <0x0 0x91 0x1 IRQ_TYPE_EDGE_RISING>;
+ #io-channel-cells = <1>;
+ #thermal-sensor-cells = <1>;
+
+ channel@0 {
+ reg = <ADC5_GEN3_REF_GND(0)>;
+ label = "pmk8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@1 {
+ reg = <ADC5_GEN3_1P25VREF(0)>;
+ label = "pmk8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@3 {
+ reg = <ADC5_GEN3_DIE_TEMP(0)>;
+ label = "pmk8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+ };
+
pmk8550_rtc: rtc@6100 {
compatible = "qcom,pmk8350-rtc";
reg = <0x6100>, <0x6200>;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/5] arm64: dts: qcom: sm8[56]50: add PMIC5 Gen3 ADC channels
From: Neil Armstrong @ 2026-06-17 12:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
Now the bindings and driver was merged for the SPMI PMIC5 Gen3 ADC
found on the PMK8550 which allow reading ADC data on the PMK8550
and other PMICs on the system.
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
Depends on:
- https://lore.kernel.org/all/20260614-adc5_gen3_dt-v2-1-32ec576c5865@oss.qualcomm.com/
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v4:
- Rebase on https://lore.kernel.org/all/20260614-adc5_gen3_dt-v2-0-32ec576c5865@oss.qualcomm.com/
- Change all defines
- Reorder nodes
- Link to v3: https://patch.msgid.link/20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org
Changes in v3:
- Added note about nodes ordering in commit message
- Rebased on next
- Link to v2: https://patch.msgid.link/20260504-topic-sm8x50-adc5-gen3-v2-0-5cc04d6ecda0@linaro.org
Changes in v2:
- Removed stray line from patch 2, added review tag
- Added missing header file
- Link to v1: https://patch.msgid.link/20260427-topic-sm8x50-adc5-gen3-v1-0-8a70f7b90a75@linaro.org
---
Neil Armstrong (5):
arm64: dts: qcom: pmk8550: add VADC node
arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodes
arm64: dts: qcom: sm8550-hdk: add SPMI ADC channels and thermal nodes
arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodes
arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodes
arch/arm64/boot/dts/qcom/pmk8550.dtsi | 30 ++++
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 277 ++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 277 ++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 277 ++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 277 ++++++++++++++++++++++++++++++++
5 files changed, 1138 insertions(+)
---
base-commit: b3f94b2b3f3e51ab880a51fc6510e1dafba654ed
change-id: 20260427-topic-sm8x50-adc5-gen3-edf94fbd335b
prerequisite-change-id: 20260430-adc5_gen3_dt-f0434155ee25:2
prerequisite-patch-id: 42a8f026b28f4f1edf4932ce99a86ced84c4cc41
prerequisite-patch-id: b370a1d9b3c61a0031e10db2aa9c7779e0a26e14
prerequisite-patch-id: 179d8932fff0aef7eb84bb7e731597f8333f4427
prerequisite-patch-id: 2a2e07499d57f0497c7ce757b2d74077ae4a843a
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence
From: Iskren Chernev @ 2026-06-17 12:48 UTC (permalink / raw)
To: Konrad Dybcio, Konrad Dybcio, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
Greg Kroah-Hartman, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <a51b6333-cd5a-4a38-b748-b6623c6a1078@oss.qualcomm.com>
On 6/15/26 1:44 PM, Konrad Dybcio wrote:
> On 6/14/26 2:29 PM, Iskren Chernev wrote:
>>
>>
>> On 6/10/26 3:04 PM, Konrad Dybcio wrote:
>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>
>>> I don't know where the existing one came from, but it's apparently
>>> wrong, according to both docs and a downstream DT [1]. Fix it up.
>>
>> They came from DTB extracted from a running billie2 (OnePlus Nord N100):
>> [1] https://mainlining.dev/wp-content/uploads/2021/02/03_dtbdump_Qualcomm_Technologies_Inc._Bengal_SoC.dts
>>
>> The phone was bough early after launch, so it could have been wrong/updated later.
>
> Good to see you're still around!
>
> Looks like vendor tuning. I see that even the initial commit for
> 6115 had the init sequence I posted. And the OnePlus sources have
> what seems like a project-specific local copy of the DTSI:
>
> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/qcom/bengal-usb.dtsi#L145
> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/20882/bengal-usb.dtsi#L148
>
> To support that, we should add a new property to override the TUNEx
> registers - like e.g. qcom,hstx-trim-value that's already consumed
My 2 cents - I never understood why init sequences are taboo in mainline
and widely used in downstream. I guess if it doesn't change (but across
what and who decides) it should be in code, but if it's "tuning"
- whatever that means, possibly depends on other components around, it
should be "configurable" via DT.
> Would you like to look into that, or should I take this?
You can take it, the other option is to mark a TODO, and if somebody
feels strongly about the binary value in a usb tune register s/he can
take up the task.
I just wanted to point out that the number didn't come from a random
number generator (or AI).
> Konrad
Iskren
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: Add Shikra CQM SoM platform
From: Dmitry Baryshkov @ 2026-06-17 12:48 UTC (permalink / raw)
To: Kamal Wadhwa
Cc: Rakesh Kota, linux-arm-msm, sashiko-reviews, Komal Bajaj, robh,
linux-phy, neil.armstrong, vkoul, olteanv, krzk+dt, conor+dt,
devicetree
In-Reply-To: <20260518114927.edxbzvklqatlntv2@hu-kamalw-hyd.qualcomm.com>
On Mon, 18 May 2026 at 14:49, Kamal Wadhwa
<kamal.wadhwa@oss.qualcomm.com> wrote:
>
> On Sun, May 17, 2026 at 08:18:15PM +0300, Dmitry Baryshkov wrote:
> > On Thu, May 14, 2026 at 04:09:18PM +0530, Kamal Wadhwa wrote:
> > > On Wed, May 13, 2026 at 06:14:20PM +0300, Dmitry Baryshkov wrote:
> > > > On 13/05/2026 17:29, Rakesh Kota wrote:
> > > > > On Wed, May 13, 2026 at 03:01:47PM +0300, Dmitry Baryshkov wrote:
> > > > > > On Wed, May 13, 2026 at 04:28:35AM +0000, sashiko-bot@kernel.org wrote:
> > > > > > > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > > > > > > - [High] The PMIC regulator definitions omit their required input supply dependencies (e.g., `vdd_s2-supply`, `vdd_l3-supply`), breaking the power hierarchy.
> > > > > > > - [Medium] The device tree inaccurately hardcodes the `compatible` string to a different PMIC model (`qcom,rpm-pm2250-regulators`) instead of explicitly identifying the actual hardware (PM4125).
> > > > > > > --
> > > > > > >
> > > > > > > commit 457abf6e7ac410430c866842e08e602ec3daaa51
> > > > > > > Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> > > > > > >
> > > > > > > arm64: dts: qcom: Add Shikra CQM SoM platform
> > > > > > >
> > > > > > > Add device tree include for the CQM variant of the Shikra System-on-Module.
> > > > > > > This variant integrates the Shikra SoC and PM4125 PMIC. The DTSI includes
> > > > > > > the common shikra.dtsi and adds PM4125 PMIC regulator definitions.
> > > > > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> > > > > > > > new file mode 100644
> > > > > > > > index 0000000000000..401e71720519d
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> > > > > > > [ ... ]
> > > > > > > > +&rpm_requests {
> > > > > > > > + regulators {
> > > > > > > > + compatible = "qcom,rpm-pm2250-regulators";
> > > > > > >
> > > > > > > Since the commit message indicates this is a PM4125 PMIC, should the
> > > > > > > compatible string include a specific identifier for the actual hardware?
> > > > > > >
> > > > > > > Using a specific identifier like "qcom,rpm-pm4125-regulators" alongside
> > > > > > > the fallback allows the kernel to apply specific quirks if PM4125 errata
> > > > > > > are discovered later.
> > > > > >
> > > > > > This can be ignored. The compat is a leftover from the historically
> > > > > > incorrect naming.
> > > > > >
> > > > > > >
> > > > > > > > +
> > > > > > > > + pm4125_s2: s2 {
> > > > > > > > + regulator-min-microvolt = <1000000>;
> > > > > > > > + regulator-max-microvolt = <1200000>;
> > > > > > > > + };
> > > > > > >
> > > > > > > Do these regulators need to explicitly define their input supply dependencies
> > > > > > > such as vdd_s2-supply?
> > > > > > >
> > > > > > > Without these properties, the regulator framework might be unaware that the
> > > > > > > PMIC regulators draw power from upstream supplies.
> > > > > > >
> > > > > > > If the kernel dynamically manages the upstream supply and its reference count
> > > > > > > drops to zero, could it be disabled, causing an unexpected power loss for
> > > > > > > downstream components?
> > > > > >
> > > > > > And this is a correct comment. Please provide missing supplies.
> > > > > >
> > > > > As per the Qualcomm system design, the parent-child supply relationship
> > > > > is managed by the RPM firmware, not the Linux regulator framework. The
> > > > > RPM ensures the parent supply is never disabled until all subsystem
> > > > > votes are cleared.
> > > >
> > > > How is this different from other, previous platforms?
> > >
> > > This is not different. In the previous platforms too this is taken care from the
> > > RPM/RPMH firmware side, the only case where we may need explicit vote to parent
> > > is for non-rpmh/rpm regulator rails (like i2c based regulator pm8008), which
> > > may have a RPM/RPMH regulator as a parent.
> > >
> > > Even on those previous targets the parent rail of all RPM/RPMH regulators are
> > > internally voted by RPM/RPMH FW at proper voltage with required headroom
> > > calculated based on the active child rails. This was done for all the
> > > subsystems (including APPS) regulators.
> > >
> > > So no explicit handling from the APPS is required for parent supply.
> >
> > You are explaining the driver behaviour. But the question is about the
> > hardware description. If there is no difference, please add necessary
> > supplies back.
>
> I understand your concern about descibing the parent-child relation in the
> devicetree, and given that we have been almost always followed this for all
> the previous targets, it will expected of us to add them.
Yes.
>
> However, we want to avoid the unnecessary access to the parent from APPS.
Why? What is the reason? Do we want to do the same for all the
platforms? Only for Shikra? Something else?
> At the moment, I do not see a way to avoid that, if we add the parent
> regulators.
That depend on the answer to the previous question. In the end, we can
make the driver ignore the parents by removing them from the regulator
desc.
>
> @Bjorn, @Konrad - can you please also share your suggestion, how we can add
> parent-child desciption, but avoid accessing parent supply from APPS, as its
> Qualcomm's system design to handle this on RPM/RPMH firmware side (you may
> recall we had a verbal/offline discussion about same concern in context of
> RPMH regulators earlier).
That's why offline discussions are bad - you can't include other
participants in them.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: Add Shikra CQM SoM platform
From: Konrad Dybcio @ 2026-06-17 12:44 UTC (permalink / raw)
To: Kamal Wadhwa, Dmitry Baryshkov
Cc: Rakesh Kota, linux-arm-msm, sashiko-reviews, Komal Bajaj, robh,
linux-phy, neil.armstrong, vkoul, olteanv, krzk+dt, conor+dt,
devicetree
In-Reply-To: <20260518114927.edxbzvklqatlntv2@hu-kamalw-hyd.qualcomm.com>
On 5/18/26 1:49 PM, Kamal Wadhwa wrote:
> On Sun, May 17, 2026 at 08:18:15PM +0300, Dmitry Baryshkov wrote:
>> On Thu, May 14, 2026 at 04:09:18PM +0530, Kamal Wadhwa wrote:
>>> On Wed, May 13, 2026 at 06:14:20PM +0300, Dmitry Baryshkov wrote:
>>>> On 13/05/2026 17:29, Rakesh Kota wrote:
>>>>> On Wed, May 13, 2026 at 03:01:47PM +0300, Dmitry Baryshkov wrote:
>>>>>> On Wed, May 13, 2026 at 04:28:35AM +0000, sashiko-bot@kernel.org wrote:
>>>>>>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>>>>>>> - [High] The PMIC regulator definitions omit their required input supply dependencies (e.g., `vdd_s2-supply`, `vdd_l3-supply`), breaking the power hierarchy.
>>>>>>> - [Medium] The device tree inaccurately hardcodes the `compatible` string to a different PMIC model (`qcom,rpm-pm2250-regulators`) instead of explicitly identifying the actual hardware (PM4125).
>>>>>>> --
>>>>>>>
>>>>>>> commit 457abf6e7ac410430c866842e08e602ec3daaa51
>>>>>>> Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
>>>>>>>
>>>>>>> arm64: dts: qcom: Add Shikra CQM SoM platform
>>>>>>>
>>>>>>> Add device tree include for the CQM variant of the Shikra System-on-Module.
>>>>>>> This variant integrates the Shikra SoC and PM4125 PMIC. The DTSI includes
>>>>>>> the common shikra.dtsi and adds PM4125 PMIC regulator definitions.
>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000000000..401e71720519d
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
>>>>>>> [ ... ]
>>>>>>>> +&rpm_requests {
>>>>>>>> + regulators {
>>>>>>>> + compatible = "qcom,rpm-pm2250-regulators";
>>>>>>>
>>>>>>> Since the commit message indicates this is a PM4125 PMIC, should the
>>>>>>> compatible string include a specific identifier for the actual hardware?
>>>>>>>
>>>>>>> Using a specific identifier like "qcom,rpm-pm4125-regulators" alongside
>>>>>>> the fallback allows the kernel to apply specific quirks if PM4125 errata
>>>>>>> are discovered later.
>>>>>>
>>>>>> This can be ignored. The compat is a leftover from the historically
>>>>>> incorrect naming.
>>>>>>
>>>>>>>
>>>>>>>> +
>>>>>>>> + pm4125_s2: s2 {
>>>>>>>> + regulator-min-microvolt = <1000000>;
>>>>>>>> + regulator-max-microvolt = <1200000>;
>>>>>>>> + };
>>>>>>>
>>>>>>> Do these regulators need to explicitly define their input supply dependencies
>>>>>>> such as vdd_s2-supply?
>>>>>>>
>>>>>>> Without these properties, the regulator framework might be unaware that the
>>>>>>> PMIC regulators draw power from upstream supplies.
>>>>>>>
>>>>>>> If the kernel dynamically manages the upstream supply and its reference count
>>>>>>> drops to zero, could it be disabled, causing an unexpected power loss for
>>>>>>> downstream components?
>>>>>>
>>>>>> And this is a correct comment. Please provide missing supplies.
>>>>>>
>>>>> As per the Qualcomm system design, the parent-child supply relationship
>>>>> is managed by the RPM firmware, not the Linux regulator framework. The
>>>>> RPM ensures the parent supply is never disabled until all subsystem
>>>>> votes are cleared.
>>>>
>>>> How is this different from other, previous platforms?
>>>
>>> This is not different. In the previous platforms too this is taken care from the
>>> RPM/RPMH firmware side, the only case where we may need explicit vote to parent
>>> is for non-rpmh/rpm regulator rails (like i2c based regulator pm8008), which
>>> may have a RPM/RPMH regulator as a parent.
>>>
>>> Even on those previous targets the parent rail of all RPM/RPMH regulators are
>>> internally voted by RPM/RPMH FW at proper voltage with required headroom
>>> calculated based on the active child rails. This was done for all the
>>> subsystems (including APPS) regulators.
>>>
>>> So no explicit handling from the APPS is required for parent supply.
>>
>> You are explaining the driver behaviour. But the question is about the
>> hardware description. If there is no difference, please add necessary
>> supplies back.
>
> I understand your concern about descibing the parent-child relation in the
> devicetree, and given that we have been almost always followed this for all
> the previous targets, it will expected of us to add them.
>
> However, we want to avoid the unnecessary access to the parent from APPS.
> At the moment, I do not see a way to avoid that, if we add the parent
> regulators.
>
> @Bjorn, @Konrad - can you please also share your suggestion, how we can add
> parent-child desciption, but avoid accessing parent supply from APPS, as its
> Qualcomm's system design to handle this on RPM/RPMH firmware side (you may
> recall we had a verbal/offline discussion about same concern in context of
> RPMH regulators earlier).
Can we introduce some flag in idk.. struct regulation_constraints, make it
skip the parts we don't need and set it for all regulators registered in
qcom-rpm(h/smd).c?
Konrad
^ permalink raw reply
* RE: [PATCH v17 01/17] dt-bindings: mmc: renesas,sdhi: Document RZ/G3L (r9a08g046) SoC
From: Biju Das @ 2026-06-17 12:42 UTC (permalink / raw)
To: wsa+renesas, biju.das.au
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, magnus.damm, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad,
Conor Dooley
In-Reply-To: <ajKQ5OzGvWg3kBYa@shikoro>
Hi Wolfram,
Thanks for the feedback.
> -----Original Message-----
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Sent: 17 June 2026 13:20
> Subject: Re: [PATCH v17 01/17] dt-bindings: mmc: renesas,sdhi: Document RZ/G3L (r9a08g046) SoC
>
> Hi Biju,
>
> On Wed, Jun 03, 2026 at 07:57:01AM +0100, Biju wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > Document the RZ/G3L (r9a08g046) SDHI controller. The RZ/G3L SDHI
> > controller is similar to RZ/G2L but has five clocks (core, clkh, cd,
> > aclk, aclkm) and three resets (rst, axim, axis), so update the
> > clocks/clock-names maximum to 5 and resets/reset-names maximum to 3.
> > It has an internal divider for all modes except HS400, and a 2048-bit
> > divider compared to 512 on others.
> >
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
>
> I know you work on v18 already, but some high level remarks already.
OK.
>
> > + - description: ACLK/IACLKS, SDHI channel bus clock.
> > + - description: IACLKM, SDHI channel bus clock m.
>
> What does 's' and 'm' stand for? Is it mentioned in the docs? Would be nice to have here as well, if so.
I know only it is bus clocks. But don't know what is 'bus clock s' and 'bus clock m' stands for.
It could be just clock name.
I will check this with hardware/documentation team and update you.
As per the clock excel sheet,:
SDHI0_IMCLK: "SDHI ch0 main clock 1"
After supplying this clock to SDHI ch0, it is possible to divide the frequency on the SDHI ch0 side and output the clock to the outside.
SDHI0_IMCLK2: "SDHI ch0 main clock 2"
Input is always required even when suspending.
When this clock is turned off, external SD card connection (Card Detect) cannot be detected."
SDHI0_CLK_HS: "SDHI ch0 High speed clock
This clock always operates with a relationship of 2 times that of SDHI ch0 main clock 1.
Must be supplied when using SDR104, HS200.
It can be stopped when suspended. "
SDHI0_IACLKS: "SDHI ch0 bus clock
It can be stopped when suspended. "
SDHI0_IACLKM: "SDHI ch0 bus clock
It can be stopped when suspended. "
>
> > + resets:
> > + items:
> > + - description: rst, Core reset.
> > + - description: axim, SDHI axi bus reset m.
> > + - description: axis, SDHI axi bus reset s.
>
> Ditto.
The reset signal mentioned in the hardware manual are
SDHIx_IXRST, SDHIx_IXRSTAXIM and SDHIx_IXRSTAXIS (where x=0,1,2)
I will check this as well with hardware/documentation team and update you.
Cheers,
Biju
>
> Happy hacking,
>
> Wolfram
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: sm8650-ayaneo-pocket-s2: add display nodes
From: Konrad Dybcio @ 2026-06-17 12:37 UTC (permalink / raw)
To: Neil Armstrong, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: linux-arm-msm, devicetree, linux-kernel, linux-renesas-soc,
KancyJoe
In-Reply-To: <20260522-topic-sm8650-ayaneo-pocket-s2-display-dt-v2-1-cdd4b70e5a16@linaro.org>
On 5/22/26 3:15 PM, Neil Armstrong wrote:
> From: KancyJoe <kancy2333@outlook.com>
>
> Add nodes for the dual DSI panel, the SGM3804 regulator, the
> SY7758 backlight controller, the touch controller, and enable
> the GPU to enable full display support.
>
> Signed-off-by: KancyJoe <kancy2333@outlook.com>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> Depends on follwing bindings, all reviewed:
> - https://lore.kernel.org/all/20260522-topic-sm8650-ayaneo-pocket-s2-r63419-v6-1-16edddda9951@linaro.org/
> - https://lore.kernel.org/all/20260521-topic-sm8650-ayaneo-pocket-s2-sy7758-v4-1-73c732615e4a@linaro.org/
> - https://lore.kernel.org/all/20260522-topic-sm8650-ayaneo-pocket-s2-sgm3804-v5-1-bd6b1c300ecc@linaro.org/
> ---
> Changes in v2:
> - Update for bindings changes
> - Remove empty line
> - Link to v1: https://patch.msgid.link/20260428-topic-sm8650-ayaneo-pocket-s2-display-dt-v1-1-ff132c00d076@linaro.org
> ---
> .../boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 241 +++++++++++++++++++++
> 1 file changed, 241 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> index 0dc994f4e48d..af890e76813b 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> @@ -220,6 +220,22 @@ upd720201_vdd33_reg: upd720201-vdd33-regulator {
> pinctrl-names = "default";
> };
>
> + sy7758_vdd33_reg: sy7758-vdd33-regulator {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "sy7758_vdd33";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpios = <&tlmm 163 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + vin-supply = <&vph_pwr>;
> +
> + pinctrl-0 = <&sy7758_vdd33>;
> + pinctrl-names = "default";
regulator-boot-on would be my guess, probably also on the other
disp regulators
Konrad
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: sm8650-ayaneo-pocket-s2: add display nodes
From: Konrad Dybcio @ 2026-06-17 12:36 UTC (permalink / raw)
To: Neil Armstrong, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: linux-arm-msm, devicetree, linux-kernel, linux-renesas-soc,
KancyJoe
In-Reply-To: <20260522-topic-sm8650-ayaneo-pocket-s2-display-dt-v2-1-cdd4b70e5a16@linaro.org>
On 5/22/26 3:15 PM, Neil Armstrong wrote:
> From: KancyJoe <kancy2333@outlook.com>
>
> Add nodes for the dual DSI panel, the SGM3804 regulator, the
> SY7758 backlight controller, the touch controller, and enable
> the GPU to enable full display support.
>
> Signed-off-by: KancyJoe <kancy2333@outlook.com>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
[...]
> + /* Backlight */
> + sy7758_backlight: sy7758@2e {
If it's the only one, 'backlight:' is good for the label. The node name
must definitely be backlight@, as those are supposed to be generic
> + compatible = "silergy,sy7758";
> + reg = <0x2e>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&sy7758_default>;
Please use this order, everywhere:
property-n
property-names
otherwise:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Konrad Dybcio @ 2026-06-17 12:32 UTC (permalink / raw)
To: Dmitry Baryshkov, Daniel Lezcano
Cc: Gaurav Kohli, Krzysztof Kozlowski, Bjorn Andersson,
Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <4gs664zboaqgpok33x7bgorfmhh3f2fahjkt4jjl6fbzpwixnm@hxzz2xeogd4k>
On 6/16/26 12:15 AM, Dmitry Baryshkov wrote:
> On Mon, Jun 15, 2026 at 05:33:15PM +0200, Daniel Lezcano wrote:
>>
>>
>> Le 15/06/2026 à 17:14, Dmitry Baryshkov a écrit :
>>> On Mon, Jun 15, 2026 at 04:33:38PM +0200, Daniel Lezcano wrote:
[...]
>>> I was thinking about something like:
>>>
>>> #define QCOM_TMD_DSP 0
>>> #define QCOM_TMD_PA 1
>>
>> Ah ok, it is correct if:
>>
>> tmd-names = "dsp", "pa"
>>
>> Or
>>
>> #define QCOM_TMD_PA 0
>> #define QCOM_TMD_DSP 1
>>
>> tmd-names = "pa", "dsp"
>
> I was more inclined about having the standard indices for the standard
> mitigations.
>
> BTW, I checked, which mitigations are being returned by the DSPs. Few
> examples, just to provide some context.
>
> SC8280XP, X13s:
>
> TMD service: instance=0x01 (adsp) node=5 port=9
> 1 mitigation device(s):
> [ 0] cpuv_restriction_cold max_mitigation_level=1
>
> TMD service: instance=0x53 (slpi) node=9 port=9
> 1 mitigation device(s):
> [ 0] cpuv_restriction_cold max_mitigation_level=1
So, are we converging towards something like:
-- include/dt-bindings/...
/* Common indices for all devices */
#define QCOM_TMD_FOO 0
#define QCOM_TMD_BAR 1
-- qcom_tmd.c
static const char * const mitigation_map[] = {
[QCOM_TMD_FOO] = "mmw_skin1_dsc",
[QCOM_TMD_BAR] = "cpuv_restriction_cold",
};
...
static int qcom_tmd_retrieve_avail_mitigations(...) {
data = qmi_get_data(...);
while (data.tmd_list++) {
// mark available on this rproc
}
}
?
Perhaps split from a global index space to DSP-specific indices
given Dmitry's list that reveals there's a lot of variability?
Konrad
^ permalink raw reply
* Re: [PATCH 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: sashiko-bot @ 2026-06-17 12:32 UTC (permalink / raw)
To: Gerald Loacker
Cc: conor+dt, devicetree, neil.armstrong, olteanv, vkoul, linux-phy,
robh
In-Reply-To: <20260617-feature-mipi-csi-dphy-4k60-v1-3-4611ff00b0ff@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 bfbb498bdd0c6aad9c80d6fe31b34f8a03261c76
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
This commit adds support for parsing and applying the optional
'rockchip,clk-lane-phase' device tree property. It allows for board-specific
tuning of the clock lane sampling phase. If the property is absent, the driver
relies on the hardware default without actively writing to the register.
> 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]
This isn't a bug, but it looks like CSIDPHY_CLK_PHASE_DEFAULT is defined
here but never actually used in the driver code.
Since the fallback logic correctly relies on leaving the hardware at its
default state when the device tree property is missing (by initializing
clk_phase to -1), could this unused macro be removed to avoid keeping
dead code around?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net?part=3
^ permalink raw reply
* Re: [PATCH 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: sashiko-bot @ 2026-06-17 12:31 UTC (permalink / raw)
To: Gerald Loacker
Cc: devicetree, neil.armstrong, conor+dt, vkoul, robh, olteanv,
linux-phy
In-Reply-To: <20260617-feature-mipi-csi-dphy-4k60-v1-1-4611ff00b0ff@wolfvision.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Valid low-frequency ranges mapping to configuration bit 0x00 are incorrectly rejected as errors.
--
commit 73e8683965255c344bec41b44d480c1cece33b57
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
This commit extends the final entry in the rk1808 hsfreq table to exactly
2500 Mbps. This allows the RK3588, which reuses this array, to fully
support rates up to 2500 Mbps.
> 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 is a pre-existing issue, but while looking at these frequency range
tables it appears that valid low-frequency configurations are incorrectly
rejected as errors.
In rockchip_inno_csidphy_configure(), the code iterates through the
hsfreq_ranges to find the cfg_bit:
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c:rockchip_inno_csidphy_configure() {
...
if (!hsfreq)
return -EINVAL;
...
}
The rk3326_mipidphy_hsfreq_ranges table defines an entry for frequencies up
to 109 Mbps with a valid cfg_bit of 0x00:
{ 109, 0x00}, { 149, 0x01}, { 199, 0x02}, { 249, 0x03},
If the data rate falls into this lowest range, hsfreq is correctly set
to 0x00, but the subsequent if (!hsfreq) check evaluates to true and
incorrectly returns -EINVAL instead of applying the configuration.
A similar issue appears in rk_dphy_configure() inside
drivers/phy/rockchip/phy-rockchip-dphy-rx0.c with tables like
rk3399_mipidphy_hsfreq_ranges which has { 89, 0x00 }.
Could this validation be modified to verify if a valid match was found
during iteration rather than checking if the resulting configuration bit
is non-zero?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net?part=1
^ permalink raw reply
* [PATCH 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: Gerald Loacker @ 2026-06-17 12:23 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: <20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@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
* [PATCH 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-17 12:23 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: <20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@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>
---
Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++
1 file changed, 7 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..0d824d1511bc0 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
@@ -56,6 +56,13 @@ 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 in 40 ps steps. The hardware default is 3.
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: Gerald Loacker @ 2026-06-17 12:23 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: <20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@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 0/3] phy: rockchip: inno-csidphy: fix 2500 Mbps support and add clock lane phase tuning
From: Gerald Loacker @ 2026-06-17 12:23 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.
---
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 | 7 ++++++
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 27 +++++++++++++++++++++-
2 files changed, 33 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
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