On Sunday, July 31, 2011, Pavel Machek wrote: > Hi! > > > > IIRC I solved it by just calling _PTS when sleepy Linux was > > > enabled. It had side effect of lighting up moon icon, but otherwise > > > seemed to work ok. > > > > > > I do not think ACPI says what can and can not be done after _PTS... > > > > Yes, it does. > > I have 2.0 spec here; it explains how _PTS can be called long time > before actual sleep and may not power down devices... > > > > It should be ok to execute _WAK in process context once system is > > > resumed. ... or maybe not executing _WAK at all. User can probably > > > live with moon icon lighted up. > > > > But I don't think the user can live with certain functionality missing, > > like battery status or such things. > > Yep; you'd probably want to execute it before calling other ACPI methods... > > > This is completely unrealistic to think that your prototype can be safely > > implemented on _every_ ACPI-based system. Period. > > My prototype would probably not be safe on any system, period. It was > quick hack to prove the concept. > > > And that's even without taking SMP into account, BTW. > > Idea was to do hot CPU unplug before enabling sleepy state. Sleepy > probably should be enabled when screen is turned off by > screensaver (if machine is sufficiently idle). > > I'm not saying that task is easy, merely that is doable. (Doing it in > clean way will be harder still). Basically prepare all the devices to > sleep when machine gets "idle enough", along with _PTS, but keep > running, including userspace. Then, if next wake up is "long enough" > into future, set up RTC alarm and push machine to sleep. You're supposed to do all that from within the idle loop on one of the CPUs (at least in the context of this discussion). I don't really think it's realistically doable. Thanks, Rafael -- 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
