Re: [PATCH 86/86] usb/dwc3: move ids to pci_ids.h
On Mon, Mar 30, 2015 at 08:58:10AM +0200, Greg Kroah-Hartman wrote: > On Mon, Mar 30, 2015 at 08:50:34AM +0200, Michael S. Tsirkin wrote: > > On Sun, Mar 29, 2015 at 10:42:00PM +0200, Greg Kroah-Hartman wrote: > > > On Sun, Mar 29, 2015 at 03:43:40PM +0200, Michael S. Tsirkin wrote: > > > > Comment says IDs should move to pci_ids.h, let's do it. > > > > > > No, please remove the comment, it's not needed in pci_ids.h at all. > > > > vendor ID does belong in pci_ids.h though, so says > > Documentation/PCI/pci.txt > > Read the top of pci_ids.h please. Thanks for pointing this out, looks like Documentation/PCI/pci.txt should be improved. -- 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/dwc3: comment update
The top of include/linux/pci_ids.h says: Do not add new entries to this file unless the definitions are shared between multiple drivers. Drop comment in usb/dwc3 which conflicts with this. Signed-off-by: Michael S. Tsirkin --- drivers/usb/dwc3/dwc3-pci.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 8d95056..759855b 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -24,7 +24,6 @@ #include "platform_data.h" -/* FIXME define these in */ #define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd #define PCI_DEVICE_ID_INTEL_BYT0x0f37 -- MST -- 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] Documentation: usb: serial: fixed how to provide vendor and product id
On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: > From: "H. Nikolaus Schaller" > > While trying to test the Pyra GSM/GPS/3G module I had reconfigured > the USB interface by mistake and therefore needed to run a different > USB driver than CSC-ACM. It turned out that I need the "usbserial" driver. CDC-ACM > This file is an official description how to use it: > Documentation/usb/usb-serial.txt > > But it is outdated. The parameters vendor= and product= are no longer > available since ca. 3.12 which means that documentation is lagging behind > quite some time. This is simply not true. The vendor and module parameters are still there for usbserial (i.e. the generic driver). Would you mind updating this patch to document the sysfs-method as an alternative instead? Using sysfs is preferred as that functionality can be used with any usb-serial driver and the drivers can also be compiled in. > Here was the solution: > > https://bbs.archlinux.org/viewtopic.php?id=175499 > > insmod usbserial vendor=0x product=0x > > becomes (first is vendor, second is product) > > modprobe usbserial > echo >/sys/bus/usb-serial/drivers/generic/new_id > > This patch changes the documentation file as needed. > > Signed-off-by: H. Nikolaus Schaller > Signed-off-by: Marek Belisko > --- > Documentation/usb/usb-serial.txt | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/Documentation/usb/usb-serial.txt > b/Documentation/usb/usb-serial.txt > index 947fa62..9f184d8 100644 > --- a/Documentation/usb/usb-serial.txt > +++ b/Documentation/usb/usb-serial.txt > @@ -466,11 +466,13 @@ Generic Serial driver >is required of your device is that it has at least one bulk in endpoint, >or one bulk out endpoint. > > - To enable the generic driver to recognize your device, build the driver > - as a module and load it by the following invocation: > - insmod usbserial vendor=0x product=0x > - where the is replaced with the hex representation of your device's > - vendor id and product id. > + To enable the generic driver to recognize your device, configure > + USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by the You don't need to build the driver as a module when using the sysfs method. > + following invocation: > + modprobe usbserial > + echo >/sys/bus/usb-serial/drivers/generic/new_id > + where the the first is replaced with the hex representation of your > + device's vendor id and the second by the product id. > >This driver has been successfully used to connect to the NetChip USB >development board, providing a way to develop USB firmware without Thanks, Johan -- 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] Documentation: usb: serial: fixed how to provide vendor and product id
Hi Johan, Am 30.03.2015 um 09:45 schrieb Johan Hovold : > On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: >> From: "H. Nikolaus Schaller" >> >> While trying to test the Pyra GSM/GPS/3G module I had reconfigured >> the USB interface by mistake and therefore needed to run a different >> USB driver than CSC-ACM. It turned out that I need the "usbserial" driver. > > CDC-ACM oh, thanks. There is always at least one more typo in any document… > >> This file is an official description how to use it: >> Documentation/usb/usb-serial.txt >> >> But it is outdated. The parameters vendor= and product= are no longer >> available since ca. 3.12 which means that documentation is lagging behind >> quite some time. > > This is simply not true. The vendor and module parameters are still > there for usbserial (i.e. the generic driver). > > Would you mind updating this patch to document the sysfs-method as an > alternative instead? Using sysfs is preferred as that functionality can > be used with any usb-serial driver and the drivers can also be compiled > in. Hm. For me it did not work as described and therefore I searched for and found the solution cited below, which appears to confirm that it does not work any more. Only with these hints to use the /sys approach I could make it working immediately. Therefore I assumed that the documentation is outdated. But it might also be a hidden bug with the parameter passing. I had tested on 4.0-rc3. I can try a little more but it might be waste of time to find out why the old does not work, if there is a preferred method now. > >> Here was the solution: >> >> https://bbs.archlinux.org/viewtopic.php?id=175499 >> >> insmod usbserial vendor=0x product=0x >> >> becomes (first is vendor, second is product) >> >> modprobe usbserial >> echo >/sys/bus/usb-serial/drivers/generic/new_id >> >> This patch changes the documentation file as needed. >> >> Signed-off-by: H. Nikolaus Schaller >> Signed-off-by: Marek Belisko >> --- >> Documentation/usb/usb-serial.txt | 12 +++- >> 1 file changed, 7 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/usb/usb-serial.txt >> b/Documentation/usb/usb-serial.txt >> index 947fa62..9f184d8 100644 >> --- a/Documentation/usb/usb-serial.txt >> +++ b/Documentation/usb/usb-serial.txt >> @@ -466,11 +466,13 @@ Generic Serial driver >> is required of your device is that it has at least one bulk in endpoint, >> or one bulk out endpoint. >> >> - To enable the generic driver to recognize your device, build the driver >> - as a module and load it by the following invocation: >> -insmod usbserial vendor=0x product=0x >> - where the is replaced with the hex representation of your device's >> - vendor id and product id. >> + To enable the generic driver to recognize your device, configure >> + USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by the > > You don't need to build the driver as a module when using the sysfs > method. Ok, that is right and my formulation is too narrow on that. So we just s/ as a module//. > >> + following invocation: >> +modprobe usbserial >> +echo >/sys/bus/usb-serial/drivers/generic/new_id >> + where the the first is replaced with the hex representation of your >> + device's vendor id and the second by the product id. >> >> This driver has been successfully used to connect to the NetChip USB >> development board, providing a way to develop USB firmware without > > Thanks, > Johan Thanks as well, Nikolaus -- 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: [Gta04-owner] [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Am 30.03.2015 um 11:32 schrieb Dr. H. Nikolaus Schaller : > Hi Johan, > > Am 30.03.2015 um 09:45 schrieb Johan Hovold : > >> On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: >>> From: "H. Nikolaus Schaller" >>> >>> While trying to test the Pyra GSM/GPS/3G module I had reconfigured >>> the USB interface by mistake and therefore needed to run a different >>> USB driver than CSC-ACM. It turned out that I need the "usbserial" driver. >> >> CDC-ACM > > oh, thanks. There is always at least one more typo in any document… > >> >>> This file is an official description how to use it: >>> Documentation/usb/usb-serial.txt >>> >>> But it is outdated. The parameters vendor= and product= are no longer >>> available since ca. 3.12 which means that documentation is lagging behind >>> quite some time. >> >> This is simply not true. The vendor and module parameters are still >> there for usbserial (i.e. the generic driver). >> >> Would you mind updating this patch to document the sysfs-method as an >> alternative instead? Using sysfs is preferred as that functionality can >> be used with any usb-serial driver and the drivers can also be compiled >> in. > > Hm. For me it did not work as described and therefore I searched for > and found the solution cited below, which appears to confirm that it does > not work any more. Only with these hints to use the /sys approach I > could make it working immediately. > > Therefore I assumed that the documentation is outdated. > > But it might also be a hidden bug with the parameter passing. > I had tested on 4.0-rc3. > > I can try a little more but it might be waste of time to find out why the old > does not work, if there is a preferred method now. > >> >>> Here was the solution: >>> >>> https://bbs.archlinux.org/viewtopic.php?id=175499 >>> >>> insmod usbserial vendor=0x product=0x >>> >>> becomes (first is vendor, second is product) >>> >>> modprobe usbserial >>> echo >/sys/bus/usb-serial/drivers/generic/new_id >>> >>> This patch changes the documentation file as needed. >>> >>> Signed-off-by: H. Nikolaus Schaller >>> Signed-off-by: Marek Belisko >>> --- >>> Documentation/usb/usb-serial.txt | 12 +++- >>> 1 file changed, 7 insertions(+), 5 deletions(-) >>> >>> diff --git a/Documentation/usb/usb-serial.txt >>> b/Documentation/usb/usb-serial.txt >>> index 947fa62..9f184d8 100644 >>> --- a/Documentation/usb/usb-serial.txt >>> +++ b/Documentation/usb/usb-serial.txt >>> @@ -466,11 +466,13 @@ Generic Serial driver >>> is required of your device is that it has at least one bulk in endpoint, >>> or one bulk out endpoint. >>> >>> - To enable the generic driver to recognize your device, build the driver >>> - as a module and load it by the following invocation: >>> - insmod usbserial vendor=0x product=0x >>> - where the is replaced with the hex representation of your device's >>> - vendor id and product id. >>> + To enable the generic driver to recognize your device, configure >>> + USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by >>> the >> >> You don't need to build the driver as a module when using the sysfs >> method. > > Ok, that is right and my formulation is too narrow on that. Well, I should add that not my formulation was too narrow but already the original. > > So we just s/ as a module//. > >> >>> + following invocation: >>> + modprobe usbserial >>> + echo >/sys/bus/usb-serial/drivers/generic/new_id >>> + where the the first is replaced with the hex representation of your >>> + device's vendor id and the second by the product id. >>> >>> This driver has been successfully used to connect to the NetChip USB >>> development board, providing a way to develop USB firmware without >> >> Thanks, >> Johan > > Thanks as well, > Nikolaus > > > ___ > Gta04-owner mailing list > gta04-ow...@goldelico.com > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner -- 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: Errata for Freescale root-hub TT?
On Fri, Mar 27, 2015 at 09:47:06AM -0400, Alan Stern wrote: > On Fri, 27 Mar 2015, Peter Chen wrote: > > > Hi Alan, > > > > I tried to your case today, but it seems full speed hub with siTD > > has some problems with latest greg's next tree, I use UAC2 with > > configfs for audio device, high speed hub works ok. > > > > The commands: > > aplay -D hw:1,0 audio32k16M.wav > > arecord -Dhw:1 -r 32000 -c 1 -f S16_LE -d 20 file_32.wav > > > > The corresponding failure logs: > > [ 81.542848] ci_hdrc ci_hdrc.0: iso sched full bd7d5100 > > [ 81.542884] usb 1-1.2: cannot submit urb 0, error -28: not enough > > bandwidth > > [ 355.078938] ci_hdrc ci_hdrc.0: iso sched full bd49cc00 > > [ 355.078969] usb 1-1.2: cannot submit urb 0, error -28: not enough > > bandwidth > > That's strange. Can you please post the /sys/kernel/debug/usb/devices > file (with the UAC2 gadget plugged in), and also collect a usbmon trace > of the test? > It should be UAC2 gadget or chipidea driver problem, it is ok if I plug in USB audio card, but most of current audio cards support 44.1k+ frame rate, it can't handle the 3rd endpoint (176-184 bytes / endpoint), I don't know how to let it only read/writes 64 bytes, anyway, I will fix the UAC2 gadget problem first. Device file for UAC2: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=12 MxCh= 0 D: Ver= 0.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=15a2 ProdID=0054 Rev= 4.00 S: Manufacturer=Freescale S: Product=FSL i.mx6q sabreSD Board S: SerialNumber=123456ABCDEF C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr= 6mA A: FirstIf#= 0 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=01(O) Atr=05(Isoc) MxPS=1023 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=81(I) Atr=05(Isoc) MxPS=1023 Ivl=1ms usbmon trace: I did not trace it since I did not find any data traffic on the bus through USB Bus Analyzer. -- 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] Documentation: usb: serial: fixed how to provide vendor and product id
On Mon, Mar 30, 2015 at 11:32:39AM +0200, Dr. H. Nikolaus Schaller wrote: > Hi Johan, > > Am 30.03.2015 um 09:45 schrieb Johan Hovold : > > > On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: > >> From: "H. Nikolaus Schaller" > >> > >> While trying to test the Pyra GSM/GPS/3G module I had reconfigured > >> the USB interface by mistake and therefore needed to run a different > >> USB driver than CSC-ACM. It turned out that I need the "usbserial" driver. > > > > CDC-ACM > > oh, thanks. There is always at least one more typo in any document… > > > > >> This file is an official description how to use it: > >> Documentation/usb/usb-serial.txt > >> > >> But it is outdated. The parameters vendor= and product= are no longer > >> available since ca. 3.12 which means that documentation is lagging behind > >> quite some time. > > > > This is simply not true. The vendor and module parameters are still > > there for usbserial (i.e. the generic driver). > > > > Would you mind updating this patch to document the sysfs-method as an > > alternative instead? Using sysfs is preferred as that functionality can > > be used with any usb-serial driver and the drivers can also be compiled > > in. > > Hm. For me it did not work as described and therefore I searched for > and found the solution cited below, which appears to confirm that it does > not work any more. Only with these hints to use the /sys approach I > could make it working immediately. > > Therefore I assumed that the documentation is outdated. > > But it might also be a hidden bug with the parameter passing. > I had tested on 4.0-rc3. > > I can try a little more but it might be waste of time to find out why the old > does not work, if there is a preferred method now. Please do try to figure out if it doesn't work as we have not deprecated this functionality yet. It should still work. Johan -- 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: [Gta04-owner] [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
On Mon, Mar 30, 2015 at 11:40:20AM +0200, Dr. H. Nikolaus Schaller wrote: > >>> diff --git a/Documentation/usb/usb-serial.txt > >>> b/Documentation/usb/usb-serial.txt > >>> index 947fa62..9f184d8 100644 > >>> --- a/Documentation/usb/usb-serial.txt > >>> +++ b/Documentation/usb/usb-serial.txt > >>> @@ -466,11 +466,13 @@ Generic Serial driver > >>> is required of your device is that it has at least one bulk in endpoint, > >>> or one bulk out endpoint. > >>> > >>> - To enable the generic driver to recognize your device, build the driver > >>> - as a module and load it by the following invocation: > >>> - insmod usbserial vendor=0x product=0x > >>> - where the is replaced with the hex representation of your device's > >>> - vendor id and product id. > >>> + To enable the generic driver to recognize your device, configure > >>> + USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by > >>> the > >> > >> You don't need to build the driver as a module when using the sysfs > >> method. > > > > Ok, that is right and my formulation is too narrow on that. > > Well, I should add that not my formulation was too narrow but already > the original. Since you change the description so that the context becomes invalid, you are responsible for updating the context as well. > > > > So we just s/ as a module//. > > > >> > >>> + following invocation: > >>> + modprobe usbserial > >>> + echo >/sys/bus/usb-serial/drivers/generic/new_id > >>> + where the the first is replaced with the hex representation of > >>> your > >>> + device's vendor id and the second by the product id. > >>> > >>> This driver has been successfully used to connect to the NetChip USB > >>> development board, providing a way to develop USB firmware without Johan -- 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 AM335x: isoc out transfers to FS device via hub are broken
Hi Felipe, a USB soundcard in fullspeed mode works correctly when directly connected to a musb OTG port in host mode on an AM335x SoC, but produces garbled audio output when connected via a hub. usbmon shows that in both cases URBs with typically 5 isoc frames of 192 bytes length are queued. The wMaxPacketSize of the endpoint is 196 bytes. A USB analyzer connected via musb and hub revealed that musb breaks the 192 byte frames into two parts, one 188 byte and one 4 byte frame, ie. a 192 byte OUT transaction produces the following token sequence: SPLIT OUT DATA0 188 bytes SPLIT OUT DATA0 4 bytes The test was done using a 3.18.4 kernel. I reviewed the relevant code in musb_core.c, musb_host.c and musb_cppi41.c, and added a few debug prints, but did not find anything wrong. Since the SPLIT transaction is handled by hardware, I'm currently thinking this might be a hardware issue. Do you have any ideas? Any possible workaround in case it is a hardware issue? BTW, I have some difficulties matching the register details in the AM335x Sitara Processors Technical Reference Manual to the musb source code. Is there any better documentation for the USB hardware available? http://www.ti.com/product/AM3359/technicaldocuments#doctype6 Thanks, Johannes -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usbhid: more mice with ALWAYS_POLL
During a stress test these mice kept dropping and reappearing
in runlevel 1 as opposed to 5.
Signed-off-by: Oliver Neukum
---
drivers/hid/hid-ids.h | 4
drivers/hid/usbhid/hid-quirks.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 7fe5590..34124a0 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -595,6 +595,9 @@
#define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110
#define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f
#define USB_DEVICE_ID_LOGITECH_HARMONY_PS3 0x0306
+#define USB_DEVICE_ID_LOGITECH_MOUSE_C01A 0xc01a
+#define USB_DEVICE_ID_LOGITECH_MOUSE_C05A 0xc05a
+#define USB_DEVICE_ID_LOGITECH_MOUSE_C06A 0xc06a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD_CORD 0xc20a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD 0xc211
#define USB_DEVICE_ID_LOGITECH_EXTREME_3D 0xc215
@@ -1026,6 +1029,7 @@
#define USB_DEVICE_ID_ZYTRONIC_ZXY100 0x0005
#define USB_VENDOR_ID_PRIMAX 0x0461
+#define USB_DEVICE_ID_PRIMAX_MOUSE_4D220x4d22
#define USB_DEVICE_ID_PRIMAX_KEYBOARD 0x4e05
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 4e3ae9f..4e345fb 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -81,6 +81,9 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C01A,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C05A,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C06A,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3_JP,
HID_QUIRK_NO_INIT_REPORTS },
@@ -94,6 +97,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2,
HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_MOUSE_4D22,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_PRODIGE, USB_DEVICE_ID_PRODIGE_CORDLESS,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3001,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3008,
HID_QUIRK_NOGET },
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usbhid: yet another mouse with ALWAYS_POLL
The device exists with two device IDs instead of one as previously
believed.
Signed-off-by: Oliver Neukum
---
drivers/hid/hid-ids.h | 3 ++-
drivers/hid/usbhid/hid-quirks.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 34124a0..3bce9c7 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -460,7 +460,8 @@
#define USB_DEVICE_ID_UGCI_FIGHTING0x0030
#define USB_VENDOR_ID_HP 0x03f0
-#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE 0x0a4a
+#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
+#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
#define USB_VENDOR_ID_HUION0x256c
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 4e345fb..219ecb4 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -78,7 +78,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
HID_QUIRK_NOGET },
- { USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_HP,
USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A, HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_HP,
USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C01A,
HID_QUIRK_ALWAYS_POLL },
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] genirq: provide dummy set_irq_wake()
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the dummy irq hook.
(e.g. drivers/gpio/gpio-pcf857x.c)
http://article.gmane.org/gmane.linux.kernel/1879035
Signed-off-by: Roger Quadros
---
kernel/irq/dummychip.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 988dc58..2405d7a 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -32,6 +32,11 @@ static unsigned int noop_ret(struct irq_data *data)
return 0;
}
+static int noop_int_ret(struct irq_data *data, unsigned int val)
+{
+ return 0;
+}
+
/*
* Generic no controller implementation
*/
@@ -57,5 +62,6 @@ struct irq_chip dummy_irq_chip = {
.irq_ack= noop,
.irq_mask = noop,
.irq_unmask = noop,
+ .irq_set_wake = noop_int_ret,
};
EXPORT_SYMBOL_GPL(dummy_irq_chip);
--
2.1.0
--
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: Errata for Freescale root-hub TT?
On Mon, 30 Mar 2015, Peter Chen wrote: > > That's strange. Can you please post the /sys/kernel/debug/usb/devices > > file (with the UAC2 gadget plugged in), and also collect a usbmon trace > > of the test? > > > > It should be UAC2 gadget or chipidea driver problem, it is ok if I plug > in USB audio card, but most of current audio cards support 44.1k+ > frame rate, it can't handle the 3rd endpoint (176-184 bytes / endpoint), > I don't know how to let it only read/writes 64 bytes, anyway, I will fix > the UAC2 gadget problem first. > > Device file for UAC2: > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=12 MxCh= 0 > D: Ver= 0.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=15a2 ProdID=0054 Rev= 4.00 > S: Manufacturer=Freescale > S: Product=FSL i.mx6q sabreSD Board > S: SerialNumber=123456ABCDEF > C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr= 6mA > A: FirstIf#= 0 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 > I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 > Driver=snd-usb-audio > I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 > Driver=snd-usb-audio > I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 > Driver=snd-usb-audio > E: Ad=01(O) Atr=05(Isoc) MxPS=1023 Ivl=1ms > I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 > Driver=snd-usb-audio > I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 > Driver=snd-usb-audio > E: Ad=81(I) Atr=05(Isoc) MxPS=1023 Ivl=1ms This is bad. All the endpoints have maxpacket = 1023, and that's much too big for this test. We need a maxpacket size of 64 (maybe a little bigger but not much). It may be possible to test the hardware without actually plugging in a USB audio device. I can write a testing patch for ehci-hcd that will cause it to create all the appropriate siTDs and link them into the periodic schedule. All you will need is a full-speed hub. The host controller will send the isochronous packets to the hub and you should be able to watch them on a bus analyzer. There won't be any response to the packets (obviously!), but for isochronous that's okay. Does that sound like it will work? 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: musb AM335x: isoc out transfers to FS device via hub are broken
On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > Hi Felipe, > > a USB soundcard in fullspeed mode works correctly > when directly connected to a musb OTG port in host mode > on an AM335x SoC, but produces garbled audio output > when connected via a hub. usbmon shows that in both This is a high-speed (USB-2) hub, right? > cases URBs with typically 5 isoc frames of 192 bytes > length are queued. The wMaxPacketSize of the > endpoint is 196 bytes. A USB analyzer connected > via musb and hub revealed that musb breaks > the 192 byte frames into two parts, one 188 byte > and one 4 byte frame, ie. a 192 byte OUT transaction > produces the following token sequence: > > SPLIT > OUT > DATA0 188 bytes > SPLIT > OUT > DATA0 4 bytes That is correct behavior when a full-speed device is connected to a high-speed hub. Have you tried hooking your USB analyzer between the hub and the sound card? In that position it ought to show a single 192-byte OUT packet, as you expect. > The test was done using a 3.18.4 kernel. I reviewed > the relevant code in musb_core.c, musb_host.c and > musb_cppi41.c, and added a few debug prints, but > did not find anything wrong. Since the SPLIT transaction > is handled by hardware, I'm currently thinking this might > be a hardware issue. > Do you have any ideas? Any possible workaround in case > it is a hardware issue? Perhaps the values in the DATA packets are wrong. The best way for you to tell is to move the bus analyzer downstream from the hub and then compare the values you see in the packets with the audio data being played. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usbhid: more mice with ALWAYS_POLL
On Mon, 30 Mar 2015, Oliver Neukum wrote:
> During a stress test these mice kept dropping and reappearing
> in runlevel 1 as opposed to 5.
>
> Signed-off-by: Oliver Neukum
I am postponing all these before it is clarified that this is indeed a
case reporter is able to reproduce on different system as well to rule out
the possibility of hub being the actual root cause.
> ---
> drivers/hid/hid-ids.h | 4
> drivers/hid/usbhid/hid-quirks.c | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 7fe5590..34124a0 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -595,6 +595,9 @@
> #define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST 0xc110
> #define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f
> #define USB_DEVICE_ID_LOGITECH_HARMONY_PS3 0x0306
> +#define USB_DEVICE_ID_LOGITECH_MOUSE_C01A0xc01a
> +#define USB_DEVICE_ID_LOGITECH_MOUSE_C05A0xc05a
> +#define USB_DEVICE_ID_LOGITECH_MOUSE_C06A0xc06a
> #define USB_DEVICE_ID_LOGITECH_RUMBLEPAD_CORD0xc20a
> #define USB_DEVICE_ID_LOGITECH_RUMBLEPAD 0xc211
> #define USB_DEVICE_ID_LOGITECH_EXTREME_3D0xc215
> @@ -1026,6 +1029,7 @@
> #define USB_DEVICE_ID_ZYTRONIC_ZXY1000x0005
>
> #define USB_VENDOR_ID_PRIMAX 0x0461
> +#define USB_DEVICE_ID_PRIMAX_MOUSE_4D22 0x4d22
> #define USB_DEVICE_ID_PRIMAX_KEYBOARD0x4e05
>
>
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 4e3ae9f..4e345fb 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -81,6 +81,9 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077,
> HID_QUIRK_ALWAYS_POLL },
> + { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C01A,
> HID_QUIRK_ALWAYS_POLL },
> + { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C05A,
> HID_QUIRK_ALWAYS_POLL },
> + { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C06A,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3_JP,
> HID_QUIRK_NO_INIT_REPORTS },
> @@ -94,6 +97,7 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2,
> HID_QUIRK_NO_INIT_REPORTS },
> + { USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_MOUSE_4D22,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_PRODIGE, USB_DEVICE_ID_PRODIGE_CORDLESS,
> HID_QUIRK_NOGET },
> { USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3001,
> HID_QUIRK_NOGET },
> { USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3008,
> HID_QUIRK_NOGET },
> --
> 2.1.4
>
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb AM335x: isoc out transfers to FS device via hub are broken
On Mon, Mar 30, 2015 at 10:07:35AM -0400, Alan Stern wrote: > On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > a USB soundcard in fullspeed mode works correctly > > when directly connected to a musb OTG port in host mode > > on an AM335x SoC, but produces garbled audio output > > when connected via a hub. usbmon shows that in both > > This is a high-speed (USB-2) hub, right? yes > > cases URBs with typically 5 isoc frames of 192 bytes > > length are queued. The wMaxPacketSize of the > > endpoint is 196 bytes. A USB analyzer connected > > via musb and hub revealed that musb breaks > > the 192 byte frames into two parts, one 188 byte > > and one 4 byte frame, ie. a 192 byte OUT transaction > > produces the following token sequence: > > > > SPLIT > > OUT > > DATA0 188 bytes > > SPLIT > > OUT > > DATA0 4 bytes > > That is correct behavior when a full-speed device is connected to a > high-speed hub. Is it? I would expect a single 192 byte packet here, breaking it in two doesn't make sense even if the hub would be able to reassemble the parts. My recollection of the SPLIT mechanism is to free up the HS bus between FS send and FS ACK for other transactions on other hub ports, not to split the data packets. > Have you tried hooking your USB analyzer between the > hub and the sound card? In that position it ought to show a single > 192-byte OUT packet, as you expect. I'll don't have the logs here but I'll let you know asap. IIRC there were CRC errors, but I did not take this log myself, I only took the log between musb host and hub to confirm the data packet split which I assumed was the root cause of the issue. > > The test was done using a 3.18.4 kernel. I reviewed > > the relevant code in musb_core.c, musb_host.c and > > musb_cppi41.c, and added a few debug prints, but > > did not find anything wrong. Since the SPLIT transaction > > is handled by hardware, I'm currently thinking this might > > be a hardware issue. > > Do you have any ideas? Any possible workaround in case > > it is a hardware issue? > > Perhaps the values in the DATA packets are wrong. The best way for you > to tell is to move the bus analyzer downstream from the hub and then > compare the values you see in the packets with the audio data being > played. The ALSA driver should be unaware of the hub and send the same data, right? Thanks, Johannes -- 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: Problems with usbserial
On Mon, Mar 30, 2015 at 04:44:12PM +0200, misterTi misterTi wrote: > Hello, > > i am having some serious problems with using usb gsm dongles (huawei E1550) > with usbserial driver. > > The problem i am experiencing is devastating on raspberry pi, debian 6 and > 7 and also on desktop debian 6 and 7. I only read your private mail quickly before asking you to send it to the list and it looks like my initial guess that this was host controller related was wrong. I see now that you say you can reproduce this also on a desktop system and not just the RPI? What USB serial driver are you using? It looks like you should be using the option driver (and usb_modeswitch). Johan -- 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
Problems with usbserial
Hello, i am having some serious problems with using usb gsm dongles (huawei E1550) with usbserial driver. The problem i am experiencing is devastating on raspberry pi, debian 6 and 7 and also on desktop debian 6 and 7. The device stops responding (stalls) randomly when i use it through ttyUSB, especially on raspberry pi. Then it might start responding again or not, or i have to remove it and reinsert it, or reboot to get it working again. If i connect a few of them with usb hub (tried many hubs), pi starts stalling to the point where it needs to be rebooted. Same for desktop, although desktop stays responsive, just usbserial sometimes unusable until reboot. In short, behavior is unpredictable. I have a feeling there is something wrong with some driver. Since i don't know yet where exactly usbserial driver comes into picture (what it depends on to reach the hardware), i would like to setup a debug environment on pi or desktop and try to find the problem. (or enable more logging) The whole thing behaves normally on windows, so it can't be usb dongle's or usb hub's fault. I sent the same email to Johan Hovold, whose address was available in the usb-serial driver source code. He suggested i contact this mailing list. BR, Joze >Response From Johan Hovold > >This is likely a problem with the host-controller (driver). > >Please submit this to the linux-usb list at linux-usb@vger.kernel.org. >You can keep me on CC. -- 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 device nodes in device tree
Hello, We are currently developing a board with an USB MFD device (I2C and GPIOs are to be supported). The device is soldered on the board and is the only one on the bus, so the bus is not really "dynamic". Since it's an USB device, it should be dynamically detected by the kernel and it would not require a node in the board's DTS. However, I need to have the devices which are "behind" the MFD USB device to be in the DTS (I2C bus topology, and some of the GPIOs are to be used directly by some other DTS nodes as well). Is there a way to add a node for USB device in a DTS ? Is there an available example for this ? Thank you Valentin -- 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 AM335x: isoc out transfers to FS device via hub are broken
On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > cases URBs with typically 5 isoc frames of 192 bytes > > > length are queued. The wMaxPacketSize of the > > > endpoint is 196 bytes. A USB analyzer connected > > > via musb and hub revealed that musb breaks > > > the 192 byte frames into two parts, one 188 byte > > > and one 4 byte frame, ie. a 192 byte OUT transaction > > > produces the following token sequence: > > > > > > SPLIT > > > OUT > > > DATA0 188 bytes > > > SPLIT > > > OUT > > > DATA0 4 bytes > > > > That is correct behavior when a full-speed device is connected to a > > high-speed hub. > > Is it? I would expect a single 192 byte packet here, breaking > it in two doesn't make sense even if the hub would be able > to reassemble the parts. My recollection of the SPLIT mechanism > is to free up the HS bus between FS send and FS ACK for other > transactions on other hub ports, not to split the data packets. You have to get down into the gritty details. They are explained in the USB spec, if you're curious. Basically, the idea is that the transfer gets broken up into pieces, each of which is more or less capable of fitting in a single microframe (125 us = 188 bytes of FS data, approximately). As far as I can tell, it was done this way so as to minimize the amount of data a hub would have to store and forward -- a bad tradeoff since it increases driver complexity while saving only a few KB of storage (a completely negligible amount nowadays). > > Perhaps the values in the DATA packets are wrong. The best way for you > > to tell is to move the bus analyzer downstream from the hub and then > > compare the values you see in the packets with the audio data being > > played. > > The ALSA driver should be unaware of the hub and > send the same data, right? That's right. 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: musb AM335x: isoc out transfers to FS device via hub are broken
On Mon, Mar 30, 2015 at 04:23:53PM +0200, Johannes Stezenbach wrote: > On Mon, Mar 30, 2015 at 10:07:35AM -0400, Alan Stern wrote: > > On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > > > cases URBs with typically 5 isoc frames of 192 bytes > > > length are queued. The wMaxPacketSize of the > > > endpoint is 196 bytes. A USB analyzer connected > > > via musb and hub revealed that musb breaks > > > the 192 byte frames into two parts, one 188 byte > > > and one 4 byte frame, ie. a 192 byte OUT transaction > > > produces the following token sequence: > > > > > > SPLIT > > > OUT > > > DATA0 188 bytes > > > SPLIT > > > OUT > > > DATA0 4 bytes > > > > That is correct behavior when a full-speed device is connected to a > > high-speed hub. > > Is it? I would expect a single 192 byte packet here, breaking > it in two doesn't make sense even if the hub would be able > to reassemble the parts. My recollection of the SPLIT mechanism > is to free up the HS bus between FS send and FS ACK for other > transactions on other hub ports, not to split the data packets. > > > Have you tried hooking your USB analyzer between the > > hub and the sound card? In that position it ought to show a single > > 192-byte OUT packet, as you expect. > > I'll don't have the logs here but I'll let you know asap. > IIRC there were CRC errors, but I did not take this > log myself, I only took the log between musb host and hub > to confirm the data packet split which I assumed was the root > cause of the issue. The log between hub and soundcard shows this: SOF OUT DATA0 185 byte with CRC error OUT DATA0 4 bytes Four different hubs have been tried to rule out a hub issue, both powered and unpowered. But I just re-read the USB spec about the special case of Isochronous OUT split handling, in this case it is indeed possible to split the payload. So let me expand the log, maybe the issue is caused by the interleaving of IN and OUT transactions? (The soundcard has audio inputs and outputs.) Between host and hub (HS): frame# 1193.1 SOF 1193.2 SOF SPLIT Complete S=0 ET=Isoc IN EP=1 DATA0 0 bytes 1193.3 SOF 1193.4 SOF 1193.5 SOF 1193.6 SOF 1193.7 SOF 1194.0 SOF SPLIT Start S=1 E=0 ET=Isoc OUT EP=1 DATA0 188 bytes SPLIT Start S=0 E=1 ET=Isoc OUT EP=1 DATA0 4 bytes 1194.1 SOF 1194.2 SOF ... Between hub and soundcard (FS): frame# 1193 SOF OUT EP=1 DATA0 185 bytes with CRC error IN EP=1 DATA0 0 bytes OUT EP=1 DATA0 4 bytes 1194 SOF ... (The Total Phase analyzer does not allow text export or copy&paste, so I had to reproduce manually. Apparently it does not show OUT SPLIT Comlete and IN SPLIT Start.) While it seems permissible by the USB spec to split the payload, I don't understand the reason to do so. I mean the payload has to be smaller than the wMaxPacketSize of the EP, and the wMaxPacketSize of a FS EP is always smaller than the max size of an HS Isoc data packet? I must be missing something... Apparently the hubs cannot cope with this sequence, does it mean all four hubs which were tested are buggy? Thanks, Johannes -- 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 AM335x: isoc out transfers to FS device via hub are broken
On Mon, Mar 30, 2015 at 11:58:55AM -0400, Alan Stern wrote: > On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > > > Is it? I would expect a single 192 byte packet here, breaking > > it in two doesn't make sense even if the hub would be able > > to reassemble the parts. My recollection of the SPLIT mechanism > > is to free up the HS bus between FS send and FS ACK for other > > transactions on other hub ports, not to split the data packets. > > You have to get down into the gritty details. They are explained in > the USB spec, if you're curious. Basically, the idea is that the > transfer gets broken up into pieces, each of which is more or less > capable of fitting in a single microframe (125 us = 188 bytes of FS > data, approximately). > > As far as I can tell, it was done this way so as to minimize the amount > of data a hub would have to store and forward -- a bad tradeoff since > it increases driver complexity while saving only a few KB of storage (a > completely negligible amount nowadays). Thanks for the explanation, our emails just crossed as it took me too long to prepare mine. So it looks like to be a hub issue. Will try some other hubs. Thanks, Johannes -- 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 AM335x: isoc out transfers to FS device via hub are broken
On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > The log between hub and soundcard shows this: > > SOF > OUT > DATA0 185 byte with CRC error > OUT > DATA0 4 bytes Which is totally wrong, of course. > Four different hubs have been tried to rule out a hub issue, > both powered and unpowered. > > But I just re-read the USB spec about the special case of > Isochronous OUT split handling, in this case it is indeed > possible to split the payload. So let me expand the log, > maybe the issue is caused by the interleaving of IN and OUT > transactions? (The soundcard has audio inputs and outputs.) > > Between host and hub (HS): > > frame# > 1193.1 SOF > 1193.2 SOF > SPLIT Complete S=0 ET=Isoc > IN EP=1 > DATA0 0 bytes > 1193.3 SOF > 1193.4 SOF > 1193.5 SOF > 1193.6 SOF > 1193.7 SOF We can ignore that isoc-IN as not being relevant to any isoc-OUT transfers. This doesn't show any isoc-OUT activity during frame 1193. > 1194.0 SOF > SPLIT Start S=1 E=0 ET=Isoc > OUT EP=1 > DATA0 188 bytes > SPLIT Start S=0 E=1 ET=Isoc > OUT EP=1 > DATA0 4 bytes > 1194.1 SOF > 1194.2 SOF > ... That is not good. The two Start SPLIT transactions are not supposed to occur in the same microframe. The second transaction should have occurred during microframe 1194.1. That could easily confuse the hub. (Actually, depending on the details of the scheduling, it seems more likely that the first Start SPLIT should have shown up during microframe 1193.7 and the second during 1194.0.) > Between hub and soundcard (FS): > > frame# > 1193 SOF > OUT EP=1 > DATA0 185 bytes with CRC error This doesn't correspond to anything in the high-speed trace. Also, the CRC is supposed to be generated by the hub's TT, not by the host. If it is wrong, it indicates the hub isn't behaving properly, perhaps because it was confused by the invalid sequence of Start SPLIT transactions. >IN EP=1 >DATA0 0 bytes >OUT EP=1 >DATA0 4 bytes This data is all for frame 1193, not 1194 as in the high-speed trace. Were the two traces made at the same time? > 1194 SOF > ... > > > (The Total Phase analyzer does not allow text export or copy&paste, > so I had to reproduce manually. Apparently it does not show > OUT SPLIT Comlete and IN SPLIT Start.) It does show isoc-IN Start SPLITs if you look closely. It doesn't show isoc-OUT Complete SPLITs because there is no such thing. > While it seems permissible by the USB spec to split the payload, Not permissible -- required! See paragraph 2a in section 11.18.4 of the USB-2 spec. > I don't understand the reason to do so. I mean the payload has > to be smaller than the wMaxPacketSize of the EP, and the > wMaxPacketSize of a FS EP is always smaller than the max > size of an HS Isoc data packet? I must be missing something... It's done this way to minimize the amount of data buffering needed in the hub's Transaction Translator. Full-speed transactions are broken up into microframe-sized pieces, and the TT is required to store only a few of these pieces. Since it's not possible to transfer more than 188 bytes over a full-speed link in 125 us (one microframe), transfers are broken up into pieces that are 188 bytes or the remainder of the transfer, whichever is smaller. The same thing happens with Complete SPLITs for long isoc-IN transfers. > Apparently the hubs cannot cope with this sequence, does it > mean all four hubs which were tested are buggy? Judging by your high-speed log, it looks like the host controller is not sending out the Start SPLIT transactions the way it should. 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: musb AM335x: isoc out transfers to FS device via hub are broken
On Mon, Mar 30, 2015 at 01:41:29PM -0400, Alan Stern wrote: > On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > The log between hub and soundcard shows this: > > > > SOF > > OUT > > DATA0 185 byte with CRC error > > OUT > > DATA0 4 bytes > > Which is totally wrong, of course. Yes, my assumption is that the receiption of the 4 byte packet truncates the 188 byte packet in the hub. > That is not good. The two Start SPLIT transactions are not supposed to > occur in the same microframe. The second transaction should have > occurred during microframe 1194.1. That could easily confuse the hub. ... > This data is all for frame 1193, not 1194 as in the high-speed trace. > Were the two traces made at the same time? Nope, I'm glad to have access to _one_ USB analyzer. The packet sequence is very repetitive, I chose sequences with the same packet number from both logs but they do not actually correspond. That also makes it difficult to compare the packet's data contents although it should match up since the same audio clip is played in both cases. > > (The Total Phase analyzer does not allow text export or copy&paste, > > so I had to reproduce manually. Apparently it does not show > > OUT SPLIT Comlete and IN SPLIT Start.) > > It does show isoc-IN Start SPLITs if you look closely. It doesn't show > isoc-OUT Complete SPLITs because there is no such thing. OK, it shows Start -> NYET -> Complete, once I figured out how to read the trace I can see it. > > While it seems permissible by the USB spec to split the payload, > > Not permissible -- required! See paragraph 2a in section 11.18.4 of > the USB-2 spec. > > > I don't understand the reason to do so. I mean the payload has > > to be smaller than the wMaxPacketSize of the EP, and the > > wMaxPacketSize of a FS EP is always smaller than the max > > size of an HS Isoc data packet? I must be missing something... > > It's done this way to minimize the amount of data buffering needed in > the hub's Transaction Translator. Full-speed transactions are broken > up into microframe-sized pieces, and the TT is required to store only a > few of these pieces. > > Since it's not possible to transfer more than 188 bytes over a > full-speed link in 125 us (one microframe), transfers are broken up > into pieces that are 188 bytes or the remainder of the transfer, > whichever is smaller. The same thing happens with Complete SPLITs for > long isoc-IN transfers. > > > Apparently the hubs cannot cope with this sequence, does it > > mean all four hubs which were tested are buggy? > > Judging by your high-speed log, it looks like the host controller is > not sending out the Start SPLIT transactions the way it should. Yes, it happens consistently that the host send two SPLIT OUT packets in the same microframe. So that explains the cause of the issue, the question is now if there is a workaround, but my expectations are low since the musb split packet handling is all done in hardware. Thanks, Johannes -- 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] genirq: provide dummy set_irq_wake()
On Mon, Mar 30, 2015 at 04:15:45PM +0300, Roger Quadros wrote:
> Without this system suspend is broken on systems that have
> drivers calling enable/disable_irq_wake() for interrupts based off
> the dummy irq hook.
> (e.g. drivers/gpio/gpio-pcf857x.c)
>
> http://article.gmane.org/gmane.linux.kernel/1879035
>
> Signed-off-by: Roger Quadros
> ---
> kernel/irq/dummychip.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
> index 988dc58..2405d7a 100644
> --- a/kernel/irq/dummychip.c
> +++ b/kernel/irq/dummychip.c
> @@ -32,6 +32,11 @@ static unsigned int noop_ret(struct irq_data *data)
> return 0;
> }
>
> +static int noop_int_ret(struct irq_data *data, unsigned int val)
> +{
> + return 0;
> +}
> +
isn't this the same as noop_ret ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] genirq: provide dummy set_irq_wake()
On Mon, Mar 30, 2015 at 01:06:24PM -0500, Felipe Balbi wrote:
> On Mon, Mar 30, 2015 at 04:15:45PM +0300, Roger Quadros wrote:
> > Without this system suspend is broken on systems that have
> > drivers calling enable/disable_irq_wake() for interrupts based off
> > the dummy irq hook.
> > (e.g. drivers/gpio/gpio-pcf857x.c)
> >
> > http://article.gmane.org/gmane.linux.kernel/1879035
> >
> > Signed-off-by: Roger Quadros
> > ---
> > kernel/irq/dummychip.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
> > index 988dc58..2405d7a 100644
> > --- a/kernel/irq/dummychip.c
> > +++ b/kernel/irq/dummychip.c
> > @@ -32,6 +32,11 @@ static unsigned int noop_ret(struct irq_data *data)
> > return 0;
> > }
> >
> > +static int noop_int_ret(struct irq_data *data, unsigned int val)
> > +{
> > + return 0;
> > +}
> > +
>
> isn't this the same as noop_ret ?
oh no, unsigned versus signed.
--
balbi
signature.asc
Description: Digital signature
Re: musb AM335x: isoc out transfers to FS device via hub are broken
On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > Judging by your high-speed log, it looks like the host controller is > > not sending out the Start SPLIT transactions the way it should. > > Yes, it happens consistently that the host send two SPLIT OUT > packets in the same microframe. So that explains the cause > of the issue, the question is now if there is a workaround, > but my expectations are low since the musb split packet handling > is all done in hardware. Is there perhaps a known erratum that mentions this? It seems like a pretty serious problem, the sort of thing anyone would notice the first time they tried to play audio through a high-speed hub. 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: USB device nodes in device tree
On Mon, 30 Mar 2015, Valentin Longchamp wrote: > Hello, > > We are currently developing a board with an USB MFD device (I2C and GPIOs are > to > be supported). The device is soldered on the board and is the only one on the > bus, so the bus is not really "dynamic". > > Since it's an USB device, it should be dynamically detected by the kernel and > it > would not require a node in the board's DTS. However, I need to have the > devices > which are "behind" the MFD USB device to be in the DTS (I2C bus topology, and > some of the GPIOs are to be used directly by some other DTS nodes as well). > > Is there a way to add a node for USB device in a DTS ? Is there an available > example for this ? No, there is no way to do it as far as I know. The main problem is that Device Tree is static whereas USB devices are dynamic. 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 4/5 linux-next] fotg210-hcd: remove unneccessary message level.
KERN_WARNING is implicitely declared in pr_warn()
Signed-off-by: Fabian Frederick
---
drivers/usb/host/fotg210-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 475b21f..98b0d05 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -5914,7 +5914,7 @@ static int __init fotg210_hcd_init(void)
set_bit(USB_EHCI_LOADED, &usb_hcds_loaded);
if (test_bit(USB_UHCI_LOADED, &usb_hcds_loaded) ||
test_bit(USB_OHCI_LOADED, &usb_hcds_loaded))
- pr_warn(KERN_WARNING "Warning! fotg210_hcd should always be
loaded before uhci_hcd and ohci_hcd, not after\n");
+ pr_warn("Warning! fotg210_hcd should always be loaded before
uhci_hcd and ohci_hcd, not after\n");
pr_debug("%s: block sizes: qh %Zd qtd %Zd itd %Zd\n",
hcd_name,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb AM335x: isoc out transfers to FS device via hub are broken
On Mon, Mar 30, 2015 at 02:56:40PM -0400, Alan Stern wrote: > On Mon, 30 Mar 2015, Johannes Stezenbach wrote: > > > > Judging by your high-speed log, it looks like the host controller is > > > not sending out the Start SPLIT transactions the way it should. > > > > Yes, it happens consistently that the host send two SPLIT OUT > > packets in the same microframe. So that explains the cause > > of the issue, the question is now if there is a workaround, > > but my expectations are low since the musb split packet handling > > is all done in hardware. > > Is there perhaps a known erratum that mentions this? It seems like a > pretty serious problem, the sort of thing anyone would notice the first > time they tried to play audio through a high-speed hub. It is not listed in the AM335x errata document: http://www.ti.com/product/AM3359/technicaldocuments#doctype3 Probably it is not a very common use case, at least I couldn't find any public mention of this issue. Johannes -- 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: Errata for Freescale root-hub TT?
On Mon, Mar 30, 2015 at 10:03:07AM -0400, Alan Stern wrote: > On Mon, 30 Mar 2015, Peter Chen wrote: > > > > That's strange. Can you please post the /sys/kernel/debug/usb/devices > > > file (with the UAC2 gadget plugged in), and also collect a usbmon trace > > > of the test? > > > > > > > It should be UAC2 gadget or chipidea driver problem, it is ok if I plug > > in USB audio card, but most of current audio cards support 44.1k+ > > frame rate, it can't handle the 3rd endpoint (176-184 bytes / endpoint), > > I don't know how to let it only read/writes 64 bytes, anyway, I will fix > > the UAC2 gadget problem first. > > > > Device file for UAC2: > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=12 MxCh= 0 > > D: Ver= 0.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > > P: Vendor=15a2 ProdID=0054 Rev= 4.00 > > S: Manufacturer=Freescale > > S: Product=FSL i.mx6q sabreSD Board > > S: SerialNumber=123456ABCDEF > > C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr= 6mA > > A: FirstIf#= 0 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 > > I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 > > Driver=snd-usb-audio > > I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 > > Driver=snd-usb-audio > > I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 > > Driver=snd-usb-audio > > E: Ad=01(O) Atr=05(Isoc) MxPS=1023 Ivl=1ms > > I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 > > Driver=snd-usb-audio > > I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 > > Driver=snd-usb-audio > > E: Ad=81(I) Atr=05(Isoc) MxPS=1023 Ivl=1ms > > This is bad. All the endpoints have maxpacket = 1023, and that's much > too big for this test. We need a maxpacket size of 64 (maybe a little > bigger but not much). Thanks, after changing maxpacket to 64, this problem is fixed. Go back to UAC2 spec, it defines wMaxPacketSize like below: Maximum packet size this endpoint is capable of sending or receiving when this configuration is selected. This is determined by the audio bandwidth constraints of the endpoint. So, the UAC2 should calculate maxpacket according to frame rate, and channel number. I will see if I can reproduce your case today. > > It may be possible to test the hardware without actually plugging in a > USB audio device. I can write a testing patch for ehci-hcd that will > cause it to create all the appropriate siTDs and link them into the > periodic schedule. > > All you will need is a full-speed hub. The host controller will send > the isochronous packets to the hub and you should be able to watch them > on a bus analyzer. There won't be any response to the packets > (obviously!), but for isochronous that's okay. > > Does that sound like it will work? > > Alan Stern > -- 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 RESEND] phy: exynos5-usbdrd: Add to support for Exynos5433 SoC
Hi Kishon.
Could you check my patch??
On 26/03/2015 14:16, Vivek Gautam wrote:
On Thu, Mar 26, 2015 at 7:48 AM, Jaewon Kim wrote:
This patch adds driver data to support for Exynos5433 SoC.
The Exynos5433 has one USB3.0 Host and USB3.0 DRD(Dual Role Device).
Exynos5433 is simplar to Eyxnos7 but Exynos5433 have
one more USB3.0 Host controller.
Signed-off-by: Jaewon Kim
Tested-by: Chanwoo Choi
---
Patch looks good to me.
Reviewed-by: Vivek Gautam
.../devicetree/bindings/phy/samsung-phy.txt|3 ++-
drivers/phy/phy-exynos5-usbdrd.c | 10 ++
include/linux/mfd/syscon/exynos5-pmu.h |3 +++
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 91e38cf..60c6f2a 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -128,6 +128,7 @@ Required properties:
- compatible : Should be set to one of the following supported values:
- "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
- "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+ - "samsung,exynos5433-usbdrd-phy" - for exynos5433 SoC.
- "samsung,exynos7-usbdrd-phy" - for exynos7 SoC.
- reg : Register offset and length of USB DRD PHY register set;
- clocks: Clock IDs array as required by the controller
@@ -139,7 +140,7 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
- - optional clocks: Exynos7 SoC has now following additional
+ - optional clocks: Exynos5433 & Exynos7 SoC has now following additional
gate clocks available:
- phy_pipe: for PIPE3 phy
- phy_utmi: for UTMI+ phy
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index e2a0be7..d72ef15 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -624,6 +624,13 @@ static const struct exynos5_usbdrd_phy_drvdata
exynos5250_usbdrd_phy = {
.has_common_clk_gate= true,
};
+static const struct exynos5_usbdrd_phy_drvdata exynos5433_usbdrd_phy = {
+ .phy_cfg= phy_cfg_exynos5,
+ .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
+ .pmu_offset_usbdrd1_phy = EXYNOS5433_USBHOST30_PHY_CONTROL,
+ .has_common_clk_gate= false,
+};
+
static const struct exynos5_usbdrd_phy_drvdata exynos7_usbdrd_phy = {
.phy_cfg= phy_cfg_exynos5,
.pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
@@ -638,6 +645,9 @@ static const struct of_device_id
exynos5_usbdrd_phy_of_match[] = {
.compatible = "samsung,exynos5420-usbdrd-phy",
.data = &exynos5420_usbdrd_phy
}, {
+ .compatible = "samsung,exynos5433-usbdrd-phy",
+ .data = &exynos5433_usbdrd_phy
+ }, {
.compatible = "samsung,exynos7-usbdrd-phy",
.data = &exynos7_usbdrd_phy
},
diff --git a/include/linux/mfd/syscon/exynos5-pmu.h
b/include/linux/mfd/syscon/exynos5-pmu.h
index 00ef24b..9352adc 100644
--- a/include/linux/mfd/syscon/exynos5-pmu.h
+++ b/include/linux/mfd/syscon/exynos5-pmu.h
@@ -36,6 +36,9 @@
#define EXYNOS5420_MTCADC_PHY_CONTROL (0x724)
#define EXYNOS5420_DPTX_PHY_CONTROL(0x728)
+/* Exynos5433 specific register definitions */
+#define EXYNOS5433_USBHOST30_PHY_CONTROL (0x728)
+
#define EXYNOS5_PHY_ENABLE BIT(0)
#define EXYNOS5_MIPI_PHY_S_RESETN BIT(1)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
Jaewon Kim.
--
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 RESEND] phy: exynos5-usbdrd: Add to support for Exynos5433 SoC
On Tuesday 31 March 2015 10:36 AM, Jaewon Kim wrote:
Hi Kishon.
Could you check my patch??
sure.. patch looks fine. will queue it.
-Kishon
On 26/03/2015 14:16, Vivek Gautam wrote:
On Thu, Mar 26, 2015 at 7:48 AM, Jaewon Kim wrote:
This patch adds driver data to support for Exynos5433 SoC.
The Exynos5433 has one USB3.0 Host and USB3.0 DRD(Dual Role Device).
Exynos5433 is simplar to Eyxnos7 but Exynos5433 have
one more USB3.0 Host controller.
Signed-off-by: Jaewon Kim
Tested-by: Chanwoo Choi
---
Patch looks good to me.
Reviewed-by: Vivek Gautam
.../devicetree/bindings/phy/samsung-phy.txt|3 ++-
drivers/phy/phy-exynos5-usbdrd.c | 10 ++
include/linux/mfd/syscon/exynos5-pmu.h |3 +++
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 91e38cf..60c6f2a 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -128,6 +128,7 @@ Required properties:
- compatible : Should be set to one of the following supported values:
- "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
- "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+ - "samsung,exynos5433-usbdrd-phy" - for exynos5433 SoC.
- "samsung,exynos7-usbdrd-phy" - for exynos7 SoC.
- reg : Register offset and length of USB DRD PHY register set;
- clocks: Clock IDs array as required by the controller
@@ -139,7 +140,7 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
- - optional clocks: Exynos7 SoC has now following additional
+ - optional clocks: Exynos5433 & Exynos7 SoC has now following
additional
gate clocks available:
- phy_pipe: for PIPE3 phy
- phy_utmi: for UTMI+ phy
diff --git a/drivers/phy/phy-exynos5-usbdrd.c
b/drivers/phy/phy-exynos5-usbdrd.c
index e2a0be7..d72ef15 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -624,6 +624,13 @@ static const struct exynos5_usbdrd_phy_drvdata
exynos5250_usbdrd_phy = {
.has_common_clk_gate= true,
};
+static const struct exynos5_usbdrd_phy_drvdata exynos5433_usbdrd_phy = {
+ .phy_cfg= phy_cfg_exynos5,
+ .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
+ .pmu_offset_usbdrd1_phy = EXYNOS5433_USBHOST30_PHY_CONTROL,
+ .has_common_clk_gate= false,
+};
+
static const struct exynos5_usbdrd_phy_drvdata exynos7_usbdrd_phy = {
.phy_cfg= phy_cfg_exynos5,
.pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
@@ -638,6 +645,9 @@ static const struct of_device_id
exynos5_usbdrd_phy_of_match[] = {
.compatible = "samsung,exynos5420-usbdrd-phy",
.data = &exynos5420_usbdrd_phy
}, {
+ .compatible = "samsung,exynos5433-usbdrd-phy",
+ .data = &exynos5433_usbdrd_phy
+ }, {
.compatible = "samsung,exynos7-usbdrd-phy",
.data = &exynos7_usbdrd_phy
},
diff --git a/include/linux/mfd/syscon/exynos5-pmu.h
b/include/linux/mfd/syscon/exynos5-pmu.h
index 00ef24b..9352adc 100644
--- a/include/linux/mfd/syscon/exynos5-pmu.h
+++ b/include/linux/mfd/syscon/exynos5-pmu.h
@@ -36,6 +36,9 @@
#define EXYNOS5420_MTCADC_PHY_CONTROL (0x724)
#define EXYNOS5420_DPTX_PHY_CONTROL(0x728)
+/* Exynos5433 specific register definitions */
+#define EXYNOS5433_USBHOST30_PHY_CONTROL (0x728)
+
#define EXYNOS5_PHY_ENABLE BIT(0)
#define EXYNOS5_MIPI_PHY_S_RESETN BIT(1)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
Jaewon Kim.
--
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
