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