Get rid of this old toolchain..
Remove 12-04 4.7 toolchain
Update to 12-5 4.7 Toolchain
Add the fixes for new 4.7 toolchain
Revert "Raise VUSIM and VAUX3 voltages for staility"

This reverts commit 975d172a3a4ea135290bfc4aab15763761bfddce.
OMAP4: MUSB: peripheral isoch in transfer support

This patch fixes the following
1. The logic that determines a short packet endpoint sizes to be a power of
   2 number. This is typically not true for isochronous endpoints.
2. When a short/zero packet or DMA mode 0 is used, and TXPKTRDY is needed to
   be set by the CPU, the ISO bit should be set if its an isochronous transfer.
3. When a short/zero packet or DMA mode 0 is used, and TXPKTRDY is set by the
   CPU, g_giveback_request is deferred till the endpoint interrupt occurs.

Change-Id: I87873496b90755cf78fd283ca996f17f02408dcd
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
net: wireless: bcmdhd: Fix WARN_ON(!res->pub.channel)

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
net: wireless: bcmdhd: Ignore signal_pending() while waiting in IOCTL

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
usb: gadget: composite: Fix corruption when changing configuration

Remove the config from the configs list before releasing the spinlock.
Otherwise the other cpu might be processing a SET_CONFIGURATION that
will switch to the configuration that is being released.

Bug: 6521576
Change-Id: Id4da0d0e18ead63e20cb236cd1d3e8e6d116acce
Signed-off-by: Benoit Goby <benoit@android.com>
net: wireless: bcmdhd: Fix WPS PBC overlap failure

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
OMAP: PM: Fixed potential overflow in throughput calculation.

Helper functions add_req_tput()/remove_req_tput() operate using 64bit,
instead of 32bit. It is possible to get target_value overflowed by
having few users requesting high throughput or invalid value.
The frequency calculation result is verified on overflow, so result is
not causing switching to lower frequency.

Change-Id: I26472aa87454d1dd471fd4c69bda8d93323b8879
Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>

Patch Set 5
net: wireless: bcmdhd: Make responce waiting uninterruptible

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Linux 3.0.33

Conflicts:

	drivers/usb/core/quirks.c
HACK: increase TILER memory from 16MB to 32MB

Change-Id: Ib417703fca753eaff7ab0fe6e91ad4d38dbe434f
Signed-off-by: Vince Kim <vince.kim@ti.com>
gpu: ion: check for input arguments in ion_free

ion_free is a public API and is directly dereferencing a
pointer without checking for NULL. A check has been
added for the same and throws a WARN in case of invalid
arguments.

Change-Id: Idcf72e4449f8cba2b8342d6fb0f64600c2c59c7e
Signed-off-by: Suman Anna <s-anna@ti.com>
OMAP4: Support for TWL6032 PMIC added

TWL6032 used as PMIC for OMAP4470 based SOMs. New specific
definitions for support TWL6032 PMIC SR-compatible resources
were been added. Settings for those resources same as for
TWL6030.

Resources_to_power-rails connection scheme for
OMAP4470 + TWL6032 is:

	TWL_6032[SMPS1] -> OMAP4470[VDD_MPU]
	TWL_6032[SMPS2] -> OMAP4470[VDD_CORE]
	TWL_6032[SMSP5] -> OMAP4470[VDD_IVA]

Change-Id: I7457e92144d1109a8a7286c07526096926a3091b
Signed-off-by: Volodymyr Riazantsev <v.riazantsev@ti.com>

Conflicts:

	arch/arm/mach-omap2/voltage.h
ARM: OMAP: Voltage: PMIC data: rename vp_vddmin and vp_vddmax fields

We used to use PMIC data defined min and max voltages which were a
balance between what the SoC supports and what PMIC supports.
As a first step to ensure scalable solution, we split the meaning
to now indicate PMIC's max and min voltages indicated by min_volt
and max_volt.

All voltage values are retained and will be modified in next
series of patches.

Change-Id: I475c6094bb6efd0142431c14cd94a48e2a8ca199
[oleksandr.kozaruk@ti.com, nm@ti.com: port to Android kernel]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
OMAP3+: VP: introduce SoC limit parameters

Introduce Voltage Processor level limit which maps to
values per SoC.

The actual VP limits are programmed using the following
logic:
vddmax as the lower value of SoC/PMIC's capability
vddmin as the higher value of SoC/PMIC's capability

Change-Id: Ib58b41f56f06dfbd59f3e6d1a129fd1496d04d07
[oleksandr.kozaruk@ti.com, nm@ti.com: port for Android]
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
[t-kristo@ti.com: original patch]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
OMAP3+: VP: do not allow voltage lower than retention voltage

Do not allow the Voltage Processor to go below the retention
voltage even if HLOS or SmartReflex AVS module requests it.

This is to prevent unsafe voltages from ever being achieved
on the device. if the voltage domain cannot function below
the retention voltage during inactive retention power state,
there is hardly a possibility for the voltagedomain to function
at lower voltages in active scenarios

Change-Id: Idd1b199431c15002cf212d84e26e83d1940f9387
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: PM: TWL603[02]: update min, max voltages

In TWL6030 depending on the value of SMPS_OFFSET efuse register the
voltage range supported in standard mode can be either between
~0.6V - ~1.3V or ~0.7V - ~1.4V. In TWL6030 ES1.0, SMPS_OFFSET efuse
is programmed to all 0's where as starting from TWL6030 ES1.1 the
efuse is programmed to 1.

Since the operational support is from TWL6030 ES1.1, and some of
the TWL6030 firmwares allow us to override the SMPS_OFFSET, we use
the 1.41V as the max voltage and min as 0V as the voltage values
from ~0.7 - ~1.4v are equidistant for each step value or in other
words, 1 step is symmetric 12.66..mV in this range.

In case we are unable to do anything about the offset, then we throw
out a warning and continue as the system should still be able to
function despite the higher value configuration.

Change-Id: I6f93b7ba4694d96f96ce53a1bbe8f058e62c4bc8
[nm@ti.com: rewrite, split up and new controls]
Signed-off-by: Nishanth Menon <nm@ti.com>
[oleksandr.kozaruk@ti.com: original patch]
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>