ACPI on XO (was: Re: [Techteam] Weekend 10/31)
[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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] One Laptop Per Child -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o ---\, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] Weekend 10/31
On Nov 03 2008, at 12:45, Richard A. Smith was caught saying: drivers/acpi/processor_core.c: result = cpuidle_register_driver(acpi_idle_driver); looking at this file I see that its called from static int __init acpi_processor_init(void) This is the same routine that creates a /proc/acpi directory which does not exist on the XO so that plus the fact that I know we have ACPI disabled I'm assuming that this routine is not called. Further greping for 'cpuidle_' I find that the only places cpuidle_ functions are called is in drivers/acpi/processor_core.c and driver/acpi/processor_idle.c . If its used in another archs besides x86 can you point me to the code? Perhaps I'm not grepping for the right thing? drivers/acpi/processor_idle.c:acpi_processor_power_init() calls driver/cpuidle/cpuidle.c:cpuidle_register_device(). This in turn calls cpuidle_install_idle_handler() which sets the pm_idle pointer to cpuidle_idle_call(). pm_idle() is called by arch.x86/kernel/proccess_32.c:cpu_idle(). cpu_idle_call() calls the governor's select() function which pokes at various the bits int the cpuidle_device structure and the current system state to determine the next state and returns an index into the cpuidle_device's state table. We then index into the state table, and call the state's enter() function to perform the actual CPU swtich. It looks like to make it work with a non-x86 arch, one would have to hook the pm_idle() call into the the cpu_idle() routine, for example arch/arm/kernel/process.c:cpu_idle() on ARM. In our case, we would want to register an olpc_idle_driver and an olpc_idle_device that exports the known states. Once those are in place, the generic x86 cpu_idle() call will call into them via the framework. [1] cpuidle is very hard to google for usage info. There is lots of unrelated hits that use the term cupidle. Is there a good reference for the stuff thats exposed to userspace other than whats in the kernel docs? I haven't found anything super useful except for reading the code. linux-pm list is probably the best place to go for more details. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o ---\, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ACPI on XO (was: Re: [Techteam] Weekend 10/31)
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ACPI on XO (was: Re: [Techteam] Weekend 10/31)
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. :) ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o ---\, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ACPI on XO (was: Re: [Techteam] Weekend 10/31)
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel