Thanks William. Regards, John
> On Nov 3, 2015, at 8:05 PM, William Hermans <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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 >> >> <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] >> <mailto:[email protected]>> wrote: >> On 2 November 2015 at 19:02, John Syne <[email protected] >> <mailto:[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 >> <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
