From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: alsa-devel@alsa-project.org, Samuel Ortiz <sameo@linux.intel.com>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
Misael Lopez Cruz <misael.lopez@ti.com>,
Liam Girdwood <lrg@ti.com>, "Cousson, Benoit" <b-cousson@ti.com>
Subject: Re: [PATCH] ASoC: twl6040: Support for DT
Date: Mon, 14 May 2012 13:11:28 +0100 [thread overview]
Message-ID: <20120514121127.GR31985@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FB0EEAC.6060204@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 1589 bytes --]
On Mon, May 14, 2012 at 02:38:20PM +0300, Peter Ujfalusi wrote:
> The child (or drivers for the functionality) only needs small update for
> compatible_of, and new chip access wrapper.
At the very least anything that's using interrupts through the device
core will also need to know how those have been wired out into the chip
top level, and of course if anything happened to move about in the
register map or there are any changes in available functionality (which
would be unsurprising, perhaps an additional line output or something
for example) those will also need to be dealt with.
Besides, if that's all the function drivers need to look at they can
just look at their parent node instead of looking at the child node,
problem sorted.
> You might be right that the resulting dts section for the chip is just
> represents the current MD stack, but if I want to prepare for the future
> this is the way I think is the best for us.
Again, if I could see how this supported non-trivial reuse I'd be right
with you but I'm just not seeing how this would allow reuse on another
chip without rework of all existing device trees or what it hides about
the chip top level. The code changes to drop the child nodes from the
device tree should be trivial. This in itself seems to me like a clear
sign that the abstraction in the device tree isn't actually providing
useful generalisation of the chip.
I'm just not seeing anything in the device tree that abstracts the chip
top level from the function drivers; if there were then it'd be very
much easier to see a general use for this.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2012-05-14 12:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-08 11:52 [PATCH] ASoC: twl6040: Support for DT Peter Ujfalusi
2012-05-08 12:26 ` Mark Brown
2012-05-08 12:42 ` Peter Ujfalusi
2012-05-08 13:41 ` Mark Brown
2012-05-09 12:01 ` Peter Ujfalusi
2012-05-09 13:35 ` Mark Brown
2012-05-10 12:55 ` Peter Ujfalusi
2012-05-11 14:05 ` Mark Brown
[not found] ` <20120509133511.GQ3955-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-05-11 11:02 ` Cousson, Benoit
2012-05-11 13:08 ` Mark Brown
[not found] ` <20120511130816.GB3960-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-05-11 15:44 ` Cousson, Benoit
2012-05-11 20:34 ` Mark Brown
2012-05-14 11:38 ` Peter Ujfalusi
2012-05-14 12:11 ` Mark Brown [this message]
2012-05-15 8:00 ` Peter Ujfalusi
2012-05-14 15:34 ` Tony Lindgren
2012-05-15 7:41 ` Peter Ujfalusi
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=20120514121127.GR31985@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=b-cousson@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=lrg@ti.com \
--cc=misael.lopez@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=sameo@linux.intel.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 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).