* RE: [PATCH v5 3/4] iio: adc: ad4691: add triggered buffer support
From: Sabau, Radu bogdan @ 2026-03-30 9:01 UTC (permalink / raw)
To: Nuno Sá, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <324e16aba4029ec4679f7b141c5f58e8929a0da3.camel@gmail.com>
> -----Original Message-----
> From: Nuno Sá <noname.nuno@gmail.com>
> Sent: Saturday, March 28, 2026 11:44 AM
> To: Sabau, Radu bogdan <Radu.Sabau@analog.com>; Lars-Peter Clausen
...
);
> >
> > - return 0;
> > + if (st->manual_mode)
> > + return 0;
> > +
> > + for (gp_num = 0; gp_num < ARRAY_SIZE(ad4691_gp_names);
> gp_num++) {
> > + if (fwnode_irq_get_byname(dev_fwnode(dev),
> > + ad4691_gp_names[gp_num]) > 0)
>
> Don't love this line break. I'm also a bit puzzled. How does the above differs
> from
> the trigger code? I guess this should be the same GP pin?
>
>
Hi Nuno,
You are right - both loops scan ad4691_gp_names[] independently and must
agree by construction, which is fragile. While gpio_setup() needs to happen,
there is no reason for it to live on ad4691_config(), since setup_triggered_buffer
is only called for the non-offload path and already iterates gp_names[] to find
the IRQ. So we can call gpio_setup right there and frop the lookup from
ad4691_config() entirely, and no need for those early returns either.
Thanks,
Radu
^ permalink raw reply
* Re: [PATCH v3 7/9] regulator: mt6392: Add support for MT6392 regulator
From: Chen-Yu Tsai @ 2026-03-30 9:35 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Gary Bisson, Louis-Alexis Eyraud, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2J355NZH=7iQ9sTDBhAmtjP7xTpXe21_3Z9J_R5YvdXAQ@mail.gmail.com>
On Mon, Mar 30, 2026 at 3:39 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> Il giorno gio 19 mar 2026 alle ore 06:04 Chen-Yu Tsai
> <wenst@chromium.org> ha scritto:
>
> > If this PMIC is anything like the MT6358, then it has 0.01V fine
> > tuning for most if not all the LDOs. It is sometimes needed as
> > a rail may have a 0.04V boost that would otherwise be invisible
> > to the system. And then if you have something like 3.04V set in
> > the DT constraints, you end up with something the regulator driver
> > doesn't support, but the hardware does.
> >
> > Please see how it's done in the MT6358 driver. I spent a lot of
> > time on that driver to make it actually support the full range
> > of voltages, and describing the supplies.
> >
>
> I had a good look at the datasheet (MT6392 PMIC Datasheet v1.0 08 Dec.
> 2016) and unfortunately I did not see any fine tuning option in there.
> I'm sure this data sheet is not perfect as it's missing some regulator
> registers that are clearly used in the Android sources, but there's no
> mention of fine tuning in that code either. I guess it does not have
> that capability.
Well, thanks for looking. FWIW on the MT6358 / MT6366, the main voltage
control and the fine tuning are mostly in the same register. The fine
tuning is described as "calibrates output voltage" from +00mV to +100mV.
I looked into this because the LDO table shows some of the default voltages
with 0.01V precision, but the main voltage controls only have 0.1V precision.
ChenYu
> I will shortly submit v4 that hopefully addresses the rest of the comments.
>
> Thanks for your help!
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac-sku support
From: Umang Chheda @ 2026-03-30 9:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <7f5bfeb8-7d91-419b-981d-1f0f568f01d2@kernel.org>
Hello Krzysztof,
On 3/30/2026 12:24 PM, Krzysztof Kozlowski wrote:
> On 30/03/2026 08:50, Umang Chheda wrote:
>> Hello Krzysztof,
>>
>> On 3/29/2026 3:22 PM, Krzysztof Kozlowski wrote:
>>> On Sat, Mar 28, 2026 at 05:11:17PM +0530, Umang Chheda wrote:
>>>> Introduce new bindings for the monaco-evk-ac-sku,
>>>> an IoT board based on the QCS8300-AC variant SoC.
>>> Please wrap commit message according to Linux coding style / submission
>>> process (neither too early nor over the limit):
>>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>>
>>
>> Ack
>>
>>>
>>>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> index ca880c105f3b..07053cc2ac1c 100644
>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> @@ -918,6 +918,7 @@ properties:
>>>> - enum:
>>>> - arduino,monza
>>>> - qcom,monaco-evk
>>>> + - qcom,monaco-evk-ac-sku
>>> Why adding name 'sku' to the compatible? What's the meaning here?
>>
>>
>> Monaco SoC has 2 variants - monaco-aa and monaco-ac -- "monaco-evk" board uses monaco-aa variant of SoC and this new
>
> so ac? or ac-sku? Decide.
>
>> introduced board uses the monaco-ac variant SoC. Hence added the compatible as "monaco-evk-ac-sku" to differentiate it from
>> monaco-evk board.
>
> Wrap your emails.
Ack
>
> "ac" differentiates. Why do you need to say that a variant is a
> "-variant"?
>
The intent for using "-sku" here was to match the existing upstream
practice where boards that are otherwise identical but differ in H/W
configuration (SoC variant, storage etc) are represented as separate SKUs.
For Example:
- sc7180-trogdor-*-sku.dtsi
- sc7280-herobrine-*-sku.dtsi
- mt8183-kukui-jacuzzi-*-sku.dts
Hence to follow the above convention and practice - Added "-sku" in the end.
Please let me know your preference ? if it is okay dropping "-sku" - I
will re-spin v2 with suggested changes.
> Best regards,
> Krzysztof
Thanks,
Umang
^ permalink raw reply
* Re: [PATCH v5 0/9] riscv: spacemit: enable SD card support with UHS modes for OrangePi RV2
From: Michael Opdenacker @ 2026-03-30 9:19 UTC (permalink / raw)
To: Iker Pedrosa, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Adrian Hunter, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: michael.opdenacker, Javier Martinez Canillas, linux-mmc,
devicetree, linux-riscv, spacemit, linux-kernel, Anand Moon,
Trevor Gamblin
In-Reply-To: <20260330-orangepi-sd-card-uhs-v5-0-bd853604322d@gmail.com>
Hi Iker
On 3/30/26 10:38 AM, Iker Pedrosa wrote:
> This series enables complete SD card support for the Spacemit K1-based
> OrangePi RV2 board, including UHS (Ultra High Speed) modes for
> high-performance SD card operation.
>
> Background
>
> The Spacemit K1 SoC includes an SDHCI controller capable of supporting
> SD cards up to UHS-I speeds (SDR104 at 208MHz). However, mainline
> currently lacks basic SD controller configuration, SDHCI driver
> enhancements for voltage switching and tuning, and power management
> infrastructure.
>
> Implementation
>
> The series enables SD card support through coordinated layers:
>
> - Hardware infrastructure (patches 1-2): Device tree bindings for voltage
> switching hardware and essential clock infrastructure.
> - SDHCI driver enhancements (patches 3-7): Regulator framework
> integration, pinctrl state switching for voltage domains, AIB register
> programming, and comprehensive SDR tuning support for reliable UHS
> operation.
> - SoC and board integration (patches 8-10): Complete K1 SoC controller
> definitions, PMIC power infrastructure, and OrangePi RV2 board enablement
> with full UHS support.
>
> This transforms the OrangePi RV2 from having no SD card support to full
> UHS-I capability, enabling high-performance storage up to 208MHz.
>
> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
> ---
> Changes in v5:
> - Document optional pinctrl-names property supporting "default" and
> "state_uhs" pinctrl states for coordinating pin configuration changes
> during UHS-I voltage switching.
> - Link to v4: https://lore.kernel.org/r/20260323-orangepi-sd-card-uhs-v4-0-567c9775fd0e@gmail.com
Thanks for the update!
Successfully tested on OrangePi RV2 (on top of mmc-next... doesn't work
on top of master).
Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
I'm excited to have this feature in the next kernel.
Cheers
Michael.
--
Root Commit
Embedded Linux Training and Consulting
https://rootcommit.com
^ permalink raw reply
* [PATCH] arm64: dts: qcom: kaanapali: Duplicate whitespace cleanup
From: Jingyi Wang @ 2026-03-30 9:39 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel, Jingyi Wang
Exactly one space is expected before '{' characters, clean
up duplicate whitespaces.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index ef6add4e5a90..7cc326aa1a1a 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -5838,7 +5838,7 @@ compute-cb@13 {
};
/* Cluster 0 */
- pmu@310b3400 {
+ pmu@310b3400 {
compatible = "qcom,kaanapali-cpu-bwmon", "qcom,sdm845-bwmon";
reg = <0x0 0x310b3400 0x0 0x600>;
@@ -5899,7 +5899,7 @@ opp-10 {
};
/* Cluster 1 */
- pmu@310b7400 {
+ pmu@310b7400 {
compatible = "qcom,kaanapali-cpu-bwmon", "qcom,sdm845-bwmon";
reg = <0x0 0x310b7400 0x0 0x600>;
---
base-commit: 66ba480978ce390e631e870b740a3406e3eb6b01
change-id: 20260330-knp-space-cleanup-ea20d5e8bba4
Best regards,
--
Jingyi Wang <jingyi.wang@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v3 2/3] thermal: spacemit: k1: Add thermal sensor support
From: Troy Mitchell @ 2026-03-30 9:42 UTC (permalink / raw)
To: Shuwei Wu, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Troy Mitchell
In-Reply-To: <20260119-patchv2-k1-thermal-v3-2-3d82c9ebe8a4@163.com>
On Mon, Jan 19, 2026 at 10:41:22 CST, Shuwei Wu wrote:
> The thermal sensor on K1 supports monitoring five temperature zones.
> The driver registers these sensors with the thermal framework
> and supports standard operations:
> - Reading temperature (millidegree Celsius)
> - Setting high/low thresholds for interrupts
>
> Signed-off-by: Shuwei Wu <shuweiwoo@163.com>
Thanks for your patch.
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
^ permalink raw reply
* [PATCH v3 0/2] Enable audio support for J721S2 EVM
From: Moteen Shah @ 2026-03-30 9:44 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
This patch series, adds support for analog audio on J721S2 EVM using
device tree overlays.
Earlier version of the patchset sent upstream[0] was rejected as
its dependency[1], which resolves the DTBS check errors introduced
by [0] also got rejected on the grounds of ABI breakage.
Another solution to fix the DTBS check errors introduced by [0] is
to modify the ti,j721e-system-controller.yaml binding to allow
audio-refclk as clock-controller child. This is done in the first
patch of this series.
Changes since v2:
Link to v2: https://lore.kernel.org/all/20260205130707.2033197-1-m-shah@ti.com/
- Fix Makefile entries to follow alphabetical ordering
- Update model string from "j721e-cpb" to "j721s2-cpb"
- Fix gpio-line-names typo: "UBS926_PWR_SW_CNTRL" -> "UB926_PWR_SW_CNTRL"
Changes since v1:
Link to v1: https://lore.kernel.org/all/20260112104536.83309-1-m-shah@ti.com/
- Convert the changes to an overlay
- Enumerate the I2C mux used
- Remove CANUART_MUX_SEL1 gpio hog
- Fix typos
- Add gpio-line-names
- Fix commit message to showcase the right idle-state for muxes
- Carry review from Rob and Hari
Test log: https://gist.github.com/Jamm02/4d4c00bf88fa76cddae6319124341c53
[0]: https://lore.kernel.org/linux-arm-kernel/20250604104656.38752-1-j-choudhary@ti.com/
[1]: https://lore.kernel.org/all/20250603095609.33569-4-j-choudhary@ti.com/
Jayesh Choudhary (1):
arm64: dts: ti: Add audio overlay for k3-j721s2-evm
Moteen Shah (1):
ti,j721e-system-controller.yaml: Allow audio-refclk as
clock-controller child
.../soc/ti/ti,j721e-system-controller.yaml | 6 +-
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 161 ++++++++++++++++++
3 files changed, 169 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
--
2.34.1
^ permalink raw reply
* [PATCH v3 1/2] ti,j721e-system-controller.yaml: Allow audio-refclk as clock-controller child
From: Moteen Shah @ 2026-03-30 9:44 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260330094459.128648-1-m-shah@ti.com>
The ti,j721e-system-controller binding currently only allows
clock-controller@ child nodes to reference the ti,am654-ehrpwm-tbclk
schema. However, the system controller on J721S2 also contains audio
reference clock controllers (ti,am62-audio-refclk) that use the same
clock-controller@XXXX naming pattern.
Hence, extend the clock-controller pattern to accept either ehrpwm-tbclk
or audio-refclk schemas using a oneOf constraint.
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
.../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
index f3bd0be3b279..d5d84a8f1257 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
@@ -53,9 +53,11 @@ patternProperties:
"^clock-controller@[0-9a-f]+$":
type: object
- $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
+ oneOf:
+ - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
+ - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
description:
- Clock provider for TI EHRPWM nodes.
+ Clock provider for TI EHRPWM or Audio Reference Clock nodes.
"phy@[0-9a-f]+$":
type: object
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm
From: Moteen Shah @ 2026-03-30 9:44 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260330094459.128648-1-m-shah@ti.com>
From: Jayesh Choudhary <j-choudhary@ti.com>
Add device tree overlay to enable analog audio support on J721S2-EVM
using PCM3168A codec connected to McASP4 serializers.
- Add nodes for sound-card, audio codec, I2C3 and McASP4
- Add pinmux for I2C3, McASP4, AUDIO_EXT_REFCLK1 and WKUP_GPIO_0
- Add GPIO expander (TCA6408) for codec control
- Add GPIO hogs to route I2C3 lines and McASP serializers
- Set idle-state to 0 in mux0 and mux1 for McASP signal routing
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Co-developed-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 161 ++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index ba01a929e06f..17048f2f5043 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-audio.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
@@ -264,6 +265,8 @@ k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie1-ep.dtbo
k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-j721s2-evm-audio-dtbs := k3-j721s2-common-proc-board.dtb \
+ k3-j721s2-evm-audio.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
k3-j721s2-evm-pcie1-ep.dtbo
k3-j721s2-evm-usb0-type-a-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -328,6 +331,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
+ k3-j721s2-evm-audio.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
new file mode 100644
index 000000000000..2a3ff1cfc650
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Device Tree Overlay for J721S2 Audio Support
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "k3-pinctrl.h"
+
+&{/} {
+ codec_audio: sound {
+ compatible = "ti,j7200-cpb-audio";
+ model = "j721s2-cpb";
+
+ ti,cpb-mcasp = <&mcasp4>;
+ ti,cpb-codec = <&pcm3168a_1>;
+
+ clocks = <&k3_clks 213 0>, <&k3_clks 213 1>,
+ <&k3_clks 157 299>, <&k3_clks 157 328>;
+ clock-names = "cpb-mcasp-auxclk", "cpb-mcasp-auxclk-48000",
+ "cpb-codec-scki", "cpb-codec-scki-48000";
+ };
+
+ i2c_mux: mux-controller-2 {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ mux-gpios = <&wkup_gpio0 54 GPIO_ACTIVE_HIGH>;
+ idle-state = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_mux_pins_default>;
+ };
+};
+
+&main_pmx0 {
+ mcasp4_pins_default: mcasp4-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x0c8, PIN_OUTPUT_PULLDOWN, 1) /* (AD28) MCASP4_ACLKX */
+ J721S2_IOPAD(0x06c, PIN_OUTPUT_PULLDOWN, 1) /* (V26) MCASP4_AFSX */
+ J721S2_IOPAD(0x068, PIN_INPUT_PULLDOWN, 1) /* (U28) MCASP4_AXR1 */
+ J721S2_IOPAD(0x0c4, PIN_OUTPUT_PULLDOWN, 1) /* (AB26) MCASP4_AXR2 */
+ J721S2_IOPAD(0x070, PIN_OUTPUT_PULLDOWN, 1) /* (R27) MCASP4_AXR3 */
+ >;
+ };
+
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x078, PIN_OUTPUT, 1) /* (Y25) MCAN2_RX.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+};
+
+&wkup_pmx2 {
+ main_i2c3_mux_pins_default: main-i2c3-mux-default-pins {
+ pinctrl-single,pins = <
+ J721S2_WKUP_IOPAD(0x038, PIN_OUTPUT, 7) /* (B27) WKUP_GPIO0_54 */
+ >;
+ };
+};
+
+&exp2 {
+ p09-hog {
+ /* P09 - MCASP/TRACE_MUX_S0 */
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "MCASP/TRACE_MUX_S0";
+ };
+
+ p10-hog {
+ /* P10 - MCASP/TRACE_MUX_S1 */
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MCASP/TRACE_MUX_S1";
+ };
+};
+
+&mux0 {
+ idle-state = <0>;
+};
+
+&mux1 {
+ idle-state = <0>;
+};
+
+&scm_conf {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ audio_refclk1: clock-controller@42e4 {
+ compatible = "ti,am62-audio-refclk";
+ reg = <0x42e4 0x4>;
+ clocks = <&k3_clks 157 299>;
+ assigned-clocks = <&k3_clks 157 299>;
+ assigned-clock-parents = <&k3_clks 157 328>;
+ #clock-cells = <0>;
+ };
+};
+
+&k3_clks {
+ /* Configure AUDIO_EXT_REFCLK1 pin as output */
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+};
+
+&main_i2c3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_pins_default>;
+ clock-frequency = <400000>;
+ mux-states = <&i2c_mux 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ exp3: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "CODEC_RSTZ", "CODEC_SPARE1",
+ "UB926_RESETN", "UB926_LOCK",
+ "UB926_PWR_SW_CNTRL", "UB926_TUNER_RESET",
+ "UB926_GPIO_SPARE";
+ };
+
+ pcm3168a_1: audio-codec@44 {
+ compatible = "ti,pcm3168a";
+ reg = <0x44>;
+ #sound-dai-cells = <1>;
+ reset-gpios = <&exp3 0 GPIO_ACTIVE_LOW>;
+ clocks = <&audio_refclk1>;
+ clock-names = "scki";
+ VDD1-supply = <&vsys_3v3>;
+ VDD2-supply = <&vsys_3v3>;
+ VCCAD1-supply = <&vsys_5v0>;
+ VCCAD2-supply = <&vsys_5v0>;
+ VCCDA1-supply = <&vsys_5v0>;
+ VCCDA2-supply = <&vsys_5v0>;
+ };
+};
+
+&mcasp4 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcasp4_pins_default>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ auxclk-fs-ratio = <256>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 2 1 1
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-03-30 9:46 UTC (permalink / raw)
To: Dmitry Baryshkov, Bryan O'Donoghue
Cc: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, linux-arm-msm, linux-phy,
linux-media, devicetree, linux-kernel
In-Reply-To: <r767islbwq2a3m6rf4wvl4hxzafdsw74jhev7jjz665kfymn56@vcn4p233n74f>
On 3/29/26 12:54 PM, Dmitry Baryshkov wrote:
> On Fri, Mar 27, 2026 at 11:40:51PM +0000, Bryan O'Donoghue wrote:
>> On 27/03/2026 23:23, Dmitry Baryshkov wrote:
>>> On Sat, Mar 28, 2026 at 01:12:22AM +0200, Vladimir Zapolskiy wrote:
>>>> On 3/28/26 00:29, Bryan O'Donoghue wrote:
>>>>> On 27/03/2026 20:51, Dmitry Baryshkov wrote:
>>>>>>> That's just not true. If you read the camx source code you can see
>>>>>>> split/combo mode 2+1 1+1 data/clock mode requires special programming of the
>>>>>>> PHY to support.
>>>>>> This needs to be identified from the data-lanes / clock-lanes topology.
>>>>>> And once you do that, there would be (probably) no difference in the
>>>>>> hardware definition.
>>>>>>
>>>>>>
>>>>>> In other words, I'd also ask to drop this mode from the DT. This
>>>>>> infromation can and should be deduced from other, already-defined
>>>>>> properties.
>>>>>
>>>>> It still needs to be communicated to the PHY from the controller,
>>>>> however that is not a problem I am trying to solve now.
>>>>>
>>>>> If I can't get consensus for PHY_QCOM_CSI2_MODE_SPLIT_DPHY then so be it.
>>>>>
>>>>> I'll aim for DPHY only and we can come back to this topic when someone
>>>>> actually tries to enable it.
>>>>>
>>>>
>>>> DPHY may be the only supported phy type in the driver, it does not matter
>>>> at this point, however it's totally essential to cover the called by you
>>>> 'split mode' right from the beginning in the renewed device tree binding
>>>> descriptions of CAMSS IPs to progress further.
>>>
>>> Okay. How would we describe that there are two sensors connected to the
>>> single PHY anyway? How would it be described with the current bindings?
>>>
>>> --
>>> With best wishes
>>> Dmitry
>>
>> Assuming you add endpoints to the PHY i.e. that is what Neil appears to be
>> asking for and I personally am _fine_ with that, then it should just be
>>
>> port@0
>> port@1
>>
>> if port@1 exists, you know you are in split-phy mode.
>>
>> Its actually straight forward enough, really. To be clear though I can write
>> that yaml - the _most_ support I'm willing to put into the PHY code is to
>> detect the port@1 and say "nope not supported yet", since like CPHY its not.
>
> SGTM. But let's define the schema for those usecases.
Let's perhaps also add a short example for both a single- and dual-sensor
cases in the YAML, even if there's no plans to support the latter
configuration now
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac-sku support
From: Krzysztof Kozlowski @ 2026-03-30 9:47 UTC (permalink / raw)
To: Umang Chheda
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <a39ca7b7-b277-4518-ad45-1f42506b615e@oss.qualcomm.com>
On 30/03/2026 11:36, Umang Chheda wrote:
> Hello Krzysztof,
>
> On 3/30/2026 12:24 PM, Krzysztof Kozlowski wrote:
>> On 30/03/2026 08:50, Umang Chheda wrote:
>>> Hello Krzysztof,
>>>
>>> On 3/29/2026 3:22 PM, Krzysztof Kozlowski wrote:
>>>> On Sat, Mar 28, 2026 at 05:11:17PM +0530, Umang Chheda wrote:
>>>>> Introduce new bindings for the monaco-evk-ac-sku,
>>>>> an IoT board based on the QCS8300-AC variant SoC.
>>>> Please wrap commit message according to Linux coding style / submission
>>>> process (neither too early nor over the limit):
>>>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>>>
>>>
>>> Ack
>>>
>>>>
>>>>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>>>>> ---
>>>>> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>> index ca880c105f3b..07053cc2ac1c 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>> @@ -918,6 +918,7 @@ properties:
>>>>> - enum:
>>>>> - arduino,monza
>>>>> - qcom,monaco-evk
>>>>> + - qcom,monaco-evk-ac-sku
>>>> Why adding name 'sku' to the compatible? What's the meaning here?
>>>
>>>
>>> Monaco SoC has 2 variants - monaco-aa and monaco-ac -- "monaco-evk" board uses monaco-aa variant of SoC and this new
>>
>> so ac? or ac-sku? Decide.
>>
>>> introduced board uses the monaco-ac variant SoC. Hence added the compatible as "monaco-evk-ac-sku" to differentiate it from
>>> monaco-evk board.
>>
>> Wrap your emails.
>
> Ack
>>
>> "ac" differentiates. Why do you need to say that a variant is a
>> "-variant"?
>>
>
> The intent for using "-sku" here was to match the existing upstream
> practice where boards that are otherwise identical but differ in H/W
> configuration (SoC variant, storage etc) are represented as separate SKUs.
>
> For Example:
> - sc7180-trogdor-*-sku.dtsi
> - sc7280-herobrine-*-sku.dtsi
> - mt8183-kukui-jacuzzi-*-sku.dts
We talk about compatible, why any of DTS names matter? You don't
understand the meaning of sku. It makes no sense without the number/ID.
It's like you called it "-revision"...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: x1e80100-dell-xps13-9345: enable onboard accelerometers
From: Aleksandrs Vinarskis @ 2026-03-30 9:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, laurentiu.tudor1,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <l3cfeezstqrabhgba2xnzciztfwp6ijunzemlb5uanpxhgmscu@kh3jdcc2dhbj>
On Monday, March 23rd, 2026 at 18:05, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Mon, Mar 23, 2026 at 04:06:53PM +0100, Konrad Dybcio wrote:
> > On 3/2/26 2:25 PM, Aleksandrs Vinarskis wrote:
> > >
> > > On Monday, March 2nd, 2026 at 13:14, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> > >
> > >> On 2/28/26 6:46 PM, Aleksandrs Vinarskis wrote:
> > >>> Particular laptop comes with two sets of sensors:
> > >>> 1. Motherboard: accelerometer
> > >>> 2. Display/Camera module: accelerometer, ambient ligth (and more)
> > >>> sensor
> > >>>
> > >>> Define both i2c busses (bitbanged), sensors and respective rotation
> > >>> matrices.
> > >>
> > >> These GPIOs correspond to ADSP/SSC-bound QUPs. It may be that you're
> > >> poking at the same bus as the DSP is, concurrently.
> > >
> > > Indeed, Val already pointed out that there is hexagonrpcd to access
> > > sensors behind Sensor Core from DSP. I found corresponding .json sensor
> > > files in Windows for all x3 sensors, but could not make it work yet.
> > >
> > > Without these additional things in userspace it does not cause any
> > > conflicts: I've been using this for a week now, no i2c communication
> > > issues and device orientation information is present.
> > >
> > > The question is then if we want to keep this series which ignores DSP
> > > capabilities with the advantage that it will work for everyone with
> > > the new kernel vs doing it 'correct' way over DSP which requires
> > > additional json (and binary blobs?) and userpsace configuration,
> > > meaning that most users will never have these sensors?
> >
> > I don't know what's the endgame for sensors. Maybe +Dmitry knows whether
> > there's any action on that point.
> >
> > Going through the DSP allows you to keep aggregating the data at close
> > to no power cost (""low power island""), notably without waking up the
> > CPUs if there's no other work. That, plus I'm somewhat skeptical about
> > going behind its back, since it may be that a firmware update or some
> > other trigger makes it start trying to communicate with them.
>
> The sensors story would require DSP libraries matching the firmware,
> sensors descriptions and several still-closed-source libraries to work.
> There is an open-source libssc project, but I don't know if anybody has
> tested it on this platform (and it will still require DSP libs to
> function).
>
> >
> > But I'm not 100% against this either
>
> I guess it is a necessary evil until we get libssc to work on it.
Thanks everyone for the input.
It sounds that long-term DSP is clearly a go-for solution, but at
the current state bit-banging is acceptable way to provide this
functionality. I will update my patch to reflect outcome of this
discussion in v2.
Regards,
Alex
>
> --
> With best wishes
> Dmitry
>
^ permalink raw reply
* Re: [PATCH v2] dts: riscv: spacemit: k3: Add i2c nodes
From: Troy Mitchell @ 2026-03-30 9:50 UTC (permalink / raw)
To: Yixun Lan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: spacemit, devicetree, linux-riscv, linux-kernel, Troy Mitchell
In-Reply-To: <20260327-02-k3-i2c-v2-1-2119c0918868@kernel.org>
Hi Yixun,
On Fri, Mar 27, 2026 at 19:40:40 CST, Yixun Lan wrote:
> Populate all I2C devicetree nodes for SpacemiT K3 SoC. The controller of
> i2c3 is reserved for secure domain, and not available from Linux. The
> controller of i2c7 simply doesn't exist from hardware perspective, as
> vendor directly name the i2c controller used for PMIC as i2c8.
>
> Signed-off-by: Yixun Lan <dlan@kernel.org>
It looks like my Reviewed-by tag got dropped.
The changes look good to me anyway.
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: PCI: intel,lgm-pcie: Make atu resource mandatory
From: Krzysztof Kozlowski @ 2026-03-30 9:50 UTC (permalink / raw)
To: Florian Eckert, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Eckert.Florian, ms
In-Reply-To: <20260330-pcie-intel-gw-v2-6-8bd07367a298@dev.tdt.de>
On 30/03/2026 11:07, Florian Eckert wrote:
> The ATU information is already set in the dwc core if it is specified in
> the DTS. The driver uses its own value here [1]. This information is
> hardware specific and should therefore be maintained in the DTS rather
> than in the source.
>
> Backwards compatibility is not an issue here [5], as the driver is
> exclusively used by Maxlinear.
What does that mean exactly? It is not used outside of Maxlinear
company, so it is purely internal device and no one outside of Maxlinear
has it?
Then we can as well remove it and I don't quite get why you are working
on this (since no one can use it outside of Maxlinear...).
>
> Old DTS entry for PCIe:
>
> reg = <0xd1000000 0x1000>,
> <0xd3000000 0x20000>,
> <0xd0c41000.0x1000>;
> reg-names = "dbi", "config", "app";
>
> New DTS entry for PCIe:
>
> reg = <0xd1000000 0x1000>,
> <0xd10c0000 0x1000>,
> <0xd3000000 0x20000>,
> <0xd0c41000.0x1000>;
> reg-names = "dbi", "atu", "config", "app";
Drop, irrelevant. You still break all users of this binding.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: qcom: kaanapali-qrd: Add SoCCP node
From: Konrad Dybcio @ 2026-03-30 9:51 UTC (permalink / raw)
To: Jingyi Wang, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel, 20260310-knp-soccp-v4-0-0a91575e0e7e
In-Reply-To: <05719918-074e-417a-8209-cbce9d49d94e@oss.qualcomm.com>
On 3/30/26 5:19 AM, Jingyi Wang wrote:
>
>
> On 3/27/2026 5:53 PM, Konrad Dybcio wrote:
>> On 3/27/26 4:20 AM, Jingyi Wang wrote:
>>> Add SoCCP node on Kaanapali QRD board.
>>
>> This is really more of an "add firmware path"
>>
>
> will update the commit msg in next version.
>
>>>
>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>>> index da0e8f9091c3..6a7eb7f4050a 100644
>>> --- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>>> +++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>>> @@ -781,6 +781,11 @@ &remoteproc_cdsp {
>>> status = "okay";
>>> };
>>> +&remoteproc_soccp {
>>> + firmware-name = "qcom/kaanapali/soccp.mbn",
>>> + "qcom/kaanapali/soccp_dtb.mbn";
>>
>> Given that this contains battmgr now, can MTP and QRD use the same
>> firmware?
>>
>
> Offline checked with the POC for SoCCP firmware, MTP and QRD board
> share the same soccp firmware.
Thanks for confirming that
Konrad
^ permalink raw reply
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Krzysztof Kozlowski @ 2026-03-30 9:54 UTC (permalink / raw)
To: Ulf Hansson
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <CAPDyKFoz-sm0pfvn5iSYFY0mrW38vaGRZsFvrVPqsv7BsYxeWQ@mail.gmail.com>
On 23/03/2026 12:13, Ulf Hansson wrote:
> Hi Krzysztof,
>
> On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>>
>> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
>>> This series adds support for the power domains on Google GS101.
>>>
>>> There are a few differences compared to SoCs already supported by this
>>> driver:
>>> * register access does not work via plain ioremap() / readl() /
>>> writel().
>>> Instead, the regmap created by the PMU driver must be used (which
>>> uses Arm SMCC calls under the hood).
>>> * DTZPC: a call needs to be made before and after power domain off/on,
>>> to inform the EL3 firmware of the request.
>>> * power domains can and are fed by a regulator rail and therefore
>>> regulator control needed be implemented.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
>> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
>> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
>> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
>> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
>> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
>>
>> Best regards,
>
> Usually I pick up the power-domain related changes for the DT bindings
> and host them via an immutable branch called "dt". If needed, SOC
> maintainers can pull it to apply/test the corresponding DTS changes.
>
> That said, I am open to whatever you think is best here. Perhaps it's
> easier if you can drop the DT patches and provide your acks instead or
> if you can share them via an immutable branch for me to pull?
I did not pick up any pmdomain binding patches. I picked up only soc and
according to cover letter there are no dependencies between anything here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: qcom: milos: Add display (MDSS)
From: Konrad Dybcio @ 2026-03-30 9:55 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jonathan Marek,
Krishna Manikandan, Neil Armstrong, Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, dri-devel, freedreno, devicetree
In-Reply-To: <20260327-milos-mdss-v2-9-bc586683f5ca@fairphone.com>
On 3/27/26 5:12 PM, Luca Weiss wrote:
> Add device nodes for display: MDSS, DPU, DSI and DSI PHY.
>
> DisplayPort is not added for now.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2] dts: riscv: spacemit: k3: Add i2c nodes
From: Yixun Lan @ 2026-03-30 9:56 UTC (permalink / raw)
To: Troy Mitchell
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, spacemit, devicetree,
linux-riscv, linux-kernel
In-Reply-To: <C57B2D153CF2A3F8+acpHUeQY8TSISRTR@kernel.org>
Hi Troy,
On 17:50 Mon 30 Mar , Troy Mitchell wrote:
> Hi Yixun,
>
> On Fri, Mar 27, 2026 at 19:40:40 CST, Yixun Lan wrote:
> > Populate all I2C devicetree nodes for SpacemiT K3 SoC. The controller of
> > i2c3 is reserved for secure domain, and not available from Linux. The
> > controller of i2c7 simply doesn't exist from hardware perspective, as
> > vendor directly name the i2c controller used for PMIC as i2c8.
> >
> > Signed-off-by: Yixun Lan <dlan@kernel.org>
> It looks like my Reviewed-by tag got dropped.
> The changes look good to me anyway.
>
> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
I realized this afer sending this out..
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: kaanapali: Duplicate whitespace cleanup
From: Konrad Dybcio @ 2026-03-30 9:58 UTC (permalink / raw)
To: Jingyi Wang, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260330-knp-space-cleanup-v1-1-0995302f7557@oss.qualcomm.com>
On 3/30/26 11:39 AM, Jingyi Wang wrote:
> Exactly one space is expected before '{' characters, clean
> up duplicate whitespaces.
>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: Add Motorola edge 30 (dubai) DTS
From: Konrad Dybcio @ 2026-03-30 10:03 UTC (permalink / raw)
To: Val Packett, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kees Cook, Tony Luck,
Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329103055.96649-2-val@packett.cool>
On 3/29/26 12:16 PM, Val Packett wrote:
> The Motorola edge 30 is a smartphone released in 2022.
>
> This commit has the following features working:
> - Display (simplefb)
> - Touchscreen
> - Power and volume buttons
> - Storage (UFS 3.1)
> - Battery (ADSP battmgr)
> - USB (Type-C, 2.0, dual-role)
> - Wi-Fi and Bluetooth (WCN6750 hw1.0)
>
> Signed-off-by: Val Packett <val@packett.cool>
> ---
[...]
> +/ {
> + model = "Motorola edge 30";
nit: Google tells me the 'e' in 'Edge' is uppercase
[...]
> + framebuffer0: framebuffer@e1000000 {
> + compatible = "simple-framebuffer";
> + reg = <0x0 0xe1000000 0x0 (1080 * 2400 * 4)>;
Let's drop reg and use the memory-region binding (also drop unit address)
[...]
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + pmic_glink_hs_in: endpoint {
> + remote-endpoint = <&usb_1_dwc3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
SBU would be @2
> + cont-splash@e1000000 {
framebuffer@
[...]
> + thermal-zones {
> + cam-flash-thermal {
> + polling-delay-passive = <0>;
that's the default setting, you may drop all polling-delay(-passive) = <0>
[...]
> +&usb_1 {
> + /* USB 2.0 only */
> + qcom,select-utmi-as-pipe-clk;
> + maximum-speed = "high-speed";
> +
> + /* Remove USB3 phy */
> + phys = <&usb_1_hsphy>;
> + phy-names = "usb2-phy";
Is it really not wired up in hw, or do you perhaps have a fake cable?
Konrad
^ permalink raw reply
* Re: [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Konrad Dybcio @ 2026-03-30 10:04 UTC (permalink / raw)
To: Richard Acayan, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Thara Gopinath, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-pm, devicetree
In-Reply-To: <20260328014041.83777-4-mailingradian@gmail.com>
On 3/28/26 2:40 AM, Richard Acayan wrote:
> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
> the first 6 CPUs are in the little cluster and the next 2 are in the big
> cluster. Define the clusters in the match data and define the different
> cluster configuration for SDM670.
>
> Currently, this only supports 8 CPUs and tolerates linking to any CPU in
> the cluster.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> ---
> drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
> 1 file changed, 56 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/thermal/qcom/lmh.c b/drivers/thermal/qcom/lmh.c
> index 3d072b7a4a6d..46c1e301f6c8 100644
> --- a/drivers/thermal/qcom/lmh.c
> +++ b/drivers/thermal/qcom/lmh.c
> @@ -30,14 +30,17 @@
>
> #define LMH_REG_DCVS_INTR_CLR 0x8
>
> -#define LMH_ENABLE_ALGOS 1
> -
> struct lmh_hw_data {
> void __iomem *base;
> struct irq_domain *domain;
> int irq;
> };
>
> +struct lmh_soc_data {
> + bool enable_algos;
> + u32 node_ids[8];
u32 clus1_start_idx or something similar denoting the first CPU index
in the second cluster?
Konrad
^ permalink raw reply
* [PATCH 2/2] dt-bindings: trivial-devices: add atmel,atecc608b
From: Thorsten Blum @ 2026-03-30 10:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Guenter Roeck,
Jonathan Cameron, Frank Li, Wensheng Wang, Nuno Sá,
Cosmo Chou, Eddie James, Pawel Dembicki, Dixit Parmar,
Antoni Pokusinski
Cc: Thorsten Blum, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel
In-Reply-To: <20260330100800.389042-3-thorsten.blum@linux.dev>
Add entry for ATECC608B. Update the ATECC508A comment for consistency.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Documentation/devicetree/bindings/trivial-devices.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index a482aeadcd44..9da4c73b23cf 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -63,8 +63,10 @@ properties:
- arduino,unoq-mcu
# Temperature monitoring of Astera Labs PT5161L PCIe retimer
- asteralabs,pt5161l
- # i2c h/w elliptic curve crypto module
+ # ATECC508A - i2c h/w elliptic curve crypto module
- atmel,atecc508a
+ # ATECC608B - i2c h/w elliptic curve crypto module
+ - atmel,atecc608b
# ATSHA204 - i2c h/w symmetric crypto module
- atmel,atsha204
# ATSHA204A - i2c h/w symmetric crypto module
^ permalink raw reply related
* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-30 10:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <1fbf5c54-8793-4585-be33-ded77019adb2@kernel.org>
On Mon, 30 Mar 2026 at 11:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 23/03/2026 12:13, Ulf Hansson wrote:
> > Hi Krzysztof,
> >
> > On Sat, 21 Mar 2026 at 14:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >>
> >> On Wed, 18 Mar 2026 15:27:45 +0000, André Draszik wrote:
> >>> This series adds support for the power domains on Google GS101.
> >>>
> >>> There are a few differences compared to SoCs already supported by this
> >>> driver:
> >>> * register access does not work via plain ioremap() / readl() /
> >>> writel().
> >>> Instead, the regmap created by the PMU driver must be used (which
> >>> uses Arm SMCC calls under the hood).
> >>> * DTZPC: a call needs to be made before and after power domain off/on,
> >>> to inform the EL3 firmware of the request.
> >>> * power domains can and are fed by a regulator rail and therefore
> >>> regulator control needed be implemented.
> >>>
> >>> [...]
> >>
> >> Applied, thanks!
> >>
> >> [01/10] dt-bindings: soc: google: add google,gs101-dtzpc
> >> https://git.kernel.org/krzk/linux/c/10084aeadadfab72648f6ed1cc78f7cd87b861ba
> >> [03/10] dt-bindings: soc: samsung: exynos-pmu: move gs101-pmu into separate binding
> >> https://git.kernel.org/krzk/linux/c/3ec3c42b426fe5e2b48ff19c551dec50bc78788c
> >> [04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
> >> https://git.kernel.org/krzk/linux/c/c8229a5160eea145b796f54317d6e659cec9b080
> >>
> >> Best regards,
> >
> > Usually I pick up the power-domain related changes for the DT bindings
> > and host them via an immutable branch called "dt". If needed, SOC
> > maintainers can pull it to apply/test the corresponding DTS changes.
> >
> > That said, I am open to whatever you think is best here. Perhaps it's
> > easier if you can drop the DT patches and provide your acks instead or
> > if you can share them via an immutable branch for me to pull?
>
>
> I did not pick up any pmdomain binding patches. I picked up only soc and
> according to cover letter there are no dependencies between anything here.
As I understand it, they are all related and some even depend on each
other. I think keeping all four DT patches together makes sense.
Although, as I said, if you think it's best to funnel them through
your tree, please do and then share them via an immutable branch, so I
can apply the pmdomain driver changes.
Kind regards
Uffe
^ permalink raw reply
* [PATCH v3 0/7] Add vibrator, IR transmitter and USB-C handling in xiaomi-ginkgo
From: Biswapriyo Nath @ 2026-03-30 10:13 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Pavel Machek, Sean Young,
Michael Turquette, Stephen Boyd, Martin Botka
Cc: linux-arm-msm, devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel, Biswapriyo Nath,
kernel test robot, Konrad Dybcio, Dmitry Baryshkov,
Krzysztof Kozlowski
This patch series add support for various components in Xiaomi Redmi
Note 8.
Most notably:
- IR transmitter
- USB-C OTG
- Vibrator
Also, fix some bindings warning as reported due to previous commits.
These are tested with linux-next tag next-20260320.
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
---
Changes in v3:
- Fix dispcc-sm6125 binding by adding qcom,gcc reference.
- Link to v2: https://patch.msgid.link/20260329-ginkgo-add-usb-ir-vib-v2-0-870e0745e55e@gmail.com
Changes in v2:
- Move bindings fixes to first in the series and add fixes tag.
- Link to v1: https://patch.msgid.link/20260325-ginkgo-add-usb-ir-vib-v1-0-446c6e865ad6@gmail.com
---
Biswapriyo Nath (7):
arm64: dts: qcom: sm6125: Use 64 bit addressing
dt-bindings: clock: qcom,sm6125-dispcc: reference qcom,gcc.yaml
arm64: dts: qcom: sm6125-xiaomi-ginkgo: Enable vibrator
arm64: dts: qcom: sm6125: Enable USB-C port handling
arm64: dts: qcom: sm6125-xiaomi-ginkgo: Add PMI632 Type-C property
dt-bindings: leds: irled: ir-spi-led: Add new duty-cycle value
arm64: dts: qcom: sm6125-xiaomi-ginkgo: Add IR transmitter
.../bindings/clock/qcom,dispcc-sm6125.yaml | 17 +--
.../devicetree/bindings/leds/irled/ir-spi-led.yaml | 2 +-
.../boot/dts/qcom/sm6125-xiaomi-ginkgo-common.dtsi | 56 +++++++
arch/arm64/boot/dts/qcom/sm6125.dtsi | 168 +++++++++++----------
4 files changed, 154 insertions(+), 89 deletions(-)
---
base-commit: 785f0eb2f85decbe7c1ef9ae922931f0194ffc2e
change-id: 20260325-ginkgo-add-usb-ir-vib-4a51bd9ff64b
Best regards,
--
Biswapriyo Nath <nathbappai@gmail.com>
^ permalink raw reply
* [PATCH v3 1/7] arm64: dts: qcom: sm6125: Use 64 bit addressing
From: Biswapriyo Nath @ 2026-03-30 10:13 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Pavel Machek, Sean Young,
Michael Turquette, Stephen Boyd, Martin Botka
Cc: linux-arm-msm, devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel, Biswapriyo Nath,
kernel test robot, Konrad Dybcio
In-Reply-To: <20260330-ginkgo-add-usb-ir-vib-v3-0-c4b778b0d7f8@gmail.com>
SM6125's SMMU uses 36bit VAs, which is a good indicator that we
should increase (dma-)ranges - and by extension #address- and
#size-cells to prevent things from getting lost in translation
(both literally and figuratively). Do so.
Fixes: 7bb7c90e0ac1 ("arm64: dts: qcom: Add Redmi Note 8T")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603141433.MDqfoVHn-lkp@intel.com/
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
---
arch/arm64/boot/dts/qcom/sm6125.dtsi | 153 ++++++++++++++++++-----------------
1 file changed, 78 insertions(+), 75 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index c84911a98fce..a1a296f90f44 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -374,22 +374,23 @@ smem: smem {
};
soc@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x00 0x00 0x00 0xffffffff>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0 0 0 0x10 0>;
+ dma-ranges = <0 0 0 0 0x10 0>;
compatible = "simple-bus";
tcsr_mutex: hwlock@340000 {
compatible = "qcom,tcsr-mutex";
- reg = <0x00340000 0x20000>;
+ reg = <0x0 0x00340000 0x0 0x20000>;
#hwlock-cells = <1>;
};
tlmm: pinctrl@500000 {
compatible = "qcom,sm6125-tlmm";
- reg = <0x00500000 0x400000>,
- <0x00900000 0x400000>,
- <0x00d00000 0x400000>;
+ reg = <0x0 0x00500000 0x0 0x400000>,
+ <0x0 0x00900000 0x0 0x400000>,
+ <0x0 0x00d00000 0x0 0x400000>;
reg-names = "west", "south", "east";
interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
@@ -672,7 +673,7 @@ qup_uart4_default: qup-uart4-default-state {
gcc: clock-controller@1400000 {
compatible = "qcom,gcc-sm6125";
- reg = <0x01400000 0x1f0000>;
+ reg = <0x0 0x01400000 0x0 0x1f0000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
@@ -682,7 +683,7 @@ gcc: clock-controller@1400000 {
hsusb_phy1: phy@1613000 {
compatible = "qcom,msm8996-qusb2-phy";
- reg = <0x01613000 0x180>;
+ reg = <0x0 0x01613000 0x0 0x180>;
#phy-cells = <0>;
clocks = <&gcc GCC_AHB2PHY_USB_CLK>,
@@ -695,18 +696,18 @@ hsusb_phy1: phy@1613000 {
rng: rng@1b53000 {
compatible = "qcom,prng-ee";
- reg = <0x01b53000 0x1000>;
+ reg = <0x0 0x01b53000 0x0 0x1000>;
clocks = <&gcc GCC_PRNG_AHB_CLK>;
clock-names = "core";
};
spmi_bus: spmi@1c40000 {
compatible = "qcom,spmi-pmic-arb";
- reg = <0x01c40000 0x1100>,
- <0x01e00000 0x2000000>,
- <0x03e00000 0x100000>,
- <0x03f00000 0xa0000>,
- <0x01c0a000 0x26000>;
+ reg = <0x0 0x01c40000 0x0 0x1100>,
+ <0x0 0x01e00000 0x0 0x2000000>,
+ <0x0 0x03e00000 0x0 0x100000>,
+ <0x0 0x03f00000 0x0 0xa0000>,
+ <0x0 0x01c0a000 0x0 0x26000>;
reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
interrupt-names = "periph_irq";
interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
@@ -720,12 +721,13 @@ spmi_bus: spmi@1c40000 {
rpm_msg_ram: sram@45f0000 {
compatible = "qcom,rpm-msg-ram";
- reg = <0x045f0000 0x7000>;
+ reg = <0x0 0x045f0000 0x0 0x7000>;
};
sdhc_1: mmc@4744000 {
compatible = "qcom,sm6125-sdhci", "qcom,sdhci-msm-v5";
- reg = <0x04744000 0x1000>, <0x04745000 0x1000>;
+ reg = <0x0 0x04744000 0x0 0x1000>,
+ <0x0 0x04745000 0x0 0x1000>;
reg-names = "hc", "cqhci";
interrupts = <GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH>,
@@ -752,7 +754,7 @@ sdhc_1: mmc@4744000 {
sdhc_2: mmc@4784000 {
compatible = "qcom,sm6125-sdhci", "qcom,sdhci-msm-v5";
- reg = <0x04784000 0x1000>;
+ reg = <0x0 0x04784000 0x0 0x1000>;
reg-names = "hc";
interrupts = <GIC_SPI 350 IRQ_TYPE_LEVEL_HIGH>,
@@ -780,7 +782,8 @@ sdhc_2: mmc@4784000 {
ufs_mem_hc: ufshc@4804000 {
compatible = "qcom,sm6125-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
- reg = <0x04804000 0x3000>, <0x04810000 0x8000>;
+ reg = <0x0 0x04804000 0x0 0x3000>,
+ <0x0 0x04810000 0x0 0x8000>;
reg-names = "std", "ice";
interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
@@ -825,7 +828,7 @@ ufs_mem_hc: ufshc@4804000 {
ufs_mem_phy: phy@4807000 {
compatible = "qcom,sm6125-qmp-ufs-phy";
- reg = <0x04807000 0xdb8>;
+ reg = <0x0 0x04807000 0x0 0xdb8>;
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
@@ -846,7 +849,7 @@ ufs_mem_phy: phy@4807000 {
gpi_dma0: dma-controller@4a00000 {
compatible = "qcom,sm6125-gpi-dma", "qcom,sdm845-gpi-dma";
- reg = <0x04a00000 0x60000>;
+ reg = <0x0 0x04a00000 0x0 0x60000>;
interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
@@ -864,19 +867,19 @@ gpi_dma0: dma-controller@4a00000 {
qupv3_id_0: geniqup@4ac0000 {
compatible = "qcom,geni-se-qup";
- reg = <0x04ac0000 0x2000>;
+ reg = <0x0 0x04ac0000 0x0 0x2000>;
clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
<&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
clock-names = "m-ahb", "s-ahb";
iommus = <&apps_smmu 0x123 0x0>;
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
status = "disabled";
i2c0: i2c@4a80000 {
compatible = "qcom,geni-i2c";
- reg = <0x04a80000 0x4000>;
+ reg = <0x0 0x04a80000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
@@ -893,7 +896,7 @@ i2c0: i2c@4a80000 {
spi0: spi@4a80000 {
compatible = "qcom,geni-spi";
- reg = <0x04a80000 0x4000>;
+ reg = <0x0 0x04a80000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
@@ -910,7 +913,7 @@ spi0: spi@4a80000 {
i2c1: i2c@4a84000 {
compatible = "qcom,geni-i2c";
- reg = <0x04a84000 0x4000>;
+ reg = <0x0 0x04a84000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>;
@@ -927,7 +930,7 @@ i2c1: i2c@4a84000 {
i2c2: i2c@4a88000 {
compatible = "qcom,geni-i2c";
- reg = <0x04a88000 0x4000>;
+ reg = <0x0 0x04a88000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
@@ -944,7 +947,7 @@ i2c2: i2c@4a88000 {
spi2: spi@4a88000 {
compatible = "qcom,geni-spi";
- reg = <0x04a88000 0x4000>;
+ reg = <0x0 0x04a88000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
@@ -961,7 +964,7 @@ spi2: spi@4a88000 {
i2c3: i2c@4a8c000 {
compatible = "qcom,geni-i2c";
- reg = <0x04a8c000 0x4000>;
+ reg = <0x0 0x04a8c000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>;
@@ -978,7 +981,7 @@ i2c3: i2c@4a8c000 {
i2c4: i2c@4a90000 {
compatible = "qcom,geni-i2c";
- reg = <0x04a90000 0x4000>;
+ reg = <0x0 0x04a90000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
@@ -995,7 +998,7 @@ i2c4: i2c@4a90000 {
uart4: serial@4a90000 {
compatible = "qcom,geni-debug-uart";
- reg = <0x04a90000 0x4000>;
+ reg = <0x0 0x04a90000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
@@ -1007,7 +1010,7 @@ uart4: serial@4a90000 {
gpi_dma1: dma-controller@4c00000 {
compatible = "qcom,sm6125-gpi-dma", "qcom,sdm845-gpi-dma";
- reg = <0x04c00000 0x60000>;
+ reg = <0x0 0x04c00000 0x0 0x60000>;
interrupts = <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
@@ -1025,19 +1028,19 @@ gpi_dma1: dma-controller@4c00000 {
qupv3_id_1: geniqup@4cc0000 {
compatible = "qcom,geni-se-qup";
- reg = <0x04cc0000 0x2000>;
+ reg = <0x0 0x04cc0000 0x0 0x2000>;
clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
<&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
clock-names = "m-ahb", "s-ahb";
iommus = <&apps_smmu 0x143 0x0>;
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
status = "disabled";
i2c5: i2c@4c80000 {
compatible = "qcom,geni-i2c";
- reg = <0x04c80000 0x4000>;
+ reg = <0x0 0x04c80000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>;
@@ -1054,7 +1057,7 @@ i2c5: i2c@4c80000 {
spi5: spi@4c80000 {
compatible = "qcom,geni-spi";
- reg = <0x04c80000 0x4000>;
+ reg = <0x0 0x04c80000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>;
@@ -1071,7 +1074,7 @@ spi5: spi@4c80000 {
i2c6: i2c@4c84000 {
compatible = "qcom,geni-i2c";
- reg = <0x04c84000 0x4000>;
+ reg = <0x0 0x04c84000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>;
@@ -1088,7 +1091,7 @@ i2c6: i2c@4c84000 {
spi6: spi@4c84000 {
compatible = "qcom,geni-spi";
- reg = <0x04c84000 0x4000>;
+ reg = <0x0 0x04c84000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>;
@@ -1105,7 +1108,7 @@ spi6: spi@4c84000 {
i2c7: i2c@4c88000 {
compatible = "qcom,geni-i2c";
- reg = <0x04c88000 0x4000>;
+ reg = <0x0 0x04c88000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
@@ -1122,7 +1125,7 @@ i2c7: i2c@4c88000 {
i2c8: i2c@4c8c000 {
compatible = "qcom,geni-i2c";
- reg = <0x04c8c000 0x4000>;
+ reg = <0x0 0x04c8c000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>;
@@ -1139,7 +1142,7 @@ i2c8: i2c@4c8c000 {
spi8: spi@4c8c000 {
compatible = "qcom,geni-spi";
- reg = <0x04c8c000 0x4000>;
+ reg = <0x0 0x04c8c000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>;
@@ -1156,7 +1159,7 @@ spi8: spi@4c8c000 {
i2c9: i2c@4c90000 {
compatible = "qcom,geni-i2c";
- reg = <0x04c90000 0x4000>;
+ reg = <0x0 0x04c90000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>;
@@ -1173,7 +1176,7 @@ i2c9: i2c@4c90000 {
spi9: spi@4c90000 {
compatible = "qcom,geni-spi";
- reg = <0x04c90000 0x4000>;
+ reg = <0x0 0x04c90000 0x0 0x4000>;
clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
clock-names = "se";
interrupts = <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>;
@@ -1191,9 +1194,9 @@ spi9: spi@4c90000 {
usb3: usb@4ef8800 {
compatible = "qcom,sm6125-dwc3", "qcom,dwc3";
- reg = <0x04ef8800 0x400>;
- #address-cells = <1>;
- #size-cells = <1>;
+ reg = <0x0 0x04ef8800 0x0 0x400>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
@@ -1228,7 +1231,7 @@ usb3: usb@4ef8800 {
usb3_dwc3: usb@4e00000 {
compatible = "snps,dwc3";
- reg = <0x04e00000 0xcd00>;
+ reg = <0x0 0x04e00000 0x0 0xcd00>;
interrupts = <GIC_SPI 255 IRQ_TYPE_LEVEL_HIGH>;
iommus = <&apps_smmu 0x100 0x0>;
phys = <&hsusb_phy1>;
@@ -1244,12 +1247,12 @@ usb3_dwc3: usb@4e00000 {
sram@4690000 {
compatible = "qcom,rpm-stats";
- reg = <0x04690000 0x10000>;
+ reg = <0x0 0x04690000 0x0 0x10000>;
};
mdss: display-subsystem@5e00000 {
compatible = "qcom,sm6125-mdss";
- reg = <0x05e00000 0x1000>;
+ reg = <0x0 0x05e00000 0x0 0x1000>;
reg-names = "mdss";
interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
@@ -1269,16 +1272,16 @@ mdss: display-subsystem@5e00000 {
iommus = <&apps_smmu 0x400 0x0>;
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
status = "disabled";
mdss_mdp: display-controller@5e01000 {
compatible = "qcom,sm6125-dpu";
- reg = <0x05e01000 0x83208>,
- <0x05eb0000 0x3000>;
+ reg = <0x0 0x05e01000 0x0 0x83208>,
+ <0x0 0x05eb0000 0x0 0x3000>;
reg-names = "mdp", "vbif";
interrupt-parent = <&mdss>;
@@ -1348,7 +1351,7 @@ opp-400000000 {
mdss_dsi0: dsi@5e94000 {
compatible = "qcom,sm6125-dsi-ctrl", "qcom,mdss-dsi-ctrl";
- reg = <0x05e94000 0x400>;
+ reg = <0x0 0x05e94000 0x0 0x400>;
reg-names = "dsi_ctrl";
interrupt-parent = <&mdss>;
@@ -1417,9 +1420,9 @@ opp-187500000 {
mdss_dsi0_phy: phy@5e94400 {
compatible = "qcom,sm6125-dsi-phy-14nm";
- reg = <0x05e94400 0x100>,
- <0x05e94500 0x300>,
- <0x05e94800 0x188>;
+ reg = <0x0 0x05e94400 0x0 0x100>,
+ <0x0 0x05e94500 0x0 0x300>,
+ <0x0 0x05e94800 0x0 0x188>;
reg-names = "dsi_phy",
"dsi_phy_lane",
"dsi_pll";
@@ -1441,7 +1444,7 @@ mdss_dsi0_phy: phy@5e94400 {
dispcc: clock-controller@5f00000 {
compatible = "qcom,sm6125-dispcc";
- reg = <0x05f00000 0x20000>;
+ reg = <0x0 0x05f00000 0x0 0x20000>;
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&mdss_dsi0_phy DSI_BYTE_PLL_CLK>,
@@ -1470,7 +1473,7 @@ dispcc: clock-controller@5f00000 {
apps_smmu: iommu@c600000 {
compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", "arm,mmu-500";
- reg = <0x0c600000 0x80000>;
+ reg = <0x0 0x0c600000 0x0 0x80000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
@@ -1544,74 +1547,74 @@ apps_smmu: iommu@c600000 {
apcs_glb: mailbox@f111000 {
compatible = "qcom,sm6125-apcs-hmss-global",
"qcom,msm8994-apcs-kpss-global";
- reg = <0x0f111000 0x1000>;
+ reg = <0x0 0x0f111000 0x0 0x1000>;
#mbox-cells = <1>;
};
timer@f120000 {
compatible = "arm,armv7-timer-mem";
- #address-cells = <1>;
+ #address-cells = <2>;
#size-cells = <1>;
- ranges;
- reg = <0x0f120000 0x1000>;
+ reg = <0x0 0x0f120000 0x0 0x1000>;
+ ranges = <0x0 0x0 0x0 0x0 0x20000000>;
clock-frequency = <19200000>;
frame@f121000 {
frame-number = <0>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0f121000 0x1000>,
- <0x0f122000 0x1000>;
+ reg = <0x0 0x0f121000 0x1000>,
+ <0x0 0x0f122000 0x1000>;
};
frame@f123000 {
frame-number = <1>;
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0f123000 0x1000>;
+ reg = <0x0 0x0f123000 0x1000>;
status = "disabled";
};
frame@f124000 {
frame-number = <2>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0f124000 0x1000>;
+ reg = <0x0 0x0f124000 0x1000>;
status = "disabled";
};
frame@f125000 {
frame-number = <3>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0f125000 0x1000>;
+ reg = <0x0 0x0f125000 0x1000>;
status = "disabled";
};
frame@f126000 {
frame-number = <4>;
interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0f126000 0x1000>;
+ reg = <0x0 0x0f126000 0x1000>;
status = "disabled";
};
frame@f127000 {
frame-number = <5>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0f127000 0x1000>;
+ reg = <0x0 0x0f127000 0x1000>;
status = "disabled";
};
frame@f128000 {
frame-number = <6>;
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x0f128000 0x1000>;
+ reg = <0x0 0x0f128000 0x1000>;
status = "disabled";
};
};
intc: interrupt-controller@f200000 {
compatible = "arm,gic-v3";
- reg = <0x0f200000 0x20000>,
- <0x0f300000 0x100000>;
+ reg = <0x0 0x0f200000 0x0 0x20000>,
+ <0x0 0x0f300000 0x0 0x100000>;
#interrupt-cells = <3>;
interrupt-controller;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
--
2.53.0
^ permalink raw reply related
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