linux-kernel - Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT

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 for Android: free password hash cracker in your pocket

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

Message-ID: <58201597.6010207@codeaurora.org>
Date:   Mon, 07 Nov 2016 11:18:07 +0530
From:   Rajendra Nayak <rnayak@...eaurora.org>
To:     'Stephen Boyd' <sboyd@...eaurora.org>,
        Sricharan <sricharan@...eaurora.org>
CC:     mturquette@...libre.com, linux-clk@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        stanimir.varbanov@...aro.org
Subject: Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus
 core0/1 clks



On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote:
> On 11/04, Sricharan wrote:
>> Hi,
>>>
>>> A better design would be to check if the associated GDSC is in hw
>>> control mode and then skip the checks because the clocks are no
>>> longer under the control of the registers. I presume we only
>>> enable the clocks here to turn on parent clocks which don't turn
>>> on/off automatically, i.e. the PLL.
>>>
>> I was thinking clocks in the powerdomain still needs to be turned
>> on explicitly, these are branch clocks, irrespective of the PLLs.
>> Putting the gdsc in hw_ctrl, only makes the polling on their status
>> invalid. Anyways would be good to be aligned on this.
> 
> Sure. We also need to make sure the branches are on themselves.
> When the gdsc is disabled the clocks are killed though. This is
> why we can't enable clocks until the gdsc is enabled.
> 
>>
>>> Given that hw control is a static decision I guess that is an
>>> over-engineered solution though? The problem is that this seems
>>> brittle because we have to keep two things in sync, the branches
>>> and the gdsc. So I guess this is ok, but it deserves a comment
>>> like "GDSC is in HW control" so we know what's going on. Also the
>>> commit text could be more explicit that clocks within the gdsc
>>> power domain don't work when the gdsc is off, and with hw control
>>> of a gdsc we can't tell when the gdsc may be off or on.
>>>
>>
>> ok, i will reword the commit log better as above.
>>
>> So i understand its ok to continue with this way of checking ?
>> since we are always having a static association which never changes,
>> than introducing additional fields in the clk_branch which can
>> get the status of the gdsc.
>>
> 
> Well I'm also curious which case is failing. Does turning on the
> clocks work after the gdsc is enabled? Does turning off the
> clocks fail because we don't know when the gdsc has turned off? I
> would hope that the firmware keeps the gdsc on when it's done
> processing things, goes idle, and hands back control to software.
> Right now I'm failing to see how the halt bits fail to toggle
> assuming that firmware isn't misbehaving and the kernel driver is
> power controlling in a coordinated manner with the firmware.

What fails is turning ON the clocks after the gdsc is put under
hardware control (by fails I mean the halt checks fail to indicate
the clock is running, but register accesses etc thereafter suggest
the clocks are actually running)
The halt checks seem to work only while the gdsc is put in SW enabled
state.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation