Re: [PATCH v2 5/6] dmaengine: arm-dma350: Add CIX Sky1 integration support

[Jelly Jia <Jelly.Jia@cixtech.com>]

On Fri, Oct 09, 2026 at 04:29:57PM +0100, Conor Dooley wrote:
> struct d350_data {
> 	u32 irq_route_reg;
> 	u32 irq_route_mask;
>
> Since this is a fixed value, there's little point having it as part of
> your match data. Ditto the reg value, for the same reason. The user is
> called directly from your probe code, so you can use the defines
> directly.
>
> That said, should you actually be doing this from here? It feels like
> a bit of a problem with abstractions where you're fiddling with another
> device. Syscon stuff is okay when you're changing something internal to
> your device's functionality or something "downstream" of your device -
> between you and the output pins. But this is something "upstream" of our
> device and I dunno if this is the right way to do it. If you need to set
> some sort of interrupt routing, should you actually do something like
> microchip,mpfs-irqmux or renesas,rzn1-gpioirqmux and preserve the
> abstraction/separation between devices?
>
> Cheers,
> Conor.

Agreed on both points. We plan to handle the interrupt gate as
firmware/pre-Linux platform setup for v3, so the upstream DMA driver
will not program it. The v3 I am preparing removes all of this from the
upstream DMA driver:

- the cix,irq-router syscon lookup and the routing write in probe
- the d350_data match data with the route register and mask
- the d350_route_irqs() helper and the resume_noirq hook that re-applied
  the routing after system resume
- the MFD_SYSCON select that this pulled in

What remains in the driver is only the integration of the DMA controller
itself: the clock and the reset, plus the address translation that is
described by the dma-ranges of the parent bus node and applied through
the DMA API. The driver no longer reaches into anything outside its own
node.

Best regards,
Jelly