All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH] ASoC: Add optional pointer to machine audio routes to snd_soc_card
Date: Mon, 20 Dec 2010 12:02:01 +0000	[thread overview]
Message-ID: <20101220120201.GB26706@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <201012201322.49437.peter.ujfalusi@nokia.com>

On Mon, Dec 20, 2010 at 01:22:49PM +0200, Peter Ujfalusi wrote:

> For sure we need to have the card level DAPM map, when we have more than one 
> codec in the system.

That's already possible - this is more a convenience for defining it.

> What I was thinking is more like to move the DAPM map from codec domain up to 
> card level.
> What I mean is, that when you build up your ASoC card, the DAPM map/routes are 
> going to be attached to the card, and not to the codec.

At runtime everyting is treated (or should be treated) as one map - the 

> One thing that might need to be changed in DAPM is how we handle the 
> connected/not connected endpoints.
> Currently if you have DAPM_OUTPUT, and you do not connect it to speaker/HP/line, 
> it is handled like it has some connection.
> In multi comp this might be not what we want.
> Also the treatment of the inputs might need to be changed.

I don't see anything different here with multi-component?  The general
idea is that by default a floating output or input should be treated as
connected.

> Now if you enable the bypass on codec2, it shall not bring up the codec2 bias, 
> since we do not have full route.

This isn't abundantly clear - there may potentially be analogue
interface issues if two devices which aren't connected aren't both
powered up and down together.  Robust system design should avoid these
issues but I'd prefer it if software were conservative and at the very
least always had an option to ensure everything is powered on at once.

> If we do not have the:
> {"codec2 Line in", NULL, "codec1 to line out"},
> in the machine driver, we shall not power the bypass path in codec2, even if the 
> switch is on, since the machine does not specified any connection.

> IMHO this is more logical, than treating non connected OUTPUTs/INPUTs as 
> connected.
> But this is a different issue.

I don't see any relationship between multi-component and the state of
the pins here?  If there's a path through the device the path would be
there even if there's only one device in the system.

  reply	other threads:[~2010-12-20 12:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-17 17:39 [PATCH] ASoC: Add optional pointer to machine audio routes to snd_soc_card Jarkko Nikula
2010-12-17 22:37 ` Mark Brown
2010-12-20  9:24   ` Liam Girdwood
2010-12-20 11:22 ` Peter Ujfalusi
2010-12-20 12:02   ` Mark Brown [this message]
2010-12-21  7:42     ` Peter Ujfalusi
2010-12-21 16:29       ` Mark Brown
2010-12-20 12:17   ` Jarkko Nikula
2010-12-21  7:30     ` Peter Ujfalusi
2010-12-21  8:16       ` Jarkko Nikula

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=20101220120201.GB26706@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=peter.ujfalusi@nokia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.