At normal loads:
- disabling auto slow boosts performance at the cost of runtime (~ -5%)
- disabling at max cpu does not noticibly decrease runtime
Change-Id: I5de80201c9a24ce556862151cbd6b21b01708b63
Playing AAC-HE files resulted in a race condition between
audio/codec/buffering for set_cpu_frequency
Change-Id: I35e1c1fd18db623e2990c305acdca03f57184d0d
The ZEN/X-Fi (STMP3700) don't handle memory frequency scaling really well, for
this reason we run it at a fixed frequency. That frequency was previously set
to 64Mhz because when the CPU run at its lowest frequency, we set the VDD voltage
to 0.975 V and on STMP3700, VDDD=VDDDMEM and this is too low to run EMI at 130Mhz.
This is not a good solution because under heavy load, running the EMI at 64Mhz
results in frame drops and a sluggish device. Thus we now run the EMI at 130Mhz
all the time now. To do so, increase the minimum VDD voltage to 1.275 V.
This may result is a decreased battery life on those targets but it will also
avoid all sorts of glictches and all the device to truly run at full speed.
Change-Id: Ia8391492c29fe67bc2701aa7d8cfd00a9df349e8
Running at 130MHz is unsafe since on those targets, we disable memory frequency
scaling because it is unstable. That leads to situation where cpu is running at
64MHz and VDD is at 1.050V. But on STMP3700, the EMI uses the VDD rail instead
of a dedicated VDDMEM rail as on STMP3780. Thus we are essentially running the
EMI at 130MHz at 1.050V when the minimum recommened voltage is 1.2V. This commit
runs the EMI at 64MHz all the time on the ZEN and ZEN X-Fi which will lead to
reduce performance but hopefully increases stability.
Change-Id: Ida6c2ec130b1778973e383d7c44a06a6ca8f9268
It handles GPIO and PWM based LEDs, possibly with several channels (red-green
LED for example). The debug allows one to play with the setting.
Currently the code supports the ZEN, ZEN X-Fi, and ZEN Mozaic.
Change-Id: I8c3b66e6ba21778acdb123daabb724280a7d1a4f
The IRQ handler saves registers on the IRQ stack, saves the old PC to imx233
HW_DIGCTL_SCRATCH0 register and switcht to SVC for the actual handling. The
old code had a problem in that if the unwinder is called during the IRQ (for
example by the watchdog), then __get_sp() will use SPSR_svc to discover the
previous mode, switch to it and recover SP. But SPSR_svc is invalid, it should
be SPSR_irq but we switch from IRQ to SVC mode. The new code copies SPSR_irq
to SPSR_svc in IRQ to fix this problem. It also saves/restore SCRATCH0 in
case I one day renable nested interrupts or use SCRATCH0 for other purposes.
I also changed the old watchdog code to call UIE directly instead of trying
to make the code crash with a SWI.
Change-Id: Id87462d410764b019bd2aa9adc71cb917ade32e3
The old code used button_get() to read the button status and wait for a
key to leave the panic screen. This is broken since when IRQ are disable,
the button mask is not updated anymore for touchpad and adc buttons. For
now, only use pswitch: this should be good enough for all targets.
Change-Id: I0ae179e24555ac20c3d2bf2d267c1bb0e2ceded0
The old timrot setup API was very low-level and unfriendly. The new one
makes in easier to select the frequency source. Use to simplify timer
and kernel timer code.
Change-Id: Iffcdf11c00e925be9ec8d9a4efc74b197b6bd2aa
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
On those targets, since the LCDIF cannot recover from underflow, changing the
EMI frequency kills one frame and cause flicker.
Change-Id: Id3c130636bcfddcc6c54896602699fbaa1636ab4
The hardware watchdog automatically shutdown the device after 10s of
inactivity, being defined as 10s without the tick IRQ fired (aka braindead
device).
The software IRQ mechanism is more interesting: it uses a very high priority
timer setup as one-shot to trigger after 5s of inactivity (but IRQ still
enabled). When detected, it patches the running code to insert a SWI
instruction so that on interrupt return it will trigger a SWI and produce
a meaningfull backtrace to debug the deadlock. This should allow to debug
freezes in IRQ context.
Change-Id: Ic55dad01201676bfb6dd79e78e535c6707cb88e6
Many imx233 targets boot in a very low performance mode, typically cpu and
dram at 24MHz. This results in very slow boots and very unstable USB
bootloader mode. Since cpu frequency scaling is disabled in bootloader in
rockbox, always make the frequency scaling code available and boost at boot
time.
Change-Id: Ie96623c00f7c4cd9a377b84dcb14b772558cfa4d
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
On the ZEN X-Fi2, the fractiona dividers are gated by the
bootloader and must be ungated before switching emi to pll.
Change-Id: I5df57ed5581054883da4cbb3b4f3ce3539391ab5
The clkctrl functions were becoming a mess. Normalise the names,
get rid of the xtal derived as special case and use the same
interface.
Change-Id: Ib954a8d30a6bd691914b5e0d97774ec9fc560c50
Move to a table based approach (scales better) and distinguish
between upward changes (increase frequency) and downward changes
(decrease frequency). This provides a better ordering of
operations and in particular it allows to avoid changing the
regulator while running at low speed since it takes a long time !
This should result in a much smoother scaling.
Change-Id: Iad7e5b61277e215f31c07877fbbad07ddde1171f
The manual recommands to tweak the arm cache settings on frequency
changes. The meaning of these values is undocumented but 0 seems
to be a safe value for all frequencies whereas 3 seems to be valid
only for low frequencies (<=64MHz ?)
Change-Id: Iaa8db4af8191010789cf986b1139ff259d73e2ed
CPU frequency scaling is basically useless without scaling the
memory frequency. On the i.MX233, the EMI (external memory
interface) and DRAM blocks are responsable for the DDR settings.
This commits implements emi frequency scaling. Only some settings
are implemented and the timings values only apply to mDDR
(extracted from Sigmatel linux port) and have been checked to
work on the Fuze+ and Zen X-Fi2/3. This feature is still disabled
by default but I expected some battery life savings by boosting
higher to 454MHz and unboosting lower to 64MHz.
Note that changing the emi frequency is particularly tricky and
to avoid writing it entirely in assembly we rely on the compiler
to not use the stack except in the prolog and epilog (because
it's in dram which is disabled when doing the change) and to put
constant pools in iram which should always be true if the
compiler isn't completely dumb and since the code itself is put
in iram. If this proves to be insufficient, one can always switch
the stack to the irq stack since interrupts are disabled during
the change.
Change-Id: If6ef5357f7ff091130ca1063e48536c6028f23ba
Do low level power init in system_init(). This can be needed
since imx233 must be able to frequecy scale atfer system_init()
and kernel_init() and this is only possible if power system was
initialised.
Change-Id: I27c66ec0dccd60bda26a45be24683c0bfe72c6da
When changing the cpu frequency, it is important to make sure that
HBUS stays at a reasonable frequency otherwise the chip will
crash. Special care is needed about auto-slow and clk_p/clk_h
ratio on intermediate steps.
Change-Id: Ief9f68ddf286caabe75c879718dac5027ab1560f
Frequency scaling seems to be unstable and causes the device to
freeze. It is unclear why at the moment, perhaps we need to ramp
up the vddd voltage to avoid a false brownout ?
Change-Id: I7aaea9d7c213922a65250fe50775fb785d430226
This does not scale the EMI frequency and keep the processor
betweel 261MHz and 454MHz. It can still be improve. The auto-slow
divisor could still be change, 8 seems reasonable for now
Change-Id: I639bb3f6b7f8efedc7dc58d08127849156eeb1b6
Implement PLL enabling/disable and unconditionally power the PLL
on startup. This is needed at least on the Zen X-Fi2.
Change-Id: Ib9ddfdeaf973cedded4b3586dd16aa95a61e78ba
