From: Timur Tabi <timur@freescale.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: alsa-devel@alsa-project.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
kumar.gala@freescale.com, broonie@opensource.wolfsonmicro.com,
linuxppc-dev@ozlabs.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Date: Wed, 28 Apr 2010 08:35:30 -0500 [thread overview]
Message-ID: <u2xed82fe3e1004280635vaeb792d2xf86996cac299ba2b@mail.gmail.com> (raw)
In-Reply-To: <q2xfa686aa41004272237ld1ffc08fhebb55ff84b51d1c2@mail.gmail.com>
On Wed, Apr 28, 2010 at 12:37 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> Why not? Just have the ssi driver probe routine register the fabric
> device based on the existence of the codec-handle property. It is the
> best way to go about things with the data that you've got available,
> and it is no big deal. The relevant fabric driver can then bind
> against that. You should probably also stuff the ssi device node
> pointer into the fabric device of_node pointer.
And then where do I put the board-specific initialization code that's
currently in the fabric driver? The programming information for that
initialization is not in the device tree.
It sounds to me like you're saying I should take all the code from the
fabric driver and shove it into the SSI driver, just so that I can
avoid instantiating a platform driver.
Keep in mind that asoc likes to have a different struct device for the
fabric driver and the SSI nodes, so I would need to manually create a
struct device for the fabric device anyway.
>> I don't know when I would ever do this. The two SSI devices are completely independent. Why would I bind them together into one "device"?
>
> If there is no use case for binding them together, then you're right.
> The current binding is probably just fine. I cannot comment on
> whether or not it will be used that way by platform designers.
Although the 8610 has two SSI devices, the reference board we ship
only has one wired up. I have a prototype board in the lab that has
both wired up, but even then, I don't think I can get the two SSIs
synchronized in any meaningful fashion. Mark suggested a technique,
but even if I could get that to work, the driver code would need to be
rewritten to handle two SSI devices in concert. In short, it might be
theoretically possible, but I'm not going to try to make it work.
> Linux struct device registrations are cheap, and every struct device
> has a device_node pointer available. It is totally fine to have both
> the ssi device and the fabric device point to the same device node if
> that helps solve your problem of finding references to the right
> things in each driver. (Just as long as only one of them is an
> of_platform driver).
But I already have it set up like that. The SSI driver is an OF
driver, and the fabric driver is a platform driver. I might be able
to move some code from the fabric driver into the SSI driver to make
it the fabric driver less obnoxious about scanning the device tree.
--
Timur Tabi
Linux kernel developer at Freescale
next prev parent reply other threads:[~2010-04-28 13:36 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-26 20:49 [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers Timur Tabi
2010-04-27 6:36 ` Benjamin Herrenschmidt
2010-04-27 8:07 ` Liam Girdwood
2010-04-27 14:52 ` Timur Tabi
2010-04-27 15:20 ` Liam Girdwood
2010-04-27 15:28 ` Timur Tabi
2010-04-27 15:56 ` Timur Tabi
2010-04-27 16:41 ` Liam Girdwood
2010-04-27 18:32 ` Timur Tabi
2010-04-27 19:15 ` Grant Likely
2010-04-27 20:04 ` Timur Tabi
2010-04-27 20:38 ` Mark Brown
2010-04-28 4:19 ` Benjamin Herrenschmidt
2010-04-28 4:18 ` Benjamin Herrenschmidt
2010-04-30 21:46 ` Timur Tabi
2010-04-30 22:04 ` Timur Tabi
2010-04-27 20:24 ` Grant Likely
2010-04-27 20:46 ` Timur Tabi
2010-04-27 20:59 ` Mark Brown
2010-04-27 21:03 ` Timur Tabi
2010-04-27 21:11 ` Mark Brown
2010-04-28 4:25 ` Benjamin Herrenschmidt
2010-04-28 13:00 ` Mark Brown
2010-04-29 0:42 ` Benjamin Herrenschmidt
2010-04-28 5:37 ` Grant Likely
2010-04-28 13:35 ` Timur Tabi [this message]
2010-04-28 13:57 ` Grant Likely
2010-04-28 16:20 ` Timur Tabi
2010-04-28 16:47 ` Grant Likely
2010-04-28 17:27 ` Timur Tabi
2010-04-27 22:29 ` Mark Brown
2010-04-28 2:31 ` Grant Likely
2010-04-28 9:16 ` Mark Brown
2010-04-28 4:10 ` Benjamin Herrenschmidt
2010-04-28 12:07 ` Mark Brown
2010-04-29 0:36 ` Benjamin Herrenschmidt
2010-04-29 3:43 ` Grant Likely
2010-04-28 13:19 ` Timur Tabi
2010-04-28 13:39 ` Mark Brown
2010-04-27 9:54 ` Mark Brown
2010-04-27 10:09 ` Benjamin Herrenschmidt
2010-04-27 10:41 ` Mark Brown
2010-04-27 20:27 ` Grant Likely
2010-04-27 20:50 ` Mark Brown
2010-04-27 20:53 ` Timur Tabi
2010-04-28 12:49 ` Liam Girdwood
2010-04-28 20:35 ` Timur Tabi
2010-04-28 21:58 ` Grant Likely
2010-04-28 22:13 ` Timur Tabi
[not found] ` <r2oed82fe3e1004281513k23b54b56v7904a4a34750c90b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-04-28 22:23 ` [alsa-devel] " Grant Likely
2010-04-29 0:52 ` Benjamin Herrenschmidt
2010-04-29 3:44 ` Grant Likely
2010-04-29 0:50 ` Benjamin Herrenschmidt
2010-04-27 19:21 ` Grant Likely
2010-04-27 20:05 ` Timur Tabi
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=u2xed82fe3e1004280635vaeb792d2xf86996cac299ba2b@mail.gmail.com \
--to=timur@freescale.com \
--cc=alsa-devel@alsa-project.org \
--cc=benh@kernel.crashing.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=grant.likely@secretlab.ca \
--cc=kumar.gala@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=lrg@slimlogic.co.uk \
/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).