Re: [PATCH v2 5/5] clk: qcom: add video clock controller driver for SM8250

[Jonathan Marek]

On 9/23/20 7:30 PM, Stephen Boyd wrote:
> Quoting Jonathan Marek (2020-09-23 09:07:16)
> > On 9/22/20 2:46 PM, Stephen Boyd wrote:
> > > Quoting Jonathan Marek (2020-09-03 20:09:54)
> > >
> > > > +                       .ops = &clk_branch2_ops,
> > > > +               },
> > > > +       },
> > > > +};
> > > > +
> > > > +static struct clk_branch video_cc_mvs0_clk = {
> > > > +       .halt_reg = 0xd34,
> > > > +       .halt_check = BRANCH_HALT_SKIP, /* TODO: hw gated ? */
> > >
> > > Is this resolved?
> >
> > Downstream has this clock as BRANCH_HALT_VOTED, but with the upstream
> > venus driver (with patches to enable sm8250), that results in a
> > "video_cc_mvs0_clk status stuck at 'off" error. AFAIK venus
> > enables/disables this clock on its own (venus still works without
> > touching this clock), but I didn't want to remove this in case it might
> > be needed. I removed these clocks in the v3 I just sent.
>
> Hmm. Does downstream use these clks? There have been some clk stuck
> problems with venus recently that were attributed to improperly enabling
> clks before enabling interconnects and power domains. Maybe it's the
> same problem.

Yes, downstream uses these clks.

The "stuck" problem still happens if GSDCS/interconnects are always on, 
and like I mentioned, venus works even with these clocks completely 
removed.

I think venus controls these clocks (and downstream just happens to try 
enabling it at a point where venus has already enabled it?). I'm not too 
sure about this, it might have something to do with the GDSC having the 
HW_CTRL flag too..