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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
