On 2017/9/25 19:23, Christoph Fritz wrote:
On Mon, 2017-09-25 at 11:33 +0800, Shawn Lin wrote:
I'm just curious about if these ATP cards could work for ACMD23?
Could you kindly try this patch?
|https://patchwork.kernel.org/patch/9887651/
By looking at your patch I can see that bool variable 'need_acmd23' is
only set when card does not support CMD23. But here this card (falsely)
claims to support CMD23, which is the whole point of the NO_CMD23 quirk.
So testing your patch would not make any difference, because its
yup, sorry fot that. I mean you could hack it a little to mask
CMD23 support and let ACMD23 take effect, and see how it would
go?
forcing ACMD23 instead of CMD23 works fine:
dd if=/dev/urandom of=/mnt/test bs=1M count=100 conv=fsync
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 9.9496 s, 10.5 MB/s
It's as fast as using my NO_CMD23 quirk.
Thanks for the test. Given that ACMD23 is mandatory but very few sd
cards claim to support CMD23, maybe force ACMD23 support is better than
current CMD23/open-ending combo.
Back to $subject patch, It still need to verify this conclusion on other
platforms or get acknowledgement from the vendor.
/*
+ * Some SD cards lockup while using CMD23 multiblock transfers.
+ */
+ MMC_FIXUP("AF SD", CID_MANFID_ATP, CID_OEMID_ANY, add_quirk_sd,
+ MMC_QUIRK_BLK_NO_CMD23),
Is really all ATP cards having this problem? Perhaps we should
consider making this a bit more fine grained?
On the other hand, this may be the safest way to do it...
I also thought about this and set CID_OEMID_ANY because I wanted to be
on the safe side. Maybe ATP can comment on this (in CC)?
Thanks
-- Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
