devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Brian Norris <briannorris@chromium.org>,
	Douglas Anderson <dianders@chromium.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Lee Jones <lee.jones@linaro.org>,
	Benson Leung <bleung@chromium.org>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH v4 09/12] dt-bindings: PM / OPP: add opp-throttlers property
Date: Mon, 25 Jun 2018 13:03:04 -0700	[thread overview]
Message-ID: <20180625200304.GF129942@google.com> (raw)
In-Reply-To: <20180625185037.GE129942@google.com>

On Mon, Jun 25, 2018 at 11:50:37AM -0700, Matthias Kaehlcke wrote:
> Hi Rob,
> 
> On Mon, Jun 25, 2018 at 09:33:41AM -0600, Rob Herring wrote:
> > On Wed, Jun 20, 2018 at 06:52:34PM -0700, Matthias Kaehlcke wrote:
> > > The optional opp-throttlers property is used to configure the throttlers
> > > (see drivers/misc/throttler/*) that use a given OPP to throttle the
> > > corresponding device(s).
> > > 
> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > Reviewed-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > > Changes in v4:
> > > - added 'Reviewed-by: Brian Norris <briannorris@chromium.org>' tag
> > > 
> > > Changes in v3:
> > > - none
> > > 
> > > Changes in v2:
> > > - patch added to series
> > > ---
> > >  Documentation/devicetree/bindings/opp/opp.txt | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > > index c396c4c0af92..747e79740c75 100644
> > > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > > @@ -170,6 +170,9 @@ Optional properties:
> > >    functioning of the current device at the current OPP (where this property is
> > >    present).
> > >  
> > > +- opp-throttlers: Array with phandles of throttlers that use this OPP to
> > > +  throttle the corresponding device(s).
> > > +
> > 
> > I think it would be better to make this a boolean for each OPP entry and 
> > then add "operating-points-v2" property to the EC node to point to the 
> > OPP table.
> 
> Thanks for your suggestion. "operating-points-v2" would have to be an
> array of phandles, a single thottler can have multiple throttling
> devices.
> 
> > Unless there is some need for a different throttler for each OPP entry?
> 
> Having the option to use different OPPs per throttler would be my
> preference. E.g. there could be configurations where one throttler
> only interacts with certain throttling devices and another one
> with others.
> 
> I see another option to achieve this, if you don't like the reference
> to the throttlers in the OPPs. The throttler could have a list of OPPs
> (as phandles, not frequencies as in v1). The main inconvenient I see
> here is that the used OPPs would need a label, which they usually
> don't have. Maybe this is no soooo bad, since the label could be added
> at device level, only on devices that use a throttler, so it wouldn't
> clutter the platform .dts files.
> 
> This could be a single array with all OPPs from different devices,
> or multiple arrays, one for each throttling device:
> 
> throttler-opps-0 = <&cpu0_opp_03 &cpu0_opp_05>;
> throttler-opps-1 = <&gpu_opp_02 &gpu_opp_04>;
> 
> My preference would be multiple arrays, because it's easier to read.

I take the preference back. The OPPs for each device (group) can be
clustered within the single array and if needed clarifying comments
can be added:

throttler-opps = <&cpu0_opp_03 &cpu0_opp_05  /* CPU0 */
	       	  &gpu_opp_02 &gpu_opp_04>;  /* GPU */

This is simpler algorithmically and there is no need for an additional
property indicating the number of OPP groups or probing.

  reply	other threads:[~2018-06-25 20:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-21  1:52 [PATCH v4 00/12] Add throttler driver for non-thermal throttling Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 01/12] PM / devfreq: Init user limits from OPP limits, not viceversa Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 02/12] PM / devfreq: Fix handling of min/max_freq == 0 Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 03/12] PM / devfreq: Don't adjust to user limits in governors Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 04/12] PM / devfreq: Add struct devfreq_policy Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 05/12] PM / devfreq: Add support for policy notifiers Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 06/12] PM / devfreq: Make update_devfreq() public Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 07/12] PM / devfreq: export devfreq_class Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 08/12] cpufreq: Add stub for cpufreq_update_policy() Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 09/12] dt-bindings: PM / OPP: add opp-throttlers property Matthias Kaehlcke
2018-06-25 15:33   ` Rob Herring
2018-06-25 18:50     ` Matthias Kaehlcke
2018-06-25 20:03       ` Matthias Kaehlcke [this message]
2018-06-26 15:49         ` Rob Herring
2018-06-26 18:11           ` Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 10/12] misc: throttler: Add core support for non-thermal throttling Matthias Kaehlcke
2018-06-22  2:04   ` Brian Norris
2018-06-23  1:31     ` Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 11/12] misc: throttler: Add Chrome OS EC throttler Matthias Kaehlcke
2018-06-21  1:52 ` [PATCH v4 12/12] mfd: cros_ec: Add throttler sub-device Matthias Kaehlcke
2018-06-22  2:06   ` Brian Norris

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=20180625200304.GF129942@google.com \
    --to=mka@chromium.org \
    --cc=arnd@arndb.de \
    --cc=bleung@chromium.org \
    --cc=briannorris@chromium.org \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kyungmin.park@samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=olof@lixom.net \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=viresh.kumar@linaro.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: link
Be 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).