Re: [RFC 5/7] xhci: Export Latency Tolerance Messaging capabilities.
On 07/06/2012 10:11 AM, Sarah Sharp wrote: Some xHCI host controllers may have optional support for Latency Tolerance Messaging (LTM). This allows USB 3.0 devices that support LTM to pass information about how much latency they can tolerate to the xHC. A PCI xHCI host will use this information to update the PCI Latency Tolerance Request (LTR) info. The goal of this is to gather latency information for the system, to enable hardware-driven C states, and the shutting down of PLLs. Signed-off-by: Sarah Sharpsarah.a.sh...@linux.intel.com This looks OK to me. Thanks, Andiry --- drivers/usb/host/xhci-hub.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 2732ef6..6d21030 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -508,12 +508,18 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, if (hcd-speed != HCD_USB3) goto error; + /* Set the U1 and U2 exit latencies. */ memcpy(buf,usb_bos_descriptor, USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE); temp = xhci_readl(xhci,xhci-cap_regs-hcs_params3); buf[12] = HCS_U1_LATENCY(temp); put_unaligned_le16(HCS_U2_LATENCY(temp),buf[13]); + /* Indicate whether the host has LTM support. */ + temp = xhci_readl(xhci,xhci-cap_regs-hcc_params); + if (HCC_LTC(temp)) + buf[8] |= USB_LTM_SUPPORT; + spin_unlock_irqrestore(xhci-lock, flags); return USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE; case GetPortStatus: -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] usb: phy: patches for v3.6
Hi Greg, On Fri, Jul 6, 2012 at 4:05 AM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jul 02, 2012 at 11:26:39AM +0300, Felipe Balbi wrote: On Mon, Jul 02, 2012 at 11:22:00AM +0300, Felipe Balbi wrote: Hi Greg, here are the patches I queued for transceiver drivers. Let me know if you want me to change anything. this will conflict with your usb-next branch, here's the resolution patch: Thanks for this, that helped out a lot. I also got a conflict in drivers/usb/otg/twl6030-usb.c, which I think I resolved properly, but it would be great if you could verify it. There is a mistake in the conflict resolution in file twl6030-usb.c + otg-default_a = true; + twl-phy.state = OTG_STATE_A_IDLE; The above two lines shouldn't be there. I can send a patch for fixing this if needed. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers: usb: otg: fix build break in twl6030-usb.c
Fixed a mistake in the merge conflict resoultion commit(ff9cce) in file
twl6030-usb.c
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl6030-usb.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index a3d0c04..6907d8d 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -302,8 +302,6 @@ static irqreturn_t twl6030_usbotg_irq(int irq, void *_twl)
twl6030_writeb(twl, TWL_MODULE_USB, 0x1, USB_ID_INT_EN_HI_CLR);
twl6030_writeb(twl, TWL_MODULE_USB, 0x10, USB_ID_INT_EN_HI_SET);
status = OMAP_MUSB_ID_GROUND;
- otg-default_a = true;
- twl-phy.state = OTG_STATE_A_IDLE;
twl-linkstat = status;
omap_musb_mailbox(status);
} else {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: infos about device ZTE MF821D 2G,3G,4G/LTE usb-modem/networkcard
Am Sonntag, 8. Juli 2012, 13:32:42 schrieb Thomas Schäfer: Not for kernel-code, but usefull for testers/users: udev-rules/usb_modeswitch /lib/udev/rules.d/40-usb_modeswitch.rules Thank you! Could you also post lsusb -v for the card? Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/1] usb: phy: move usb_otg_state from struct usb_phy to struct usb_otg
Since we will have a standalone USB PHY layer, the first step is
to move some non-PHY related things out of struct usb_phy.
It has lots of things need to do, this one is just the beginning.
The enum usb_otg_state should be not relationship with USB PHY, so
move it out.
A formal patch should include the modification for related drivers,
I send this RFC is just want to know if everyone agrees to this change,
If there is no disagreement, I will send out a formal patch later.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
include/linux/usb/otg.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 0cb2ec2..f077cb3 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -67,6 +67,8 @@ struct usb_otg {
struct usb_bus *host;
struct usb_gadget *gadget;
+ enum usb_otg_state state;
+
/* bind/unbind the host controller */
int (*set_host)(struct usb_otg *otg, struct usb_bus *host);
@@ -97,7 +99,6 @@ struct usb_phy {
unsigned int flags;
enum usb_phy_type type;
- enum usb_otg_state state;
enum usb_phy_events last_event;
struct usb_otg *otg;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Infinite looping in omap2430.c USB driver
* NeilBrown ne...@suse.de [120706 15:44]:
Hello `./scripts/get_maintainer.pl -f drivers/usb/musb/omap2430.c`
omap2430_musb_set_vbus in omap2430.c contains:
while (musb_readb(musb-mregs, MUSB_DEVCTL) 0x80) {
cpu_relax();
if (time_after(jiffies, timeout)) {
dev_err(musb-controller,
configured as A device timeout);
ret = -EINVAL;
break;
}
}
having set
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
so it can busy-loop for up to 1 second. Probably not ideal, but if it works
I wouldn't complain.
The
if (int_usb MUSB_INTR_SESSREQ) {
branch of musb_stage0_irq() called from musb_interrupt (from
generic_interrupt) calls this:
if (musb-int_usb)
retval |= musb_stage0_irq(musb, musb-int_usb,
devctl, power);
so the busy loop can happen in an interrupt handler (not a threaded interrupt
handler), which is probably less ideal.
However this can be called with interrupt disabled, as happens at least
during resume when resume_irqs() calls:
raw_spin_lock_irqsave(desc-lock, flags);
__enable_irq(desc, irq, true);
raw_spin_unlock_irqrestore(desc-lock, flags);
and an interrupt is found to be IRQS_PENDING.
In this case interrupts are disabled so 'jiffies' never changes so this loop
can continue forever.
This happens on my (GTA04) phone fairly regularly - between 1 in 10 and 1 in
30 resumes. The musb-hdrc interrupt is pending and reports
[ 4957.624176] musb-hdrc musb-hdrc: ** IRQ peripheral usb0040 tx rx
'usb0040' is MUSB_INTR_SESSREQ. I think this is triggered by detecting a
voltage change on the USB ID pin - is that right? A short-to-earth would be
a request to switch to host mode, which is why it tries to enable VBUS.
Maybe there is some electrical noise which is being picked up?
I guess that could happen if the transceiver pins are floating during suspend?
In any case I get the interrupt despite nothing being plugged in, and the 0x80
bit of MUSB_DEVCTL never gets cleared.
As far as I remember, musb tries to be smart about changing to host mode,
and tries to do the session and vbus detection on it's own.. AFAIK, there's
nothing you can do until musb is done and detects the VBUS is not rising and
gives up. There are all kind of interrupt flag combinations trying to deal
with that mess, maybe you need to add yet another one?
I've added a simple loop counter which aborts the loop after 1000 loops -
this takes about 5 seconds, but includes some printks which probably slow it
down.
In 2 out of 2 cases, subsequent messages show that the hsmmc driver for the
uSD card that holds my root filesystem is messed up. It seems to be waiting
for a request that is never going to complete.
So maybe the hsmmc is causing the noise that triggers the musb issue.
I can send a patch which add a loop count if you like, but I suspect you can
come up with a much better approach.
Sounds like that loop should be fixed.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: host: Fix possible kernel crash
In functions itd_complete sitd_complete, a pointer
by name stream may get dereferenced after freeing it, when
iso_stream_put is called with stream-refcount = 2.
Hence fixing it.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
In Patchset 1, modified parameter of iso_stream_put() to handle the crash.
However the crash can be handled without modifying the function
parameter, by just adding a local variable in the functions that call
iso_stream_put(). Hence implemented it in the current patch.
drivers/usb/host/ehci-sched.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 33182c6..20d0c38 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1715,6 +1715,7 @@ itd_complete (
struct ehci_iso_stream *stream = itd-stream;
struct usb_device *dev;
unsignedretval = false;
+ u32 stream_ref_count = 0;
/* for each uframe with a packet */
for (uframe = 0; uframe 8; uframe++) {
@@ -1783,7 +1784,8 @@ itd_complete (
dev-devpath, stream-bEndpointAddress 0x0f,
(stream-bEndpointAddress USB_DIR_IN) ? in : out);
}
- iso_stream_put (ehci, stream);
+ stream_ref_count = stream-refcount;
+ iso_stream_put(ehci, stream);
done:
itd-urb = NULL;
@@ -1797,7 +1799,7 @@ done:
* Move it to a safe place until a new frame starts.
*/
list_move(itd-itd_list, ehci-cached_itd_list);
- if (stream-refcount == 2) {
+ if (stream_ref_count == 3) {
/* If iso_stream_put() were called here, stream
* would be freed. Instead, just prevent reuse.
*/
@@ -1866,7 +1868,7 @@ done_not_linked:
done:
if (unlikely (status 0))
- iso_stream_put (ehci, stream);
+ iso_stream_put(ehci, stream);
return status;
}
@@ -2127,6 +2129,7 @@ sitd_complete (
struct ehci_iso_stream *stream = sitd-stream;
struct usb_device *dev;
unsignedretval = false;
+ u32 stream_ref_count = 0;
urb_index = sitd-index;
desc = urb-iso_frame_desc [urb_index];
@@ -2179,7 +2182,8 @@ sitd_complete (
dev-devpath, stream-bEndpointAddress 0x0f,
(stream-bEndpointAddress USB_DIR_IN) ? in : out);
}
- iso_stream_put (ehci, stream);
+ stream_ref_count = stream-refcount;
+ iso_stream_put(ehci, stream);
done:
sitd-urb = NULL;
@@ -2193,7 +2197,7 @@ done:
* Move it to a safe place until a new frame starts.
*/
list_move(sitd-sitd_list, ehci-cached_sitd_list);
- if (stream-refcount == 2) {
+ if (stream_ref_count == 3) {
/* If iso_stream_put() were called here, stream
* would be freed. Instead, just prevent reuse.
*/
@@ -2259,7 +2263,7 @@ done_not_linked:
done:
if (status 0)
- iso_stream_put (ehci, stream);
+ iso_stream_put(ehci, stream);
return status;
}
--
1.7.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 2/9] usb: make usb port a real device
On Sun, Jul 08, 2012 at 09:28:35AM -0700, Greg KH wrote: On Sat, Jul 07, 2012 at 08:05:47PM -0400, Sarah Sharp wrote: On Fri, Jul 06, 2012 at 11:12:32AM -0700, Greg KH wrote: On Fri, Jul 06, 2012 at 02:13:53PM +0800, Lan Tianyu wrote: Don't split strings across a line, it makes it impossible to search for. Do you prefer 80 char lines or split strings? checkpatch.pl throws an error either way, so pick your poison. checkpatch should not throw an error if you have a string which forces the line to be longer than 80 characters. If it does, it is wrong and should be fixed. It does. I've tried to send checkpatch fixes in the past (including making any warning not make the script return an error so you can have it in your pre-commit hook) and gotten no response. At this point I'm not really sure who to send patches to. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb sound issue - any ideas?
On Mon, Jul 09, 2012 at 02:07:42PM +0800, Andiry Xu wrote:
On 07/08/2012 08:50 PM, Dr. Ing. Dieter Jurzitza wrote:
Dear listmembers,
recently I switched to a new pc, making use of an external USB sound device.
The problem: when I log off a kde-session and log in again, the sound device
vanishes. Issuing dmesg, I see:
[747766.894681] systemd-logind[22155]: New session 1337 of user hoss.
[747767.130779] checkproc[31777]: checkproc: can not get session id for
process 30437!
[747767.172502] nas[31781]: Network Audio System Release 1.9.2
[747768.192940] dbus-daemon[22185]: no kernel backlight interface found
[747768.967589] dbus-daemon[22185]: dbus[22185]: [system] Activating via
systemd: service name='org.freedesktop.NetworkManager' unit='dbus-
org.freedesktop.NetworkManager.service'
[747768.967791] dbus[22185]: [system] Activation via systemd failed for unit
'dbus-org.freedesktop.NetworkManager.service': Unit dbus-
org.freedesktop.NetworkManager.service failed to load: No such file or
directory. See system logs and 'systemctl status dbus-
org.freedesktop.NetworkManager.service' for details.
[747768.967812] dbus-daemon[22185]: dbus[22185]: [system] Activation via
systemd failed for unit 'dbus-org.freedesktop.NetworkManager.service': Unit
dbus-org.freedesktop.NetworkManager.service failed to load: No such file or
directory. See system logs and 'systemctl status dbus-
org.freedesktop.NetworkManager.service' for details.
[747773.392964] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with
disabled ep 8803cf791240
[747773.392966] xhci_hcd :00:14.0: Trying to add endpoint 0x3 without
dropping it.
[747773.392969] usb 3-4: Not enough bandwidth for altsetting 1
[747773.392971] ALSA pcm.c:250 9:3:1: usb_set_interface failed
[747773.394882] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with
disabled ep 8803cf791240
[747773.394885] xhci_hcd :00:14.0: Trying to add endpoint 0x3 without
dropping it.
[747773.394887] usb 3-4: Not enough bandwidth for altsetting 1
[747773.394889] ALSA pcm.c:250 9:3:1: usb_set_interface failed
[747773.419558] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with
disabled ep 8803cf791240
[747773.419561] xhci_hcd :00:14.0: Trying to add endpoint 0x3 without
dropping it.
[747773.419563] usb 3-4: Not enough bandwidth for altsetting 1
[747773.419565] ALSA pcm.c:250 9:3:1: usb_set_interface failed
[747773.449987] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with
disabled ep 8803cf791240
[747773.449989] xhci_hcd :00:14.0: Trying to add endpoint 0x3 without
dropping it.
[747773.449992] usb 3-4: Not enough bandwidth for altsetting 2
[747773.449995] ALSA pcm.c:250 9:3:2: usb_set_interface failed
I think the dbus-manager messages can savely be ignored, they are not related
to this problem IMHO. In contrast, xhci_hcd seems to be the culprit but I
cannot tell anything more about it.
After this, I have to plug-unplug the device, then I can use it again - until
the next logout, what is very anoying. By the way, I am using kernel 3.4.4.
Thank you very much for looking into this,
take care
I have got a basic idea about what's going on...
When you logoff, the driver will change interface. xHCI driver will
drop the endpoints of the old interface and add the endpoints of new
interface. However the drop endpoint is disabled and xHCI driver
ignores the drop request, while in add endpoint request driver finds
out the endpoint is not dropped and hence the add request fails.
But why is the endpoint disabled in the first place? That's what we
need to know, since this isn't a valid fix. Perhaps a WARN_ON() around
the error path for the disabled endpoint would help us with a stack
trace?
Sarah Sharp
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 73e8817..220671a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1448,7 +1448,7 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
xhci_get_endpoint_flag(ep-desc)) {
xhci_warn(xhci, xHCI %s called with disabled ep %p\n,
__func__, ep);
- return 0;
+// return 0;
}
ctrl_ctx-drop_flags |= cpu_to_le32(drop_flag);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb sound issue - any ideas?
Dear Sarah, dear Andiry, thank you very much for your inputs. If you, Sarah, could be a little more precise for a (nearly ) non programmer what you'd like to see in terms of code lines (WARN_ON(), but where ...) I could apply a corresponding patch and would gladly provide anything my kernel spits out in terms of messages :-). Again, many thanks for all your efforts, take care Dieter Jurzitza -Original-Nachricht- Von: Sarah Sharp sarah.a.sh...@linux.intel.com An: Andiry Xu andiry...@amd.com Cc: Dr. Ing. Dieter Jurzitza dieter.jurzi...@t-online.de, linux-usb@vger.kernel.org Betreff: Re: usb sound issue - any ideas? Datum: Mon, 09 Jul 2012 12:37:13 +0200 But why is the endpoint disabled in the first place? That's what we need to know, since this isn't a valid fix. Perhaps a WARN_ON() around the error path for the disabled endpoint would help us with a ** -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] usb: gadget: mv_udc: reduce the delay time
Hello. On 09-07-2012 6:27, Neil Zhang wrote: -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: 2012年7月7日 1:34 To: Neil Zhang Cc: ba...@ti.com; gre...@linuxfoundation.org; Chao Xie; khoroshi...@ispras.ru; linux-usb@vger.kernel.org Subject: Re: [PATCH 1/7] usb: gadget: mv_udc: reduce the delay time Hello. On 07/06/2012 04:44 PM, Neil Zhang wrote: We have several place will use udelay to wait the status meeting the request, Um, that doesn't parse... :-( Do you mean the syntax here is not correct or something else? Yes, syntax. Thanks. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB: panic with printk
Hello, Current 3.5-rc5-git panics on my MIPS targets during USB host controller initialization. Disabling CONFIG_PRINTK fixes it. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver au1xxx-ehci au1xxx-ehci.0: Au1xxx EHCI au1xxx-ehci au1xxx-ehci.0: new USB bus registered, assigned bus number 1 au1xxx-ehci au1xxx-ehci.0: irq 98, io mem 0x1402 Unhandled kernel unaligned access[#1]: Cpu 0 $ 0 : 10003c00 b4696540 $ 4 : 80776278 74696540 $ 8 : 10003c00 101e $12 : 807d12d8 807d123c 3b9aca00 $16 : 74696540 74696475 80776278 0028 $20 : 8083 $24 : 801444b0 $28 : 80776000 807761b0 0003 80104f60 Hi: Lo: epc : 8010c948 do_page_fault+0x68/0x350 kra: 80104f60 ret_from_exception+0x0/0x18 Status: 10003c02KERNEL EXL Cause : 80808410 BadVA : 7469653d PrId : 800c8000 (Au1300) Process (pid: 0, threadinfo=80776000, task=8084ebe4, tls=0020) Stack : 45524f4e 5341 0054 5f515249 48544f4e 44414552 5f515249 55414f4e 00030001 53515249 5455415f 5445444f 00544345 53515249 5045525f 0059414c 53515249 4941575f 474e4954 53515249 4e45505f 474e4944 6d6f682f 616d2f65 642f6f6e 30323162 656b2f30 6c656e72 6e696c2f 6b2f7875 656e7265 72692f6c 61682f71 656c646e 632e 20717269 ... Call Trace: [8010c948] do_page_fault+0x68/0x350 Code: 00809021 00a0b021 00c08021 14400093 8e3500c8 8f830014 3c02efff 3442 00621024 8/wÇ ÿ'wÇ╚( äÇkra: v12Au12└wÇ((Au12└wÇ( Caus`OÇv12äÇÇH╔Ç ( HÑ┬ıc@Î└) Process ¬¬¬ Stack : ... Call Trace: [8010c948] _agad_easad_ad_t+0x68/0x350 H%wÇ╚H%wÇ╚H%wÇ╚H%wÇ╚H%wÇ╚H%wÇ╚H%wÇ╚H%wÇ╚H%wÇ╚ ÿ'wÇ╚( äÇkra: v12Au12└wÇ((Au12└wÇ( Caus`OÇv12äÇÇH╔Ç ( HÑ┬ıc@Î└) For reference, the working case: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver au1xxx-ehci au1xxx-ehci.0: Au1xxx EHCI au1xxx-ehci au1xxx-ehci.0: new USB bus registered, assigned bus number 1 au1xxx-ehci au1xxx-ehci.0: irq 37, io mem 0x14020200 au1xxx-ehci au1xxx-ehci.0: USB 0.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI au1xxx-ohci au1xxx-ohci.0: new USB bus registered, assigned bus number 2 au1xxx-ohci au1xxx-ohci.0: irq 37, io mem 0x14020100 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected usbcore: registered new interface driver uas Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. Thanks! Manuel Lauss
[PATCH 1/3] arm: omap: hwmod: add new memory resource for usb phy cont
From: Ajay Kumar Gupta ajay.gu...@ti.com
Added usb_ctrl0 and usb_ctrl1 base address as new memory resources
which will be used at am335x musb driver glue layer to turn on or
off builin PHY. This is needed untill we have a separate system
control module driver.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Damodar Santhapuri x0132...@ti.com
---
This patch set applies to 'xceiv' branch on Felipe's tree.
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index df888fe..7dfb61e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -3274,6 +3274,18 @@ static struct omap_hwmod_addr_space
am33xx_usbss_addr_space[] = {
.pa_end = 0x47401800 + SZ_2K - 1,
.flags = ADDR_TYPE_RT
},
+ {
+ .name = usb_ctrl0,
+ .pa_start = 0x44E10620,
+ .pa_end = 0x44E10624,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = usb_ctrl1,
+ .pa_start = 0x44E10628,
+ .pa_end = 0x44E1062c,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] usb: musb: dsps: add phy control logic to glue
From: Ajay Kumar Gupta ajay.gu...@ti.com
AM335x uses NOP transceiver driver and need to enable builtin PHY
by writing into usb_ctrl register available in system control
module register space. This is being added at musb glue driver
layer untill a separate system control module driver is available.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Damodar Santhapuri x0132...@ti.com
---
arch/arm/mach-omap2/board-ti8168evm.c |1 -
arch/arm/mach-omap2/omap_phy_internal.c | 35
arch/arm/plat-omap/include/plat/usb.h |5 +-
drivers/usb/musb/musb_dsps.c| 88 +--
4 files changed, 74 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index d4c8392..0c7c098 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -26,7 +26,6 @@
#include plat/usb.h
static struct omap_musb_board_data musb_board_data = {
- .set_phy_power = ti81xx_musb_phy_power,
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..d80bb16 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -254,38 +254,3 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
-
-void ti81xx_musb_phy_power(u8 on)
-{
- void __iomem *scm_base = NULL;
- u32 usbphycfg;
-
- scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
- if (!scm_base) {
- pr_err(system control module ioremap failed\n);
- return;
- }
-
- usbphycfg = __raw_readl(scm_base + USBCTRL0);
-
- if (on) {
- if (cpu_is_ti816x()) {
- usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
- usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
- } else if (cpu_is_ti814x()) {
- usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
- }
- } else {
- if (cpu_is_ti816x())
- usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
- else if (cpu_is_ti814x())
- usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
-
- }
- __raw_writel(usbphycfg, scm_base + USBCTRL0);
-
- iounmap(scm_base);
-}
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 548a4c8..c2aa4ae 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -95,7 +95,6 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
-extern void ti81xx_musb_phy_power(u8 on);
/* AM35x */
/* USB 2.0 PHY Control */
@@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on);
#define CONF2_DATPOL (1 1)
/* TI81XX specific definitions */
-#define USBCTRL0 0x620
-#define USBSTAT0 0x624
+#define MUSB_USBSS_REV_816X0x9
+#define MUSB_USBSS_REV_814X0xb
/* TI816X PHY controls bits */
#define TI816X_USBPHY0_NORMAL_MODE (1 0)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 494772f..f7271c3 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -115,9 +115,46 @@ struct dsps_glue {
struct platform_device *musb; /* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
+ u32 __iomem *usb_ctrl;
+ u8 usbss_rev;
};
/**
+ * musb_dsps_phy_control - phy on/off
+ * @glue: struct dsps_glue *
+ * @on: flag for phy to be switched on or off
+ *
+ * This is to enable the PHY using usb_ctrl register in system control
+ * module space.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+{
+ u32 usbphycfg;
+
+ usbphycfg = __raw_readl(glue-usb_ctrl);
+
+ if (on) {
+ if (glue-usbss_rev == MUSB_USBSS_REV_816X) {
+ usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
+ usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
+ } else if (glue-usbss_rev == MUSB_USBSS_REV_814X) {
+ usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
+ | USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
+
[PATCH 3/3] usb: musb: dsps: enable phy control for am335x
From: Ajay Kumar Gupta ajay.gu...@ti.com
Enabled the phy control logic for am335x also based on usbss
revision register.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Damodar Santhapuri x0132...@ti.com
---
Earlier version of this patch based on function pointer was submitted at
http://marc.info/?l=linux-usbm=133583281512646w=2
and was not accepted as Felipe wanted this to be done through
system conrol module driver.
arch/arm/plat-omap/include/plat/usb.h |1 +
drivers/usb/musb/musb_dsps.c | 17 +++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index c2aa4ae..6459b10 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -121,6 +121,7 @@ extern void am35x_set_mode(u8 musb_mode);
/* TI81XX specific definitions */
#define MUSB_USBSS_REV_816X0x9
#define MUSB_USBSS_REV_814X0xb
+#define MUSB_USBSS_REV_33XX0xd
/* TI816X PHY controls bits */
#define TI816X_USBPHY0_NORMAL_MODE (1 0)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f7271c3..171352c 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -140,16 +140,21 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
if (glue-usbss_rev == MUSB_USBSS_REV_816X) {
usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
- } else if (glue-usbss_rev == MUSB_USBSS_REV_814X) {
- usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
+ } else if (glue-usbss_rev == MUSB_USBSS_REV_814X ||
+ glue-usbss_rev == MUSB_USBSS_REV_33XX) {
+ usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
+ usbphycfg |= USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN;
+ if (glue-usbss_rev == MUSB_USBSS_REV_814X) {
+ usbphycfg = ~(USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= USBPHY_DPOPBUFCTL
+ | USBPHY_DMOPBUFCTL;
+ }
}
} else {
if (glue-usbss_rev == MUSB_USBSS_REV_816X)
usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
- else if (glue-usbss_rev == MUSB_USBSS_REV_814X)
+ else if (glue-usbss_rev == MUSB_USBSS_REV_814X ||
+ glue-usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
__raw_writel(usbphycfg, glue-usb_ctrl);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] Input: xpad - Handle all variations of Mad Catz Beat Pad
On Sun, 8 Jul 2012, Yuri Khan wrote:
* Add a quirk to usbhid to ignore this device
---
drivers/hid/hid-ids.h |3 +++
drivers/hid/usbhid/hid-quirks.c |2 ++
drivers/input/joystick/xpad.c |1 +
3 files changed, 6 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d1cdd2d..43c3d75 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -518,6 +518,9 @@
#define USB_DEVICE_ID_CRYSTALTOUCH 0x0006
#define USB_DEVICE_ID_CRYSTALTOUCH_DUAL 0x0007
+#define USB_VENDOR_ID_MADCATZ0x0738
+#define USB_DEVICE_ID_MADCATZ_BEATPAD0x4540
+
#define USB_VENDOR_ID_MCC0x09db
#define USB_DEVICE_ID_MCC_PMD1024LS 0x0076
#define USB_DEVICE_ID_MCC_PMD1208LS 0x007a
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 0597ee6..8726d33 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -45,6 +45,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
+ { USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_BEATPAD,
HID_QUIRK_IGNORE },
+
Please put it in drivers/hid/hid-core.c, hid_ignore_list[] array instead.
HID_QUIRK_IGNORE is there solely for allowing specification as a module
parameter.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: musb: implement (un)map_urb_for_dma hooks
MUSB controller cannot work in DMA mode with misaligned buffers,
switching in PIO mode.
HCD core has hooks that allow to override the default DMA
mapping and unmapping routines for host controllers that have
special DMA requirements, such as alignment contraints.
It is observed that work in PIO mode is slow and it's better
to align buffers properly before passing them to MUSB
This increased throughput 80-120 MBits/s over musb@omap4 with
USB Gigabit ethernet adapter attached.
Some ideas taken from ehci-tegra.c
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
drivers/usb/musb/musb_core.c | 14 ++
drivers/usb/musb/musb_host.c | 102 +-
drivers/usb/musb/musb_host.h |2 +-
3 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index db3dff8..50a74e5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1428,6 +1428,20 @@ static int __devinit musb_core_init(u16 musb_type,
struct musb *musb)
/* log release info */
musb-hwvers = musb_read_hwvers(mbase);
+
+#ifndef CONFIG_MUSB_PIO_ONLY
+ /*
+* The DMA engine in RTL1.8 and above cannot handle
+* DMA addresses that are not aligned to a 4 byte boundary.
+* For such engine implemented (un)map_urb_for_dma hooks.
+* Do not use these hooks for RTL1.8
+*/
+ if (musb-hwvers MUSB_HWVERS_1800) {
+ musb_hc_driver.map_urb_for_dma = NULL;
+ musb_hc_driver.unmap_urb_for_dma = NULL;
+ }
+#endif
+
snprintf(aRevision, 32, %d.%d%s, MUSB_HWVERS_MAJOR(musb-hwvers),
MUSB_HWVERS_MINOR(musb-hwvers),
(musb-hwvers MUSB_HWVERS_RC) ? RC : );
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 4bb717d..48f2311 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2317,7 +2317,102 @@ static int musb_bus_resume(struct usb_hcd *hcd)
return 0;
}
-const struct hc_driver musb_hc_driver = {
+
+#ifndef CONFIG_MUSB_PIO_ONLY
+
+#define MUSB_USB_DMA_ALIGN 4
+
+struct musb_temp_buffer {
+ void *kmalloc_ptr;
+ void *old_xfer_buffer;
+ u8 data[0];
+};
+
+static void musb_free_temp_buffer(struct urb *urb)
+{
+ enum dma_data_direction dir;
+ struct musb_temp_buffer *temp;
+
+ if (!(urb-transfer_flags URB_ALIGNED_TEMP_BUFFER))
+ return;
+
+ dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ temp = container_of(urb-transfer_buffer, struct musb_temp_buffer,
+ data);
+
+ if (dir == DMA_FROM_DEVICE) {
+ memcpy(temp-old_xfer_buffer, temp-data,
+ urb-transfer_buffer_length);
+ }
+ urb-transfer_buffer = temp-old_xfer_buffer;
+ kfree(temp-kmalloc_ptr);
+
+ urb-transfer_flags = ~URB_ALIGNED_TEMP_BUFFER;
+}
+
+static int musb_alloc_temp_buffer(struct urb *urb, gfp_t mem_flags)
+{
+ enum dma_data_direction dir;
+ struct musb_temp_buffer *temp;
+ void *kmalloc_ptr;
+ size_t kmalloc_size;
+
+ if (urb-num_sgs || urb-sg ||
+ urb-transfer_buffer_length == 0 ||
+ !((uintptr_t)urb-transfer_buffer (MUSB_USB_DMA_ALIGN - 1)))
+ return 0;
+
+ dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ /* Allocate a buffer with enough padding for alignment */
+ kmalloc_size = urb-transfer_buffer_length +
+ sizeof(struct musb_temp_buffer) + MUSB_USB_DMA_ALIGN - 1;
+
+ kmalloc_ptr = kmalloc(kmalloc_size, mem_flags);
+ if (!kmalloc_ptr)
+ return -ENOMEM;
+
+ /* Position our struct temp_buffer such that data is aligned */
+ temp = PTR_ALIGN(kmalloc_ptr, MUSB_USB_DMA_ALIGN);
+
+
+ temp-kmalloc_ptr = kmalloc_ptr;
+ temp-old_xfer_buffer = urb-transfer_buffer;
+ if (dir == DMA_TO_DEVICE)
+ memcpy(temp-data, urb-transfer_buffer,
+ urb-transfer_buffer_length);
+ urb-transfer_buffer = temp-data;
+
+ urb-transfer_flags |= URB_ALIGNED_TEMP_BUFFER;
+
+ return 0;
+}
+
+static int musb_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
+ gfp_t mem_flags)
+{
+ int ret;
+
+ ret = musb_alloc_temp_buffer(urb, mem_flags);
+ if (ret)
+ return ret;
+
+ ret = usb_hcd_map_urb_for_dma(hcd, urb, mem_flags);
+ if (ret)
+ musb_free_temp_buffer(urb);
+
+ return ret;
+}
+
+static void musb_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
+{
+ usb_hcd_unmap_urb_for_dma(hcd, urb);
+ musb_free_temp_buffer(urb);
+}
+#endif /* !CONFIG_MUSB_PIO_ONLY */
+
+struct hc_driver musb_hc_driver = {
.description= musb-hcd,
.product_desc = MUSB HDRC host driver,
Re: [PATCH 1/2] usb: gadget: composite: Race between disconnect/unbind and setup
On Sun, 8 Jul 2012, Kevin Cernekee wrote: On Sun, Jul 8, 2012 at 5:33 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 8 Jul 2012, Kevin Cernekee wrote: usb_gadget_remove_driver() runs through a four-step sequence to shut down the gadget driver. For the case of a composite gadget + at91 UDC, this would look like: udc-driver-disconnect(udc-gadget); // composite_disconnect() usb_gadget_disconnect(udc-gadget); // at91_pullup(gadget, 0) udc-driver-unbind(udc-gadget); // composite_unbind() usb_gadget_udc_stop(udc-gadget, udc-driver); // at91_stop() composite_disconnect() says: if (cdev-config) reset_config(cdev); reset_config() sets cdev-config to NULL. composite_unbind() later tests for this: WARN_ON(cdev-config); But SETUP packets may be sent to the composite driver up until the point when usb_gadget_disconnect() returns. That doesn't sound right. A host can't send SETUP packets to a disconnected port. The packets should stop arriving when udc-driver-disconnect returns -- assuming the UDC driver implements a disconnect method. udc-driver-disconnect points to composite_disconnect(). What is composite_disconnect() doing to tell the UDC driver to disconnect the port from the host? Oops -- you're right and I was wrong. It's the usb_gadget_disconnect() call which turns off the pullup. Sorry about the confusion. What I see is that usb_gadget_disconnect() does tell the UDC driver to stop activity on the port, but that only happens after composite_disconnect() was called. Can you confirm that the order of the calls in usb_gadget_remove_driver() is correct? They might need to be changed. It does seems like a bad idea to tell the gadget driver that a disconnect occurred before the host knows about it. If you change the order of those two calls, does that make your posted patch unnecessary? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] usb: host: Fix possible kernel crash
On Mon, 9 Jul 2012, Venu Byravarasu wrote:
In functions itd_complete sitd_complete, a pointer
by name stream may get dereferenced after freeing it, when
iso_stream_put is called with stream-refcount = 2.
I don't understand the problem. Did you actually see this happen or is
it only theoretical?
Hence fixing it.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
By mistake sent incorrect patch set number as v2 earlier.
Hence fixing it.
drivers/usb/host/ehci-sched.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 33182c6..20d0c38 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1715,6 +1715,7 @@ itd_complete (
struct ehci_iso_stream *stream = itd-stream;
struct usb_device *dev;
unsignedretval = false;
+ u32 stream_ref_count = 0;
/* for each uframe with a packet */
for (uframe = 0; uframe 8; uframe++) {
@@ -1783,7 +1784,8 @@ itd_complete (
dev-devpath, stream-bEndpointAddress 0x0f,
(stream-bEndpointAddress USB_DIR_IN) ? in : out);
}
- iso_stream_put (ehci, stream);
+ stream_ref_count = stream-refcount;
+ iso_stream_put(ehci, stream);
This iso_stream_put removes the reference held by the URB. Before it
is called, stream-refcount must be = 3:
refcount is set to 1 when the stream is created;
each active URB holds a reference;
each itd holds a reference.
So after the call, the refcount value must be = 2 and the stream could
not have been deallocated.
done:
itd-urb = NULL;
@@ -1797,7 +1799,7 @@ done:
* Move it to a safe place until a new frame starts.
*/
list_move(itd-itd_list, ehci-cached_itd_list);
- if (stream-refcount == 2) {
+ if (stream_ref_count == 3) {
Therefore this seems unnecessary.
/* If iso_stream_put() were called here, stream
* would be freed. Instead, just prevent reuse.
*/
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PCI: EHCI: fix crash during suspend on ASUS computers
Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend. It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.
It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working. Consequently
commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add
NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.
Now we know the actual cause of the problem. Thanks to AceLan Kao for
tracking it down.
According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows. When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS. Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state. If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so. This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3. The end result is
a system hang or memory corruption.
Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend. This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.
In theory we could do this for every PCI device. However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.
Finally the affected systems can suspend with USB wakeup working
properly.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Dâniel Fraga frag...@gmail.com
Tested-by: Javier Marcet jmar...@gmail.com
Tested-by: Andrey Rahmatullin w...@wrar.name
Tested-by: Oleksij Rempel bug-tr...@fisher-privat.net
Tested-by: Pavel Pisa p...@cmp.felk.cvut.cz
CC: sta...@vger.kernel.org
---
drivers/pci/pci-driver.c | 12
drivers/pci/pci.c|5 -
drivers/pci/quirks.c | 26 --
include/linux/pci.h |2 --
4 files changed, 12 insertions(+), 33 deletions(-)
Index: usb-3.4/drivers/pci/pci.c
==
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1744,11 +1744,6 @@ int pci_prepare_to_sleep(struct pci_dev
if (target_state == PCI_POWER_ERROR)
return -EIO;
- /* Some devices mustn't be in D3 during system sleep */
- if (target_state == PCI_D3hot
- (dev-dev_flags PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
- return 0;
-
pci_enable_wake(dev, target_state, device_may_wakeup(dev-dev));
error = pci_set_power_state(dev, target_state);
Index: usb-3.4/drivers/pci/quirks.c
===
--- usb-3.4.orig/drivers/pci/quirks.c
+++ usb-3.4/drivers/pci/quirks.c
@@ -2929,32 +2929,6 @@ static void __devinit disable_igfx_irq(s
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
-/*
- * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
- * ASUS motherboards will cause memory corruption or a system crash
- * if they are in D3 while the system is put into S3 sleep.
- */
-static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
-{
- const char *sys_info;
- static const char good_Asus_board[] = P8Z68-V;
-
- if (dev-dev_flags PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
- return;
- if (dev-subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
- return;
- sys_info = dmi_get_system_info(DMI_BOARD_NAME);
- if (sys_info memcmp(sys_info, good_Asus_board,
- sizeof(good_Asus_board) - 1) == 0)
- return;
-
- dev_info(dev-dev, broken D3 during system sleep on ASUS\n);
- dev-dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
- device_set_wakeup_capable(dev-dev, false);
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
-
static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
struct pci_fixup *end)
{
Index: usb-3.4/include/linux/pci.h
===
---
Re: usbutils 006 release
On Fri, 6 Jul 2012, Greg KH wrote: Here's the 006 release of usbutils. Some USB 3.0 updates, a new usb.ids file update, and a number of other fixes and updates for annoying problems that people had reported. Full shortlog information is below if people are curious. The package can be downladed from kernel.org: http://www.kernel.org/pub/linux/utils/usb/usbutils/ We've switched over to using git for development now, which makes things much easier than the old cvs tree. The tree can be found on both kernel.org and github.com if you want to fork it and send us changes easier: http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git This link doesn't work for me. Are you sure the repository is installed at git.kernel.org? http://github.com/gregkh/usbutils/tree/master Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: infos about device ZTE MF821D 2G,3G,4G/LTE usb-modem/networkcard
Am 09.07.2012 10:22, schrieb Oliver Neukum: Am Sonntag, 8. Juli 2012, 13:32:42 schrieb Thomas Schäfer: Not for kernel-code, but usefull for testers/users: udev-rules/usb_modeswitch /lib/udev/rules.d/40-usb_modeswitch.rules Be careful. The expert from draisberghof told me yesterday that is only the SCSI-command for eject and can have collateral damage. His explanation is here: http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=946 Could you also post lsusb -v for the card? It was part of the first mail. Now there are two copys in web: http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=946 http://www.spinics.net/lists/linux-usb/msg66855.html Regards, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] Input: xpad - Handle all variations of Mad Catz Beat Pad
On Mon, Jul 9, 2012 at 9:08 PM, Jiri Kosina jkos...@suse.cz wrote:
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
+ { USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_BEATPAD,
HID_QUIRK_IGNORE },
Please put it in drivers/hid/hid-core.c, hid_ignore_list[] array instead.
HID_QUIRK_IGNORE is there solely for allowing specification as a module
parameter.
I knew something was not right as there were no prior HID_QUIRK_IGNORE
entries. Thanks for the guidance, will send a revised patch tomorrow.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 ver. 2] EHCI: centralize controller initialization
On Fri, Jun 29, 2012 at 11:42:46AM -0400, Alan Stern wrote: This patch (as1564b) converts the EHCI platform drivers to use the central ehci_setup() routine for generic controller initialization rather than each having its own idiosyncratic approach. The major point of difficulty lies in ehci-pci's many vendor- and device-specific workarounds. Some of them have to be applied before calling ehci_setup() and some after, which necessitates a fair amount of code motion. The other platform drivers require much smaller changes. One point not addressed by the patch is whether ports should be powered on or off following initialization. The different drivers appear to handle this pretty much at random. In fact it shouldn't matter, because the hub driver turns on power to all ports when it binds to the root hub. Straightening that out will be left for another day. Signed-off-by: Alan Stern st...@rowland.harvard.edu --- Ver. 2: Rebased on top of Russ Dill's changes to ehci-omap.c. Fixed several mistakes involving unused local variables and calls to ehci_setup(ehci) rather than ehci_setup(hcd). I'm getting a conflict when trying to apply this in that driver: patching file drivers/usb/host/ehci-omap.c Hunk #3 FAILED at 329. Hunk #4 FAILED at 356. Hunk #5 succeeded at 560 (offset 14 lines). 2 out of 5 hunks FAILED -- saving rejects to file drivers/usb/host/ehci-omap.c.rej Can you refresh this and resend it? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PCI: EHCI: fix crash during suspend on ASUS computers
On Monday, July 09, 2012, Alan Stern wrote:
Quite a few ASUS computers experience a nasty problem, related to the
EHCI controllers, when going into system suspend. It was observed
that the problem didn't occur if the controllers were not put into the
D3 power state before starting the suspend, and commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers) was created to do this.
It turned out this approach messed up other computers that didn't have
the problem -- it prevented USB wakeup from working. Consequently
commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add
NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it
reverted the earlier commit and added a whitelist of known good board
names.
Now we know the actual cause of the problem. Thanks to AceLan Kao for
tracking it down.
According to him, an engineer at ASUS explained that some of their
BIOSes contain a bug that was added in an attempt to work around a
problem in early versions of Windows. When the computer goes into S3
suspend, the BIOS tries to verify that the EHCI controllers were first
quiesced by the OS. Nothing's wrong with this, but the BIOS does it
by checking that the PCI COMMAND registers contain 0 without checking
the controllers' power state. If the register isn't 0, the BIOS
assumes the controller needs to be quiesced and tries to do so. This
involves making various MMIO accesses to the controller, which don't
work very well if the controller is already in D3. The end result is
a system hang or memory corruption.
Since the value in the PCI COMMAND register doesn't matter once the
controller has been suspended, and since the value will be restored
anyway when the controller is resumed, we can work around the BIOS bug
simply by setting the register to 0 during system suspend. This patch
(as1590) does so and also reverts the second commit mentioned above,
which is now unnecessary.
In theory we could do this for every PCI device. However to avoid
introducing new problems, the patch restricts itself to EHCI host
controllers.
Finally the affected systems can suspend with USB wakeup working
properly.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Dâniel Fraga frag...@gmail.com
Tested-by: Javier Marcet jmar...@gmail.com
Tested-by: Andrey Rahmatullin w...@wrar.name
Tested-by: Oleksij Rempel bug-tr...@fisher-privat.net
Tested-by: Pavel Pisa p...@cmp.felk.cvut.cz
CC: sta...@vger.kernel.org
Acked-by: Rafael J. Wysocki r...@sisk.pl
---
drivers/pci/pci-driver.c | 12
drivers/pci/pci.c|5 -
drivers/pci/quirks.c | 26 --
include/linux/pci.h |2 --
4 files changed, 12 insertions(+), 33 deletions(-)
Index: usb-3.4/drivers/pci/pci.c
==
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1744,11 +1744,6 @@ int pci_prepare_to_sleep(struct pci_dev
if (target_state == PCI_POWER_ERROR)
return -EIO;
- /* Some devices mustn't be in D3 during system sleep */
- if (target_state == PCI_D3hot
- (dev-dev_flags PCI_DEV_FLAGS_NO_D3_DURING_SLEEP))
- return 0;
-
pci_enable_wake(dev, target_state, device_may_wakeup(dev-dev));
error = pci_set_power_state(dev, target_state);
Index: usb-3.4/drivers/pci/quirks.c
===
--- usb-3.4.orig/drivers/pci/quirks.c
+++ usb-3.4/drivers/pci/quirks.c
@@ -2929,32 +2929,6 @@ static void __devinit disable_igfx_irq(s
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
-/*
- * The Intel 6 Series/C200 Series chipset's EHCI controllers on many
- * ASUS motherboards will cause memory corruption or a system crash
- * if they are in D3 while the system is put into S3 sleep.
- */
-static void __devinit asus_ehci_no_d3(struct pci_dev *dev)
-{
- const char *sys_info;
- static const char good_Asus_board[] = P8Z68-V;
-
- if (dev-dev_flags PCI_DEV_FLAGS_NO_D3_DURING_SLEEP)
- return;
- if (dev-subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
- return;
- sys_info = dmi_get_system_info(DMI_BOARD_NAME);
- if (sys_info memcmp(sys_info, good_Asus_board,
- sizeof(good_Asus_board) - 1) == 0)
- return;
-
- dev_info(dev-dev, broken D3 during system sleep on ASUS\n);
- dev-dev_flags |= PCI_DEV_FLAGS_NO_D3_DURING_SLEEP;
- device_set_wakeup_capable(dev-dev, false);
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c26, asus_ehci_no_d3);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1c2d, asus_ehci_no_d3);
-
static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
Re: [PATCH] PCI: EHCI: fix crash during suspend on ASUS computers
On Mon, Jul 09, 2012 at 06:50:24PM +0200, Rafael J. Wysocki wrote: On Monday, July 09, 2012, Alan Stern wrote: Quite a few ASUS computers experience a nasty problem, related to the EHCI controllers, when going into system suspend. It was observed that the problem didn't occur if the controllers were not put into the D3 power state before starting the suspend, and commit 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during suspend on ASUS computers) was created to do this. It turned out this approach messed up other computers that didn't have the problem -- it prevented USB wakeup from working. Consequently commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it reverted the earlier commit and added a whitelist of known good board names. Now we know the actual cause of the problem. Thanks to AceLan Kao for tracking it down. According to him, an engineer at ASUS explained that some of their BIOSes contain a bug that was added in an attempt to work around a problem in early versions of Windows. When the computer goes into S3 suspend, the BIOS tries to verify that the EHCI controllers were first quiesced by the OS. Nothing's wrong with this, but the BIOS does it by checking that the PCI COMMAND registers contain 0 without checking the controllers' power state. If the register isn't 0, the BIOS assumes the controller needs to be quiesced and tries to do so. This involves making various MMIO accesses to the controller, which don't work very well if the controller is already in D3. The end result is a system hang or memory corruption. Since the value in the PCI COMMAND register doesn't matter once the controller has been suspended, and since the value will be restored anyway when the controller is resumed, we can work around the BIOS bug simply by setting the register to 0 during system suspend. This patch (as1590) does so and also reverts the second commit mentioned above, which is now unnecessary. In theory we could do this for every PCI device. However to avoid introducing new problems, the patch restricts itself to EHCI host controllers. Finally the affected systems can suspend with USB wakeup working properly. Signed-off-by: Alan Stern st...@rowland.harvard.edu Tested-by: Dâniel Fraga frag...@gmail.com Tested-by: Javier Marcet jmar...@gmail.com Tested-by: Andrey Rahmatullin w...@wrar.name Tested-by: Oleksij Rempel bug-tr...@fisher-privat.net Tested-by: Pavel Pisa p...@cmp.felk.cvut.cz CC: sta...@vger.kernel.org Acked-by: Rafael J. Wysocki r...@sisk.pl Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 REBASE 6/9] USB: notify phy when root hub port connect change
On Sat, Jul 07, 2012 at 10:56:45PM +0800, Richard Zhao wrote:
Phy may need to change settings when port connect change.
Signed-off-by: Richard Zhao richard.z...@freescale.com
Tested-by: Subodh Nijsure snijs...@grid-net.com
---
drivers/usb/core/hub.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4cc8dc9..2ba9d84 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -20,6 +20,7 @@
#include linux/usb.h
#include linux/usbdevice_fs.h
#include linux/usb/hcd.h
+#include linux/usb/otg.h
#include linux/usb/quirks.h
#include linux/kthread.h
#include linux/mutex.h
@@ -4037,6 +4038,13 @@ static void hub_port_connect_change(struct usb_hub
*hub, int port1,
}
}
+ if (unlikely(hcd-phy !hdev-parent)) {
Why is this unlikely? And why mark it as such, is this a fast path
that needs the compiler to know this hint to optimize things here?
Please don't use likely() or unlikely() except in places it really is
needed, _and_ you have measured the difference. Have you done so in
this place?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 REBASE 0/9] add imx usb driver based on Greg next tree
On Sat, Jul 07, 2012 at 10:56:39PM +0800, Richard Zhao wrote: The work is based on ci13xxx rework done by Alexander Shishkin. To let Greg pick up, I also added patches Alex queued that I depends on. I've applied everything but patch number 6, which I've responded to with some questions about it. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On 2012-07-09 15:54, Clemens Ladisch wrote: (forwarded to linux-usb) Udo van den Heuvel wrote: Hello, One moment the box is runing OK. One moment the 3.4.4 kernel decides to disable an interrupt. Why? Jul 8 07:43:49 box3 ntpd[5067]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits Jul 8 07:44:53 box3 kernel: irq 18: nobody cared (try booting with the irqpoll option) Jul 8 07:44:53 box3 kernel: Pid: 1501, comm: irq/18-ohci_hcd Tainted: G W3.4.4 #1 Jul 8 07:44:53 box3 kernel: Call Trace: Jul 8 07:44:53 box3 kernel: [81095a76] ? __report_bad_irq+0x36/0xd0 Jul 8 07:44:53 box3 kernel: [81095d7f] ? note_interrupt+0x1cf/0x220 Jul 8 07:44:53 box3 kernel: [810945c0] ? irq_thread_fn+0x40/0x40 Jul 8 07:44:53 box3 kernel: [8109443d] ? irq_thread+0x13d/0x180 Jul 8 07:44:53 box3 kernel: [81094300] ? wake_threads_waitq+0x50/0x50 Jul 8 07:44:53 box3 kernel: [81052015] ? kthread+0x85/0x90 Jul 8 07:44:53 box3 kernel: [81405514] ? kernel_thread_helper+0x4/0x10 Jul 8 07:44:53 box3 kernel: [81051f90] ? kthread_freezable_should_stop+0x50/0x50 Jul 8 07:44:53 box3 kernel: [81405510] ? gs_change+0xb/0xb Jul 8 07:44:53 box3 kernel: handlers: Jul 8 07:44:53 box3 kernel: [810939d0] irq_default_primary_handler threaded [812c7bb0] usb_hcd_irq Jul 8 07:44:53 box3 kernel: [810939d0] irq_default_primary_handler threaded [812c7bb0] usb_hcd_irq Jul 8 07:44:53 box3 kernel: [810939d0] irq_default_primary_handler threaded [812c7bb0] usb_hcd_irq Jul 8 07:44:53 box3 kernel: Disabling IRQ #18 Jul 8 07:44:53 box3 kernel: pwc: Iso frame 0 has error -114 Jul 8 07:44:53 box3 kernel: pwc: Iso frame 1 has error -18 Jul 8 07:44:53 box3 kernel: pwc: Iso frame 2 has error -18 Jul 8 07:44:53 box3 kernel: pwc: Iso frame 3 has error -18 Jul 8 07:44:53 box3 kernel: pwc: Iso frame 4 has error -18 Jul 8 07:44:53 box3 kernel: pwc: Iso frame 5 has error -18 (etc; many more of the pwc messages) Kind regards, Udo ... and, with apparently the same mainboard: Over here: Manufacturer: Gigabyte Technology Co., Ltd. Product Name: GA-MA770-DS3 Motherboard is Gigabyte GA-990XA-UD3 CPU is AMD Bulldozer 6 Core version AMD 9550 4 core in my case, i.e.: less new. pwc driver is the main user for a webcam on USB. I'll attach the 2 dmesg logs, one from 3.2 and other from 3.4, hopefully someone can see what's wrong, there is a suggestion to boot with irqpoll, but really wanted someone's opinion on this. Any ideas why the IRQ stops working? Udo -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: maintainers: change of mail
On Thu, Jul 05, 2012 at 09:44:18AM +0200, Oliver Neukum wrote: From 36847fa21bbbe1b2164b7376a0ed73c33374cc78 Mon Sep 17 00:00:00 2001 From: Oliver Neukum oli...@neukum.org Date: Thu, 5 Jul 2012 09:42:41 +0200 Subject: [PATCH] maintainers: change of mail Please don't embed git patches with this header within the email, I have to save the body and apply that, or edit it by hand, either way is a pain. The .name package has run out --- MAINTAINERS | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) No Signed-off-by line, so I can't apply it :( -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 ver. 2] EHCI: centralize controller initialization
On Mon, 9 Jul 2012, Greg KH wrote: On Fri, Jun 29, 2012 at 11:42:46AM -0400, Alan Stern wrote: This patch (as1564b) converts the EHCI platform drivers to use the central ehci_setup() routine for generic controller initialization rather than each having its own idiosyncratic approach. The major point of difficulty lies in ehci-pci's many vendor- and device-specific workarounds. Some of them have to be applied before calling ehci_setup() and some after, which necessitates a fair amount of code motion. The other platform drivers require much smaller changes. One point not addressed by the patch is whether ports should be powered on or off following initialization. The different drivers appear to handle this pretty much at random. In fact it shouldn't matter, because the hub driver turns on power to all ports when it binds to the root hub. Straightening that out will be left for another day. Signed-off-by: Alan Stern st...@rowland.harvard.edu --- Ver. 2: Rebased on top of Russ Dill's changes to ehci-omap.c. Fixed several mistakes involving unused local variables and calls to ehci_setup(ehci) rather than ehci_setup(hcd). I'm getting a conflict when trying to apply this in that driver: patching file drivers/usb/host/ehci-omap.c Hunk #3 FAILED at 329. Hunk #4 FAILED at 356. Hunk #5 succeeded at 560 (offset 14 lines). 2 out of 5 hunks FAILED -- saving rejects to file drivers/usb/host/ehci-omap.c.rej Can you refresh this and resend it? That's because my patch was meant to go on top of Russ Dill's changes: http://marc.info/?l=linux-usbm=134084901330725w=2 which evidently hasn't been merged yet. Or if it has, it's in Felipe's tree instead of yours. The two patches touch the same regions of code. What should we do? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: udc-core: Race between disconnect/unbind and setup
On Mon, Jul 9, 2012 at 7:15 AM, Alan Stern st...@rowland.harvard.edu wrote:
What I see is that usb_gadget_disconnect() does tell the UDC driver to
stop activity on the port, but that only happens after
composite_disconnect() was called. Can you confirm that the order of
the calls in usb_gadget_remove_driver() is correct?
They might need to be changed. It does seems like a bad idea to tell
the gadget driver that a disconnect occurred before the host knows
about it.
If you change the order of those two calls, does that make your posted
patch unnecessary?
Yes, that works too. Here is the change:
-- 8 --
From: Kevin Cernekee cerne...@gmail.com
usb_gadget_remove_driver() runs through a four-step sequence to shut down
the gadget driver. For the case of a composite gadget + at91 UDC, this
would look like:
udc-driver-disconnect(udc-gadget); // composite_disconnect()
usb_gadget_disconnect(udc-gadget);// at91_pullup(gadget, 0)
udc-driver-unbind(udc-gadget); // composite_unbind()
usb_gadget_udc_stop(udc-gadget, udc-driver); // at91_stop()
The UDC driver can receive SETUP packets from the host up until the
point when usb_gadget_disconnect() returns. On rare occasions, the
gadget driver may see this sequence:
udc-driver-disconnect(udc-gadget); // composite_disconnect()
udc-driver-setup(udc-gadget, ctrl);// composite_setup()
udc-driver-unbind(udc-gadget); // composite_unbind()
Some gadget drivers, such as composite, assume this will never happen
and crash as a result.
The fix is to quiesce the UDC hardware (via usb_gadget_disconnect)
before running the gadget driver through the disconnect/unbind sequence.
Signed-off-by: Kevin Cernekee cerne...@gmail.com
---
drivers/usb/gadget/udc-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index e5e44f8..bae243c 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -262,8 +262,8 @@ static void usb_gadget_remove_driver(struct usb_udc *udc)
kobject_uevent(udc-dev.kobj, KOBJ_CHANGE);
if (udc_is_newstyle(udc)) {
- udc-driver-disconnect(udc-gadget);
usb_gadget_disconnect(udc-gadget);
+ udc-driver-disconnect(udc-gadget);
udc-driver-unbind(udc-gadget);
usb_gadget_udc_stop(udc-gadget, udc-driver);
} else {
--
1.7.11.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 ver. 2] EHCI: centralize controller initialization
On Mon, Jul 09, 2012 at 02:39:42PM -0400, Alan Stern wrote: On Mon, 9 Jul 2012, Greg KH wrote: On Fri, Jun 29, 2012 at 11:42:46AM -0400, Alan Stern wrote: This patch (as1564b) converts the EHCI platform drivers to use the central ehci_setup() routine for generic controller initialization rather than each having its own idiosyncratic approach. The major point of difficulty lies in ehci-pci's many vendor- and device-specific workarounds. Some of them have to be applied before calling ehci_setup() and some after, which necessitates a fair amount of code motion. The other platform drivers require much smaller changes. One point not addressed by the patch is whether ports should be powered on or off following initialization. The different drivers appear to handle this pretty much at random. In fact it shouldn't matter, because the hub driver turns on power to all ports when it binds to the root hub. Straightening that out will be left for another day. Signed-off-by: Alan Stern st...@rowland.harvard.edu --- Ver. 2: Rebased on top of Russ Dill's changes to ehci-omap.c. Fixed several mistakes involving unused local variables and calls to ehci_setup(ehci) rather than ehci_setup(hcd). I'm getting a conflict when trying to apply this in that driver: patching file drivers/usb/host/ehci-omap.c Hunk #3 FAILED at 329. Hunk #4 FAILED at 356. Hunk #5 succeeded at 560 (offset 14 lines). 2 out of 5 hunks FAILED -- saving rejects to file drivers/usb/host/ehci-omap.c.rej Can you refresh this and resend it? That's because my patch was meant to go on top of Russ Dill's changes: http://marc.info/?l=linux-usbm=134084901330725w=2 which evidently hasn't been merged yet. Or if it has, it's in Felipe's tree instead of yours. It wasn't merged because I thought you objected to it in the review comments in that thread. Your v1 version of this patch also didn't apply, and I thought that was without Russ's patch. So how about you just refresh your patch now, on my tree, and then Russ can redo his patch as it looks like it is much more specific and there were issues left to handle with it. Is that ok with everyone? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.4.4: disabling irq
On Mon, 9 Jul 2012, Clemens Ladisch wrote: (forwarded to linux-usb) Udo van den Heuvel wrote: Hello, One moment the box is runing OK. One moment the 3.4.4 kernel decides to disable an interrupt. Why? The kernel disables IRQs when too many interrupts arrive too quickly. In general that means some device is generating an interrupt request and it isn't getting handled by any driver. Jul 8 07:43:49 box3 ntpd[5067]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits Jul 8 07:44:53 box3 kernel: irq 18: nobody cared (try booting with the irqpoll option) Jul 8 07:44:53 box3 kernel: Pid: 1501, comm: irq/18-ohci_hcd Tainted: G W3.4.4 #1 ... and, with apparently the same mainboard: Simon Jones wrote: Hi, Am not sure where to start with getting help on an issue. Since buying my motherboard i have found the usb ports are pretty unstable, and some devices work on usb2 some on usb3, after a while i managed to work out which will work where and it's reasonably stable now. Am on kernel 3.2.16 and tonight i thought i would try 3.4.4, it's all been compiled and seemed fine until i ran mythtv and couldn't get a smooth picture, then the tuner stopped responding and when looking in to the logs it appears IRQ18 assigned to the usb chipset gets disabled from what i can tell, it also causes a crash. Motherboard is Gigabyte GA-990XA-UD3 CPU is AMD Bulldozer 6 Core version I'll attach the 2 dmesg logs, one from 3.2 and other from 3.4, hopefully someone can see what's wrong, there is a suggestion to boot with irqpoll, but really wanted someone's opinion on this. Simon's log shows a large of number of devices all using the same IRQ. A good place to start would be to unload or unbind the drivers for some or all of the devices -- if that can be done before the IRQ is disabled. Maybe it will turn out that an individual device is responsible for the problem. Another possibility is that some other device is using that IRQ line without the kernel's knowledge. That's not an easy sort of thing to track down, though. In general, how easy is it to reproduce these problems? Does the IRQ line always get disabled after the system has been up for a few seconds? If it does, and if the problem is caused by a software change, git bisection might be the easiest way to track it down. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 9 Jul 2012, Octavio Alvarez wrote: On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern st...@rowland.harvard.edu wrote: Removing my pen drive cleared CCS on [6]. Okay, that explains that. More or less. Is this an old USB-1.1 pen drive? If it is USB-2.0 then I would expect it to connect to the EHCI controller, not the OHCI controller. I don't know... Is there a way to know that? The device is a Bus 001 Device 011: ID 0781:5406 SanDisk Corp. Cruzer Micro U3 That doesn't mean much by itself. But the lsusb output you included confirms that the pen drive was running at high speed -- which means that it should never have been connected to the OHCI controller at all. Another mystery. It appears that your computer's USB hardware is kind of funky. Alan, take a look at this: Bus# 2 `-Dev# 1 Vendor 0x1d6b Product 0x0001 Linux Foundation 1.1 root hub |-Dev# 18 Vendor 0x046d Product 0xc05a Logitech, Inc. Optical Mouse M90 `-Dev# 19 Vendor 0x046d Product 0xc31d Logitech, Inc. Bus# 1 `-Dev# 1 Vendor 0x1d6b Product 0x0002 Linux Foundation 2.0 root hub `-Dev# 18 Vendor 0x0781 Product 0x5406 SanDisk Corp. Cruzer Micro U3 For some reason, my USB drive is now on EHCI! As it should be. Was there ever a time when it was definitely using the OHCI controller? (The CCS status you got before wasn't definite enough to count -- it showed a connected status but not an enabled status.) That should never happen, except when ehci-hcd is unloaded. What happens if you unplug only the keyboard, or only the mouse? The only thing I can confirm for now is that with both disconnected the system consistently suspends and that I have seen the system NOT suspend with either one connected. Having said that, I have also seen the system suspend, but I don't quite trust these tests. I think I may have failed to make sure the settings were appropriate for the test (wrong kernel or wakeup disabled). Well, we can assume that the suspend doesn't work when either device is plugged in. Which suggests another test. Try unloading ehci-hcd, and plug in the pen drive. At that point it should use the OHCI controller. Then if you unplug the keyboard and mouse, what happens when you suspend? My guess is that it will resume immediately. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: gadget: composite: Race between disconnect/unbind and setup
They might need to be changed. It does seems like a bad idea to tell the gadget driver that a disconnect occurred before the host knows about it. Yes, it should pull down dp first, then, tell class driver, it has been disconnected. If you change the order of those two calls, does that make your posted patch unnecessary? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 REBASE 6/9] USB: notify phy when root hub port connect change
On Mon, Jul 09, 2012 at 09:57:57AM -0700, Greg KH wrote:
On Sat, Jul 07, 2012 at 10:56:45PM +0800, Richard Zhao wrote:
Phy may need to change settings when port connect change.
Signed-off-by: Richard Zhao richard.z...@freescale.com
Tested-by: Subodh Nijsure snijs...@grid-net.com
---
drivers/usb/core/hub.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4cc8dc9..2ba9d84 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -20,6 +20,7 @@
#include linux/usb.h
#include linux/usbdevice_fs.h
#include linux/usb/hcd.h
+#include linux/usb/otg.h
#include linux/usb/quirks.h
#include linux/kthread.h
#include linux/mutex.h
@@ -4037,6 +4038,13 @@ static void hub_port_connect_change(struct usb_hub
*hub, int port1,
}
}
+ if (unlikely(hcd-phy !hdev-parent)) {
Why is this unlikely? And why mark it as such, is this a fast path
that needs the compiler to know this hint to optimize things here?
Please don't use likely() or unlikely() except in places it really is
needed, _and_ you have measured the difference. Have you done so in
this place?
It's from a comment by Alan Stern.
http://www.spinics.net/lists/linux-usb/msg64987.html
Actually, for my board, it's not unlikely. But for others which don't
have notify_connect/disconnect, it's unlikely.
Because it's not unlikely for all boards, I prefer remove unlikely.
Thanks
Richard
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mac USB 3.0 Linux support Fwd: [tova-technical-support] Request 2012/06/14/00000005 from Nancy Blum (SN: 20051 )
On Jul 9, 2012, at 5:59 PM, Peter Stuge wrote: Ian Osgood wrote: dmesg errors: xhci_hcd :00:14.0: xhci_run xhci_hcd :00:14.0: Failed to enable MSI-X xhci_hcd :00:14.0: failed to allocate MSI entry xhci_hcd :00:14.0: No msi-x/msi found and no IRQ in BIOS xhci_hcd :00:14.0: startup error -22 xhci_hcd :00:14.0: USB bus 3 deregistered xhci_hcd :00:14.0: can't derive routing for PCI INT A xhci_hcd :00:14.0: init :00:14.0 fail, -22 xhci_hcd: probe of :00:14.0 failed with error -22 Either the firmware isn't setting up interrupt routing correctly (less common) or it is not passing correct data structures to the kernel about how interrupt routing has been set up (very common) or the kernel does not have support compiled-in for the particular type of data structures specifying interrupt routing which are passed by the firmware (there are at least four kinds, some firmware provides all of them since different OSes understand different types, and often the different data is inconsistent). The no MSI is strange though. Could you also send lspci -vvnn output, ran as root? //Peter Actually, that was enough of a hint. We had stripped MSI out of our kernel. Once CONFIG_PCI_MSI was enabled, the external USB ports started working again. Now to figure out why that one change breaks uvesa... Ian-- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7 v2] usb: gadget: mv_udc: reduce the delay interval
There are several places use udelay(LOOPS_USEC) to wait the status to be changed, but the delay interval is a bit too long, so reduce it to enhance the performance. Signed-off-by: Neil Zhang zhan...@marvell.com --- drivers/usb/gadget/mv_udc_core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c index 75db2c3..9e40f89 100644 --- a/drivers/usb/gadget/mv_udc_core.c +++ b/drivers/usb/gadget/mv_udc_core.c @@ -53,7 +53,7 @@ #define READSAFE_TIMEOUT 1000 #define DTD_TIMEOUT1000 -#define LOOPS_USEC_SHIFT 4 +#define LOOPS_USEC_SHIFT 1 #define LOOPS_USEC (1 LOOPS_USEC_SHIFT) #define LOOPS(timeout) ((timeout) LOOPS_USEC_SHIFT) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7 v2] usb: gadget: mv_udc: avoid sleeping on spinlock
build_dtd() can be called when hold a spinlock, but GFP_KERNEL may cause
dma_pool_alloc() sleep, So we need use GFP_ATOMIC instead of GFP_KERNEL.
But using GFP_ATOMIC may cause failure when allocating memory, add error
handler to handle it.
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
Signed-off-by: Neil Zhang zhan...@marvell.com
---
drivers/usb/gadget/mv_udc_core.c | 52 ++
1 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index c05d340..425a204 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -373,7 +373,7 @@ static struct mv_dtd *build_dtd(struct mv_req *req,
unsigned *length,
* Be careful that no _GFP_HIGHMEM is set,
* or we can not use dma_to_virt
*/
- dtd = dma_pool_alloc(udc-dtd_pool, GFP_KERNEL, dma);
+ dtd = dma_pool_alloc(udc-dtd_pool, GFP_ATOMIC, dma);
if (dtd == NULL)
return dtd;
@@ -706,6 +706,7 @@ mv_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
gfp_t gfp_flags)
struct mv_req *req = container_of(_req, struct mv_req, req);
struct mv_udc *udc = ep-udc;
unsigned long flags;
+ int retval;
/* catch various bogus parameters */
if (!_req || !req-req.complete || !req-req.buf
@@ -753,15 +754,17 @@ mv_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
gfp_t gfp_flags)
/* build dtds and push them to device queue */
if (!req_to_dtd(req)) {
- int retval;
retval = queue_dtd(ep, req);
if (retval) {
spin_unlock_irqrestore(udc-lock, flags);
- return retval;
+ dev_err(udc-dev-dev, Failed to queue dtd\n);
+ goto err_unmap_dma;
}
} else {
spin_unlock_irqrestore(udc-lock, flags);
- return -ENOMEM;
+ dev_err(udc-dev-dev, Failed to dma_pool_alloc\n);
+ retval = -ENOMEM;
+ goto err_unmap_dma;
}
/* Update ep0 state */
@@ -773,6 +776,22 @@ mv_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
gfp_t gfp_flags)
spin_unlock_irqrestore(udc-lock, flags);
return 0;
+
+err_unmap_dma:
+ if (req-mapped) {
+ dma_unmap_single(ep-udc-gadget.dev.parent,
+ req-req.dma, req-req.length,
+ ((ep_dir(ep) == EP_DIR_IN) ?
+ DMA_TO_DEVICE : DMA_FROM_DEVICE));
+ req-req.dma = DMA_ADDR_INVALID;
+ req-mapped = 0;
+ } else
+ dma_sync_single_for_cpu(ep-udc-gadget.dev.parent,
+ req-req.dma, req-req.length,
+ ((ep_dir(ep) == EP_DIR_IN) ?
+ DMA_TO_DEVICE : DMA_FROM_DEVICE));
+
+ return retval;
}
static void mv_prime_ep(struct mv_ep *ep, struct mv_req *req)
@@ -1497,15 +1516,17 @@ udc_prime_status(struct mv_udc *udc, u8 direction, u16
status, bool empty)
}
/* prime the data phase */
- if (!req_to_dtd(req))
+ if (!req_to_dtd(req)) {
retval = queue_dtd(ep, req);
- else{ /* no mem */
+ if (retval) {
+ dev_err(udc-dev-dev,
+ Failed to queue dtd when prime status\n);
+ goto out;
+ }
+ } else{ /* no mem */
retval = -ENOMEM;
- goto out;
- }
-
- if (retval) {
- dev_err(udc-dev-dev, response error on GET_STATUS
request\n);
+ dev_err(udc-dev-dev,
+ Failed to dma_pool_alloc when prime status\n);
goto out;
}
@@ -1513,6 +1534,15 @@ udc_prime_status(struct mv_udc *udc, u8 direction, u16
status, bool empty)
return 0;
out:
+ if (req-mapped) {
+ dma_unmap_single(ep-udc-gadget.dev.parent,
+ req-req.dma, req-req.length,
+ ((ep_dir(ep) == EP_DIR_IN) ?
+ DMA_TO_DEVICE : DMA_FROM_DEVICE));
+ req-req.dma = DMA_ADDR_INVALID;
+ req-mapped = 0;
+ }
+
return retval;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7 v2] usb: gadget: mv_udc: remove unused code
Clean unused code for mv_udc driver. Signed-off-by: Neil Zhang zhan...@marvell.com --- drivers/usb/gadget/mv_udc_core.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c index 9e40f89..c05d340 100644 --- a/drivers/usb/gadget/mv_udc_core.c +++ b/drivers/usb/gadget/mv_udc_core.c @@ -51,7 +51,6 @@ #define EPSTATUS_TIMEOUT 1 #define PRIME_TIMEOUT 1 #define READSAFE_TIMEOUT 1000 -#define DTD_TIMEOUT1000 #define LOOPS_USEC_SHIFT 1 #define LOOPS_USEC (1 LOOPS_USEC_SHIFT) @@ -64,7 +63,6 @@ static const char driver_desc[] = DRIVER_DESC; /* controller device global variable */ static struct mv_udc *the_controller; -int mv_usb_otgsc; static void nuke(struct mv_ep *ep, int status); static void stop_activity(struct mv_udc *udc, struct usb_gadget_driver *driver); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7 v2] usb: gadget: mv_udc: add iso support
From: Chao Xie chao@marvell.com
In order to support iso, we need do the following things:
1. fix length for one dtd
2. allow req contains multiple packets for a ISO transfer
Signed-off-by: Chao Xie chao@marvell.com
Signed-off-by: Yu Xu y...@marvell.com
Signed-off-by: Neil Zhang zhan...@marvell.com
---
drivers/usb/gadget/mv_udc_core.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index 4d3a413..ff6154d 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -355,17 +355,24 @@ done:
return retval;
}
-
static struct mv_dtd *build_dtd(struct mv_req *req, unsigned *length,
dma_addr_t *dma, int *is_last)
{
- u32 temp;
struct mv_dtd *dtd;
struct mv_udc *udc;
+ struct mv_dqh *dqh;
+ u32 temp, mult = 0;
/* how big will this transfer be? */
- *length = min(req-req.length - req-req.actual,
- (unsigned)EP_MAX_LENGTH_TRANSFER);
+ if (usb_endpoint_xfer_isoc(req-ep-ep.desc)) {
+ dqh = req-ep-dqh;
+ mult = (dqh-max_packet_length EP_QUEUE_HEAD_MULT_POS)
+0x3;
+ *length = min(req-req.length - req-req.actual,
+ (unsigned)(mult * req-ep-ep.maxpacket));
+ } else
+ *length = min(req-req.length - req-req.actual,
+ (unsigned)EP_MAX_LENGTH_TRANSFER);
udc = req-ep-udc;
@@ -407,6 +414,8 @@ static struct mv_dtd *build_dtd(struct mv_req *req,
unsigned *length,
if (*is_last !req-req.no_interrupt)
temp |= DTD_IOC;
+ temp |= mult 10;
+
dtd-size_ioc_sts = temp;
mb();
@@ -718,10 +727,6 @@ mv_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
gfp_t gfp_flags)
dev_err(udc-dev-dev, %s, bad ep, __func__);
return -EINVAL;
}
- if (ep-ep.desc-bmAttributes == USB_ENDPOINT_XFER_ISOC) {
- if (req-req.length ep-ep.maxpacket)
- return -EMSGSIZE;
- }
udc = ep-udc;
if (!udc-driver || udc-gadget.speed == USB_SPEED_UNKNOWN)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7 v2] usb: gadget: mv_udc: enable stream mode
According to ChipIdea's reference manual in section 8.5.2 Non-streaming operational mode in device mode, we'd better enable stream mode, especially that ISO endpoints are not supported when the SDIS bit is set. Signed-off-by: Neil Zhang zhan...@marvell.com --- drivers/usb/gadget/mv_udc_core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c index 425a204..4d3a413 100644 --- a/drivers/usb/gadget/mv_udc_core.c +++ b/drivers/usb/gadget/mv_udc_core.c @@ -1082,7 +1082,7 @@ static int udc_reset(struct mv_udc *udc) tmp |= USBMODE_CTRL_MODE_DEVICE; /* turn setup lockout off, require setup tripwire in usbcmd */ - tmp |= USBMODE_SETUP_LOCK_OFF | USBMODE_STREAM_DISABLE; + tmp |= USBMODE_SETUP_LOCK_OFF; writel(tmp, udc-op_regs-usbmode); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 REBASE 6/9] USB: notify phy when root hub port connect change
Dear Richard Zhao,
On Sat, Jul 07, 2012 at 10:56:45PM +0800, Richard Zhao wrote:
Phy may need to change settings when port connect change.
Signed-off-by: Richard Zhao richard.z...@freescale.com
Tested-by: Subodh Nijsure snijs...@grid-net.com
---
drivers/usb/core/hub.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4cc8dc9..2ba9d84 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -20,6 +20,7 @@
#include linux/usb.h
#include linux/usbdevice_fs.h
#include linux/usb/hcd.h
+#include linux/usb/otg.h
#include linux/usb/quirks.h
#include linux/kthread.h
#include linux/mutex.h
@@ -4037,6 +4038,13 @@ static void hub_port_connect_change(struct usb_hub
*hub, int port1,
}
}
+ if (unlikely(hcd-phy !hdev-parent)) {
+ if (portstatus USB_PORT_STAT_CONNECTION)
+ usb_phy_notify_connect(hcd-phy, port1);
+ else
+ usb_phy_notify_disconnect(hcd-phy, port1);
There's another issue. When hcd is removed, notify disconnect is not
called. Is it ok, if I remove the above two line and add below patch:
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1924,6 +1924,11 @@ void usb_disconnect(struct usb_device **pdev)
*/
device_del(udev-dev);
+ if (udev-parent !udev-parent-parent) {
+ struct usb_hcd *hcd = bus_to_hcd(udev-bus);
+ usb_phy_notify_disconnect(hcd-phy, udev-portnum);
+ }
Shouldn't that go before device_del() ?
+
/* Free the device number and delete the parent's children[]
* (or root_hub) pointer.
*/
Thanks
Richard
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg =0x4a0ad080 0x58;
Don;t you need a 'ti,hwmods' entry for this one?
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,273 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
Copyright (C) 2012? Same for the couple of headers below.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham Ikis...@ti.com
+ *
+ * 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.
+ *
+ */
+
+
+static int __devinit omap_usb2_probe(struct platform_device *pdev)
+{
+ struct omap_usb *phy;
+ struct usb_otg *otg;
+ struct resource *res;
+
+ phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy) {
+ dev_err(pdev-dev, unable to allocate memory for USB2 PHY\n);
+ return -ENOMEM;
+ }
+
+ otg = devm_kzalloc(pdev-dev, sizeof(*otg), GFP_KERNEL);
+ if (!otg) {
+ dev_err(pdev-dev, unable to allocate memory for USB OTG\n);
+ return -ENOMEM;
+ }
+
+ phy-dev =pdev-dev;
+
+ phy-phy.dev = phy-dev;
+ phy-phy.label = omap-usb2;
+ phy-phy.set_suspend = omap_usb2_suspend;
+ phy-phy.otg = otg;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+ phy-control_dev_conf = devm_request_and_ioremap(pdev-dev, res);
+ if (phy-control_dev_conf == NULL) {
+ dev_err(pdev-dev, Failed to obtain io memory\n);
+ return -ENXIO;
+ }
+
+ phy-is_suspended= 1;
+ omap_usb_phy_power(phy, 0);
+
+ otg-set_host= omap_usb_set_host;
+ otg-set_peripheral = omap_usb_set_peripheral;
+ otg-set_vbus= omap_usb_set_vbus;
+ otg-start_srp = omap_usb_start_srp;
+ otg-phy =phy-phy;
+
+ phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k);
Why not just use clk_get()? What does devm_clk_get() do?
+ if (IS_ERR(phy-wkupclk)) {
+ dev_err(pdev-dev, unable to get usb_phy_cm_clk32k\n);
+ return PTR_ERR(phy-wkupclk);
+ }
+ clk_prepare(phy-wkupclk);
Ideally clk_prepare() is an extension of clk_enable() and is expected
to be used that way. Not to be clubbed with clk_get(). Same with
clk_unprepare(). Do you do a clk_enable()/_disable() in interrupt/
atomic context?
+
+ usb_add_phy(phy-phy, USB_PHY_TYPE_USB2);
+
+ platform_set_drvdata(pdev, phy);
+
+ pm_runtime_enable(phy-dev);
+
+ return 0;
+}
+
+static int __devexit omap_usb2_remove(struct platform_device *pdev)
+{
+ struct omap_usb *phy = platform_get_drvdata(pdev);
+
+ clk_unprepare(phy-wkupclk);
+ usb_remove_phy(phy-phy);
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+
+static int omap_usb2_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_usb *phy = platform_get_drvdata(pdev);
+
+ clk_disable(phy-wkupclk);
+
+ return 0;
+}
+
+static int omap_usb2_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_usb *phy = platform_get_drvdata(pdev);
+
+ clk_enable(phy-wkupclk);
+
+ return 0;
+}
+
+static const struct dev_pm_ops omap_usb2_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, omap_usb2_runtime_resume,
+ NULL)
+};
+
+#define DEV_PM_OPS (omap_usb2_pm_ops)
+#else
+#define DEV_PM_OPS NULL
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id omap_usb2_id_table[] = {
+ { .compatible = ti,omap-usb2 },
+ {}
+};
+MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
+#else
+#define omap_usb2_id_table NULL;
+#endif
+
+static
Re: [PATCH v1 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 18
drivers/usb/otg/twl6030-usb.c | 45 ++--
2 files changed, 50 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..f293271
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,18 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts when
+ the controller has to act as host and the second interrupt number is the
+ usb interrupt number that raises VBUS interrupts when the controller has to
+ act as device
+ - regulator :supply-name can be vusb or ldousb
+ -supply-name-supply : phandle to the regulator device tree node
+
+twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10;
+ regulator = vusb;
+ vusb-supply =vusb;
This doesn't seem right. Why do you ned a 'regulator' string along
with the phandle?
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..20b7abe 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#define comparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl-features TWL6025_SUBCLASS)
- regulator_name = ldousb;
- else
- regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+ twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
{
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev =pdev-dev;
- pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev =pdev-dev;
+ struct twl4030_usb_data *pdata = dev-platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,28 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-dev =pdev-dev;
twl-irq1= platform_get_irq(pdev, 0);
twl-irq2= platform_get_irq(pdev, 1);
- twl-features= pdata-features;
twl-linkstat= OMAP_MUSB_UNKNOWN;
twl-comparator.set_vbus = twl6030_set_vbus;
twl-comparator.start_srp= twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
+ if (np) {
+ err = of_property_read_string(np, regulator,twl-regulator);
+ if (err 0) {
+ dev_err(pdev-dev, unable to get regulator\n);
+ return err;
+ }
Isn't there a better way for the driver to know which supply to use
instead of DT passing the supply name?
regards,
Rajendra
+ } else if (pdata) {
+ if (pdata-features TWL6025_SUBCLASS)
+ twl-regulator = ldousb;
+ else
+ twl-regulator = vusb;
+ } else {
+ dev_err(pdev-dev, twl6030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -403,12 +411,23 @@ static int __exit twl6030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+ { .compatible =
