devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	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 00:35:08 +0100	[thread overview]
Message-ID: <20120620233507.GC4037@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FE23A1B.2000809@wwwdotorg.org>

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

On Wed, Jun 20, 2012 at 03:01:15PM -0600, Stephen Warren wrote:
> On 06/20/2012 02:40 PM, Arnd Bergmann wrote:

> > For a "compatible" property, I would expect two objects that have
> > the same register-level interface but are responsible for different
> > physical objects to have the same "compatible" values, but here
> > you specifically need distinct "regulator-compatible" values.

> I'd originally suggested "regulator-id" instead of
> "regulator-compatible" in order to avoid any association with the
> pre-existing "compatible" property. Mark didn't like that, although I
> don't think I quite understood why.

Like I said we already have names (and we have IDs inside the API as
well) and it also seems better to make the "which thing is this?"
property have the same name as the more generic "which thing is this?"
property.  I did mention the fact that drivers could read additional
properties to further identify the regulator if they were so moved.

Ideally we'd just be able to have either named nodes directly in the
parent or be able to have arrays function as a hash, really this is
trying to simulate a hash.

> The problem is that dtc has no named constants. Using raw integers
> instead of names would make the .dts file rather unreadable. The issue
> is much more accute for regulators than say GPIOs or IRQs because
> there's likely no relative order to the set of regulators defined by the
> documentation, unlike for GPIOs/IRQs where the integer (often) is the
> object's primary ID.

Well, there are actually a lot of chips which do provide useful indexes
- for example the wm831x devices just have a bunch of DCDCs and a bunch
of LDOs which can usefully be referred to as DCDCn or LDOn.  They will
hopefully not need to use this interface.  It's just that there's also a
large class of devices we need to cater for which don't have any such
regularity in their register map, this biding
mechanism is for them.

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

  reply	other threads:[~2012-06-20 23:35 UTC|newest]

Thread overview: 34+ 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 [this message]
2012-06-21 14:50             ` Arnd Bergmann
2012-06-21 16:14               ` Mark Brown
2012-06-21 17:17                 ` Arnd Bergmann
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]                     ` <20120621194544.GZ4037-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-06-21 21:53                       ` Mitch Bradley
2012-06-21 22:36                         ` Mark Brown
2012-06-20 23:15         ` Mark Brown
     [not found]       ` <20120620194609.GA4037-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
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=20120620233507.GC4037@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=arnd@arndb.de \
    --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;
as well as URLs for NNTP newsgroup(s).