Message-ID: <20080620194128.2720cc51@mjolnir.drzeus.cx>
Date:	Fri, 20 Jun 2008 19:41:28 +0200
From:	Pierre Ossman <drzeus-mmc@...eus.cx>
To:	Ben Dooks <ben-linux@...ff.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: MMC test driver - help with output

On Fri, 20 Jun 2008 12:15:53 +0100
Ben Dooks <ben-linux@...ff.org> wrote:

> I'm testing the s3c24xx sd/mmc driver and can't find any
> documentation for each of the tests the mmc_test driver is
> doing.
> 
> The following is output from a recent linux-next+driver:
> 
> mmc0: Test case 8. Power of two block reads...
> s3c2440-sdi s3c2440-sdi: unfinished read - pio_count:[0] pio_words:[0]
> mmc0: Result: UNSUPPORTED (by host)
> 
> => probably the wrong error being returned, but what would be
> the general problem with this causing a finish before the driver
> has decided that there should have been data to read?
> 

I'm not sure what's going on here. The purpose of the test (and most of
them) is to test that the driver supports all block sizes. The reason
there are so many tests is because there are a lot of different bugs in
different drivers. This particular one is for the PXA controller
(IIRC), where only power of two sizes are valid.

This test starts with a block size of 1 byte, then doubles it until it
reaches 512 bytes.

> mmc0: Test case 10. Weird sized block reads...
> s3c2440-sdi s3c2440-sdi: unfinished read - pio_count:[0] pio_words:[0]
> mmc0: Result: UNSUPPORTED (by host)

This test starts with 3 bytes and adds 7 bytes to the size until it
reaches 512 bytes. It is primarily meant to test size alignment issues.

> mmc0: Test case 15. Correct xfer_size at write (start failure)...
> s3c2440-sdi s3c2440-sdi: bad data crc (incoming)
> 
> => is this sort of error what was exepected?
> 

Not really, no. The test tells the driver to write a block, but sends a
non-data command to the card. The idea is to simulate a failed write
and see that the driver handles the error properly.

The validation of the test is making sure the driver doesn't report
more data written than was actually transferred and to check that the
error code is -ETIMEDOUT, which is what is expected as the card should
not acknowledge the data block.

> mmc0: Result: ERROR (-84)
> mmc0: Test case 16. Correct xfer_size at read (start failure)...
> s3c2440-sdi s3c2440-sdi: data timeout
> mmc0: Result: OK
> 
> => is this the expected response?
> 

This follows the same reasoning, but for reads. You shouldn't have a
driver that prints out such errors though. A timeout might be a valid
condition.

> mmc0: Test case 17. Correct xfer_size at write (midway failure)...
> s3c2440-sdi s3c2440-sdi: bad data crc (incoming)
> mmc0: Result: ERROR (-84)

This is similar to the above tests. The test tells the controller the
request has two blocks, but tells the card it's only one. The purpose
is to simulate a write error half way through a transaction.

> mmc0: Test case 18. Correct xfer_size at read (midway failure)...
> s3c2440-sdi s3c2440-sdi: data timeout
> mmc0: Result: OK

Same for reads.

> 
> Also, any indications of how the "busy state" warnings could be
> debugged?
> 

I'm not familiar with this controller, so no. The warning is about the
driver returning early when it should be waiting for the card to stop
its busy signalling first. The idea here is that that upper layers can
only do this by polling, whereas the driver might be able to do it
using interrupts (i.e. much cheaper). Not a high priority though. Most
drivers get this wrong (including my own).

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

  WARNING: This correspondence is being monitored by the
  Swedish government. Use end-to-end encryption where
  possible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists