Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 1/7] ASoC: Fix cards getting stuck in a powered state.
Date: Thu, 28 Apr 2011 21:47:12 +0200	[thread overview]
Message-ID: <4DB9C440.7090201@metafoo.de> (raw)
In-Reply-To: <20110428191533.GA16837@opensource.wolfsonmicro.com>

On 04/28/2011 09:15 PM, Mark Brown wrote:
> On Thu, Apr 28, 2011 at 06:46:07PM +0200, Lars-Peter Clausen wrote:
> 
>> This problem can arise if the card contains at least one widget-less DAPM
>> context.
> 
> No, this is getting silly.  We need to just make DAPM mandatory for all
> contexts - they get essentially no testing from people doing active
> development and the special casing they require is just a constant
> source of fragility.

I've thought about that. But I didn't wanted to break existing codec drivers.
As far as I can see there are at least 4 drivers in mainline code which do not
register any DAPM widgets, but provide set_bias_level callbacks:
wm8804.c, uda134x.c, stac9766.c, cq93vc.c

These would have to be updated.

> 
> For CODECs we can easily add some widgets for them based on the DAI, for
> cards we should just shove a random widget in there with the name of the
> card, it doesn't need to be wired up to anything.

For codecs we can use SND_SOC_DAPM_AIF_{IN,OUT} widgets.

I don't understand you comment regarding cards though. It does not make sense
to add a random widget which is not connected anywhere, since it either would
have no effect or keep the card power up.
The problem was not due to widget-less contexts per se, but due to the special
treatment they received regarding their power state.
As written in the commit message the power state was kept across multiple
dapm_power_widget calls while for normal context the power state was cleared at
the beginning of dapm_power_widget. So once a widget-less context was powered
it could not (easily) be powered down again, which as a result kept the whole
card powered.

If we drop that special casing, we can handle widget-less context just fine,
with the assumption that they don't need to be powered.

- Lars

  reply	other threads:[~2011-04-28 19:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-28 16:46 [PATCH 1/7] ASoC: Fix cards getting stuck in a powered state Lars-Peter Clausen
2011-04-28 16:46 ` [PATCH 2/7] ASoC: DAPM: Pass snd_dapm_soc_update as parameter Lars-Peter Clausen
2011-04-28 19:40   ` Mark Brown
2011-04-28 20:39     ` Lars-Peter Clausen
2011-04-28 20:58       ` Mark Brown
2011-04-28 21:24         ` Lars-Peter Clausen
2011-04-28 21:48           ` Mark Brown
2011-04-28 22:04             ` Lars-Peter Clausen
2011-04-28 22:18               ` Mark Brown
2011-04-28 22:23                 ` Mark Brown
2011-04-28 22:34                   ` Lars-Peter Clausen
2011-04-28 22:48                     ` Mark Brown
2011-04-28 22:58                       ` Lars-Peter Clausen
2011-04-28 22:59                         ` Mark Brown
2011-04-28 16:46 ` [PATCH 3/7] ASoC: Drop unused parameter from dapm_seq_run Lars-Peter Clausen
2011-04-28 16:46 ` [PATCH 4/7] ASoC: Pass snd_soc_card instead of snd_soc_dapm_context were appropriate Lars-Peter Clausen
2011-04-28 19:47   ` Mark Brown
2011-04-28 20:13     ` Mark Brown
2011-04-28 16:46 ` [PATCH 5/7] ASoC: Move DAPM debugfs directory creation to snd_soc_dapm_debugfs_init Lars-Peter Clausen
2011-04-28 16:46 ` [PATCH 6/7] ASoC: Move DAPM widget debugfs entry creation to snd_soc_dapm_new_widgets Lars-Peter Clausen
2011-04-28 16:46 ` [PATCH 7/7] ASoC: Instantiate all DAPM widgets at once Lars-Peter Clausen
2011-04-28 20:07   ` Mark Brown
2011-04-28 20:25     ` Lars-Peter Clausen
2011-04-28 21:18       ` Mark Brown
2011-04-28 19:15 ` [PATCH 1/7] ASoC: Fix cards getting stuck in a powered state Mark Brown
2011-04-28 19:47   ` Lars-Peter Clausen [this message]
2011-04-28 19:52     ` Mark Brown
2011-04-28 23:14       ` Lars-Peter Clausen
2011-04-28 23:17         ` Mark Brown
2011-04-28 23:40           ` Lars-Peter Clausen

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=4DB9C440.7090201@metafoo.de \
    --to=lars@metafoo.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --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