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

From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: "Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	linux-iio <linux-iio@vger.kernel.org>,
	"David Wu" <david.wu@rock-chips.com>,
	"Anand Ashok Dumbre" <anand.ashok.dumbre@xilinx.com>,
	"Vladimir Zapolskiy" <vz@mleia.com>,
	"Paul Cercueil" <paul@crapouillou.net>,
	"Antoniu Miclaus" <antoniu.miclaus@analog.com>,
	"Sascha Hauer" <kernel@pengutronix.de>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	"Nuno Sa" <nuno.sa@analog.com>,
	"Michal Simek" <michal.simek@xilinx.com>,
	"Simon Xue" <xxm@rock-chips.com>
Subject: Re: [PATCH 06/13] iio: adc: rockchip_saradc: Benefit from devm_clk_get_enabled() to simplify
Date: Sat, 20 Aug 2022 12:42:35 +0100	[thread overview]
Message-ID: <20220820124235.223d4a7e@jic23-huawei> (raw)
In-Reply-To: <bd8472f2-e4d0-2a63-98a5-5e1fe8ad6255@metafoo.de>

On Tue, 16 Aug 2022 10:38:41 +0200
Lars-Peter Clausen <lars@metafoo.de> 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@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.  
> 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
> >  
> 