- 08 Jul, 2011 16 commits
-
-
Michał Sroczyński authored
PL2303: correctly handle baudrates above 115200 Signed-off-by:
Michal Sroczynski <msroczyn@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kuninori Morimoto authored
This is typo fix of 749da5f8 (USB: straighten out port feature vs. port status usage) Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Kuninori Morimoto authored
This patch rescues renesas_usbhs compile from commit 193ab2a6 (usb: gadget: allow multiple gadgets to be built) CONFIG_USB_RENESAS_USBHS compile renesas_usbhs main code which is shared between Host/Gadget. CONFIG_USB_RENESAS_USBHS_UDC add mod_gadget to it. It had lost USB_GADGET_DUALSPEED Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Kuninori Morimoto authored
This patch add/modify comment-out of renesas_usbhs. On this process, usbhs_pkt_init was moved because it was placed under usbhsf_null_handler which has no relationship it Signed-off-by:
-
Yoshihiro Shimoda authored
Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Yoshihiro Shimoda authored
R8A66597 has the pin of WR0 and WR1. So, if one write-pin of CPU connects to the pins, we have to change the setting of FIFOSEL register in the controller. If we don't change the setting, the controller cannot send the data of odd length. Signed-off-by:
-
Sergei Shtylyov authored
MAX4967 USB power supply chip we use on our boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That unfortunately caused the endless stream of "over-current change on port" messages. The EHCI root hub code reacts on every over-current signal change with powering off the port -- such change event is generated the moment the port power is enabled, so once enabled the power is immediately cut off. I think we should only cut off power when we're seeing the active over-current signal, so I'm adding such check to that code. I also think that the fact that we've cut off the port power should be reflected in the result of GetPortStatus request immediately, hence I'm adding a PORTSCn register readback after write... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: stable@kernel.org Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Tobias Klauser authored
Do not bail out with an error in mon_text_init() if debugfs is not available, instead just return 0 and let mon_init() go ahead with loading the binary API. Return -ENOMEM in case debugfs_create_dir() fails for other reasons. Later, it is enough to check for mon_dir not set. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Alan Stern authored
This patch (as1477) fixes a problem affecting a few types of EHCI controller. Contrary to what one might expect, these controllers automatically stop their internal frame counter when no ports are enabled. Since ehci-hcd currently relies on the frame counter for determining when it should unlink QHs from the async schedule, those controllers run into trouble: The frame counter stops and the QHs never get unlinked. Some systems have also experienced other problems traced back to commit b9638011 (USB: ehci-hcd unlink speedups), which made the original switch from using the system clock to using the frame counter. It never became clear what the reason was for these problems, but evidently it is related to use of the frame counter. To fix all these problems, this patch more or less reverts that commit and goes back to using the system clock. But this can't be done cleanly because other changes have since been made to the scan_async() subroutine. One of these changes involved the tricky logic that tries to avoid rescanning QHs that have already been seen when the scanning loop is restarted, which happens whenever an URB is given back. Switching back to clock-based unlinks would make this logic even more complicated. Therefore the new code doesn't rescan the entire async list whenever a giveback occurs. Instead it rescans only the current QH and continues on from there. This requires the use of a separate pointer to keep track of the next QH to scan, since the current QH may be unlinked while the scanning is in progress. That new pointer must be global, so that it can be adjusted forward whenever the _next_ QH gets unlinked. (uhci-hcd uses this same trick.) Simplification of the scanning loop removes a level of indentation, which accounts for the size of the patch. The amount of code changed is relatively small, and it isn't exactly a reversion of the b9638011 commit. This fixes Bugzilla #32432. Signed-off-by:
Matej Kenda <matejken@gmail.com> Signed-off-by:
-
Anisse Astier authored
Add another variant of the Pegatron tablet used by Ordissimo, and apparently RM Slate 100, to the list of models that should skip the negociation for the handoff of the EHCI controller. Signed-off-by:
Anisse Astier <anisse@astier.eu> Signed-off-by:
-
Anisse Astier authored
In commit 3610ea53 (ehci: workaround for pci quirk timeout on ExoPC), a workaround was added to skip the negociation for the handoff of the EHCI controller. Refactor the DMI detection code to use standard dmi_check_system function. Signed-off-by:
-
Kirill Smelkov authored
There are cases, when 80% max isochronous bandwidth is too limiting. For example I have two USB video capture cards which stream uncompressed video, and to stream full NTSC + PAL videos we'd need NTSC 640x480 YUV422 @30fps ~17.6 MB/s PAL 720x576 YUV422 @25fps ~19.7 MB/s isoc bandwidth. Now, due to limited alt settings in capture devices NTSC one ends up streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both with interval=1. In terms of microframe time allocation this gives NTSC ~53us PAL ~57us and together ~110us > 100us == 80% of 125us uframe time. So those two devices can't work together simultaneously because the'd over allocate isochronous bandwidth. 80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and both devices started to work together, so I though sometimes it would be a good idea for users to override hardcoded default of max 80% isoc bandwidth. After all, isn't it a user who should decide how to load the bus? If I can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB newcomer, but that 80% set in stone by USB 2.0 specification seems to be chosen pretty arbitrary to me, just to serve as a reasonable default. NOTE 1 ~~~~~~ for two streams with max_pkt_size=3072 (worst case) both time allocation would be 60us+60us=120us which is 96% periodic bandwidth leaving 4% for bulk and control. Alan Stern suggested that bulk then would be problematic (less than 300*8 bittimes left per microframe), but I think that is still enough for control traffic. NOTE 2 ~~~~~~ Sarah Sharp expressed concern that maxing out periodic bandwidth could lead to vendor-specific hardware bugs on host controllers, because > It's entirely possible that you'll run into > vendor-specific bugs if you try to pack the schedule with isochronous > transfers. I don't think any hardware designer would seriously test or > validate their hardware with a schedule that is basically a violation of > the USB bus spec (more than 80% for periodic transfers). So far I've only tested this patch on my HP Mini 5103 with N10 chipset kirr@mini:~$ lspci 00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 02) 01:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8059 PCI-E Gigabit Ethernet Controller (rev 11) and the system works stable with 110us/uframe (~88%) isoc bandwith allocated for above-mentioned isochronous transfers. NOTE 3 ~~~~~~ This feature is off by default. I mean max periodic bandwidth is set to 100us/uframe by default exactly as it was before the patch. So only those of us who need the extreme settings are taking the risk - normal users who do not alter uframe_periodic_max sysfs attribute should not see any change at all. NOTE 4 ~~~~~~ I've tried to update documentation in Documentation/ABI/ thoroughly, but only "TBD" was put into Documentation/usb/ehci.txt -- the text there seems to be outdated and much needing refreshing, before it could be amended. Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:Kirill Smelkov <kirr@mns.spb.ru> Acked-by:
-
Kirill Smelkov authored
The only sysfs attr implemented so far is "companion" from ehci-hub.c, but in the next patch we are going to add another sysfs file, so prior to that let's structure things and move already-in-there sysfs code to separate file. NOTE: All the code I'm moving into this new file was written by Alan Stern (in 57e06c11 "EHCI: force high-speed devices to run at full speed"; Jan 16 2007), that's why I'm putting Copyright (C) 2007 by Alan Stern there after explicit request from the author. Signed-off-by:
-
Chris Forbes authored
Added missing const qualifier as flagged by checkpatch.pl Signed-off-by:
Chris Forbes <chrisf@ijw.co.nz> Signed-off-by:
-
Chris Forbes authored
Replaced __attribute__ ((packed)) with __packed; Signed-off-by:
-
Matthieu CASTET authored
Signed-off-by:
Matthieu CASTET <castet.matthieu@free.fr> Tested-by:
Pavankumar Kondeti <pkondeti@codeaurora.org> Signed-off-by:
-
- 01 Jul, 2011 24 commits
-
-
edwin_rong authored
The autosuspend function can be disabled by unchecking the Macro CONFIG_REALTEK_AUTOPM in kernel config file, by default, this macro is turned on. Signed-off-by:
edwin_rong <edwin_rong@realsil.com.cn> Signed-off-by:
-
edwin_rong authored
Remove Macros wait_timeout() and wait_timeout_x(). Signed-off-by:
-
edwin_rong authored
Signed-off-by:
-
Viliam Mateicka authored
There is a bug in Samsung's UDC driver, which is completely disabling the USB device when a custom UDC command is used. Following patch seems to get the right behavior (e.g. enabling pull-up instead of disabling then Vcc is applied). Signed-off-by:
Viliam Mateicka <viliam.mateicka@gmail.com> Signed-off-by:
-
Tatyana Brokhman authored
A compilation warning was added by the patch "usb: gadget: use config_ep_by_speed() instead of ep_choose()". This patch fixed it. Signed-off-by:
Tatyana Brokhman <tlinder@codeaurora.org> Signed-off-by:
-
Moiz Sonasath authored
With this commit: cccad6d4 usb: otg: notifier: switch to atomic notifier Following dumps are observed on attach/detach for MUSB HOST mode and on a detach for MUSB Device mode. BUG: sleeping function called from invalid context at kernel/mutex.c:85 where, the source is: twl6030_usb_irq ->atomic_notifier_call_chain ->musb_otg_notifications ->twl6030_set_vbus ->twl_i2c_write_u8 ->mutex_lock This patch moves the i2c writes in set_vbus function to a work-queue thereby avoiding I2C writes in atomic context. Tested HOST and Device mode functionality on OMAP4460 Signed-off-by:
Moiz Sonasath <m-sonasath@ti.com> Signed-off-by:
-
Jassi Brar authored
The config bind was reported success even if usb_add_function failed. Fix the return value. Signed-off-by:
Jassi Brar <jaswinder.singh@linaro.org> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Bob Liu authored
The recent commit 2edb11cb fixed req->length in the composite_setup() function, but that will cause all g_zero tests to fail like: root#> ./testusb -D /proc/bus/usb/002/021 -t14 -c 15000 -s 256 -v 1 unknown speed /proc/bus/usb/002/021 /proc/bus/usb/002/021 test 14 --> 32 (Broken pipe) We need to fix req->length in sourcesink_setup() as well to avoid this. Signed-off-by:
Bob Liu <lliubbo@gmail.com> Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Tobias Klauser authored
Use ASCII minus sign instead of unicode EN DASH in gadget_hid.txt. Also remove two unecessary spaces in the same file. Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
-
Manuel Zerpies authored
Since printk_ratelimit() shouldn't be used anymore (see comment in include/linux/printk.h), replace it with printk_ratelimited() Signed-off-by:
Manuel Zerpies <manuel.f.zerpies@ww.stud.uni-erlangen.de> Signed-off-by:
-
Manuel Zerpies authored
Since printk_ratelimit() shouldn't be used anymore (see comment in include/linux/printk.h), replace it with printk_ratelimited() Signed-off-by:
-
Manuel Zerpies authored
Since printk_ratelimit() shouldn't be used anymore (see comment in include/linux/printk.h), replace it with printk_ratelimited() Signed-off-by:
-
Felipe Balbi authored
dev_get_drvdata() is exactly the same as platform_get_drvdata(). Drop that useless access to the platform device. Signed-off-by:
-
Felipe Balbi authored
there's no point in not creating that device always. It's simpler to always create, than to keep changing that stupid ifdef. Signed-off-by:
-
Sebastian Andrzej Siewior authored
This was somehow forgotten. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
bind() and pull is moved to udc core, call callbacks are verified by the upper layer. Signed-off-by:
-
Sebastian Andrzej Siewior authored
udc-core checks for valid callbacks so there is no need for the driver to do so. Also "can-be-bound-once" is verified by udc-core. The pull-up callback is called by udc-core afterwords. [ balbi@ti.com : keep holding gadget_driver pointer for now remove the stupid check for gadget_driver otherwise we don't handle IRQs ] Signed-off-by:
-
Sebastian Andrzej Siewior authored
udc_start() should only trigger the internal state machine and make minimal house keeping. Before that call udc-core calls the bind() callback and after the callback the pullup(). udc_stop() is simillar, udc-core calls pullup(), unbind() and finally udc_stop(). Signed-off-by:
-
Sebastian Andrzej Siewior authored
The configuration is static however we only know the speed after we have connected with the other side. Signed-off-by:
-
Sebastian Andrzej Siewior authored
This value is now assigned during bind(). The configuration depends on static values assigned by dummy driver itself. So there is no need to defer this assigment until one know the actuall speed since the configuration is static and known early. Signed-off-by:
-
Sebastian Andrzej Siewior authored
This is only required to be done once. There is no counter part to this in ->stop() so there is no need to re-do it next time. While here also init the max_stream size to 0 on SS speed. Signed-off-by:
-
Sebastian Andrzej Siewior authored
maxpacket is set by the udc driver for ep0 very early. This value is copied by the function gadget used later for the USB_DT_DEVICE and USB_DT_DEVICE_QUALIFIER query. This seems to work fine so far. For USB3 we need set a different value here. In SS speed it is 2^x with x=9 and in HS we set something <= 64. If the UDC starts in SS and continues in HS after the cable has been plugged it will report a too small value. There setting of this value is defered and taken automaticly from the ep0 pointer where the UDC driver can update it according to the speed it detected _after_ a cable has been plugged. Signed-off-by:
-
