On Monday, April 04, 2016 12:04:56 John Syne wrote: > I’m not sure that is correct. The master will normally send a command and > then your slave driver will have to respond with relevant packet. The > protocol will have to be well defined.
None of that is required by SPI (in the most basic form it is just a shift register). What I was alluding it protocol games that be played like Master writes byte to slave and waits for an active GPIO before anymore clocking. Or even a dumb (unidirectional) protocol where the master waits for a GPIO to go active before clocking out data. In contrast, doing it like a lot of common devices where you can clock in a byte (i.e. register address or a command) and expect data after another 8 clocks could impose some very tight timing requirements. > However, you are correct that the > SPI slave must be preconfigured and waiting for the master to start > clocking the interface. The problem with the SPI framework and in > particular the McSPI driver is that they is written around a master > implementation and adding slave support is almost impossible. It would be > easier to write a slave McSPI from scratch. The I2C slave framework might > be a good guide on how to make this work. There are 2 things being mixed up here - Merely grafting on slave functionality isn't too difficult with the current McSPI driver (that's what I did). The main thing this gets you is a lot of the driver registration and McSPI init is reused; this is a big hack but it gets data flowing. Getting it as a clean interface would definitely benefit from a rewrite as you described. > > Regards, > John > > > On Apr 4, 2016, at 11:27 AM, [email protected] wrote: > > > > Getting it to work is not hard. (Had it working for a project.) To get to > > work reliably at a high clock rate requires debugging the DMA or working > > out a protocol where timing isn't as tricky. As a slave the master can > > start clocking at anytime and unless the FIFO (or DMA) is preloaded with > > the entire packet the master wants, you will need to respond to the > > interrupt before an underrun occurs. > > > > The bigger barrier is a framework for SPI slave. > > > > On Monday, March 28, 2016 09:14:38 Yaron Yzhak Lederman wrote: > >> Thank you very much about clarifying this point ! > >> > >> I don't think that I can allocate enough time to dive into what John > >> described - I assume that at some stage there will be such a driver or > >> other form of such support > >> > >> Thanks for now > >> > >> On Sun, Mar 27, 2016 at 11:29 PM, John Syne <[email protected]> wrote: > >>> The McSPI needs a driver and there is currently no Linux Driver that > >>> supports SPI slave mode. The current driver > >>> /drivers/spi/spi-omap2-mcspi.c > >>> does not support slave mode. The Linux kernel SPI framework uses > >>> spi-omap2-mcspi driver on TI processors. > >>> > >>> Regards, > >>> John > >>> > >>> > >>> > >>> > >>> On Mar 27, 2016, at 12:35 PM, William Hermans <[email protected]> wrote: > >>> > >>> I'd actually look into using the McSPI module. Which is hardware, and > >>> does > >>> support slave mode. > >>> > >>> On Sun, Mar 27, 2016 at 11:29 AM, John Syne <[email protected]> wrote: > >>>> Ah, what you are trying to do cannot be done with the current SPI > >>>> driver > >>>> because Linux SPI framework does not support SPI slave mode. Recently > >>>> someone added I2C slave support to the I2C framework and that might be > >>>> your > >>>> first place to look. My approach would be to create a custom SPI driver > >>>> that does not use the SPI framework. The length and frequency of > >>>> messages > >>>> will define the driver design. For example, if the message length is > >>>> smaller than the SPI receive FIFO size, I would do this with > >>>> interrupts, > >>>> but the interrupt would occur only when exceeding the FIFO threshold > >>>> and > >>>> then dump the full FIFO in the bottom half interrupt handler. This way, > >>>> you > >>>> would get an interrupt on every say every 32 receive bytes, which will > >>>> reduce the interrupt overhead and improve throughput. > >>>> > >>>> If the message length is more than the FIFO length, or if the message > >>>> is > >>>> cyclical, then I would use DMA to copy the SPI data into a ping-pong > >>>> buffer > >>>> arrangement. From the use space app, you would use poll to wait for a > >>>> complete buffer, and then read that buffer via read or mmap. > >>>> > >>>> Question is, how experienced are you at writing Linux drivers? This > >>>> isn’t > >>>> a trivial task. > >>>> > >>>> Regards, > >>>> John > >>>> > >>>> > >>>> > >>>> > >>>> On Mar 27, 2016, at 12:26 AM, Yaron Yzhak Lederman < > >>>> [email protected]> wrote: > >>>> > >>>> John Hi, > >>>> > >>>> Thank you for coming back on this. > >>>> > >>>> I'm trying to connect 2 SPI busses on the BBB (HDMI disabled) and > >>>> configure SPI1 as SPI slave so that I can sent messages from SPI0 to > >>>> SPI1 > >>>> - > >>>> this allows me my application development and laterone I'll connect the > >>>> respective SPI slave and master devices > >>>> > >>>> Thank you > >>>> Yaron > >>>> > >>>> On Wed, Mar 23, 2016 at 10:37 PM, John Syne <[email protected]> wrote: > >>>>> What exactly are you trying to do? Please explain your application so > >>>>> that we can propose a solution. > >>>>> > >>>>> Regards, > >>>>> John > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mar 23, 2016, at 4:29 AM, [email protected] wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> Is there any resolution about this ? Since I'm having the same > >>>>> consideration > >>>>> > >>>>> Thanks ! > >>>>> > >>>>> > >>>>> On Wednesday, November 4, 2015 at 4:15:23 PM UTC+2, [email protected] > >>>>> > >>>>> wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I'm trying to setup SPI slave mode with same above method and > >>>>>> changed OMAP2_MCSPI_MODULCTRL_MS set to 0 for slave mode. > >>>>>> > >>>>>> i'm facing issue in master mode and slave both on sckl pin > >>>>>> configuration. > >>>>>> > >>>>>> http://elinux.org/BeagleBone_Black_Enable_SPIDEV in this link why > >>>>>> sckl > >>>>>> pin is configured as INPUT 0x33 but it will work with same > >>>>>> configuration if > >>>>>> i change it to OUTPUT it doesn't work with any slave device and no > >>>>>> clock on > >>>>>> that pin. > >>>>>> > >>>>>> Please anyone clarify this doubt and issues. > >>>>>> > >>>>>> For slave mode i tried to change OMAP2_MCSPI_MODULCTRL_MS bit in > >>>>>> driver > >>>>>> file spi_omap2_mcspi.c but no use. still its master only. > >>>>>> > >>>>>> Please provide any suggestion or exact procedure. > >>>>>> > >>>>>> Thank you in advance. > >>>>>> > >>>>>> Regard s > >>>>>> Ravi > >>>>>> > >>>>>> On Thursday, September 18, 2014 at 5:45:47 AM UTC+5:30, > >>>>>> > >>>>>> [email protected] wrote: > >>>>>>> I am having issues with SPI between two BBB that may be simple to > >>>>>>> solve. I have spidev_test loopback working on each board but am > >>>>>>> having > >>>>>>> problems connecting the two. > >>>>>>> > >>>>>>> spi0 master dts: > >>>>>>> 0x150 0x10 /* spi0_sclk, OUTPUT_PULLUP | MODE0 */ > >>>>>>> 0x154 0x30 /* spi0_d0, INPUT_PULLUP | MODE0 */ > >>>>>>> 0x158 0x10 /* spi0_d1, OUTPUT_PULLUP | MODE0 */ > >>>>>>> 0x15c 0x10 /* spi0_cs0, OUTPUT_PULLUP | MODE0 */ > >>>>>>> > >>>>>>> spi slave dts: > >>>>>>> 0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */ > >>>>>>> 0x154 0x10 /* spi0_d0, OUTPUT_PULLUP | MODE0 */ > >>>>>>> 0x158 0x30 /* spi0_d1, INPUT_PULLUP | MODE0 */ > >>>>>>> 0x15c 0x30 /* spi0_cs0, INPUT_PULLUP | MODE0 */ > >>>>>>> > >>>>>>> The oscilloscope shows activity when spi0_sckl (P9_17) is not > >>>>>>> connected but nothing when P9_17 is connected between both boards. > >>>>>>> I am sending bytes from master with the command: echo 1 > > >>>>>>> /dev/spidev1.0 > >>>>>>> > >>>>>>> I need 4-8mbit/sec transfer, is this achievable by bit banging over > >>>>>>> GPIO and would that be a viable alternative to getting SPI working? > >>>>> > >>>>> -- > >>>>> 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 a topic in the > >>>>> Google Groups "BeagleBoard" group. > >>>>> To unsubscribe from this topic, visit > >>>>> https://groups.google.com/d/topic/beagleboard/jQ1LH6IDH1A/unsubscribe. > >>>>> To unsubscribe from this group and all its topics, send an email to > >>>>> [email protected]. > >>>>> For more options, visit https://groups.google.com/d/optout. > >>>> > >>>> -- > >>>> בברכה, > >>>> > >>>> ירון יצחק לדרמן > >>>> 08-6909594 > >>>> > >>>> -- > >>>> 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 a topic in the > >>> Google Groups "BeagleBoard" group. > >>> To unsubscribe from this topic, visit > >>> https://groups.google.com/d/topic/beagleboard/jQ1LH6IDH1A/unsubscribe. > >>> To unsubscribe from this group and all its topics, send an email to > >>> [email protected]. > >>> For more options, visit https://groups.google.com/d/optout. -- Hunyue Yau http://www.hy-research.com/ -- 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.
