wangyanqing [Fri, 11 Mar 2011 14:24:38 +0000 (06:24 -0800)]
USB: serial: ch341: add new id
I picked up a new DAK-780EX(professional digitl reverb/mix system),
which use CH341T chipset to communication with computer on 3/2011
and the CH341T's vendor code is 1a86
Looking up the CH341T's vendor and product id's I see:
1a86 QinHeng Electronics
5523 CH341 in serial mode, usb to serial port converter
CH341T,CH341 are the products of the same company, maybe
have some common hardware, and I test the ch341.c works
well with CH341T
Paul Bolle [Fri, 11 Mar 2011 17:03:52 +0000 (18:03 +0100)]
USB: Only treat lasting over-current conditions as errors
On a laptop I see these errors on (most) resumes:
hub 3-0:1.0: over-current change on port 1
hub 3-0:1.0: over-current change on port 2
Since over-current conditions can disappear quite quickly it's better to
downgrade that message to debug level, recheck for an over-current
condition a little later and only print and over-current condition error
if that condition (still) exists when it's rechecked.
Add similar logic to hub over-current changes. (That code is untested,
as those changes do not occur on this laptop.)
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hubert Feurstein [Thu, 10 Mar 2011 09:06:37 +0000 (10:06 +0100)]
ehci-atmel: fix section mismatch warning
Fix the following section mismatch warning:
WARNING: drivers/usb/built-in.o(.data+0x74c): Section mismatch in reference from the variable ehci_atmel_driver to the function .init.text:ehci_atmel_drv_probe()
The variable ehci_atmel_driver references
the function __init ehci_atmel_drv_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626
On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/636091, one of
the cases reported is a big timeout on option_send_setup, which causes
some side effects as tty_lock is held. Looks like some of ZTE MF626
devices also don't like the RTS/DTR setting in option_send_setup, like
with 4G XS Stick W14. The reporter confirms which this it solves the
long freezes in his system.
Hao Wu [Wed, 9 Mar 2011 12:41:08 +0000 (12:41 +0000)]
USB OTG Langwell: use simple IPC command to control VBus power.
Direct access to PMIC register is not safe and will impact battery
charging. New IPC command supported in SCU FW for VBus power control.
USB OTG driver will switch to such commands instead of direct access
to PMIC register for safety and SCU FW will handle the actual work
after got the request(IPC command).
Due to this change, usb driver should wait more time for sync OTGSC
with USBCFG by SCU. Update wait time from 2ms to 5ms.
ARM: s3c24xx: Switch to common GPIO controlled UDC pullup implementation
Currently all boards using the s3c2410_udc driver use a GPIO to control the
state of the pullup, as a result the same code is reimplemented in each board
This patch changes these boards to use the common implementation for GPIO
controlled pullup in the UDC driver.
USB: s3c2410_udc: Add common implementation for GPIO controlled pullups
Currently all boards using the s3c2410_udc driver use a GPIO to control the
state of the pullup, as a result the same code is reimplemented in each board
file.
This patch adds support for using a GPIO to control the pullup state to the udc
driver, so the boards can use a common implementation.
Anand Gadiyar [Wed, 16 Feb 2011 11:17:19 +0000 (16:47 +0530)]
arm: omap4: 4430sdp: drop ehci support
Most revisions of the OMAP4 Blaze/SDP platform do not have
the EHCI signals routed by default. The pads are routed
for the alternate HSI functionality instead, and explicit
board modifications are needed to route the signals to
the USB PHY on the board.
Also, turning on the PHY connected to the EHCI port causes
a board reboot during bootup due to an unintended short
on the rails - this affects many initial revisions of the
board, and needs a minor board mod to fix (or as a
workaround, one should not attempt to power on the
USB PHY).
Given that these boards need explicit board mods to even
get EHCI working (separate from the accidental short above),
we should not attempt to enable EHCI by default.
So drop the EHCI support from the board files for the
Blaze/SDP platforms.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergei Shtylyov [Thu, 3 Mar 2011 18:10:05 +0000 (21:10 +0300)]
USB: OHCI: use pci_dev->revision
Commit ab1666c1364a209e6141d7c14e47a42b5f00eca2 (USB: quirk PLL power down mode)
added code that reads the revision ID from the PCI configuration register while
it's stored by PCI subsystem in the 'revision' field of 'struct pci_dev'...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Arvid Brodin [Mon, 7 Mar 2011 14:36:21 +0000 (15:36 +0100)]
usb/isp1760: Fix crash when unplugging bug
This fixes a problem with my previous patch series where there's a great
risk that the kernel will crash when unplugging interrupt devices from
the USB port. These lines must have got missing when I rebased the
patches from the older kernel I was working with to 2.6.37 and 2.6-next:
This fixes a bug where the kernel may crash if you unplug a USB device
that has active interrupt transfers.
Alan Stern [Mon, 7 Mar 2011 16:11:52 +0000 (11:11 -0500)]
USB: move usbcore away from hcd->state
The hcd->state variable is a disaster. It's not clearly owned by
either usbcore or the host controller drivers, and they both change it
from time to time, potentially stepping on each other's toes. It's
not protected by any locks. And there's no mechanism to prevent it
from going through an invalid transition.
This patch (as1451) takes a first step toward fixing these problems.
As it turns out, usbcore uses hcd->state for essentially only two
things: checking whether the controller's root hub is running and
checking whether the controller has died. Therefore the patch adds
two new atomic bitflags to the hcd structure, to store these pieces of
information. The new flags are used only by usbcore, and a private
spinlock prevents invalid combinations (a dead controller's root hub
cannot be running).
The patch does not change the places where usbcore sets hcd->state,
since HCDs may depend on them. Furthermore, there is one place in
usb_hcd_irq() where usbcore still must use hcd->state: An HCD's
interrupt handler can implicitly indicate that the controller died by
setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a
big improvement over the current code.
The patch makes one other change. The hcd_bus_suspend() and
hcd_bus_resume() routines now check first whether the host controller
has died; if it has then they return immediately without calling the
HCD's bus_suspend or bus_resume methods.
This fixes the major problem reported in Bugzilla #29902: The system
fails to suspend after a host controller dies during system resume.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alex Terekhov <a.terekhov@gmail.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Akinobu Mita [Wed, 2 Mar 2011 11:35:28 +0000 (20:35 +0900)]
wusb: fix find_first_zero_bit() return value check
In wusb_cluster_id_get(), if no zero bits exist in wusb_cluster_id_table,
find_first_zero_bit() returns CLUSTER_IDS.
But it is impossible to detect that the bitmap is full because there
is an off-by-one error in the return value check. It will cause
unexpected memory access by setting bit out of wusb_cluster_id_table
bitmap, and caller will get wrong cluster id.
usb: EHCI, OHCI: Add configuration for the SH USB controller
The SH EHCI/OHCI driver hardcoded the CPU type in {ehci,ohci}-hcd.c.
So if we will add the new CPU, we had to add to the hcd driver each time.
The patch adds the CONFIG_USB_{EHCI,OHCI}_SH configuration. So if we
want to use the SH EHCI/OHCI, we only enable the configuration.
Andiry Xu [Tue, 1 Mar 2011 06:57:05 +0000 (14:57 +0800)]
USB host: Move AMD PLL quirk to pci-quirks.c
This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.
AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:
1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
in low power state is enabled.
Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.
Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:
1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
make them cleaner;
2. AMD chipset information will be probed only once and then stored.
Currently they're probed during every OHCI/EHCI initialization, move
the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
code, every host controller enable/disable PLL only according to
its own status, and may enable PLL while there is still isoc transfer on
other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: Andiry Xu <andiry.xu@amd.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alex He <alex.he@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The devices of clocks are set to usbhs, so that
only usbhs common driver can invoke these clocks.
The dummy per port clocks are added to omap3
clock data base. This helps to invoke common
clock get APIs for omap3 and omap4.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
The ehci and ohci drivers are simplified; Since
UHH and TLL initialization, clock handling are
done by common usbhs core driver, these functionalities
are removed from ehci and ohci drivers.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
arm: omap: usb: cleanup ehci and ohci resources and devices
The prototype and defination of functions usb_ehci_init and
usb_ohci_init are removed. The ehci and ohci devices are
removed since usbhs device contains both ehci and ohci details.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
A new usbhs platform device is defined;
this device will be the parent device of ehci and
ohci platform devices. the usbhs_init function
is defined which does the usbhs device initialization
and I/O mux of ehci and ohci.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
enabling and disabling the common clocks for ehci
and ohci is implemented. usbhs is a common parent
platform driver for EHCI and OHCI driver. This driver
receives the clock enable and disable requests
from ehci and ohci drivers.The UHH and TLL
initialization is also performed.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Tue, 1 Mar 2011 14:38:15 +0000 (20:08 +0530)]
arm: omap2: usb: rename usb-ehci.c to usb-host.c
We already have both EHCI and OHCI there, so let's
rename to be sure everybody will understand the entire
USB HOST functionality is setup on this file.
Felipe Balbi [Tue, 1 Mar 2011 14:38:14 +0000 (20:08 +0530)]
usb: host: omap: switch to platform_get_resource_byname
now that we have names on all memory bases, we can
switch to use platform_get_resource_byname() which
will make it simpler when we move to a setup where
OHCI and EHCI on OMAP play well together.
Anand Gadiyar [Wed, 16 Feb 2011 10:13:14 +0000 (15:43 +0530)]
usb: ehci: omap: add support for TLL mode on OMAP4
The EHCI controller in OMAP4 supports a transceiver-less link
mode (TLL mode), similar to the one in OMAP3. On the OMAP4
however, there are an additional set of clocks that need
to be turned on to get this working.
Request and configure these for each port if that port
is connected in TLL mode.
In OMAP3xxx with OTG mode or host only mode, When the device
is inserted after the gadget driver loading the enumeration was not
through. This is because the mentor controller will start sensing the
ID PIN only after setting the session bit.
So after ID-GND, need to set the session bit for mentor to get it
configured as A device.
This is a fix to set the session bit again in ID_GND notification handler.
Tested with OMAP3630Zoom3 platform.
Signed-off-by: Hema HK <hemahk@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Mon, 28 Feb 2011 08:49:35 +0000 (14:19 +0530)]
usb: musb: OMAP4430: Power down the PHY during board init
Powerdown the internal PHY during board init for OMAP44xx.
So that when musb is disabled core transition to retention/off
is not blocked.
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Mon, 28 Feb 2011 08:49:36 +0000 (14:19 +0530)]
usb: otg: OMAP4430: Save/restore the context
Add the context save/restore for the control module register
used for OMAP4430 musb with UTMI embedded PHY interface.
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Mon, 28 Feb 2011 08:49:34 +0000 (14:19 +0530)]
usb: musb: Idle path retention and offmode support for OMAP3
This patch supports the retention and offmode support in the idle path for
musb driver using runtime pm APIs.
This is restricted to support offmode and retention only when device not
connected.When device/cable connected with gadget driver loaded,configured
to no idle/standby which will not allow the core transition to retention
or off.
There is no context save/restore done by hardware for musb in OMAP3
and OMAP4,driver has to take care of saving and restoring the context
during offmode.
Musb has a requirement of configuring sysconfig register to force
idle/standby mode and set the ENFORCE bit in module STANDBY register
for retention and offmode support.
Runtime pm and hwmod frameworks will take care of configuring to force
idle/standby when pm_runtime_put_sync is called and back to no
idle/standby when pm_runeime_get_sync is called.
Compile, boot tested and also tested the retention in the idle path on
OMAP3630Zoom3. And tested the global suspend/resume with offmode enabled.
Usb basic functionality tested on OMAP4430SDP.
There is some problem with idle path offmode in mainline, I could not test
with offmode. But I have tested this patch with resetting the controller
in the idle path when wakeup from retention just to make sure that the
context is lost, and restore path is working fine.
Removed .suspend/.resume fnction pointers and functions because there
is no need of having these functions as all required work is done
at runtime in the driver.
There is no need to call the runtime pm api with glue driver device
as glue layer device is the parent of musb core device, when runtime apis
are called for the child, parent device runtime functionality
will be invoked.
Design overview:
pm_runtime_get_sync: When called with musb core device takes care of
enabling the clock, calling runtime callback function of omap2430 glue
layer, runtime call back of musb driver and configure the musb sysconfig
to no idle/standby
pm_runtime_put: Takes care of calling runtime callback function of omap2430
glue layer, runtime call back of musb driver, Configure the musb sysconfig
to force idle/standby and disable the clock.
During musb driver load: Call pm_runtime_get_sync.
End of musb driver load: Call pm_runtime_put
During gadget driver load: Call pm_runtime_get_sync,
End of gadget driver load: Call pm_runtime_put if there is no device
or cable is connected.
During unload of the gadget driver:Call pm_runtime_get_sync if cable/device
is not connected.
End of the gadget driver unload : pm_runtime_put
During unload of musb driver : Call pm_runtime_get_sync
End of unload: Call pm_runtime_put
On connect of usb cable/device -> transceiver notification(VBUS and ID-GND):
pm_runtime_get_sync only if the gadget driver loaded.
On disconnect of the cable/device -> Disconnect Notification:
pm_runtime_put if the gadget driver is loaded.
Signed-off-by: Hema HK <hemahk@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Mon, 28 Feb 2011 08:49:33 +0000 (14:19 +0530)]
usb: musb: Remove platform context save/restore API
For OMAP3 and OMAP4 for offmode and retention support, musb
sysconfig is configured to force idle and standby with ENABLE_FORCE bit
of OTG_FORCESTNDBY set.
And on wakeup configure to no ilde/standby with resetting the ENABLE_FORCE
bit. There is not need to save and restore of this register anymore
so removed omap2430_save_context/omap2430_restore_context functions.
and also removed otg_forcestandby member of musb_context_registers
structure
Signed-off-by: Hema HK <hemahk@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Mon, 28 Feb 2011 08:44:50 +0000 (10:44 +0200)]
usb: musb: gadget: fix list_head usage
commit ad1adb89a0d9410345d573b6995a1fa9f9b7c74a
(usb: musb: gadget: do not poke with gadget's list_head)
fixed a bug in musb where it was corrupting the list_head
which is supposed to be used by gadget drivers. While
doing that, I forgot to fix the usage in musb_gadget_dequeue()
method. Fix that.
Reported-by: Pavol Kurina <pavol.kurina@emsys.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
Davidlohr Bueso [Sun, 27 Feb 2011 07:58:48 +0000 (04:58 -0300)]
USB: ffs-test: fix header path
When compiling this program the functionfs.h header cannot be found, producing:
ffs-test.c:40: fatal error: linux/usb/functionfs.h: No such file or directory
This patch also fixes the following warning:
ffs-test.c:453: warning: format ‘%4d’ expects type ‘int’, but argument 3 has type ‘size_t’
Arvid Brodin [Sat, 26 Feb 2011 21:07:35 +0000 (22:07 +0100)]
usb/isp1760: Replace period calculation for INT packets with something readable
Replace the period calculation for INT packets with something readable. Seems
to fix a rare bug with quickly repeated insertion/removal of several USB
devices simultaneously (hub control INT packets).
Arvid Brodin [Sat, 26 Feb 2011 21:06:37 +0000 (22:06 +0100)]
usb/isp1760: Consolidate printouts and remove unused code
Consolidate printouts to use dev_XXX functions instead of an assortment of
printks and driver specific macros. Remove some unused code snippets and struct
members. Remove some unused function parameters and #defines. Change the
"queue_entry" variable name which has different but related meanings in
different places and use "slot" only.
Arvid Brodin [Sat, 26 Feb 2011 21:03:49 +0000 (22:03 +0100)]
usb/isp1760: Remove redundant variables and defines
Removes the redundant hw_next list pointer from struct isp1760_qtd, removes some
unused #defines, removes redundant "urb" member from struct inter_packet_info.
Arvid Brodin [Sat, 26 Feb 2011 21:02:57 +0000 (22:02 +0100)]
usb/isp1760: Move to native-endian ptds
This helps users with platform-bus-connected isp176xs, big-endian cpu,
and missing byteswapping on the data bus. It does so by collecting all
SW byteswaps in one place and also fixes a bug with non-32-bit io
transfers on this hardware, where payload has to be byteswapped
instead of ptds.
Alan Stern [Wed, 23 Feb 2011 20:28:18 +0000 (15:28 -0500)]
USB: serial drivers need to use larger bulk-in buffers
When a driver doesn't know how much data a device is going to send,
the buffer size should be at least as big as the endpoint's maxpacket
value. The serial drivers don't follow this rule; many of them
request only 256-byte bulk-in buffers. As a result, they suffer
overflow errors if a high-speed device wants to send a lot of data,
because high-speed bulk endpoints are required to have a maxpacket
size of 512.
This patch (as1450) fixes the problem by using the driver's
bulk_in_size value as a minimum, always allocating buffers no smaller
than the endpoint's maxpacket size.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Flynn Marquardt <flynn@flynnux.de> CC: <stable@kernel.org> [after .39-rc1 is out] Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Maulik Mankad [Tue, 22 Feb 2011 13:38:42 +0000 (19:08 +0530)]
usb: gadget: composite: fix req->length in composite_setup()
When USB CV MSC tests are run on f_mass_storage gadget
Bulk Only Mass Storage Reset fails since req->length
is set to USB_BUFSIZ=1024 in composite_setup().
Initialize req->length to zero to fix this.
Signed-off-by: Maulik Mankad <maulik@ti.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Tue, 22 Feb 2011 14:53:41 +0000 (09:53 -0500)]
USB: use "device number" instead of "address"
The USB stack historically has conflated device numbers (i.e., the
value of udev->devnum) with device addresses. This is understandable,
because until recently the two values were always the same.
But with USB-3.0 they aren't the same, so we should start calling
these things by their correct names. This patch (as1449b) changes many
of the references to "address" in the hub driver to "device number"
or "devnum".
The patch also removes some unnecessary or misleading comments.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Luben Tuikov <ltuikov@yahoo.com> Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/usb/host/ehci-dbg.c:45: warning: 'dbg_hcs_params' defined but not used
drivers/usb/host/ehci-dbg.c:89: warning: 'dbg_hcc_params' defined but not used
USB: gadget: Add test mode support for ci13xxx_udc
Implement the test modes mentioned in 7.1.20 section of USB 2.0
specification. High-speed capable devices must support these test
modes to facilitate compliance testing.
USB: gadget: Implement remote wakeup in ci13xxx_udc
This patch adds support for remote wakeup. The following things
are handled:
- Process SET_FEATURE/CLEAR_FEATURE control requests sent by host
for enabling/disabling remote wakeup feature.
- Report remote wakeup enable status in response to GET_STATUS
control request.
- Implement wakeup method defined in usb_gadget_ops for initiating
remote wakeup.
- Notify gadget driver about suspend and resume.
USB: gadget: Implement hardware queuing in ci13xxx_udc
Chipidea USB controller provides a means (Add dTD TripWire semaphore)
for safely adding a new dTD to an active endpoint's linked list. Make
use of this feature to improve performance. Dynamically allocate and
free dTD for supporting zero length packet termination. Honor
no_interrupt flag set by gadget drivers.
Matthew Garrett [Tue, 11 Jan 2011 17:26:48 +0000 (12:26 -0500)]
ehci: Check individual port status registers on resume
If a device plug/unplug is detected on an ATI SB700 USB controller in D3,
it appears to set the port status register but not the controller status
register. As a result we'll fail to detect the plug event. Check the port
status register on resume as well in order to catch this case.
Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: stable <stable@kernel.org> [after .39-rc1 is out] Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergei Shtylyov [Fri, 18 Feb 2011 20:44:32 +0000 (23:44 +0300)]
usb: musb: gadget: DBG() already prints function name
In the gadget code, there are several DBG() macro invocations that explicitly
print the calling function's name while DBG() macro itself does this anyway;
most of these were added by commit f11d893de444965dfd3e55f726533ae1df5c6471
(usb: musb: support ISO high bandwidth for gadget mode). Remove the duplicated
printing, somewhat clarifying the messages at the same time...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Thu, 17 Feb 2011 06:36:10 +0000 (12:06 +0530)]
usb: musb: OMAP4430: Fix usb device detection if connected during boot
OMAP4430 is embedded with UTMI PHY. This PHY does not support the
OTG features like ID pin detection and VBUS detection. This function
is exported to an external companion chip TWL6030. Software must retrieve
the OTG HNP and SRP status from the TWL6030 and configure the bits inside
the control module that drive the related USBOTGHS UTMI interface signals.
It must also read back the UTMI signals needed to configure the TWL6030
OTG module.
Can find more details in the TRM[1].
[1]:http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.0_Public_TRM_vJ.pdf
In OMAP4430 musb driver VBUS and ID notifications are received from the
transceiver driver. If the cable/device is connected during boot,
notifications from transceiver driver will be missed till musb driver
is loaded.
Patch to configure the transceiver in the platform_enable/disable
functions and enable the vbus in the gadget driver based on the
last_event of the otg_transceiver.
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Thu, 17 Feb 2011 06:36:09 +0000 (12:06 +0530)]
usb: otg: TWL6030 Save the last event in otg_transceiver
Save the last event in the otg_transceiver so that it can used in the
musb driver and gadget driver to configure the musb and enable the
vbus for host mode and OTG mode, if the device is connected during boot.
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Thu, 17 Feb 2011 06:36:08 +0000 (12:06 +0530)]
usb: otg: TWL6030: Introduce the twl6030_phy_suspend function.
Introduce the twl6030_phy_suspend function and assign to otg.set_suspend
function pointer.
This function is used by the musb-omap2430 platform driver
during suspend/resume.
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Thu, 17 Feb 2011 06:36:07 +0000 (12:06 +0530)]
usb: otg: OMAP4430: Introducing suspend function for power management
Introduced the suspend/resume function for the OMAP4430 internal PHY.
This will be used by the twl6030-usb transceiver driver.
Moved the clock enable/disable function calls and power on/off of the PHY
code from power on/off functions to suspend/resume function.
Pass the suspend function through board data for OMAP4430sdp and OMAP4panda.
This will be used by the twl6030-usb transceiver driver.
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Thu, 17 Feb 2011 06:36:06 +0000 (12:06 +0530)]
usb: otg: OMAP4430: Add phy_suspend function pointer to twl4030_usb_data
Declare the .phy_suspend function pointer to twl4030_usb_data structure.
OMAP internal phy suspend function will be hooked though this function
pointer to use in the transceiver driver.
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Thu, 17 Feb 2011 06:36:05 +0000 (12:06 +0530)]
usb: otg: Remove one unnecessary I2C read request.
To get the ID status there was an I2C read transfer. Removed this I2C
read transfer as this info can be used from existing variable(linkstat).
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Thu, 17 Feb 2011 06:36:04 +0000 (12:06 +0530)]
usb: otg: enable regulator only on cable/device connect
Remove the regulator enable while driver loading and enable it only when
the cable/device is connected and disable it when disconnected.
Remove the configuration of config_state and config_trans register
configuration as these registers are programmed when regulator
enable/disable is called.
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Hema HK [Thu, 17 Feb 2011 06:37:22 +0000 (12:07 +0530)]
usb: musb: Using runtime pm APIs for musb.
Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings.
Enable clock, configure no-idle/standby when active and configure force idle/standby
and disable clock when idled. This is taken care by the runtime framework when
driver calls the pm_runtime_get_sync and pm_runtime_put_sync APIs.
Need to configure MUSB into force standby and force idle mode when usb not used
Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe Balbi [Wed, 16 Feb 2011 10:40:05 +0000 (12:40 +0200)]
usb: musb: gadget: do not poke with gadget's list_head
struct usb_request's list_head is supposed to be
used only by gadget drivers, but musb is abusing
that. Give struct musb_request its own list_head
and prevent musb from poking into other driver's
business.
Just a few cosmetic fixes to usb_gadget_probe_driver()
and usb_gadget_unregister_driver().
Decreased a few indentation levels with goto statements.
While at that, also add the missing call to musb_stop().
If we don't have OTG, there's no point of leaving
MUSB prepared for operation if a gadget driver fails
to probe. The same is valid for usb_gadget_unregister_driver(),
since we are removing the gadget driver and we don't have
OTG, we can completely unconfigure MUSB.
Oliver Neukum [Thu, 10 Feb 2011 14:33:37 +0000 (15:33 +0100)]
usb_wwan: fix error case in close()
The device never needs to be resumed in close(). But the counters
must be balanced. As resumption can fail, but the counters must
be balanced, use the _no_resume() version which cannot fail.
Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Oliver Neukum [Thu, 10 Feb 2011 14:33:10 +0000 (15:33 +0100)]
usb_wwan: fix error in marking device busy
This fixes two errors:
- the device is busy if a message was recieved even if resubmission fails
- the device is not busy if resubmission fails due to -EPERM
Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The document says:
|2.1 Problem description
| When at least two USB devices are simultaneously running, it is observed that
| sometimes the INT corresponding to one of the USB devices stops occurring. This may
| be observed sometimes with USB-to-serial or USB-to-network devices.
| The problem is not noticed when only USB mass storage devices are running.
|2.2 Implication
| This issue is because of the clearing of the respective Done Map bit on reading the ATL
| PTD Done Map register when an INT is generated by another PTD completion, but is not
| found set on that read access. In this situation, the respective Done Map bit will remain
| reset and no further INT will be asserted so the data transfer corresponding to that USB
| device will stop.
|2.3 Workaround
| An SOF INT can be used instead of an ATL INT with polling on Done bits. A time-out can
| be implemented and if a certain Done bit is never set, verification of the PTD completion
| can be done by reading PTD contents (valid bit).
| This is a proven workaround implemented in software.
Russell King run into this with an USB-to-serial converter. This patch
implements his suggestion to enable the high frequent SOF interrupt only
at the time we have ATL packages queued. It goes even one step further
and enables the SOF interrupt only if we have more than one ATL packet
queued at the same time.
Cc: <stable@kernel.org> # [2.6.35.x, 2.6.36.x, 2.6.37.x] Tested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: s3c2410_udc: Add handling for S3C244X dual-packet mode
This is a patch that seems to make the USB hangs on the S3C244X go away.
At least a good amount of ping torture didn't make them come back so far.
The issue is that, if there are several back-to-back packets, sometimes no
interrupt is generated for one of them. This seems to be caused by the
mysterious dual packet mode, which the USB hardware enters automatically
if the endpoint size is half that of the FIFO. (On the 244X, this is the
normal situation for bulk data endpoints.)
There is also a timing factor in this. It seems that what happens is that
the USB hardware automatically sends an acknowledgement if there is only one
packet in the FIFO (the FIFO has space for two). If another packet arrives
before the host has retrieved and acknowledged the previous one, no interrupt
is generated for that second one.
However, there may be an indication. There is one undocumented bit (none
of the 244x manuals document it), OUT_CRS1_REG[1], that seems to be set
suspiciously often when this condition occurs. There is also
CLR_DATA_TOGGLE, OUT_CRS1_REG[7], which may have a function related to
this. (The Samsung manual is rather terse on that, as usual.)
This needs to be examined further. For now, the patch seems to do the
trick.
projects / linux-beck.git / log