[U-Boot] [PATCH v1 06/11] mmc: if possible, poll the busy state using DAT0

[Jean-Jacques Hiblot]

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 <jjhiblot at 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. [...]


>