On 01/20/2010 07:23 AM, Alex Stewart wrote:
> On Tue, Jan 19, 2010 at 10:16 PM, Ned Forrester <nforrester@...> wrote:
>> On 01/19/2010 01:03 PM, Alex Stewart wrote:
>>> Hi all,
>>> Im developing a ADC driver that leverages the McBSP on the overo water
>>> board. I've gotten to the point where I can happily read in data and it
>>> looks correct when plotted. So far I've just been using one buffer in the
>>> kernel and using the standard DMA api to buffer into it. I've run into a
>>> couple of problems:
>>> 1) I am obviously limited in the size of buffer I can allocate in kernel
>>> space. This is easily over come by allocating more than one buffer,
>>> I am not exactly sure how to leverage this. My first attempt was to set
>> up a
>>> work que that churned through a link list of buffers, kicking of a DMA
>>> transfer as the previous one finished. The problem with this is the McBSP
>>> I'm using (#3) only has a 128 word deep fifo, which seems to not be deep
>>> enough, when I plot the data I see a discontinuity at the transition
>>> buffers. Reading the TRM I see I probably should be chaining multiple
>>> channels together to lower the latency, but I'm still seeing the
>>> between buffers. Someone familiar with this, how much latency is there
>>> between one dma transfer and the next in a chained configuration? The
>>> thing I can think of is the THRSH1 register is set to the default (0)
>>> I think may be causing the DMA engine to trip with every element instead
>>> filling the fifo some to allow the switch between buffers to happen.
>>> leads to 2nd problem.
>> I don't know anything about OMAP or OE (I used the Connex, PXA255, and
>> buildroot), so don't ask me about specifics or examples. However....
>> On the PXA255, I have to receive 11Mbit/sec continuous data on the SPI
>> port. This fundamentally requires Linux to be a slave to the external
>> hardware, but there is not any slave support in the SPI core code for
>> the simple reason that slaves often need to respond instantly to master
>> requests (e.g. master clocks out a register address and expects the
>> register value to follow in the next immediately clocked word).
>> However, limited slave operation is possible in the case where the next
>> action of the slave is completely predictable (and there is only one
>> device on the SPI bus). A single A/D converter can be such a device.
>> In my case, I had to substantially re-write the master driver to allow
>> it to use chained DMA and external clocks (and also, in my case,
>> read-without-write, so that DMA time is not wasted loading unused null
>> TX data). Using the chained DMAs (DMA descriptors in PXA terminology)
>> cured the gaps that you refer to, which are caused by not servicing the
>> RX FIFO soon enough after the interrupt following a DMA buffer full.
>> The interrupt latency on the PXA is typically 200us, but I measured as
>> much as 600us at some times; with a 16word, 32bit FIFO, at 11Mbit/s the
>> FIFO fills in only 50us.
>> I had to modify the master driver, and I wrote my own protocol driver
>> (which passes a stream of messages with attached buffers to be chained,
>> and passes the latest received buffer to user space in response to
>> "read"). I did not have to change any aspect of the SPI core. There is
>> no need for the core to be aware that it is really operating as a
>> (limited) slave. It simply thinks it is passing many messages to the
>> master driver to read data, and does not need to know that these are
>> being returned in real (buffered) time.
>> The original master driver, pxa2xx_spi.c, was constructed to handle one
>> transfer at a time (an SPI message consists of one or more transfers).
>> The hardest part was breaking the driver functions in two, so that the
>> front end queues incoming messages/transfers to the chain of DMAs, and
>> the backend matches the completed buffers back to the messages they came
>> from for return to the protocol driver. My code is a complete mess and
>> not really suitable as an example, because it tries to retain all
>> original general-purpose functionality of the driver, while layering the
>> DMA chaining and read-without-transmit on top. I probably should have
>> used the existing driver only as a model, and written a stand-alone,
>> single-purpose driver for my task.
>> How fast does your data come? If your data rate is less than
>> 500kBit/sec, and if the OMAP has a similar or larger FIFO, you should
>> not have to go to the trouble of chained DMAs.
>>> 2) Setting THRSH1 to anything but 0, causes my system to hang and never
>>> return (seems like the McBSP never returns data).
>> Well it is critical to make the buffer work correctly before you try
>> anything else. If you don't understand how the driver is using the
>> parameters, then you will have to read the driver documentation (if any)
>> and/or its code.
>>> So the root question of all this, is what is the best way to "stream" DMA
>>> data from something like a McBSP? Should a work que posting buffers and
>>> kicking of transfers generally have low enough latency? Or is something
>>> the DMA chain API needed?
>> Ned Forrester nforrester@...
>> Oceanographic Systems Lab 508-289-2226
>> Applied Ocean Physics and Engineering Dept.
>> Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA
> Hey Ned,
> Thanks for all the very helpful comments. You thoughts are more or less the
> conclusions I came to yesterday. The McBSP in question only has a 128 word
> deep fifo. However my data rates are in the audio ranges, ie as low as
> ~60Khz -- up to 100KHz, which means worst case my fifo fills in 1.28mS. This
> seems more than slow enough (I'd hope) to allow the interrupt to service. I
> think I'm inherently missing something. If I try and capture 1024 words into
> a buffer, I get a "correct looking" capture. The problem comes when I try to
> switch out the buffer for a different buffer... IE capture 1024 words, be
> pushing them to user space while a different buffer is off catching the next
> 1024. From what you said about your data rates, and since my FIFO is bigger
> it seems like I should be able to not dive into the hassle of DMA chains.
> I'll dive into reading the code of the McBSP driver since there seems to be
> no documentation.
The original pxa2xx_spi.c driver was written by Stephen Street for
stereo (or maybe 5.1) audio A/D and D/A work. His application is
though it does not look like there has been any activity there for 4-5
Obviously Stephen found the one-transfer-at-a-time model, with an
interrupt per transfer, to be satisfactory on a PXA255 (or PXA270, I
have forgotten which he used).
Ned Forrester nforrester@...
Oceanographic Systems Lab 508-289-2226
Applied Ocean Physics and Engineering Dept.
Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA