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?
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?
Regards,
Martin
On Wed, 15 Apr 2009 11:13:44 +0200
Martin Fuzzey <[email protected]> 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.