Re: [PATCH v2 0/2] PM / devfreq: Add dev_pm_qos support

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

On 12/6/19 12:27 PM, Chanwoo Choi wrote:
> On 12/5/19 7:44 PM, Leonard Crestez wrote:
>> On 2019-12-05 12:13 PM, Rafael J. Wysocki wrote:
>>> On Thu, Dec 5, 2019 at 11:05 AM Leonard Crestez <leonard.crestez@nxp.com> wrote:
>>>>
>>>> Add dev_pm_qos notifiers to devfreq core in order to support frequency
>>>> limits via dev_pm_qos_add_request.
>>>>
>>>> Unlike the rest of devfreq the dev_pm_qos frequency is measured in kHz,
>>>> this is consistent with current dev_pm_qos usage for cpufreq and
>>>> allows frequencies above 2Ghz (pm_qos expresses limits as s32).
>>>>
>>>> Like with cpufreq the handling of min_freq/max_freq is moved to the
>>>> dev_pm_qos mechanism. Constraints from userspace are no longer clamped on
>>>> store, instead all values can be written and we only check against OPPs in a
>>>> new devfreq_get_freq_range function. This is consistent with the design of
>>>> dev_pm_qos.
>>>>
>>>> Notifiers from pm_qos are executed under a single global dev_pm_qos_mtx and
>>>> need to take devfreq->lock, this means that calls into dev_pm_qos while holding
>>>> devfreq->lock are not allowed (lockdep warns about possible deadlocks).
>>>>
>>>> Fix this by only adding the qos request and notifiers after devfreq->lock is
>>>> released inside devfreq_add_device. In theory this means sysfs writes
>>>> are possible before the min/max requests are initialized so we guard
>>>> against that explictly. The dev_pm_qos_update_request function would
>>>> otherwise print a big WARN splat.
>>>>
>>>> This series depends on recently accepted series restoring
>>>> DEV_PM_QOS_MIN/MAX_FREQUENCY inside the pm core:
>>>>
>>>>          https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11262633%2F&amp;data=02%7C01%7Cleonard.crestez%40nxp.com%7C265c079a936b4c2a9c6608d7796bbc16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637111375932506745&amp;sdata=uI0if7aNnedxEsMlNQ4sCDOElVBxCp%2B%2BVGaeZC0DaMk%3D&amp;reserved=0
>>>>
>>>> It would be great for this to get into 5.5-rc1
>>>
>>> Not at this point.  The earliest realistic target can be -rc2.
>>>
>>> Does this still depend on anything which has not been included into
>>> the Linus' tree to date?
>>
>> This series depends on DEV_PM_QOS_MIN/MAX_FREQUENCY and that's already 
>> in. It also depends on a few other patches from devfreq-next:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-next&id=1d81785fd070088c952fd9f0d8cb4c47c192122b
>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-next&id=a2b3d24b75036c44a5509e9ec3a5c14672e98c73
>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-next&id=0f68bfe7d58dfb49972f93768f9fdd97ce205844
> 
> And this patch depends on patch[1] in order to prevent the merge conflict.
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-fixes&id=6306ad828b335ba967d2f3c2cbfdb84ebda46cb8
> 
> For sending the devfreq pm-qos features for rc2 period,
> - "devfreq-fixes" branch contains the required patches for devfreq pm-qos feature.
> - "devfreq-testing-pm-qos" branch contains the devfreq pm-qos feature based on devfreq-fixes branch.
>   To prevent the build error, applied the following four patches picked from linux-pm.git.
> 	PM / QoS: Restore DEV_PM_QOS_MIN/MAX_FREQUENCYdevfreq-testing-pm-qos
> 	PM / QoS: Reorder pm_qos/freq_qos/dev_pm_qos structs
> 	PM / QoS: Initial kunit test
> 	PM / QoS: Redefine FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAX
> : https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing

I'm sorry. I wrote the wrong branch name previously.
Write the correct url of "devfreq-testing-pm-qos" branch.
: https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-pm-qos

> 
> After released the v5.5-rc1, I'll send the devfreq pm-qos patches.
> 
>>
>> It doesn't currently apply on torvalds/master
>>
>> There are some interconnect patches which depend on this for proper 
>> functionality but we can figure something out with icc maintainer.
>>
>> * https://patchwork.kernel.org/cover/11244421/
>> * https://patchwork.kernel.org/patch/11153917/
>>
>> I personally always test with linux-next so RC schedules don't affect me 
>> very much.
>>
>> --
>> Regards,
>> Leonard
>>
>>
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel