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