Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "broonie@kernel.org" <broonie@kernel.org>
Cc: "corbet@lwn.net" <corbet@lwn.net>, "pavel@ucw.cz" <pavel@ucw.cz>,
	"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
	"dmurphy@ti.com" <dmurphy@ti.com>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	"jeffrey.t.kirsher@intel.com" <jeffrey.t.kirsher@intel.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"mchehab+samsung@kernel.org" <mchehab+samsung@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>,
	"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
	"a.zummo@towertech.it" <a.zummo@towertech.it>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"hofrat@osadl.org" <hofrat@osadl.org>,
	"wsa+renesas@sang-engineering.com"
	<wsa+renesas@sang-engineering.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
	"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"phil.edworthy@renesas.com" <phil.edworthy@renesas.com>,
	"lee.jones@linaro.org" <lee.jones@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"sboyd@kernel.org" <sboyd@kernel.org>
Subject: Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282 regulator bindings
Date: Mon, 2 Dec 2019 14:02:41 +0000
Message-ID: <72a1f4c5768b8c08c2669ea01e60d1b614095a43.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <20191202131140.GD1998@sirena.org.uk>


On Mon, 2019-12-02 at 13:11 +0000, Mark Brown wrote:
> On Mon, Dec 02, 2019 at 07:57:13AM +0000, Vaittinen, Matti wrote:
> > On Fri, 2019-11-29 at 12:09 +0000, Mark Brown wrote:
> > > The regulator driver has a bunch fo set_suspend_ operations.
> > Hmm. I saw these. But unless I am mistaken linux only knows one
> > 'suspend' state whereas the PMIC has a few separate states I can
> > see as
> > 'suspend' states. As far as I understood the set_suspend_voltage
> > does
> > not allow setting separate suspend voltages depending on the "type
> > of
> > suspend" (as there is only one 'suspend' state).
> 
> No, look at the bindings - we support a bunch of different
> suspend states matching the different suspend states that the
> kernel as a whole supports.  We don't assume that the device will
> know this but you can always use the current suspend we're going
> for to decide where to update.

Hm. So if I understand this correctly, you mean user should set the
suspend 'target' - and then call the set_suspend_voltage for this
state. To set voltages for all states one should do loop

get_current_mode()

for_all_modes() {
	set_mode()
	set_voltage()
}

restore_original_mode()

am I on a right track? I'll try to see if I can find some examples of
this - thanks.

> 
> > > > (RUN0, ... RUN3) could be mapped to regulator modes
> > > > REGULATOR_MODE_FAST, REGULATOR_MODE_NORMAL, REGULATOR_MODE_IDLE
> > > > and 
> > > > REGULATOR_MODE_STANDBY. But regulators which are controlled by
> > > > these
> > > That doesn't make sense at all, the modes affect the quality of
> > > regulation not the voltage that is set.
> > Thanks. I misunderstood this. I thought these states could be used
> > for
> > some adaptive voltages. My understanding is that the RUN0,...RUN3
> > are
> > designed for that - but I didn't know if regulator framework is
> > designed for this.
> 
> The framework doesn't care how a device is controlled, that's up
> to the device.  Like I said I recommend figuring out what
> voltages are useful to have quick access to at runtime, for
> example it's likely that it's good to have quick access to the
> highest voltage that's been set (and/or the top of the
> constraints).

Problem is that the run-level controlled regulator can't be
individually controlled (unless it is only regulator in the group). I
misunderstood these REGULATOR_MODE_FAST, ...,REGULATOR_MODE_STANDBY to
be global 'states' rather than states of individual regulators. And I
thought these were also designed for voltage scaling. But as I said, I
misunderstood them - so thanks for correcting me on this.

> 
> > > The cpufreq code is all there in kernel - drivers/cpufreq.  I
> > > can't
> > > remember if Android still has a custom governor in their trees
> > > but it
> > > doesn't really make much difference in terms of how it interacts
> > > with
> > > the regulator drivers.
> > Right. I guess your answers mean that there is no "regulator group
> > control" for "adaptive voltage changes" supported by regulator
> 
> I can't parse the above, sorry.  What is "regulator group
> control"?

I mean bundling the regulators in a group - and changing state for all
of the bundled regulators in one go. The thing I mentioned earlier -
and I guess you did already confirm it's not doable. I think you said
that only 'mass operation' or 'group operation' is the suspend.

But just to confirm, I meant for example assigning bucks 1,2,6 and 7
into a group which 'state' is changed via GPIO line. Say 'states' are
RUN0, RUN1. For each of these bucks we can define a voltage and
enable/disable status which is to be used on RUN0, and another
voltage/state tuple for RUN1.

When certain 'trigger' is detected (I assume CPU load here and adaptive
voltage scaling - but this is just my assumption of the use-case for
now) the PMIC state can be quickly changed via this GPIO toggle.

In realty, we have two GPIOs and 4 states - but that does not change
the princible. I don't think there is any 'de-facto' mechanism to
control such groups.


Br,
	Matti Vaittinen

  reply index

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18  6:53 [PATCH v5 00/16] Support ROHM BD71828 PMIC Matti Vaittinen
2019-11-18  6:53 ` [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
2019-11-18 16:25   ` Mark Brown
2019-11-18 18:03     ` Vaittinen, Matti
2019-11-19 18:13       ` Mark Brown
2019-11-19 18:51         ` Vaittinen, Matti
2019-11-19 19:36           ` Mark Brown
2019-11-29  7:48             ` Vaittinen, Matti
2019-11-29 12:09               ` Mark Brown
2019-12-02  7:57                 ` Vaittinen, Matti
2019-12-02 13:11                   ` Mark Brown
2019-12-02 14:02                     ` Vaittinen, Matti [this message]
2019-12-04 12:47                       ` Mark Brown
2019-12-04 13:13                         ` Vaittinen, Matti
2019-12-04 14:14                           ` Mark Brown
2019-11-22 22:48   ` Rob Herring
2019-11-18  6:54 ` [PATCH v5 02/16] dt-bindings: leds: ROHM BD71282 PMIC LED driver Matti Vaittinen
2019-11-22 23:00   ` Rob Herring
2019-11-18  6:54 ` [PATCH v5 03/16] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
2019-11-22 23:05   ` Rob Herring
2019-11-18  6:55 ` [PATCH v5 04/16] mfd: rohm PMICs - use platform_device_id to match MFD sub-devices Matti Vaittinen
2019-11-18  6:55 ` [PATCH v5 05/16] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-11-18  6:56 ` [PATCH v5 06/16] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-11-18  6:56 ` [PATCH v5 07/16] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-11-18  6:57 ` [PATCH v5 08/16] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2019-11-18  6:57 ` [PATCH v5 09/16] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
2019-11-18 16:20   ` Mark Brown
2019-11-19  9:12     ` Vaittinen, Matti
2019-11-18  6:58 ` [PATCH v5 10/16] gpio: devres: Add devm_gpiod_get_parent_array Matti Vaittinen
2019-11-19 14:43   ` Linus Walleij
2019-11-19 17:54     ` Vaittinen, Matti
2019-11-21 14:13       ` Linus Walleij
2019-11-18  6:59 ` [PATCH v5 11/16] docs: driver-model: Add missing managed GPIO array get functions Matti Vaittinen
2019-11-18  6:59 ` [PATCH v5 12/16] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
2019-11-18  7:00 ` [PATCH v5 13/16] rtc: bd70528 add BD71828 support Matti Vaittinen
2019-11-18  7:01 ` [PATCH v5 14/16] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-11-18  9:22   ` Bartosz Golaszewski
2019-11-18  7:03 ` [PATCH v5 15/16] leds: Add common LED binding parsing support to LED class/core Matti Vaittinen
2019-11-18 21:55   ` Jacek Anaszewski
2019-11-19  7:21     ` Vaittinen, Matti
2019-11-19 19:30       ` Jacek Anaszewski
2019-11-20  7:31         ` Vaittinen, Matti
2019-11-19 14:23   ` Vaittinen, Matti
2019-11-18  7:03 ` [PATCH v5 16/16] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen

Reply instructions:

You may reply publically 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=72a1f4c5768b8c08c2669ea01e60d1b614095a43.camel@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dmurphy@ti.com \
    --cc=hkallweit1@gmail.com \
    --cc=hofrat@osadl.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=mazziesaccount@gmail.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=pavel@ucw.cz \
    --cc=phil.edworthy@renesas.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /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

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git