This requires adjusting the CPU voltage, so enable the axp20x driver for
A20 boards.
In evbarm/awin/awin_machdep.c, the DCDC powering up the CPU cores needs to
be defined for each board. The board machine-dependant code (at this time,
only awin_machdep.c) has to provide a awin_set_mpu_volt() function
which calls the right PMU driver to change the CPU core voltage.
The CPU frequency/voltage table in awin_board.c comes from various
sources: linux kernel, device tree and fex scripts, and experiments on
olimex lime2 and cubieboard 2.
The following sysctls are provided (compatible with estd):
machdep.frequency.min,machdep.frequency.max: writable lower and upper
bounds of the useable frequencies. Affects machdep.frequency.available.
Lower bound defaults to 700Mhz, as does linux.
Upper bound defaults to 960Mhz, which is the boot frequency
on the boards I tested. There is a 1008Mhz entry available,
but requires an out of spec CPU voltage (more than 1.4V) so it's
not available by default.
machdep.frequency.available: list of available frequencies. This is
the CPU frequency/voltage table, bound by machdep.frequency.{min,max}.
machdep.frequency.current: current CPU speed. Write a new value to change
the CPU speed, only values from machdep.frequency.available are
accepted.
not (AWIN_REF_FREQ * n * k) / m (m is only used for the SATA clock).
On the boards I tested, m happens to be 2 so the correct value was returned
anyway.
by a shiftout ends up reading bits(0,1) instead of AWIN_CPU_CLK_SRC_SEL.
It happens that these bits (AWIN_AXI_CLK_DIV_RATIO) are 2 (divide by 3) at boot
(at last on cubieboard2 and olimex lime2), which matches
AWIN_CPU_CLK_SRC_SEL_PLL1, so this has gone unnoticed.
