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

[Marek Vasut]

On 6/26/19 2:21 PM, Jean-Jacques Hiblot wrote:
> 
> 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.

All right, let's try this.

-- 
Best regards,
Marek Vasut