From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "broonie@kernel.org" <broonie@kernel.org>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
"sboyd@kernel.org" <sboyd@kernel.org>,
"dmurphy@ti.com" <dmurphy@ti.com>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
"linux-rtc@vger.kernel.org" <linux-rtc@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>,
"pavel@ucw.cz" <pavel@ucw.cz>,
"phil.edworthy@renesas.com" <phil.edworthy@renesas.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"lee.jones@linaro.org" <lee.jones@linaro.org>
Subject: Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282 regulator bindings
Date: Wed, 4 Dec 2019 13:13:08 +0000 [thread overview]
Message-ID: <6f7b96c71bd1257b0b218a092f8aca7f32ef5468.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <20191204124717.GR1998@sirena.org.uk>
On Wed, 2019-12-04 at 12:47 +0000, Mark Brown wrote:
> On Mon, Dec 02, 2019 at 02:02:41PM +0000, Vaittinen, Matti wrote:
> > On Mon, 2019-12-02 at 13:11 +0000, Mark Brown wrote:
> > > 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
>
> The general idea is that we set the suspend state during the
> process of suspending rather than in advance - that way when the
> hardware doesn't understand different types of suspsend things
> work fine.
Ok. So voltage for the specific suspend state is set just before going
to suspend - when the target suspend state is already selected. Makes
sense. Thanks.
> > 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.
>
> I don't understand the save and restore of mode?
I was thinking that there is some 'cahced suspend target state' in
framework. This get mode is pseudo-code for getting the suspend mode
from framework - "restore mode" is returning back the "original mode"
after voltages for all modes are set. But please ignore this - I think
I captured your message already :)
> If setting the
> suspend configuration affects the runtime state then the hardware
> doesn't support suspend configuration.
No, it does not. I probably explained this badly.
>
> > > 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
>
> Regulators that have to be controlled en masse aren't really
> supported by the API, it only understands regulators that are
> individually controllable.
Thanks. This was the piece of information I wanted and assumed. Thus
the patch 12 did introduce new in-kernel APIs - but as I said, we don't
have any in-tree socs using BD71828 RUN0, ..., RUN3 states for now so
I'll drop the patch 12 and leave only the basic support for
individually controllable regulators.
> > 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.
>
> So you could also just create a group consisting of a single
> regulator? That would be fine for the API.
I think I once again explained myself badly. There can be only one
group with 4 RUN states selected by combination of 2 GPIO lines. bucks
1,2,6 and 7 can each either be assigned into this one group or
controlled individually via I2C. But I doubt assigning only one of the
bucks in this group is the typical use-case. What we would need would
really be the 'en-masse' control - either via GPIO or I2C - but I don't
want to suggest any framework expansion as I don't have proper in-tree
use-case for this as of now :) So I'll forget this for now (and thanks
for all the help!) and drop the patch 12 from series. I'll see if I can
send updated series tomorrow - or latest early next week :)
Br,
Matti Vaittinen
next prev parent reply other threads:[~2019-12-04 13:13 UTC|newest]
Thread overview: 51+ 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
2019-12-04 12:47 ` Mark Brown
2019-12-04 13:13 ` Vaittinen, Matti [this message]
2019-12-04 14:14 ` Mark Brown
2019-12-10 10:39 ` Vaittinen, Matti
2019-12-10 11:14 ` Vaittinen, Matti
2019-12-10 12:11 ` Mark Brown
2019-12-10 12:41 ` Vaittinen, Matti
2019-12-10 12:45 ` Mark Brown
2019-12-10 13:07 ` Vaittinen, Matti
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-12-10 13:24 ` Alexandre Belloni
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 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=6f7b96c71bd1257b0b218a092f8aca7f32ef5468.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
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).