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

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Tue, Aug 03, 2010 at 09:15:12AM +0300, Peter Ujfalusi wrote:

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

Good, this is the sort of analysis we need to make a change to DAPM
itself.  I don't think it's resonable to say that the active->active
changes are primarily concerned with powerdown pops, though - if you're
making a change where you're adding in a new source then obviously the
powerup of the path is going to be relevant.

I think there's something useful we can do with DAPM here (independantly
of anything in TWL4030), probably involving splitting up the routing
change walk to run power down first and then power up but the current
patch feels like it's going to cause at least as many problems as it
solves.

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

You keep saying "ordering change" but I'm still not clear what you mean
by this?  Are you just talking about the fact that things end up
happening in different orders for the active->active transitions or do
you see some active reordering of things in the code?

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

Honestly, looking at the TWL4030 specific patch it looks like a better
idea anyway regardless of any changes to the core since it's just moving
from the use of an event to pure DAPM widgets which is generally a more
robust approach.  Events generally cause hassle if they're doing much
more than implementing multi-write sequences for turning the widget on
and off.

If you could provide a version of the patch with a standalone changelog
I think I'd ack it.