* Re: [PATCH v3 1/3] dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
From: Krzysztof Kozlowski @ 2026-03-28 14:00 UTC (permalink / raw)
To: nick.hawkins
Cc: catalin.marinas, will, robh, krzk+dt, conor+dt, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260327174445.3275835-2-nick.hawkins@hpe.com>
On Fri, Mar 27, 2026 at 12:44:43PM -0500, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Add the HPE GSC ARM64 BMC SoC compatibles to the existing
> hpe,gxp.yaml binding.
>
> The initial board compatible is hpe,gsc-dl340gen12 for the DL340 Gen12
> server platform.
>
> Add the arm64 DTS path to the existing ARM/HPE GXP MAINTAINERS entry,
> renamed to ARM/HPE GXP/GSC ARCHITECTURE.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> Documentation/devicetree/bindings/arm/hpe,gxp.yaml | 7 ++++++-
> MAINTAINERS | 3 ++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
> index 224bbcb93f95..6f057cd58571 100644
> --- a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
> +++ b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/arm/hpe,gxp.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: HPE BMC GXP platforms
> +title: HPE BMC GXP and GSC platforms
>
> maintainers:
> - Nick Hawkins <nick.hawkins@hpe.com>
> @@ -18,6 +18,11 @@ properties:
> - enum:
> - hpe,gxp-dl360gen10
> - const: hpe,gxp
> + - description: GSC Based Boards
> + items:
> + - enum:
> + - hpe,gsc-dl340gen12
> + - const: hpe,gsc
What sort of ordering are you going to use in this file? Usual choice is
the fallback compatible, but I see you have chosen something else. That
is fine, just keep that else sorting in the future instead of adding to
the end.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: sound: Convert pcm3060 to DT Schema
From: Krzysztof Kozlowski @ 2026-03-28 13:50 UTC (permalink / raw)
To: Padmashree S S
Cc: k.marinushkin, lgirdwood, broonie, robh, krzk+dt, conor+dt,
linux-sound, devicetree, linux-kernel
In-Reply-To: <20260327121919.603768-1-padmashreess2006@gmail.com>
On Fri, Mar 27, 2026 at 05:49:18PM +0530, Padmashree S S wrote:
> Convert pcm3060 to DT Schema
>
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
> .../devicetree/bindings/sound/pcm3060.txt | 23 ----------
> .../devicetree/bindings/sound/pcm3060.yaml | 42 +++++++++++++++++++
You sent it already after I asked you to slow down and implement
previous feedback, so this has the same issues.
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
> 2 files changed, 42 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/pcm3060.txt
> create mode 100644 Documentation/devicetree/bindings/sound/pcm3060.yaml
Filename must match compatible.
...
> +
> + reg:
> + maxItems: 1
> +
> + ti,out-single-ended:
> + type: boolean
> + description: |
Drop |
> + If present, the output is single-ended.
> + If absent, the output is differential.
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pcm3060: audio-codec@46 {
Drop unused label.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 12/16] irqchip/eip201-aic: Add support for Safexcel EIP-201 AIC
From: Thomas Gleixner @ 2026-03-28 13:10 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric), Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Olivia Mackall, Herbert Xu, Jayesh Choudhary, David S. Miller,
Christian Marangi, Antoine Tenart, Geert Uytterhoeven,
Magnus Damm
Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
devicetree, linux-kernel, linux-crypto, linux-renesas-soc,
Miquel Raynal (Schneider Electric)
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-12-5e6ff7853994@bootlin.com>
On Fri, Mar 27 2026 at 21:09, Miquel Raynal wrote:
> +config SAFEXCEL_EIP201_AIC
> + tristate "Safexcel EIP201 AIC"
TAB, not spaces please
> + select IRQ_DOMAIN
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026 Schneider Electric
> + * Authored by Miquel Raynal <miquel.raynal@bootlin.com>
> + * Based on the work from Mathieu Hadjimegrian <mathieu.hadjimegrian@non.se.com>
> + */
> +
> +#include "linux/irq.h"
> +#include "linux/stddef.h"
That's not a standard include format.
> +
> +struct eip201_aic {
> + struct device *dev;
> + void __iomem *regs;
> + struct irq_domain *domain;
> + struct irq_chip_generic *gc;
> + u32 type;
> + u32 pol;
> +};
Please follow:
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#struct-declarations-and-initializers
> +
> + /* Type register indicates:
See 'comment style' in the same document.
> + * - '1' for edge interrupts
> + * - '0' for level interrupts
> + */
> + if (*out_type & IRQ_TYPE_LEVEL_MASK &&
> + EIP201_AIC_INT(aic->type, *out_hwirq))
No line break required. You have 100 characters.
> +static int eip201_aic_probe(struct platform_device *pdev)
> +{
> + struct eip201_aic *aic;
> + struct clk *clk;
> + u32 rev;
> + int irq;
> + int ret;
See 'variable declarations' in the same document.
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
Leaks the chip and the domain.
> +static struct platform_driver eip201_aic_driver = {
> + .probe = eip201_aic_probe,
> + .remove = eip201_aic_remove,
> + .driver = {
> + .name = "safexcel-eip201-aic",
> + .of_match_table = eip201_aic_of_match,
See above.
Thanks,
tglx
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Add RK3562 serial aliases
From: 谢致邦 (XIE Zhibang) @ 2026-03-28 13:05 UTC (permalink / raw)
To: linux-rockchip
Cc: 谢致邦 (XIE Zhibang), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Finley Xiao, devicetree, linux-arm-kernel, linux-kernel
This fixes the stdout-path in rk3562-evb2-v10.dts.
Fixes: ceb6ef1ea900 ("arm64: dts: rockchip: Add RK3562 evb2 devicetree")
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
arch/arm64/boot/dts/rockchip/rk3562.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3562.dtsi b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
index e4816aa3dae0..14e74e8ac7df 100644
--- a/arch/arm64/boot/dts/rockchip/rk3562.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
@@ -26,6 +26,16 @@ aliases {
gpio2 = &gpio2;
gpio3 = &gpio3;
gpio4 = &gpio4;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ serial5 = &uart5;
+ serial6 = &uart6;
+ serial7 = &uart7;
+ serial8 = &uart8;
+ serial9 = &uart9;
};
xin32k: clock-xin32k {
--
2.43.0
^ permalink raw reply related
* [PATCH] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Khushal Chitturi @ 2026-03-28 12:47 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Linus Walleij, linux-pm, devicetree, linux-kernel,
Khushal Chitturi
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
2 files changed, 42 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
new file mode 100644
index 000000000000..1f9af7f34004
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems Gemini Poweroff Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that
+ controls system power-down operations.
+
+properties:
+ compatible:
+ const: cortina,gemini-power-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ power-controller@4b000000 {
+ compatible = "cortina,gemini-power-controller";
+ reg = <0x4b000000 0x100>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
deleted file mode 100644
index 7fec3e100214..000000000000
--- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device-Tree bindings for Cortina Systems Gemini Poweroff
-
-This is a special IP block in the Cortina Gemini SoC that only
-deals with different ways to power the system down.
-
-Required properties:
-- compatible: should be "cortina,gemini-power-controller"
-- reg: should contain the physical memory base and size
-- interrupts: should contain the power management interrupt
-
-Example:
-
-power-controller@4b000000 {
- compatible = "cortina,gemini-power-controller";
- reg = <0x4b000000 0x100>;
- interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
-};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 11/14] dt-bindings: media: mediatek: vcodec: add decoder dt-bindings for mt8196
From: Krzysztof Kozlowski @ 2026-03-28 12:22 UTC (permalink / raw)
To: Yunfei Dong
Cc: Nícolas F . R . A . Prado, Sebastian Fricke,
Nicolas Dufresne, Hans Verkuil, AngeloGioacchino Del Regno,
Benjamin Gaignard, Nathan Hebert, Daniel Almeida, Hsin-Yi Wang,
Fritz Koenig, Daniel Vetter, Steve Cho, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260328051630.7937-12-yunfei.dong@mediatek.com>
On Sat, Mar 28, 2026 at 01:16:21PM +0800, Yunfei Dong wrote:
> Add decoder document in dt-bindings yaml file for mt8196 platform.
>
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> ---
> .../bindings/media/mediatek,vcodec-subdev-decoder.yaml | 1 +
> 1 file changed, 1 insertion(+)
Still incomplete constraints. If the binding defines flexibly/variable
lists, each device MUST have them constrained.
Or explained WHY NOT in the commit msg. You have entire commit msg to
say something useful explaining unexpected changes, instead of repeating
the subject.
Also, reversed subject prefix:
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: thermal: lmh: Add SDM670 compatible
From: Krzysztof Kozlowski @ 2026-03-28 12:20 UTC (permalink / raw)
To: Richard Acayan
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Thara Gopinath, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pm, devicetree
In-Reply-To: <20260328014041.83777-3-mailingradian@gmail.com>
On Fri, Mar 27, 2026 at 09:40:39PM -0400, Richard Acayan wrote:
> Document the SDM670 LMh.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Why are you sending patches already applied 18 days ago?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] memory: renesas-rpc-if: Add support for RZ/T2H SoC
From: Krzysztof Kozlowski @ 2026-03-28 12:19 UTC (permalink / raw)
To: Prabhakar, Rob Herring, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Biju Das, Wolfram Sang
Cc: linux-kernel, devicetree, linux-renesas-soc, Fabrizio Castro,
Lad Prabhakar
In-Reply-To: <20260327174245.3947213-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
On 27/03/2026 18:42, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add support for the xSPI controller found on the Renesas RZ/T2H
> (R9A09G077) SoC.
>
> The xSPI IP on RZ/T2H is closely related to the RZ/G3E variant, with
> minor differences in some configuration register bits. As these
> differences are not currently exercised by the driver, reuse the
> existing implementation and regmap configuration.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2:
> - Added xspi_info_r9a09g077 for RZ/T2H with type XSPI_RZ_T2H instead
> of reusing xspi_info_r9a09g047 with type XSPI_RZ_G3E, to allow for
> better differentiation in the future if needed.
I see you tried to improve the description, but I have the same
concerns. You added now bunch of dead code to mimic lack of
compatibility, but it does not change the fact the code is 100%
compatible in the meaning of DT.
Let me repeat the question from v1:
"Eventually provide extensive arguments in terms of how DT understands
compatibility."
And if you answer like Geert did last time: "differences are not handled
yet" or "new features are not yet implemented" then you will get the
same answer.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/5] dt-bindings: memory: Add Tegra114 memory client IDs
From: Krzysztof Kozlowski @ 2026-03-28 12:11 UTC (permalink / raw)
To: Thierry Reding
Cc: Svyatoslav Ryhel, Rob Herring, Conor Dooley, Thierry Reding,
Jonathan Hunter, Mikko Perttunen, Sumit Gupta, Dmitry Osipenko,
linux-kernel, devicetree, linux-tegra
In-Reply-To: <22870432-521b-40c0-8f4a-93d2c605baa7@kernel.org>
On 28/03/2026 12:40, Krzysztof Kozlowski wrote:
> On 28/03/2026 00:53, Thierry Reding wrote:
>> On Tue, Feb 17, 2026 at 08:22:24AM +0100, Krzysztof Kozlowski wrote:
>>> On 26/01/2026 20:07, Svyatoslav Ryhel wrote:
>>>> Each memory client has unique hardware ID, add these IDs.
>>>>
>>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>>> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>>>> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
>>>> ---
>>>> include/dt-bindings/memory/tegra114-mc.h | 67 ++++++++++++++++++++++++
>>>
>>> This is never a separate commit. Squash with the binding.
>>
>> You have previously requested that bindings and driver changes be
>> applied together. If this header file is applied to your memory tree it
>> means I cannot apply the corresponding DT changes until a release later
>> because the defines are part of the header included in the DT bindings
>> patch.
>
> I cannot apply the driver either without it, because it uses it, no?
> Otherwise what is it doing in bindings if the driver is not using it?
>
>>
>> Seems a bit suboptimal. Do you have any good ideas on how to solve that
>
> We listed five already in maintainer soc profile. Are they not good?
>
>> particular issue? The only one that comes to mind is for you to pick up
>> the DT changes as well, though that obviously runs a greater risk of
>> causing merge conflicts down the road.
One more thing:
There is no DTS here and nothing explains (commit msgs, changelogs or
cover letter) that there is any dependency and this was supposed to go
other tree. So the squash-or-not-squash is absolutely irrelevant to your
question/problem how DTS should deal with it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/6] dt-bindings: display: panel: Add Novatek NT35532 LCD DSI
From: Krzysztof Kozlowski @ 2026-03-28 12:05 UTC (permalink / raw)
To: Cristian Cozzolino
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
dri-devel, devicetree, linux-kernel, linux-arm-msm,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260327-rimob-new-features-v4-1-06edff9c4509@protonmail.com>
On Fri, Mar 27, 2026 at 03:30:47PM +0100, Cristian Cozzolino wrote:
> Document Novatek NT35532-based DSI display panel.
> Since it's not possible to identify panel vendor nor id, add a suitable
> compatible (matching the device's user, which makes use of this DDIC)
> and set "novatek,nt35532" as fallback.
>
> Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4] dt-bindings: arm: mediatek: mediatek,g3dsys: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-28 11:58 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel, skhan
In-Reply-To: <20260326181726.64957-1-challauday369@gmail.com>
On Thu, Mar 26, 2026 at 11:47:26PM +0530, Udaya Kiran Challa wrote:
> Convert the MediaTek G3D system controller devicetree binding
> from the legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v8 1/3] iio: backend: add devm_iio_backend_get_by_index()
From: Antoniu Miclaus @ 2026-03-28 11:40 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Antoniu Miclaus,
Jonathan Cameron, David Lechner, Nuno Sá, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Olivier Moysan, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260328114050.46848-1-antoniu.miclaus@analog.com>
Add a new function to get an IIO backend by its index in the
io-backends device tree property. This is useful for multi-channel
devices that have multiple backends, where looking up by index is
more straightforward than using named backends.
Extract __devm_iio_backend_fwnode_get_by_index() from the existing
__devm_iio_backend_fwnode_get(), taking the index directly as a
parameter. The new public API devm_iio_backend_get_by_index() uses
the index to find the backend reference in the io-backends property,
avoiding the need for io-backend-names.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
Changes in v8:
- No changes
drivers/iio/industrialio-backend.c | 53 +++++++++++++++++++++---------
include/linux/iio/backend.h | 1 +
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
index 58f7e1426095..d6e922c65347 100644
--- a/drivers/iio/industrialio-backend.c
+++ b/drivers/iio/industrialio-backend.c
@@ -949,23 +949,13 @@ int iio_backend_data_transfer_addr(struct iio_backend *back, u32 address)
}
EXPORT_SYMBOL_NS_GPL(iio_backend_data_transfer_addr, "IIO_BACKEND");
-static struct iio_backend *__devm_iio_backend_fwnode_get(struct device *dev, const char *name,
- struct fwnode_handle *fwnode)
+static struct iio_backend *__devm_iio_backend_fwnode_get_by_index(struct device *dev,
+ struct fwnode_handle *fwnode,
+ unsigned int index)
{
struct iio_backend *back;
- unsigned int index;
int ret;
- if (name) {
- ret = device_property_match_string(dev, "io-backend-names",
- name);
- if (ret < 0)
- return ERR_PTR(ret);
- index = ret;
- } else {
- index = 0;
- }
-
struct fwnode_handle *fwnode_back __free(fwnode_handle) =
fwnode_find_reference(fwnode, "io-backends", index);
if (IS_ERR(fwnode_back))
@@ -981,8 +971,7 @@ static struct iio_backend *__devm_iio_backend_fwnode_get(struct device *dev, con
if (ret)
return ERR_PTR(ret);
- if (name)
- back->idx = index;
+ back->idx = index;
return back;
}
@@ -990,6 +979,24 @@ static struct iio_backend *__devm_iio_backend_fwnode_get(struct device *dev, con
return ERR_PTR(-EPROBE_DEFER);
}
+static struct iio_backend *__devm_iio_backend_fwnode_get(struct device *dev, const char *name,
+ struct fwnode_handle *fwnode)
+{
+ unsigned int index;
+ int ret;
+
+ if (name) {
+ ret = device_property_match_string(dev, "io-backend-names", name);
+ if (ret < 0)
+ return ERR_PTR(ret);
+ index = ret;
+ } else {
+ index = 0;
+ }
+
+ return __devm_iio_backend_fwnode_get_by_index(dev, fwnode, index);
+}
+
/**
* devm_iio_backend_get - Device managed backend device get
* @dev: Consumer device for the backend
@@ -1006,6 +1013,22 @@ struct iio_backend *devm_iio_backend_get(struct device *dev, const char *name)
}
EXPORT_SYMBOL_NS_GPL(devm_iio_backend_get, "IIO_BACKEND");
+/**
+ * devm_iio_backend_get_by_index - Device managed backend device get by index
+ * @dev: Consumer device for the backend
+ * @index: Index of the backend in the io-backends property
+ *
+ * Gets the backend at @index associated with @dev.
+ *
+ * RETURNS:
+ * A backend pointer, negative error pointer otherwise.
+ */
+struct iio_backend *devm_iio_backend_get_by_index(struct device *dev, unsigned int index)
+{
+ return __devm_iio_backend_fwnode_get_by_index(dev, dev_fwnode(dev), index);
+}
+EXPORT_SYMBOL_NS_GPL(devm_iio_backend_get_by_index, "IIO_BACKEND");
+
/**
* devm_iio_backend_fwnode_get - Device managed backend firmware node get
* @dev: Consumer device for the backend
diff --git a/include/linux/iio/backend.h b/include/linux/iio/backend.h
index 7f815f3fed6a..ce2263d4c2de 100644
--- a/include/linux/iio/backend.h
+++ b/include/linux/iio/backend.h
@@ -237,6 +237,7 @@ int iio_backend_extend_chan_spec(struct iio_backend *back,
struct iio_chan_spec *chan);
void *iio_backend_get_priv(const struct iio_backend *conv);
struct iio_backend *devm_iio_backend_get(struct device *dev, const char *name);
+struct iio_backend *devm_iio_backend_get_by_index(struct device *dev, unsigned int index);
struct iio_backend *devm_iio_backend_fwnode_get(struct device *dev,
const char *name,
struct fwnode_handle *fwnode);
--
2.43.0
^ permalink raw reply related
* [PATCH v8 3/3] iio: adc: ad4080: add support for AD4880 dual-channel ADC
From: Antoniu Miclaus @ 2026-03-28 11:40 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Antoniu Miclaus,
Jonathan Cameron, David Lechner, Nuno Sá, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Olivier Moysan, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260328114050.46848-1-antoniu.miclaus@analog.com>
Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC with
integrated fully differential amplifiers (FDA).
The AD4880 has two independent ADC channels, each with its own SPI
configuration interface. The driver uses spi_new_ancillary_device() to
create an additional SPI device for the second channel, allowing both
channels to share the same SPI bus with different chip selects.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
Changes in v8:
- Clarify backend buffer comment to describe FPGA architecture
(two axi_ad408x IP instances with a packer block)
- Make filter_type a per-channel array instead of a single variable
- Restore debugfs_reg_access for AD4880 (uses channel 0 regmap),
based on sashiko's review
drivers/iio/adc/ad4080.c | 251 ++++++++++++++++++++++++++++++---------
1 file changed, 192 insertions(+), 59 deletions(-)
diff --git a/drivers/iio/adc/ad4080.c b/drivers/iio/adc/ad4080.c
index 7cf3b6ed7940..fcd29e94107f 100644
--- a/drivers/iio/adc/ad4080.c
+++ b/drivers/iio/adc/ad4080.c
@@ -16,6 +16,7 @@
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/property.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/spi/spi.h>
@@ -131,6 +132,9 @@
#define AD4084_CHIP_ID 0x0054
#define AD4086_CHIP_ID 0x0056
#define AD4087_CHIP_ID 0x0057
+#define AD4880_CHIP_ID 0x0750
+
+#define AD4080_MAX_CHANNELS 2
#define AD4080_LVDS_CNV_CLK_CNT_MAX 7
@@ -176,8 +180,9 @@ struct ad4080_chip_info {
};
struct ad4080_state {
- struct regmap *regmap;
- struct iio_backend *back;
+ struct spi_device *spi[AD4080_MAX_CHANNELS];
+ struct regmap *regmap[AD4080_MAX_CHANNELS];
+ struct iio_backend *back[AD4080_MAX_CHANNELS];
const struct ad4080_chip_info *info;
/*
* Synchronize access to members the of driver state, and ensure
@@ -187,7 +192,7 @@ struct ad4080_state {
unsigned int num_lanes;
unsigned int dec_rate;
unsigned long clk_rate;
- enum ad4080_filter_type filter_type;
+ enum ad4080_filter_type filter_type[AD4080_MAX_CHANNELS];
bool lvds_cnv_en;
};
@@ -204,9 +209,9 @@ static int ad4080_reg_access(struct iio_dev *indio_dev, unsigned int reg,
struct ad4080_state *st = iio_priv(indio_dev);
if (readval)
- return regmap_read(st->regmap, reg, readval);
+ return regmap_read(st->regmap[0], reg, readval);
- return regmap_write(st->regmap, reg, writeval);
+ return regmap_write(st->regmap[0], reg, writeval);
}
static int ad4080_get_scale(struct ad4080_state *st, int *val, int *val2)
@@ -227,8 +232,9 @@ static unsigned int ad4080_get_dec_rate(struct iio_dev *dev,
struct ad4080_state *st = iio_priv(dev);
int ret;
unsigned int data;
+ unsigned int ch = chan->channel;
- ret = regmap_read(st->regmap, AD4080_REG_FILTER_CONFIG, &data);
+ ret = regmap_read(st->regmap[ch], AD4080_REG_FILTER_CONFIG, &data);
if (ret)
return ret;
@@ -240,13 +246,14 @@ static int ad4080_set_dec_rate(struct iio_dev *dev,
unsigned int mode)
{
struct ad4080_state *st = iio_priv(dev);
+ unsigned int ch = chan->channel;
guard(mutex)(&st->lock);
- if ((st->filter_type >= SINC_5 && mode >= 512) || mode < 2)
+ if ((st->filter_type[ch] >= SINC_5 && mode >= 512) || mode < 2)
return -EINVAL;
- return regmap_update_bits(st->regmap, AD4080_REG_FILTER_CONFIG,
+ return regmap_update_bits(st->regmap[ch], AD4080_REG_FILTER_CONFIG,
AD4080_FILTER_CONFIG_SINC_DEC_RATE_MSK,
FIELD_PREP(AD4080_FILTER_CONFIG_SINC_DEC_RATE_MSK,
(ilog2(mode) - 1)));
@@ -266,15 +273,15 @@ static int ad4080_read_raw(struct iio_dev *indio_dev,
dec_rate = ad4080_get_dec_rate(indio_dev, chan);
if (dec_rate < 0)
return dec_rate;
- if (st->filter_type == SINC_5_COMP)
+ if (st->filter_type[chan->channel] == SINC_5_COMP)
dec_rate *= 2;
- if (st->filter_type)
+ if (st->filter_type[chan->channel])
*val = DIV_ROUND_CLOSEST(st->clk_rate, dec_rate);
else
*val = st->clk_rate;
return IIO_VAL_INT;
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
- if (st->filter_type == FILTER_NONE) {
+ if (st->filter_type[chan->channel] == FILTER_NONE) {
*val = 1;
} else {
*val = ad4080_get_dec_rate(indio_dev, chan);
@@ -295,7 +302,7 @@ static int ad4080_write_raw(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
- if (st->filter_type == FILTER_NONE && val > 1)
+ if (st->filter_type[chan->channel] == FILTER_NONE && val > 1)
return -EINVAL;
return ad4080_set_dec_rate(indio_dev, chan, val);
@@ -304,23 +311,23 @@ static int ad4080_write_raw(struct iio_dev *indio_dev,
}
}
-static int ad4080_lvds_sync_write(struct ad4080_state *st)
+static int ad4080_lvds_sync_write(struct ad4080_state *st, unsigned int ch)
{
- struct device *dev = regmap_get_device(st->regmap);
+ struct device *dev = regmap_get_device(st->regmap[ch]);
int ret;
- ret = regmap_set_bits(st->regmap, AD4080_REG_ADC_DATA_INTF_CONFIG_A,
+ ret = regmap_set_bits(st->regmap[ch], AD4080_REG_ADC_DATA_INTF_CONFIG_A,
AD4080_ADC_DATA_INTF_CONFIG_A_INTF_CHK_EN);
if (ret)
return ret;
- ret = iio_backend_interface_data_align(st->back, 10000);
+ ret = iio_backend_interface_data_align(st->back[ch], 10000);
if (ret)
return dev_err_probe(dev, ret,
"Data alignment process failed\n");
dev_dbg(dev, "Success: Pattern correct and Locked!\n");
- return regmap_clear_bits(st->regmap, AD4080_REG_ADC_DATA_INTF_CONFIG_A,
+ return regmap_clear_bits(st->regmap[ch], AD4080_REG_ADC_DATA_INTF_CONFIG_A,
AD4080_ADC_DATA_INTF_CONFIG_A_INTF_CHK_EN);
}
@@ -329,9 +336,10 @@ static int ad4080_get_filter_type(struct iio_dev *dev,
{
struct ad4080_state *st = iio_priv(dev);
unsigned int data;
+ unsigned int ch = chan->channel;
int ret;
- ret = regmap_read(st->regmap, AD4080_REG_FILTER_CONFIG, &data);
+ ret = regmap_read(st->regmap[ch], AD4080_REG_FILTER_CONFIG, &data);
if (ret)
return ret;
@@ -343,6 +351,7 @@ static int ad4080_set_filter_type(struct iio_dev *dev,
unsigned int mode)
{
struct ad4080_state *st = iio_priv(dev);
+ unsigned int ch = chan->channel;
int dec_rate;
int ret;
@@ -355,18 +364,18 @@ static int ad4080_set_filter_type(struct iio_dev *dev,
if (mode >= SINC_5 && dec_rate >= 512)
return -EINVAL;
- ret = iio_backend_filter_type_set(st->back, mode);
+ ret = iio_backend_filter_type_set(st->back[ch], mode);
if (ret)
return ret;
- ret = regmap_update_bits(st->regmap, AD4080_REG_FILTER_CONFIG,
+ ret = regmap_update_bits(st->regmap[ch], AD4080_REG_FILTER_CONFIG,
AD4080_FILTER_CONFIG_FILTER_SEL_MSK,
FIELD_PREP(AD4080_FILTER_CONFIG_FILTER_SEL_MSK,
mode));
if (ret)
return ret;
- st->filter_type = mode;
+ st->filter_type[ch] = mode;
return 0;
}
@@ -380,14 +389,14 @@ static int ad4080_read_avail(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
- switch (st->filter_type) {
+ switch (st->filter_type[chan->channel]) {
case FILTER_NONE:
*vals = ad4080_dec_rate_none;
*length = ARRAY_SIZE(ad4080_dec_rate_none);
break;
default:
*vals = ad4080_dec_rate_avail;
- *length = st->filter_type >= SINC_5 ?
+ *length = st->filter_type[chan->channel] >= SINC_5 ?
(ARRAY_SIZE(ad4080_dec_rate_avail) - 2) :
ARRAY_SIZE(ad4080_dec_rate_avail);
break;
@@ -399,6 +408,28 @@ static int ad4080_read_avail(struct iio_dev *indio_dev,
}
}
+static int ad4880_update_scan_mode(struct iio_dev *indio_dev,
+ const unsigned long *scan_mask)
+{
+ struct ad4080_state *st = iio_priv(indio_dev);
+ int ret;
+
+ for (unsigned int ch = 0; ch < st->info->num_channels; ch++) {
+ /*
+ * Each backend has a single channel (channel 0 from the
+ * backend's perspective), so always use channel index 0.
+ */
+ if (test_bit(ch, scan_mask))
+ ret = iio_backend_chan_enable(st->back[ch], 0);
+ else
+ ret = iio_backend_chan_disable(st->back[ch], 0);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static const struct iio_info ad4080_iio_info = {
.debugfs_reg_access = ad4080_reg_access,
.read_raw = ad4080_read_raw,
@@ -406,6 +437,19 @@ static const struct iio_info ad4080_iio_info = {
.read_avail = ad4080_read_avail,
};
+/*
+ * AD4880 needs update_scan_mode to enable/disable individual backend channels.
+ * Single-channel devices don't need this as their backends may not implement
+ * chan_enable/chan_disable operations.
+ */
+static const struct iio_info ad4880_iio_info = {
+ .debugfs_reg_access = ad4080_reg_access,
+ .read_raw = ad4080_read_raw,
+ .write_raw = ad4080_write_raw,
+ .read_avail = ad4080_read_avail,
+ .update_scan_mode = ad4880_update_scan_mode,
+};
+
static const struct iio_enum ad4080_filter_type_enum = {
.items = ad4080_filter_type_iio_enum,
.num_items = ARRAY_SIZE(ad4080_filter_type_iio_enum),
@@ -420,17 +464,28 @@ static struct iio_chan_spec_ext_info ad4080_ext_info[] = {
{ }
};
-#define AD4080_CHANNEL_DEFINE(bits, storage) { \
+/*
+ * AD4880 needs per-channel filter configuration since each channel has
+ * its own independent ADC with separate SPI interface.
+ */
+static struct iio_chan_spec_ext_info ad4880_ext_info[] = {
+ IIO_ENUM("filter_type", IIO_SEPARATE, &ad4080_filter_type_enum),
+ IIO_ENUM_AVAILABLE("filter_type", IIO_SEPARATE,
+ &ad4080_filter_type_enum),
+ { }
+};
+
+#define AD4080_CHANNEL_DEFINE(bits, storage, idx) { \
.type = IIO_VOLTAGE, \
.indexed = 1, \
- .channel = 0, \
+ .channel = (idx), \
.info_mask_separate = BIT(IIO_CHAN_INFO_SCALE), \
.info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.info_mask_shared_by_all_available = \
BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.ext_info = ad4080_ext_info, \
- .scan_index = 0, \
+ .scan_index = (idx), \
.scan_type = { \
.sign = 's', \
.realbits = (bits), \
@@ -438,17 +493,45 @@ static struct iio_chan_spec_ext_info ad4080_ext_info[] = {
}, \
}
-static const struct iio_chan_spec ad4080_channel = AD4080_CHANNEL_DEFINE(20, 32);
+/*
+ * AD4880 has per-channel attributes (filter_type, oversampling_ratio,
+ * sampling_frequency) since each channel has its own independent ADC
+ * with separate SPI configuration interface.
+ */
+#define AD4880_CHANNEL_DEFINE(bits, storage, idx) { \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = (idx), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_SCALE) | \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) | \
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
+ .info_mask_separate_available = \
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
+ .ext_info = ad4880_ext_info, \
+ .scan_index = (idx), \
+ .scan_type = { \
+ .sign = 's', \
+ .realbits = (bits), \
+ .storagebits = (storage), \
+ }, \
+}
-static const struct iio_chan_spec ad4081_channel = AD4080_CHANNEL_DEFINE(20, 32);
+static const struct iio_chan_spec ad4080_channel = AD4080_CHANNEL_DEFINE(20, 32, 0);
-static const struct iio_chan_spec ad4083_channel = AD4080_CHANNEL_DEFINE(16, 16);
+static const struct iio_chan_spec ad4081_channel = AD4080_CHANNEL_DEFINE(20, 32, 0);
-static const struct iio_chan_spec ad4084_channel = AD4080_CHANNEL_DEFINE(16, 16);
+static const struct iio_chan_spec ad4083_channel = AD4080_CHANNEL_DEFINE(16, 16, 0);
-static const struct iio_chan_spec ad4086_channel = AD4080_CHANNEL_DEFINE(14, 16);
+static const struct iio_chan_spec ad4084_channel = AD4080_CHANNEL_DEFINE(16, 16, 0);
-static const struct iio_chan_spec ad4087_channel = AD4080_CHANNEL_DEFINE(14, 16);
+static const struct iio_chan_spec ad4086_channel = AD4080_CHANNEL_DEFINE(14, 16, 0);
+
+static const struct iio_chan_spec ad4087_channel = AD4080_CHANNEL_DEFINE(14, 16, 0);
+
+static const struct iio_chan_spec ad4880_channels[] = {
+ AD4880_CHANNEL_DEFINE(20, 32, 0),
+ AD4880_CHANNEL_DEFINE(20, 32, 1),
+};
static const struct ad4080_chip_info ad4080_chip_info = {
.name = "ad4080",
@@ -510,25 +593,34 @@ static const struct ad4080_chip_info ad4087_chip_info = {
.lvds_cnv_clk_cnt_max = 1,
};
-static int ad4080_setup(struct iio_dev *indio_dev)
+static const struct ad4080_chip_info ad4880_chip_info = {
+ .name = "ad4880",
+ .product_id = AD4880_CHIP_ID,
+ .scale_table = ad4080_scale_table,
+ .num_scales = ARRAY_SIZE(ad4080_scale_table),
+ .num_channels = 2,
+ .channels = ad4880_channels,
+ .lvds_cnv_clk_cnt_max = AD4080_LVDS_CNV_CLK_CNT_MAX,
+};
+
+static int ad4080_setup_channel(struct ad4080_state *st, unsigned int ch)
{
- struct ad4080_state *st = iio_priv(indio_dev);
- struct device *dev = regmap_get_device(st->regmap);
+ struct device *dev = regmap_get_device(st->regmap[ch]);
__le16 id_le;
u16 id;
int ret;
- ret = regmap_write(st->regmap, AD4080_REG_INTERFACE_CONFIG_A,
+ ret = regmap_write(st->regmap[ch], AD4080_REG_INTERFACE_CONFIG_A,
AD4080_INTERFACE_CONFIG_A_SW_RESET);
if (ret)
return ret;
- ret = regmap_write(st->regmap, AD4080_REG_INTERFACE_CONFIG_A,
+ ret = regmap_write(st->regmap[ch], AD4080_REG_INTERFACE_CONFIG_A,
AD4080_INTERFACE_CONFIG_A_SDO_ENABLE);
if (ret)
return ret;
- ret = regmap_bulk_read(st->regmap, AD4080_REG_PRODUCT_ID_L, &id_le,
+ ret = regmap_bulk_read(st->regmap[ch], AD4080_REG_PRODUCT_ID_L, &id_le,
sizeof(id_le));
if (ret)
return ret;
@@ -537,18 +629,18 @@ static int ad4080_setup(struct iio_dev *indio_dev)
if (id != st->info->product_id)
dev_info(dev, "Unrecognized CHIP_ID 0x%X\n", id);
- ret = regmap_set_bits(st->regmap, AD4080_REG_GPIO_CONFIG_A,
+ ret = regmap_set_bits(st->regmap[ch], AD4080_REG_GPIO_CONFIG_A,
AD4080_GPIO_CONFIG_A_GPO_1_EN);
if (ret)
return ret;
- ret = regmap_write(st->regmap, AD4080_REG_GPIO_CONFIG_B,
+ ret = regmap_write(st->regmap[ch], AD4080_REG_GPIO_CONFIG_B,
FIELD_PREP(AD4080_GPIO_CONFIG_B_GPIO_1_SEL_MSK,
AD4080_GPIO_CONFIG_B_GPIO_FILTER_RES_RDY));
if (ret)
return ret;
- ret = iio_backend_num_lanes_set(st->back, st->num_lanes);
+ ret = iio_backend_num_lanes_set(st->back[ch], st->num_lanes);
if (ret)
return ret;
@@ -556,7 +648,7 @@ static int ad4080_setup(struct iio_dev *indio_dev)
return 0;
/* Set maximum LVDS Data Transfer Latency */
- ret = regmap_update_bits(st->regmap,
+ ret = regmap_update_bits(st->regmap[ch],
AD4080_REG_ADC_DATA_INTF_CONFIG_B,
AD4080_ADC_DATA_INTF_CONFIG_B_LVDS_CNV_CLK_CNT_MSK,
FIELD_PREP(AD4080_ADC_DATA_INTF_CONFIG_B_LVDS_CNV_CLK_CNT_MSK,
@@ -565,24 +657,38 @@ static int ad4080_setup(struct iio_dev *indio_dev)
return ret;
if (st->num_lanes > 1) {
- ret = regmap_set_bits(st->regmap, AD4080_REG_ADC_DATA_INTF_CONFIG_A,
+ ret = regmap_set_bits(st->regmap[ch], AD4080_REG_ADC_DATA_INTF_CONFIG_A,
AD4080_ADC_DATA_INTF_CONFIG_A_SPI_LVDS_LANES);
if (ret)
return ret;
}
- ret = regmap_set_bits(st->regmap,
+ ret = regmap_set_bits(st->regmap[ch],
AD4080_REG_ADC_DATA_INTF_CONFIG_B,
AD4080_ADC_DATA_INTF_CONFIG_B_LVDS_CNV_EN);
if (ret)
return ret;
- return ad4080_lvds_sync_write(st);
+ return ad4080_lvds_sync_write(st, ch);
}
-static int ad4080_properties_parse(struct ad4080_state *st)
+static int ad4080_setup(struct iio_dev *indio_dev)
+{
+ struct ad4080_state *st = iio_priv(indio_dev);
+ int ret;
+
+ for (unsigned int ch = 0; ch < st->info->num_channels; ch++) {
+ ret = ad4080_setup_channel(st, ch);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ad4080_properties_parse(struct ad4080_state *st,
+ struct device *dev)
{
- struct device *dev = regmap_get_device(st->regmap);
st->lvds_cnv_en = device_property_read_bool(dev, "adi,lvds-cnv-enable");
@@ -617,14 +723,28 @@ static int ad4080_probe(struct spi_device *spi)
return dev_err_probe(dev, ret,
"failed to get and enable supplies\n");
- st->regmap = devm_regmap_init_spi(spi, &ad4080_regmap_config);
- if (IS_ERR(st->regmap))
- return PTR_ERR(st->regmap);
+ /* Setup primary SPI device (channel 0) */
+ st->spi[0] = spi;
+ st->regmap[0] = devm_regmap_init_spi(spi, &ad4080_regmap_config);
+ if (IS_ERR(st->regmap[0]))
+ return PTR_ERR(st->regmap[0]);
st->info = spi_get_device_match_data(spi);
if (!st->info)
return -ENODEV;
+ /* Setup ancillary SPI devices for additional channels */
+ for (unsigned int ch = 1; ch < st->info->num_channels; ch++) {
+ st->spi[ch] = devm_spi_new_ancillary_device(spi, spi_get_chipselect(spi, ch));
+ if (IS_ERR(st->spi[ch]))
+ return dev_err_probe(dev, PTR_ERR(st->spi[ch]),
+ "failed to register ancillary device\n");
+
+ st->regmap[ch] = devm_regmap_init_spi(st->spi[ch], &ad4080_regmap_config);
+ if (IS_ERR(st->regmap[ch]))
+ return PTR_ERR(st->regmap[ch]);
+ }
+
ret = devm_mutex_init(dev, &st->lock);
if (ret)
return ret;
@@ -632,9 +752,10 @@ static int ad4080_probe(struct spi_device *spi)
indio_dev->name = st->info->name;
indio_dev->channels = st->info->channels;
indio_dev->num_channels = st->info->num_channels;
- indio_dev->info = &ad4080_iio_info;
+ indio_dev->info = st->info->num_channels > 1 ?
+ &ad4880_iio_info : &ad4080_iio_info;
- ret = ad4080_properties_parse(st);
+ ret = ad4080_properties_parse(st, dev);
if (ret)
return ret;
@@ -644,15 +765,25 @@ static int ad4080_probe(struct spi_device *spi)
st->clk_rate = clk_get_rate(clk);
- st->back = devm_iio_backend_get(dev, NULL);
- if (IS_ERR(st->back))
- return PTR_ERR(st->back);
+ /* Get backends for all channels */
+ for (unsigned int ch = 0; ch < st->info->num_channels; ch++) {
+ st->back[ch] = devm_iio_backend_get_by_index(dev, ch);
+ if (IS_ERR(st->back[ch]))
+ return PTR_ERR(st->back[ch]);
- ret = devm_iio_backend_request_buffer(dev, st->back, indio_dev);
- if (ret)
- return ret;
+ ret = devm_iio_backend_enable(dev, st->back[ch]);
+ if (ret)
+ return ret;
+ }
- ret = devm_iio_backend_enable(dev, st->back);
+ /*
+ * Request buffer from the first backend only. For multi-channel
+ * devices (e.g., AD4880), the FPGA uses two axi_ad408x IP instances
+ * (one per ADC channel) whose outputs are combined by a packer block
+ * that interleaves all channel data into a single DMA stream routed
+ * through the first backend's clock domain.
+ */
+ ret = devm_iio_backend_request_buffer(dev, st->back[0], indio_dev);
if (ret)
return ret;
@@ -670,6 +801,7 @@ static const struct spi_device_id ad4080_id[] = {
{ "ad4084", (kernel_ulong_t)&ad4084_chip_info },
{ "ad4086", (kernel_ulong_t)&ad4086_chip_info },
{ "ad4087", (kernel_ulong_t)&ad4087_chip_info },
+ { "ad4880", (kernel_ulong_t)&ad4880_chip_info },
{ }
};
MODULE_DEVICE_TABLE(spi, ad4080_id);
@@ -681,6 +813,7 @@ static const struct of_device_id ad4080_of_match[] = {
{ .compatible = "adi,ad4084", &ad4084_chip_info },
{ .compatible = "adi,ad4086", &ad4086_chip_info },
{ .compatible = "adi,ad4087", &ad4087_chip_info },
+ { .compatible = "adi,ad4880", &ad4880_chip_info },
{ }
};
MODULE_DEVICE_TABLE(of, ad4080_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH v8 2/3] dt-bindings: iio: adc: ad4080: add AD4880 support
From: Antoniu Miclaus @ 2026-03-28 11:40 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Antoniu Miclaus,
Jonathan Cameron, David Lechner, Nuno Sá, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Olivier Moysan, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260328114050.46848-1-antoniu.miclaus@analog.com>
Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC
with integrated fully differential amplifiers (FDA).
The AD4880 has two independent ADC channels, each with its own SPI
configuration interface. This requires:
- Two entries in reg property for primary and secondary channel
chip selects
- Two io-backends entries for the two data channels
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
Changes in v8:
- No changes
.../bindings/iio/adc/adi,ad4080.yaml | 53 ++++++++++++++++++-
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
index ccd6a0ac1539..0cf86c6f9925 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
@@ -18,7 +18,11 @@ description: |
service a wide variety of precision, wide bandwidth data acquisition
applications.
+ The AD4880 is a dual-channel variant with two independent ADC channels,
+ each with its own SPI configuration interface.
+
https://www.analog.com/media/en/technical-documentation/data-sheets/ad4080.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4880.pdf
$ref: /schemas/spi/spi-peripheral-props.yaml#
@@ -31,9 +35,15 @@ properties:
- adi,ad4084
- adi,ad4086
- adi,ad4087
+ - adi,ad4880
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+ description:
+ SPI chip select(s). For single-channel devices, one chip select.
+ For multi-channel devices like AD4880, two chip selects are required
+ as each channel has its own SPI configuration interface.
spi-max-frequency:
description: Configuration of the SPI bus.
@@ -57,7 +67,10 @@ properties:
vrefin-supply: true
io-backends:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Backend for channel A (primary)
+ - description: Backend for channel B (secondary)
adi,lvds-cnv-enable:
description: Enable the LVDS signal type on the CNV pin. Default is CMOS.
@@ -78,6 +91,25 @@ required:
- vdd33-supply
- vrefin-supply
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,ad4880
+ then:
+ properties:
+ reg:
+ minItems: 2
+ io-backends:
+ minItems: 2
+ else:
+ properties:
+ reg:
+ maxItems: 1
+ io-backends:
+ maxItems: 1
+
additionalProperties: false
examples:
@@ -98,4 +130,21 @@ examples:
io-backends = <&iio_backend>;
};
};
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad4880";
+ reg = <0>, <1>;
+ spi-max-frequency = <10000000>;
+ vdd33-supply = <&vdd33>;
+ vddldo-supply = <&vddldo>;
+ vrefin-supply = <&vrefin>;
+ clocks = <&cnv>;
+ clock-names = "cnv";
+ io-backends = <&iio_backend_cha>, <&iio_backend_chb>;
+ };
+ };
...
--
2.43.0
^ permalink raw reply related
* [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-channel ADC
From: Antoniu Miclaus @ 2026-03-28 11:40 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Antoniu Miclaus,
Jonathan Cameron, David Lechner, Nuno Sá, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Olivier Moysan, linux-iio,
devicetree, linux-kernel
Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC with
integrated fully differential amplifiers (FDA).
Architecture notes:
The AD4880 is modeled as a single IIO device rather than two independent
devices because the channels share power supplies, a voltage reference,
the CNV conversion clock, and a single interleaved data output stream.
Splitting them into separate IIO devices would make synchronized
dual-channel capture impossible from userspace.
An MFD approach does not apply here either - the channels are not
functionally distinct sub-devices but identical ADC paths sharing a
common data interface.
Each channel has fully independent configuration registers accessible
through separate SPI chip selects, so per-channel regmaps are used with
no locking between them. The data path has no software involvement at
runtime: the CNV clock triggers simultaneous conversions and the device
outputs an interleaved bitstream captured directly by the IIO backend
(FPGA). spi_new_ancillary_device() handles the configuration path;
the IIO backend handles the data path.
The debugfs_reg_access callback is not exposed for the dual-channel
variant since the IIO framework provides a single (reg, val) interface
with no channel parameter, and exposing only one channel would be
misleading.
The AD4880 is a fairly unique part - having separate SPI config
interfaces per channel with a shared interleaved data output is not
a common pattern.
Changes in v8:
- Drop fwnode_handle cleanup patch (now in jic23/testing)
- Clarify backend buffer comment to describe FPGA architecture
(two axi_ad408x IP instances with a packer block)
- Make filter_type a per-channel array instead of a single variable
- Restore debugfs_reg_access for AD4880 (uses channel 0 regmap),
based on sashiko's review
Antoniu Miclaus (3):
iio: backend: add devm_iio_backend_get_by_index()
dt-bindings: iio: adc: ad4080: add AD4880 support
iio: adc: ad4080: add support for AD4880 dual-channel ADC
.../bindings/iio/adc/adi,ad4080.yaml | 53 +++-
drivers/iio/adc/ad4080.c | 251 ++++++++++++++----
drivers/iio/industrialio-backend.c | 53 ++--
include/linux/iio/backend.h | 1 +
4 files changed, 282 insertions(+), 76 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: qcs8300: Add monaco-ac-sku EVK board
From: Umang Chheda @ 2026-03-28 11:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran
Cc: linux-arm-msm, devicetree, linux-kernel, Umang Chheda,
Faruque Ansari
In-Reply-To: <20260328-monaco-evk-ac-sku-v1-0-79d166fa5571@oss.qualcomm.com>
Add initial device tree support for monaco-ac-sku EVK board,
based on Qualcomm's QCS8300-AC variant SoC.
monaco-ac-sku EVK is single board supporting these peripherals :
- Storage: 1 × 128 GB UFS, micro-SD card, EEPROMs for MACs,
and eMMC.
- Audio/Video, Camera & Display ports.
- Connectivity: RJ45 2.5GbE, WLAN/Bluetooth, CAN/CAN-FD.
- PCIe ports.
- USB & UART ports.
Compared to "monaco-evk" variant, which utilizes higher tier QCS8300-AA
SKU (supporting 40 TOPS of NPU) and a 4-PMIC (2x PM8650AU + Maxim MAX20018
+ TI TPS6594) power delivery network (PDN) to support higher power
requirement. This board utilizes lower tier QCS8300-AC SKU
(Supporting 20 TOPS of NPU) and a simplified 2 PMIC(2x PM8650AU) PDN.
Add support for the following components :
- GPI (Generic Peripheral Interface) and QUPv3-0/1
controllers to facilitate DMA and peripheral communication.
- TCA9534 I/O expander via I2C to provide 8 additional GPIO
lines for extended I/O functionality.
- USB1 controller routed to a TypeC connector in device mode to
support USB peripheral operations.
- Remoteproc subsystems for supported DSPs such as Audio DSP,
Compute DSP and Generic DSP, along with their corresponding
firmware.
- Configure nvmem-layout on the I2C EEPROM to store data for Ethernet
and other consumers.
- QCA8081 2.5G Ethernet PHY on port-0 and expose the
Ethernet MAC address via nvmem for network configuration.
It depends on CONFIG_QCA808X_PHY to use QCA8081 PHY.
- Support for the Iris video decoder, including the required
firmware, to enable video decoding capabilities.
- PCIe0 and PCIe1 controller and phy-nodes.
- Sound card and max98357a based I2S speaker amplifier.
Written with inputs from:
Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> - GPIO
Expander.
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> - GPI/QUP.
Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> - Ethernet.
Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
Swati Agarwal <swati.agarwal@oss.qualcomm.com> - USB.
Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com> - PCIe.
Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com> - Audio.
Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts | 730 +++++++++++++++++++++++++
2 files changed, 731 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index c46d94bb6dd5..1d8c2a3db6c0 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -57,6 +57,7 @@ dtb-$(CONFIG_ARCH_QCOM) += mahua-crd.dtb
dtb-$(CONFIG_ARCH_QCOM) += milos-fairphone-fp6.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-arduino-monza.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk.dtb
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ac-sku.dtb
monaco-evk-camera-imx577-dtbs := monaco-evk.dtb monaco-evk-camera-imx577.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-camera-imx577.dtb
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts b/arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts
new file mode 100644
index 000000000000..c100ed9f7981
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts
@@ -0,0 +1,730 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/sound/qcom,q6afe.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "monaco.dtsi"
+#include "monaco-pmics.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. Monaco-ac-sku EVK";
+ compatible = "qcom,monaco-evk-ac-sku", "qcom,qcs8300";
+
+ aliases {
+ ethernet0 = ðernet0;
+ i2c1 = &i2c1;
+ serial0 = &uart7;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ dmic: audio-codec-0 {
+ compatible = "dmic-codec";
+ #sound-dai-cells = <0>;
+ num-channels = <1>;
+ };
+
+ max98357a: audio-codec-1 {
+ compatible = "maxim,max98357a";
+ #sound-dai-cells = <0>;
+ };
+
+ sound {
+ compatible = "qcom,qcs8275-sndcard";
+ model = "MONACO-EVK";
+
+ pinctrl-0 = <&hs0_mi2s_active>, <&mi2s1_active>;
+ pinctrl-names = "default";
+
+ hs0-mi2s-playback-dai-link {
+ link-name = "HS0 MI2S Playback";
+
+ codec {
+ sound-dai = <&max98357a>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai PRIMARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ sec-mi2s-capture-dai-link {
+ link-name = "Secondary MI2S Capture";
+
+ codec {
+ sound-dai = <&dmic>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai SECONDARY_MI2S_TX>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vreg_l3a: ldo3 {
+ regulator-name = "vreg_l3a";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4a: ldo4 {
+ regulator-name = "vreg_l4a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5a: ldo5 {
+ regulator-name = "vreg_l5a";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6a: ldo6 {
+ regulator-name = "vreg_l6a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7a: ldo7 {
+ regulator-name = "vreg_l7a";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8a: ldo8 {
+ regulator-name = "vreg_l8a";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9a: ldo9 {
+ regulator-name = "vreg_l9a";
+ regulator-min-microvolt = <2970000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4a: smps4 {
+ regulator-name = "vreg_s4a";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s9a: smps9 {
+ regulator-name = "vreg_s9a";
+ regulator-min-microvolt = <1352000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vreg_l1c: ldo1 {
+ regulator-name = "vreg_l1c";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <500000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c: ldo2 {
+ regulator-name = "vreg_l2c";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c: ldo4 {
+ regulator-name = "vreg_l4c";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6c: ldo6 {
+ regulator-name = "vreg_l6c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c: ldo7 {
+ regulator-name = "vreg_l7c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c: ldo8 {
+ regulator-name = "vreg_l8c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c: ldo9 {
+ regulator-name = "vreg_l9c";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5c: smps5 {
+ regulator-name = "vreg_s5c";
+ regulator-min-microvolt = <1104000>;
+ regulator-max-microvolt = <1104000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+ðernet0 {
+ phy-mode = "2500base-x";
+ phy-handle = <&hsgmii_phy0>;
+
+ pinctrl-0 = <ðernet0_default>;
+ pinctrl-names = "default";
+
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ nvmem-cells = <&mac_addr0>;
+ nvmem-cell-names = "mac-address";
+
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hsgmii_phy0: ethernet-phy@1c {
+ compatible = "ethernet-phy-id004d.d101";
+ reg = <0x1c>;
+ reset-gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <11000>;
+ reset-deassert-us = <70000>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,route-up;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x1>;
+ snps,route-ptp;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x2>;
+ snps,route-avcp;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,map-to-dma-channel = <0x3>;
+ snps,priority = <0xc>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ };
+
+ queue2 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+
+ queue3 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3e800>;
+ snps,low_credit = <0xffc18000>;
+ };
+ };
+};
+
+&gpi_dma0 {
+ status = "okay";
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-0 = <&qup_i2c1_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ eeprom0: eeprom@50 {
+ compatible = "atmel,24c256";
+ reg = <0x50>;
+ pagesize = <64>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac_addr0: mac-addr@0 {
+ reg = <0x0 0x6>;
+ };
+ };
+ };
+};
+
+&i2c15 {
+ pinctrl-0 = <&qup_i2c15_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ expander0: gpio@38 {
+ compatible = "ti,tca9538";
+ reg = <0x38>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 56 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander0_int>;
+ pinctrl-names = "default";
+ };
+
+ expander1: gpio@39 {
+ compatible = "ti,tca9538";
+ reg = <0x39>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 16 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander1_int>;
+ pinctrl-names = "default";
+ };
+
+ expander2: gpio@3a {
+ compatible = "ti,tca9538";
+ reg = <0x3a>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 95 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander2_int>;
+ pinctrl-names = "default";
+ };
+
+ expander3: gpio@3b {
+ compatible = "ti,tca9538";
+ reg = <0x3b>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 24 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander3_int>;
+ pinctrl-names = "default";
+ };
+
+ expander4: gpio@3c {
+ compatible = "ti,tca9538";
+ reg = <0x3c>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 96 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander4_int>;
+ pinctrl-names = "default";
+ };
+
+ expander5: gpio@3d {
+ compatible = "ti,tca9538";
+ reg = <0x3d>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander5_int>;
+ pinctrl-names = "default";
+ };
+
+ expander6: gpio@3e {
+ compatible = "ti,tca9538";
+ reg = <0x3e>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts-extended = <&tlmm 52 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&expander6_int>;
+ pinctrl-names = "default";
+ };
+};
+
+&iris {
+ status = "okay";
+};
+
+&pcie0 {
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l6a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&pcie1 {
+ pinctrl-0 = <&pcie1_default_state>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie1_phy {
+ vdda-phy-supply = <&vreg_l6a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&pcieport0 {
+ reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+};
+
+&pcieport1 {
+ reset-gpios = <&tlmm 23 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+};
+
+&qupv3_id_0 {
+ firmware-name = "qcom/qcs8300/qupv3fw.elf";
+
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ firmware-name = "qcom/qcs8300/qupv3fw.elf";
+
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/qcs8300/adsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/qcs8300/cdsp0.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_gpdsp {
+ firmware-name = "qcom/qcs8300/gpdsp0.mbn";
+
+ status = "okay";
+};
+
+&serdes0 {
+ phy-supply = <&vreg_l4a>;
+
+ status = "okay";
+};
+
+&spi10 {
+ status = "okay";
+
+ tpm@0 {
+ compatible = "st,st33htpm-spi", "tcg,tpm_tis-spi";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+&tlmm {
+
+ pcie0_default_state: pcie0-default-state {
+ wake-pins {
+ pins = "gpio0";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ clkreq-pins {
+ pins = "gpio1";
+ function = "pcie0_clkreq";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-pins {
+ pins = "gpio2";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ expander5_int: expander5-int-state {
+ pins = "gpio3";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ ethernet0_default: ethernet0-default-state {
+ ethernet0_mdc: ethernet0-mdc-pins {
+ pins = "gpio5";
+ function = "emac0_mdc";
+ drive-strength = <16>;
+ bias-pull-up;
+ };
+
+ ethernet0_mdio: ethernet0-mdio-pins {
+ pins = "gpio6";
+ function = "emac0_mdio";
+ drive-strength = <16>;
+ bias-pull-up;
+ };
+ };
+
+ expander1_int: expander1-int-state {
+ pins = "gpio16";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ qup_i2c1_default: qup-i2c1-state {
+ pins = "gpio19", "gpio20";
+ function = "qup0_se1";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ qup_i2c1_default: qup-i2c1-state {
+ pins = "gpio19", "gpio20";
+ function = "qup0_se1";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ pcie1_default_state: pcie1-default-state {
+ wake-pins {
+ pins = "gpio21";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ clkreq-pins {
+ pins = "gpio22";
+ function = "pcie1_clkreq";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-pins {
+ pins = "gpio23";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ expander3_int: expander3-int-state {
+ pins = "gpio24";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander6_int: expander6-int-state {
+ pins = "gpio52";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander0_int: expander0-int-state {
+ pins = "gpio56";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ qup_i2c15_default: qup-i2c15-state {
+ pins = "gpio91", "gpio92";
+ function = "qup1_se7";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ expander2_int: expander2-int-state {
+ pins = "gpio95";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ expander4_int: expander4-int-state {
+ pins = "gpio96";
+ function = "gpio";
+ bias-pull-up;
+ };
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l8a>;
+ vcc-max-microamp = <1100000>;
+ vccq-supply = <&vreg_l4c>;
+ vccq-max-microamp = <1200000>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l4a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vreg_l7a>;
+ vdda18-supply = <&vreg_l7c>;
+ vdda33-supply = <&vreg_l9a>;
+
+ status = "okay";
+};
+
+&usb_qmpphy {
+ vdda-phy-supply = <&vreg_l7a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac-sku support
From: Umang Chheda @ 2026-03-28 11:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran
Cc: linux-arm-msm, devicetree, linux-kernel, Umang Chheda
In-Reply-To: <20260328-monaco-evk-ac-sku-v1-0-79d166fa5571@oss.qualcomm.com>
Introduce new bindings for the monaco-evk-ac-sku,
an IoT board based on the QCS8300-AC variant SoC.
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index ca880c105f3b..07053cc2ac1c 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -918,6 +918,7 @@ properties:
- enum:
- arduino,monza
- qcom,monaco-evk
+ - qcom,monaco-evk-ac-sku
- qcom,qcs8300-ride
- const: qcom,qcs8300
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: qcom: Introduce support for Monaco-ac-sku Evaluation Kit
From: Umang Chheda @ 2026-03-28 11:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran
Cc: linux-arm-msm, devicetree, linux-kernel, Umang Chheda,
Faruque Ansari
Add support for Qualcomm's Monaco-ac-sku Evaluation Kit (EVK) without
safety monitoring feature of Safety Island(SAIL) subsystem.
This board is based on Qualcomm's QCS8300-AC variant SoC.
Monaco-ac-sku EVK board is a single board computer (SBC) that supports various
industrial applications, including factory automation, industrial
robots, drones, edge AI boxes, machine vision, autonomous mobile
robots (AMRs), and industrial gateways.
Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
---
Umang Chheda (2):
dt-bindings: arm: qcom: Add monaco-evk-ac-sku support
arm64: dts: qcom: qcs8300: Add monaco-ac-sku EVK board
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/monaco-evk-ac-sku.dts | 730 ++++++++++++++++++++++++
3 files changed, 732 insertions(+)
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260328-monaco-evk-ac-sku-6d66f965335c
Best regards,
--
Umang Chheda <umang.chheda@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v1 3/5] dt-bindings: memory: Add Tegra114 memory client IDs
From: Krzysztof Kozlowski @ 2026-03-28 11:40 UTC (permalink / raw)
To: Thierry Reding
Cc: Svyatoslav Ryhel, Rob Herring, Conor Dooley, Thierry Reding,
Jonathan Hunter, Mikko Perttunen, Sumit Gupta, Dmitry Osipenko,
linux-kernel, devicetree, linux-tegra
In-Reply-To: <accXjw2BSCbzMyak@orome>
On 28/03/2026 00:53, Thierry Reding wrote:
> On Tue, Feb 17, 2026 at 08:22:24AM +0100, Krzysztof Kozlowski wrote:
>> On 26/01/2026 20:07, Svyatoslav Ryhel wrote:
>>> Each memory client has unique hardware ID, add these IDs.
>>>
>>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>>> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>>> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
>>> ---
>>> include/dt-bindings/memory/tegra114-mc.h | 67 ++++++++++++++++++++++++
>>
>> This is never a separate commit. Squash with the binding.
>
> You have previously requested that bindings and driver changes be
> applied together. If this header file is applied to your memory tree it
> means I cannot apply the corresponding DT changes until a release later
> because the defines are part of the header included in the DT bindings
> patch.
I cannot apply the driver either without it, because it uses it, no?
Otherwise what is it doing in bindings if the driver is not using it?
>
> Seems a bit suboptimal. Do you have any good ideas on how to solve that
We listed five already in maintainer soc profile. Are they not good?
> particular issue? The only one that comes to mind is for you to pick up
> the DT changes as well, though that obviously runs a greater risk of
> causing merge conflicts down the road.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 7/7] media: iris: add platform data for kaanapali
From: Vikash Garodia @ 2026-03-28 11:37 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Baryshkov
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Joerg Roedel, Will Deacon,
Robin Murphy, Stefan Schmidt, Hans Verkuil, Vishnu Reddy,
Hans Verkuil, linux-arm-msm, linux-media, devicetree,
linux-kernel, iommu, Bryan O'Donoghue
In-Reply-To: <cb50d35f-840d-4732-bf86-4e96f69fef35@kernel.org>
On 3/13/2026 9:25 PM, Krzysztof Kozlowski wrote:
> On 13/03/2026 16:46, Dmitry Baryshkov wrote:
>> On Fri, Mar 13, 2026 at 06:49:41PM +0530, Vikash Garodia wrote:
>>> Add support for the kaanapali platform by re-using the SM8550
>>> definitions and using the vpu4 ops.
>>> Move the configurations that differs in a per-SoC platform header, that
>>> will contain SoC specific data.
>>>
>>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>> ---
>>> .../platform/qcom/iris/iris_platform_common.h | 1 +
>>> .../media/platform/qcom/iris/iris_platform_gen2.c | 90 ++++++++++++++++++++++
>>> .../platform/qcom/iris/iris_platform_kaanapali.h | 83 ++++++++++++++++++++
>>> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
>>> 4 files changed, 178 insertions(+)
>>>
>>
>>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h b/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..bdca1e5bf673353862c1554fb0420f73b3f519cb
>>> --- /dev/null
>>> +++ b/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h
>>> @@ -0,0 +1,83 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>>> + */
>>> +
>>> +#ifndef __IRIS_PLATFORM_KAANAPALI_H__
>>> +#define __IRIS_PLATFORM_KAANAPALI_H__
>>> +
>>> +#include <dt-bindings/media/qcom,kaanapali-iris.h>
>>
>> So, you are including the bindings here, from the header, which gets
>> included from the C source file including headers for all the platforms.
>> What if Kaanapali+1 (or +3) defines different sets of regions?
>
> Different problem - header file MUST NOT have data definitions.
>
> That's basic of C, we don't write such code. First because it leads to
> multiplied, redundant data. Second, that's not C coding style.
Ack, will define in c and extern in header approach
>
> This pattern in Qualcomm Iris is terrible and I could accept variations
> of existing data like below:
>
>>
>>> +
>>> +#define VIDEO_REGION_VM0_SECURE_NP_ID 1
>>> +#define VIDEO_REGION_VM0_NONSECURE_NP_ID 5
>>> +
>>> +static const char *const kaanapali_clk_reset_table[] = {
>>> + "bus0",
>>> + "bus1",
>>> + "core",
>>> + "vcodec0_core",
>>> +};
>>> +
>>> +static const char *const kaanapali_pmdomain_table[] = {
>>> + "venus",
>>> + "vcodec0",
>>> + "vpp0",
>>> + "vpp1",
>>> + "apv",
>>> +};
>>> +
>>> +static const struct platform_clk_data kaanapali_clk_table[] = {
>>> + { IRIS_AXI_CLK, "iface" },
>>> + { IRIS_CTRL_CLK, "core" },
>>> + { IRIS_HW_CLK, "vcodec0_core" },
>>> + { IRIS_AXI1_CLK, "iface1" },
>>> + { IRIS_CTRL_FREERUN_CLK, "core_freerun" },
>>> + { IRIS_HW_FREERUN_CLK, "vcodec0_core_freerun" },
>>> + { IRIS_BSE_HW_CLK, "vcodec_bse" },
>>> + { IRIS_VPP0_HW_CLK, "vcodec_vpp0" },
>>> + { IRIS_VPP1_HW_CLK, "vcodec_vpp1" },
>>> + { IRIS_APV_HW_CLK, "vcodec_apv" },
>>> +};
>>> +
>>> +static const char *const kaanapali_opp_clk_table[] = {
>>> + "vcodec0_core",
>>> + "vcodec_apv",
>>> + "vcodec_bse",
>>> + "core",
>>> + NULL,
>>> +};
>>> +
>>> +static struct tz_cp_config tz_cp_config_kaanapali[] = {
>
> But this is new thus NAK.
>
> Don't grow this broken pattern. There is no single reason data
> definition should be placed in a header. No single one.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: dmaengine: Add SpacemiT K3 DMA request definitions
From: Krzysztof Kozlowski @ 2026-03-28 11:35 UTC (permalink / raw)
To: Troy Mitchell, Troy Mitchell
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Vinod Koul,
Frank Li, Guodong Xu, Michael Turquette, Stephen Boyd, devicetree,
linux-riscv, spacemit, linux-kernel, dmaengine, linux-clk,
liyeshan
In-Reply-To: <DHEBS4TLJV5W.3AO0UY2JXWAFE@linux.spacemit.com>
On 28/03/2026 10:58, Troy Mitchell wrote:
> On Fri Mar 27, 2026 at 3:30 PM CST, Krzysztof Kozlowski wrote:
>> On Thu, Mar 26, 2026 at 04:17:18PM +0800, Troy Mitchell wrote:
>>> From: liyeshan <yeshan.li@spacemit.com>
>>>
>>> Add device tree binding header for SpacemiT k3 DMA request numbers. This
>>
>> Why?
> The DMA request mappings are hardware-hardwired and differ between the K1 and K3 SoCs.
> Therefore, separate header files are required to define these unique constants for each
> platform to ensure correct DMA channel allocation in the device tree.
Nothing explains why we want this as ABI. Header does not ensure correct
DMA channel allocation.
>>
>>> defines the DMA request mapping for non-secure peripherals including UART,
>>> I2C, SSP/SPI, CAN, and QSPI.
>>>
>>> Signed-off-by: liyeshan <yeshan.li@spacemit.com>
>>
>> Name looks close to login name?
> I will contact her and confirm.
>>
>>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>>> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>>> ---
>>> include/dt-bindings/dma/k3-pdma.h | 83 +++++++++++++++++++++++++++++++++++++++
>>
>> I am already confused what is happening in this patchset - so which
>> device are you adding? K1 or K3?
> Aside from this K1-related patch, the rest of the series focuses on adding support for
> the K3 SoC. I included the K1 header because I noticed it was missing in the upstream
> tree while working on the K3 support.
So k3 is the new device? Then this is not a separate commit, but belongs
to the bindings patch.
>
> It seems my attempt to 'clean up' K1 while adding K3 has caused unnecessary confusion.
> Would you prefer me to remove the K1 patch from this series and submit it as a separate
> patch?
I expect explaining in commit msg why you are doing things.
So far none of these are bindings, so drop both headers from bindings.
Feel free to provide explanation what part of Linux SW you are binding here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 7/7] media: iris: add platform data for kaanapali
From: Vikash Garodia @ 2026-03-28 11:21 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Dikshita Agarwal, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Joerg Roedel, Will Deacon,
Robin Murphy, Stefan Schmidt, Hans Verkuil, Krzysztof Kozlowski,
Vishnu Reddy, Hans Verkuil, linux-arm-msm, linux-media,
devicetree, linux-kernel, iommu, Bryan O'Donoghue
In-Reply-To: <5t3bke2sjkxahn4pjhdpyznbrdmu67u7cfgdfwqgjcgo7cbg2e@4wr2jadk6b7i>
On 3/13/2026 9:16 PM, Dmitry Baryshkov wrote:
> On Fri, Mar 13, 2026 at 06:49:41PM +0530, Vikash Garodia wrote:
>> Add support for the kaanapali platform by re-using the SM8550
>> definitions and using the vpu4 ops.
>> Move the configurations that differs in a per-SoC platform header, that
>> will contain SoC specific data.
>>
>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>> .../platform/qcom/iris/iris_platform_common.h | 1 +
>> .../media/platform/qcom/iris/iris_platform_gen2.c | 90 ++++++++++++++++++++++
>> .../platform/qcom/iris/iris_platform_kaanapali.h | 83 ++++++++++++++++++++
>> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
>> 4 files changed, 178 insertions(+)
>>
>
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h b/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..bdca1e5bf673353862c1554fb0420f73b3f519cb
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h
>> @@ -0,0 +1,83 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#ifndef __IRIS_PLATFORM_KAANAPALI_H__
>> +#define __IRIS_PLATFORM_KAANAPALI_H__
>> +
>> +#include <dt-bindings/media/qcom,kaanapali-iris.h>
>
> So, you are including the bindings here, from the header, which gets
> included from the C source file including headers for all the platforms.
> What if Kaanapali+1 (or +3) defines different sets of regions?
>
thats correct, to handle this, the soc platform data can be defined in
iris_platform_kaanapali.c, and iris_platform_kaanapali.h can extern the
platform data struct which gets included in gen2.c.
Also would have preferred naming the binding abi header
"qcom,kaanapali-iris.h" to something generic so that it can be included
in other platforms, but it seems like the maintainer does not like that
idea.
>> +
>> +#define VIDEO_REGION_VM0_SECURE_NP_ID 1
>> +#define VIDEO_REGION_VM0_NONSECURE_NP_ID 5
>> +
>> +static const char *const kaanapali_clk_reset_table[] = {
>> + "bus0",
>> + "bus1",
>> + "core",
>> + "vcodec0_core",
>> +};
>> +
>> +static const char *const kaanapali_pmdomain_table[] = {
>> + "venus",
>> + "vcodec0",
>> + "vpp0",
>> + "vpp1",
>> + "apv",
>> +};
>> +
>> +static const struct platform_clk_data kaanapali_clk_table[] = {
>> + { IRIS_AXI_CLK, "iface" },
>> + { IRIS_CTRL_CLK, "core" },
>> + { IRIS_HW_CLK, "vcodec0_core" },
>> + { IRIS_AXI1_CLK, "iface1" },
>> + { IRIS_CTRL_FREERUN_CLK, "core_freerun" },
>> + { IRIS_HW_FREERUN_CLK, "vcodec0_core_freerun" },
>> + { IRIS_BSE_HW_CLK, "vcodec_bse" },
>> + { IRIS_VPP0_HW_CLK, "vcodec_vpp0" },
>> + { IRIS_VPP1_HW_CLK, "vcodec_vpp1" },
>> + { IRIS_APV_HW_CLK, "vcodec_apv" },
>> +};
>> +
>> +static const char *const kaanapali_opp_clk_table[] = {
>> + "vcodec0_core",
>> + "vcodec_apv",
>> + "vcodec_bse",
>> + "core",
>> + NULL,
>> +};
>> +
>> +static struct tz_cp_config tz_cp_config_kaanapali[] = {
>> + {
>> + .cp_start = VIDEO_REGION_VM0_SECURE_NP_ID,
>> + .cp_size = 0,
>> + .cp_nonpixel_start = 0x01000000,
>> + .cp_nonpixel_size = 0x24800000,
>> + },
>> + {
>> + .cp_start = VIDEO_REGION_VM0_NONSECURE_NP_ID,
>> + .cp_size = 0,
>> + .cp_nonpixel_start = 0x25800000,
>> + .cp_nonpixel_size = 0xda400000,
>> + },
>> +};
>> +
>> +static struct iris_context_bank kaanapali_cb_data[] = {
>> + {
>> + .name = "iris_bitstream",
>> + .f_id = IRIS_BITSTREAM,
>> + .region_mask = BIT(IRIS_BITSTREAM_REGION),
>
> I'd say, it's really easy to mix IRIS_BITSTREAM and
> IRIS_BITSTREAM_REGION when looking at the code, which might be bad
> because they are not equal.
this logic have changed now given that the handling is now 1:1, rather
than multi map case. Maybe..we can revisit this in v4.
Regards,
Vikash
>
>> + },
>> + {
>> + .name = "iris_non_pixel",
>> + .f_id = IRIS_NON_PIXEL,
>> + .region_mask = BIT(IRIS_NON_PIXEL_REGION),
>> + },
>> + {
>> + .name = "iris_pixel",
>> + .f_id = IRIS_PIXEL,
>> + .region_mask = BIT(IRIS_PIXEL_REGION),
>> + },
>> +};
>> +
>> +#endif /* __IRIS_PLATFORM_KAANAPALI_H__ */
>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
>> index 439e6e0fe8adf8287f81d26257ef2a7e9f21e53d..f6d8761daf0471d3aabec21c708445ee7698487b 100644
>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>> @@ -406,6 +406,10 @@ static const struct dev_pm_ops iris_pm_ops = {
>> };
>>
>> static const struct of_device_id iris_dt_match[] = {
>> + {
>> + .compatible = "qcom,kaanapali-iris",
>> + .data = &kaanapali_data,
>> + },
>> {
>> .compatible = "qcom,qcs8300-iris",
>> .data = &qcs8300_data,
>>
>> --
>> 2.34.1
>>
>
^ permalink raw reply
* [PATCH v2] dt-bindings: i2c: intel,ixp4xx-i2c: Convert to DT schema
From: Shi Hao @ 2026-03-28 10:11 UTC (permalink / raw)
To: krzk+dt
Cc: robh, andi.shyti, conor+dt, linux-i2c, devicetree, linux-kernel,
i.shihao.999
Convert the IOP3xx and IXP4xx XScale bindings to DT schema. This
conversion also adds the <irq.h> header file to the example section, since
IRQ_TYPE_LEVEL_LOW macro is used. This ensures the examples validate
correctly.
Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
---
v2:
- Fix checkpatch.pl warnings
- Reorder compatibles in alphabetical order
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
---
.../devicetree/bindings/i2c/i2c-iop3xx.txt | 20 ---------
.../bindings/i2c/intel,ixp4xx-i2c.yaml | 41 +++++++++++++++++++
2 files changed, 41 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt
create mode 100644 Documentation/devicetree/bindings/i2c/intel,ixp4xx-i2c.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt b/Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt
deleted file mode 100644
index dcc8390e0d24..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-i2c Controller on XScale platforms such as IOP3xx and IXP4xx
-
-Required properties:
-- compatible : Must be one of
- "intel,iop3xx-i2c"
- "intel,ixp4xx-i2c";
-- reg
-- #address-cells = <1>;
-- #size-cells = <0>;
-
-Optional properties:
-- Child nodes conforming to i2c bus binding
-
-Example:
-
-i2c@c8011000 {
- compatible = "intel,ixp4xx-i2c";
- reg = <0xc8011000 0x18>;
- interrupts = <33 IRQ_TYPE_LEVEL_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/intel,ixp4xx-i2c.yaml b/Documentation/devicetree/bindings/i2c/intel,ixp4xx-i2c.yaml
new file mode 100644
index 000000000000..15ef510f6fd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/intel,ixp4xx-i2c.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/intel,ixp4xx-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2c Controller on XScale platforms such as IOP3xx and IXP4xx
+
+maintainers:
+ - Andi Shyti <andi.shyti@kernel.org>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - intel,iop3xx-i2c
+ - intel,ixp4xx-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c@c8011000 {
+ compatible = "intel,ixp4xx-i2c";
+ reg = <0xc8011000 0x18>;
+ interrupts = <33 IRQ_TYPE_LEVEL_LOW>;
+ };
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 3/7] dt-bindings: dmaengine: Add SpacemiT K3 DMA request definitions
From: Troy Mitchell @ 2026-03-28 9:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, Troy Mitchell
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Vinod Koul,
Frank Li, Guodong Xu, Michael Turquette, Stephen Boyd, devicetree,
linux-riscv, spacemit, linux-kernel, dmaengine, linux-clk,
liyeshan
In-Reply-To: <20260327-granite-giraffe-of-infinity-ff49a3@quoll>
On Fri Mar 27, 2026 at 3:30 PM CST, Krzysztof Kozlowski wrote:
> On Thu, Mar 26, 2026 at 04:17:18PM +0800, Troy Mitchell wrote:
>> From: liyeshan <yeshan.li@spacemit.com>
>>
>> Add device tree binding header for SpacemiT k3 DMA request numbers. This
>
> Why?
The DMA request mappings are hardware-hardwired and differ between the K1 and K3 SoCs.
Therefore, separate header files are required to define these unique constants for each
platform to ensure correct DMA channel allocation in the device tree.
>
>> defines the DMA request mapping for non-secure peripherals including UART,
>> I2C, SSP/SPI, CAN, and QSPI.
>>
>> Signed-off-by: liyeshan <yeshan.li@spacemit.com>
>
> Name looks close to login name?
I will contact her and confirm.
>
>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>> ---
>> include/dt-bindings/dma/k3-pdma.h | 83 +++++++++++++++++++++++++++++++++++++++
>
> I am already confused what is happening in this patchset - so which
> device are you adding? K1 or K3?
Aside from this K1-related patch, the rest of the series focuses on adding support for
the K3 SoC. I included the K1 header because I noticed it was missing in the upstream
tree while working on the K3 support.
It seems my attempt to 'clean up' K1 while adding K3 has caused unnecessary confusion.
Would you prefer me to remove the K1 patch from this series and submit it as a separate
patch?
- Troy
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: dmaengine: Add SpacemiT K1 DMA request definitions
From: Troy Mitchell @ 2026-03-28 9:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Troy Mitchell
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan, Vinod Koul,
Frank Li, Guodong Xu, Michael Turquette, Stephen Boyd, devicetree,
linux-riscv, spacemit, linux-kernel, dmaengine, linux-clk
In-Reply-To: <20260327-silkworm-of-algebraic-aurora-e9bd1c@quoll>
On Fri Mar 27, 2026 at 3:28 PM CST, Krzysztof Kozlowski wrote:
> On Thu, Mar 26, 2026 at 04:17:16PM +0800, Troy Mitchell wrote:
>> From: Guodong Xu <guodong@riscstar.com>
>>
>> Add the DMA request numbers for non-secure peripherals of the K1 SoC
>> from SpacemiT.
>>
>> Signed-off-by: Guodong Xu <guodong@riscstar.com>
>> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>> ---
>> include/dt-bindings/dma/k1-pdma.h | 56 +++++++++++++++++++++++++++++++++++++++
>
> Also, this is not a separate commit.
Could you please clarify? This patch already contains only a single file
(include/dt-bindings/dma/k3-pdma.h).
- Troy
^ 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