Re: [PATCH v2 2/8] dt-bindings: dma: Introduce RZN1 DMA compatible

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Geert,

geert@linux-m68k.org wrote on Wed, 23 Feb 2022 17:16:32 +0100:

> Hi Miquel,
> 
> On Wed, Feb 23, 2022 at 4:49 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > geert@linux-m68k.org wrote on Wed, 23 Feb 2022 13:21:47 +0100:  
> > > On Tue, Feb 22, 2022 at 11:35 AM Miquel Raynal
> > > <miquel.raynal@bootlin.com> wrote:  
> > > > Just like for the NAND controller that is also on this SoC, let's
> > > > provide a SoC generic and a more specific couple of compatibles for the
> > > > DMA controller.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>  
> > >  
> > > > +++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml  
> > >
> > > Perhaps you want to add the power-domains property?
> > > The RZ/N1 clock driver is also a clock-domain provider.  
> >
> > I haven't looked at the power domains yet, but I don't plan to invest
> > time on it right now. Unless I don't understand your request, and you
> > are telling me that someone else added the description and we should
> > now point to the right domain from each new node?  
> 
> The RZ/N1 System Controller is a clock-domain provider. 

Yes, there are many domains managed there.

> This means
> it can automatically manage the module clocks of devices that are
> part of the clock domain, assuming device drivers are using Runtime PM.
> 
> The upstream RZ/N1 DTS doesn't have many devices enabled yet.
> Most of them are (variants of) Synopsis IP cores, and their drivers
> manage clocks explicitly, instead of relying on Runtime PM.
> 
> BTW, I have just noticed the system-controller node[1] even lacks
> the #power-domain-cells property, while the example[2] does have it.

Yes, that's why I didn't understand the initial remark.

> When that is added, device nodes can gain "power-domains = <&sysctrl>",
> and module clocks can be managed from Runtime PM.  Perhaps the NAND
> driver would be a good target for conversion to Runtime PM, as its
> driver is not shared with SoCs from other vendors yet?
> Note this is not mandatory, and drivers can keep on using explicit
> clock handling (until the IP core is reused on an SoC that not only
> has a clock-domain, but also real power-domains).

Got it, thanks for the details. Indeed it would be interesting to gain
runtime PM support if this SoC has a good power-domain support.

Power domain cells must first be contributed.

> [1] arch/arm/boot/dts/r9a06g032.dtsi
> [2] Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds


Thanks,
Miquèl