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

[Taniya Das]

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.

--