Re: [RFC 0/4] opp: Parse required-opp as dev_pm_qos_request

[Leonard Crestez <leonard.crestez@nxp.com>]

On 20.08.2019 12:22, Viresh Kumar wrote:
> On 20-08-19, 09:02, Leonard Crestez wrote:
>> On 20.08.2019 09:52, Viresh Kumar wrote:
>>> On 06-08-19, 14:12, Leonard Crestez wrote:
>>>> The "required-opps" property can be placed on any device and point to
>>>> any OPP table according to bindings doc but this is not fully
>>>> implemented. In practice it can only point from the opp table of a
>>>> device to the opp table of a power domain.
>>>>
>>>> As part of my investingating QOS mechanisms I implemented support for
>>>> parsing "required-opps" into a DEV_PM_QOS_MIN_FREQUENCY
>>>> dev_pm_qos_request. Since OPPs can be shared between devices this only
>>>> works when OPP tables are unshared.
>>>>
>>>> This would need to be called from a device probe function and any
>>>> suspend/resume handling (which likely means disabling the QOS requests)
>>>> would also be handled manually by each driver.
>>>>
>>>> This is RFC mostly because I plan to use the "interconnect" framework
>>>> for device requests instead. In theory this could be used if you don't
>>>> care about implementing smart aggregation and just want to "set bus freq
>>>> to high".
>>>>
>>>> Devfreq support for dev_pm_qos is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F11078475%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7C9ff357888cba49c522ce08d7254fe2c4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637018897344276009&sdata=NV2Xnop9%2BplnKdIqrMCHF05xpt9y651ed%2BhwFK8gEKI%3D&reserved=0
>>>
>>> Some work is going on in related field. Please have a look at this as well.
>>
>> I noticed that series but other than touching "required-opp" there is
>> little in common. It seems to be mostly an expansion of the passive
>> governor.
>>
>> My series doesn't even depend on devfreq; in theory you could even use
>> required-opp = <&opp_1200mhz> on a cpu device.
> 
> What is the exact use case you are targeting here or the problem you are trying
> to solve ?

My exact use case is that devices (such as display, gpu, audio etc) need 
DRAM to run at a minimum frequency. This is currently done in imx vendor 
tree with a custom API but I'm trying to upstream via devfreq:

https://patchwork.kernel.org/cover/11104113/

The "required-opp" documentation looked like it would be a fit but 
apparently it requires all requesting devices to have OPPs and the 
target to be a power domain? This seemed very restrictive so this series 
implements a different way to handle required-opp, via dev_pm_qos.

The interconnect subsystem has additional capabilities (scaling along a 
path) so I plan to use that instead. You can treat this series as a 
"curiosity".

--
Regards,
Leonard