Message ID | 20211211211412.10791-1-digetx@gmail.com |
---|---|
Headers | show |
Series | NVIDIA Tegra ARM32 device-tree patches for 5.17 (new devices and more) | expand |
On Sun, Dec 12, 2021 at 12:13:59AM +0300, Dmitry Osipenko wrote: > From: Stefan Eichenberger <stefan.eichenberger@toradex.com> > > 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@gmail.com: improved commit message] > Tested-by: Thomas Graichen <thomas.graichen@gmail.com> # T124 Nyan Big > Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > 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". Thierry
On Sun, Dec 12, 2021 at 12:13:52AM +0300, Dmitry Osipenko wrote: [...] > + display-panel { > + compatible = "hannstar,hsd101pww2"; There doesn't seem to be a DT binding for this and I can't find any patches where this would be added. Is there a patch somewhere to do this? Thierry
On Sun, Dec 12, 2021 at 12:13:55AM +0300, Dmitry Osipenko wrote: [...] > + i2c@1 { > + reg = <1>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + dsi-bridge@7 { > + compatible = "toshiba,tc358768"; > + reg = <0x7>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + clocks = <&tc358768_osc>; > + clock-names = "refclk"; > + > + reset-gpios = <&gpio TEGRA_GPIO(N, 6) GPIO_ACTIVE_LOW>; > + > + vddc-supply = <&vdd_1v2_mipi>; > + vddio-supply = <&vdd_1v8_vio>; > + vddmipi-supply = <&vdd_1v2_mipi>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + > + bridge_input: endpoint { > + remote-endpoint = <&dpi_output>; > + data-lines = <24>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + > + bridge_output: endpoint { > + remote-endpoint = <&panel_input>; > + }; > + }; > + }; > + > + /* > + * Panasonic VVX10F004B00 or HYDIS HV101WU1-1E1 > + * LCD SuperIPS+ Full HD panel. > + */ > + panel@1 { > + compatible = "panasonic,vvx10f004b00"; > + reg = <1>; > + > + power-supply = <&vdd_pnl>; > + backlight = <&backlight>; > + > + port { > + panel_input: endpoint { > + remote-endpoint = <&bridge_output>; > + }; > + }; > + }; make dtbs_check complains about this and says that panel@1 (as well as #address-cells and #size-cells) are not allowed here. And indeed the binding for the Toshiba bridge doesn't mention them here. Do we need this here or should this be moved to the top level to fix those warnings? I guess what you're doing above is describe a DSI bus created by the DSI bridge, which also makes sense, so another alternative would be to fix up the binding and let it accept those properties. Thierry
15.12.2021 16:28, Thierry Reding пишет: > On Sun, Dec 12, 2021 at 12:13:52AM +0300, Dmitry Osipenko wrote: > [...] >> + display-panel { >> + compatible = "hannstar,hsd101pww2"; > > There doesn't seem to be a DT binding for this and I can't find any > patches where this would be added. Is there a patch somewhere to do > this? Are you trolling me? :/ Please search the "Tegra kernel patches for 5.17" email in your inbox, it must be there. Please read and answer to it. All patches are in the Tegra patchwork. Who marked them "Not Applicable"? https://patchwork.ozlabs.org/project/linux-tegra/patch/20211211213653.17700-3-digetx@gmail.com/ https://patchwork.ozlabs.org/project/linux-tegra/list/?series=276358
15.12.2021 17:01, Thierry Reding пишет: > On Sun, Dec 12, 2021 at 12:13:55AM +0300, Dmitry Osipenko wrote: > [...] >> + i2c@1 { >> + reg = <1>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + dsi-bridge@7 { >> + compatible = "toshiba,tc358768"; >> + reg = <0x7>; >> + >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + clocks = <&tc358768_osc>; >> + clock-names = "refclk"; >> + >> + reset-gpios = <&gpio TEGRA_GPIO(N, 6) GPIO_ACTIVE_LOW>; >> + >> + vddc-supply = <&vdd_1v2_mipi>; >> + vddio-supply = <&vdd_1v8_vio>; >> + vddmipi-supply = <&vdd_1v2_mipi>; >> + >> + ports { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + port@0 { >> + reg = <0>; >> + >> + bridge_input: endpoint { >> + remote-endpoint = <&dpi_output>; >> + data-lines = <24>; >> + }; >> + }; >> + >> + port@1 { >> + reg = <1>; >> + >> + bridge_output: endpoint { >> + remote-endpoint = <&panel_input>; >> + }; >> + }; >> + }; >> + >> + /* >> + * Panasonic VVX10F004B00 or HYDIS HV101WU1-1E1 >> + * LCD SuperIPS+ Full HD panel. >> + */ >> + panel@1 { >> + compatible = "panasonic,vvx10f004b00"; >> + reg = <1>; >> + >> + power-supply = <&vdd_pnl>; >> + backlight = <&backlight>; >> + >> + port { >> + panel_input: endpoint { >> + remote-endpoint = <&bridge_output>; >> + }; >> + }; >> + }; > > make dtbs_check complains about this and says that panel@1 (as well as > #address-cells and #size-cells) are not allowed here. And indeed the > binding for the Toshiba bridge doesn't mention them here. > > Do we need this here or should this be moved to the top level to fix > those warnings? I guess what you're doing above is describe a DSI bus > created by the DSI bridge, which also makes sense, so another > alternative would be to fix up the binding and let it accept those > properties. Toshiba bridge binding is incomplete. David has patch for that [1], I don't think that it was sent out yet. [1] https://github.com/okias/linux/commit/0875230062294b6db17f395ced0a8384a4c1cfc7
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@toradex.com> >> >> 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@gmail.com: improved commit message] >> Tested-by: Thomas Graichen <thomas.graichen@gmail.com> # T124 Nyan Big >> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >> --- >> 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.
On Wed, Dec 15, 2021 at 05:19:09PM +0300, Dmitry Osipenko wrote: > 15.12.2021 16:28, Thierry Reding пишет: > > On Sun, Dec 12, 2021 at 12:13:52AM +0300, Dmitry Osipenko wrote: > > [...] > >> + display-panel { > >> + compatible = "hannstar,hsd101pww2"; > > > > There doesn't seem to be a DT binding for this and I can't find any > > patches where this would be added. Is there a patch somewhere to do > > this? > > Are you trolling me? :/ Please search the "Tegra kernel patches for > 5.17" email in your inbox, it must be there. Please read and answer to it. Hmm... I searched for this in my inbox and couldn't find it. Odd. > All patches are in the Tegra patchwork. Who marked them "Not Applicable"? > > https://patchwork.ozlabs.org/project/linux-tegra/patch/20211211213653.17700-3-digetx@gmail.com/ > > https://patchwork.ozlabs.org/project/linux-tegra/list/?series=276358 I will regularly go over patchwork and mark things "Not Applicable" if they don't go in via the Tegra tree. These would have to go in via DRM and so are not relevant on the linux-tegra patchwork instance. Thierry
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@toradex.com> > >> > >> 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@gmail.com: improved commit message] > >> Tested-by: Thomas Graichen <thomas.graichen@gmail.com> # T124 Nyan Big > >> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> > >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > >> --- > >> 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. 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 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. Thierry
On Wed, Dec 15, 2021 at 05:52:24PM +0300, Dmitry Osipenko wrote: > 15.12.2021 17:01, Thierry Reding пишет: > > On Sun, Dec 12, 2021 at 12:13:55AM +0300, Dmitry Osipenko wrote: > > [...] > >> + i2c@1 { > >> + reg = <1>; > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + dsi-bridge@7 { > >> + compatible = "toshiba,tc358768"; > >> + reg = <0x7>; > >> + > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + clocks = <&tc358768_osc>; > >> + clock-names = "refclk"; > >> + > >> + reset-gpios = <&gpio TEGRA_GPIO(N, 6) GPIO_ACTIVE_LOW>; > >> + > >> + vddc-supply = <&vdd_1v2_mipi>; > >> + vddio-supply = <&vdd_1v8_vio>; > >> + vddmipi-supply = <&vdd_1v2_mipi>; > >> + > >> + ports { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + port@0 { > >> + reg = <0>; > >> + > >> + bridge_input: endpoint { > >> + remote-endpoint = <&dpi_output>; > >> + data-lines = <24>; > >> + }; > >> + }; > >> + > >> + port@1 { > >> + reg = <1>; > >> + > >> + bridge_output: endpoint { > >> + remote-endpoint = <&panel_input>; > >> + }; > >> + }; > >> + }; > >> + > >> + /* > >> + * Panasonic VVX10F004B00 or HYDIS HV101WU1-1E1 > >> + * LCD SuperIPS+ Full HD panel. > >> + */ > >> + panel@1 { > >> + compatible = "panasonic,vvx10f004b00"; > >> + reg = <1>; > >> + > >> + power-supply = <&vdd_pnl>; > >> + backlight = <&backlight>; > >> + > >> + port { > >> + panel_input: endpoint { > >> + remote-endpoint = <&bridge_output>; > >> + }; > >> + }; > >> + }; > > > > make dtbs_check complains about this and says that panel@1 (as well as > > #address-cells and #size-cells) are not allowed here. And indeed the > > binding for the Toshiba bridge doesn't mention them here. > > > > Do we need this here or should this be moved to the top level to fix > > those warnings? I guess what you're doing above is describe a DSI bus > > created by the DSI bridge, which also makes sense, so another > > alternative would be to fix up the binding and let it accept those > > properties. > > Toshiba bridge binding is incomplete. David has patch for that [1], I > don't think that it was sent out yet. > > [1] > https://github.com/okias/linux/commit/0875230062294b6db17f395ced0a8384a4c1cfc7 Okay, please make sure this finds its way upstream eventually. That patch looks quite similar to what I tried to do to fix this up locally. Thierry
Hello Dmitry and Thierry! Sent as "[PATCH] dt-bindings: display: bridge: document Toshiba TC358768 cells and panel node", I'll try to not keep these patches for myself for so long. David On Wed, Dec 15 2021 at 16:19:19 +0100, Thierry Reding <thierry.reding@gmail.com> wrote: > On Wed, Dec 15, 2021 at 05:52:24PM +0300, Dmitry Osipenko wrote: >> 15.12.2021 17:01, Thierry Reding пишет: >> > On Sun, Dec 12, 2021 at 12:13:55AM +0300, Dmitry Osipenko wrote: >> > [...] >> >> + i2c@1 { >> >> + reg = <1>; >> >> + #address-cells = <1>; >> >> + #size-cells = <0>; >> >> + >> >> + dsi-bridge@7 { >> >> + compatible = "toshiba,tc358768"; >> >> + reg = <0x7>; >> >> + >> >> + #address-cells = <1>; >> >> + #size-cells = <0>; >> >> + >> >> + clocks = <&tc358768_osc>; >> >> + clock-names = "refclk"; >> >> + >> >> + reset-gpios = <&gpio TEGRA_GPIO(N, 6) GPIO_ACTIVE_LOW>; >> >> + >> >> + vddc-supply = <&vdd_1v2_mipi>; >> >> + vddio-supply = <&vdd_1v8_vio>; >> >> + vddmipi-supply = <&vdd_1v2_mipi>; >> >> + >> >> + ports { >> >> + #address-cells = <1>; >> >> + #size-cells = <0>; >> >> + >> >> + port@0 { >> >> + reg = <0>; >> >> + >> >> + bridge_input: endpoint { >> >> + remote-endpoint = <&dpi_output>; >> >> + data-lines = <24>; >> >> + }; >> >> + }; >> >> + >> >> + port@1 { >> >> + reg = <1>; >> >> + >> >> + bridge_output: endpoint { >> >> + remote-endpoint = <&panel_input>; >> >> + }; >> >> + }; >> >> + }; >> >> + >> >> + /* >> >> + * Panasonic VVX10F004B00 or HYDIS HV101WU1-1E1 >> >> + * LCD SuperIPS+ Full HD panel. >> >> + */ >> >> + panel@1 { >> >> + compatible = "panasonic,vvx10f004b00"; >> >> + reg = <1>; >> >> + >> >> + power-supply = <&vdd_pnl>; >> >> + backlight = <&backlight>; >> >> + >> >> + port { >> >> + panel_input: endpoint { >> >> + remote-endpoint = <&bridge_output>; >> >> + }; >> >> + }; >> >> + }; >> > >> > make dtbs_check complains about this and says that panel@1 (as >> well as >> > #address-cells and #size-cells) are not allowed here. And indeed >> the >> > binding for the Toshiba bridge doesn't mention them here. >> > >> > Do we need this here or should this be moved to the top level to >> fix >> > those warnings? I guess what you're doing above is describe a DSI >> bus >> > created by the DSI bridge, which also makes sense, so another >> > alternative would be to fix up the binding and let it accept those >> > properties. >> >> Toshiba bridge binding is incomplete. David has patch for that [1], >> I >> don't think that it was sent out yet. >> >> [1] >> >> https://github.com/okias/linux/commit/0875230062294b6db17f395ced0a8384a4c1cfc7 > > Okay, please make sure this finds its way upstream eventually. That > patch looks quite similar to what I tried to do to fix this up > locally. > > Thierry
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@toradex.com> >>>> >>>> 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@gmail.com: improved commit message] >>>> Tested-by: Thomas Graichen <thomas.graichen@gmail.com> # T124 Nyan Big >>>> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> >>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>> --- >>>> 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
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@toradex.com> > >>>> > >>>> 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@gmail.com: improved commit message] > >>>> Tested-by: Thomas Graichen <thomas.graichen@gmail.com> # T124 Nyan Big > >>>> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> > >>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > >>>> --- > >>>> 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
15.12.2021 18:52, Thierry Reding пишет: >>> 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. Sounds correct. >>> 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. Marking them "host" should be correct, but that wasn't tested. I assume that those "OTG" ports may default to the host mode.