Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Paul Fox wrote: > perhaps this should be obvious, but can it handle S-states as > well? because i believe that's the goal -- freeze the display > and then go into S3. I just stumbled across the Design Scenarios for Linux's Power Management Quality of Service system, courtesy of Intel. [1] Notable inclusion: """ # Platform Suspend * you can put the system into S3 or S4, as a function of acceptable wake up latency * you can specify the delay in dropping into a suspend state as an idle time out """ I don't know exactly what this means, if anything, but it sounds good. [1] http://www.lesswatts.org/projects/power-qos/design-scenarios.php signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
John Watlington wrote: > We have often discussed the need for an audio DCON. > It wouldn't take much -- the amount of memory required > for a second of playback/record could be included in > the codec. > > wad My impression is that the codec does DMA to memory for recording and playback. If DMA works during CPU suspend, then it seems like playback should "just work". In fact, if the buffer's big enough, the interrupts issued by the codec should be able to wake the CPU up in time to refill/empty the buffer without a glitch. The power domain charts for XO-1 and XO-1.5 don't quite tell me whether the codec, amplifiers, northbridge, and southbridge are enough powered in suspend for this to work. I imagine not, though, so audio playback will probably have to inhibit suspend in XO-1.5. I do not think this will be difficult to implement in software. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
We have often discussed the need for an audio DCON. It wouldn't take much -- the amount of memory required for a second of playback/record could be included in the codec. wad On Jul 20, 2009, at 4:41 PM, Richard A. Smith wrote: > Benjamin M. Schwartz wrote: > >> >> To handle unpredictable interrupts, cpuidle uses recent history to >> predict >> the frequency of future interrupts, and then chooses processor >> states to >> meet an associated latency requirement. It seems likely to me >> that this >> will avoid any need for a special idleness API. > > How will it do with an app like acoustic measure? > > -- > Richard Smith > One Laptop Per Child > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
On Jul 20 2009, at 16:49, Chris Ball was caught saying: > Hi, > >> perhaps this should be obvious, but can it handle S-states as >> well? because i believe that's the goal -- freeze the display >> and then go into S3. > > Looks like no. We could invent a C-state that traps to SMI and goes > to S3 except I hate this idea already. We can use a custom userspace governor that when switching states also freezed DCON. It's been a while since I looked at cpuidle but is on the queue of things to poke at. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Benjamin M. Schwartz wrote: > Audio playback and recording don't use userspace timers, but they do > generate a lot of interrupts. If cpuidle does something even marginally > sane with interrupt history, it should not go into a high-latency sleep > state during sound playback or recording. If it does, audio will skip, > but the CPU will be woken up by every interrupt delivered from the sound > card. (It occurs to me that this probably should've happened for the XO-1 > too, but it didn't. Maybe the EC is not handling those interrupts properly?) On second thought, the Geode's audio codec was probably powered off along with the CPU. I imagine there's a way to use the kernel's Power Management QoS to prevent this from happening, but I don't know the details. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Chris Ball wrote: > Hi, > >> perhaps this should be obvious, but can it handle S-states as >> well? because i believe that's the goal -- freeze the display >> and then go into S3. > > Looks like no. Oh? From looking at the code? Do you mean that it can't, or that it doesn't now? > We could invent a C-state that traps to SMI and goes > to S3 except I hate this idea already. I think there's a good argument that S3 with the DCON freeze is very different from the classic notion of "suspend", and so warrants its own designation. More importantly, though, I don't think cpuidle is limited to ACPI states. I think you can plug in any "state" you like, if you have code to enter and leave it. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Richard A. Smith wrote: > Benjamin M. Schwartz wrote: > >> >> To handle unpredictable interrupts, cpuidle uses recent history to >> predict >> the frequency of future interrupts, and then chooses processor states to >> meet an associated latency requirement. It seems likely to me that this >> will avoid any need for a special idleness API. > > How will it do with an app like acoustic measure? I see what you're saying. (This program proved a problem in the past because it would use very little CPU while playing and recording sound, resulting in idleness detection kicking in and turning off the CPU entirely.) Audio playback and recording don't use userspace timers, but they do generate a lot of interrupts. If cpuidle does something even marginally sane with interrupt history, it should not go into a high-latency sleep state during sound playback or recording. If it does, audio will skip, but the CPU will be woken up by every interrupt delivered from the sound card. (It occurs to me that this probably should've happened for the XO-1 too, but it didn't. Maybe the EC is not handling those interrupts properly?) Hopefully, this shouldn't be a problem even if cpuidle is dumb, because drivers can specify their latency requirements explicitly using pm_qos_add_requirement(). During recording, the sound driver should set a low enough interrupt latency requirement so that buffer overruns do not occur. cpuidle will then not enter states with too high an interrupt latency. I believe the HDA audio driver code already does this. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Hi, > perhaps this should be obvious, but can it handle S-states as > well? because i believe that's the goal -- freeze the display > and then go into S3. Looks like no. We could invent a C-state that traps to SMI and goes to S3 except I hate this idea already. - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
On Mon, 20 Jul 2009, Richard A. Smith wrote: > Benjamin M. Schwartz wrote: > >> >> To handle unpredictable interrupts, cpuidle uses recent history to predict >> the frequency of future interrupts, and then chooses processor states to >> meet an associated latency requirement. It seems likely to me that this >> will avoid any need for a special idleness API. > > How will it do with an app like acoustic measure? if the mic or the camera are running, you need wakeups to deal with new data frequently enough that you will not be able to sleep, but you may be able to slow down the CPU and still keep up with the incoming data. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Paul Fox wrote: > benjamin m. schwartz wrote: > > cpuidle is already used by the kernel to select the ACPI state, but it is > > possible to add more states as well. Therefore, it seems to me that the > > logical thing to do is to add the "frozen" state to cpuidle's menu. > > perhaps this should be obvious, but can it handle S-states as > well? because i believe that's the goal -- freeze the display > and then go into S3. My impression is that this has never been done, presumably due to the absence of a DCON on other ACPI machines.I know nothing about kernel internals or suspend-resume, so I cannot comment intelligently on the difficulty of supporting S3+DCON in cpuidle. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Benjamin M. Schwartz wrote: > > To handle unpredictable interrupts, cpuidle uses recent history to predict > the frequency of future interrupts, and then chooses processor states to > meet an associated latency requirement. It seems likely to me that this > will avoid any need for a special idleness API. How will it do with an app like acoustic measure? -- Richard Smith One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
benjamin m. schwartz wrote: > Richard A. Smith wrote: > > In any case time based suspend is not where we want to go anyway. We > > need proper idle detection and some sort of API such that apps which > > have a workload that idle detection is difficult can specify that they > > need idle-suspend. > > I'm repeating myself (I promise I'll stop) but the method for this in > Linux is "cpuidle".[1] cpuidle is incredibly poorly advertised, but it's > a very good system. It maintains a list of all available CPU states, > along with the latency to enter and exit them. Because it operates inside > the kernel, mode selection can be made with full knowledge of any upcoming > timed wakeup requests from userspace. > > To handle unpredictable interrupts, cpuidle uses recent history to predict > the frequency of future interrupts, and then chooses processor states to > meet an associated latency requirement. It seems likely to me that this > will avoid any need for a special idleness API. > > cpuidle is already used by the kernel to select the ACPI state, but it is > possible to add more states as well. Therefore, it seems to me that the > logical thing to do is to add the "frozen" state to cpuidle's menu. perhaps this should be obvious, but can it handle S-states as well? because i believe that's the goal -- freeze the display and then go into S3. paul > > --Ben > > [1] http://lwn.net/Articles/221791/ =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Richard A. Smith wrote: > In any case time based suspend is not where we want to go anyway. We > need proper idle detection and some sort of API such that apps which > have a workload that idle detection is difficult can specify that they > need idle-suspend. I'm repeating myself (I promise I'll stop) but the method for this in Linux is "cpuidle".[1] cpuidle is incredibly poorly advertised, but it's a very good system. It maintains a list of all available CPU states, along with the latency to enter and exit them. Because it operates inside the kernel, mode selection can be made with full knowledge of any upcoming timed wakeup requests from userspace. To handle unpredictable interrupts, cpuidle uses recent history to predict the frequency of future interrupts, and then chooses processor states to meet an associated latency requirement. It seems likely to me that this will avoid any need for a special idleness API. cpuidle is already used by the kernel to select the ACPI state, but it is possible to add more states as well. Therefore, it seems to me that the logical thing to do is to add the "frozen" state to cpuidle's menu. --Ben [1] http://lwn.net/Articles/221791/ signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Deepak Saxena wrote: > So far our minimal testing shows that we may be able to freeze > on 5 seconds of inactivity instead of 30 and not see a glitch > in the screen contents. I don't quite understand this. There should not be any difference for screen glitching between 5 seconds and 1 second or even less than 1 second. 30 seconds was a compromise number that allowed a fair number of apps to still behave properly when idle-suspend was enabled. XO-1.5 firmware supports timed EC wakeups and there are timers in the via chipset that operate from the suspend well so power wise we would be much better off to have the idle time set at <=1 second or and a timer wake the system up every 5 seconds if you needed that level of granularity. In any case time based suspend is not where we want to go anyway. We need proper idle detection and some sort of API such that apps which have a workload that idle detection is difficult can specify that they need idle-suspend. -- Richard Smith One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Deepak Saxena wrote: > simply grabbing that irq via request_irq() causes USB > device insertion (and other things?) to break. I had a related problem in OFW - enabling the SMBALRT# pin (for DCON use) caused immediate wakeups from suspends (in OFW-based testing). OFW's solution is to enable SMBALRT# for the shortest possible time, just when it is being tested. I wonder if a similar narrow-enable approach could be used with request_irq()? I can see how that might be tricky. Alternatively, could Linux avoid using interrupts for that DCON sync function, polling with interrupts disabled like OFW does? The overall system performance impact should be small, since the maximum wait time is only one video frame, and it only happens a freeze points, which are presumably times of low activity. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
