devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
To: Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
	Laxman Dewangan
	<ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	lrg-l0cyMroinI0@public.gmane.org
Subject: Re: [PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible
Date: Thu, 21 Jun 2012 11:53:41 -1000	[thread overview]
Message-ID: <4FE397E5.1070707@firmworks.com> (raw)
In-Reply-To: <20120621194544.GZ4037-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 2315 bytes --]

On 6/21/2012 9:45 AM, Mark Brown wrote:
> On Thu, Jun 21, 2012 at 05:17:45PM +0000, Arnd Bergmann wrote:
>> On Thursday 21 June 2012, Mark Brown wrote:
>
>>> 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.


Maybe I'm missing something, but in general it's not necessary to update 
old device
trees to support new features.  The trick is to define a new property 
that describes
the new possibility.  Absence of that property implies that the default 
- the thing
that used to happen across the board, before the feature existed - applies.

>>>   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.
>
> Well, nobody does that anyway but even if they were it doesn't help
> non-DT systems at all, nor does it help when we need to go and add new
> properties to every existing device tree using the device.  We've got
> far more architectures don't use DT than do...
>
>>> 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.
>
> How would this work given that we also need to put system specific
> configuration for the same devices into DT?  As Stephen says it doesn't
> seem to match what we're currently doing.
>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


[-- Attachment #1.2: Type: text/html, Size: 4117 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

  parent reply	other threads:[~2012-06-21 21:53 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
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 [this message]
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=4FE397E5.1070707@firmworks.com \
    --to=wmb-d5eqfidgl7eakbo8gow8eq@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lrg-l0cyMroinI0@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.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).