omap: remoteproc: choose ducati firmware as per platform

Ducati firmwares are different for default 1GB configuration
and 512MB system configuration. remoteproc will load
appropriate firmware as per system configuration

Change-Id: Ib790abc162c258fb8062b527b1e01c67271b199f
Signed-off-by: Devaraj Rangasamy <dev@ti.com>
OMAP4: DPLL cascading: SR: handle SRCLKLENGTH

In DPLL cascading mode SYS_CLK is gated.  This impacts many IP, including
the SmartReflex AVS modules.  To compensate for loss of SYS_CLK the
SR_xxx_SYSCLK clocks derived from the PRM use the 32K timer as a clock
source.  As such the SRCLKLENGTH value needs to be updated for this
change in frequency.  In DPLL cascading the rate of this clock should be
12.288MHz.

This patch implements three distinct changes:

1) add a 12.288MHz option to the existing sr_set_clk_length function
and give it the ability to detect whether we are in DPLL cascading
mode or not.
2) Remove optimizations in sr_configure_errgen and sr_configure_minmax to
skip sr_set_clk_length re-calibration if the clk_length parameter exists.
The assumption was that this value would never change after initial
calibration at boot; that assumption fails in light of DPLL cascading
scenario.

[Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>:
Ported and adapted to p-android-omap-3.0]

Change-Id: Ie657459e53838067139a4dd7316a6adc1f5e7259
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
OMAP4: DPLL cascading: Clock: new DPLL_CORE set_rate, and M2 fixes

omap4_dpll_dpll_set_rate checks for target rate matching the clk_bypass rate
and enters Low Power Bypass in that case. Otherwise it rounds the rate and
locks the DPLL at the new rate.  Same function handles EMIF programming.

omap4_dpll_core_m2_set_rate now has better documentation, follows the same
coding style as the above function and is a bit safer by forcing clk_enable
and clk_disable calls on emif1_fck and emif2_fck.

[Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>:
Ported and adapted to p-android-omap-3.0]

Change-Id: I921be9d20fe9e9c5b5604dceb4e5aa037a6b7009
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
omap: remove unused omaplfb platform device

Change-Id: Ic7d8aa22868c0cf2396ae499a1a320903e9feb31
Signed-off-by: Tony Lofthouse <a0741364@ti.com>
OMAP4: DPLL cascading: introduce devise scale function for GPU

GPU driver should be able to manage DPLL cascading constraint.
Right now sources of GPU driver are not in the kernel mainline.
So, patch introduces simple wrapper function for omap_device_scale(),
which holds DPLL cascading blocker when GPU scales to OPP higher, than
OPP50

Change-Id: I3f83b8b1c49118625f550aea031e86546ceb97fc
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
OMAP4: DPLL cascading: Fix GPU constraint

DPLL cascading constraint from GPU should be released
only when GPU is at OPP50.

Change-Id: Ice7d8e387b61737a085df4b221c6d57dcbb3813a
Signed-off-by: Taras Kondratiuk <taras@ti.com>
Revert "remoteproc: get suspend address from resource table"

This reverts commit 14b65e36480f9193b25131b0a6664494510004bf.

Breaks CameraHAL...
Merge branch 'exp' into stable
OMAP4: DPLL cascading: introduce DPLL_ABE low power bypass/cascade

DPLL_ABE can output 196.608MHz when fed from the 32KHz timer if
CM_CLKMODE_DPLL_ABE.REGM4XEN is set.  This unique property allows us to
make DPLL_ABE the parent of DPLL_CORE and then drive DPLL_MPU and DPLL_IVA,
all of which are in Low Power Bypass mode.  This allows the system to remain
usable while consuming far less power than when all of the DPLLs are
locked. The primary use case for this mode low power audio playback with the
display turned off.

Many caveats exist in this DPLL cascading mode:
DSS operation is unsupported, MPU is limited to 196.608MHz, ABE runs at
49.152MHz in LP mode and there are no doubt others we haven't figured
out yet.

[Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>:
Ported and adapted to p-android-omap-3.0]

Change-Id: I63ce263dd793801b9b13daff4d1b5f8f326b6d98
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
OMAP4: DPLL cascading: Removed race condition while entering in the DPLL cascading

Checking if omap is in DPLL cascading has to be under a lock. Without the lock it
can lead to a situation when one thread is waiting for omap_dvfs_lock thinking
that is not in DPLL cascading while another thread, that has locked dvfs
lock, put omap in dpll cascading. So when dvfs_lock will be unlocked the first
thread will run thinking that omap is not in DPLL cascading but it has
been put in DPLL cascading already.

Example:

Assume the device is not in dpll cascading state,
that is omap4_is_in_dpll_cascading = 0.

+--------------------------------+--------------------------------------------+
|           thread 1             |                thread 2                    |
+--------------------------------+--------------------------------------------+
|                                | ->omap4_dpll_cascading_blocker_release() { |
|                                | ...                                        |
|                                | mutex_lock(dvfs_lock)                      |
|                                | ... ->                                     |
| -> omap_device_scale() {       |                                            |
| ...                            |                                            |
| if (omap4_is_in_dpll_cascading |                                            |
|                       == 0)    |                                            |
| mutex_lock(dvfs_lock) ->       |                                            |
|                                | -> ...                                     |
|                                | omap4_is_in_dpll_cascading = 1             |
|                                | ... //enter in dpll cascading              |
|                                | mutex_unlock(dvfs_lock)                    |
|                                | ... ->                                     |
| -> mutex_lock(dvfs_lock)       |                                            |
| ... // do bad things           |                                            |
+--------------------------------+--------------------------------------------+

Change-Id: I2d7769a4b7347197c0c9c149873207a322fd4d5c
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
OMAP4: DPLL cascading: Removed deadlock during DPLL cascading transition

We need take a console lock due to change uart frequency.
We cannot do it under omap_dvfs_lock because it can lead to
deadlock in situation when some thread has taken the console
lock and trying to scale waiting for the omap_dvfs_lock that has
been taken already by DPLL cascading transition.

Example:
+--------------------------------------------+--------------------------------+
|           thread 1                         |           thread 2             |
+--------------------------------------------+--------------------------------+
| ->omap4_dpll_cascading_blocker_release() { |                                |
| ...                                        |                                |
| mutex_lock(dvfs_lock)                      |                                |
| ... ->                                     |                                |
|                                            | -> ...                         |
|                                            | console_lock()                 |
|                                            | omap_device_scale() {          |
|                                            | ...                            |
|                                            | mutex_lock(dvfs_lock) ->       |
| -> ...                                     |                                |
| console_lock() // deadlock                 |                                |
+--------------------------------------------+--------------------------------+

Change-Id: I90f7c66ef9d490a4552e94adddf2e2eb79c58b99
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
ARM: OMAP4: DPLL: DO NOT do DLL reset when changing M2/frequpdate

PRCM programming model in OMAP4 and OMAP5 require that DLL reset
NOT to be done as part of frequpdate(EMIF) and when M2 divider is
changed.

Change-Id: I486e1381fa8b86ef4b903e778b8638d553800dfe
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: DPLL cascading: Introduce menuconfig option

New menuconfig option CONFIG_OMAP4_DPLL_CASCADING will be
used for DPLL cascading feature. All related code should
use it.

Change-Id: I221d1bf92419cc84fdd014b0d20f49f18691d3b1
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>

Conflicts:
	arch/arm/mach-omap2/Kconfig
OMAP4: DPLL cascading: Add option which allows using DPLL cascading only for OMAP4430

Current DPLL cascading implementation is going to be used only on OMAP4430.
This patch adds config option to enable DPLL cascading only for OMAP4430.

Change-Id: I4942cef5ada3c7b764876fb44bfa9fb02e3e9730
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: Taras Kondratiuk <taras@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>

Conflicts:
	arch/arm/mach-omap2/Kconfig
OMAP4: DPLL cascading: Tune cpufreq interactive governor

During DPLL cascading timer_rate of interactive timer should be
increased, otherwise interactive governor will try to put system
out of DPLL cascading very frequently

[Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>:
Ported and adapted to p-android-omap-3.0]

Change-Id: I99bd86a8277b75f3f985124372f1c1b02f7d5ff2
Signed-off-by: Nicole Chalhoub <n-chalhoub@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
omap4-hsmmc: Remove USBC1 PBIAS controls from MMC1

Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable
for MMC1_PBIAS and associated extended-drain MMC1 I/O cell.
This is in accordance with the control module programming
guide. This fixes a bug where if trying to use gpio_98
or gpio_99 and MMC1 at the same time, the GPIO signal will
be affected by a changing SDMMC1_VDDS

Change-Id: I21da39ba46c1b246e7c5288e5962ee0af094c683
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
omap4-hsmmc: MMC1 PBIAS handling after card power down

The MMC1 PBIAS and I/O Cells must be kept powered down
after turning the SDMMC1_VDDS down. Since cells are
already powered down before SDMMC1_VDDS is turned down,
we just need to keep the cells turned down.

Change-Id: I679efbc61a326f0793149e46fb131b2cfcdf8a6d
Signed-off-by: Viswanath Puttagunta <vishp@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>
OMAP4: DPLL cascading: Fix build error if interactive governor is disabled

DPLL cascading directly calls function from interactive governor
to limit max timer rate.
So build fails if interactive governor or whole CPUfreq is disabled in config.

This patch adds dummy cpufreq_interactive_set_timer_rate() function
in case if interactive governor is disabled.

Change-Id: I493c2df6934fc20493ce9476f3c8005c51f91731
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP4: DPLL cascading: Don't limit DPLL cascading to 4430 by default

By default DPLL cascading was enabled only for OMAP4430. This patch enable DPLL
cascading for OMAP44XX by default.

Change-Id: I0533dcd8ff9d2644177cbeaa607b85de510b1e6b
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>