GTA series power design

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Dear Harald:
|>
|> I think there needs to be a lot of research/planning into the high-level
|> power management profiles.  I think top-down engineering is the better
|> approach here.
|>
|
| Yes, but this comes from 2 point of view, 1 from linux itself, the other
| one is product specific/centric. handhold/portable device is heavily
| hardware based power management and custom fine tune process. Do we have
| better way out of here?
|
| I think this is some of the essential question of linux in embedded
device.

Agreed but I think we can find a way that is OK for everyone.

Because we will probably find a similar large step in 6400 CPU power
between suspend with RAM in selfrefresh and PLLs and Core off, and the
lowest power state for the CPU that we find in 2442, CPU suspend will
still be especially important for optimum results on power.  If this is
true then it means that good battery life --> Linux will be suspended as
much as possible, just the same as we all agree keeping the backlight
down as early as possible if we think the user does not interact with us
is necessary for reasonable power consumption.

However when the CPU goes in and out of suspend, it goes through the
normal suspend and resume driver actions and has the chance to make
power arrangements in there.  So it doesn't really mean that Linux stack
is pushed out of power management, really it can largely or completely
control it still.  So Linux-driven power stack is important.

Something that I think can work well was in-driver power management
based on open handles from userspace.  We do this on motion sensor
driver, if nothing has the input events open then the interrupts are not
serviced... we can do better and remove power from motion sensors too.
Again if we do not perform any read of battery then HDQ FIQ does not
run, driven by if usermode has sys node open.

Cesar had the idea that we break out low power / operation configuration
action from suspend / resume functions and are able to use it even when
in CPU active mode, this is a great idea to make a single implementation
of low power mode for a peripheral that also includes power switching
decision, but which can be deployed when the CPU is up just not using
the peripheral.  When combined with monitoring open handles for some
cases anyway it can be pretty optimal power behaviour without any API.

|>> **WLAN (SDIO/SPI?)
|>
|> SDIO has better software support.  SPI only if high-speed SPI (higher
|> clock rates, e.g. 25-40MHz)
|>
|
| I think should keep using SDIO if possible, but still need SD/MMC card
| interface is the problem.

It seems we have three available on 64x0 so it is OK I think.  I think
SDIO is better just on the basis we have a pretty working SDIO WLAN already.

|>> **Bluetooth (USB/others?)
|>
|> USB is a bad choice since it both consumes a lot of power in the
|> software stack and host cpu, as well as the lack for proper wakeup
|> handling (separate gpio/irq lines, complex software resume path, etc.)
|
| I don't think we will keep using USB for this :)

Sounds good.

| Following type of product may be the case, switch behavior base on
| different case, just saw in news recently.
|
| http://www.modumobile.com/

Pretty big architecture change if we wanted to do this :-)  I guess it
means to license a connector, it's a sort of IPod accessory idea the same.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkf4vekACgkQOjLpvpq7dMpzvwCggmtlYWGQ+06DXw7yDsRasfDw
xgQAoJKpYCFwBosP6aIAstmzEbVCtd8M
=RIeP
-----END PGP SIGNATURE-----