On Tuesday 26 February 2008, Bryan Wu wrote: > On Tue, Feb 26, 2008 at 11:16 PM, Hans Eklund <[EMAIL PROTECTED]> 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/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
