Re: [Uclinux-dist-devel] spi_mmc bus concurrency fix

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

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/