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

[Deepak Saxena]

[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.

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.

~Deepak

[1] https://lists.linux-foundation.org/pipermail/linux-pm/2008-February/016546.html
[2] 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.
>
> Thanks,
> Adam
>
> 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_/_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~