From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Grant Likely" <grant.likely@secretlab.ca>,
linuxppc-dev@ozlabs.org, alsa-devel@alsa-project.org,
liam.girdwood@wolfsonmicro.com, jonsmirl@gmail.com
Subject: Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
Date: Mon, 14 Jul 2008 11:06:34 -0600 [thread overview]
Message-ID: <fa686aa40807141006k402b6a5fq8da1424081a20011@mail.gmail.com> (raw)
In-Reply-To: <20080714134930.GC25448@sirena.org.uk>
On Mon, Jul 14, 2008 at 7:49 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
>> +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
>> +{
>> + struct platform_device *pdev;
>> + int rc;
>> +
>> + /* Only register the device if both the codec and platform have
>> + * been registered */
>> + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
>> + return;
>> +
>> + pr_info("platform<-->codec match achieved; registering machine\n");
>
> So what this does is add an extremely simple machine driver which
> matches up the first DAI on a single codec and platform with no facility
> for setting up any configurable clocking or anything? This is fine in
> so far as it goes but it's going to work for very few systems as it is -
> most codecs will need some additional configuration. This could be
> added later, though.
Yes, that is pretty much exactly what it is. When I wrote this my
goal was just to get something working that had some semblance of
cleanliness. Since it is now looking like something that could get
merged, I'll clean up the documentation describing exactly what it is
and what the limitations are. I fully expect that if others find it
useful then they will need to extend it to extract additional
configuration information out of the device tree.
That being said, I expect this code to be completely rewritten when
ASoC v2 hits mainline. Most of the code is devoted to matching
platforms with codecs. The mechanism will be completely different
when the ASoC layer handles making sure all devices are present before
setting up the machine driver. I expect that some machines can be
handled with some form of generic of-asoc driver, while more complex
ones will need custom code.
> Given this it might be worth renaming it to something less generic and
> perhaps pushing it down into an of directory below the main ASoC
> directory to parallel existing machine drivers. I'm happy with the code
> from an ASoC point of view.
I'm okay with that. How about fsl/mpc5200-of-machine.c for now?
(only the mpc5200 i2s driver uses it at the moment). It can always be
renamed if other folks want to use it for other chips.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2008-07-14 17:06 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-12 8:39 [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers Grant Likely
2008-07-12 8:39 ` [PATCH v2 2/3] ALSA SoC: Add mpc5200-psc I2S driver Grant Likely
2008-07-14 12:10 ` [alsa-devel] " Mark Brown
2008-07-12 8:39 ` [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver Grant Likely
2008-07-12 18:10 ` [alsa-devel] " Mark Brown
2008-07-12 18:14 ` Grant Likely
2008-07-14 11:45 ` Mark Brown
2008-07-18 6:29 ` Grant Likely
2008-07-18 10:39 ` Mark Brown
2008-07-15 7:57 ` dinesh
2008-07-15 10:33 ` Mark Brown
2008-07-15 12:38 ` dinesh
2008-07-15 12:46 ` Mark Brown
2008-07-16 9:05 ` WRITING AN SOC DRIVER WITHOUT DMA dinesh
2008-07-16 10:07 ` [alsa-devel] " Nobin Mathew
2008-07-16 10:13 ` dinesh
2008-07-17 6:03 ` dinesh
2008-07-17 10:56 ` Mark Brown
2008-07-17 11:26 ` Nobin Mathew
2008-07-17 12:05 ` Jon Smirl
2008-07-17 16:02 ` [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver Timur Tabi
2008-07-14 13:49 ` [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers Mark Brown
2008-07-14 14:13 ` Jon Smirl
2008-07-14 15:05 ` Mark Brown
2008-07-14 16:14 ` Timur Tabi
2008-07-14 16:27 ` Grant Likely
2008-07-14 16:53 ` Mark Brown
2008-07-14 17:21 ` Grant Likely
2008-07-14 18:36 ` Mark Brown
2008-07-14 18:40 ` Timur Tabi
2008-07-14 18:49 ` Mark Brown
2008-07-14 18:53 ` Timur Tabi
2008-07-14 22:28 ` Grant Likely
2008-07-14 23:45 ` Jon Smirl
2008-07-15 10:13 ` Mark Brown
2008-07-15 13:08 ` Jon Smirl
2008-07-15 14:04 ` Mark Brown
2008-07-14 15:51 ` Timur Tabi
2008-07-14 17:06 ` Grant Likely [this message]
2008-07-14 17:16 ` Mark Brown
2008-07-14 17:22 ` Grant Likely
2008-07-18 7:17 ` Grant Likely
2008-07-18 10:00 ` Mark Brown
2008-07-18 14:59 ` Timur Tabi
2008-07-14 14:16 ` Anton Vorontsov
2008-07-14 17:11 ` Grant Likely
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=fa686aa40807141006k402b6a5fq8da1424081a20011@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=alsa-devel@alsa-project.org \
--cc=jonsmirl@gmail.com \
--cc=liam.girdwood@wolfsonmicro.com \
--cc=linuxppc-dev@ozlabs.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).