Messages in this thread | | | From | Geert Uytterhoeven <> | Date | Thu, 11 Feb 2021 08:55:07 +0100 | Subject | Re: [PATCH v4] PM / clk: make PM clock layer compatible with clocks that must sleep |
| |
Hi Stephen,
On Thu, Feb 11, 2021 at 4:35 AM Stephen Boyd <sboyd@kernel.org> wrote: > Quoting Nicolas Pitre (2021-01-25 11:29:18) > > The clock API splits its interface into sleepable ant atomic contexts: > > > > - clk_prepare/clk_unprepare for stuff that might sleep > > > > - clk_enable_clk_disable for anything that may be done in atomic context > > > > The code handling runtime PM for clocks only calls clk_disable() on > > suspend requests, and clk_enable on resume requests. This means that > > runtime PM with clock providers that only have the prepare/unprepare > > methods implemented is basically useless. > > > > Many clock implementations can't accommodate atomic contexts. This is > > often the case when communication with the clock happens through another > > subsystem like I2C or SCMI. > > > > Let's make the clock PM code useful with such clocks by safely invoking > > clk_prepare/clk_unprepare upon resume/suspend requests. Of course, when > > such clocks are registered with the PM layer then pm_runtime_irq_safe() > > can't be used, and neither pm_runtime_suspend() nor pm_runtime_resume() > > may be invoked in atomic context. > > > > For clocks that do implement the enable and disable methods then > > everything just works as before. > > > > A note on sparse: > > According to https://lwn.net/Articles/109066/ there are things > > that sparse can't cope with. In particular, pm_clk_op_lock() and > > pm_clk_op_unlock() may or may not lock/unlock psd->lock depending on > > some runtime condition. To work around that we tell it the lock is > > always untaken for the purpose of static analisys. > > > > Thanks to Naresh Kamboju for reporting issues with the initial patch. > > > > Signed-off-by: Nicolas Pitre <npitre@baylibre.com> > > Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> > > > > --- > > Thanks for doing this. I think it's the main reason why nobody uses the > PM clock code so far.
"git grep pm_clk_add" tells you otherwise?
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
| |