[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <666fc9cf-ac5a-2289-d838-14c36dc8dfcb@arm.com>
Date: Wed, 14 Oct 2020 10:11:30 +0100
From: Lukasz Luba <lukasz.luba@....com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Ionela Voinescu <ionela.voinescu@....com>,
Sudeep Holla <sudeep.holla@....com>,
Nicola Mazzucato <nicola.mazzucato@....com>,
devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
vireshk@...nel.org, daniel.lezcano@...aro.org, rjw@...ysocki.net,
linux-kernel@...r.kernel.org, robh+dt@...nel.org,
chris.redpath@....com, morten.rasmussen@....com,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for
cpu-perf-dependencies
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
Powered by blists - more mailing lists