Re: Question: why call clk_prepare in pm_clk_acquire

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

On Sun, Sep 11, 2022 at 01:31:15AM +0000, Peng Fan wrote:
> > Subject: Re: Question: why call clk_prepare in pm_clk_acquire
> > 
> > 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 ?
> 
> We are using 5.15 kernel, and clk_is_enabled_when_prepared(clk) is false.
>

Sorry I was just looking at scmi clk driver.

> > 
> > > > 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 ?
> 
> The is flag in clk driver, drivers/clk/imx/clk-imx8ulp.c,
> imx8ulp_clk_hw_composite will use CLK_SET_RATE_GATE.
>

Understood.

> > 
> > > > 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.
> 
> Yes, clk_is_enabled_when_prepared(clk) is not always true in my case,
> This function is just checking ops:
> clk && !(clk->core->ops->enable && clk->core->ops->disable)
> 

Got it, I was assuming you are using scmi clk driver which is not the case.

-- 
Regards,
Sudeep