[xhci] corrupt urbs after module reload
Hallo Sarah, looks like my adventure with this controller are not finished. Short story: After reloading ath9k_htc module i get some corrupt urbs on adapter side. It was possible to confirm it by debuging ath9k_htc firmware. On the host side i tried to use Wireshark, but at this stage all affected urbs was ok. After reloading xhci_hcd module, my adapter work ok. Right now i was able to reproduce this issue only on: 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: ASUSTeK Computer Inc. Zenbook Prime UX31A Flags: bus master, medium devsel, latency 0, IRQ 41 Memory at f7d0 (64-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: xhci_hcd same adapter with same firmware has no issue with other XHCI controllers, for example: 03:00.0 USB controller: Fresco Logic FL1009 USB 3.0 Host Controller (rev 02) (prog-if 30 [XHCI]) Subsystem: ASUSTeK Computer Inc. Device 1427 Flags: bus master, fast devsel, latency 0, IRQ 19 Memory at de00 (64-bit, non-prefetchable) [size=64K] Memory at de011000 (64-bit, non-prefetchable) [size=4K] Memory at de01 (64-bit, non-prefetchable) [size=4K] Capabilities: Kernel driver in use: xhci_hcd or other EHCI controllers. -- Regards, Oleksij -- 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: Chipidea usb otg support for IMX/MXS (device functionality)
Hi Peter, > > Where can I measure this? > > > > > Two possible reasons: > > > > > > 1. You have not gpio control for vbus toggle when role switches. > > > > This works well. > > > > > 2. Your hardware has some problems that the vbus can't lower than 0.8v. > > > > How can I check that? > > Just measure the voltage of your otg vbus pin. It's 2.5 volt for me. What am I supposed to observe happening there? 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 2/2] [RFC] usb: dwc3: using the maximum_speed to determine if the usb3 phy is needed
On 07:53-20130706, Ruchika Kharwar wrote:
> When the initialization of usb3 phy fails, when enabled in the system
> the dwc3_probe deferral is further qualified by the maximum speed.
> In devices such as dra7xx, there are multiple dwc3 instances where the
> maximum_speed is different between the instances.
indentation.
>
> This patch depends on http://www.spinics.net/lists/linux-usb/msg88627.html
Dependencies must be stated in diffstat - it is better to post a
complete series unless this maybe a standalone - which it seems to be..
just my 2 cents.
>
> Signed-off-by: Ruchika Kharwar
> ---
> drivers/usb/dwc3/core.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 7b98e4f..05f2205 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -460,8 +460,11 @@ static int dwc3_probe(struct platform_device *pdev)
> if (ret == -ENXIO)
> return ret;
>
> - dev_err(dev, "no usb3 phy configured\n");
> - return -EPROBE_DEFER;
> + if (dwc->maximum_speed == USB_SPEED_SUPER) {
> + dev_err(dev, "no usb3 phy configured\n");
> + return -EPROBE_DEFER;
is deferal always the right solution? just curious if one does not
declare the phy node, would'nt there be an opportunity to giveup
earlier?
> + } else
> + dev_dbg(dev, "maximum speed is < super\n");
Checkpatch would have asked you to add {} on both branches of the if
condition ;)
> }
>
> usb_phy_set_suspend(dwc->usb2_phy, 0);
> --
> 1.7.9.5
>
--
Regards,
Nishanth Menon
--
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: musb: dsps: make it work with two instances
Hi Sebastian, On Fri, Jul 5, 2013 at 10:32 AM, Sebastian Andrzej Siewior wrote: > This enables the two musb instances on am335x to work. I like a lot the idea of splitting the DT representation of the two USB instances. The DT binding looks much better this way. After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. Also, FWIW, I think that having a separate USB phy for am35xx would be much better. Nice job! -- Ezequiel -- 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: Repeated disconnects of wired mouse
On Sat, 6 Jul 2013, Larry Keegan wrote:
> Just a thought, but has the way the kernel 'sets-up' a USB mouse
> changed over the months? I mean in a way which would mean different
> numbers in the above usbmon trace? What I'm wondering is if the newer
> kernel could be eeking out different bugs in the mouse's software, and
> that is provoking the disconnect. Is that possible? Or is it genuinely an
> electrical thing? I'm afraid I know zip about USB.
As far as I know, there haven't been any changes in the way a USB mouse
gets initialized. Besides, even if there were, I have never heard of
any setting that would tell the mouse to disconnect itself every 62
seconds! :-)
> > > The other thing which makes me feel that power and EMI are unlikely
> > > to be the cause of the problem is the precise nature of the events.
> > > Here is a snippet from my syslog:
> > >
> > > # tail -f /var/log/messages | grep 'USB disconnect'
> > > 2013-07-06T11:27:19.518567Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 126
> > > 2013-07-06T11:28:21.518556Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 127
> > > 2013-07-06T11:29:23.518567Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 2
> > > 2013-07-06T11:30:25.518562Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 3
> > > 2013-07-06T11:31:27.518568Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 4
> > > 2013-07-06T11:32:29.518567Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 5
> > > 2013-07-06T11:33:31.518568Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 6
> > >
> > > These events occur with surprising regularity. Too regular for it
> > > to be an uncorrelated external event. Three mice, (two Microsoft,
> > > and one other) but all three containing the same PixArt chip all
> > > exhibit the same timing. If this were power droop I'd expect
> > > capacitor component tolerances to cause slightly different timings
> > > on the different mice, or different computers but they are
> > > microsecond perfect.
> >
> > Yes. Obviously this is related to a hardware or software timer. The
> > microsecond perfection may not mean anything, however. Is this bus
> > connected to a UHCI controller? The uhci-hcd driver uses a software
> > timer for detecting port-connect changes; the timer runs at a steady
> > rate of precisely 4 times per second.
>
> Ah ah. I thought the numbers were suspiciously regular. I suppose the
> mice, being 1.5Mbps devices will be connected to the UHCI. The ports
> are wired to the motherboard's Intel ICH7. The port is definitely also
> capable of speaking at 480Mbps.
You didn't say before that your motherboard was Intel. Other brands
use OHCI instead of UHCI, and the ohci-hcd driver uses hardware
interrupts rather than a software timer for detecting port-connect
changes.
> However, I'm not sure this explains the essentially-random behaviour of
> the most of the bus when the mouse is plugged into a USB 2.0 hub. In
With an external hub, the port-status packets are sent based on a
hardware timer that triggers 8 times per second, with great regularity.
> these cases it is my understanding that the controller is EHCI and the
> hub buffers these packets and sends them over the 480Mbps link as if
> they were 'normal' USB 2.0 packets. That implies the mouse is also
> electrically incompatible with my hubs. Umm. I'll look into this.
They aren't electically incompatible, or they wouldn't work at all.
But _something_ is causing them to disconnect.
> > You said the problems began on one of the computers when you upgraded
> > the kernel. Can you try using bisection to find the kernel change
> > that first triggered the problem?
>
> I'm recompiling as we speak.
This seems like the best approach. It wouldn't be surprising to find
that the problem's source lies in some totally unexpected area.
> Thank you very much for your help.
You're welcome.
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: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage with hcd_urb_list_lock
On Sat, 6 Jul 2013, Maarten Lankhorst wrote:
> I didn't even know I still had lockdep on.
> The following lockdep splat happened when I plugged in a usb bluetooth
> dongle, using
> the pre-rc1 3.11 kernel at HEAD b2c311075db
>
> =
> [ INFO: inconsistent lock state ]
> 3.10.0+ #106 Not tainted
> -
> inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> irq/42-xhci_hcd/97 [HC0[0]:SC0[2]:HE1:SE0] takes:
> (hcd_urb_list_lock){?.}, at: []
> usb_hcd_unlink_urb_from_ep+0x28/0x4e
> stack backtrace:
> CPU: 1 PID: 97 Comm: irq/42-xhci_hcd Not tainted 3.10.0+ #106
> Hardware name: Acer Aspire M3985/Aspire M3985, BIOS P01-A1 03/12/2012
> 8210c150 88040834da48 81691af4 0007
> 8804082e20b0 88040834daa8 8168cb10 0002
> 88040001 8804 8100f4f7 88040834dac4
> Call Trace:
> [] dump_stack+0x4f/0x84
> [] print_usage_bug+0x1f5/0x206
> [] ? save_stack_trace+0x2f/0x50
> [] mark_lock+0x276/0x2cf
> [] ? check_usage_forwards+0x12f/0x12f
> [] __lock_acquire+0x5c0/0x1c2e
> [] ? mark_held_locks+0x6d/0x117
> [] ? __slab_free+0x1c7/0x2ed
> [] ? trace_hardirqs_on_caller+0xac/0x1bb
> [] ? trace_hardirqs_on+0xd/0xf
> [] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
> [] lock_acquire+0x87/0x139
> [] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
> [] _raw_spin_lock+0x3b/0x4a
> [] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
> [] usb_hcd_unlink_urb_from_ep+0x28/0x4e
> [] xhci_irq+0x5ac/0x143d
> [] ? _raw_spin_unlock_irq+0x3b/0x5d
> [] ? finish_task_switch+0x7c/0x101
> [] ? finish_task_switch+0x3f/0x101
> [] ? __schedule+0x42a/0x885
> [] ? irq_thread_fn+0x48/0x48
> [] xhci_msi_irq+0x11/0x15
It looks like xhci_msi_irq() needs to call local_irq_save() and
local_irq_restore().
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: Audio I/O parameters
On Sat, Jul 6, 2013 at 9:36 PM, James Stone wrote: > On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern wrote: >> On Sat, 6 Jul 2013, James Stone wrote: >> >>> The output when I try to start jack with 128 frames/period is: >>> >>> /usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 >>> -O512 -S >>> jackdmp 1.9.9.5 >>> Copyright 2001-2005 Paul Davis and others. >>> Copyright 2004-2012 Grame. >>> jackdmp comes with ABSOLUTELY NO WARRANTY >>> This is free software, and you are welcome to redistribute it >>> under certain conditions; see the file COPYING for details >>> no message buffer overruns >>> no message buffer overruns >>> no message buffer overruns >>> JACK server starting in realtime mode with priority 10 >>> audio_reservation_init >>> Acquire audio card Audio0 >>> creating alsa driver ... >>> hw:USB,0|hw:USB,0|128|2|44100|0|0|nomon|swmeter|-|16bit >>> Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 >>> USB at usb-:00:12.2-3, high speed >>> configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods >>> ALSA: final selected sample format for capture: 32bit integer little-endian >>> ALSA: use 2 periods for capture >>> ALSA: final selected sample format for playback: 32bit integer little-endian >>> ALSA: use 2 periods for playback >>> ^CJack main caught signal 2 >>> >>> ..the device is unusable with the lights flashing on and off. Jack >>> then shuts down as seen above. >>> >>> At 256 frames/period it starts OK. >> >> What happens if you run JACK with input only, no audio out? >> >> Alan Stern >> > > It works fine with both input only or output only - down to 16 > frames/period. At 8 frames/period it shows the same behaviour as at > 256 frames/period in duplex - but that is a ridiculously low latency > of 0.2ms, so hardly surprising it won't work. > > I have now got an error message when jack fails to start in duplex mode: > > ALSA: prepare error for playback on "hw:USB,0" (Protocol error) > JackAudioDriver::ProcessAsync: read error, stopping... > > James Sorry - slight misinformation there. I can go down to 16 frames/period for capture only, but for playback only, it will only go down to 128 frames/period. Anything lower: /usr/bin/jackd -dalsa -r44100 -p64 -n2 -Phw:USB,0 -I512 -O512 -S jackdmp 1.9.9.5 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2012 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 audio_reservation_init Acquire audio card Audio0 creating alsa driver ... hw:USB,0|-|64|2|44100|0|0|nomon|swmeter|-|16bit Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 USB at usb-:00:12.2-3, high speed configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback ALSA: poll time out, polled for 2176094 usecs JackAudioDriver::ProcessAsync: read error, stopping... This is a definite reduction in performance compared to earlier kernels. James -- 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: Audio I/O parameters
On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern wrote: > On Sat, 6 Jul 2013, James Stone wrote: > >> The output when I try to start jack with 128 frames/period is: >> >> /usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 -O512 >> -S >> jackdmp 1.9.9.5 >> Copyright 2001-2005 Paul Davis and others. >> Copyright 2004-2012 Grame. >> jackdmp comes with ABSOLUTELY NO WARRANTY >> This is free software, and you are welcome to redistribute it >> under certain conditions; see the file COPYING for details >> no message buffer overruns >> no message buffer overruns >> no message buffer overruns >> JACK server starting in realtime mode with priority 10 >> audio_reservation_init >> Acquire audio card Audio0 >> creating alsa driver ... >> hw:USB,0|hw:USB,0|128|2|44100|0|0|nomon|swmeter|-|16bit >> Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 >> USB at usb-:00:12.2-3, high speed >> configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods >> ALSA: final selected sample format for capture: 32bit integer little-endian >> ALSA: use 2 periods for capture >> ALSA: final selected sample format for playback: 32bit integer little-endian >> ALSA: use 2 periods for playback >> ^CJack main caught signal 2 >> >> ..the device is unusable with the lights flashing on and off. Jack >> then shuts down as seen above. >> >> At 256 frames/period it starts OK. > > What happens if you run JACK with input only, no audio out? > > Alan Stern > It works fine with both input only or output only - down to 16 frames/period. At 8 frames/period it shows the same behaviour as at 256 frames/period in duplex - but that is a ridiculously low latency of 0.2ms, so hardly surprising it won't work. I have now got an error message when jack fails to start in duplex mode: ALSA: prepare error for playback on "hw:USB,0" (Protocol error) JackAudioDriver::ProcessAsync: read error, stopping... James -- 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: Repeated disconnects of wired mouse
On Sat, 6 Jul 2013 09:53:21 -0400 Alan Stern wrote: > Please use Reply-To-All so that your messages get sent to the mailing > list as well as to me. Dear Alan, Sorry! As it happened I just noticed this and was about to re-send it when my mailer crashed... > > On Sat, 6 Jul 2013, Larry Keegan wrote: > > > On Fri, 5 Jul 2013 17:41:25 -0400 > > Alan Stern wrote: > > > On Fri, 5 Jul 2013, Larry Keegan wrote: > > > > > > > Dear Chaps, > > > > > > > > I have a Microsoft Basic Optical mouse. When I used an earlier > > > > kernel (2.6 series) it just worked. However, now that I'm using > > > > 3.4.51 it suffers from USB disconnects and reconnects every 62 > > > > seconds precisely. These disconnects do not occur whilst the > > > > mouse device is open. I have tried two different wired mice in > > > > different USB slots of different computers with different > > > > motherboard types, all to no avail. > > > > > > Can you post a usbmon trace showing some of those disconnects and > > > reconnects? > > > > > > > Dear Alan, > > > > Thank you very much for helping me to diagnose this problem. > > > > The following trace was made by waiting for a disconnect and > > reconnect event to complete, starting cat, waiting for another event > > and killing cat a few seconds afterwards. > > > > The mouse was plugged directly into the socket on the motherboard. > > > > # cat /sys/kernel/debug/usb/usbmon/4u > > e9921c00 2437517512 C Ii:4:001:1 0:128 1 = 04 > > e9921c00 2437517523 S Ii:4:001:1 -115:128 2 < > > e7454480 2437517533 S Ci:4:001:0 s a3 00 0002 0004 4 < > > e7454480 2437517543 C Ci:4:001:0 0 4 = 00010300 > > e7454480 2437517545 S Co:4:001:0 s 23 01 0010 0002 0 > > e7454480 2437517548 C Co:4:001:0 0 0 > > e7454480 2437517549 S Co:4:001:0 s 23 01 0011 0002 0 > > e7454480 2437517551 C Co:4:001:0 0 0 > > e7454900 2437520222 S Ci:4:001:0 s a3 00 0002 0004 4 < > > e7454900 2437520229 C Ci:4:001:0 0 4 = 0001 > > e7454480 2437545511 S Ci:4:001:0 s a3 00 0002 0004 4 < > > e7454480 2437545518 C Ci:4:001:0 0 4 = 0001 > > e4411780 2437571511 S Ci:4:001:0 s a3 00 0002 0004 4 < > > e4411780 2437571517 C Ci:4:001:0 0 4 = 0001 > > e7454480 2437597511 S Ci:4:001:0 s a3 00 0002 0004 4 < > > e7454480 2437597517 C Ci:4:001:0 0 4 = 0001 > > e7454480 2437623509 S Ci:4:001:0 s a3 00 0002 0004 4 < > > e7454480 2437623515 C Ci:4:001:0 0 4 = 0001 > > e9921c00 2439017513 C Ii:4:001:1 0:128 1 = 04 > > e9921c00 2439017518 S Ii:4:001:1 -115:128 2 < > > e7454480 2439017523 S Ci:4:001:0 s a3 00 0002 0004 4 < > > e7454480 2439017528 C Ci:4:001:0 0 4 = 01030100 > ... > > This at least confirms that the disconnects do take place at the > hardware level. They aren't merely a software artifact. > > > I can supply more if you tell me what configurations are most > > interesting. > > No, I don't think usbmon will reveal anything more interesting than > this. > Just a thought, but has the way the kernel 'sets-up' a USB mouse changed over the months? I mean in a way which would mean different numbers in the above usbmon trace? What I'm wondering is if the newer kernel could be eeking out different bugs in the mouse's software, and that is provoking the disconnect. Is that possible? Or is it genuinely an electrical thing? I'm afraid I know zip about USB. > > > > What is interesting is that if I connect either mouse to the > > > > computer via a hub, the timing of the disconnects becomes > > > > irregular and unpredictable. I often find all the devices on > > > > the bus (ie. everything but the root hub) disconnect themselves > > > > at much the same time as the mouse does. Often the mouse > > > > doesn't reconnect to the bus. In any case plugging in either > > > > mouse makes that entire bus distinctly unreliable. This problem > > > > is not peculiar to any particular hub model. > > It certainly sounds like something in the mice is causing all this > disturbance. > > > > > I am using a virgin kernel and am not using a well-known > > > > user-space distribution. I use udev to set up my device nodes, > > > > but that's all. To me, this has a distinct whiff of USB suspend > > > > problems. I have attempted to turn off USB suspend by > > > > repeatedly writing 'on' to all the 'power/control' files > > > > under /sys/bus/usb/devices. It did not help. I also re-compiled > > > > the kernel with power management and usb suspend support > > > > removed. This didn't help either. > > > > > > That's a pretty clear indication that USB suspend is _not_ > > > involved. > > > > > > > I'd appreciate some advice. > > > > > > It's possible this is an electrical problem -- the bus may not > > > provide enough power for all the devices on it. > > > > I doubt it's a power problem because: > > > > - I have tried 3 computers now, each with different motherboards. > > - One of the computers has had no hardware changes. It worked > > before I updated the kernel, but fails now. > > - The co
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage with hcd_urb_list_lock
I didn't even know I still had lockdep on.
The following lockdep splat happened when I plugged in a usb bluetooth dongle,
using
the pre-rc1 3.11 kernel at HEAD b2c311075db
=
[ INFO: inconsistent lock state ]
3.10.0+ #106 Not tainted
-
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
irq/42-xhci_hcd/97 [HC0[0]:SC0[2]:HE1:SE0] takes:
(hcd_urb_list_lock){?.}, at: []
usb_hcd_unlink_urb_from_ep+0x28/0x4e
{IN-HARDIRQ-W} state was registered at:
[] __lock_acquire+0x861/0x1c2e
[] lock_acquire+0x87/0x139
[] _raw_spin_lock+0x3b/0x4a
[] usb_hcd_unlink_urb_from_ep+0x28/0x4e
[] ehci_urb_done+0x5b/0x9c
[] qh_completions+0x311/0x3ca
[] ehci_handle_intr_unlinks+0xad/0x143
[] ehci_hrtimer_func+0x6b/0xbd
[] __run_hrtimer+0x61/0x1f9
[] hrtimer_interrupt+0x10a/0x253
[] local_apic_timer_interrupt+0x38/0x5e
[] smp_apic_timer_interrupt+0x46/0x5b
[] apic_timer_interrupt+0x6f/0x80
irq event stamp: 224
hardirqs last enabled at (224): [] __slab_free+0x1c7/0x2ed
hardirqs last disabled at (223): [] __slab_free+0x139/0x2ed
softirqs last enabled at (206): []
irq_forced_thread_fn+0x49/0x5a
softirqs last disabled at (212): []
irq_forced_thread_fn+0x24/0x5a
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(hcd_urb_list_lock);
lock(hcd_urb_list_lock);
*** DEADLOCK ***
1 lock held by irq/42-xhci_hcd/97:
#0: (&(&xhci->lock)->rlock){+.-...}, at: []
xhci_irq+0x2f/0x143d
stack backtrace:
CPU: 1 PID: 97 Comm: irq/42-xhci_hcd Not tainted 3.10.0+ #106
Hardware name: Acer Aspire M3985/Aspire M3985, BIOS P01-A1 03/12/2012
8210c150 88040834da48 81691af4 0007
8804082e20b0 88040834daa8 8168cb10 0002
88040001 8804 8100f4f7 88040834dac4
Call Trace:
[] dump_stack+0x4f/0x84
[] print_usage_bug+0x1f5/0x206
[] ? save_stack_trace+0x2f/0x50
[] mark_lock+0x276/0x2cf
[] ? check_usage_forwards+0x12f/0x12f
[] __lock_acquire+0x5c0/0x1c2e
[] ? mark_held_locks+0x6d/0x117
[] ? __slab_free+0x1c7/0x2ed
[] ? trace_hardirqs_on_caller+0xac/0x1bb
[] ? trace_hardirqs_on+0xd/0xf
[] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[] lock_acquire+0x87/0x139
[] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[] _raw_spin_lock+0x3b/0x4a
[] ? usb_hcd_unlink_urb_from_ep+0x28/0x4e
[] usb_hcd_unlink_urb_from_ep+0x28/0x4e
[] xhci_irq+0x5ac/0x143d
[] ? _raw_spin_unlock_irq+0x3b/0x5d
[] ? finish_task_switch+0x7c/0x101
[] ? finish_task_switch+0x3f/0x101
[] ? __schedule+0x42a/0x885
[] ? irq_thread_fn+0x48/0x48
[] xhci_msi_irq+0x11/0x15
[] irq_forced_thread_fn+0x2e/0x5a
[] irq_thread+0x10e/0x131
[] ? irq_finalize_oneshot.part.33+0xe0/0xe0
[] ? wake_threads_waitq+0x44/0x44
[] kthread+0xea/0xef
[] ? flush_kthread_work+0x19c/0x19c
[] ret_from_fork+0x7c/0xb0
[] ? flush_kthread_work+0x19c/0x19c
--
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] [RFC] usb: dwc3: using the maximum_speed to determine if the usb3 phy is needed
Hello.
On 06-07-2013 16:53, Ruchika Kharwar wrote:
When the initialization of usb3 phy fails, when enabled in the system
the dwc3_probe deferral is further qualified by the maximum speed.
In devices such as dra7xx, there are multiple dwc3 instances where the
maximum_speed is different between the instances.
This patch depends on http://www.spinics.net/lists/linux-usb/msg88627.html
Don't indent the changelog please.
Signed-off-by: Ruchika Kharwar
---
drivers/usb/dwc3/core.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7b98e4f..05f2205 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -460,8 +460,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret == -ENXIO)
return ret;
- dev_err(dev, "no usb3 phy configured\n");
- return -EPROBE_DEFER;
+ if (dwc->maximum_speed == USB_SPEED_SUPER) {
+ dev_err(dev, "no usb3 phy configured\n");
+ return -EPROBE_DEFER;
+ } else
+ dev_dbg(dev, "maximum speed is < super\n");
According to Documenation/CodingStyle chapter 3, there should be {}
on both arms of the *if* statement if one arm has it.
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
Re: Audio I/O parameters
On Sat, 6 Jul 2013, James Stone wrote: > The output when I try to start jack with 128 frames/period is: > > /usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 -O512 > -S > jackdmp 1.9.9.5 > Copyright 2001-2005 Paul Davis and others. > Copyright 2004-2012 Grame. > jackdmp comes with ABSOLUTELY NO WARRANTY > This is free software, and you are welcome to redistribute it > under certain conditions; see the file COPYING for details > no message buffer overruns > no message buffer overruns > no message buffer overruns > JACK server starting in realtime mode with priority 10 > audio_reservation_init > Acquire audio card Audio0 > creating alsa driver ... > hw:USB,0|hw:USB,0|128|2|44100|0|0|nomon|swmeter|-|16bit > Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 > USB at usb-:00:12.2-3, high speed > configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods > ALSA: final selected sample format for capture: 32bit integer little-endian > ALSA: use 2 periods for capture > ALSA: final selected sample format for playback: 32bit integer little-endian > ALSA: use 2 periods for playback > ^CJack main caught signal 2 > > ..the device is unusable with the lights flashing on and off. Jack > then shuts down as seen above. > > At 256 frames/period it starts OK. What happens if you run JACK with input only, no audio out? 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: Repeated disconnects of wired mouse
Please use Reply-To-All so that your messages get sent to the mailing list as well as to me. On Sat, 6 Jul 2013, Larry Keegan wrote: > On Fri, 5 Jul 2013 17:41:25 -0400 > Alan Stern wrote: > > On Fri, 5 Jul 2013, Larry Keegan wrote: > > > > > Dear Chaps, > > > > > > I have a Microsoft Basic Optical mouse. When I used an earlier > > > kernel (2.6 series) it just worked. However, now that I'm using > > > 3.4.51 it suffers from USB disconnects and reconnects every 62 > > > seconds precisely. These disconnects do not occur whilst the mouse > > > device is open. I have tried two different wired mice in different > > > USB slots of different computers with different motherboard types, > > > all to no avail. > > > > Can you post a usbmon trace showing some of those disconnects and > > reconnects? > > > > Dear Alan, > > Thank you very much for helping me to diagnose this problem. > > The following trace was made by waiting for a disconnect and > reconnect event to complete, starting cat, waiting for another event > and killing cat a few seconds afterwards. > > The mouse was plugged directly into the socket on the motherboard. > > # cat /sys/kernel/debug/usb/usbmon/4u > e9921c00 2437517512 C Ii:4:001:1 0:128 1 = 04 > e9921c00 2437517523 S Ii:4:001:1 -115:128 2 < > e7454480 2437517533 S Ci:4:001:0 s a3 00 0002 0004 4 < > e7454480 2437517543 C Ci:4:001:0 0 4 = 00010300 > e7454480 2437517545 S Co:4:001:0 s 23 01 0010 0002 0 > e7454480 2437517548 C Co:4:001:0 0 0 > e7454480 2437517549 S Co:4:001:0 s 23 01 0011 0002 0 > e7454480 2437517551 C Co:4:001:0 0 0 > e7454900 2437520222 S Ci:4:001:0 s a3 00 0002 0004 4 < > e7454900 2437520229 C Ci:4:001:0 0 4 = 0001 > e7454480 2437545511 S Ci:4:001:0 s a3 00 0002 0004 4 < > e7454480 2437545518 C Ci:4:001:0 0 4 = 0001 > e4411780 2437571511 S Ci:4:001:0 s a3 00 0002 0004 4 < > e4411780 2437571517 C Ci:4:001:0 0 4 = 0001 > e7454480 2437597511 S Ci:4:001:0 s a3 00 0002 0004 4 < > e7454480 2437597517 C Ci:4:001:0 0 4 = 0001 > e7454480 2437623509 S Ci:4:001:0 s a3 00 0002 0004 4 < > e7454480 2437623515 C Ci:4:001:0 0 4 = 0001 > e9921c00 2439017513 C Ii:4:001:1 0:128 1 = 04 > e9921c00 2439017518 S Ii:4:001:1 -115:128 2 < > e7454480 2439017523 S Ci:4:001:0 s a3 00 0002 0004 4 < > e7454480 2439017528 C Ci:4:001:0 0 4 = 01030100 ... This at least confirms that the disconnects do take place at the hardware level. They aren't merely a software artifact. > I can supply more if you tell me what configurations are most > interesting. No, I don't think usbmon will reveal anything more interesting than this. > > > What is interesting is that if I connect either mouse to the > > > computer via a hub, the timing of the disconnects becomes irregular > > > and unpredictable. I often find all the devices on the bus (ie. > > > everything but the root hub) disconnect themselves at much the same > > > time as the mouse does. Often the mouse doesn't reconnect to the > > > bus. In any case plugging in either mouse makes that entire bus > > > distinctly unreliable. This problem is not peculiar to any > > > particular hub model. It certainly sounds like something in the mice is causing all this disturbance. > > > I am using a virgin kernel and am not using a well-known user-space > > > distribution. I use udev to set up my device nodes, but that's all. > > > To me, this has a distinct whiff of USB suspend problems. I have > > > attempted to turn off USB suspend by repeatedly writing 'on' to all > > > the 'power/control' files under /sys/bus/usb/devices. It did not > > > help. I also re-compiled the kernel with power management and usb > > > suspend support removed. This didn't help either. > > > > That's a pretty clear indication that USB suspend is _not_ involved. > > > > > I'd appreciate some advice. > > > > It's possible this is an electrical problem -- the bus may not provide > > enough power for all the devices on it. > > I doubt it's a power problem because: > > - I have tried 3 computers now, each with different motherboards. > - One of the computers has had no hardware changes. It worked before I > updated the kernel, but fails now. > - The computers consist of nothing more than motherboard with > integrated graphics, 35W or 65W Celeron CPU, RAM and single HDD. They > are powered by 250, 450 and 750W power supplies respectively. One of > the computers has a slim-line Radeon graphics card. > - I've also tried connecting the mouse via a Startech USB2EXT4 CAT5 USB > extender. This device is mains-powered on both the local and remote > end. Agreed, lack of power seems unlikely. > EMI is also a possibility - both mains-borne and pick up from the > unscreened mouse leads. Although I've not done any spectrum analysis, I > have tried creating interference (mains and irradiated) and they seem > pretty immune to upset. The other thing is, prior to doing the > interference tests, the tangle of wires hadn
[PATCH 2/2] [RFC] usb: dwc3: using the maximum_speed to determine if the usb3 phy is needed
When the initialization of usb3 phy fails, when enabled in the system
the dwc3_probe deferral is further qualified by the maximum speed.
In devices such as dra7xx, there are multiple dwc3 instances where the
maximum_speed is different between the instances.
This patch depends on http://www.spinics.net/lists/linux-usb/msg88627.html
Signed-off-by: Ruchika Kharwar
---
drivers/usb/dwc3/core.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7b98e4f..05f2205 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -460,8 +460,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret == -ENXIO)
return ret;
- dev_err(dev, "no usb3 phy configured\n");
- return -EPROBE_DEFER;
+ if (dwc->maximum_speed == USB_SPEED_SUPER) {
+ dev_err(dev, "no usb3 phy configured\n");
+ return -EPROBE_DEFER;
+ } else
+ dev_dbg(dev, "maximum speed is < super\n");
}
usb_phy_set_suspend(dwc->usb2_phy, 0);
--
1.7.9.5
--
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/2] usb: dwc3: adapt to use dr_mode device tree helper
This patch adapts the dwc3 to use the device tree helper
"of_usb_get_dr_mode" for the mode of operation of the dwc3 instance
being probed.
Signed-off-by: Ruchika Kharwar
---
drivers/usb/dwc3/core.c | 51 +--
drivers/usb/dwc3/core.h |5 -
2 files changed, 27 insertions(+), 29 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..7b98e4f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -517,14 +517,17 @@ static int dwc3_probe(struct platform_device *pdev)
}
if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
- mode = DWC3_MODE_HOST;
+ mode = USB_DR_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
- mode = DWC3_MODE_DEVICE;
+ mode = USB_DR_MODE_PERIPHERAL;
else
- mode = DWC3_MODE_DRD;
+ mode = of_usb_get_dr_mode(node);
+
+ if (mode == USB_DR_MODE_UNKNOWN)
+ mode = USB_DR_MODE_OTG;
switch (mode) {
- case DWC3_MODE_DEVICE:
+ case USB_DR_MODE_PERIPHERAL:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
ret = dwc3_gadget_init(dwc);
if (ret) {
@@ -532,7 +535,7 @@ static int dwc3_probe(struct platform_device *pdev)
goto err2;
}
break;
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
ret = dwc3_host_init(dwc);
if (ret) {
@@ -540,7 +543,7 @@ static int dwc3_probe(struct platform_device *pdev)
goto err2;
}
break;
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_OTG:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
ret = dwc3_host_init(dwc);
if (ret) {
@@ -572,13 +575,13 @@ static int dwc3_probe(struct platform_device *pdev)
err3:
switch (mode) {
- case DWC3_MODE_DEVICE:
+ case USB_DR_MODE_PERIPHERAL:
dwc3_gadget_exit(dwc);
break;
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
dwc3_host_exit(dwc);
break;
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_OTG:
dwc3_host_exit(dwc);
dwc3_gadget_exit(dwc);
break;
@@ -612,13 +615,13 @@ static int dwc3_remove(struct platform_device *pdev)
dwc3_debugfs_exit(dwc);
switch (dwc->mode) {
- case DWC3_MODE_DEVICE:
+ case USB_DR_MODE_PERIPHERAL:
dwc3_gadget_exit(dwc);
break;
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
dwc3_host_exit(dwc);
break;
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_OTG:
dwc3_host_exit(dwc);
dwc3_gadget_exit(dwc);
break;
@@ -643,11 +646,11 @@ static int dwc3_prepare(struct device *dev)
spin_lock_irqsave(&dwc->lock, flags);
switch (dwc->mode) {
- case DWC3_MODE_DEVICE:
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
dwc3_gadget_prepare(dwc);
/* FALLTHROUGH */
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
default:
dwc3_event_buffers_cleanup(dwc);
break;
@@ -666,11 +669,11 @@ static void dwc3_complete(struct device *dev)
spin_lock_irqsave(&dwc->lock, flags);
switch (dwc->mode) {
- case DWC3_MODE_DEVICE:
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
dwc3_gadget_complete(dwc);
/* FALLTHROUGH */
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
default:
dwc3_event_buffers_setup(dwc);
break;
@@ -687,11 +690,11 @@ static int dwc3_suspend(struct device *dev)
spin_lock_irqsave(&dwc->lock, flags);
switch (dwc->mode) {
- case DWC3_MODE_DEVICE:
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
dwc3_gadget_suspend(dwc);
/* FALLTHROUGH */
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
default:
/* do nothing */
break;
@@ -720,11 +723,11 @@ static int dwc3_resume(struct device *dev)
dwc3_writel(dwc->regs, DWC3_GCTL, dwc->gctl);
switch (dwc->mode) {
- case DWC3_MODE_DEVICE:
- case DWC3_MODE_DRD:
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
dwc3_gadget_resume(dwc);
/* FALLTHROUGH */
- case DWC3_MODE_HOST:
+ case USB_DR_MODE_HOST:
default:
/* do nothing */
break;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3
Re: Audio I/O parameters
On Sat, Jul 6, 2013 at 10:36 AM, James Stone wrote: > On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch wrote: >> Alan Stern wrote: >>> The first half is audio-out only. About 2 seconds after the start, the >>> audio-in stream starts up. After 2 URBs (2 ms) of data, everything >>> is shut down for no apparent reason -- there were no I/O errors. >>> [...] >>> I can't tell whether all these starts and stops are caused by JACK or >>> by the ALSA layer, let alone figure out the reason for them. >> >> Two URBs is the Jack buffer size, isn't it? Does Jack complain? >> >> James, pleasy try running aplay and arecord at the same time; something >> like this: >> >> aplay -D hw:x -t raw -c 4 -f S32_LE -r 44100 --period-size=128 >> --buffer-size=256 /dev/zero & >> arecord -D hw:x-c 2 -f S32_LE -r 44100 --period-size=128 >> --buffer-size=256 test.wav >> > > Yes - this works fine, without issue. (I assumed you wanted me to run these without jack running?) The output when I try to start jack with 128 frames/period is: /usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 -O512 -S jackdmp 1.9.9.5 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2012 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 audio_reservation_init Acquire audio card Audio0 creating alsa driver ... hw:USB,0|hw:USB,0|128|2|44100|0|0|nomon|swmeter|-|16bit Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4 USB at usb-:00:12.2-3, high speed configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback ^CJack main caught signal 2 ..the device is unusable with the lights flashing on and off. Jack then shuts down as seen above. At 256 frames/period it starts OK. James -- 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: Audio I/O parameters
On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch wrote: > Alan Stern wrote: >> The first half is audio-out only. About 2 seconds after the start, the >> audio-in stream starts up. After 2 URBs (2 ms) of data, everything >> is shut down for no apparent reason -- there were no I/O errors. >> [...] >> I can't tell whether all these starts and stops are caused by JACK or >> by the ALSA layer, let alone figure out the reason for them. > > Two URBs is the Jack buffer size, isn't it? Does Jack complain? > > James, pleasy try running aplay and arecord at the same time; something > like this: > > aplay -D hw:x -t raw -c 4 -f S32_LE -r 44100 --period-size=128 > --buffer-size=256 /dev/zero & > arecord -D hw:x-c 2 -f S32_LE -r 44100 --period-size=128 > --buffer-size=256 test.wav > Yes - this works fine, without issue. -- 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: [xhci] null pointer dereference on ring_doorbell_for_active_rings
Hi Sarah,
thanks you or who ever fixed this issue. With latest wireless-testing
i can't reproduce my crash any more. Instead i get this messages:
[ 4510.621603] ath9k_htc: Driver unloaded
[ 4516.407764] usb 3-2: reset high-speed USB device number 4 using xhci_hcd
[ 4516.430175] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39c00
[ 4516.430179] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39c40
[ 4516.430181] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39c80
[ 4516.430183] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39cc0
[ 4516.430185] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39d00
[ 4516.430186] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
with disabled ep 880113f39d40
[ 4516.430855] usb 3-2: ath9k_htc: Firmware htc_9271.fw requested
[ 4516.431139] usbcore: registered new interface driver ath9k_htc
Am 11.06.2013 19:34, schrieb Sarah Sharp:
On Mon, Jun 10, 2013 at 08:55:56AM +0200, Oleksij Rempel wrote:
Hello all,
i'm working on usb_autosuspend for ath9k_htc and triggered this
oops. Currently i do not know if real bug is in ath9k_htc or in
xhci. Same adapter with same kernel and my patches work fine on ehci
host... so may be it is xhci.
Which kernel version is this oops on? I suspect it's an xHCI issue.
Please turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG and
send me dmesg, from the beginning of connecting the device to when it is
suspended and then resumed. That will be a lot of output, so feel free
to compress it.
Sarah Sharp
i get oops on this line:
426 static void ring_doorbell_for_active_rings(struct xhci_hcd *xhci,
427 unsigned int slot_id,
428 unsigned int ep_index)
429 {
430 unsigned int stream_id;
431 struct xhci_virt_ep *ep;
432
433 ep = &xhci->devs[slot_id]->eps[ep_index];
^^^ ^^^
changes for ath9k_htc are in attachment and photo of oops here:
https://plus.google.com/u/0/102032716864870215256/posts/a9d8nFsLhYK
--
Regards,
Oleksij
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f5dda84..3d74575 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1368,6 +1368,7 @@ static struct usb_driver ath9k_hif_usb_driver = {
.suspend = ath9k_hif_usb_suspend,
.resume = ath9k_hif_usb_resume,
.reset_resume = ath9k_hif_usb_resume,
+ .supports_autosuspend = 1,
#endif
.id_table = ath9k_hif_usb_ids,
.soft_unbind = 1,
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..20be8a1 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -905,6 +905,7 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
struct ath_hw *ah = priv->ah;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_channel *curchan = hw->conf.chandef.chan;
+ struct hif_device_usb *hif_dev = priv->htc->hif_dev;
struct ath9k_channel *init_channel;
int ret = 0;
enum htc_phymode mode;
@@ -917,6 +918,14 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
"Starting driver with initial channel: %d MHz\n",
curchan->center_freq);
+ ret = usb_autopm_get_interface(hif_dev->interface);
+ if (ret < 0) {
+ ath_err(common,
+ "Unable wake up hardware\n");
+ mutex_unlock(&priv->mutex);
+ return ret;
+ }
+
/* Ensure that HW is awake before flushing RX */
ath9k_htc_setpower(priv, ATH9K_PM_AWAKE);
WMI_CMD(WMI_FLUSH_RECV_CMDID);
@@ -972,6 +981,7 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
{
struct ath9k_htc_priv *priv = hw->priv;
struct ath_hw *ah = priv->ah;
+ struct hif_device_usb *hif_dev = priv->htc->hif_dev;
struct ath_common *common = ath9k_hw_common(ah);
int ret __attribute__ ((unused));
u8 cmd_rsp;
@@ -1022,6 +1032,8 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
set_bit(OP_INVALID, &priv->op_flags);
+ usb_autopm_put_interface(hif_dev->interface);
+
ath_dbg(common, CONFIG, "Driver halt\n");
mutex_unlock(&priv->mutex);
}
--
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
--
Regards,
Oleksij
--
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.ht
Re: Audio I/O parameters
Alan Stern wrote: > The first half is audio-out only. About 2 seconds after the start, the > audio-in stream starts up. After 2 URBs (2 ms) of data, everything > is shut down for no apparent reason -- there were no I/O errors. > [...] > I can't tell whether all these starts and stops are caused by JACK or > by the ALSA layer, let alone figure out the reason for them. Two URBs is the Jack buffer size, isn't it? Does Jack complain? James, pleasy try running aplay and arecord at the same time; something like this: aplay -D hw:x -t raw -c 4 -f S32_LE -r 44100 --period-size=128 --buffer-size=256 /dev/zero & arecord -D hw:x-c 2 -f S32_LE -r 44100 --period-size=128 --buffer-size=256 test.wav Regards, Clemens -- 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
Announcing libusbx-1.0.16-rc3
Hi All, I'm very happy to announce libusbx-1.0.16-rc3. Changes since 1.0.16-rc2: - * Improve topology API docs (#95) * Make libusb_hotplug_deregister_callback() wake-up libusb_handle_events() * Document how to use an event handling thread, especially how to stop this thread on exit Changes since 1.0.16-rc1: - * Fix crash on exit on openbsd, netbsd & wince * Logging now use a single write call per log-message, avoiding log-message "interlacing" when using multiple threads. * Do not use uninitialized memory for auto_detach_kernel_driver Highlights of changes since 1.0.15: --- * As Nathan Hjelm already announced in his "libusb and libusbx merging" mail, Nathan has taken over libusb maintenance and this release is a combined effort between the libusb and libusbx projects! * Hotplug support for Darwin and Linux * Superspeed endpoint companion and BOS descriptor support * We finally have a libusb_strerror API You can find 1.0.16-rc2 docs including all the new API-s here: http://people.fedoraproject.org/~jwrdegoede/libusb-reference/ You can download the 1.0.16-rc2 tarbal here: http://downloads.sourceforge.net/libusbx/libusbx-1.0.16-rc2.tar.bz2 Please give it a thorough testing, and report any issues you find. For those interested the full ChangeLog is below. Regards, Hans 2013-07-05: v1.0.16-rc3 * Add hotplug support for Darwin and Linux (#9) * Add superspeed endpoint companion descriptor support (#15) * Add BOS descriptor support (#15) * Make descriptor parsing code more robust * New libusb_get_port_numbers API, this is libusb_get_port_path without the unnecessary context parameter, libusb_get_port_path is now deprecated * New libusb_strerror API (#14) * New libusb_set_auto_detach_kernel_driver API (#17) * Improve topology API docs (#95) * Logging now use a single write call per log-message, avoiding log-message "interlacing" when using multiple threads. * Android: use Android logging when building on Android (#101) * Darwin: make libusb_reset reenumerate device on descriptors change (#89) * Darwin: add support for the LIBUSB_TRANSFER_ADD_ZERO_PACKET flag (#91) * Darwin: add a device cache (#112, #114) * Examples: Add sam3u_benchmark isochronous example by Harald Welte (#109) * Many other bug fixes and improvements The (#xx) numbers are libusbx issue numbers, see ie: https://github.com/libusbx/libusbx/issues/9 -- 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
