platform/kernel/linux-rpi.git
8 years agogreybus: timesync: reduce initial startup time
Bryan O'Donoghue [Tue, 19 Jul 2016 14:04:37 +0000 (15:04 +0100)]
greybus: timesync: reduce initial startup time

Currently we have a long initial delay when initiating the first operation
to synchronize the FrameTime. That made sense during development of the
feature since we did synchronization asynchronously and wanted to give some
grace time for new Interfaces to be added before initiating a new
synchronization. On the PM runtime resume path though we do a synchronous
restoration of FrameTime and in this case waiting for 1 second before
initiating the first operation is clearly wrong.

This patch reduces the initial operation time bringing the synchronous call
time down by 990 milliseconds.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: move all firmware prefix strings to one place
Greg Kroah-Hartman [Wed, 20 Jul 2016 17:11:37 +0000 (10:11 -0700)]
greybus: move all firmware prefix strings to one place

The firmware prefix is hard-coded in a few different places.  Put it all
in one handy #define, for when/if we ever decide to change it in the
future...

Testing: 'strings gb-firmware.ko gb-bootrom.ko | grep ara_' produced the
 same output before and after this patch.

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: hibernate UniPro link in activation error path
Johan Hovold [Wed, 20 Jul 2016 14:40:27 +0000 (16:40 +0200)]
greybus: interface: hibernate UniPro link in activation error path

To be well-behaved, we should hibernate the link before disabling UniPro
in case the link has already been established (i.e. when the interface
type has been detected as UniPro or Greybus).

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Reviewed-by: Patrick Titiano <ptitiano@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: fix power_state documentation
Johan Hovold [Wed, 20 Jul 2016 14:40:26 +0000 (16:40 +0200)]
greybus: interface: fix power_state documentation

Reword the power_state attribute documentation to make it clear that an
attempt to boot and possibly enumerate an interface is made when writing
"on" to the file, and that on errors the interface will again be powered
down.

Drop the incorrect claim that writing the currently read value has no
effect, since no such guarantees can be made (e.g. several writers may
be sleeping on the interface mutex).

Also fix some minor language issues.

Reviewed-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Patrick Titiano <ptitiano@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: add power_state attribute
Viresh Kumar [Wed, 20 Jul 2016 14:40:25 +0000 (16:40 +0200)]
greybus: interface: add power_state attribute

User space needs the capability of powering ON or OFF an Interface for
multiple use cases. For example, userspace may want an Interface
currently in its S3 boot stage, to boot into its S2 Loader stage to
update the bridge SPI flash. Or the Interface is running its S2 Loader
stage and updated the SPI flash with the new S2 Loader firmware and
wants to boot into the new S2 Loader firmware.

Another use case can be, Android wants to disable (not eject) a
misbehaving module.

Add a 'power_state' sysfs file within the interface directory. It can be
read to know the current power state of the Interface and can be written
to power ON or power OFF an Interface. Possible values that can be
written or read from it are: "on" and "off".

Testing Done: Tested by enabling/disabling camera module on EVT 2.0.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
CC: David Lin <dtwlin@google.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
[johan: drop es3-quirk duplication, add to power attribute group, fix
return value, drop tags ]
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Reviewed-by: Patrick Titiano <ptitiano@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: prevent reactivation during removal
Johan Hovold [Wed, 20 Jul 2016 14:40:24 +0000 (16:40 +0200)]
greybus: interface: prevent reactivation during removal

Make sure to prevent an interface that is going away from being
reactivated.

This is needed to preemptively close a race between the upcoming feature
to reactivate a powered-down interface and physical removal (i.e.
module_removed event processing) as well as logical removal (e.g. the
current system-suspend hack).

Reviewed-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Patrick Titiano <ptitiano@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: make sure type is invariant during reactivation
Johan Hovold [Wed, 20 Jul 2016 14:40:23 +0000 (16:40 +0200)]
greybus: interface: make sure type is invariant during reactivation

An interface is not expected to change its type after a power down and
reactivation so make sure to treat that as a fatal error.

This is complicated by the current Toshiba ES3 hack which requires us
to retry activation as Greybus interfaces are sometimes misdetected as
UniPro interfaces. Handle that by only retrying activation the first
time an interface is activated, and for interfaces already detected as
having Greybus type.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Reviewed-by: Patrick Titiano <ptitiano@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: clean up ES3 activation-retry hack
Johan Hovold [Wed, 20 Jul 2016 14:40:22 +0000 (16:40 +0200)]
greybus: interface: clean up ES3 activation-retry hack

Clean up the ES3 activation retry-hack and isolate it in the interface
code.

This way the retry hack can be reused when we soon start allowing
interfaces to be reactivated after having been powered down.

Reviewed-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Patrick Titiano <ptitiano@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: do not read DME during reactivation
Johan Hovold [Wed, 20 Jul 2016 14:40:21 +0000 (16:40 +0200)]
greybus: interface: do not read DME during reactivation

It will soon be possible to reactivate an interface that has been
powered down after already having been activated. In that case there's
no need to re-read the DME attributes as part of activation as the
values are already cached.

Reviewed-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Patrick Titiano <ptitiano@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: use an enum for interface type
Johan Hovold [Wed, 20 Jul 2016 14:40:20 +0000 (16:40 +0200)]
greybus: interface: use an enum for interface type

Use an enum for the interface type instead of using the SVC protocol
values directly.

Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Reviewed-by: Patrick Titiano <ptitiano@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: module: suppress activation error message for dummy interfaces
Johan Hovold [Tue, 19 Jul 2016 13:24:50 +0000 (15:24 +0200)]
greybus: module: suppress activation error message for dummy interfaces

We currently handle dummy interfaces by deactivating them using
activation error paths, but we don't want the corresponding
module_inserted error message to be printed.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: amend interface registration message
Johan Hovold [Tue, 19 Jul 2016 13:24:49 +0000 (15:24 +0200)]
greybus: interface: amend interface registration message

Amend the interface registration message with the detected interface
type, and only print the Ara VID/PID and DDBL1 attributes for the types
for which they exist.

Also drop the now redundant message about a detected dummy interface
from the activate operation helper.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: make attributes type dependent
Johan Hovold [Tue, 19 Jul 2016 13:24:48 +0000 (15:24 +0200)]
greybus: interface: make attributes type dependent

Make most interface attributes type dependent (e.g only UniPro and
Greybus interfaces should have a DDBL1 Manufacturer ID attribute).

Note that the power attributes (e.g. current_now) will only be visible
for UniPro- and Greybus-type interfaces (i.e. interfaces that can draw
power).

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: partition attribute group
Johan Hovold [Tue, 19 Jul 2016 13:24:47 +0000 (15:24 +0200)]
greybus: interface: partition attribute group

Partition the current attribute group into four groups for UniPro,
Greybus, power and common attributes.

This is a step in refining the interface-type handling as attributes are
type dependent.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: interface: add interface-type attribute
Johan Hovold [Tue, 19 Jul 2016 13:24:46 +0000 (15:24 +0200)]
greybus: interface: add interface-type attribute

Add an interface-type string attribute that represents the detected
interface type as either "dummy", "unipro", "greybus", or "unknown".

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: arche-platform: Add support for init-off feature
Vaibhav Hiremath [Tue, 19 Jul 2016 08:01:46 +0000 (13:31 +0530)]
greybus: arche-platform: Add support for init-off feature

Disable wake_detect interrupt after request

As part of SW-4344/SW-7061, now we are enabling FW flashing
to all builds. That means check for need of FW upgrade is
going to be present in all builds, and moving to FW_FlASHING
mode from active is heavy operation; so the idea here is
simplify this process and save the boot time due to switching
back-n-forth between ACTIVE<=>FW_FLASHING modes.

So we decided to put unipro into OFF state by default on boot,
which can be changed through DT property. If arche-platform
device node has "arche,init-off" property set, then unipro
will be in OFF state on boot. User can bring it back by

 # echo active > /sys/devices/arche_platform*/state

And to simply the exit code of probe() fn the
arche_platform_coldboot_seq() has been shifted to the
bottom of the _probe() fn.

Testing Done: Tested on EVT2 platform, with and without
"arche,init-off" property, multiple times.
Note: I am seeing SW-7128, which is not related to these changes.

Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Tested-by: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: connection: drop the svc quiescing operation
Johan Hovold [Tue, 19 Jul 2016 15:21:27 +0000 (17:21 +0200)]
greybus: connection: drop the svc quiescing operation

Connection tear down is being reworked, and the SVC quiescing operation
is going away.

Let's remove this operation now along with the coupled second ping from
our intermediate tear down implementation.

This both avoids unnecessary noise in the logs resulting from the fact
that the SVC side of the quiescing operation was never merged, and
speeds up connection tear down slightly.

Testing done: Tested on EVT2 using runtime PM.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: sdio: add switch voltage operation
Rui Miguel Silva [Tue, 19 Jul 2016 14:41:30 +0000 (15:41 +0100)]
greybus: sdio: add switch voltage operation

Core sd/mmc needs the start_signal_voltage_switch operation to be
defined to issue a voltage switch command. So, we define it here even
though we do not need to take in action on it, since all voltage control
is done in the Module.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: sdio: convert vdd kernel values to greybus
Rui Miguel Silva [Tue, 19 Jul 2016 14:41:29 +0000 (15:41 +0100)]
greybus: sdio: convert vdd kernel values to greybus

We need to convert vdd kernel values to greybus ones. And we get this by
shifting the kernel values by 8.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: bootrom: Use "s2l" instead of boot stage in package name
Viresh Kumar [Sat, 16 Jul 2016 16:57:30 +0000 (09:57 -0700)]
greybus: bootrom: Use "s2l" instead of boot stage in package name

The S3 firmware and S3-BFU firmware images will be named like this going
forward:

S3: ara_00000126_00001001_fffe0001_ffe70018_s3f.tftf
S3-BFU: ara_00000126_00001001_fffe0001_ffe70018_s3_bfu.tftf

But the current naming for S2 loader image is:

ara_00000126_00001001_fffe0001_ffe70018_02.tftf

It makes sense to use similar encoding for all three packages and so it
should be named as:

ara_00000126_00001001_fffe0001_ffe70018_s2l.tftf

Because the boot stage is passed from ES3 bootrom, we can't change its
value now. But the string created to match the package name is created
in bootrom.c and that is the only string we create from bootrom.c.

Update bootrom.c to use "s2l" instead of "02" in the package name.

Compile Tested only.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Karthik Ravi Shankar <karthikrs@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: timesync: Bugfix ping should not result in -EAGAIN
Bryan O'Donoghue [Tue, 19 Jul 2016 00:56:49 +0000 (01:56 +0100)]
greybus: timesync: Bugfix ping should not result in -EAGAIN

gb_timesync_schedule_synchronous() is currently making a synchronous
FrameTime synchronization happen. It does a wait_event_interruptible() and
then goes to check the status of the state-machine. Occasionally the state
indicates PING - which is a completely valid state and should result in a
result code of 0 not -EAGAIN. This patch fixes by making
__gb_timesync_get_status() return 0 instead of -EAGAIN for the PING state.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: David Lin <dtwlin@google.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: greybus_protocols.h: convert __u32 to __le32
Bryan O'Donoghue [Mon, 18 Jul 2016 13:59:37 +0000 (14:59 +0100)]
greybus: greybus_protocols.h: convert __u32 to __le32

All 32 bit declarations associated with data interchange to the greybus
network need to be declared explicitly as little-endian since that is the
byte order we use on the greybus network. struct gb_audio_topology is
declaring its variables as u32. Fortunately this structure isn't currently
used so we can do a conversion from u32 to __le32 without any ancillary
code-churn.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: greybus_protocols.h/es2: Ensure __le32 is used not u32
Bryan O'Donoghue [Mon, 18 Jul 2016 13:59:36 +0000 (14:59 +0100)]
greybus: greybus_protocols.h/es2: Ensure __le32 is used not u32

There is a dangling u32 in es2/greybus_protocols.h that is only obvious
when you try to compile up gbsim. We need to do a cpu_to_le32 and declare
the 32-bit int in the header as __le32. This patch does that and splits out
the assignment of the req->flags parameter to a temporary variable to allow
for later printing.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Suggested-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: camera: Update CSI config parameters
Jacopo Mondi [Fri, 15 Jul 2016 09:03:46 +0000 (11:03 +0200)]
greybus: camera: Update CSI config parameters

Remove lines_per_second parameter from csi configuration
structure as VFE driver dropped dependency on it

Signed-off-by: Jacopo Mondi <jacopo.mondi@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: camera: Configure APB-A with new params
Jacopo Mondi [Fri, 15 Jul 2016 09:03:45 +0000 (11:03 +0200)]
greybus: camera: Configure APB-A with new params

Update the configuration supplied to APB-A to use new parameters, while
keeping compatibility with legacy camera modules.
Substitute hard-coded clock frequency with information provided by camera
module, and retrieve the maximum CSI Long Packet length from the
returned stream configuration.

This patch requires APB-A csi-tx driver to be updated to comply with
newly defined bandwidth requirements.

Testing Done: preview, capture and video recording with updated csi-tx
driver on APB-A side, and legacy white camera module firmware

Signed-off-by: Jacopo Mondi <jacopo.mondi@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: camera: Update Configure Streams Response
Jacopo Mondi [Fri, 15 Jul 2016 09:03:44 +0000 (11:03 +0200)]
greybus: camera: Update Configure Streams Response

As camera specification gets updated, and Configure Stream Response
payload modified, define here the new response structure.
In order to not break non up-to-date camera modules, keep the existing
structure and add the _deprecated suffix to it.

Add the size of both new and old structure in order to discriminate
dynamically which version of Camera Specification the camera module
implements and translate deprecated version of configure_streams response
in the new one.

In order not to break camera functionalities, for testing purposes,
hard-code values the APB-A CSI Tx driver still requires for proper
interface configuration (lines_per_second and num_lanes)

Testing Done: Preview, capture and video recording with white camera
module and APB-A with legacy firmware implementations

Signed-off-by: Jacopo Mondi <jacopo.mondi@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: camera: Hardcode the APB-A CSI-2 TX parameters
Laurent Pinchart [Fri, 15 Jul 2016 09:03:43 +0000 (11:03 +0200)]
greybus: camera: Hardcode the APB-A CSI-2 TX parameters

Camera modules will stop reporting the number of lines per second,
hardcode the parameter in the driver until the APB-A CSI-2 TX
configuration protocol gets updated as well to use a more appropriate
form of bandwidth information.

The number of data lanes is also hardcoded as it should not depend on
the module's CSI-2 bus configuration.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: camera: Add wrapper for sync operation with flags
Jacopo Mondi [Fri, 15 Jul 2016 09:03:42 +0000 (11:03 +0200)]
greybus: camera: Add wrapper for sync operation with flags

The greybus operation core synchronous operation call doesn't support
operation flags. Create a new synchronous operation wrapper with flags,
and modify the capabilities operation implementation to use it.

The code could be later moved to the greybus core if other drivers have
a similar need.

Signed-off-by: Jacopo Mondi <jacopo.mondi@linaro.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: camera: Add bpp to Greybus Format description
Jacopo Mondi [Fri, 15 Jul 2016 09:03:41 +0000 (11:03 +0200)]
greybus: camera: Add bpp to Greybus Format description

Add the bytes per pixel value to the structure describing a Greybus
Protocol Image Format.
The bpp information will be used to compute the length in bytes of a
line of pixel data

Signed-off-by: Jacopo Mondi <jacopo.mondi@linaro.org>
Reviewed-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: audio_topology: Fix compile warning
Viresh Kumar [Sat, 16 Jul 2016 16:44:28 +0000 (09:44 -0700)]
greybus: audio_topology: Fix compile warning

Fix following compile warning by staticizing gb_generate_enum_strings().

greybus/audio_topology.c:134:12: warning: symbol 'gb_generate_enum_strings' was not declared. Should it be static?

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: power_supply: add missing defines present in the specification
Rui Miguel Silva [Fri, 15 Jul 2016 11:16:55 +0000 (12:16 +0100)]
greybus: power_supply: add missing defines present in the specification

Some of the Greybus properties values (capacity level and scope) even
though they are defined in the specification were missing from the
protocol header.

They still match the kernel ones, but they should be present in there
for protocol sake.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: power_supply: remove references to kernel header
Rui Miguel Silva [Fri, 15 Jul 2016 11:16:54 +0000 (12:16 +0100)]
greybus: power_supply: remove references to kernel header

In Greybus power supply macro definitions we have a comment that point
to a kernel header, remove it since we have a specification for that.

As at it, align the status values to the upper values.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: timesync/pm: Make synchronous call to restore FrameTime
Bryan O'Donoghue [Fri, 15 Jul 2016 17:01:49 +0000 (18:01 +0100)]
greybus: timesync/pm: Make synchronous call to restore FrameTime

When we discussed and agreed a serialized way to-do PM runtime
suspend/resume we omitted the necessity to restore the FrameTime on resume.
This patch restores the FrameTime synchronously such that when an Interface
PM resume callback completes we have either successfully restored the
FrameTime including the new Interface or we've produced a result code to
indicate what went wrong when trying.

Suggested-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Tested-by: David Lin <dtwlin@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: hd: arche-platform: implement greybus shutdown
David Lin [Wed, 13 Jul 2016 00:41:21 +0000 (17:41 -0700)]
greybus: hd: arche-platform: implement greybus shutdown

Implement platform driver shutdown callback to perform proper greybus
shutdown so that the userspace unipro_shutdown service that shuts down
the APB/SVC abruptly can be removed. The shutdown callback in
arche-platform will first remove SVC so that all the Interface can be
Deactivated in a sequence according to the spec before powering off the
APB:

Before:
 -> Arche/APB power off
 -> SoC power off

After this patch:
 -> HD shutdown
     -> SVC shutdown
         -> Module shutdown
             -> Interface shutdown
                 -> Bundle shutdown
 -> Arche/APB power off
 -> SoC power off

Testing Done:
 - Observe all Interfaces are deactivated in the log during shutdown
 - Measure power off current and make sure no regression

Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: power_supply: convert greybus properties to power supply properties
Rui Miguel Silva [Wed, 13 Jul 2016 13:11:20 +0000 (14:11 +0100)]
greybus: power_supply: convert greybus properties to power supply properties

We need to translate greybus properties to power supply core properties,
for that when parsing the properties that were fetch during
configuration we check if there is a match to the running kernel version
and store it in a new field (gb_prop) in the gb_power_supply_prop
struct.

If the corresponding property does not exist in the running
kernel (because of version or vendor specific property) we drop that
property.

A collection of properties that, at this time, may diverge are defined
in the kernel_ver.h to avoid breakage at build time and run time if this
properties are not supported by the kernel.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: power_supply: change property values to integer
Rui Miguel Silva [Wed, 13 Jul 2016 13:11:19 +0000 (14:11 +0100)]
greybus: power_supply: change property values to integer

To align with power supply core values type (integer) move the val and
previous_val to integer also.

Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Reviewed-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: use memdup_user()
Alex Elder [Thu, 14 Jul 2016 19:24:19 +0000 (14:24 -0500)]
greybus: use memdup_user()

Coccinelle reports that there are two opportunities to use memdup_user()
in "authentication.c".  This patch simplifies the code in cap_ioctl() by
taking advantage of that.  Make use of a local variable "size" to improve
readability.

Signed-off-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: get rid of a compile warning
Alex Elder [Thu, 14 Jul 2016 19:24:18 +0000 (14:24 -0500)]
greybus: get rid of a compile warning

The compiler has no way of knowing whether a called function will
actually assign something to the object whose address is passed as
an argument.  So it must assume it won't happen, and this leads to a
compile warning.  Fix this.

Signed-off-by: Alex Elder <elder@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
8 years agogreybus: loopback: add runtime pm support
Axel Haslam [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: spi: Add runtime_pm support
Axel Haslam [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: pwm: Add runtime_pm support
Axel Haslam [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: gpio: Add runtime_pm suppourt
Axel Haslam [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: uart: Add runtime pm support
Axel Haslam [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: i2c: add runtime pm support
David Lin [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: gbphy: add gbphy runtime pm support
David Lin [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: camera: add runtime pm support
David Lin [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: audio: add runtime pm support
David Lin [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: bundle: add runtime pm support
David Lin [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: interface: add runtime pm support
David Lin [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: bundle: add activate and deactivate
David Lin [Thu, 14 Jul 2016 20:13:00 +0000 (15:13 -0500)]
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>
8 years agogreybus: es2: fix arpc response lookups
Johan Hovold [Thu, 14 Jul 2016 17:55:00 +0000 (12:55 -0500)]
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>
8 years agogreybus: es2: Fix 'make check' warnings with arpc
Viresh Kumar [Thu, 14 Jul 2016 17:18:00 +0000 (12:18 -0500)]
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>
8 years agogreybus: audio: Maintain proper codec state during shutdown sequence.
Vaibhav Agarwal [Tue, 12 Jul 2016 09:56:00 +0000 (04:56 -0500)]
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>
8 years agogreybus: audio: Fix incorrect codec state modification
Vaibhav Agarwal [Tue, 12 Jul 2016 09:56:00 +0000 (04:56 -0500)]
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>
8 years agogreybus: es2: fix arpc return value
Johan Hovold [Wed, 13 Jul 2016 14:34:00 +0000 (09:34 -0500)]
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>
8 years agogreybus: es2: Implement APBridgeA RPC (ARPC)
Alexandre Bailon [Thu, 7 Jul 2016 12:41:00 +0000 (07:41 -0500)]
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>
8 years agogreybus: es2: Add a new bulk in endpoint for APBridgeA RPC
Alexandre Bailon [Thu, 7 Jul 2016 12:41:00 +0000 (07:41 -0500)]
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>
8 years agogreybus: interface: send deactivate prepare when interface is disabled
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: control: add connection suspend and resume calls
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: interface: implement unipro link hibernate call
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: svc: add power mode call for link hibernation
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: svc: add interface resume operation
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: control: add interface hibernate abort operation
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: control: add interface deactivate prepare operation
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: control: add interface suspend prepare operation
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: control: add bundle deactivate and activate operation
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: control: add bundle suspend and resume preparations
David Lin [Fri, 8 Jul 2016 03:07:00 +0000 (22:07 -0500)]
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>
8 years agogreybus: connection: remove CDSI1 hack
Fabien Parent [Wed, 6 Jul 2016 15:51:00 +0000 (10:51 -0500)]
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>
8 years agogreybus: Documentation: Document Authentication interfaces
Viresh Kumar [Thu, 30 Jun 2016 15:54:00 +0000 (10:54 -0500)]
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>
8 years agogreybus: Add Component Authentication Protocol support
Viresh Kumar [Thu, 30 Jun 2016 15:54:00 +0000 (10:54 -0500)]
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>
8 years agogreybus: camera: Fix size of configure_streams(0)
Jacopo Mondi [Thu, 30 Jun 2016 14:18:00 +0000 (09:18 -0500)]
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>
8 years agogreybus: camera: Fix number of configured streams
Jacopo Mondi [Thu, 30 Jun 2016 14:18:00 +0000 (09:18 -0500)]
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>
8 years agogreybus: camera: Early update num_streams and flags
Jacopo Mondi [Thu, 30 Jun 2016 14:18:00 +0000 (09:18 -0500)]
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>
8 years agogreybus: audio: topology: Enable enumerated control support
Vaibhav Agarwal [Thu, 30 Jun 2016 13:15:37 +0000 (18:45 +0530)]
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>
8 years agogreybus: audio: topology: Use csize while computing next_ptr in parser
Vaibhav Agarwal [Tue, 5 Jul 2016 22:09:20 +0000 (17:09 -0500)]
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>
8 years agogreybus: added warning message in case of missing widget
Vaibhav Agarwal [Thu, 30 Jun 2016 13:15:35 +0000 (18:45 +0530)]
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>
8 years agogreybus: audio: topology: Add helper API to map controlid with widget name
Vaibhav Agarwal [Tue, 5 Jul 2016 22:09:20 +0000 (17:09 -0500)]
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>
8 years agogreybus: light: Initialize mutex before using it
Viresh Kumar [Wed, 29 Jun 2016 20:42:26 +0000 (13:42 -0700)]
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>
8 years agogreybus: Revert "greybus: uart: don't use spin_lock_irq()"
Johan Hovold [Mon, 27 Jun 2016 18:07:12 +0000 (20:07 +0200)]
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>
8 years agogreybus: Revert "greybus: es2.c: don't use spin_lock_irq()"
Johan Hovold [Mon, 27 Jun 2016 18:07:11 +0000 (20:07 +0200)]
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>
8 years agogreybus: Revert "greybus: gb_connections_lock: don't use spin_lock_irq()"
Johan Hovold [Mon, 27 Jun 2016 18:07:10 +0000 (20:07 +0200)]
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>
8 years agogreybus: Revert "connection: switch to using spin_lock_irqsave/spin_lock_irqrestore...
Johan Hovold [Mon, 27 Jun 2016 18:07:09 +0000 (20:07 +0200)]
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>
8 years agogreybus: svc: remove input device handling in SVC protocol
Sandeep Patil [Tue, 28 Jun 2016 19:10:14 +0000 (12:10 -0700)]
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>
8 years agogreybus: kernel_ver: Add kstrtobool()
Viresh Kumar [Mon, 27 Jun 2016 05:49:23 +0000 (11:19 +0530)]
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>
8 years agogreybus: es2: add support for greybus cport flags
Johan Hovold [Wed, 22 Jun 2016 09:42:05 +0000 (11:42 +0200)]
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>
8 years agogreybus: connection: add support for high-priority connections
Johan Hovold [Wed, 22 Jun 2016 09:42:04 +0000 (11:42 +0200)]
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>
8 years agogreybus: connection: prevent drivers from specifying core flags
Johan Hovold [Wed, 22 Jun 2016 09:42:03 +0000 (11:42 +0200)]
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>
8 years agogreybus: hd: add flag argument to cport_enable callback
Johan Hovold [Wed, 22 Jun 2016 09:42:02 +0000 (11:42 +0200)]
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>
8 years agogreybus: camera: Add RAW data format
Evgeniy Borisov [Thu, 23 Jun 2016 09:39:18 +0000 (12:39 +0300)]
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>
8 years agogreybus: audio: remove the unnecessary return statement
David Lin [Fri, 24 Jun 2016 20:52:43 +0000 (13:52 -0700)]
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>
8 years agogreybus: connection: switch to using spin_lock_irqsave/spin_lock_irqrestore excluisvely
Jeffrey Carlyle [Fri, 24 Jun 2016 03:28:56 +0000 (08:58 +0530)]
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>
8 years agogreybus: bootrom: Wait for 10 seconds for mode-switch
Viresh Kumar [Wed, 22 Jun 2016 09:16:41 +0000 (14:46 +0530)]
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>
8 years agogreybus: bootrom: send timeout in milliseconds to gb_bootrom_set_timeout()
Viresh Kumar [Wed, 22 Jun 2016 09:16:40 +0000 (14:46 +0530)]
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>
8 years agogreybus: bootrom: Enhance timeout error message
Viresh Kumar [Wed, 22 Jun 2016 09:16:39 +0000 (14:46 +0530)]
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>
8 years agogreybus: timesync: Make printout consitent with other greybus messages
Bryan O'Donoghue [Wed, 22 Jun 2016 13:58:44 +0000 (14:58 +0100)]
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>
8 years agogreybus: timesync: Initialize the timesync ping fields to zero
Bryan O'Donoghue [Wed, 22 Jun 2016 13:58:43 +0000 (14:58 +0100)]
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>
8 years agogreybus: add support for the log protocol
Joel Porquet [Fri, 24 Jun 2016 21:41:36 +0000 (14:41 -0700)]
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>
8 years agogreybus: gb_connections_lock: don't use spin_lock_irq()
Viresh Kumar [Thu, 23 Jun 2016 17:53:06 +0000 (23:23 +0530)]
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>
8 years agogreybus: es2.c: don't use spin_lock_irq()
Viresh Kumar [Thu, 23 Jun 2016 17:53:06 +0000 (23:23 +0530)]
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>
8 years agogreybus: uart: don't use spin_lock_irq()
Viresh Kumar [Thu, 23 Jun 2016 17:53:06 +0000 (23:23 +0530)]
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>