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.

Hi, sorry for newbie questions but it will be a while before I can catch up.

I understand that when apparantly powered off the WiFi Mesh will keep forwarding while almost everything else is off. This implies there is no way the WiFi could use external RAM buffers so it could implement some QoS policies. Also no way to store an incoming feed to flash. Am wondering whether changes to that are feasible. If so I'll write details on why it could be important enough to do in next HW rollout even though no software actually using it for a while.

Q1. Is there already some way to keep a small amount of RAM on during the WiFi only state, without consuming excessive amounts of power. eg Just the RAM that would be used to freeze the DCON display in suspend mode (but without also powering the LCD itself).

Q2. If not, would it be a minor engineering change that could be implemented (including the ability for the WiFi, perhaps with the aid of the embedded controller, to write to it and read from it) without adding significantly to manufacturing delays and costs?

Q3 Relevant (approximate guesstimate) power drains for: a) WiFi only when mainly dozing waiting for traffic. b) WiFi only when heavy mesh traffic relaying. b) Plus the small amount of RAM when only doing self refresh. c) Plus the small amount of RAM when being read only. d) Plus the small amount of RAM when also being written.

Similar questions for being able to copy stuff out of these RAM buffers to flash. (I am assuming an entirely separate dedicated partition using a circular buffer instead of jffs).

Q4. Is there already some way in which the WiFi and embedded controller could control this without waking up the CPU?

Q4. If not would making that possible be a minor engineering change?

Q5. If not would it be possible to wake up the CPU briefly, without loading a full kernel but just enough to do this kind of stuff (as in the boot process before kernel and drivers loaded)? How long would that be likely to take?

Q6. Relevant (approximate guesstimate) power drains and delays for: a) Reading from small amount of RAM and writing to Flash b) Reading from flash and writing to small amount of RAM c) Waking up CPU to do this stuff.

Thanks. Arthur (first post)