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

[Lukasz Luba <lukasz.luba@arm.com>]

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
>