Talk:Hardware Power Domains

Power Domain Discussion

CaFe Chip, SD Controller Section

If the SD-Card would be switched into MMC mode, then IIRC the only way back is to power cycle the SD-card. --Frief 03:58, 13 September 2006 (EDT)

No support for optional ACPI Sleep state S2

• S2 is uninteresting. IMHO - its a vague state literally defined as "higher latency then S1 but lower latency then S3". Not sure if your itention here is to mention that S2 *should*

be supported, or just commenting that it isn't. - JordanCrouse (Talk to me!) 18:58, 12 September 2006 (EDT)

C1 Test

This confused me for a second - what you're talking about is really more of a poor man's S1 - turning off pratically everything we can, turn off the PIT, and then enable wakeup devices and go to a hlt. A more correct name might be low-latency S1, because it will be slower then a C state transition (obivously) but it should be faster then a S1 transition.

This is quite similar to a tickless system, except that we turn off more devices. The only question is - how quickly can we turn off and turn on the un-needed devices, and does that latency fit within the average idle timesice of a nominally busy kernel? I believe that we can measure the average length between timeouts in the kernel with Systemtap - that would be useful information to have. If we can make this all fit - it would be a heck of a cool thing. - JordanCrouse (Talk to me!) 19:16, 12 September 2006 (EDT)

Another question - keeping in mind that we can't lose context in this mode - what devices would we possibly shut off that would have an effect on the total power consumption during C1? - JordanCrouse (Talk to me!) 19:40, 12 September 2006 (EDT)

two enhancements

It is not power-efficient to do PCI config space access via SMI/SMM. Linux supports multiple PCI config space accessor functions. Linux itself can do whatever the SMM/SMI stuff is doing, calling the code from the generic PCI code via a function pointer.

Disable the TSC and turn off the counter in the CPU. If an app needs it, the app will fault into the kernel and then the kernel can enable the TSC until that app is done running. You can keep a count of apps that are known to need the TSC. When the count reaches zero, turn off the TSC until another app faults. When turning on the TSC, update it from the RTC in case an app is using the TSC for time.

Problem with B3 Diagram

I noticed that there are blocks that are marked in orange and the key says this is "Powered when Running (S5)". This should be S0. The key for yellow (powered in suspend and run) should be marked as S3,S0.

Also, I'm not sure why the 802.11 would be powered continuously. Normally it would just be powered occasionally, and only while in the S0 state.