[alsa-devel] [RFC 0/2] soc-dapm or TWL4030: Runtime DAPM ordering problem
peter.ujfalusi at nokia.com
Tue Aug 3 08:15:12 CEST 2010
On Tuesday 03 August 2010 05:56:40 ext Mark Brown wrote:
> > A. When the user configures the capture routing, and starts the capture
> > B. When the user changes the capture routing during active capture
> > (analog to digital, or back).
> It feels like you're focusing in on one specific use case here - there's
> way more active->active transitions that are possible. For example, you
> could switch in bypass or start a second (unrelated) capture stream on
> devices that can support that. I think any change in DAPM needs to be
> motivated in more general terms than you're using here. For
> driver-specific changes this is fine but for changes in the generic code
> we need to think things through more generically.
Sure, I'm pointing these two cases, since I have noticed the problem in these.
But the same thing happens, when one enables the bypass vs during enabled bypass
the routing is changed.
We do have different register write sequences, which means that we could have
different type of pop depending on the current sequence.
In startup (playback/capture/bypass) we most likely have pop from components
powering up, while during active state (and changing the routings) we might need
to deal with the pop coming from components turning off.
As I said, this might be not an issue at all, but the twl4030 codec used to
switch two bits with DAPM_MUX (within the enum, and than with POST_REG event).
Because of the ordering change, in runtime this causes problems, since the
DAPM_MUX's POST_REG comes as the last thing in the sequence.
The patch against soc-dapm.c is my way of asking about this different sequences
on startup vs runtime routing change.
I can fix this problem within the twl4030 codec as well (patch 2), which gives
me satisfying results, so I'm happy if you ack that.
I only need one of the two patch, and my bet goes for the fix within the twl4030
codec driver, but I do wanted to bring up the root cause of this problem
(surfaced with my codec driver).
More information about the Alsa-devel