linux-kernel - Re: [PATCH 2/4] OPP: Add support for parsing the 'opp-sustainable' property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c8c2319-969e-d028-9a52-271d43611568@arm.com>
Date:   Fri, 30 Oct 2020 12:53:58 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Quentin Perret <qperret@...gle.com>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        vireshk@...nel.org, robh+dt@...nel.org, nm@...com,
        rafael@...nel.org, sboyd@...nel.org, daniel.lezcano@...aro.org,
        sudeep.holla@....com, Dietmar.Eggemann@....com
Subject: Re: [PATCH 2/4] OPP: Add support for parsing the 'opp-sustainable'
 property

Hi Quentin,

On 10/30/20 11:47 AM, Quentin Perret wrote:
> Hi Lukasz,
> 
> On Wednesday 28 Oct 2020 at 14:08:45 (+0000), Lukasz Luba wrote:
>> +unsigned long dev_pm_opp_get_sustainable_opp_freq(struct device *dev)
>> +{
>> +	struct opp_table *opp_table;
>> +	unsigned long freq = 0;
>> +
>> +	opp_table = _find_opp_table(dev);
>> +	if (IS_ERR(opp_table))
>> +		return 0;
>> +
>> +	if (opp_table->sustainable_opp && opp_table->sustainable_opp->available)
>> +		freq = dev_pm_opp_get_freq(opp_table->sustainable_opp);
>> +
>> +	dev_pm_opp_put_opp_table(opp_table);
>> +
>> +	return freq;
>> +}
>> +EXPORT_SYMBOL_GPL(dev_pm_opp_get_sustainable_opp_freq);
> 
> I'm guessing this is what IPA will use to find out what the sustainable
> frequency is right?

Yes, you are right.

> 
> Is PM_OPP the right place for that? It feels odd IPA will get the EM
> from one place, which includes the performance state, and the sustained
> OPP from another. Should we move that to PM_EM instead?

True, it might looks strange, but the OPP framework is available when we
are adding the OPPs in scmi perf layer. The EM is available after we
register the device, so at the end of scmi-cpufreq init.
It would require a new scmi perf api function e.g. get_sustained_freq(),
and a set/get function for EM, which is doable.

I've discussed this approach to Viresh and he likes it better.
I am happy that you are also suggesting the EM approach.

I will send different patches for EM and SCMI to make that happen.
Should I re-based them on top of the patch adding this milliwatts filed
in EM [1]? Or do the opposite, changing the dependency order?

Regards,
Lukasz

[1] https://lkml.org/lkml/2020/10/19/392

> 
> Thanks,
> Quentin
>