Hardware: Beaglebone Black, latest revision
OS: Debian Jessie 8.5, Linux kernel 3.8.13-bone73
Custom 'cape' for hardware expansion
We're using a dual-channel DMA strategy to retrieve 20-bit samples from an LTC2378 SPI ADC at 312.5 Ksps. The ADC's BUSY output is inverted and delivered to pin D14 on the AM3358, where the pin function XDMA_EVENT_INTR1 is used to trigger a DMA channel that writes the McSPI0 TX0 register, starting each SPI operation. When the associated RX0 register is full, the second DMA channel, SPIREVT0 for McSPI0, is used to copy the RX0 register into a circular RAM buffer.
This code is working well, but it initially failed because the McSPI0 SPIREVT0 event (EDMA channel 17) was not enabled after a call to edma_start(). A subsequent call to edma_resume() got it enabled. edma_start() did not return an error code. Note that the TX DMA channel works as expected with just a call to edma_start().
You should know that in our kernel spi-omap2-mcspi is compiled as a loadable module and then not loaded. It doesn't look like the kernel's mcspi code is designed to support continuous high speed SPI transfers. Our kernel module manages the McSPI hardware directly but does of course use the kernel's EDMA code. Additionally, our kernel sets the necessary pinmux configuration so no device tree overlay is required either. I'm sharing this information for completeness although I doubt it has a bearing on the issue at hand.
I suspect that the need to call edma_resume() is indicative of a knowledge gap on my part. I'm hoping someone can fill me in on what I'm missing, or give me a strong pointer in the right direction. I'm concerned my lack of understanding has resulted in as-yet-discovered defects in our code.
PS - We plan to move to a custom AM3358 board, and the latest TI kernel and OS release (SDK), but it will be a bit before this migration can happen.
Thanks,
Steve
