On Audio class, the wLength field of the Setup
packet, contains the data payload size of the
following Data phase. Instead of harcoding values,
use wLength.
This also fixes a bug where Gadget driver had to
receive 3 bytes, but it was queueing a ZLP.
Signed-off-by: Felipe Balbi <balbi@ti.com>
While testing g_audio with HighSpeed UDC on a
FS Hub, we had no configurations to present to
the host. That's because both speeds where
mutually exclusive.
Signed-off-by: Felipe Balbi <balbi@ti.com>
FSG_NUM_BUFFERS is set to 2 as default.
Usually 2 buffers are enough to establish a good buffering pipeline.
The number may be increased in order to compensate a for bursty VFS
behaviour.
Here follows a description of system that may require more than
2 buffers.
* CPU ondemand governor active
* latency cost for wake up and/or frequency change
* DMA for IO
Use case description.
* Data transfer from MMC via VFS to USB.
* DMA shuffles data from MMC and to USB.
* The CPU wakes up every now and then to pass data in and out from VFS,
which cause the bursty VFS behaviour.
Test set up
* Running dd on the host reading from the mass storage device
* cmdline: dd if=/dev/sdb of=/dev/null bs=4k count=$((256*100))
* Caches are dropped on the host and on the device before each run
Measurements on a Snowball board with ondemand_governor active.
FSG_NUM_BUFFERS 2
104857600 bytes (105 MB) copied, 5.62173 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.61811 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.57817 s, 18.8 MB/s
FSG_NUM_BUFFERS 4
104857600 bytes (105 MB) copied, 5.26839 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2691 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2711 s, 19.9 MB/s
There may not be one optimal number for all boards. This is why
the number is added to Kconfig. If selecting USB_GADGET_DEBUG_FILES
this value may be set by a module parameter as well.
Signed-off-by: Per Forlin <per.forlin@linaro.org>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch (as1481) fixes a problem affecting g_file_storage and
g_mass_storage when running at SuperSpeed. The two drivers currently
assume that the bulk-out maxpacket size can evenly divide the SCSI
block size, which is 512 bytes. But SuperSpeed bulk endpoints have a
maxpacket size of 1024, so the assumption is no longer true.
This patch removes that assumption from the drivers, by getting rid of
a small optimization (they try to align VFS reads and writes on page
cache boundaries). If a command's starting logical block address is
512 bytes below the end of a page, it's not okay to issue a USB
command for just those 512 bytes when the maxpacket size is 1024 -- it
would result in either babble (for an OUT transfer) or a short packet
(for an IN transfer).
Also, for backward compatibility, the test for writes extending beyond
the end of the backing storage has to be changed. If the host tries
to do this, we should accept the data that fits in the backing storage
and ignore the rest. Because the storage's end may not align with a
USB packet boundary, this means we may have to accept a USB OUT
transfer that extends beyond the end of the storage and then write out
only the part of the data that fits.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Now the mass storage driver has fixed logic block size of 512 bytes.
The mass storage gadget read/write bound devices only through VFS, so the
bottom level devices actually are just RAW devices to the driver and connected
PC. As a RAW, hosts can always format, read and write it right in 512 bytes
logic block and don't care about the actual logic block size of devices bound
to the gadget.
But if we want to share the bound block device partition between target board
and PC, in case the logic block size of the bound block device is 4KB, we
execute the following steps:
1. connect a board with mass storage gadget to PC(the board has set one
partition of on-board block device as file name of the mass storage)
2. PC format the mass storage to VFAT by default logic block size and
read/write it
3. disconnect boards from PC
4. target board mount the partition as VFAT
Step 4 will fail since kernel on target thinks the logic block size of the
bound partition as 4KB.
A typical error is "FAT: logical sector size too small for device (logical
sector size = 512)"
If we execute opposite steps:
1. format the partition to VFAT on target board and read/write this partition
2. connect the board to Windows PC as usb mass storage gadget, windows will
think the disk is not formatted
So the conclusion is that only as a gadget, the mass storage driver has no any
problem. But being shared VFAT or other filesystem on PC and target board, it
will fail.
This patch adapts logic block size to bound block devices and fix the issue.
Cc: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Peiyu Li <peiyu.li@csr.com>
Signed-off-by: Xianglong Du <xianglong.du@csr.com>
Signed-off-by: Huayi Li <huayi.li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
It's useful to know which states core is going
through, as it might help us figure out misbehavior
on specific link states.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This flag will tell us which direction we're
expecting on the next (data or status) phase.
It will help us catching errors of host going
crazy and requesting data of the wrong direction.
Signed-off-by: Felipe Balbi <balbi@ti.com>
if req->dma isn't DMA_ADDR_INVALID it means gadget driver
mapped the request or allocated from coherent, so it's
unnecessary to do anything.
Signed-off-by: Felipe Balbi <balbi@ti.com>
If the gadget drivers sends a ZLP we are trying to map this this request
which does not work on all implementations. So we simply skip mapping
it.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
dwc3-wrapper can be used by any other wrapper,
using dwc3-omap makes it clear that we're running
on OMAP SoC.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The OMAP wrapper allows us to either control internal
OTG signals via SW or HW. Different boards might wish
to use one or the other mode of operation. Let's have
have that information passed via platform_data for now.
After DT conversion is finished for OMAP, we can easily
convert this to a DT attribute.
Signed-off-by: Felipe Balbi <balbi@ti.com>
We need to have actual HW in order to implement
and test that part of the code anyway. Until then
it's best to remove it.
Signed-off-by: Felipe Balbi <balbi@ti.com>
this field will hold the next expected event.
In certain cases, host might fall into some error
condition and ask from us the wrong Control phase.
On such situations, we should stall and restart.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Whenever we issue a Set Stall command on EP0,
the state machine will be restarted and Stall
is cleared automatically, when core receives
the next SETUP packet.
There's no need to track that EP0_STALL state.
Signed-off-by: Felipe Balbi <balbi@ti.com>
when we're going to issue Set Stall command,
we should clear DWC3_EP_STALL flag, but also
we should clear BUSY, HALTED and all others.
Signed-off-by: Felipe Balbi <balbi@ti.com>
There are two spots where we wait until the HW finishes processing a
certain command. Initially we had a few problems and we used 500ms as a
limit to be on a the safe side. Paul Zimmerman mentioned this is little too
much. After a debugging session, we noticed that we hardly ever go over 20us
and didn't pass 30usec so far. Using mdelay() seems way overloaded.
Giving the current numbers 500usec as the upper limit is more than enough.
Should it ever timeout then something is definitely wrong.
While here, also replace the type with u32 since long does not really
fit here.
Cc: Paul Zimmerman <paul.zimmerman@synopsys.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
- since a while we are disabling an endpoint and purging every requests on
RESET and DISCONNECT which leads to a warning since the endpoint was
disabled twice (once by the UDC, and second time by the gadget). I
think UDC should nuke all requests because all those requests
become invalid. It's gadget driver's responsability, though, to disable
its used endpoints. This is done by merging dwc3_stop_active_transfer()
and dwc3_gadget_nuke_reqs() into dwc3_remove_requests().
- dwc3_stop_active_transfer() is now no longer called unconditionaly.
This has the advantage that it is always called to disable an active
transfer which means if res_trans_idx 0 than something went wrong and
it is an error condition because we can't clean up the requests.
- Remove the DWC3_EP_WILL_SHUTDOWN which was introduced while
introducing the command complete part for dequeue. All requests on
req_queued list should be removed during the dwc3_cleanup_done_reqs()
callback so there is no reason to go through the list again.
We consider it an error condition if requests are still on this
list since we never queue TRB without LST=1 (the last requests has
always LST=1, there are no requests with LST=0 behind it).
[ balbi@ti.com : reworked commit log a bit, made patch apply ]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We read the DWC3_GSNPSID register to make sure we got the correct
register offset passed. One of the recent commits moved the soft reset
before this so in case of the wrong offset we end up with "reset timed
out". This patch moves the "id" check before the reset again.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
There are some issues around for enabling/disabling this mode and
handling it. It does not work perfectly (yet). However we have a few
gadgets tested successfuly so far. That means we are quite confident
that we won't need this in near future.
So I'm for removing it and bringing a working version back once there is
a need for it.
Thanks to Dan Carpenter who spotted the wrong memory handling here.
[ balbi@ti.com : made it actually apply ]
Cc: Dan Carpenter <error27@gmail.com>
Cc: wharms@bfs.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The DesignWare USB3 core tells us which phase
of a control transfer should be started, it
also tells us which physical endpoint needs
that transfer.
With these two informations, we have all we
need to simply EP0 handling quite a lot and
get rid rid of the SW state machine tracking
ep0 states.
For achieving this perfectly, we needed to
add support for situations where we get
XferNotReady while endpoint is still busy
and XferNotReady while gadget driver still
hasn't queued a request.
Signed-off-by: Felipe Balbi <balbi@ti.com>
In case we have transfers which aren't aligned
to wMaxPacketSize, we need to be careful with
how we start the transfer with the HW. OUT
transfers _must_ be aligned with wMaxPacketSize
and in order to guarantee that, we use a bounce
buffer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This core cannot handle OUT transfers which aren't
aligned to wMaxPacketSize, but that can happen at
least on control endpoint with the USB Audio Class.
This patch adds a bounce buffer to be used on the
case of a non-aligned ep0out request is queued.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The status field of the Transfer Not Read event
is different on Control Endpoints. On this patch
we are just adding the defines to be used on a
later patch which will re-work the control endpoint
handling.
Signed-off-by: Felipe Balbi <balbi@ti.com>
the previous message had too little meaning. Make
it more human readable and use the macro we already
had for extracting the command completion status out
of DEPCMDn register.
Signed-off-by: Felipe Balbi <balbi@ti.com>
if we don't set DMA address to invalid when unmapping,
we might fall in a situation where request buffer
can't be mapped to DMA again.
Signed-off-by: Felipe Balbi <balbi@ti.com>
We may as well fix this potential leak so we don't have to listen to
the static checkers complain.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Without this patch we won't clear that bit and instead will
clear all other bits on our endpoint flag.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Type 6 should be used for the first transfer during an interval. This is
also what the reference driver is using. Type 7 seems to be for following
or additional transfers within the same interval.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If we collected two requests together (i.e. only the last of them has
LST=1) then we only have to stop transfer once: The clean-up code will
cleanup everything until first TRB with the LST bit set.
After XferComplete this index should be no longer valid since there is
no transfer pending.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
A TRB which is dequeued seems to have its HWO bits set to 1. Therefore
we ignore it if we dequeue it after the command is completed.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch changes rts51x_read_mem, rts51x_write_mem, and rts51x_read_status to
allocate temporary buffers with kmalloc. This way stack addresses are not used
for DMA when these functions call rts51x_bulk_transport.
Signed-off-by: Adam Cozzette <acozzette@cs.hmc.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
the MACH_MX* macros are scheduled for removal, so just depend
on ARCH_MXC instead. The Kconfig text makes it clear on which
SoC the driver runs on.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The ARCH_MX1 scheduled for removal. Instead, depend on ARCH_MXC
and make clear in the Kconfig text that only i.MX1 has this
hardware.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Felipe Balbi
Per Forlin
Alan Stern
Peiyu Li
Sebastian Andrzej Siewior
Dan Carpenter
Michał Sroczyński
Adam Cozzette
Sascha Hauer
Randy Dunlap