public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Mark Brown <broonie@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Olof Johansson <olof@lixom.net>, Chris Zhong <zyw@rock-chips.com>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Abhilash Kesavan <kesavan.abhilash@gmail.com>,
	linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support
Date: Wed, 08 Oct 2014 18:00:47 +0200	[thread overview]
Message-ID: <54355FAF.6060708@collabora.co.uk> (raw)
In-Reply-To: <20141008143439.GB4609@sirena.org.uk>

On 10/08/2014 04:34 PM, Mark Brown wrote:
> On Wed, Oct 08, 2014 at 03:44:05PM +0200, Javier Martinez Canillas wrote:
> 
>> +- regulator-initial-mode: initial regulator operating mode. One of following:
>> +	<1>: REGULATOR_MODE_FAST    - Regulator can handle fast changes.
>> +	<2>: REGULATOR_MODE_NORMAL  - Normal regulator power supply mode.
>> +	<4>: REGULATOR_MODE_IDLE    - Regulator runs in a more efficient mode.
>> +	<8>: REGULATOR_MODE_STANDBY - Regulator runs in the most efficient mode.
>> +  modes are defined in the dt-bindings/regulator/regulator.h header and can be
>> +  used in device tree sources files. If no mode is defined, then the OS will not
>> +  manage the operating mode and the HW default values will be used instead.
> 
> ...and as previously and repeatedly discussed this still gives the user
> no way of telling if or how these modes might correspond to what the
> chip is capable of doing.  This really needs addressing rather than
> ignoring, for example by not trying to define the modes in generic
> bindings.
> 

Drivers could add custom per-device DT properties. That is how it was
solved in the ChromeOS kernel. There is a regulator-op-mode DT property
whose value is just a magic number with the value that has to be written
in the OPMODE field of the control register of each regulator and that
is made on the driver probe.

Another option is to not document the standard modes in the generic
regulator binding but instead on each device DT binding doc. That way
each device binding can define what are the semantics of the standard
modes and how correspond to the real modes in the chip.

That way the regulator-initial-mode could still be generic and parsed
by the core instead of each driver implementing their own custom parsing.

Best regards,
Javier

  reply	other threads:[~2014-10-08 16:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08 13:44 [PATCH 0/5] regulator: Add support for initial operating modes Javier Martinez Canillas
2014-10-08 13:44 ` [PATCH 1/5] regulator: of: Add regulator-initial-mode parse support Javier Martinez Canillas
2014-10-08 14:25   ` Mark Brown
2014-10-08 14:38     ` Javier Martinez Canillas
2014-10-08 15:12       ` Mark Brown
2014-10-08 16:29         ` Javier Martinez Canillas
2014-10-09 10:27           ` Mark Rutland
2014-10-09 15:19             ` Javier Martinez Canillas
2014-10-10 13:17               ` Mark Rutland
2014-10-08 13:44 ` [PATCH 2/5] regulator: dt-bindings: Add DT include for constants Javier Martinez Canillas
2014-10-08 13:44 ` [PATCH 3/5] regulator: dt-bindings: Add regulator-initial-mode support Javier Martinez Canillas
2014-10-08 14:34   ` Mark Brown
2014-10-08 16:00     ` Javier Martinez Canillas [this message]
2014-10-09  8:45   ` Krzysztof Kozlowski
2014-10-09 15:04     ` Javier Martinez Canillas
2014-10-09 19:01       ` Mark Brown
2014-10-09 21:56         ` Javier Martinez Canillas
2014-10-08 13:44 ` [PATCH 4/5] regulator: max77802: Add regulator operating mode set support Javier Martinez Canillas
2014-10-08 14:36   ` Mark Brown
2014-10-08 16:01     ` Javier Martinez Canillas
2014-10-08 13:44 ` [PATCH 5/5] ARM: dts: Add initial regulator mode on exynos Peach boards Javier Martinez Canillas
2014-10-08 14:56   ` Mark Brown
2014-10-08 16:25     ` Javier Martinez Canillas

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=54355FAF.6060708@collabora.co.uk \
    --to=javier.martinez@collabora.co.uk \
    --cc=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=k.kozlowski@samsung.com \
    --cc=kesavan.abhilash@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=zyw@rock-chips.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