Re: [PATCH v8 0/9] RZN1 DMA support

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Stephen Boyd <sboyd@kernel.org>,
	Gareth Williams <gareth.williams.jx@renesas.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	Vinod Koul <vkoul@kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	dmaengine <dmaengine@vger.kernel.org>,
	Milan Stevanovic <milan.stevanovic@se.com>,
	Jimmy Lalande <jimmy.lalande@se.com>,
	Pascal Eberhard <pascal.eberhard@se.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Herve Codina <herve.codina@bootlin.com>,
	Clement Leger <clement.leger@bootlin.com>,
	Michael Turquette <mturquette@baylibre.com>,
	linux-clk <linux-clk@vger.kernel.org>,
	Viresh Kumar <vireshk@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
	Rob Herring <robh@kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH v8 0/9] RZN1 DMA support
Date: Thu, 14 Apr 2022 13:24:56 +0200	[thread overview]
Message-ID: <20220414132456.30b19306@xps13> (raw)
In-Reply-To: <CAMuHMdXPRb0SiCtYcqAy5YJEGp3U30FaXcmjMpgc=szXUnShpA@mail.gmail.com>

Hi Geert,

geert@linux-m68k.org wrote on Tue, 12 Apr 2022 10:12:41 +0200:

> Hi Miquel,
> 
> On Tue, Apr 12, 2022 at 10:03 AM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200:  
> > > On Tue, Apr 12, 2022 at 9:43 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:37:22 +0200:  
> > > > > So far I've been rather terse in giving feedback on these series,
> > > > > as I'm in wait-and-see mode w.r.t. what else you've planned for the
> > > > > sysctrl DT node[1] and clock/sys controller code...
> > > > >
> > > > > [1] Did I say I'm not that fond of child nodes? But for the dmamux,
> > > > >     it looks like a good solution to handle this.  
> > > >
> > > > O:-)
> > > >
> > > > I plan in the coming days to write a proper reset controller driver
> > > > that will be queried by the rtc driver (as proposed by Alexandre).  
> > >
> > > OK.
> > >  
> > > > Which means I'll have to declare this reset controller as a child of
> > > > the systrl node. If you disagree with it, you may jump-in, see this
> > > > thread :
> > > >
> > > >         Subject: Re: [PATCH 2/7] soc: renesas: rzn1-sysc: Export a
> > > >                  function to  enable/disable the RTC
> > > >         Date: Wed, 6 Apr 2022 10:32:31 +0200  
> > >
> > > But do you need a child node for that? All(most all) other Renesas
> > > clock drivers provide reset functionality, and none of them use a
> > > child node for that.  
> >
> > How do you "request" the reset handle from the consumer driver if it's
> > not described in the DT? Do you have examples to share?  
> 
> I didn't say it does not need to be described in DT ;-)
> 
> Just add "#reset-cells = <1>" to the sysctrl node, and nodes can
> start referring to it using "resets = <&sysctrl N>".
> Currently, the sysctrl node is already a clock and power-domain provider.
> 
> Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
> shows an R-Car CPG/MSSR node providing clock, power-domain, and
> reset functionalities.

While working on implementing a reset controller driver, I realized
that almost all the clocks had a reset, which was already managed by the
driver as part of a number of additional possible signals (gate
reset, gate master idle, gate ready...). So I actually figured out
that my issue originated from an incomplete description of the RTC clock
gate, which I fulfilled. Now it works without the need for an additional
exported symbol.

Thanks,
Miquèl