GTA series power design
Neng-Yu Tu (Tony Tu)
tony at openmoko.com
Sat Apr 5 10:48:28 CEST 2008
> 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.
>> *What PMU should we use for 6400/6410 (if we use)
> Samsung has designed a special PMU to accompany the 6400/6410.
> Actually, one of their partners in Germany or Austria did the PMU
> design. I think it is very hard to find any other stock component
Yes, Samsung S5M8750 one. But there still do not have any product using
6400 in MP scale yet. It hard to tell it at really reliable stage ;)
And we will also have document openness issue need to fix with samsung
>> **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.
I saw the 6400 support MIPI HSI interface, but I did not see any thinmg
in market using this yet (some 3G HSDPA chipset seems support it, but
non -popular in module)
>> **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 :)
>> **Accelerometer (SPI)
>> **GPS (UART)
>> **GSM/EDGE (UART)
> Only GSM/GPRS/EDGE will run on traditional UART. 3G chipset usually
> have dual-ported memory interface. I strongly recommend to not use USB
> here for the same reasons as with bluetooth.
EDGE still could use UART, but some 3G module seems trend to use USB.
Also have different multiplexer need to implement.
>> suit for device power management?
> the problem is mostly that the existing software deals a lot with what I
> would call 'power control', i.e. setting the devices into their power
> states. high-level power management will have to come from product
> The product specification would have to include individual power states
> of the device, and specify power consumption targets for the individual
Following type of product may be the case, switch behavior base on
different case, just saw in news recently.
More information about the openmoko-kernel