ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume

OMAP device hooks around suspend|resume_noirq ensures that hwmod
devices are forced to idle using omap_device_idle/enable as part of
the last stage of suspend activity.

For a device such as i2c who uses autosuspend, it is possible to enter
the suspend path with dev->power.runtime_status = RPM_ACTIVE.

As part of the suspend flow, the generic runtime logic would increment
it's dev->power.disable_depth to 1. This should prevent further
pm_runtime_get_sync from succeeding once the runtime_status has been
set to RPM_SUSPENDED.

Now, as part of the suspend_noirq handler in omap_device, we force the
following: if the device status is !suspended, we force the device
to idle using omap_device_idle (clocks are cut etc..). This ensures
that from a hardware perspective, the device is "suspended". However,
runtime_status is left to be active.

*if* an operation is attempted after this point to
pm_runtime_get_sync, runtime framework depends on runtime_status to
indicate accurately the device status, and since it sees it to be
ACTIVE, it assumes the module is functional and returns a non-error
value. As a result the user will see pm_runtime_get succeed, however a
register access will crash due to the lack of clocks.

To prevent this from happening, we should ensure that runtime_status
exactly indicates the device status. As a result of this change
any further calls to pm_runtime_get* would return -EACCES (since
disable_depth is 1). On resume, we restore the clocks and runtime
status exactly as we suspended with.

Reported-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.com>
ARM: dts: omap5-uevm: Add rtc node for Palmas

TWL6037 Palmas PMIC used on OMAP5uEVM has RTC capability.
Further, the platform uses XH414HG as a backup battery for RTC function.
Hence add a node for the same to represent the hardware behavior.
Node follows the bindings described in
Documentation/devicetree/bindings/rtc/rtc-palmas.txt

Signed-off-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
ARM: omap2plus_defconfig: enable Palmas RTC

Enable Palmas RTC for support on OMAP5 uEVM platform.

Signed-off-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
ARM: dts: OMAP5-uevm: pull-up Palmas MSECURE line

Palmas MSECURE line must be pulled up, otherwise some of the PMIC
registers will be read-only. This fixes the problem with RTC
not updating properly.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
clk: ti: dra7: enable deshdcp clock in dra7xx_clk_init

The DESHDCP clock is required only by the DES-HDCP block within HDMI in DSS.
However, if the clock isn't set before DSS clock domian is enabled, the clock
domain never comes out of idle state.

This is because the DSS IP is such that if DES-HDCP block can't transition
from idle state, the entire DSS also cannot transition from idle to enabled.
DES-HDCP block needs the DESHDCP clock enabled to transition from idle
successfully.

The DESHDCP clock is enabled/disabled at the DSS boundry by the bit
DSS_DESHDCP_CLKEN in CTRL_CORE_CONTROL_IO_2.

We enable the deshdcp clock in dra7xx_clk_init() which happens before omap
hwmods are setup. This clock is effectively a gate clock with the parent as
DSS_L3_GICLK. The parent is an automatically controlled clock by DSS clock
domain and hence doesn't have a clock node associated to it. Since
DSS_L3_GICLK is derived from the OCP clock, we set the dss_deshdcp_clk's
parent as l3_iclk_div.

Leaving this bit enabled doesn't prevent DSS or the system to suspend, and only
a very few flops get this clock all the time. So there is negligible impact.

Signed-off-by: Archit Taneja <archit@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
ARM: configs: omap2plus: Enable crypto test module

Signed-off-by: Joel Fernandes <joelf@ti.com>
OMAP: hwmod: Add SYSC offsets for AES IP

The AES IP has the SIDLE offset by 2 and not 3, to allow SIDLE modes
to work for AES, we add a new SYSC type to HWMOD code.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: DRA7xx: hwmod: Add hwmod data for DES IP

dra7xx SoC has a DES module. Add the required data to hwmod.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: DRA7xx: hwmod: Add hwmod data for AES IP

DRA7xx SoC has same AES IP has OMAP4. Add hwmod data for PM functions
for the same.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: dts: DRA7: Add DT node for DES IP

DRA7xx SoCs have a DES3DES IP. Add DT data for the same.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: dts: DRA7: Add DT node for AES IP

DRA7 SoC has same AES IP as on OMAP4. Add DT entries for the same.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: OMAP4: hwmod: Add hwmod data for AES IP

Crypto modules AES0/1 belong to:
    PD_L4_PER power domain
    CD_L4_SEC clock domain
    On the L3, the AES modules are mapped to
    L3_CLK2: Peripherals and multimedia sub clock domain

We add hwmod data for the same.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: OMAP4: hwmod: add hwmod data for DES IP

OMAP4 has a DES IP for DES and 3DES encryption, Add hwmod data for the same.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: dts: OMAP4: Add node for AES

OMAP4 has an AES module that uses the omap-aes crypto driver.
Add DT entries for the same.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: dts: OMAP4: Add node for DES3DES module

OMAP4 has an DES3DES  module that uses the omap-des crypto driver.
Add DT entries for the same.

Signed-off-by: Joel Fernandes <joelf@ti.com>
OMAP: AM33xx: hwmod: Correct AES module SYSC type

Use the newly added sysc type4 for AES module.
crypto: omap-aes: Fix CTR mode counter length

NIST vectors in testmgr.h assume the entire IV as the counter. To get correct
results that match the output of these vectors, we need to set the counter
length correctly.

Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: OMAP: Disable POSTED mode for errata i103 and i767

Enabling of Posted mode is seen to cause problems on dmtimer modules on AM33xx
(much like other OMAPs).  Reference discussions on forums [1] [2]. Earlier
patch solving this on other OMAPs [3].

For OMAP SoCs with this errata, the fix has been to not enable Posted mode.
However, on some SoCs (atleast AM33xx) which carry this errata, Posted mode
is enabled on reset. So we not only need to ignore enabling of the POSTED bit
when the timer is requested, but also disable Posted mode if errata is present.

[1] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/285744.aspx
[2] http://e2e.ti.com/support/arm/sitara_arm/f/791/t/270632.aspx
[3] http://www.spinics.net/lists/linux-omap/msg81770.html

Reported-by: Russ Dill <russ.dill@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Joel Fernandes <joelf@ti.com>
ARM: OMAP: DRA7xx: Make L4SEC clock domain SWSUP only

Using HWSUP for l4sec clock domain is causing warnings in HWMOD code for DRA7.
Based on some observations, once the clock domain goes into an IDLE state
(because of no activity etc), the IDLEST for the module goes to '0x2' value
which means Interface IDLE condition. So far so go, however once the MODULEMODE
is set to disabled for the particular IP, the IDLEST for the module should go
to '0x3', per the HW AUTO IDLE protocol. However this is not observed and there
is no reason per the protocl for the transition to not happen. This could
potentially be a bug in the HW AUTO state-machine.

Work around for this is to use SWSUP only for the particular clockdomain. With
this all the transitions of IDLEST happen correctly and warnings don't occur.

Signed-off-by: Joel Fernandes <joelf@ti.com>