Re: [RFC 0/2] soc-dapm or TWL4030: Runtime DAPM ordering problem

[Peter Ujfalusi <peter.ujfalusi@nokia.com>]

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). 


Thanks,
Péter