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

[Taniya Das <tdas@codeaurora.org>]

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.

--