MFD: twl6040-codec: cancel synch all active works on suspend

The TWL6040 vib_update work has to be canceled synchronously
before continue suspending, because of:
- it may sleep while accessing to I2C bus and, as result, WFI may be
reached in the middle of its execution and that may prevent system
from entering to OFF state.
- the device suspend handler may switch TWL6040 device to sleep
state while vib_update work is still active.

Change-Id: I77b681188976378eec9242ea64dc5f001960d279
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
TI TFW: omap die governor: cancel synch panic guard work on suspend

The decrease_mpu_freq_work has to be canceled synchronously before
continue suspending.
The decrease_mpu_freq_work may sleep because of accessing to I2C bus as
result WFI may be reached in the middle of its execution which will
prevent system from entering to OFF state.

Change-Id: Ief29ba634b9d296f8aa82f94bd39687c65b331ec
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
SMC: Update to AG01.06p4 release

With this SMC driver version present in MSHIELD-DK 1.7.10 and using
corresponding PPA/PA, the crypto driver now uses DMA beyond a certain
data size threshold.

It fixes some statbility issues observed since introduction of DMA
in MSHIELD-DK release 1.7.2

        * start using GFP_ATOMIC instead of GFP_KERNEL in
                aes_sync_operate() and tf_digest_hw_perform_dma()
        * tf_clock_timer_start() now called in tf_clock_timer_cbis()
        * fixed potential memory leak in aes_sync_operate

Change-Id: Ifcb4653b0cad7dc2e5cf61bd58631c56d7738dd7
Signed-off-by: Trusted Logic <smc_support@trusted-logic.com>
Signed-off-by: Bryan Buckley <bryan.buckley@ti.com>
Signed-off-by: Srinivas Pulukuru <srinivas.pulukuru@ti.com>
ARM: OMAP: Voltage: PMIC data: rename vp_vddmin and vp_vddmax fields

We used to use PMIC data defined min and max voltages which were a
balance between what the SoC supports and what PMIC supports.
As a first step to ensure scalable solution, we split the meaning
to now indicate PMIC's max and min voltages indicated by min_volt
and max_volt.

All voltage values are retained and will be modified in next
series of patches.

Change-Id: I475c6094bb6efd0142431c14cd94a48e2a8ca199
[oleksandr.kozaruk@ti.com, nm@ti.com: port to Android kernel]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
OMAP3+: VP: introduce SoC limit parameters

Introduce Voltage Processor level limit which maps to
values per SoC.

The actual VP limits are programmed using the following
logic:
vddmax as the lower value of SoC/PMIC's capability
vddmin as the higher value of SoC/PMIC's capability

Change-Id: Ib58b41f56f06dfbd59f3e6d1a129fd1496d04d07
[oleksandr.kozaruk@ti.com, nm@ti.com: port for Android]
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
[t-kristo@ti.com: original patch]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
OMAP3+: VP: do not allow voltage lower than retention voltage

Do not allow the Voltage Processor to go below the retention
voltage even if HLOS or SmartReflex AVS module requests it.

This is to prevent unsafe voltages from ever being achieved
on the device. if the voltage domain cannot function below
the retention voltage during inactive retention power state,
there is hardly a possibility for the voltagedomain to function
at lower voltages in active scenarios

Change-Id: Idd1b199431c15002cf212d84e26e83d1940f9387
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: PM: TWL603[02]: update min, max voltages

In TWL6030 depending on the value of SMPS_OFFSET efuse register the
voltage range supported in standard mode can be either between
~0.6V - ~1.3V or ~0.7V - ~1.4V. In TWL6030 ES1.0, SMPS_OFFSET efuse
is programmed to all 0's where as starting from TWL6030 ES1.1 the
efuse is programmed to 1.

Since the operational support is from TWL6030 ES1.1, and some of
the TWL6030 firmwares allow us to override the SMPS_OFFSET, we use
the 1.41V as the max voltage and min as 0V as the voltage values
from ~0.7 - ~1.4v are equidistant for each step value or in other
words, 1 step is symmetric 12.66..mV in this range.

In case we are unable to do anything about the offset, then we throw
out a warning and continue as the system should still be able to
function despite the higher value configuration.

Change-Id: I6f93b7ba4694d96f96ce53a1bbe8f058e62c4bc8
[nm@ti.com: rewrite, split up and new controls]
Signed-off-by: Nishanth Menon <nm@ti.com>
[oleksandr.kozaruk@ti.com: original patch]
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
OMAP4: VP: recommeded VP registers settings

Settings for vddmax were different from recommended.
The recommendations are different for 4430 and 4460. There are
no recommended settings for 4470 yet. Set it as for 4460.

Recommended settings(in millivolts):
-------+--------------+------------
       |     4430     |    4460
-------+--------------+------------
 MPU   |  1360(0x35)  |  1380(0x58)
 IVA   |  1240(0x2b)  |  1375(0x36)
 CORE  |  1170(0x26)  |  1250(0x2c)
-----------------------------------

Set recommended register settings in voltage processor.

Change-Id: Ibf9f46eef76da7858245b028558a69e0de4a645b
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>
omap: ramconsole: set ramconsole start address as 256MB

Currently RAM console start address is set as 512MB which
is not applicable to system with 512MB RAM. To make it
generic across OMAP platforms, make it 256MB

Change-Id: Ib29c70735ef793b3f7877c873f0e2d14857f6b9a
Signed-off-by: Devaraj Rangasamy <dev@ti.com>
OMAPDSS: DSSCOMP: Skip manager set to overlay if manager is currently blank.

This is done to prevent call of dispc_set_channel_out when manager
is blanked. And to prevent changes to dispc registers, when dispc
is disabled (all managers blanked).

Change-Id: I0887abd3a9e883c09e75ef0a5f0632c40754d24d
Signed-off-by: Volodymyr Frolov <volodymyr.frolov@ti.com>
Signed-off-by: Kostiantyn Luzan <x0166170@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>
twl6040: errata: PDMUP State In Sleep/Deep Sleep Mode

When AUDPWRON is set to 0 at any time in the IC operation to
put it into sleep or deep sleep mode, there is a finite probability
that the value of PDMUP could be at logic 1 (VDDVIO). In this state,
the resistive pulldown on OMAP on this pin results in a current drain.

Adding new impacted revisions (ES1.3, ES2.0, ES2.2) to errata workaround.

Change-Id: I049fe85eb2e1e9d04c72a9820f3adcc25db35646
Signed-off-by: Vadym Shovkoplias <shovkoplias.vadym@ti.com>

Conflicts:
	arch/arm/mach-omap2/board-44xx-power.c
Revert "OMAP4: Android Kernel Names and Versions"

This reverts commit 222dcf5a83f2cf51181b778c963b80c0b9e54911.

We are going to use CONFIG_MODVERSIONS instead of this.

Change-Id: I32a4e5921540a7cd116b5b0ab1abfd2001d8e5fc
Signed-off-by: Tate Hornbeck <tate.hornbeck@ti.com>
OMAP4470 LPDDR interface configuration update for 466MHz

Some instability with OMAP4470 when running the DDR at 466MHz is
discovered. This instability is resolved with updated LPDDR settings:

- DLL delay should be set to 461ps:
  DDR_PHY_CTRL_1_SHDW[11:4] = 0x37

- Read latency should be set to 0xB:
  DDR_PHY_CTRL_1_SHDW[3:0] = 0xB

- Slew Rate should be set to “FASTEST” and Impedance Control to “Drv12”:
  CONTROL_LPDDR2IOx_2[LPDDR2IO1_GR10_SR] = 0
  CONTROL_LPDDR2IOx_2[LPDDR2IO1_GR10_I] = 7
  where x=[1-2]

Change-Id: Ifa47a7ccae437225db5838039e528c04250a911d
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>
OMAP4: otg: phy: fix charger detection

Charger detection feature is not correctly used
and thus makes some regressions if OTG was used in
the host mode. Charger detection takes 500 ms so
if some device is attached to the host after 500 ms
it will be suddenly resetted.

This feature is enabled by default after reset/cold boot
so always affects PHY usage, also it wasn't disabled during
calling omap4_charger_detect. So finally this was wrongly
interpreted as "phy requires 200ms to start" (in latest
versions - 300ms). After fixing this we can safely remove
uggly mdelay after powering on the PHY.

Change-Id: I901d1613f1f72df408158a086ce94c554aeab186
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
OMAP4: otg: phy: remove uggly mdelay(300)

The original issue with powering on the PHY (and using
300 ms delay after this) is not related to internal
processes in the PHY but is in the incorrect charger
detection future usage.

Now when it is fixed, we can safely remove this uggly
mdelay that sometimes was called in atomic context and
leads to unacceptable system freezing

Tested with different hubs, devices, and booting scenarios.

Change-Id: I54b770d27ab140dd1de4103397881dd3fb807221
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
USB: musb: check input parameter in dma_controller_destroy

Function dma_controller_destroy is visible to other code
so input parameter should be checked before work on it.

Change-Id: Ic28b4b7b950cf33734ef8f2ab9f0b4420ed42f06
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
Fix disabling printk's build error.

Disabling printk's via CONFIG_PRINTK in the menuconfig gives the build error:

arch/arm/common/built-in.o: In function `end_syslog_dump':
~/a-3.0/arch/arm/common/fiq_debugger.c:524: undefined reference to `log_buf_copy'
arch/arm/common/built-in.o: In function `begin_syslog_dump':
~/a-3.0/arch/arm/common/fiq_debugger.c:514: undefined reference to `do_syslog'
arch/arm/common/built-in.o: In function `dump_kernel_log':
~/a-3.0/arch/arm/common/fiq_debugger.c:208: undefined reference to `log_buf_copy'
make: *** [.tmp_vmlinux1] Error 1

This was tested on both the 4AI.1.2 and 4AI.1.3 releases with the same result.

Change-Id: I432408bdd4ee07a261d11ca6710a56164512438b
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>
Signed-off-by: x0182794 <volodymyr.mieshkov@ti.com>
USB: gadget: f_mtp: fix send ZLP packet algorithm.

If size of the data that sent from MTP-device to computer is a multiple of
wMaxPacketSize (usb endpoint) then at the end of transfer device must
send ZLP packet. Previously in f_mtp module a variable 'maxpacket' that
used to send ZLP packet was always equal to 512. For USB2.0 wMaxPacketSize
equals 512 but for USB1.1 wMaxPacketSize can be 64, 32, 16 or 8. Now variable
'maxpacket' contains real value of wMaxPacketSize in all USB modes and ZLP
packet is sent correctly for USB1.1.

Change-Id: I75606c954119dea2a76d955849a47208df0d2db0
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@ti.com>
omap: hwmod: enable clocks before deasserting hardreset

The enable code currently deasserts the hard-reset before
turning on the clocks. These kind of reset lines are limited
only to processor-device like IPs such as DSP or IPU or
IVA, which actually need the clock to be enabled first.

The code that deasserts the hard-reset has therefore been
relocated to execute after the clocks are enabled, to avoid
the hard-deassert traces (failed to hard reset).

Change-Id: Id9c413b315c927295cf4be7f986f6e1a710b9ef8
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>
Signed-off-by: Paul Hunt <hunt@ti.com>