From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 1/2] ARM:Tegra: Device Tree Support: Initialize the audio card from the device tree.
Date: Tue, 14 Jun 2011 09:42:11 -0600 [thread overview]
Message-ID: <20110614154211.GA1839@ponder.secretlab.ca> (raw)
In-Reply-To: <20110602213656.GB10532@n2100.arm.linux.org.uk>
On Thu, Jun 02, 2011 at 10:36:56PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 02, 2011 at 10:04:45AM -0600, Grant Likely wrote:
> > Right now we can't do dynamic registration for on-chip devices in a
> > lot of cases because we don't have the infrastructure to hook up the
> > associated struct clks.
>
> I've been wondering about this, and I don't see it as a blocking problem
> as you seem to be.
>
> I assume platform devices have stable names when they're created from
> the device tree? If yes, there's no problem having the DT start to
> describe the SoC specific devices _today_ - all that the clk API using
> clkdev requires is a stable device name.
Yes, the name is stable, but the name isn't the same as what board
support code currently uses for statically registered
platform_devices, and when I started on this work my goal has been to
have as little impact on existing platform support code. I certainly
didn't want two sets of clock registrations, one with the names that
statically allocated platform devices use and one with the DT
generated names.
One solution would have been to add a "linux,devname" property or
something similar to each device node, but one of the things I'm very
careful about is to strongly avoid encoding Linux specific
implementation details into the DT. History has shown that internal
details are subject to change over time, so there is less chance of
breaking a DT platform if the description is focused on the HW. The
name Linux needs to hook up {clocks,regulators,etc} to a device very
much falls into this category.
That said, I stepped back and took another look at the problem after
receiving your email, and I've been looking at it all wrong. I did
actually had a solution that matched up static device registrations
to DT nodes (of_platform_prepare()), but it was complex and ugly so I
wasn't very excited about it.
However, I've got a patch now that solves the problem in a much nicer
way. If Linux needs specific devices to have specific names, then it
can pass in a lookup table that matches DT nodes to device names,
which is considerably simpler and it leaves the platform setup code in
control over how devices get instantiated. I'll post the patches today
or tomorrow.
So, basically, all my problems on obtaining clocks are now completely
gone. :-)
Ultimately, this is a short-term solution that allows devices to get
described in the DT without having to implement clock mappings at the
same time. When clock mappings also get moved to the device tree, the
need for the lookup table simply goes away.
g.
next prev parent reply other threads:[~2011-06-14 15:42 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-27 20:56 [RFC 0/2] ARM: Tegra: Device Tree: Audio John Bonesio
[not found] ` <20110527205706.21000.34832.stgit@riker>
2011-05-27 21:05 ` [RFC 1/2] ARM:Tegra: Device Tree Support: Initialize the audio card from the device tree Grant Likely
2011-05-28 1:28 ` Mark Brown
2011-06-01 7:07 ` Barry Song
2011-06-01 16:47 ` Grant Likely
2011-06-02 9:07 ` Barry Song
2011-06-02 16:04 ` Grant Likely
2011-06-02 16:21 ` Barry Song
2011-06-02 21:43 ` Russell King - ARM Linux
2011-06-03 2:32 ` Barry Song
2011-06-03 6:20 ` Russell King - ARM Linux
2011-06-02 21:36 ` Russell King - ARM Linux
2011-06-03 1:19 ` Barry Song
2011-06-07 3:44 ` Barry Song
2011-06-14 15:42 ` Grant Likely [this message]
[not found] ` <20110527205721.21000.78599.stgit@riker>
2011-05-27 21:06 ` [RFC 2/2] ARM:Tegra: Device Tree Support: Initialize audio card gpio's " Grant Likely
2011-05-28 1:24 ` Mark Brown
2011-05-30 3:11 ` Olof Johansson
2011-05-30 3:38 ` Mark Brown
2011-05-30 6:11 ` Grant Likely
2011-05-30 6:18 ` Mitch Bradley
2011-05-30 6:22 ` Grant Likely
2011-05-30 7:01 ` Mark Brown
2011-05-30 16:22 ` Grant Likely
2011-05-30 18:54 ` Segher Boessenkool
2011-05-30 19:20 ` Grant Likely
2011-05-30 20:53 ` Mitch Bradley
2011-05-31 17:55 ` Stephen Warren
2011-05-31 18:42 ` Mitch Bradley
2011-06-01 15:59 ` Stephen Warren
2011-06-01 16:18 ` Mark Brown
2011-06-02 15:40 ` Grant Likely
2011-06-01 21:32 ` Mitch Bradley
2011-06-03 21:24 ` Stephen Warren
2011-06-04 0:25 ` Mitch Bradley
2011-06-02 14:59 ` Grant Likely
2011-06-02 15:40 ` Grant Likely
2011-06-28 21:39 ` Grant Likely
2011-05-30 23:27 ` Benjamin Herrenschmidt
2011-05-30 23:49 ` Olof Johansson
2011-05-31 0:58 ` Segher Boessenkool
2011-05-31 10:24 ` Mark Brown
2011-05-30 7:10 ` Mark Brown
2011-05-30 23:26 ` Benjamin Herrenschmidt
2011-05-31 10:03 ` Mark Brown
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=20110614154211.GA1839@ponder.secretlab.ca \
--to=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.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).