On Tue, 1 Jun 2010, Neil Brown wrote: > And if you are right that the race window cannot be closed, then the whole > suspend-blocker infrastructure is pointless as the purpose of it is simply to > close that window. If it really does not and cannot work, then it would be > best to reject it for that reason rather than for less concrete aesthetic > arguments. > But presumably it does work in practice on Android hardware so ..... confused. > > Having just seen the email from Thomas, maybe you mean that it cannot be > closed on devices using ACPI, but can on other devices. I can sort-of > imagine how that would be the case (I tried reading an ACPI spec once - my > hat is of to those of you who understand it). > That shouldn't prevent us from closing the race window on "sane" hardware > that allows it. This would, I think, be sufficient for Android's needs. > > I'm hoping we can get agreement on: > - there is a race with suspend That's a matter of how you define "suspend". If "suspend" is another deep idle state and the hardware is sane, there is no race at all - assumed that the driver/platform developer got it right. It's not rocket science to transition from "normal" irq delivery to wakeup based delivery raceless (except for PC style x86 hardware of today) If "suspend" is the thing we are used to via /sys/power/state then the race will persist forever except for the suspend blocker workaround, which we can express in QoS terms as well w/o adding another suspend related user space API. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
