Messages in this thread |  | | Subject | Re: [PATCH v2 5/5] clk: qcom: add video clock controller driver for SM8250 | From | Jonathan Marek <> | Date | Wed, 23 Sep 2020 20:54:59 -0400 |
| |
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..
|  |