I spent quite a bit of time yesterday evening tweaking w/ printk statements before realizing that the mxc_spi for the audio was not being initialized. In the end, I think it was just one line of code that got everything loaded and working along w/ setting the right Kernel config options. I just got the LITEKIT and am new to Linux Kernel, so excuse me if this is obvious and/or old news, but I just wanted to share my experiences.
Enable Drivers->Sound->ALSA
Enable Drivers->SPI
Enable Drivers->SPI->CSPI2, otherwise the PMIC spi driver doesn't get loaded
Enable Drivers->MXC->PMIC->{ALL OPTIONS}
Enable Drivers->MXC->DAM
Enable Drivers->Sound->{MXC Audio Driver somewhere}
In the mxc_init_board function (in arch/arm/mach-mx3/mx31lite.c), I added the line:
spi_init_board_info(mxc_spi_board_info, ARRAY_SIZE(mxc_spi_board_info));
and then somewhere above that had to create the mxc_spi_board_info structure. This structure was copied verbatim out of the mx31ads.c file from the original (unpatched-for-LITE LTIB kernel)
All this is off of memory, so names and files may be slightly off. I can post the actual code and structure if anyone needs.
So w/ that, dmesg shows detected Alsa card, and I was able to do
aplay /usr/share/sounds/Front_Right.wav
It only came out of one ear in mono, but after running alsamixer I was able to get it out of both ears in mono.
Does anyone know how to get stereo sound working in alsa or how to display what is supported? I'm hoping its just some option I need to enable that the driver already supports b/c I saw traces of "stereo" all over the driver source code.
madplay gives an error saying could not find /dev/dsp, but I'm guessing thats a quickie to fix.
While I'm posting, I may as well ask if anyone knows a solution to the USB_CLK error b/c I think thats the next thing I am going to tackle. About 10% of the time (it seems to only be when I have recently recompiled the kernel), boot stops after the line reporting something about bad USB_CLK, should be equal to 60MHz. Funny thing is that it always says this (whether boot succeeds or not), and USB still works (when boot succeeds) in spite of the error. Also the source code returns success (I'm sure the patches added this as a fix) even though the error exists. Could it be a coincidence that boot hangs right after this line just w/ no error indicating so? Anyway, if anyone can share any extra info on this boot lockup, let me know.
While I'm posting... I have the 12.1" LogicPD LCD working flawlessly - if anyone is interested in the structure, let me know. Hell, why doesn't everybody post all 100% working structures for the LogicPD LCDs. If theres a reasonable response, I may update Daniels patches to add LCD support and maybe a menuconfig option to compile in support and choose the appropriate screen.