On Thu, Oct 19, 2017 at 01:38:45AM +0200, Lukasz Majewski wrote: > Hi Alan, > > Thank you for you reply. > > > 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... > > But you do know a lot about EHCI/USB.... :) > > > > > > 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? > > I'm using TotalPhase USB 480 Analyzer. It shows only "Invalid PID > sequence" as the error. When I "unroll" the GetConfigurationDescriptor, > then all data is the same as for correct transmission. > > > > > > 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. > > I do receive 16B, but those are "comprised" of two separate IN > transactions (8 B each). > One such transaction is built with SETUP -> DATA1 -> ACK packets. > > [Please see the attached screen] > > > Anyway, > > this should have caused the device to retransmit the DATA1 packet in > > response to the next IN packet (if there was one). > > There is IN packet sent afterwards, but it is empty. The whole > GetConfigurationDescriptor ends with OUT ZLP.... > > > > > > 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. > > Ach... right. > > > Notice, however, that the CErr field was not decremented. According > > to the EHCI spec, that should not happen. Another hardware bug? > > Good point. > > > > > Notice that the Halted bit was not set. This means the hardware > > thinks the transaction completed successfully. > > Unfortunately, it does. It behaves like everything went correct and > pases truncated data up to the stack. > > > > > > [ 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. > > No retry from the touchscreen IC. > > It seems like we do have HW bugs on both sides.... (EHCI ChipIdea > Implementation and the touchscreen IC - ssd2533) > > > > > > 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. > > I hope that the NXP community will respond promptly. > > I'm wondering if it is feasible to manually check the XactErr bit and > then for example order the soft USB reset (from the root hub)? > > Or is there any other acceptable in upstream solution? > > > > > > The problem has been described in detail (including screen shots > > > from USB analyzer + some further investigations) here: > > > https://community.nxp.com/thread/462409 > > Lukasz, there is a known issue that low speed device may have issue that i.mx6 PHY's power is not ready before controller goes to initialize, so for i.mx6, we should not use PORT_PP for PHY's power. See flag: CI_HDRC_TURN_VBUS_EARLY_ON for detail. At i.mx6, the VBUS 5v is the power for USB PHY. -- Best Regards, Peter Chen -- 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
