On Wed, Dec 15, 2021 at 06:45:32PM +0300, Dmitry Osipenko wrote: > 15.12.2021 18:16, Thierry Reding пишет: > > On Wed, Dec 15, 2021 at 06:04:54PM +0300, Dmitry Osipenko wrote: > >> 15.12.2021 16:14, Thierry Reding пишет: > >>> On Sun, Dec 12, 2021 at 12:13:59AM +0300, Dmitry Osipenko wrote: > >>>> From: Stefan Eichenberger <stefan.eichenberger@xxxxxxxxxxx> > >>>> > >>>> If an USB port is an OTG port, then we should add the usb-role-switch > >>>> property. Otherwise XUSB setup fails and therefore padctl is unable to > >>>> set up the ports. This leads to broken USB and PCIe ports. Add the > >>>> usb-role-switch properties to Tegra124 device-trees to fix the problem. > >>>> > >>>> The error message shown without this patch is e.g: > >>>> usb2-0: usb-role-switch not found for otg mode > >>>> > >>>> [digetx@xxxxxxxxx: improved commit message] > >>>> Tested-by: Thomas Graichen <thomas.graichen@xxxxxxxxx> # T124 Nyan Big > >>>> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@xxxxxxxxxxx> > >>>> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx> > >>>> --- > >>>> arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi | 1 + > >>>> arch/arm/boot/dts/tegra124-apalis.dtsi | 1 + > >>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 1 + > >>>> arch/arm/boot/dts/tegra124-venice2.dts | 2 +- > >>>> 4 files changed, 4 insertions(+), 1 deletion(-) > >>> > >>> The device tree bindings for the XUSB pad controller say that when this > >>> property is set, then the "connector" subnode should also exist. > >>> > >>> Any chance we can add that? I was planning on making that a dependency > >>> in the json-schema conversion of the binding, in which case it would be > >>> more of a "must" than a "should". > >> > >> I guess it will be harmless if you'll add the connector subnodes. Will > >> you be able to create a separate patch that will add the subnodes on top > >> of this patch? > >> > >> Thomas Graichen says that one USB port on Nyan Big doesn't work without > >> this patch. This is why this patch is needed essentially. > > > > Okay, I can add "dummy" connector nodes for now. I don't see how we can > > properly set this up because as far as I can tell there's USB ID GPIO on > > Tegra124 (seems like it's a fixed function pin) and the VBUS GPIO is > > already used to enable the VBUS supply. The gpio-usb-b-connector binding > > required at least one of the ID and VBUS GPIOs to be specified. > > The ID and VBUS hardware configurations are very board-specific. There > are multiple ways of how it could implemented on Tegra. > > > On the other hand, at least Venice2 has a USB type A connector for this, > > so I'm not even sure how that would work. I vaguely recall that the > > Tegra20 Seaboard also had a USB type A and that it was possible to use > > it in device mode, but I don't how that would. Nor would it be correct > > to use the gpio-usb-b-connector compatible for that since, well, it's > > not USB type B. > > I'm not sure whether it makes much sense to use OTG for USB type A > connectors, normally they should be fixed to host mode. My recollection is that those can be used in device mode as well. For example that USB type A port on Venice2 (same as for Seaboard) can be used for RCM, IIRC. It's possible that there's no way to detect what is connected, though, so this may not be proper OTG. > > > I suspect that Apalis has a micro-B port, much like the Jetson TK1. My > > understanding is that OTG doesn't work on Jetson TK1 (which is why it's > > configured in "host" mode), so it'd be interesting to see if this can be > > made to work on Apalis. > > Looks like the default Apalis carrier board has three type A connectors. > > https://www.toradex.com/products/carrier-board/ixora-carrier-board I'm wondering if the best thing would be to mark all of these as "host" for now and avoid making this look like something that it isn't. I don't think we've ever made OTG work on these boards, so perhaps we shouldn't assume that it works. Thierry
Attachment:
signature.asc
Description: PGP signature
