On 6/28/19 10:28 AM, Jean-Jacques Hiblot wrote: > > On 28/06/2019 02:07, Marek Vasut wrote: >> On 6/27/19 12:31 PM, Jean-Jacques Hiblot wrote: >>> Using the DAT0 line as a rdy/busy line is an alternative to reading the >>> status register of the card. It especially useful in situation where the >>> bus is not in a good shape, like when modes are switched. >>> This is also how the linux driver behaves. >>> >>> Signed-off-by: Jean-Jacques Hiblot <jjhib...@ti.com> >> Is this documented somewhere that this is an OK thing to do ? >> If the bus is not in a good shape, what guarantee do we have that DAT0 >> (part of the bus ;-) ) would be in good shape ? > > The spec states in "6.6.1 Command sets and extended settings": [...] The > SWITCH command response is of type R1b, therefore, the host should read > the Device status, using SEND_STATUS command, after the busy signal is > de-asserted, to check the result of the SWITCH operation.[...] > > Also this is how it is done in linux, except that instead of > wait_dat0(), the host driver provides a card_busy() function. > > I think that "not in good shape" probably means transients on the bus, > maybe due to changes in the voltage levels. Looking at DAT0 should be > fine because it is grounded while the card is busy. > > The only trouble with using DAT0, is that the clock must run while > waiting otherwise DAT0 may not be de-asserted, hence the encapsulation > in the wait_dat0() so that the HW can disable automatic clock-gating > before monitoring DAT0. Here is the relevant text from the spec: 6.7 > "clock control" [...] The host is allowed to shut down the clock of a > “busy” Device. The Device will complete the programming operation > regardless of the host clock. However, the host must provide a clock > edge for the Device to turn off its busy signal. Without a clock edge > the Device (unless previously disconnected by a deselect command (CMD7)) > will force the DAT0 line down, forever. [...]
Ah, good, maybe this should be in the commit message? Also, which version of the spec is that ? -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
