Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.

[Shawn Lin <shawn.lin@rock-chips.com>]

On 2015/9/6 22:51, Yousong Zhou wrote:
>>>> 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 I undertand your point:  Uboot w/o commit[1] + 3.16 kernel failed 
that way just as Uboot w/ commit[1] + pre-3.16 kernel, right?

If that is it, could you check sunxi-platform's patches merged into 
v3.16 for sure whether there is any patch do the same things just like 
what commit[1] did for uboot or not?

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


-- 
Best Regards
Shawn Lin