rpmsg: omx: fix rpmsg_omx_connect return value

The rpmsg_omx_connect() is currently returning a positive value on
success (as returned by the wait_for_completion_interruptible_timeout
function - remaining jiffies to timeout value) instead of 0. This
regression was introduced by commit,
ac7dcb8 "rpmsg: omx: revise mutex protection for rpmsg_omx file".

This regression is fixed up to return the following as well
   - 0 when omx->state == OMX_CONNECTED
   - -EIO when omx->state == OMX_UNCONNECTED and timeout not expired.

Change-Id: Iee428919d73ebb843421be915e91b9553d71cbd7
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
OMAPDSS: DISPC: Do not enable MFLAG by default

We should not enable MFLAG by default.
DSSCOMP will decide either MFLAG should be enabled or not.

Change-Id: I528ac09c507adc9b25d252990e8d20af36b6ee99
Signed-off-by: Victor Kleinik <x0150886@ti.com>
OMAPDSS: DSSCOMP: Enable MFLAG only for FULL HD compositions with 4 overlays

Enable MFLAG only for FULL HD compositions with 4 pipelines to avoid
conflicts with ISS.

Change-Id: I79f49af577740510c71d1b449852b1caee8adf4b
Signed-off-by: Victor Kleinik <x0150886@ti.com>
OMAP4: Add platform data to support HDMI default display

Adding new platform data to support HDMI default display feature.
HDMI platform data is selected if HDMI is selected as default
display in boot args.

Change-Id: If31be22ecf09140a0c63246bd1a055e01a315a6f
Signed-off-by: Oleksandr Krol <oleksandr.krol@globallogic.com>
OMAP4: Blaze: populate board file with sgx config data

This sgx data will be needed in multi display configuration
to reflect number of framebuffers and swapchains to allocate.

Change-Id: I99373beeb860f777ec1d52558e1410cfc2176c83
Signed-off-by: Oleksandr Krol <oleksandr.krol@globallogic.com>
rpmsg: omx: fix a race condition in rpmsg_omx_probe()

The rpmsg_omx is a client driver on the rpmsg bus, providing a user
space interface to the remote OMX server (represented as a rpmsg_omx
device). The rpmsg_omx device(s) are created at runtime when a remote
processor publishes the device(s) through the rpmsg bus's name service
announcement. The devices are destroyed during a remoteproc recovery
process, unless there are open references to the device. Such pre-
existing handles are rechecked for during the driver probe.

The current rpmsg_omx probe is racy when checking for a pre-existing
omx service device. The rpmsg omx devices are created by a kthread
(the vq messages in omap_remoteproc are processed through a kthread),
and so the rpmsg_omx_probe can be executed in parallel in a SMP
environment. An error can occur in _match_omx_service cb ("Unable to
handle kernel NULL pointer dereference at virtual address 0000002c")
within the probe due to a NULL dev pointer. This race condition is
possible any time a remote processor is booted up, including during
the kernel boot.

The race condition scenario is explained below:

thread1:                          thread2:
...                               ...
rpmsg_omx_probe() for 1st device  ...
  omxserv=idr_for_each(...)       ...
    _match_omx_service(...)       ...
  ...                             rpmsg_omx_probe() for 2st device
  idr_get_new(...) _               omxserv = idr_for_each(...)
  ...               |                _match_omx_service(...)
                    |
  cdev_init(...)    |_               Oops! omxserv->dev is NULL for 1st device
  cdev_add(...)     |
  ...              _|
  omxserv->dev=device_create(...)
  ...

The race condition can be eliminated by making sure the service
channel is added to the list only after the device node is created,
but protecting the entire probe using a lock ensures that the device
name check is also atomic. The spinlock defining the lock is converted
to the more suitable mutex.

Change-Id: Ifcc2e505da6ae32fcb67303852140c98f4200214
Signed-off-by: Oleksandr Tyshchenko <oleksandr.tyshchenko@ti.com>
[s-anna@ti.com: revise patch description and retain variable name]
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: check for proper rproc state before power off

Add a check for the current rproc state in rproc_shutdown() to prevent
powering off the remote processor if it has not been booted completely.
The remote processor would remain in offline state if the boot fails
for any reason, and the cleanup would be handled automatically in the
rproc_fw_boot() function upon a boot failure.

Change-Id: Ie01eee861c0a75d134bda55f573eb42a85ff8b81
Signed-off-by: Oleksandr Tyshchenko <oleksandr.tyshchenko@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
I2C: OMAP: use pm_qos_update_request to set PM QoS constraints

Now PM QoS constraints have been set in omap_i2c_xfer() using
pm_qos_add_request() and pm_qos_remove_request() PM QoS API and this
introduces additional run-time overhead.

So, use pm_qos_update_request() to set PM QoS constraints in
omap_i2c_xfer().

Change-Id: I17746719a3d5a17c72dadd5374f30ec02577084d
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
usb: ehci-omap: configure default PHY settings on boot

On Blaze Tablet, USB PHY doesn't have ability to be
reset because its /RESET line is soldered to Vcc.

As a workaround, during OMAP EHCI initialization we
reset it using [Function Control].Reset=1 bit.
As per datasheet, this resets transceiver but not
the ULPI interface or register set. This means,
that PHY may store previous registers settings.

It is OK if we do 'cold' power ON of board because the PHY
is in its default state after that. However if we do reset
of the board by pressing the 'reset' button or as
result of kernel panic, PHY do not loose its power so PHY's
registers will hold old values that may be incorrect
and an USB device, connected to the PHY may be not enumerated
for example. In Blaze Tablet particular case, devices
are not enumerated after 'reset' button or kernel panic
till power OFF-ON sequence.

In this patch we configure default PHY settings after its
soft reset so EHCI controller will expect correct behavior.

Change-Id: I7747c0a39eb8e51d499bd62c3ac0d311d19a924d
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ext4: check bh in ext4_read_block_bitmap()

Validate the bh pointer before using it, since
ext4_read_block_bitmap_nowait() might return NULL.

I've seen this in fsfuzz testing.

 EXT4-fs error (device loop0): ext4_read_block_bitmap_nowait:385: comm touch: Cannot get buffer for block bitmap - block_group = 0, block_bitmap = 3925999616
 BUG: unable to handle kernel NULL pointer dereference at           (null)
 IP: [<ffffffff8121de25>] ext4_wait_block_bitmap+0x25/0xe0
 ...
 Call Trace:
  [<ffffffff8121e1e5>] ext4_read_block_bitmap+0x35/0x60
  [<ffffffff8125e9c6>] ext4_free_blocks+0x236/0xb80
  [<ffffffff811d0d36>] ? __getblk+0x36/0x70
  [<ffffffff811d0a5f>] ? __find_get_block+0x8f/0x210
  [<ffffffff81191ef3>] ? kmem_cache_free+0x33/0x140
  [<ffffffff812678e5>] ext4_xattr_release_block+0x1b5/0x1d0
  [<ffffffff812679be>] ext4_xattr_delete_inode+0xbe/0x100
  [<ffffffff81222a7c>] ext4_free_inode+0x7c/0x4d0
  [<ffffffff812277b8>] ? ext4_mark_inode_dirty+0x88/0x230
  [<ffffffff8122993c>] ext4_evict_inode+0x32c/0x490
  [<ffffffff811b8cd7>] evict+0xa7/0x1c0
  [<ffffffff811b8ed3>] iput_final+0xe3/0x170
  [<ffffffff811b8f9e>] iput+0x3e/0x50
  [<ffffffff812316fd>] ext4_add_nondir+0x4d/0x90
  [<ffffffff81231d0b>] ext4_create+0xeb/0x170
  [<ffffffff811aae9c>] vfs_create+0xac/0xd0
  [<ffffffff811ac845>] lookup_open+0x185/0x1c0
  [<ffffffff8129e3b9>] ? selinux_inode_permission+0xa9/0x170
  [<ffffffff811acb54>] do_last+0x2d4/0x7a0
  [<ffffffff811af743>] path_openat+0xb3/0x480
  [<ffffffff8116a8a1>] ? handle_mm_fault+0x251/0x3b0
  [<ffffffff811afc49>] do_filp_open+0x49/0xa0
  [<ffffffff811bbaad>] ? __alloc_fd+0xdd/0x150
  [<ffffffff8119da28>] do_sys_open+0x108/0x1f0
  [<ffffffff8119db51>] sys_open+0x21/0x30
  [<ffffffff81618959>] system_call_fastpath+0x16/0x1b

Also fix comment for ext4_read_block_bitmap_nowait()

Change-Id: I078306b8c4e99a0fd8c609e17744249cf8e3358c
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
[Ruslan: cherry-picked from mainline 15b49132]
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
smartreflex: add an nvalue override setting which is used when efuse is missing voltage values (overclock)

Change-Id: I7b0fedd77e8edf59445a130cb06cc092f85dcc4f
opp: add 4430 nvalue override for 1.2ghz (when missing)

Change-Id: I4b8d19a81b7743194c5184f628468b6651710888
opp: add 4460 nvalue override for 1.5ghz (when missing)

Change-Id: I45bca78394e4dca2ec8cec66f3d6db4843c91c6d
ARM: OMAP4: hwmod data: set init_no_reset flag for ipu iommu

This patch fixes a problem with the IPU boot sequence caused
by an improper AMMU/Unicache state upon a retention->active
transition of CORE domain. The AMMU/Unicache is enabled by the
SCACHE_CONFIG.BYPASS bit - a value of 1 enables the cache and
mandates all addresses accessed by M3 be defined in the AMMU.
This bit is not programmable from the A9-side. The M3 boot
sequence starts out with the AMMU/Unicache in disabled state,
and SYS/BIOS programs the AMMU regions and enables the Unicache
during one of its initial boot steps. Out of retention, the
SCACHE_CONFIG.BYPASS bit is enabled by default, irrespective of
whether it was previously enabled or not.

By not setting this flag in the hwmod database, the hwmod
initialization enables the clocks and deasserts RST3. And when
the CORE domain hits either of OSWR or CSWR, the BYPASS bit gets
auto-set, and the M3 boot throws an exception as soon as the M3
core's reset is deasserted since the boot address is typically
not defined in any valid AMMU regions. Setting this flag allows
an IPC driver to take out the resets as required, after doing the
necessary programming. This also keeps the entire sub-system in
RESET if no IPC driver is selected in the kernel.

Change-Id: I20820455b4b1f9860fafa37535ba96a0102d40ea
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP5: hwmod data: set init_no_reset flag for ipu iommu

This patch fixes a problem with the IPU boot sequence caused
by an improper AMMU/Unicache state upon a retention->active
transition of CORE domain. The AMMU/Unicache is enabled by the
SCACHE_CONFIG.BYPASS bit - a value of 1 enables the cache and
mandates all addresses accessed by M3 be defined in the AMMU.
This bit is not programmable from the A9-side. The M3 boot
sequence starts out with the AMMU/Unicache in disabled state,
and SYS/BIOS programs the AMMU regions and enables the Unicache
during one of its initial boot steps. Out of retention, the
SCACHE_CONFIG.BYPASS bit is enabled by default, irrespective of
whether it was previously enabled or not.

By not setting this flag in the hwmod database, the hwmod
initialization enables the clocks and deasserts RST3. And when
the CORE domain hits either of OSWR or CSWR, the BYPASS bit gets
auto-set, and the M3 boot throws an exception as soon as the M3
core's reset is deasserted since the boot address is typically
not defined in any valid AMMU regions. Setting this flag allows
an IPC driver to take out the resets as required, after doing the
necessary programming. This also keeps the entire sub-system in
RESET if no IPC driver is selected in the kernel.

Change-Id: Ifc916db88247d2de9025974eb595fdc32b0e9669
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP: iommu: do shutdown instead of idle on runtime suspend

This patch fixes an issue with resuming/booting the remote processors
in OMAP4+ SoCs when the particular domain goes through a retention
(CSWR or OSWR) to active state transition.

The Attribute MMU (AMMU) registers are not accessible from the MPU
side, and are programmed/restored by the SYS/BIOS RTOS running on the
remote processors during one of its initial steps. The remote cores
expect the Unicache to be in disabled/bypass state before this initial
programming step, in both the cold and warm boot sequences. The AMMU/
Unicache module logic is controlled by the specific h/w reset line
associated with the MMU. Any retention to active transition of the
corresponding remote processor subsystem's power domain, with this
h/w reset line deasserted, applies a retention reset and causes the
AMMU to lose context, but with Unicache/AMMU module enabled. This
hangs the remote processor upon boot/resume as an internal bus fault
is thrown due to the lack of valid AMMU programming registers for the
instruction space that the processor is executing. This scenario is
applicable both during a warm boot (resume) and a cold boot (if there
is sufficient time between the IOMMU programming and the processor
reset deassertion for the domain to enter a retention state).

The IOMMU power management including Device OFF support is currently
implemented through the runtime pm framework. The runtime suspend for
the IOMMU driver is invoked whenever the remote processor is put into
a suspend state. The IOMMU is idled at present on runtime suspend with
the associated h/w reset line left in deasserted state. This leaves
the particular sub-modules clocked and enabled, and susceptible to
the above AMMU context loss problem.

The issue is fixed by defining an IOMMU specific omap_device_pm_latency
structure and using a omap_device_shutdown_hwmods() instead of the
default omap_device_idle_hwmods() within it for deactivate function.
This ensures that the OMAP hwmod framework will assert the h/w reset
line upon a runtime suspend and allows the IOMMU to be programmed /
restored back properly upon runtime resume. Logic (implemented through
dev_pm_qos latency constraints) is already present in the iommu driver
preventing any OSWR/CSWR transitions on the corresponding power domain
during active use-cases.

Change-Id: I2d35d35129e313620ba86e6ed6ce6a605f056942
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
[s-anna@ti.com: rewrite commit description completely]
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: usb host: mux: force PHY STP line to low state in idle/off mode

If OMAP HS USB Host hwmod is not in active state,
USB remote wakeups are handled by I/O daisy chain
logic due to erratas around Host that don't
allow to use HW smart standby/idle capabilities:
 - i571: USB host EHCI may stall when entering smart-standby mode
 - i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

As a result, we enable different clocks to the Host quite late
and its internal state machine may enter in some bad state.
Next patch http://review.omapzoom.org/32086 (OMAP: USB Host: Wake
up L3_init clockdomain ASAP on USB remote wakeup event)(1) fixed
this issue for OMAP4470 but it is not enough for 4430/4460
where restoring from OFF mode takes more time.

In this case next behavior has been observed on ULPI lines
for 4430/4460 (say initial OMAP's state is OFF mode):      (2)
 - a device connected to PHY issues remote wakeup
 - the PHY directly represents this state on D0:D1 lines
 - OMAP sees line state change and starts its 'resume from OFF'
   procedure
 - after ~100 uS after D0:D1 change, OMAP asserts STP line
 - PHY starts is internal resume procedure, deasserts DIR and
   starts to generate clocks to OMAP
 - after ~8ms OMAP deasserts STP line and puts the PHY to the
   low-power state immediately (sends 0x84-0x4A 0x84-0x4A 0x84-0x05
   sequence)
 - the OMAP restoring sequence is still in progress and is only on
   its start phase.

After above sequence the ULPI interface is not functional
anymore for OMAP - no matter PORTSC.FPR nor direct access
through INSNREG05_ULPI register you use.
The root cause seems to be related to i693 errata (USB HOST EHCI - Port
Resume Fails On Second Resume Iteration) that says we have to
switch ULPI_CLK to internal clocksource for short time after *each* PHY
suspend, otherwise internal EHCI counter will not reach
18 and second resume iteration will fail.
The reason of why it affects only 4430/4460 but not 4470 is because
after applying patch [1] 4470 restores from OFF mode fast enough
and so internal EHCI logic does not have a chance to
put the PHY in low power mode. Whereas for 4430/4460
the restore-from-OFF sequence is a little bit longer,
and we have PHY-resume and PHY-suspend [2], and after that
after end of restore-from-OFF we try to wakeup the PHY
again and meet the i693 condition.

The workaround here consists in keeping the STP line
in low state until the EHCI is ready to work with PHY.

For this, the patch uses some MUX magic, forcing the
STP to 'safe mode' and pulldown for idle or OFF state
and muxing it back to STP mode for active state.

This prevents wake-up-the-PHY in the middle of restoring from
off sequence and works fine on all OMAP4 SoCs.

Change-Id: I95d7bf707f76519ee7d81f4437d8564f03b5d602
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
Merge remote-tracking branch 'origin/p-linux-omap-3.4' into HEAD
usb: musb: gadget: fix enumeration on heavy-loaded systems

From musb point of view, the Address Assignment sequence during
device enumeration is next:
 - first ep0 interrupt:
	* read the address from USB_REQ_SET_ADDRESS request
	* set up CSR0L.DataEnd bit (that is ACK
	  signalization for the host)
 - second ep0 interrupt:
	* indicates that the request completed successfully
	* set up musb device address
	  Now musb device should answer to this address

From the host perspective, if peripheral device acquires
SET_ADDRESS request, it now may be accessed only using that address.
However, on heavy loaded systems, time between first and
second musb ep0 interrupts may be too long and musb controller
misses requests between. As result, device enumeration may be
unsuccessful. This can be checked on USB3.0 Host and
using USB3.0 test suite (from usb.org) running ch9 tests
for USB2.0 devices.
Usually 'Addressed state/TD9.1: Device Descriptor Test' will fail

The fix consists in checking CSR0L.DataEnd state and assigning
the device address in the first ep0 interrupt handling, so
delay is as minimal as possible

Change-Id: I226911fa0bdba9411db04f139699f3d5959cb24f
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
Merge remote-tracking branch 'origin/p-linux-omap-3.4' into HEAD