On Wed, Jan 24, 2024 at 02:38:54PM +0100, Vincent Guittot wrote: > On Wed, 24 Jan 2024 at 14:17, Nikunj Kela <quic_nkela@xxxxxxxxxxx> wrote: > > > > > > On 1/24/2024 4:48 AM, Sudeep Holla wrote: > > > On Wed, Jan 24, 2024 at 04:27:55AM -0800, Nikunj Kela wrote: > > >> On 1/24/2024 3:02 AM, Sudeep Holla wrote: > > >>> Not really, still puzzled may be more than before as I don't understand > > >>> what is going on with the approach as it seem to be deviating from my > > >>> initial understanding. > > >>> > > >>> May be take an example of one driver, present the DT binding and driver > > >>> changes to make sure there is no misunderstanding from my side. But I am > > >>> not convinced with the explanation so far. > > >> Hi Sudeep, > > >> > > >> We are not using clock protocol to deal with clocks individually. We are > > >> trying to define different perf domains for peripherals where we are > > >> grouping clocks/regulators/interconnect bandwidth into these perf domains > > >> and use OPP levels via SCMI perf protocol. > > > That clarifies on what you are trying to achieve. > > > > > >> This is done so as to avoid individual scmi calls for these resources > > >> hence avoiding any race conditions and minimizing the traffic between SCMI > > >> client and server to get better KPIs. > > > Fair enough, why can't you just use genpd perf APIs to achieve that ? > > > > OPP is built on top of genpd perf only and was recommended by Ulf(PM > > maintainer from Linaro) hence we decided to use OPP APIs instead of > > directly genpd perf API. > > > > > > > > > >> This is being planned for sa8775p platform and any subsequent platforms will > > >> use the same approach. The idea of using perf protocol for peripherals is > > >> new and Qualcomm is first one trying to use that. > > > Sure. > > > > > >> Therefore existing peripheral drivers will require a way to distinguish between the > > >> two different configurations. Hope this provides little more context and > > >> insight. > > >> > > > While I agree this is new, use custom APIs to control standard resources > > > is simply *VERY VERY BAD IDEA* IMO. You may be fine to have these custom > > > API calls in qcom specific drivers. But what if this is needed in some > > > generic IP driver. Just not scalable and why should the maintainer of > > > such driver accept you custom API. > > > > Apologies if it wasn't clear but we are not using custom APIs. We are > > using standard OPP APIs to set to opp level of the perf domain. > > Example-dev_pm_opp_set_opp(). As mentioned above, we are following PM > > framework maintainers recommendation to use OPP. > > > > > > > > > > So I would suggest to work towards using std framework APIs or create one > > > if you can justify the need for it. Please stop creating custom APIs for > > > using SCMI. It defeats the whole standardisation it is meant to provide. > > > > Not sure I understand what you refer to as custom APIs here. The OPP > > APIs are not custom APIs. They are from OPP framework built on top of > > genpd perf. [1] and [2] patch series might provide you more insight into > > the work that Ulf did to support SCMI perf with OPP framework. > > I think that you are speaking about the same thing. They plan to use > SCMI power domain for idle states and SCMI performance domain for > setting a performance mode. Then, the OPP library is used on top of > perf domain to gather and manipulate the different perf levels. > Indeed, I just realise that after Nikunj's last email. Earlier to that, it was not so clear and it sounded like some custom way. Anyways I am still not convinced if this is something drivers need to handle with explicit DT support for this distinction in particular. -- Regards, Sudeep
