> On Apr 4, 2016, at 3:25 PM, ybeag...@rehut.com wrote: > > On Monday, April 04, 2016 13:13:48 John Syne wrote: >>> On Apr 4, 2016, at 12:49 PM, ybeag...@rehut.com wrote: >>> >>> 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. >> >> Well, technically, that is correct, because data is shifted in and out at >> the same time, using the same clock. However, when the master hasn’t >> requested a specific data, what do you respond with? Random data? Perhaps >> if it was just streaming channel data, then I can see your point. > > Since SPI is always full duplex, it comes down to protocol definition. It > could be a fixed pattern, 0, 0xff, or random, or undefined data during the > initial clock out for the command byte. > >>> 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. >> >> I agree, this could be very difficult to achieve using interrupts, but using >> DMA that should be pretty simple. That presupposes that the data is already >> in the DMA buffer and this is some streaming interface I spoke of >> previously. Streaming channel data into the BBB using DMA would also be >> pretty simple. Exchanging of short master/slave command/response would need >> interrupt processing. Maybe using fixed size messages and using fifo >> watermark might limit the interrupt overhead. >>>> 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. >> >> Can you share that with me? I would be interested to see how you managed to >> do this. I’ve looked at this several times and each time my head wants to >> explode. > > Unfortunately, I cannot share that code (paperwork reasons, owned by > customer). The differences between slave/master from a pure driver's point of > view is a few register settings. A naive way of doing this is - > > Initialize as slave > Have a callback in the driver that queue's data for transmission. > Driver user (aka data consumer) registers a receive callback that is invoked > when data comes in. Driver user is responsible for ignoring data when > appropriate. Yeah, this is the approach used by the I2C Slave Framework. So traditionally, the McSPI driver registers with the SPI Framework as an SPI Master. Now through DT config, we could have the McSPI driver register with the SPI Framework as an SPI Slave and then the SPI framework registers a callback with the McSPI driver (Slave Provider). On receiving event from the master, McSPI driver calls Custom Driver callback, which responds by writing to McSPI FIFO. Does that sound reasonable? > > On receive, queue more data for xfer to avoid underruns on the MISO end. If > nothing is queued by the driver user, put in fix data to keep the McSPI happy > (avoid underruns). I agree. In the case when the slave driver cannot respond in time, simply send a wait response and have the master retry until successful. > > A better implementation may be to use a work queue arrangement to limit the > exposure of the driver user to time criticality. Probally need to propagate > the CS (SS) signal up to the driver user to help synchronize things. The McSPI hardware will take care of this. From what I recall, McSPI does not process SPI signals until Slave Select is true. > >>> Getting it as a clean interface would definitely benefit from a rewrite as >>> you described. >> >> If you are willing, perhaps this is a project we can work on together. > > We can talk about it. >> >> Regards, >> John >> >>>> Regards, >>>> John >>>> >>>>> On Apr 4, 2016, at 11:27 AM, ybeag...@rehut.com 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 <john3...@gmail.com> 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 <yyrk...@gmail.com> >>>>>>> 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 <john3...@gmail.com> > 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 < >>>>>>>> yaron.leder...@gmail.com> 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 <john3...@gmail.com> > 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, yaron.leder...@gmail.com 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, >>>>>>>>> ravi...@gmail.com >>>>>>>>> >>>>>>>>> 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, >>>>>>>>>> >>>>>>>>>> phil...@gmail.com 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 beagleboard+unsubscr...@googlegroups.com. >>>>>>>>> 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/unsubscrib >>>>>>>>> e. >>>>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>>>> beagleboard+unsubscr...@googlegroups.com. >>>>>>>>> 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 beagleboard+unsubscr...@googlegroups.com. >>>>>>>> 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 beagleboard+unsubscr...@googlegroups.com. >>>>>>>> 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 beagleboard+unsubscr...@googlegroups.com. >>>>>>> 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 >>>>>>> beagleboard+unsubscr...@googlegroups.com. >>>>>>> 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 beagleboard+unsubscr...@googlegroups.com. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
