Re: Fwd: Re: [alsa-devel] no reset_resume for driver snd-usb-audio for logitech headset H600
At Sun, 19 Jan 2014 21:30:58 +0100,
baum...@hotmail.com wrote:
Hello,
there must be a misunderstanding;
There is a functional change, because with the line/patch .reset_resume =
usb_audio_resume, the mixer of the usb headset was not removed during
suspend/resume and so the master channel in KDE Mixer was not changed
(Headset), which is the correct behaviour.
Without the line .reset_resume = usb_audio_resume, in /sound/usb/card.c,
the mixer was removed during suspend/resume and re-added, and so the master
channel changed in KDE Mixer to the default onboard audio.
I have tested kernel 3.13rc8, and as you mentioned, the
reset_resume-messages are gone.
But the behaviour of removing the mixer of the usb_audio_headset occurs,
which is, in my opinion, not the correct behaviour, because the chosen master
channel/mixer should stay after suspend/resume.
Could you please take a look at the issue again.
Simply adding usb_audio-resume to reset_resume ops doesn't work
properly as Clemens already suggested. It misses the recovery of the
current mixer values. This might work in some cases like S3 (where
the device is kept more or less powered on), but it'll be definitely
broken in some cases like S4.
Takashi
Thanks, Bernhard
On 2014-01-13 10:55, Takashi Iwai wrote:
At Sat, 11 Jan 2014 11:08:39 +0100,
The reset_resume kernel message was known to be harmless, and now
it's degraded as a debug message. That's the only change, so there is
no functional change.
That being said, you just need to ignore the kernel messages in the
old kernels. Or, feel free to submit the commit [0a56b4fa6844: USB:
change dev_warn about missing reset-resume to dev_dbg] to stable
kernel.
Takashi
baum...@hotmail.com wrote:
FWD:
Any news to the snd-usb-audio issue?
Thanks, Bernhard
Old Message:
-
I have tested the patch with kernel 3.12.0 with suspend and hibernate, and
the problem is gone.
No messages no reset_resume for driver snd-usb-audio? or other negative
effects/messages.
After resume, the usb_audio_device (Headset) is the master channel in KDE
Mixer, as it should be.
= So the problem is solved for me.
Can you please add the patch to the latest kernels and LTS-kernels or
whitelist the workaround for my device (ID 046d:0a29 Logitech, Inc. H600
[Wireless Headset])
Thanks, Bernhard
On 2013-10-20 23:35, Takashi Iwai wrote:
At Sun, 20 Oct 2013 23:18:13 +0200,
baum...@hotmail.com wrote:
On 2013-10-09 11:16 (CEST,UTC+2), Takashi Iwai wrote:
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 9d9de8d..c591a83 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -747,6 +747,7 @@ static struct usb_driver usb_audio_driver = {
.disconnect = usb_audio_disconnect,
.suspend = usb_audio_suspend,
.resume = usb_audio_resume,
+.reset_resume = usb_audio_resume,
.id_table = usb_audio_ids,
.supports_autosuspend = 1,
};
Shall I add the line in b/sound/usb/card.c and try it? Which kernel
version shall I use?
It doesn't matter which kernel version is.
The error message should disappear, but I don't know whether any other
positive effect you get. As Clemens pointed, there can be some
negative effects by this, so it cannot be taken as is. But at least,
it'd be good to know the result...
thanks,
Takashi
--
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 v5 2/9] mfd: omap-usb-host: Get clocks based on hardware revision
On 01/10/2014 04:26 PM, Lee Jones wrote:
On Fri, 10 Jan 2014, Arnd Bergmann wrote:
On Friday 10 January 2014, Lee Jones wrote:
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap-ehci_logic_fck = omap-init_60m_fclk = ERR_PTR(-EINVAL);
+ omap-utmi_p1_gfclk = omap-utmi_p2_gfclk = ERR_PTR(-EINVAL);
+ omap-xclk60mhsp1_ck = omap-xclk60mhsp2_ck = ERR_PTR(-EINVAL);
I don't think this is the correct error code.
-EINVAL means 'invalid parameter'.
You probably want -ENODEV or -ENOSYS ('function not implemented'
probably isn't ideal either tbh, but you get the idea). Perhaps you
can set them as NULL and check for IS_ERR_OR_NULL() instead?
I think ENODEV is ok here, I'd much prefer this over IS_ERR_OR_NULL().
Sounds good to me.
OK. Will fix.
cheers,
-roger
--
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 v5 3/9] mfd: omap-usb-host: Update DT clock binding information
On 01/10/2014 12:11 PM, Lee Jones wrote: On Thu, 09 Jan 2014, Roger Quadros wrote: The omap-usb-host driver expects certained named clocks. Add this information to the DT binding document. Use clock names as per function for reference clocks. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++ drivers/mfd/omap-usb-host.c| 6 +++--- 2 files changed, 26 insertions(+), 3 deletions(-) Please don't mix up binding changes with code ones. Separate patch please. OK. cheers, -roger -- 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
. I want to transfer an abandoned
Hi friend I am a banker in IDB BANK. I want to transfer an abandoned USD5. 5Million to your Bank account. 40/percent will be your share. No risk involved but keep it as secret.Contact me for more details.Please I will like you to reply. thank you,mr.sinzogan chabi. -- 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 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
From: On 01/17/2014 06:34 AM, David Laight wrote: Can you try the patch I posted that stops the ownership on LINK TRBs being changed before that on the linked-to TRB? Sadly, the patch didn't fix the ASMedia lockup behavior, however :( I did notice that the lockup occurred only when copying *to* the usb3 drive, and not when copying from it. I think that may be new behavior but I can't swear to it. If the behaviour has changed then the fix is on the right lines. If reads used to lock up, and don't with the patch then that is an improvement. It might be that the tx issue is actually a different 'bug'. Just to confirm, here are the first few lines of the patch I used. Please let me know if it's the wrong patch: ... + + field4 = (field4 amp; ~TRB_CYCLE) | ring-gt;cycle_state; + if (trb == amp;ring-gt;enqueue_first-gt;generic) + field4 ^= TRB_CYCLE; + trb-gt;field[0] = cpu_to_le32(field1); That looks like my earlier 'test' patch. The fuller patch is http://article.gmane.org/gmane.linux.usb.general/101784 There shouldn't be any difference in the way the chip is driven, the later patch just rips out a load of code that is no longer needed. Mostly it simplifies the way the ownership of ring entries is passed to the hardware. David
RE: [PATCH] xhci: make warnings greppable
From: Sarah Sharp This is fixed in the revised patch, David. Please read through the entire thread before commenting, thanks. Sorry, I should have noticed that you said that you'd applied the 'checkpatch' fixes. I'm more or less forced to read these lists with outlook, it makes looking at the entire thread almost impossible. I might have to subscribe from a home address where I can use mutt. David -- 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: gadgetfs USB2.0 Chapter 9 Tests: Test after Addressed State fails
Hello! I have a question regarding the user space testapplication for FunctionFS (http://stuff.mit.edu/afs/sipb/contrib/linux/tools/usb/ffs-test.c). The struct descriptors that contains the header and the fs and hs descriptors has only interface and endpoint descriptors. Those are written to ep0. I understand that device and config descriptor are added by the FunctionFS module? I tried adding them to the descriptor struct and increasing fs_count and hs_count in the header filed by 2, but the write() on ep0 then returns -1: ffs-test: crit: ep0: write: descriptors: (-22) Invalid argument. Is it possible to pass my own device and config descriptor to the module or do I have to patch the module? Thanks! -- 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: AM335x USB DMA seems broken on ISOC URBs
On 01/18/2014 04:12 PM, Daniel Mack wrote: On 01/17/2014 05:27 PM, Ezequiel Garcia wrote: On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: While doing some experiments with the stk1160 driver (for Easycap TV video capture devices), ran into problems using v3.13-rc4. The problem is that the stk1160 IRQ handler receives no URBs at all. [...] Let me know if you find anything - I hope to find some time to do similar tests on AM33xx based hardware. I tried using an USB headset connected to a AM33xx based board, using kernel v3.13. The good news is that aplay gives me sound, so there's nothing generally wrong with isochronous streams on musb_dsps/cppi41. I can also do some simple 'arecord | aplay' loopback, and I can hear the microphone signal, but the stream breaks down after a couple of seconds, showing the following error: [ 433.671757] ALSA sound/core/pcm_lib.c:1945 capture write error (DMA or IRQ trouble?) Also, when tearing down the aplay stream, the cppi41 driver spits a number of the warnings below. Sebastian, do you have any pending patches that might be worth testing? Thanks, Daniel [ 340.255651] [ cut here ] [ 340.262828] WARNING: CPU: 0 PID: 112 at drivers/dma/cppi41.c:605 cppi41_dma_control+0x2a8/0x2d4() [ 340.272086] Modules linked in: [ 340.287140] CPU: 0 PID: 112 Comm: aplay Tainted: GW 3.13.0-00051-gff62d1c #1661 [ 340.295798] [c00137b8] (unwind_backtrace+0x0/0xf4) from [c001158c] (show_stack+0x10/0x14) [ 340.304712] [c001158c] (show_stack+0x10/0x14) from [c0037154] (warn_slowpath_common+0x6c/0x84) [ 340.314070] [c0037154] (warn_slowpath_common+0x6c/0x84) from [c0037208] (warn_slowpath_null+0x1c/0x24) [ 340.324153] [c0037208] (warn_slowpath_null+0x1c/0x24) from [c02b50d8] (cppi41_dma_control+0x2a8/0x2d4) [ 340.334255] [c02b50d8] (cppi41_dma_control+0x2a8/0x2d4) from [c0375f0c] (cppi41_dma_channel_abort+0xcc/0) [ 340.344976] [c0375f0c] (cppi41_dma_channel_abort+0xcc/0x140) from [c037187c] (musb_cleanup_urb.isra.16+0) [ 340.356147] [c037187c] (musb_cleanup_urb.isra.16+0x58/0x11c) from [c0371b80] (musb_urb_dequeue+0xe8/0x12) [ 340.366595] [c0371b80] (musb_urb_dequeue+0xe8/0x128) from [c035aa74] (unlink1+0x2c/0x110) [ 340.375497] [c035aa74] (unlink1+0x2c/0x110) from [c035b2e0] (usb_hcd_unlink_urb+0x50/0xc4) [ 340.384496] [c035b2e0] (usb_hcd_unlink_urb+0x50/0xc4) from [c03db53c] (deactivate_urbs+0xd8/0xf4) [ 340.394126] [c03db53c] (deactivate_urbs+0xd8/0xf4) from [c03dc614] (snd_usb_endpoint_stop+0x30/0x70) [ 340.404032] [c03dc614] (snd_usb_endpoint_stop+0x30/0x70) from [c03e3d40] (stop_endpoints+0x70/0x88) [ 340.413843] [c03e3d40] (stop_endpoints+0x70/0x88) from [c03e3ea0] (snd_usb_substream_playback_trigger+0x) [ 340.424836] [c03e3ea0] (snd_usb_substream_playback_trigger+0x9c/0xb8) from [c03cdb40] (snd_pcm_do_stop+0) [ 340.435917] [c03cdb40] (snd_pcm_do_stop+0x54/0x58) from [c03cd768] (snd_pcm_action_single+0x38/0x78) [ 340.445816] [c03cd768] (snd_pcm_action_single+0x38/0x78) from [c03cd970] (snd_pcm_drop+0x6c/0xc4) [ 340.455443] [c03cd970] (snd_pcm_drop+0x6c/0xc4) from [c03cf22c] (snd_pcm_common_ioctl1+0xc90/0x109c) [ 340.465344] [c03cf22c] (snd_pcm_common_ioctl1+0xc90/0x109c) from [c03cf7f0] (snd_pcm_playback_ioctl1+0x1) [ 340.476434] [c03cf7f0] (snd_pcm_playback_ioctl1+0x1b8/0x4b0) from [c00e7a60] (do_vfs_ioctl+0x3fc/0x5f0) [ 340.486607] [c00e7a60] (do_vfs_ioctl+0x3fc/0x5f0) from [c00e7cc4] (SyS_ioctl+0x70/0x80) [ 340.495331] [c00e7cc4] (SyS_ioctl+0x70/0x80) from [c000e340] (ret_fast_syscall+0x0/0x48) [ 340.504136] ---[ end trace 521a83c0d2567bbb ]--- -- 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 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
From: walt On 01/17/2014 06:34 AM, David Laight wrote: Can you try the patch I posted that stops the ownership on LINK TRBs being changed before that on the linked-to TRB? Please disregard my earlier post about the patch not applying cleanly. That was the usual html corruption, so I found the original on the usb list and it was okay. Sadly, the patch didn't fix the ASMedia lockup behavior, however :( I did notice that the lockup occurred only when copying *to* the usb3 drive, and not when copying from it. I think that may be new behavior but I can't swear to it. Consistent with another report that says that ethernet worked provided that TSO was disabled (ie no sg tx). (Without the patch to delay he ownership change on link trbs it didn't work at all.) A guess... In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead of xhci_td_remainder(). You can try that on top of either of my other patches. David
Re: AM335x USB DMA seems broken on ISOC URBs
On Mon, Jan 20, 2014 at 12:15:40PM +0100, Daniel Mack wrote: On 01/18/2014 04:12 PM, Daniel Mack wrote: On 01/17/2014 05:27 PM, Ezequiel Garcia wrote: On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: While doing some experiments with the stk1160 driver (for Easycap TV video capture devices), ran into problems using v3.13-rc4. The problem is that the stk1160 IRQ handler receives no URBs at all. [...] Let me know if you find anything - I hope to find some time to do similar tests on AM33xx based hardware. I tried using an USB headset connected to a AM33xx based board, using kernel v3.13. The good news is that aplay gives me sound, so there's nothing generally wrong with isochronous streams on musb_dsps/cppi41. Hm.. interesting. I wonder what's the difference between those URBs and the video URBs involved in stk1160 operation. Maybe the size of each buffer transfered? Can anybody bring some light on this? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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: EHCI host broken -- interrupts disabled
Try to apply this patch to kernel 3.8.0. Make sure the ehci can work fine and lspci show that PCI_COMMAND_INTX_DISABLE is 0. The patch can resolved this issue. #lspci -vv 00:1d.0 USB controller: Intel Corporation Device 0f34 (rev 0a) (prog-if 20 [EHCI]) Subsystem: Intel Corporation Device 7270 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 0: Memory at 90612000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: ehci-pci dmesg: [1.014556] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.014559] ehci-pci: EHCI PCI platform driver [1.014612] ehci-pci :00:1d.0: setting latency timer to 64 [1.014618] ehci-pci :00:1d.0: EHCI Host Controller [1.014629] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1 [1.014652] ehci-pci :00:1d.0: debug port 2 [1.018562] ehci-pci :00:1d.0: cache line size of 64 is not supported [1.018594] ehci-pci :00:1d.0: irq 23, io mem 0x90612000 [1.029238] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.029274] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.029279] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.029283] usb usb1: Product: EHCI Host Controller [1.029286] usb usb1: Manufacturer: Linux 3.8.13.13-pci ehci_hcd [1.029290] usb usb1: SerialNumber: :00:1d.0 [1.029469] hub 1-0:1.0: USB hub found [1.029785] ehci-platform: EHCI generic platform driver [1.340641] usb 1-1: new high-speed USB device number 2 using ehci-pci [1.473442] usb 1-1: New USB device found, idVendor=8087, idProduct=07e6 [1.473447] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [1.475095] hub 1-1:1.0: USB hub found [1.749587] usb 1-1.2: new high-speed USB device number 3 using ehci-pci [1.841046] usb 1-1.2: New USB device found, idVendor=05e3, idProduct=0608 [1.841052] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [1.841056] usb 1-1.2: Product: USB2.0 Hub [1.841469] hub 1-1.2:1.0: USB hub found [2.115558] usb 1-1.2.1: new high-speed USB device number 4 using ehci-pci [2.208321] usb 1-1.2.1: New USB device found, idVendor=05e3, idProduct=0608 [2.208327] usb 1-1.2.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [2.208331] usb 1-1.2.1: Product: USB2.0 Hub [2.209113] hub 1-1.2.1:1.0: USB hub found [2.283104] usb 1-1.2.3: new low-speed USB device number 5 using ehci-pci [2.378487] usb 1-1.2.3: New USB device found, idVendor=03f0, idProduct=0c4a [2.378492] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [2.378496] usb 1-1.2.3: Product: HP [2.378500] usb 1-1.2.3: Manufacturer: HP [2.385945] usbcore: registered new interface driver usbhid [2.385950] usbhid: USB HID core driver [ 11.550722] input: HP HP as /devices/pci:00/:00:1d.0/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/input/input5 [ 11.550963] hid-generic 0003:03F0:0C4A.0001: input,hidraw0: USB HID v1.11 Mouse [HP HP] on usb-:00:1d.0-1.2.3/input0 Jamie -- 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 4/6] phy-rcar-usb-gen2: add device tree support
On 20/01/14 12:18, Sergei Shtylyov wrote:
Hello.
On 18-01-2014 19:03, Ben Dooks wrote:
Add support for the phy-rcar-gen2-usb driver to be probed from device
tree.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
Reviewed-by: Ian Molton ian.mol...@codethink.co.uk
---
Cc: linux-usb@vger.kernel.org (open list:USB PHY LAYER)
Cc: linux...@vger.kernel.org (open list:ARM/SHMOBILE ARM...)
Cc: Magnus Damm magnus.d...@gmail.com (supporter:ARM/SHMOBILE ARM...)
Cc: Simon Horman ho...@verge.net.au (supporter:ARM/SHMOBILE ARM...)
Cc: devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND...)
---
drivers/usb/phy/phy-rcar-gen2-usb.c | 35
++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-rcar-gen2-usb.c
b/drivers/usb/phy/phy-rcar-gen2-usb.c
index db3ab34..906b74b 100644
--- a/drivers/usb/phy/phy-rcar-gen2-usb.c
+++ b/drivers/usb/phy/phy-rcar-gen2-usb.c
[...]
@@ -203,16 +212,31 @@ static int rcar_gen2_usb_phy_probe(struct
platform_device *pdev)
[...]
+if (of_id) {
+int len = 0;
+
+if (of_get_property(dev-of_node, renesas,usb0-hs, len))
+priv-ugctrl2 = USBHS_UGCTRL2_USB0_HS;
+else
+priv-ugctrl2 = USBHS_UGCTRL2_USB0_PCI;
+
+if (of_get_property(dev-of_node, renesas,usb2-ss, len))
You can use of_property_read_bool() in both cases as both these
props are boolean I guess. It's more handy.
Thanks, missed that one, will sort that out.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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 v3] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v2:
1) Added support for multiple PHYs (UTMI+ and PIPE3) and
related changes in the driver structuring.
2) Added a xlate function to get the required phy out of
number of PHYs in mutiple PHY scenerio.
3) Changed the names of few structures and variables to
have a clearer meaning.
4) Added 'usb3phy_config' structure to take care of mutiple
phys for a SoC having 'exynos5_usb3phy_drv_data' driver data.
5) Not deleting support for old driver 'phy-samsung-usb3' until
required support for generic phy is added to DWC3.
.../devicetree/bindings/phy/samsung-phy.txt| 49 ++
drivers/phy/Kconfig|8 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usb3.c | 621
4 files changed, 679 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usb3.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa..57079f8 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,52 @@ Required properties:
- compatible : should be samsung,exynos5250-dp-video-phy;
- reg : offset and length of the Display Port PHY register set;
- #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung Exynos5 SoC series USB 3.0 PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usb3phy - for exynos5250 SoC,
+ - samsung,exynos5420-usb3phy - for exynos5420 SoC.
+- reg : Register offset and length of USB 3.0 PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB 3.0 controller IP clock),
+ used for register access.
+ - usb3phy_refclk: PHY's reference clock (usually crystal clock),
+ associated by phy name, used to determine bit values for
+ clock settings register.
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY operation
+ depicted as 'sclk_usbphy30' in CMU of Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usb3phy and samsung,exynos5420-usb3phy compatible
+PHYs, the second cell in the PHY specifier identifies the PHY id, which is
+interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usb3phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, usb3phy_refclk;
+ samsung,syscon-phandle = pmu_syscon;
+ #phy-cells = 1;
+ };
+
+- aliases: For SoCs like Exynos5420 having multiple USB PHY controllers,
+ 'usb3_phy' nodes should have numbered alias in the aliases node,
+ in the form of usb3phyN, N = 0, 1... (depending on number of
+ controllers).
+Example:
+ aliases {
+ usb3phy0 = usb3_phy0;
+ usb3phy1 = usb3_phy1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..32f9f38 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,12 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_EXYNOS5_USB3
+ tristate Exynos5 SoC series USB 3.0 PHY driver
+ depends on ARCH_EXYNOS5
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB 3.0 PHY support for Exynos 5 SoC series
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..9c06a61 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o
diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
new file mode 100644
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Kishon, [...] Right. While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+) can be used for High speed. It should then come under *single IP muliple PHY* category similar to what Sylwester has done. [...] The idea is to model the driver as close to the hardware though I understand there won't be any advantages w.r.t power or performance. maybe in later versions of the IP we'll have separate bits to control usb3 and usb2. Ok, i will prepare the next patchset for separating out the possible code based on the UTMI+ or PIPE3 phys. Though when experimenting with the PHY settings i can see there's little of such code :-) I think for power control we should have both usb3 and usb2 power-on callback calling a single function that controls the power bit. Right. I will do that. Have posted the next version of patch with functionality to support multiple PHYs as suggested. Please review the same. Thanks !! -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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
[no subject]
Hello! I have a question regarding the user space testapplication for FunctionFS (http://stuff.mit.edu/afs/sipb/contrib/linux/tools/usb/ffs-test.c). The struct descriptors that contains the header and the fs and hs descriptors has only interface and endpoint descriptors. Those are written to ep0. I understand that device and config descriptor are added by the FunctionFS module? I tried adding them to the descriptor struct and increasing fs_count and hs_count in the header filed by 2, but the write() on ep0 then returns -1: ffs-test: crit: ep0: write: descriptors: (-22) Invalid argument. Is it possible to pass my own device and config descriptor to the module or do I have to patch the module? Thanks! -- 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 audio breaks ohci-pci
On Wed, 15 Jan 2014 17:04:05 -0500 (EST), Alan Stern wrote: On Wed, 15 Jan 2014, Dennis New wrote: When listening to my usb-bluetooth audio headset, the usb subsystem (I think) on my laptop crashes, the bluetooth/audio is lost, and my mplayer program is left in an uninterruptible sleep (D) state and cannot be killed. The only way to get my usb-audio working again is to reboot. ... The crash is difficult to reproduce, sometimes it can occur after a few minutes of a clean boot, and sometimes after a few days. After the audio/usb abruptly stops, the syslog simply says: kernel: ALSA sound/usb/endpoint.c:501 timeout: still 3 active urbs on EP #3 And then after a few minutes (after enabling some kernel debugging options), I get some call traces of the hung task(s), which have ohci_urb_dequeue in common. http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash1.log http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash2.log http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash3.log The logs show that the khubd thread is hung, waiting for the ohci-hcd driver to finish cancelling a transfer. The problem is not with my device, since it occurs with another identical piece of hardware. It maybe be a problem with my laptop, since my friend does not seem to be experiencing this problem, although her laptop does not use ohci-pci. My usb controllers are: 1002:4374 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB Host Controller (prog-if 10 [OHCI]) 1002:4375 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB Host Controller (prog-if 10 [OHCI]) 1002:4373 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB2 Host Controller (prog-if 20 [EHCI]) Your first step in attacking this problem should be to use the most up-to-date kernel available, which at the moment is 3.13-rc8. Be sure to enable CONFIG_FRAME_POINTER along with CONFIG_USB_DEBUG. If the problem occurs again, collect a copy of the output from the dmesg command (_not_ a copy of the system log). Then go into /sys/kernel/debug/usb/ohci and collect copies of all the files in the two subdirectories. It may be necessary to apply some debugging patches to get more information. I haven't been able to reproduce the bug after upgrading to 3.13-rc8! -- 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] xhci: Pass the physical address to queue_trb() as a single u64
There is no point splitting a 64bit value into two 32bit parameters
for almost all the calls to queue_trb().
Change the definition of the 'generic' trb to have named fields
phys_addr, info_len and type_flags following the most common usage.
Add make_immd_data() to convert two 32bit values in the 64bit one,
and use it is the one place where immediate data is passed.
Signed-off-by: David Laight david.lai...@aculab.com
---
Patch is against 3.13.0-rc8
drivers/usb/host/xhci-dbg.c | 8 +-
drivers/usb/host/xhci-ring.c | 166 ++
drivers/usb/host/xhci-trace.h | 7 +-
drivers/usb/host/xhci.c | 3 +-
drivers/usb/host/xhci.h | 15 +++-
5 files changed, 92 insertions(+), 107 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 73503a8..bd5f3ea 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -241,10 +241,10 @@ void xhci_print_registers(struct xhci_hcd *xhci)
void xhci_print_trb_offsets(struct xhci_hcd *xhci, union xhci_trb *trb)
{
- int i;
- for (i = 0; i 4; ++i)
- xhci_dbg(xhci, Offset 0x%x = 0x%x\n,
- i*4, trb-generic.field[i]);
+ xhci_dbg(xhci, phys_addr %#12llx, info %#10x, type %#10x\n,
+ trb-generic.phys_addr,
+ trb-generic.info_len,
+ trb-generic.type_flags);
}
/**
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 53c2e29..bdd2ccd 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -214,7 +214,7 @@ static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring
*ring,
union xhci_trb *next;
unsigned long long addr;
- chain = le32_to_cpu(ring-enqueue-generic.field[3]) TRB_CHAIN;
+ chain = le32_to_cpu(ring-enqueue-generic.type_flags) TRB_CHAIN;
/* If this is not event ring, there is one less usable TRB */
if (ring-type != TYPE_EVENT
!last_trb(xhci, ring, ring-enq_seg, ring-enqueue))
@@ -474,7 +474,7 @@ static struct xhci_segment *find_trb_seg(
while (cur_seg-trbs trb ||
cur_seg-trbs[TRBS_PER_SEGMENT - 1] trb) {
generic_trb = cur_seg-trbs[TRBS_PER_SEGMENT - 1].generic;
- if (generic_trb-field[3] cpu_to_le32(LINK_TOGGLE))
+ if (generic_trb-type_flags cpu_to_le32(LINK_TOGGLE))
*cycle_state ^= 0x1;
cur_seg = cur_seg-next;
if (cur_seg == start_seg)
@@ -594,8 +594,8 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
}
trb = state-new_deq_ptr-generic;
- if (TRB_TYPE_LINK_LE32(trb-field[3])
- (trb-field[3] cpu_to_le32(LINK_TOGGLE)))
+ if (TRB_TYPE_LINK_LE32(trb-type_flags)
+ (trb-type_flags cpu_to_le32(LINK_TOGGLE)))
state-new_cycle_state ^= 0x1;
next_trb(xhci, ep_ring, state-new_deq_seg, state-new_deq_ptr);
@@ -637,16 +637,16 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
for (cur_seg = cur_td-start_seg, cur_trb = cur_td-first_trb;
true;
next_trb(xhci, ep_ring, cur_seg, cur_trb)) {
- if (TRB_TYPE_LINK_LE32(cur_trb-generic.field[3])) {
+ if (TRB_TYPE_LINK_LE32(cur_trb-generic.type_flags)) {
/* Unchain any chained Link TRBs, but
* leave the pointers intact.
*/
- cur_trb-generic.field[3] = cpu_to_le32(~TRB_CHAIN);
+ cur_trb-generic.type_flags = cpu_to_le32(~TRB_CHAIN);
/* Flip the cycle bit (link TRBs can't be the first
* or last TRB).
*/
if (flip_cycle)
- cur_trb-generic.field[3] ^=
+ cur_trb-generic.type_flags ^=
cpu_to_le32(TRB_CYCLE);
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
Cancel (unchain) link TRB);
@@ -658,17 +658,16 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
cur_seg,
(unsigned long long)cur_seg-dma);
} else {
- cur_trb-generic.field[0] = 0;
- cur_trb-generic.field[1] = 0;
- cur_trb-generic.field[2] = 0;
+ cur_trb-generic.phys_addr = 0;
+ cur_trb-generic.info_len = 0;
/* Preserve only the cycle bit of this TRB */
- cur_trb-generic.field[3] = cpu_to_le32(TRB_CYCLE);
+ cur_trb-generic.type_flags = cpu_to_le32(TRB_CYCLE);
[PATCH v6 00/10] USB Host support for OMAP5 uEVM (for 3.14)
Hi Benoit Tony, This patchset brings up USB Host ports and Ethernet port on the OMAP5 uEVM board. It depends on the TI Clock DT conversion patches [1] and is based on 3.13 [1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/293147 Tested on: - OMAP5 uEVM - Pandaboard ES Rev. B1 - Beagleboard-XM Rev C2 - Beagleboard Rev C4. cheers, -roger Changelog: v6: - Initialized clocks to -ENODEV and split patch 3. v5: - Expose all clocks in the DT binding document for mfd:omap-usb-host and mfd:omap-usb-tll v4: - Updated DT binding document for clock binding v3: - Rebased on top of 3.13-rc7 cheers, -roger Roger Quadros (10): mfd: omap-usb-host: Use resource managed clk_get() mfd: omap-usb-host: Get clocks based on hardware revision mfd: omap-usb-host: Use clock names as per function for reference clocks mfd: omap-usb-host: Update DT clock binding information mfd: omap-usb-tll: Update DT clock binding information ARM: dts: omap4: Update omap-usb-host node ARM: dts: omap5: Update omap-usb-host node ARM: dts: omap4-panda: Provide USB PHY clock ARM: dts: omap5-uevm: Provide USB PHY clock ARM: OMAP2+: Remove legacy_init_ehci_clk() .../devicetree/bindings/mfd/omap-usb-host.txt | 23 +++ .../devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++ arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +- arch/arm/boot/dts/omap4.dtsi | 6 + arch/arm/boot/dts/omap5-uevm.dts | 8 +- arch/arm/boot/dts/omap5.dtsi | 6 + arch/arm/mach-omap2/pdata-quirks.c | 16 -- drivers/mfd/omap-usb-host.c| 171 ++--- 8 files changed, 128 insertions(+), 120 deletions(-) -- 1.8.3.2 -- 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 v6 04/10] mfd: omap-usb-host: Update DT clock binding information
The omap-usb-host driver expects certained named clocks. Add this information to the DT binding document. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..4721b2d 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,29 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + +- clock-names: should include: + For OMAP3 + * usbhost_120m_fck - 120MHz Functional clock. + + For OMAP4+ + * refclk_60m_int - 60MHz internal reference clock for UTMI clock mux + * refclk_60m_ext_p1 - 60MHz external ref. clock for Port 1's UTMI clock mux. + * refclk_60m_ext_p2 - 60MHz external ref. clock for Port 2's UTMI clock mux + * utmi_p1_gfclk - Port 1 UTMI clock mux. + * utmi_p2_gfclk - Port 2 UTMI clock mux. + * usb_host_hs_utmi_p1_clk - Port 1 UTMI clock gate. + * usb_host_hs_utmi_p2_clk - Port 2 UTMI clock gate. + * usb_host_hs_utmi_p3_clk - Port 3 UTMI clock gate. + * usb_host_hs_hsic480m_p1_clk - Port 1 480MHz HSIC clock gate. + * usb_host_hs_hsic480m_p2_clk - Port 2 480MHz HSIC clock gate. + * usb_host_hs_hsic480m_p3_clk - Port 3 480MHz HSIC clock gate. + * usb_host_hs_hsic60m_p1_clk - Port 1 60MHz HSIC clock gate. + * usb_host_hs_hsic60m_p2_clk - Port 2 60MHz HSIC clock gate. + * usb_host_hs_hsic60m_p3_clk - Port 3 60MHz HSIC clock gate. + Required properties if child node exists: - #address-cells: Must be 1 -- 1.8.3.2 -- 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 v6 08/10] ARM: dts: omap4-panda: Provide USB PHY clock
The USB PHY gets its clock from AUXCLK3. Provide this information. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..50b72966 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -83,12 +83,8 @@ compatible = usb-nop-xceiv; reset-gpios = gpio2 30 GPIO_ACTIVE_LOW; /* gpio_62 */ vcc-supply = hsusb1_power; - /** -* FIXME: -* put the right clock phandle here when available -* clocks = auxclk3; -* clock-names = main_clk; -*/ + clocks = auxclk3_ck; + clock-names = main_clk; clock-frequency = 1920; }; -- 1.8.3.2 -- 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 v6 10/10] ARM: OMAP2+: Remove legacy_init_ehci_clk()
The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 16
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 39f020c..6a4e2d1 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -26,20 +26,6 @@ struct pdata_init {
void (*fn)(void);
};
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init __used legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias(main_clk, NULL, clkname, NULL);
- if (ret)
- pr_err(%s:Failed to add main_clk alias to %s :%d\n,
- __func__, clkname, ret);
-}
-
#if IS_ENABLED(CONFIG_WL12XX)
static struct wl12xx_platform_data wl12xx __initdata;
@@ -105,7 +91,6 @@ static void __init omap4_sdp_legacy_init(void)
static void __init omap4_panda_legacy_init(void)
{
omap4_panda_display_init_of();
- legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
#endif
@@ -113,7 +98,6 @@ static void __init omap4_panda_legacy_init(void)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_uevm_legacy_init(void)
{
- legacy_init_ehci_clk(auxclk1_ck);
}
#endif
--
1.8.3.2
--
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 v6 09/10] ARM: dts: omap5-uevm: Provide USB PHY clock
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70..3b99ec2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,12 +31,8 @@
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
reset-gpios = gpio3 16 GPIO_ACTIVE_LOW; /* gpio3_80
HUB_NRESET */
- /**
- * FIXME
- * Put the right clock phandle here when available
- * clocks = auxclk1;
- * clock-names = main_clk;
- */
+ clocks = auxclk1_ck;
+ clock-names = main_clk;
clock-frequency = 1920;
};
--
1.8.3.2
--
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 v6 07/10] ARM: dts: omap5: Update omap-usb-host node
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2f12a47..0f82ecf 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -765,6 +765,12 @@
#address-cells = 1;
#size-cells = 1;
ranges;
+ clocks = l3init_60m_fclk,
+xclk60mhsp1_ck,
+xclk60mhsp2_ck;
+ clock-names = refclk_60m_int,
+ refclk_60m_ext_p1,
+ refclk_60m_ext_p2;
usbhsohci: ohci@4a064800 {
compatible = ti,ohci-omap3, usb-ohci;
--
1.8.3.2
--
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 v6 05/10] mfd: omap-usb-tll: Update DT clock binding information
The omap-usb-tll driver needs one clock for each TLL channel.
Add this information to the DT binding document.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
index 62fe697..c58d704 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -7,6 +7,16 @@ Required properties:
- interrupts : should contain the TLL module's interrupt
- ti,hwmod : must contain usb_tll_hs
+Optional properties:
+
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+
+- clock-names: should include:
+ * usb_tll_hs_usb_ch0_clk - USB TLL channel 0 clock
+ * usb_tll_hs_usb_ch1_clk - USB TLL channel 1 clock
+ * usb_tll_hs_usb_ch2_clk - USB TLL channel 2 clock
+
Example:
usbhstll: usbhstll@4a062000 {
--
1.8.3.2
--
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 v6 02/10] mfd: omap-usb-host: Get clocks based on hardware revision
Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.
This should avoid un-necessary clk_get failure messages that were
observed earlier.
Be more strict and always fail on clk_get() error.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 92 +++--
1 file changed, 64 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1c9bca2..eaafd2e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -665,22 +665,41 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap-ehci_logic_fck = omap-init_60m_fclk = ERR_PTR(-ENODEV);
+ omap-utmi_p1_gfclk = omap-utmi_p2_gfclk = ERR_PTR(-ENODEV);
+ omap-xclk60mhsp1_ck = omap-xclk60mhsp2_ck = ERR_PTR(-ENODEV);
+
for (i = 0; i omap-nports; i++) {
- if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
- is_ehci_hsic_mode(i))
- need_logic_fck |= true;
+ omap-utmi_clk[i] = ERR_PTR(-ENODEV);
+ omap-hsic480m_clk[i] = ERR_PTR(-ENODEV);
+ omap-hsic60m_clk[i] = ERR_PTR(-ENODEV);
}
- omap-ehci_logic_fck = ERR_PTR(-EINVAL);
- if (need_logic_fck) {
- omap-ehci_logic_fck = devm_clk_get(dev, ehci_logic_fck);
- if (IS_ERR(omap-ehci_logic_fck)) {
- ret = PTR_ERR(omap-ehci_logic_fck);
- dev_dbg(dev, ehci_logic_fck failed:%d\n, ret);
+ /* for OMAP3 i.e. USBHS REV1 */
+ if (omap-usbhs_rev == OMAP_USBHS_REV1) {
+ need_logic_fck = false;
+ for (i = 0; i omap-nports; i++) {
+ if (is_ehci_phy_mode(pdata-port_mode[i]) ||
+ is_ehci_tll_mode(pdata-port_mode[i]) ||
+ is_ehci_hsic_mode(pdata-port_mode[i]))
+
+ need_logic_fck |= true;
+ }
+
+ if (need_logic_fck) {
+ omap-ehci_logic_fck = clk_get(dev, usbhost_120m_fck);
+ if (IS_ERR(omap-ehci_logic_fck)) {
+ ret = PTR_ERR(omap-ehci_logic_fck);
+ dev_err(dev, usbhost_120m_fck failed:%d\n,
+ ret);
+ goto err_mem;
+ }
}
+ goto initialize;
}
+ /* for OMAP4+ i.e. USBHS REV2+ */
omap-utmi_p1_gfclk = devm_clk_get(dev, utmi_p1_gfclk);
if (IS_ERR(omap-utmi_p1_gfclk)) {
ret = PTR_ERR(omap-utmi_p1_gfclk);
@@ -728,54 +747,71 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* them
*/
omap-utmi_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-utmi_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-utmi_clk[i]));
+ if (IS_ERR(omap-utmi_clk[i])) {
+ ret = PTR_ERR(omap-utmi_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic480m_p%d_clk, i + 1);
omap-hsic480m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-hsic480m_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-hsic480m_clk[i]));
+ if (IS_ERR(omap-hsic480m_clk[i])) {
+ ret = PTR_ERR(omap-hsic480m_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic60m_p%d_clk, i + 1);
omap-hsic60m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-hsic60m_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-hsic60m_clk[i]));
+ if (IS_ERR(omap-hsic60m_clk[i])) {
+ ret = PTR_ERR(omap-hsic60m_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
}
if (is_ehci_phy_mode(pdata-port_mode[0]))
[PATCH v6 01/10] mfd: omap-usb-host: Use resource managed clk_get()
Use devm_clk_get() instead of clk_get().
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/omap-usb-host.c | 81 +
1 file changed, 16 insertions(+), 65 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 142650f..1c9bca2 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -674,46 +674,46 @@ static int usbhs_omap_probe(struct platform_device *pdev)
omap-ehci_logic_fck = ERR_PTR(-EINVAL);
if (need_logic_fck) {
- omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
+ omap-ehci_logic_fck = devm_clk_get(dev, ehci_logic_fck);
if (IS_ERR(omap-ehci_logic_fck)) {
ret = PTR_ERR(omap-ehci_logic_fck);
dev_dbg(dev, ehci_logic_fck failed:%d\n, ret);
}
}
- omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk);
+ omap-utmi_p1_gfclk = devm_clk_get(dev, utmi_p1_gfclk);
if (IS_ERR(omap-utmi_p1_gfclk)) {
ret = PTR_ERR(omap-utmi_p1_gfclk);
dev_err(dev, utmi_p1_gfclk failed error:%d\n, ret);
- goto err_p1_gfclk;
+ goto err_mem;
}
- omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk);
+ omap-utmi_p2_gfclk = devm_clk_get(dev, utmi_p2_gfclk);
if (IS_ERR(omap-utmi_p2_gfclk)) {
ret = PTR_ERR(omap-utmi_p2_gfclk);
dev_err(dev, utmi_p2_gfclk failed error:%d\n, ret);
- goto err_p2_gfclk;
+ goto err_mem;
}
- omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
- goto err_xclk60mhsp1;
+ goto err_mem;
}
- omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
- goto err_xclk60mhsp2;
+ goto err_mem;
}
- omap-init_60m_fclk = clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
- goto err_init60m;
+ goto err_mem;
}
for (i = 0; i omap-nports; i++) {
@@ -727,21 +727,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* platforms have all clocks and we can function without
* them
*/
- omap-utmi_clk[i] = clk_get(dev, clkname);
+ omap-utmi_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-utmi_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-utmi_clk[i]));
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic480m_p%d_clk, i + 1);
- omap-hsic480m_clk[i] = clk_get(dev, clkname);
+ omap-hsic480m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-hsic480m_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-hsic480m_clk[i]));
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic60m_p%d_clk, i + 1);
- omap-hsic60m_clk[i] = clk_get(dev, clkname);
+ omap-hsic60m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-hsic60m_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-hsic60m_clk[i]));
@@ -784,7 +784,7 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, Failed to create DT children: %d\n, ret);
- goto err_alloc;
+ goto err_mem;
}
} else {
@@ -792,40 +792,12 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, omap_usbhs_alloc_children failed: %d\n,
ret);
- goto err_alloc;
+ goto err_mem;
}
}
return 0;
-err_alloc:
- for (i = 0; i omap-nports; i++) {
-
[PATCH v6 06/10] ARM: dts: omap4: Update omap-usb-host node
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..39a05ce 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -697,6 +697,12 @@
#address-cells = 1;
#size-cells = 1;
ranges;
+ clocks = init_60m_fclk,
+xclk60mhsp1_ck,
+xclk60mhsp2_ck;
+ clock-names = refclk_60m_int,
+ refclk_60m_ext_p1,
+ refclk_60m_ext_p2;
usbhsohci: ohci@4a064800 {
compatible = ti,ohci-omap3, usb-ohci;
--
1.8.3.2
--
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 v6 03/10] mfd: omap-usb-host: Use clock names as per function for reference clocks
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index eaafd2e..d6fab3e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
--
1.8.3.2
--
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
FunctionFS: Provide device and configdescriptor from user mode application?
Hi! Sorry, I posted before but forgot the subject. I am running the test application ffs-test.c in user space and I want to write the descriptors to ep0. However, it seems that I can only write interface descriptors and enpoint descriptors. What about device and configdescriptors? When I put those in the descriptor struct I get an EINVAL (22, invalid parameter) error: ffs-test: info: ep0: writing descriptors ffs-test: crit: ep0: write: descriptors: (-22) Invalid argument -- 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
FunctionFS: Provide device and configdescriptor from user mode application?
Hi! Sorry, I posted before but forgot the subject. I am running the test application ffs-test.c in user space and I want to write the descriptors to ep0. However, it seems that I can only write interface descriptors and enpoint descriptors. What about device and configdescriptors? When I put those in the descriptor struct I get an EINVAL (22, invalid parameter) error: ffs-test: info: ep0: writing descriptors ffs-test: crit: ep0: write: descriptors: (-22) Invalid argument -- 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: Fwd: Re: [alsa-devel] no reset_resume for driver snd-usb-audio for logitech headset H600
At Mon, 20 Jan 2014 09:45:58 +0100,
Takashi Iwai wrote:
At Sun, 19 Jan 2014 21:30:58 +0100,
baum...@hotmail.com wrote:
Hello,
there must be a misunderstanding;
There is a functional change, because with the line/patch .reset_resume =
usb_audio_resume, the mixer of the usb headset was not removed during
suspend/resume and so the master channel in KDE Mixer was not changed
(Headset), which is the correct behaviour.
Without the line .reset_resume = usb_audio_resume, in /sound/usb/card.c,
the mixer was removed during suspend/resume and re-added, and so the master
channel changed in KDE Mixer to the default onboard audio.
I have tested kernel 3.13rc8, and as you mentioned, the
reset_resume-messages are gone.
But the behaviour of removing the mixer of the usb_audio_headset occurs,
which is, in my opinion, not the correct behaviour, because the chosen
master channel/mixer should stay after suspend/resume.
Could you please take a look at the issue again.
Simply adding usb_audio-resume to reset_resume ops doesn't work
properly as Clemens already suggested. It misses the recovery of the
current mixer values. This might work in some cases like S3 (where
the device is kept more or less powered on), but it'll be definitely
broken in some cases like S4.
... and below is a quick fix with mixer resume code.
It still doesn't handle some quirks, so it might break some devices.
Takashi
-- 8 --
From: Takashi Iwai ti...@suse.de
Subject: [PATCH] ALSA: usb-audio: Resume mixer values properly
Implement reset_resume callback so that the mixer values are properly
restored. Still no boot quirks are called, so it might not work well
on some devices.
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/usb/card.c | 18 --
sound/usb/mixer.c | 99 ---
sound/usb/mixer.h | 7 ++--
3 files changed, 99 insertions(+), 25 deletions(-)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index d979050e6a6a..025224136129 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -691,12 +691,12 @@ static int usb_audio_suspend(struct usb_interface *intf,
pm_message_t message)
}
list_for_each_entry(mixer, chip-mixer_list, list)
- snd_usb_mixer_inactivate(mixer);
+ snd_usb_mixer_suspend(mixer);
return 0;
}
-static int usb_audio_resume(struct usb_interface *intf)
+static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
{
struct snd_usb_audio *chip = usb_get_intfdata(intf);
struct usb_mixer_interface *mixer;
@@ -711,7 +711,7 @@ static int usb_audio_resume(struct usb_interface *intf)
* we just notify and restart the mixers
*/
list_for_each_entry(mixer, chip-mixer_list, list) {
- err = snd_usb_mixer_activate(mixer);
+ err = snd_usb_mixer_resume(mixer, reset_resume);
if (err 0)
goto err_out;
}
@@ -723,9 +723,20 @@ static int usb_audio_resume(struct usb_interface *intf)
err_out:
return err;
}
+
+static int usb_audio_resume(struct usb_interface *intf)
+{
+ return __usb_audio_resume(intf, false);
+}
+
+static int usb_audio_reset_resume(struct usb_interface *intf)
+{
+ return __usb_audio_resume(intf, true);
+}
#else
#define usb_audio_suspend NULL
#define usb_audio_resume NULL
+#define usb_audio_reset_resume NULL
#endif /* CONFIG_PM */
static struct usb_device_id usb_audio_ids [] = {
@@ -747,6 +758,7 @@ static struct usb_driver usb_audio_driver = {
.disconnect = usb_audio_disconnect,
.suspend = usb_audio_suspend,
.resume = usb_audio_resume,
+ .reset_resume = usb_audio_reset_resume,
.id_table = usb_audio_ids,
.supports_autosuspend = 1,
};
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 44b0ba4feab3..aa9bc19aae68 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -2299,26 +2299,6 @@ requeue:
}
}
-/* stop any bus activity of a mixer */
-void snd_usb_mixer_inactivate(struct usb_mixer_interface *mixer)
-{
- usb_kill_urb(mixer-urb);
- usb_kill_urb(mixer-rc_urb);
-}
-
-int snd_usb_mixer_activate(struct usb_mixer_interface *mixer)
-{
- int err;
-
- if (mixer-urb) {
- err = usb_submit_urb(mixer-urb, GFP_NOIO);
- if (err 0)
- return err;
- }
-
- return 0;
-}
-
/* create the handler for the optional status interrupt endpoint */
static int snd_usb_mixer_status_create(struct usb_mixer_interface *mixer)
{
@@ -2417,3 +2397,82 @@ void snd_usb_mixer_disconnect(struct list_head *p)
usb_kill_urb(mixer-urb);
usb_kill_urb(mixer-rc_urb);
}
+
+#ifdef CONFIG_PM
+/* stop any bus activity of a mixer */
+static void snd_usb_mixer_inactivate(struct usb_mixer_interface *mixer)
+{
+ usb_kill_urb(mixer-urb);
+
Re: [PATCH v2 2/3] usb: gadget: f_fs: add poll for endpoint 0
On Fri, Jan 17 2014, Robert Baldyga wrote:
@@ -558,6 +560,45 @@ static long ffs_ep0_ioctl(struct file *file, unsigned
code, unsigned long value)
return ret;
}
+static unsigned int ffs_ep0_poll(struct file *file, poll_table *wait)
+{
+ struct ffs_data *ffs = file-private_data;
+ unsigned int mask = POLLWRNORM;
+ int ret;
+
+ ret = ffs_mutex_lock(ffs-mutex, file-f_flags O_NONBLOCK);
+ if (unlikely(ret 0))
+ return mask;
+
+ switch (ffs-state) {
+ case FFS_READ_DESCRIPTORS:
+ case FFS_READ_STRINGS:
+ mask |= POLLOUT;
+ break;
+
+ case FFS_ACTIVE:
+ switch (FFS_SETUP_STATE(ffs)) {
One more thing, this should not be FFS_SETUP_STATE but simply
ffs-setup_state. This is because FFS_SETUP_STATE changes value of
ffs-setup_state and we don't want that to happen here.
+ case FFS_NO_SETUP:
+ if (ffs-ev.count)
+ mask |= POLLIN;
+ break;
+
+ case FFS_SETUP_PENDING:
+ mask |= (POLLIN | POLLOUT);
+ break;
+
+ case FFS_SETUP_CANCELED:
+ break;
+ }
+ case FFS_CLOSING:
+ break;
+ }
+
+ mutex_unlock(ffs-mutex);
+
+ return mask;
+}
+
static const struct file_operations ffs_ep0_operations = {
.llseek = no_llseek,
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
Re: usb disk recognized but fails
Cc-ing the USB storage list, in case this device needs some quirk. On Wed, Jan 15, 2014 at 03:47:39PM +0100, Milan Svoboda wrote: The SATA adapter has a power input, but it is not used, it is connected to the PC with Y-type USB cable. The disk works with my smart TV, it works with Windows on the same machine, it also had worked some time ago with Linux, but now it shows the following: Do you know which kernel version it worked with? What version are you currently running? Please run `uname -a`. [ 2192.027213] usb 1-3: new high-speed USB device number 5 using xhci_hcd [ 2192.042323] ums-cypress 1-3:1.0: USB Mass Storage device detected [ 2192.042500] scsi9 : usb-storage 1-3:1.0 [ 2193.044219] scsi 9:0:0:0: Direct-Access WDC WD64 00BPVT-00HXZT0 PQ: 0 ANSI: 0 [ 2193.045083] sd 9:0:0:0: [sdb] 1250263728 512-byte logical blocks: (640 GB/596 GiB) [ 2193.045240] sd 9:0:0:0: [sdb] Write Protect is off [ 2193.045245] sd 9:0:0:0: [sdb] Mode Sense: 03 00 00 00 [ 2193.045384] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.045388] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.046259] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.046264] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.054389] sdb: sdb1 [ 2193.055092] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.055095] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.055098] sd 9:0:0:0: [sdb] Attached SCSI disk [ 2200.821345] usb 1-3: reset high-speed USB device number 5 using xhci_hcd [ 2200.835063] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800bc71e480 [ 2200.835068] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800bc71e4c0 [ 2267.897715] sd 9:0:0:0: [sdb] Unhandled sense code [ 2267.897719] sd 9:0:0:0: [sdb] [ 2267.897721] Result: hostbyte=0x07 driverbyte=0x08 [ 2267.897722] sd 9:0:0:0: [sdb] [ 2267.897724] Sense Key : 0x4 [current] [ 2267.897735] sd 9:0:0:0: [sdb] [ 2267.897736] ASC=0x0 ASCQ=0x0 [ 2267.897738] sd 9:0:0:0: [sdb] CDB: [ 2267.897740] cdb[0]=0x28: 28 00 4a 85 6e af 00 00 08 00 [ 2267.897746] end_request: I/O error, dev sdb, sector 1250258607 [ 2267.897750] Buffer I/O error on device sdb1, logical block 625129272 [ 2267.897752] Buffer I/O error on device sdb1, logical block 625129273 [ 2267.897753] Buffer I/O error on device sdb1, logical block 625129274 [ 2267.897754] Buffer I/O error on device sdb1, logical block 625129275 [ 2270.884154] usb 1-3: USB disconnect, device number 5 Bus 001 Device 010: ID 14cd:6116 Super Top M6116 SATA Bridge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x14cd Super Top idProduct 0x6116 M6116 SATA Bridge bcdDevice1.50 iManufacturer 1 Super Top iProduct3 USB 2.0 SATA BRIDGE iSerial 2 M6116018VE15 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0001 Self Powered -- To unsubscribe from this list: send the line
Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote: From: walt On 01/17/2014 06:34 AM, David Laight wrote: Can you try the patch I posted that stops the ownership on LINK TRBs being changed before that on the linked-to TRB? Please disregard my earlier post about the patch not applying cleanly. That was the usual html corruption, so I found the original on the usb list and it was okay. Sadly, the patch didn't fix the ASMedia lockup behavior, however :( I did notice that the lockup occurred only when copying *to* the usb3 drive, and not when copying from it. I think that may be new behavior but I can't swear to it. Consistent with another report that says that ethernet worked provided that TSO was disabled (ie no sg tx). (Without the patch to delay he ownership change on link trbs it didn't work at all.) Please be more clear. What do you mean by these statements? That someone privately reported that your earlier patch [1] did not help them, but applying your new patch [2] on top of the old patch did? [1] http://marc.info/?l=linux-usbm=138418996717941w=2 [2] http://marc.info/?l=linux-usbm=138996538403468w=2 In general, will you please Cc me and the USB list when replying to privately reported bugs/confirmations that patches work? Or if the confirmation was reported, please provide a link to the mailing list discussion or bugzilla entry. We need to keep bug and fix confirmations publicly archived. Please keep me on Cc since I filter mail based on that. A guess... In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead of xhci_td_remainder(). Why? Walt has a 0.96 xHCI host controller, and the format for how to calculate the TD remainder changed between the 0.96 and the 1.0 spec. That's why we have xhci_v1_0_td_remainder() and xhci_td_remainder(). 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 disk recognized but fails
Non-working: 3.12.7-2-ARCH #1 SMP PREEMPT Sun Jan 12 13:09:09 CET 2014 x86_64 GNU/Linux I'm sorry, I don't remember exactly which version worked, I have had the disk connected to TV for a long time and only recently I wanted to copy some movies on it. I guess it worked something like 6 or 9 months ago. Milan __ Od: Sarah Sharp sarah.a.sh...@linux.intel.com Komu: Milan Svoboda milan.svob...@centrum.cz Datum: 20.01.2014 19:23 Předmět: Re: usb disk recognized but fails CC: linux-usb@vger.kernel.org, USB Storage List usb-stor...@lists.one-eyed-alien.net, linux-s...@vger.kernel.org Cc-ing the USB storage list, in case this device needs some quirk. On Wed, Jan 15, 2014 at 03:47:39PM +0100, Milan Svoboda wrote: The SATA adapter has a power input, but it is not used, it is connected to the PC with Y-type USB cable. The disk works with my smart TV, it works with Windows on the same machine, it also had worked some time ago with Linux, but now it shows the following: Do you know which kernel version it worked with? What version are you currently running? Please run `uname -a`. [ 2192.027213] usb 1-3: new high-speed USB device number 5 using xhci_hcd [ 2192.042323] ums-cypress 1-3:1.0: USB Mass Storage device detected [ 2192.042500] scsi9 : usb-storage 1-3:1.0 [ 2193.044219] scsi 9:0:0:0: Direct-Access WDC WD64 00BPVT-00HXZT0 PQ: 0 ANSI: 0 [ 2193.045083] sd 9:0:0:0: [sdb] 1250263728 512-byte logical blocks: (640 GB/596 GiB) [ 2193.045240] sd 9:0:0:0: [sdb] Write Protect is off [ 2193.045245] sd 9:0:0:0: [sdb] Mode Sense: 03 00 00 00 [ 2193.045384] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.045388] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.046259] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.046264] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.054389] sdb: sdb1 [ 2193.055092] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.055095] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.055098] sd 9:0:0:0: [sdb] Attached SCSI disk [ 2200.821345] usb 1-3: reset high-speed USB device number 5 using xhci_hcd [ 2200.835063] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800bc71e480 [ 2200.835068] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800bc71e4c0 [ 2267.897715] sd 9:0:0:0: [sdb] Unhandled sense code [ 2267.897719] sd 9:0:0:0: [sdb] [ 2267.897721] Result: hostbyte=0x07 driverbyte=0x08 [ 2267.897722] sd 9:0:0:0: [sdb] [ 2267.897724] Sense Key : 0x4 [current] [ 2267.897735] sd 9:0:0:0: [sdb] [ 2267.897736] ASC=0x0 ASCQ=0x0 [ 2267.897738] sd 9:0:0:0: [sdb] CDB: [ 2267.897740] cdb[0]=0x28: 28 00 4a 85 6e af 00 00 08 00 [ 2267.897746] end_request: I/O error, dev sdb, sector 1250258607 [ 2267.897750] Buffer I/O error on device sdb1, logical block 625129272 [ 2267.897752] Buffer I/O error on device sdb1, logical block 625129273 [ 2267.897753] Buffer I/O error on device sdb1, logical block 625129274 [ 2267.897754] Buffer I/O error on device sdb1, logical block 625129275 [ 2270.884154] usb 1-3: USB disconnect, device number 5 Bus 001 Device 010: ID 14cd:6116 Super Top M6116 SATA Bridge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x14cd Super Top idProduct 0x6116 M6116 SATA Bridge bcdDevice1.50 iManufacturer 1 Super Top iProduct3 USB 2.0 SATA BRIDGE iSerial 2 M6116018VE15 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02
Re: [BUGREPORT] Linux USB 3.0
Hi Markus, I'm the xHCI driver maintainer, and it helps to Cc me on USB 3.0 bug reports. On Sat, Dec 28, 2013 at 07:24:20AM +0100, Markus Rechberger wrote: just received following log snippset: Please state which kernel version you (or your customer) is running. You've reported issues with several different kernel versions, so which kernel are you running for this particular snippet? Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr These messages might be harmless. The 3.0 kernel contains a fix for Intel Panther Point xHCI hosts that suppresses those messages, commit ad808333d8201d53075a11bc8dd83b81f3d68f0b Intel xhci: Ignore spurious successful event. A later commit extends that to all xHCI 1.0 hosts, commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 That was queued for 3.11 and marked to be backported into stable kernels as old as 3.0. the previous bug report of that user: https://bugzilla.kernel.org/show_bug.cgi?id=65021 xhci: complete USB freeze Hmm, Greg didn't assign that bug to me, so I missed it, sorry. On Fri, Dec 27, 2013 at 8:59 PM, Markus Rechberger mrechber...@gmail.com wrote: Seems like DH87RL was working with 3.2.0-55-generic-pae unfortunately we don't have such a board for testing and customer patience is limited to bisect the kernel. Does anyone have a clue what modification could have killed USB 3.0 support within those releases? It does not seem to be SG support. 3.2 was the kernel where the Intel EHCI to xHCI port switchover code went in. Without that code, all ports will remain under the EHCI host, and USB 3.0 devices will work at USB 2.0 speeds. I suspect the USB device triggers an issue with the xHCI driver, and 3.2 only works because the device is on an EHCI port without the switchover code. On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger mrechber...@gmail.com wrote: I just got another USB 3.0 bugreport, the entire system crashed. That particular customer already filed a bugreport in November 2013 that his system is in a bad state when using some USB 2.0 media devices which even have opensource drivers built into the kernel. USB 3.0 support with Linux seems to be a disaster with Linux 3.6.12. The affected board is an Intel DH87RL board. Why are they running 3.6.12 in particular? That's not a supported stable kernel. On Wed, Dec 25, 2013 at 8:18 AM, Markus Rechberger mrechber...@gmail.com wrote: A customer using a device with USBDEVFS is reporting following backtrace (it seems to be a rather generic issue related to linux usb 3.0 in general): According to him this problem is reproducible as soon as he starts the data transfer, is there anything known about that? He is using 3.12.0-031200-generic So at this point you've reported three separate bugs, all with the same symptom, but different kernel versions? Are these all from the same bug reporter, or a different bug reporter? You've got me seriously confused right now. Please keep one bug report to one mail thread, and get the original bug reporter to start that thread. If this is from one bug reporter, please state the current kernel they are running, and send dmesg showing the issue with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on (you may also need to turn on CONFIG_DYNAMIC_DEBUG in later kernels). Please attach the dmesg as a file, since your mail client line-wraps. Dec 24 14:22:39 homenas kernel: [ 1469.818460] xhci_hcd :0f:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Dec 24 14:30:39 homenas kernel: last message repeated 16 times Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: WARN Successful completion on short TX Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: WARN Successful completion on short TX Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: URB transfer length is wrong, xHC issue? req. len = 46080, act. len = 1382400 Dec 24 14:30:39 homenas kernel: [ 1469.822450] BUG: unable to handle kernel NULL pointer dereference at 0004 Dec 24 14:30:39 homenas kernel: [ 1469.822450] IP: [] finish_td+0x13f/0x250 Dec 24 14:30:39 homenas kernel: [ 1469.822450] PGD 0 Dec 24 14:30:39 homenas kernel: [ 1469.822450] Oops: [#1] SMP Dec 24 14:30:39 homenas kernel: [ 1469.822450] Modules linked in: videodev pci_stub vboxpci(OF) vboxnetadp(OF) vboxnetflt(OF) vboxdrv(OF) dm_crypt snd_hda_codec_ca0132 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi dm_multipath psmouse scsi_dh snd_rawmidi serio_raw sb_edac snd_seq_midi_event edac_core snd_seq snd_timer snd_seq_device lpc_ich snd bnep rfcomm soundcore snd_page_alloc bluetooth
Re: EHCI host broken -- interrupts disabled
On Mon, Jan 20, 2014 at 12:15:47PM +, Chen, Jamie wrote: Try to apply this patch to kernel 3.8.0. Make sure the ehci can work fine and lspci show that PCI_COMMAND_INTX_DISABLE is 0. The patch can resolved this issue. Great! Thanks for testing, Jamie. Bjorn, can you add me to the Cc list for this patch? I'd like to notify other Linux distros when it lands so they can pick it up. Sarah Sharp #lspci -vv 00:1d.0 USB controller: Intel Corporation Device 0f34 (rev 0a) (prog-if 20 [EHCI]) Subsystem: Intel Corporation Device 7270 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 0: Memory at 90612000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: ehci-pci dmesg: [1.014556] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.014559] ehci-pci: EHCI PCI platform driver [1.014612] ehci-pci :00:1d.0: setting latency timer to 64 [1.014618] ehci-pci :00:1d.0: EHCI Host Controller [1.014629] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1 [1.014652] ehci-pci :00:1d.0: debug port 2 [1.018562] ehci-pci :00:1d.0: cache line size of 64 is not supported [1.018594] ehci-pci :00:1d.0: irq 23, io mem 0x90612000 [1.029238] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.029274] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.029279] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.029283] usb usb1: Product: EHCI Host Controller [1.029286] usb usb1: Manufacturer: Linux 3.8.13.13-pci ehci_hcd [1.029290] usb usb1: SerialNumber: :00:1d.0 [1.029469] hub 1-0:1.0: USB hub found [1.029785] ehci-platform: EHCI generic platform driver [1.340641] usb 1-1: new high-speed USB device number 2 using ehci-pci [1.473442] usb 1-1: New USB device found, idVendor=8087, idProduct=07e6 [1.473447] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [1.475095] hub 1-1:1.0: USB hub found [1.749587] usb 1-1.2: new high-speed USB device number 3 using ehci-pci [1.841046] usb 1-1.2: New USB device found, idVendor=05e3, idProduct=0608 [1.841052] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [1.841056] usb 1-1.2: Product: USB2.0 Hub [1.841469] hub 1-1.2:1.0: USB hub found [2.115558] usb 1-1.2.1: new high-speed USB device number 4 using ehci-pci [2.208321] usb 1-1.2.1: New USB device found, idVendor=05e3, idProduct=0608 [2.208327] usb 1-1.2.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [2.208331] usb 1-1.2.1: Product: USB2.0 Hub [2.209113] hub 1-1.2.1:1.0: USB hub found [2.283104] usb 1-1.2.3: new low-speed USB device number 5 using ehci-pci [2.378487] usb 1-1.2.3: New USB device found, idVendor=03f0, idProduct=0c4a [2.378492] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [2.378496] usb 1-1.2.3: Product: HP [2.378500] usb 1-1.2.3: Manufacturer: HP [2.385945] usbcore: registered new interface driver usbhid [2.385950] usbhid: USB HID core driver [ 11.550722] input: HP HP as /devices/pci:00/:00:1d.0/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/input/input5 [ 11.550963] hid-generic 0003:03F0:0C4A.0001: input,hidraw0: USB HID v1.11 Mouse [HP HP] on usb-:00:1d.0-1.2.3/input0 Jamie -- 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 disk recognized but fails
On Mon, Jan 20, 2014 at 08:00:23PM +0100, Milan Svoboda wrote: Non-working: 3.12.7-2-ARCH #1 SMP PREEMPT Sun Jan 12 13:09:09 CET 2014 x86_64 GNU/Linux I'm sorry, I don't remember exactly which version worked, I have had the disk connected to TV for a long time and only recently I wanted to copy some movies on it. I guess it worked something like 6 or 9 months ago. If you're up for compiling a custom kernel, can you try 3.12.7 with these two patches applied? http://marc.info/?l=linux-usbm=138921117504911w=2 http://marc.info/?l=linux-usbm=138921117604912w=2 I'm concerned the I/O errors are caused by commit 459d3c146117 usb: xhci: Link TRB must not occur within a USB payload burst. Can you also send me the output of `sudo lspci -vvv -n`? I need the output for the xHCI host only. Sarah Sharp __ Od: Sarah Sharp sarah.a.sh...@linux.intel.com Komu: Milan Svoboda milan.svob...@centrum.cz Datum: 20.01.2014 19:23 Předmět: Re: usb disk recognized but fails CC: linux-usb@vger.kernel.org, USB Storage List usb-stor...@lists.one-eyed-alien.net, linux-s...@vger.kernel.org Cc-ing the USB storage list, in case this device needs some quirk. On Wed, Jan 15, 2014 at 03:47:39PM +0100, Milan Svoboda wrote: The SATA adapter has a power input, but it is not used, it is connected to the PC with Y-type USB cable. The disk works with my smart TV, it works with Windows on the same machine, it also had worked some time ago with Linux, but now it shows the following: Do you know which kernel version it worked with? What version are you currently running? Please run `uname -a`. [ 2192.027213] usb 1-3: new high-speed USB device number 5 using xhci_hcd [ 2192.042323] ums-cypress 1-3:1.0: USB Mass Storage device detected [ 2192.042500] scsi9 : usb-storage 1-3:1.0 [ 2193.044219] scsi 9:0:0:0: Direct-Access WDC WD64 00BPVT-00HXZT0 PQ: 0 ANSI: 0 [ 2193.045083] sd 9:0:0:0: [sdb] 1250263728 512-byte logical blocks: (640 GB/596 GiB) [ 2193.045240] sd 9:0:0:0: [sdb] Write Protect is off [ 2193.045245] sd 9:0:0:0: [sdb] Mode Sense: 03 00 00 00 [ 2193.045384] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.045388] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.046259] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.046264] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.054389] sdb: sdb1 [ 2193.055092] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.055095] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.055098] sd 9:0:0:0: [sdb] Attached SCSI disk [ 2200.821345] usb 1-3: reset high-speed USB device number 5 using xhci_hcd [ 2200.835063] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800bc71e480 [ 2200.835068] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800bc71e4c0 [ 2267.897715] sd 9:0:0:0: [sdb] Unhandled sense code [ 2267.897719] sd 9:0:0:0: [sdb] [ 2267.897721] Result: hostbyte=0x07 driverbyte=0x08 [ 2267.897722] sd 9:0:0:0: [sdb] [ 2267.897724] Sense Key : 0x4 [current] [ 2267.897735] sd 9:0:0:0: [sdb] [ 2267.897736] ASC=0x0 ASCQ=0x0 [ 2267.897738] sd 9:0:0:0: [sdb] CDB: [ 2267.897740] cdb[0]=0x28: 28 00 4a 85 6e af 00 00 08 00 [ 2267.897746] end_request: I/O error, dev sdb, sector 1250258607 [ 2267.897750] Buffer I/O error on device sdb1, logical block 625129272 [ 2267.897752] Buffer I/O error on device sdb1, logical block 625129273 [ 2267.897753] Buffer I/O error on device sdb1, logical block 625129274 [ 2267.897754] Buffer I/O error on device sdb1, logical block 625129275 [ 2270.884154] usb 1-3: USB disconnect, device number 5 Bus 001 Device 010: ID 14cd:6116 Super Top M6116 SATA Bridge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x14cd Super Top idProduct 0x6116 M6116 SATA Bridge bcdDevice1.50 iManufacturer 1 Super Top iProduct3 USB 2.0 SATA BRIDGE iSerial 2 M6116018VE15 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6
Re: xhci ASMedia lockups - a theory and a patch
On Thu, Jan 16, 2014 at 10:21:11AM +, David Laight wrote: From: David Laight From: David Laight From: Alan Stern On Wed, 15 Jan 2014, David Laight wrote: I have a theory, I'll try to write a non-invasive patch. ... Doesn't this mean you shouldn't change the ownership of a LINK TRB until after you change the ownership of the TRB it points to? That is what I assume. In practise this means that the 'first_trb' (whose ownership is set last) has to be the one that is valid when prepare_ring() is called. The plan for the patch is: - Save the enq pointer in prepare_ring (in the ep_ring structure). - When writing a trb set the ownership unless it is the saved one (ignoring the value set by the caller). - At the end invert the ownership on the saved entry. Below is a possible patch, I've only compile tested it. I've minimalised the patch by not removing all the code that saves 'start_trb' and modifies the TRB_CYCLE bit. If the patch works those parts can also be tidied up. I've had some feedback (in a private email) that the patch helps. This was using the ASMedia controller with the asx88179_178a ethernet device. David, please post the contents of that private email to the list and Cc me. We don't debug in private in the kernel. So the theory was definitely on the right lines. And I managed to write the patch without any silly mistakes! Your theory about the ASMedia host may be correct. There are other host controllers (Synopsys, I think) that needed us to not give a link TRB over to the host until the TRB it pointed had the cycle bit set to hardware owned. ISTR that this was only triggered with USB 3.0 streams, at least on that Synopsys host. (BTW, you can find out why any part of the code was written by using `git blame filename`, although the original commit that fixed this bug has an entirely unhelpful description.) So, I agree that this needs to get fixed, especially since full UAS and streams support will be landing in the 3.15 kernel. However, I like the simple patch you posted much better than the second patch. The second patch is much too big to be back ported to stable, and we need to get this backported to stable. Please resend your previous patch. 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: [PATCH] xhci: Stop last TRB being a LINK TRB
On Fri, Jan 17, 2014 at 01:27:01PM +, David Laight wrote: At least some hardware (eg ASMedia PCIe cards) don't like processing a LINK TRB and then finding that the 'cycle' bit on the next TRB is 'unset'. As I mentioned, this patch is much too big to be backported to the stable trees. You need to break it up into the very minimal amount of code necessary to fix the ASMedia bug, and then clean up patches on top of that. The clean up patches can be queued for just the current kernel version. So, please try to turn this into a series of patches. I would suggest: 1. A minimal patch to ensure a link TRB isn't given over to hardware until after the TD it points to is. Your original patch seemed like the right size and complexity for that small fix. 2. A patch that removes the unused cleanup code at the end of xhci_queue_isoc_tx(). If it is unused as you claim, it does not need to be part of the minimal bug fix patch, since the code will never be run. 3. A patch to remove the 'flip_cycle' parameter to td_to_noop(), since the only code that used it was in xhci_queue_isoc_tx(). 4. Make any simplifications of the cycle handover code. Do not include simplifications in the minimal patch. Please break the simplifications up into easily-readable chunks. 5. Trace short reads only when they're unexpected. I know you've been trying to push some of these cleanups in previous patches, but it's not generally a good idea to push both cleanups and bug fixes into stable. I've been bitten on that in the past, with a simple bug fix and arithmetic shortcut combined in one patch causing four different stable kernels to fail, and a big mess to fix all of them. Please break up these changes into separate commits. It's too hard to review and catch bugs with this large of a change. - if (trb_comp_code == COMP_SHORT_TX) + if (*status == -EREMOTEIO) This is an unrelated change not described in your patch description. Please remove it from the bug fix patch, and create a separate patch describing why you think it's necessary. 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: Bug#733826: [PATCH] xhci: Set scatter-gather limit to avoid failed block writes.
On Fri, Jan 17, 2014 at 04:18:52PM +0100, Johannes Stezenbach wrote: On Tue, Jan 07, 2014 at 02:40:39AM +, Ben Hutchings wrote: On Tue, 2014-01-07 at 07:01 +0800, jida...@jidanni.org wrote: Don't worry, I'll trust you! Plus I'm 53. I don't think anyone else has reproduced this problem, so you are the person in the best place to check that these changes really fix it. You can test patches against the Debian kernel package by following the instructions here: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official Sascha Weaver found a way to reproduce the problem and was nice enough to test this patch, and also the one in Debian bug #733907. See: http://marc.info/?l=linux-usbm=138996707603975w=2 Ok, thanks for letting me know, Johannes. The patch is queued for 3.14, and won't land in the stable kernels until after 3.14-rc1 (in a couple weeks). 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: EHCI host broken -- interrupts disabled
On Mon, Jan 20, 2014 at 11:39:18AM -0800, Sarah Sharp wrote: On Mon, Jan 20, 2014 at 12:15:47PM +, Chen, Jamie wrote: Try to apply this patch to kernel 3.8.0. Make sure the ehci can work fine and lspci show that PCI_COMMAND_INTX_DISABLE is 0. The patch can resolved this issue. Great! Thanks for testing, Jamie. Bjorn, can you add me to the Cc list for this patch? I'd like to notify other Linux distros when it lands so they can pick it up. Might as well mark it for sta...@vger.kernel.org, so that it does automatically get propagated to the distros... 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
[PATCH] usb: host: xhci: fix HALTED endpoint handling
If the HW reports the endpoint as Halted, there's no need to start any URB for that endpoint, we can simply return -EPIPE and this will tell upper layers that the endpoint is, indeed, halted. This patch fixes usbtest's set/clear halt test #13 on xHCI-based hosts. Cc: sta...@vger.kernel.org Signed-off-by: Felipe Balbi ba...@ti.com --- Hi Sarah, seems like this has been broken for quite a long time. I tested the patch on an AM437x which has XHCI Host and the same IP configured as device as well (two dwc3 instances, basically). It has been running for the past hour or so without any failures when running testusb -t 13 -c 5000 -s 2048 -a in a loop, but if you think there's a better way to fix this, let me know. I just didn't understand why xhci-hcd still queues the URB even though HW already told us the endpoint is halted. Any comments ? cheers drivers/usb/host/xhci-ring.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 53c2e29..e9df61a 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2959,7 +2959,8 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring, /* XXX not sure if this should be -ENOENT or not */ return -EINVAL; case EP_STATE_HALTED: - xhci_dbg(xhci, WARN halted endpoint, queueing URB anyway.\n); + xhci_dbg(xhci, WARN halted endpoint.\n); + return -EPIPE; case EP_STATE_STOPPED: case EP_STATE_RUNNING: break; -- 1.8.4.GIT -- 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
[GIT PULL] USB patches for 3.14-rc1
The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c:
Linux 3.13-rc5 (2013-12-22 13:08:32 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-3.14-rc1
for you to fetch changes up to 2fc5a7dace3c43e62402ab4e8800a8f1834ffe2a:
usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX
(2014-01-13 15:55:19 -0800)
USB patches for 3.14-rc1
Here's the big USB pull request for 3.14-rc1
Lots of little things all over the place, and the usual USB gadget
updates, and XHCI fixes (some for an issue reported by a lot of people.)
USB PHY updates as well as chipidea updates and fixes.
All of these have been in the linux-next tree with no reported issues.
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Aaro Koskinen (7):
ARM: OMAP1: USB: move omap_usb_config to platform data
usb: omap1: add extcon to platform data
usb: omap1: OTG controller driver
usb: omap1: Tahvo USB transceiver driver
usb: phy: tahvo: fix smatch warnings
usb: phy: isp1301-omap: fix smatch warnings
usb: phy: fix some Kconfig descriptions
Alan Stern (1):
USB: fix race between hub_disconnect and recursively_mark_NOTATTACHED
Alexander Shiyan (2):
usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs
usb: chipidea: usbmisc: Add support for i.MX51 CPU
Andreas Larsson (1):
usb: gadget: Add UDC driver for Aeroflex Gaisler GRUSBDC
Andrew Lunn (2):
tty: Add C_CMSPAR(tty)
USB: serial: add Moxa UPORT 12XX/14XX/16XX driver
Andrzej Pietrasiewicz (21):
usb: gadget: composite: redirect setup requests
usb: gadget: factor out alloc_ep_req
usb: gadget: f_loopback: add configfs support
usb: gadget: f_sourcesink: add configfs support
usb: gadget: configfs: allow setting function instance's name
usb: gadget: g_ffs: remove a reduntant gfs_ether_setup variable
usb: gadget: g_ffs: convert to new interface of f_ecm
usb: gadget: f_ecm: remove compatibility layer
usb: gadget: g_ffs: convert to new interface of f_subset
usb: gadget: f_subset: remove compatibility layer
usb: gadget: g_ffs: convert to new interface of f_rndis
usb: gadget: f_rndis: remove compatibility layer
usb: gadget: rndis: merge u_rndis.ko with usb_f_rndis.ko
usb: gadget: FunctionFS: Remove VLAIS usage from gadget code
usb: gadget: FunctionFS: create utility file
usb: gadget: FunctionFS: add devices management code
usb: gadget: FunctionFS: convert to new function interface with backward
compatibility
usb: gadget: g_ffs: convert to new interface of f_fs
usb: gadget: FunctionFS: Remove compatibility layer
usb: gadget: FunctionFS: add configfs support
usb: gadget: nokia: fix error recovery path for optional functions
Anton Tikhomirov (5):
usb: phy: fsm: protect against multiple inclusions
usb: phy: replace spinlock with mutex in OTG FSM
usb: phy: move OTG FSM header
usb: phy: Add OTG FSM configuration option
usb: phy: Fix double lock in OTG FSM
Apelete Seketeli (2):
usb: musb: add support for JZ4740 usb device controller
usb: musb: fix setting JZ4740 gadget periphal mode on reset
Arnd Bergmann (1):
USB: fix: ohci-at91 mismerge build error
Ben Hutchings (2):
USB: emi62: Provide the correct bitstream firmware
xhci: Avoid infinite loop when sg urb requires too many trbs
Bin Liu (1):
usb: musb: dsps: polling ID pin status only in otg mode
Bjørn Mork (2):
usb: cdc-wdm: avoid hanging on zero length reads
usb: cdc-wdm: resp_count can be 0 even if WDM_READ is set
Boris BREZILLON (3):
usb: ohci-at91: replace request_mem_region + ioremap by
devm_ioremap_resource
usb: ohci-at91: use dev variable instead of pdev-dev
usb: ohci-at91: use device managed clk retrieval
Chris Ruehl (3):
usb: chipidea: Reallocate regmap only if lpm is detected
usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
usb: chipidea: put hw_phymode_configure before ci_usb_phy_init
Colin Leitner (1):
USB: ftdi_sio: added CS5 quirk for broken smartcard readers
Dan Carpenter (1):
usb: gadget: update some out of date comments
Dan Williams (2):
usb: xhci: change enumeration scheme to 'new scheme' by default
xhci: clarify logging in xhci_setup_device
Daniel Mack (7):
usb: musb: unconditionally save and restore the context on suspend
usb: musb: call musb_port_suspend from musb_bus_suspend
usb: musb: dsps: add {tx,rx}_mode to wrapper
usb: musb: dsps: add support for suspend and resume
usb: musb: finish suspend/reset work independently from musb_hub_control()
usb: musb: fix prototype for
Re: XHCI - USB3 HDD not recognised
Hi Sarah.
On 12/18/13 17:23, Chris Clayton wrote:
On 12/17/13 21:39, Sarah Sharp wrote:
On Sat, Dec 14, 2013 at 11:59:15AM +, Chris Clayton wrote:
On 12/13/13 16:38, Sarah Sharp wrote:
On Fri, Dec 13, 2013 at 02:31:47PM +, Chris Clayton wrote:
Hi,
Hi Chris,
Hi Sarah and thanks for the reply.
Thanks for the bug report!
Firstly, I'm not subscribed, so please cc me on any replies.
I see the problem I describe below on 3.12.[0..5] and on the current 3.13
development kernel, including a kernel pulled
from Linus' tree just a few minutes ago. The diagnostics below and the
config file attached are from 3.12.5. I can
easily repeat on 3.13 if that would be more useful.
My Fujitsu Lifebook AH531 laptop has an expresscard slot and I bought an
expresscard USB3.0 card.
So, after looking at the two different dmesg outputs, I think either
your host controller or the device is just not working at USB 3.0
speeds. When you hot-plug the device, the host doesn't give a port
status event at all, so there's really nothing the xHCI driver can do.
Even when you plug in the host with the hard drive attached, it only
detects it as a USB 2.0 device.
It really feels like the hardware is just broken. Have you tried this
host and device combination under Windows? I hate to say it, but
perhaps you want to try a different vendor for either the host or
device?
I think your feeling that hardware is broken is probably right. I've abandoned
that card and bought one with a different
an NEC/Renesas chipset. That works fine - udev events are raised when drives
are {un,}plugged and the performance
improvement over USB2 is very noticeable.
This message should help people who in the future search looking for
information on the linux compatibility of
expresscard USB3 adapters. The three-port adapters (in this case manufactured
by AKE and) based on the Fresco Logic
chipset do not, at the time of writing, work with the linux XHCI driver.
Thanks for your analysis.
Once I got the drivers installed, Windows 7 reports the card as Fresco
Logic XHCI (USB3) Controller FL1100 Series and
Fresco Logic xHCI (USB3) Root Hub and detects the drive when I plug that
in. However, it reports that the drive could
transfer data faster if it where ... connected to a Super Speed USB 3.0
port.
If you plug in other USB 2.0 or 1.1 devices into the xHCI expresscard,
do those work? E.g. a mouse, keyboard, hub, etc. If they do, I would
lean towards trying to find a replacement USB 3.0 hard drive. If they
don't, I would try to replace the xHCI host. Or if the host is cheaper
to replace, maybe try replacing that first?
My USB 2.0 mouse and USB 1.1 speakers are detected and work fine. Oddly
enough though, when I plugged in the HDD
alongside the mouse and speakers it was detected. usbview reports it as USB
2.1. I then detached all three devices and
unplugged the card. When I re-attached the mouse and the speakers, they were
detected. The drive, however, was not
detected - the no hotplug settings from platform message I've reported
previously was produced
So, it would appear that Windows 7 sees the card as not actually supporting
USB 3.0, but the drive as preferring USB
3.0. Linux, on the other hand, sees the card as supporting USB 3.0, but the
drive as USB 2.1.
I've cut and paste the relevant data from usbview into a file which is
attached, as is the output from lsusb -v with the
devices attached.
Sorry I can't be of more help, I just don't know how to fix this. The
only thing I could possibly think would help is enabling the compliance
mode polling. Maybe the USB 3.0 port is stuck in compliance mode, and
can't give the xHCI host a port status change event? Can you send me
the output of `sudo lspci -vvv -n` and `sudo lspci`?
That output is in the attached file lspci.data
Thanks for looking into this, Sarah.
Chris
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: AM335x USB DMA seems broken on ISOC URBs
Hi Daniel, On Sat, Jan 18, 2014 at 04:12:24PM +0100, Daniel Mack wrote: On 01/17/2014 05:27 PM, Ezequiel Garcia wrote: On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: [..] Did you try this with a different type of peripheral hardware, a USB audio device for example? [..] Finally I found some time to setup the board and do some new tests using an UVC webcam (which might behave better given it should transfer smaller buffers). The result is not encouraging! Device is detected regularly, but then I get some ugly messages on the first command: # yavta /dev/video0 -l [ 21.279722] BUG: spinlock cpu recursion on CPU#0, kworker/0:2/46 [ 21.286041] lock: 0xdf01e010, .magic: dead4ead, .owner: yavta/78, .owner_cpu: 0 [ 21.293800] CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc8-next-20140120-dirty #69 [ 21.302571] Workqueue: events musb_host_finish_resume [ 21.307899] [c000faa1] (unwind_backtrace) from [c000e8db] (show_stack+0xb/0xc) [ 21.315844] [c000e8db] (show_stack) from [c003f981] (do_raw_spin_lock+0xc5/0xe8) [ 21.323969] [c003f981] (do_raw_spin_lock) from [c030c949] (_raw_spin_lock_irqsave+0xd/0x10) [ 21.333094] [c030c949] (_raw_spin_lock_irqsave) from [c021927b] (musb_host_finish_resume+0xf/0x60) [ 21.342860] [c021927b] (musb_host_finish_resume) from [c0031709] (process_one_work+0xad/0x224) [ 21.352258] [c0031709] (process_one_work) from [c0031b19] (worker_thread+0xc9/0x270) [ 21.360750] [c0031b19] (worker_thread) from [c00355c7] (kthread+0x7b/0x94) [ 21.368325] [c00355c7] (kthread) from [c000cb7d] (ret_from_fork+0x11/0x34) [ 27.352780] BUG: spinlock lockup suspected on CPU#0, kworker/0:2/46 [ 27.359350] lock: 0xdf01e010, .magic: dead4ead, .owner: yavta/78, .owner_cpu: 0 [ 27.367104] CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc8-next-20140120-dirty #69 [ 27.375860] Workqueue: events musb_host_finish_resume [ 27.381162] [c000faa1] (unwind_backtrace) from [c000e8db] (show_stack+0xb/0xc) [ 27.389103] [c000e8db] (show_stack) from [c003f971] (do_raw_spin_lock+0xb5/0xe8) [ 27.397224] [c003f971] (do_raw_spin_lock) from [c030c949] (_raw_spin_lock_irqsave+0xd/0x10) [ 27.406348] [c030c949] (_raw_spin_lock_irqsave) from [c021927b] (musb_host_finish_resume+0xf/0x60) [ 27.416109] [c021927b] (musb_host_finish_resume) from [c0031709] (process_one_work+0xad/0x224) [ 27.425506] [c0031709] (process_one_work) from [c0031b19] (worker_thread+0xc9/0x270) [ 27.433991] [c0031b19] (worker_thread) from [c00355c7] (kthread+0x7b/0x94) [ 27.441566] [c00355c7] (kthread) from [c000cb7d] (ret_from_fork+0x11/0x34) Any ideas from the maintainers? PS: As expected TI's PSP v3.2 driver works just fine :P -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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: [Stlinux-devel] FW: [PATCH (linux-stm) 1/2] usb: dwc3: fix kernel compilation in gadget mode
On 1/17/2014 3:43 AM, Felipe Balbi wrote: Hi, Hello Felipe, On Thu, Jan 16, 2014 at 01:58:30PM +0100, Carmelo Amoroso wrote: I'm one of the maintainer of the STLinux kernel @ST. Let me clarify the inconvenience occurred about this patches. We are back-porting some patches from upstream for DWC3 driver into our 3.4.58 based kernel as our chipsets use this host controller. right, that's ok. Would be nice to see your glue layer hitting upstream, though. we are working on 3.12 kernel indeed as well for upstream. The way we do it, is exactly what you referred to, by using 'git cherry-pick -xs' to keep authorship, upstream reference and so on, and when cherry-pick is not straightforward, we are used to specify what are the modification added by us wrt the upstream patch. git cherry-pick would give a merge conflict, in which case you would just solve it. In any case, if you cherry-pick every patch, you would never have conflicts to solve, just the usual API change which is usually very simple to sort out. yes, right. You might have a look at some recent backport stuff we did for our 3.4 kernel: http://git.stlinux.com/?p=stm/linux-stm.git;a=commit;h=cef7a3a85413142e73315463eae2fedea451490e http://git.stlinux.com/?p=stm/linux-stm.git;a=commit;h=71538603d521a6e1b5d5b4ad47c77e6f9dfc8882 (feel free to browse our git.stlinux.com) just did, you guys have a few things to sort out on your glue layer: for sure a) PHY shouldn't be directly accessed by the glue layer, just add a PHY driver and you get all of that for free. we are not relying upon the USB_PHY driver in 3.4 (we have it in 3.10) b) you shouldn't access DWC3_GSBUSCFG0 outside of core.c. The right way to handle that, would be to either pass a quirk flag, or figure out a detect that the underlying AXI needs this particular configuration. thanks for the hint One thing though, why wasn't that bit set properly during coreConsultant configuration ? Frankly I don't know. c) you should be using devm_ioremap_resource() instead of devm_request_and_ioremap() ok d) that xhci_hub_on_disconnect() is nasty yes, I know. We had to manage under a big pressure and with a short time such feature and the fastest way was to implement it and use 'weak' symbol. I know it will not work if some other xhci controllers would require it. This is why we are maintaining it internally and not posted for upstream. A proper and clean design should come later. For sure, I'd like to post to the community. You will see authorship not changed, properly upstream commit reference and so on. Regarding the merged patches sent by the colleague Giuseppe, I asked him to provide me an unique patch just to check locally if the issue were actually fixed. It should have been a private, temporary hack for testing. I see. It was not meant to be applied in the kernel, neither he had the intention to change authorship. Due to bad git configuration (and user mistakes), when he sent the patch it went to our devel-list plus you as in the signed-off list, but purely by mistake (--suppress-xxx neither passed) As kernel maintainer, I can guarantee such a work will not included at all in our kernel. It has been just due to user mistakes. We seriously consider copyright laws. Our apologies for such inconvenience. apologies accepted, thanks to you thanks for clarifying so quickly. it was our duty Hope to see your glue layer in mainline soon, believe me, it'll make your life a lot easier in the long run. I do fully agree. cheers cheers, Carmelo -- 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-PATA bridge inic-1511. It is not possible to read a lot of audio disks
On Sat, 18 Jan 2014, Andrey Karpenko wrote: Hi Greg Kroah-Hartman asks me to send it to you https://bugzilla.kernel.org/show_bug.cgi?id=68941 It would help if you could post a usbmon trace for the Inspiron computer, showing the problem. (See the kernel source file Documentation/usb/usbmon.txt for instructions.) If possible, you should use the new 3.13 kernel. 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: chipidea udc: ctrl traffic on endpoint 8
On Mon, Jan 20, 2014 at 11:26:02AM +0100, Matthieu CASTET wrote: Le Sat, 18 Jan 2014 09:03:01 +0100, Michael Grzeschik m...@pengutronix.de a écrit : On Fri, Jan 17, 2014 at 05:15:49PM +0100, Matthieu CASTET wrote: How many fifo have your controller (hw_ep_max) ? It's MX28. For this hw_ep_max is 16. When you say fifo on position 8, you mean in software (in ci_hw_ep array), but not in hardware (ENDPTCTRLx) ? Yes. In the code i is the index of the hwep array. AFAIK the array is organized like this; i == [0:7] out endpoints i == [8:15] in endpoints. Therefor index 0 is ep0out and index 8 is ep0in. Could you try the attached patch ? The SETUPSTAT register is only 16 bits. For index 8 (ep_to_bit(8) = 16) we shouldn't read it. Yes, the ep_to_bit is not suitable for clear ENDPTSETUPSTAT. In fact, we only need to clear bit0 at ENDPTSETUPSTAT for ep0out since we only receive setup packet at ep0out. Michael's problem is too many warning message for ep0in, the possible reason is ENDPTSETUPSTAT BIT(16) is not zero at that time (it is strange!). In fact, for ep0in complete handler, it should do noop except clear the complete status and notify class driver. I think you patch can solve Michael's problem currently. I will split ep0 and non-ep0 complete handler soon according your suggestion below. Peter Matthieu PS : the code for handling ctrl endpoint is a bit messy. We should split isr_tr_complete_handler in isr_tr_complete_handler and isr_tr_setup_handler. -- Best Regards, Peter Chen -- 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/1] usb: chipidea: udc: delete wrong warning message for ep0in
On Mon, Jan 20, 2014 at 09:13:11AM +0800, Peter Chen wrote:
The idea of this message is: the non-ep0 should not use ctrl
transfer. But it does not cover the ep0in which uses ctrl
transfer too.
This commit deletes the warning message at interrupt handler,
and adds judgement at ep_enable, if non-ep0 requests ctrl transfer,
it will indicate an error.
Reported-by: Michael Grzeschik m...@pengutronix.de
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/udc.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 09366b4..646d958 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1001,11 +1001,6 @@ __acquires(ci-lock)
!hw_test_and_clear_setup_status(ci, i))
continue;
- if (i != 0) {
- dev_warn(ci-dev, ctrl traffic at endpoint %d\n, i);
- continue;
- }
-
/*
* Flush data and handshake transactions of previous
* setup packet.
@@ -1201,6 +1196,11 @@ static int ep_enable(struct usb_ep *ep,
retval |= hw_ep_enable(hwep-ci, hwep-num, hwep-dir,
hwep-type);
+ if (hwep-num != 0 hwep-type == USB_ENDPOINT_XFER_CONTROL) {
+ dev_err(hwep-ci-dev, Set control xfer at non-ep0\n);
+ retval = -EINVAL;
+ }
+
spin_unlock_irqrestore(hwep-lock, flags);
return retval;
}
--
1.7.8
Michael, this patch may not fix your problem totally, as a temp solution,
you can use the matthieu's patch at your email thread.
--
Best Regards,
Peter Chen
--
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: at91: fix the number of endpoint parameter
On 11:39 Mon 20 Jan , Bo Shen wrote:
Hi J,
On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:59 Fri 17 Jan , Bo Shen wrote:
In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
is only 7. So, fix it for sama5d3 SoC using the udc-num_ep.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/atmel_usba_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index 2cb52e0..7e67a81 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1670,7 +1670,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (ep_status) {
int i;
- for (i = 0; i USBA_NR_ENDPOINTS; i++)
+ for (i = 0; i udc-num_ep; i++)
no the limit need to specified in the driver as a checkpoint by the
compatible
or platform driver id
You mean, we should not trust the data passed from dt node or
platform data? Or do you think we should do double confirm?
no base on the driver name or the compatible you will known the MAX EP
not based on the dt ep description
as we do on pinctrl-at91
Best Regards,
J.
if (ep_status (1 i)) {
if (ep_is_control(udc-usba_ep[i]))
usba_control_irq(udc, udc-usba_ep[i]);
--
1.8.5.2
Best Regards,
Bo Shen
--
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: phy: msm: tiny leak on error in probe()
Free motog on error. This is more to appease the static checkers than
a real worry.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8546c8dccd51..64c9d14ea77d 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1429,7 +1429,8 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
motg-phy.otg = kzalloc(sizeof(struct usb_otg), GFP_KERNEL);
if (!motg-phy.otg) {
dev_err(pdev-dev, unable to allocate msm_otg\n);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto free_motg;
}
motg-pdata = dev_get_platdata(pdev-dev);
--
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 v3] phy: Add new Exynos5 USB 3.0 PHY driver
On Mon, Jan 20, 2014 at 7:12 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Sorry, forgot to add a Reviewed-by tag from Felipe. :-(
Will update in the next version of patch after getting a feedback on this patch.
---
Changes from v2:
1) Added support for multiple PHYs (UTMI+ and PIPE3) and
related changes in the driver structuring.
2) Added a xlate function to get the required phy out of
number of PHYs in mutiple PHY scenerio.
3) Changed the names of few structures and variables to
have a clearer meaning.
4) Added 'usb3phy_config' structure to take care of mutiple
phys for a SoC having 'exynos5_usb3phy_drv_data' driver data.
5) Not deleting support for old driver 'phy-samsung-usb3' until
required support for generic phy is added to DWC3.
.../devicetree/bindings/phy/samsung-phy.txt| 49 ++
drivers/phy/Kconfig|8 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usb3.c | 621
4 files changed, 679 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usb3.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa..57079f8 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,52 @@ Required properties:
- compatible : should be samsung,exynos5250-dp-video-phy;
- reg : offset and length of the Display Port PHY register set;
- #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung Exynos5 SoC series USB 3.0 PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usb3phy - for exynos5250 SoC,
+ - samsung,exynos5420-usb3phy - for exynos5420 SoC.
+- reg : Register offset and length of USB 3.0 PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB 3.0 controller IP clock),
+ used for register access.
+ - usb3phy_refclk: PHY's reference clock (usually crystal clock),
+ associated by phy name, used to determine bit values for
+ clock settings register.
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY operation
+ depicted as 'sclk_usbphy30' in CMU of Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usb3phy and samsung,exynos5420-usb3phy compatible
+PHYs, the second cell in the PHY specifier identifies the PHY id, which is
+interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usb3phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, usb3phy_refclk;
+ samsung,syscon-phandle = pmu_syscon;
+ #phy-cells = 1;
+ };
+
+- aliases: For SoCs like Exynos5420 having multiple USB PHY controllers,
+ 'usb3_phy' nodes should have numbered alias in the aliases node,
+ in the form of usb3phyN, N = 0, 1... (depending on number of
+ controllers).
+Example:
+ aliases {
+ usb3phy0 = usb3_phy0;
+ usb3phy1 = usb3_phy1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..32f9f38 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,12 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_EXYNOS5_USB3
+ tristate Exynos5 SoC series USB 3.0 PHY driver
+ depends on ARCH_EXYNOS5
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB 3.0 PHY support for Exynos 5 SoC series
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..9c06a61 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) +=
phy-exynos-dp-video.o
