Re: [PATCH v2] clk: qcom: lpasscc: Re-configure the PLL in case lost

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, Oct 14, 2020 at 10:06 AM Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
>
> Quoting Douglas Anderson (2020-10-14 08:58:24)
> > diff --git a/drivers/clk/qcom/lpasscorecc-sc7180.c b/drivers/clk/qcom/lpasscorecc-sc7180.c
> > index 228d08f5d26f..ee23eb5b9bf2 100644
> > --- a/drivers/clk/qcom/lpasscorecc-sc7180.c
> > +++ b/drivers/clk/qcom/lpasscorecc-sc7180.c
> > @@ -356,6 +356,25 @@ static const struct qcom_cc_desc lpass_audio_hm_sc7180_desc = {
> >         .num_gdscs = ARRAY_SIZE(lpass_audio_hm_sc7180_gdscs),
> >  };
> >
> > +static int lpass_core_cc_pm_clk_resume(struct device *dev)
> > +{
> > +       struct regmap *regmap = dev_get_drvdata(dev);
>
> Can we use dev_get_remap(dev, NULL) instead?

Good idea.  ...but as far as I can tell there are two regmaps.  I'll use

dev_get_regmap(dev, "lpass_core_cc");


> > +       unsigned int l_val;
> > +       int ret;
> > +
> > +       ret = pm_clk_resume(dev);
> > +       if (ret)
> > +               return ret;
> > +
> > +       /* Read PLL_L_VAL */
>
> Please drop this useless comment. Replace it with something like this
> (if at all):
>
>         /* Reconfigure PLL if PLL was reset across suspend */

We reconfigure more than just the PLL.  I believe that the PLL being
zero is just a clue that we use to know we should re-init the whole
thing.  I've tried to convey this in a comment in the next version.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux