ARM: OMAP4: omap-twl: Fix setting VSEL code for max_voltage

Errata ProDB00121179 says voltage overshoot may occur if
switch from DVS to non-DVS ranges on TWL6032.
 - DVS range VSEL codes     0x01-0x39
 - non-DVS range VSEL codes 0x3A-0x3E

Max_volt settings (1.418V) were converted to VSEL=0x3A.
This VSEL code is in non-DVS range while all other codes
are in DVS range. Thus using this code leads to voltage
overshoot due to errata.
Now max_volt 1.418V is converted to code VSEL=0x39
which corresponds to 1.417960V and is in the safe range.
The voltages higher than 1.418V aren't used for both 6030 and 6032.
Thus replacing VSEL code 0x3A by 0x39 does not impact performance.
If used SMPS_OFFSET=0 (default only for twl6030 es1.0 and
is not used on twl6032) the max voltage of 1.35V is
recalculated to VSEL=0x3A and is not affected by the patch.

Change-Id: I5e992be09899f520c1635fe3c268cbfdedc4caf4
Signed-off-by: Oleg_Kosheliev <oleg.kosheliev@ti.com>
ARM: omap2+: mux: allow PAD_WKUP bit to be changed

Some modules need PAD_WKUP only for OFF mode, and
this needs to be set on suspend and cleared on resume
to prevent unnecessary  PRCM interrupts.

Change-Id: Ie1cc9280a30dec9cbfecb7b81580e9b61fd8a990
Signed-off-by: Axel Haslam <axelhaslam@ti.com>
MMC: Make sure PBIAS config matches VMMC supply.

Depending on the system, VMMC may end up being 3 or 1.8v.  It is
important that the PBIAS cell be configured to match the supply.
Fortunately, the PBIAS cell contains a handy detector which can
determine what the supply is set to after PWRDNZ has been released.
Use this detector to make sure that the cell is properly configured
and does not damage itself.

Change-Id: Id59ab8e4042efe0778a80f1476bcf8aa746e6cd6
Signed-off-by: John Grossman <johngro@google.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ARM: OMAP4: trim_quirks: Repair the wrong comparison

The omap_rev() returns value not comparable with CHIP_IS_* constants.

Change-Id: I4f21fc84b37f09d1c14c2656bf13337a453d783e
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
usb: omap4: add HSIC support

The OMAP4 HS USB host subsystem supports the configurations
with two HSIC interfaces. This patch adds the ability
to use both of them

Change-Id: I95478563e07bba6811fed56abe442e640ccd71e4
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
Fix mach-omap2/omap-iommu.c to prevent NULL pointer deref and fix a warning.

Change-Id: Iee7790cd529d8823b8c0606a3e4e614e94df0a77
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properly

Fix the typo, instead it should be SDMMC1
USBC1 is not related to MMC1 I/Os

Change-Id: Icf99d8c9d4eb01ab803cb43a63a623812246da9c
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
OMAP4: PM: Fix missed PRCM MPU interrupt events

OMAP PRCM detects events with EDGE sensitivity. Edge sensitivity
requires to clear the interrupt event status bit before acknowledging
the source event.
If the source event is cleared (1) before reseting the interrupt event
status bit (2), then a subsequent source event (i.e edge) between (1)
and (2) would be missed. Then, all the source events would be kept
"masked" until the source event is cleared again.

The bug seen here is that upon two consecutive PRCM interrupt events
from the IO daisy chain source event, the second event is missed if it
occurs before the PRCM interrupt event status is cleared.
Since the IO daisy chain source event has not been acknowledged, the
subseqent events from this source are missed too.

This patch fix the PRCM interrupt handler by acknowledging the interrupt
event status bit before clearing the source event.

Change-Id: I8c43a93c3b6c7c654ddaa262b7c1c3e7385da158
Signed-off-by: Patrick Combes <p-combes@ti.com>
Signed-off-by: Cedric Poignet <c-poignet@ti.com>
OMAP4: DVFS: Fix scaling dependent frequencies.

When scaling dependent frequencies down it is observed that the order
in which frequencies are changed is incorrect.  For example, when core
domain changes OPP down from OPP119 to OPP50 the order is:
a) scale L3 freq down to OPP50
b) scale SGX freq down to OPP50
which is wrong.

Frequencies are scaled in order devices are registered in omap dvfs
framework in device list. Devices are inserted to the list in order,
such as dependences are satisfied if scaling frequencies up.

When scaling frequencies down traverse list backwards.

Change-Id: I752bcb264cac12514f358986a906f29ee81ba75e
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@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>
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>

Conflicts:
	arch/arm/mach-omap2/sleep44xx.S
OMAP3+: PM: DVFS: add qos requirement to prevent interruptions

DVFS transitions are not meant to be interrupted as the interruptions
can cause severe mismatch in configuration sequences involved in DVFS.

We currently have omap_dvfs_lock check made in omap4_enter_sleep
function, however, considering cpuidle path:
a) omap4_enter_sleep is called by cpuidle's omap4_enter_idle_primary
   after the following steps:
   i) set the log state and set power domain state
   ii) WAIT FOR power domain state to transition!!!
  then we call omap4_enter_sleep
b) Now in omap4_enter_idle_secondary,
  GIC disabled, and we directly hit omap4_enter_lowpwer and goes down

We DONOT want this to take place when DVFS frequency configuration,
voltage programming and smartreflex AVS operations take place.

So request for QoS for the period of transition and release once operation
is done as it is less intrusive and takes care of CPU0 or CPU1 activity
to low power states as well.

Change-Id: I7731a3262bf88dd78e279a8c8306850e077865a5
Reported-by: Vinay Chaurasia <vinaych@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3630+: SmartReflex : 1p5: add qos request

Since we do calibration sequences out of the DVFS path, we still
need to honor the requirement not to interrupt the hardware activities
by attempting lower power states untill calibration is complete.
Hence request a QoS while we have hardware calibration sequence
active and monitoring is in progress.

We currently have check for work->active and abort as part of trigger
sequence from omap4_enter_sleep function, however,
considering cpuidle path:
a) omap4_enter_sleep is called by cpuidle's omap4_enter_idle_primary
after the following steps:
  i) set the log state and set power domain state
  ii) WAIT for power domain state to transition!!!
  we then call omap4_enter_sleep
b) Now in omap4_enter_idle_secondary,
  GIC disabled, and we directly hit omap4_enter_lowpwer and goes down

We DONOT want these to take place while we are capturing a calibrated
voltage for the OPP.

Change-Id: I217d80b1ffcf7cbe80eea4ceb29363bd2d25178e
Reported-by: Shashi Shekar B.S. <shashi.shekar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: PM: Correct powerstates initialization sequence

  During initialization of new powerstate item it
should be added into list before it's configuration.

  Initialization of powerstates skiped for CORE, MPU,
CPU0, CPU1 powerdomains. Current implementation caused
incorrect initialization of powerstate at least for
GFX PWRDM because it masked by CORE PWRDM.

We should add powerstate node to list before it will
been initialized.

Change-Id: I2f9274a9ec951eb9f6b54e104a0e14921b61264e
Signed-off-by: Volodymyr Riazantsev <v.riazantsev@ti.com>
OMAP: dmtimer: Fix timer handling logic for non loses_context timers

The use of the enabled flag is currently tightly coupled with the
loses_context flag on the timer struct. This change makes the enabled
flag behave more sanely without consideration of the loses_context flag.

Change-Id: I9d33bb4cc3fd7917ad493adde75cf57cb240b106
Signed-off-by: Jared Suttles <jsuttles@motorola.com>
OMAP4: PM: Program pwrst of each pwdm as per their supported state

Configure next power state of each power domain based on their
supported state. This will be done one time during initialization of
power_setup function. Device can change their power domain state runtime
based on dev latency requirement.
Also, this API will be called during suspend path as well to make sure each power
domain has been configured the right state before entering OFF transition.

Change-Id: I030f2b5df3186cb147e919d9d98dbcdfc75269a8
Signed-off-by: Gilles-Arnaud Bleu-Laine <gilles@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>