| 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.
In this patchset you will find: - New device-trees of ASUS Transformer and Pegatron Chagall tablets. - New device-tree of Nyan Big Chromebook variant that has 1080p display panel. - Enabled video decoder on Tegra114. - Minor cleanup of Nexus7 device-tree. - Renamed clocks and regulator nodes. - Fixes for T124 device-trees. Changelog: v6: - Added my s-o-b to all patches. - Separated clk/regulator nodes renaming patch and gave Thierry Reding credit for that. - Borrowed "ARM: tegra: Add #reset-cells for Tegra114 MC" patch from Thierry to resolve merge conflict with the video decoder patch. - Added old patch from Stefan Agner that enables gpio-ranges, it was brought up in the other DT thread. I borrowed "ARM: tegra: Remove stray #reset-cells property" patch from Thierry to resolve merge conflict of these patches. - Reordered all DT nodes alphabetically. - Enabled couple more options in tegra_defconfig needed by Nyan Chromebook, as was requested by Thomas Graichen. - Improved thermal zones of TF101, making them to match what latest DT of Acer A500 uses. Previous versions used older variant of the A500 zones. v5: - Minor update. Maxim improved commit messages. We added links to the postmarketOS Wiki. v4: - Factored out common parts of ASUS device-trees into separate patches. I retained the original author of the tegra30-asus-transformer-common.dtsi after chatting with Svyatoslav. Initially I wanted to change the authorship to Michał, but not that much left from the original DT that was created by Michał, so it's fair to keep Svyatoslav the author. I explained in the commit message that the common DT was derived from the Michał's TF300T DT and then reworked heavily, I also added Michał as co-developer of the common part. - Added new T124 patches that were requested by Thomas Graichen. They restore USB, CPUFreq and fix overheating of Nyan Chromebooks. - Added patches that update tegra_defconfig and multi_v7_defconfig with enabled drivers used by ASUS Transformers and Nyan Chromebooks. - Added acks that were given by Rob Herring to v3. - Changed display panel compatible of ASUS TF701T like it was suggested by Rob Herring in other thread. - Removed yet unused SDMMC1 pinmux from TF701T DT as was requested by Anton Bambura. - Added patch which adds node labels to T30 DTSI. It eases porting devices to upstream. This was requested by Michał Mirosław. v3: - Maxim added couple "FIXME" comments to Transformer device-trees for things that are yet missing on kernel side, and thus, can't be enabled in the DT for now. - Maxim also found that v2 had a small problem in the patch which adds device-tree for Chagall tablet. Turned out I made a mistake during rebase of the patches and haven't noticed it, it's fixed now. v2: - Svyatoslav and Maxim made couple corrections to regulators, comments and default brightness of the device-trees. - Added thermtrip node to transformers DT as we now have PMIC fix for it [1], it works properly now. [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20211124190104.23554-1-digetx@gmail.com/ - Changed sound card model names to make them per-device and consistent with the names that other Tegra DTs already use in upstream. This will prevent potential ABI breakages in the future if we will find that sound of some device needs extra differentiation. Anton Bambura (3): ARM: tegra: Add labels to tegra114.dtsi ARM: tegra: Add device-tree for ASUS Transformer Pad TF701T ARM: tegra: Enable video decoder on Tegra114 David Heidelberg (3): dt-bindings: ARM: tegra: Document Pegatron Chagall ARM: tegra: Rename top-level clocks ARM: tegra: nexus7: Drop clock-frequency from NFC node Dmitry Osipenko (7): ARM: tegra: Add device-tree for 1080p version of Nyan Big ARM: tegra: Enable HDMI CEC on Nyan ARM: tegra: Enable CPU DFLL on Nyan ARM: tegra: Add CPU thermal zones to Nyan device-tree ARM: tegra: Rename top-level regulators ARM: tegra_defconfig: Enable drivers wanted by Acer Chromebooks and ASUS tablets ARM: config: multi v7: Enable display drivers used by Tegra devices Maxim Schwalm (2): ARM: tegra: Add common device-tree for LVDS display panels of Tegra30 ASUS tablets ARM: tegra: nexus7: Use common LVDS display device-tree Michał Mirosław (2): ARM: tegra: Add labels to tegra30.dtsi ARM: tegra: Add device-tree for ASUS Transformer Pad TF300T Nikola Milosavljevic (1): ARM: tegra: Add device-tree for ASUS Transformer EeePad TF101 Stefan Agner (1): ARM: tegra: Re-add gpio-ranges properties Stefan Eichenberger (1): ARM: tegra: Add usb-role-switch property to USB OTG ports Svyatoslav Ryhel (6): dt-bindings: ARM: tegra: Document ASUS Transformers ARM: tegra: Add common device-tree base for Tegra30 ASUS Transformers ARM: tegra: Add device-tree for ASUS Transformer Prime TF201 ARM: tegra: Add device-tree for ASUS Transformer Pad TF300TG ARM: tegra: Add device-tree for ASUS Transformer Infinity TF700T ARM: tegra: Add device-tree for Pegatron Chagall Thierry Reding (2): ARM: tegra: Add #reset-cells for Tegra114 MC ARM: tegra: Remove stray #reset-cells property .../devicetree/bindings/arm/tegra.yaml | 19 + arch/arm/boot/dts/Makefile | 10 +- arch/arm/boot/dts/tegra114-asus-tf701t.dts | 788 +++++ arch/arm/boot/dts/tegra114-dalmore.dts | 16 +- arch/arm/boot/dts/tegra114-roth.dts | 14 +- arch/arm/boot/dts/tegra114-tn7.dts | 8 +- arch/arm/boot/dts/tegra114.dtsi | 92 +- arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi | 1 + arch/arm/boot/dts/tegra124-apalis.dtsi | 1 + arch/arm/boot/dts/tegra124-jetson-tk1.dts | 26 +- arch/arm/boot/dts/tegra124-nyan-big-fhd.dts | 11 + arch/arm/boot/dts/tegra124-nyan.dtsi | 84 +- arch/arm/boot/dts/tegra124-venice2.dts | 30 +- arch/arm/boot/dts/tegra124.dtsi | 2 - .../boot/dts/tegra20-acer-a500-picasso.dts | 12 +- arch/arm/boot/dts/tegra20-asus-tf101.dts | 1228 ++++++++ arch/arm/boot/dts/tegra20-harmony.dts | 16 +- arch/arm/boot/dts/tegra20-medcom-wide.dts | 8 +- arch/arm/boot/dts/tegra20-paz00.dts | 6 +- arch/arm/boot/dts/tegra20-plutux.dts | 8 +- arch/arm/boot/dts/tegra20-seaboard.dts | 16 +- arch/arm/boot/dts/tegra20-tamonten.dtsi | 4 +- arch/arm/boot/dts/tegra20-tec.dts | 8 +- arch/arm/boot/dts/tegra20-trimslice.dts | 12 +- arch/arm/boot/dts/tegra20-ventana.dts | 12 +- arch/arm/boot/dts/tegra20.dtsi | 2 - .../boot/dts/tegra30-asus-lvds-display.dtsi | 61 + .../tegra30-asus-nexus7-grouper-common.dtsi | 64 +- ...egra30-asus-nexus7-grouper-maxim-pmic.dtsi | 4 +- .../tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 2 +- .../boot/dts/tegra30-asus-nexus7-grouper.dtsi | 1 - .../boot/dts/tegra30-asus-nexus7-tilapia.dtsi | 2 - arch/arm/boot/dts/tegra30-asus-tf201.dts | 623 ++++ arch/arm/boot/dts/tegra30-asus-tf300t.dts | 1030 ++++++ arch/arm/boot/dts/tegra30-asus-tf300tg.dts | 1072 +++++++ arch/arm/boot/dts/tegra30-asus-tf700t.dts | 818 +++++ .../dts/tegra30-asus-transformer-common.dtsi | 1729 ++++++++++ arch/arm/boot/dts/tegra30-beaver.dts | 20 +- arch/arm/boot/dts/tegra30-cardhu-a02.dts | 12 +- arch/arm/boot/dts/tegra30-cardhu-a04.dts | 14 +- arch/arm/boot/dts/tegra30-cardhu.dtsi | 28 +- arch/arm/boot/dts/tegra30-ouya.dts | 5 - .../arm/boot/dts/tegra30-pegatron-chagall.dts | 2794 +++++++++++++++++ arch/arm/boot/dts/tegra30.dtsi | 38 +- arch/arm/configs/multi_v7_defconfig | 5 + arch/arm/configs/tegra_defconfig | 12 + 46 files changed, 10497 insertions(+), 271 deletions(-) create mode 100644 arch/arm/boot/dts/tegra114-asus-tf701t.dts create mode 100644 arch/arm/boot/dts/tegra124-nyan-big-fhd.dts create mode 100644 arch/arm/boot/dts/tegra20-asus-tf101.dts create mode 100644 arch/arm/boot/dts/tegra30-asus-lvds-display.dtsi create mode 100644 arch/arm/boot/dts/tegra30-asus-tf201.dts create mode 100644 arch/arm/boot/dts/tegra30-asus-tf300t.dts create mode 100644 arch/arm/boot/dts/tegra30-asus-tf300tg.dts create mode 100644 arch/arm/boot/dts/tegra30-asus-tf700t.dts create mode 100644 arch/arm/boot/dts/tegra30-asus-transformer-common.dtsi create mode 100644 arch/arm/boot/dts/tegra30-pegatron-chagall.dts