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

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

On Tuesday 26 February 2008, Bryan Wu wrote:
> On Tue, Feb 26, 2008 at 11:16 PM, Hans Eklund <hans-9ai+6vhHfRGzQB+pC5nmwQ@public.gmane.org> wrote:

> --
> /* NOTES:
>  *
>  * ...
>  *
>  * - MMC depends on a different chipselect management policy than the
>  *   SPI interface currently supports for shared bus segments:  it needs
>  *   to issue multiple spi_message requests with the chipselect active,
>  *   using the results of one message to decide the next one to issue.
>  *
>  *   Pending updates to the programming interface, this driver expects
>  *   that it not share the bus with other drivers (precluding conflicts).
>  *
>  * - We tell the controller to keep the chipselect active from the
>  *   beginning of an mmc_host_ops.request until the end.  So beware
>  *   of SPI controller drivers that mis-handle the cs_change flag!
>  *
>  *   However, many cards seem OK with chipselect flapping up/down
>  *   during that time ... at least on unshared bus segments.
>  */
> ---
> 
> So we can investigate with the SPI framework update.
> 
> >  There is one messaging scheme that i cant figure out how to create
> >  correctly using spi messages and transfers that is important for the
> >  MMC/SD SPI protocol.

I'm not following something here.  Is there another MMC-over-SPI
driver being developed?  Why not use the current one?


> >  Example of writing a single 512 byte block to SD/MMC, CS need to be
> >  asserted during whole sequence, no other traffic can be allowed.
> >
> >  Send command:           6 Bytes
> >  Poll for cmd response:  1 Byte( appears after 1-3 bytes read)
> >  Send data+token:        512+1 Bytes
> >  Poll for data response: 1 Byte (within a few bytes)
> >     --- card is now busy for a while and it is ok to deselct chip ---
> >  Poll for not busy:      coult take 30-10000 bytes at 20 Mhz to finnish
> >
> >  Last step can be done blockwise, 64 bytes a time by DMA for example..
> >  'not busy' is just a matter of transison from busy tokens to idle tokens.

Right, and there are plenty of other similar examples.  The current
drivers/mmc/host/mmc_spi.c code handles that, if the underlying SPI
controller driver handles the chipselecct as expected.


> >  Note that 'send data+token' can only be done if a specific cmd response
> >  was found. Same for data response, if not correct response another path
> >  in code will be taken(ask for card status). All this needs to be done
> >  "atomically" on the bus. Can this be achieved with the current state of
> >  the spi driver?

As noted above.  There are two issues:  (a) keeping other drivers off
the bus, and (b) making sure chipselect doesn't go inactive at the wrong
place.

The *current* assumption is that the bus will be unshared, so (a) isn't
an issue ... and that the SPI master controller driver will implement
the chipselect hinting mechanism (spi_transfer.cs_change set on the
last transfer).


We do need better solutions for (a) though.

- 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/