[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aK2gE0CysSWisFwB@x1>
Date: Tue, 26 Aug 2025 07:52:51 -0400
From: Brian Masney <bmasney@...hat.com>
To: claudiu beznea <claudiu.beznea@...on.dev>
Cc: mturquette@...libre.com, sboyd@...nel.org, geert+renesas@...der.be,
linux@...linux.org.uk, linux-renesas-soc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org,
Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH 0/2] clk: renesas: rzg2l: Disable unused clocks after
resume
Hi Claudiu,
On Tue, Aug 26, 2025 at 02:01:56PM +0300, claudiu beznea wrote:
> On 8/25/25 20:05, Brian Masney wrote:
> > On Thu, Aug 21, 2025 at 11:03:30AM +0300, Claudiu wrote:
> > > From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> > > This series disables clocks that remain unused after resume.
> > > This is necessary when the resume process is done with the help of the
> > > bootloader, as the bootloader enables various clocks when returning from
> > > resume.
> > >
> > > On the RZ/G3S SoC (where this series was tested), the bootloader enables
> > > the SDHI clocks (for all SDHI modules, of which 2 are used by Linux and
> > > 1 is unused) and the clocks for a serial IP (unused by Linux).
> > >
> > > Testing was done on the RZ/G3S SMARC Carrier II board.
> >
> > Do you think that other boards would also benefit from this change? If
> > so, what do you think about putting the call to register_pm_notifier()
> > inside an __init block in clk.c so that this same change doesn't have to
> > be implemented across various clk drivers?
>
> Yes, that was my other approach I was thinking about. I wanted to see how
> other people consider this version.
>
> >
> > Alternatively, if this is board specific, could this be fixed in the
> > boot loader so that the clock that's not used by Linus is properly shut
> > down on resume?
>
> As a result of your request I did some more investigations on my side, I can
> say that, yes, in theory that could be also handled by bootloader.
>
> I can drop this and try to do it in bootloader, if any. Please let me know
> if you still consider this (or the variant that implements it in a generic
> way) necessary.
Personally I would go the route of fixing this in the bootloader for
this particular platform.
If this issue affects other platforms, particularly across multiple
SoC vendors, then I think it would be worthwhile to have a discussion
about adding this functionality to the clk core.
Brian
Powered by blists - more mailing lists