Hi Feng,
I have to say that lots of SD controllers are not compatible to SDHC,
too. Just look at $Linux/drivers/mmc/host. And too many vendors are
using Designware eMMC/SD controller IP, like Samsung, ST, Hisilicon,
ZTE, Rockchip, Altera, and so on.
If the eMMC/SD stack only supports SDHC, it'll only benefit a few
vendors. And it also means that vendors need to create different eMMC/SD
stack to do the same thing.
Best Regards
Haojian
在 07/22/2016 08:56 AM, Tian, Feng 写道:
Hi, Haojian
JEDEC org doesn't have a eMMC host controller spec. most of eMMC h/c vendors
just reuse the SD host controller spec defined by SD Association. Of course
there are also some variants on eMMC host controller IP which doesn't follow SD
host controller spec perfectly.
The intention of EDKII SD/MMC stack is to cover those HCs/Devices following
standard SD/MMC specs. For your Designware case, You would have to have an
override version as it doesn't follow SD/MMC specs.
Thanks
Feng
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Haojian
Zhuang
Sent: Thursday, July 21, 2016 9:40 PM
To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Charles Garcia-Tobin
<charles.garcia-to...@arm.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data
On 2016/7/21 19:24, Ard Biesheuvel wrote:
On 21 July 2016 at 13:17, Haojian Zhuang <haojian.zhu...@linaro.org> wrote:
On 2016/7/21 9:52, Haojian Zhuang wrote:
在 07/21/2016 09:51 AM, Haojian Zhuang 写道:
Hi Feng,
I think the main difference is who to handle the CRC bits. In the
designware emmc/sd controller, the whole 128-bit value is loaded
into the four response registers. There's no any shift on the
128-bit value to remove CRC. (Refer to: drivers/mmc/host/dw_mmc.c).
I mean the implementation in linux. $Linux/drivers/mmc/host/dw_mmc.c
In the eMMC spec, it only mentions R2 response in table.
Bit position [127:1]
Width (bits) 127
Value x
Description CID or CSD register incl.
internal CRC7 It also doesn't mention
that we need to shift response value for CSD register.
So I did this fixing patch. I think that shifting isn't common to
support all eMMC/SD controller IP. Without this patch, the eMMC
stack will only get shifted CSD register value.
It results in parse error.
As I checked the SDHC driver in linux, there's the same logic as you
implemented in EmmcDxe.
Now the question is whether EmmcDxe is designed for common code of
all vendor's IP. If so, we need to provide a GetCsd() callback to
handle different implementations for different vendor. Do you mind
that I append the GetCsd() callback in EFI_SD_MMC_PASS_THRU_PROTOCOL to fix
this issue?
Unfortunately, you cannot simply add methods to protocols that are
defined by the UEFI spec. If the passthru protocol is lacking in
functionality, we should work with the UEFI forum to get it amended.
OK. Maybe we can do the same thing by another way. Now only SDHC needs to
shift data for CSD register. We could parse EMMC_CID by EmmcGetCid() in
EmmcGetCsd()
function. What's your opinion?
Best Regards
Haojian
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
