arch/arm64/boot/dts/ti/k3-am69-sk.dts | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
From: Dasnavis Sabiya <sabiya.d@ti.com>
AM69 SK board has two stacked USB3 connectors:
1. USB3 (Stacked TypeA + TypeC)
2. USB3 TypeA Hub interfaced through TUSB8041.
The board uses SERDES0 Lane 3 for USB3 IP. So update the
SerDes lane info for PCIe and USB. Add the pin mux data
and enable USB 3.0 support with its respective SERDES settings.
Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
---
I've been carrying this patch for quite long time in my builds to have
support for USB on my AM69-SK board without problems. For some reason this
patch was never send to upstream or I couldn't find it. So I took the
opportunity, now that I rebased my build, to send upstream.
I have maintained the original author of the downstream patch as is
basically his work.
---
arch/arm64/boot/dts/ti/k3-am69-sk.dts | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
index 1e36965a14032ca07143230855e04b9549f1d0d1..72797f4b689c1d069bf395d6d4fe1846dc4e4297 100644
--- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
@@ -484,6 +484,12 @@ J784S4_IOPAD(0x09C, PIN_OUTPUT, 0) /* (AF35) MCAN7_TX */
>;
};
+ main_usbss0_pins_default: main-usbss0-default-pins {
+ pinctrl-single,pins = <
+ J784S4_IOPAD(0x0EC, PIN_OUTPUT, 6) /* (AN37) TIMER_IO1.USB0_DRVVBUS */
+ >;
+ };
+
};
&wkup_pmx0 {
@@ -1299,6 +1305,14 @@ serdes0_pcie_link: phy@0 {
cdns,phy-type = <PHY_TYPE_PCIE>;
resets = <&serdes_wiz0 1>, <&serdes_wiz0 2>, <&serdes_wiz0 3>;
};
+
+ serdes0_usb_link: phy@3 {
+ reg = <3>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_USB3>;
+ resets = <&serdes_wiz0 4>;
+ };
};
&serdes_wiz1 {
@@ -1339,3 +1353,22 @@ &pcie3_rc {
phy-names = "pcie-phy";
num-lanes = <1>;
};
+
+&usb_serdes_mux {
+ idle-states = <0>; /* USB0 to SERDES0 */
+};
+
+&usbss0 {
+ status = "okay";
+ pinctrl-0 = <&main_usbss0_pins_default>;
+ pinctrl-names = "default";
+ ti,vbus-divider;
+};
+
+&usb0 {
+ status = "okay";
+ dr_mode = "host";
+ maximum-speed = "super-speed";
+ phys = <&serdes0_usb_link>;
+ phy-names = "cdns3,usb3-phy";
+};
---
base-commit: 7eef7e306d3c40a0c5b9ff6adc9b273cc894dbd5
change-id: 20241126-am69sk-dt-usb-89180ef58f8d
Best regards,
--
Enric Balletbo i Serra <eballetb@redhat.com>Hi Enric,
On 26/11/2024 12:08, Enric Balletbo i Serra wrote:
> From: Dasnavis Sabiya <sabiya.d@ti.com>
>
> AM69 SK board has two stacked USB3 connectors:
> 1. USB3 (Stacked TypeA + TypeC)
> 2. USB3 TypeA Hub interfaced through TUSB8041.
>
> The board uses SERDES0 Lane 3 for USB3 IP. So update the
> SerDes lane info for PCIe and USB. Add the pin mux data
> and enable USB 3.0 support with its respective SERDES settings.
>
> Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
> Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
> ---
> I've been carrying this patch for quite long time in my builds to have
> support for USB on my AM69-SK board without problems. For some reason this
> patch was never send to upstream or I couldn't find it. So I took the
> opportunity, now that I rebased my build, to send upstream.
>
> I have maintained the original author of the downstream patch as is
> basically his work.
> ---
> arch/arm64/boot/dts/ti/k3-am69-sk.dts | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> index 1e36965a14032ca07143230855e04b9549f1d0d1..72797f4b689c1d069bf395d6d4fe1846dc4e4297 100644
> --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> @@ -484,6 +484,12 @@ J784S4_IOPAD(0x09C, PIN_OUTPUT, 0) /* (AF35) MCAN7_TX */
> >;
> };
>
> + main_usbss0_pins_default: main-usbss0-default-pins {
> + pinctrl-single,pins = <
> + J784S4_IOPAD(0x0EC, PIN_OUTPUT, 6) /* (AN37) TIMER_IO1.USB0_DRVVBUS */
address offset should be lower case?
> + >;
> + };
> +
> };
>
> &wkup_pmx0 {
> @@ -1299,6 +1305,14 @@ serdes0_pcie_link: phy@0 {
> cdns,phy-type = <PHY_TYPE_PCIE>;
> resets = <&serdes_wiz0 1>, <&serdes_wiz0 2>, <&serdes_wiz0 3>;
> };
> +
> + serdes0_usb_link: phy@3 {
> + reg = <3>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_USB3>;
> + resets = <&serdes_wiz0 4>;
> + };
> };
>
> &serdes_wiz1 {
> @@ -1339,3 +1353,22 @@ &pcie3_rc {
> phy-names = "pcie-phy";
> num-lanes = <1>;
> };
> +
> +&usb_serdes_mux {
> + idle-states = <0>; /* USB0 to SERDES0 */
> +};
> +
> +&usbss0 {
> + status = "okay";
> + pinctrl-0 = <&main_usbss0_pins_default>;
> + pinctrl-names = "default";
> + ti,vbus-divider;
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + maximum-speed = "super-speed";
> + phys = <&serdes0_usb_link>;
> + phy-names = "cdns3,usb3-phy";
> +};
Reviewed-by: Roger Quadros <rogerq@kernel.org>
--
cheers,
-roger
On Tue, Nov 26, 2024 at 11:08:19AM +0100, Enric Balletbo i Serra wrote:
Hello Enric,
> From: Dasnavis Sabiya <sabiya.d@ti.com>
>
> AM69 SK board has two stacked USB3 connectors:
> 1. USB3 (Stacked TypeA + TypeC)
> 2. USB3 TypeA Hub interfaced through TUSB8041.
>
> The board uses SERDES0 Lane 3 for USB3 IP. So update the
> SerDes lane info for PCIe and USB. Add the pin mux data
> and enable USB 3.0 support with its respective SERDES settings.
>
> Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
> Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
> ---
> I've been carrying this patch for quite long time in my builds to have
> support for USB on my AM69-SK board without problems. For some reason this
> patch was never send to upstream or I couldn't find it. So I took the
> opportunity, now that I rebased my build, to send upstream.
>
> I have maintained the original author of the downstream patch as is
> basically his work.
> ---
> arch/arm64/boot/dts/ti/k3-am69-sk.dts | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
[...]
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
Since the Type-C interface is also connected to USB0, shouldn't "dr_mode"
be "otg"? Also, has the Type-C interface been tested with this patch?
Please let me know.
[...]
Regards,
Siddharth.
Hi,
On Wed, Nov 27, 2024 at 9:27 AM s-vadapalli <s-vadapalli@ti.com> wrote:
>
> On Tue, Nov 26, 2024 at 11:08:19AM +0100, Enric Balletbo i Serra wrote:
>
> Hello Enric,
>
> > From: Dasnavis Sabiya <sabiya.d@ti.com>
> >
> > AM69 SK board has two stacked USB3 connectors:
> > 1. USB3 (Stacked TypeA + TypeC)
> > 2. USB3 TypeA Hub interfaced through TUSB8041.
> >
> > The board uses SERDES0 Lane 3 for USB3 IP. So update the
> > SerDes lane info for PCIe and USB. Add the pin mux data
> > and enable USB 3.0 support with its respective SERDES settings.
> >
> > Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
> > Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
> > ---
> > I've been carrying this patch for quite long time in my builds to have
> > support for USB on my AM69-SK board without problems. For some reason this
> > patch was never send to upstream or I couldn't find it. So I took the
> > opportunity, now that I rebased my build, to send upstream.
> >
> > I have maintained the original author of the downstream patch as is
> > basically his work.
> > ---
> > arch/arm64/boot/dts/ti/k3-am69-sk.dts | 33 +++++++++++++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
>
> [...]
>
> > +&usb0 {
> > + status = "okay";
> > + dr_mode = "host";
>
> Since the Type-C interface is also connected to USB0, shouldn't "dr_mode"
> be "otg"? Also, has the Type-C interface been tested with this patch?
> Please let me know.
>
Yes, all usb from the board were tested. I'll try otg mode for the
Type-C interface and resend the patch.
$ lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 001: Dev 004, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
|__ Port 001: Dev 004, If 1, Class=Human Interface Device,
Driver=usbhid, 1.5M
|__ Port 002: Dev 005, If 0, Class=Mass Storage,
Driver=usb-storage, 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 003: Dev 004, If 0, Class=Mass Storage,
Driver=usb-storage, 5000M
|__ Port 004: Dev 003, If 0, Class=Mass Storage,
Driver=usb-storage, 5000M
Thanks,
Enric
> [...]
>
> Regards,
> Siddharth.
>
Hi,
On Wed, Nov 27, 2024 at 11:00 AM Enric Balletbo i Serra
<eballetb@redhat.com> wrote:
>
> Hi,
>
> On Wed, Nov 27, 2024 at 9:27 AM s-vadapalli <s-vadapalli@ti.com> wrote:
> >
> > On Tue, Nov 26, 2024 at 11:08:19AM +0100, Enric Balletbo i Serra wrote:
> >
> > Hello Enric,
> >
> > > From: Dasnavis Sabiya <sabiya.d@ti.com>
> > >
> > > AM69 SK board has two stacked USB3 connectors:
> > > 1. USB3 (Stacked TypeA + TypeC)
> > > 2. USB3 TypeA Hub interfaced through TUSB8041.
> > >
> > > The board uses SERDES0 Lane 3 for USB3 IP. So update the
> > > SerDes lane info for PCIe and USB. Add the pin mux data
> > > and enable USB 3.0 support with its respective SERDES settings.
> > >
> > > Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
> > > Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
> > > ---
> > > I've been carrying this patch for quite long time in my builds to have
> > > support for USB on my AM69-SK board without problems. For some reason this
> > > patch was never send to upstream or I couldn't find it. So I took the
> > > opportunity, now that I rebased my build, to send upstream.
> > >
> > > I have maintained the original author of the downstream patch as is
> > > basically his work.
> > > ---
> > > arch/arm64/boot/dts/ti/k3-am69-sk.dts | 33 +++++++++++++++++++++++++++++++++
> > > 1 file changed, 33 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
> >
> > [...]
> >
> > > +&usb0 {
> > > + status = "okay";
> > > + dr_mode = "host";
> >
> > Since the Type-C interface is also connected to USB0, shouldn't "dr_mode"
> > be "otg"? Also, has the Type-C interface been tested with this patch?
> > Please let me know.
> >
So I changed the dr_mode to otg instead of host and tried to configure
a usb mass storage gadget but unfortunately didn't work, but this
could be a driver problem, I got the following error
UDC core: g1: couldn't find an available UDC
As the devicetree should describe the hardware, and as far as I can
see it should support the type-c port act as a gadget, I'm fine with
changing the dr_mode, unless anyone have more information about this,
the thing that makes me think a bit more is that, in the TI kernel
this is set to host, so I'm wondering if I'm missing something or is
just that was never tested.
Thanks,
Enric
>
> Yes, all usb from the board were tested. I'll try otg mode for the
> Type-C interface and resend the patch.
>
> $ lsusb -t
> /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 001: Dev 004, If 0, Class=Human Interface Device,
> Driver=usbhid, 1.5M
> |__ Port 001: Dev 004, If 1, Class=Human Interface Device,
> Driver=usbhid, 1.5M
> |__ Port 002: Dev 005, If 0, Class=Mass Storage,
> Driver=usb-storage, 480M
> /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
> |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 5000M
> |__ Port 003: Dev 004, If 0, Class=Mass Storage,
> Driver=usb-storage, 5000M
> |__ Port 004: Dev 003, If 0, Class=Mass Storage,
> Driver=usb-storage, 5000M
>
> Thanks,
> Enric
> > [...]
> >
> > Regards,
> > Siddharth.
> >
On Thu, Nov 28, 2024 at 10:47:42AM +0100, Enric Balletbo i Serra wrote: > Hi, [...] > So I changed the dr_mode to otg instead of host and tried to configure > a usb mass storage gadget but unfortunately didn't work, but this > could be a driver problem, I got the following error > > UDC core: g1: couldn't find an available UDC > > As the devicetree should describe the hardware, and as far as I can > see it should support the type-c port act as a gadget, I'm fine with > changing the dr_mode, unless anyone have more information about this, > the thing that makes me think a bit more is that, in the TI kernel > this is set to host, so I'm wondering if I'm missing something or is > just that was never tested. Are all interfaces (Type-A and Type-C) functional as Host when the dr_mode is set to "otg"? (Do USB devices connected to the interfaces enumerate on AM69-SK?) If yes, then it could be a DIP Switch setting that is related to OTG mode of operation or a USB-C Mux that needs to be configured. Regards, Siddharth.
Hi, On Thu, Nov 28, 2024 at 10:58 AM s-vadapalli <s-vadapalli@ti.com> wrote: > > On Thu, Nov 28, 2024 at 10:47:42AM +0100, Enric Balletbo i Serra wrote: > > Hi, > > [...] > > > So I changed the dr_mode to otg instead of host and tried to configure > > a usb mass storage gadget but unfortunately didn't work, but this > > could be a driver problem, I got the following error > > > > UDC core: g1: couldn't find an available UDC > > > > As the devicetree should describe the hardware, and as far as I can > > see it should support the type-c port act as a gadget, I'm fine with > > changing the dr_mode, unless anyone have more information about this, > > the thing that makes me think a bit more is that, in the TI kernel > > this is set to host, so I'm wondering if I'm missing something or is > > just that was never tested. > > Are all interfaces (Type-A and Type-C) functional as Host when the > dr_mode is set to "otg"? (Do USB devices connected to the interfaces > enumerate on AM69-SK?) If yes, then it could be a DIP Switch setting > that is related to OTG mode of operation or a USB-C Mux that needs to be > configured. > Yes, all interfaces (Type-A and Type-C) are functional as host when the dr_mode is set to "otg". Looking at SK-AM69 Processor Start Kit User's Guide (Rev. A) [1] I don't see any DIP Switch related to the OTG mode. Looks like the type-c connector connects directly to the SoC through a USB HUB (TUSB4041). [1] https://www.ti.com/lit/ug/spruj70a/spruj70a.pdf?ts=1733215039014 Regards, Enric > Regards, > Siddharth. >
On Tue, Dec 03, 2024 at 04:29:02PM +0100, Enric Balletbo i Serra wrote: > Hi, > > On Thu, Nov 28, 2024 at 10:58 AM s-vadapalli <s-vadapalli@ti.com> wrote: > > > > On Thu, Nov 28, 2024 at 10:47:42AM +0100, Enric Balletbo i Serra wrote: > > > Hi, > > > > [...] > > > > > So I changed the dr_mode to otg instead of host and tried to configure > > > a usb mass storage gadget but unfortunately didn't work, but this > > > could be a driver problem, I got the following error > > > > > > UDC core: g1: couldn't find an available UDC > > > > > > As the devicetree should describe the hardware, and as far as I can > > > see it should support the type-c port act as a gadget, I'm fine with > > > changing the dr_mode, unless anyone have more information about this, > > > the thing that makes me think a bit more is that, in the TI kernel > > > this is set to host, so I'm wondering if I'm missing something or is > > > just that was never tested. > > > > Are all interfaces (Type-A and Type-C) functional as Host when the > > dr_mode is set to "otg"? (Do USB devices connected to the interfaces > > enumerate on AM69-SK?) If yes, then it could be a DIP Switch setting > > that is related to OTG mode of operation or a USB-C Mux that needs to be > > configured. > > > > Yes, all interfaces (Type-A and Type-C) are functional as host when > the dr_mode is set to "otg". Looking at SK-AM69 Processor Start Kit > User's Guide (Rev. A) [1] I don't see any DIP Switch related to the > OTG mode. Looks like the type-c connector connects directly to the > SoC through a USB HUB (TUSB4041). > > [1] https://www.ti.com/lit/ug/spruj70a/spruj70a.pdf?ts=1733215039014 In that case, please post the patch setting "dr_mode" to "otg". As to why "peripheral"/"gadget" operation doesn't work could be addressed separately and seems to be independent of the device-tree. The reason for suggesting "otg" instead of "host" is to ensure that the device-tree describes the Hardware. Since "host" mode is still functional with "dr_mode" set to "otg", at-least for the use-cases that you have in mind, I believe that "otg" should be acceptable. Regards, Siddharth.
© 2016 - 2026 Red Hat, Inc.