Hi Peter, > 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
Could you point me to any "Errata" document describing this issue? Could you elaborate on it a bit more? > that low speed device may have issue > that i.mx6 PHY's power is not ready before controller goes to > initialize, Please correct my understanding if I'm wrong - the issue here is with USB PHY. When low-speed device is connected, the USB PHY may be not properly powered, but the USB controller is ready for serving the transmission. > so for i.mx6, we should not use PORT_PP for PHY's power. In our design we do control (with some dedicated USB VBUS switch IC) the VBUS power with USB_H1_PWR# pin PAD_EIM_D31, which indeed is the output controlled by PORTSC1's bit 12 (PP). One more strange thing, which I've observed - the bit 4 (OCA) from PORTSC1 goes high during the operation - no matter if we succeed or no with the USB enumeration: IMX6#0>mdahb 0x02184384 1 AHB/AXI 00_02184384 : 14001415 It indicates that we do have an "over-current" condition, but the touchscreen IC's MAX current consumption is 18 mA, and the port can provide 100 mA. The touchscreen IC is the only device connected to USB Host1. > See flag: CI_HDRC_TURN_VBUS_EARLY_ON for detail. This flag enables very early the VBUS power. I do use standard settings here (the flag is set). > At i.mx6, the VBUS > 5v is the power for USB PHY. So the VBUS is at iMX6q also the power for USB PHY? In our design we do use VBUS to power the sensor. How can I workaround this issue? Can it be done in SW (to avoid changing the PCB routing)? Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de -- 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
