OMAP4: DSS: Fix to correct the manager index for VSYNC irq handler

Patch to fix the Manager id in dss_completion_irq_handler.
DSSCOMP is expecting the manager id 1 to be mapped to HDMI display.
This patch fixes the DSSCOMP_STATE_DISPLAYED callback in DSSCOMP.

Change-Id: I0aab3e494cb305d75a64fabc4cd6919def636285
Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>
Signed-off-by: Varadarajan Charulatha <charu@ti.com>
OMAP: DSS2: Fix callback completion issue in mgr->blank

Uncommitted callbacks were not completed yet eclipsed in mgr->blank.

Also fixed mgr index in ECLIPSED_CACHE callback.
This patch is co-authored with Muralidhar Dixit <murali.dixit@ti.com>

Change-Id: Ia20b79e9a6308441423d9900469e0c4adfc30eee
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>
OMAP4: DPLL cascading: introduce DPLL cascading blocker API

Some devices cannot operate correctly while in DPLL cacading mode used
for low power MP3 playback.  Thus two new functions have been created which
can be used by device drivers to block entry, exit and allow entry into DPLL
cascading.

Function protoypes are:

int omap4_dpll_cascading_blocker_hold(struct device *dev);
int omap4_dpll_cascading_blocker_release(struct device *dev);

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

Change-Id: I6df901c2790d874166ac5c4231cedd8c9b18d170
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>

Conflicts:
	arch/arm/mach-omap2/dpll44xx.c
OMAP4: DPLL csacading: CPUfreq: manage DPLL cascading constraint

Only release a DPLL cascading constraint when at the lowest OPP,
otherwise hold a constraint blocking DPLL cascading entry.

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

Change-Id: Ic842773e7a20bb2250cfd44c674a531d9fbec46f
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
OMAP4: DPLL cascading: Added dummy symbols to support external modules

The DPLL cascading is used in external modules, so if the DPLL cascading is
disabled, the external modules couldn't be added by reason the lack of
needed symbols.

Change-Id: I5d5e54e04dddbb20e60d2115c81f2c4362eccc5b
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
OMAP4: DPLL cascading: ASoC: ABE DSP: DPLL cascading: Add initial support

DPLL cascading mode can be entered when the following conditions
are met:
 - System is in early suspend (screen is off)
 - Multimedia Low-Power port is active (ping-pong)
 - OPP is 50 or less (DL1 path only)

ABE DSP driver will leave DPLL cascading mode when:
 - Screen is on
 - Any other port apart from Multimedia Low-Power is used
 - Stream is closed

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

Change-Id: Ib239730806e44456f45611c6eca1150733635470
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@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>

Conflicts:
	arch/arm/mach-omap2/clock44xx_data.c
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>

Conflicts:
	arch/arm/mach-omap2/devices.c
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>
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>

Conflicts:
	arch/arm/mach-omap2/dvfs.c
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>

Conflicts:
	arch/arm/mach-omap2/dvfs.c
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

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

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
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>
OMAP4: DPLL cascading: remove unused CM_SHADOW_FREQ_CONFIG2

The value from CM_SHADOW_FREQ_CONFIG2 can't be applied because
GPMC is always active and can't be entered in idle state.

The GPMC is always active because on OMAP4, CPU accesses on
unmapped addresses are redirected to GPMC by L3 interconnect.
CPU is speculative nature and such accesses are possible which
can lead to indirect access to GPMC and if it's clock is
not running, it can result in hang/abort on the platform.
See path d60565948468b for more information.

Change-Id: Ia62d8bf8c59ac3a06445b6f5f9e08ad0c9369c5b
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
OMAP4: DPLL cascading: The HSMMC output clock handling to support DPLL cascading

The HSMMC1 output clock will change from 96MHz to 49MHz upon entry
to DPLL cascading mode. This patch modifies the MMC1 divisor to
handle the change in clock frequency.

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

Change-Id: Ia52425132bfcc80489b39cb5562dc86cc483cb83
Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>