linux-kernel - Re: [PATCH v4 0/2] clk: qcom: Add support for RCG to register for DFS

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] [day] [month] [year] [list]

Message-ID: <531a5894-da72-fb38-dece-87a06c4ff7d6@codeaurora.org>
Date:   Tue, 28 Aug 2018 14:36:35 +0530
From:   Taniya Das <tdas@...eaurora.org>
To:     Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>
Cc:     Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Amit Nischal <anischal@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/2] clk: qcom: Add support for RCG to register for DFS



On 8/28/2018 2:34 AM, Stephen Boyd wrote:
> Quoting Stephen Boyd (2018-08-23 11:25:41)
>> Quoting Taniya Das (2018-08-22 03:28:31)
>>>
>>>>
>>>> Hmmmm. Ok. That won't work then. recalc_rate() better not try to
>>>> populate the frequency table then or it will not work. So I suppose it
>>>> needs to fallback to reading the registers and assuming the parent_rate
>>>> coming in is the actual frequency of it's parent until the frequency
>>>> table pointer is non-NULL. Would that work?
>>>>
>>> Yes that would work.
>>
>> Ok.
>>
>>>
>>>> BTW, does DFS switch parents without software knowing about it?
>>> DFS would not switch until a HW request is sent, but SW would be unware
>>> of the switch except the current_perf_state being updated with the
>>> requested level.
>>>
>>> What
>>>> happens in that case? Does the QUP driver make sure that the new parent
>>>> of this RCG is properly enabled so that it can switch to it when needed?
>>>
>>> I am not sure if they poll for any of their QUP HW state to make sure
>>> the switch is complete.
>>>
>>>> I'm still trying to understand this whole design. Who takes care of the
>>>> voltage requirements in this case? The QUP driver as well?
>>>>
>>>
>>> When the QUP driver requires to switch to new performance level, the
>>> first request would be to set_rate()(QUP driver would get the list of
>>> supported frequencies using the clk_round_rate()) which in QCOM clock
>>> driver would take care of setting the required voltage for the new
>>> parent switch.
>>
>> It would also make sure that the new parent is enabled if the QUP clk is
>> enabled. That's another concern. Does the PLL turn on automatically when
>> the RCG switches to it?
>>
>>> Then the QUP driver would request the HW for a new perf switch which
>>> would result to a DFS switch for the QUP clocks.
>>
>> It sounds like the QUP driver does half of the work via the clk APIs and
>> then the other half through the DFS register. Maybe the QUP driver
>> should be registering a clk as well for its DFS register so it can all
>> be clk API calls here. Something to consider. Anyway, that's not
>> important to this patch so here's the updated patch.
> 
> I've squashed this in and applied the patches.
> 
Thanks Stephen.
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--