2008/1/3, David Brownell <[EMAIL PROTECTED]>: > On Thursday 03 January 2008, Gernot Kvas wrote: > > I have implemented a DMA/PIO driven SPI driver for the ARM based > > ns9xxx SoCs, largely based on the driver for the omap2. I'm using the > > mmc_spi stuff from the mm patches, currently 2.6.23-mm1. > > ISTR some initial merge glitches, but maybe they were gone by then. > I'd still recommend using more current code; especially with the > 2.6.24 release nearly upon us. :)
I'm looking forward to 2.6.24. Anyone volunteered to implement the spi-subsystem primitives to allowed mmc_spi on a shared bus? > > subsequent CMD25 or CMD24 would fail. Both commands expect a R1 > > response, 8-bits. However, prior to what looks like a 8-bit response, > > I read a couple of 0xFF (which is normal) and then suddenly a 0xFE. It > > seems as if the card goes low too early. Any ideas, hints? > > That sounds a bit familiar. Does that happen with all cards, or > just with ones from one particular vendor? Is that driver version > using SPI_MODE_0 or SPI_MODE_3? It should be using SPI_MODE_0. As far as I can remember on the scope traces, that should be true. > And is your SPI controller driver keeping chipselect low during > that whole period? I tried it both with a toggling chipselect (which would be the default, as the ns9xxx toggles if you write bytewise and as I suspected this, I manually changed the chipselect in a driver callback. No change, even with the chipselect low over the entire period. I only have cards from that manufacturer to try out, however, I will have access to an older card at the weekend to try that out. Cheers, Gernot ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
