Hi! > > > "too heavy" (in fact it's much lighter weight than resuming all devices > > > that your approach doesn't prevent from happening, so for example on my > > > desktop/notebook machines I woulnd't mind at all if user space were > > > thawed after all of the devices had been resumed). > > > > Well, it would be behavior change for the user. I told the zaurus to > > go s2ram, I do not expect it to wake up after 5 minutes because it > > needed to check battery status. > > > > I'd have to modify my userland to retry suspend again and again and > > again... > > And that's exactly what should be done. Have a user space process controlling > that, because avoiding to thaw user space doesn't buy us almost > anything. That makes Zaurus implement different user-kernel interface than PC class machine, because of hardware quirk. > Now, I know that it's probably easier to modify the kernel than to write > a user space tool for that, test it and so on, but "easier" is not necessarily > "better". It is easier, allows us to keep same user-kernel interface on PC and Zaurus, and is compatible with 2.6.38. Heck, I'm used to typing "echo mem > /sys/power/state". I should not have to learn different interface just because Zaurus does not have proper hardware charger. > > I'm not sure if we need to cover hibernation. Do you know any machine > > that needs this for hibernation case? > > Yes, any machine that "needs" it while suspended. What's the difference, > after all? The only difference is that there's an image on permanent storage > in the hibernation case. You still can overheat a battery when charging it > while hibernated, right? No, you can not; not on Zaurus. It can not really power down; it is always sleeping. s2ram is sleep in operating system, hibernation or poweroff is sleep in bootloader. Bootloader takes care of battery in that case. > > > To conclude, I'm not sure about the approach. In particular, I'm not sure > > > if the benefit is worth the effort and the resulting complications (ie. the > > > possibility of having to deal with wakeup signals not requested by user > > > space) seem to be a bit too far reaching. > > > > We already have platform-specific hacks to do exactly this at least on > > Zaurus. Moving it to common code means that hacks are not duplicated.. > > Well, good to know they are there, but I'm still not sure what to do about > that. At the moment I feel like having too little information to really > decide, so perhaps please point me to the code you're talking about for > starters. Ok, see the spitz_should_wakeup() function in arch/arm/mach-pxa/* and should_wakeup() usage. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
