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

[Jean-Jacques Hiblot]

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.


>