LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org> To: MyungJoo Ham <myungjoo.ham@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com>, Chanwoo Choi <cw00.choi@samsung.com>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Brian Norris <briannorris@chromium.org>, Douglas Anderson <dianders@chromium.org> Subject: Re: [PATCH 07/11] PM / devfreg: Add support policy notifiers Date: Tue, 29 May 2018 13:02:40 -0700 [thread overview] Message-ID: <20180529200240.GI168650@google.com> (raw) In-Reply-To: <20180528051949epcms1p3bedd6ac3e2f20d0bcd8cb082349d97fa@epcms1p3> On Mon, May 28, 2018 at 02:19:49PM +0900, MyungJoo Ham wrote: > >Policy notifiers are called before a frequency change and may narrow > >the min/max frequency range in devfreq_policy, which is used to adjust > >the target frequency if it is beyond this range. > > > >Also add a few helpers: > > - devfreq_verify_within_[dev_]limits() > > - should be used by the notifiers for policy adjustments. > > - dev_to_devfreq() > > - lookup a devfreq strict from a device pointer > > > >Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > >--- > > drivers/devfreq/devfreq.c | 47 +++++++++++++++++++++------- > > include/linux/devfreq.h | 66 +++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 102 insertions(+), 11 deletions(-) > > Hello Matthias, > > > Why should we have yet another notifier from an instance of devfreq? > Wouldn't it better to let the current notifier (transition notifier) > handle new events as well by adding possible event states to it? Honestly the main reason is that I sought inspiration from cpufreq, which uses a dedicated policy notifier. Unfortunately this change predates the git history so I don't know what was the exact rationale to do it this way. Some minor advantages that I see are: - transition notifiers aren't bothered about adjustments and viceversa - different data types are passed for transitions and adjustments, which makes code of notifiers that handle both a bit more messy. > Anyway, is this the reason why you've separated some data of devfreq > into "policy" struct? (I was wondering why while reading commit 6/11). The DEVFREQ_ADJUST is the reason for the "policy struct". With this change we are dealing with 3 types of frequency pairs: user (df->min/max_freq), devinfo (df->scaling_min/max_freq) and the policy/adjustable ones. I think it is cleaner to group them in a struct (and sub-structs), rather than having 6 individual <type>_min/max_freq variables. Also it allows to only pass the policy object to the notifiers, instead of the entire devfreq device. I opted to do the introduction of the struct policy in a separate NOP patch, because I think it is easier to review the 'reorg' churn and the functional change separately. Please let me know if you'd prefer to have certain things done differently. Thanks Matthias
next prev parent reply other threads:[~2018-05-29 20:02 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-25 20:30 [PATCH 00/11] Add throttler driver for non-thermal throttling Matthias Kaehlcke 2018-05-25 20:30 ` [PATCH 01/11] PM / devfreq: Init user limits from OPP limits, not viceversa Matthias Kaehlcke 2018-05-28 5:26 ` Chanwoo Choi 2018-05-29 18:06 ` Matthias Kaehlcke 2018-05-25 20:30 ` [PATCH 02/11] PM / devfreq: Fix handling of min/max_freq == 0 Matthias Kaehlcke 2018-05-28 6:37 ` Chanwoo Choi 2018-05-29 18:57 ` Matthias Kaehlcke 2018-05-30 8:04 ` Chanwoo Choi 2018-05-30 21:13 ` Matthias Kaehlcke 2018-06-05 9:40 ` Chanwoo Choi 2018-05-25 20:30 ` [PATCH 03/11] PM / devfreq: Remove check for df->max_freq == 0 from governors Matthias Kaehlcke 2018-05-28 5:27 ` Chanwoo Choi 2018-05-25 20:30 ` [PATCH 04/11] PM / devfreq: Remove redundant frequency adjustment " Matthias Kaehlcke 2018-05-28 5:36 ` Chanwoo Choi 2018-05-25 20:30 ` [PATCH 05/11] PM / devfreq: governors: Return device frequency limits instead of user limits Matthias Kaehlcke 2018-05-28 6:56 ` Chanwoo Choi 2018-05-25 20:30 ` [PATCH 06/11] PM / devfreq: Add struct devfreq_policy Matthias Kaehlcke 2018-05-25 20:30 ` [PATCH 07/11] PM / devfreg: Add support policy notifiers Matthias Kaehlcke 2018-05-25 20:30 ` [PATCH 08/11] PM / devfreq: Make update_devfreq() public Matthias Kaehlcke 2018-05-25 20:30 ` [PATCH 09/11] misc: throttler: Add core support for non-thermal throttling Matthias Kaehlcke 2018-05-28 7:32 ` Chanwoo Choi 2018-05-29 20:57 ` Matthias Kaehlcke 2018-05-30 8:08 ` Chanwoo Choi 2018-05-28 8:08 ` Greg Kroah-Hartman 2018-05-29 21:30 ` Matthias Kaehlcke 2018-05-25 20:30 ` [PATCH 10/11] dt-bindings: misc: add bindings for throttler Matthias Kaehlcke 2018-05-31 16:31 ` Rob Herring 2018-05-31 18:34 ` Matthias Kaehlcke 2018-05-31 20:04 ` Rob Herring 2018-05-31 21:10 ` Matthias Kaehlcke 2018-05-25 20:30 ` [PATCH 11/11] misc/throttler: Add Chrome OS EC throttler Matthias Kaehlcke 2018-05-31 9:05 ` Enric Balletbo Serra 2018-05-31 17:33 ` Matthias Kaehlcke [not found] ` <CGME20180525203120epcas2p429d60dc21e16f0b53c58e7b1f942858f@epcms1p8> 2018-05-28 3:59 ` [PATCH 02/11] PM / devfreq: Fix handling of min/max_freq == 0 MyungJoo Ham [not found] ` <CGME20180525203122epcas3p42a494949f50aa933355840b7e46bb0fe@epcms1p2> 2018-05-28 4:51 ` [PATCH 03/11] PM / devfreq: Remove check for df->max_freq == 0 from governors MyungJoo Ham [not found] ` <CGME20180525203124epcas2p2db3f1996b33348f19a6a91cee55abb0b@epcms1p1> 2018-05-28 4:57 ` [PATCH 04/11] PM / devfreq: Remove redundant frequency adjustment " MyungJoo Ham [not found] ` <CGME20180525203125epcas3p46c7cac352ede4b0ba5d2b36bc32ad566@epcms1p8> 2018-05-28 5:04 ` [PATCH 05/11] PM / devfreq: governors: Return device frequency limits instead of user limits MyungJoo Ham 2018-05-29 19:32 ` Matthias Kaehlcke [not found] ` <CGME20180525203128epcas5p138dbf89498c03bc2a9221aa662001fd4@epcms1p3> 2018-05-28 5:19 ` [PATCH 07/11] PM / devfreg: Add support policy notifiers MyungJoo Ham 2018-05-29 20:02 ` Matthias Kaehlcke [this message] [not found] ` <CGME20180525203128epcas2p21a65a88fed7838221d02f6419f58bf26@epcms1p1> 2018-05-28 5:24 ` [PATCH 08/11] PM / devfreq: Make update_devfreq() public MyungJoo Ham
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180529200240.GI168650@google.com \ --to=mka@chromium.org \ --cc=arnd@arndb.de \ --cc=briannorris@chromium.org \ --cc=cw00.choi@samsung.com \ --cc=devicetree@vger.kernel.org \ --cc=dianders@chromium.org \ --cc=gregkh@linuxfoundation.org \ --cc=kyungmin.park@samsung.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=myungjoo.ham@samsung.com \ --cc=robh+dt@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).