On Wed, 15 Apr 2009 11:13:44 +0200 Martin Fuzzey wrote: > Hi, > I'm currently updating the mxcmmc driver for the i.MX21 platform > [patches have been posted to the arm list] and have a couple of > questions about the test suite. > > 1) I'm getting an error on testcase 10 (weird reads) which does reads > of 3 to 512 bytes by steps of 7. > Modifying the test so it continues in case of error shows that it > _only_ fails on the 395 byte read. > > It fails with a software timeout (-110) > The card sends the same response to CMD17 (READ_SINGLE_BLOCK) as the > reads that work > but hardware never indicates transfer complete. > > Changing the test to start at 395 makes it fail immediately (so not > dependent on previous reads). > Has anyone seen this before? > Nothing I recognize, no. Have you tested more than one card in case it's a card bug? > 2) I'm getting "Warning: Host did not wait for busy state to end" on > the multiblock write tests (Tests 5 and 13) but they still pass. > Seems to be timing related since this doesn't occur with MMC debugging enabled. > My understanding of this is that the driver should wait for the > hardware to stop signalling busy on the data line (response R1b) after > sending > command 12 (stop transmission) before replying - is this correct? > However the MX2 SDHC doesn't have a register for this. > > Should I: > a) ignore it? [apart from the testcase warning everything seems to work] > b) try reading the data line as GPIO - seems a bit of a hack > c) issue CMD13 (SEND_STATUS) from the driver to poll the card - seems > to be the wrong layer. > > If b) is the way to go how long can the delay be - is polling > acceptable or must it be interrupt driven? > I'd say a). If the hardware doesn't support it then I don't think we can do that much better than the polling that mmc_block does. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.