Re: [PATCHv2] PM / devfreq: Add dev_pm_qos support

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

On 8/14/2019 4:14 AM, Chanwoo Choi wrote:
> On 19. 8. 14. 오전 10:06, Chanwoo Choi wrote:
>> On 19. 8. 13. 오후 8:27, Leonard Crestez wrote:
>>> On 13.08.2019 09:10, Chanwoo Choi wrote:
>>>> In case of cpufreq, cpufreq.c replace the body of store_min_freq()
>>>> and store_max_freq() by using struct dev_pm_qos_request instancce
>>>> with dev_pm_qos_update_request().
>>>>
>>>> If you use the new way with dev_pm_qos_update_request() for
>>>> min_freq_store() and max_freq_store(), it doesn't need to
>>>> get the final frequency from three candidate frequencies.
>>>
>>> Yes, I saw that but didn't implement the equivalent for devfreq because
>>> it's not clear what there is to gain.
>>
>> I think that it is clear. Just use the dev_pm_qos_request interface
>> for both user input through sysfs and device input with qos request.
>> Already PM_QOS has the feature to get the final freuency among
>> the multiple request. When use the dev_pm_qos request, the devfreq
>> doesn't need to compare between user input and device input with qos.
>> It make devfreq core more clear and simple

>>> Since dev_pm_qos is measured in khz it means that min_freq/max_req on
>>> sysfq would lose 3 significant digits, however those digits are probably
>>> useless anyway.
>>
>> I think that it doesn't matter. This patch already considers the this issue
>> by using '* 1000'. We can get either KHz or MHz with additional operation.
>> I think that it is not problem.

It introduces the following issue:

# echo 333333333 > /sys/class/devfreq/devfreq0/min_freq
# cat /sys/class/devfreq/devfreq0/min_freq
333333000

Changing rounding rules could confuse userspace tools. This is not 
entirely a new issue because freq values which are not an integer number 
of khz are likely not an integer number of hz either.

>> Actually, I think that I want to use the only dev_pm_qos_request
>> for all external request like devfreq cooling of thermal,
>> user input through sysfs and device request with dev_pm_qos_request.
>>
>> Already, dev_pm_qos_request is designed to consider the multiple requirements.
>> We don't need to use the various method (OPP interface, sysfs input, dev_pm_qos)
>> because make it more simple and easy.
>>
>> I think that after finished the review of this patch, I will do refactor the devfreq_cooling.c
>> by using the dev_pm_qos_request. Or, if there are some volunteeer,
> 
> Sorry, I would withdraw the this opinion about replacing
> the OPP enable/disable interface with the dev_pm_qos_request
> because even if devfreq-cooling.c needs the 'dev' instance
> to use the dev_pm_qos_request method, it is not clear until now.
> It needs how to get the device instance of devfreq on device-tree.

I looked a bit at the devfreq-cooling implementation and it seems like 
there aren't any users in upstream?

As far as I can tell a devfreq implementation needs to call 
of_devfreq_cooling_register and then the devfreq cooling code could 
register a dev_pm_qos request on devfreq->dev.parent. I'm not sure I 
understand what problem you see.

--
Regards,
Leonard