media: ti-vpe: vip: Fix multiple device open

v4l2-compliance: Multiple open test for VIP fails.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
media: ti-vpe: vip: Fix frame format and intervals enumerations

v4l2-compliance: Various frame format and frame intervals tests fails.
Fix enum_fmt, enum_frameinterval, enum_dramesize along with try/get/set format
to follow the convention.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
media: ti-vpe: vip: Fix priority parameter checking

v4l2-compliance: default_oictl parameter checking was failing

Signed-off-by: Benoit Parrot <bparrot@ti.com>
media: ti-vpe: vip: Fix enuminput error

v4l2-compliance: enum_input test failing

Fix enuminput, but ultimately disabled it until get/set input fucntions are also provided.
Disabled vidioc_expbuf as it is not supported at this time.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
media: ti-vpe: vip: Fix format enumeration to match sensor capabilities

Format enumeration was based on a static/private format table.
Until CSC is enabled the format enumerated must match the sensor capability only.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
rpmsg: rpc: fix unbalanced mutex locking during recovery

An user thread can be blocked while waiting for new response
messages. The thread is unblocked either when a new message is
available for the thread to read or when the remote processor
has crashed and the rpmsg-rpc device has been removed and
recreated as part of the recovery process.

The user thread currently fails to release a mutex lock it
held in the case of wakeup due to the latter event causing
the user process to never be closed properly or be killed.
Fix this unbalanced mutex locking so that the user process
can proceed to close or recover itself gracefully.

Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: return proper error status during recovery in read

An user thread can be blocked while waiting for new response
messages. The thread is unblocked either when a new message is
available for the thread to read or when the remote processor
has crashed and the rpmsg-rpc device has been removed and
recreated as part of the recovery process.

A special error number ENXIO is returned in the file operations
on the file descriptors for the rpmsg-rpc driver to notify the
user process that the underlying device is invalid due to a
crash of the remote processor. An incorrect error number of
EIO is being returned currently if the user thread blocked on
a read is woken up due to a recovery, fix the same to return
the correct value of -ENXIO so that the user process can take
an appropriate action.

Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix potential memory leak of unprocessed skbs

A user thread sends a request for a remote function execution
on the remote processor through a write() fop. All the responses
from the remote service are queued using allocated skbs in the
driver's rpmsg callback. The allocated skbs are processed and
freed in a read() fop. An error recovery causes a blocked user
thread to bail out immediately and any in-flight queued skbs
are left unprocessed. These in-flight skbs are never freed and
can result in a memory leak.

Fix the memory leak by checking for the presence of any of these
unprocessed skbs in the read queue, and freeing them during the
file descriptor's release() function. This also ensures no memory
is leaked for user applications with bugs and not using matching
write() and read() fops.

Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix sysfs entry creation failures during recovery

The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. The remote service can be running on any of the available
remote processors, and the supported functions are published as
different sysfs entries on that particular device. These rpmsg-rpc
devices are deleted and recreated as part of the reboot of the remote
processor during an error recovery. The sysfs entries are also deleted
and recreated. The current logic retains the associated rppc_device
structure and the underlying device pointer if there are any
applications actively using the character device at the time of the
rpmsg-rpc device removal, and reuses it upon the reprobe of the same
rpmsg-rpc device. The creation of the sysfs entries fails with -ENOENT
due to an invalid reference to a non-existing parent object, and this
is exposed first in 3.14 kernel due to the repartitioning of the core
sysfs code into a new common kernfs code.

Fix this by deleting the underlying device pointer in the driver's
.remove, and recreating it with the appropriate new rpmsg server
device as its parent in the driver's .probe function. A name
description field is also added to the representative rppc_device
structure for looking up the service on reprobe as the device name
cannot be used due to the deletion of the device pointer.

Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: maintain a reference device pointer per open fd

The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and is asynchronous
to any of the operations on the exposed character device. A reference
to this device pointer is to be maintained therefore for each open
application so that it can be used during regular fops and until the
file descriptor is closed instead of referencing the rppc_device's
dev pointer, which can become NULL at any point due to a recovery
process. The actual memory of the rppc_device's dev pointer deleted
in the driver's .remove() is freed when all the open applications
have closed either gracefully or forcefully. Any new applications
after a recovery will leverage a newly created device pointer.

Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: use the local device pointer in all file operations

The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and can become
NULL at any point if an error recovery happens. So, switch to using
the local reference device pointer in all the fop functions for
the exposed character device.

Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: revise couple of traces

Couple of traces have been revised to fix some typos. The
traces in the driver's .remove() function are also switched
to use the device pointer of the rpmsg rpc device being
removed rather than the underlying device pointer of the
representative service's rppc_device structure. This is
done to match the corresponding traces from .probe().

Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: rpc: fix ept memory leak during recovery

The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. An endpoint is created in the open() fops, and forms the
source end-point of a dedicated communication channel to allow an
application to send and receive remote function execution commands/
responses on this service. This endpoint address is a child of the
parent virtio device to which the rpmsg-rpc device belongs to. The
virtio devices are deleted and recreated during a remoteproc crash
and recovery process. The associated child endpoints are not deleted
at present during recovery, and the corresponding release() cannot
delete the end-points if it happens after a recovery as the parent
rpmsg-rpc device has already been removed, thereby resulting in a
memory leak during recovery amidst an active usage.

Fix this by deleting all the epts associated with the parent virtio
device of the corresponding rpmsg-rpc device. This is done during the
rpmsg-rpc driver's .remove() which is invoked during the deletion of
the virtio device.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: DRA7: hwmod: Fix CAL hwmod flag to allow sw supervised standby

Although CAL does not support standby mode per se hwmod would not
enabled the functional/interface clock if module is not a master.
This only occurred when CAL would probe without VIP1 enabled.

This changes ensure that i/f clocks are available when CAL is enabled alone.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y

TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y

* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
  ARM: DRA7: hwmod: Fix CAL hwmod flag to allow sw supervised standby
  media: ti-vpe: vip: Fix format enumeration to match sensor capabilities
  media: ti-vpe: vip: Fix enuminput error
  media: ti-vpe: vip: Fix priority parameter checking
  media: ti-vpe: vip: Fix frame format and intervals enumerations
  media: ti-vpe: vip: Fix multiple device open

Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y

Pull in fixes in rpmsg-rpc driver to fixup couple of memory leaks
and various bug fixes during error recovery with active open
applications.

* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: fix ept memory leak during recovery
  rpmsg: rpc: revise couple of traces
  rpmsg: rpc: use the local device pointer in all file operations
  rpmsg: rpc: maintain a reference device pointer per open fd
  rpmsg: rpc: fix sysfs entry creation failures during recovery
  rpmsg: rpc: fix potential memory leak of unprocessed skbs
  rpmsg: rpc: return proper error status during recovery in read
  rpmsg: rpc: fix unbalanced mutex locking during recovery

Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux-3.14.y

TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-3.14.y

* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: fix ept memory leak during recovery
  rpmsg: rpc: revise couple of traces
  rpmsg: rpc: use the local device pointer in all file operations
  rpmsg: rpc: maintain a reference device pointer per open fd
  rpmsg: rpc: fix sysfs entry creation failures during recovery
  rpmsg: rpc: fix potential memory leak of unprocessed skbs
  rpmsg: rpc: return proper error status during recovery in read
  rpmsg: rpc: fix unbalanced mutex locking during recovery

Signed-off-by: Dan Murphy <DMurphy@ti.com>
musb: musb: core: use ->resume instead ->resume_noirq

In commit 0ec8fd70fb ("USB: musb: fix possible panic while resuming")
musb_resume() became musb_resume_early() in order to enable the clocks
early on resume. This piece of the resume code was removed later in
commit 034917612 ("usb: musb: move clock handling to glue layer").
In between the function was renamed from musb_resume_early() to
musb_resume_noirq() by commit commit 48fea9659e ("USB: Rework musb
suspend()/resume_early()").
Now I see that first musb_core is resumed followed by phy and glue
layer and I ask myself is this really what we intend to do? This kind
of revoked the purpose of the first commit (0ec8fd70fb).
Because of this and because it looks wrong to resume before the glue
layer I push it to the ->resume callback.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
musb: musb: core: check link status on resume

The am335x-evmsk support two kinds of suspend:
- standby
  the USB device remains powered while the system goes into suspend

- mem
  the USB device becomes powerless while the system goes into suspend.

In the "standby" case the device resumes quickly. In the "mem" case the
system hangs for a few seconds. It seems to be that the USB-device has
no address (it was disconnected) and the USB stack thinks that it is
fully operational and GetPortStatus returns the status from before the
suspend so it is not a big help here.
This adds a check in the resume path to see if the device mode (A or B)
and the speed is the same. If the device went missing between
suspend/resume (VBUS went down) then MUSB seems to go into B mode and
HS/FS bits are cleared. In that case we clear the port1_status bits and
assume a disconnect. Once the stack learns this it does a "logical
disconnect" and removes the USB-device quickly. Should the device remain
connected during the suspend then MUSB will receives a "CONNECT" interrupt.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
drivers: dma: omap-dma: Enable burst and data pack for SG

Enable the burst and data pack modes for the scatter-gather
in order to improve the throughput of the data transfers.

The improvement has been verified with MMC HS200 mode in
the DRA72 EVM using the iozone tool to compare the read
throughput (in kB/s) with and without burst/pack for
different reclens (in kB).

                              With
    reclen    Baseline   sDMA burst/pack
    ------    --------   ---------------
       64       46568         50820
      128       57564         63413
      256       65634         74937
      512       72427         83483
     1024       74563         84504
     2048       76265         86079
     4096       78045         87335
     8192       78989         88154
    16384       81265         91034

Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>