From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Shawn Guo <shawn.guo@freescale.com>
Cc: alsa-devel@alsa-project.org, devicetree-discuss@lists.ozlabs.org,
s.hauer@pengutronix.de, Grant Likely <grant.likely@secretlab.ca>,
u.kleine-koenig@pengutronix.de,
Dong Aisheng <b29396@freescale.com>,
lrg@ti.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V2 03/10] ASoc: mxs: add mxs-sgtl5000 machine driver
Date: Sat, 16 Jul 2011 00:17:13 +0900 [thread overview]
Message-ID: <20110715151706.GD11154@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20110715151104.GE1840@S2100-06.ap.freescale.net>
On Fri, Jul 15, 2011 at 11:11:06PM +0800, Shawn Guo wrote:
> Currently, soc-core requires machine driver register snd_soc_dai_link
> with proper codec, cpu_dai and platform device name coded, so that it
> can match/bind dai link. It works for existing non-dt devices probe,
> because they can have static device id assigned by platform code to
> map the actual hardware instance.
There's existing device tree code for PowerPC which seems to figure this
out by doing a DT lookup in the machine driver which appears to be sane
enough. If we can't look up a struct device via the device tree we'd
seem to have a fairly serious problem as struct devices are how we talk
about devices at runtime in general.
To be honest I've not paid too much attention to the device tree code
people are currently using since discussion around it has always
involved repeatedly going over all the reasons why we actually need
machine drivers and that gets tedious after a while.
> Actually, I found matching cpu_dai using name does not scale in imx-ssi
> case even for non-dt probe. imx provides some flexibility on the
> connection between codec and ssi. With proper audmux configuration,
> codec can be connected to either ssi.0 or ssi.1 for given board design.
> That said even for given board, .cpu_dai_name can be dynamic. This is
> something the current soc-core matching/binding approach hates to see.
This isn't a scalability thing and it's not related to binding, it's
because the AUXMUX isn't properly represented as a driver. It probably
wants to be moved over to use the soc-dsp stuff Liam's doing at the
minute. Currently we don't tell the core about the AUDMUX at all so
it's unreasonable to expect it to do anything except a static route.
prev parent reply other threads:[~2011-07-15 15:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1310483085-31442-1-git-send-email-b29396@freescale.com>
[not found] ` <1310483085-31442-4-git-send-email-b29396@freescale.com>
[not found] ` <1310483085-31442-4-git-send-email-b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2011-07-15 15:11 ` [PATCH V2 03/10] ASoc: mxs: add mxs-sgtl5000 machine driver Shawn Guo
2011-07-15 15:17 ` Mark Brown [this message]
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=20110715151706.GD11154@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=b29396@freescale.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lrg@ti.com \
--cc=s.hauer@pengutronix.de \
--cc=shawn.guo@freescale.com \
--cc=u.kleine-koenig@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 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).