On Tue, 14 Apr 2020 at 20:40, Michał Mirosław <mirq-linux@xxxxxxxxxxxx> wrote: > > 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. Alright, let me try something like that. Thanks for your suggestion. Kind regards Uffe
