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.