Status of audio on 3.3 kernel for ARM

[Mark Brown]

On Mon, May 07, 2012 at 09:07:37AM -0600, Daniel Drake wrote:

> When playing sound normally, it appears not to find a meaningful route
> and leaves all of the widgets powered down. This can be seen with cat
> /sys/devices/platform/soc-audio/*5631/dapm_widget (and you can compare
> to 3.0 where various things do get powered up during playback).

Yes, this is the intended behaviour if nothing is connected.

> If you make some tweaks to the mixer controls (even ones that should
> have no net effect) you can sometimes poke DAPM into looking for a
> route again and finding one and powering up the right components, e.g.
> http://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/051686.htm

That link is broken....

> To solve this, I first tried to understand and debug the DAPM logic.
> This is tedious and time consuming, with so many widgets and routes in
> our codec driver there is a lot of recursion and after a few hours I
> still couldn't make any sense of it.

It's just a straightforward DAG of connections from input to output -
nothing too magic.  The routing tables in the drivers are like this:

	{ "Destination", "Control", "Source" },

where Destination and Source are widgets and the optional Control is
either a mixer switch or mux value associated with Destination.  If
you've not found it the debugfs stuff in debugfs/asoc is usually very
helpful in inspecting what DAPM thinks is going on.

> I then tried to simplify our driver, removing practically all routes
> and widgets at the DAPM level and just pre-configuring registers to
> have the right components for audio playback through the speakers
> working. No luck there either - couldn't get any audible output.
> I think this is the right approach though - first remove all the
> dynamic stuff just to have playback working, then re-add the widgets
> and routes one-by-one (based on the codec datasheet which has a nice
> logic diagram) with repeated testing to make sure nothing gets broken.

The fact that you're struggling with even a fixed register write
sequence suggests you might just be missing something like a mute...

> This seems like a hard issue.

It really shouldn't be, it normally isn't.  It's probably worth trying
to upstream your drivers -