On Thursday 03 January 2008, Gernot Kvas wrote: > Hello, > > 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. :) > Apart from a > small patch to the UNSTUFF_BITS macro in drivers/mmc/core/mmc.c to > resolve some endianess issues, it works like a charm (for reading). > The card gets properly detected, I can mount it and read files from it > at a decent speed. That's good to know! > However, when I try to write to it, it fails. I used a scope to > monitor all 4 lines and discovered that after a CMD25 or CMD24, a That is, after WRITE_MULTIPLE_BLOCK or WRITE_BLOCK ... > 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? And is your SPI controller driver keeping chipselect low during that whole period? - Dave ------------------------------------------------------------------------- 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
