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 = <&gpio3 31 GPIO_ACTIVE_LOW>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usbh1_vbus>; regulator-name = "usb_h1_vbus"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; regulator-enable-ramp-delay = <300000>; }; &usbh1 { 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: wd@xxxxxxx -- 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
