On 20/04/17 06:25, Viresh Kumar wrote: > On 19-04-17, 14:58, Sudeep Holla wrote: >> On 19/04/17 12:47, Viresh Kumar wrote: >>> On 18-04-17, 17:01, Sudeep Holla wrote: [...] >> >> Yes, I completely agree. I am not saying the direction is wrong. I >> am saying it's confusing and binding needs to be more clear. > > What exactly isn't clear? (Yeah, there had been lots of emails and I > want to know what improvements are you looking for). > Just that the term performance is closely related to frequency, it needs to be explicit on what *exactly* it means. As it stands now, it can be used for OPP as I explain which controls both but as you clarify that's not what it's designed for. >> On the contrary(playing devil's advocate here), we can treat all >> existing regulators alone as OPP then if you strip the voltages >> and treat it as abstract number. > > But then we are going to have lots of platform specific code which > will program the actual hardware, etc. Which is all handled by the > regulator framework. Also note that the regulator core selects the > common voltage selected by all the children, while we want to select > the highest performance point here. > I am not sure if choosing highest performance point makes it difficult to fit it in regulator framework. It could be some configuration. Also IIUC the actual programming is done in the firmware in this case and I fail to see how that adds lot of platform code. > Even if we have to configure both clock and voltage for the power > domain using standard clk/regulator frameworks, OPP will work just > fine as it will do that then. So, its not that we are bypassing the > regulator framework here. It will be used if we have the voltages > available for the power-domain's performance states. > Yes I understand that. -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
