From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bin Meng Date: Thu, 29 Jun 2017 17:54:39 +0800 Subject: [U-Boot] [PATCH 0/3] usb: xhci: Add interrupt transfer support In-Reply-To: References: <1498475142-9252-1-git-send-email-bmeng.cn@gmail.com> <87d6fcc1-b8cd-5822-582a-c1ecf55d4296@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stefan, On Thu, Jun 29, 2017 at 4:57 PM, Bin Meng wrote: > Hi Stefan, > > On Thu, Jun 29, 2017 at 4:09 PM, Stefan Roese wrote: >> Hi Bin, >> >> >> On 29.06.2017 08:51, Bin Meng wrote: >>> >>> Hi Stefan, >>> >>> On Thu, Jun 29, 2017 at 2:13 PM, Stefan Roese wrote: >>>> >>>> Hi Bin, >>>> >>>> On 29.06.2017 07:39, Bin Meng wrote: >>>>> >>>>> Hi Stefan, >>>>> >>>>> On Wed, Jun 28, 2017 at 8:47 PM, Stefan Roese wrote: >>>>>> >>>>>> Hi Bin, >>>>>> >>>>>> On 28.06.2017 14:11, Bin Meng wrote: >>>>>>> >>>>>>> On Wed, Jun 28, 2017 at 7:00 PM, Stefan Roese wrote: >>>>>>>> >>>>>>>> Hi Bin, >>>>>>>> >>>>>>>> On 26.06.2017 13:05, Bin Meng wrote: >>>>>>>>> >>>>>>>>> This series is the final series of the xHCI driver update. >>>>>>>>> >>>>>>>>> This adds the missing interrupt transfer support to xHCI driver, so >>>>>>>>> that devices like USB keyboard that uses interrupt transfer when >>>>>>>>> CONFIG_SYS_USB_EVENT_POLL is defined can work. >>>>>>>>> >>>>>>>>> Previous two series: >>>>>>>>> [1]: usb: xhci: Fix USB xHCI support on Intel platform >>>>>>>>> https://lists.denx.de/pipermail/u-boot/2017-June/296166.html >>>>>>>>> [2]: usb: hub: Support USB 3.0 hubs >>>>>>>>> https://lists.denx.de/pipermail/u-boot/2017-June/296284.html >>>>>>>>> >>>>>>>>> This series is available at u-boot-x86/xhci-working3 for testing. >>>>>>>> >>>>>>>> >>>>>>>> I'm using this git branch to test all your xHCI related patches >>>>>>>> now. On my BayTrail platform I get these messages upon "usb reset" >>>>>>>> scanning: >>>>>>>> >>>>>>>> => usb reset >>>>>>>> resetting USB... >>>>>>>> USB0: Register 7000820 NbrPorts 7 >>>>>>>> Starting the controller >>>>>>>> USB XHCI 1.00 >>>>>>>> scanning bus 0 for devices... cannot reset port 1!? >>>>>>>> USB device descriptor short read (expected 18, got 8) >>>>>>>> 5 USB Device(s) found >>>>>>>> scanning usb for storage devices... 1 Storage Device(s) >>>>>>>> found >>>>>>>> >>>>>>>> On the 2nd scan, the "cannot reset port 1" line is gone: >>>>>>>> >>>>>>>> => usb reset >>>>>>>> resetting USB... >>>>>>>> USB0: Register 7000820 NbrPorts 7 >>>>>>>> Starting the controller >>>>>>>> USB XHCI 1.00 >>>>>>>> scanning bus 0 for devices... USB device descriptor short read >>>>>>>> (expected 18, got 8) >>>>>>>> 5 USB Device(s) found >>>>>>>> scanning usb for storage devices... 1 Storage Device(s) >>>>>>>> found >>>>>>>> >>>>>>>> All USB devices seem to be detected correctly though. Here the >>>>>>>> logs: >>>>>>>> >>>>>>>> => usb tree >>>>>>>> USB device tree: >>>>>>>> 1 Hub (5 Gb/s, 0mA) >>>>>>>> | U-Boot XHCI Host Controller >>>>>>>> | >>>>>>>> +-2 Hub (480 Mb/s, 100mA) >>>>>>>> | >>>>>>>> +-3 Hub (480 Mb/s, 2mA) >>>>>>>> | | >>>>>>>> | +-5 Mass Storage (480 Mb/s, 200mA) >>>>>>>> | JetFlash Mass Storage Device 3281440601 >>>>>>>> | >>>>>>>> +-4 Vendor specific (5 Gb/s, 64mA) >>>>>>>> Realtek USB 10/100/1000 LAN 000002000000 >>>>>>>> >>>>>>>> => usb info >>>>>>>> 1: Hub, USB Revision 3.0 >>>>>>>> - U-Boot XHCI Host Controller >>>>>>>> - Class: Hub >>>>>>>> - PacketSize: 512 Configurations: 1 >>>>>>>> - Vendor: 0x0000 Product 0x0000 Version 1.0 >>>>>>>> Configuration: 1 >>>>>>>> - Interfaces: 1 Self Powered 0mA >>>>>>>> Interface: 0 >>>>>>>> - Alternate Setting 0, Endpoints: 1 >>>>>>>> - Class Hub >>>>>>>> - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms >>>>>>>> >>>>>>>> 2: Hub, USB Revision 2.0 >>>>>>>> - Class: Hub >>>>>>>> - PacketSize: 64 Configurations: 1 >>>>>>>> - Vendor: 0x0409 Product 0x005a Version 1.0 >>>>>>>> Configuration: 1 >>>>>>>> - Interfaces: 1 Self Powered Remote Wakeup 100mA >>>>>>>> Interface: 0 >>>>>>>> - Alternate Setting 0, Endpoints: 1 >>>>>>>> - Class Hub >>>>>>>> - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms >>>>>>>> >>>>>>>> 3: Hub, USB Revision 2.1 >>>>>>>> - Class: Hub >>>>>>>> - PacketSize: 64 Configurations: 1 >>>>>>>> - Vendor: 0x0424 Product 0x4604 Version 1.131 >>>>>>>> Configuration: 1 >>>>>>>> - Interfaces: 1 Self Powered Remote Wakeup 2mA >>>>>>>> Interface: 0 >>>>>>>> - Alternate Setting 0, Endpoints: 1 >>>>>>>> - Class Hub >>>>>>>> - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms >>>>>>>> - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms >>>>>>>> >>>>>>>> 5: Mass Storage, USB Revision 2.10 >>>>>>>> - JetFlash Mass Storage Device 3281440601 >>>>>>>> - Class: (from Interface) Mass Storage >>>>>>>> - PacketSize: 64 Configurations: 1 >>>>>>>> - Vendor: 0x8564 Product 0x1000 Version 16.117 >>>>>>>> Configuration: 1 >>>>>>>> - Interfaces: 1 Bus Powered 200mA >>>>>>>> Interface: 0 >>>>>>>> - Alternate Setting 0, Endpoints: 2 >>>>>>>> - Class Mass Storage, Transp. SCSI, Bulk only >>>>>>>> - Endpoint 2 Out Bulk MaxPacket 512 >>>>>>>> - Endpoint 1 In Bulk MaxPacket 512 >>>>>>>> >>>>>>>> 4: Vendor specific, USB Revision 3.0 >>>>>>>> - Realtek USB 10/100/1000 LAN 000002000000 >>>>>>>> - Class: (from Interface) Vendor specific >>>>>>>> - PacketSize: 512 Configurations: 2 >>>>>>>> - Vendor: 0x0bda Product 0x8153 Version 48.0 >>>>>>>> Configuration: 1 >>>>>>>> - Interfaces: 1 Bus Powered Remote Wakeup 64mA >>>>>>>> Interface: 0 >>>>>>>> - Alternate Setting 0, Endpoints: 3 >>>>>>>> - Class Vendor specific >>>>>>>> - Endpoint 1 In Bulk MaxPacket 1024 >>>>>>>> - Endpoint 2 Out Bulk MaxPacket 1024 >>>>>>>> - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms >>>>>>>> >>>>>>>> Do you have any ideas about the scanning logs that I've noticed >>>>>>>> above? Would it help if I provided some debug logs (-DDEBUG) >>>>>>>> for this? >>>>>>> >>>>>>> >>>>>>> "cannot reset port 1" message is annoying, but that may happen >>>>>>> sometimes due to unstable power supply. I will see if we can mute it >>>>>>> if it's not the final round of reset try. >>>>>> >>>>>> >>>>>> That would be good, thanks. >>>>>> >>>>>>> I am more concerned about >>>>>>> the "USB device descriptor short read (expected 18, got 8)". This >>>>>>> message indicates U-Boot cannot get the device descriptor during set >>>>>>> configuration process. So did you manage to get all USB devices that >>>>>>> are connected on your board enumerated? >>>>>> >>>>>> >>>>>> Might be that I'm missing some keyboard / mouse, which I'm not >>>>>> using and not really aware of. One USB port is connected to a >>>>>> KVM switch, enumberating such devices. Here the log from U-Boot >>>>>> and Linux again: >>>>>> >>>>>> => usb reset >>>>>> resetting USB... >>>>>> USB0: Register 7000820 NbrPorts 7 >>>>>> Starting the controller >>>>>> USB XHCI 1.00 >>>>>> scanning bus 0 for devices... cannot reset port 1!? >>>>>> USB device descriptor short read (expected 18, got 8) >>>>>> 6 USB Device(s) found >>>>>> scanning usb for storage devices... 2 Storage Device(s) found >>>>>> => usb tree >>>>>> USB device tree: >>>>>> 1 Hub (5 Gb/s, 0mA) >>>>>> | U-Boot XHCI Host Controller >>>>>> | >>>>>> +-2 Hub (480 Mb/s, 100mA) >>>>>> | >>>>>> +-3 Mass Storage (480 Mb/s, 98mA) >>>>>> | USBest Technology USB Mass Storage Device 09092207fbf0c4 >>>>>> | >>>>>> +-4 Hub (480 Mb/s, 2mA) >>>>>> | | >>>>>> | +-6 Mass Storage (480 Mb/s, 200mA) >>>>>> | JetFlash Mass Storage Device 3281440601 >>>>>> | >>>>>> +-5 Vendor specific (5 Gb/s, 64mA) >>>>>> Realtek USB 10/100/1000 LAN 000002000000 >>>>>> >>>>>> >>>>>> $ lsusb -t >>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M >>>>>> |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, >>>>>> Driver=r8152, 5000M >>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M >>>>>> |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M >>>>>> |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 12M >>>>>> |__ Port 1: Dev 6, If 1, Class=Human Interface Device, >>>>>> Driver=usbhid, 12M >>>>>> |__ Port 1: Dev 6, If 2, Class=Human Interface Device, >>>>>> Driver=usbhid, 12M >>>>>> |__ Port 1: Dev 6, If 0, Class=Human Interface Device, >>>>>> Driver=usbhid, 12M >>>>>> |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, >>>>>> 480M >>>>>> |__ Port 5: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M >>>>>> |__ Port 1: Dev 7, If 0, Class=Mass Storage, >>>>>> Driver=usb-storage, 480M >>>>>> >>>>>> >>>>>> Which event polling Kconfig option do I need to enable? >>>>>> >>>>> >>>>> The default one CONFIG_SYS_USB_EVENT_POLL should be OK. By comparing >>>>> your U-Boot log and Linux one, I found the following devices were >>>>> enumerated by Linux but not by U-Boot: >>>>> >>>>> |__ Port 1: Dev 6, If 1, Class=Human Interface Device, >>>>> Driver=usbhid, 12M >>>>> |__ Port 1: Dev 6, If 2, Class=Human Interface Device, >>>>> Driver=usbhid, 12M >>>>> |__ Port 1: Dev 6, If 0, Class=Human Interface Device, >>>>> Driver=usbhid, 12M >>>>> >>>>> These devices are full speed devices. I believe the reason is that >>>>> U-Boot encounters "USB device descriptor short read (expected 18, got >>>>> 8)" so it does not continue the enumeration. As to why these full >>>>> speed devices only return 8 bytes descriptors, this needs to be >>>>> investigated. Which devices are they? >>>> >>>> >>>> This is my KVM switch with its USB keyboard and mouse. When I unplug >>>> this USB cable, this message does not appear while running "usb reset". >>>> >>>> This also happen, when I only plug a USB mouse to this same USB >>>> port: >>>> >>>> => usb reset >>>> resetting USB... >>>> USB0: Register 7000820 NbrPorts 7 >>>> Starting the controller >>>> USB XHCI 1.00 >>>> scanning bus 0 for devices... USB device descriptor short read (expected >>>> 18, got 8) >>>> 5 USB Device(s) found >>>> scanning usb for storage devices... 2 Storage Device(s) found >>>> => usb tree >>>> USB device tree: >>>> 1 Hub (5 Gb/s, 0mA) >>>> | U-Boot XHCI Host Controller >>>> | >>>> +-2 Mass Storage (480 Mb/s, 98mA) >>>> | USBest Technology USB Mass Storage Device 09092207fbf0c4 >>>> | >>>> +-3 Hub (480 Mb/s, 2mA) >>>> | | >>>> | +-5 Mass Storage (480 Mb/s, 200mA) >>>> | JetFlash Mass Storage Device 3281440601 >>>> | >>>> +-4 Vendor specific (5 Gb/s, 64mA) >>>> Realtek USB 10/100/1000 LAN 000002000000 >>>> >>>> >>>> $ lsusb -t >>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M >>>> |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, >>>> 5000M >>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M >>>> |__ Port 2: Dev 2, If 0, Class=Human Interface Device, >>>> Driver=usbhid, 12M >>>> |__ Port 2: Dev 2, If 1, Class=Human Interface Device, >>>> Driver=usbhid, 12M >>>> |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, >>>> 480M >>>> |__ Port 5: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M >>>> |__ Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, >>>> 480M >>>> >>>> >>>> Can you reproduce this on your MinnowMax? Would it help, if I >>>> would enable some traces (-DDEBUG)? >>> >>> >>> I cannot reproduce this on MinnowMax. Is the KVM switch a USB 2.0 or >>> 3.0 hub? >> >> >> USB 2.0, its a pretty old device. But the example above is without the >> KVM and only with the USB mouse. >> >>> Is it possible to switch BayTrail SoC to EHCI and do the same >>> testing? >> >> >> Sure. After disabling CONFIG_USB_XHCI_HC I now get this error: >> >> => usb reset >> resetting USB... >> USB0: USB EHCI 1.00 >> scanning bus 0 for devices... Divide Error >> EIP: 0010:[<7b587862>] EFLAGS: 00010246 >> Original EIP :[] >> EAX: 00000040 EBX: 7b35db00 ECX: 00000380 EDX: 00000000 >> ESI: 7b33af40 EDI: 7b33aa00 EBP: 7b35a640 ESP: 7b33a990 >> DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018 >> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000600 >> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 >> DR6: ffff0ff0 DR7: 00000400 >> Stack: >> 0x7b33a9d0 : 0x7b35dac0 >> 0x7b33a9cc : 0x7b33af40 >> 0x7b33a9c8 : 0x00000100 >> 0x7b33a9c4 : 0x7b33ac80 >> 0x7b33a9c0 : 0x00000001 >> 0x7b33a9bc : 0x7b33ac80 >> 0x7b33a9b8 : 0x7b35a680 >> 0x7b33a9b4 : 0x00000000 >> 0x7b33a9b0 : 0x00000040 >> 0x7b33a9ac : 0x80000080 >> 0x7b33a9a8 : 0x7b35db00 >> 0x7b33a9a4 : 0x00000040 >> 0x7b33a9a0 : 0x00000002 >> 0x7b33a99c : 0x7b35dac0 >> 0x7b33a998 : 0x1616cae2 >> 0x7b33a994 : 0xc8159ec7 >> --->0x7b33a990 : 0xc1b7c2b0 >> 0x7b33a98c : 0x00010246 >> 0x7b33a988 : 0x00000010 >> 0x7b33a984 : 0x7b587862 >> ### ERROR ### Please RESET the board ### >> >> EHCI worked before just fine. Does this (EHCI) work on your >> MinnoxMax? > > I've reproduced the EHCI crash issue. Looks the crash happens in > ehci_submit_async(). However my patches did not touch this function. I > will debug this. It turns out this patch breaks EHCI. http://patchwork.ozlabs.org/patch/779917/ Regards, Bin