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: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Doug Anderson <dianders@chromium.org>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Olof Johansson <olof@lixom.net>, Chris Zhong <zyw@rock-chips.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: Thu, 09 Oct 2014 23:56:59 +0200	[thread overview]
Message-ID: <543704AB.4030805@collabora.co.uk> (raw)
In-Reply-To: <20141009190107.GY4609@sirena.org.uk>

On 10/09/2014 09:01 PM, Mark Brown wrote:
> On Thu, Oct 09, 2014 at 05:04:35PM +0200, Javier Martinez Canillas wrote:
> 
>> Agree, Mark also pointed out that there is a difference between changing
>> how the regulator will behave on runtime vs changing how the regulator
>> will behave during system suspend. AFAIU from his explanation, the modes
>> defined in consumer.h only applies to the former and conceptually there
>> should be a difference between those two cases even when the Maxim PMIC
>> seems to mix it both in the data-sheet and by using the same field.
> 
> No, that's not accurate at all - you're still not getting the concepts
> of modes or suspend handling in the regulator API.  I really think you
> need to take a step back and try to understand what's currently there
> before trying to make changes here.  We've got a set of operations we
> can use to change the regulator configuration, if you look at the
> existing driver interface you'll see that these are matched with
> equivalent operations for setting the behaviour when in suspend
> (including a set_suspend_mode() operation).  
> 

I tried to say that there is a difference between the need to change
within the kernel a regulator configuration (e.g: change opmode from
normal to low power) when the system is going to enter in suspend state
vs setting a register at probe time that will force the PMIC to change
the regulator to low power mode on suspend without kernel intervention.

> Like I keep saying abstractions are really important to making sure the
> code is maintainable.
> 

Agree, I'll try to come up with a more sensible solution by using the
existing abstractions from the regulator framework.

Best regards,
Javier

  reply	other threads:[~2014-10-09 21:57 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
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 [this message]
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=543704AB.4030805@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