USB HOST: TLL: HACK: EHCI Port disabled after resume on ES2.2 OMAP4430

Errata i640 WA function has critical timing between writes to USBTLL
register and to PRCM register. Errata WA needs write to PRCM register
be completed in 500-600ns after a write to the USB register.
While only one CPU is online and utilize ARM MPCore this timing is kept.
If two CPUs are online it is possible situation when activity of another
CPU could significantly affect WA execution timing.

In order to keep i640 WA timings another CPU is calmed while i640 WA
is executed. Using smp_call_function_single() it is forced to run
simple function what doesn't mess caches and write buffers.

There is a restriction for this WA:
i640 is effective for OMAP4430 up to ES2.2. These processors have
two A9 cores. So choosing CPU to calm down is done with one xor
operation. If such workaround needs to be generic it should be
reimplemented with more complex selecting of "other" CPUs.

Change-Id: I8df7d7276e8bcbcd57fbba4087278421f52c47d1
Signed-off-by: Andrii Anisov <x0163225@ti.com>
OMAP: I2C: Wait till functional part of the I2C controller completely becomes valid

Bus busy status bit is not effective when functional part of the I2C controller
is not valid, and bus busy detection in omap_i2c_wait_for_bb() will be skipped
sometimes. So we should wait till functional part of the I2C controller
completely becomes valid, after setting the I2Ci.I2C_CON[15] I2C_EN bit to 1.
For doing that we have to wait till RDONE bit of SYSS register reach "1".

For details see TRM, 23.1.4.3 HS I2C Software Reset.

Change-Id: I989855d6cb2b1aa0098e11245dacb77583fe6647
Signed-off-by: Semen Protsenko <semen.protsenko@ti.com>
OMAP4: DPLL cascading: Removed race condition while entering in the DPLL cascading

Checking if omap is in DPLL cascading has to be under a lock. Without the lock it
can lead to a situation when one thread is waiting for omap_dvfs_lock thinking
that is not in DPLL cascading while another thread, that has locked dvfs
lock, put omap in dpll cascading. So when dvfs_lock will be unlocked the first
thread will run thinking that omap is not in DPLL cascading but it has
been put in DPLL cascading already.

Example:

Assume the device is not in dpll cascading state,
that is omap4_is_in_dpll_cascading = 0.

+--------------------------------+--------------------------------------------+
|           thread 1             |                thread 2                    |
+--------------------------------+--------------------------------------------+
|                                | ->omap4_dpll_cascading_blocker_release() { |
|                                | ...                                        |
|                                | mutex_lock(dvfs_lock)                      |
|                                | ... ->                                     |
| -> omap_device_scale() {       |                                            |
| ...                            |                                            |
| if (omap4_is_in_dpll_cascading |                                            |
|                       == 0)    |                                            |
| mutex_lock(dvfs_lock) ->       |                                            |
|                                | -> ...                                     |
|                                | omap4_is_in_dpll_cascading = 1             |
|                                | ... //enter in dpll cascading              |
|                                | mutex_unlock(dvfs_lock)                    |
|                                | ... ->                                     |
| -> mutex_lock(dvfs_lock)       |                                            |
| ... // do bad things           |                                            |
+--------------------------------+--------------------------------------------+

Change-Id: I2d7769a4b7347197c0c9c149873207a322fd4d5c
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
OMAP4: DPLL cascading: Removed deadlock during DPLL cascading transition

We need take a console lock due to change uart frequency.
We cannot do it under omap_dvfs_lock because it can lead to
deadlock in situation when some thread has taken the console
lock and trying to scale waiting for the omap_dvfs_lock that has
been taken already by DPLL cascading transition.

Example:
+--------------------------------------------+--------------------------------+
|           thread 1                         |           thread 2             |
+--------------------------------------------+--------------------------------+
| ->omap4_dpll_cascading_blocker_release() { |                                |
| ...                                        |                                |
| mutex_lock(dvfs_lock)                      |                                |
| ... ->                                     |                                |
|                                            | -> ...                         |
|                                            | console_lock()                 |
|                                            | omap_device_scale() {          |
|                                            | ...                            |
|                                            | mutex_lock(dvfs_lock) ->       |
| -> ...                                     |                                |
| console_lock() // deadlock                 |                                |
+--------------------------------------------+--------------------------------+

Change-Id: I90f7c66ef9d490a4552e94adddf2e2eb79c58b99
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
OMAP4: DPLL cascading: Removed race between SR calibration and DPLL cascading exit

Before OMAP starts to exit from DPLL cascading the omap_sr_disable() is called
and when it completely exits from DPLL cascading the omap_sr_enable() is called.
A situation can occur when the OPP first calibration or periodic recalibration
of a smartreflex is continue the exit from DPLL cascading is started that stops
the calibration work by calling omap_sr_disable(). The calibration will start
again when we call omap_sr_enable(). A configuration of error generator during
the calibration is depend on flag omap4_is_in_dpll_cascading. So error generator
will be configured supposing that device is in DPLL cascading but actually it is
not. So flag indicating DPLL cascading mode has to be cleared prior to the
omap_sr_enable(), that is before the potential calibration.

Race illustration:

Assume that smartreflex calibration is ongoing and device is in DPLL cascading,
that is omap4_is_in_dpll_cascading = 1
-------------------------------------------------------------------------------
...
omap4_dpll_low_power_cascade_exit() {
  ...
  omap_sr_disable() // disable smartreflex calibration, so it will start
                    // again when we call omap_sr_enable()

  ...               // completely exit form DPLL cascading
  omap_sr_enable() {
    ...
    if (omap4_is_in_dpll_cascading()) // flag is set but cascading is off
      sys_clk_speed = 12288000;
    else
      sys_clk_speed = clk_get_rate(sys_ck);
    ...
  }
  omap4_is_in_dpll_cascading = 0
}

Change-Id: Iac03021ddc8517a09545f158865ee0d354852441
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
OMAP: UART: Specify DMA RX buffer size

At the moment DMA mode is disabled for UART. When enable it -- there is
continuously printing "DMA misaligned error" even though data is aligned
properly (tested with IS_ALIGNED() macro). Actually the problem is in zero
length size for RX DMA buffer.

This patch set RX DMA buffer size equals to default size to prevent futher
problems if DMA will be enabled for UART. Also it set other DMA RX fields to
their default values.

This patch inspired by OMAP5 serial board file (board-omap5evm-serial.c)
in k3.4.

Change-Id: Id73c30892b2104b4283783e740f137514be64a1f
Signed-off-by: Semen Protsenko <semen.protsenko@ti.com>
enable USB networking

USB network adapters are widely used for many cases.
Enable USB networking so rebuild of kernel will not be
required for USB network adapters usage.
OMAPFB: Select correct VSYNC IRQ based on DSS channel

Select correct VSYNC IRQ for asynchronous vsync notification
based on the DSS channel.
Current VSYNC notification supports only primary LCD panel.
To support VSYNC notification for default HDMI display this
patch adds the VSYNC IRQ selection based on the DSS channel
for default display.

Change-Id: I0594e80d4b4850c278e6bdd3b07c0cb63488be39
Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>

Conflicts:
	drivers/video/omap2/omapfb/omapfb-main.c
	drivers/video/omap2/omapfb/omapfb.h
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>
remoteproc: omap: differentiate auto-suspend from system suspend

The omap remoteproc driver sends a mailbox message to the remote
processor requesting it to save its context and then be suspended.
This can happen either through the runtime auto-suspend path or
through the system suspend.

The mailbox message being sent to the remote processor is now
differentiated between the two paths. This differentiation provides
flexibility on the remote processor to allow an application cancel
auto-suspend. This flexibility is needed as there can be some
operations wherein there is no on-going activity between the host
and the remote processor with the remote processor idle waiting for
an event that would take more time to complete than the auto-suspend
timeout.

The auto-suspend cancellation is detected by the driver on the
host-side through a timeout for the processor to be idled, and is
simply rescheduled.

Change-Id: Ifdeeb80a632ac0145194d3c20f66256226e7efd4
Signed-off-by: Shahid Akhtar <sakhtar@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap4: hwmod_data: add clocks to ipu processor devices

The ipu processor hwmod devices (ipu_c0 & ipu_c1) are defined
primarily as pseudo-hwmod devices with only reset controls.
These share the same functional clock along with the ipu hwmod
device that is mainly used for controlling the MMU. This clock
name is added to these pseudo-hwmod devices, as it will improve
the robustness to any HW_AUTO settings performed within the
hwmod framework. There is no major effect on the clock framework
itself, as the clock enable & disable will simply be reference
counted and the functionality would be identical as before.

Change-Id: I865e9690b503e601df27aa0a55cfac45622c4259
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: iommu: relax constraint value to allow CSWR

The iommu driver currently requests a latency constraint,
if configured in platform data, on the power domain it is
present in. These values are required only for OMAP4 and
beyond and is done to ensure the AMMU context is maintained
when the corresponding power domain goes to a low power state
during cpuidle path. The AMMU context is retained in CSWR, but
is lost in OSWR.

The current constraint value (10) for OMAP4+ is high and
restricts the power domain to remain in ON state as long as
the processor is active. This value is relaxed to 400 to
allow a lower power CSWR state during cpuidle path.

The context is saved and restored properly when suspending
the remote processor.

Change-Id: I89fd125f2244ae1691843c3c078aa6314a7ae8a6
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: mailbox: relax constraint to allow powerdomain to go to CSWR

The mailbox registers can be accessed and configured by other remote
processor initiators, and hence the driver has to be responsible for
maintaining the register context when they are active. This is
achieved by the mailbox driver by requesting a latency constraint
on the power domain that it belongs to.

The current constraint value (10) is high and restricts the power
domain to remain in ON state as long as a remote processor is
active. This value is relaxed to 400 to allow a lower power CSWR
state that can still retain the context during cpuidle path and
a remote processor is active.

The constraint is completely removed when the remote processor is
suspended. The mailbox context is saved and restored properly
when suspending the remote processor.

Change-Id: I152b57e982dc8e5739808cbbbe8bd5cc96223ffa
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
i2c: omap: implement shutdown handler

Once i2c driver shutdown has been called, ignore any more
transfer requests. This patch adds the missing callback.

Leave the PMIC i2c (i2c-1) alive, since power_off case needs it
well after shutdown handlers have been called for power_off case.

Change-Id: I4f4553327e5c024f78acb8501864dd9beb1883c3
Signed-off-by: Semen Protsenko <semen.protsenko@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
[Media:Radio] wl12xx: Fix for overflow while getting irq status

->dlen is 8 bit long and so while memcpy there is a chance
that fmdev->irq_info.flag will overflow.

So this patch removes memcpy and instead copies the 16bit flag
register value from skb->data to fmdev->irq_info.flag directly.

Change-Id: I37604b91b2777ed9e56a7e1c1ecefe32e9024170
Signed-off-by: Manjunatha Halli <x0130808@ti.com>
[Media:Radio] WiLink: Add support for Russian Band

This patch adds support for russian band (frequency range
65.8 MHz to 74 MHz).

This frequency range comes under OIRT FM broadcast band which is
currently used by Russia,Belarus,Moldova and Ukraine.

User app has to write "2" to "/sys/class/video4linux/radio0/fmrx_band"
to switch to Russian/OIRT band.

Change-Id: I26ea5b54afab10eb1769e0b07421d0b98ca24eee
Signed-off-by: Manjunatha Halli <x0130808@ti.com>
[Media:Radio] WiLink: Miscellaneous fixes for FM Receiver

This patch fixes below small issues with FM RX,
	1) Enables the support for FM Alternate Frequency
	2) Modifies Wrap_Seek such that seek will try for one time
	   and if it didn't get a good station within, then returns
	   the default frequency according to band.

Change-Id: Id9ca57451847617fade8959154f205cfff06faee
Signed-off-by: Manjunatha Halli <x0130808@ti.com>
[Media:Radio] WiLink: Add support for complete scan

This patch adds support for complete scan feature.

To start/stop/read complete scan user has to write to
'/sys/class/video4linux/radio0/fmrx_comp_scan'

After complete scan read on /dev/radio will give the
scanned results

Change-Id: Ic02408cfbfcea3c10623da8f377a0224ce7b4c31
Signed-off-by: Manjunatha Halli <x0130808@ti.com>
asix: asix_rx_fixup surgery to reduce skb truesizes

asix_rx_fixup() is complex, and does some unnecessary memory copies (at
least on x86 where NET_IP_ALIGN is 0)

Also, it tends to provide skbs with a big truesize (4096+256 with
MTU=1500) to upper stack, so incoming trafic consume a lot of memory and
I noticed early packet drops because we hit socket rcvbuf too fast.

Switch to a different strategy, using copybreak so that we provide nice
skbs to upper stack (including the NET_SKB_PAD to avoid future head
reallocations in some paths)

With this patch, I no longer see packets drops or tcp collapses on
various tcp workload with a AX88772 adapter.

Backported from opensource a9e0aca4b37885b5599e52211f098bd7f565e749

Change-Id: I96b35e1e0037e42b9cda9025e9a72e1cc4996578
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Aurelien Jacobs <aurel@gnuage.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Trond Wuellner <trond@chromium.org>
Cc: Grant Grundler <grundler@chromium.org>
Cc: Paul Stewart <pstew@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
net: usbnet: limit 'tx' and 'done' queue size

The dev->done queue size was not controlled
Thus under heavy load (usually UDP transfers)
if upper layer reads the data from this queue
slowly, it may be increased to fatal size, eating
all accessible memory.

Now the 'done' queue size is limited by RX_QLEN + TX_QLEN

Change-Id: Ie6253c07d6fa7adfccab3af66c19448c920e42a1
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>

Conflicts:
	drivers/net/usb/usbnet.c