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

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

Hi Geert,

geert@linux-m68k.org wrote on Tue, 12 Apr 2022 09:52:25 +0200:

> Hi Miquel,
> 
> 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:  
> > > On Tue, Apr 12, 2022 at 9:32 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > geert@linux-m68k.org wrote on Mon, 11 Apr 2022 17:09:50 +0200:  
> > > > > On Thu, Apr 7, 2022 at 10:16 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > > > > sboyd@kernel.org wrote on Wed, 06 Apr 2022 17:45:09 -0700:  
> > > > > > > Quoting Miquel Raynal (2022-04-06 09:18:47)  
> > > > > > > > Here is a first series bringing DMA support to RZN1 platforms. Soon a
> > > > > > > > second series will come with changes made to the UART controller
> > > > > > > > driver, in order to interact with the RZN1 DMA controller.
> > > > > > > >
> > > > > > > > Stephen acked the sysctrl patch (in the clk driver) but somehow I feel
> > > > > > > > like it would be good to have this patch applied on both sides
> > > > > > > > (dmaengine and clk) because more changes will depend on the addition of
> > > > > > > > this helper, that are not related to DMA at all. I'll let you folks
> > > > > > > > figure out what is best.  
> > > > > > >
> > > > > > > Are you sending more patches in the next 7 weeks or so that will touch
> > > > > > > the same area? If so, then it sounds like I'll need to take the clk
> > > > > > > patch through clk tree. I don't know what is best because I don't have
> > > > > > > the information about what everyone plans to do in that file.  
> > > > > >
> > > > > > This series brings DMA support and needs to access the dmamux registers
> > > > > > that are in the sysctrl area.
> > > > > >
> > > > > > I've sent an RTC series which needs to access this area as well, but
> > > > > > it is not fully ready yet as it was advised to go for a reset
> > > > > > controller in this case. The reset controller would be registered by
> > > > > > the clock driver, so yes it would touch the same file.
> > > > > >
> > > > > > Finally, there is an USB series that is coming soon, I don't know if
> > > > > > it will be ready for merge for 5.19, but it needs to access a specific
> > > > > > register in this area as well (h2mode).
> > > > > >
> > > > > > So provided that we are able to contribute this reset driver quickly
> > > > > > enough, I would argue that it is safer to merge the clk changes in the
> > > > > > clk tree.  
> > > > >
> > > > > The clk tree or the renesas-clk tree? ;-)  
> > > >
> > > > Actually I forgot about this tree, would you mind to merge *all* the
> > > > patches that depend on the sysctrl changes in the renesas/renesas-clk
> > > > tree? This also stands for the UART and RTC for instance. Otherwise
> > > > you'll need to set up immutable branches and share them with the
> > > > dmaengine, serial and rtc trees. I'm fine either way, it's just much
> > > > less work in the first situation IMHO.  
> > >
> > > Sure, I can do that, given acks from the DMA, UART, and RTC
> > > maintainers.  
> >
> > Ok, I'll say so in the cover letter of the v9.
> >  
> > > 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?

Thanks,
Miquèl