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

[Marek Vasut]

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

Ah, good, maybe this should be in the commit message?

Also, which version of the spec is that ?

-- 
Best regards,
Marek Vasut