msm: camera: Make AXI stop/abort/reset and overflow recovery
mutually exclusive.

This would avoid potential problems when AXI bus is stopped when
recovery is in progress and vice versa.

Change-Id: I44ef2c4f7b54f81aef5be41293a5f70099307a13
CRs-Fixed: 561680,586602
Signed-off-by: Alok Kediya <kediya@codeaurora.org>
msm: bam_dmux: reset bam hardware when A2 goes into pc

Reset the bam hardware when A2 goes into power collapse so that the A2
can be reset after the disconnect ack is sent from bam_dmux to A2.  This
allows the A2 to remain in sync with the bam hardware which prevents
possible unrecoverable data stalls from occuring.

This change reverts commit b11a52c7748e3f5fba7850fb843cabd9ad4878e7 but
adds special handling for the subsystem restart case so that the issue
fixed by b11a52 is not reintroduced.

CRs-Fixed: 433400
Change-Id: Ie476e249b03bb6bd40abc8981472684664d34ae6
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
msm: bam_dmux: wait for DL thread to shutdown in case of SSR

In case of Subsystem Restart, recent targets require that the downlink
processing thread be signaled to shutdown eariler and that the SSR
process wait for the DL thread completely shutdown otherwise an unclocked
register access could occur which might cause a kernel panic.

CRs-Fixed: 451694
Change-Id: I9216c6006bdc8941dd3c03bd6aff14cd732540bc
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
msm: bam_dmux: Use IPC Logging for string formatting

BAM DMUX currently formats a string into a local buffer before passing the
pre-formated string directly to IPC Logging. This results in an extra copy
operation and adds an extra timestamp. It also limits the printed string to
the size of the local buffer (which is currently 80 characters). Remove the
pre-formatting code and use the formatting capability in IPC Logging which
removes the local length limitations, improves performance and removes the
duplicate timestamp.

Change-Id: I11712d5232daee58ac2f0d5ec78a8ba11af1ca04
Signed-off-by: Zaheerulla Meer <zmeer@codeaurora.org>
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
msm: bam_dmux: correct sps_transfer_one() flag usage

From debugging the underlying BAM layer, bam_dmux has been discovered to
be using extraneous flags when invoking sps_transfer_one.  Although these
extra flags have no functional impact, they confuse debug efforts by
masking when events actually happen.

In the transmit direction, SPS_IOVEC_FLAG_INT is redundant when
SPS_IOVEC_FLAG_EOT is specified.  Remove the TX uses of FLAG_INT.

In the receive direction, neither SPS_IOVEC_FLAG_INT nor
SPS_IOVEC_FLAG_EOT is required.  FLAG_EOT is set by the remote side when
it transmits, and FLAG_INT is assumed by the hardware.

CRs-Fixed: 471804
Change-Id: Ia867f5685ab3dacb2a8cbb3070874e401c1a08ea
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
msm: bam_dmux: reduce notify_all() logging

Notify_all() logs a message to the internal log for each client that gets
notified.  This consumes a lot of log space for little real information.

Reduce the logging to a single statement indicating when and why
notify_all() was called.  It can be safely assumed that every valid
client will be notified when notify_all() is called.

Change-Id: I5ae6ea72a734e37dce05539e2de3108ed5b2b40d
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
msm: bam_dmux: increase shutdown logging granularity

In the power collapse shutdown path, some of the major events are grouped
together in the span between two log statements.  It is difficult to tell
which event might be the cause or victim of a delay.

Add a few additional log statements to help identify when exactly each
major event occurs to assist debugging any possible delays.

Change-Id: I904f1be98b57026bd2499b034c8113c01afb1869
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
msm: bam_dmux: delay shutdown until DL polling is complete

Bam_dmux assumes that a shutdown event will not occur while downlink (DL)
polling is active. If this assumption does not hold, bam_dmux stops
polling, but does not cleanly switch back to interrupt mode until the next
power-on event. This is a problem because the next power-on event could
occur in the distant future and until that time some resources may be
incorrectly accessed or not released. Instead, if a shutdown event occurs
while DL polling is active, delay processing of that event until polling
completes.

CRs-Fixed: 503046
Change-Id: I67e4216b4820942e6070944557cd13f59600a2aa
Signed-off-by: Brent Hronik <bhronik@codeaurora.org>
msm: bam_dmux: Update UL wakeup timeout to two seconds

The current uplink (UL) wakeup timeout of one second does not allow the
remote side enough time to trigger a watchdog and recover from some serious
problems. Increase the UL wakeup timeout to two seconds to provide the
remote side enough time to trigger the watchdog, if necessary, without
significantly impacting user experience due to an overly long data stall.

Change-Id: Ia9f85bb9822ce500c3d41b894a945fc6ecc75fc7
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
msm: bam_dmux: prevent duplicate subsystem restart

If a subsystem restart is triggered while BAM DMUX is waiting for a
power control response, then BAM DMUX will timeout and trigger another
subsystem restart which will cause a kernel panic.

Check if an SSR is already in progress before triggering another
subsystem restart.

CRs-Fixed: 515398
Change-Id: I9e8e5513f6568da9c0090fd97c671a9bc824c43b
Signed-off-by: Eric Holmberg <eholmber@codeaurora.org>
msm: bam_dmux: add downlink processing state logging

State transitions of the downlink packet processing task are not directly
logged.  This leads to information gaps when debugging downlink issues.

Add explict logging of the state transitions to provide complete
information on what the downlink processing task has done.

Change-Id: Ie253c9739447da6ed236e865b7f1ed318e13cb6e
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
msm: bam_dmux: tune downlink polling parameters

This change disables the BAM DMUX adaptive timer - this is to address
concerns about drops in TCP throughput for some use cases with the timer
enabled.  It also sets the aggregation to 3ms to save power while not
compromising performance. Power tests show a savings of 3-4% (compared to
having the timer poll the BAM pipe every 1 ms) for LTE (40Mbps downlink and
25Mbps uplink) and HSPA (7Mbps downlink and 384Kbps uplink) with no
degradation in performance.

Change-Id: Ia51eae773723e60d8b051766ad80bfb0a16f5f6d
Signed-off-by: Anurag Singh <anursing@codeaurora.org>
msm: bam_dmux: add loopback support

Bam dmux is currently very difficult to isolate and provide measurements
for common metrics, such as throughput and latency.

Add hooks into bam_dmux to allow for a seperate dynamically
loadable loopback module. This allows bam dmux to be isolated, and to
provide more accurate measurements of the above metrics.

Change-Id: I174d900dea73cca27d32a54a908f43728059be30
Signed-off-by: Brent Hronik <bhronik@codeaurora.org>
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
msm: bam_dmux: Fix race condition during SSR

BAM DMUX drivers set the global flags to identify the SSR during
SUBSYS_BEFORE_SHUTDOWN notification, but the flags change is not reflected
in some code paths like msm_bam_dmux_write().

Add the SSR flag check and SRCU locking to complete all pending bam dmux
writes before returning the control in SSR call back function for
SUBSYS_BEFORE_SHUTDOWN notification.

CRs-Fixed: 584805
Change-Id: I26647b485977943f272c44f7450ed6c4a4aa62f3
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
msm: bam_dmux: modify DL low memory algorithm

Bam_dmux maintains a pool of dynamically allocated buffers for the BAM DMA
engine to use as destination memory for Downlink (DL) data.  The allocation
requests for the buffers are done using flags to indicate delays are
tolerable and either the memory or an error should be returned immediately
to bam_dmux as the buffers are normally allocated within various hot paths
inside of the driver.  If a low memory allocation failure is encountered
when attempting to replenish the pool of buffers, bam_dmux will either
attempt the memory allocations later when the next scheduled pool refilling
occurs if there is at least one buffer remaining in the pool, or will
schedule a delayed task to retry the buffer allocation until atleast one
buffer can be put into the pool.

This mechanism of handling low memory situations has two flaws.  First, the
allocation type used by bam_dmux does not trigger the standard low memory
recovery mechanism within the memory management subsystem.  Second, the
peripeheral on the otherside do the DMA engine has a limited hardware based
flow control mechanism that will not release flow control with only one
buffer queued to the DMA engine.

To assist in system recovery, and avoid a data stall, create a cold path
that is tolerant of memory allocation delays and is triggered when the hot
path encounters an allocation failure.

CRs-Fixed: 589665
Change-Id: If72b0eaef285ac6dfd99e97bef1cd7df154e3a48
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
Merge "Merge "csdio: Remove the driver""
Merge "Merge "Merge "csdio: Remove the driver"""
Merge "Merge "csdio: Remove the driver""
Merge "Merge "Merge "csdio: Remove the driver"""
Merge "Merge "csdio: Remove the driver""