On Tue, 16 Aug 2022 10:38:41 +0200 Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: > On 8/16/22 10:27, Lars-Peter Clausen wrote: > > On 8/16/22 10:20, Andy Shevchenko wrote: > >> On Mon, Aug 15, 2022 at 10:42 AM Uwe Kleine-König > >> <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > >>> On Mon, Aug 15, 2022 at 10:30:45AM +0300, Andy Shevchenko wrote: > >>>> On Mon, Aug 15, 2022 at 12:31 AM Uwe Kleine-König > >>>> <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > >>>>> On Sun, Aug 14, 2022 at 10:01:08PM +0300, Andy Shevchenko wrote: > >>>>>> On Sat, Aug 13, 2022 at 7:21 PM Jonathan Cameron > >>>>>> <jic23@xxxxxxxxxx> wrote: > >>>>>>> On Mon, 8 Aug 2022 22:47:33 +0200 > >>>>>>> Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > >>>>>>> > >>>>>>>> Make use of devm_clk_get_enabled() to replace some code that > >>>>>>>> effectively > >>>>>>>> open codes this new function. > >>>>>>>> > >>>>>>>> Reviewed-by: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> > >>>>>>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > >>>>>>> This might have side effects as it now enables the clock before > >>>>>>> calling > >>>>>>> the clk_set_rate(). Also changes the clock start up ordering. > >>>>>>> Neither is that > >>>>>>> scary a change, but on really fussy hardware they might cause > >>>>>>> problems. > >>>>>>> > >>>>>>> Add a few rock-chips people who have sent patches in last few years > >>>>>>> to hopefully take a look or even better run a test. > >>>>>> I believe you found a bug in the patch. The possible solutions are: > >>>>>> - not take the patch > >>>>>> - disable and re-enable clock around clk_set_rate() > >>>>>> > >>>>>> IIRC clk_set_rate() will spit a WARN if clock is enabled. > >>>>> You mean in general? I think that's wrong. There might be some > >>>>> clks that > >>>>> do that, but I'd consider them strange. If you ask me, calling > >>>>> clk_set_rate() for a *disabled* clk is the strange concept ... > >>>> I think it's correct from the logic and electrical perspective. That's > >>>> why the preparation and enablement are separated in CCF. But please > >>>> double check, because I can't remember everything by heart. > >>> In my book the separation is done because "enabling" has to sleep for > >>> some clks (e.g. PLLs) while a sleeping clk_enable() is bad for various > >>> use cases and most clks don't sleep for enabling. > >> Yeah, but the idea of changing clock rate on the fly may produce > >> interesting side-effects on hardware level (with PLL latencies to lock > >> the phase and possible glitches). So, changing clock against enabled > >> hardware (not in reset / power off state) seems not a good idea. > > > > The clk_set_rate() API will internally disable the clock, if the clock > > chip requires it. See `CLK_SET_RATE_GATE` flag. > Sorry, I misremembered. If `CLK_SET_RATE_GATE` is set `set_rate` will > return an error if the clock is enabled when `set_rate` is called. Thanks for chasing that down. In that case I definitely don't want to take this without input from those who can test it! Jonathan > > > > But I tend to agree, the better idiom is to `set_rate` we should do > > that before `enable`. This will avoid any unintentional glitches on > > the clock signal > > >
