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
Re: ACPI on XO
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. 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? Thats what I'm proposing as one of the first steps and I was starting with cpuidle (perhaps incorrectly). Replacing the current simplistic decision with something that we can mold into the Right way. If cpuidle can't give us all the kernel info then we need start thinking about what can. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ACPI on XO
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/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ACPI on XO
___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
