On Monday, April 04, 2016 16:05:47 John Syne wrote: <SNIP> > 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?
Sort of. I'd suggest an alternative (might be implied by what you are saying): - Provide a fast callback that does exactly what you are saying. - If no fast callback is registered, a slow path callback can be registered. This slow back call back is invoked via a work queue. Goal with something like this is to lessen the timing requirement on the driver user. The I2C slave side doesn't need this as I2C provides for the slave to slow things down if needed. > > 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. That is not sufficient for a slave. Consider the following usage scenario - Protocol is - SS is asserted on a per transaction. First 8 bits clocked in is a command. Additional clocks will read out data. Attempting to read out data beyond what is appropriate for the command will return zeros. Deasserting /SS will stop the current transaction to allow a new transaction to be started. Something like that is often used for things that return variable amounts of data. It can also provide a back channel for the master to resync thing. Without propagating the /SS state back up to the driver user, the driver would have a hard time synchronizing on the protocol level. > >>> 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 > >> <SNIP> -- 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.
