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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>