devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] regulator: Add coupled regulator
Date: Thu, 21 Jan 2016 16:46:49 +0100	[thread overview]
Message-ID: <20160121154649.GE3997@lukather> (raw)
In-Reply-To: <20160118162538.GH6588@sirena.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

Hi,

On Mon, Jan 18, 2016 at 04:25:38PM +0000, Mark Brown wrote:
> > >   - When you come to consider it from an hardware point of view, the
> > >     device usually have a single pin that powers it. It's the board
> > >     designer that chose to route that pin to multiple regulators, so
> > >     it's really the board that is wired that way, and putting that
> > >     code in the consumer drivers would be an abstraction leak imho.
> 
> > That's a good point. Perhaps the regulator core needs to be able to 
> > parse the list and return the single ptr to the virtual regulator.
> 
> Exactly, if we don't want to represent the combination directly.  For
> most uses it's probably OK but I can see us in a situation where we
> might want to do things like only use one of the regulators in low load
> situations where we might want to attach properties to the merge of the
> two regulators rather than just referencing them both.  I'm not sure
> that's realistic though or that we wouldn't just be working that use
> case out dynamically at runtime.
> 
> I'm ambivalent on which way is better, it does complicate the
> implementation to support doing this as lists and while it makes the DT
> more elegant I'm not clear that it's worth the effort especially when it
> comes to constraint combining.  But perhaps the implementation turns out
> to be simpler than I would anticiapte.

I guess a separate driver would make it easier to deal with cases like
the one you suggested (shutting down when the load is going to be
lower). I don't see how we could have a good DT representation of that
if we're going to use lists.

Anyway, I'm fine with both approaches, just let me know what you
prefer.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-01-21 15:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-12 13:37 [PATCH v2 0/2] regulator: Add support for parallel regulators Maxime Ripard
2016-01-12 13:37 ` [PATCH v2 1/2] regulator: Add coupled regulator Maxime Ripard
2016-01-12 14:31   ` Rob Herring
2016-01-15  8:57     ` Maxime Ripard
2016-01-17  0:04       ` Rob Herring
2016-01-18 16:25         ` Mark Brown
2016-01-21 15:46           ` Maxime Ripard [this message]
2016-01-21 16:28             ` Mark Brown
     [not found]               ` <20160121162802.GL6588-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-02-05 14:33                 ` Maxime Ripard
2016-02-05 15:32                   ` Mark Brown
     [not found]                     ` <20160205153258.GW4455-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-11-07 15:47                       ` Maxime Ripard
2016-11-11 16:46                         ` Mark Brown
     [not found] ` <1452605842-9317-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2016-01-12 13:37   ` [PATCH v2 2/2] ARM: sunxi: chip: Add Wifi chip Maxime Ripard

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=20160121154649.GE3997@lukather \
    --to=maxime.ripard@free-electrons.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=wens@csie.org \
    /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).