[U-Boot] [RFC 2/3][v4] mmc: SEND_OP_COND considers card capabilities (voltage)

Andy Fleming afleming at gmail.com
Wed Aug 17 04:51:28 CEST 2011


Please see:

commit b1f1e821d335de58d362bf3013c93cef86cdb356
Author: Łukasz Majewski <l.majewski at samsung.com>
Date:   Tue Jul 5 02:19:44 2011 +0000

    mmc: Access mode validation for eMMC cards > 2 GiB

It adds support for setting the HCS bit. It will only be done if your
driver has set  mmc->host_caps & MMC_MODE_HC.

Let me know if that patch didn't solve your problem.

Andy

On Thu, Jul 28, 2011 at 2:25 PM, Gary Thomas <samoht.yrag at gmail.com> wrote:
> On 2011-04-13 05:24, Andy Fleming wrote:
>>
>> On Fri, Mar 11, 2011 at 6:01 AM, Raffaele Recalcati
>> <lamiaposta71 at gmail.com>  wrote:
>>>
>>> From: Raffaele Recalcati<raffaele.recalcati at bticino.it>
>>>
>>> The first SEND_OP_COND (CMD1) command added is used to ask card
>>> capabilities.
>>> After it an AND operation is done between card capabilities and host
>>> capabilities (at the moment only for the voltage field).
>>> Finally the correct value is sent to the MMC, waiting that the card
>>> exits from busy state.
>>>
>>> Signed-off-by: Raffaele Recalcati<raffaele.recalcati at bticino.it>
>>> ---
>>>  drivers/mmc/mmc.c |   19 +++++++++++++++++--
>>>  include/mmc.h     |    2 ++
>>>  2 files changed, 19 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index fc1792a..5bea476 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -351,17 +351,32 @@ sd_send_op_cond(struct mmc *mmc)
>>>
>>>  int mmc_send_op_cond(struct mmc *mmc)
>>>  {
>>> -       int timeout = 1000;
>>> +       int timeout = 10000;
>>>        struct mmc_cmd cmd;
>>>        int err;
>>>
>>>        /* Some cards seem to need this */
>>>        mmc_go_idle(mmc);
>>>
>>> +       /* Asking to the card its capabilities */
>>> +       cmd.cmdidx = MMC_CMD_SEND_OP_COND;
>>> +       cmd.resp_type = MMC_RSP_R3;
>>> +       cmd.cmdarg = 0;
>>> +       cmd.flags = 0;
>>> +
>>> +       err = mmc_send_cmd(mmc,&cmd, NULL);
>>> +
>>> +       if (err)
>>> +               return err;
>>> +
>>> +       udelay(1000);
>>> +
>>>        do {
>>>                cmd.cmdidx = MMC_CMD_SEND_OP_COND;
>>>                cmd.resp_type = MMC_RSP_R3;
>>> -               cmd.cmdarg = OCR_HCS | mmc->voltages;
>>> +               cmd.cmdarg = ((mmc->voltages&
>>> +                             (cmd.response[0]&  OCR_VOLTAGE_MASK)) |
>>> +                             (cmd.response[0]&  OCR_ACCESS_MODE));
>>
>>
>> My concern here is that OCR_HCS has been dropped. I thought it was
>> necessary to query the HCS abilities.
>>
>> I'm guessing I'm missing something, or that it's not needed, so I will
>> apply this patch, and we'll see if anyone has issues.
>
> I just tried this on my eMMC chip (THGBM1G5D2EBAI7) and without the OCR_HCS
> bit set, the
> device gets totally hosed.  Only a power cycle will fix it.
>
> Adding it back like this fixes the problem:
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 21aedba..76117da 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -446,7 +446,7 @@ int mmc_send_op_cond(struct mmc *mmc)
>                cmd.cmdidx = MMC_CMD_SEND_OP_COND;
>                cmd.resp_type = MMC_RSP_R3;
>                cmd.cmdarg = (mmc_host_is_spi(mmc) ? 0 :
> -                               (mmc->voltages &
> +                               OCR_HCS | (mmc->voltages &
>                                (cmd.response[0] & OCR_VOLTAGE_MASK)) |
>                                (cmd.response[0] & OCR_ACCESS_MODE));
>                cmd.flags = 0;
>


More information about the U-Boot mailing list