Re: DT Query on "New Compatible vs New Property"

[Sudeep Holla <sudeep.holla@arm.com>]

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@quicinc.com> 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