rk29: cpufreq: support limit by voltage

rk29: include/linux/regulator/consumer.h: fix warning: no return statement in function returning non-void

rk29: pm-vol.h: fix warning: no return statement in function returning non-void

cpufreq: ondemand: rk29 ignore nice default

newton:modify bu92747 irda_irq type for fir EOF

lzg:update mt9p111 and s5k6aa

newton: update board-rk29-newton.c

clockevents: Use u32 for mult and shift factors

The mult and shift factors of clock events differ in their data type
from those of clock sources for no reason. u32 is sufficient for
both. shift is always <= 32 and mult is limited to 2^32-1 to avoid
64bit multiplication overflows in the conversion.

Preparatory patch for a generic mult/shift factor calculation
function.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Mikael Pettersson <mikpe@it.uu.se>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Cc: John Stultz <johnstul@us.ibm.com>
LKML-Reference: <20091111134229.725664788@linutronix.de>

phonesdk: step voltage regulator for Vcore

a22 and rk29 phonesdk:32K Frequency switch time cut short

Revert "rk29: add hr_msleep/hr_msleep_interruptible/usleep"

This reverts commit c4c6281fd76657b320bb68a1698d469a620ccb6b.

rk29: add hr_msleep/hr_msleep_interruptible/usleep

timer: Added usleep_range timer

usleep_range is a finer precision implementations of msleep
and is designed to be a drop-in replacement for udelay where
a precise sleep / busy-wait is unnecessary.

Since an easy interface to hrtimers could lead to an undesired
proliferation of interrupts, we provide only a "range" API,
forcing the caller to think about an acceptable tolerance on
both ends and hopefully avoiding introducing another interrupt.

INTRO

As discussed here ( http://lkml.org/lkml/2007/8/3/250 ), msleep(1) is not
precise enough for many drivers (yes, sleep precision is an unfair notion,
but consistently sleeping for ~an order of magnitude greater than requested
is worth fixing). This patch adds a usleep API so that udelay does not have
to be used. Obviously not every udelay can be replaced (those in atomic
contexts or being used for simple bitbanging come to mind), but there are
many, many examples of

mydriver_write(...)
/* Wait for hardware to latch */
udelay(100)

in various drivers where a busy-wait loop is neither beneficial nor
necessary, but msleep simply does not provide enough precision and people
are using a busy-wait loop instead.

CONCERNS FROM THE RFC

Why is udelay a problem / necessary? Most callers of udelay are in device/
driver initialization code, which is serial...

As I see it, there is only benefit to sleeping over a delay; the
notion of "refactoring" areas that use udelay was presented, but
I see usleep as the refactoring. Consider i2c, if the bus is busy,
you need to wait a bit (say 100us) before trying again, your
current options are:

* udelay(100)
* msleep(1) <-- As noted above, actually as high as ~20ms
on some platforms, so not really an option
* Manually set up an hrtimer to try again in 100us (which
  is what usleep does anyway...)

People choose the udelay route because it is EASY; we need to
provide a better easy route.

Device / driver / boot code is *currently* serial, but every few
months someone makes noise about parallelizing boot, and IMHO, a
little forward-thinking now is one less thing to worry about
if/when that ever happens

udelay's could be preempted

Sure, but if udelay plans on looping 1000 times, and it gets
preempted on loop 200, whenever it's scheduled again, it is
going to do the next 800 loops.

Is the interruptible case needed?

Probably not, but I see usleep as a very logical parallel to msleep,
so it made sense to include the "full" API. Processors are getting
faster (albeit not as quickly as they are becoming more parallel),
so if someone wanted to be interruptible for a few usecs, why not
let them? If this is a contentious point, I'm happy to remove it.

OTHER THOUGHTS

I believe there is also value in exposing the usleep_range option; it gives
the scheduler a lot more flexibility and allows the programmer to express
his intent much more clearly; it's something I would hope future driver
writers will take advantage of.

To get the results in the NUMBERS section below, I literally s/udelay/usleep
the kernel tree; I had to go in and undo the changes to the USB drivers, but
everything else booted successfully; I find that extremely telling in and
of itself -- many people are using a delay API where a sleep will suit them
just fine.

SOME ATTEMPTS AT NUMBERS

It turns out that calculating quantifiable benefit on this is challenging,
so instead I will simply present the current state of things, and I hope
this to be sufficient:

How many udelay calls are there in 2.6.35-rc5?

udealy(ARG) >= | COUNT
1000 | 319
500 | 414
100 | 1146
20 | 1832

I am working on Android, so that is my focus for this. The following table
is a modified usleep that simply printk's the amount of time requested to
sleep; these tests were run on a kernel with udelay >= 20 --> usleep

"boot" is power-on to lock screen
"power collapse" is when the power button is pushed and the device suspends
"resume" is when the power button is pushed and the lock screen is displayed
         (no touchscreen events or anything, just turning on the display)
"use device" is from the unlock swipe to clicking around a bit; there is no
sd card in this phone, so fail loading music, video, camera

ACTION | TOTAL NUMBER OF USLEEP CALLS | NET TIME (us)
boot | 22 | 1250
power-collapse | 9 | 1200
resume | 5 | 500
use device | 59 | 7700

The most interesting category to me is the "use device" field; 7700us of
busy-wait time that could be put towards better responsiveness, or at the
least less power usage.

Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
Cc: apw@canonical.com
Cc: corbet@lwn.net
Cc: arjan@linux.intel.com
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Merge branch 'develop' of 10.10.10.29:/home/rockchip/kernel into develop

modify cir send

Merge branch 'develop' of 10.10.10.29:/home/rockchip/kernel into develop

newton:remove flash usb mass storage

rk29: sdk: defconfig: kernel log buffer size 512KB

rk29: phonesdk: defconfig: kernel log buffer size 512KB

rk29: phonepadsdk: defconfig: kernel log buffer size 512KB

rk29: ddr3sdk: defconfig: kernel log buffer size 512KB

fix bug of GIC crash

move clk_set_rate out of irq disabled

a22 and 29phonesdk:sey VCC25 0V when in sleep,29phonesdk:set key gpio pullup/down disable

update hdmi drivers

rk29_fb.c: hdmi_get_scale-->hdmi_get_fbscale

RK29SmartPhone:sync. SDCard code with XBW, use the old config

close hdmi debug info

update hdmi driver

arm: Makefile: better support make boot.img

wm8994: fix a bug for Bluetooth headsets

rk29_phone: fix heatset main mic Call Features

newton:update config and board file

rk29: vpu_service: fix bug when delay work and cancel work come at the same time

support 3 usb ethernet: dm9620, ax8872b, sr9700 (2)

support 3 usb ethernet: dm9620, ax8872b, sr9700

change AXI frequency division from 3 to 2

Merge branch 'develop' of /home/rockchip/kernel into develop

Merge remote branch 'origin/develop_xbw_update-SDCard' into develop

 Integrate the XBW-version of SDMMC-drver into rk29_ddr3sdk

Revert "rk29: vpu_service: fix bug when __cancel_delayed_work and delay work run at the same time"

This reverts commit c41dd263406cad12ec15d39986a530be1d23ad11.

newton:add gt819 firmware

Merge branch 'develop' of 10.10.10.29:/home/rockchip/kernel into develop

newton:add gt819 firmware

rk29: vpu_service: fix bug when __cancel_delayed_work and delay work run at the same time
if in inturrept use async interface else use sync interface

arm: Makefile: boot.img use zImage

rk29: default LZO-compressed kernel for zImage

arm: add support for LZO-compressed kernels

- changes to ach/arch/boot/Makefile to make it easier to add new
   compression types
 - new piggy.lzo.S necessary for lzo compression
 - changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
   gzip, depending on the config
 - Kconfig support

Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Tested-by: Wu Zhangjin <wuzhangjin@gmail.com>
Acked-by: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Russell King <rmk@arm.linux.org.uk>
Acked-by: Russell King <rmk@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lib: add support for LZO-compressed kernels

This patch series adds generic support for creating and extracting
LZO-compressed kernel images, as well as support for using such images on
the x86 and ARM architectures, and support for creating and using
LZO-compressed initrd and initramfs images.

Russell King said:

: Testing on a Cortex A9 model:
: - lzo decompressor is 65% of the time gzip takes to decompress a kernel
: - lzo kernel is 9% larger than a gzip kernel
:
: which I'm happy to say confirms your figures when comparing the two.
:
: However, when comparing your new gzip code to the old gzip code:
: - new is 99% of the size of the old code
: - new takes 42% of the time to decompress than the old code
:
: What this means is that for a proper comparison, the results get even better:
: - lzo is 7.5% larger than the old gzip'd kernel image
: - lzo takes 28% of the time that the old gzip code took
:
: So the expense seems definitely worth the effort.  The only reason I
: can think of ever using gzip would be if you needed the additional
: compression (eg, because you have limited flash to store the image.)
:
: I would argue that the default for ARM should therefore be LZO.

This patch:

The lzo compressor is worse than gzip at compression, but faster at
extraction.  Here are some figures for an ARM board I'm working on:

Uncompressed size: 3.24Mo
gzip  1.61Mo 0.72s
lzo   1.75Mo 0.48s

So for a compression ratio that is still relatively close to gzip, it's
much faster to extract, at least in that case.

This part contains:
 - Makefile routine to support lzo compression
 - Fixes to the existing lzo compressor so that it can be used in
   compressed kernels
 - wrapper around the existing lzo1x_decompress, as it only extracts one
   block at a time, while we need to extract a whole file here
 - config dialog for kernel compression

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: cleanup]
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Tested-by: Wu Zhangjin <wuzhangjin@gmail.com>
Acked-by: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Russell King <rmk@arm.linux.org.uk>
Acked-by: Russell King <rmk@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

gpu : fix the gcdOPTIMIZE_HEAP_SAMESIZE for heap alloc.

rk29: i2c: cpu freq notifier only for i2c0

IPP fix bugs:

1.Disable pre_scaling or deinterlacing when there is no request to do
2.Store clip mode always set to 1 now

Merge remote branch 'origin/develop_xbw_update-SDCard' into develop

rk29: clock: bump version

lcd: nt35510: aclk_lcdc max 300MHz

lcd: ls035y8dx02a: aclk_lcdc max 300MHz

rk29: sdk: more fix for vmac and usb host 1.1 both enabled

rk29: ddr3sdk: more fix for vmac and usb host 1.1 both enabled

rk29: clock: fix aclk_lcdc from ddr pll

Merge branch 'develop' of 10.10.10.29:/home/rockchip/kernel into develop

新的modem驱动

支持更多的3g dongle

newton:fix touch screen compile error

newton: modify irda serial device suspend&resume function

modify rk29_sdk_defconfig for SDMMC

Integrae the XBW-version of SDMMC-drver into RK29SDK, and the xbw-version is set to default(2)

Integrae the XBW-version of SDMMC-drver into RK29SDK, and the xbw-version is set to default

rk29_phone: change headset volume

Revert "Merge branch 'hdmi' into develop"

This reverts commit 57a857b5743d0166ac639b560ae3dc483c6e72e2, reversing
changes made to 5a152bcf0214a60cb5d72cad71a9b6f9c8b4ec4f.

Revert "update rk29_sdk_defconfig: change hdmi config"

This reverts commit 57f8574caa1c3e76b7c395ae260c18e0baf07f01.

newton: add irda serial driver

update rk29_sdk_defconfig: change hdmi config

A22:deal with minimum and maximal value of touchscreen specially

Merge branch 'hdmi' into develop

fix hdmi bug : wake up , the hdmi screen probabilistic flash of white

Merge branch 'newton' into develop

newton:update config and board file

Revert "RK29 SDMMC Ver1.14 2011-06-26 release from XBW"

This reverts commit 543f1a582cda4d8b4945bbda8a9a876b76712ba1.

Merge branch 'develop' of 10.10.10.29:/home/rockchip/kernel into develop

newton:add gt819 config and firmware update

phonesdk and A22: increasing the speed of resume

RK29 SDMMC Ver1.14 2011-06-26 release from XBW

rk29: fix for vmac and usb host 1.1 both enabled

rk29: vpu_service: fix bug when encode tash and decode task work together

rk29: clock: make aclk_lcdc as high as possible

support make_ext4fs

fix dma channel bug found in uart dma

RK29SmartPhone:Sharp LCD 02A stanby change, reset lcd when resume

rk29: ddr3sdk: defconfig: ddr freq 456MHz

newton:update config file

newton:update config and board

Merge branch 'develop' of 10.10.10.29:/home/rockchip/kernel into develop

newton:optimize ft5406,modify supend and resume for ft5406 and gt819

rk29_phone:add config for wm831x charge IRQ

gpu: modify gcsHAL_INTERFACE to reduce memcopy size, Android version must be synchronized.

rk29: vpu: move vpu_service from user to kernel

rk29: sdk: defconfig remove EXT3_FS_XATTR and YAFFS, add EXT4 and FUSE

rk29: phonesdk: defconfig remove EXT3_FS_XATTR and YAFFS, add EXT4 and FUSE

rk29: phonepadsdk: defconfig remove EXT3_FS_XATTR and YAFFS, add EXT4 and FUSE

rk29: ddr3sdk: defconfig remove EXT3_FS_XATTR and YAFFS, add EXT4 and FUSE