Rename host-driver structure to gb_hd_driver to more clearly separate it
from the host-device structure.
Also remove an outdated description of the struct.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Previously we had only one AP bridge connected to the AP. We will
now have two. Now that the have moved the logging related symbols
into the AP device, we can stop assuming there's only on of them.
Specifically, rename symbols like "apb1_*" to be just "apb_*",
because the "1" is no longer meaningful.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Finish moving the logging data structures into the es2 AP data
structure rather than having it be a single global. This patch
moves the two dentries related to logging.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Continue moving the logging data structures into the es2 AP data
structure rather than having it be a single global. This patch
moves the fifo.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
If an APB has a logging task it is associated with that APB. Move
the task pointer into the es2_ap_dev structure rather than having it
be a single global.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
I tried this once before and Greg NAK'd it because at that point the
es2 code was nearly identical to the es1 code. This is no longer
the case, and we need to diverge further, so I think it's time to go
down that path.
The ap_dev structure changed significantly for ES2 versus ES1 as of
this commit:
667f8d3 es2.c: create dedicated struct for cport_in and cport_out
Since the structures are no longer the same, they should not have
the same name.
This patch renames three data structures so the "1" is replaced with
a "2", to reflect the Toshiba AP bridge chip revision we are working
with. The structures are:
es1_ap_dev -> es2_ap_dev
es1_cport_in -> es2_cport_in
es1_cport_out -> es2_cport_out
It changes names of symbols having this type as well. To finish the
job, all references "ES1" (in comments and in symbol names) have
been switched to use "ES2" instead.
The result is a lot of changes, but they amount to a global search
and replace of "es1" with "es2" (and "ES1" with "ES2"), and the
result has been compile tested.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
We now have an officially assigned Google USB device id for the
APBridge, so add in support for it in the es2 driver. The old entry can
be removed once the firmware has caught up and uses the new number.
We should use the version field to determine ES1/ES2/ES3, but that will
come later, for now, grab anything with this device id.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
As part of an effort to get deep inspection of latencies throughout the
greybus network including HSIC, UniPro and firmware incurred latencies a
new command to the APBridge to tag a known offset with timestamping data
has been introduced. This patch adds that code to the es1 and es2 drivers.
- latency_tag_enable
- latency_tag_disable
Respectively send the enable/disable command to APBridge on a per-CPort
basis. This allows only specified cports to have timestamping data added by
APBridge, leaving any CPort not specifically enabled untouched.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Replace the remaining pr_err with dev_err, and drop redundant function
prefixes.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Toshiba UniPro IP requires to reset the CPort that has been used in a previous
connection. This commit implement a new control request in order to
reset CPorts on an APBridgeA.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reset the hcpriv field before returning the message to greybus core in
the OUT-URB completion callback.
This fixes a use-after-free bug when sending responses to incoming
requests as the final reference is then dropped when the message is
returned.
Reported-by: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This patch hooks tracepoints for the handoff point to/from hardware. With
these tracepoints in place we can view the time between gb_message_send and
usb_submit_urb and similarly we can view the time between cport_in_callback
and gb_message_recv_response/gb_message_recv_request
- trace_gb_host_device_send
- trace_gb_host_device_recv
It provides standard tracepoints at
/sys/kernel/debug/tracing/events/greybus/gb_host_device_send
/sys/kernel/debug/tracing/events/greybus/gb_host_device_recv
Giving outputs like
gb_host_device_recv: greybus:2-1 if_id=0000 l=10
gb_host_device_send: greybus:2-1 if_id=0000 l=10
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This patch drops tracking of internal latencies, it's possible to derive
these times via kernel tracepoints and some user-space scripting. Since
there's no other use of the internal timestamp than the loopback driver we
remove the connection.c, connection.h, es1.c, es2.c and loopback.c
inter-dependency in one go.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The Qualcomm kernel builds with -Werror so the existing es2.c driver
breaks the build due to unused static functions. As we are still
hashing out exactly how to implement this logic at the moment, just
comment out the functions to make the build be clean, no logic changes
happen here at all.
Reported-by: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The SVC Control request is obsolete and not used anymore. Remove the related
define.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Endpoints pair will only be managed by es2 driver.
map_cport_to_ep() and unmap_cport() should be static.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Some methods and variables name were a lot confusing.
Replace it or add ep_pair in methods or varaibles name
to make sources less confusing.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The endpoint set 0 is currently considered as invalid.
But 0 mean muxed cports on ep1 and ep2,
then it must not return -EINVAL.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
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>
Use the control request REQUEST_CPORT_COUNT in order to get the number of
CPorts supported by the UniPro IP.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
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>
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>
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>
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.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Its really part of initializing the host device and is required for
every 'hd' that is created. Lets move the call to do basic
initialization of svc connection to greybus_create_hd().
Also add a comment to specify why we need to do it that early.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The svc connection needs to be ready before creating the URBs, otherwise
the svc version request might come in before the AP was ready to parse
them.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The callback is never used anymore, so remove it from struct
greybus_host_driver as well as from the es1 and es2 drivers.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
We have switched over to use the "new" svc messages, no more need to
have a special USB endpoint to handle them, they come through the normal
CPort messages.
Based on a patch from Viresh.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
All bits and pieces are in place now. Lets start using svc protocol
instead of stuff present in ap.c.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Perry Hung <perry@leaflabs.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The firmware for the svc changes isn't quite ready, so revert the whole
set of patches in one hunk to get things back to a working state for the
other firmware developers. The svc patches will be added back in a
separate branch.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Its really part of initializing the host device and is required for
every 'hd' that is created. Lets move the call to do basic
initialization of svc connection to greybus_create_hd().
Also add a comment to specify why we need to do it that early.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The svc connection needs to be ready before creating the URBs, otherwise
the svc version request might come in before the AP was ready to parse
them.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The callback is never used anymore, so remove it from struct
greybus_host_driver as well as from the es1 and es2 drivers.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
We have switched over to use the "new" svc messages, no more need to
have a special USB endpoint to handle them, they come through the normal
CPort messages.
Based on a patch from Viresh.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
All bits and pieces are in place now. Lets start using svc protocol
instead of stuff present in ap.c.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Perry Hung <perry@leaflabs.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The current host-controller message-cancellation implementation suffer
from a lifetime bug as dynamically allocated URBs would complete and be
deallocated while being unlinked as part of cancellation.
The current locking is also insufficient to prevent the related race
where the URB is deallocated before being unlinked.
Fix this by pushing the cancellation implementation from greybus core
down to the host-controller drivers, and replace the "cookie" pointer
with a hcpriv field that those drivers can use to maintain their state
with the required locking and reference counting in place.
Specifically the drivers need to acquire a reference to the URB under a
lock before calling usb_kill_urb as part of cancellation.
Note that this also removes the insufficient gb_message_mutex, which
also effectively prevented us from implementing support for submissions
from atomic context.
Instead the host-controller drivers must now explicitly make sure that
the pre-allocated URBs are not reused while cancellation is in progress.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
ES2 give us more endpoints. Use them to map one cport to two endpoints
(in and out). Because there is more cports than endpoints, we still
need to mux other cports traffic on 2 endpoints.
Firmware currently assumes these endpoints are 2 and 3.
By default, all cports are muxed.
To map one cport to 2 endpoints, use map_cport_to_ep().
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
ES2 support 16 endpoints. Update es2.c to allocate endpoints, urbs
and buffers for these new endpoints.
Currently, they are not yet used and es2.c is working in legacy mode
(only original endpoints are used).
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Instead of keep cport buffers, urbs and endpoints in es1_ap_dev,
move them in two dedicated struct (es1_cport_in and es1_cport_out),
in order to ease the migration to es2 (increase the number of endpoint).
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
We now limit the maximum value for both host and module CPort ids,
and we know they can always be represented in a single byte.
Make use of this by using only one of the two pad bytes for encoding
the CPort id in a message header.
(Note that we have never used a CPort higher than 255. Encoding
such a small CPort id in little endian 2-byte format has the same
result as what is done here.)
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
For the ES1 and ES2 host interfaces we encode the CPort ID over
which the message should be sent within the message itself. The
CPort ID is recorded in unused pad bytes found in the operation
message header in order to avoid introducing misaligned messages.
This patch defines some helper routines to abstract this activity.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Define a public predicate that defines whether a CPort ID is valid.
Use it in the message_send() routine, and make the message reported
more accurately reflect the error. Also use it to check whether the
CPort ID in a received message is valid; if it is not, just drop the
message.
Get rid of local variable "buffer" in message_send(); it adds no
value.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Johan Hovold