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

[Chanwoo Choi <cw00.choi@samsung.com>]

Hi,

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.

> 
>> In result, We only consider the following two candidate frequencies
>> as following:
>> 1. "devfreq->scaling_min_freq" will contain the requirement
>>     from devfreq thermal throttling by OPP interface.
> 
> It's a bit awkward that the OPPs enable/disable API is not obviously 
> specific to "thermal".

driver/thermal/devfreq_cooling.c uses the OPP interface to enable/disable
the OPP entries according to the thermal throttling policy. 

> 
>> 2. "devfreq->min_freq" will contain the requirements
>>     from both user input through sysfs and the dev_pm_qos_request.
> According to a comment on a previous version it would be useful to have 
> a separate files for "constraint min/max freq" and "user min/max freq":
> 
>      https://patchwork.kernel.org/patch/11078475/#22805379

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,

> 
> Combining min/max requests from dev_pm_qos and sysfs would make this 
> harder to implement. I guess user_min_freq could be implemented by 

I think that it is not difficult. Just make the different dev_pm_qos_request
instances. When qos has the multiple request from one more dev_pm_qos_request,
just get the value by using dev_pm_qos_read_value().
- a dev_pm_qos_request for user input
- b dev_pm_qos_request for device request on other device driver


> reading back the dev_pm_qos request but there would be no way to 
> implement a qos_min_freq entry.

I don't understand. Just devfreq show the min freq from dev_pm_qos_request
which contains the all requirement of minimum frequency.

If there are no any request to dev_pm_qos_request, we can just
get the minimum frequency from dev_pm_qos_request because 
the devfreq device would call the dev_pm_qos_update_request(..., min_freq)
on the probe time.

If I know the wrong information, please let me know.


> 
>>> +static int devfreq_qos_min_notifier_call(struct notifier_block *nb, unsigned long val, void *ptr)
>>
>> Please keep the under 80 line if there are no any special reason.
> 
> OK, will check.
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics