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>
OMAP4: DPLL cascading: Removed race between SR calibration and DPLL cascading exit

Before OMAP starts to exit from DPLL cascading the omap_sr_disable() is called
and when it completely exits from DPLL cascading the omap_sr_enable() is called.
A situation can occur when the OPP first calibration or periodic recalibration
of a smartreflex is continue the exit from DPLL cascading is started that stops
the calibration work by calling omap_sr_disable(). The calibration will start
again when we call omap_sr_enable(). A configuration of error generator during
the calibration is depend on flag omap4_is_in_dpll_cascading. So error generator
will be configured supposing that device is in DPLL cascading but actually it is
not. So flag indicating DPLL cascading mode has to be cleared prior to the
omap_sr_enable(), that is before the potential calibration.

Race illustration:

Assume that smartreflex calibration is ongoing and device is in DPLL cascading,
that is omap4_is_in_dpll_cascading = 1
-------------------------------------------------------------------------------
...
omap4_dpll_low_power_cascade_exit() {
  ...
  omap_sr_disable() // disable smartreflex calibration, so it will start
                    // again when we call omap_sr_enable()

  ...               // completely exit form DPLL cascading
  omap_sr_enable() {
    ...
    if (omap4_is_in_dpll_cascading()) // flag is set but cascading is off
      sys_clk_speed = 12288000;
    else
      sys_clk_speed = clk_get_rate(sys_ck);
    ...
  }
  omap4_is_in_dpll_cascading = 0
}

Change-Id: Iac03021ddc8517a09545f158865ee0d354852441
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Don't use DPLL cascading yet, it's incomplete
OMAP: I2C: Remove the SYSC register definition

The SYSC register should not accessed in the driver removing the
define from the driver.
Also clean up the syscstate from the omap_i2c_dev struct.

Change-Id: I95a7668de47a26523b51a9d13aea83b7aa7def03
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
OMAP4: I2C: Add hwspinlock support

Adding support for hwspinlock in I2C driver
in Blaze and Blaze_Tablet2.
Also adding an api omap_i2c_get_hwspinlockid to be
used by remote proc to populate the resource table.

Change-Id: I5f554ead10806c90442359365dcb8ebff51bf2bf
Signed-off-by: Christina Warren <cawarren@ti.com>

Conflicts:
	arch/arm/mach-omap2/board-4430sdp.c
	arch/arm/mach-omap2/board-44xx-tablet.c
	arch/arm/plat-omap/include/plat/i2c.h
	drivers/i2c/busses/i2c-omap.c
ARM: OMAP4: Add resistor selection code to the I2C platform driver

Add a call into the I2C to set the I2C pullup resistor strength.

Change-Id: I0bb9eee666d75e04ebd752cb15f1c41a9c8a7b71
Signed-off-by: Dan Murphy <dmurphy@ti.com>

Conflicts:
	arch/arm/plat-omap/include/plat/i2c.h
OMAP: I2C: Reset support

Under some error conditions the i2c driver may do a reset.
Adding a reset field and support in the device-specific code.

Change-Id: I1093774aa6ba419da92047f28a087b2d29ff6750
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
OMAP: I2C: Remove the reset in the init path

-  The reset in the driver at init is not needed anymore as the
   hwmod framework takes care of reseting it.
-  Reset is removed from omap_i2c_init, which was called
   not only during probe, but also after time out and error handling.
   device_reset were added in those places to effect the reset.
-  Earlier the hwmod SYSC settings were over-written in the driver.
   Removing the same and letting the hwmod take care of the settings.
-  Clean up the SYSS_RESETDONE_MASK macro as it is no longer needed.
-  Clean up the SYSCONFIG SYSC bit defination macros.
-  Fix the typos in wakeup.

Change-Id: I8f4ccdf783de6fe3d883e4aa5290473ea0117945
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Conflicts:
	drivers/i2c/busses/i2c-omap.c
I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero

By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.

Move the call to wait_for_completion_timeout() onto a single line as it is less
than 80 characters.

Change-Id: I906a112c1ef339aa0b7ad26896669fa413448fa8
Signed-off-by: Jon Hunter <jon-hunter@ti.com>