OMAP DSI: Fix consecutive bus unlocks for manual mode panel.

Description: In manual mode panels, a semphore is used to keep track
of display queue and release. Upon the condition of framedone timeout
error the semaphore is released once by the callback handler before exiting.
If framedone for the timed-out frame arrives after 250 msec and before
next frame queuing, it releases the semaphore second time in the callback handler.
This results in warnon assert later.

This patch puts in proper check before releasing the semaphore.
This way we prevent multiple unlocks of the bus..

Change-Id: I7db034de1a286f58a7fb9187b4ff356d7ad4731b
Signed-off-by: Sreenidhi Koti <sreenidhi@ti.com>
Signed-off-by: Sujeet Barnawal <s-baranwal@ti.com>
OMAP4: DSI: Reset required disable-enable sequence

During the initialization of DSI,some times BTA
sent by OMAP DSI, was not receiving an BTA ACK.
To rectify this, we need to reset the DSI module
whenever we diable-enable the DSI module.

Change-Id: Ic2542970da06a121559a8cc700222881c60c025c
Signed-off-by: Sujeet Kumar Baranwal <s-baranwal@ti.com>
OMAP4460: TWL: disable PD on VCORE1 shutdown

When the PREQ goes low, both VCORE1(VDD_CORE) and VDDD_MPU
start transitioning to 0 volt but VCORE1 discharge is faster
than VDD_MPU discharge. This causes reliability concern from
OMAP's perspective. So, we disable  pulldown on VCORE1 to
slow down VDD_CORE discharge to make it comparable to VDD_MPU.

The Pulldown does not impact DVFS transition, and actual
OFF timing is not changed as well.

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

Conflicts:
	arch/arm/mach-omap2/omap_twl.c
ASoC: OMAP: HDMI: Use generated audio MCLK for OMAP4430 ES 2.3

For OMAP4430 ES2.3, use pseudo generated clock (MCLK- based on TMDS
clock) to form Audio Clock Regeneration (ACR) packets. MCLK is also
used for OMAP4460 and later chip versions.

Change-Id: I65f255cb7eac39bbbb52b2f0105f6721f0f08df7
Signed-off-by: Axel Castaneda Gonzalez <x0055901@ti.com>
OMAP4: HDMI: Update 6 channel configuration

For 6 channel, set info frame with channel count = 7 (8-1) and
CA = 0x13 in order to ensure that sample_present bits
configuration matches the number of channels (2 channels are
padded with zeroes) that are sent to sink device, in order
to fullfil multichannel compliance test.

Change-Id: I5f149ec679e4a808ed0dbcf845de746e3a113c68
Signed-off-by: Axel Castaneda Gonzalez <x0055901@ti.com>
OMAP4: HDMI: Enable ACR packet WA in CPU DAI

For OMAP4430 ES2.0, ES2.1 and ES2.2, enable the ACR packet WA
in HDMI CPU DAI driver to limit the number of ACR packets that
are sent to HDMI sink device. This allows to send ACR packets
at the rate described in HDMI 1.4a.

Change-Id: Ib38fa6dac6f3d85d4b38eb8e6391e6f67aecdd2b
Signed-off-by: vamsi krishna k <x0093442@ti.com>
Signed-off-by: Axel Castaneda Gonzalez <x0055901@ti.com>
OMAP4: TEMP_SENSOR: Add missing carriage returns in print-function call

Due to missing carriage return in print-functions calls
sometimes it's hard to read kernel log.
Fix this so now kernel log reading is more easy.

Change-Id: I399c12f38a8e685ea19c7f79d930fa6ffc59511f
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
drivers:misc: ti-st: protect registrations

Concurrent access to UART2/combo-interface by multiple protocol drivers such
as BT, FM and GPS caused issues during firmware download failure cases or
cases when the firmware download took longer than usual.

This was because of un-safe access to protos_registered & st_states.
Protecting this will also make the registration complete callback un-safe for
sleep.

Change-Id: I1163587ee4ee7561ca591a874f5c403f7da84e58
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
drivers:misc: ti-st: fix unexpected UART close

If suppose the UIM were to die and hence UART were to close when the
Bluetooth/FM or GPS is turned on, prep the ST for a state where-in if
the UIM comes back up, Bluetooth/FM/GPS can be turned on.

Change-Id: If3a0f100c69d485c343e189c4a483db26961b6b7
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
drivers:misc: ti-st: fail-safe on wrong pkt type

Texas Instrument's shared transport driver interpret incoming data from the
UART based on the various protocol drivers registered to the driver such as
btwilink driver or FM or GPS driver which provide logical channel IDs.

In case of bad-behavior from chip such as HCI Event response for a GPS command
or a HCI Event (h/w error event) for a FM response & In case of bad-behavior
from UART driver such as dropping data bytes a fail-safe is required to avoid
kernel panic.

Change-Id: I4a0b4b3152a27830ae85f986f5f2de922f007cd2
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
Signed-off-by: Vijay Badawadagi <bvijay@ti.com>
drivers:misc: ti-st: avoid a misleading dbg msg

Previously the private data of each protocol registered to use ST was
used to determine whether the protocol was registered to use shared
transport or otherwise.
However, now a flag is_registered is maintained to identify whether a
protocol intends to use ST.
Upon closing of the UART the error message relevant to this lack of
un-registration was misleading and this patch fixes that.

Change-Id: I1a452dccd7b4bd53cce923df5b61ce077b7aa466
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
drivers:misc:ti-st: protect against bad packets

We encounter situations where we got bad packet type from the
UART (probably due to platform problem or UART driver issues)
which caused us out of boundary array access,
which eventually led to kernel panic.

Change-Id: I6f0f13168c69e46260c5abb7d7c0b854c61cab7d
Signed-off-by: Amir Ayun <amira@ti.com>
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
drivers: misc: ti-st: Add missing carriage returns in print-functions calls

Due to missing carriage returns in print-functions calls
sometimes it's hard to read kernel log.
Fix this so now kernel log reading is more easy.

Change-Id: I033126f24e5819b2f97564bafd30b3156a95c06c
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
OMAP4: USB Host: Re-implement EHCI Hub Control to workaround errata

The OMAP4 EHCI controller has the following defect (errata ID i640):

Title:
	USB HOST EHCI In TLL Mode Will See The Port Being Disabled Upon Resume
	Or Remote Wakeup.

Description:
	This bug impacts the TLL module when used in conjunction with the EHCI
	part of the USB host module. Upon resume or remote wakeup from a bus
	suspended state, the device will switch from full speed to high speed
	before the host does.This will incorrectly generate a disconnect IRQ on
	the host side (USBSTS[2]:PCD=1), and the hardware will disable the port
	(PORTSC[2]:PED=0). The peripheral will then go back to suspend because
	there is no more activity on the bus.

	PHY mode (non-TLL) is not impacted. OHCI is not impacted.

WORKAROUND:
	The workaround consists of stalling the device for some time so that
	the host can switch to HS before the device.

	The programming guide to follow at the end of the resume sequence is:
	1. The host ends the resume sequence by clearing PORTSC.FPR bit.
	2. The software waits for the TLL to report the LineState change from
	   K to SE0 on ULPI. PORTSC.LS will switch from 0x1(K) to 0x0(SE0).
	3. Gate the TLL ULPI clock and thereby the device controller by PRCM
	   control: the whole TLL is frozen, including the ULPI clock
		- Clear the appropriate OPTFCLKEN_USB_CHx_CLK bit in the
		  CM_L3INIT_HSUSBTLL_CLKCTRL register
	4. Wait 3 us for the host to go to HS.
	5. Restart the TLL ULPI clock and the device controller by PRCM
	   control, to unfreeze the entire TLL, including the ULPI clock
		- Set back the appropriate OPTFCLKEN_USB_CHx_CLK bit in the
		  CM_L3INIT_HSUSBTLL_CLKCTRL register
	6. The USB device switches to HS.

Add a wrapper function to default ehci_hub_control function that is called
for omap4 devices for ports configured for TLL mode. Please note that
OMAP4430 ES2.3 devices are not impacted by this errata.

Change-Id: Iaf3e116c80681a5073febec3a254ac81f90f8bc6
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Ravikumar Vembu <a18394@motorola.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Ruslan Bilovol <x0155540@ti.com>

Conflicts:
	drivers/usb/host/ehci-omap.c
Regulator: TWL6030: Unmask PREQ in MASK_TRANSITION.

Based on board configuration, unmask PREQ so that on de-assertion
or assertion on PREQ{1,2,3} transition Executes ACT2SLP and
SLP2ACT sleep sequence.

By default APPs process group is unmasked, but can be overridden
through board file using struct twl4030_power_data.

Change-Id: Ib9f561c64210e5997865a4bf7a2203dca9a1d695
Signed-off-by: Ambresh K <ambresh@ti.com>
MFD: TWL: Regulator: Link USB LDO with USB OTG

By unknown reason, USB LDO regulator not linked
to USB OTG, it just defined in board file.
This patch adds this, that give possibility
to control USB LDO by regulators framework.

Change-Id: I73dfe3c7944dc46e25bf9bf053b2db36eeae2301
Signed-off-by: Sergii Postulga <x0153364@ti.com>
ARM:OMAP4:Temp sensor: Fixed context restoration of OMAP temp sensor

Spurious thermal alert interrupt is generated when restoring the context
of OMAP temperature sensor driver upon a wake-up from CORE OSWRet/OFF modes.
This spurious interrupt is due to the fact that current SW implementation
restores all HW registers without any specific sequence.
Finally, the thermal alert interrupt handler prints error message because
the temperature reported by the sensor is invalid.

This patch applies a SW sequence taking into the HW constraints to avoid
the generation of cold thermal alert.
HW constraints:
- The HW logic decrements the counter and then starts the temperature
measurement.
- An immediate temperature measurement is possible only if counter is set to
low value.
- The HW logic compares the BGAP_TEMP_SENSOR_DTEMP bitfield with threshold as
soon as the clock is enabled.
- To avoid spurious interrupt, it is mandatory to unmask interrupts (cold
and/or hot) when BGAP_TEMP_SENSOR_DTEMP bitfield is different than 0.
- if BGAP_TEMPSOFF bit sit set, then the sensor is stopped and returns 0.

New SW implementation:
1/ If all registers have been reset:
- Force immediate temperature measurement and wait until
BGAP_TEMP_SENSOR_DTEMP bitfield is updated before completing the full context
restoration.
- Ensure that the BGAP_TEMPSOFF bit is not set to 1 during context restoration.
- Complete the context restoration (mask bits and counter).
2/ If registers have not been reset:
- clears TEMPSOFF bit
- Force immediate temperature measurement and wait until
BGAP_TEMP_SENSOR_DTEMP bitfield is different than 0.

Change-Id: I6e18e2882107b93cccee8fc20f7052994565a40d
Signed-off-by: Sebastien Sabatier <s-sabatier1@ti.com>
ARM:OMAP4:Temp sensor: Keep constant sampling rate

The HW control module uses an internal counter to start periodic
temperature measurement. This HW internal counter is incrementing from
0 to the value of CONTROL_BANDGAP_COUNTER register.
If SW decreases the value in CONTROL_BANDGAP_COUNTER to a value lower than
the current internal counter, then HW logic will increment the internal
counter until its maximum value (coded on 24-bits) and start a new
temperature measurement when internal counter reaches again the new value
from CONTROL_BANDGAP_COUNTER register.
Finally, the next temperature measurement could be delayed by 10 to 20
seconds.

As there is no way to reset this internal counter or to read the intern
counter, the only valid workaround is to keep a constant value in
CONTROL_BANDGAP_COUNTER register and ensure that SW never changes.
This patch uses 250 ms whatever is the thermal zone.

Change-Id: I139a1205e4eb06a558e6442e1c78e83a8c75f0df
Signed-off-by: Sebastien Sabatier <s-sabatier1@ti.com>
ARM:OMAP4:Temp sensor: fix low limit for thresholds

As the full temperature range is -40 DegC to 125 Deg C,
this patch ensures that thresholds are higher than the low
limit (-40 Deg C) instead of 0 Deg C.

Change-Id: I28c49cd53703f9d9ed61458bc61612f4dbb476bb
Signed-off-by: Sebastien Sabatier <s-sabatier1@ti.com>
gccore: only enable the clock when the driver is used.

Change-Id: I23a5831ef320d6ecbdf7e55e0d00c4efc0ec2a14
Signed-off-by: David Sin <davidsin@ti.com>