On Nov 03 2008, at 13:41, Jordan Crouse was caught saying: > The concept of suspend is muddled greatly with kernel and userspace folks > both participating in the discussion and coming at the problem from > different directions. As Deepak says, the dream is to put the whole system > to sleep on a very long idle interval where other processors would be in a > deeper C state. To do this, we need to know certain kernel timing > information that we can compare to our worse case suspend/resume time and > make a reasonable choice to attempt to enter a suspended state. So in > that regard, it does help us determine if we want to try to sleep, but its > only one of a number of inputs into the black box - some of which are > determined in userspace through OHM, and others which are determined > by the kernel. > > Presumably the cpuidle code would kick into XO specific code at some point > which would check that all of the other suspend inputs are green before > doing the deed. The funny thing is that this isn't so dissimilar from how > ACPI works.
Right, and at that point, we're not doing "cpuidle", we're doing full system state assesment and I don't think doing that in the kernel in the middle of the idle loop is the best thing to do and we would probably have to add a lot of interfaces into the kernel to manage all that information. We could alternative add a callback into a userpsace helper in an OLPC-specific cpuidle governer but jumping back into userspace from this deep in the idle path is probably very unsafe to do. The simplest thing to do would be to have our device present a state that has a very long latency value corresponding to full system suspend so that the existing framework can just work. I'm not sure how well the kernel would handle us triggering a suspend from within the kernel either, but only one way to find out. :) ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _____ __o (o> ------ -\<, Give One Laptop, Get One Laptop //\ ----- ( )/ ( ) http://www.amazon.com/xo V_/_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel