Hi, On Thu, 4 Oct 2018 17:40:06 +0300 Tero Kristo <t-kristo@xxxxxx> wrote: > On 04/10/18 08:51, Andreas Kemnade wrote: > > We have the scenario that first autoidle is disabled for all clocks, > > then it is disabled for selected ones and then enabled for all. So > > we should have some counting here, also according to the > > comment in _setup_iclk_autoidle() > > > > Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx> > > --- > > drivers/clk/ti/autoidle.c | 20 ++++++++++++-------- > > include/linux/clk/ti.h | 1 + > > 2 files changed, 13 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c > > index 7bb9afbe4058..be2ce42e4f33 100644 > > --- a/drivers/clk/ti/autoidle.c > > +++ b/drivers/clk/ti/autoidle.c > > @@ -48,8 +48,11 @@ int omap2_clk_deny_idle(struct clk *clk) > > struct clk_hw_omap *c; > > > > c = to_clk_hw_omap(__clk_get_hw(clk)); > > - if (c->ops && c->ops->deny_idle) > > - c->ops->deny_idle(c); > > + if (c->ops && c->ops->deny_idle) { > > + c->autoidle_count--; > > + if (c->autoidle_count == -1) > > + c->ops->deny_idle(c); > > This code is racy as you have no locking in place. Please fix. > hmm, yes, it is. Due to low risk (things are only called from init before the drivers are initialized, if I understand that correctly). I kept that for final polishing and not for a rfc patch. The deny_idle/allow_idle are also racy themselves. Multiple clocks with bits in the same register changed at the same time would also create a mess. > Also, this should be verified that it doesn't cause any PM regressions, > I hope you have done that? > Tested things: I checked various autoidle registers for changes. I checked registers by reading out /dev/mem Seen changes: hdq iclk no autoidle (that is the goal of all this) dss iclk no autoidle. This one is really interesting: There are multiple users of dss_ick, so that is a special case. I will check whether I can handle that (I have already an idea) or just delete that flag there for sorting out that later, we could somehow live with not disabled autoidle flag there but needed some strange fixes in the past. Now dss_ick does unecessarily enabled, so yes, a little regression. CORE/PER idlest seems to behave as well as before that change. Regards, Andreas
Attachment:
pgpeLc2QHVZOR.pgp
Description: OpenPGP digital signature