- 18 Sep, 2011 15 commits
-
-
git://gitorious.org/usb/usbGreg Kroah-Hartman authored
* 'for-next' of git://gitorious.org/usb/usb: (47 commits) usb: musb: Enable DMA mode1 RX for transfers without short packets usb: musb: fix build breakage usb: gadget: audio: queue wLength-sized requests usb: gadget: audio: actually support both speeds usb: gadget: storage: make FSG_NUM_BUFFERS variable size USB: gadget: storage: remove alignment assumption usb: gadget: storage: adapt logic block size to bound block devices usb: dwc3: gadget: improve debug on link state change usb: dwc3: omap: set idle and standby modes usb: dwc3: ep0: introduce ep0_expect_in flag usb: dwc3: ep0: giveback requests on stall_and_restart usb: dwc3: gadget: drop the useless dma_sync_single* calls usb: dwc3: gadget: fix GCTL programming usb: dwc3: define ScaleDown macro helper usb: dwc3: Fix definition of DWC3_GCTL_U2RSTECN usb: dwc3: gadget: do not map/unmap ZLP transfers usb: dwc3: omap: fix IRQ handling usb: dwc3: omap: change IRQ name to dwc3-omap usb: dwc3: add module.h to dwc3-omap.c and core.c usb: dwc3: omap: distinguish between SW and HW modes ...
-
Yong Zhang authored
This flag is a NOOP and can be removed now. Signed-off-by:
Yong Zhang <yong.zhang0@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ming Lei authored
According to ehci spec 4.10.2, Advance Queue If the fetched qTD has its Active bit set to a zero, the host controller aborts the queue advance and follows the queue head's horizontal pointer to the next schedule data structure. the 'qtd' will be linked into qh hardware queue after the line below *dummy = *qtd; is executed and observed by EHCI HC, but EHCI HC won't have chance to fetch the qtd descriptor pointed by 'qtd' in qh_append_tds until the line below dummy->hw_token = token; #set Active bit here is executed by CPU and observed by EHCI HC. There is already one 'wmb' to order writing to 'dummy'/'qtd' descriptors and writing 'token' to 'dummy' descriptor(set Active bit), so the 1st wmb is not needed and can be removed. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
Ming Lei authored
EHCI_SHRINK_JIFFIES should be 5ms, which was just used originally, and not 200ms, so fix it. Signed-off-by:
-
Ming Lei authored
Obviously, ZLP is only required for transfer of OUT direction, so just take same policy with UHCI for ZLP packet. Signed-off-by:
-
Ming Lei authored
qh_refresh is always called when the qh is idle and has not been linked into hardware queue, so EHCI will not access overlay of the qh at this time. Just before linking qh into hardware queue, there has already one wmb to order writing qh descriptor and writing dma address of the qh into hardware queue, so HC can always see up-to-date qh descriptor once the qh is fetched with its dma address by EHCI. Signed-off-by:
-
Denis Pershin authored
here is the patch to support Owen SI-30 device. This is a pulse counter controller. http://www.owen.ru/en/catalog/93788515 usb-drivers output: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=03eb ProdID=0030 Rev=01.01 C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=00 Driver=cdc_acm I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm This patch is installed on my home system which receives data from this controller connected to cold water counter. Signed-off-by:
Denis Pershin <dyp@perchine.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Vincent Palatin authored
A typo in the configuration variable name prevents from activating the USB autosuspend on the device. Signed-off-by:
Vincent Palatin <vpalatin@chromium.org> Cc: stable <stable@kernel.org> Signed-off-by:
-
Fabian Godehardt authored
The allocated chardevice region range is only 1 device but on unregister it currently tries to deregister 2. Found this while doing a insmod/rmmod/insmod/rm... of the module which seemed to eat major numbers. Signed-off-by:
Fabian Godehardt <fg@emlix.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Heiko Stübner authored
When a transceiver is available use otg_set_power to submit the target current to it. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Michal Nazarewicz authored
In a few places in the kernel, the code prints a human-readable USB device speed (eg. "high speed"). This involves a switch statement sometimes wrapped around in ({ ... }) block leading to code repetition. To mitigate this issue, this commit introduces usb_speed_string() function, which returns a human-readable name of provided speed. It also changes a few places switch was used to use this new function. This changes a bit the way the speed is printed in few instances at the same time standardising it. Signed-off-by:Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
Dan Williams authored
IDs found in the Windows driver's ZTEusbnet.inf file from the ZTE MF100 drivers (O2 UK). Also fixes the ZTE MF626 device since it really is distinct from the 4G Systems stick and apparently needs the net interface blacklisted too, while there's no indication (yet) that the 4G Systems stick does. Signed-off-by:
Dan Williams <dcbw@redhat.com> Cc: stable <stable@kernel.org> Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
That's what the blacklist is for... Signed-off-by:
-
Dan Williams authored
It's cleaner than the array stuff, and we're about to add a bunch more blacklist entries. Second, there are devices that need both the sendsetup and the reserved interface blacklists, which the current code can't accommodate. Signed-off-by:
-
- 09 Sep, 2011 25 commits
-
-
Klaus Schwarzkopf authored
remove the following two paragraphs as they are not needed: This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc.,59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. Signed-off-by:
Klaus Schwarzkopf <schwarzkopf@sensortherm.de> Signed-off-by:
-
Hans Petter Selasky authored
There is a multi-year old bug in the MUSB hardware which is not documented. It causes spurious interrupts and have various symptoms, like endless "SetupEnd came in a wrong ep0stage" messages. The fix is taken from the FreeBSD's musb driver. How to reproduce: For example issue clear-stall on a couple of endpoints very fast, like one request per 125us. After a while the bug triggers and the musb-chip becomes unusable until next re-enumeration. Signed-off-by:
Hans Petter Selasky <hps@bitfrost.no> Signed-off-by:
-
Jim Wylder authored
A return value of -EINPROGRESS from pm_runtime_get indicates that the device is already resuming due to a previous call. Internally, usb_autopm_get_interface_async doesn't treat this as an error and increments the usage count, but passes the error status along to the caller. The logical assumption of the caller is that any negative return value reflects the device not resuming and the pm_usage_cnt not being incremented. Since the usage count is being incremented and the device is resuming, return success (0) instead. Signed-off-by:
James Wylder <james.wylder@motorola.com> Acked-by:
-
Luben Tuikov authored
This patch solves two things: 1) Enables autosense emulation code to correctly interpret descriptor format sense data, and 2) Fixes a bug whereby the autosense emulation code would overwrite descriptor format sense data with SENSE KEY HARDWARE ERROR in fixed format, to incorrectly look like this: Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc] Sense Key : Recovered Error [current] [descriptor] Oct 21 14:11:07 localhost kernel: Descriptor sense data with sense descriptors (in hex): Oct 21 14:11:07 localhost kernel: 72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 Oct 21 14:11:07 localhost kernel: 00 4f 00 c2 00 50 Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc] ASC=0x4 ASCQ=0x1d Signed-off-by:
Luben Tuikov <ltuikov@yahoo.com> Acked-by:
Matthew Dharm <mdharm-usb@one-eyed-alien.net> Cc: stable <stable@kernel.org> Signed-off-by:
-
sifram.rajas@gmail.com authored
The xhci_hcd->devs is an array of pointers rather than pointer to pointer. Hence this check is not required. Signed-off-by: Sifram Rajas <Sifram Rajas sifram.rajas@gmail.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Andiry Xu authored
In xhci_urb_enqueue(), allocate a block of memory for all the TDs instead of allocating memory for each of them separately. This reduces the number of kzalloc calling when an isochronous usb is submitted. Signed-off-by:
Andiry Xu <andiry.xu@amd.com> Signed-off-by:
-
Sarah Sharp authored
Now that the xHCI driver always return a status value of zero for isochronous URBs, when the last TD of an isochronous URB is short, the local variable "status" stays set to -EINPROGRESS. When xHCI driver debugging is turned on, this causes the log file to fill with messages like this: [ 38.859282] xhci_hcd 0000:00:14.0: Giveback URB ffff88013ad47800, len = 1408, expected = 580, status = -115 Don't print out the status of an URB for isochronous URBs. Signed-off-by:
-
Sarah Sharp authored
The xHCI host controller in the Intel Panther Point chipset needs to have software check whether new devices will fit in the available bus bandwidth. Activate the software bandwidth checking quirk when we find the right PCI device. Signed-off-by:
-
Sarah Sharp authored
Now that we have a bandwidth interval table per root port or TT that describes the endpoint bandwidth information, we can finally use it to check whether the bus bandwidth is oversubscribed for a new device configuration/alternate interface setting. The complication for this algorithm is that the bit of hardware logic that creates the bus schedule is only 12-bit logic. In order to make sure it can represent the maximum bus bandwidth in 12 bits, it has to convert the endpoint max packet size and max esit payload into "blocks" (basically a less-precise representation). The block size for each speed of device is different, aside from low speed and full speed. In order to make sure we don't allow a setup where the scheduler might fail, we also have to do the bandwidth checking in blocks. After checking that the endpoints fit in the schedule, we store the bandwidth used for this root port or TT. If this is a FS/LS device under an external HS hub, we also update the TT bandwidth and the root port bandwidth (if this is a newly activated or deactivated TT). I won't go into the details of the algorithm, as it's pretty well documented in the comments. Signed-off-by:
-
Sarah Sharp authored
In order to update the root port or TT's bandwidth interval table, we will need to keep track of a list of endpoints, per interval. That way we can easily know the new largest max packet size when we have to remove an endpoint. Add an endpoint list for each root port or TT structure, sorted by endpoint max packet size. Insert new endpoints into the list such that the head of the list always has the endpoint with the greatest max packet size. Only insert endpoints and update the interval table with new information when those endpoints are periodic. Make sure to update the number of active TTs when we add or drop periodic endpoints. A TT is only considered active if it has one or more periodic endpoints attached (control and bulk are best effort, and counted in the 20% reserved on the high speed bus). If the number of active endpoints for a TT was zero, and it's now non-zero, increment the number of active TTs for the rootport. If the number of active endpoints was non-zero, and it's now zero, decrement the number of active TTs. We have to be careful when we're checking the bandwidth for a new configuration/alt setting. If we don't have enough bandwidth, we need to be able to "roll back" the bandwidth information stored in the endpoint and the root port/TT interval bandwidth table. We can't just create a copy of the interval bandwidth table, modify it, and check the bandwidth with the copy because we have lists of endpoints and entries can't be on more than one list. Instead, we copy the old endpoint bandwidth information, and use it to revert the interval table when the bandwidth check fails. We don't check the bandwidth after endpoints are dropped from the interval table when a device is reset or freed after a disconnect, because having endpoints use less bandwidth should not push the bandwidth usage over the limits. Besides which, we can't fail a device disconnect. Signed-off-by:
-
Sarah Sharp authored
In the upcoming patches, we'll use some stored endpoint information to make software keep track of the worst-case bandwidth schedule. We need to store several variables associated with each periodic endpoint: - the type of endpoint - Max Packet Size - Mult - Max ESIT payload - Max Burst Size (aka number of packets, stored in one-based form) - the endpoint interval (normalized to powers of 2 microframes) All this information is available to the hardware, and stored in its device output context. However, we need to ensure that the new information is stored before the xHCI driver drops the xhci->lock to wait on the Configure Endpoint command, so that another driver requesting a configuration or alt setting change will see the update. The Configure Endpoint command will never fail on the hardware that needs this software bandwidth checking (assuming the slot is enabled and the flags are set properly), so updating the endpoint info before the command completes should be fine. Until we add in the bandwidth checking code, just update the endpoint information after the Configure Endpoint command completes, and after a Reset Device command completes. Don't bother to clear the endpoint bandwidth info when a device is being freed, since the xhci_virt_ep is just going to be freed anyway. Signed-off-by:
-
Sarah Sharp authored
For upcoming patches, we need to keep information about the bandwidth domains under the xHCI host. Each root port is a separate primary bandwidth domain, and each high speed hub's TT (and potentially each port on a multi-TT hub) is a secondary bandwidth domain. If the table were in text form, it would look a bit like this: EP Interval Sum of Number Largest Max Max Packet of Packets Packet Size Overhead 0 N mps overhead ... 15 N mps overhead Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol overhead, etc) for all the endpoints in this interval. Devices with different speeds have different max packet overhead. For example, if there is a low speed and a full speed endpoint that both have an interval of 3, we would use the higher overhead (the low speed overhead). Interval 0 is a bit special, since we really just want to know the sum of the max ESIT payloads instead of the largest max packet size. That's stored in the interval0_esit_payload variable. For root ports, we also need to keep track of the number of active TTs. For each root port, and each TT under a root port, store some information about the bandwidth consumption. Dynamically allocate an array of root port bandwidth information for the number of root ports on the xHCI host. Each root port stores a list of TTs under the root port. A single TT hub only has one entry in the list, but a multi-TT hub will have an entry per port. When the USB core says that a USB device is a hub, create one or more entries in the root port TT list for the hub. When a device is deleted, and it is a hub, search through the root port TT list and delete all TT entries for the hub. Keep track of which TT entry is associated with a device under a TT. LS/FS devices attached directly to the root port will have usb_device->tt set to the roothub. Ignore that, and treat it like a primary bandwidth domain, since there isn't really a high speed bus between the roothub and the host. Signed-off-by:
-
Sarah Sharp authored
Since the xHCI driver now has split USB2/USB3 roothubs, devices under each roothub can have duplicate "fake" port numbers. For the next set of patches, we need to keep track of the "real" port number that the xHCI host uses to index into the port status arrays. Signed-off-by:
-
Sarah Sharp authored
Move the code to check whether we've reached the host controller's limit on the number of endpoints out of the two conditional statements, to remove duplicate code. Signed-off-by:
-
Sarah Sharp authored
The "port" field in xhci_virt_dev stores the port number associated with one of the two xHCI split roothubs, not the unique port number the xHCI hardware uses. Since we'll need to store the real hardware port number in future patches, rename this field to "fake_port". Signed-off-by:
-
Sarah Sharp authored
Some alternate interface settings have no endpoints associated with them. This shows up in some USB webcams, particularly the Logitech HD 1080p, which uses the uvcvideo driver. If a driver switches between two alt settings with no endpoints, there is no need to issue a configure endpoint command, because there is no endpoint information to update. The only time a configure endpoint command with just the add slot flag set makes sense is when the driver is updating hub characteristics in the slot context. However, that code never calls xhci_check_bandwidth, so we should be safe not issuing a command if only the slot context add flag is set. Signed-off-by:
-
Anand Gadiyar authored
This patch enables DMA mode1 for the RX path when we know there won't be any short packets. We check that by looking into the short_no_ok flag, if it's true we enable mode1, otherwise we use mode0 to transfer the data. This will result in a throughput performance gain of around 40% for USB mass-storage/mtp use cases. [ balbi@ti.com : updated commit log and code comments slightly ] Signed-off-by:
Anand Gadiyar <gadiyar@ti.com> Signed-off-by:
Moiz Sonasath <m-sonasath@ti.com> Signed-off-by:
Vikram Pandita <vikram.pandita@ti.com> Tested-by:
Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
This patch fixes the compilation brekage which commits 208466dc ("usb: otg:OMAP4430: Powerdown the internal PHY when USB is disabled") and fb91cde4 ("usb: musb: OMAP4430: Power down the PHY during board init") introduced when building a OMAP2-only kernel. LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o:(.data+0x7ce0): undefined reference to +`omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0x7ce4): undefined reference to +`omap4430_phy_exit' arch/arm/mach-omap2/built-in.o:(.data+0x7ce8): undefined reference to +`omap4430_phy_power' arch/arm/mach-omap2/built-in.o:(.data+0x7cec): undefined reference to +`omap4430_phy_set_clk' arch/arm/mach-omap2/built-in.o:(.data+0x7cf0): undefined reference to +`omap4430_phy_suspend' make: *** [.tmp_vmlinux1] Error 1 Reported-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Felipe Balbi authored
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 authored
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: -
Per Forlin authored
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:
-
Alan Stern authored
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:
-
Peiyu Li authored
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:
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 authored
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 authored
For now, let's disable IDLE and STANDBY transitions until we have a real HW to validate against. Signed-off-by:
-
