Status of audio on 3.3 kernel for ARM

[Mark Brown]

On Tue, May 08, 2012 at 08:02:02AM -0600, Daniel Drake wrote:
> On Tue, May 8, 2012 at 3:27 AM, Mark Brown <broonie at sirena.org.uk> wrote:

> > That link is broken....

> Sorry, here's the right one:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/051686.html

Ah, right.  If you CC maintainers you're much more likely to get a
response!  I'm not sure what the "(cached)" bits are in your write
logs...

> I did look in debugfs without really learning anything on why things
> are not being powered up, but based on your advice perhaps we should
> spend more time there as a next step.

What you should see there in the dapm subdirectories is a node for each
widget listing all the connected inputs and outputs.  You can normally
just start at one end of the path (eg, headphone out) then walk back
or forward until you find something that's not got an input you're
expecting and look at the driver to figure out what the options are.

> However, this missing mute is different from the main problem we're
> facing here, because (before going down the "strip out all the routes"
> route, we can get working audio after making "meaningless" changes in
> alsamixer, as described in the alsa-devel thread).

It's probable there's a bug in the driver, something like the register
bitfield for a control being specified wrongly.  Another possibility is
that the register default values that are being provided don't
accurately reflect the actual register defaults, that can trigger issues
where things work if you rewrite the control value you thought you had
originally.

I'd be very surprised if there were something this basic wrong in DAPM
itself in a release, essentially all embedded audio relies on it
heavily so someone tends to notice if anything important breaks.

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

> The driver that we're having trouble with is upstream already -
> soc/codecs/rt5631.c.

So, looking at the changlogs that was just a vendor driver thrown over
the wall which has had no followup since then and has no mainline users.
I'd not be entirely surprised if there were issues, the quality of
mainline testing for vendor drivers can vary quite a bit.  I've added
the original authors...