The power management code was erroneously shuting down the 4.2V rail
when charging is complete. This resulted in the DCDC draining the battery
and thus the battery discharging with USB plugged...
The new code keeps the 4.2V rail active so that battery remains untouched
once charge is complete.
Change-Id: I36e8d31e8115c12ce813c939c5d7bbf2c3490157
NOTE: this commit does not introduce any change, ideally even the binary should
be almost the same. I checked the disassembly by hand and there are only a few
differences here and there, mostly the compiler decides to compile very close
expressions slightly differently. I tried to run the new code on several targets
to make sure and saw no difference.
The major syntax changes of the new headers are as follows:
- BF_{WR,SET,CLR} are now superpowerful and allows to set several fileds at once:
BF_WR(reg, field1(value1), field2(value2), ...)
- BF_CS (use like BF_WR) does a write to reg_CLR and then reg_SET instead of RMW
- there is no more need for macros like BF_{WR_,SET,CLR}_V, since one can simply
BF_WR with field_V(name)
- the old BF_SETV macro has no trivial equivalent and is replaced with its
its equivalent for BF_WR(reg_SET, ...)
I also rename the register headers: "regs/regs-x.h" -> "regs/x.h" to avoid the
redundant "regs".
Final note: the registers were generated using the following command:
./headergen_v2 -g imx -o ../../firmware/target/arm/imx233/regs/ desc/regs-stmp3{600,700,780}.xml
Change-Id: I7485e8b4315a0929a8edb63e7fa1edcaa54b1edc
The current code does hazardous tweaks to the power subsystem: indeed if one
boots with USB plugged and some stub powers on the DCDC switch, it will fail.
Indeed, a hardware bug prevents from going back to linear regulators (see
errata) so we cannot expect to reach a known state (linreg on, dcdc off)
on each configuration and in particular, powering down the 4p2 rail in
such a configuration will result in a power brownout.
This commit works around this issue by not touching the initial power
configuration until USB is (un)plugged, which are the best spots to get
known states.
Change-Id: I8741a3995df8ae61ca1c887a3ecb7903d0ac5136
The current code was spreaded over power and powermgmt which made
it behave strangely, especially since there are relationships
between power management and frequency scaling. The new code makes
sure power management is initialised before frequency scaling
starts. It also makes sure to start from a known state, thus
fixing potential issue when the bootloader stops in a trickle
state where DCDC is improperly configured.
Change-Id: Ibded2e590e108f6c98daa52d2cf1bd28763c8923
Power management is somewhat different on stmp3700 which doesn't
have the 4.2V rail and completely different on stmp3600 which has
several DCDC. Currently only handle imx233.
Change-Id: Ic7815141286117b74022ffc53cfa48664fd7faac
* Introduce CONFIG_BATTERY_MEASURE define, to allow targets (application)
to break powermgmt.c's assumption about the ability to read battery voltage.
There's now additionally percentage (android) and remaining time measure
(maemo). No measure at all also works (sdl app). If voltage can't be measured,
then battery_level() is king and it'll be used for power_history and runtime
estimation.
* Implement target's API in the simulator, i.e. _battery_voltage(), so it
doesn't need to implement it's own powermgmt.c and other stubs. Now
the sim behaves much more like a native target, although it still
changes the simulated battery voltage quickly,
* Other changes include include renaming battery_adc_voltage() to
_battery_voltage(), for consistency with the new target functions and
making some of the apps code aware that voltage and runtime estimation
is not always available.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31548 a1c6a512-1295-4272-9138-f99709370657
