rk29: support get boot mode by register

Revert "cpufreq: ondemand: rk29 ignore nice default"

This reverts commit 71e7f0d47f03ed67282ae6e5a8c46b3d1b5f0113.

add rt5625.c.enc

rk29: vpu_service: add log when waiting task at power off

wm8994:fix a bug on calling pop noise

camera:fix ov5640 flash complite error

fb: fix fb rotate bug

bq27541 board

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

add bq27541

rk29: clock: default codec pll rate set to 297MHz

rk29phonesdk:touch screen->modify gt818 driver to fit the new touch screen panel

Use gpio for codec pop noise

rk29: memcpy_dma: fix section mismatch and initialization from incompatible pointer type warning

rk29: ipp: fix section mismatch warning and include slab.h

rtc: HYM8563: include slab.h, prepare for 2.6.36

rk29: cpufreq: fix section mismatch warning

rk29: rfkill: sdk: fix section mismatch warning

rk29: rfkill: phonepadsdk: fix section mismatch warning

rk29: rfkill: phonesdk: fix section mismatch warning

rk29: rfkill: a22: fix section mismatch warning

newton: updata irda serial driver
add ioctl get frame length and start send function

rk29: ddr_recofig: add ddr_reconfig.c

rk29: add dynamic DDR reconfiguration support, default disabled

net:wireless:bcm4329: add country code setting for various radio regulator domains.

RK29Smartphone:core voltage changed from 1.25v to 1.30v, when cpu frequecy is 1G Hz

rk29: adc: fix error: incompatible type for argument 1 of spin_lock

camera: update ov2655 sensor driver

WM831X:enable battery FET

rk2818: remove all rk2818 stuff, prepare for 2.6.36

newton: add support for the pwm led and update board_rk29_newton.c

camera: update gc0308 sensor driver from 和天创

fb:support 180 degree rotate

camera: fix ov5640 driver auto focus may be failed

uvc: fix dqueue ioctl may hold on forever when sensor is dead

camera: fix ov2659 delay 600ms after capture and pmem allocate for 0.3 Mega

camera: fix ov5642 display abnormity moment after capture in focus infinity

camera: update ov5642 driver

camera: fix camera open operation make a difference between O_RDONLY and O_RDWR for accerate open device

camera: fix 0.0.2 camera driver is not compatible 0.0.1 driver v4l2 format

camera and uvc: support uvc sensor

newton:disable usb host 1.1

phonesdk: slove the warnimg that the gpio used but not request

lzg: close mirror in ov2655 for newton

fb:src_vir_w and dst_vir_w of ipp request  must be setted.

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

newton:update cs42l52 driver

rk29: phonesdk: cpufreq add 1G support

rk29: clock: more increase aclk_cpu

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