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: 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
