The request sequence for SVC protocol is fixed at least upto SVC_HELLO
request. The first request has to be Protocol Version, followed by
SVC_HELLO. Any other request can follow them, but these two.
Add another field in 'struct gb_svc' that keeps track of current state
of the protocol driver. It tracks only upto SVC_HELLO, as we don't need
to track later ones.
Also add a comment, about the order in which the requests are allowed
and why a race can't happen while accessing 'state'.
This removes the WARN_ON() in gb_svc_hello() as we track state
transition with 'state' field.
This also fixes a crash, when the hotplug request is received before
fully initializing the svc connection. The crash mostly happens while
accessing svc->connection->bundle, which is NULL, but can happen at
other places too, as svc connection isn't fully initialized.
Reported-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[johan: add 0x-prefix to warning message ] Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
greybus: build: android: avoid building for targets that don't have kernel binary
For sdk related targets, the greybus build will error out due to missing
kernel dependency. Let's avoid those targets by checking TARGET_NO_KERNEL.
Signed-off-by: Vishal Bhoj <vishal.bhoj@linaro.org> Signed-off-by: Michael Scott <michael.scott@linaro.org> Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Johan Hovold [Wed, 2 Sep 2015 16:03:21 +0000 (18:03 +0200)]
greybus: fix cport-id defines
The CPORT_ID_MAX define has been used by host drivers as a device limit,
but also for sanity checks when parsing manifests.
Now that it's only used for sanity checks we can increase it to the
specification maximum (4095) and get rid of the config-option that could
be used to override the previous limit (128).
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
There is no need to store the endpoint number of the control requests since
the default control endpoint is used and the USB standard defines for it a fixed
endpoint number of 0.
Remove every instance of the field control_endpoint and replace it with a
hardcoded 0 value.
Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
greybus: es2: dynamically allocate array for cport <-> ep mapping
In order to be able to dynamically determine the number of CPorts supported
by the UniPro IP instead of hardcoding the value we need to dynamically
allocate the array that is doing the cport-ep mapping.
Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
This commit is doing the preparation work in order to get the number of cports
supported from the UniPro IP instead of using a constant defined in a Kconfig
file.
Greybus host device is now holding the cport count, and all the code will now
use this value instead of the constant CPORT_ID_MAX when referring to an AP's
CPort ID.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
[johan: es1 supports 256 cports, minor style changes ] Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
greybus: es2: rename misnamed CPORT_MAX into CPORT_COUNT
Rename the misnamed macro CPORT_MAX into CPORT_COUNT. CPORT_MAX could let
people think that the macro is holding the value of the last CPort ID
usable.
Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Use scnprintf in the generic attribute helper, which does not currently
check for buffer overflow.
The attribute helper is used to print generic strings, which could
potentially overflow the buffer. Note that the only strings currently
exported are taken from greybus string descriptors and should therefore
be limited to 255 chars.
Alexandre Bailon [Mon, 31 Aug 2015 07:00:16 +0000 (09:00 +0200)]
greybus: es1/es2: set transfer flag to send a zero-length packet
Greybus messages with a multiple size of 512B generate timeouts
(any other message size doesn't).
512B is exactly the packet size of a bulk out endpoint.
Hence USB device is expecting a short (< 512B)
or zero-length packet to finish the transfer,
which is never generated and causes the timeout.
Set the transfer flag to send a zero-length packet in this situation.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com> Reviewed-by: Patrick Titiano <ptitiano@baylibre.com> Reviewed-by: Johan Hovold <johan@hovoldconsulting.com> Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Bryan O'Donoghue [Sun, 16 Aug 2015 23:55:11 +0000 (00:55 +0100)]
greybus: loopback: add module level sys/debug fs data points
Code this far has used the first connection's sysfs entry to present
variables intended to control the entire test - across multiple
connections. This patch changes that so that the module level variables
only appear at the end0:x level in sysfs.
Example:
Total counts for errors over the entire set of connections will be here
/sys/bus/greybus/devices/endo0:x/error_dev
In contrast an error for each connection will be presented like this
/sys/bus/greybus/devices/endo0:x:y:z:w/error_con
x = <module-id>
y = <interface-id>
z = <bundle-id>
w = <cport-id>
checkpatch.pl is choking on a later change to dev_stats_attrs, where
checkpatch expects to see the values encapsulated in curly brackets.
Encapsulating in curly brackets will cause a compiler error. To resolve the
dichotomy this patch drops the macros and adds the arrary declarations
directly.
Bryan O'Donoghue [Sun, 16 Aug 2015 23:55:08 +0000 (00:55 +0100)]
greybus: loopback: add bitmask of connections to include in test
Feature add which enables the ability to select a bit-mask of connections
to run when executing a loopback test set. This is a feature add to
facilitate testing on the firmware side minus the necessity to recompile
firmware to support unicast (v) multicast (v) bitmask.
In order to enable that behaviour without forcing an undesirable
checkpointing scheme this patch introduces a kfifo for each thread to store
the raw timestamps and calculate a time difference.
The __gb_loopback_calc_latency will be useful in later patches. Provide it
here and use as intended. Later on we just want to use the timestamp
rollover detection, so split it out now.
Bryan O'Donoghue [Sun, 16 Aug 2015 23:55:04 +0000 (00:55 +0100)]
greybus: loopback: support synchronized tests over multiple cports
The loopback code as currently implemented allows free running threads to
blast data to cports in isolation, however no overall stastics are gathered
for the aggregate throughput to a given module.
This patch moves derivation of stastics for all cports to one structure
so that 1 to n cports will report their overall stastics in one place.
Later patches update the sysfs/debugfs accessor functions to provide the
per-module and per-connection data separately.
Bryan O'Donoghue [Sun, 16 Aug 2015 23:55:03 +0000 (00:55 +0100)]
greybus: loopback: convert sample report interface to debugfs
Greg previously suggested switching over to debugfs instead of a char
interface to report raw samples to user-space. At the time we agreed not
to go for that change. However later patches in this series are made
simpler if debugfs is used instead of /dev, so it makes sense to make the
conversion now for that reason. This patch removes the char interface and
replaces it with a debugfs interface. Raw samples will be acquired from
/sys/kernel/debug/gb_loopback/raw_latency_endo0:x:y:z:w where
x = <module-id>
y = <interface-id>
z = <bundle-id>
w = <cport-number>
Bryan O'Donoghue [Sun, 16 Aug 2015 23:55:02 +0000 (00:55 +0100)]
greybus: loopback: add ability to graph greybus latency
This patch adds the ability to graph the latency of the overhead introduced
by the greybus stack in the roundtrip time AP->Module->AP.
Since this is a small number it is reported in nanoseconds, not
mircoseconds. This data can also be derived with tracepoints but it's being
provided in this format to export to CSV file more easily than with
tracepoints.
'user-replicable' means something that a user can replicate.
'user-replaceable' means something that a user can replace. We defintely
mean to say replaceable not replicable here.
Rui Miguel Silva [Fri, 14 Aug 2015 12:58:19 +0000 (13:58 +0100)]
greybus: lights: add lights implementation
This patch adds lights implementation for Greybus Lights class, it
allows multiplexing of lights devices using the same connection. Also
adds two sysfs entries to led class (color, fade) which are commonly
used in several existing LED devices.
It support 2 major class of devices (normal LED and flash type), for
the first it registers to led_classdev, for the latest it registers in
the led_classdev_flash and v4l2_flash, depending on the support of the
kernel version.
Each Module can have N light devices attach and each light can have
multiple channel associated:
glights
|->light0
| |->channel0
| |->channel1
| | ....
| |->channeln
|->...
|->lightn
|->channel0
|->channel1
| ....
|->channeln
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Rui Miguel Silva [Fri, 14 Aug 2015 12:58:18 +0000 (13:58 +0100)]
greybus: makefile: add needed config options for lights
Add a function to check kernel versions and append the necessary
options to support LEDS_CLASS, LEDS_CLASS_FLASH and V4L2_FLASH_LED_CLASS
depending of the kernel version.
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Viresh Kumar [Wed, 12 Aug 2015 05:34:06 +0000 (11:04 +0530)]
greybus: protocol: send own protocol version while requesting it
The greybus specifications clearly say (for all protocols) that the
sender is responsible for sending the highest version of protocol it
supports, while it requests the same from the receiver.
But the greybus code never followed that.
Fix, this by always sending AP's version of the protocol, while
requesting the same from svc/module.
This also renames 'response' to 'version' in gb_protocol_get_version()
as it is used for both request/response.
Viresh Kumar [Wed, 12 Aug 2015 03:49:34 +0000 (09:19 +0530)]
greybus: connection: Send protocol version for firmware protocol
As per greybus specs, we need to send the protocol version for firmware
protocol and so this special case Hack.
Probably we should always send the protocol version AP supports and kill
this hack completely. But then it requires updates to specs as well, and
that should be done after some discussion.
For now, add a FIXME for that and a special case for firmware protocol.
Viresh Kumar [Wed, 12 Aug 2015 03:49:32 +0000 (09:19 +0530)]
greybus: protocol: Create request structure from within gb_protocol_get_version()
The version request can only send the version of protocol for which it
is initiated and gb_protocol_get_version() has all the information to
create the request structure.
Replace the 'request' and 'request_size' arguments to
gb_protocol_get_version() with a bool to know if the version information
of the protocol should be sent or not.
Bryan O'Donoghue [Tue, 11 Aug 2015 12:50:54 +0000 (13:50 +0100)]
greybus: loopback: handle timestamp roll-over
This patch ensures we account for roll-over in the loopback driver.
do_gettimeofday() is used to grab a timestamp. Two timestamps are derived
one before and one after a gb_operation_sync(), however since
do_gettimeofday() returns the number of seconds and mircoseconds that have
elapsed today - we need to account for a situation where the timestamp
starts at say 23:59:999us rolls over and the end time is now earlier than
the start time.
Bryan O'Donoghue [Tue, 11 Aug 2015 12:50:53 +0000 (13:50 +0100)]
greybus: loopback: functionally decompose calculation of turn-around times
We have a pattern similar to this over and over again gb->elapsed_nsecs =
timeval_to_ns(&te) - timeval_to_ns(&ts); good software practice dictates we
functionally decompose this. This patch decomposes into
gb_loopback_calc_latency().
Bryan O'Donoghue [Tue, 11 Aug 2015 12:50:52 +0000 (13:50 +0100)]
greybus: es-drivers: add outbound timestamp to connection
In order to facilitate grabbing a timestamp that doesn't include greybus
overhead, this patch adds a timestamp right before usb_submit_urb() for
both es1.c and es2.c. Long term the timestmaping of messages like this
probably wants to go away but, for the moment it may have some use to the
firmware people instrumenting the performance of the system.
Bryan O'Donoghue [Tue, 11 Aug 2015 12:50:51 +0000 (13:50 +0100)]
greybus: connection: add a timestamp kfifo to track connection handoff
For the ES2 test activity it may be beneficial to have a performance
metric that doesn't include any of the greybus stack malloc, workqueues
etc. In order to faciltate, this patch adds a simple kfifo structure to
hold two timestamp values. One timestamp will represent the last reasonable
point a greybus outbound timestamp can be taken, the other timestamp will
represent the first reasonable point an inbound timestamp can be taken. In
order to facilitate this model, tracking the timestamps in the connection
structure appears to be the best place to keep store of this data.
Bryan O'Donoghue [Tue, 11 Aug 2015 12:50:50 +0000 (13:50 +0100)]
greybus: connection: fix jump label on device_add failure
On device_add() failure in gb_connection_create_range() we jump to
err_remove_ida. Instead we should be jumping to err_free_connection, so
change the flow to accomodate.
Viresh Kumar [Tue, 11 Aug 2015 01:59:19 +0000 (07:29 +0530)]
greybus: svc: error out only for smaller payloads received
!= was used in place of <, while comparing expected and actual payload
size. The module may be running a higher version of the protocol and
might have some extra fields (towards the end) in the structure, and the
AP needs to ignore them.
This also updates the print (expected-payload-size <
actual-payload-size), when the size doesn't match for requests received
by the module. This gives more details required for debugging.
Viresh Kumar [Sat, 8 Aug 2015 02:39:32 +0000 (08:09 +0530)]
greybus: sdio: error out only for smaller payloads received
!= was used in place of <, while comparing expected and actual payload
size. The module may be running a higher version of the protocol and
might have some extra fields (towards the end) in the structure, and the
AP needs to ignore them.
This also updates the print (expected-payload-size <
actual-payload-size), when the size doesn't match for requests received
by the module. This gives more details required for debugging.
Viresh Kumar [Thu, 6 Aug 2015 07:14:55 +0000 (12:44 +0530)]
greybus: svc: Handle hotplug request from a workqueue
Bringing up a module can be time consuming, as that may require lots of
initialization on the module side. Over that, we may also need to
download the firmware first and flash that on the module.
In order to make other hotplug events to not wait for all this to
finish, handle most of module hotplug stuff outside of the hotplug
callback, with help of a workqueue.
Viresh Kumar [Thu, 6 Aug 2015 07:14:54 +0000 (12:44 +0530)]
greybus: svc: Print expected/actual payload size on mismatch
Print (expected-payload-size actual-payload-size), when the size doesn't
match for requests received by the module. This gives more details
required for debugging the issue.
Viresh Kumar [Thu, 6 Aug 2015 07:14:51 +0000 (12:44 +0530)]
greybus: gpio: Print expected/actual payload size on mismatch
Print (expected-payload-size actual-payload-size), when the size doesn't
match for requests received by the module. This gives more details
required for debugging the issue.
Viresh Kumar [Thu, 6 Aug 2015 07:14:52 +0000 (12:44 +0530)]
greybus: raw: Print expected/actual payload size on mismatch
Print (expected-payload-size actual-payload-size), when the size doesn't
match for requests received by the module. This gives more details
required for debugging the issue.