lkml.org 
[lkml]   [2020]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 5/5] clk: qcom: add video clock controller driver for SM8250
From
Date
Quoting Jonathan Marek (2020-09-23 17:54:59)
> 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..

Ok. Maybe Taniya has an idea.

\
 
 \ /
  Last update: 2020-09-24 08:19    [W:0.060 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site