OMAPDSS: HDMI: Add support for HDCP driver

Add support for HDCP driver in HDMI ip and source files

Change-Id: Ib3663a2ea3bf438bc35ee0bb0d825dba94bdda7f
Signed-off-by: srinivas pulukuru <srinivas.pulukuru@ti.com>
OMAPDSS: HDMI: HDCP: Add HDCP Driver

Add HDCP driver and add support for HDCP driver in HDMI driver

Change-Id: I1a064f735acfe9ba6a67da4e88679ec4b5d64d9d
Signed-off-by: srinivas pulukuru <srinivas.pulukuru@ti.com>
Revert "ARM: DRA7: hwmod: Fix HDMI irq number"

This reverts commit 3617904a2b12714fa50e475afafc76421141fbe3.

Change-Id: Ifef10ad046455d764329fe90bbe8f1075fd17054
Signed-off-by: srinivas pulukuru <srinivas.pulukuru@ti.com>
Merge branch 'hdmi' into p-ti-android-3.8.y-video
OMAPDSS: DISPC: Remove reduntant code for passing plane info

overlay id is being retrived from overlay that was not initialized during probe.
This will cause NULL pointer exception when accessing the ovl->id
directly when initializing the DISPC without initializing the
overlas/managers during probe.

overlays/managers are being initialized during probe with a call
to omapdss_compat_init(). This call is being made from dsscomp or omapfb
probe. if either of these components are not used by the rendering engine
then it will cause NULL pointer exception when accessing overlays frmo DISPC.

Change-Id: I2c98aa5de4f3bf2a4ea6206f0f605d24343e9996
Signed-off-by: Srinivas Pulukuru <srinivas.pulukuru@ti.com>
Merge branch 'p-ti-android-3.8.y-video' of git://git.ti.com/android-sdk/kernel-video into p-ti-android-3.8.y-video
Merge branch 'dss' into p-ti-android-3.8.y-video
Merge remote-tracking branch 'origin/dss' into p-ti-linux-3.8.y-video

* origin/dss:
  OMAPDSS: DISPC: Remove reduntant code for passing plane info

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
menuconfig: fix uninitialized variable warning

scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:515:19: warning: ‘jump’ may be used uninitialized in this function

The warning is caused by patch:

commit 95ac9b3b585d20df116c5bea1511d9eb5758ac81
Author: Benjamin Poirier <bpoirier@suse.de>
menuconfig: Assign jump keys per-page instead of globally

Change-Id: Icc6e2a5204343218b8bbd247322c6351de780949
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
scripts/sortextable: fix uninitialized variable warning

fix uninitialized variable warning caused by:

commit d59a16836d917548cf41eda3369936684d527f5f
Author: David Daney <david.daney@cavium.com>
scripts/sortextable: Handle relative entries, and other cleanups

fixing warning:
scripts/sortextable.h:104:6: warning: ‘relocs_size’ may be used uninitialized in this function

Change-Id: I767d06ecb3a9abda46259a987932f787d9613dc1
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
ARM: 7676/1: fix a wrong value returned from CALLER_ADDRn

This makes return_address() return a correct value for CALLER_ADDRn.
To have a correct value from CALLER_ADDRn, we need to fix three points.

* The unwind_frame() does not update frame->lr but frame->pc for backtrace.
So frame->pc is meaningful for backtrace.

* data.level should be adjusted by adding 2 additional iteration levels.
With the current +1 level adjustment, the result of CALLER_ADDR1 will
be the same return address with CALLER_ADDR0.

* The initialization of data.addr to NULL is needed.
When unwind_fame() fails right after data.level reaches zero,
the routine returns data.addr which has uninitialized garbage value.

Signed-off-by: Sahara <keun-o.park@windriver.com>
Reviewed-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[port to p-ti-linux-3.8.y]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

Change-Id: I4a4b7c4da089e4365c7cd0ac0c21faac22807129
regmap: regmap: avoid spurious warning in regmap_read_debugfs

Gcc warns about the case where regmap_read_debugfs tries to walk an
empty map->debugfs_off_cache list, which would results in uninitialized
variable getting returned, if we hadn't checked the same condition
just before that.

After an originally suggested inferior patch from Arnd Bergmann,
this is the solution that Russell King came up with, sidestepping
the problem by merging the error case for an empty list with the
normal path.

Without this patch, building mxs_defconfig results in:

drivers/base/regmap/regmap-debugfs.c: In function 'regmap_read_debugfs':
drivers/base/regmap/regmap-debugfs.c:147:9: : warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]

Reported-by: Vincent Stehle <v-stehle@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
[port to p-ti-linux-3.8.y]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

Change-Id: I6632f5fe6cc6e7f41418a4222d58a59c18cdc1e9
svcrpc: silence "unused variable" warning in !RPC_DEBUG case

Change-Id: Idfa6de4cda99ba1fbf71e3540806eaf82b9e0284
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
[port to p-ti-linux-3.8.y]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
scripts/sortextable: silence script output

The exception table sorter outputs one line every time
it gets called, e.g. 'sort done marker at 66dc00', which
is slightly annoying when doing 'make -s' which is otherwise
completely silent. Since that output is not helpful to
most people building the kernel, turn it off by default.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David Daney <david.daney@cavium.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
[port to p-ti-linux-3.8.y]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>

Change-Id: I5d52439943735268062c1523e9c47b0c428d0493
regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver

upstream commit 40b1936efebdb9c31d9ed6fe59055f71ea366509

Adaptive Body Biasing (ABB) modulates transistor bias voltages
dynamically in order to optimize switching speed versus leakage.

Texas Instruments' SmartReflex 2 technology provides support for this
power management technique with Forward Body Biasing (FBB) and Reverse
Body Biasing (RBB). These modulate the body voltage of transistor
cells or blocks dynamically to gain performance and reduce leakage.
TI's SmartReflex white paper[1] has further information for usage in
conjunction with other power management techniques.

The application of FBB/RBB technique is determined for each unique
device in some process nodes, whereas, they are mandated on other
process nodes.

In a nutshell, ABB technique is implemented on TI SoC as an on-chip
LDO which has ABB module controlling the bias voltage. However, the
voltage is unique per device. These vary per SoC family and the manner
in which these techniques are used may vary depending on the Operating
Performance Point (OPP) voltage targeted. For example:
OMAP3630/OMAP4430: certain OPPs mandate usage of FBB independent of
	devices.
OMAP4460/OMAP4470: certain OPPs mandate usage of FBB, while others may
	optionally use FBB or optimization with RBB.
OMAP5: ALL OPPs may optionally use ABB, and ABB biasing voltage is
	influenced by vset fused in s/w and requiring s/w override of
	default values.

Further, two generations of ABB module are used in various TI SoCs.
They have remained mostly register field compatible, however the
register offset had switched between versions.

We introduce ABB LDO support in the form of a regulator which is
controlled by voltages denoting the desired Operating Performance
Point which is targeted. However, since ABB transition is part of OPP
change sequence, the sequencing required to ensure sane operation
w.r.t OPP change is left to the controlling driver (example: cpufreq
SoC driver) using standard regulator operations.

The driver supports all ABB modes and ability to override ABB LDO vset
control efuse based ABB mode detection etc.

Current implementation is heavily influenced by the original patch
series [2][3] from Mike Turquette. However, the current implementation
supports only device tree based information.

[1] http://www.ti.com/pdfs/wtbu/smartreflex_whitepaper.pdf
[2] http://marc.info/?l=linux-omap&m=134931341818379&w=2
[3] http://marc.info/?l=linux-arm-kernel&m=134931402406853&w=2

[nm@ti.com: co-developer]

Change-Id: I26f2e0afabfee2c65ac820fb13f307b56371e43c
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regulator: ti-abb: Fix off-by-one valid range checking for abb->current_info_idx

upstream commit f5cd8de2ce32e25e399f1d49d4876bf9450163a2

abb->current_info_idx is used as array subscript to access volt_table,
thus the valid value range should be 0 ... desc->n_voltages - 1.

[nm@ti.com: backport]

Change-Id: I0aad8faf540c906908549f727622cec0931bf1b5
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: ti-abb: Fix bias voltage glitch in transition to bypass mode with ldo voltage override

As documented in Application Note SWPA117 v2.1(NDA), LDO override has a
requirement that when switching from Bias active + override active
mode(FBB/RBB) to Bypass(nominal) mode, LDO reset must be performed
*after* LDO transitions to Bypass(nominal) mode.

The same rule in reverse applies when switching from a ABB bypass mode
to ABB enabled - LDO override *must* be performed prior to transition to
required ABB mode, if we do not do that, the same glitch takes place.

Currently while transitioning to ABB bypass, we reset the LDO overide
prior to the transition which causes a few milliseconds where ABB LDO
voltage could go all the way to 800mV(based on SoC process node),
during this period, the delta voltage between VDD rail and VBB rail
could cause the system to improperly function.

Change-Id: I6b42f17de8123969a2a4581d20fed718b7de8afe
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: ti-abb: Fix operator precedence typo

commit 40b1936e (regulator: Introduce TI Adaptive Body Bias(ABB) on-chip
LDO driver) missed a pair of brackets which cause the wrong vset data to be
picked up from efuse, resulting in bad VBB voltage values.

Change-Id: I7d26cdc94650537c7a0ca441995f24c7dadae5fc
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: ti-abb: Add support for interleaved LDO registers

Certain platforms such as DRA7 have quirky memory maps such as:
PRM_ABBLDO_DSPEVE_CTRL	0x4ae07e20
PRM_ABBLDO_IVA_CTRL	0x4ae07e24
PRM_ABBLDO_DSPEVE_SETUP	0x4ae07e30
PRM_ABBLDO_IVA_SETUP	0x4ae07e34

These need the address allocation to be either shared OR unique
allocation per register instance.

So, introduce v3 type of ABB for these instances to allocate based on
shared addressing.

Change-Id: Ib4e20a319a8de3901081961b9cdd00e12a4ab392
Signed-off-by: Nishanth Menon <nm@ti.com>
regulator: ti-abb: implement chained regulator

Case 1. Transition From Lower OPP to Higher OPP:
- Set the new OPP voltage value
- Select the next OPP for the ABB LDO
- Change MPU/IVA/CORE frequency to the new OPP frequency

ABB mode must be changed AFTER voltage scaling and
BEFORE clock rate scaling, if OPP scales UP.

Case 2. Transition From Higher OPP to Lower OPP:
- Change MPU/IVA/CORE frequency to new OPP frequency
- Select the next OPP for the ABB LDO
- Set the new OPP voltage value

ABB mode must be changed AFTER clock rate scaling and
BEFORE voltage scaling, if OPP scales DOWN.

Based on work by "Andrii.Tseglytskyi" <andrii.tseglytskyi@ti.com>

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