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 ? > 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. 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. -- Regards, Sudeep
