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

[Jordan Crouse]

On 03/11/08 09:31 -0800, Deepak Saxena wrote:
> [cc:ing devel]
> 
> My understanding of cpuidle is that it is designed to be fairly CPU/system
> agnostic with a clean driver interface to allow for tweaking the CPU/SOC
> idle control. There is even an ARM port [1] but as you will see in that
> email, the nomenclature for CPU idle states has been heavily borrowed from 
> the ACPI definition (C-states) as that is what the X86 world uses
> everywhere.  If we dont' want to use ACPI (my vote), I'm thinking we can 
> write a a low level driver that talks directly to the HW to move us between 
> "C-states".  Looking at the Geode documentation [2], it only seems to 
> support running, halt, and sleep state (Jordan, is this correct?) and
> I can't imagine it being difficult to write a driver to switch between
> these if the raw HW is documented.

Yes, in classic ACPI terminology, we only support C1 through the 'hlt'
instruction).

> I want to make sure everyone understand what CPUIdle does as I've heard
> some comments that lead me to believe people expect more out of it.
> It is meant as a framework to help move the CPU between high and low latency 
> idle states based on recent CPU usage patterns, latency requiremenents and 
> any other things that we care about in the heureistic algorithm (the governor).
> 
> We still have to things like keep track of how long it has been since a user 
> interacted with the device and whether the audio devide is open, etc to determine 
> whether we want to do a full system suspend or not. While we could push all 
> that into the governor, I think it would be massively overiding the framework. I 
> want to clarify this b/c I recall someone saying something along the lines
> that cpuidle will help us figure when to suspend and that is not the
> case. It is meant only for CPU idle state management, In our case, when the
> system is fairly idle, we want to put the whole system to sleep, not just
> the CPU.

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.

Jordan