Power management

[nomis]

Could you clarify which devices can be powered on or off?

It looks like only the bits for the SD card and USB host have any effect. USB is currently left powered on all the time, so is there any significant benefit to powering down the SD card? Can USB be powered down with devices attached or will they be reset when this happens? (Linux can can handle determining when it is safe to do this.)

There appears to be no way to query for what is currently powered on so I can't see this integrating well with the kernel's power management unless everything is turned off at boot, otherwise as soon as one of either the SD or USB host devices is registered it's going to turn that on and turn everything else off.

I'm able to send any of bits 0..27 set to 1 to the power mailbox channel and it'll respond with the list of powered devices. Sending all bits 0 results in no response. Is there anything else I've missed available in its API? Is everything off at boot? It has just loaded everything from the SD card so that may still be powered on.

[popcornmix]

From Phil who wrote this code:
"The SD Card is powered off to save power. In practice the ARM keeps USB power on, but the interface allows it to be powered off.

The bits in use are SDCARD (bit 0) and USB (bit 3). The ARM keeps track of what it is requesting. The ARM must wait for something to be powered up before using it, so VC sends a response indicating the power state when something is powered up, otherwise it doesn’t bother so that the ARM doesn’t have to wait."

So, GPU won't power off devices without ARM telling it to, so ARM can keep track of what the current state is.
If needed I could add a way of querying the state (e.g. bit=31 set means return current state).

Note: you only get a response (of the new state) when transitioning something from off->on. If nothing is newly switched on, there is no response.

[nomis]

It can only keep track of the state if it sent the last power request - on powerup it's not clear what the current state is.

Bit 31 (with all other bits set to 0 - reserved for future use) to query the current state would be useful. Even if the kernel assumes that the power should be all off on boot this might be inconvenient in the future. By "the ARM" don't you really mean whatever is running on it, such as the Linux kernel?

This still doesn't tell me if/when I can safely power off USB... would it be possible (ignoring the ethernet device) to power down USB when nothing is connected without breaking any state in the USB host?

[popcornmix]

I would have thought you can't power off USB without cooperation from the linux dwc_otg driver. It will need to set registers to sensible values after power on.
Possibly by using suspend/resume, power management, or removing/adding module it could be persuaded to work but that is beyond my knowledge (dwc_otg was written by synopsys).

[nomis]

I'm assuming co-operation from the other areas of the kernel managing the device being powered off.

If you could add a bit 31 query option it'll make the logic easier and I'll do some testing by adding device suspend/resume to the 3.1.9 dwc_otg code to see if anything still works after power management.

(Given that it's only two devices it's tempting to just power them both on all the time and avoid the complication)

[popcornmix]

Updated firmware should support bit 31 to query power state.

[nomis]

Thanks, currently I'm powering on both devices on boot but the support is there to be able to turn them on and off when the mmc/usb drivers are added.