arm64: dts: allwinner: properly connect USB PHY to port 0
diff mbox series

Message ID 20190620010127.12071-1-andre.przywara@arm.com
State New
Headers show
Series
  • arm64: dts: allwinner: properly connect USB PHY to port 0
Related show

Commit Message

Andre Przywara June 20, 2019, 1:01 a.m. UTC
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(+)

Comments

Chen-Yu Tsai June 24, 2019, 8:25 a.m. UTC | #1
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
Andre Przywara June 24, 2019, 12:58 p.m. UTC | #2
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.
Chen-Yu Tsai June 24, 2019, 1:03 p.m. UTC | #3
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
Chen-Yu Tsai June 27, 2019, 3:34 a.m. UTC | #4
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

Patch
diff mbox series

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";
 };