On Thu, Oct 26, 2017 at 3:49 PM, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 26/10/17 16:32, Linus Walleij wrote: >> My patch series switches the stack around to make it possible >> to do this. But it doesn't go the whole way to complete the requests >> from interrupt context. >> >> Since we have to send commands for retune etc request finalization >> cannot easily be done from interrupt context. > > Re-tuning and background operations are rare and slow, so there is no reason > to try to start them from interrupt context. OK I will try to get them out of the way and see what happens, hehe :) What I mean is that we were checking - on every command - if BKOPS or retune needs to happen. And then doing it. Thus all was done in process context. >> But I am thinking about testing to hack it >> using some ugly approaches ... like assuming we don't need any >> retune etc and just say all is fine and optimistically complete the >> request directly in the interrupt handler if all was OK and wait >> for errors to happen before retuning. > > It already works that way. Re-tuning happens before you start a request. > We prevent re-tuning in between dependent requests, like between starting a > transfer and CMD13 polling for completion. Ah that is what these if()s do ... right. I'll see if I can get around this then. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
