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>
There's no need to include anything other than "greybus.h" in
"connection.c". Same thing in "core.c" and "manifest.c" and
"svc.c". Some files need headers included, but most come along
with "greybus.h".
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The firmware is having a hard time with 4k buffers and memory
allocation, so decrease the size on the host side to 2k. Also move away
from using PAGE_SIZE to denote 4k as that's not the case on all
architectures, and someone, someday, might get a rude surprise.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Currently, the data structure representing an Endo is set up at the
time a host device gets created. This is too early.
Once the control infrastructure is in place, there's no sense in
setting up the Endo utnil after we have heard from the SVC via a
probe operation on our control CPort. And even then, there's
no real point until we've successfully authenticated with the SVC,
which will be indicated by the arrival of the Control protocol
"connected" operation request notifying us that our SVC CPort
is operational.
In addition to this logical argument, we also can't actually
receive any messages on the Control CPort until the host device
is set up and ready to receive messages. At the point we're
currently setting up the Endo data structure, that has not yet
been done.
Define a new exported function greybus_endo_setup(), which will
be used (for now) as the entry point for setting up the Endo
data structure. Arrange to call it in the host USB driver
probe method, *after* we are set up for handling messages.
Note: Once the control protocol has been implemented, this function
may no longer need to be exported.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Return a pointer-coded error from greybus_create_hd() rather
than NULL in the event an error occurs.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Host devices impose buffer-size constraints on Greybus core which are
taken into account when allocating messages.
Make sure to verify these constraints when the host device is allocated,
rather than when the first message is allocated.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
These are all GPLv2-only kernel modules, so properly set the correct
MODULE_LICENSE string to make static checkers happy.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Drop the host-driver buffer headroom that was used to transfer the cport
id on ES1 and ES2.
Rather than transferring additional bytes on the wire and having to deal
with buffer-alignment issues (e.g. requiring the headroom to be a
multiple of 8 bytes) simply drop the headroom functionality.
Host drivers are expected set up their transfer descriptors separately
from the data buffers and any intermediate drivers (e.g. for Greybus
over USB) can (ab)use the operation message pad bytes for now.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Fix transfer-buffer alignment of outgoing transfers which are currently
byte aligned.
Some USB host drivers cannot handle byte-aligned buffers and will
allocate temporary buffers, which the data is copied to or from on every
transfer. This affects for example musb (e.g. Beaglebone Black) and
ehci-tegra (e.g. Jetson).
Instead of transferring pad bytes on the wire, let's (ab)use the pad
bytes of the operation message header to transfer the cport id. This
gives us properly aligned buffers and more efficient transfers in both
directions.
By using both pad bytes, we can also remove the arbitrary limitation of
256 cports.
Note that the protocol between the host driver and the UniPro bridge is
not necessarily Greybus. As long as the firmware clears the pad bytes
before forwarding the data, and the host driver does the same before
passing received data up the stack, this should be considered "legal"
use.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Pass structured greybus messages rather than buffers to the host
drivers.
This will allow us to separate the transfer buffers from the message
structures.
Rename the related functions to reflect the new interface.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The maximum buffer size does not include the headroom, so subtract the
headroom size from the actual buffer size.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
A stack-allocated buffer is not generally DMA-able and must not be used
for USB control transfers.
Note that the memset and extra buffer byte were redundant as no more
than the bytes actually transferred was ever added to the fifo.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
When usb_log_enable() is called, the global apb1_log_task is used to
hold the result of kthread_run(). It is possible for kthread_run()
to return an error pointer, so tests of apb_log_task against NULL
are insufficient to determine its validity.
Note that kthread_run() never returns NULL so we don't have to check
for that. But apb1_log_task is initially NULL, so that global must
be both non-null and not an error in order to be considered valid.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
These clever macros were fine for early development, but they're
more of a distraction now.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
One function shouldn't do two different things depending on a parameter
passed to it, so split usb_log_enable() into usb_log_disable()
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Add a blank line in apb1_log_enable_read() to make checkpatch happy.
Oh, and it makes the code more readable too...
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
No need to duplicate built-in functions that the kernel has, so have the
core kernel parse the userspace string. Saves us an allocation and
makes the logic simpler.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
On AP module (form factor), we don't have access to APBridge JTAG or UART.
But sometime, we still need to get log from APBridge. Add a new request in control endpoint
to get APBridge logs.
Logs can be accessed using debugfs (greybus/apb1_log).
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When initializing the USB device, we were starting up the svc message
queue before the cport urbs were allocated. This might not be an issue
for "slower" machines, but not having any allocated urbs for a cport
might be an issue if we were to handle svc messages.
So wait until everything is properly initialized and allocated before
starting the svc urb.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Some files are still prefixed with "gb-" with the reasoning that the modules
would be named so, i.e. gb-*.ko. But this can be done by playing a bit in
Makefile instead and keep uniform naming of .c files.
Lets try it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-01-22 11:27:20 +08:00
Renamed from drivers/staging/greybus/gb-es1.c (Browse further)
