| Message ID | 20220222103437.194779-3-miquel.raynal@bootlin.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | RZN1 DMA support | expand |
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. Apart from that: Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> 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
Hi Geert, 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? > Apart from that: > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Thanks! Miquèl
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. 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. 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). [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
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
diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml index 6b35089ac017..c13649bf7f19 100644 --- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml @@ -15,7 +15,13 @@ allOf: properties: compatible: - const: snps,dma-spear1340 + oneOf: + - const: snps,dma-spear1340 + - items: + - enum: + - renesas,r9a06g032-dma + - const: renesas,rzn1-dma + "#dma-cells": minimum: 3
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> --- .../devicetree/bindings/dma/snps,dma-spear1340.yaml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)