* Re: [PATCH 1/3] arm64: dts: amlogic: t7: Add uart_c pinctrl pins group
From: Xianwei Zhao @ 2026-04-15 11:28 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260415-add-bluetooth-t7-vim4-v1-1-0ba0746cc1d6@aliel.fr>
On 2026/4/15 19:16, Ronald Claveau wrote:
> Add the pin multiplexing configuration for UART C (TX, RX, CTS, RTS)
> in the T7 SoC pinctrl node, required to route the UART C signals
> through the correct pads before enabling the controller.
>
> Signed-off-by: Ronald Claveau<linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 7fe72c94ed623..531931cc1437c 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -553,6 +553,18 @@ mux {
> bias-pull-up;
> };
> };
> +
> + uart_c_pins: uart_c {
node name uart-c
> + mux {
> + groups = "uart_c_tx",
> + "uart_c_rx",
> + "uart_c_cts",
> + "uart_c_rts";
> + bias-pull-up;
> + output-high;
> + function = "uart_c";
> + };
> + };
> };
>
> gpio_intc: interrupt-controller@4080 {
^ permalink raw reply
* [PATCH 3/3] arm64: dts: amlogic: t7: khadas-vim4: Enable Bluetooth
From: Ronald Claveau @ 2026-04-15 11:16 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Ronald Claveau
In-Reply-To: <20260415-add-bluetooth-t7-vim4-v1-0-0ba0746cc1d6@aliel.fr>
Enable UART C on the Khadas VIM4 board and attach the BCM43438
compatible Bluetooth controller to it. The node configures the RTS/CTS
hardware flow control, the associated pinmux, the power supplies (vddao_3v3
and vddao_1v8), the 32 kHz LPO clock shared with the wifi32k fixed
clock, and the GPIO lines used for host wakeup, device wakeup and
shutdown.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 69d6118ba57e7..16f648908090f 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -253,3 +253,22 @@ &uart_a {
clocks = <&xtal>, <&xtal>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
};
+
+&uart_c {
+ status = "okay";
+ pinctrl-0 = <&uart_c_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpio GPIOX_18 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
+ max-speed = <3000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ vbat-supply = <&vddao_3v3>;
+ vddio-supply = <&vddao_1v8>;
+ };
+};
--
2.49.0
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: amlogic: t7: Add UART controllers nodes
From: Ronald Claveau @ 2026-04-15 11:16 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Ronald Claveau
In-Reply-To: <20260415-add-bluetooth-t7-vim4-v1-0-0ba0746cc1d6@aliel.fr>
Add device tree nodes for UART B through F (serial@7a000 to
serial@82000), completing the UART controller description for the T7
SoC. Each node includes the peripheral clock.
While at it, move the uart_a node to its correct position in the
bus address order (0x78000) to comply with the DT requirement that
nodes be sorted by their reg address. Complete the
uart_a node with its peripheral clock (CLKID_SYS_UART_A) and the
associated clock-names, matching the vendor default clock assignment,
consistent with the other UART nodes.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 61 +++++++++++++++++++++++++----
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 531931cc1437c..56b015cfbd6d1 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -577,13 +577,6 @@ gpio_intc: interrupt-controller@4080 {
<10 11 12 13 14 15 16 17 18 19 20 21>;
};
- uart_a: serial@78000 {
- compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
- reg = <0x0 0x78000 0x0 0x18>;
- interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
- status = "disabled";
- };
-
gp0: clock-controller@8080 {
compatible = "amlogic,t7-gp0-pll";
reg = <0x0 0x8080 0x0 0x20>;
@@ -713,6 +706,60 @@ pwm_ao_cd: pwm@60000 {
status = "disabled";
};
+ uart_a: serial@78000 {
+ compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
+ reg = <0x0 0x78000 0x0 0x18>;
+ interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_A>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_b: serial@7a000 {
+ compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
+ reg = <0x0 0x7a000 0x0 0x18>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_B>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_c: serial@7c000 {
+ compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
+ reg = <0x0 0x7c000 0x0 0x18>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_C>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_d: serial@7e000 {
+ compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
+ reg = <0x0 0x7e000 0x0 0x18>;
+ interrupts = <GIC_SPI 171 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_D>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_e: serial@80000 {
+ compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
+ reg = <0x0 0x80000 0x0 0x18>;
+ interrupts = <GIC_SPI 172 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_E>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_f: serial@82000 {
+ compatible = "amlogic,t7-uart", "amlogic,meson-s4-uart";
+ reg = <0x0 0x82000 0x0 0x18>;
+ interrupts = <GIC_SPI 173 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&clkc_periphs CLKID_SYS_UART_F>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
sd_emmc_a: mmc@88000 {
compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
reg = <0x0 0x88000 0x0 0x800>;
--
2.49.0
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: amlogic: t7: Add UART support and enable Bluetooth on VIM4
From: Ronald Claveau @ 2026-04-15 11:16 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Ronald Claveau
This series adds all UART controllers for the Amlogic T7 SoC and enables
the Bluetooth controller on the Khadas VIM4 board.
The T7 SoC ships with six UART controllers (A through F), but only
uart_a was previously described in the device tree.
- Patch 1 adds the pinctrl group for UART C, which is needed to route
its four signals (TX, RX, CTS, RTS) through the correct pads.
- Patch 2 completes the uart_a node (peripheral clock) and
repositions it to respect the ascending reg address order required
by the DT specification. It then adds nodes for UART B through F,
each with their respective peripheral clock.
- Patch 3 enables UART C on the Khadas VIM4 board and attaches the
on-board BCM43438 Bluetooth controller to it, with hardware flow
control, wakeup GPIOs, LPO clock and power supplies.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Ronald Claveau (3):
arm64: dts: amlogic: t7: Add uart_c pinctrl pins group
arm64: dts: amlogic: t7: Add UART controllers nodes
arm64: dts: amlogic: t7: khadas-vim4: Enable Bluetooth
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 19 ++++++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 73 +++++++++++++++++++---
2 files changed, 85 insertions(+), 7 deletions(-)
---
base-commit: 6aa9edb4f8266cfb913ee74f5e55116550b5574d
change-id: 20260414-add-bluetooth-t7-vim4-f01e03c4ec2a
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH 1/3] arm64: dts: amlogic: t7: Add uart_c pinctrl pins group
From: Ronald Claveau @ 2026-04-15 11:16 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Ronald Claveau
In-Reply-To: <20260415-add-bluetooth-t7-vim4-v1-0-0ba0746cc1d6@aliel.fr>
Add the pin multiplexing configuration for UART C (TX, RX, CTS, RTS)
in the T7 SoC pinctrl node, required to route the UART C signals
through the correct pads before enabling the controller.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed623..531931cc1437c 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -553,6 +553,18 @@ mux {
bias-pull-up;
};
};
+
+ uart_c_pins: uart_c {
+ mux {
+ groups = "uart_c_tx",
+ "uart_c_rx",
+ "uart_c_cts",
+ "uart_c_rts";
+ bias-pull-up;
+ output-high;
+ function = "uart_c";
+ };
+ };
};
gpio_intc: interrupt-controller@4080 {
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v3] Add remoteproc PAS loader for SoCCP on Glymur DT
From: Ananthu C V @ 2026-04-15 11:12 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Sibi Sankar
In-Reply-To: <adm2oq_ozs_VUXs0@baldur>
Hi Bjorn,
On Fri, Apr 10, 2026 at 09:52:18PM -0500, Bjorn Andersson wrote:
> On Fri, Apr 03, 2026 at 04:39:05AM -0700, Ananthu C V wrote:
> > From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> >
>
> Your commit is lacking both subject prefix and commit message.
Yes, sorry for that. Some mess happened during the process, next revision will
have everything proper.
>
> > Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> > Co-developed-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > ---
>
> v3? Where is the changelog?
This is also part of the aforementioned mess up, already taken care of for the
next revision prep.
> > arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 7 +++++
> > arch/arm64/boot/dts/qcom/glymur.dtsi | 47 ++++++++++++++++++++++++++++++++
> > 2 files changed, 54 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> > index 2852d257ac8c..3fdf8dbbde02 100644
> > --- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> > @@ -560,6 +560,13 @@ &pon_resin {
> > status = "okay";
> > };
> >
> > +&remoteproc_soccp {
> > + firmware-name = "qcom/glymur/soccp.mbn",
> > + "qcom/glymur/soccp_dtb.mbn";
> > +
> > + status = "okay";
> > +};
> > +
> > &tlmm {
> > gpio-reserved-ranges = <4 4>, /* EC TZ Secure I3C */
> > <10 2>, /* OOB UART */
> > diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> > index f23cf81ddb77..f7f3374a5e08 100644
> > --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> > @@ -2264,6 +2264,53 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
> > };
> > };
> >
> > + remoteproc_soccp: remoteproc-soccp@d00000 {
>
> Isn't remoteproc@ sufficient?
ack.
>
> > + compatible = "qcom,glymur-soccp-pas", "qcom,kaanapali-soccp-pas";
>
> This binding hasn't been merged, and yet you don't mention that this
> can't be merged?
My understanding was that the prerequisite-***-id part would serve as the dependency.
I'll make sure to explicitly mention such cases in the future.
>
> > + reg = <0x0 0x00d00000 0x0 0x200000>;
> > +
> > + interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
> > + interrupt-names = "wdog",
> > + "fatal",
> > + "ready",
> > + "handover",
> > + "stop-ack",
> > + "pong";
> > +
> > + clocks = <&rpmhcc RPMH_CXO_CLK>;
> > + clock-names = "xo";
> > +
> > + power-domains = <&rpmhpd RPMHPD_CX>,
> > + <&rpmhpd RPMHPD_MX>;
> > + power-domain-names = "cx",
> > + "mx";
> > +
> > + memory-region = <&soccp_mem>,
> > + <&soccpdtb_mem>;
> > +
> > + qcom,smem-states = <&soccp_smp2p_out 0>,
> > + <&soccp_smp2p_out 8>;
> > + qcom,smem-state-names = "stop",
> > + "ping";
> > +
> > + status = "disabled";
> > +
> > + glink-edge {
> > + interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
> > + IPCC_MPROC_SIGNAL_GLINK_QMP
> > + IRQ_TYPE_EDGE_RISING>;
> > + mboxes = <&ipcc IPCC_MPROC_SOCCP
> > + IPCC_MPROC_SIGNAL_GLINK_QMP>;
> > + qcom,remote-pid = <19>;
> > + label = "soccp";
> > +
> > + };
> > + };
> > +
> > usb_hs_phy: phy@fa0000 {
> > compatible = "qcom,glymur-m31-eusb2-phy",
> > "qcom,sm8750-m31-eusb2-phy";
> >
> > ---
> > base-commit: bd0f139e5fc11182777b81cefc3893ea508544ec
> > change-id: 20260403-glymur-soccp-2ca25f3b30e2
> > prerequisite-message-id: <20260326-knp-soccp-dt-v1-0-a60c2ae36e9b@oss.qualcomm.com>
> > prerequisite-patch-id: fa390011ee531589a7ad14250d158f497622efbd
> > prerequisite-patch-id: 93e7fca58a5c06edefa624ec2b006dd80f4749a8
> > prerequisite-patch-id: 99a3b6a7fcd061267b40097ad25f652ebe0a4c7b
>
> Why isn't this list empty?
As mentioned above, this was supposed to be the dependency, my bad for not mentioning it
explicitly.
>
> Regards,
> Bjorn
Thanks for the review, Bjorn. I'll probably wait until the driver changes are merged to
make another revision.
Best,
Ananthu
^ permalink raw reply
* Re: [PATCH v1 4/4] ASoC: qcom: sc8280xp: don't force S16_LE in hw_params fixup
From: Alexey Klimov @ 2026-04-15 11:06 UTC (permalink / raw)
To: Kumar Anurag, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Srinivas Kandagatla,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, devicetree, linux-kernel, linux-sound
In-Reply-To: <20260413091937.134469-5-kumar.singh@oss.qualcomm.com>
On Mon Apr 13, 2026 at 10:19 AM BST, Kumar Anurag wrote:
> The machine driver was unconditionally forcing S16_LE in
> sc8280xp_be_hw_params_fixup(), which prevents links (e.g. HDMI bridges)
> that require 32-bit formats from working. Drop the format override and
> keep only the fixed rate/channels constraints.
Why the format override is no longer needed? Please add it in the
description.
> Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com>
> ---
> sound/soc/qcom/sc8280xp.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
> index 7925aa3f63ba..c00eabf200b7 100644
> --- a/sound/soc/qcom/sc8280xp.c
> +++ b/sound/soc/qcom/sc8280xp.c
> @@ -75,10 +75,8 @@ static int sc8280xp_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
> SNDRV_PCM_HW_PARAM_RATE);
> struct snd_interval *channels = hw_param_interval(params,
> SNDRV_PCM_HW_PARAM_CHANNELS);
> - struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
>
> rate->min = rate->max = 48000;
> - snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE);
Does compressed playback work after this change? How did you test it?
Will it be possible with this series to have compressed playback via
HDMI (with 32-bit format, right?)? You might need to add some
functionality for this in topology.
Thanks,
Alexey
^ permalink raw reply
* [PATCH v4] dt-bindings: display: ti, am65x-dss: Fix AM62L DSS reg and clock constraints
From: Swamil Jain @ 2026-04-15 11:04 UTC (permalink / raw)
To: jyri.sarha, tomi.valkeinen, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, robh, krzk+dt, conor+dt, devarsht
Cc: dri-devel, devicetree, linux-kernel, praneeth, vigneshr, s-jain1
The AM62L DSS [1] support incorrectly used the same register and
clock constraints as AM65x, but AM62L has a single video port
Fix this by adding conditional constraints that properly define the
register regions and clocks for AM62L DSS (single video port) versus
other AM65x variants (dual video port).
[1]: Section 12.7 (Display Subsystem and Peripherals)
Link : https://www.ti.com/lit/pdf/sprujb4
Fixes: cb8d4323302c ("dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS")
Cc: stable@vger.kernel.org
Signed-off-by: Swamil Jain <s-jain1@ti.com>
---
Validated the changes with some examples:
https://gist.github.com/swamiljain/79f30568c9ece89f5a20218f52647486
Changelog:
v3->v4:
- Add reg-names constraint
- Re-order constraints to make it consistent with the properties order
Link to v3:
https://lore.kernel.org/all/20260410105955.843868-1-s-jain1@ti.com/
v2->v3:
- Reduce redundancy and use constraints suggested by maintainers
- Remove blank line between the tags
Link to v2:
https://lore.kernel.org/all/20260129150601.185882-1-s-jain1@ti.com/
v1->v2:
- Remove oneOf from top level constraints, it makes bindings redundant
- Remove minItems from top level constraints
- "dma-coherent" property shouldn't be changed in v1 itself
- Add description for reg-names, clock and clock-names
- Add constraints specific to AM62L and for other SoCs within allOf
check
Link to v1:
https://lore.kernel.org/all/20251224133150.2266524-1-s-jain1@ti.com/
---
.../bindings/display/ti/ti,am65x-dss.yaml | 70 ++++++++++++++-----
1 file changed, 52 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 38fcee91211e..49a007cbcd3a 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -36,34 +36,50 @@ properties:
reg:
description:
Addresses to each DSS memory region described in the SoC's TRM.
- items:
- - description: common DSS register area
- - description: VIDL1 light video plane
- - description: VID video plane
- - description: OVR1 overlay manager for vp1
- - description: OVR2 overlay manager for vp2
- - description: VP1 video port 1
- - description: VP2 video port 2
- - description: common1 DSS register area
+ oneOf:
+ - items:
+ - description: common DSS register area
+ - description: VIDL1 light video plane
+ - description: VID video plane
+ - description: OVR1 overlay manager for vp1
+ - description: OVR2 overlay manager for vp2
+ - description: VP1 video port 1
+ - description: VP2 video port 2
+ - description: common1 DSS register area
+ - items:
+ - description: common DSS register area
+ - description: VIDL1 light video plane
+ - description: OVR1 overlay manager for vp1
+ - description: VP1 video port 1
+ - description: common1 DSS register area
reg-names:
- items:
- - const: common
- - const: vidl1
- - const: vid
- - const: ovr1
- - const: ovr2
- - const: vp1
- - const: vp2
- - const: common1
+ oneOf:
+ - items:
+ - const: common
+ - const: vidl1
+ - const: vid
+ - const: ovr1
+ - const: ovr2
+ - const: vp1
+ - const: vp2
+ - const: common1
+ - items:
+ - const: common
+ - const: vidl1
+ - const: ovr1
+ - const: vp1
+ - const: common1
clocks:
+ minItems: 2
items:
- description: fck DSS functional clock
- description: vp1 Video Port 1 pixel clock
- description: vp2 Video Port 2 pixel clock
clock-names:
+ minItems: 2
items:
- const: fck
- const: vp1
@@ -179,6 +195,24 @@ allOf:
ports:
properties:
port@1: false
+ reg:
+ maxItems: 5
+ reg-names:
+ maxItems: 5
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+ else:
+ properties:
+ reg:
+ minItems: 8
+ reg-names:
+ minItems: 8
+ clocks:
+ minItems: 3
+ clock-names:
+ minItems: 3
- if:
properties:
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: kaanapali: Enable cpufreq cooling devices
From: Konrad Dybcio @ 2026-04-15 11:01 UTC (permalink / raw)
To: dipa.mantre, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260415-cpufreq_kaanapali-v1-1-1fa94105d5c2@oss.qualcomm.com>
On 4/15/26 12:57 PM, Dipa Mantre via B4 Relay wrote:
> From: Dipa Mantre <dipa.mantre@oss.qualcomm.com>
>
> Add cooling-cells property to the CPU nodes to support cpufreq
> cooling devices.
>
> Signed-off-by: Dipa Mantre <dipa.mantre@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: qcom: kaanapali: Enable cpufreq cooling devices
From: Dipa Mantre via B4 Relay @ 2026-04-15 10:57 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dipa Mantre
From: Dipa Mantre <dipa.mantre@oss.qualcomm.com>
Add cooling-cells property to the CPU nodes to support cpufreq
cooling devices.
Signed-off-by: Dipa Mantre <dipa.mantre@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7cc326aa1a1a..81c493668b51 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -48,6 +48,7 @@ cpu0: cpu@0 {
power-domains = <&cpu_pd0>;
power-domain-names = "psci";
clocks = <&pdp_scmi_perf 0>;
+ #cooling-cells = <2>;
l2_0: l2-cache {
compatible = "cache";
@@ -65,6 +66,7 @@ cpu1: cpu@100 {
power-domains = <&cpu_pd1>;
power-domain-names = "psci";
clocks = <&pdp_scmi_perf 0>;
+ #cooling-cells = <2>;
};
cpu2: cpu@200 {
@@ -76,6 +78,7 @@ cpu2: cpu@200 {
power-domains = <&cpu_pd2>;
power-domain-names = "psci";
clocks = <&pdp_scmi_perf 0>;
+ #cooling-cells = <2>;
};
cpu3: cpu@300 {
@@ -87,6 +90,7 @@ cpu3: cpu@300 {
power-domains = <&cpu_pd3>;
power-domain-names = "psci";
clocks = <&pdp_scmi_perf 0>;
+ #cooling-cells = <2>;
};
cpu4: cpu@400 {
@@ -98,6 +102,7 @@ cpu4: cpu@400 {
power-domains = <&cpu_pd4>;
power-domain-names = "psci";
clocks = <&pdp_scmi_perf 0>;
+ #cooling-cells = <2>;
};
cpu5: cpu@500 {
@@ -109,6 +114,7 @@ cpu5: cpu@500 {
power-domains = <&cpu_pd5>;
power-domain-names = "psci";
clocks = <&pdp_scmi_perf 0>;
+ #cooling-cells = <2>;
};
cpu6: cpu@10000 {
@@ -120,6 +126,7 @@ cpu6: cpu@10000 {
power-domains = <&cpu_pd6>;
power-domain-names = "psci";
clocks = <&pdp_scmi_perf 1>;
+ #cooling-cells = <2>;
l2_1: l2-cache {
compatible = "cache";
@@ -137,6 +144,7 @@ cpu7: cpu@10100 {
power-domains = <&cpu_pd7>;
power-domain-names = "psci";
clocks = <&pdp_scmi_perf 1>;
+ #cooling-cells = <2>;
};
cpu-map {
---
base-commit: e6efabc0afca02efa263aba533f35d90117ab283
change-id: 20260414-cpufreq_kaanapali-f2866a18567c
Best regards,
--
Dipa Ramesh Mantre <dipa.mantre@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH v2 3/3] gpio: zynq: Add eio gpio support
From: Shubhrajyoti Datta @ 2026-04-15 10:56 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260415105628.957689-1-shubhrajyoti.datta@amd.com>
Add support for the EIO GPIO controller found on
xa2ve3288 silicon.
The EIO GPIO block provides access to multiplexed I/O pins exposed
through the EIO interface. Only bank 0 and bank 1 are connected to
external MIO pins, with 26 GPIOs per bank (52 GPIOs total). This
change extends the Zynq GPIO driver to support the EIO GPIO
variant.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
(no changes since v1)
drivers/gpio/gpio-zynq.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 571e366624d2..8118ae3412c2 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -25,6 +25,7 @@
#define VERSAL_GPIO_MAX_BANK 4
#define PMC_GPIO_MAX_BANK 5
#define VERSAL_UNUSED_BANKS 2
+#define EIO_GPIO_MAX_BANK 2
#define ZYNQ_GPIO_BANK0_NGPIO 32
#define ZYNQ_GPIO_BANK1_NGPIO 22
@@ -818,6 +819,16 @@ static const struct dev_pm_ops zynq_gpio_dev_pm_ops = {
RUNTIME_PM_OPS(zynq_gpio_runtime_suspend, zynq_gpio_runtime_resume, NULL)
};
+static const struct zynq_platform_data eio_gpio_def = {
+ .label = "eio_gpio",
+ .ngpio = 52,
+ .max_bank = EIO_GPIO_MAX_BANK,
+ .bank_min[0] = 0,
+ .bank_max[0] = 25, /* 0 to 25 are connected to MIOs (26 pins) */
+ .bank_min[1] = 26,
+ .bank_max[1] = 51, /* Bank 1 are connected to MIOs (26 pins) */
+};
+
static const struct zynq_platform_data versal_gpio_def = {
.label = "versal_gpio",
.quirks = GPIO_QUIRK_VERSAL,
@@ -882,6 +893,7 @@ static const struct of_device_id zynq_gpio_of_match[] = {
{ .compatible = "xlnx,zynqmp-gpio-1.0", .data = &zynqmp_gpio_def },
{ .compatible = "xlnx,versal-gpio-1.0", .data = &versal_gpio_def },
{ .compatible = "xlnx,pmc-gpio-1.0", .data = &pmc_gpio_def },
+ { .compatible = "xlnx,eio-gpio-1.0", .data = &eio_gpio_def },
{ /* end of table */ }
};
MODULE_DEVICE_TABLE(of, zynq_gpio_of_match);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: gpio: Add EIO GPIO compatible to gpio-zynq
From: Shubhrajyoti Datta @ 2026-04-15 10:56 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260415105628.957689-1-shubhrajyoti.datta@amd.com>
EIO (Extended IO) is a GPIO block found on xa2ve3288 silicon..
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
Changes in v2:
- Add description of EIO block in the dt-bindings patch
.../devicetree/bindings/gpio/gpio-zynq.yaml | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
index 30a7f836c341..1ca067217509 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
@@ -12,6 +12,7 @@ maintainers:
properties:
compatible:
enum:
+ - xlnx,eio-gpio-1.0
- xlnx,pmc-gpio-1.0
- xlnx,versal-gpio-1.0
- xlnx,zynq-gpio-1.0
@@ -30,7 +31,7 @@ properties:
gpio-line-names:
description: strings describing the names of each gpio line
- minItems: 58
+ minItems: 52
maxItems: 174
interrupt-controller: true
@@ -89,6 +90,17 @@ allOf:
minItems: 116
maxItems: 116
+ - if:
+ properties:
+ compatible:
+ enum:
+ - xlnx,eio-gpio-1.0
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 52
+ maxItems: 52
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: gpio: zynq: Sort compatible strings alphabetically
From: Shubhrajyoti Datta @ 2026-04-15 10:56 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260415105628.957689-1-shubhrajyoti.datta@amd.com>
Sort the compatible string alphabetically.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
Changes in v2:
- Add new patch to sort the compatible strings alphabetically
Documentation/devicetree/bindings/gpio/gpio-zynq.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
index 5e2496379a3c..30a7f836c341 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
@@ -12,10 +12,10 @@ maintainers:
properties:
compatible:
enum:
+ - xlnx,pmc-gpio-1.0
+ - xlnx,versal-gpio-1.0
- xlnx,zynq-gpio-1.0
- xlnx,zynqmp-gpio-1.0
- - xlnx,versal-gpio-1.0
- - xlnx,pmc-gpio-1.0
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] gpio: Add EIO GPIO support
From: Shubhrajyoti Datta @ 2026-04-15 10:56 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Shubhrajyoti Datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
Add the EIO GPIO support.
Add the dt description and the compatible to the driver.
Changes in v2:
- Add new patch to sort the compatible strings alphabetically
- Add description of EIO block in the dt-bindings patch
Shubhrajyoti Datta (3):
dt-bindings: gpio: zynq: Sort compatible strings alphabetically
dt-bindings: gpio: Add EIO GPIO compatible to gpio-zynq
gpio: zynq: Add eio gpio support
.../devicetree/bindings/gpio/gpio-zynq.yaml | 18 +++++++++++++++---
drivers/gpio/gpio-zynq.c | 12 ++++++++++++
2 files changed, 27 insertions(+), 3 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v4 02/12] ASoC: dt-bindings: Add RZ/G3E (R9A09G047) sound binding
From: John Madieu @ 2026-04-15 10:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: John Madieu, Kuninori Morimoto, Mark Brown, Liam Girdwood,
Geert Uytterhoeven, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Magnus Damm,
Philipp Zabel, Claudiu Beznea, Biju Das, linux-sound,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260410-astute-celadon-dugong-ee367b@quoll>
Hi Krzysztof,
Thank you for your review.
> On Thu, Apr 09, 2026 at 11:02:51AM +0200, John Madieu wrote:
> > The RZ/G3E shares the same audio IP as the R-Car variants but differs
> > in several aspects: it supports up to 5 DMA controllers per audio
> > channel, requires additional clocks (47 total including per-SSI ADG
> > clocks, SCU domain clocks and SSIF supply) and additional reset lines
> > (14 total including SCU, ADG and Audio DMAC peri-peri resets).
> >
> > Add a dedicated devicetree binding for the RZ/G3E sound controller.
> > The binding references the common renesas,rsnd-common.yaml schema for
> > shared property and subnode definitions.
> >
> > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> > ---
> >
> > Changes:
> >
> > v4: No changes
> > v3: No changes
> > v2:
> > - Introduce RZ/G3E sound binding as a standalone schema
> >
> > .../sound/renesas,r9a09g047-sound.yaml | 371 ++++++++++++++++++
> > 1 file changed, 371 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> > new file mode 100644
> > index 000000000000..1dfe9bab3382
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> > @@ -0,0 +1,371 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/sound/renesas,r9a09g047-sound.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas RZ/G3E Sound Controller
> > +
> > +maintainers:
> > + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > + - John Madieu <john.madieu.xa@bp.renesas.com>
> > +
> > +description:
> > + The RZ/G3E (R9A09G047) integrates an R-Car compatible sound controller
> > + with extended DMA channel support (up to 5 DMACs per direction), additional
> > + clock domains, and additional reset lines compared to the R-Car Gen2/Gen3
> > + variants.
> > +
> > +allOf:
> > + - $ref: renesas,rsnd-common.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: renesas,r9a09g047-sound
> > +
> > + reg:
> > + maxItems: 5
> > +
> > + reg-names:
> > + items:
> > + - const: scu
> > + - const: adg
> > + - const: ssiu
> > + - const: ssi
> > + - const: audmapp
> > +
> > + clocks:
> > + maxItems: 47
> > +
> > + clock-names:
> > + items:
> > + - const: ssi-all
> > + - const: ssi.9
> > + - const: ssi.8
> > + - const: ssi.7
> > + - const: ssi.6
> > + - const: ssi.5
> > + - const: ssi.4
> > + - const: ssi.3
> > + - const: ssi.2
> > + - const: ssi.1
> > + - const: ssi.0
> > + - const: src.9
> > + - const: src.8
> > + - const: src.7
> > + - const: src.6
> > + - const: src.5
> > + - const: src.4
> > + - const: src.3
> > + - const: src.2
> > + - const: src.1
> > + - const: src.0
> > + - const: mix.1
> > + - const: mix.0
> > + - const: ctu.1
> > + - const: ctu.0
> > + - const: dvc.0
> > + - const: dvc.1
> > + - const: clk_a
> > + - const: clk_b
> > + - const: clk_c
> > + - const: clk_i
> > + - const: ssif_supply
> > + - const: scu
> > + - const: scu_x2
> > + - const: scu_supply
> > + - const: adg.ssi.9
> > + - const: adg.ssi.8
> > + - const: adg.ssi.7
> > + - const: adg.ssi.6
> > + - const: adg.ssi.5
> > + - const: adg.ssi.4
> > + - const: adg.ssi.3
> > + - const: adg.ssi.2
> > + - const: adg.ssi.1
> > + - const: adg.ssi.0
> > + - const: audmapp
> > + - const: adg
> > +
>
> Missing clock-cells.
>
> Mising dai-cells.
>
> Why your binding is so flexible? You have a fixed (as in afixed) ABI, no?
>
Will address this in v5.
> > + resets:
> > + maxItems: 14
> > +
> > + reset-names:
> > + items:
> > + - const: ssi-all
> > + - const: ssi.9
> > + - const: ssi.8
> > + - const: ssi.7
> > + - const: ssi.6
> > + - const: ssi.5
> > + - const: ssi.4
> > + - const: ssi.3
> > + - const: ssi.2
> > + - const: ssi.1
> > + - const: ssi.0
> > + - const: scu
> > + - const: adg
> > + - const: audmapp
> > +
> > + rcar_sound,dvc:
>
> All new properties must follow standard rules. I understand it will
> create duplication, but really that's a mistake of 2014 of adding fake
> vendor prefix rcar_sound.
>
As this definitely changes from the original implementation, I'll simply
drop the split patch and add a standalone binding for RZ/G3E. Hope this
is ok for you.
In there I'll address all the comments you've mentionned.
Regards,
^ permalink raw reply
* [PATCH v3] arm64: dts: airoha: en7581: Enable spi nand controller for EN7581 EVB
From: Lorenzo Bianconi @ 2026-04-15 10:31 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Arnd Bergmann, linux-arm-kernel, linux-mediatek, devicetree,
Lorenzo Bianconi
Enable spi controller used for snand memory device for EN7581 evaluation
board.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v3:
- Rebase and resend
- Link to v2: https://lore.kernel.org/linux-mediatek/20250225-en7581-snfi-probe-fix-v2-1-92e35add701b@kernel.org/
Changes in v2:
- Clarify the commit title
- Link to v1: https://lore.kernel.org/r/20250225-en7581-snfi-probe-fix-v1-1-77e4769574e4@kernel.org
---
arch/arm64/boot/dts/airoha/en7581-evb.dts | 4 ++++
arch/arm64/boot/dts/airoha/en7581.dtsi | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/airoha/en7581-evb.dts b/arch/arm64/boot/dts/airoha/en7581-evb.dts
index 886e2e4b5f64..3dc68dbf1be7 100644
--- a/arch/arm64/boot/dts/airoha/en7581-evb.dts
+++ b/arch/arm64/boot/dts/airoha/en7581-evb.dts
@@ -25,6 +25,10 @@ memory@80000000 {
};
};
+&snfi {
+ status = "okay";
+};
+
&spi_nand {
partitions {
compatible = "fixed-partitions";
diff --git a/arch/arm64/boot/dts/airoha/en7581.dtsi b/arch/arm64/boot/dts/airoha/en7581.dtsi
index ff6908a76e8e..0964cd783013 100644
--- a/arch/arm64/boot/dts/airoha/en7581.dtsi
+++ b/arch/arm64/boot/dts/airoha/en7581.dtsi
@@ -150,7 +150,7 @@ gic: interrupt-controller@9000000 {
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
};
- spi@1fa10000 {
+ snfi: spi@1fa10000 {
compatible = "airoha,en7581-snand";
reg = <0x0 0x1fa10000 0x0 0x140>,
<0x0 0x1fa11000 0x0 0x160>;
---
base-commit: e6490a169f6d5f5bdea7a2e8a673890d43afadc0
change-id: 20260415-airoha-7581-spi-enable-034c0ef32db6
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: monaco-pmics: Add PON power key and reset inputs
From: Rakesh Kota @ 2026-04-15 10:24 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
kamal.wadhwa, rakesh.kota
In-Reply-To: <0b4ac3c1-11b3-4991-83c2-0c39a81baa8f@oss.qualcomm.com>
On Fri, Jan 30, 2026 at 12:18:53PM +0100, Konrad Dybcio wrote:
> On 1/22/26 7:59 AM, Rakesh Kota wrote:
> > Add the Power On (PON) peripheral with power key and reset input
> > support for the PMM8654AU PMIC on Monaco platforms.
> >
> > Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/monaco-pmics.dtsi | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi b/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
> > index e990d7367719beaa9e0cea87d9c183ae18c3ebc8..051407cd83eef8eace8521084b1ad012a5192ace 100644
> > --- a/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/monaco-pmics.dtsi
> > @@ -13,6 +13,26 @@ pmm8620au_0: pmic@0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > + pmm8654au_0_pon: pon@1200 {
> > + compatible = "qcom,pmk8350-pon";
>
> I see pmm8655x has some slight changes vs pmk8350 (more configs but
> generally backwards compatible if we don't use them), let's add a
> separate compatible in bindings so that we can maybe handle these
> differences down the line:
>
> diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> index 979a377cb4ff..14b85b0d97da 100644
> --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> @@ -17,12 +17,16 @@ description: |
>
> properties:
> compatible:
> - enum:
> - - qcom,pm8916-pon
> - - qcom,pm8941-pon
> - - qcom,pms405-pon
> - - qcom,pm8998-pon
> - - qcom,pmk8350-pon
> + oneOf:
> + - enum:
> + - qcom,pm8916-pon
> + - qcom,pm8941-pon
> + - qcom,pms405-pon
> + - qcom,pm8998-pon
> + - qcom,pmk8350-pon
> + - items:
> + - const: qcom,pmm8654au-pon
> + - const: qcom,pmk8350-pon
>
Hi Konrad,
Based on the below discussion:
https://lore.kernel.org/all/872faa80-d323-4625-ab8f-50ab2e0e8e0f@kernel.org/
I understand that introducing new compatibles without a corresponding driver
change is not acceptable per upstream community guidelines. As Krzysztof pointed out,
neew compatibles must be accompanied by the necessary driver support.
so,shall we use the old compatible in the current patch series for now ?
And Resume the patch series at https://lore.kernel.org/linux-arm-msm/9c7521fe-5008-4daa-945b-ce3f5c0f6dc0@kernel.org/
once the driver changes are ready and upstreamed ?
reagrs
Rakesh Kota
>
>
> Konrad
^ permalink raw reply
* Re: [PATCH v10 00/11] ADF41513/ADF41510 PLL frequency synthesizers
From: Andy Shevchenko @ 2026-04-15 10:24 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan,
Krzysztof Kozlowski
In-Reply-To: <20260415-adf41513-iio-driver-v10-0-df61046d5457@analog.com>
On Wed, Apr 15, 2026 at 10:51:43AM +0100, Rodrigo Alencar via B4 Relay wrote:
> This patch series adds support for the Analog Devices ADF41513 and ADF41510
> ultralow noise PLL frequency synthesizers. These devices are designed for
> implementing local oscillators (LOs) in high-frequency applications.
> The ADF41513 covers frequencies from 1 GHz to 26.5 GHz, while the ADF41510
> operates from 1 GHz to 10 GHz.
>
> Key features supported by this driver:
> - Integer-N and fractional-N operation modes
> - High maximum PFD frequency (250 MHz integer-N, 125 MHz fractional-N)
> - 25-bit fixed modulus or 49-bit variable modulus fractional modes
> - Digital lock detect functionality
> - Phase resync capability for consistent output phase
> - Load Enable vs Reference signal syncronization
>
> The series includes:
> 1. PLL driver implementation
> 2. Device tree bindings documentation
> 3. IIO ABI documentation
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> Changes in v10:
> - Drop simple_strntoull() changes
> - Create kstrtodec64() and kstrtoudec64() helpers.
On a brief look this looks quite good. I will review it later on. We still have
several weeks time.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v12 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: P.K. Lee @ 2026-04-15 10:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jason-Hsu, p.k.lee
In-Reply-To: <e7a1588d-b4d4-4aa7-ba94-da3e2591d49c@lunn.ch>
> > > > > If there are no devices on the bus, why enable it?
> > > >
> > > > We intentionally enable it so user-space tools can access the switch
> > > > registers. I have added a comment in v13 to clarify this.
> > >
> > > Why would user space want to access the switch registers for an
> > > unmanaged switch? It sounds like you are using Marvells SDK in
> > > userspace to manage the switch, rather than using DSA.
> > >
> >
> > We do have a custom user-space daemon that configures the switch
> > registers for our specific use case. Should I remove the &mdio0 node
> > if it is only enabled and has no other configuration in the upstream
> > device tree?
>
> Please just be truthful that you have a user space driver, so need the
> bus enabled.
>
> I also guess you have some other kernel code that allows you to
> actually use the bus from user space? The typical ethernet IOCTL
> handler does not work for you, since you don't have an ethernet device
> using this bus. Such code is unlikely to be accepted into mainline. We
> don't like user space drivers when there is a perfectly good kernel
> driver for this switch.
Since the kernel driver for mv88e6xxx in kernel 6.6 used by this
project does not support LED control, and this feature is only
available starting from kernel 6.13, I had to initialize the LEDs of
the 88E6393X from user space.
In this case, should I remove the &mdio0 node?
P.K. Lee
^ permalink raw reply
* Re: [PATCH v12 00/15] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-04-15 10:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
On 4/2/2026 3:26 PM, Jinjie Ruan wrote:
> The crash memory allocation, and the exclude of crashk_res, crashk_low_res
> and crashk_cma memory are almost identical across different architectures,
> This patch set handle them in crash core in a general way, which eliminate
> a lot of duplication code.
>
> And add support for crashkernel CMA reservation for arm64 and riscv.
>
> Rebased on v7.0-rc1.
>
> Basic second kernel boot test were performed on QEMU platforms for x86,
> ARM64, and RISC-V architectures with the following parameters:
>
> "cma=256M crashkernel=256M crashkernel=64M,cma"
>
> Changes in v12:
> - Remove the unused "nr_mem_ranges" for x86.
> - Add "Fix crashk_low_res not exclude bug" test log.
> - Provide a separate patch for each architecture for using
> crash_prepare_headers(), which will make the review more convenient.
> - Add Reviewed-by and Tested-by.
> - Link to v11: https://lore.kernel.org/all/20260328074013.3589544-1-ruanjinjie@huawei.com/
>
> Changes in v11:
> - Avoid silently drop crash memory if the crash kernel is built without
> CONFIG_CMA.
> - Remove unnecessary "cmem->nr_ranges = 0" for arch_crash_populate_cmem()
> as we use kvzalloc().
> - Provide a separate patch for each architecture to fix the existing
> buffer overflow issue.
Are there any further review comments? Especially regarding the patch
for fixing out-of-bounds access (suggested by the AI review), as well as
the changes for LoongArch, x86 and riscv architectures.
> - Add Acked-bys for arm64.
>
> Changes in v10:
> - Fix crashk_low_res not excluded bug in the existing
> RISC-V code.
> - Fix an existing memory leak issue in the existing PowerPC code.
> - Fix the ordering issue of adding CMA ranges to
> "linux,usable-memory-range".
> - Fix an existing concurrency issue. A Concurrent memory hotplug may occur
> between reading memblock and attempting to fill cmem during kexec_load()
> for almost all existing architectures.
> - Link to v9: https://lore.kernel.org/all/20260323072745.2481719-1-ruanjinjie@huawei.com/
>
> Changes in v9:
> - Collect Reviewed-by and Acked-by, and prepare for Sashiko AI review.
> - Link to v8: https://lore.kernel.org/all/20260302035315.3892241-1-ruanjinjie@huawei.com/
>
> Changes in v8:
> - Fix the build issues reported by kernel test robot and Sourabh.
> - Link to v7: https://lore.kernel.org/all/20260226130437.1867658-1-ruanjinjie@huawei.com/
>
> Changes in v7:
> - Correct the inclusion of CMA-reserved ranges for kdump kernel in of/kexec
> for arm64 and riscv.
> - Add Acked-by.
> - Link to v6: https://lore.kernel.org/all/20260224085342.387996-1-ruanjinjie@huawei.com/
>
> Changes in v6:
> - Update the crash core exclude code as Mike suggested.
> - Rebased on v7.0-rc1.
> - Add acked-by.
> - Link to v5: https://lore.kernel.org/all/20260212101001.343158-1-ruanjinjie@huawei.com/
>
> Jinjie Ruan (14):
> riscv: kexec_file: Fix crashk_low_res not exclude bug
> powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
> x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
> arm64: kexec_file: Fix potential buffer overflow in
> prepare_elf_headers()
> riscv: kexec_file: Fix potential buffer overflow in
> prepare_elf_headers()
> LoongArch: kexec: Fix potential buffer overflow in
> prepare_elf_headers()
> crash: Add crash_prepare_headers() to exclude crash kernel memory
> arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
> x86/kexec: Use crash_prepare_headers() helper to simplify code
> riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
> LoongArch: kexec: Use crash_prepare_headers() helper to simplify code
> crash: Use crash_exclude_core_ranges() on powerpc
> arm64: kexec: Add support for crashkernel CMA reservation
> riscv: kexec: Add support for crashkernel CMA reservation
>
> Sourabh Jain (1):
> powerpc/crash: sort crash memory ranges before preparing elfcorehdr
>
> .../admin-guide/kernel-parameters.txt | 16 +--
> arch/arm64/kernel/machine_kexec_file.c | 43 +++-----
> arch/arm64/mm/init.c | 5 +-
> arch/loongarch/kernel/machine_kexec_file.c | 43 +++-----
> arch/powerpc/include/asm/kexec_ranges.h | 1 -
> arch/powerpc/kexec/crash.c | 7 +-
> arch/powerpc/kexec/ranges.c | 101 +-----------------
> arch/riscv/kernel/machine_kexec_file.c | 42 +++-----
> arch/riscv/mm/init.c | 5 +-
> arch/x86/kernel/crash.c | 92 +++-------------
> drivers/of/fdt.c | 9 +-
> drivers/of/kexec.c | 9 ++
> include/linux/crash_core.h | 9 ++
> include/linux/crash_reserve.h | 4 +-
> kernel/crash_core.c | 89 ++++++++++++++-
> 15 files changed, 193 insertions(+), 282 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly
From: Nickolay Goppen @ 2026-04-15 10:03 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ekansh Gupta
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <70d4dbe7-0e5b-4065-858e-b5a57bbf45e3@oss.qualcomm.com>
15.04.2026 12:52, Konrad Dybcio wrote:
> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>> Downstream [1] this region is marked as shared and reusable so
>> describe it that way.
>>
>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>
>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>> ---
> +Ekansh some insight, please?
>
> We're giving away that memory via qcom_scm_assign_mem() anyway
> and I would assume that making it not-"no-map" could introduce issues
> when the OS tries to access that region
I've made it as sdm845 done [1].
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sdm845.dtsi#n893
> Konrad
>
>
>> arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> index 4b47efdb57b2..13094b5e9339 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>> };
>>
>> adsp_mem: adsp-region@f6000000 {
>> + compatible = "shared-dma-pool";
>> reg = <0x0 0xf6000000 0x0 0x800000>;
>> - no-map;
>> + reusable;
>> };
>>
>> qseecom_mem: qseecom-region@f6800000 {
>>
--
Best regards,
Nickolay
^ permalink raw reply
* [BUG] stm32mp135-dk: DT uses PA13 used for LED and button at the same time
From: Ahmad Fatoum @ 2026-04-15 9:55 UTC (permalink / raw)
To: Fabien Dessenne, Patrice Chotard
Cc: Alexandre Torgue, Maxime Coquelin, linux-stm32,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
kernel@pengutronix.de
Hello,
I just noticed that barebox built against the v7.0-rc1 device trees
reports following error:
ERROR: gpiolib: _gpio_request: gpio-13 (led-red) status -16
This is caused by the combination of following two commits:
57012d79fefd ("ARM: dts: stm32: add UserPA13 button on stm32mp135f-dk")
31f0d9a486a8 ("ARM: dts: stm32: Add red LED for stm32mp135f-dk board")
Both reference the same &gpioa 13. Linux didn't seem to mind, but
barebox fails the LED driver probe, because the GPIO had already been
requested.
Assuming it is correct that they share the same GPIO physically,
does the current DT description make sense though for actual use?
Blinking the LED would register a button press, so it feels that they
should rather be mutually exclusive?
Thanks,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly
From: Konrad Dybcio @ 2026-04-15 9:52 UTC (permalink / raw)
To: Nickolay Goppen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ekansh Gupta
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20260415-qcom-sdm660-cdsp-adsp-fastrpc-dts-fix-v1-3-03b475b29554@mainlining.org>
On 4/15/26 11:40 AM, Nickolay Goppen wrote:
> Downstream [1] this region is marked as shared and reusable so
> describe it that way.
>
> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---
+Ekansh some insight, please?
We're giving away that memory via qcom_scm_assign_mem() anyway
and I would assume that making it not-"no-map" could introduce issues
when the OS tries to access that region
Konrad
> arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index 4b47efdb57b2..13094b5e9339 100644
> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
> };
>
> adsp_mem: adsp-region@f6000000 {
> + compatible = "shared-dma-pool";
> reg = <0x0 0xf6000000 0x0 0x800000>;
> - no-map;
> + reusable;
> };
>
> qseecom_mem: qseecom-region@f6800000 {
>
^ permalink raw reply
* [PATCH v10 11/11] Documentation: ABI: testing: add common ABI file for iio/frequency
From: Rodrigo Alencar via B4 Relay @ 2026-04-15 9:51 UTC (permalink / raw)
To: linux-kernel, linux-iio, devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan, Rodrigo Alencar
In-Reply-To: <20260415-adf41513-iio-driver-v10-0-df61046d5457@analog.com>
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add ABI documentation file for PLL/DDS devices with frequency_resolution
sysfs entry attribute used by both ADF4350 and ADF41513.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
Documentation/ABI/testing/sysfs-bus-iio-frequency | 11 +++++++++++
Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 | 10 ----------
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency b/Documentation/ABI/testing/sysfs-bus-iio-frequency
new file mode 100644
index 000000000000..1ce8ae578fd6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency
@@ -0,0 +1,11 @@
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_resolution
+KernelVersion: 6.20
+Contact: linux-iio@vger.kernel.org
+Description:
+ Stores channel Y frequency resolution/channel spacing in Hz for PLL
+ devices. The given value directly influences the operating mode when
+ fractional-N synthesis is required, as it derives values for
+ configurable modulus parameters used in the calculation of the output
+ frequency. It is assumed that the algorithm that is used to compute
+ the various dividers, is able to generate proper values for multiples
+ of channel spacing.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
index 1254457a726e..76987a119feb 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
+++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
@@ -1,13 +1,3 @@
-What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_resolution
-KernelVersion: 3.4.0
-Contact: linux-iio@vger.kernel.org
-Description:
- Stores channel Y frequency resolution/channel spacing in Hz.
- The value given directly influences the MODULUS used by
- the fractional-N PLL. It is assumed that the algorithm
- that is used to compute the various dividers, is able to
- generate proper values for multiples of channel spacing.
-
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_refin_frequency
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH v10 10/11] docs: iio: add documentation for adf41513 driver
From: Rodrigo Alencar via B4 Relay @ 2026-04-15 9:51 UTC (permalink / raw)
To: linux-kernel, linux-iio, devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan, Rodrigo Alencar
In-Reply-To: <20260415-adf41513-iio-driver-v10-0-df61046d5457@analog.com>
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add documentation for ADF41513 driver, which describes the device
driver files and shows how userspace may consume the ABI for various
tasks.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
Documentation/iio/adf41513.rst | 199 +++++++++++++++++++++++++++++++++++++++++
Documentation/iio/index.rst | 1 +
MAINTAINERS | 1 +
3 files changed, 201 insertions(+)
diff --git a/Documentation/iio/adf41513.rst b/Documentation/iio/adf41513.rst
new file mode 100644
index 000000000000..4193c825b532
--- /dev/null
+++ b/Documentation/iio/adf41513.rst
@@ -0,0 +1,199 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============
+ADF41513 driver
+===============
+
+This driver supports Analog Devices' ADF41513 and similar SPI PLL frequency
+synthesizers.
+
+1. Supported devices
+====================
+
+* `ADF41510 <https://www.analog.com/ADF41510>`_
+* `ADF41513 <https://www.analog.com/ADF41513>`_
+
+The ADF41513 is an ultralow noise frequency synthesizer that can be used to
+implement local oscillators (LOs) as high as 26.5 GHz in the upconversion and
+downconversion sections of wireless receivers and transmitters. The ADF41510
+is a similar device that supports frequencies up to 10 GHz.
+
+Both devices support integer-N and fractional-N operation modes, providing
+excellent phase noise performance and flexible frequency generation
+capabilities.
+
+Key Features:
+
+- **ADF41510**: 1 GHz to 10 GHz frequency range
+- **ADF41513**: 1 GHz to 26.5 GHz frequency range
+- Integer-N and fractional-N operation modes
+- Ultra-low phase noise (-235 dBc/Hz integer-N, -231 dBc/Hz fractional-N)
+- High maximum PFD frequency (250 MHz integer-N, 125 MHz fractional-N)
+- 25-bit fixed modulus or 49-bit variable modulus fractional modes
+- Programmable charge pump currents with 16x range
+- Digital lock detect functionality
+- Phase resync capability for consistent output phase
+
+2. Device attributes
+====================
+
+The ADF41513 driver provides the following IIO extended attributes for
+frequency control and monitoring:
+
+Each IIO device has a device folder under ``/sys/bus/iio/devices/iio:deviceX``,
+where X is the IIO index of the device. Under these folders reside a set of
+device files that provide access to the synthesizer's functionality.
+
+The following table shows the ADF41513 related device files:
+
++----------------------+-------------------------------------------------------+
+| Device file | Description |
++======================+=======================================================+
+| frequency | RF output frequency control and readback (Hz) |
++----------------------+-------------------------------------------------------+
+| frequency_resolution | Target frequency resolution control (Hz) |
++----------------------+-------------------------------------------------------+
+| powerdown | Power management control (0=active, 1=power down) |
++----------------------+-------------------------------------------------------+
+| phase | RF output phase adjustment and readback (radians) |
++----------------------+-------------------------------------------------------+
+
+2.1 Frequency Control
+----------------------
+
+The ``frequency`` attribute controls the RF output frequency with sub-Hz
+precision. The driver automatically selects between integer-N and fractional-N
+modes to achieve the requested frequency with the best possible phase noise
+performance.
+
+**Supported ranges:**
+
+- **ADF41510**: 1,000,000,000 Hz to 10,000,000,000 Hz (1 GHz to 10 GHz)
+- **ADF41513**: 1,000,000,000 Hz to 26,500,000,000 Hz (1 GHz to 26.5 GHz)
+
+The frequency is specified in Hz, for sub-Hz precision use decimal notation.
+For example, 12.102 GHz would be written as "12102000000.000000".
+
+2.2 Frequency Resolution Control
+--------------------------------
+
+The ``frequency_resolution`` attribute controls the target frequency resolution
+that the driver attempts to achieve. This affects the choice between integer-N
+and fractional-N modes, including fixed modulus (25-bit) and variable modulus
+(49-bit) fractional-N modes:
+
+- **Integer-N**: Resolution = f_PFD
+- **Fixed modulus**: Resolution = f_PFD / 2^25 (~3 Hz with 100 MHz PFD)
+- **Variable modulus**: Resolution = f_PFD / 2^49 (µHz resolution possible)
+
+Default resolution is 1 Hz (1,000,000 µHz).
+
+2.3 Phase adjustment
+--------------------
+
+The ``phase`` attribute allows adjustment of the output phase in radians.
+Setting this attribute enables phase adjustment. It can be set from 0 to 2*pi
+radians. Reading this attribute returns the current phase offset of the output
+signal. To create a consistent phase relationship with the reference signal,
+the phase resync feature needs to be enabled by setting a non-zero value to the
+``adi,phase-resync-period-ns`` device property, which triggers a phase
+resynchronization after locking is achieved.
+
+3. Operating modes
+==================
+
+3.1 Integer-N Mode
+------------------
+
+When the requested frequency can be achieved as an integer multiple of the PFD
+frequency (within the specified resolution tolerance), the driver automatically
+selects integer-N mode for optimal phase noise performance.
+
+In integer-N mode:
+
+- Phase noise: -235 dBc/Hz normalized floor
+- Frequency resolution: f_PFD (same as PFD frequency)
+- Maximum PFD frequency: 250 MHz
+- Bleed current: Disabled
+
+3.2 Fractional-N Mode
+---------------------
+
+When sub-integer frequency steps are required, the driver automatically selects
+fractional-N mode using either fixed or variable modulus.
+
+**Fixed Modulus (25-bit)**:
+
+- Used when variable modulus is not required
+- Resolution: f_PFD / 2^25
+- Simpler implementation, faster settling
+
+**Variable Modulus (49-bit)**:
+
+- Used for maximum resolution requirements
+- Resolution: f_PFD / 2^49 (theoretical)
+- Exact frequency synthesis capability
+
+In fractional-N mode:
+
+- Phase noise: -231 dBc/Hz normalized floor
+- Maximum PFD frequency: 125 MHz
+- Bleed current: Automatically enabled and optimized
+- Dithering: Enabled to reduce fractional spurs
+
+3.3 Automatic Mode Selection
+----------------------------
+
+The driver automatically selects the optimal operating mode based on:
+
+1. **Frequency accuracy requirements**: Determined by frequency_resolution setting
+2. **Phase noise optimization**: Integer-N preferred when possible
+3. **PFD frequency constraints**: Different limits for integer vs fractional modes
+4. **Prescaler selection**: Automatic 4/5 vs 8/9 prescaler selection based on frequency
+
+4. Usage examples
+=================
+
+4.1 Basic Frequency Setting
+----------------------------
+
+Set output frequency to 12.102 GHz:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 12102000000 > out_altvoltage0_frequency
+
+Read current frequency:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat out_altvoltage0_frequency
+ 12101999999.582767
+
+4.2 High Resolution Frequency Control
+-------------------------------------
+
+Configure for sub-Hz resolution and set a precise frequency:
+
+.. code-block:: bash
+
+ # Set resolution to 0.1 Hz (100,000 µHz)
+ root:/sys/bus/iio/devices/iio:device0> echo 0.1 > out_altvoltage0_frequency_resolution
+
+ # Set frequency to 12.102 GHz (1 µHz precision)
+ root:/sys/bus/iio/devices/iio:device0> echo 12102000000 > out_altvoltage0_frequency
+ root:/sys/bus/iio/devices/iio:device0> cat out_altvoltage0_frequency
+ 12101999999.980131
+
+4.3 Monitor Lock Status
+-----------------------
+
+When lock detect GPIO is configured, check if PLL is locked:
+
+.. code-block:: bash
+
+ # Read frequency - will return error if not locked
+ root:/sys/bus/iio/devices/iio:device0> cat out_altvoltage0_frequency
+
+If the PLL is not locked, the frequency read will return ``-EBUSY`` (Device or
+resource busy).
diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
index ba3e609c6a13..605871765c78 100644
--- a/Documentation/iio/index.rst
+++ b/Documentation/iio/index.rst
@@ -30,6 +30,7 @@ Industrial I/O Kernel Drivers
ad7625
ad7944
ade9000
+ adf41513
adis16475
adis16480
adis16550
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e28f54cb34f..37fc22dc525b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1660,6 +1660,7 @@ L: linux-iio@vger.kernel.org
S: Supported
W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/frequency/adi,adf41513.yaml
+F: Documentation/iio/adf41513.rst
F: drivers/iio/frequency/adf41513.c
ANALOG DEVICES INC ADF4377 DRIVER
--
2.43.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