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: 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
