> > *I think that link refers to SPI slave nodes and not SPI slave mode.* >
Yeah it's not always clear what these people are talking about. For instance, peopel talking about using SPI Master mode using the inccorect acronyms (SIMO, SOMI ) etc. Master device -> MISO, MOSI Slave device -> SIMO, SOMI Is how I understand it's supposed to be . . . anyway, good luck, and I'll keep an eye out for anything useful. On Tue, Nov 3, 2015 at 8:56 PM, John Syne <[email protected]> wrote: > I think that link refers to SPI slave nodes and not SPI slave mode. There > are a few postings on E2E related to SPI slave mode, but none seem to have > achieve anything, or at least anything that they disclosed. > > My approach is to use Starterware to mock up a solution where I have McSPI > and EDMA transferring data to a ping-pong buffer (DMA writes to one buffer > while CPU processes the other buffer and then swap buffers at the end of > each transfer). If I can achieve that then I should be able to implement > the same solution in a device driver. > > Regards, > John > > > > > On Nov 3, 2015, at 7:33 PM, William Hermans <[email protected]> wrote: > > So, I was curious about this too, and decided to do some web searching . . > . it seems there is a lot of talk about this going back since around 2009. > Although it is unclear whether or not slave mode was ever achieved, some > guy on the E2E forums claimed to have done it. Using DMA as well. > > But there is this: > > http://linux-kernel.2935.n7.nabble.com/PATCH-spi-spi-omap2-mcspi-c-Add-dts-for-slave-device-configuration-td622831.html > > And a bunch of other semi code related posts here and there that I can't > make out if they're useful or not. It's kind of a wonder that any of these > guys ever get anything done . . . > > > On Tue, Nov 3, 2015 at 4:25 PM, Matthijs van Duin < > [email protected]> wrote: > >> On 2 November 2015 at 19:02, John Syne <[email protected]> wrote: >> >>> I have been reading your posts and I am impressed with your detailed >>> knowledge of the inner workings of the AM335x. Do you have any experience >>> with using MCSPI as a slave and using EDMA. I’m using a high speed ADC that >>> works as a SPI master (generates sclk). Since LInux has no support for SPI >>> slave mode, my plan was create a driver that sets up MCSPI in slave mode >>> and use EDMA to store measurements to a ping-pong buffer. >> >> >> I don't have any experience with it yet, but it sounds like it should >> work. McSPI even has an option to relocate the fifo port to a 32-byte >> aligned address which is specifically added to allow you to use EDMA's >> "FIFO mode" (aka "constant addressing" or "streaming burst"), which enables >> it to slurp 16 or 32 bytes from the McSPI fifo with a single read. >> >> I'm not sure about the "ping-pong buffer" though, I'm not really familiar >> with linux kernel programming but I think for incoming DMA it might be >> better to allocate cache-cold pages? hmm, not sure how the reduced cache >> activity would balance against the increase in bookkeeping... depends also >> on what you intend to do with the received data, e.g. if you're going to >> stuff it down a pipe towards userspace you probably want to hand over the >> pages and need to allocate new ones anyway. >> >> Beware BTW that if SPI mode 0 or 2 is used, chip select is *required* to >> be deasserted between transfers. No such restriction applies to SPI mode 1 >> or 3, and chip select is optional there. >> >> Depending on what exactly that adc is sending, there's also a (small) >> chance you could interface it to McASP instead, which has a larger fifo and >> some data reformatting options. >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
