ACPI on XO

[Deepak Saxena]

On Nov 03 2008, at 17:11, Richard A. Smith was caught saying:
> Jordan Crouse wrote:
>
>> 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.
>
> I appear to have completely the wrong idea of what cpuidle would do for  
> us then wrt suspend decisions.  I thought that cpuidle had the ability  
> to report that the _system_ was idle.  For example if we are doing lots  
> of DMA the cpu usage is very low but the system is far from idle.  Only  
> the kernel has the proper knowledge of everything thats going on under  
> the hood.

So CPUIdle can theoretically do things like change cpu idle states 
based on DMA latency requirements that are programmed via the
new PM QOS interface; however, that interface is not too well 
defined. 

I just had a conversation with one of the TI-OMAP Linux developers 
and they have hooks in their CPUidle code to detect bus master 
activity to determine what state they can be in. On their end
this is done by using the clock framework in the kernel to see
if any bus master devices are in use and whether it is safe to 
go into full idle state (C6, which on their chip is == OFF).

We could do something similar by having a C state that is full suspend
and doing simple checks like "is the audio device open", but this requires 
trusting applications to not open a device and just keep it open while it 
is not in use. Or.... we could add a "cpuidle" state to /sys/power/state 
and when OHM knows that it is safe for us to suspend on idle, it can write 
that to the file.

> Where the ultimate decision to suspend is made doesn't seem to so  
> important as the getting the inputs to that decision correct.  We don't  
> appear to have a plan on how to get all the inputs.  Do we?

No we don't and I really need to help out with the kernel side of things 
but I'm not sure I knows all the requirements and use cases which is the 
first step.  We need to list out all the decision criteria then figure out:

1. Where that information is currently stored
2. Where it needs to go for the suspend decision (OHM, an in-kernel structure, ?)
3. How to get it there (uevent, in-kernel callback, userspace helper, ?)

~Deepak

-- 
 Deepak Saxena - Kernel Developer, One Laptop Per Child
   _____   __o                                   (o>
------    -\<,  Give One Laptop, Get One Laptop  //\
 ----- ( )/ ( )  http://www.amazon.com/xo        V_/_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~