> On Apr 4, 2016, at 4:56 PM, [email protected] wrote: > > 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. Yep, I think we are talking about the same thing. Either call the callback in interrupt context, or schedule the callback through a work queue (bottom half). > > 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. Good point because I2C can drag this out until slave does an ack. However, SPI slave could respond with a wait response until it has data available. Maybe the interrupt routing checks kfifo for a response message and it none exist, send wait command. Master retries until it gets the desired response. > >>> 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. I see your point. Need to do some thinking on this one. So we need some sort of state machine?
Regards, John > > >>>>> 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 [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.
