- 14 Aug, 2013 29 commits
-
-
Sascha Hauer authored
The chipidea i.MX driver is split into two drivers. The ci_hdrc_imx driver handles the chipidea cores and the usbmisc_imx driver handles the noncore registers common to all chipidea cores (but SoC specific). Current flow is: - usbmisc sets an ops pointer in the ci_hdrc_imx driver during probe - ci_hdrc_imx checks if the pointer is valid during probe, if yes calls the functions in the ops pointer. - usbmisc_imx calls back into the ci_hdrc_imx driver to get additional data This is overly complicated and has problems if the drivers are compiled as modules. In this case the usbmisc_imx driver can be unloaded even if the ci_hdrc_imx driver still needs usbmisc functionality. This patch changes this by letting the ci_hdrc_imx driver calling functions from the usbmisc_imx driver. This way the symbol resolving during module load makes sure the ci_hdrc_imx driver depends on the usbmisc_imx driver. Also instead of letting the usbmisc_imx driver call back into the ci_hdrc_imx driver, pass the needed data in the first place. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Chen authored
For chipidea, the IP must know vbus before the controller begins to run. So the .pullup should only be called when the vbus is there. Tested-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Peter Chen authored
Currently, the controller only runs when the ci->vbus_active is true. So the flag CI_HDRC_PULLUP_ON_VBUS is useless no longer. If the user doesn't have otgsc, he/she needs to change ci_handle_vbus_change to update ci->vbus_active. Signed-off-by:
-
Peter Chen authored
CI_HDRC_REGS_SHARED stands for the controller registers is shared with other USB drivers, if all USB drivers are at chipidea/, it doesn't needed to be set. CI_HDRC_PULLUP_ON_VBUS stands for pullup dp when the vbus is on. This flag doesn't need to be set if the vbus is always on for gadget since dp has always pulled up after the gadget has initialized. So, the current code seems to misuse this two flags. - When the gadget initializes, the controller doesn't need to run if it depends on vbus (CI_HDRC_PULLUP_ON_VBUS), it does not relate to shared register. - When the gadget starts (load one gadget module), the controller can run if vbus is on (CI_HDRC_PULLUP_ON_VBUS), it also does not relate to shared register. Tested-by:
-
Peter Chen authored
When the gadget role starts, we need to make sure the vbus is lower than OTGSC_BSV, or there will be an vbus interrupt since we use B_SESSION_VALID as vbus interrupt to indicate connect and disconnect. When the host role starts, it may not be useful to wait vbus to lower than OTGSC_BSV, but it can indicate some hardware problems like the vbus is still higher than OTGSC_BSV after we disconnect to host some time later (5000 milliseconds currently), which is obvious not correct. Tested-by:
-
Peter Chen authored
We add vbus interrupt handler at ci_otg_work, it uses OTGSC_BSV(at otgsc) to know it is connect or disconnet event. Meanwhile, we introduce two flags id_event and b_sess_valid_event to indicate it is an id interrupt or a vbus interrupt. Tested-by:
-
Peter Chen authored
Move otg related things to otg file. Tested-by:
-
Peter Chen authored
During the initialization, it needs to disable all interrupts enable bit as well as clear all interrupts status bits to avoid exceptional interrupt. Tested-by:
-
Peter Chen authored
Since we need otgsc to know vbus's status at some chipidea controllers even it is peripheral-only mode. Besides, some SoCs (eg, AR9331 SoC) don't have otgsc register even the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS. We inroduce flag CI_HDRC_DUAL_ROLE_NOT_OTG to indicate if the controller is dual role, but not supports OTG. If this flag is not set, we follow the rule that if DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS, then this controller is otg capable. Signed-off-by:
-
Peter Chen authored
- The role's init will be called at probe procedure. - The role's destroy will be called at fail patch at probe and driver's removal. - The role's start/stop will be called when specific role has started. Tested-by:
-
Peter Chen authored
This file is mainly used to access otgsc currently, it may add otg related things in the future. Tested-by:
-
Peter Chen authored
It is useless at below cases: - If we implement both usb host and device at chipidea driver. - If we don't need phy->otg. Tested-by:
-
Peter Chen authored
For boards which have board level vbus control (eg, through gpio), we need to vbus operation according to below rules: - For host, we need open vbus before start hcd, and close it after remove hcd. - For otg, the vbus needs to be on/off when usb role switches. When the host roles begins, it opens vbus; when the host role finishes, it closes vbus. We put vbus operation to host as host is the only vbus user, When we are at host mode, the vbus is on, when we are not at host mode, vbus should be off. Tested-by:
-
Peter Chen authored
The vbus regulator is a common element for USB vbus operation, So, move it from glue layer to core. Tested-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
-
Fabio Estevam authored
After the rename to ci_hdrc we ended up with two MODULE_ALIAS entries, so remove the old one. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Reviewed-by:
-
Lothar Waßmann authored
Commit 40dcd0e8 ("usb: chipidea: add PTW, PTS and STS handling") introduced the following code to the ci_hdrc_probe() function: + if (!dev->of_node && dev->parent) + dev->of_node = dev->parent->of_node; This inadvertently associates the ci_hdrc device with the ci_hdrc_imx driver (which created the ci_hdrc device in the first place). This results in ci_hdrc_imx_probe() being run for the ci_hdrc device if ci_hdrc_probe() fails for some reason. ci_hdrc_imx_probe() will happily create a new ci_hdrc platform_device whose probing will likewise fail and trigger a new invocation of ci_hdrc_imx_probe() ... ad nauseam. Signed-off-by:
Lothar Waßmann <LW@KARO-electronics.de> Reviewed-and-tested-by:
-
Lothar Waßmann authored
If a role fails to start, propagate the error code up the call stack from probe. Signed-off-by:
-
Lothar Waßmann authored
This prevents the USB PHY refcount to be decremented below zero upon unloading the ci-hdrc-imx module. Signed-off-by:
-
Lothar Waßmann authored
This patch provides a cleaner solution to the problem described in commit 20a677fd ("usb: chipidea: improve kconfig"). The goal to be achieved is to force USB_CHIPIDEA=m if either USB_EHCI_HCD=m or USB_GADGET=m. If both are 'y' USB_CHIPIDEA may be selected to be 'm' or 'y'. The old patch had the drawback, that USB_CHIPIDEA could be chosen as 'y' though USB_EHCI_HCD or USB_GADGET (or both) were 'm' leading to a situation where USB_CHIPIDEA_HOST or USB_CHIPIDEA_UDC vanished from the config options producing a compilable but dysfunctional driver. Signed-off-by:
-
Peter Chen authored
Remove an unused macro leftover from the old initialization code. Signed-off-by:
-
Fabio Estevam authored
Currently hw_phymode_configure() is located inside hw_device_reset(), which is only called by chipidea udc driver. When operating in host mode, we also need to call hw_phymode_configure() in order to properly configure the PHY mode, so move this function into probe. After this change, USB Host1 port on mx53qsb board is functional. Signed-off-by:
Arnaud Patard <arnaud.patard@rtp-net.org> Reviewed-by:
-
Fabio Estevam authored
'res' is not used anywhere, so let's get rid of it. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Felipe Balbi authored
if pdata is a NULL pointer we could cause a kernel oops when probing the driver. Make sure to cope with systems which won't pass pdata to the driver. Tested-by:
Paul Zimmerman <paulz@synopsys.com> Reported-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sean O. Stalley authored
rh_call_control() contains a buffer, tbuf, which it uses to hold USB descriptors. These discriptors are eventually copied into the transfer_buffer in the URB. The buffer in the URB is dynamically defined and is always large enough to hold the amount of data it requests. tbuf is currently statically allocated on the stack with a size of 15 bytes, regardless of the size specified in the URB. This patch dynamically allocates tbuf, and ensures that tbuf is at least as big as the buffer in the URB. If an hcd attempts to write a descriptor containing more than 15 bytes ( such as the Standard BOS Descriptor for hubs, defined in the USB3.0 Spec, section 10.13.1 ) the write would overflow the buffer and corrupt the stack. This patch addresses this behavior. Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Sean O. Stalley <sean.stalley@intel.com> Signed-off-by:
-
Jack Pham authored
commit 9841f37a ("usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET") added additional code to the EHCI hub driver but it is anticipated to only have a limited audience (e.g. embedded silicon vendors and integrators). Avoid subjecting all EHCI (and in the future maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally compiling the EHSET-specific additions with a new Kconfig option, CONFIG_USB_HCD_TEST_MODE. Signed-off-by:
Jack Pham <jackp@codeaurora.org> Acked-by:
-
Frank Schäfer authored
The driver currently knows about 3 different PL2303 chip types: The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX type. The device distinction is currently completely based on the examination of the USB descriptors. During the last years, Prolific has introduced further PL2303 chips, such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA, RA, EA and TB variants. Unfortunately, all these new chips are currently detected as HX chips, because they are all using the same bMaxPacketSize0 = 0x40 value in the USB device descriptor. At this point it is not clear if these chips are really working with the driver, there are just some positive indicators (like device manufacturers claiming Linux support for these devices or commit 8d48fdf6 "correctly handle baudrates above 115200" which should only be necessary for newer devices, ...) For a complete support of all devices, we need to distinguish between them, because they differ in several functional aspects, such as the maximum supported baud rate (HXD, TB, EA: 12Mbps, HX, TA: 6Mbps, RA: 1Mbps, SA: 115.2kbps), handshaking line support, RS422/485 and GPIO ports support (currently not supported by the driver). And there might be further differences that we don't know yet. This patch improves the chip type detection by evaluating the bcdDevice value of the device descriptor. The values are taken from the datasheets and are safe to use because manufacturers can't change them: 3.00: X/HX, TA 4.00: HXD, EA, RA, SA 5.00: TB The rest of the device descriptors is completely identical, so no further distinction is possible this way. Anyway, Prolifics "checkChipVersion.exe"-tool is definitely able to distinguish for example between the X/HX and the TA chips, so there must be a possibility to improve the distinction further... Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Frank Schäfer authored
The chip type distinction is getting more and more relevant and complicating, so always print the chip type. Printing a name string is also much better than just printing an internal index number. Signed-off-by:
-
Frank Schäfer authored
There is no need for two else-if constructs for the type_1 chip detection in pl2303_startup(), so merge them. Signed-off-by:
-
- 13 Aug, 2013 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usbGreg Kroah-Hartman authored
Felipe writes: usb: patches for v3.12 merge window All patches here have been pending on linux-usb and sitting in linux-next for a while now. The biggest things in this tag are: DWC3 learned proper usage of threaded IRQ handlers and now we spend very little time in hardirq context. MUSB now has proper support for BeagleBone and Beaglebone Black. Tegra's USB support also got quite a bit of love and is learning to use PHY layer and generic DT attributes. Other than that, the usual pack of cleanups and non-critical fixes follow. Signed-of-by: -
Sebastian Andrzej Siewior authored
Stephen Rothwell reported that this driver does not compile on PowerPC due to this missing include. One could argue why this driver is enabled on PowerPC in the first place but it sure isn't wrong to include headers for used function instead of to rely that they sneak in. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. Signed-off-by:
-
Sebastian Andrzej Siewior authored
This patch makes use of the two function is_cppi_enabled() and tusb_dma_omap() instead of the ifdef for the proper DMA implementation setup code. It basically shifts the code right by one indention level and adds a few line breaks once the chars are crossed. Signed-off-by:
-
- 12 Aug, 2013 7 commits
-
-
Frank Schäfer authored
I've found some new datasheets which describe some additionally supported standard baud rates and I've verified them with my HX (rev. 3A) device. But adding support for individual (chip type specific) baud rates would add a good amount of extra code (especially when support for further chips will be added to the driver one day), which makes no sense as long as we are not using the direct baud rate encoding method for newer chips. So for now, just drop a comment about these additionally supported baud rates. The second comment is about the baud rate differences between the two encoding methods. In theory, we could optimize the code a bit by comparing the resulting baud rates of both methods and selecting the one which is closer to the requested baud rate. But that seems to be a bit overkill, because the differences are very small and the device likely uses the same baud rate generator for both methods so that the resulting baud rate would be the same. Signed-off-by:
-
Frank Schäfer authored
usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips Now that the divisor based baud rate encoding method has been fixed and extended, it can also be used for baud rates < 115200 baud with HX chips. This makes it possible to adjust the baud rate almost continuously instead of just beeing able to select between 16 fixed standard values. Tested with a PL2303HX 04463A (week 46, 2004, rev 3A). Signed-off-by:
-
Frank Schäfer authored
Reinhard Max has done some tests with a PL2303HX (rev A) and a logic analyzer and it seems, that although the PL2303HX is specified for baud rates from 75 to 6M baud, the full divisor range can be used with the divisor based baud rate encoding method. This corresponds to baud rates from 46 to 24M baud. Baud rates down to 46 baud (max. divisor) have been confirmed to work even under heavy/permanent load, so remove the lower limit. Baud rates up to 24M baud should really be tested carefully in "real life" scenarios before removing the upper limit completely. Anyway, the Windows driver allows maximum baud rates of 110% of the specified limit, so for now, increase the upper limit to this value. Signed-off-by:
Reinhard Max <max@suse.de> Signed-off-by:
-
Frank Schäfer authored
Signed-off-by:
-
Frank Schäfer authored
Commit 0c967e7e "USB: serial: pl2303 works at 500kbps" added 500000 baud to the list of supported standard baud rates. But the reason why the driver works with this baud rate is, that since commit 8d48fdf6 "USB: PL2303: correctly handle baudrates above 115200" a second (divisor based) baud rate encoding method is used for values above 115200 baud, which is not limited to a fixed set of standard baud rates. Remove the 500000 baud value from the list of standard baud rates again, because this list is only used with the direct baud rate encoding method and 500000 baud is not supported with this method. Signed-off-by:
-
Frank Schäfer authored
usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method In opposition to the direct baud rate encoding method, the divisor based method is not limited to a fixed set of standard baud rates. Hence, there is no need to round to the next nearest standard value. Reported-by:
Mastro Gippo <gipmad@gmail.com> Signed-off-by:
-
Frank Schäfer authored
Based on the formula in the code description, Reinhard Max and me have investigated the devices behavior / functional principle of the divisor based baud rate encoding method. It turned out, that (although beeing a good starting point) the current code has some flaws. It doesn't work correctly for a wide range of baud rates and the divisor resolution can be improved. It also doesn't report the actually set baud rate. This patch fixes and improves the code for the divisor based baud rate encoding method a lot. It can now be used for the whole range of baud rates from 46 baud to 24M baud with a very good divisor resolution and userspace can read back the resulting baud rate. It also documents the formula used for encoding and the hardware behavior (including special cases). The basic algorithm, rounding and several code comments/explanations are provided by Reinhard Max. I've added some minor fixes, the handling of the special cases and further code/algorithm descriptions. Signed-off-by:
-
