Last week was a busy week in XO-1.5 kernel land.
* Attacked the DCON driver and it is now 75% functional. We can
freeze/unfreeze, set brightness, and switch between color and
monochrome mode via the syfs attributes. In the process of getting
the DCON working, I broke USB and spent a day
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
