OMAP4: battery: correcting measured battery temperature value

Previously the measured temperature was returned in tenths of
degree Celsius. Now it returned in degrees Celsius.

Change-Id: Ic7cb46d49f32e728a23c685d78d44d7453a39739
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
OMAP4: battery: correct refreshing temperature algorithm

Previously temperature of the battery was refreshed only if adc ch1 value
was in range from 100 to 950. Now the temperature of the battery measured
correctly. If the temperature is less then -2 degrees Celsius then
-2 degrees Celsius returned and if the temperature is more then +62 degrees
Celsius then +62 degrees Celsius returned.

Change-Id: I8f91b88e76fc3c00e0d7a22267de16f096584e13
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
OMAPDSS: DSSCOMP: Handle DSI manual mode update errors

Description: Upon errors returned from manually updated panels,
previous compositions needs to be cleared to ensure SGX won't
block on commandcomplete function indefinitely.

Change-Id: I3a09018ce0c971a5978de7b178e07137ed320948
Signed-off-by: Sreenidhi Koti <sreenidhi@ti.com>
OMAP4: HDMI: limited & full range support

Limited & full range support is added.Full range is selected
for DVI mode and for VGA reolsution in HDMI mode.

Change-Id: I618375be996b3e36a4f960e1a3cefaf0c59e9223
Signed-off-by: Preetam MN <preetammn@ti.com>
Signed-off-by: Sujeet Baranwal <s-baranwal@ti.com>
OMAP3+: PM: VP: fix integer truncation error

In the voltage processor, the SPMSUpdateWait is calculated based on the
slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step).
After the voltage processor receives the SMPS_Ack signal, the Voltage
controller will wait for SMPSUpdateWait clock cycles for the voltage to
settle to the new value. For all practical purposes, the waittime
parameter is the hardware translation of what the slew rate on the PMIC
is.

As an example, with TPS62361 on OMAP4460,
step_size = 10000
slew_rate = 32000
sys_clk_rate = 38400

Our current computation of this results in the following:
 = ((step_size / slew_rate) * sys_clk_rate) / 1000
 = ((10000 / 32000) * 38400 / 1000
 = 0

Fix the same using DIV_ROUND_UP as an extra wait clock cycle
is better than lesser clock cycle. For the above example, this
translates to:
 = (10000 * 38400) / (1000 * 32000)
 = 12

Change-Id: I0ee22e60555e1cfd6cc3dea7ee44d0584ce182b6
Acked-by: Jon Hunter <jon-hunter@ti.com>
[nm@ti.com: slightly better implementation]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Yuan Jiangli <jlyuan@motorola.com>
rpmsg: resmgr: Use i2c_adapter to obtain I2C platform device

The I2C platform device is parent for i2c_adapter device and it can be
got from i2c_adapter device "parent" field (adapter->dev.parent)
instead of using HW_MOD.

Change-Id: I663b0a04d85f45d049eee85304d292afb2d9910e
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAP3+: PM: DVFS: add qos requirement to prevent interruptions

DVFS transitions are not meant to be interrupted as the interruptions
can cause severe mismatch in configuration sequences involved in DVFS.

We currently have omap_dvfs_lock check made in omap4_enter_sleep
function, however, considering cpuidle path:
a) omap4_enter_sleep is called by cpuidle's omap4_enter_idle_primary
   after the following steps:
   i) set the log state and set power domain state
   ii) WAIT FOR power domain state to transition!!!
  then we call omap4_enter_sleep
b) Now in omap4_enter_idle_secondary,
  GIC disabled, and we directly hit omap4_enter_lowpwer and goes down

We DONOT want this to take place when DVFS frequency configuration,
voltage programming and smartreflex AVS operations take place.

So request for QoS for the period of transition and release once operation
is done as it is less intrusive and takes care of CPU0 or CPU1 activity
to low power states as well.

Change-Id: I7731a3262bf88dd78e279a8c8306850e077865a5
Reported-by: Vinay Chaurasia <vinaych@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3630+: SmartReflex : 1p5: add qos request

Since we do calibration sequences out of the DVFS path, we still
need to honor the requirement not to interrupt the hardware activities
by attempting lower power states untill calibration is complete.
Hence request a QoS while we have hardware calibration sequence
active and monitoring is in progress.

We currently have check for work->active and abort as part of trigger
sequence from omap4_enter_sleep function, however,
considering cpuidle path:
a) omap4_enter_sleep is called by cpuidle's omap4_enter_idle_primary
after the following steps:
  i) set the log state and set power domain state
  ii) WAIT for power domain state to transition!!!
  we then call omap4_enter_sleep
b) Now in omap4_enter_idle_secondary,
  GIC disabled, and we directly hit omap4_enter_lowpwer and goes down

We DONOT want these to take place while we are capturing a calibrated
voltage for the OPP.

Change-Id: I217d80b1ffcf7cbe80eea4ceb29363bd2d25178e
Reported-by: Shashi Shekar B.S. <shashi.shekar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3630+: PM: LDO: Change ABB handling sequence

Current ABB handling sequence does not follow a recommended sequence.
1. ABB should be in bypass state during voltage scale.
2. RBB can be enabled only after a SmartReflex convergence.

While invoking DVFS transitions among various OPPs, the API call sequence
is as follows
scaling DOWN	| scaling UP
------------------------------
FREQ		| abb_PRESCALE
abb_PRESCALE	| voltage_scale
voltage_scale	| abb_POSTSCALE
abb_POSTSCALE	| FREQ

So in abb_PRESCALE call ABB should be always put to bypass.
And then in abb_POSTSCALE call it can be configured to target state.

In case of SR 1.5 the fact that SR convergence is finished can be
easily checked by looking into calibrated voltage.
Unfortunatelly there is no simple solution for SR 3.0, so for now
this patch addresses only SR 1.5.

Change-Id: I591c081ae78e04ee18112d475a3f8b828cd24350
[axelhaslam@ti.com, nm@ti.com: fixes, cleanups]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Axel Haslam <axelhaslam@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
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>
OMAP3+: LDO: ensure that right ABB type is selected

since target_volt converted by omap_voltage_get_voltdata to get to
abb type for the OPP voltage level, we can have a scenario as follows:
OPP100 Vnom=1.2V, Vcalib = 0V(not calibrated) ABB type - bypass
OPPNitro Vnom=1.375, Vcalib = 1.2V ABB type = FBB
in this case, voltdm_scale will first gets the operational_voltage
of oppNitro and recieves 1.2V, sends it down to abb_prescale function
which in turn 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 ABB logic to think
that it is attempting to go to an OPP with bypass, which in effect
crashes the device once frequency is set to OPPNitro, but ABB is in
bypass mode.

To solve this, we should pass the exact volt_data pointer down to
the abb prescale and postscale handlers so that this back and forth
conversion error does not take place.

Change-Id: I49099caba069798d7bd8888c614fd5e2e27fab6f
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@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>
OMAP3630+: PM: LDO: ABB: ensure transition complete

Currently when we configure ABB LDO, we do the following:
clear interrupt status
program new ABB
clear interrupt status

This does not guarentee that the ABB LDO has achieved the
desired configuration, and in cases where we are moving to
high performance OPP such as OPP NitroSB, this could result
in undeterministic failures on few corner lots.

Fix to ensure the right sequence as:
clear interrupt status
program new ABB
wait for interrupt
clear interrupt status (even if wait failed.)

Change-Id: Ida9320b9249a134f0ae33adf20ec2be81c806682
Reported-by: Vincent Bour <v-bour@ti.com>
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>
OMAP3+: voltage: omap_voltage_get_voltdata searches only for Vnom

Operational voltage comparisons are wrong in this search since we can
end up with scenarios such as the following:
OPP1 Volt_nominal == OPP2 Volt_calibrated
if the search for Volt_calibrated of OPP2 is done, if OPP1 appears
earlier in the array, this will result in returning the OPP1's
volt_data pointer which is wrong. In such a double match, there is no
real "correct selection" possible.

The current users of this function omap_voltage_get_voltdata are
dvfs.c and pm.c (setting up boot voltage) - both these use Vnom
for search, so it is safe to remove the check for operational voltage
and search for a match only for Vnom.

Change-Id: Ic8455cbd5a00dcc30e4989aa9db9b18c9da9741c
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAPDSS: tc358765: expand struct tc358765_board_data

Board-specific configuration structure expanded with additional attributes,
that will be needed for dynamic D2L bridge configuration.

Change-Id: Id908433197bbdedb2e6090b1dd3443cffb55f487
Signed-off-by: Sergiy Kibrik <sergiy.kibrik@globallogic.com>
OMAP4: tablet: add tc358765 bridge configuration

Add struct tc358765_board_data with Tablet1/2 panel configuration
to omapdss board data, which will be used by tc358765 driver for
dynamic bridge configuration.

Change-Id: Ib56f9f8cff138bac2bc0de9450f2e42f73010d98
Signed-off-by: Sergiy Kibrik <sergiy.kibrik@globallogic.com>
OMAPDSS: tc358765: fix register access interface

Routines for registers read access should separate exit
status and register values, thus not mixing signed status
codes and unsigned register values.
For this reason status is returned, and register value is
stored in separate function parameter.

Change-Id: I94ef6a6338adb79491a0f8a3f1f0df8b26b21880
Signed-off-by: Sergiy Kibrik <sergiy.kibrik@globallogic.com>
OMAPDSS: tc358765: add fields manipulation macros

Add FLD_XXX macroses, used in rest of DSS for registers fields
access and mangling.

Change-Id: I67eaf43845b39015f06dae18351073b3f07c42bf
Signed-off-by: Sergiy Kibrik <sergiy.kibrik@globallogic.com>