mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Jelly Jia <Jelly.Jia@cixtech.com>
Cc: vkoul@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, robin.murphy@arm.com,
	devicetree@vger.kernel.org, Frank.Li@kernel.org,
	cix-kernel-upstream@cixtech.com, dmaengine@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 6/6] arm64: dts: cix: Describe the Sky1 DMA-350 bus integration
Date: Mon, 12 Oct 2026 20:07:48 +0100	[thread overview]
Message-ID: <20261012-rural-undermost-b4817ebd4740@spud> (raw)
In-Reply-To: <20261012084155.2547480-7-Jelly.Jia@cixtech.com>

[-- Attachment #1: Type: text/plain, Size: 7554 bytes --]

On Mon, Oct 12, 2026 at 04:41:55PM +0800, Jelly Jia wrote:
> The FCH DMA-350 controller sits behind an interconnect window, so the
> addresses its DMA master uses differ from the CPU physical addresses.
> Describe the integration as a bus node carrying the dma-ranges of that
> window, with the controller itself as a child, and give the controller
> the SoC compatible and the clock feeding it.
> 
> The AUDSS DMA-350 controller is described the same way, with its clock
> and reset. It has no consumer in the SoC dtsi yet: the audio controllers
> that use it are not described upstream.
> 
> The bus nodes are address domains, not devices: they have no reg, so
> they carry no unit-address in their node names.
> 

> v1 -> v2:
> - The DMA-350 nodes are no longer wrappers with the generic controller
>   as a child: each Sky1 DMA-350 is a single device node with the
>   "cix,sky1-dma350", "arm,dma-350" compatible, its real MMIO region and
>   the integration resources (clock, reset) that v1 kept on the wrapper.
>   The integration and the block are one device, and the MMIO is the same
>   as the generic node it replaces.
> - The FCH and AUDSS DMA-350 masters sit behind SoC interconnect windows
>   in a static DMA address domain: the AUDSS masters see the audio
>   register and FIFO block at 0x20000000 and the DRAM window at
>   0x30000000, which the CPU sees at 0x07010000 and 0xc0000000, and the
>   FCH masters see the 0x040b0000 window at 0x040a0000. Their DMA view of
>   the address space is not the CPU physical view.
> - The windows are static hardware configuration, set up before Linux
>   starts by the boot firmware / secure world: they are not programmable
>   from Linux and must not be reconfigured by it. There is nothing for a
>   Linux interconnect provider to manage here, so the translation cannot
>   be modeled as one; it is a fixed property of the bus.
> - It is described the standard devicetree way instead: a generic
>   "simple-bus" parent with an identity "ranges;" and the "dma-ranges" of
>   the window. This is not the rejected v1 wrapper and not a separate DMA
>   wrapper/integration device: the parent has no device-specific or
>   vendor wrapper compatible, only the generic "simple-bus" compatible,
>   no reg, no clocks, no resets, no driver and no private address
>   translation. Its only job is to carry the static translation, so it is
>   only a generic bus/address-domain node.
> - The "dma-ranges" have to sit on that parent for the OF core to build
>   dev->dma_range_map: of_dma_configure_id() starts the lookup at the
>   device's parent (bus_np = __of_get_dma_parent(np) in
>   drivers/of/device.c), so a "dma-ranges" on the controller node itself
>   would be ignored. The translation is applied by the DMA API, not by
>   driver code: the driver maps slave resources with dma_map_resource()
>   and contains no address parser.
> - Mainline has similar bus nodes: the Agilex5 DMA bus (dma-bus@10db0000,
>   a simple-bus with dma-ranges whose controller carries
>   "altr,agilex5-axi-dma", "snps,axi-dma-1.01a") and the Marvell AC5
>   buses (bus@80500000 with "ranges;" and "dma-ranges", and
>   behind-32bit-controller@7f000000, whose only purpose is the DMA
>   mapping of the devices below it).
> 
> v2 -> v3:
> - The AUDSS interrupt gate is set up by the boot firmware and is not
>   configured by Linux, so the cix,irq-router property is gone.
> - The bus nodes carry no unit-address in their names: they have no reg,
>   which made dtc warn (unit_address_vs_reg).

None of this should be in the commit message.

> 
> Assisted-by: LLM checkpatch sparse dt_binding_check dtbs_check
> Signed-off-by: Jelly Jia <Jelly.Jia@cixtech.com>
> ---
>  arch/arm64/boot/dts/cix/sky1.dtsi | 68 +++++++++++++++++++++++++------
>  1 file changed, 56 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/cix/sky1.dtsi b/arch/arm64/boot/dts/cix/sky1.dtsi
> index 0a820f45feb9..1262f34794d2 100644
> --- a/arch/arm64/boot/dts/cix/sky1.dtsi
> +++ b/arch/arm64/boot/dts/cix/sky1.dtsi
> @@ -518,18 +518,33 @@ iomuxc: pinctrl@4170000 {
>  			reg = <0x0 0x04170000 0x0 0x1000>;
>  		};
>  
> -		fch_dmac: dma-controller@4190000 {
> -			compatible = "arm,dma-350";
> -			reg = <0x0 0x4190000 0x0 0x10000>;
> -			interrupts = <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> -				     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> -				     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> -				     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> -				     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> -				     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> -				     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> -				     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>;
> -			#dma-cells = <1>;
> +		/*
> +		 * The FCH DMA-350 master sits behind an interconnect window;
> +		 * the dma-ranges below are its view of the address space.
> +		 */
> +		fch-dma-bus {
> +			compatible = "simple-bus";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			ranges;
> +			dma-ranges = <0x0 0x040a0000 0x0 0x040b0000 0x0 0x00040000>,
> +				     <0x0 0x80000000 0x0 0x80000000 0x8 0x00000000>,
> +				     <0x80 0x00000000 0x80 0x00000000 0x80 0x00000000>;
> +
> +			fch_dmac: dma-controller@4190000 {
> +				compatible = "cix,sky1-dma350", "arm,dma-350";
> +				reg = <0x0 0x04190000 0x0 0x10000>;
> +				clocks = <&scmi_clk CLK_TREE_FCH_DMA_ACLK>;
> +				interrupts = <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH 0>;

As I said on v2 an hour or so ago, I don't think this is correct, and
you should put an interrupt-map node into the syscon that contains the
irq routing registers, and have the syscon be the interrupt parent for
this node.

Thanks,
Conor.

> +				#dma-cells = <1>;
> +			};
>  		};
>  
>  		mbox_ap2se: mailbox@5060000 {
> @@ -576,6 +591,35 @@ mbox_pm2ap: mailbox@65a0080 {
>  			cix,mbox-dir = "rx";
>  		};
>  
> +		/*
> +		 * The AUDSS DMA-350 master sits behind an interconnect window;
> +		 * the dma-ranges below are its view of the address space.
> +		 */
> +		audss-dma-bus {
> +			compatible = "simple-bus";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			ranges;
> +			dma-ranges = <0x0 0x20000000 0x0 0x07010000 0x0 0x00100000>,
> +				     <0x0 0x30000000 0x0 0xc0000000 0x0 0x20000000>;
> +
> +			audss_dmac: dma-controller@7010000 {
> +				compatible = "cix,sky1-dma350", "arm,dma-350";
> +				reg = <0x0 0x07010000 0x0 0x10000>;
> +				clocks = <&audss_cru CLK_DMAC_AXI>;
> +				resets = <&audss_cru AUDSS_DMAC_SW_RST>;
> +				interrupts = <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH 0>,
> +					     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH 0>;
> +				#dma-cells = <1>;
> +			};
> +		};
> +
>  		audss_cru: clock-controller@7110000 {
>  			compatible = "cix,sky1-audss-cru";
>  			reg = <0x0 0x07110000 0x0 0x10000>;
> -- 
> 2.54.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2026-10-12 19:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12  8:41 [PATCH v3 0/6] dmaengine: arm-dma350: Add slave support and CIX Sky1 integration Jelly Jia
2026-10-12  8:41 ` [PATCH v3 1/6] dmaengine: arm-dma350: Fix source trigger bit Jelly Jia
2026-10-12 15:09   ` Frank Li
2026-10-12  8:41 ` [PATCH v3 2/6] dmaengine: arm-dma350: Add slave and cyclic transfer support Jelly Jia
2026-10-12  8:41 ` [PATCH v3 3/6] dmaengine: arm-dma350: Sync the slave command list before starting Jelly Jia
2026-10-12  8:41 ` [PATCH v3 4/6] dt-bindings: dma: arm,dma-350: Document the CIX Sky1 integration Jelly Jia
2026-10-12 19:06   ` Conor Dooley
2026-10-12  8:41 ` [PATCH v3 5/6] dmaengine: arm-dma350: Support integration clocks, resets and reserved memory Jelly Jia
2026-10-12  8:41 ` [PATCH v3 6/6] arm64: dts: cix: Describe the Sky1 DMA-350 bus integration Jelly Jia
2026-10-12 19:07   ` Conor Dooley [this message]

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=20261012-rural-undermost-b4817ebd4740@spud \
    --to=conor@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=Jelly.Jia@cixtech.com \
    --cc=cix-kernel-upstream@cixtech.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=vkoul@kernel.org \
    /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®