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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
