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