On Wednesday 27 February 2008, Phil Wilshire wrote: > > Thats why I wanted an optional callback after each single transfer.
That would preclude using chained DMA requests in those cases, but presumably that'd be OK in this context. > So if you are waiting for a status byte in the spi data > then the callback would add the a small read transfer a few times while > checking the status. Just a few? If you're assuming it would add a new spi_transfer after the existing ones in that message ... that could add up to quite a lot of additional transfers, presumably ones that are dynamically allocated. I've seen some MMC/SD cards need quite a lot of polling there... > When it times out (IE reaches a max retry limit) then the transfer can > be halted returning some kind of failure state. > > If the correct status is found then the next transfer can be the data to > be written to the device. > > I thought about the single device queue based in chip select but that > looked a but more complex. That is, one queue per device. Yes, more complicated than one shared between devices. I was just pointing that out as an option that could be implemented transparently ... albeit not portably. > With the TRANSFER callback we have a good (IMHO) way to modify the > message flow based on the data contents. > > The complete function may need two arguments. One to hold the SPI > Transfer in progress and the other to hold user state > (like max read loops and final state). > > Let me know if this would fit in the "overall formal design" and I'll > stop hacking a custom solution. It doesn't seem like the right approach to me. In the specific use case of an MMC interface, three'd be a *LOT* of those callbacks, each adding another transfer to the current message. And that breaks assumptions like being able to validate entire messages before starting to process them, bounded memory use, and so on. I'd far rather see something that does less damage to the underlying models. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
