On Wed, 18 Oct 2017, Lukasz Majewski wrote: > Dear All, > > I'm using iMX6q for my application. It uses the touchscreen IC > connected via USB port (Host port 1). The touchscreen operates with > low-speed. I don't know anything about the iMX6q specifically... > Board: Wandboard rev1b / some custom board > SW: Mainline Linux 4.13 > > Problem: > > I do observe that the USB transfers are truncated - for example > "Get Configuration Descriptor", which length is 34B only gets 16B from > the device. > > I do get the "Invalid PID sequence" error and despite the How do you know the error is "Invalid PID sequence" and not something else, like CRC error or timeout? > DATA1 Packet received by host - the EHCI controller is not sending ACK. The DATA1 packets are the ones containing bytes 9-16, 25-32, and so on (low speed always uses maxpacket size = 8). Since you received 16 bytes, this means the host controller accepted the DATA1 packet but didn't send an ACK -- that certainly would be a hardware bug. Anyway, this should have caused the device to retransmit the DATA1 packet in response to the next IN packet (if there was one). > The problem is not observed when I plug the touchscreen device via USB > 2.0 HUB. (iMX6q -> USB 2.0 HUB -> touchscreen) > > Also, the problem is not present on different EHCI implementations - > namely Intel or Synopsis (Exynos 5422). > > > Please find below some data dump from EHCI's qTD (Queue Element > Transfer Descriptor): > > [ 1.987479] ci_hdrc ci_hdrc.0: submit_async 1 urb edfe6e80 ep0out > len 178, qtd ef061180 [qh edfe6780] > [ 1.988781] ehci urb: IRQ status: 0x1 INTREN: 0x37 hrt: 0x80 > [ 1.988795] scan_async: urb qh: 0xedfe6780 qtd_list: 0xef0610f8 > [ 1.988802] qh_completions: urb token 0x80000e00 0 178 This is the Setup transaction, which completed normally. > [ 1.988809] qh_completions: urb token 0x920d08 0 178 > ^--- here we do have still > active "status" 9x8 No, 0x08 in the low-order bits is XactErr. Active would be 0x80. Notice, however, that the CErr field was not decremented. According to the EHCI spec, that should not happen. Another hardware bug? Notice that the Halted bit was not set. This means the hardware thinks the transaction completed successfully. > [ 1.988815] qh_completions: urb token 0x8c00 32 178 > ^--- here the IOC bit is > set (0x8) > [ 1.988828] ci_hdrc ci_hdrc.0: ehci_urb_done 1 urb edfe6e80 > ep0in status 0 len 32/178 > > The above code is executed after receiving "USBINT" interrupt - > according to EHCI controller everything went fine > > > [ 1.992192] ci_hdrc ci_hdrc.0: submit_async 1 urb edfe6e80 ep0out > len 178, qtd ef061060 [qh edfe6780] > [ 1.995785] ehci urb: IRQ status: 0x1 INTREN: 0x37 hrt: 0x80 > [ 1.995804] scan_async: urb qh: 0xedfe6780 qtd_list: 0xef0611b8 > [ 1.995811] qh_completions: urb token 0x80000e00 0 178 > ^--- setup transaction > [ 1.995819] qh_completions: urb token 0xd00 0 178 > ^--- here we do have 0x0 status > [ 1.995825] qh_completions: urb token 0x8c00 178 178 > ^--- here we do ask for > interrupt when done > [ 1.995840] ci_hdrc ci_hdrc.0: ehci_urb_done 1 urb edfe6e80 > ep0in status 0 len 178/178 > > > The most _strange_ issue here is the lack of _any_ error indicated by > the HOST driver. All transmissions end with USBINT set. No error > interrupt present. This corrupted data (with smaller size than > expected) is then passed to upper layers, causing subtle errors. The host controller driver doesn't report an error because the Halted status bit isn't set. XactErr by itself isn't a fatal error; it means that something went wrong but then the transaction was retried. > Have anybody had similar problem? > > Any hints on how to proceed? It does sound like a hardware bug. But you should get more information from people who know more about iMX6q. > The problem has been described in detail (including screen shots > from USB analyzer + some further investigations) here: > https://community.nxp.com/thread/462409 I didn't see any screen shots or further investigations on that web page. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
