ARM: OMAP5: Use arm revision for CPU identification for incorrect efused ES2.0 samples

The OMAP silicon revision is not efused correctly for OMAP5 ES2.0 silicon.
So use arm revision for now to identify the SOC version.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
--
[only append change-id and port to p-linux-omap-3.4]]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

Change-Id: I63b669b71a4f3aa72761a24cb2bbad8fbbcb2c75
ARM: OMAP54XX: hwmod data: use correct clock name for MMC1

Change-Id: Ib35634539ec4f0fc711b2a7c3099f32a0d8b59f6
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
ARM: OMAP5430: hwmod data: Fix break caused by "Clean context_offs/clkctrl_offs usage"

<re-applying> since initial ES2.0 data patch reverted the change:
commit: a720ac8d6c7415d89527b2d9020f7775d0d7d8be
--
original patch description:

patch: ARM: OMAP5430: hwmod data: Clean context_offs/clkctrl_offs usage
commit: 498c4e3bbf687a15d22deec27689734f4b43fe96

causes omap5 platform boot failure.

Reason:
removing "clkctrl_offs =  OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET"
causes dss_dispc,dss_dsi1_a,dss_dsi1_c,dss_hdmi,dss_rfbi as in-accessible

If clkctrl_offs was present, _wait_target_ready will timeout and
hence causing subsequent functions not to execute and hence the
print

"omap_hwmod: dss_dispc: cannot be enabled (3)"
--

whereas if clkctrl_offs is removed, _wait_target_ready will return
without checking the target and hence system crashes due to
"update_syscache" execution

Change-Id: I51dcb73dd50181e07ec0f9d56060542fe856ec94
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
ARM: OMAP54XX: clock data: add alias for dmic_gfclk

Patch adds alias dmic_fck -> dmic_gfclk, which is needed for
omap dmic driver.

Change-Id: I4a8a9094dbdea0c7ce1b662ee0f26b47a718d6bb
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
ARM: OMAP54XX: voltagedomains: fix initialization for OMAP5430_REV_ES2_0

Patch adds proper initialization in for OMAP5430_REV_ES2_0,
before only OMAP5432_REV_ES2_0 was properly initialized.

Change-Id: Idda959dec85e90437bb453b821155fa88155ba27
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
ARM: OMAP54XX: mux: correct names for mcpdm

Names for mcpdm should be properly updated to be aligned
with mux data.

Change-Id: I6aa0ca0caac439ee41f3c30fa20691fc871b72ed
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
ARM: OMAP4: Tablet/SDP: Enable SmartReflex on init

Enable SmartReflex on init on SDP4430 and Tablet44xx boards.

Change-Id: I4dfb2f83399d18b9b965cf0ab319c90666ad8cfd
Signed-off-by: Taras Kondratiuk <taras@ti.com>
ARM: OMAP4: board: Configure UART autosuspend delay

Set UART autosuspend delay to 3000ms by default.
This allows CORE to reach retention during CPUidle.
3 sec value was used in k3.0 so it is acceptable.

Change-Id: I887a78490a9367d7b64f485e037ba852ac56de57
Signed-off-by: Taras Kondratiuk <taras@ti.com>
ARM: OMAP4: PM: Enable Voltage Transition in LP states

Now the Voltage Transition in LP states is disabled because
omap5_has_auto_ret() feature check always returns false for OMAP4.
But OMAP4 supports Voltage Transition in LP states and Retention voltage
reliably by default.
Hence, enable Enable Voltage Transition in LP states for OMAP4 SoCs and
disable it for OMAP5 only.

Change-Id: Ie4a8af9abeb8c84aa823cd9388af88e91f35d78b
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
ARM: omap4plus_pm_min_defconfig: Enable TWL6030_POWER for OMAP4 platforms

Enable TWL6030_POWER to allow use the power resources on the
TWL6030 family chips.

Change-Id: I6f347950da117305a2a18781028f2b82748c3903
Signed-off-by: Oleksandr Tyshchenko <oleksandr.tyshchenko@ti.com>
MFD: TWL-CORE: fixed wrong usage sysen instead of regen1 for TWL6030/32

There was an typo in the regulator registration in the twl-core.c
This patch corrects it.

Change-Id: If981c578899a203541e7d8bef9e9e948ec604716
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
[oleksandr.tyshchenko@ti.com: ported from K3.0]
Signed-off-by: Oleksandr Tyshchenko <oleksandr.tyshchenko@ti.com>
ARM: OMAP4460/70: PM: Disable MPUSS-EMIF static dependency

Due to errata "MPU EMIF Static Dependency Needed" and errata i688
"Async Bridge Corruption" the dynamic dependency isn't working on
the path between MPU to DMM (to EMIF) on OMAP4430,
therefore the static dependency MPUSS-EMIF should be enabled.

But on OMAP4460/70 the direct path from MPU to EMIF (through memory
adapter in MPU-SS) is replacing MPU-to-DMM path, which was taking place
in the OMAP4430. As result, in an OMAP4460 device, i688 errata is
not impacting the direct path from MPU to EMIF (through memory adapter
in MPU-SS).

Hence, disable MPUSS-EMIF static dependency on OMAP4460/70 and leave it
enabled on OMAP443x. Within this patch PM specific
OMAP44xx_54xx_PM_ERRATUM_MPU_EMIF_STATIC_DEP_NEEDED_i731 define is
introduced.

Change-Id: I0c28e843b07bea1e835c12381d8633c5f1ff49a7
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
ARM: OMAP4460/70: PM: MPU-EMIF static dependency needed around WFI

This patch prevents system hang/lockups seen when relying on MPU-EMIF
dynamic dependency.

The issue with removing MPU->EMIF SD surfaced random lockups
during active usecase - if static dependency from the MPU
clock domain toward the MEMIF clock domain is disabled to save power
(CM_MPU_STATICDEP[4] MEMIF_STATDEP = 0x0), the platform may lockup
when exiting MPU WFI.

As workaround, this patch toggles MPU-EMIF static dependency around WFI
for targeting C-states which has power state set to INACTIVE and
lower. There should be no power impact as SD is kept disable for
active period and only getting toggled over WFI.

TI EID: i745; IMPACTED: OMAP4460/70 all revisions

Change-Id: I27276915c05f5ddf4eb5525848d702d14a6eb860
Cc: David Derrick <dderrick@ti.com>
Cc: Ambresh K <ambresh@ti.com>
Signed-off-by: Nishanth M <nm@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Cedric Vamour <c-vamour@ti.com>
[grygorii.strashko@ti.com - Forward port from K3.0]
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
ARM: OMAP5: hwmod: add ocp2scp child device information as dev_attr

ocp2scp driver probe takes care of creating the child devices connected to it.
In omap5, ocp2scp has usb2 and usb3 phys connected to it. This information is
passed as pdata to ocp2scp driver. So filled the hwmod data with the
child device information which is passed in pdata when creating the
ocp2scp device.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
ARM: OMAP54XX: hwmod data: correct user flags for emif1 and emif2

Change-Id: Ie6799f134466c80fb20770e91ac3ebd32ba5d3a6
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
ARM: OMAP54XX: clock data: allow set rate on bandgap clock

This patch adds the clk_set_rate capability on bandgap clock.
This is required to bump up the BG clock.

Change-Id: Ica92d7f33ff918d0d9f26aad1de2ce82683dca80
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
ARM: OMAP4+: SAR: enable l3_main_3 hwmod during save_sar_bank3

Some of the firewall registers are not accessible without the l3_main_3
clock being enabled.

Change-Id: I405c3d6a40c5c1b837959c56337f01cf21dbd6cf
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
ARM: OMAP5: DPLL: Update children before scaling MPU up

Currently dividers of MPU-ABE and MPU-EMIF asynchronous
bridges are updated after MPU scaling.
This leaves a window with a wrong configuration during scale up.

So update dividers before scaling up.

Change-Id: I945966b1ca34e89ae75ce80b5b806a9c8f39350e
Signed-off-by: Taras Kondratiuk <taras@ti.com>
ARM: OMAP5: DPLL: Fix MPU DPLL rate check

omap5_mpu_dpll_set_rate() function skips setting
MPU DPLL rate if it is already the same.
But rate check is not correct if DCC is used.

For example we set MPU frequency to 1500MHz (DCC is used).
If we try to set 1500MHz again then configuration should be skipped.
But it is not skipped:

    rate = 1500;
    dpll_rate = 750;
    if (rate == dpll_rate/2) -> (1500 != 375)

Instead check should be changed to (rate/2 == dpll_rate)

Change-Id: I7e2115b2f1024915d9efcd35add56cc30a5feb0e
Signed-off-by: Taras Kondratiuk <taras@ti.com>
ARM: OMAP5: DPLL: Enable DCC after MPU DPLL is scaled.

Currently DCC is enabled before scaling DPLL frequency to rate/2.
In some cases for short period of time this will scale MPU
to higher frequency.

The patch enables DCC only after MPU DPLL is scaled.

mult_div1_reg rmw operation can't be interrupted by set_rate(),
because they both modify OMAP54XX_CM_CLKSEL_DPLL_MPU register.
So dd->mult_div1_reg should be read separately
inside of both if-else branches.

Change-Id: Ib42447b681153e500abb28e41a91850ebc0c3a19
Signed-off-by: Taras Kondratiuk <taras@ti.com>