* [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] 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
* 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 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 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
* 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
* [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
* [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 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 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
* 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 0/2] Introduce TLMM driver for Qualcomm IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-04-15 11:29 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel,
Kathiravan Thirumoorthy
The IPQ9650 is Qualcomm's SoC for Routers, Gateways and Access Points.
Add the pinctrl support for the same.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Kathiravan Thirumoorthy (2):
dt-bindings: pinctrl: qcom: add IPQ9650 pinctrl
pinctrl: qcom: Introduce IPQ9650 TLMM driver
.../bindings/pinctrl/qcom,ipq9650-tlmm.yaml | 118 ++++
drivers/pinctrl/qcom/Kconfig.msm | 9 +
drivers/pinctrl/qcom/Makefile | 1 +
drivers/pinctrl/qcom/pinctrl-ipq9650.c | 762 +++++++++++++++++++++
4 files changed, 890 insertions(+)
---
base-commit: e6efabc0afca02efa263aba533f35d90117ab283
change-id: 20260326-ipq9650_tlmm-2a1cea46fc91
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: pinctrl: qcom: add IPQ9650 pinctrl
From: Kathiravan Thirumoorthy @ 2026-04-15 11:29 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel,
Kathiravan Thirumoorthy
In-Reply-To: <20260415-ipq9650_tlmm-v1-0-bd16ccb06332@oss.qualcomm.com>
Add device tree bindings for IPQ9650 TLMM block.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
.../bindings/pinctrl/qcom,ipq9650-tlmm.yaml | 118 +++++++++++++++++++++
1 file changed, 118 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq9650-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9650-tlmm.yaml
new file mode 100644
index 000000000000..549eaa6aa11b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9650-tlmm.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq9650-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm IPQ9650 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ9650 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,ipq9650-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 27
+
+ gpio-line-names:
+ maxItems: 54
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq9650-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq9650-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq9650-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-4][0-9]|5[0-3])$"
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char_start, atest_char_status0, atest_char_status1,
+ atest_char_status2, atest_char_status3, atest_tic_en,
+ audio_pri_mclk_in0, audio_pri_mclk_out0, audio_pri_mclk_in1,
+ audio_pri_mclk_out1, audio_pri, audio_sec, audio_sec_mclk_in0,
+ audio_sec_mclk_out0, audio_sec_mclk_in1, audio_sec_mclk_out1,
+ core_voltage_0, core_voltage_1, core_voltage_2, core_voltage_3,
+ core_voltage_4, cri_rng0, cri_rng1, cri_rng2, dbg_out_clk,
+ gcc_plltest_bypassnl, gcc_plltest_resetn, gcc_tlmm, gpio,
+ mdc_mst, mdc_slv0, mdc_slv1, mdio_mst, mdio_slv, mdio_slv0,
+ mdio_slv1, pcie0_clk_req_n, pcie0_wake, pcie1_clk_req_n,
+ pcie1_wake, pcie2_clk_req_n, pcie2_wake, pcie3_clk_req_n,
+ pcie3_wake, pcie4_clk_req_n, pcie4_wake, pll_bist_sync,
+ pll_test, pwm, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1,
+ qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_a0,
+ qdss_cti_trig_out_a1, qdss_cti_trig_out_b0, qdss_cti_trig_out_b1,
+ qdss_traceclk_a, qdss_tracectl_a, qdss_tracedata_a, qspi_data,
+ qspi_clk, qspi_cs_n, qup_se0, qup_se1, qup_se2, qup_se3,
+ qup_se4, qup_se5, qup_se6, qup_se7, resout, rx_los0, rx_los1,
+ rx_los2, sdc_clk, sdc_cmd, sdc_data, tsens_max, tsn ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq9650-tlmm";
+ reg = <0x01000000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 54>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ qup-uart1-default-state {
+ pins = "gpio43", "gpio44";
+ function = "qup_se6";
+ drive-strength = <8>;
+ bias-pull-down;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] pinctrl: qcom: Introduce IPQ9650 TLMM driver
From: Kathiravan Thirumoorthy @ 2026-04-15 11:29 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel,
Kathiravan Thirumoorthy
In-Reply-To: <20260415-ipq9650_tlmm-v1-0-bd16ccb06332@oss.qualcomm.com>
Qualcomm's IPQ9650 comes with a TLMM block, like all other platforms,
so add a driver for it.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
drivers/pinctrl/qcom/Kconfig.msm | 9 +
drivers/pinctrl/qcom/Makefile | 1 +
drivers/pinctrl/qcom/pinctrl-ipq9650.c | 762 +++++++++++++++++++++++++++++++++
3 files changed, 772 insertions(+)
diff --git a/drivers/pinctrl/qcom/Kconfig.msm b/drivers/pinctrl/qcom/Kconfig.msm
index 836cdeca1006..0d6f698e26ec 100644
--- a/drivers/pinctrl/qcom/Kconfig.msm
+++ b/drivers/pinctrl/qcom/Kconfig.msm
@@ -120,6 +120,15 @@ config PINCTRL_IPQ9574
Qualcomm Technologies Inc. IPQ9574 platform. Select this for
IPQ9574.
+config PINCTRL_IPQ9650
+ tristate "Qualcomm Technologies, Inc. IPQ9650 pin controller driver"
+ depends on ARM64 || COMPILE_TEST
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for
+ the Qualcomm Technologies Inc. TLMM block found on the
+ Qualcomm Technologies Inc. IPQ9650 platform. Select this for
+ IPQ9650.
+
config PINCTRL_KAANAPALI
tristate "Qualcomm Technologies Inc Kaanapali pin controller driver"
depends on ARM64 || COMPILE_TEST
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 84bda3ada874..f0bb1920b27b 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_PINCTRL_IPQ5424) += pinctrl-ipq5424.o
obj-$(CONFIG_PINCTRL_IPQ8074) += pinctrl-ipq8074.o
obj-$(CONFIG_PINCTRL_IPQ6018) += pinctrl-ipq6018.o
obj-$(CONFIG_PINCTRL_IPQ9574) += pinctrl-ipq9574.o
+obj-$(CONFIG_PINCTRL_IPQ9650) += pinctrl-ipq9650.o
obj-$(CONFIG_PINCTRL_KAANAPALI) += pinctrl-kaanapali.o
obj-$(CONFIG_PINCTRL_MSM8226) += pinctrl-msm8226.o
obj-$(CONFIG_PINCTRL_MSM8660) += pinctrl-msm8660.o
diff --git a/drivers/pinctrl/qcom/pinctrl-ipq9650.c b/drivers/pinctrl/qcom/pinctrl-ipq9650.c
new file mode 100644
index 000000000000..64e443aa31b2
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-ipq9650.c
@@ -0,0 +1,762 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include "pinctrl-msm.h"
+
+#define REG_SIZE 0x1000
+#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9) \
+ { \
+ .grp = PINCTRL_PINGROUP("gpio" #id, \
+ gpio##id##_pins, \
+ ARRAY_SIZE(gpio##id##_pins)), \
+ .ctl_reg = REG_SIZE * id, \
+ .io_reg = 0x4 + REG_SIZE * id, \
+ .intr_cfg_reg = 0x8 + REG_SIZE * id, \
+ .intr_status_reg = 0xc + REG_SIZE * id, \
+ .mux_bit = 2, \
+ .pull_bit = 0, \
+ .drv_bit = 6, \
+ .oe_bit = 9, \
+ .in_bit = 0, \
+ .out_bit = 1, \
+ .intr_enable_bit = 0, \
+ .intr_status_bit = 0, \
+ .intr_target_bit = 5, \
+ .intr_target_kpss_val = 3, \
+ .intr_raw_status_bit = 4, \
+ .intr_polarity_bit = 1, \
+ .intr_detection_bit = 2, \
+ .intr_detection_width = 2, \
+ .funcs = (int[]){ \
+ msm_mux_gpio, /* gpio mode */ \
+ msm_mux_##f1, \
+ msm_mux_##f2, \
+ msm_mux_##f3, \
+ msm_mux_##f4, \
+ msm_mux_##f5, \
+ msm_mux_##f6, \
+ msm_mux_##f7, \
+ msm_mux_##f8, \
+ msm_mux_##f9, \
+ }, \
+ .nfuncs = 10, \
+ }
+
+static const struct pinctrl_pin_desc ipq9650_pins[] = {
+ PINCTRL_PIN(0, "GPIO_0"),
+ PINCTRL_PIN(1, "GPIO_1"),
+ PINCTRL_PIN(2, "GPIO_2"),
+ PINCTRL_PIN(3, "GPIO_3"),
+ PINCTRL_PIN(4, "GPIO_4"),
+ PINCTRL_PIN(5, "GPIO_5"),
+ PINCTRL_PIN(6, "GPIO_6"),
+ PINCTRL_PIN(7, "GPIO_7"),
+ PINCTRL_PIN(8, "GPIO_8"),
+ PINCTRL_PIN(9, "GPIO_9"),
+ PINCTRL_PIN(10, "GPIO_10"),
+ PINCTRL_PIN(11, "GPIO_11"),
+ PINCTRL_PIN(12, "GPIO_12"),
+ PINCTRL_PIN(13, "GPIO_13"),
+ PINCTRL_PIN(14, "GPIO_14"),
+ PINCTRL_PIN(15, "GPIO_15"),
+ PINCTRL_PIN(16, "GPIO_16"),
+ PINCTRL_PIN(17, "GPIO_17"),
+ PINCTRL_PIN(18, "GPIO_18"),
+ PINCTRL_PIN(19, "GPIO_19"),
+ PINCTRL_PIN(20, "GPIO_20"),
+ PINCTRL_PIN(21, "GPIO_21"),
+ PINCTRL_PIN(22, "GPIO_22"),
+ PINCTRL_PIN(23, "GPIO_23"),
+ PINCTRL_PIN(24, "GPIO_24"),
+ PINCTRL_PIN(25, "GPIO_25"),
+ PINCTRL_PIN(26, "GPIO_26"),
+ PINCTRL_PIN(27, "GPIO_27"),
+ PINCTRL_PIN(28, "GPIO_28"),
+ PINCTRL_PIN(29, "GPIO_29"),
+ PINCTRL_PIN(30, "GPIO_30"),
+ PINCTRL_PIN(31, "GPIO_31"),
+ PINCTRL_PIN(32, "GPIO_32"),
+ PINCTRL_PIN(33, "GPIO_33"),
+ PINCTRL_PIN(34, "GPIO_34"),
+ PINCTRL_PIN(35, "GPIO_35"),
+ PINCTRL_PIN(36, "GPIO_36"),
+ PINCTRL_PIN(37, "GPIO_37"),
+ PINCTRL_PIN(38, "GPIO_38"),
+ PINCTRL_PIN(39, "GPIO_39"),
+ PINCTRL_PIN(40, "GPIO_40"),
+ PINCTRL_PIN(41, "GPIO_41"),
+ PINCTRL_PIN(42, "GPIO_42"),
+ PINCTRL_PIN(43, "GPIO_43"),
+ PINCTRL_PIN(44, "GPIO_44"),
+ PINCTRL_PIN(45, "GPIO_45"),
+ PINCTRL_PIN(46, "GPIO_46"),
+ PINCTRL_PIN(47, "GPIO_47"),
+ PINCTRL_PIN(48, "GPIO_48"),
+ PINCTRL_PIN(49, "GPIO_49"),
+ PINCTRL_PIN(50, "GPIO_50"),
+ PINCTRL_PIN(51, "GPIO_51"),
+ PINCTRL_PIN(52, "GPIO_52"),
+ PINCTRL_PIN(53, "GPIO_53"),
+};
+
+#define DECLARE_MSM_GPIO_PINS(pin) \
+ static const unsigned int gpio##pin##_pins[] = { pin }
+DECLARE_MSM_GPIO_PINS(0);
+DECLARE_MSM_GPIO_PINS(1);
+DECLARE_MSM_GPIO_PINS(2);
+DECLARE_MSM_GPIO_PINS(3);
+DECLARE_MSM_GPIO_PINS(4);
+DECLARE_MSM_GPIO_PINS(5);
+DECLARE_MSM_GPIO_PINS(6);
+DECLARE_MSM_GPIO_PINS(7);
+DECLARE_MSM_GPIO_PINS(8);
+DECLARE_MSM_GPIO_PINS(9);
+DECLARE_MSM_GPIO_PINS(10);
+DECLARE_MSM_GPIO_PINS(11);
+DECLARE_MSM_GPIO_PINS(12);
+DECLARE_MSM_GPIO_PINS(13);
+DECLARE_MSM_GPIO_PINS(14);
+DECLARE_MSM_GPIO_PINS(15);
+DECLARE_MSM_GPIO_PINS(16);
+DECLARE_MSM_GPIO_PINS(17);
+DECLARE_MSM_GPIO_PINS(18);
+DECLARE_MSM_GPIO_PINS(19);
+DECLARE_MSM_GPIO_PINS(20);
+DECLARE_MSM_GPIO_PINS(21);
+DECLARE_MSM_GPIO_PINS(22);
+DECLARE_MSM_GPIO_PINS(23);
+DECLARE_MSM_GPIO_PINS(24);
+DECLARE_MSM_GPIO_PINS(25);
+DECLARE_MSM_GPIO_PINS(26);
+DECLARE_MSM_GPIO_PINS(27);
+DECLARE_MSM_GPIO_PINS(28);
+DECLARE_MSM_GPIO_PINS(29);
+DECLARE_MSM_GPIO_PINS(30);
+DECLARE_MSM_GPIO_PINS(31);
+DECLARE_MSM_GPIO_PINS(32);
+DECLARE_MSM_GPIO_PINS(33);
+DECLARE_MSM_GPIO_PINS(34);
+DECLARE_MSM_GPIO_PINS(35);
+DECLARE_MSM_GPIO_PINS(36);
+DECLARE_MSM_GPIO_PINS(37);
+DECLARE_MSM_GPIO_PINS(38);
+DECLARE_MSM_GPIO_PINS(39);
+DECLARE_MSM_GPIO_PINS(40);
+DECLARE_MSM_GPIO_PINS(41);
+DECLARE_MSM_GPIO_PINS(42);
+DECLARE_MSM_GPIO_PINS(43);
+DECLARE_MSM_GPIO_PINS(44);
+DECLARE_MSM_GPIO_PINS(45);
+DECLARE_MSM_GPIO_PINS(46);
+DECLARE_MSM_GPIO_PINS(47);
+DECLARE_MSM_GPIO_PINS(48);
+DECLARE_MSM_GPIO_PINS(49);
+DECLARE_MSM_GPIO_PINS(50);
+DECLARE_MSM_GPIO_PINS(51);
+DECLARE_MSM_GPIO_PINS(52);
+DECLARE_MSM_GPIO_PINS(53);
+
+enum ipq9650_functions {
+ msm_mux_atest_char_start,
+ msm_mux_atest_char_status0,
+ msm_mux_atest_char_status1,
+ msm_mux_atest_char_status2,
+ msm_mux_atest_char_status3,
+ msm_mux_atest_tic_en,
+ msm_mux_audio_pri_mclk_in0,
+ msm_mux_audio_pri_mclk_out0,
+ msm_mux_audio_pri_mclk_in1,
+ msm_mux_audio_pri_mclk_out1,
+ msm_mux_audio_pri,
+ msm_mux_audio_sec,
+ msm_mux_audio_sec_mclk_in0,
+ msm_mux_audio_sec_mclk_out0,
+ msm_mux_audio_sec_mclk_in1,
+ msm_mux_audio_sec_mclk_out1,
+ msm_mux_core_voltage_0,
+ msm_mux_core_voltage_1,
+ msm_mux_core_voltage_2,
+ msm_mux_core_voltage_3,
+ msm_mux_core_voltage_4,
+ msm_mux_cri_rng0,
+ msm_mux_cri_rng1,
+ msm_mux_cri_rng2,
+ msm_mux_dbg_out_clk,
+ msm_mux_gcc_plltest_bypassnl,
+ msm_mux_gcc_plltest_resetn,
+ msm_mux_gcc_tlmm,
+ msm_mux_gpio,
+ msm_mux_mdc_mst,
+ msm_mux_mdc_slv0,
+ msm_mux_mdc_slv1,
+ msm_mux_mdio_mst,
+ msm_mux_mdio_slv,
+ msm_mux_mdio_slv0,
+ msm_mux_mdio_slv1,
+ msm_mux_pcie0_clk_req_n,
+ msm_mux_pcie0_wake,
+ msm_mux_pcie1_clk_req_n,
+ msm_mux_pcie1_wake,
+ msm_mux_pcie2_clk_req_n,
+ msm_mux_pcie2_wake,
+ msm_mux_pcie3_clk_req_n,
+ msm_mux_pcie3_wake,
+ msm_mux_pcie4_clk_req_n,
+ msm_mux_pcie4_wake,
+ msm_mux_pll_bist_sync,
+ msm_mux_pll_test,
+ msm_mux_pwm,
+ msm_mux_qdss_cti_trig_in_a0,
+ msm_mux_qdss_cti_trig_in_a1,
+ msm_mux_qdss_cti_trig_in_b0,
+ msm_mux_qdss_cti_trig_in_b1,
+ msm_mux_qdss_cti_trig_out_a0,
+ msm_mux_qdss_cti_trig_out_a1,
+ msm_mux_qdss_cti_trig_out_b0,
+ msm_mux_qdss_cti_trig_out_b1,
+ msm_mux_qdss_traceclk_a,
+ msm_mux_qdss_tracectl_a,
+ msm_mux_qdss_tracedata_a,
+ msm_mux_qspi_data,
+ msm_mux_qspi_clk,
+ msm_mux_qspi_cs_n,
+ msm_mux_qup_se0,
+ msm_mux_qup_se1,
+ msm_mux_qup_se2,
+ msm_mux_qup_se3,
+ msm_mux_qup_se4,
+ msm_mux_qup_se5,
+ msm_mux_qup_se6,
+ msm_mux_qup_se7,
+ msm_mux_resout,
+ msm_mux_rx_los0,
+ msm_mux_rx_los1,
+ msm_mux_rx_los2,
+ msm_mux_sdc_clk,
+ msm_mux_sdc_cmd,
+ msm_mux_sdc_data,
+ msm_mux_tsens_max,
+ msm_mux_tsn,
+ msm_mux__,
+};
+
+static const char *const gpio_groups[] = {
+ "gpio0", "gpio1", "gpio2", "gpio3", "gpio4", "gpio5", "gpio6",
+ "gpio7", "gpio8", "gpio9", "gpio10", "gpio11", "gpio12", "gpio13",
+ "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19", "gpio20",
+ "gpio21", "gpio22", "gpio23", "gpio24", "gpio25", "gpio26", "gpio27",
+ "gpio28", "gpio29", "gpio30", "gpio31", "gpio32", "gpio33", "gpio34",
+ "gpio35", "gpio36", "gpio37", "gpio38", "gpio39", "gpio40", "gpio41",
+ "gpio42", "gpio43", "gpio44", "gpio45", "gpio46", "gpio47", "gpio48",
+ "gpio49", "gpio50", "gpio51", "gpio52", "gpio53",
+};
+
+static const char *const atest_char_start_groups[] = {
+ "gpio21",
+};
+
+static const char *const atest_char_status0_groups[] = {
+ "gpio33",
+};
+
+static const char *const atest_char_status1_groups[] = {
+ "gpio35",
+};
+
+static const char *const atest_char_status2_groups[] = {
+ "gpio22",
+};
+
+static const char *const atest_char_status3_groups[] = {
+ "gpio23",
+};
+
+static const char *const atest_tic_en_groups[] = {
+ "gpio53",
+};
+
+static const char *const audio_pri_mclk_in0_groups[] = {
+ "gpio53",
+};
+
+static const char *const audio_pri_mclk_out0_groups[] = {
+ "gpio53",
+};
+
+static const char *const audio_pri_mclk_in1_groups[] = {
+ "gpio51",
+};
+
+static const char *const audio_pri_mclk_out1_groups[] = {
+ "gpio51",
+};
+
+static const char *const audio_pri_groups[] = {
+ "gpio36", "gpio37", "gpio38", "gpio39",
+};
+
+static const char *const audio_sec_mclk_in0_groups[] = {
+ "gpio37",
+};
+
+static const char *const audio_sec_mclk_out0_groups[] = {
+ "gpio37",
+};
+
+static const char *const audio_sec_mclk_in1_groups[] = {
+ "gpio37",
+};
+
+static const char *const audio_sec_mclk_out1_groups[] = {
+ "gpio37",
+};
+
+static const char *const audio_sec_groups[] = {
+ "gpio45", "gpio46", "gpio47", "gpio48",
+};
+
+static const char *const core_voltage_0_groups[] = {
+ "gpio16",
+};
+
+static const char *const core_voltage_1_groups[] = {
+ "gpio17",
+};
+
+static const char *const core_voltage_2_groups[] = {
+ "gpio33",
+};
+
+static const char *const core_voltage_3_groups[] = {
+ "gpio34",
+};
+
+static const char *const core_voltage_4_groups[] = {
+ "gpio35",
+};
+
+static const char *const cri_rng0_groups[] = {
+ "gpio6",
+};
+
+static const char *const cri_rng1_groups[] = {
+ "gpio7",
+};
+
+static const char *const cri_rng2_groups[] = {
+ "gpio8",
+};
+
+static const char *const dbg_out_clk_groups[] = {
+ "gpio46",
+};
+
+static const char *const gcc_plltest_bypassnl_groups[] = {
+ "gpio33",
+};
+
+static const char *const gcc_plltest_resetn_groups[] = {
+ "gpio35",
+};
+
+static const char *const gcc_tlmm_groups[] = {
+ "gpio34",
+};
+
+static const char *const mdc_mst_groups[] = {
+ "gpio22",
+};
+
+static const char *const mdc_slv0_groups[] = {
+ "gpio20",
+};
+
+static const char *const mdc_slv1_groups[] = {
+ "gpio14",
+};
+
+static const char *const mdio_mst_groups[] = {
+ "gpio23",
+};
+
+static const char *const mdio_slv_groups[] = {
+ "gpio46",
+ "gpio47",
+};
+
+static const char *const mdio_slv0_groups[] = {
+ "gpio21",
+};
+
+static const char *const mdio_slv1_groups[] = {
+ "gpio15",
+};
+
+static const char *const pcie0_clk_req_n_groups[] = {
+ "gpio24",
+};
+
+static const char *const pcie0_wake_groups[] = {
+ "gpio26",
+};
+
+static const char *const pcie1_clk_req_n_groups[] = {
+ "gpio27",
+};
+
+static const char *const pcie1_wake_groups[] = {
+ "gpio29",
+};
+
+static const char *const pcie2_clk_req_n_groups[] = {
+ "gpio51",
+};
+
+static const char *const pcie2_wake_groups[] = {
+ "gpio53",
+};
+
+static const char *const pcie3_clk_req_n_groups[] = {
+ "gpio40",
+};
+
+static const char *const pcie3_wake_groups[] = {
+ "gpio42",
+};
+
+static const char *const pcie4_clk_req_n_groups[] = {
+ "gpio30",
+};
+
+static const char *const pcie4_wake_groups[] = {
+ "gpio32",
+};
+
+static const char *const pll_bist_sync_groups[] = {
+ "gpio47",
+};
+
+static const char *const pll_test_groups[] = {
+ "gpio39",
+};
+
+static const char *const pwm_groups[] = {
+ "gpio6", "gpio7", "gpio8", "gpio9", "gpio10", "gpio11", "gpio16",
+ "gpio17", "gpio33", "gpio34", "gpio35", "gpio43", "gpio44", "gpio45",
+ "gpio46", "gpio47", "gpio48",
+};
+
+static const char *const qdss_cti_trig_in_a0_groups[] = {
+ "gpio53",
+};
+
+static const char *const qdss_cti_trig_in_a1_groups[] = {
+ "gpio29",
+};
+
+static const char *const qdss_cti_trig_in_b0_groups[] = {
+ "gpio42",
+};
+
+static const char *const qdss_cti_trig_in_b1_groups[] = {
+ "gpio43",
+};
+
+static const char *const qdss_cti_trig_out_a0_groups[] = {
+ "gpio51",
+};
+
+static const char *const qdss_cti_trig_out_a1_groups[] = {
+ "gpio27",
+};
+
+static const char *const qdss_cti_trig_out_b0_groups[] = {
+ "gpio40",
+};
+
+static const char *const qdss_cti_trig_out_b1_groups[] = {
+ "gpio44",
+};
+
+static const char *const qdss_traceclk_a_groups[] = {
+ "gpio45",
+};
+
+static const char *const qdss_tracectl_a_groups[] = {
+ "gpio46",
+};
+
+static const char *const qdss_tracedata_a_groups[] = {
+ "gpio6", "gpio7", "gpio8", "gpio9", "gpio10", "gpio11",
+ "gpio12", "gpio13", "gpio14", "gpio15", "gpio20", "gpio21",
+ "gpio36", "gpio37", "gpio38", "gpio39",
+};
+
+static const char *const qspi_data_groups[] = {
+ "gpio0", "gpio1", "gpio2", "gpio3",
+};
+
+static const char *const qspi_clk_groups[] = {
+ "gpio5",
+};
+
+static const char *const qspi_cs_n_groups[] = {
+ "gpio4",
+};
+
+static const char *const qup_se0_groups[] = {
+ "gpio6", "gpio7", "gpio8", "gpio9", "gpio51", "gpio53",
+};
+
+static const char *const qup_se1_groups[] = {
+ "gpio10", "gpio11", "gpio12", "gpio13", "gpio27", "gpio29",
+};
+
+static const char *const qup_se2_groups[] = {
+ "gpio27", "gpio29", "gpio33", "gpio34",
+};
+
+static const char *const qup_se3_groups[] = {
+ "gpio16", "gpio17", "gpio20", "gpio21",
+};
+
+static const char *const qup_se4_groups[] = {
+ "gpio14", "gpio15", "gpio40", "gpio42", "gpio43", "gpio44",
+};
+
+static const char *const qup_se5_groups[] = {
+ "gpio40", "gpio42", "gpio45", "gpio46", "gpio47", "gpio48",
+};
+
+static const char *const qup_se6_groups[] = {
+ "gpio43", "gpio44", "gpio51", "gpio53",
+};
+
+static const char *const qup_se7_groups[] = {
+ "gpio36", "gpio37", "gpio38", "gpio39",
+};
+
+static const char *const resout_groups[] = {
+ "gpio49",
+};
+
+static const char *const rx_los0_groups[] = {
+ "gpio39", "gpio47", "gpio50",
+};
+
+static const char *const rx_los1_groups[] = {
+ "gpio38", "gpio46",
+};
+
+static const char *const rx_los2_groups[] = {
+ "gpio37", "gpio45",
+};
+
+static const char *const sdc_clk_groups[] = {
+ "gpio5",
+};
+
+static const char *const sdc_cmd_groups[] = {
+ "gpio4",
+};
+
+static const char *const sdc_data_groups[] = {
+ "gpio0", "gpio1", "gpio2", "gpio3",
+};
+
+static const char *const tsens_max_groups[] = {
+ "gpio14",
+};
+
+static const char *const tsn_groups[] = {
+ "gpio50",
+};
+
+static const struct pinfunction ipq9650_functions[] = {
+ MSM_PIN_FUNCTION(atest_char_start),
+ MSM_PIN_FUNCTION(atest_char_status0),
+ MSM_PIN_FUNCTION(atest_char_status1),
+ MSM_PIN_FUNCTION(atest_char_status2),
+ MSM_PIN_FUNCTION(atest_char_status3),
+ MSM_PIN_FUNCTION(atest_tic_en),
+ MSM_PIN_FUNCTION(audio_pri_mclk_in0),
+ MSM_PIN_FUNCTION(audio_pri_mclk_out0),
+ MSM_PIN_FUNCTION(audio_pri_mclk_in1),
+ MSM_PIN_FUNCTION(audio_pri_mclk_out1),
+ MSM_PIN_FUNCTION(audio_pri),
+ MSM_PIN_FUNCTION(audio_sec),
+ MSM_PIN_FUNCTION(audio_sec_mclk_in0),
+ MSM_PIN_FUNCTION(audio_sec_mclk_out0),
+ MSM_PIN_FUNCTION(audio_sec_mclk_in1),
+ MSM_PIN_FUNCTION(audio_sec_mclk_out1),
+ MSM_PIN_FUNCTION(core_voltage_0),
+ MSM_PIN_FUNCTION(core_voltage_1),
+ MSM_PIN_FUNCTION(core_voltage_2),
+ MSM_PIN_FUNCTION(core_voltage_3),
+ MSM_PIN_FUNCTION(core_voltage_4),
+ MSM_PIN_FUNCTION(cri_rng0),
+ MSM_PIN_FUNCTION(cri_rng1),
+ MSM_PIN_FUNCTION(cri_rng2),
+ MSM_PIN_FUNCTION(dbg_out_clk),
+ MSM_PIN_FUNCTION(gcc_plltest_bypassnl),
+ MSM_PIN_FUNCTION(gcc_plltest_resetn),
+ MSM_PIN_FUNCTION(gcc_tlmm),
+ MSM_GPIO_PIN_FUNCTION(gpio),
+ MSM_PIN_FUNCTION(mdc_mst),
+ MSM_PIN_FUNCTION(mdc_slv0),
+ MSM_PIN_FUNCTION(mdc_slv1),
+ MSM_PIN_FUNCTION(mdio_mst),
+ MSM_PIN_FUNCTION(mdio_slv),
+ MSM_PIN_FUNCTION(mdio_slv0),
+ MSM_PIN_FUNCTION(mdio_slv1),
+ MSM_PIN_FUNCTION(pcie0_clk_req_n),
+ MSM_PIN_FUNCTION(pcie0_wake),
+ MSM_PIN_FUNCTION(pcie1_clk_req_n),
+ MSM_PIN_FUNCTION(pcie1_wake),
+ MSM_PIN_FUNCTION(pcie2_clk_req_n),
+ MSM_PIN_FUNCTION(pcie2_wake),
+ MSM_PIN_FUNCTION(pcie3_clk_req_n),
+ MSM_PIN_FUNCTION(pcie3_wake),
+ MSM_PIN_FUNCTION(pcie4_clk_req_n),
+ MSM_PIN_FUNCTION(pcie4_wake),
+ MSM_PIN_FUNCTION(pll_bist_sync),
+ MSM_PIN_FUNCTION(pll_test),
+ MSM_PIN_FUNCTION(pwm),
+ MSM_PIN_FUNCTION(qdss_cti_trig_in_a0),
+ MSM_PIN_FUNCTION(qdss_cti_trig_in_a1),
+ MSM_PIN_FUNCTION(qdss_cti_trig_in_b0),
+ MSM_PIN_FUNCTION(qdss_cti_trig_in_b1),
+ MSM_PIN_FUNCTION(qdss_cti_trig_out_a0),
+ MSM_PIN_FUNCTION(qdss_cti_trig_out_a1),
+ MSM_PIN_FUNCTION(qdss_cti_trig_out_b0),
+ MSM_PIN_FUNCTION(qdss_cti_trig_out_b1),
+ MSM_PIN_FUNCTION(qdss_traceclk_a),
+ MSM_PIN_FUNCTION(qdss_tracectl_a),
+ MSM_PIN_FUNCTION(qdss_tracedata_a),
+ MSM_PIN_FUNCTION(qspi_data),
+ MSM_PIN_FUNCTION(qspi_clk),
+ MSM_PIN_FUNCTION(qspi_cs_n),
+ MSM_PIN_FUNCTION(qup_se0),
+ MSM_PIN_FUNCTION(qup_se1),
+ MSM_PIN_FUNCTION(qup_se2),
+ MSM_PIN_FUNCTION(qup_se3),
+ MSM_PIN_FUNCTION(qup_se4),
+ MSM_PIN_FUNCTION(qup_se5),
+ MSM_PIN_FUNCTION(qup_se6),
+ MSM_PIN_FUNCTION(qup_se7),
+ MSM_PIN_FUNCTION(resout),
+ MSM_PIN_FUNCTION(rx_los0),
+ MSM_PIN_FUNCTION(rx_los1),
+ MSM_PIN_FUNCTION(rx_los2),
+ MSM_PIN_FUNCTION(sdc_clk),
+ MSM_PIN_FUNCTION(sdc_cmd),
+ MSM_PIN_FUNCTION(sdc_data),
+ MSM_PIN_FUNCTION(tsens_max),
+ MSM_PIN_FUNCTION(tsn),
+};
+
+static const struct msm_pingroup ipq9650_groups[] = {
+ [0] = PINGROUP(0, sdc_data, qspi_data, _, _, _, _, _, _, _),
+ [1] = PINGROUP(1, sdc_data, qspi_data, _, _, _, _, _, _, _),
+ [2] = PINGROUP(2, sdc_data, qspi_data, _, _, _, _, _, _, _),
+ [3] = PINGROUP(3, sdc_data, qspi_data, _, _, _, _, _, _, _),
+ [4] = PINGROUP(4, sdc_cmd, qspi_cs_n, _, _, _, _, _, _, _),
+ [5] = PINGROUP(5, sdc_clk, qspi_clk, _, _, _, _, _, _, _),
+ [6] = PINGROUP(6, qup_se0, pwm, _, cri_rng0, qdss_tracedata_a, _, _, _, _),
+ [7] = PINGROUP(7, qup_se0, pwm, _, cri_rng1, qdss_tracedata_a, _, _, _, _),
+ [8] = PINGROUP(8, qup_se0, pwm, _, cri_rng2, qdss_tracedata_a, _, _, _, _),
+ [9] = PINGROUP(9, qup_se0, pwm, _, qdss_tracedata_a, _, _, _, _, _),
+ [10] = PINGROUP(10, qup_se1, pwm, _, _, qdss_tracedata_a, _, _, _, _),
+ [11] = PINGROUP(11, qup_se1, pwm, _, _, qdss_tracedata_a, _, _, _, _),
+ [12] = PINGROUP(12, qup_se1, _, qdss_tracedata_a, _, _, _, _, _, _),
+ [13] = PINGROUP(13, qup_se1, _, qdss_tracedata_a, _, _, _, _, _, _),
+ [14] = PINGROUP(14, qup_se4, mdc_slv1, tsens_max, _, qdss_tracedata_a, _, _, _, _),
+ [15] = PINGROUP(15, qup_se4, mdio_slv1, _, qdss_tracedata_a, _, _, _, _, _),
+ [16] = PINGROUP(16, core_voltage_0, qup_se3, pwm, _, _, _, _, _, _),
+ [17] = PINGROUP(17, core_voltage_1, qup_se3, pwm, _, _, _, _, _, _),
+ [18] = PINGROUP(18, _, _, _, _, _, _, _, _, _),
+ [19] = PINGROUP(19, _, _, _, _, _, _, _, _, _),
+ [20] = PINGROUP(20, mdc_slv0, qup_se3, _, qdss_tracedata_a, _, _, _, _, _),
+ [21] = PINGROUP(21, mdio_slv0, qup_se3, atest_char_start, _, qdss_tracedata_a, _, _, _, _),
+ [22] = PINGROUP(22, mdc_mst, atest_char_status2, _, _, _, _, _, _, _),
+ [23] = PINGROUP(23, mdio_mst, atest_char_status3, _, _, _, _, _, _, _),
+ [24] = PINGROUP(24, pcie0_clk_req_n, _, _, _, _, _, _, _, _),
+ [25] = PINGROUP(25, _, _, _, _, _, _, _, _, _),
+ [26] = PINGROUP(26, pcie0_wake, _, _, _, _, _, _, _, _),
+ [27] = PINGROUP(27, pcie1_clk_req_n, qup_se2, qup_se1, _, qdss_cti_trig_out_a1, _, _, _, _),
+ [28] = PINGROUP(28, _, _, _, _, _, _, _, _, _),
+ [29] = PINGROUP(29, pcie1_wake, qup_se2, qup_se1, _, qdss_cti_trig_in_a1, _, _, _, _),
+ [30] = PINGROUP(30, pcie4_clk_req_n, _, _, _, _, _, _, _, _),
+ [31] = PINGROUP(31, _, _, _, _, _, _, _, _, _),
+ [32] = PINGROUP(32, pcie4_wake, _, _, _, _, _, _, _, _),
+ [33] = PINGROUP(33, core_voltage_2, qup_se2, gcc_plltest_bypassnl, pwm, atest_char_status0, _, _, _, _),
+ [34] = PINGROUP(34, core_voltage_3, qup_se2, gcc_tlmm, pwm, _, _, _, _, _),
+ [35] = PINGROUP(35, core_voltage_4, gcc_plltest_resetn, pwm, atest_char_status1, _, _, _, _, _),
+ [36] = PINGROUP(36, audio_pri, qup_se7, qdss_tracedata_a, _, _, _, _, _, _),
+ [37] = PINGROUP(37, audio_pri, qup_se7, audio_sec_mclk_out0, audio_sec_mclk_in0, rx_los2, qdss_tracedata_a, _, _, _),
+ [38] = PINGROUP(38, audio_pri, qup_se7, rx_los1, qdss_tracedata_a, _, _, _, _, _),
+ [39] = PINGROUP(39, audio_pri, qup_se7, audio_sec_mclk_out1, audio_sec_mclk_in1, pll_test, rx_los0, _, qdss_tracedata_a, _),
+ [40] = PINGROUP(40, pcie3_clk_req_n, qup_se5, qup_se4, _, qdss_cti_trig_out_b0, _, _, _, _),
+ [41] = PINGROUP(41, _, _, _, _, _, _, _, _, _),
+ [42] = PINGROUP(42, pcie3_wake, qup_se5, qup_se4, _, qdss_cti_trig_in_b0, _, _, _, _),
+ [43] = PINGROUP(43, qup_se4, qup_se6, pwm, _, qdss_cti_trig_in_b1, _, _, _, _),
+ [44] = PINGROUP(44, qup_se4, qup_se6, pwm, _, qdss_cti_trig_out_b1, _, _, _, _),
+ [45] = PINGROUP(45, qup_se5, rx_los2, audio_sec, pwm, _, qdss_traceclk_a, _, _, _),
+ [46] = PINGROUP(46, qup_se5, rx_los1, audio_sec, mdio_slv, pwm, dbg_out_clk, qdss_tracectl_a, _, _),
+ [47] = PINGROUP(47, qup_se5, rx_los0, audio_sec, mdio_slv, pll_bist_sync, pwm, _, _, _),
+ [48] = PINGROUP(48, qup_se5, audio_sec, pwm, _, _, _, _, _, _),
+ [49] = PINGROUP(49, resout, _, _, _, _, _, _, _, _),
+ [50] = PINGROUP(50, tsn, rx_los0, _, _, _, _, _, _, _),
+ [51] = PINGROUP(51, pcie2_clk_req_n, qup_se6, qup_se0, audio_pri_mclk_out1, audio_pri_mclk_in1, qdss_cti_trig_out_a0, _, _, _),
+ [52] = PINGROUP(52, _, _, _, _, _, _, _, _, _),
+ [53] = PINGROUP(53, pcie2_wake, qup_se6, qup_se0, audio_pri_mclk_out0, audio_pri_mclk_in0, qdss_cti_trig_in_a0, _, atest_tic_en, _),
+};
+
+static const struct msm_pinctrl_soc_data ipq9650_tlmm = {
+ .pins = ipq9650_pins,
+ .npins = ARRAY_SIZE(ipq9650_pins),
+ .functions = ipq9650_functions,
+ .nfunctions = ARRAY_SIZE(ipq9650_functions),
+ .groups = ipq9650_groups,
+ .ngroups = ARRAY_SIZE(ipq9650_groups),
+ .ngpios = 54,
+};
+
+static const struct of_device_id ipq9650_tlmm_of_match[] = {
+ { .compatible = "qcom,ipq9650-tlmm", },
+ {},
+};
+
+static int ipq9650_tlmm_probe(struct platform_device *pdev)
+{
+ return msm_pinctrl_probe(pdev, &ipq9650_tlmm);
+}
+
+static struct platform_driver ipq9650_tlmm_driver = {
+ .driver = {
+ .name = "ipq9650-tlmm",
+ .of_match_table = ipq9650_tlmm_of_match,
+ },
+ .probe = ipq9650_tlmm_probe,
+};
+
+static int __init ipq9650_tlmm_init(void)
+{
+ return platform_driver_register(&ipq9650_tlmm_driver);
+}
+arch_initcall(ipq9650_tlmm_init);
+
+static void __exit ipq9650_tlmm_exit(void)
+{
+ platform_driver_unregister(&ipq9650_tlmm_driver);
+}
+module_exit(ipq9650_tlmm_exit);
+
+MODULE_DESCRIPTION("QTI IPQ9650 TLMM driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/3] arm64: dts: amlogic: t7: Add UART controllers nodes
From: Xianwei Zhao @ 2026-04-15 11:38 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-2-0ba0746cc1d6@aliel.fr>
Hi Ronald,
On 2026/4/15 19:16, Ronald Claveau wrote:
> 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";
The xtal clock is defined in the board-level DTS file, while it is
referenced in the DTSI file, which seems a bit unusual.
On other chips, the xtal clock is usually defined directly in the DTSI file.
> + 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>;
^ permalink raw reply
* Re: [PATCH 04/13] clk: amlogic: Add basic clock driver
From: Chuan Liu @ 2026-04-15 11:40 UTC (permalink / raw)
To: Krzysztof Kozlowski, Neil Armstrong, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-amlogic, linux-clk, devicetree, linux-kernel,
Martin Blumenstingl
In-Reply-To: <b97c2e64-8a43-498b-a447-6a5b67c525e5@kernel.org>
Hi Krzysztof,
On 4/9/2026 2:12 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On 08/04/2026 16:32, Chuan Liu wrote:
>> Hi Krzysztof (& ALL),
>> Thanks for review.
>>
>> On 2/9/2026 9:17 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On 09/02/2026 06:48, Chuan Liu via B4 Relay wrote:
>>>> From: Chuan Liu <chuan.liu@amlogic.com>
>>>>
>>>> Implement core clock driver for Amlogic SoC platforms, supporting
>>>
>>> So how did all existing Amlogic SoC platforms work so far without basic
>>> clock driver? Really, how?
>>>
>>> You are suppose to grow existing code, not add your completely new
>>> "basic" driver just because you have it that way in downstream.
>>>
>>
>> Firstly, apologies for the delayed response. I had intended to
>> consolidate the V1 review feedback and come back with a clearer plan for
>> V2 changes. In the meantime, Martin has provided many detailed and
>> valuable suggestions - much appreciated.
>>
>> The original goal of optimizing the HW based on A9 and introducing a new
>> clock driver is to reduce unnecessary complexity in the driver. On A9,
>
> Nah, you just don't care about upstream and it is easier for you to
> duplicate new code.
Regarding the "duplicate new code": the ops implemented in clk-basic.c
are indeed based on the CCF components (clk-mux, clk-divider, clk-gate),
with the following enhancements:
- Register access via regmap (meson clock driver looks like this)
- Additional debug nodes to support Amlogic clock automated test
tools (in conjunction with clk-measure to verify hardware functionality
of each clock)
- Clock context save/restore support for STD/STR
Other drivers mainly focus on adapting to A9-specific hardware
optimizations, as well as improving and refactoring the existing meson
drivers.
>
>> we optimized the Clock/PLL controller HW to simplify driver performance,
>> complexity, memory footprint, and reusability. Improvements on the HW
>> side can also help drive corresponding enhancements in the driver:
>> - Performance: Encapsulates sub-clock functions, reducing call paths
>> - Complexity: Standardized register bits eliminate a large number of
>> bit definitions (~1/3 of original code is defined register bit [1])
>> - Memory: Object-oriented design avoids copy/paste for repeated clocks
>
> Object oriented design? Sorry, what?
In the new driver, clocks are modeled as the SoC CCU itself. For
example, pwm_a/b/c... and emmc_a/b/c use the same CCU, represented as a
"composite-ccu". We instantiate the CCU once, rather than redefining
clocks for each module.
>
>> - Reusability: Same controller works across SoCs without driver
>> changes (or with minimal changes)
>>
>> The old meson driver required compromises to unify legacy controller
>> characteristics and driver styles. On A9, we want a fresh start.
>
> And maintainers don't want that. We expressed this many times already.
> Not only in this thread - that's one of the most known feedbacks.
Thanks for the clarification.
>
> Best regards,
> Krzysztof
--
Best regards,
Chuan
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: Introduce IPQ9650 TLMM driver
From: Konrad Dybcio @ 2026-04-15 11:49 UTC (permalink / raw)
To: Kathiravan Thirumoorthy, Bjorn Andersson, Linus Walleij,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260415-ipq9650_tlmm-v1-2-bd16ccb06332@oss.qualcomm.com>
On 4/15/26 1:29 PM, Kathiravan Thirumoorthy wrote:
> Qualcomm's IPQ9650 comes with a TLMM block, like all other platforms,
> so add a driver for it.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sdm845-shift-axolotl: describe WiFi/BT properly
From: David Heidelberg via B4 Relay @ 2026-04-15 11:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
David Heidelberg
From: David Heidelberg <david@ixit.cz>
The onboard WiFi / BT device, WCN3990, has a simple on-chip PMU, which
further spreads generated voltage. Describe the PMU in the device tree.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts | 65 +++++++++++++++++++----
1 file changed, 55 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts b/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts
index 7d81198bc499c..c14a798035d1b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts
@@ -105,6 +105,43 @@ vreg_s4a_1p8: pm8998-smps4 {
vin-supply = <&vph_pwr>;
};
+
+ wcn3990-pmu {
+ compatible = "qcom,wcn3990-pmu";
+
+ pinctrl-0 = <&sw_ctrl_default>;
+ pinctrl-names = "default";
+
+ vddio-supply = <&vreg_s4a_1p8>;
+ vddxo-supply = <&vreg_l7a_1p8>;
+ vddrf-supply = <&vreg_l17a_1p3>;
+ vddch0-supply = <&vreg_l25a_3p3>;
+ vddch1-supply = <&vreg_l23a_3p3>;
+
+ swctrl-gpios = <&pm8998_gpios 3 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ vreg_pmu_io: ldo0 {
+ regulator-name = "vreg_pmu_io";
+ };
+
+ vreg_pmu_xo: ldo1 {
+ regulator-name = "vreg_pmu_xo";
+ };
+
+ vreg_pmu_rf: ldo2 {
+ regulator-name = "vreg_pmu_rf";
+ };
+
+ vreg_pmu_ch0: ldo3 {
+ regulator-name = "vreg_pmu_ch0";
+ };
+
+ vreg_pmu_ch1: ldo4 {
+ regulator-name = "vreg_pmu_ch1";
+ };
+ };
+ };
};
&adsp_pas {
@@ -526,6 +563,13 @@ &mss_pil {
};
&pm8998_gpios {
+ sw_ctrl_default: sw-ctrl-default-state {
+ pins = "gpio3";
+ function = "normal";
+ input-enable;
+ bias-pull-down;
+ };
+
volume_up_gpio: pm8998-gpio6-state {
pinconf {
pins = "gpio6";
@@ -732,10 +776,11 @@ bluetooth {
*/
firmware-name = "SHIFT/axolotl/crnv21.bin";
- vddio-supply = <&vreg_s4a_1p8>;
- vddxo-supply = <&vreg_l7a_1p8>;
- vddrf-supply = <&vreg_l17a_1p3>;
- vddch0-supply = <&vreg_l25a_3p3>;
+ vddio-supply = <&vreg_pmu_io>;
+ vddxo-supply = <&vreg_pmu_xo>;
+ vddrf-supply = <&vreg_pmu_rf>;
+ vddch0-supply = <&vreg_pmu_ch0>;
+
max-speed = <3200000>;
};
};
@@ -790,14 +835,14 @@ &venus {
};
&wifi {
- status = "okay";
-
vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
- vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
- vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
- vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
- vdd-3.3-ch1-supply = <&vreg_l23a_3p3>;
+ vdd-1.8-xo-supply = <&vreg_pmu_xo>;
+ vdd-1.3-rfa-supply = <&vreg_pmu_rf>;
+ vdd-3.3-ch0-supply = <&vreg_pmu_ch0>;
+ vdd-3.3-ch1-supply = <&vreg_pmu_ch1>;
qcom,calibration-variant = "shift_axolotl";
qcom,snoc-host-cap-8bit-quirk;
+
+ status = "okay";
};
---
base-commit: e6efabc0afca02efa263aba533f35d90117ab283
change-id: 20260415-axolotl-wifi-9280ef88618a
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: sdm845-shift-axolotl: describe WiFi/BT properly
From: Konrad Dybcio @ 2026-04-15 12:05 UTC (permalink / raw)
To: david, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260415-axolotl-wifi-v1-1-07df39cfc0a4@ixit.cz>
On 4/15/26 1:56 PM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> The onboard WiFi / BT device, WCN3990, has a simple on-chip PMU, which
> further spreads generated voltage. Describe the PMU in the device tree.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 7/7] dt-bindings: PCI: intel,lgm-pcie: Add atu resource
From: Rob Herring @ 2026-04-15 12:09 UTC (permalink / raw)
To: Florian Eckert
Cc: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Johan Hovold, Sajid Dalvi,
Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-kernel, devicetree, Eckert.Florian, ms
In-Reply-To: <20260415-pcie-intel-gw-v4-7-ad45d2418c8e@dev.tdt.de>
On Wed, Apr 15, 2026 at 3:02 AM Florian Eckert <fe@dev.tdt.de> wrote:
>
> The 'atu' information is already set in the dwc core, if it is specified
> in the devicetree. The driver uses its own default, if not set in the
> devicetree. This information is hardware specific and should therefore be
> maintained in the devicetree rather than in the source.
>
> To be backward compatible, this field is not mandatory. If 'atu'
> resource is not specified in the devicetree, the driver’s default value
> is used.
>
> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
> ---
> Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
> index 54e2890ae6314ac6847fc23f49440d05d66d87d4..9b7a8ef77585677841c7064c5001110bc2b65db1 100644
> --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
> @@ -27,16 +27,19 @@ properties:
> - const: snps,dw-pcie
>
> reg:
> + minItems: 3
> items:
> - description: Controller control and status registers.
> - description: PCIe configuration registers.
> - description: Controller application registers.
> + - description: Internal Address Translation Unit (iATU) registers.
>
> reg-names:
Don't you need minItems here?
> items:
> - const: dbi
> - const: config
> - const: app
> + - const: atu
>
> ranges:
> maxItems: 1
> @@ -95,8 +98,9 @@ examples:
> #size-cells = <2>;
> reg = <0xd0e00000 0x1000>,
> <0xd2000000 0x800000>,
> - <0xd0a41000 0x1000>;
> - reg-names = "dbi", "config", "app";
> + <0xd0a41000 0x1000>,
> + <0xd0ec0000 0x1000>;
> + reg-names = "dbi", config", "app", "atu";
> linux,pci-domain = <0>;
> max-link-speed = <4>;
> bus-range = <0x00 0x08>;
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: airoha: en7581: Enable spi nand controller for EN7581 EVB
From: Benjamin Larsson @ 2026-04-15 12:09 UTC (permalink / raw)
To: Christian Marangi (Ansuel), Lorenzo Bianconi
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
linux-mediatek, devicetree
In-Reply-To: <CA+_ehUyfP7bohsSZEbjp-KLxD084NcR+2SmhDNrpoKQE=BiHcQ@mail.gmail.com>
On 4/15/26 11:47, Christian Marangi (Ansuel) wrote:
> Il giorno mar 10 mar 2026 alle ore 18:07 Lorenzo Bianconi
> <lorenzo@kernel.org> ha scritto:
>>> 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>
>> Hi all,
>>
>> it seems this patch has been reviewed by AngeloGioacchino, but it has never
>> been applied to linux-mediatek tree (or at least I can't find it). It is marked
>> as 'New, archived' in patchwork [0]. Am I missing something?
>>
>> Regards,
>> Lorenzo
>>
>> [0] https://patchwork.kernel.org/project/linux-mediatek/patch/20250225-en7581-snfi-probe-fix-v2-1-92e35add701b@kernel.org/
>>
> Hi,
>
> friendly ping here. There are lots of patch with review tag and ACK
> also for 7583.
>
> Any chance someone can ping maintainers that take care of picking these patch?
> Or someone that can reply on how to handle this? Maybe we need to sync with
> them? Lorenzo (and also me) are fully maintaining the Airoha ARM target also on
> U-Boot. Also on OpenWrt this target is starting to get traction and is
> getting used
> there, so Airoha is not considered an abandoned target anymore.
I think the following Airoha patch set has not been picked up either:
[PATCH RESEND v3 0/2] ARM: dts: airoha: en7523: update dts
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: airoha: en7581: Enable spi nand controller for EN7581 EVB
From: Lorenzo Bianconi @ 2026-04-15 12:12 UTC (permalink / raw)
To: Benjamin Larsson
Cc: Christian Marangi (Ansuel), Matthias Brugger,
AngeloGioacchino Del Regno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-kernel, linux-mediatek, devicetree,
Arnd Bergmann
In-Reply-To: <ab5bab39-88be-4f58-aee6-2bb0dc49a732@genexis.eu>
[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]
>
> On 4/15/26 11:47, Christian Marangi (Ansuel) wrote:
> > Il giorno mar 10 mar 2026 alle ore 18:07 Lorenzo Bianconi
> > <lorenzo@kernel.org> ha scritto:
> > > > 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>
> > > Hi all,
> > >
> > > it seems this patch has been reviewed by AngeloGioacchino, but it has never
> > > been applied to linux-mediatek tree (or at least I can't find it). It is marked
> > > as 'New, archived' in patchwork [0]. Am I missing something?
> > >
> > > Regards,
> > > Lorenzo
> > >
> > > [0] https://patchwork.kernel.org/project/linux-mediatek/patch/20250225-en7581-snfi-probe-fix-v2-1-92e35add701b@kernel.org/
> > >
> > Hi,
> >
> > friendly ping here. There are lots of patch with review tag and ACK
> > also for 7583.
> >
> > Any chance someone can ping maintainers that take care of picking these patch?
> > Or someone that can reply on how to handle this? Maybe we need to sync with
> > them? Lorenzo (and also me) are fully maintaining the Airoha ARM target also on
> > U-Boot. Also on OpenWrt this target is starting to get traction and is
> > getting used
> > there, so Airoha is not considered an abandoned target anymore.
>
> I think the following Airoha patch set has not been picked up either:
>
> [PATCH RESEND v3 0/2] ARM: dts: airoha: en7523: update dts
>
> MvH
>
> Benjamin Larsson
>
ack. Thx Ben for pointing this out.
It is not clear to me if these patches should go via linux-mediatek tree.
@AngeloGioacchino @Matthias: any input about it?
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding
From: Rob Herring @ 2026-04-15 12:19 UTC (permalink / raw)
To: Michal Simek
Cc: Krzysztof Kozlowski, Ben Levinsky, andersson, mathieu.poirier,
krzk+dt, conor+dt, linux-remoteproc, devicetree, linux-kernel,
tanmay.shah
In-Reply-To: <e82faa64-22fa-4dba-8cde-f02cf9f95e25@amd.com>
On Wed, Apr 15, 2026 at 1:16 AM Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 4/14/26 19:53, Krzysztof Kozlowski wrote:
> > On 14/04/2026 18:15, Ben Levinsky wrote:
> >
> > A nit, subject: drop second/last, redundant "binding". The "dt-bindings"
> > prefix is already stating that these are bindings.
> > See also:
> > https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> >
> >> +---
> >> +$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: AMD MicroBlaze remote processor
> >> +
> >> +maintainers:
> >> + - Ben Levinsky <ben.levinsky@amd.com>
> >> +
> >> +description:
> >> + MicroBlaze remote processor controlled by Linux through the remoteproc
> >> + framework.
> >
> > Describe hardware, not Linux frameworks. IOW, Linux framework is here
> > irrelevant.
> >
> >> +
> >> + The executable firmware memory window is described in the
> >> + MicroBlaze-local address space by the node's reg property and translated
> >> + to the system physical address space with standard devicetree address
> >> + translation provided by the parent bus node's ranges property.
> >> +
> >> +properties:
> >> + $nodename:
> >> + pattern: "^remoteproc@[0-9a-f]+$"
> >> +
> >> + compatible:
> >> + const: amd,microblaze
> >
> > microblaze is architecture, so this feels way too generic. You need SoC
> > specific compatibles and I suggest do not reference architecture, but
> > name or the function of the processor, if there are such.
>
> I have been arguing internally that I think when you look at driver itself it
> can be pretty much generic loader for any firmware and doesn't really matter if
> target subsystem is Microblaze/Risc-V/whatever based. And I was suggesting them
> to use more generic name.
Generic to AMD though, not everyone, right?
I agree it probably doesn't matter what the processor arch is. The
compatible just needs to be specific enough when there's some
quirk/feature in the interface to the operating system, that we can
distinguish the specific implementation *without* a DT update.
> Because at the end of day reg property is pointing to location where firmware
> should be loaded and gpio is a way how to start that subsystem and there is
> nothing Microblaze specific.
>
> I can also imagine that the same driver could be extended with optional power
> domain, power regulator and clock properties if there is a need to drive them
> before subsystem gets out of reset.
That never works because then there's timing/ordering constraints for
enabling/disabling all those resources. Then we end up with a never
ending stream of properties added which results in a poorly designed
binding.
Rob
^ permalink raw reply
* Re: [PATCH 04/13] clk: amlogic: Add basic clock driver
From: Chuan Liu @ 2026-04-15 12:21 UTC (permalink / raw)
To: Jerome Brunet
Cc: Krzysztof Kozlowski, Neil Armstrong, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-amlogic, linux-clk, devicetree, linux-kernel,
Martin Blumenstingl
In-Reply-To: <1j7bqhtkyt.fsf@starbuckisacylon.baylibre.com>
Hi Jerome,
On 4/9/2026 1:34 AM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On mer. 08 avril 2026 at 22:32, Chuan Liu <chuan.liu@amlogic.com> wrote:
>
>> Hi Krzysztof (& ALL),
>> Thanks for review.
>>
>> On 2/9/2026 9:17 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>> On 09/02/2026 06:48, Chuan Liu via B4 Relay wrote:
>>>> From: Chuan Liu <chuan.liu@amlogic.com>
>>>>
>>>> Implement core clock driver for Amlogic SoC platforms, supporting
>>> So how did all existing Amlogic SoC platforms work so far without basic
>>> clock driver? Really, how?
>>> You are suppose to grow existing code, not add your completely new
>>> "basic" driver just because you have it that way in downstream.
>>>
>>
>> Firstly, apologies for the delayed response. I had intended to consolidate
>> the V1 review feedback and come back with a clearer plan for V2 changes. In
>> the meantime, Martin has provided many detailed and valuable suggestions -
>> much appreciated.
>>
>> The original goal of optimizing the HW based on A9 and introducing a new
>> clock driver is to reduce unnecessary complexity in the driver. On A9, we
>> optimized the Clock/PLL controller HW to simplify driver performance,
>> complexity, memory footprint, and reusability. Improvements on the HW side
>> can also help drive corresponding enhancements in the driver:
>> - Performance: Encapsulates sub-clock functions, reducing call paths
>> - Complexity: Standardized register bits eliminate a large number of
>> bit definitions (~1/3 of original code is defined register bit [1])
>> - Memory: Object-oriented design avoids copy/paste for repeated clocks
>> - Reusability: Same controller works across SoCs without driver
>> changes (or with minimal changes)
>>
>> The old meson driver required compromises to unify legacy controller
>> characteristics and driver styles. On A9, we want a fresh start.
>
> I thought I was clear on the cover letter, apparently not.
>
> *This is not going to happen*
>
> You've provided no technical justification for such "a fresh start".
>
> There no reason for A9 HW to be supported by different drivers than the
> rest of the Amlogic SoC when it is quite clear it can fit with the
> current drivers.
>
> At lot of work by a lot of different people has gone into stabilizing
> and maintaing the current driver. That's valuable too. If you are not
> happy with current level of "performance" then make your case with
> actual numbers and submit changes against the current drivers, making
> improvement available to all supported SoCs. That's how upstream works.
The new driver is intended to reduce unnecessary complexity, making it
easier to support future SoC clock drivers while also lowering the
review effort required for adding such support. It is important for us
to have the foundational clock drivers supported upstream as soon as
possible, so that other dependent drivers can proceed with their enablement.
In addition, the A9 clock driver abstracts clocks as fully functional
"CCU" units. In previous SoCs, clocks were modeled as discrete
components such as mux/divider/gate. Changing the abstraction model in
existing drivers would likely require modifying clkids in the DT
bindings, which introduces a risk of breaking the ABI.
I respect and truly appreciate your contributions to the Amlogic
upstream ecosystem. Based on previous problems and current dilemmas, we
hope the A9 approach can bring meaningful improvements.
>
>>
>>> Best regards,
>>> Krzysztof
>
> --
> Jerome
--
Best regards,
Chuan
^ permalink raw reply
* Re: [PATCH v4 7/7] dt-bindings: PCI: intel,lgm-pcie: Add atu resource
From: Florian Eckert @ 2026-04-15 12:26 UTC (permalink / raw)
To: Rob Herring
Cc: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas, Johan Hovold, Sajid Dalvi,
Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-kernel, devicetree, Eckert.Florian, ms
In-Reply-To: <CAL_JsqJp_s1gH438sCTdOr_kTA3A9E8ch48ann-w-8D3ZH6MmQ@mail.gmail.com>
On 2026-04-15 14:09, Rob Herring wrote:
> On Wed, Apr 15, 2026 at 3:02 AM Florian Eckert <fe@dev.tdt.de> wrote:
>>
>> The 'atu' information is already set in the dwc core, if it is
>> specified
>> in the devicetree. The driver uses its own default, if not set in the
>> devicetree. This information is hardware specific and should therefore
>> be
>> maintained in the devicetree rather than in the source.
>>
>> To be backward compatible, this field is not mandatory. If 'atu'
>> resource is not specified in the devicetree, the driver’s default
>> value
>> is used.
>>
>> Signed-off-by: Florian Eckert <fe@dev.tdt.de>
>> ---
>> Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>> b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>> index
>> 54e2890ae6314ac6847fc23f49440d05d66d87d4..9b7a8ef77585677841c7064c5001110bc2b65db1
>> 100644
>> --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>> +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
>> @@ -27,16 +27,19 @@ properties:
>> - const: snps,dw-pcie
>>
>> reg:
>> + minItems: 3
>> items:
>> - description: Controller control and status registers.
>> - description: PCIe configuration registers.
>> - description: Controller application registers.
>> + - description: Internal Address Translation Unit (iATU)
>> registers.
>>
>> reg-names:
>
> Don't you need minItems here?
You're absolutely right, of course!
My fault. Thanks for pointing that out.
I will wait 24 hours to send a v5 with this change.
Just to clarify. How does the creator of DTS know which items are
required.
Does that mean, in this case, that the last item is always optional and
the
others are absolutely essential?
>
>> items:
>> - const: dbi
>> - const: config
>> - const: app
>> + - const: atu
>>
>> ranges:
>> maxItems: 1
>> @@ -95,8 +98,9 @@ examples:
>> #size-cells = <2>;
>> reg = <0xd0e00000 0x1000>,
>> <0xd2000000 0x800000>,
>> - <0xd0a41000 0x1000>;
>> - reg-names = "dbi", "config", "app";
>> + <0xd0a41000 0x1000>,
>> + <0xd0ec0000 0x1000>;
>> + reg-names = "dbi", config", "app", "atu";
>> linux,pci-domain = <0>;
>> max-link-speed = <4>;
>> bus-range = <0x00 0x08>;
>>
>> --
>> 2.47.3
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox