Hi and thanks for any information in advance,
I'm using a beaglebone to process video and flush pixel data to serial LED drivers through SPI (TLC5951). My plan is to use the virtual frame buffer "example" that is part of the linux kernel which will act as an interface between mplayer (or other video application) and my driver. My issue though, is that the lines need to update once every 200us worst-case with about 4k of data. I've done the math, and the high-level numbers suggest it 's possible, 48MHz gives me plenty of time, more if I can use both ports simultaneously.
My first problem is that I have a 3.2.21 kernel with the Xenomai/iPipe patches working properly but this version of the kernel does not have DMA support with the McSPI driver, the spi subsytem becomes unresponsive when a transfer large enough to warrant DMA is requested. I modified the McSPI driver to always use PIO, but this will likely be a problem when I need to start decoding video on the same system.
My second problem is that even when the spi subsystem is only using PIO mode, requesting transfers via a real-time task is very unstable, I've tried to guard it using spi_async (which is "guaranteed" not to sleep and safe to use in interrupt handlers) and a mutex that is unlocked by the complete callback, but I usually only get fewer than 10 transfers before the SPI subsystem becomes unresponsive and I need to reboot.
Both of these problems make me consider using portions of the starterware code to make a bare-bones application-specific driver to bang the dma and spi registers manually, but I don't have a lot of experience developing in the kernel and I don't know where to start with code that assumes there isn't already an operating system running. Is this approach feasible or should I go down a different road? Or if there's something like this already out there that would be fantastic too ;)
-Jon
