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. > > [1]: > https://lore.kernel.org/all/20230919121605.7304-1-ulf.hansson@xxxxxxxxxx/ > > [2]:https://lore.kernel.org/all/20230925131715.138411-1-ulf.hansson@xxxxxxxxxx/ > > >
