ACPI on XO (was: Re: [Techteam] Weekend 10/31)

[Jordan Crouse]

On 03/11/08 13:12 -0800, Deepak Saxena wrote:
> 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. :)

I said that we needed to walk down a decision tree, but I didn't say
that the idle detection needed to be the first branch.  Certainly,
we can do much of the math in userspace, and perhaps we can turn it
into a binary (allow_suspend && enough_time) in the idle loop or
appropriate hook.  But if we want to suspend on idle, then we need to
do it while are... you know... idle - so something  has to live there.

I think we are basically saying the same thing here - userspace needs
to give us the go-ahead to suspend, and we need to have the right
latency programmed so that if all is well, we just suspend.  Or at least,
we'll try to suspend and hope like heck it works.

Jordan