[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141017135441.GR1820@sirena.org.uk>
Date: Fri, 17 Oct 2014 15:54:41 +0200
From: Mark Brown <broonie@...nel.org>
To: Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc: Lee Jones <lee.jones@...aro.org>,
Doug Anderson <dianders@...omium.org>,
Chanwoo Choi <cw00.choi@...sung.com>,
Olof Johansson <olof@...om.net>,
Chris Zhong <zyw@...k-chips.com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Abhilash Kesavan <kesavan.abhilash@...il.com>,
linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v2 5/7] regulator: max77802: Document regulator opmode DT
properties
On Fri, Oct 17, 2014 at 02:39:15PM +0200, Javier Martinez Canillas wrote:
> Just to be sure I understood correctly, are you suggesting something like this?
> ldo1_reg: LDO1 {
> regulator-name = "vdd_1v0";
> regulator-min-microvolt = <1000000>;
> regulator-max-microvolt = <1000000>;
> regulator-state-mem {
> regulator-on-in-suspend;
> regulator-mode = <MAX77802_OPMODE_LP>;
> };
> };
> In other words, extending Chanwoo Choi's original suspend state binding to add
> the regulator-mode property that was present in his v3 [0] but instead trying
> to use the standard REGULATOR_MODE_*, say that each regulator driver should
> define it's own device-specific set of modes and a do the translation to fill
> standard modes in the struct regulation_constraints {initial,disk,mem} mode?
> That way adding new suspend states, will only require changing the generic
> regulator binding but not the regulator driver specific bindings.
Something like that, yes. Not sure if numbers or strings are the best
way of doing the mode but it probably doesn't matter too much now we
have preprocessor support for inclue files.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists