Re: Question: why call clk_prepare in pm_clk_acquire

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

Hi Peng,

On Thu, Sep 15, 2022 at 12:59:32AM +0000, Peng Fan wrote:
> > Subject: Re: Question: why call clk_prepare in pm_clk_acquire
> > 
> > On Mon, Sep 12, 2022 at 06:58:49PM +0100, Geert Uytterhoeven wrote:
> > > Hi Sudeep,
> > >
> > > CC Dien Pham
> > >
> > > On Mon, Sep 12, 2022 at 6:49 PM Geert Uytterhoeven <geert@linux-
> > m68k.org> wrote:
> > > > On Fri, Sep 9, 2022 at 4:51 PM Sudeep Holla <sudeep.holla@arm.com>
> > wrote:
> > > > > On Fri, Sep 09, 2022 at 01:12:03PM +0200, Ulf Hansson wrote:
> > > > > > On Thu, 8 Sept 2022 at 19:38, Sudeep Holla <sudeep.holla@arm.com>
> > wrote:
> > > > > > > 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:
> > > > > > > > > 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.
> > > > > >
> > > > > > Okay! Maybe Nico remembers more, as he authored the patch...
> > > > > >
> > > > >
> > > > > May be, or even check with Renesas team who tested his patch.
> > > >
> > > > I'm not aware of Renesas platforms using SCMI...
> > >
> > > Upon closer look, Diep Pham did report a build issue in the SCMI code,
> > > so perhaps Diep knows more...
> > >
> > 
> > Yes indeed, Diep Pham tested the original patch IIRC and also has reported
> > few bugs in SCMI clock code which are fixed. Hence I know it is used by
> > Renesas.
> > 
> > Hi Peng,
> > 
> > Absence of DTS changes indicate nothing. I am aware of couple of vendors
> > who use SCMI on several platforms and do report issues regularly and help
> > in review of the code. So DTS is not a good indicator of SCMI usage
> > unfortunately. On reason could be that since it is a firmware, bootloaders
> > can detect and update DTS, just my thought and may differ from the reality.
> 
> Could we make the GENPD_FLAG_PM_CLK as a optional flag as Ulf suggested?
> Such as non scmi clk platforms not require this flag, or any other suggestion?
> 

I agreed to make it conditional, but what that "condition" must be is
something I don't know as I don't understand it. What I want to avoid it
to make it platform dependent(using some platform specific compatible) in
the generic SCMI PM domain driver if possible.

Hi Dien,

If you could confirm that there are Renesas platforms dependent on this,
that would be great. We could simply revert the original commit if there
is no more use for this instead of finding other ways to fix the issue
Peng has reported.

-- 
Regards,
Sudeep