在 2015/9/6 20:09, Yousong Zhou 写道:
Hi,
On 6 September 2015 at 08:12, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote:
On 2015/9/5 22:58, Hans de Goede wrote:
Hi Shawn Lin,
On 05-09-15 16:07, Shawn Lin wrote:
On 2015/9/5 18:19, Yousong Zhou wrote:
A SD card with sunxi-mmc can fail with the following error message
(RCD for
response CRC error) when trying to switch to highspeed mode. Setting
the bus
clock before the access mode switch fixed it.
No, that's wrong!
Before this card is switched to highspeed, it works under
identification mode(From spec: bus clock <= 400KHz). How could you
raise bus clock to higher clk rate which I _guess_ is 52MHz before you
notify sd cards to run into highspeed mode?
Althought it works for this card, this patch will not please the other
cards that they might not reply CMDs any longer including the
following CMD6.
Thanks for the feedback, this is exactly why I asked Yousong Zhou to
take this
to the mmc list.
So if this is not the proper fix for the problem that Yousong Zhou is
seeing, then
what might be the proper fix ?
From my knowledge of mmc, there hadn't have a way to deal with this "broken"
case. In another word, IMO,it's ANTI-SPEC. We can't be too spec sometimes,
but at least we shouldn't violate it.
Maybe the fix is anti-spec. But the fact is that the card works on
many other platforms with the builtin card reader (not through an USB
adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.
Could it be that the sunxi-mmc is doing some things in the wrong order
when
changing the clock, or is this all under control of the mmc core ?
all of this is under control of the mmc core.
So if Yongsong does want this card to work for any linux-based mmc stack, I
guess something like that should be "better"?
if (switch to HS fail) {
set_bus_clk
goto retry switch to HS
}
BUT...I admit it seems strange as well.
The SD Specification (simplified version) says "If CRC error occurs on
the status data, the host should issue a power cycle.", so I guess the
above approach is anti-spec in some way :)
Right，I was guessing that way from your intention.
In case it may help debug this problem, I'd like to add that the card
previously worked fine with U-Boot before commit [1]. This can also
be confirmed by Debian Jessie installer image with which the old
U-Boot there worked fine while the kernel (3.16) did not.
[1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c
Interesting... but that at least prove your patch is a workaround but
not find the root cause.
Anyway, look into commit-sha [1], can you have a test by restoring
mod-clk and clock sampling phases before jump to kernel.
I happended to fix some problems which seems *similar* to yours(but I'm
not sure just from commit[1]'s msg):
https://patchwork.kernel.org/patch/7119661/
Cheers
yousong
--
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
--
Best Regards
Shawn Lin
--
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
