On 6/28/19 4:26 PM, Jean-Jacques Hiblot wrote: > > On 28/06/2019 15:38, Marek Vasut wrote: >> 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 <[email protected]> >>>> 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? > which part ? the clock stuff ? >> >> Also, which version of the spec is that ? > I'm quoting from JESD84-B51A (rev 5.1A) but IFAIK rdy/busy on DAT0 has > been there from the start.
^ yes, that part should likely be in the commit message, this is really useful info which should be retained in the history IMO. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
