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

[Mark Brown]

On 2 Aug 2010, at 08:08, Peter Ujfalusi wrote:

> I'm facing the following problem with the TWL4030 codec:
> The order of DAPM register write order different in case, when I start a capture
> operation after setting up the routing, and when I change the routing during
> active capture.
> This is really visible, when I want to record from the digital microphone
> interface.

> Because of this ordering problem, when during active capture I switch to the
> digital mic from analog path, the codec would enable analog bias (2.2 volts) to
> the digital mic for a moment, and than later it will switch to the correct
> digital mic bias (1.8 volts).

It'd be really helpful in this section if you could've said what the actual problem you see is...

> Since the twl4030 codec needs several bits in different registers to be changed,
> when I change between analog and digital input it is not that obvious how to get
> the correct ordering all the time.
> 
> I have two different ways to fix this:
> A: by reordering how DAPM would handle control changes (patch 1)
> B: by changing TWL4030 internal DAPM widgets (patch 2)

...you even start proposing solutions before describing what they're fixing :)

Just summarising briefly since I can't see a clear problem statement I think what you're saying is that DAPM applies control changes for routing before checking for power up changes but for some TWL4030 routes it would be more convenient to only write the changes for route setup after changing the power state?

I think this is best handled in TWL4030, or possibly with some sort of optional flag in DAPM which TWL4030 and anything else could then use. 

With most things it's safer to implement the route change first - especially in the analogue domain route changes tend to introduce DC offsets so it's safer to set the route prior to powering up so the offset changes don't get amplified. This is also very important when doing DC offset correction, obviously there it's important to measure the offset of the path you're actually trying to run rather than using whatever path was there before.