OMAP4: DPLL csacading: CPUfreq: manage DPLL cascading constraint

Only release a DPLL cascading constraint when at the lowest OPP,
otherwise hold a constraint blocking DPLL cascading entry.
targa: remove ramdisk mod from build script
OMAP2PLUS:fix for TF doesn't work when CPU1 on/off

TI thermal framework: rework initialization sequence

The initialization of max_thermal was placed in function
which is executed for each CPU1 start. The old value of
max_thermal is lost in this case and is set to max_freq.
As result, the omap_thermal_step_freq_down() can't
reduce the frequency if CPU1 is  switched on/off often.
OMAP2PLUS: TF: rework initialization sequence

The duty cooling device is being registered in the
wrong place. We don't want to register a cooling device
every time a CPU is initialized.  Thus, this patch moves
the cooling device registration to module init instead.
It seems that there is no external PCB temperature sensor is included

This means the thermal pcb domain is not reached on 4430 devices and causes useless
warnings which fill up the logcat.
On 4460 devices it causes a wrong calculated temperature, which means the cpu freq driver
isn't able to react with throttling down the CPU.

With this patch the thermal_lookup request is silently aborted with an ENODEV error, which
is handled at the further thermal calculation routines.
Add omap4_duty_governor_pcb_sections definition based of the SDP board.

This should prevent overheating the board by reducing cpu performance.
staging: add sync and sw_sync

sw_sync is a base sync driver that uses the cpu for serialization.

Sync is a framework for synchronization between multiple
drivers. Sync implementations can take advantage of hardware
synchronization built into devices like GPUs.
[moto] Kernel: power: Introduce Quickwakeup feature

Refer: http://www.elinux.org/Android_Power_Management
** Highly experimental **
The purpose of this feature is to drastically reduce the suspend/resume
time for device driver which needs to do periodic job.
In our use case (android smartphone), the system is most of the time in
suspend to RAM, and needs to send a low level command every 30s. With
current framework it takes about 500ms on omap3430 to resume the full
system, and then suspend again. With quickwakup feature, in the resume
process after resuming sysdev and re-enabling irq, the driver handler is
executed, and then it suspends again.
This new path takes 20ms for us, which leads to good power-saving.
defconfig: EXPERIMENTAL: adjust features
HWMOD: Using this patch to don't distrub the sleep when serial port is activated and connected.

UART idle state stuck in TRANSITION state while devie suspending
http://e2e.ti.com/support/omap/f/849/p/214828/759744.aspx
audit: allowed but just be quiet
omap: change opp table for edison

Change-Id: I24ac7af16198268f3d085d86b3ea175fcdc28de8
fix audit.c compile error

Change-Id: I68d9f4584182ac7f89769b837b582767e850d8fe
Revert "staging: add sync and sw_sync"

This reverts commit 645b7a82a9b5d012cce88374ac114aa0794c9975.