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: 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>