On Tue, Apr 14, 2020 at 06:14:00PM +0200, Ulf Hansson wrote: > Some commands uses R1B responses, which means the card may assert the DAT0 > line to signal busy for a period of time, after it has received the > command. The mmc core normally specifies the busy period for the command in > the cmd->busy_timeout. Ideally the driver should respect it, but that > requires quite some update of the code, so let's defer that to someone with > the HW at hand. > > Instead, let's inform the mmc core about the maximum supported busy timeout > in ->max_busy_timeout during ->probe(). This value corresponds to the fixed > ~2s timeout of the polling loop, implemented in cb710_wait_for_event(). In > this way, we let the mmc core validate the needed timeout, which may lead > to that it converts from a R1B into a R1 response and then use CMD13 to > poll for busy completion. > > In other words, this change enables support for commands with longer busy > periods than 2s, like erase (CMD38) for example. [...] > + /* > + * In cb710_wait_for_event() we use a fixed timeout of ~2s, hence let's > + * inform the core about it. A future improvement should instead make > + * use of the cmd->busy_timeout. > + */ [...] I'm not sure whether the controller limits busy signalling time. Since this is rare HW now, I would just pass the timeout to cb710_wait_for_event() and see if someone reports a bug. Best Regards, Michał Mirosław
