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
next prev parent 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 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.