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

[Jean-Jacques Hiblot]

On 26/06/2019 11:50, Marek Vasut wrote:
> 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 ?

dat0 is a rdy/busy indicator. In the linux driver it is used in the 
card_busy() callback (look at sdhci_card_busy() for an example).

In u-boot we have a wait_dat0() that polls on dat0. It is used during 
the UHS initialization.




>