From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Per Forlin <per.forlin@stericsson.com>,
niklas.hernaeus@linaro.org, linux-mmc@vger.kernel.org,
cjb@laptop.org, Lee Jones <lee.jones@linaro.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/5] MMC: mmci: Provide bindings for Device Tree
Date: Sat, 17 Mar 2012 21:26:53 +0000 [thread overview]
Message-ID: <20120317212652.GD3315@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201203161236.36088.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
On Fri, Mar 16, 2012 at 12:36:35PM +0000, Arnd Bergmann wrote:
> On Friday 16 March 2012, Linus Walleij wrote:
> > On Thu, Mar 15, 2012 at 9:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > But I guess you're after modelling the levelshifter as a regulator?
> > Basically the level shifter is a separate device has two voltage
> > inputs A and B (from other regulators) that is controlled by a
> > simple GPIO to select voltage A or B to drive the signals to
> > the card.
> > That could probably be modelled as a regulator with two
> > volategs for sure, but then we should maybe create a more
> > generic "struct level_shifter_regulator" (or whatever) for the
> > concept as a whole.
> Ok, thanks for the explanation.
I'm not sure I'd bother defining a special regulator type for this if it
is done using regulators - given that it's likely to just be a GPIO
rather than a specific driver I'm not sure it's worth worrying about how
exactly the hardware is implemented.
> > Let's page Mark about what to do with levelshifters and whether
> > they are regulators of sorts in his book.
> It does sound appealing, especially because this one could be
> done completely generically by defining a regulator that has
> a bunch of other regulators as well as a set of gpio lines as
> inputs and one output that can be used in other devices. We
> would probably only use this one together with device tree then.
It seems sensible to me - probably the existing gpio-regulator driver
can do the job, though it's not unreasonable to expect that we'll want
to support switching between variable voltage supplies at some point.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] MMC: mmci: Provide bindings for Device Tree
Date: Sat, 17 Mar 2012 21:26:53 +0000 [thread overview]
Message-ID: <20120317212652.GD3315@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201203161236.36088.arnd@arndb.de>
On Fri, Mar 16, 2012 at 12:36:35PM +0000, Arnd Bergmann wrote:
> On Friday 16 March 2012, Linus Walleij wrote:
> > On Thu, Mar 15, 2012 at 9:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > But I guess you're after modelling the levelshifter as a regulator?
> > Basically the level shifter is a separate device has two voltage
> > inputs A and B (from other regulators) that is controlled by a
> > simple GPIO to select voltage A or B to drive the signals to
> > the card.
> > That could probably be modelled as a regulator with two
> > volategs for sure, but then we should maybe create a more
> > generic "struct level_shifter_regulator" (or whatever) for the
> > concept as a whole.
> Ok, thanks for the explanation.
I'm not sure I'd bother defining a special regulator type for this if it
is done using regulators - given that it's likely to just be a GPIO
rather than a specific driver I'm not sure it's worth worrying about how
exactly the hardware is implemented.
> > Let's page Mark about what to do with levelshifters and whether
> > they are regulators of sorts in his book.
> It does sound appealing, especially because this one could be
> done completely generically by defining a regulator that has
> a bunch of other regulators as well as a set of gpio lines as
> inputs and one output that can be used in other devices. We
> would probably only use this one together with device tree then.
It seems sensible to me - probably the existing gpio-regulator driver
can do the job, though it's not unreasonable to expect that we'll want
to support switching between variable voltage supplies at some point.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120317/67f5e0c6/attachment.sig>
next prev parent reply other threads:[~2012-03-17 21:26 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-14 14:19 [PATCH 0/5] MMC: mmci: Provide bindings for Device Tree Lee Jones
2012-03-14 14:19 ` Lee Jones
2012-03-14 14:19 ` [PATCH 1/5] MMC: mmci: Seperate ux500 variants from generic code Lee Jones
2012-03-14 14:19 ` Lee Jones
2012-03-14 14:20 ` [PATCH 2/5] MMC: mmci: Seperate ARM " Lee Jones
2012-03-14 14:20 ` Lee Jones
2012-03-15 17:32 ` Russell King - ARM Linux
2012-03-15 17:32 ` Russell King - ARM Linux
2012-03-15 17:36 ` Lee Jones
2012-03-15 17:36 ` Lee Jones
2012-03-15 17:37 ` Russell King - ARM Linux
2012-03-15 17:37 ` Russell King - ARM Linux
2012-03-15 17:46 ` Arnd Bergmann
2012-03-15 17:46 ` Arnd Bergmann
2012-03-15 17:54 ` Russell King - ARM Linux
2012-03-15 17:54 ` Russell King - ARM Linux
2012-03-15 18:23 ` Arnd Bergmann
2012-03-15 18:23 ` Arnd Bergmann
2012-03-15 20:30 ` Russell King - ARM Linux
2012-03-15 20:30 ` Russell King - ARM Linux
2012-03-16 12:48 ` Arnd Bergmann
2012-03-16 12:48 ` Arnd Bergmann
2012-03-17 21:30 ` Mark Brown
2012-03-17 21:30 ` Mark Brown
2012-03-15 17:38 ` Lee Jones
2012-03-15 17:38 ` Lee Jones
2012-03-14 14:20 ` [PATCH 3/5] MMC: mmci: Add generic Device Tree bindings to mmci core code Lee Jones
2012-03-14 14:20 ` Lee Jones
2012-03-15 15:12 ` Per Forlin
2012-03-15 15:12 ` Per Forlin
2012-03-15 15:25 ` Lee Jones
2012-03-15 15:25 ` Lee Jones
2012-03-14 14:20 ` [PATCH 4/5] MMC: mmci: Enable Device Tree support for ux500 variants Lee Jones
2012-03-14 14:20 ` Lee Jones
2012-03-14 14:20 ` [PATCH 5/5] MMC: mmci: Add required documentation for Device Tree bindings Lee Jones
2012-03-14 14:20 ` Lee Jones
2012-03-15 17:35 ` Russell King - ARM Linux
2012-03-15 17:35 ` Russell King - ARM Linux
2012-03-15 17:49 ` Arnd Bergmann
2012-03-15 17:49 ` Arnd Bergmann
2012-03-15 17:58 ` Russell King - ARM Linux
2012-03-15 17:58 ` Russell King - ARM Linux
2012-03-15 17:53 ` Arnd Bergmann
2012-03-15 17:53 ` Arnd Bergmann
2012-03-15 17:59 ` Russell King - ARM Linux
2012-03-15 17:59 ` Russell King - ARM Linux
2012-03-15 15:06 ` [PATCH 0/5] MMC: mmci: Provide bindings for Device Tree Per Forlin
2012-03-15 15:06 ` Per Forlin
2012-03-15 15:25 ` Lee Jones
2012-03-15 15:25 ` Lee Jones
2012-03-15 15:32 ` Arnd Bergmann
2012-03-15 15:32 ` Arnd Bergmann
2012-03-15 15:44 ` Lee Jones
2012-03-15 15:44 ` Lee Jones
2012-03-15 19:12 ` Per Forlin
2012-03-15 19:12 ` Per Forlin
2012-03-15 20:36 ` Russell King - ARM Linux
2012-03-15 20:36 ` Russell King - ARM Linux
2012-03-15 20:58 ` Arnd Bergmann
2012-03-15 20:58 ` Arnd Bergmann
2012-03-16 9:01 ` Linus Walleij
2012-03-16 9:01 ` Linus Walleij
2012-03-16 12:36 ` Arnd Bergmann
2012-03-16 12:36 ` Arnd Bergmann
2012-03-17 21:26 ` Mark Brown [this message]
2012-03-17 21:26 ` Mark Brown
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=20120317212652.GD3315@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=arnd@arndb.de \
--cc=cjb@laptop.org \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=niklas.hernaeus@linaro.org \
--cc=per.forlin@stericsson.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.