From: Lee Jones <lee.jones@linaro.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>,
Linus Walleij <linus.walleij@linaro.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
linux-arm-kernel@lists.infradead.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org,
Alessandro Rubini <rubini@gnudd.com>,
Linus Walleij <linus.walleij@stericsson.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Deepak Saxena <dsaxena@linaro.org>,
devicetree-discuss@lists.ozlabs.org,
Grant Likely <grant.likely@secretlab.ca>
Subject: Re: linux-next: manual merge of the arm-soc tree with the i2c-embedded tree
Date: Tue, 17 Jul 2012 14:30:01 +0100 [thread overview]
Message-ID: <500568D9.10805@linaro.org> (raw)
In-Reply-To: <20120717130650.GB27595@sirena.org.uk>
On 17/07/12 14:06, Mark Brown wrote:
> On Mon, Jul 16, 2012 at 12:31:08PM +0100, Lee Jones wrote:
>
>> I agree with what you say to some extent, but I believe that it is
>> more important to have a working solution now than to ensure that
>> each bindings are as unique as possible. After any suggestion of
>> consolidation, a move from vendor specific to generically defined
>> Device Tree bindings is trivial. Especially in the current stage
>> where adaptions and definitions are still fluid.
>
>> Obviously some care is taken to ensure the bindings are as generic
>> as possible, but not to the extent that will put the project back
>> some months. Over past few months I have enabled many sub-systems;
>
> It's not just about having generic bindings, it's also about having
> bindings which have some abstraction and hope of reusability. An awful
> lot of bindings are just straight dumps of Linux data structures into
> the device tree which don't make a terribly great deal of sense as
> bindings.
The Device Tree should supply any platform configuration which the
driver needs in order to correctly setup for a particular machine. This
is exactly what the platform_data structure did before, hence is is
reasonable to assume that whatever information resides in that structure
would be required in the Device Tree.
>> however, I think it would have been a fraction of that if we'd gone
>> through the laborious process of immediate forced consolidation. I
>> think it's fine to have platform/vendor specific bindings that work,
>> then come back to unify them once the dust settles.
>
> In many of these cases we'd be better off just not putting things into
> the device tree in the first place, leaving things at the basic "is the
> device there" stuff.
Then what do you do with the platform data?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: linux-next: manual merge of the arm-soc tree with the i2c-embedded tree
Date: Tue, 17 Jul 2012 14:30:01 +0100 [thread overview]
Message-ID: <500568D9.10805@linaro.org> (raw)
In-Reply-To: <20120717130650.GB27595@sirena.org.uk>
On 17/07/12 14:06, Mark Brown wrote:
> On Mon, Jul 16, 2012 at 12:31:08PM +0100, Lee Jones wrote:
>
>> I agree with what you say to some extent, but I believe that it is
>> more important to have a working solution now than to ensure that
>> each bindings are as unique as possible. After any suggestion of
>> consolidation, a move from vendor specific to generically defined
>> Device Tree bindings is trivial. Especially in the current stage
>> where adaptions and definitions are still fluid.
>
>> Obviously some care is taken to ensure the bindings are as generic
>> as possible, but not to the extent that will put the project back
>> some months. Over past few months I have enabled many sub-systems;
>
> It's not just about having generic bindings, it's also about having
> bindings which have some abstraction and hope of reusability. An awful
> lot of bindings are just straight dumps of Linux data structures into
> the device tree which don't make a terribly great deal of sense as
> bindings.
The Device Tree should supply any platform configuration which the
driver needs in order to correctly setup for a particular machine. This
is exactly what the platform_data structure did before, hence is is
reasonable to assume that whatever information resides in that structure
would be required in the Device Tree.
>> however, I think it would have been a fraction of that if we'd gone
>> through the laborious process of immediate forced consolidation. I
>> think it's fine to have platform/vendor specific bindings that work,
>> then come back to unify them once the dust settles.
>
> In many of these cases we'd be better off just not putting things into
> the device tree in the first place, leaving things at the basic "is the
> device there" stuff.
Then what do you do with the platform data?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2012-07-17 13:30 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-10 6:41 linux-next: manual merge of the arm-soc tree with the i2c-embedded tree Stephen Rothwell
2012-07-10 6:41 ` Stephen Rothwell
2012-07-10 6:41 ` Stephen Rothwell
2012-07-10 6:50 ` Stephen Rothwell
2012-07-10 6:50 ` Stephen Rothwell
2012-07-10 6:50 ` Stephen Rothwell
2012-07-10 8:38 ` Wolfram Sang
2012-07-10 8:38 ` Wolfram Sang
2012-07-12 13:12 ` Wolfram Sang
2012-07-12 13:12 ` Wolfram Sang
2012-07-12 15:54 ` Arnd Bergmann
2012-07-12 15:54 ` Arnd Bergmann
2012-07-13 11:03 ` Lee Jones
2012-07-13 11:03 ` Lee Jones
[not found] ` <20120712131231.GH2194-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-14 21:34 ` Linus Walleij
2012-07-14 21:34 ` Linus Walleij
2012-07-14 21:34 ` Linus Walleij
2012-07-16 10:17 ` Wolfram Sang
2012-07-16 10:17 ` Wolfram Sang
2012-07-16 11:31 ` Lee Jones
2012-07-16 11:31 ` Lee Jones
2012-07-16 13:00 ` Wolfram Sang
2012-07-16 13:00 ` Wolfram Sang
2012-07-16 13:55 ` Lee Jones
2012-07-16 13:55 ` Lee Jones
2012-07-17 13:06 ` Mark Brown
2012-07-17 13:06 ` Mark Brown
2012-07-17 13:30 ` Lee Jones [this message]
2012-07-17 13:30 ` Lee Jones
2012-07-17 13:35 ` Mark Brown
2012-07-17 13:35 ` Mark Brown
2012-07-17 14:02 ` Lee Jones
2012-07-17 14:02 ` Lee Jones
2012-07-17 14:22 ` Mark Brown
2012-07-17 14:22 ` Mark Brown
2012-07-17 14:52 ` Lee Jones
2012-07-17 14:52 ` Lee Jones
[not found] ` <50057C1A.80606-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-07-17 15:20 ` Mark Brown
2012-07-17 15:20 ` Mark Brown
2012-07-17 15:20 ` Mark Brown
2012-07-18 5:33 ` Shawn Guo
2012-07-18 5:33 ` Shawn Guo
2012-07-18 5:33 ` Shawn Guo
2012-07-18 9:59 ` Mark Brown
2012-07-18 9:59 ` Mark Brown
2012-07-18 10:29 ` Lee Jones
2012-07-18 10:29 ` Lee Jones
2012-07-18 10:33 ` Mark Brown
2012-07-18 10:33 ` Mark Brown
2012-07-18 10:43 ` Lee Jones
2012-07-18 10:43 ` Lee Jones
2012-07-18 7:35 ` Lee Jones
2012-07-18 7:35 ` Lee Jones
2012-07-18 11:12 ` Mark Brown
2012-07-18 11:12 ` Mark Brown
2012-07-18 11:24 ` Lee Jones
2012-07-18 11:24 ` Lee Jones
2012-07-16 11:37 ` Linus Walleij
2012-07-16 11:37 ` Linus Walleij
2012-07-16 12:35 ` Wolfram Sang
2012-07-16 12:35 ` Wolfram Sang
[not found] ` <20120716123550.GE17435-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-16 19:45 ` Linus Walleij
2012-07-16 19:45 ` Linus Walleij
2012-07-16 19:45 ` Linus Walleij
[not found] ` <CACRpkdaMB-n7XYcxE8QtAm-WrGc2DR0krfTjQZCbvOL1HYep1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-07-16 20:04 ` Chris Ball
2012-07-16 20:04 ` Chris Ball
2012-07-16 20:04 ` Chris Ball
2012-07-17 13:10 ` Mark Brown
2012-07-17 13:10 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2012-07-19 5:28 Stephen Rothwell
2012-07-19 5:28 ` Stephen Rothwell
2012-07-19 5:28 ` Stephen Rothwell
2012-09-13 6:41 Stephen Rothwell
2012-09-13 6:41 ` Stephen Rothwell
2012-09-13 6:41 ` Stephen Rothwell
2012-09-13 7:09 ` Uwe Kleine-König
2012-09-13 7:09 ` Uwe Kleine-König
2012-11-15 5:27 Stephen Rothwell
2012-11-15 5:27 ` Stephen Rothwell
2012-11-15 5:27 ` Stephen Rothwell
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=500568D9.10805@linaro.org \
--to=lee.jones@linaro.org \
--cc=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dsaxena@linaro.org \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=olof@lixom.net \
--cc=rubini@gnudd.com \
--cc=sfr@canb.auug.org.au \
--cc=swarren@wwwdotorg.org \
--cc=w.sang@pengutronix.de \
/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.