OMAP: MUSB: Fix for issue when booting with USB charger connected

Issue:
When the charger is disconnected after bootup, the device fails
to go into OFF mode.
Bug Details:
1. At the end of Gadget Driver probe pm_runtime_put()is not called in
case of charger/USB cable connected during bootup.
2. After bootup when we disconnect the charger, the disconnect handler
for USB_EVENT_NONE checks first if the disconnect was for charger.
If yes it returns without autosuspend else it call pm_runtime_autosuspend.
So because of this PM calls get imbalanced and system does not go to OFF.
Fix:
Logic at the end of the gadget probe function is fixed to prevent
the above problem.

Change-Id: Ief7daade9aed7460bd4d1d576c22024a419ddbda
Signed-off-by: Mantesh Sarashetti <mantesh@ti.com>
CC: Ruchika Kharwar <ruchika@ti.com>
omap:musb:PHY powering time change to longer

This patch helps to avoid problems in coldboot stage with some
selfpowered hubs, like old belkin. Problem looks like this:

[ 1019.749084] usb 2-1: reset high speed USB device number 107 using musb-hdrc
[ 1034.881805] usb 2-1: device descriptor read/64, error -110
[ 1040.115386] usb 2-1: device descriptor read/64, error -19
[ 1043.303710] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1046.389648] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1049.475555] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1049.483459] usb 2-1: USB disconnect, device number 107
[ 1052.569366] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
[ 1055.655242] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?

At boot time DEVCTL register occasionaly change it's state from
IRQ host to IRQ device but musb->xceiv->state is still host what cause messages.
Problem caused transient processes caused powering after enabling clocks.

Powering on the phy need more time after enabling the internal phy clocks.
It was done because 300ms give us possibility to avoid problems caused transient
processes after powering that was found in the experimental practice
with a larger number of selfpowered hubs.

Also it should make work with chain of two selfpowered hubs more stable.

Change-Id: Ib0add65ab2be6fc2f0123538fb0b6447fa140f8b
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Andrii Danylov <x0158318@ti.com>
OMAP3+: PM: DVFS: Scale dependent domains to existing OPP

Currently dependent domain is scaled to:
 - dependent voltage that is got from voltage dependency table.
 - frequency that is got from OPP found for dependent voltage.

OPP for dependent voltage is found by _volt_to_opp() function
which looks for OPP with equal or _greater_ voltage.
So if there is no OPP with exact voltage (or this OPP is disabled),
then frequency from OPP with higher voltage will be used.

As a result device will run at not supported combination of frequency and voltage.
This may lead to instabilities.

This patch scales dependent domain to a correct voltage-frequency tuple,
by using both frequency and voltage from the matched OPP.

Change-Id: Ieb14be32ce2f6f2971ca0530dd077bb445a7e2f7
Signed-off-by: Taras Kondratiuk <taras@ti.com>
gccore: set GCHOLD bit before disabling clock.

Change-Id: I970a2fd10f00bfd3afff4096d7815c2d0a1053d6
Signed-off-by: David Sin <davidsin@ti.com>
gcbv: batching fixes.

      - changed to use change flags;
      - optimized mapping and state handling for batching;

Change-Id: Ic322bc62ff2297756e3f58a6dc7b74b881140702
Signed-off-by: Alexei Shlychkov <ashlychkov@vivantecorp.com>
Signed-off-by: David Sin <davidsin@ti.com>
OMAP4: SAR: Store OMAP revision on SAR

OMAP revision is a useful piece of info to have available in SAR.
At the moment it is required for POR restore on GP devices while
coming out of OFF state. POR service was added to 4430GP ROM in ES2.2
and is not available before that.

Change-Id: I7cd6a1c45d9cbe5dedd4cef39aaee88a55b117c3
Signed-off-by: Vimarsh Zutshi <vimarsh.zutshi@ti.com>
OMAP4: L2C: Restore L2 POR on GP devices

Current code restores POR on HS devices only. Add support for restoring POR on
GP devices.

Failure to restore POR severely affects memory bandwidth on the device.

This was found during investigating a memory throughput issue on GP devices
using the 'stream' benchmark as reported by Rocky Rhodes. On GP devices the
memory throuput was slashed by almost half after the first OSWR to ON
transition was done. Restoring POR fixes that issue.

The original patch for this was done by Volodymyr Riazantsev on
p-android-omap-2.6.35 (Commit 34d50a29) which seems to have been lost in the
newer kernel versions. Hopefully this one is not lost again :-)

[vikram pandita]
	- fixed bug with decimal vs hex in assembly
	- made code cleaner by passing 0x443022 to mean 4430 ES2.2
	- fix por setting on 4430 on ES2.2 and above silicon only

Change-Id: I3b607d2436e8fc5c5c1719a726b8fa88e339625c
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Vimarsh Zutshi <vimarsh.zutshi@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
gccore: zero GCHOLD bit before enabling clock.

Change-Id: Iba0f4c216f06add98ecd2f26654daf6b92f70220
Signed-off-by: David Sin <davidsin@ti.com>
OMAP4: cpuidle: don't touch mpu and core state until CPU1 is off

MPU/Core logic and PD states shouldn't be changed until CPU1 is
completely off

Change-Id: Ia90126776e7bd7108c7b885c622df36323982cb0
Signed-off-by: Lianwei Wang <lian-wei.wang@motorola.com>
Signed-off-by: suilunlam <a0868997@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP: SMC: Fix compile error if CONFIG_ION is not enabled

Change-Id: I541f0281916c008e0bf7dfe0069eaf700de37d42
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP4: hack for device is not resuming after suspend

The device is not resumed, in the case if "POWERON" button was
pressed for short time. The algorithm is following:
1. Device is resumed, and system reads the reason of resuming
from TWL status registers. But user releases the "POWERON"
button while system is in resume process. See pic1 and pic2
                          ___
   pic1                  |   |
real button state       /|\ \|/
                 ________|   |___________

   pic2                       |   |
system receive               \|/ \|/
following state  _____________|___|______

      |                            |
     /|\                          \|/
where | is button pressed state    | is button released state

2.We are read the cause of resume and get "button released".
3.After that we get second interrupt "Button released", because
button was really released and second interrupt was happened.
See pic2.
In this situation the system sees this, like two pairs
of "pressButton/releaseButton".
The patch removes a second "pressButton/releaseButton".

Change-Id: Ieec7227db19ed43f7964159169eee44386d7d511
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
Signed-off-by: Sergii Postulga <x0153364@ti.com>
Merge remote-tracking branch 'remotes/omap_zoom/p-android-omap-3.0' into acclaim