Re: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

[Conor Dooley <conor@kernel.org>]

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

On Thu, Jan 29, 2026 at 09:04:45AM +0100, Geert Uytterhoeven wrote:
> Hi Conor,
> 
> On Wed, 28 Jan 2026 at 21:09, Conor Dooley <conor@kernel.org> wrote:
> > On Wed, Jan 28, 2026 at 06:51:48PM +0000, Cosmin-Gabriel Tanislav wrote:
> > > > From: Conor Dooley <conor@kernel.org>
> 
> > > > On Tue, Jan 27, 2026 at 10:17:04PM +0200, Cosmin Tanislav wrote:
> > > > > The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
> > > > > can be used with the RSPI peripheral. The current bindings only allow a
> > > > > single pair of RX and TX DMAs.
> > > > >
> > > > > Allow multiple DMAs by only restricting the possible names of the DMA
> > > > > channels.
> > > >
> > > > > All '.*-names$' properties must conform to the string-array.yaml
> > > > > meta-schema, which requires both minItems and maxItems properties to be
> > > > > present before the items can be a schema. Otherwise, the items need to
> > > > > be an array.
> > > >
> > > > Why is this in the commit message?
> > >
> > > To provide a context for the maxItems that are needed below, even if
> > > there's not really a maximum. Which is why having a maxItems does not
> > > really make sense but it is expected by the meta-schema so we can
> > > constrain the names of the DMA channels.
> > >
> > > dtschema/meta-schemas/string-array.yaml:
> > >
> > > if:
> > >   not:
> > >     required:
> > >       - minItems
> > >       - maxItems
> > > then:
> > >   properties:
> > >     items:
> > >       type: array
> >
> > Right. You can probably remove all that since I'm asking you to add
> > actual constraints to the property.
> >
> > > > > Declare a generous maxItems of 32, which should be enough for 16 DMA
> > > > > controllers, so that we don't have to update this value ever again, even
> > > > > if currently the maximum number of DMA controllers on a Renesas SoC is
> > > > > 5.
> > > >
> > > > Huh, No. The binding should constrain this to fit what the actual
> > > > devices do.
> 
> The device is the SPI controller, or the SoC where the SPI controller
> is integrated?

Whether the SoC's number of dma controllers is the limiter or whether it's
the number of inputs to the spi controller isn't something I know the
answer to (and which it is in theory could vary between SoCs), so I used
device instead of "SoC integration of the spi controller represented by
a given compatible".

> > > Should the binding for SPI be updated if a device ever comes up with
> > > 6 DMA controllers? It seems a bit unrelated to me. In this case, should
> > > we constrain the number of dmas and dma-names per SoC? Some may have 2
> > > DMA controllers, while others may have 5. Please let me know your
> > > thoughts, taking into account that I only added maxItems to satisfy the
> > > meta-schema.
> >
> > Yes, I think you should constrain it to the correct number of providers
> > for each device.
> > Whether that's done or not, there's not all that much reason to set it
> > above whatever the current maximum is, since the binding will have to be
> > updated to add the compatible for whatever device exceeds the current max
> > and the limit can be increased then.
> 
> The actual maximum number of dmas pairs does not depend on the SPI
> controller, but on the SoC integration.  I think the (single) DMA
> request signal from the SPI controller is just wired to all DMACs
> present (on this SoC, IIRC there were some Renesas SoCs where some
>  DMA clients are wired to only a single DMAC).

Right, that's largely what I had gathered from Cosmin-Gabriel's comments
and the patch itself. I think the comments I made here are all still
applicable? If there's a new SoC, there'll be a new compatible for the
spi controller's integration on that SoC and the limit can be bumped
then.

Cheers,
Conor.


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