[PATCH] devio: fix issue with log flooding
usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085 Signed-off-by: Oliver Neukum oneu...@suse.de CC: sta...@vger.kernel.org --- drivers/usb/core/devio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 257876e..0b59731 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1509,7 +1509,7 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb u = (is_in ? URB_DIR_IN : URB_DIR_OUT); if (uurb-flags USBDEVFS_URB_ISO_ASAP) u |= URB_ISO_ASAP; - if (uurb-flags USBDEVFS_URB_SHORT_NOT_OK) + if (uurb-flags USBDEVFS_URB_SHORT_NOT_OK is_in) u |= URB_SHORT_NOT_OK; if (uurb-flags USBDEVFS_URB_NO_FSBR) u |= URB_NO_FSBR; -- 1.8.4.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
musb + full speed device (2)
Hello, we are having a curious behaviour with the USB OTG throughput on a DM3730. Specifically, we get a much greater throughput with high cpu loads. The DM3730 OTG is running has HOST and attached to a custom board. That board is a full-speed device, with 64B Bulk endpoints. The system is the following : Linux DM-37x 3.0.0-BSP-dm37x-2.3-2 #5 PREEMPT Thu Jul 31 12:11:28 CEST 2014 armv7l GNU/Linux and the musb driver is compiled using Inventra DMA. A test program runs that retrieves data from the board with libusb bulk transfers. If we run the program standalone, the cpu load as reported by top is less than 5% and the througput we get is ~200KB/s. If we run gzip -c /dev/urandom /dev/null the cpu rises up to almost 100%. If then we run our program the throughput increases to ~480 KB/s, which is the maximum the board delivers, so we attain all the throughput available. We'd expect less throughput with higher cpu load because of interrupt latency :) So why ? Could it be related to power management ( I mean, with low load the CPU enters in some low power state that at the same time lowers the USB Clock or the bus between the CPU and the USB..) ? We have tested setting the clock frequency to a fixed 1000MHz with cpufreq-set but, although the throughput seems to increase about 30 KB/s we are still far from the 480 KB/s with 100% CPU load. These are the musb logs for two transfers, one with low throughput and the other with high. Baud Rate: ~200KB/s, CPU Load 10% usb0008 means Start of Frame - 3 transactions of 64B per frame [ 6637.993194] musb-hdrc musb-hdrc: RXCSR10 := 0620 [ 6637.993286] musb-hdrc musb-hdrc: ** IRQ host usb0008 tx rx0400 [ 6637.993316] musb-hdrc musb-hdrc: == Power=e0, DevCtl=5d, int_usb=0x8 [ 6637.993377] musb-hdrc musb-hdrc: == hw 10 rxcsr 0003, urb actual 0 (+dma 11) [ 6637.993408] musb-hdrc musb-hdrc: RX10 count 64, buffer 0x85a9c000 len 0/3851 [ 6637.993469] musb-hdrc musb-hdrc: == hw 10 rxcsr a000, urb actual 0 (+dma 64) [ 6637.993499] musb-hdrc musb-hdrc: ep 10 dma reset, rxcsr 0020, rxcount 0 [ 6637.993560] musb-hdrc musb-hdrc: ** IRQ host usb tx rx0400 [ 6637.993621] musb-hdrc musb-hdrc: == hw 10 rxcsr 0203, urb actual 64 (+dma 64) [ 6637.993652] musb-hdrc musb-hdrc: RX10 count 64, buffer 0x85a9c040 len 64/3851 [ 6637.993682] musb-hdrc musb-hdrc: == hw 10 rxcsr a200, urb actual 64 (+dma 64) [ 6637.993743] musb-hdrc musb-hdrc: ep 10 dma reset, rxcsr 0220, rxcount 0 [ 6637.994079] musb-hdrc musb-hdrc: ** IRQ host usb0008 tx rx0400 [ 6637.994110] musb-hdrc musb-hdrc: == Power=e0, DevCtl=5d, int_usb=0x8 [ 6637.994140] musb-hdrc musb-hdrc: == hw 10 rxcsr 0003, urb actual 128 (+dma 64) [ 6637.994201] musb-hdrc musb-hdrc: RX10 count 64, buffer 0x85a9c080 len 128/3851 [ 6637.994232] musb-hdrc musb-hdrc: == hw 10 rxcsr a000, urb actual 128 (+dma 64) [ 6637.994262] musb-hdrc musb-hdrc: ep 10 dma reset, rxcsr 0020, rxcount 0 [ 6637.994354] musb-hdrc musb-hdrc: ** IRQ host usb tx rx0400 [ 6637.994384] musb-hdrc musb-hdrc: == hw 10 rxcsr 0203, urb actual 192 (+dma 64) [ 6637.994415] musb-hdrc musb-hdrc: RX10 count 64, buffer 0x85a9c0c0 len 192/3851 [ 6637.994476] musb-hdrc musb-hdrc: == hw 10 rxcsr a200, urb actual 192 (+dma 64) [ 6637.994506] musb-hdrc musb-hdrc: ep 10 dma reset, rxcsr 0220, rxcount 0 [ 6637.994567] musb-hdrc musb-hdrc: ** IRQ host usb tx rx0400 [ 6637.994598] musb-hdrc musb-hdrc: == hw 10 rxcsr 0003, urb actual 256 (+dma 64) [ 6637.994659] musb-hdrc musb-hdrc: RX10 count 64, buffer 0x85a9c100 len 256/3851 [ 6637.994689] musb-hdrc musb-hdrc: == hw 10 rxcsr a000, urb actual 256 (+dma 64) [ 6637.994750] musb-hdrc musb-hdrc: ep 10 dma reset, rxcsr 0020, rxcount 0 [ 6637.995056] musb-hdrc musb-hdrc: ** IRQ host usb0008 tx rx0400 [ 6637.995086] musb-hdrc musb-hdrc: == Power=e0, DevCtl=5d, int_usb=0x8 [ 6637.995117] musb-hdrc musb-hdrc: == hw 10 rxcsr 0203, urb actual 320 (+dma 64) [ 6637.995178] musb-hdrc musb-hdrc: RX10 count 64, buffer 0x85a9c140 len 320/3851 [ 6637.995269] musb-hdrc musb-hdrc: == hw 10 rxcsr a200, urb actual 320 (+dma 64) [ 6637.995300] musb-hdrc musb-hdrc: ep 10 dma reset, rxcsr 0220, rxcount 0 [ 6637.995361] musb-hdrc musb-hdrc: ** IRQ host usb tx rx0400 [ 6637.995391] musb-hdrc musb-hdrc: == hw 10 rxcsr 0003, urb actual 384 (+dma 64) [ 6637.995452] musb-hdrc musb-hdrc: RX10 count 64, buffer 0x85a9c180 len 384/3851 [ 6637.995483] musb-hdrc musb-hdrc: == hw 10 rxcsr a000, urb actual 384 (+dma 64) [ 6637.995544] musb-hdrc musb-hdrc: ep 10 dma reset, rxcsr 0020, rxcount 0 [ 6637.995605] musb-hdrc musb-hdrc: ** IRQ host usb tx rx0400 [ 6637.995635] musb-hdrc musb-hdrc: == hw 10 rxcsr 0203, urb actual 448 (+dma 64) [ 6637.995666] musb-hdrc musb-hdrc: RX10 count 64, buffer 0x85a9c1c0 len 448/3851 [ 6637.995697] musb-hdrc musb-hdrc: == hw 10 rxcsr a200, urb actual 448 (+dma 64) [ 6637.995758] musb-hdrc musb-hdrc: ep 10 dma reset, rxcsr 0220, rxcount 0 [
Re: musb + full speed device (2)
Hi, Your kernel is ancient. You should either ask your kernel supplier for support or switch to using a current upstream kernel if you want help here. I can just give some general libusb advice. Pedro Erencia wrote: we are having a curious behaviour with the USB OTG throughput on a DM3730. Specifically, we get a much greater throughput with high cpu loads. .. A test program runs that retrieves data from the board with libusb bulk transfers. Does the program use the async libusb API to ensure that multiple transfers are submitted at any given time? If not, and it is calling libusb_bulk_transfer() in a loop, then the USB controller will be idle a lot, until Linux has scheduled the libusb program, until the program has looped around and submitted another transfer. By submitting multiple transfers at once you ensure that the host controller hardware will work independently of whatever else is going on in the system. It's like with all DMA. You need to prepare buffers ahead of time. //Peter -- 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 0/2] usb: renesas_usbhs: Add device tree support for R-Car H2 and M2
This driver supports other SoCs, but they need boards/Soc depend code. So, this patch adds device tree support for R-Car H2 and M2 initially. Yoshihiro Shimoda (2): usb: renesas_usbhs: Add device tree bindings documentation usb: renesas_usbhs: Add device tree support for R-Car H2 and M2 .../devicetree/bindings/usb/renesas_usbhs.txt | 24 +++ drivers/usb/renesas_usbhs/common.c | 43 2 files changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/renesas_usbhs.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] serial/option: Add support for Option GTM671WFS
After this patch: [5.389385] usbserial: USB Serial support registered for GSM modem (1-port) [5.390181] option 2-1.4:1.0: GSM modem (1-port) converter detected [5.390556] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB0 [5.390636] option 2-1.4:1.1: GSM modem (1-port) converter detected [5.390935] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB1 [5.391002] option 2-1.4:1.2: GSM modem (1-port) converter detected [5.391258] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB2 [5.391318] option 2-1.4:1.3: GSM modem (1-port) converter detected [5.391650] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB3 [5.391685] option 2-1.4:1.4: GSM modem (1-port) converter detected [5.391895] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB4 [5.391927] option 2-1.4:1.5: GSM modem (1-port) converter detected [5.392076] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB5 [5.392109] option 2-1.4:1.6: GSM modem (1-port) converter detected [5.392278] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB6 root@qt5022:~# lsusb -d 0af0: -vvv Bus 002 Device 003: ID 0af0:9200 Option Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0af0 Option idProduct 0x9200 bcdDevice0.00 iManufacturer 3 Option N.V. iProduct2 Globetrotter HSUPA Modem iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 200 bNumInterfaces 8 bConfigurationValue 1 iConfiguration 1 Option Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol 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 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 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 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None
Re: musb + full speed device (2)
2014-08-01 13:33 GMT+02:00 Peter Stuge pe...@stuge.se: Hi, Your kernel is ancient. You should either ask your kernel supplier for support or switch to using a current upstream kernel if you want help here. I can just give some general libusb advice. Pedro Erencia wrote: we are having a curious behaviour with the USB OTG throughput on a DM3730. Specifically, we get a much greater throughput with high cpu loads. .. A test program runs that retrieves data from the board with libusb bulk transfers. Does the program use the async libusb API to ensure that multiple transfers are submitted at any given time? If not, and it is calling libusb_bulk_transfer() in a loop, then the USB controller will be idle a lot, until Linux has scheduled the libusb program, until the program has looped around and submitted another transfer. By submitting multiple transfers at once you ensure that the host controller hardware will work independently of whatever else is going on in the system. It's like with all DMA. You need to prepare buffers ahead of time. //Peter Hi Peter, Unfortunately we cannot change the linux kernel, we are tied to the BSP supplied. :( We are currently doing synchronous bulk transfers but we also tested the suggested approach and the results were the same. What really puzzles me is the fact that higher cpu load results in better throughput. Apart from a power management issue, i cannot find any other explanation... -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb + full speed device (2)
Pedro Erencia wrote: Unfortunately we cannot change the linux kernel, we are tied to the BSP supplied. :( Then unfortunately you cannot get any help from the community, but are tied also to the BSP supplier for your support. :( We are currently doing synchronous bulk transfers but we also tested the suggested approach and the results were the same. Ok. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb + full speed device (2)
2014-08-01 15:33 GMT+02:00 Peter Stuge pe...@stuge.se: Pedro Erencia wrote: Unfortunately we cannot change the linux kernel, we are tied to the BSP supplied. :( Then unfortunately you cannot get any help from the community, but are tied also to the BSP supplier for your support. :( We are currently doing synchronous bulk transfers but we also tested the suggested approach and the results were the same. Ok. //Peter Last time i asked the community I received support, even without having to change the kernel. At least some interesting indications. I think the behaviour is strange enough to give it some thought before going the easy way and, probably, find that nothing changed. Anyway, 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: XHCI dies after several tries to enumerate a USB mouse
On 07/30/2014 12:02 PM, zed...@gmx.net wrote: Overview: XHCI dies if i have my USB mouse plugged in at boot. Steps to Reproduce: Boot any newer Linux Distribution with Kernel 3.13 or 3.14 and plug in my USB mouse before startup. If i boot normally i dont have USB at all after boot, but if i continiously move the mouse at login prompt until the system is completely up, the mouse and xhci is working flawless. The Mouse is a Wintech Z-2 Laser Mouseplugged in at a USB 2.0 Port of my Motherboard (Gigabyte Z87n-wifi) You can find all crash logs and some syslog entries in the attachement. From your log: Jul 23 19:09:03 Dicke-Berta kernel: [ 43.106507] WARNING: CPU: 1 PID: 208 at /build/buildd/linux-3.13.0/drive rs/usb/host/xhci-ring. c:613 xhci_find_new_dequeue_state+0x1c7/0x3b0() Looks very much like the same issue we had with finding new deqeue pointer erlier: If you can, you could test this patch on top of a 3-16-rc kernel: http://marc.info/?l=linux-usbm=140665101112261w=2 -Mathias -- 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] devio: fix issue with log flooding
On Fri, 1 Aug 2014, Oliver Neukum wrote: usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085 Signed-off-by: Oliver Neukum oneu...@suse.de CC: sta...@vger.kernel.org --- drivers/usb/core/devio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 257876e..0b59731 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1509,7 +1509,7 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb u = (is_in ? URB_DIR_IN : URB_DIR_OUT); if (uurb-flags USBDEVFS_URB_ISO_ASAP) u |= URB_ISO_ASAP; - if (uurb-flags USBDEVFS_URB_SHORT_NOT_OK) + if (uurb-flags USBDEVFS_URB_SHORT_NOT_OK is_in) u |= URB_SHORT_NOT_OK; if (uurb-flags USBDEVFS_URB_NO_FSBR) u |= URB_NO_FSBR; Acked-by: Alan Stern st...@rowland.harvard.edu Do you want to put in a one-time warning, so that people will be aware of these mistakes and are motivated to fix them? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] devio: fix issue with log flooding
On Fri, 1 Aug 2014, Oliver Neukum wrote: On Fri, 2014-08-01 at 10:24 -0400, Alan Stern wrote: On Fri, 1 Aug 2014, Oliver Neukum wrote: usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK for output URBs. That causes usbcore to log messages without limit for a nonsensical disallowed combination. The fix is to silently drop the attribute in usbfs. The problem is reported to exist since 3.14 https://www.virtualbox.org/ticket/13085 Signed-off-by: Oliver Neukum oneu...@suse.de CC: sta...@vger.kernel.org --- drivers/usb/core/devio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 257876e..0b59731 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1509,7 +1509,7 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb u = (is_in ? URB_DIR_IN : URB_DIR_OUT); if (uurb-flags USBDEVFS_URB_ISO_ASAP) u |= URB_ISO_ASAP; - if (uurb-flags USBDEVFS_URB_SHORT_NOT_OK) + if (uurb-flags USBDEVFS_URB_SHORT_NOT_OK is_in) u |= URB_SHORT_NOT_OK; if (uurb-flags USBDEVFS_URB_NO_FSBR) u |= URB_NO_FSBR; Acked-by: Alan Stern st...@rowland.harvard.edu Do you want to put in a one-time warning, so that people will be aware of these mistakes and are motivated to fix them? We used to allow this silently. And the combination is not really harmful, only sort of redundant. Was that a genuine question or a request? It was a real question. You're right that this is a pretty unimportant kind of error. The question is whether anybody cares enough to want to fix it. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] uas: Limit qdepth to 32 when connected over usb-2
Some jmicron uas chipsets act up (they disconnect from the bus) when sending
more then 32 commands to them at once.
Rather then building an ever growing list with usb-id based quirks for
devices using this chipset, simply reduce the qdepth to 32 when connected
over usb-2. 32 should be plenty to keep things close to maximum
possible throughput on usb-2.
Cc: sta...@vger.kernel.org
Tested-and-reported-by: Laszlo T. tla...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/storage/uas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 511b229..3f42785 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1026,7 +1026,7 @@ static int uas_configure_endpoints(struct uas_dev_info
*devinfo)
usb_endpoint_num(eps[3]-desc));
if (udev-speed != USB_SPEED_SUPER) {
- devinfo-qdepth = 256;
+ devinfo-qdepth = 32;
devinfo-use_streams = 0;
} else {
devinfo-qdepth = usb_alloc_streams(devinfo-intf, eps + 1,
--
2.0.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
USB modem interface not detected sometimes
Hi, I have USB modem which has also support for micro SD card. With kernel version 3.15 and later, I am facing a issue with modem interface detection. When I connect it first time only storage interface is detected. I had to disconnect it and reconnect it again. This issue is not seen with kernel version 3.11. Following are dmesg logs with version 3.15 After USB modem attached first time [ 44.044105] usb 4-1: USB disconnect, device number 3 [ 52.764071] usb 1-1: new high-speed USB device number 4 using ehci-pci [ 52.898661] usb 1-1: New USB device found, idVendor=1c9e, idProduct=f000 [ 52.898667] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [ 52.898670] usb 1-1: Product: USB Modem [ 52.898672] usb 1-1: Manufacturer: USB Modem [ 52.898675] usb 1-1: SerialNumber: 1234567890ABCDEF [ 53.479638] usb-storage 1-1:1.0: USB Mass Storage device detected [ 53.479889] scsi4 : usb-storage 1-1:1.0 [ 53.480139] usbcore: registered new interface driver usb-storage [ 54.480352] scsi 4:0:0:0: CD-ROMUSBModem Disk 2.31 PQ: 0 ANSI: 2 [ 54.485187] sr1: scsi-1 drive [ 54.485575] sr 4:0:0:0: Attached scsi CD-ROM sr1 [ 54.486557] sr 4:0:0:0: Attached scsi generic sg2 type 5 After disconnecting and connecting it again. [ 119.964616] usb 1-1: USB disconnect, device number 4 [ 126.736117] usb 1-1: new high-speed USB device number 5 using ehci-pci [ 126.870805] usb 1-1: New USB device found, idVendor=1c9e, idProduct=f000 [ 126.870813] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [ 126.870818] usb 1-1: Product: USB Modem [ 126.870822] usb 1-1: Manufacturer: USB Modem [ 126.870826] usb 1-1: SerialNumber: 1234567890ABCDEF [ 126.872936] usb-storage 1-1:1.0: USB Mass Storage device detected [ 126.873225] scsi5 : usb-storage 1-1:1.0 [ 127.873602] scsi 5:0:0:0: CD-ROMUSBModem Disk 2.31 PQ: 0 ANSI: 2 [ 127.877304] sr1: scsi-1 drive [ 127.877740] sr 5:0:0:0: Attached scsi CD-ROM sr1 [ 127.878452] sr 5:0:0:0: Attached scsi generic sg2 type 5 [ 130.122519] usb 1-1: USB disconnect, device number 5 [ 130.488100] usb 1-1: new high-speed USB device number 6 using ehci-pci [ 130.622919] usb 1-1: New USB device found, idVendor=1c9e, idProduct=9605 [ 130.622926] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [ 130.622931] usb 1-1: Product: USB Modem [ 130.622935] usb 1-1: Manufacturer: USB Modem [ 130.622939] usb 1-1: SerialNumber: 1234567890ABCDEF [ 131.265801] usb-storage 1-1:1.4: USB Mass Storage device detected [ 131.265991] scsi6 : usb-storage 1-1:1.4 [ 131.363101] usbcore: registered new interface driver usbserial [ 131.363126] usbcore: registered new interface driver usbserial_generic [ 131.363143] usbserial: USB Serial support registered for generic [ 131.446570] usbcore: registered new interface driver option [ 131.446593] usbserial: USB Serial support registered for GSM modem (1-port) [ 131.446737] option 1-1:1.0: GSM modem (1-port) converter detected [ 131.451834] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0 [ 131.451933] option 1-1:1.1: GSM modem (1-port) converter detected [ 131.452394] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1 [ 131.452471] option 1-1:1.2: GSM modem (1-port) converter detected [ 131.452574] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2 [ 131.452636] option 1-1:1.3: GSM modem (1-port) converter detected [ 131.452733] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3 [ 132.265188] scsi 6:0:0:0: Direct-Access USBModem Disk 2.31 PQ: 0 ANSI: 2 [ 132.268559] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 132.271063] sd 6:0:0:0: [sdb] Attached SCSI removable disk [ 135.440547] option1 ttyUSB3: option_instat_callback: error -2 [ 152.486473] option1 ttyUSB3: option_instat_callback: error -2 lsusb -d 1c9e:9605 -v Bus 001 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1c9e OMEGA TECHNOLOGY idProduct 0x9605 bcdDevice0.00 iManufacturer 3 iProduct2 iSerial 4 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 131 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 1 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific
Re: USB modem interface not detected sometimes
On Fri, 2014-08-01 at 21:44 +0530, Rahul Bedarkar wrote: Hi, I have USB modem which has also support for micro SD card. With kernel version 3.15 and later, I am facing a issue with modem interface detection. When I connect it first time only storage interface is detected. I had to disconnect it and reconnect it again. This issue is not seen with kernel version 3.11. Following are dmesg logs with version 3.15 After USB modem attached first time The device is actually switched from fake CD mode to modem mode by usb_modeswitch, and it appears that usb_modeswitch is failing to do that here sometimes. You should probably debug the usb_modeswitch stuff a bit more first. usb_modeswitch provides a udev helper (/usr/lib/udev/usb_modeswitch) that calls the main usb_modeswitch binary whenever a known device is inserted. You might get some more info by turning on udev verbose logging, or by modifying /etc/usb_modeswitch.conf and setting EnableLogging=1. Dan [ 44.044105] usb 4-1: USB disconnect, device number 3 [ 52.764071] usb 1-1: new high-speed USB device number 4 using ehci-pci [ 52.898661] usb 1-1: New USB device found, idVendor=1c9e, idProduct=f000 [ 52.898667] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [ 52.898670] usb 1-1: Product: USB Modem [ 52.898672] usb 1-1: Manufacturer: USB Modem [ 52.898675] usb 1-1: SerialNumber: 1234567890ABCDEF [ 53.479638] usb-storage 1-1:1.0: USB Mass Storage device detected [ 53.479889] scsi4 : usb-storage 1-1:1.0 [ 53.480139] usbcore: registered new interface driver usb-storage [ 54.480352] scsi 4:0:0:0: CD-ROMUSBModem Disk 2.31 PQ: 0 ANSI: 2 [ 54.485187] sr1: scsi-1 drive [ 54.485575] sr 4:0:0:0: Attached scsi CD-ROM sr1 [ 54.486557] sr 4:0:0:0: Attached scsi generic sg2 type 5 After disconnecting and connecting it again. [ 119.964616] usb 1-1: USB disconnect, device number 4 [ 126.736117] usb 1-1: new high-speed USB device number 5 using ehci-pci [ 126.870805] usb 1-1: New USB device found, idVendor=1c9e, idProduct=f000 [ 126.870813] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [ 126.870818] usb 1-1: Product: USB Modem [ 126.870822] usb 1-1: Manufacturer: USB Modem [ 126.870826] usb 1-1: SerialNumber: 1234567890ABCDEF [ 126.872936] usb-storage 1-1:1.0: USB Mass Storage device detected [ 126.873225] scsi5 : usb-storage 1-1:1.0 [ 127.873602] scsi 5:0:0:0: CD-ROMUSBModem Disk 2.31 PQ: 0 ANSI: 2 [ 127.877304] sr1: scsi-1 drive [ 127.877740] sr 5:0:0:0: Attached scsi CD-ROM sr1 [ 127.878452] sr 5:0:0:0: Attached scsi generic sg2 type 5 [ 130.122519] usb 1-1: USB disconnect, device number 5 [ 130.488100] usb 1-1: new high-speed USB device number 6 using ehci-pci [ 130.622919] usb 1-1: New USB device found, idVendor=1c9e, idProduct=9605 [ 130.622926] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 [ 130.622931] usb 1-1: Product: USB Modem [ 130.622935] usb 1-1: Manufacturer: USB Modem [ 130.622939] usb 1-1: SerialNumber: 1234567890ABCDEF [ 131.265801] usb-storage 1-1:1.4: USB Mass Storage device detected [ 131.265991] scsi6 : usb-storage 1-1:1.4 [ 131.363101] usbcore: registered new interface driver usbserial [ 131.363126] usbcore: registered new interface driver usbserial_generic [ 131.363143] usbserial: USB Serial support registered for generic [ 131.446570] usbcore: registered new interface driver option [ 131.446593] usbserial: USB Serial support registered for GSM modem (1-port) [ 131.446737] option 1-1:1.0: GSM modem (1-port) converter detected [ 131.451834] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0 [ 131.451933] option 1-1:1.1: GSM modem (1-port) converter detected [ 131.452394] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1 [ 131.452471] option 1-1:1.2: GSM modem (1-port) converter detected [ 131.452574] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2 [ 131.452636] option 1-1:1.3: GSM modem (1-port) converter detected [ 131.452733] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3 [ 132.265188] scsi 6:0:0:0: Direct-Access USBModem Disk 2.31 PQ: 0 ANSI: 2 [ 132.268559] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 132.271063] sd 6:0:0:0: [sdb] Attached SCSI removable disk [ 135.440547] option1 ttyUSB3: option_instat_callback: error -2 [ 152.486473] option1 ttyUSB3: option_instat_callback: error -2 lsusb -d 1c9e:9605 -v Bus 001 Device 006: ID 1c9e:9605 OMEGA TECHNOLOGY Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1c9e OMEGA TECHNOLOGY idProduct 0x9605 bcdDevice
Re: [PATCH] serial/option: Add support for Option GTM671WFS
On Fri, 2014-08-01 at 14:00 +0200, Ricardo Ribalda Delgado wrote: After this patch: [5.389385] usbserial: USB Serial support registered for GSM modem (1-port) [5.390181] option 2-1.4:1.0: GSM modem (1-port) converter detected [5.390556] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB0 [5.390636] option 2-1.4:1.1: GSM modem (1-port) converter detected [5.390935] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB1 [5.391002] option 2-1.4:1.2: GSM modem (1-port) converter detected [5.391258] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB2 [5.391318] option 2-1.4:1.3: GSM modem (1-port) converter detected [5.391650] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB3 [5.391685] option 2-1.4:1.4: GSM modem (1-port) converter detected [5.391895] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB4 [5.391927] option 2-1.4:1.5: GSM modem (1-port) converter detected [5.392076] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB5 [5.392109] option 2-1.4:1.6: GSM modem (1-port) converter detected [5.392278] usb 2-1.4: GSM modem (1-port) converter now attached to ttyUSB6 root@qt5022:~# lsusb -d 0af0: -vvv Are you 100% sure these don't go into the 'hso' driver? 'option' is used for mostly older Option devices (like 5+ years old). I tried to find information about this module, and the closest I could come for 0af0:9200 was: http://trac.gateworks.com/wiki/3g which indicates they might be 'hso' instead. Can you give that a try? Dan Bus 002 Device 003: ID 0af0:9200 Option Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0af0 Option idProduct 0x9200 bcdDevice0.00 iManufacturer 3 Option N.V. iProduct2 Globetrotter HSUPA Modem iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 200 bNumInterfaces 8 bConfigurationValue 1 iConfiguration 1 Option Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol 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 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 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 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2
RE: [PATCHv2 02/13] usb: dwc2: Moves s3c_hsotg gadget data structure into dwc2_hsotg
From: dingu...@altera.com [mailto:dingu...@altera.com]
Sent: Wednesday, July 30, 2014 8:21 AM
Adds the gadget data structure and appropriate data structure pointers
to the common dwc2_hsotg data structure. This is needed so that the
dwc2_hsotg data structure can be used by the hcd and gadget drivers.
Signed-off-by: Dinh Nguyen dingu...@altera.com
---
drivers/usb/dwc2/core.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 3b4bd4c..ee34ee1 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -604,6 +604,12 @@ struct dwc2_hsotg {
struct timer_list wkp_timer;
enum dwc2_lx_state lx_state;
+ /* Gadget structures */
+ struct s3c_hsotg *s3c_hsotg;
+ struct usb_gadget gadget;
+ struct usb_gadget_driver *driver;
+ struct s3c_hsotg_ep *eps;
+
Hi Dinh,
After looking at this some more, I'm not really happy with including
a pointer to the s3c_hsotg struct inside the dwc2_hsotg struct. It
makes the peripheral mode kind of a second class citizen, and requires
a bunch of double pointer indirections in gadget.c
(hsotg-s3c_hsotg-foo). Plus, when building for peripheral-only mode,
there are a lot of unused fields in the dwc2_hsotg struct.
So how about something like the below instead? This moves all of the
s3c_hsotg struct fields into the dwc2_hsotg struct, and adds ifdefs
around the host-only and peripheral-only fields. Doing this should
make the diff to gadget.c even smaller, since it eliminates the double
indirections.
This patch is on top of your series. And I'm only showing the changes
to core.h.
--
Paul
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index ed8d81d..0113e22 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -155,67 +155,6 @@ struct s3c_hsotg_ep {
};
/**
- * struct s3c_hsotg - driver state.
- * @dev: The parent device supplied to the probe function
- * @driver: USB gadget driver
- * @phy: The otg phy transceiver structure for phy control.
- * @uphy: The otg phy transceiver structure for old USB phy control.
- * @plat: The platform specific configuration data. This can be removed once
- * all SoCs support usb transceiver.
- * @regs: The memory area mapped for accessing registers.
- * @irq: The IRQ number we are using
- * @supplies: Definition of USB power supplies
- * @phyif: PHY interface width
- * @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
- * @num_of_eps: Number of available EPs (excluding EP0)
- * @debug_root: root directrory for debugfs.
- * @debug_file: main status file for debugfs.
- * @debug_fifo: FIFO status file for debugfs.
- * @ep0_reply: Request used for ep0 reply.
- * @ep0_buff: Buffer for EP0 reply data, if needed.
- * @ctrl_buff: Buffer for EP0 control requests.
- * @ctrl_req: Request for EP0 control packets.
- * @setup: NAK management for EP0 SETUP
- * @last_rst: Time of last reset
- * @eps: The endpoints being supplied to the gadget framework
- */
-struct s3c_hsotg {
- struct device*dev;
- struct usb_gadget_driver *driver;
- struct phy *phy;
- struct usb_phy *uphy;
- struct s3c_hsotg_plat*plat;
-
- spinlock_t lock;
-
- void __iomem*regs;
- int irq;
- struct clk *clk;
-
- struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
-
- u32 phyif;
- int fifo_mem;
- unsigned intdedicated_fifos:1;
- unsigned char num_of_eps;
- u32 fifo_map;
-
- struct dentry *debug_root;
- struct dentry *debug_file;
- struct dentry *debug_fifo;
-
- struct usb_request *ep0_reply;
- struct usb_request *ctrl_req;
- u8 ep0_buff[8];
- u8 ctrl_buff[8];
-
- struct usb_gadget gadget;
- unsigned intsetup;
- unsigned long last_rst;
- struct s3c_hsotg_ep *eps;
-};
-
-/**
* struct s3c_hsotg_req - data transfer request
* @req: The USB gadget request
* @queue: The list of requests for the endpoint this is queued for.
@@ -495,15 +434,22 @@ struct dwc2_hw_params {
* struct dwc2_hsotg - Holds the state of the driver, including the
non-periodic
* and periodic schedules
*
+ * These are common for both host and peripheral modes:
+ *
* @dev:The struct device pointer
- * @regs: Pointer to controller regs
- * @core_params:Parameters that define how the core should be
configured
+ * @regs: Pointer to controller regs
* @hw_params: Parameters that were autodetected from the
* hardware registers
+ * @core_params:Parameters that define how the core should
RE: [PATCHv2 02/13] usb: dwc2: Moves s3c_hsotg gadget data structure into dwc2_hsotg
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Paul Zimmerman
Sent: Friday, August 01, 2014 11:49 AM
From: dingu...@altera.com [mailto:dingu...@altera.com]
Sent: Wednesday, July 30, 2014 8:21 AM
Adds the gadget data structure and appropriate data structure pointers
to the common dwc2_hsotg data structure. This is needed so that the
dwc2_hsotg data structure can be used by the hcd and gadget drivers.
Signed-off-by: Dinh Nguyen dingu...@altera.com
---
drivers/usb/dwc2/core.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 3b4bd4c..ee34ee1 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -604,6 +604,12 @@ struct dwc2_hsotg {
struct timer_list wkp_timer;
enum dwc2_lx_state lx_state;
+ /* Gadget structures */
+ struct s3c_hsotg *s3c_hsotg;
+ struct usb_gadget gadget;
+ struct usb_gadget_driver *driver;
+ struct s3c_hsotg_ep *eps;
+
Hi Dinh,
After looking at this some more, I'm not really happy with including
a pointer to the s3c_hsotg struct inside the dwc2_hsotg struct. It
makes the peripheral mode kind of a second class citizen, and requires
a bunch of double pointer indirections in gadget.c
(hsotg-s3c_hsotg-foo). Plus, when building for peripheral-only mode,
there are a lot of unused fields in the dwc2_hsotg struct.
So how about something like the below instead? This moves all of the
s3c_hsotg struct fields into the dwc2_hsotg struct, and adds ifdefs
around the host-only and peripheral-only fields. Doing this should
make the diff to gadget.c even smaller, since it eliminates the double
indirections.
This patch is on top of your series. And I'm only showing the changes
to core.h.
And here is a patch which actually compiles in all three modes. I am
including the full patch, including the changes to gadget.c, this time.
These changes should really be folded into your series, instead of
being tacked onto the end like this.
I have no way to test this, since I don't have non-PCI hardware that
works in peripheral mode. (After this series goes in, I plan to add
support for that on PCI.)
--
Paul
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index ed8d81d..4d551e9 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -155,67 +155,6 @@ struct s3c_hsotg_ep {
};
/**
- * struct s3c_hsotg - driver state.
- * @dev: The parent device supplied to the probe function
- * @driver: USB gadget driver
- * @phy: The otg phy transceiver structure for phy control.
- * @uphy: The otg phy transceiver structure for old USB phy control.
- * @plat: The platform specific configuration data. This can be removed once
- * all SoCs support usb transceiver.
- * @regs: The memory area mapped for accessing registers.
- * @irq: The IRQ number we are using
- * @supplies: Definition of USB power supplies
- * @phyif: PHY interface width
- * @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
- * @num_of_eps: Number of available EPs (excluding EP0)
- * @debug_root: root directrory for debugfs.
- * @debug_file: main status file for debugfs.
- * @debug_fifo: FIFO status file for debugfs.
- * @ep0_reply: Request used for ep0 reply.
- * @ep0_buff: Buffer for EP0 reply data, if needed.
- * @ctrl_buff: Buffer for EP0 control requests.
- * @ctrl_req: Request for EP0 control packets.
- * @setup: NAK management for EP0 SETUP
- * @last_rst: Time of last reset
- * @eps: The endpoints being supplied to the gadget framework
- */
-struct s3c_hsotg {
- struct device*dev;
- struct usb_gadget_driver *driver;
- struct phy *phy;
- struct usb_phy *uphy;
- struct s3c_hsotg_plat*plat;
-
- spinlock_t lock;
-
- void __iomem*regs;
- int irq;
- struct clk *clk;
-
- struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
-
- u32 phyif;
- int fifo_mem;
- unsigned intdedicated_fifos:1;
- unsigned char num_of_eps;
- u32 fifo_map;
-
- struct dentry *debug_root;
- struct dentry *debug_file;
- struct dentry *debug_fifo;
-
- struct usb_request *ep0_reply;
- struct usb_request *ctrl_req;
- u8 ep0_buff[8];
- u8 ctrl_buff[8];
-
- struct usb_gadget gadget;
- unsigned intsetup;
- unsigned long last_rst;
- struct s3c_hsotg_ep *eps;
-};
-
-/**
* struct s3c_hsotg_req - data transfer request
* @req: The USB gadget request
* @queue: The list of requests for the endpoint this is queued for.
@@ -229,6 +168,7 @@ struct s3c_hsotg_req {
RE: [PATCHv2 01/13] usb: dwc2: Update Kconfig to support dual-role
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of dingu...@altera.com Sent: Wednesday, July 30, 2014 8:21 AM Update DWC2 kconfig and makefile to support dual-role mode. The platform file will always get compiled for the case where the controller is directly connected to the CPU. So for loadable modules, only dwc2.ko is needed. Signed-off-by: Dinh Nguyen dingu...@altera.com --- v2: Remove reference to dwc2_gadget --- drivers/usb/dwc2/Kconfig | 59 + drivers/usb/dwc2/Makefile | 21 2 files changed, 44 insertions(+), 36 deletions(-) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index f93807b..3d69928 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -1,40 +1,29 @@ config USB_DWC2 - bool DesignWare USB2 DRD Core Support + tristate DesignWare USB2 DRD Core Support depends on USB help Say Y here if your system has a Dual Role Hi-Speed USB controller based on the DesignWare HSOTG IP Core. - For host mode, if you choose to build the driver as dynamically - linked modules, the core module will be called dwc2.ko, the PCI - bus interface module (if you have a PCI bus system) will be - called dwc2_pci.ko, and the platform interface module (for - controllers directly connected to the CPU) will be called - dwc2_platform.ko. For gadget mode, there will be a single - module called dwc2_gadget.ko. - - NOTE: The s3c-hsotg driver is now renamed to dwc2_gadget. The - host and gadget drivers are still currently separate drivers. - There are plans to merge the dwc2_gadget driver with the dwc2 - host driver in the near future to create a dual-role driver. + If you choose to build the driver as dynamically + linked modules, a single dwc2.ko(regardless of mode of operation) + will get built for both platform IPs and PCI. if USB_DWC2 +choice + bool DWC2 Mode Selection + default USB_DWC2_DUAL_ROLE if (USB USB_GADGET) + default USB_DWC2_HOST if (USB !USB_GADGET) + default USB_DWC2_PERIPHERAL if (!USB USB_GADGET) + config USB_DWC2_HOST - tristate Host only mode + bool Host only mode depends on USB help The Designware USB2.0 high-speed host controller - integrated into many SoCs. - -config USB_DWC2_PLATFORM - bool DWC2 Platform - depends on USB_DWC2_HOST - default USB_DWC2_HOST - help - The Designware USB2.0 platform interface module for - controllers directly connected to the CPU. This is only - used for host mode. + integrated into many SoCs. Select this option if you want the + driver to operate in Host-only mode. config USB_DWC2_PCI bool DWC2 PCI @@ -47,11 +36,29 @@ config USB_DWC2_PCI comment Gadget mode requires USB Gadget support to be enabled config USB_DWC2_PERIPHERAL - tristate Gadget only mode + bool Gadget only mode depends on USB_GADGET help The Designware USB2.0 high-speed gadget controller - integrated into many SoCs. + integrated into many SoCs. Select this option if you want the + driver to operate in Peripheral-only mode. + +config USB_DWC2_DUAL_ROLE + bool Dual Role mode + depends on ((USB=y || USB=USB_DWC2) (USB_GADGET=y)) Hi Dinh, I just noticed that for dual-role mode, you are not allowing USB_GADGET to be modular. Is there a reason for that? If so, please mention it in the commit message. It should also be explained in the help text. Or maybe add another comment line saying Dual-role mode requires USB Gadget = y or something like that. -- Paul -- 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: [PATCHv2 02/13] usb: dwc2: Moves s3c_hsotg gadget data structure into dwc2_hsotg
On Fri, 2014-08-01 at 20:31 +, Paul Zimmerman wrote:
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Paul Zimmerman
Sent: Friday, August 01, 2014 11:49 AM
From: dingu...@altera.com [mailto:dingu...@altera.com]
Sent: Wednesday, July 30, 2014 8:21 AM
Adds the gadget data structure and appropriate data structure pointers
to the common dwc2_hsotg data structure. This is needed so that the
dwc2_hsotg data structure can be used by the hcd and gadget drivers.
Signed-off-by: Dinh Nguyen dingu...@altera.com
---
drivers/usb/dwc2/core.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 3b4bd4c..ee34ee1 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -604,6 +604,12 @@ struct dwc2_hsotg {
struct timer_list wkp_timer;
enum dwc2_lx_state lx_state;
+ /* Gadget structures */
+ struct s3c_hsotg *s3c_hsotg;
+ struct usb_gadget gadget;
+ struct usb_gadget_driver *driver;
+ struct s3c_hsotg_ep *eps;
+
Hi Dinh,
After looking at this some more, I'm not really happy with including
a pointer to the s3c_hsotg struct inside the dwc2_hsotg struct. It
makes the peripheral mode kind of a second class citizen, and requires
a bunch of double pointer indirections in gadget.c
(hsotg-s3c_hsotg-foo). Plus, when building for peripheral-only mode,
there are a lot of unused fields in the dwc2_hsotg struct.
So how about something like the below instead? This moves all of the
s3c_hsotg struct fields into the dwc2_hsotg struct, and adds ifdefs
around the host-only and peripheral-only fields. Doing this should
make the diff to gadget.c even smaller, since it eliminates the double
indirections.
This patch is on top of your series. And I'm only showing the changes
to core.h.
And here is a patch which actually compiles in all three modes. I am
including the full patch, including the changes to gadget.c, this time.
Thanks Paul. I agree that having the double pointers looked messy. I
like this suggestion. Can I add your Signed-by when I fold your patch
into mine?
Thanks,
Dinh
These changes should really be folded into your series, instead of
being tacked onto the end like this.
I have no way to test this, since I don't have non-PCI hardware that
works in peripheral mode. (After this series goes in, I plan to add
support for that on PCI.)
--
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: [PATCHv2 01/13] usb: dwc2: Update Kconfig to support dual-role
On Fri, 2014-08-01 at 20:42 +, Paul Zimmerman wrote: From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of dingu...@altera.com Sent: Wednesday, July 30, 2014 8:21 AM Update DWC2 kconfig and makefile to support dual-role mode. The platform file will always get compiled for the case where the controller is directly connected to the CPU. So for loadable modules, only dwc2.ko is needed. Signed-off-by: Dinh Nguyen dingu...@altera.com --- v2: Remove reference to dwc2_gadget --- drivers/usb/dwc2/Kconfig | 59 + drivers/usb/dwc2/Makefile | 21 2 files changed, 44 insertions(+), 36 deletions(-) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index f93807b..3d69928 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -1,40 +1,29 @@ config USB_DWC2 - bool DesignWare USB2 DRD Core Support + tristate DesignWare USB2 DRD Core Support depends on USB help Say Y here if your system has a Dual Role Hi-Speed USB controller based on the DesignWare HSOTG IP Core. - For host mode, if you choose to build the driver as dynamically - linked modules, the core module will be called dwc2.ko, the PCI - bus interface module (if you have a PCI bus system) will be - called dwc2_pci.ko, and the platform interface module (for - controllers directly connected to the CPU) will be called - dwc2_platform.ko. For gadget mode, there will be a single - module called dwc2_gadget.ko. - - NOTE: The s3c-hsotg driver is now renamed to dwc2_gadget. The - host and gadget drivers are still currently separate drivers. - There are plans to merge the dwc2_gadget driver with the dwc2 - host driver in the near future to create a dual-role driver. + If you choose to build the driver as dynamically + linked modules, a single dwc2.ko(regardless of mode of operation) + will get built for both platform IPs and PCI. if USB_DWC2 +choice + bool DWC2 Mode Selection + default USB_DWC2_DUAL_ROLE if (USB USB_GADGET) + default USB_DWC2_HOST if (USB !USB_GADGET) + default USB_DWC2_PERIPHERAL if (!USB USB_GADGET) + config USB_DWC2_HOST - tristate Host only mode + bool Host only mode depends on USB help The Designware USB2.0 high-speed host controller - integrated into many SoCs. - -config USB_DWC2_PLATFORM - bool DWC2 Platform - depends on USB_DWC2_HOST - default USB_DWC2_HOST - help - The Designware USB2.0 platform interface module for - controllers directly connected to the CPU. This is only - used for host mode. + integrated into many SoCs. Select this option if you want the + driver to operate in Host-only mode. config USB_DWC2_PCI bool DWC2 PCI @@ -47,11 +36,29 @@ config USB_DWC2_PCI comment Gadget mode requires USB Gadget support to be enabled config USB_DWC2_PERIPHERAL - tristate Gadget only mode + bool Gadget only mode depends on USB_GADGET help The Designware USB2.0 high-speed gadget controller - integrated into many SoCs. + integrated into many SoCs. Select this option if you want the + driver to operate in Peripheral-only mode. + +config USB_DWC2_DUAL_ROLE + bool Dual Role mode + depends on ((USB=y || USB=USB_DWC2) (USB_GADGET=y)) Hi Dinh, I just noticed that for dual-role mode, you are not allowing USB_GADGET to be modular. Is there a reason for that? If so, please mention it in the commit message. It should also be explained in the help text. Or maybe add another comment line saying Dual-role mode requires USB Gadget = y or something like that. I think it was an oversight on my part and there's not reason why USB_GADGET can't be modular. Dinh -- 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: [PATCHv2 02/13] usb: dwc2: Moves s3c_hsotg gadget data structure into dwc2_hsotg
From: Dinh Nguyen [mailto:dingu...@altera.com]
Sent: Friday, August 01, 2014 2:39 PM
On Fri, 2014-08-01 at 20:31 +, Paul Zimmerman wrote:
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Paul
Zimmerman
Sent: Friday, August 01, 2014 11:49 AM
From: dingu...@altera.com [mailto:dingu...@altera.com]
Sent: Wednesday, July 30, 2014 8:21 AM
Adds the gadget data structure and appropriate data structure pointers
to the common dwc2_hsotg data structure. This is needed so that the
dwc2_hsotg data structure can be used by the hcd and gadget drivers.
Signed-off-by: Dinh Nguyen dingu...@altera.com
---
drivers/usb/dwc2/core.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 3b4bd4c..ee34ee1 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -604,6 +604,12 @@ struct dwc2_hsotg {
struct timer_list wkp_timer;
enum dwc2_lx_state lx_state;
+ /* Gadget structures */
+ struct s3c_hsotg *s3c_hsotg;
+ struct usb_gadget gadget;
+ struct usb_gadget_driver *driver;
+ struct s3c_hsotg_ep *eps;
+
Hi Dinh,
After looking at this some more, I'm not really happy with including
a pointer to the s3c_hsotg struct inside the dwc2_hsotg struct. It
makes the peripheral mode kind of a second class citizen, and requires
a bunch of double pointer indirections in gadget.c
(hsotg-s3c_hsotg-foo). Plus, when building for peripheral-only mode,
there are a lot of unused fields in the dwc2_hsotg struct.
So how about something like the below instead? This moves all of the
s3c_hsotg struct fields into the dwc2_hsotg struct, and adds ifdefs
around the host-only and peripheral-only fields. Doing this should
make the diff to gadget.c even smaller, since it eliminates the double
indirections.
This patch is on top of your series. And I'm only showing the changes
to core.h.
And here is a patch which actually compiles in all three modes. I am
including the full patch, including the changes to gadget.c, this time.
Thanks Paul. I agree that having the double pointers looked messy. I
like this suggestion. Can I add your Signed-by when I fold your patch
into mine?
Sure, yes.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH] usb: host: ehci-msm: Make of_device_id array const
On Wed, Jul 30, 2014 at 06:14:45PM +0530, Kiran Padwal wrote:
Make of_device_id array const, because all OF functions handle it as const.
Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
---
drivers/usb/host/ehci-msm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 982c09b..934b39d 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -190,7 +190,7 @@ static const struct dev_pm_ops ehci_msm_dev_pm_ops = {
.resume = ehci_msm_pm_resume,
};
-static struct of_device_id msm_ehci_dt_match[] = {
+static const struct of_device_id msm_ehci_dt_match[] = {
{ .compatible = qcom,ehci-host, },
{}
};
--
1.7.9.5
This patch is already in my tree, right? Why submit it again?
confused,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] Misc. xhci + uas fixes / cleanups
On Fri, Jul 25, 2014 at 10:01:17PM +0200, Hans de Goede wrote: Hi All, I've just spend 3 days trying to get bulk streams / uas to work on an Etron controller, and failed. So the first patch in this set is the most important one (and has a CC stable, and should be added to 3.16 if still possible). It simply outright disables streams on the Etron model in question, for more details see the patch. The rest is mostly cleanups and a few small fixes as a result of all the digging through the xhci / uas code I did while trying to get the Etron controller to work. I really would like to have gotten an ack from Mathias, as my tree is going to close in a few minutes. I'll pick through these and see how they look... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD
On Fri, Jul 25, 2014 at 10:01:20PM +0200, Hans de Goede wrote: Lately (with the use of uas / bulk-streams) we have been seeing several cases where this error triggers (which should never happen). Add some extra logging to make debugging these errors easier. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/usb/host/xhci-mem.c | 4 +++- drivers/usb/host/xhci-ring.c | 22 ++ drivers/usb/host/xhci.h | 6 +++--- 3 files changed, 24 insertions(+), 8 deletions(-) This patch just fails to apply: checking file drivers/usb/host/xhci-mem.c checking file drivers/usb/host/xhci-ring.c Hunk #4 FAILED at 2519. 1 out of 4 hunks FAILED checking file drivers/usb/host/xhci.h Hunk #1 succeeded at 1804 (offset -2 lines). So while I wanted to apply it, I can't :( greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] Misc. xhci + uas fixes / cleanups
On Fri, Jul 25, 2014 at 10:01:17PM +0200, Hans de Goede wrote: Hi All, I've just spend 3 days trying to get bulk streams / uas to work on an Etron controller, and failed. So the first patch in this set is the most important one (and has a CC stable, and should be added to 3.16 if still possible). It simply outright disables streams on the Etron model in question, for more details see the patch. The rest is mostly cleanups and a few small fixes as a result of all the digging through the xhci / uas code I did while trying to get the Etron controller to work. Ok, I've applied a few of these, please feel free to refresh the remaining and resend. Hopefully Mathias will be able to review them as well... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3/AM3517 EHCI USB Issue
On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is generally a challenge. How would one determine if off-while-idle is enabled?
Re: OMAP3/AM3517 EHCI USB Issue
On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling mwell...@emacinc.com wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is
Re: [PATCH v2 3/7] usb: phy: mxs: Add VF610 USB PHY support
On Mon, Jul 28, 2014 at 04:57:29PM +0200, Stefan Agner wrote:
This adds support for the USB PHY in Vybrid VF610. We assume that
the disconnection without VBUS is also needed for Vybrid.
Tests showed, without MXS_PHY_NEED_IP_FIX, enumeration of devices
behind a USB Hub fails with errors:
[ 215.163507] usb usb1-port1: cannot reset (err = -32)
[ 215.170498] usb usb1-port1: cannot reset (err = -32)
[ 215.185120] usb usb1-port1: cannot reset (err = -32)
[ 215.191345] usb usb1-port1: cannot reset (err = -32)
[ 215.202487] usb usb1-port1: cannot reset (err = -32)
[ 215.207718] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[ 215.219317] usb usb1-port1: unable to enumerate USB device
Hence we also enable the MXS_PHY_NEED_IP_FIX flag.
Signed-off-by: Stefan Agner ste...@agner.ch
---
Documentation/devicetree/bindings/usb/mxs-phy.txt | 1 +
drivers/usb/phy/phy-mxs-usb.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt
b/Documentation/devicetree/bindings/usb/mxs-phy.txt
index cef181a..fe3eed8 100644
--- a/Documentation/devicetree/bindings/usb/mxs-phy.txt
+++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt
@@ -5,6 +5,7 @@ Required properties:
* fsl,imx23-usbphy for imx23 and imx28
* fsl,imx6q-usbphy for imx6dq and imx6dl
* fsl,imx6sl-usbphy for imx6sl
+ * fsl,vf610-usbphy for Vybrid vf610
fsl,imx23-usbphy is still a fallback for other strings
- reg: Should contain registers location and length
- interrupts: Should contain phy interrupt
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index c42bdf0..8c2f23b 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -125,10 +125,16 @@ static const struct mxs_phy_data imx6sl_phy_data = {
MXS_PHY_NEED_IP_FIX,
};
+static const struct mxs_phy_data vf610_phy_data = {
+ .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
+ MXS_PHY_NEED_IP_FIX,
+};
+
static const struct of_device_id mxs_phy_dt_ids[] = {
{ .compatible = fsl,imx6sl-usbphy, .data = imx6sl_phy_data, },
{ .compatible = fsl,imx6q-usbphy, .data = imx6q_phy_data, },
{ .compatible = fsl,imx23-usbphy, .data = imx23_phy_data, },
+ { .compatible = fsl,vf610-usbphy, .data = vf610_phy_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
--
2.0.2
Acked-by: Peter Chen peter.c...@freescale.com
--
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 v2 5/7] chipidea: usbmisc_imx: Add USB support for VF610 SoCs
On Mon, Jul 28, 2014 at 04:57:31PM +0200, Stefan Agner wrote:
This adds Vybrid VF610 SoC support. The IP is very similar to i.MX6,
however, the non-core registers are spread in two different register
areas. Hence we support multiple instances of the USB misc driver
and add the driver instance to the imx_usbmisc_data structure.
Signed-off-by: Stefan Agner ste...@agner.ch
---
In the end, I decieded against the advice of Peter to integrate the
multi-instance functionality in a second driver. To support multiple
instances, I needed to extend the imx_usbmisc_data to point to the
instance. Since this is part of the ci_hdrc_imx driver, I feel it's
cleaner to extend the current driver rather to add a second driver
and implement two different handlings in the ci_hdrc_imx driver.
Also, the current approach has a slight advantage for current users
too: EPROBE_DEFER is returned earlier, when initializing the
imx_usbmisc_data structure rather than later on, when accessing
the driver by using imx_usbmisc_init/imx_usbmisc_init_post.
As a free bonus, this driver would now also support the mixed case:
multiple non-core registers in different areas which each support
multiple USB controllers...
Tell me if this is ok for you too.
.../devicetree/bindings/usb/usbmisc-imx.txt| 1 +
drivers/usb/chipidea/ci_hdrc_imx.c | 8
drivers/usb/chipidea/ci_hdrc_imx.h | 1 +
drivers/usb/chipidea/usbmisc_imx.c | 52
+-
4 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
index 97ce94e..c101a4b 100644
--- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
+++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
@@ -4,6 +4,7 @@ Required properties:
- #index-cells: Cells used to descibe usb controller index. Should be 1
- compatible: Should be one of below:
fsl,imx6q-usbmisc for imx6q
+ fsl,vf610-usbmisc for Vybrid vf610
- reg: Should contain registers location and length
Examples:
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 2e58f8d..9af12b4 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -54,6 +54,7 @@ struct ci_hdrc_imx_data {
static struct imx_usbmisc_data *usbmisc_get_init_data(struct device *dev)
{
+ struct platform_device *misc_pdev;
struct device_node *np = dev-of_node;
struct of_phandle_args args;
struct imx_usbmisc_data *data;
@@ -79,8 +80,15 @@ static struct imx_usbmisc_data
*usbmisc_get_init_data(struct device *dev)
}
data-index = args.args[0];
+
+ misc_pdev = of_find_device_by_node(args.np);
of_node_put(args.np);
+ if (!misc_pdev)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ data-dev = misc_pdev-dev;
+
if (of_find_property(np, disable-over-current, NULL))
data-disable_oc = 1;
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.h
b/drivers/usb/chipidea/ci_hdrc_imx.h
index 996ec93..4ed828f 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.h
+++ b/drivers/usb/chipidea/ci_hdrc_imx.h
@@ -13,6 +13,7 @@
#define __DRIVER_USB_CHIPIDEA_CI_HDRC_IMX_H
struct imx_usbmisc_data {
+ struct device *dev;
int index;
unsigned int disable_oc:1; /* over current detect disabled */
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 85293b8..926c997 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -57,6 +57,8 @@
#define MX6_BM_OVER_CUR_DIS BIT(7)
+#define VF610_OVER_CUR_DIS BIT(7)
+
struct usbmisc_ops {
/* It's called once when probe a usb device */
int (*init)(struct imx_usbmisc_data *data);
@@ -71,10 +73,9 @@ struct imx_usbmisc {
const struct usbmisc_ops *ops;
};
-static struct imx_usbmisc *usbmisc;
-
static int usbmisc_imx25_init(struct imx_usbmisc_data *data)
{
+ struct imx_usbmisc *usbmisc = dev_get_drvdata(data-dev);
unsigned long flags;
u32 val = 0;
@@ -108,6 +109,7 @@ static int usbmisc_imx25_init(struct imx_usbmisc_data
*data)
static int usbmisc_imx25_post(struct imx_usbmisc_data *data)
{
+ struct imx_usbmisc *usbmisc = dev_get_drvdata(data-dev);
void __iomem *reg;
unsigned long flags;
u32 val;
@@ -130,6 +132,7 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data
*data)
static int usbmisc_imx27_init(struct imx_usbmisc_data *data)
{
+ struct imx_usbmisc *usbmisc = dev_get_drvdata(data-dev);
unsigned long flags;
u32 val;
@@ -160,6 +163,7 @@ static int usbmisc_imx27_init(struct imx_usbmisc_data
*data)
static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
{
+ struct imx_usbmisc
Kernel Debugging Support
Hey Sharp, After reading around seems people want support for usb debugging in kgdb or other usb based solutions. If you and the other developers are able to help me out a bit as I am new I can definitively write this area of kgdb support. Regards Nick P.S. If you want Sharp I can change the commit message on my other commit you didn't like if me or you talk to Greg in order to remove in from mainline, if no that's OK too. -- 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
