Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies

[Lukasz Luba]

On 10/14/20 5:25 AM, Viresh Kumar wrote:
> On 12-10-20, 18:18, Lukasz Luba wrote:
> > On 10/12/20 5:52 PM, Ionela Voinescu wrote:
> > > On Monday 12 Oct 2020 at 16:49:30 (+0100), Sudeep Holla wrote:
> > > > On Fri, Oct 09, 2020 at 11:09:21AM +0530, Viresh Kumar wrote:
> > > > > - I wonder if we can keep using that instead of creating new bindings
> > > > >     for exact same stuff ? Though the difference here would be that the
> > > > >     OPP may not have any other entries.
> > > >
> > > > Well summarised, sorry for chiming in late. I could have not summarised
> > > > any better. Just saw the big thread and was thinking of summarising.
> > > > If the last point on OPP is possible(i.e. no OPP entries but just use
> > > > it for fetch the information) for $subject patch is trying to achieve,
> > > > then it would be good.
>
> Under normal circumstances, I wouldn't have suggested empty opp-tables
> for sure but it doesn't seem worth adding another binding to get this
> information out :)
>
> > > Just to put in my two pennies worth: using opp-shared (in possibly empty
> > > OPP table) as alternative to cpu-perf-dependencies sounds good enough
> > > to me as well.
> >
> > +1
>
> Now that (almost) everyone agrees, I don't think we need to make any
> change anywhere, in code or bindings. This should work right now as
> well.  The code should never try to create OPP tables and the core
> will not create one. Your driver (which want to get this information
> out of empty OPP tables) shall call dev_pm_opp_of_get_sharing_cpus(),
> which just parses the DT to get this information out.

Thank you Viresh. We are going to experiment with this and come back
soon.

Regards,
Lukasz