[U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing

[Marek Vasut]

On 6/26/19 11:22 AM, Jean-Jacques Hiblot wrote:
> 
> On 25/06/2019 21:47, Marek Vasut wrote:
>> On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
>>> On 25/06/2019 17:53, Marek Vasut wrote:
>>>> On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
>>>>> Hi Marek,
>>>>>
>>>>> On 06/02/2019 14:11, Marek Vasut wrote:
>>>>>> When using CMD6 to switch eMMC card timing from HS200/HS400 to
>>>>>> HS/legacy,
>>>>>> do not poll for the completion status using CMD13, but rather wait
>>>>>> 50mS.
>>>>>>
>>>>>> Once the card receives the CMD6 and starts executing it, the bus
>>>>>> is in
>>>>>> undefined state until both the card finishes executing the command
>>>>>> and
>>>>>> until the controller switches the bus to matching timing
>>>>>> configuration.
>>>>>> During this time, it is not possible to transport any commands or
>>>>>> data
>>>>>> across the bus, which includes the CMD13.
>>>>> Is it something that affects all platforms ?
>>>>>
>>>>> I've been working on this on TI platforms lately and although I've
>>>>> seen
>>>>> the same kind of problems. But they mostly go away If the code
>>>>> handling
>>>>> the switch handles the SWITCH_ERROR bit.
>>>> The error probably happens because you send the card a command, but the
>>>> command hits the bus that's in some weird intermediate state. Either
>>>> the
>>>> card didn't finish switching the bus properties yet, or it did, or it's
>>>> in the middle of it, but you cannot tell.
>>> OK thanks for the response.
>>>
>>> If CMD13 can't be used because the bus is in an undefined state,
>>> shouldn't send_cmd(CMD13) just fail ?
>> So it would fail, but how do you guarantee the bus/card switched to the
>> new state and is reliably ready ? You can't, because you cannot
>> communicate with the card -- which is the entire problem here, you have
>> no way to communicate with the card while the bus is switching. However,
>> you can wait the maximum allowed time according to the spec, and then
>> the bus/card must be ready. If not, all bets are off.
>>
>>> I'm asking because this is a 50ms delay in the hot path of the boot
>>> process.
>> I totally understand that, I have the same issue with HS200/HS400 on
>> R-Car Gen3, all the calibration shenanigans and this indeed add quite a*
>> bit to the boot time. But I don't have a good answer here.
> 
> I'll post something using the existing wait_dat0() callback. If the
> callback is implemented, we can forgo the 50ms delay and poll the dat0
> line.

We can ? Do you have some more details ?

-- 
Best regards,
Marek Vasut