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
_______________________________________________
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
