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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d7207c1c-c4e4-f994-cacb-bdfb7952732b@marek.ca>
Date:   Wed, 23 Sep 2020 20:54:59 -0400
From:   Jonathan Marek <jonathan@...ek.ca>
To:     Stephen Boyd <sboyd@...nel.org>, linux-arm-msm@...r.kernel.org
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v2 5/5] clk: qcom: add video clock controller driver for
 SM8250

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..