Hi Mark, thanks a lot for your help here. On Tue, May 8, 2012 at 3:27 AM, Mark Brown <broo...@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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel