Status of audio on 3.3 kernel for ARM

[Daniel Drake]

Hi Mark, thanks a lot for your help here.

On Tue, May 8, 2012 at 3:27 AM, Mark Brown <broonie at sirena.org.uk> wrote:
>> 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....

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

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

Yeah, I managed to get my head around the routing table format and
spent a good while comparing it to the logic diagram in the codec
specs. Can't see anything wrong with it.

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 I tried to do was understand the code logic in soc-dapm.c and
added various printks to try and understand why it is making the
decisions it is making. I was primarily trying to answer the question
"Why is the DAC not powered up when trying to play a sound?" and I
wasn't able to conclude anything, it just turned into a horrible
printk mess, mostly due to the large amount of routes and widgets we
have.

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

Yes, I think I missed something small like this, and I think it could
be made to work with more time.
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).

>> This seems like a hard issue.
>
> 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.

The sound driver, soc-mmp2, unfortunately is not, and you're right we
should work on that. However, I'm fairly confident the bug we're
facing is constrained to rt5631.c and/or soc-dapm.c.

Thanks for your help!
Daniel