ARM: OMAP: PM: Add more information on error path

Sometimes if some code tries to remove requested
throughput, the message "Invalid Device Structure"
is shown. This message is not informative because
it's unknown for what device it was tried - so
now added more information to that message.

Change-Id: Id26bf385dafd4992c8c3487d9dc38935e0fcd777
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
SMC: Update UUID to match generic, common secure playback driver

Remove WVDRM prepends as this UUID is now generic.

Change-Id: I8b890d3f8227523635a394c9b02d409d597def8c
Signed-off-by: Bryan Buckley <bryan.buckley@ti.com>
ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properly

Fix the typo, instead it should be SDMMC1
USBC1 is not related to MMC1 I/Os

Change-Id: Icf99d8c9d4eb01ab803cb43a63a623812246da9c
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
OMAPDSS: DSSCOMP: Fix incorrect num_ovls check

In setup manager IOCTL, the check to validate the number of overlays
is incorrect. Hence when all overlays are passed to setup manager IOCTL
with enable/disable, error was returned. Fix the same.

Change-Id: I8ec1a6dee9f074ebf83a39bdf113a97e2543cc70
Signed-off-by: Varadarajan, Charulatha <charu@ti.com>
ASoC: dapm: Use card's power_mutex during codec shutdown

Codec shutdown performs a DAPM power sequence that might cause conflicts
and/or race conditions if another stream power event is running simultaneously.
Use card's power_mutex to protect any potential race condition between them.

Change-Id: Idd3be5967df9a454da8aaefb28ddbe497b651f8f
Signed-off-by: Misael Lopez Cruz <misael.lopez@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: 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 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>
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>
omap: omap-serial: fix compilation warning

 In function 'serial_omap_set_termios':
 warning: unused variable 'efr'

Change-Id: Iae94150c9aba04bd2f5295a9d411040c7e86ddf9
Signed-off-by: Leed Aguilar <leed.aguilar@ti.com>
Serial: OMAP: external API to control uart

Add external API to control UART from client devices.
This API can be used by any external client
peripherals connected to uart to wakeup uart.

Change-Id: Ibcc55553d3976ea3bde93175e2af918a9d5ca5c3
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
omap: uart: wer restoration

The WER value for a uart port is restored properly in
either case
Case 1:
The port is started, the device enters off mode and
resumes. In this case wer is restored with the
intended board defined value.

Case 2:
The port is started, shutdown, the device enters off
mode and resumes. In this case wer is restored with zero.
This prevents events from being registered in the uart
hardware which will not be handled by a port that is not
started in software.

Change-Id: I5dd426b2cdb8925404f6ba7fc83569b49bda1695
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
OMAP4: DPLL cascading: applying hold/release API to serial driver

Serial driver can block DPLL cascading only form non-atomic
context, if any external device uses UART.

Change-Id: I56d31a296b8a644cb2cf066b4aa7b22d2c07027a
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>

Conflicts:
	drivers/tty/serial/omap-serial.c
OMAP: hsi_char: added new module author

Official request for being module author (maintainer) of hsi_char module.

Change-Id: I1adf9b64635d7b444b130ed08e14fda91cf3698b
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP: HSI: set hsi_char default channel to ch 0

When hsi_char driver is loaded, it must be given 2 arguments :
 - port
 - channels_map
If they are ommited, channel 0 of port 1 is opened by default.

Change-Id: I618e8d9266179604cc4a9d3e091cb02b148aa7b5
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP: xSI: auto create hsi_char devices during module registration

Previously, after hsi_char driver was registered, user still needed to retrieve
the major number & use
 mknod to create character file & register to sysfs.

This fix introduces :
* automatic udev class creation : hsi_char
* automatic device file creation for all channels passed in module parameter :
/dev/hsi0, /dev/hsi1, etc.

New hsi_char driver does not require usage of mknod anymore. Names are :
/dev/hsi0, /dev/hsi1, etc...
instead of /dev/hsi/0, /dev/hsi/1, etc...

Change-Id: I6e1894a1d5857aabbd1733e3e84d156a98ee1781
Signed-off-by: Wei-Bin Feng <w20088@motorola.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: fix FIFO flush API

APIs for flushing HSI RX and TX FIFOs were using the SSI method, which doesn't work for HSI because
HSI_HSR_RXSTATE_REG and HSI_HST_TXSTATE_REG are Read Only in HSI.

Now split the FIFO flush into HSI and SSI specific code.
* For HSI we simply need to read as many frames as there are in the FIFO.
  OK for RX, not possible for TX
* For SSI we clear the state machine. Warning : all FIFOs are flushed.
  OK for RX and TX

Once a FIFO is flushed, the corresponding RX or TX interrupt is acked.

Change-Id: I510f5c14496147634e4e1e9b299f00964da39401
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: fix checkpatch & build warnings

Change-Id: I3a21ff3214566010a9963e0f279cbd954685fcaa
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>

Conflicts:
	drivers/omap_hsi/hsi_driver.h
OMAP4: HSI: clean platform data access

Replaced direct access to dev->platform_data by usage of dev_get_platdata()

Change-Id: Ifd4c18d449f848f32ceca83b3ec4520f2eea2c83
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: reduced alarmist traces

Decreased level of some traces which are normal.

Change-Id: Ie9ce785270154fcdffbd1fe0aa620eff70f738bf
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>