On 12 October 2017 at 10:08, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Wed, Oct 11, 2017 at 3:58 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > >> Actually completing the request in the ->done callback, may still be >> possible, because in principle it only needs to inform the other >> prepared request that it may start, before it continues to post >> process/completes the current one. > > I try to do that in this patch: > https://marc.info/?l=linux-mmc&m=148665460925587&w=2 Yeah, something like that! > > I'm trying to rebase this work now. Great! > >> However, by looking at for example how mmci.c works, it actually holds >> its spinlock while it calls mmc_request_done(). The same spinlock is >> taken in the ->request() function, but not in the ->post_req() >> function. In other words, completing the request in the ->done() >> callback, would make mmci to keep the spinlock held throughout the >> post processing cycle, which then prevents the next request from being >> started. > > It seems my patch would not deliver in some drivers until we look > into the locking semantics in the drivers. Yes! As a matter of fact the above change may actually introduce performance regressions, in case the behavior of the driver doesn't follow the expectations from the core. For that reason, either we have to invent a new MMC cap to allow drivers to opt-in using the "shortcut" or fix host drivers first. Kind regards Uffe
