Re: [iMX6Q][CI] EHCI Low-speed device problem
On Thu, Oct 19, 2017 at 10:25:13AM +0200, Lukasz Majewski wrote:
> Hi Peter,
>
> > On Thu, Oct 19, 2017 at 07:47:01AM +0200, Lukasz Majewski wrote:
> > > > > 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?
> > >
> >
> > No, it assumes PHY's power is prior to controller's initialization.
>
> Is there any particular time necessary?
I don't know, this info should from IC team, but I think 1ms is enough.
> > > > 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).
> >
> > Please configure PAD_EIM_D31 as GPIO instead of USB_PWR_EN.
>
> pinctrl_usbh1_vbus: usbh1_vbus_grp {
> fsl,pins = <
> MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
> >;
> };
>
> It did not help.
>
> I've also setup the regulator API to enable VBUS and then wait ~300ms
> with stable power before we proceed with USB Host further
> initialization.
>
> reg_usbh1_vbus: usb-h1-vbus {
> compatible = "regulator-fixed";
> gpio = < 31 GPIO_ACTIVE_LOW>;
Are you really sure it is ACTIVE_LOW?
> pinctrl-names = "default";
> pinctrl-0 = <_usbh1_vbus>;
> regulator-name = "usb_h1_vbus";
> regulator-min-microvolt = <500>;
> regulator-max-microvolt = <500>;
> regulator-enable-ramp-delay = <30>;
> };
>
> {
> vbus-supply = <_usbh1_vbus>;
> }
>
> > One of USBOTG1_VBUS and USBH1_VBUS can be both USB PHY's power.
> > Usually, it doesn't matter the VBUS powers USB peripheral unless
> > the peripheral really consumes too much current, eg > 500mA, it
> > may have problem, I am not sure, I am not hardware guy.
> >
>
> Could you look into the picture attached to the earlier e-mail and
> comment on Alan's reply (especially about the lack of error indication
> fo XactErr)?
>
>
Please double confirm the VBUS supplies to SoC USB_OTG_VBUS or
USB_H1_VBUS before EHCI goes to initialization. Meanwhile, you can
try to clear USB_LDO current_ilimit bit (0x20c8120, bit 2).
For EHCI error, it is strange, I can't explain.
For hardware (or IC) support, you can consult your FAE.
--
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: [iMX6Q][CI] EHCI Low-speed device problem
Hi Alan, > On Thu, 19 Oct 2017, Lukasz Majewski wrote: > > > > > 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] > > According to the screen dump, the device sent a DATA1 packet which > the host controller did not ACK. That's a bug in the host > controller. In the next transaction, the device sent an empty DATA1 > packet instead of resending the previous data. That's a bug in the > device. > Ok. So then we do have HW issues in both sides :-). Nice... > > > 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 > > That part is normal. Ok. > > > 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? > > Not in general. For this one particular case (a short transfer for a > Get-Configuration-Descriptor request), it would be easy enough to > retry the transfer. Just put a short retry loop around the second > usb_get_descriptor() call in usb_get_configuration() in > drivers/usb/core/config.c. But similar failures at other times would > be harder to recover from. This only one case. Those errors happens also at other parts of the enumeration phase -> very often also the "Get Report Descriptor" (178 bytes in size) is truncated. This is more severe, since those errors are propagated up the USB stack and exceed the "rule of thumb" of 4 retries set by Linus back at 2005 I'm now trying to force the code from ./usb/host/ehci-q.c qh_completions() to re-execute retry_xacterr. Unfortunately, it would be hard since CI Host Controller do not set "Halt" token status (bit 6) and some extra hacks are needed. @ Fabio, Peter, is there anybody from NXP, who can I contact to get some info regarding the way this IP block works (some IP block designer/ RTL implementor)? Maybe, I could get some hints on how to look for "reserved" registers? Or alleviating the HW problem on the CI HCI side? > > 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 Anyway, many thanks for clarification. 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
Re: [iMX6Q][CI] EHCI Low-speed device problem
On Thu, 19 Oct 2017, Lukasz Majewski wrote: > > > 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] According to the screen dump, the device sent a DATA1 packet which the host controller did not ACK. That's a bug in the host controller. In the next transaction, the device sent an empty DATA1 packet instead of resending the previous data. That's a bug in the device. > > 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 That part is normal. > 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? Not in general. For this one particular case (a short transfer for a Get-Configuration-Descriptor request), it would be easy enough to retry the transfer. Just put a short retry loop around the second usb_get_descriptor() call in usb_get_configuration() in drivers/usb/core/config.c. But similar failures at other times would be harder to recover from. 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: [iMX6Q][CI] EHCI Low-speed device problem
Hi Peter,
> On Thu, Oct 19, 2017 at 07:47:01AM +0200, Lukasz Majewski wrote:
> > > > 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?
> >
>
> No, it assumes PHY's power is prior to controller's initialization.
Is there any particular time necessary?
>
> > > 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.
>
> Yes.
>
> >
> > > 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).
>
> Please configure PAD_EIM_D31 as GPIO instead of USB_PWR_EN.
pinctrl_usbh1_vbus: usbh1_vbus_grp {
fsl,pins = <
MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
>;
};
It did not help.
I've also setup the regulator API to enable VBUS and then wait ~300ms
with stable power before we proceed with USB Host further
initialization.
reg_usbh1_vbus: usb-h1-vbus {
compatible = "regulator-fixed";
gpio = < 31 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_usbh1_vbus>;
regulator-name = "usb_h1_vbus";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-enable-ramp-delay = <30>;
};
{
vbus-supply = <_usbh1_vbus>;
}
The ~300ms is from touchscreen datasheet - time needed for
initialization.
However, with EHCI from Samsung/Intel I don't need such time to have
touchscreen properly enumerated.
> >
> > 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.
>
> Please check if pinctrl and polarity of OC pin are correct.
The OC on the PCB is active low (and it is externally pullup'ed with
10k resistor).
>
> >
> > > 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).
> >
>
> You need to enable VBUS power early really, that means using GPIO to
> control it instead of USB PIN. See imx6qdl-sabresd as an example.
OK. This is already done (I checked that the CI_HDRC_TURN_VBUS_EARLY_ON
is enabled and USB_PWR_EN is configured as GPIO).
>
> > > 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)?
> >
>
> One of USBOTG1_VBUS and USBH1_VBUS can be both USB PHY's power.
> Usually, it doesn't matter the VBUS powers USB peripheral unless
> the peripheral really consumes too much current, eg > 500mA, it
> may have problem, I am not sure, I am not hardware guy.
>
Could you look into the picture attached to the earlier e-mail and
comment on Alan's reply (especially about the lack of error indication
fo XactErr)?
Thanks in advance,
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
Re: [iMX6Q][CI] EHCI Low-speed device problem
On Thu, Oct 19, 2017 at 07:47:01AM +0200, Lukasz Majewski wrote: > > > 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? > No, it assumes PHY's power is prior to controller's initialization. > > 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. Yes. > > > 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). Please configure PAD_EIM_D31 as GPIO instead of USB_PWR_EN. > > 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. Please check if pinctrl and polarity of OC pin are correct. > > > 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). > You need to enable VBUS power early really, that means using GPIO to control it instead of USB PIN. See imx6qdl-sabresd as an example. > > 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)? > One of USBOTG1_VBUS and USBH1_VBUS can be both USB PHY's power. Usually, it doesn't matter the VBUS powers USB peripheral unless the peripheral really consumes too much current, eg > 500mA, it may have problem, I am not sure, I am not hardware guy. -- 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: [iMX6Q][CI] EHCI Low-speed device problem
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 0x8e00 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 0x8e00 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 > >
Re: [iMX6Q][CI] EHCI Low-speed device problem
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 0x8e00 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 0x8e00 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
Re: [iMX6Q][CI] EHCI Low-speed device problem
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 0x8e00 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 0x8e00 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
