alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Liam Girdwood <lrg@ti.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] ASoC: core: Add support for DAI driver DAI widgets.
Date: Wed, 7 Mar 2012 20:37:23 +0000	[thread overview]
Message-ID: <20120307203722.GL3107@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1331120862-16161-2-git-send-email-lrg@ti.com>


[-- Attachment #1.1: Type: text/plain, Size: 2249 bytes --]

On Wed, Mar 07, 2012 at 11:47:42AM +0000, Liam Girdwood wrote:

> Automatically create DAI widgets for DAI drivers. This allows us to connect
> CPU DAIs into the DAPM graph. The widgets use the DAI driver dev name with
> a "Playback" or "Capture" suffix.

So what this is doing is the above which is really about synthesising a
name for streams where the driver didn't provide one.  This isn't
specific to CPU DAIs, it'll apply just as well to CODEC DAIs that don't
specify a per stream name for whatever reason.  

> Also add a snd_soc_dai member to snd_soc_widget so that we dont have to
> use the widget private data.

If we're going to do that I think we should just drop the private data
field, this is exactly the sort of stuff it was added for.  Currently
it's only used by DAIs and regulator supplies.

> +#define NAME_SIZE	32

32 bytes is enough for everyone!  :P  Actually it should be so no real
problem.

>  	if (dai->driver->playback.stream_name) {
> -		template.id = snd_soc_dapm_dai;
>  		template.name = dai->driver->playback.stream_name;
>  		template.sname = dai->driver->playback.stream_name;
> +	} else {
> +		snprintf(name, NAME_SIZE, "%s %s", dev_name(dai->dev), "Playback");
> +		template.name = name;
> +		template.sname = name;
> +	}

Isn't this going to get complicated to use when building up the DAPM
routes?  The device is going to need to know its own dev_name() to
supply a table of routes which would mean you'd have to dynamically
create the routing table (or just specify a name and skip the whole
thing I guess).  

Could we not just use plain old "Playback" and "Capture" here?  We could
then use the name_prefix mechanism which we've got to support multiple
CODECs with the CPU side stuff as well, that will then take care of the
DAPM routes in the same way it does for the CODECs - it'd allow them to
use simple data tables with no dev_name in them which seems like a win.
We'd want to supply a default name_prefix for CPU DAIs but that seems
OK.

This would also ensure that this mechanism works for multi-CODEC systems
which I've got a horrible feeling are going to run into trouble at some
point soon for the same reason you're adding in the dev_names here.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2012-03-07 20:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07 11:47 [PATCH] ASoC: core: Add platform DAI widget mapping Liam Girdwood
2012-03-07 11:47 ` [PATCH] ASoC: core: Add support for DAI driver DAI widgets Liam Girdwood
2012-03-07 20:37   ` Mark Brown [this message]
2012-03-08 12:07     ` Liam Girdwood
2012-03-08 13:21       ` Mark Brown
2012-03-07 19:52 ` [PATCH] ASoC: core: Add platform DAI widget mapping 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=20120307203722.GL3107@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@ti.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).