>>> 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.
>

Maybe my statement about U-Boot commit [1] above was a little
ambiguous, sorry.  I meant to say that with that commit applied,
U-Boot failed initialising the card the same way as the kernel, i.e.
response crc error.

The Debian Jessie installer image's U-Boot worked fine and booted the
kernel because it was before commit [1] happened.  However after that
the 3.16 kernel failed initialising the card.

So, with commit [1], U-Boot failed right away without any chance at
all jumping to kernel.

OpenWrt ticket 20387 has more info about the U-Boot failure.

https://dev.openwrt.org/ticket/20387

Anyway, I have no idea what's the effect of those magic numbers on
"sampling phases".  Never played with such things before :)

                yousong

> 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/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to