sunxi: Add sunxi_*_mem_reserve kernel cmdline options

This patch adds the following kernel commandline options:
sunxi_g2d_mem_reserve
sunxi_ve_mem_reserve
sunxi_fb_mem_reserve

These can be set to configure the amount of RAM (in MB) to reserve for the
named sunxi drivers. This is useful for kernels for ready-to-use disk images,
so that an user can choose to use various binary only drivers to use the
hardware blocks in question, while not making the memory unavailable for
general use for users who choose not to use these drivers, without requiring
a kernel recompile.

IE I'm currently using the following since I don't use any binary drivers:
sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 sunxi_fb_mem_reserve=16

Giving me an additional 112 MB of extra memory.

Note that:
1) This patch also allows making the reservations larger in an easy way :)
2) This patch removes the comments stating that memory won't be reserved if
the block in question is disabled in the fex file, since this was not true
before this patch, and still is not true after this patch.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi: Also allow disabling MALI mem reservation from the cmdline

This patch adds a new "sunxi_no_mali_mem_reserve" kernel commandline options
to disable the memory reservation for the mali driver, makign the 64MB of
RAM in question usable for other purposes.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-disp: Fall back to kmalloc-ed mem when no fb mem is reserved

Since it is now possible to disable fb-mem reservation from the cmdline,
enable the kmalloc fallback path even if CONFIG_FB_SUNXI_RESERVED_MEM is set.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
axp20: Don't create the virtual axp devs if pmu_used is not set

This stops dmesg showing these:
[   86.720000] platform reg-20-cs-buck3: Driver reg-20-cs-buck3 requests probe deferral
[   86.720000] platform reg-20-cs-buck2: Driver reg-20-cs-buck2 requests probe deferral
[   86.740000] platform reg-20-cs-ldo4: Driver reg-20-cs-ldo4 requests probe def
<snip more of the same>

Each time a usb device gets (un)plugged when using a generic kernel build
(so with axp20 enabled) on a board without a pmu, such as the mk802, or
the a13_olinuxino_micro.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-cpu-freq: Unify sun4i and sun5i code

Note if you do a diff between the 2, there are some differences, where as
this patch just moves the mach-sun4i code to plat-sunxi. The reason for this
is that the sun5i code does the same as the sun4i code just in a more
complicated manner.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
sunxi-cpu-freq: Tweak cpufreq limits

cpu-freq has 2 sets of limits, 1 called cpuinfo which indicates what the
minimum / maximum freq of the cpu is, and the 2nd set indicates between
which limits the governor should automatically scale.

This patch splits the setting of the 2 sets of limits, and adds a
SUNXI_SCALING_MIN Kconfig option to allow raising the minimum speed
the (ondemand) governor will use from the current 60 MHz, which is
unworkably slow IMHO, to something better, ie 408 MHz, which is the last
speed at which the cpu runs at its lowest voltage of 1.0 volt.

This patch keeps the default at 60 MHz, to avoid regressions in battery
use, but I would like to advocate people to try out 408 Mhz instead,
which not only makes the interactive feel of the device a lot better, it
likely also *saves* power since it will cause the cpu to reach an idle
state quicker, which will allow it to power down entire blocks, thus stopping
the constant (non speed dependent) leakage current of those blocks sooner,
while using aprox. the same amount of power to do the work (it uses more
power due to the higher clock, but does the work proportionally faster,
resulting in aprox. the same power use). This is the so called race to idle
trick.

While at it also fix the formatting of sun4i_cpufreq_init().

Signed-off-by: Hans de Goede <hdegoede@redhat.com>