Re: Question: why call clk_prepare in pm_clk_acquire

[Sudeep Holla <sudeep.holla@arm.com>]

On Thu, Sep 08, 2022 at 04:37:13PM +0200, Ulf Hansson wrote:
> On Thu, 8 Sept 2022 at 09:33, Peng Fan <peng.fan@nxp.com> wrote:
> >
> > Hi All,
> >
> > We are facing an issue clk_set_rate fail with commit a3b884cef873 ("firmware:
> > arm_scmi: Add clock management to the SCMI power domain") ,
> 
> Hmm, I wonder about the main reason behind that commit. Can we revert
> it or is there some platform/driver that is really relying on it?
>

IIUC, at the time of the commit, it was needed on some Renesas platform.
Not sure if it is still used or not.

> >
> > we use scmi power domain, but not use scmi clk, but with upper commit, the clk is prepared
> > when pm_clk_acquire.
> >

Is this based on latest SCMI clocks that support atomic or older one
which doesn't. If latter, I see pm_clk_acquire doesn't actually call
prepare as if clk_is_enabled_when_prepared(clk) = true. Do you see have
issue ?

> > However the clk has flag CLK_SET_RATE_GATE, clk_set_rate will fail in driver, because
> > clk is prepared in pm_clk_acquire.
> >

Where is CLK_SET_RATE_GATE set exactly ?

> > Looking into drivers/base/power/clock_ops.c, I see pm_clk_suspend/pm_clk_resume
> > will handle clk prepare/unprepared, so why pm_clk_acquire will also prepare the clk?
>

As asked above do you see the actual clk_prepare getting called as I
see it isn't if lk_is_enabled_when_prepared(clk) = true.

> I agree, the behaviour is certainly questionable to me too. However,
> it may be tricky to change by now, due to the deployment that has
> happened over the years.
>

Agreed.

> In principle we would need to make the part where pm_clk_acquire
> prepares the clock to become optional, in some clever way.
>

I see it is already, let us see what is Peng's observation.

-- 
Regards,
Sudeep