Update the DMA-350 DT binding to match the current driver behavior.
Allow both:
- "arm,dma-350" as the generic compatible, and
- "cix,sky1-dma-350", "arm,dma-350" for SoC-specific fallback usage.
Also document interrupt topology variants supported by hardware
integration:
- one combined interrupt for all channels, or
- one interrupt per channel (up to 8 channels).
Assisted-by: Cursor: GPT-5.3-Codex
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
---
.../devicetree/bindings/dma/arm,dma-350.yaml | 34 +++++++++++++------
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
index 429f682f15d8..47091614d1b4 100644
--- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
+++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
@@ -14,7 +14,14 @@ allOf:
properties:
compatible:
- const: arm,dma-350
+ description:
+ Use "arm,dma-350" for generic integration. A SoC-specific
+ compatible may be listed first, followed by "arm,dma-350".
+ oneOf:
+ - const: arm,dma-350
+ - items:
+ - const: cix,sky1-dma-350
+ - const: arm,dma-350
reg:
items:
@@ -22,15 +29,22 @@ properties:
interrupts:
minItems: 1
- items:
- - description: Channel 0 interrupt
- - description: Channel 1 interrupt
- - description: Channel 2 interrupt
- - description: Channel 3 interrupt
- - description: Channel 4 interrupt
- - description: Channel 5 interrupt
- - description: Channel 6 interrupt
- - description: Channel 7 interrupt
+ maxItems: 8
+ description:
+ Either one interrupt per channel (8 interrupts), or one
+ combined interrupt for all channels.
+ oneOf:
+ - items:
+ - description: Channel 0 interrupt
+ - description: Channel 1 interrupt
+ - description: Channel 2 interrupt
+ - description: Channel 3 interrupt
+ - description: Channel 4 interrupt
+ - description: Channel 5 interrupt
+ - description: Channel 6 interrupt
+ - description: Channel 7 interrupt
+ - items:
+ - description: Combined interrupt shared by all channels
"#dma-cells":
const: 1
--
2.34.1On 2026-03-23 11:48 am, Jun Guo wrote:
> Update the DMA-350 DT binding to match the current driver behavior.
>
> Allow both:
> - "arm,dma-350" as the generic compatible, and
> - "cix,sky1-dma-350", "arm,dma-350" for SoC-specific fallback usage.
>
> Also document interrupt topology variants supported by hardware
> integration:
> - one combined interrupt for all channels, or
> - one interrupt per channel (up to 8 channels).
To repeat myself for the 3rd time, this is at best unnecessary, and at
worst arguably wrong. Here's an example of a system which happens to use
the combined interrupt from another IP block which also offers both options:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8qm.dtsi#n279
Same thing here; each channel is a distinct interrupt source, so it is
perfectly honest to describe that consistently in DT, regardless of
whether or not the interrupt signals are still distinct by the time they
reach the interrupt controller.
Furthermore, in this case the IRQ_COMB_NONSEC interrupt actually has
additional functionality beyond just being a mux of the individual
IRQ_CHANNEL interrupts. So although Linux probably won't ever care, if
it's going to be in the DT binding then it should really be distinct
from the channel interrupts anyway, since systems could well wire them
*all* up, and an OS could choose to use the IRQ_CHANNEL outputs directly
for individual channel completion/error status, while also using the
IRQ_COMB_NONSEC just for its overall INTR_ALLCH{STOPPED,PAUSED,IDLE} status.
If you only want to make your thing work in Linux, all that is needed is
a 1-line change in the driver to enable the INTR_ANYCHINTR bit (which as
I've also said before, we can do unconditionally because we're *not*
using the other INTR_ALLCH stuff), and to write your DT using the
existing binding. "One interrupt per channel" already carries no
expectation that they all have to be *different* interrupts.
Thanks,
Robin.
> Assisted-by: Cursor: GPT-5.3-Codex
> Signed-off-by: Jun Guo <jun.guo@cixtech.com>
> ---
> .../devicetree/bindings/dma/arm,dma-350.yaml | 34 +++++++++++++------
> 1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> index 429f682f15d8..47091614d1b4 100644
> --- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> +++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> @@ -14,7 +14,14 @@ allOf:
>
> properties:
> compatible:
> - const: arm,dma-350
> + description:
> + Use "arm,dma-350" for generic integration. A SoC-specific
> + compatible may be listed first, followed by "arm,dma-350".
> + oneOf:
> + - const: arm,dma-350
> + - items:
> + - const: cix,sky1-dma-350
> + - const: arm,dma-350
>
> reg:
> items:
> @@ -22,15 +29,22 @@ properties:
>
> interrupts:
> minItems: 1
> - items:
> - - description: Channel 0 interrupt
> - - description: Channel 1 interrupt
> - - description: Channel 2 interrupt
> - - description: Channel 3 interrupt
> - - description: Channel 4 interrupt
> - - description: Channel 5 interrupt
> - - description: Channel 6 interrupt
> - - description: Channel 7 interrupt
> + maxItems: 8
> + description:
> + Either one interrupt per channel (8 interrupts), or one
> + combined interrupt for all channels.
> + oneOf:
> + - items:
> + - description: Channel 0 interrupt
> + - description: Channel 1 interrupt
> + - description: Channel 2 interrupt
> + - description: Channel 3 interrupt
> + - description: Channel 4 interrupt
> + - description: Channel 5 interrupt
> + - description: Channel 6 interrupt
> + - description: Channel 7 interrupt
> + - items:
> + - description: Combined interrupt shared by all channels
>
> "#dma-cells":
> const: 1
On 3/24/2026 8:04 PM, Robin Murphy wrote:
> [Some people who received this message don't often get email from
> robin.murphy@arm.com. Learn why this is important at https://aka.ms/
> LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL
>
> On 2026-03-23 11:48 am, Jun Guo wrote:
>> Update the DMA-350 DT binding to match the current driver behavior.
>>
>> Allow both:
>> - "arm,dma-350" as the generic compatible, and
>> - "cix,sky1-dma-350", "arm,dma-350" for SoC-specific fallback usage.
>>
>> Also document interrupt topology variants supported by hardware
>> integration:
>> - one combined interrupt for all channels, or
>> - one interrupt per channel (up to 8 channels).
>
> To repeat myself for the 3rd time, this is at best unnecessary, and at
> worst arguably wrong. Here's an example of a system which happens to use
> the combined interrupt from another IP block which also offers both
> options:
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> tree/arch/arm64/boot/dts/freescale/imx8qm.dtsi#n279
>
> Same thing here; each channel is a distinct interrupt source, so it is
> perfectly honest to describe that consistently in DT, regardless of
> whether or not the interrupt signals are still distinct by the time they
> reach the interrupt controller.
>
> Furthermore, in this case the IRQ_COMB_NONSEC interrupt actually has
> additional functionality beyond just being a mux of the individual
> IRQ_CHANNEL interrupts. So although Linux probably won't ever care, if
> it's going to be in the DT binding then it should really be distinct
> from the channel interrupts anyway, since systems could well wire them
> *all* up, and an OS could choose to use the IRQ_CHANNEL outputs directly
> for individual channel completion/error status, while also using the
> IRQ_COMB_NONSEC just for its overall INTR_ALLCH{STOPPED,PAUSED,IDLE}
> status.
>
> If you only want to make your thing work in Linux, all that is needed is
> a 1-line change in the driver to enable the INTR_ANYCHINTR bit (which as
> I've also said before, we can do unconditionally because we're *not*
> using the other INTR_ALLCH stuff), and to write your DT using the
> existing binding. "One interrupt per channel" already carries no
> expectation that they all have to be *different* interrupts.
>
You've indeed said this for the third time, but I did not ignore your
comments earlier. I carefully reviewed your feedback on both the V1
and V2 patches. However, since your initial comments were not as detailed,
I promptly replied to your emails hoping to discuss them further.
Unfortunately, you did not respond to either of my follow-up emails,
so I proceeded with submitting the current version of the patch.
You can refer to the records here:
https://lore.kernel.org/all/20251216123026.3519923-2-jun.guo@cixtech.com/
or
https://lore.kernel.org/all/20251117015943.2858-3-jun.guo@cixtech.com/
Now, with this latest email, I clearly understand the point you are making.
I will revise and resubmit the patch accordingly, which should result in
a much more concise version. Thank you for your reply.
Best regards,
Jun
On 23/03/2026 12:48, Jun Guo wrote: > Update the DMA-350 DT binding to match the current driver behavior. > > Allow both: > - "arm,dma-350" as the generic compatible, and > - "cix,sky1-dma-350", "arm,dma-350" for SoC-specific fallback usage. > > Also document interrupt topology variants supported by hardware > integration: > - one combined interrupt for all channels, or > - one interrupt per channel (up to 8 channels). > > Assisted-by: Cursor: GPT-5.3-Codex There is no space here. Read the docs, I quite insisted on this last time. If you make mistakes in this, I doubt you read the docs thus I doubt you followed the requirements - have actual rights to send it for example. > Signed-off-by: Jun Guo <jun.guo@cixtech.com> > --- > .../devicetree/bindings/dma/arm,dma-350.yaml | 34 +++++++++++++------ > 1 file changed, 24 insertions(+), 10 deletions(-) > > diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml > index 429f682f15d8..47091614d1b4 100644 > --- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml > +++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml > @@ -14,7 +14,14 @@ allOf: > > properties: > compatible: > - const: arm,dma-350 > + description: > + Use "arm,dma-350" for generic integration. A SoC-specific > + compatible may be listed first, followed by "arm,dma-350". What is the point of explaining it? What is the difference between generic integration and non-generic? Best regards, Krzysztof
On 3/23/2026 8:00 PM, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL > > On 23/03/2026 12:48, Jun Guo wrote: >> Update the DMA-350 DT binding to match the current driver behavior. >> >> Allow both: >> - "arm,dma-350" as the generic compatible, and >> - "cix,sky1-dma-350", "arm,dma-350" for SoC-specific fallback usage. >> >> Also document interrupt topology variants supported by hardware >> integration: >> - one combined interrupt for all channels, or >> - one interrupt per channel (up to 8 channels). >> >> Assisted-by: Cursor: GPT-5.3-Codex > > There is no space here. Read the docs, I quite insisted on this last > time. If you make mistakes in this, I doubt you read the docs thus I > doubt you followed the requirements - have actual rights to send it for > example. Sorry, I did overlook the format between AGENT_NAME and MODEL_VERSION. I will fix it. > >> Signed-off-by: Jun Guo <jun.guo@cixtech.com> >> --- >> .../devicetree/bindings/dma/arm,dma-350.yaml | 34 +++++++++++++------ >> 1 file changed, 24 insertions(+), 10 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml >> index 429f682f15d8..47091614d1b4 100644 >> --- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml >> +++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml >> @@ -14,7 +14,14 @@ allOf: >> >> properties: >> compatible: >> - const: arm,dma-350 >> + description: >> + Use "arm,dma-350" for generic integration. A SoC-specific >> + compatible may be listed first, followed by "arm,dma-350". > > What is the point of explaining it? What is the difference between > generic integration and non-generic? I might not need to add the "cix,sky1-dma-350" and can directly use "arm,dma-350" instead. I will rework the code and description accordingly. Best regards, Jun
On 23/03/2026 13:00, Krzysztof Kozlowski wrote: > On 23/03/2026 12:48, Jun Guo wrote: >> Update the DMA-350 DT binding to match the current driver behavior. >> >> Allow both: >> - "arm,dma-350" as the generic compatible, and >> - "cix,sky1-dma-350", "arm,dma-350" for SoC-specific fallback usage. >> >> Also document interrupt topology variants supported by hardware >> integration: >> - one combined interrupt for all channels, or >> - one interrupt per channel (up to 8 channels). >> >> Assisted-by: Cursor: GPT-5.3-Codex > > There is no space here. Read the docs, I quite insisted on this last > time. If you make mistakes in this, I doubt you read the docs thus I > doubt you followed the requirements - have actual rights to send it for > example. And you already received that comment: "Wrong tag, please read carefully the guideline before using LLM tools." Best regards, Krzysztof
On 3/23/2026 8:02 PM, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL > > On 23/03/2026 13:00, Krzysztof Kozlowski wrote: >> On 23/03/2026 12:48, Jun Guo wrote: >>> Update the DMA-350 DT binding to match the current driver behavior. >>> >>> Allow both: >>> - "arm,dma-350" as the generic compatible, and >>> - "cix,sky1-dma-350", "arm,dma-350" for SoC-specific fallback usage. >>> >>> Also document interrupt topology variants supported by hardware >>> integration: >>> - one combined interrupt for all channels, or >>> - one interrupt per channel (up to 8 channels). >>> >>> Assisted-by: Cursor: GPT-5.3-Codex >> >> There is no space here. Read the docs, I quite insisted on this last >> time. If you make mistakes in this, I doubt you read the docs thus I >> doubt you followed the requirements - have actual rights to send it for >> example. > > And you already received that comment: > > "Wrong tag, please read carefully the guideline before using LLM tools." I did receive that feedback, and I will learn from this experience to submit more reliable patches in the future. Best regards, Jun
© 2016 - 2026 Red Hat, Inc.