mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Jun Guo <jun.guo@cixtech.com>,
	peter.chen@cixtech.com, fugang.duan@cixtech.com, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org, vkoul@kernel.org,
	ychuang3@nuvoton.com, schung@nuvoton.com, Frank.Li@kernel.org
Cc: dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, cix-kernel-upstream@cixtech.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/3] dt-bindings: dma: arm-dma350: document generic and combined IRQ topologies
Date: Tue, 24 Mar 2026 12:04:44 +0000	[thread overview]
Message-ID: <c91176d1-851a-4cf5-b7dc-cde431a8326e@arm.com> (raw)
In-Reply-To: <20260323114822.1925869-2-jun.guo@cixtech.com>

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.

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


  parent reply	other threads:[~2026-03-24 12:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-23 11:48 [PATCH v4 0/3] dmaengine: arm-dma350: support combined IRQ topology Jun Guo
2026-03-23 11:48 ` [PATCH v4 1/3] dt-bindings: dma: arm-dma350: document generic and combined IRQ topologies Jun Guo
2026-03-23 12:00   ` Krzysztof Kozlowski
2026-03-23 12:02     ` Krzysztof Kozlowski
2026-03-23 12:15       ` Jun Guo
2026-03-23 12:14     ` Jun Guo
2026-03-24 12:04   ` Robin Murphy [this message]
2026-03-25  6:05     ` Jun Guo
2026-03-23 11:48 ` [PATCH v4 2/3] dma: arm-dma350: support combined IRQ mode with runtime IRQ topology detection Jun Guo
2026-03-23 12:03   ` Krzysztof Kozlowski
2026-03-24 12:59   ` Robin Murphy
2026-03-23 11:48 ` [PATCH v4 3/3] arm64: dts: cix: add DT nodes for DMA Jun Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c91176d1-851a-4cf5-b7dc-cde431a8326e@arm.com \
    --to=robin.murphy@arm.com \
    --cc=Frank.Li@kernel.org \
    --cc=cix-kernel-upstream@cixtech.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=fugang.duan@cixtech.com \
    --cc=jun.guo@cixtech.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.chen@cixtech.com \
    --cc=robh@kernel.org \
    --cc=schung@nuvoton.com \
    --cc=vkoul@kernel.org \
    --cc=ychuang3@nuvoton.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®