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.

Questions on access from WiFi to RAM and Flash during WiFi only power off mode

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

{After reviewing recent much more detailed explanations in Power Management I now understand that WiFi Mesh does not continue relaying in "powered off" state but rather continues with "CPU suspended to RAM" state. Was confused about this because the B3 power domains diagram shows WiFi chip in Green "Powered Continuously" domain like Embedded Controller but SDRAM in yellow "Suspend and Run" domain. Not sure whether it is just me or whether diagram should be more clear. Some questions below are clarified while others remain, so adding these notes in curly brackets.}

I understand that when apparently 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?

{A1 and A2. All of RAM is available without needing any engineering changes or tricks with DCON. WiFi just has to wake up the CPU which may take something like 100 ms. This implies that a 4KiB packet could be transferred from incoming WiFi flow delivering 32 Kibps via RAM to flash by waking up CPU about once per second. If the 94KiB RAM on the WiFi chip had room for more to be buffered within the WiFi then it would be possible to download while suspended at a higher rate or wake up even less often, but once per second is not a big problem for power management.}

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.

{Based on above I am assuming that doing large downloads by a WiFi trickle overnight, say at 32Kibps, would not unduly drain power compared with just relaying. eg 100MiB could be downloaded to flash over about 6 or 7 hours at a rate of about 256KiB per minute. Please confirm - or correct me if I am wrong.}

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).

{Since the full OS kernel is resuming from suspension it is no problem to use jffs and no need for a separate dedicated partition).

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?

{A4 and A5. Do need to wake up the CPU, but it is only suspeneded with full kernel in RAM so no problem.}

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)

{Note: 1 If cost of flash continues to fall at 65% p.a. it is easy to imagine XOs wanting to download much more than 100MB overnight to their (large) MMC/SD cards - eg DVD 4.5GB cf 64GB flash drives already announced for video cameras. If the possibility arises of having larger RAM within the Marvell 88W8388 WiFi chip so as to wake Geode CPU less often, the trade off with download speeds and battery usage should be considered in deciding whether to do it. In particular a multicast or broadcast of far more than 1GB overnight would be within network capacity as well as within future MMC/SD flash capacity, since the mesh could permit much larger bandwidth for shared stream than say 32Kibps for individual downloads, but could be limited by having to wake up CPU too often unless more RAM within the 88W8388. (There are protocols that could request replacements for occasional missed packets to turn an unreliable stream into a reliable download.) Also note that broadcasts and multicasts would be throttled by slowest participant so better to add RAM early than late to avoid mixture of deployments with old XOs that have less WiFi RAM slowing down later models.}

{Note: 2 A store and forward multi-cast network (like news feeds) would save power provided sufficient nodes have "subscribed" to a given feed so that they can store it in large chunks in flash for their own use as well as pass it on, since they can wake up less often, but stay awake for longer chunks transferred at higher rates for each chunk without needing more RAM within the 88W8388. See The Power Aware Streaming Proxy Architecture. However presumably nodes that are not subscribed to the data themselves should not wear out their flash by repeated writes for passing traffic. It would still be desirable to multi-cast chunks to all those neighbours subscribed at once, and still necessary to limit the bandwidth used for chunks so that other traffic is not choked off. These are software/protocol issues more or less independent of hardware power saving design.}

{Note: 3 Additional internal RAM on future replacements of the 88W8388 is likely to be useful for other aspects of QoS queueing when implementing MAC extensions for Mesh Deterministic Access (MDA is a major enhancement to 802.11e for VOIP traffic over 802.11s) and Congestion Control. Enabling other XOs to be in STA mode with only some acting as both Mesh Points and Access Points for forwarding allows those "leaf" XOs to "doze" for long periods but requires the APs to buffer traffic for them. Typically this is done by an AP with plenty of RAM and power. The 88W8388 is intended for mobile WiFi STAs in cell phones, PDAs etc that are expected to save power by dozing rather than designed for APs assisting mobile Stas to doze by buffering traffic for them. Rotating the role of AP and MP could save power overall because only 1 of a set of XO nodes would be consuming more power by buffering traffic as an AP and MP, while several would be enabled to doze more as STAs. At any rate, even if 32Kibps and 1 wakeup per second does turn out to be acceptable for overnight flows, additional RAM would certainly result in non-marginal improvements.}

{Note: 4 If a WiFi System On Chip with more internal static RAM does not become available before Generation 2, it might be worth considering whether to add external static RAM used only by the Wifi. Perhaps the design could switch to use the MMC/SD interface approach rather than USB and the CAFE ASIC might provide the WiFi enablement as well as the flash controller and camera. This might be easier for adding direct access to external RAM independent of whether the Geode CPU is sleeping.}