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