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

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

On Tuesday 03 August 2010 11:39:44 ext Mark Brown wrote:
> 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.

I tend to agree. The patch for the core is quite dramatic change, and it can 
introduce other types of problems.
But... It would make the actual register write sequence consistent in all cases.
 
> > 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?

Yes, I mean that things end up happening in different order. The DAPM power 
sequence is always the same, but combined that with the writes not coming from 
the DAPM powering, than the sequence is different.

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

Agreed.

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

I have sent the patch separately against the twl4030 codec.

-- 
Péter