Revert "OMAP3PLUS DVFS: Remove frequency based usecounting in DVFS"

This reverts commit 37a80dc2838ebd1df60cc552e0e91a9bdde5ee04.
OMAP3+: PM: DVFS: scale only target_device freq when list is empty

On scaling a dependent voltage domain, if the dependent target device's
frequency list is empty, we should scale just the dependent device's
frequency corresponding to the voltage we are scaling to. This is to
handle conditions such as core voltage scale to OPP100 without a
corresponding bus bandwidth request pending, it makes sense to scale
the dependent device's frequency as well(in this case core).

However, we currently scale all devices hooked on to the domain
to the corresponding frequencies corresponding to the voltage
request when the list for that device is empty, this implies, when
we have a dependency table as the following:
vdd_core
|- voltage requests
|  |
|  |-1025000: platform:mpu.0
|  |-1250000: pvrsrvkm:pvrsrvkm.0
|  X
|
|- frequency requests
|  |
|  |- platform:l3_main_1.0
|  |  `-none
|  |- pvrsrvkm:pvrsrvkm.0
|  |  |-384000000: pvrsrvkm:pvrsrvkm.0
|  |  X
|  |- rpres:fdif.0
|  |  `-none
|  |- omap_hsi:omap_hsi.0
|  |  `-none
|  |- platform:iss.0
|  |  `-none
|  X
We will attempt to scale fdif, hsi and iss in addition to scaling
core frequency which is not the intended behavior. Instead we check
for the matching target device(l3_main_l1.0) before selecting
correponding frequency, if there are no explicit frequency requests
for that device.

Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: DVFS: Return max OPP if no match for volt in opp_find_freq_ceil

Return max available OPP when there is no match found for the corresponding
volt in opp_find_freq_ceil(..)

Change-Id: I240668b851cc781e3344e7fa89c57af2befc362a
Signed-off-by: Girish S G <girishsg@ti.com>
OMAP4: DVFS: Scale freq when dependent volt is scaled

Add support to scale frequency when _dependent_ voltage is scaled for
that particular OPP.

If there is a volt domain dependency between two device then device scale should
take care of scaling voltage and its freq together. For example, MPU has
dependency on CORE. Which implies, if MPU runs above OPP50 than CORE should be
at OPP100. This dependency was only restricted to voltage in the current framework.
However, we need to consider its corresponding frequency as well. Because, the
dependency is just not on the voltage but its on the device _OPP_. Which is a tuple
of Volt and Freq.

This patch also takes care of scaling vdd frequency appropriatley when devices within
that vdd domain request for that particular OPP. For example, if SGX does a device
scale for OPP100 then CORE vdd's voltage and frequency is scaled to OPP100 as well.

Below short log on how dvfs/core/info looks like when system is loaded:
|- voltage requests
|  |
|  |-962000: aess:aess
|  |-1127000: platform:mpu.0
|  |-1250000: pvrsrvkm:pvrsrvkm.0
|  X
|
|- frequency requests
|  |
|  |- platform:l3_main_1.0
|  |  |-100000000: aess:aess
|  |  |-200000000: platform:mpu.0
|  |  |-200000000: pvrsrvkm:pvrsrvkm.0
|  |  X
|  |- pvrsrvkm:pvrsrvkm.0
|  |  |-384000000: pvrsrvkm:pvrsrvkm.0
|  |  X

Below log on dvfs/core/info when system is unloaded idle usecase:
|- voltage requests
|  |
|  |-962000: platform:mpu.0
|  |-962000: pvrsrvkm:pvrsrvkm.0
|  |-962000: aess:aess
|  X
|
|- frequency requests
|  |
|  |- platform:l3_main_1.0
|  |  |-100000000: platform:mpu.0
|  |  |-100000000: pvrsrvkm:pvrsrvkm.0
|  |  |-100000000: aess:aess
|  |  X
|  |- pvrsrvkm:pvrsrvkm.0
|  |  |-153600000: pvrsrvkm:pvrsrvkm.0
|  X

Change-Id: I7bb8396f4b353b41260ffe1ea63268c10d9bd123
Signed-off-by: Girish S G <girishsg@ti.com>

Conflicts:

	arch/arm/mach-omap2/dvfs.c

Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP3+: PM: DVFS: Scale dependent domains to existing OPP

Currently dependent domain is scaled to:
 - dependent voltage that is got from voltage dependency table.
 - frequency that is got from OPP found for dependent voltage.

OPP for dependent voltage is found by _volt_to_opp() function
which looks for OPP with equal or _greater_ voltage.
So if there is no OPP with exact voltage (or this OPP is disabled),
then frequency from OPP with higher voltage will be used.

As a result device will run at not supported combination of frequency and voltage.
This may lead to instabilities.

This patch scales dependent domain to a correct voltage-frequency tuple,
by using both frequency and voltage from the matched OPP.

Change-Id: Ieb14be32ce2f6f2971ca0530dd077bb445a7e2f7
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP3+: PM: VP: dereference voltdm after checking valid voltdm

voltdm should be dereferenced only after voltdm has been checked
for NULL parameters.

Change-Id: I61792933b6a33121dc2e7855e6c0b75f24a0d03b
Reported-by; Hoon Heo <ryan.heo@samsung.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

Conflicts:

	arch/arm/mach-omap2/vp.c

Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP3+: voltage: use volt_data pointer instead values

Voltage values can get confusing in meaning with various SmartReflex
classes being active. Depending on the class used, the actual voltage
selected might be a variant. For example:
With SmartReflex AVS class 3:
a) If we don't have SR enabled, we will go to volt_nominal.
b) If have SR enabled, we go to volt_nominal, then enable SR and
   expect it to adjust voltage. We don't really care about the
   resultant voltage.
Essentially, when we ask voltage layer to scale to voltage x for OPP
y, it always means x is the nominal voltage for OPP y.

Now, once we introduce SmartReflex AVS class 1.5:
a) If you are booting for the first time OR if you never enabled SR
   before, we always go to volt_nominal.
b) If you enable SR and the OPP is calibrated, we will not enable SR
   again when that OPP is accessed anymore, but when we set voltage for
   an OPP, the voltage achieved will be volt_calibrated.
c) If recalibration timeout triggers or SR is disabled after a
   calibration, the calibrated values are not valid anymore, at this point,
   setting the voltage will mean volt_dynamic_nominal.
So, depending on which state the system is at, voltage for that OPP
we are setting has not 1 single value anymore, but 3 possible valid
values.

For upper layers(DVFS/cpufreq OMAP SoC layers) to use voltage values, it
will need to know which type of voltage AVS strategy is being used and
the corresponding system state from voltage layer perspective. This
would replicate the role of voltage layer, SmartReflex AVS in the upper
layers and make the corresponding implementations complex.

Since each voltage domain contains a set of volt_data structs representing
a voltage point that is supported for that domain, volt_data is a more
accurate representation of the voltage point we are interested in going to,
and the actual translation of this voltage point to the voltage value is
done inside the voltage layer. Doing this allows the users of the voltage
layer to be blissfully ignorant of any complexity of the underneath
layers and simplify the implementation of dependent layers.

As part of this change, omap_voltage_get_nom_volt has been renamed to
omap_voltage_get_curr_vdata to better represent it's behavior.

Signed-off-by: Nishanth Menon <nm@ti.com>

Conflicts:

	arch/arm/mach-omap2/dvfs.c
	arch/arm/mach-omap2/prm44xx.c
	arch/arm/mach-omap2/smartreflex-class3.c
	arch/arm/mach-omap2/vc.c
	arch/arm/mach-omap2/vc.h
	arch/arm/mach-omap2/voltage.c
	arch/arm/mach-omap2/voltage.h
	arch/arm/mach-omap2/vp.c
	arch/arm/mach-omap2/vp.h

Ported from TI Android 3.0 branch, with many conflitcs resolutions and
aptatations (including many problems with
f1dc75a0da8594bd09e9f5a17dfe8917a2c6e51a that was partially already
intgration)

Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP3+: PM: DVFS: fix making wrong scale direction decision

In most cases with SmartReflex AVS class 3 and Class 1.5 calibration,
the SR adjusted voltage(Vsr) is usually lower than Vnom, However,
at times, the Vsr for a higher OPP may even be lower than a couple of
lower OPPs. For example, on a specific sample silicon on OMAP4430:
MPU OPP    Vsr                Vnom
OPP50      0.862249970436096  1.025
OPP100     1.03509700298309   1.2
OPPTurbo   1.09257805347443   1.325
OPPNitro   1.18703103065491   1.388
OPPNitroSB 1.29427194595337   1.398

Consider in the above case where we transition from OPPTurbo to OPP100
We are attempting to transition from 1.325V to 1.09V, if we pickup voltage
while SmartReflex AVS convergence is taking place, we might pickup 1.21V
which in effect is a scale down decision flag for DVFS. however,
since SR was active, it could make a jump of upto 8steps (100mV) lowering
the voltage to 1.1V after s/w sampled the voltage, which in reality
should have made SR to do a scale up operation.

This wrong scale direction can result in either dependent domain scale
combination to be performed wrongly OR even scale with lower voltage
for a given transition frequency resulting in device instability.

Fix the same by sampling the voltage only after stopping SmartReflex AVS
convergence.

Change-Id: I119a22b7060f30d123c4fe3bcabfadb6d7d71419
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: PM: DVFS: decide to scale dependent domains based on nominal voltage

Current DVFS scale decision assumes voltage dependency - hence the scale
decision is implemented based on voltage transition decision. This is
wrong as the dependency between domains is at OPP tuple level, so
no matter what the voltage level is, if we transition from a lower
frequency to a higher frequency, we should scale dependent domain
ahead of transitioning voltage/frequency for the current domain,
and viceversa when switching to lower OPP.

With Smartreflex AVS Class3 or Smartreflex AVS Class1.5, consider
the following Scenario:
The current OPP might be in
Vnom (Vn) - if SR is disabled OR if SR has not yet made the first
   adjustment
Vcurrent(Vc) - which can either be:
	Vsr_intermdiate(Vi) - if SR was interrupted in the middle
		of convergence
	Vsr(Vs) - if SR has completed adjustment.

For all purposes Current OPP's Vn > Vc.
However, when we consider the new OPP we are entering (assume for
SR1.5, new OPP is not a calibrated opp in this discussion):
Going down, we have the following cases:
Case a) current_Vn > current_Vc > new_Vn
Case b) current_Vn > new_Vn > current_Vc
Going up, we could have:
Case c) new_Vn > current_Vn > current_Vc
OR we might even have a scenario
case d) current_Vn > (current_Vc == new_Vn)

Today's code compares current_Vc against new_Vn, and makes a decision
when to scale dependent domain. This will work find in case (a) and
case (c).

However, in case (b), we scale dependent domain at the wrong time,
in case of case (d), we dont even attempt to scale dependent domains!!

This is wrong. since the comparable factor which closely represents
the order of OPP is Vnom, the right thing to check for scaling dependent
domains is Vnom. Hence use it instead.

Change-Id: I93868743301e115fab8e33ff14317b07b81ef5d8
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: VP/VC: ensure vp errgen is configured for the right OPP

Since target_volt converted by omap_voltage_get_voltdata to get to
vp_errgain for the OPP voltage level, we can have a scenario as follows:
OPP100 Vnom=1.2V, Vcalib = 0V(not calibrated) vp_errgain=0x16
OPPNitro Vnom=1.375, Vcalib = 1.2V vp_errgain=0x27
When a request to vc_bypass or vp_forceupdate is provided to OPPNitro
volt_data pointer, it in turn calls vc_prescale with 1.2V, this gets
passed down to vp_errgen_configure, who converts it back into vdata
using omap_voltage_get_voltdata

However, omap_voltage_get_voltdata walks through the volt_data array
and finds the first match of OPP100 where Vnom = 1.2V and returns
the volt_data pointer for OPP100, this causes 0x16 to be selected
for VP errgain instead of 0x27, causing instability for voltage scale
operation.

Instead, pass the volt_data pointer straight to vc_prescale and down
to vp_errgen_configure to ensure that the right configuration parameters
are used.

Change-Id: I96c697175fb5d16c53de9891ec5c008101c0550b
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

Conflicts:

	arch/arm/mach-omap2/vc.c
	arch/arm/mach-omap2/vp.c
	arch/arm/mach-omap2/vp.h

Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP3+: DVFS: ensure proper volt config if curr_volt==new_volt

At times when current_volt is same as new voltage, voltdm_scale is not
invoked. Since, vp_err_gain update and voltdm->curr_volt update is done
as part of vc_prescale and post_scale invoked as part of scale call,
these are left configured to old OPP values even if we are moving
to a new OPP.

Update these when we detect voltdm_scale is not being invoked, but
new OPP Vnom is detected.

Change-Id: Ic45d5a51edb4e5fe526529c6040cd014907b560e
Reported-by: Honda Kenji <x0092217@ti.com>
Reported-by: Maki Tanaka <m-tanaka1@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
config try sr 1.5 again

Signed-off-by: Andy Green <andy.green@linaro.org>
gpio/omap: get rid of redundant state variables and suspend/resume hooks

The runtime suspend/resume functions do all that is necessary and
we don't need to have the system suspend/resume hooks.

Signed-off-by: Roger Quadros <rogerq@ti.com>
ARM: OMAP4_Panda: Configure pins meant to wakeup the board from suspend

The User button i.e.'gpio_121' and 'sysn_irq1' are configured as wakeup
pins. sysn_irq is from TWL6030 PMIC and must be wakeup capable if we
need to detect events like USB plug-in while in suspend.

Signed-off-by: Roger Quadros <rogerq@ti.com>
OMAP4: config: Enable KEYBOARD_GPIO

This is required for 'user' key to work on Panda.

Signed-off-by: Roger Quadros <rogerq@ti.com>
OMAPDSS: DISPC: HACK: Fix Transfer writeback pipeline FIFOs

Fix issue in dispc_transfer_fifo()
OMAPDSS: DISPC: Fix buffer underflow err on downscaling

When downscaling heavily, FIFO buffers may underflow at the first
line.  Set DMA preload value to the high threshold to avoid this.

Change-Id: Ic791f48a252d82b2ba514f16c9e824d25e96fa44
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Varadarajan, Charulatha <charu@ti.com>
staging: omapdrm: Fix error paths during dmm init

Failures during the dmm probe can cause the kernel to crash.  Moved
the spinlock to a global and moved list initializations immediately
after the allocation of the dmm private structure.

Signed-off-by: Andy Gross <andy.gross@ti.com>

Conflicts:

	drivers/staging/omapdrm/omap_dmm_tiler.c
Adding OMAP Remote Procedure Call Driver to staging area of kernel.
Adding defines for CONFIG_DRM_OMAP and isolating Android parts