[v2,0/2] PM / devfreq: Add dev_pm_qos support
mbox series

Message ID cover.1575540224.git.leonard.crestez@nxp.com
Headers show
Series
  • PM / devfreq: Add dev_pm_qos support
Related show

Message

Leonard Crestez Dec. 5, 2019, 10:05 a.m. UTC
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://patchwork.kernel.org/cover/11262633/

It would be great for this to get into 5.5-rc1

---
Changes since RFC v1:
* Trim cover letter
* Drop RFC since DEV_PM_QOS_MIN/MAX_FREQUENCY was restored
* Collect Acks.
* No code changes
Link to v1: https://patchwork.kernel.org/cover/11252415/

Changes since "big version" v10:
* Drop accepted cleanups
* Work with current locking approach (split cleanups into other series)
* Drop acks and deliberately relabel as a new series. It still incorporates
most previous discussion but takes a different approach to locking.
* Don't print errors if devfreq_dev_release is called on error cleanup from
devfreq_add_device, just accept that requests and notifiers might not be
registered yet. I wish dev_pm_qos cleanups behaved like standard "kfree" and
silently did nothing when there's nothing to be done.
Link to v10: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=196443

Leonard Crestez (2):
  PM / devfreq: Add PM QoS support
  PM / devfreq: Use PM QoS for sysfs min/max_freq

 drivers/devfreq/devfreq.c | 151 ++++++++++++++++++++++++++++++++++----
 include/linux/devfreq.h   |  14 +++-
 2 files changed, 145 insertions(+), 20 deletions(-)

Comments

Rafael J. Wysocki Dec. 5, 2019, 10:12 a.m. UTC | #1
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://patchwork.kernel.org/cover/11262633/
>
> 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?
Leonard Crestez Dec. 5, 2019, 10:44 a.m. UTC | #2
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

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
Chanwoo Choi Dec. 6, 2019, 3:27 a.m. UTC | #3
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

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
> 
>
Chanwoo Choi Dec. 6, 2019, 4:54 a.m. UTC | #4
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
>>
>>
> 
>