greybus: loopback: add runtime pm support

Add runtime pm to the loopback driver so that
the module wakes up from suspend while a test
is executed.

Testing Done: Let the module enter standby and
execute a loopback test.

Signed-off-by: Axel Haslam <haslam_axel@projectara.com>
Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: spi: Add runtime_pm support

Add runtime operations to the spi driver so that the
module is woken up when an spi transfer is started
and put back to sleep when the transfer is done.

Testing Done: Let the module enter standby and initiate
an spi operation. The operation wakes up the module
and succeeds.

Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: pwm: Add runtime_pm support

Add runtime pm support for the pmw driver.

Testing Done: Set the parameters of pwm0, and enable.
Disable pwm0 and let the module enter standby.
Enable pwm0, and observe that with an oscilloscope
that the wave form is the same as before.

Signed-off-by: Axel Haslam <haslam_axel@projectara.com>
Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: gpio: Add runtime_pm suppourt

Add runtime pm support for the gpio driver.
Since there is no remote wakeup support, the
module will not suspend as long as a gpio is
requested.

Maybe an optimization could be made, to allow suspend
if all the requested gpios are in output mode, since
the bridge should maintain the state of the gpio
during suspend.

Testing Done: using the test board, let the
gpbrige enter standby and request a gpio.

Signed-off-by: Axel Haslam <haslam_axel@projectara.com>
Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: uart: Add runtime pm support

This adds runtime pm support for the uart driver.

Testing Done: Using the test daughter board, let
the gpb bridge enter standby and do a uart transfer
operation.

Signed-off-by: Axel Haslam <haslam_axel@projectara.com>
Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: i2c: add runtime pm support

Add runtime pm support to camera i2c bridged phy device class driver

Testing Done:
 - Passed #gb_test.sh -v -t i2c

Signed-off-by: David Lin <dtwlin@google.com>
Signed-off-by: Axel Haslam <haslam_axel@projectara.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: gbphy: add gbphy runtime pm support

Since GBphy is a child of the Bundle device driver, for those runtime pm
settings that are common to all the protocol drivers need to go in to
the GBphy bus driver.

Testing Done:
 - Check gbphy driver can be autosuspended

Signed-off-by: David Lin <dtwlin@google.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: camera: add runtime pm support

Add runtime pm support to camera protocol device class driver.

Testing Done:
 - Make sure white camera module is able to runtime suspend and resume
   when the camera is being used

Signed-off-by: David Lin <dtwlin@google.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: audio: add runtime pm support

Add runtime pm support to audio protocol device class driver.

Testing Done:
 - Use white speaker module and check the interface is autosuspended when
   it's idle and resumed when playback audio

Signed-off-by: David Lin <dtwlin@google.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Reviewed-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: bundle: add runtime pm support

This patch adds runtime pm support for the bundle core. Unbound bundle
devices are always deactivated. During probe, Runtime PM status is set
to enabled and active and the usage count is incremented. If the driver
supports runtime PM, it should call pm_runtime_put() in its probe
routine and pm_runtime_get_sync() in remove routine as bundle needs to
be resume before it can be deactivated.

Testing Done:
 - Check runtime_status of the bundle driver when bundle goes to suspend

Signed-off-by: David Lin <dtwlin@google.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: interface: add runtime pm support

Configure and enable runtime pm support for the Interface. Refer to the
12.2. The Interface Lifecycle of the Greybus specification for details
on the requirements for transitioning from ENUMERATED to SUSPEND and
vice versa. All the Bundles for the Interface have to be either OFF or
SUSPENDED before the Interface can be autosuspended.

Testing Done:
 - Check the runtime_status of an interface driver and validate the
   suspend current of a module.

Signed-off-by: David Lin <dtwlin@google.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: bundle: add activate and deactivate

AP shall send the Bundle Activate Operation to power on a bundle, and
send the Bundle Deactivate Request after closing all the associated
connections for power down.

Testing Done:
 - Check for the return code of the bundle activate and deactivate
  operation sent

Signed-off-by: David Lin <dtwlin@google.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: es2: fix arpc response lookups

Fix arpc response lookups that were truncating the 16-bit response id to
8-bit, something which would have lead to all arpc calls timing out
after the 256th request.

Testing done: Enumerated and ejected a module on EVT2.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: es2: Fix 'make check' warnings with arpc

This is what I got:

greybus/es2.c:1130:29: warning: restricted __le16 degrades to integer
greybus/es2.c:1140:22: warning: incorrect type in assignment (different base types)
greybus/es2.c:1140:22:    expected restricted __le16 [usertype] id
greybus/es2.c:1140:22:    got unsigned short [unsigned] [usertype] <noident>
greybus/es2.c:1162:52: warning: incorrect type in argument 8 (different base types)
greybus/es2.c:1162:52:    expected unsigned short [unsigned] [usertype] size
greybus/es2.c:1162:52:    got restricted __le16 [usertype] size
greybus/es2.c:1164:31: warning: restricted __le16 degrades to integer
greybus/es2.c:1253:34: warning: incorrect type in argument 2 (different base types)
greybus/es2.c:1253:34:    expected unsigned char [unsigned] [usertype] id
greybus/es2.c:1253:34:    got restricted __le16 [usertype] id

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: audio: Maintain proper codec state during shutdown sequence.

During shutdown sequence, in case all modules are already removed,
codec state is not updated. Though it's not causing any harm for now,
but it's good to maintain proper codec state. Fix this.

Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: audio: Fix incorrect codec state modification

In case module is removed dynamically with ongoing playback, during
module cleanup codec state is mistakenly modified. State should be
modified for module only. Fix this.

Fixes: 76414cb499b7 ("audio: Use single codec driver
registration")

Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: es2: fix arpc return value

ARPC should return 0 on success, but instead was returning the number of
jiffies left until the timeout.

This caused cport_reset() to report an error and an incorrect error
message to be printed when disabling a connection.

Reported-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Tested-by: Alex Elder <elder@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: es2: Implement APBridgeA RPC (ARPC)

Implement ARPC. In first time, we are going to use it to
implement new request but the goal is to update all existing vendor
request to use ARPC.

In addition, Convert the current USB Vendor request for CPort Reset
to ARPC so that we can be sure that the port has been fully reset
by the time the request completes.

Testing Done:
  AP can reset APBA Cports by using the ARPC command.
  In addition, tested with a hacked firmware that cause error during
  the Cport reset, and Greybus printed the error "failed to reset cport".

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: es2: Add a new bulk in endpoint for APBridgeA RPC

Add a new bulk in endpoint in order to get RPC status
from APbridgeA without to have to poll on control endpoint.

So the new endpoint layout is:
EP0: control EP
EP1 and EP2: muxed endpoints (bulk in and out)
EP3 to EP14: direct muxed endpoints (bulk in and out)
EP15: ARPC bulk in endpoint

Note:
This patch is allocating ARPC URBs but does nothing with them.
The following patch will use them.

Testing Done:
  Tested with an APBridgeA enumerating 16 endpoints.
  Kernel doesn't print Not enough endpoints found in device, aborting!

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: interface: send deactivate prepare when interface is disabled

The AP Interface shall exchange a Greybus Control Interface Deactivate
Prepare Operation with the Interface being powered down.

Testing Done:
 - Check for the return code after sending the deactivate prepare operation

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: control: add connection suspend and resume calls

Adds function calls for handling control connection suspend and resume,
for now all they do is disable and enable control connection.

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: interface: implement unipro link hibernate call

Adds AP implementation of unipro link hibernation set power mode call
needed for proper cport closure and interface suspend and power off
transition.

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: svc: add power mode call for link hibernation

Due to when using set_power_mode to hibernate a link, it won't trigger a
POWERMODEIND event, hence the hard-coded GB_SVC_SETPWRM_PWR_OK would be
returned and it should also be considered as successful result code for
link hibernation. Therefore, adding this set_power_mode_hibernate
function to separate the two calls in order to check with the correct
result code.

Testing Done:
 - Suspend an Interface and observe no set power mode error.

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: svc: add interface resume operation

Add the AP implementation for the Greybus SVC Interface Resume
Operation. This operation allows the AP to request the SVC to resume an
Interface which was previously SUSPENDED, allowing it to later be
ENUMERATED.

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: control: add interface hibernate abort operation

Add the AP implementation for the Greybus Control Hibernate Abort
Operation. AP may use this Operation to abort a previous Control
Interface Suspend or Control Interface Deactivate Prepare Operation.

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: control: add interface deactivate prepare operation

Add the AP implementation for the Greybus Control Interface Deactivate
Prepare Operation. AP uses this Operation during the Power Down
transition to request the bridge to power down after it detects a
subsequent UniPro link hibernation.

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: control: add interface suspend prepare operation

Add the AP implementation for the Greybus Control Interface Suspend
Prepare Operation. AP uses this Operation during the Suspend transition
to request the Interface to enter a low-power mode after it detects a
subsequent UniPro link hibernation.

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: control: add bundle deactivate and activate operation

Add the AP implementation for the Greybus Control Bundle Deactivate
Operation. This operation requests a Bundle to enter the BUNDLE_OFF
state. All Connections associated with the Bundle must be closed prior
sending this operation.

Add the AP implementation for the Greybus Control Bundle Activate
Operation. This operation requests a specific Bundle to transition from
the BUNDLE_OFF state to the BUNDLE_ACTIVE state.

[elder@linaro.org: fixed a typo pointed out by Johan]

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: control: add bundle suspend and resume preparations

Add the AP implementation for the Greybus Control Bundle Suspend
Operation. This Operation is used to request a Bundle to enter the
BUNDLE_SUSPENDED state, all Connections associated with this Bundle must
be closed before issuing this operation.

Add the AP implementation for the Greybus Control Bundle Resume
Operation. This operation request a specific Bundle to transition from
the BUNDLE_SUSPENDED state to the BUNDLE_ACTIVE state.

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: connection: remove CDSI1 hack

This hack is not necessary anymore since the firmware is now able to
handle correctly (dis)connect{ed,ing} operations on the CDSI CPort.

Testing Done: Checked that I could start the camera app several time
              and got the preview each time.

Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: Documentation: Document Authentication interfaces

This patch defined userspace interface of the CAP protocol.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Jun Li <li_jun@projectara.com>
Tested-by: Jun Li <li_jun@projectara.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: Add Component Authentication Protocol support

This patch adds Component Authentication Protocol support in greybus.
The purpose of the CAP protocol is to authenticate the Module hardware,
and it can only be used when it is present as part of the
firmware-management bundle, on a separate CPort.

Compile tested only.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Jun Li <li_jun@projectara.com>
Tested-by: Jun Li <li_jun@projectara.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: camera: Fix size of configure_streams(0)

When APB-A CSI-Tx configuration fails, it is necessary to unconfigure
the camera module issuesing a 0 stream configuration request.
Fix size of request and response to avoid Greybus core complain about
Response size differences.

Testing Done: Triggering the error condition after APB-A CSI-tx
              configuration does not make Greybus core complain anymore

Signed-off-by: Jacopo Mondi <jacopo.mondi@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: camera: Fix number of configured streams

Camera Module may report a lower number of configured streams than the
one requested by the AP.
All the non-supported stream configuration are zeroed.
Make the stream configuration inspection loop take only the valid stream
into account, to avoid unnecessarily accessing zeroed memory areas.

So far, inspecting non valid streams configuration has prove to be
harmless, but as we'll need to inspect stream characteristics as reported
image sizes and format, we have to take only valid configurations into
account.

Testing Done: White Camera Module preview and capture.

Signed-off-by: Jacopo Mondi <jacopo.mondi@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: camera: Early update num_streams and flags

In configure_streams Operation, when returning from the greybus
operation call, we can assign the num_streams and flags variable earlier
so that if the following stream configuration inspection fails, the
caller receives the right number of configured streams anyway

Testing Done: White camera module preview and capture.
              Triggering failure during stream configuration inspection
              makes configuration fails, but avoid segfaulting as
              was previously happening

Signed-off-by: Jacopo Mondi <jacopo.mondi@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: audio: topology: Enable enumerated control support

Added .get/.set callback and relevant changes in parser to enable
enumerated control support for kcontrols and DAPM widget controls.
Currently, it is limited to enumerated strings only.

Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Mark Greer <mark.greer@animalcreek.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: audio: topology: Use csize while computing next_ptr in parser

Size of control elements vary in case of enumerated controls. As a
preparation to enable enumerated control in topology parser, this patch
uses csize while parsing controls & wsize while parsing widgets & its
control to update next pointer.

Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Mark Greer <mark.greer@animalcreek.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: added warning message in case of missing widget

Additional warning message added to notify in case above layer tries to
access widget that is already removed from the list.

Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Mark Greer <mark.greer@animalcreek.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: audio: topology: Add helper API to map controlid with widget name

This API is used by enumerated controls .get/.set callback functions to
fetch control id associated with a widget.

Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Mark Greer <mark.greer@animalcreek.com>
Signed-off-by: Alex Elder <elder@linaro.org>

greybus: light: Initialize mutex before using it

Light protocol driver is suffering from the same issue that was fixed in
camera driver earlier (commit a7c3b0c3c8da).

Big cleanup function is used instead of fine grained control in the
error path, and in one of the cases the mutex was found uninitialized
and so the oops seen in SW-6752.

Initialize the mutex before any code can access it.

Compile tested only.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Revert "greybus: uart: don't use spin_lock_irq()"

This reverts commit bd3c4aa99dc23449699432e0744bcb5af7afa98c.

Someone decided that all use of spin_lock_irq was to be considered a bug
and went on a search-and-replace type "bug-fixing" spree last week.

This is however just plain wrong. Using spin_lock_irq is perfectly fine
in paths were interrupts have not been disabled, and this is in fact
even preferred over the lazy approach of always using spin_lock_irqsave
instead of understanding the code that is being written or modified.

All current uses of spin_lock_irq have already been vetted in this
respect. Also note that it is only used in functions that may sleep,
that is, in functions that must not be called with interrupts disabled
in the first place.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Revert "greybus: es2.c: don't use spin_lock_irq()"

This reverts commit b44c3b5b0307788750eb4c462ed5982236876a8b.

Someone decided that all use of spin_lock_irq was to be considered a bug
and went on a search-and-replace type "bug-fixing" spree last week.

This is however just plain wrong. Using spin_lock_irq is perfectly fine
in paths were interrupts have not been disabled, and this is in fact
even preferred over the lazy approach of always using spin_lock_irqsave
instead of understanding the code that is being written or modified.

All current uses of spin_lock_irq have already been vetted in this
respect. Also note that it is only used in functions that may sleep,
that is, in functions that must not be called with interrupts disabled
in the first place.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Revert "greybus: gb_connections_lock: don't use spin_lock_irq()"

This reverts commit b022fd95108e8b9d202532a74d39e86152bc8f7f.

Someone decided that all use of spin_lock_irq was to be considered a bug
and went on a search-and-replace type "bug-fixing" spree last week.

This is however just plain wrong. Using spin_lock_irq is perfectly fine
in paths were interrupts have not been disabled, and this is in fact
even preferred over the lazy approach of always using spin_lock_irqsave
instead of understanding the code that is being written or modified.

All current uses of spin_lock_irq have already been vetted in this
respect. Also note that it is only used in functions that may sleep,
that is, in functions that must not be called with interrupts disabled
in the first place.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Revert "connection: switch to using spin_lock_irqsave/spin_lock_irqrestore excluisvely"

This reverts commit 426237c515b42b9f06d9a2b1021a6d2c4d440c51.

Someone decided that all use of spin_lock_irq was to be considered a bug
and went on a search-and-replace type "bug-fixing" spree last week.

This is however just plain wrong. Using spin_lock_irq is perfectly fine
in paths were interrupts have not been disabled, and this is in fact
even preferred over the lazy approach of always using spin_lock_irqsave
instead of understanding the code that is being written or modified.

All current uses of spin_lock_irq have already been vetted in this
respect. Also note that it is only used in functions that may sleep,
that is, in functions that must not be called with interrupts disabled
in the first place.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: svc: remove input device handling in SVC protocol

The input device was added before to handle the key(s) connected
directly to SVC, which is not the case anymore. So, this change removes
the gb_svc_key_event() operation and the corresponding input device
code with it.

Testing Done:
Boot tested and tried module insert/removal through AraManager

Change-Id: Iaa541d4aefb5c0ed16caaa39450029de35d7c228
Signed-off-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: kernel_ver: Add kstrtobool()

It was added in 4.6 and is required for one of the use case, copy it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: es2: add support for greybus cport flags

Add support for Greybus CPort flags that are sent to the bridge through
a new USB vendor request when enabling a CPort as part of connection
establishment.

Currently the Greybus control and high-priority connection flags are
recognised and forwarded to APBA.

Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: connection: add support for high-priority connections

Add connection flag to indicate that a connection has high priority.

For the SVC and control connections this may be used by the host-device
driver as a hint to allocate dedicated DMA channels or to use polling to
avoid message congestion.

We also allow drivers to set this flag on their connections, even though
we currently have no use case for this (and the host-device driver is
again free to ignore it).

Note that this mechanism can be used to indicate also high-bandwidth
connections (e.g. wanting larger buffers or dedicated endpoints), but
that that should be done using a separate high-bandwidth flag rather
than overloading the high-priority flag.

Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: connection: prevent drivers from specifying core flags

Prevent drivers from specifying core flags (currently only
GB_CONNECTION_FLAG_CONTROL) when creating connections.

Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: hd: add flag argument to cport_enable callback

Add a flag argument to the host-device cport_enable callback that can be
used to provide hints about the connection being created (e.g.
connection priority).

Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: camera: Add RAW data format

Add support for greybus RAW data format.
Greybus RAW data formats starts from 0x80.

Signed-off-by: Evgeniy Borisov <eborisov@mm-sol.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Reviewed-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: audio: remove the unnecessary return statement

The return statement immediately after the BUG_ON of the gbcodec_write()
call is added by mistake. It's not causing any errors right now due to
that gbcodec_reg is currently not being used.

Testing Done:
- Audio playback on EVT2

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: connection: switch to using spin_lock_irqsave/spin_lock_irqrestore excluisvely

We know that it is a bad idea to explicitly enable IRQs when we don't
don't know if they were already off before we disabled, so switch to the
save _irqsave and _irqrestore functions.

Ultimately, we need to review places in the Greybus drivers where IRQs
are disabled and remove unnecessary instances. This is only an interim
step.

This code will never run from hard irq context, as it is already taking
mutex in the path.

Testing done: booted EVT2.0, ran suspend/resume test app with a period
of 20s for a few dozen cycles.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Jeffrey Carlyle <jcarlyle@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: bootrom: Wait for 10 seconds for mode-switch

The greybus SVC core handles events from the SVC serially today. In some
cases the SVC operations may take too long, for example trying to
activate a dummy interface. If another interface receives a mode-switch
mailbox event in that time, the SVC core wouldn't be able to process it
in quickly enough and bootrom driver will print following error:

bootrom 1-3.3.1: Timed out waiting for Interface Mode Switch from the Module

This can be reproduced easily by attaching a 2x2 module along with any
other normal module like camera or speaker, and doing a unipro_reset
from userspace.

The logs suggest this time to be around 6-7 seconds in most of the
cases. Attaching multiple modules with dummy interfaces may make this
worst.

Lets increase the timeout from 5 to 10 seconds for now, also add a FIXME
for the same.

Testing Done: Tested on EVT 2.0 with camera and a 2x2 module.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: bootrom: send timeout in milliseconds to gb_bootrom_set_timeout()

Rename NEXT_REQ_TIMEOUT_J to NEXT_REQ_TIMEOUT_MS and store the timeout
in milliseconds instead of jiffies.

Suggested-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: bootrom: Enhance timeout error message

The timeout message is very generic today and there are several requests
we can be timing out waiting for.

Update bootrom driver to also track the next expected request and
enhance the error message based on that to confirm the request we timed
out waiting for.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: timesync: Make printout consitent with other greybus messages

The current printout on a TimeSync ping doesn't actually contain the word
greybus and uses the word ping-time in the print string, something that
appears nowhere in our official documentation on this feature. This patch
changes the format string to contain 'greybus' and 'frametime' to bring the
TimeSync printout more in-line with other greybus kernel log strings.

before:
timesync ping-time: ap=8632564 1-svc=8630712 greybus1=8633031 1-8.8=8633026

after:
greybus frametime: ap=8632564 1-svc=8630712 greybus1=8633031 1-8.8=8633026

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: timesync: Initialize the timesync ping fields to zero

Remember to initialize the TimeSync ping fields to zero so that if a
timesync_get_last_event() returns an error - we display a FrameTime that is
obviously incorrect.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: add support for the log protocol

Add support for the new Log class/protocol. This protocol allows modules
to send their internal logging messages to the AP in order to make
module debugging easier.

The protocol is, for now, composed a single module-initiated request.
This request contains a message and associated length. The message is
integrated in the kernel log with dev_dbg(). In order to be displayed
with 'dmesg', the following command needs to be entered first:

$ echo "file log.c +p" > /sys/kernel/debug/dynamic_debug/control

The major portion of this file was initially written by Greg KH.

Signed-off-by: Joel Porquet <porquet_joel@projectara.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: gb_connections_lock: don't use spin_lock_irq()

spin_[un]lock_irq() routines should be used carefully as they things can
go wrong, if they are mixed with spin_lock_irqsave() or other variants.

The main problem is that spin_[un]lock_irq() routines doesn't check if
the IRQs are already disabled/enabled on the local CPU and so
spin_unlock_irq() will forcefully enable interrupts for example.

This may not work well, if some other code was relying on interrupts
being disabled.

Use spin_lock_irqsave() and spin_unlock_restore() instead.

This patch doesn't claim that it fixes the JIRA completely, but
the issue was harder to reproduce for some iterations after this, which
was quite easy to reproduce earlier on.

Tested on EVT 2.0 with lots of debug patches to kernel and greybus.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: es2.c: don't use spin_lock_irq()

spin_[un]lock_irq() routines should be used carefully as they things can
go wrong, if they are mixed with spin_lock_irqsave() or other variants.

The main problem is that spin_[un]lock_irq() routines doesn't check if
the IRQs are already disabled/enabled on the local CPU and so
spin_unlock_irq() will forcefully enable interrupts for example.

This may not work well, if some other code was relying on interrupts
being disabled.

Use spin_lock_irqsave() and spin_unlock_restore() instead.

This patch doesn't claim that it fixes the JIRA completely, but
the issue was harder to reproduce for some iterations after this, which
was quite easy to reproduce earlier on.

Tested on EVT 2.0 with lots of debug patches to kernel and greybus.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: uart: don't use spin_lock_irq()

spin_[un]lock_irq() routines should be used carefully as they things can
go wrong, if they are mixed with spin_lock_irqsave() or other variants.

The main problem is that spin_[un]lock_irq() routines doesn't check if
the IRQs are already disabled/enabled on the local CPU and so
spin_unlock_irq() will forcefully enable interrupts for example.

This may not work well, if some other code was relying on interrupts
being disabled.

Use spin_lock_irqsave() and spin_unlock_restore() instead.

This patch doesn't claim that it fixes the JIRA completely, but
the issue was harder to reproduce for some iterations after this, which
was quite easy to reproduce earlier on.

Tested on EVT 2.0 with lots of debug patches to kernel and greybus.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Revert "greybus: don't use spin_lock_irq()"

This reverts commit 469fbe5da0229edcb42aa08bef8e10feaa37e6d7.

It isn't correct in places.

Reported-by: Gjorgji Rosikopulos <rosikopulos_gjorgji@projectara.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: timesync: Enforce TimeSync locks as subordinate to Interface locks

gb_timesync_svc_teardown() is called from gb_timesync_svc_del() and issues a
command to a remote Interface to switch off its timers. The lock ordering
is TimeSync => Interface in this case. However gb_module_del() takes an
Interface lock then calls gb_interface_del() => gb_timesync_svc_del() in
this case the lock ordering is Interface => TimeSync.

This patch fixes by removing the taking of the Interface mutex in
gb_interface_timesync_do_something(). If an Interface is present in the
TimeSync linked-list - it is by definition intf->enabled.

Reported-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: don't use spin_lock_irq()

spin_[un]lock_irq() routines should be used carefully as they things can
go wrong, if they are mixed with spin_lock_irqsave() or other variants.

The main problem is that spin_[un]lock_irq() routines doesn't check if
the IRQs are already disabled/enabled on the local CPU and so
spin_unlock_irq() will forcefully enable interrupts for example.

This may not work well, if some other code was relying on interrupts
being disabled.

Use spin_lock_irqsave() and spin_unlock_restore() instead.

This patch doesn't claim that it fixes the JIRA completely, but
the issue was harder to reproduce for some iterations after this, which
was quite easy to reproduce earlier on.

Tested on EVT 2.0 with lots of debug patches to kernel and greybus.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Jeffrey Carlyle <jcarlyle@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Revert "greybus: ratelimit errors usually seen on unipro_reset"

This reverts commit 9b891f4fda8dfd6c1d8dc16479c5f6d418a9ccc7.

We discussed this over the other thread,

[PATCH 0/2] Improve watchdog's implementation a bit,

and decided that we shouldn't be trying to hide the watchdog reboot
problem by using such patches, rather we should make sure they occur
consistently so that the real problem can be fixed.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: adjust kernel version check for led_sysfs_is_disabled

When building greybus against a 3.18 kernel the following error is generated:
light.c:205:9: error: implicit declaration of function 'led_sysfs_is_disabled'
[-Werror=implicit-function-declaration]

led_sysfs_is_disabled was not added until 3.19 kernel cycle

Verification:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/linux/leds.h?h=linux-3.18.y
(no function led_sysfs_is_disabled defined here)

Testing Done:
- Successfully built greybus for 3.18 kernel

Signed-off-by: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: ratelimit errors usually seen on unipro_reset

It is believed that excessive serial messages from greybus
on suspend/resume is leading to watchdog bite.
There is still discussion going on whether ratelimiting
prints would really fix anything, except it may reduce
traffic on serial console and probably bring out real issues
in the front.
So in order to meet the alpha requirement, we all decided to
get ratelimit change "as a TEMP fix" and decide later whether
we should revert back once we get proper suspend/resume implementation.

Please follow the discussion on Jira card SW-6261.

Testing Done: Build tested against ara/main branch.

Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Reviewed-by: Konstantin Buhchev <buhchev_konstantin@projectara.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: sdio: avoid extra memory operation at data transfer

Right now greybus sdio uses the greybus operation_sync to transfer data,
this will imply an extra memcpy at greybus core that we can avoid.

Also with this change we remove the need for an extra buffer to store
intermediate copy.

So, let us create the operation and do the memory operations in the sdio
driver.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: connection: add trace events before disabling connection

This is what we are doing elsewhere:
- Send enable/create trace events after enabling/creating stuff.
- Send disable/remove trace events before disabling/removing stuff.

This wasn't followed in a same way while disabling connections. Fix it.

Compile tested.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: firmware: prefix char-device with 'gb-'

This will make it consistent with any other character devices we have
for greybus and let us identify greybus character devices easily.

Compiled tested only.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: timesync: Rework timesync removal serialization logic

We need to make sure we adequately cancel and quiesce any scheduled
TimeSync synchronization operations in the case of greybus.ko being yanked
out of memory i.e. when doing an EHCI runtime suspend or just a plain
rmmod. The scenario is a new TimeSync sync operation has been scheduled.
Next gb_timesync_svc_remove() runs. In this case we should terminate any
scheduled work, terminate our ktime tracking timer and state transition to
GB_TIMESYNC_STATE_INVALID to ensure no other context may schedule any new
TimeSync operations.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: timesync: Fix transitions to the INACTIVE state

Analysing a backtrace associated with the current EHCI runtime suspend code
has highlighted several places where its perfectly valid to make a
transition to GB_TIMESYNC_STATE_INACTIVE when not already in the
GB_TIMESYNC_STATE_INIT state, for example failure to issue a TimeSync
enable command to the SVC can and should legitimately call
gb_timesync_teardown() - at this point the state will be
GB_TIMESYNC_STATE_WAIT_SVC and it's legitimate and desirable to transition
to the INACTIVE state in this case. This patch fixes by removing the
restrictive and incorrect restriction on the transition to INACTIVE only
being valid when state == GB_TIMESYNC_STATE_INIT.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Tested-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: timesync: Do not hold mutex on cancel_delayed_work_sync

There is a scenario where gb_timesync_svc_remove() can run, attain a mutex
and call cancel_delayed_work_sync(). In the meantime a worker may already
be running and trying to attain the same mutex but will never do so as the
gb_timesync_svc_remove() path is holding the mutex and waiting on the
delayed_work_sync() to complete - leading to deadlock. This patch addresses
by calling the cancel_delayed_work_sync() before locking the relevant
mutex.

Reported-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Tested-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: firmware: Add license and copyright header to application

Add license and copyright header to the firmware.c test application.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: manifest: Disallow reuse of control cport

We should be checking if any of the bundles contains a CPort with its id
set to the special value of '0', which is reserved for control CPort.

Discard the bundle in that case.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: svc: Pass the correct pointer to input_free_device()

In gb_svc_input_create() fn, on failure, wrong pointer
was being passed to input_free_device(). Correct it.

svc->input gets initialized only on successful return of this fn,
so it is absolutely wrong to pass svc->input to input_free_device().

Testing Done: Tested on EVT2.0 platform.

Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: camera: Create and destroy data connection on demand

Creating the data connection at probe time makes it impossible to
support multiple inserted camera modules as they would all try to
establish a data connection to the same CPort on the AP side. Create and
destroy the data connection when configuring the streams instead, as a
single module can be streaming at a time.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Tested-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: camera: Fix data connection setup

When the module is in the configured state, an attempt to change the
configuration must first tear down the data connection to update its
parameters, as the APB1 bridge doesn't support modifying the CSI
transmitter configuration when it is already started.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Tested-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: camera: Clean up on stream configuration failure

When the camera pipeline can't be configured due to a failure of one of
the components (failure to start the CSI transmitter for instance),
components that have already been setup for video streaming need to be
set back to a quiescient state. This is especially important to ensure
that a stream configuration failure won't keep the UniPro links in high
speed mode forever.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Tested-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: svc: disable connection after all its users are gone

gb_svc_del() can be called during removal of gb-es2.ko module as well,
and in that case we would like to properly shutdown all modules and
interfaces as USB is still alive.

This requires that we don't disable the svc connection, at least for tx,
as that will be used while removing modules and interfaces.

Disable only rx to begin with, as we shouldn't be handling any requests
from the SVC. Disable tx only after all the users of svc connection are
gone.

Tested on EVT 2.0 by remove gb-es2.ko module. There are still few
errors, specially while quiescing the connections (-22), but not that
many.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: camera: Initialize mutex before using it

We are using the mutex from gb_camera_cleanup(), which can get called
even before the mutex is initialized.

Fix it by initializing the mutex early enough.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Reviewed-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: connection: Return bool from gb_connection_intf_find()

This is used only to check if an existing connection already uses the
cport_id or not and doesn't really need to return pointer to the
connection.

While at it, also rename it to suit its purpose.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Remove extra blank lines

This patch removes few blank lines across the repository at places where
two blank lines were present together or when a blank line is present at
the start or end of a routine.

Note that this doesn't remove most of them from greybus_protocols.h as
they were added on purpose.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: firmware: Fix spelling mistake

s/directly/directory :)

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: timesync: Do 64 bit divisions in a 32 friendly way

We need to use 'do_div()' when doing 64 bit division or modulo division
since the kernel will not pull in the gcc builtins __aeabi_ldivmod and
__aeabi_uldivmod on 32 bit builds.

Reported-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: uart: Fix minor number leak

On the gb_uart_remove() path we are forgetting to do a release_minor()
leading to a minor number leak. This is a simple one-line fix.

Tested on EVT 2.0

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: audio: Ratelimit err messages in bundle, topology driver

Earlier I have shared a patch to rate limit err messages in audio_codec
driver. However, missed to include suggestion from Mark to do similar
changes in audio bundle & topology parser as well. Doing it now.

Testing Done: Compile tested

Fixes: 4cb3d109e5fc ("audio: Ratelimit err messages")
Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Remove apbridgea_shutdown_xx sequence if already done

While reordering gb_deactivate sequence to avoid protocol error this was
mistakenly added even during shutdown_tx/rx. It is supposed to be done
immediately after stop_tx and only once.

Fixes: 739f25d5f490 ("audio: Reorder gb_deactivate sequence to avoid protocol error")
Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Use mute_stream callback to initiate GB data xfer

Currently trigger callback is used to start/stop greybus tx/rx
path. This works well for almost all scenario except few
specially handled usecases by Android Audio subsystem.

In case of Music playback followed by Incoming ringtone, above
layer tries to trigger_pause from one FE dailink and start a
fresh playback via different FE dailink. Since, same BE dailink
is used for both cases, an invalid state transition is requested
i.e. from PAUSE->START. This fails & thus causes ringtone playback
failure. With built-in codec, trigger callback is not required to
initiate data xfer unlike gb-codec driver.

This state transition should be handled in Android layer, but
since it can lead to multiple side effects for various usecase
we are trying to avoid trigger callback in gbcodec driver as well.

Signed-off-by: Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
Reviewed-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: update UniPro Set Interface Power Mode operation to match spec

Bring the gb_svc_intf_set_power_mode() up-to-date with the current Greybus
specification.  This largely involves adding more members to the structure
sent across the wire.  Also change the camera code to use the new
operation properly, with default values passed for the new necessary
arguments.  The correctness of these default values is confirmed via testing
and by asking Rob Johnson.

We must make sure to zero the request structure sent across the wire, lest
bite us most cruelly, and we fix by changing the Set Power Mode
Response structure to use a __u8 rather than a __le16.

Testing Done: Took a picture with a camera module, received error code
when passing deliberately incorrect values for new parameters, got proper
-EIO and Greybus result code printed when operation stopped halfway
through.  Could induce error by initializing request struct with random
nonsense, and can stop it by initializing request struct with zeroes.

Associated Firmware Changes: 1669-1671 on Android N Gerrit for SW-2945

Signed-off-by: Eli Sennesh <esennesh@leaflabs.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: connection: Avoid unnecessary line breaks

Some line breaks weren't required as we never crossed 80 columns, remove
them.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: hd: Export host device tracepoint from hd.c

There is no point keeping this code in core.c, while its only used by
hd.c. Relocate it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Remove legacy suspend/resume callbacks

We should be using the PM hooks available within the 'struct
device_driver', instead of adding legacy suspend/resume callbacks.
Remove them.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: Use BIT(2) for GREYBUS_ID_MATCH_CLASS

Bit 2 was left unused, use it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: core: Make greybus_match_one_id() return bool

This routine always returns 0 or 1 and a return type of 'bool' suits it
the best. Update it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: bootrom: Compile as a separate module

User space doesn't break anymore with new greybus modules and its time
to make bootrom a separate module.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: remove obsolete SVC result codes

The "busy" SVC result codes are gone from the spec. Delete them.

Testing Done: compile.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: pwm: Fix compilation with v4.3 kernel

pwm_is_enabled() wasn't enabled by v4.2-rc1, but it was based of
v4.2-rc1. It was actually first included in v4.3.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

greybus: camera: Add debug data format

Add support for greybus debug data format.
Greybus debug data format id is 0x42.

Signed-off-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Acked-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>