On Tue, 1 Jun 2010 12:20:12 +1000 Neil Brown <neilb@xxxxxxx> wrote: > On Tue, 1 Jun 2010 03:49:37 +0200 (CEST) > Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > 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. Can you explain the difference between the /sys/power/state thing? Is it the reprogramming of wake-sources as mentioned by Raffael? In an idle based suspend I assume there would be no new wake-sources on suspending. > I'm not interested in adding another user-space API if it can possibly be > avoided, and I think it can. But that is a later step in the process. > > I think you have acknowledged that there is a race with suspend - thanks. > Next step was "can it be closed". > You seem to suggest that it can, but you describe it as a "work around" > rather than a "bug fix"... Well as far as I get it, the workaround is to not suspend in sitations where a race is likely to occur. (I.e. block suspend) > > Do you agree that the race is a "bug", and therefore it is appropriate to > "fix" it assuming an acceptable fix can be found (which I think it can)? > > If you agree that it is appropriate for try to fix this bug, then the next > step would be to get the Android devs to agree that a fix could - in > principle - address the need for which they created suspend-blockers. > Arve: can you confirm that? > > Then, with a clear and agreed goal, we can look at possible fixes. > > Thanks, > NeilBrown > > > > > Thanks, > > > > tglx cheers, Flo -- 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
