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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux