I like the simplified approach taken in this patch. Shortening the awake time by trying to call __pm_relax() in all corner cases turned out to be too complex. Reviewed-by: Zoran Markovic <zoran.markovic@xxxxxxxxxx> Regards, Zoran On 1 October 2013 02:22, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > Hi John, > >> So how does the notification done to userspace? I wonder if you could >> use the select/lock/read style method for releasing the kernel space >> wakeup_source, as is done in the input layer? > > If I understand what you mean correctly, it is very similar what Zoran > tried to do before in his patch!? > > For the mmc subsystem, especially considering the pitfalls around the > scheduled detect work, I think it will be hard to get this right, if > implementing like this. I fear we might end up in situations were the > wakeup_source is never "relaxed". > >> >> >>> Not sure how to set the time-out value to meet all expectations. I >>> believe we could also consider that inserting/removing a card is a >>> quite seldom operation, so using a bit higher value than necessary >>> might be okay. What do you think? >> >> As long as its sure to be *very* rare, then slightly longer delays >> aren't a major problem. The trouble with the timeout style wakelocks is >> that they are easy to misuse and that hurts power efficiency. (I've >> heard stories of badly written wifi drivers that took 5 minute timed >> wakelocks on packets, which effectively kept devices from ever sleeping). > > In this case, I am more confident that this would actually simplify > code that much, so we can get around all the scary pitfalls. > > I can only think of one case which could lead to problem. If there is > a host driver, enabled for wakeup, that gets spurious card detect > irqs, outside the window were you expect a card to be > detected/removed, and at the same time do not have a software > mechanism to "debounce" the irqs. But, should we even consider this as > a valid case? > > Kind regards > Ulf Hansson > >> >> So if possible, its much better to have a normal path where the pm_relax >> is called in most cases, using the timeout for only the few places where >> you really can't get an end point. >> >> thanks >> -john -- 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
