Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

[Michael Turquette]

Hi James,

Quoting James Liao (2016-07-03 20:51:48)
> On Fri, 2016-07-01 at 18:21 -0700, Stephen Boyd wrote:
> > (Resending to everyone)
> > 
> > On 06/22, Erin Lo wrote:
> > > From: James Liao <jamesjj.liao@xxxxxxxxxxxx>
> > > 
> > > This patch fixed wrong state of parent clocks if they are registered
> > > after critical clocks.
> > > 
> > > Signed-off-by: James Liao <jamesjj.liao@xxxxxxxxxxxx>
> > > Signed-off-by: Erin Lo <erin.lo@xxxxxxxxxxxx>
> > 
> > It would be nice if you included the information about the
> > problem from James' previous mail. This says what it does, but
> > doesn't explain what the problem is and how it is fixing it.
> > 
> > > ---
> > >  drivers/clk/clk.c | 9 ++++++++-
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index d584004..e9f5f89 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -2388,8 +2388,15 @@ static int __clk_core_init(struct clk_core *core)
> > >     hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) {
> > >             struct clk_core *parent = __clk_init_parent(orphan);
> > >  
> > > -           if (parent)
> > > +           if (parent) {
> > >                     clk_core_reparent(orphan, parent);
> > > +
> > > +                   if (orphan->prepare_count)
> > > +                           clk_core_prepare(parent);
> > > +
> > > +                   if (orphan->enable_count)
> > > +                           clk_core_enable(parent);
> > > +           }
> > >     }
> > 
> > I'm pretty sure I pointed this problem out to Mike when the
> > critical clk patches were being pushed. I can't recall what the
> > plan was though to fix the problem. I'm pretty sure he said that
> > clk_core_reparent() would take care of it, but obviously it is
> > not doing that. Or perhaps it was that clk handoff should figure
> > out that the parents of a critical clk are also on and thus keep
> > them on.
> 
> Hi Mike
> 
> Is there any other patch to fix this issue? Or did I misuse critical
> clock flag?

There is no fix yes. Your fix is basically correct. I was mistaken back
when I told you and Stephen that the framework already took care of
this.

However, instead of "open coding" this solution, I would rather re-use
the __clk_set_parent_{before,after} helpers instead. Can you review/test
the following patch and let me know what you think?

Thanks,
Mike