| Message ID | cover.1575540224.git.leonard.crestez@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | PM / devfreq: Add dev_pm_qos support | expand |
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?
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&data=02%7C01%7Cleonard.crestez%40nxp.com%7C265c079a936b4c2a9c6608d7796bbc16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637111375932506745&sdata=uI0if7aNnedxEsMlNQ4sCDOElVBxCp%2B%2BVGaeZC0DaMk%3D&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
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&data=02%7C01%7Cleonard.crestez%40nxp.com%7C265c079a936b4c2a9c6608d7796bbc16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637111375932506745&sdata=uI0if7aNnedxEsMlNQ4sCDOElVBxCp%2B%2BVGaeZC0DaMk%3D&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 > >
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&data=02%7C01%7Cleonard.crestez%40nxp.com%7C265c079a936b4c2a9c6608d7796bbc16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637111375932506745&sdata=uI0if7aNnedxEsMlNQ4sCDOElVBxCp%2B%2BVGaeZC0DaMk%3D&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 >> >> > >