ACPI on XO (was: Re: [Techteam] Weekend 10/31)
dsaxena at laptop.org
Mon Nov 3 12:31:22 EST 2008
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  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 , 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.
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
 May 2008 version, Page 599, Power State Parameter Definitions
On Nov 03 2008, at 10:11, Adam M Belay was caught saying:
> Hi Richard,
> That's correct, there shouldn't be any hard dependencies with ACPI.
> However, it
> was the first interface supported, so there could be some cruft
> remaining. I'd
> be interested in hearing more about the issue.
> Quoting "Richard A. Smith" <richard at laptop.org>:
>> Jim Gettys wrote:
>>> CPU idle shouldn't be entangled with ACPI. People on non-x86 will care.
>>> So think your proposed "fix" is wrong; but should go into trac against
>>> the kernel, and a patch for the fundamental kernel fix developed....
>>> - Jim
>> I hope that indeed I'm incorrect on this but when I tried to follow
>> the code init/working path for cpuidle thats where I wound up.
>> If the kernel hackers can give me a quick 2nd opinion I'll be happy to
>> file a bug with the results.
>> Richard Smith <richard at laptop.org>
>> One Laptop Per Child
Deepak Saxena - Kernel Developer, One Laptop Per Child
_____ __o (o>
------ -\<, Give One Laptop, Get One Laptop //\
----- ( )/ ( ) http://www.amazon.com/xo V_/_
More information about the Devel