| Message ID | 20190620010127.12071-1-andre.przywara@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: allwinner: properly connect USB PHY to port 0 | expand |
On Thu, Jun 20, 2019 at 9:02 AM Andre Przywara <andre.przywara@arm.com> wrote: > > In recent Allwinner SoCs the first USB host controller (HCI0) shares > the first PHY with the MUSB controller. Probably to make this sharing > work, we were avoiding to declare this in the DT. This has two > shortcomings: > - U-Boot (which uses the same .dts) cannot use this port without a PHY > linked, so we were loosing one USB port there. > - It requires the MUSB driver to be enabled and loaded, although we > don't actually use it. > > For those (64-bit) boards which use an USB-A socket for HCI0/MUSB, add > a "phys" property pointing to the USB PHY 0. > > This makes it work in U-Boot, also improves compatiblity when no MUSB > driver is loaded (for instance in distribution installers). > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > --- > Hi, > > I have the feeling this belongs into the .dtsi, but cant't tell for sure > how this interacts with the MUSB driver. If need be, we can always pull > this up later, I guess. Have you tried if gadget mode and switching between gadget/host mode on an otg port still works? AFAICT that would be the main thing to worry about. ChenYu
On Mon, 24 Jun 2019 16:25:47 +0800 Chen-Yu Tsai <wens@csie.org> wrote: Hi, > On Thu, Jun 20, 2019 at 9:02 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > In recent Allwinner SoCs the first USB host controller (HCI0) shares > > the first PHY with the MUSB controller. Probably to make this sharing > > work, we were avoiding to declare this in the DT. This has two > > shortcomings: > > - U-Boot (which uses the same .dts) cannot use this port without a PHY > > linked, so we were loosing one USB port there. > > - It requires the MUSB driver to be enabled and loaded, although we > > don't actually use it. > > > > For those (64-bit) boards which use an USB-A socket for HCI0/MUSB, add > > a "phys" property pointing to the USB PHY 0. > > > > This makes it work in U-Boot, also improves compatiblity when no MUSB > > driver is loaded (for instance in distribution installers). > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > > --- > > Hi, > > > > I have the feeling this belongs into the .dtsi, but cant't tell for sure > > how this interacts with the MUSB driver. If need be, we can always pull > > this up later, I guess. > > Have you tried if gadget mode and switching between gadget/host mode on > an otg port still works? AFAICT that would be the main thing to worry > about. I briefly tried gadget mode on a BPi-M64, and that still seemed to work, but I couldn't switch it to host mode. IIRC that didn't even work without this patch, but I didn't find the time to investigate yet. Is it supposed to switch automatically when the ID pin changes state? Do you know a board/kernel combination which is known to work? Cheers, Andre.
On Mon, Jun 24, 2019 at 8:58 PM Andre Przywara <andre.przywara@arm.com> wrote: > > On Mon, 24 Jun 2019 16:25:47 +0800 > Chen-Yu Tsai <wens@csie.org> wrote: > > Hi, > > > On Thu, Jun 20, 2019 at 9:02 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > > > In recent Allwinner SoCs the first USB host controller (HCI0) shares > > > the first PHY with the MUSB controller. Probably to make this sharing > > > work, we were avoiding to declare this in the DT. This has two > > > shortcomings: > > > - U-Boot (which uses the same .dts) cannot use this port without a PHY > > > linked, so we were loosing one USB port there. > > > - It requires the MUSB driver to be enabled and loaded, although we > > > don't actually use it. > > > > > > For those (64-bit) boards which use an USB-A socket for HCI0/MUSB, add > > > a "phys" property pointing to the USB PHY 0. > > > > > > This makes it work in U-Boot, also improves compatiblity when no MUSB > > > driver is loaded (for instance in distribution installers). > > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > > > --- > > > Hi, > > > > > > I have the feeling this belongs into the .dtsi, but cant't tell for sure > > > how this interacts with the MUSB driver. If need be, we can always pull > > > this up later, I guess. > > > > Have you tried if gadget mode and switching between gadget/host mode on > > an otg port still works? AFAICT that would be the main thing to worry > > about. > > I briefly tried gadget mode on a BPi-M64, and that still seemed to work, > but I couldn't switch it to host mode. IIRC that didn't even work without > this patch, but I didn't find the time to investigate yet. > > Is it supposed to switch automatically when the ID pin changes state? Do > you know a board/kernel combination which is known to work? Yes it's supposed to switch automatically when you insert or remove the OTG host mode cable. I think it worked during the last release cycle while I was adding support for VBUS polling. I'll do some tests on the current sunxi-next tomorrow and let you know. ChenYu
On Mon, Jun 24, 2019 at 9:03 PM Chen-Yu Tsai <wens@csie.org> wrote: > > On Mon, Jun 24, 2019 at 8:58 PM Andre Przywara <andre.przywara@arm.com> wrote: > > > > On Mon, 24 Jun 2019 16:25:47 +0800 > > Chen-Yu Tsai <wens@csie.org> wrote: > > > > Hi, > > > > > On Thu, Jun 20, 2019 at 9:02 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > > > > > In recent Allwinner SoCs the first USB host controller (HCI0) shares > > > > the first PHY with the MUSB controller. Probably to make this sharing > > > > work, we were avoiding to declare this in the DT. This has two > > > > shortcomings: > > > > - U-Boot (which uses the same .dts) cannot use this port without a PHY > > > > linked, so we were loosing one USB port there. > > > > - It requires the MUSB driver to be enabled and loaded, although we > > > > don't actually use it. > > > > > > > > For those (64-bit) boards which use an USB-A socket for HCI0/MUSB, add > > > > a "phys" property pointing to the USB PHY 0. > > > > > > > > This makes it work in U-Boot, also improves compatiblity when no MUSB > > > > driver is loaded (for instance in distribution installers). > > > > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > > > > --- > > > > Hi, > > > > > > > > I have the feeling this belongs into the .dtsi, but cant't tell for sure > > > > how this interacts with the MUSB driver. If need be, we can always pull > > > > this up later, I guess. > > > > > > Have you tried if gadget mode and switching between gadget/host mode on > > > an otg port still works? AFAICT that would be the main thing to worry > > > about. > > > > I briefly tried gadget mode on a BPi-M64, and that still seemed to work, > > but I couldn't switch it to host mode. IIRC that didn't even work without > > this patch, but I didn't find the time to investigate yet. > > > > Is it supposed to switch automatically when the ID pin changes state? Do > > you know a board/kernel combination which is known to work? > > Yes it's supposed to switch automatically when you insert or remove the > OTG host mode cable. > > I think it worked during the last release cycle while I was adding support > for VBUS polling. I'll do some tests on the current sunxi-next tomorrow > and let you know. So it works properly for me on the Bananapi M64 with the latest sunxi-next branch. I have the gadget drivers built-in. ChenYu
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts index 409523cb0950..b23e827a6065 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts @@ -93,6 +93,7 @@ }; &ehci0 { + phys = <&usbphy 0>; status = "okay"; }; @@ -147,6 +148,7 @@ }; &ohci0 { + phys = <&usbphy 0>; status = "okay"; }; diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts index e6fb9683f213..b422bef19fff 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts @@ -105,6 +105,7 @@ }; &ehci0 { + phys = <&usbphy 0>; status = "okay"; }; @@ -151,6 +152,7 @@ }; &ohci0 { + phys = <&usbphy 0>; status = "okay"; }; diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts index 9887948d5c86..5da9cdfb4f48 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts @@ -124,6 +124,7 @@ }; &ehci0 { + phys = <&usbphy 0>; status = "okay"; }; @@ -179,6 +180,7 @@ }; &ohci0 { + phys = <&usbphy 0>; status = "okay"; }; diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts index 0dc33c90dd60..293f66c44032 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts @@ -58,6 +58,7 @@ }; &ehci0 { + phys = <&usb2phy 0>; status = "okay"; }; @@ -104,6 +105,7 @@ }; &ohci0 { + phys = <&usb2phy 0>; status = "okay"; }; diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts index 9e464d40cbff..577f8133181e 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts @@ -96,6 +96,7 @@ }; &ehci0 { + phys = <&usb2phy 0>; status = "okay"; }; @@ -120,6 +121,7 @@ }; &ohci0 { + phys = <&usb2phy 0>; status = "okay"; };
In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. For those (64-bit) boards which use an USB-A socket for HCI0/MUSB, add a "phys" property pointing to the USB PHY 0. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- Hi, I have the feeling this belongs into the .dtsi, but cant't tell for sure how this interacts with the MUSB driver. If need be, we can always pull this up later, I guess. Thanks, Andre arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 2 ++ arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts | 2 ++ arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts | 2 ++ arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 2 ++ arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 2 ++ 5 files changed, 10 insertions(+)