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

[Stephen Boyd]

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.