omap: omap-mcbsp: fix compilation warnings

 In function 'omap_mcbsp_dai_set_dai_sysclk':
 warning: suggest explicit braces to avoid ambiguous 'else'

Change-Id: Ic273b811371ae12ae76097cc709327443690d39b
Signed-off-by: Leed Aguilar <leed.aguilar@ti.com>
omap-hsmmc: Fix issue during SD card disconnect

Turning off IO & PBIAS cells and then SD card VMMC
as soon as we get disconnect interrupt. Failure to do
so is causing current spikes (latch-up issue)which
can potentially burn the I/O cells.

Enabled Debounce logic in TWL6030 so that erroneous
disconnect/connect interrupts will be suppressed.

This will also fix issue where SD card disconnect
event was not getting detected when SD card is very
slowly plugged out.

Change-Id: I13f55451718b8cce3448245395b8d1344d4a2790
Signed-off-by: Viswanath Puttagunta <vishp@ti.com>
OMAP4: HDCP: add support for M0/V' check from user space lib

Add support for M0 and V' calculations from user space lib

Change-Id: Ifb55d44723885d307c39d4bb7eb06cd4d50a469f
Signed-off-by: srinivas pulukuru <srinivas.pulukuru@ti.com>
OMAP: HSI: fix build error in HSI char driver

Added a needed #define when hsi_char module is built.

Change-Id: I1498c4d19812a4dd452b1a3192581c692cfd8226
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: hsi_char: clarified parameters usage for RX/TX config

added some comments to explain the meaning of structures used for
RX/TX set and get ioctl.

Change-Id: I87bedbb3f6544e27327485748c1ed754cfb7f591
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
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: SW WA for HSR in dead state after SW reset with pending errors

SW WA for HSI-C1BUG00088 "OMAP4430 HSI : No recovery from SW reset
under specific circumstances"

Description of issue:
It seems that in certain cases after some errors are detected by
HSR (frame timeout and/or tailing bit error and/or overrun), writing
the SW reset bit (SYSCONFIG.SOFTERESET to 1) may put the HSI in a
"dead" state in which it does not answer anymore to L4 OCP commands.
It seems that in certain cases after some errors are detected by HSR
(frame timeout and/or tailing bit error and/or overrun), writing the
SW reset bit (SYSCONFIG.SOFTERESET to 1) may put the HSI in a "dead"
state in which it does not answer anymore to L4 OCP commands.

Workaround is:
* Set HSR_MODE_P1.MODE_VAL = sleep and HSR_MODE_P2.MODE_VAL = sleep
* Acknowledge all errors (do not care if there is any) by writing
  HSR_ERRORACK_P1 and HSR_ERRORACK_P2
* Set SW reset

HW fix will be available for OMAP5430

Other changes:
* Removed write to Read only register HSI_HSR_BREAK_REG

Change-Id: I0cbcc0ccc7d0cec991e8a76fff7b6d1ffb01f5b7
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: Fix Multiple IRQ disabling

    When we add the CA_WAKE signal as a wakeup source in the daisy chain,
    we are not sure that the L3_INIT power domain is going to RET/OFF mode.
    So if we receive a HSI frame, the HSI IP generate an IRQ and at the
    same time the IOPAD Daisy Chain too can generate an IRQ scheduling
    HSI tasklet.

    The consequence is that the do_hsi_tasklet()  can be scheduled from
    hsi_mpu_handler() or prcm_interrupt_handler(). In both handlers, the
    tasklet is scheduled then the HSI IRQ of the correponding port is
    disabled in the GIC.

    At the end of the tasklet, the HSI IRQ is enabled in the GIC.

    In some corner cases (race conditions) HSI tasklet can be scheduled twice
    at the same time, so 2 disable_irq_nosync() are done but only one tasklet is scheduled and
    so only one enable_irq() is done leading to HSI IRQ remaining disabled.

    To forbid this double tasklet scheduling we use an atomic test_and_set lock.

Change-Id: I98f6555bfbd48ecd246f588f5859b44ff591b59d
Signed-off-by: Cedric Poignet <a0919860@ti.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: Port 2 support

Removed hardcoded value to port 1
Enhanced platform data to include CAWAKE name and mode for each port
Modified HSI platform function to check both ports

Supported configuration are :
Port 1 only
Port 2 only
Port 1 + Port 2

Change-Id: I9b2ed7a4680a99b61dd2552129a3c5a7dbf23db3
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: FIFO mapping support for Port 2

It is now possible to map all 16 FIFOs to Port 2.
FIFO mapping strategy is now a platform data field given to the driver, rather than a #define.

Change-Id: I1ac2243e75f1e09846ce6c899118d69a2180a7b3
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: Abort clocks disable if FIFO not empty

FIFO content is lost in RET or OFF modes.
To avoid loosing FIFO content, driver now checks FIFOs state before disabling clocks and allowing
L3_INIT_PD to enter RET or OFF.
As a result, HSI clocks are now kept in case of data available in the FIFO.

Change-Id: I5a5f5e0129fe9d3cc16d53e9f96cb710364e1e2f
Signed-off-by: Cedric Poignet <a0919860@ti.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4:HSI: Fix CA_WAKE IRQ loss in L3INIT OSWRET

In Open Switch Retention, the asynchronous wake up of the HSI IP
is not possible from the CA_WAKE signal.

Open Switch Retention is possible in Idle mode, so we forbid the idle
mode in this patch when we need it.

In details:
When CAWAKE goes low with data still in RX FIFO, HSI driver tries
to disable the clocks, but aborts because FIFO is not empty. So IO
Daisy chain is not enabled.

Since CAWAKE is low, HSI driver sets SYSCONFIG to SMART_IDLE_WAKEUP
and SMART_STBY_WAKEUP, so L3INIT_PD might be powered down. Since
IO daisy chain has not been enabeld, we miss the following CAWAKE
high event.

Fix consists in always forcing SYSCONFIG to NO_IDLE while there
is any HSI activity, and let omap_hwmod re-enable the
SMART_WAKEUP features as soon as HSI doesn't need the clocks anymore.

Change-Id: I86994aafa4701e549faa52e9d8648f6bd4a464ef
Signed-off-by: Cedric Poignet <a0919860@ti.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP: HSI: Fix missed interrupt in polling mode

Wen a RX interrupt occurs, it is disabled unconditionnaly whether there is still some polling
ongoing or not. But polling is not one-shot mode, but must remain enabled once set.
Consequently it can happen that despite polling is enabled and HSI driver expects an interrupt to
inform about RX data reception, this interrupt will never arrive more than once.

This issue was fixed in K35, but didn't make it through K3.0

Change-Id: I62ad87ed54eff4022260f0f4c781cd74996f49f3
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: Fix missign break; setting HSI in 3-wires mode

There is a missing break in the SET_ACREADY_NORMAL IOCTL, so every time we use
the HSI_IOCTL_SET_ACREADY_NORMAL, the HSI is set in 3 wires modes, which forces the
ACREADY to default to 1.
This is why we observed a frame being received while ACREADY doesn’t go back to 0.

This was causing ACK timeout issue.

Change-Id: I20accfa258810fb836667d333555456753df46d1
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
Reported-by:wonhee <wonhee48.seo@samsung.com>
omap_hsi: Don't make /sys/kernel/debug/hsi/*/counters world writable

Change-Id: Id0b0928682cc6db6d763bdb5d340128afb17033b
Signed-off-by: Benoit Goby <benoit@android.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: retry omap_device_scale until PM ready

omap_device_scale() has a dependency on PM framework and constraint
is that module using this function needs to be loaded later than PM
(omap4_pm_init()) or make sure the function is called at the later
stage of the driver once PM is loaded.

omap_device_scale returns -EBUSY when PM framework is not ready to
be functional. This can cause wrong HSI Fclock setting as the HSI
driver is loaded up and attempts omap_device_scale before the PM
framework is ready. Instead, if the PM framework is not ready and
omap_device_scale fails on module load, we retry on every open until
clock change is successful.

Change-Id: I85b233c8b0d11a98529862b11316e4d3963a50ac
Reported-by: Narasimha Gururaj <x0083234@ti.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: make omap_hsi_is_io_wakeup_from_hsi bool

When HSI is not enabled on the config, omap_hsi_is_io_wakeup_from_hsi
may return a negative value. Instead, make omap_hsi_is_io_wakeup_from_hsi
return a bool as the return is a bool operation - it either "woke up"
or not.

Change-Id: If29ca4e83ab2477ae5db9bc266620d06f58f3b96
Signed-off-by: Axel Haslam <axelhaslam@ti.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
OMAP4: HSI: PM: Errata: DSP woken-up by HSI CAWAKE signal

Description:
There is a silicon bug in HSI IP.
The logic for generating the SWakeup for DSP is same as the logic for generating
SWakeup for MPU, even when DSP interrupt generation is disabled.
As a result when the MPU Wakeup is generated, a false DSP wakeup is also
generated.

Consequences of this bug in below scenario:
- Modem interface (HSI is enabled)
	- The system is allowed to suspend
	- When CAWAKE signal has activity, it will wake-up MPU; it also wakes up
	DSP incorrectly
	- The DSP is not able to handle this wake up correctly.
	- Next suspend, system can’t enter in off-mode because DSP remains
	active

This errata needs to be handled in two scenarios:
a) If the device has woken-up from RET/OFF through CAWAKE signal and is taken
care as part of wakeup from suspend.
b) During MPU active and HSI transitioning from its internal low power state,
will generate SWakeup signal which eventually wakeup's DSP. This prevents
DSP (Tesla) from entering low power state and thus handling this corner case
in HSI interrupt handler as recommended by silicon team.

Change-Id: Icfb3aabb3290b5dc9d81e142b01882bb2c3130bf
Signed-off-by: Vinay Chaurasia <vinayc@ti.com>
Signed-off-by: Ambresh K <ambresh@ti.com>
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>