Greetings: Well, it took quite a bit longer than I anticipated, but I've completely re-written the audio driver for the McASP, DSP-side/user-space EDMA driver, user-space AIC33 driver. Unfortunately, since most of the code is on the DSP side and the ARM side code only draws on POSIX user-space calls, our company has decided to not release the code GPL. I may be able to release specific information under NDA or similar arrangement -- contact me personally and I'll discuss it with our department heads.
I can, however, give a run-down of the areas that I had trouble with, things to watch out for, and features: Features: * DSP-based implementation with full duplex stereo 44.1KHz load 7.5 ~ 8.5 percent on DM6446 running on emulator (may be able to improve performance). Total ARM-side load for simple loop-back < 0.1% on DM6446 * TDM support for multiple AIC33 * Mixed EDMA & interrupt driven implementation allows predictable start/stop/restart behavior * Automatic zero spin when transmit buffer starves, receive automatically throws away data when receive buffer full * Buffers can be purged (emptied) while running - useful for receive when you don't want stale data in the buffers * Non-blocking (small waits only) implementation to prevent hang-ups and deadlocks on ARM and DSP side * Completely stand-alone from other DSP technologies (other than DSP/BIOS) and can be piggy-backed alongside CodecEngine images * Supports all McASP sample sizes (only tested 8 & 16 so far). * Supports sample rates of 4,8,11.25,16,22.5,32,44.1,48 KHz (this can be tweaked further to allow double rate, but will use more resources) * Uses small ping-pong buffers in faster IRAM with flexible fragment buffers allocated by user in contiguous memory (either by CMEM or my own /dev/mem + mmap wrapper). * User selectable channel interleaving/de-interleaving of both transmit and receive (i.e. A1 B1 A2 B2 -> A1 A2 B1 B2 and vice versa) * User selectable transmit buffer zero-fill * Multiple command channels for multi-threaded applications * Tested with both MV 4.0.1 kernel and latest GIT head version Post-mortem: One thing that I found particularly difficult was the McASP + EDMA behavior. When I ran my EDMA code from the ARM side without an emulator present the ping-pong transfers as spec'd in the EDMA manual ran just fine, but when I moved the code over to the DSP-side with an emulator present to load the DSP, the EDMA would not only instantly go to an error condition (SER bits set), but would often get stuck and not be able to clear the SER bits even after the McASP was disabled. This required a reboot of the board and the tedious process halting the ARM in U-boot, booting the DSP from L2, halting the DSP, loading the DSP, then starting the ARM. I burned an awful amount of time checking and rechecking thinking that it was an error in my code, but I was following all the tech specs exactly and the code did work on the ARM side. Finally I just decided to move to a hybrid approach and deal with the HWI overhead. The decision really payed off in the stability of the implementation since now I can start/stop the McASP and HWI at will and always return to a predictable state. It may seem obvious, but another thing to watch out for when packing multiple samples in one DRR/DXR move is endian issues... my first test code case produced swapped channels, in the multiple AIC33 case, swapped channels and swapped chips! This can be taken care of with some clever EDMA param ram tweaking. Sorry that I can't contribute more to the solution for you guys at the moment other than this information. Regards, David DAVID A. KONDRAD Software Design Engineer On-Q/Legrand Telephone (800) 321-2343 x311 www.onqlegrand.com _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
