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

[Lei Wen]

Hi Raffaele,


On Fri, Mar 11, 2011 at 2:30 PM, Raffaele Recalcati
<lamiaposta71 at gmail.com> wrote:
> On Fri, Mar 11, 2011 at 4:14 AM, Lei Wen <adrian.wenl at gmail.com> wrote:
>> On Fri, Mar 11, 2011 at 12:59 AM, Raffaele Recalcati
>> <lamiaposta71 at gmail.com> wrote:
>>> On Thu, Mar 10, 2011 at 5:29 PM, Lei Wen <adrian.wenl at gmail.com> wrote:
>>>> Hi Raffaele,
>>>>
>>>> On Thu, Mar 10, 2011 at 11:43 PM, Raffaele Recalcati
>>>> <lamiaposta71 at gmail.com> wrote:
>>>>> From: Raffaele Recalcati <raffaele.recalcati at bticino.it>
>>>>>
>>>>> The first SEND_OP_COND (CMD1) is used only to ask card capabilities, waiting
>>>>> that the card is not busy.
>>>>> 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.
>>>>>
>>>>> Signed-off-by: Raffaele Recalcati <raffaele.recalcati at bticino.it>
>>>>> ---
>>>>>  drivers/mmc/mmc.c |   21 +++++++++++++++++++--
>>>>>  include/mmc.h     |    2 ++
>>>>>  2 files changed, 21 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>>>> index 042653f..ded630b 100644
>>>>> --- a/drivers/mmc/mmc.c
>>>>> +++ b/drivers/mmc/mmc.c
>>>>> @@ -347,17 +347,34 @@ 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 */
>>>>> +       do {
>>>>> +               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);
>>>>> +       } while (!(cmd.response[0] & OCR_BUSY) && timeout--);
>>>>
>>>> I think you should not put the first probe a multi-time. In linux framework,
>>>> it would skip the first probing.
>>>>
>>>> I test with this patch and fail to detect my emmc card...
>>>> While just let the first probe once, it works fine.
>>>>
>>>> Best regards,
>>>> Lei
>>>>
>>>
>>> Look at JEDEC Standard No. 84-A441 document at page 190.
>>> It is normal to ask the card capabilities before setting.
>>> But I understand also that in your case there is some issue.
>>> I'm sorry, what does "multi-time" mean?
>>>
>>
>> I mean on my board I cannot get (!(cmd.response[0] & OCR_BUSY) to be
>> true for the first
>> MMC_CMD_SEND_OP_COND until its timeout, which lead to card init fail.
>>
>> Best regards,
>> Lei
>>
>
> This means 10msec are not enough.
> Even if a board dependent value should be better, can you find please
> the minimum value that it nice for your board?

It is not about the delay, it is about you shouldn't let the probe
perform multi-times.
As you also mention the JESD84-A44 doc, you could see the query mode only
perform _ONCE_, then continue to send SEND_OP_COND till card accept that.

So my point is that: in this patch, you shouldn't add a do{} while for
the first query.
Please remove it. As I test, my board works fine with the do{} while remove.

Best regards,
Lei