On Thu, Aug 26, 2010 at 14:06, Adam Rosenberg wrote:
Thank you for the reply. I emailed Barry Song on July 30th to request some help moving to the new ASoC standards but received no response.
developers shouldnt be e-mailed directly ... it isnt uncommon for them to simply be punted. this is why we have mailing lists and forums.
I began writing this driver on the Blackfin uClinux 2009 release and based it on the AD1836 and AD1938 drivers. I am now using the Blackfin SVN trunk and have found that the driver model was changed to ASoC. It is not apparent how I would create a driver that supports two chips off of the same SPORT using the ASoC framework.
The best I could do was use the same SPORT driver that the ASoC code uses (bf5xx-sport.c) so that I was at least up-to-date in that area. I had to modify that driver so that it would support the secondary data lines of the SPORT. I found that the driver did not function well in 2D DMA mode so I have to keep my period size below 64kb. There is also a problem with starting Rx and Tx that causes the DMA data to be placed into the SPORT multichannel window incorrectly. I added a function to the SPORT driver yesterday that can work around this problem by starting both Rx and Tx as normal then stopping the SPORT and restarting it like this:
int sport_start_both(struct sport_device *sport) { sport_tx_start(sport); msleep(1); // is this needed? sport_rx_start(sport); msleep(1); // is this needed? sport_stop(sport); msleep(1); // is this needed? sport_start(sport); return 0; } EXPORT_SYMBOL(sport_start_both);
This ensures that the data from the DMA buffer is properly loaded into the SPORT multichannel window for both the Rx and Tx data lines. If it is not done this way it seems that one of them is always being filled incorrectly. This may have sometime to do with the fact that I have to enable the secondary data lines but there is no clear explanation for why that would have an effect.
I have not entered any constraints into the driver because there really should be no need. The driver just copies whatever PCM data that is provided directly to the DMA buffer. It seems that the problem occurs because the location to copy to is based on the pos suggested by the callback function. I am still finding it difficult to tell how ALSA decides there is an underrun or overrun. I am definitely trying to read or write the pcm data fast enough but it seems as though I get these errors anyway.
Questions: 1. How do I implement an ASoC-style driver that supports multiple chips when they are connected to the same SPORT but use different SPI chip selects? 2. How do I define the proper buffer/period size constraints or should I ignore the suggested position during copy operations and just keep track of the position within the DMA buffer myself? 3. Can you suggest a good way to debug underrun/overrun problems?
i dont really know ASoC/SPORTs, so we'd have to get someone to look into it -mike