On Wed, Jan 24, 2024 at 05:17:09AM -0800, Nikunj Kela 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. > Right, this is std API, but the way it was explained before seemed like a custom API that builds and sends SCMI command and hence the objection. I assume dev_pm_opp_set_opp() uses the attached genpd perf domain to make the request, so it is fine. > > > > 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. > As mentioned above, agreed. It was not clear before and it was explained as if you are using custom methods. Anyways, why do you need know what is the backend provider if you just use this dev_pm_opp_set_opp() unconditionally. That part is still not clear. Things like this should be handled without any explicit DT changes IMO, but happy to hear if I am missing something. -- Regards, Sudeep
