From: Arnd Bergmann <arnd@arndb.de>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Laxman Dewangan <ldewangan@nvidia.com>,
lrg@ti.com, rob.herring@calxeda.com, grant.likely@secretlab.ca,
linus.walleij@linaro.org, lee.jones@linaro.org,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible
Date: Thu, 21 Jun 2012 17:17:45 +0000 [thread overview]
Message-ID: <201206211717.46142.arnd@arndb.de> (raw)
In-Reply-To: <20120621161459.GY4037@opensource.wolfsonmicro.com>
On Thursday 21 June 2012, Mark Brown wrote:
> Show Details
> On Thu, Jun 21, 2012 at 02:50:35PM +0000, Arnd Bergmann wrote:
>
> > It seems that the drivers that are changed to use this could also try to
> > describe the individual regulators completely, by moving the contents
> > of e.g. ab8500_regulator_info into the device tree, but having the string
> > identifier with an in-kernel table makes sense when there is only one
> > such table.
>
> I'm not that big a fan of moving all the data into device tree as it
> means that you need even more parsing code and you need to update the
> device trees for every board out there every time you want to add
> support for a new feature which doesn't seem like a win. Right now with
> the DT kept in the kernel it's not so bad but if we ever do start
> distributing it separately it becomes more of an issue.
Right. It's certainly a trade-off. If a company makes 100 SoCs that
all have similar-but-different regulators, then it should be clear
win to have the driver be very abstract and fed with DT data for
configuragtion.
> I'm also not sure if the tooling works well for allowing people to
> include standard DTs for chips and add new properties to nodes for the
> board specific configuration, though I think I've seen a few things
> which suggested that was dealt with reasonably well.
It should never be necessary to add board-specific properties in the
nodes that describe the SoC specific bits. What I was referring to
is just moving the data that currently resides in the regulator
driver into DT.
Arnd
next prev parent reply other threads:[~2012-06-21 17:20 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 12:23 [PATCH V3 0/3] regulator: dt: add policy to match regulator with prop "regulator-compatible" Laxman Dewangan
2012-06-20 12:23 ` [PATCH V3 1/3] ARM: dts: db8500: add property "regulator-compatible" regulator node Laxman Dewangan
2012-06-20 18:48 ` Stephen Warren
2012-06-20 12:23 ` [PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible Laxman Dewangan
2012-06-20 19:24 ` Arnd Bergmann
2012-06-20 19:46 ` Mark Brown
2012-06-20 19:51 ` Stephen Warren
2012-06-20 23:37 ` Mark Brown
2012-06-20 20:40 ` Arnd Bergmann
2012-06-20 21:01 ` Stephen Warren
2012-06-20 23:35 ` Mark Brown
2012-06-21 14:50 ` Arnd Bergmann
2012-06-21 16:14 ` Mark Brown
2012-06-21 17:17 ` Arnd Bergmann [this message]
2012-06-21 17:31 ` Stephen Warren
2012-06-21 21:03 ` Arnd Bergmann
2012-06-21 22:52 ` Mark Brown
2012-06-21 19:45 ` Mark Brown
[not found] ` <4FE397E5.1070707@firmworks.com>
2012-06-21 22:36 ` Mark Brown
2012-06-20 23:15 ` Mark Brown
2012-06-22 6:13 ` Thierry Reding
2012-06-22 8:42 ` Mark Brown
2012-06-22 8:59 ` Thierry Reding
2012-06-22 9:12 ` Mark Brown
2012-06-26 9:02 ` Laxman Dewangan
2012-06-26 9:12 ` Mark Brown
2012-06-26 10:13 ` Lee Jones
2012-07-04 23:48 ` Linus Walleij
2012-07-05 7:16 ` Lee Jones
2012-06-20 12:23 ` [PATCH V3 3/3] regulator: dt: add policy to have property "regulator-compatible" Laxman Dewangan
2012-06-20 18:52 ` Stephen Warren
2012-07-03 19:25 ` Mark Brown
2012-07-04 7:03 ` Laxman Dewangan
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=201206211717.46142.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=ldewangan@nvidia.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.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
Powered by JetHome