Re: [PATCH 06/13] iio: adc: rockchip_saradc: Benefit from devm_clk_get_enabled() to simplify

[Lars-Peter Clausen <lars@metafoo.de>]

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@pengutronix.de> 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@pengutronix.de> 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@kernel.org> wrote:
>>>>>> On Mon,  8 Aug 2022 22:47:33 +0200
>>>>>> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 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@gmail.com>
>>>>>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>>>>> 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.

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