[PATCH 0/4] Enable USB OTG on Allwinner H3 and two boards

[Icenowy Zheng]

This patchset depends on the following patch (only the patch, as it adds the
MUSB controller used in H3, the patchset itself is for V3s):
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/476387.html

This patchset enables USB OTG ports on Orange Pi Zero and One board, using the
SoC's MUSB controller.

The mode of PHY0 is currently set to MUSB mode, as supporting EHCI/OHCI will
cost more time and code; but MUSB can supply both host and peripheral mode.

OTG function is only enabled for these two boards, as they're the only H3/H2+
boards that I have.

I think other boards' owners can easily enable their boards' OTG function with
these patches.

Icenowy Zheng (4):
phy: sun4i-usb: support PHY0 on H3 in MUSB mode
ARM: dts: sun8i: add MUSB node to H3 SoC
ARM: dts: sun8i: enable USB OTG for Orange Pi Zero board
ARM: dts: sun8i: enable USB OTG on Orange Pi One board

arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 6 ++++++
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 12 +++++++++++
arch/arm/boot/dts/sun8i-h3.dtsi | 13 ++++++++++++
drivers/phy/phy-sun4i-usb.c | 25 ++++++++---------------
4 files changed, 40 insertions(+), 16 deletions(-)

--
2.11.0

[Icenowy Zheng]

The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
controller.

The original driver wired it to OHCI/EHCI controller; however, as the
code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
unusable.

Rename the register (according to its function and the name in BSP
driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
can support both peripheral and host mode (although the host mode of
MUSB is buggy).

The register that is renamed is now unused, as its initial value is just
MUSB mode. However, when OHCI/EHCI mode support is added, the register
can be used again.

Signed-off-by: Icenowy Zheng <ice...@aosc.xyz>
---
drivers/phy/phy-sun4i-usb.c | 25 +++++++++----------------
1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index bf28a0fdd569..6b193a635c6b 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -49,7 +49,7 @@
#define REG_PHYBIST 0x08
#define REG_PHYTUNE 0x0c
#define REG_PHYCTL_A33 0x10
-#define REG_PHY_UNK_H3 0x20
+#define REG_PHY_OTGCTL 0x20

#define REG_PMU_UNK1 0x10

@@ -269,23 +269,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val & ~2, phy->pmu + REG_PMU_UNK1);
}

- if (data->cfg->type == sun8i_h3_phy) {
- if (phy->index == 0) {
- val = readl(data->base + REG_PHY_UNK_H3);
- writel(val & ~1, data->base + REG_PHY_UNK_H3);
- }
- } else {
- /* Enable USB 45 Ohm resistor calibration */
- if (phy->index == 0)
- sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
+ /* Enable USB 45 Ohm resistor calibration */
+ if (phy->index == 0)
+ sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);

- /* Adjust PHY's magnitude and rate */
- sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
+ /* Adjust PHY's magnitude and rate */
+ sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);

- /* Disconnect threshold adjustment */
- sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
- data->cfg->disc_thresh, 2);
- }
+ /* Disconnect threshold adjustment */
+ sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
+ data->cfg->disc_thresh, 2);

sun4i_usb_phy_passby(phy, 1);

--
2.11.0

[Icenowy Zheng]

As we have already H3 PHY support code to MUSB mode fixed, and the H3
MUSB controller supported, we can now add the MUSB node to the DTSI file
of H3.

Signed-off-by: Icenowy Zheng <ice...@aosc.xyz>
---

arch/arm/boot/dts/sun8i-h3.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 08fd0860bb6b..60dd88c7fb9a 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -206,6 +206,19 @@
#size-cells = <0>;
};

+ usb_otg: usb@01c19000 {
+ compatible = "allwinner,sun8i-h3-musb";
+ reg = <0x01c19000 0x0400>;
+ clocks = <&ccu CLK_BUS_OTG>;
+ resets = <&ccu RST_BUS_OTG>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ status = "disabled";
+ };
+
usbphy: phy@01c19400 {
compatible = "allwinner,sun8i-h3-usb-phy";
reg = <0x01c19400 0x2c>,
--
2.11.0

[Icenowy Zheng]

Orange Pi Zero board features a USB OTG port, which has a ID pin, and
can be used to power up the borad. However, even if the board is powered
via +5V pin in GPIO/expansion headers, the VBUS in the OTG port cannot
be powered up, thus it's impossible to use it in host mode with simple
OTG cables.

Add support for it in peripheral mode.

If someone really want to use it in host mode, the dr_mode property of
&usb_otg can be changed into "otg", then a powered USB OTG cable or USB
HUB is needed for powering out the external USB devices.

Signed-off-by: Icenowy Zheng <ice...@aosc.xyz>
---

arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index b7ca916d871d..437536e2b594 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -154,7 +154,13 @@
status = "disabled";
};

+&usb_otg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
&usbphy {
/* USB VBUS is always on */
status = "okay";
+ usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
};
--
2.11.0

[Icenowy Zheng]

Orange Pi One board features a USB OTG port, which cannot be used to
power up the board, but have a gateable VBUS and an ID pin, which makes
it possible to be used in both host and peripheral mode.

Enable its OTG port in dual-role mode.

Signed-off-by: Icenowy Zheng <ice...@aosc.xyz>
---

arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 34da853ee037..8f69c8c9995c 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -115,6 +115,11 @@
};
};

+&reg_usb0_vbus {
+ gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */

+ status = "okay";
+};
+

&r_pio {
leds_r_opc: led_pins@0 {
pins = "PL10";
@@ -151,7 +156,14 @@
status = "disabled";
};

+&usb_otg {
+ dr_mode = "otg";

+ status = "okay";
+};
+
&usbphy {
/* USB VBUS is always on */
status = "okay";
+ usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */

+ usb0_vbus-supply = <&reg_usb0_vbus>;
};
--
2.11.0

[Ondřej Jirman]

Dne 16.1.2017 v 20:14 Icenowy Zheng napsal(a):

You have added REG_PHY_OTGCTL, but it is not used below.

regards,
o.

[Icenowy Zheng]

See the commit message.

I know it's now unused :-) It's just because the default mode is musb.

[Maxime Ripard]

On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> controller.
>
> The original driver wired it to OHCI/EHCI controller; however, as the
> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> unusable.
>
> Rename the register (according to its function and the name in BSP
> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> can support both peripheral and host mode (although the host mode of
> MUSB is buggy).

Can you elaborate on that? What's wrong with it?

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Icenowy Zheng]

17.01.2017, 16:06, "Maxime Ripard" <maxime...@free-electrons.com>:

> On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
>>  The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
>>  controller.
>>
>>  The original driver wired it to OHCI/EHCI controller; however, as the
>>  code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
>>  unusable.
>>
>>  Rename the register (according to its function and the name in BSP
>>  driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
>>  can support both peripheral and host mode (although the host mode of
>>  MUSB is buggy).
>
> Can you elaborate on that? What's wrong with it?

The configuration is at bit 0 of register 0x20 in PHY.

When the PHY is reseted, it defaults as MUSB mode.

However, the original author of the H3 PHY code seems to be lack of this
knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI mode.

I just removed the code that wires it to HCI mode, thus it will work in MUSB
mode, with my sun8i-h3-musb patch.

[Maxime Ripard]

On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote:
>
>
> 17.01.2017, 16:06, "Maxime Ripard" <maxime...@free-electrons.com>:
> > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
> >>  The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> >>  controller.
> >>
> >>  The original driver wired it to OHCI/EHCI controller; however, as the
> >>  code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> >>  unusable.
> >>
> >>  Rename the register (according to its function and the name in BSP
> >>  driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> >>  can support both peripheral and host mode (although the host mode of
> >>  MUSB is buggy).
> >
> > Can you elaborate on that? What's wrong with it?
>
> The configuration is at bit 0 of register 0x20 in PHY.
>
> When the PHY is reseted, it defaults as MUSB mode.
>
> However, the original author of the H3 PHY code seems to be lack of
> this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI
> mode.
>
> I just removed the code that wires it to HCI mode, thus it will work
> in MUSB mode, with my sun8i-h3-musb patch.

I have no idea what you mean by MUSB mode.

Do you mean that the previous code was only working in host mode, and
now it only works in peripheral?

[Chen-Yu Tsai]

Hi,

From what I understand, with the H3, Allwinner has put a mux
in front of the MUSB controller. The mux can send the USB data
to/from the MUSB controller, or a standard EHCI/OHCI pair.
This register controls said mux.

This means we can use a proper USB host for host mode,
instead of the limited support in MUSB.

ChenYu

[Maxime Ripard]

But musb can still operate as a host, right?

Thanks!

[Icenowy Zheng]

19.01.2017, 22:34, "Maxime Ripard" <maxime...@free-electrons.com>:

Yes!

[Karsten Merker]

Hello,

I don't know how the MUSB implementation in the H3 behaves as I
don't have any H3-based systems, but if it should happen to be
similar to the one in the A31s, it probably isn't a full-fledged
alternative to using an OHCI/EHCI controller.

From my practical experiments with the MUSB in the A31s in host
mode I can report that I hadn't been able to get multiple HIDs
(in my case keyboard and mouse) working at the same time. The
keyboard alone worked without problems, the mouse alone worked
without problems, but when both were connected, only one of them
worked.

I had at that time talked to Hans de Goede about the problem and
if I remenber correctly, he had mentioned that the MUSB has
problems servicing more than one device that does interrupt
transfers (as HIDs do).

Hans, can you perhaps shed some light on this?

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[Hans de Goede]

HI,

You right it isn't which is why I suggested that the phy-sun4i-usb
code should set the mux to the OCHI/EHCI pair when the id pin
is pulled low (host-mode).

> From my practical experiments with the MUSB in the A31s in host
> mode I can report that I hadn't been able to get multiple HIDs
> (in my case keyboard and mouse) working at the same time. The
> keyboard alone worked without problems, the mouse alone worked
> without problems, but when both were connected, only one of them
> worked.
>
> I had at that time talked to Hans de Goede about the problem and
> if I remenber correctly, he had mentioned that the MUSB has
> problems servicing more than one device that does interrupt
> transfers (as HIDs do).
>
> Hans, can you perhaps shed some light on this?

Everything you've said is correct, the MUSB can emulate a
host-controller, but it is not really one and when possible
should not be used as such.

Regards,

Hans

[Icenowy Zheng]

20.01.2017, 16:04, "Hans de Goede" <hdeg...@redhat.com>:

But implement proper EHCI/OHCI pair and MUSB coexistence needs
a lot of code, and MUSB can still work.

We can now just enable MUSB, then after the coexistence is done,
switch to use MUSB for peripheral and {E,O}HCI for host.

Seems that SoCs after sun8iw7 (H3) all have this feature. (At least
I verified it on H3, V3s, A64, H5)

P.S. The implementation on FreeBSD of A64 PHY uses a dedicated
PHY number for the HCI pair, which seems to break the DT compatibility
between Linux and FreeBSD.

>
> Hans

[Hans de Goede]

HI,

No it doesn't see the previous thread on this I give an example
of how this can be implemented there, and it is not a lot of
work, it just requires someone to do it.

> and MUSB can still work.
>
> We can now just enable MUSB, then after the coexistence is done,
> switch to use MUSB for peripheral and {E,O}HCI for host.

I'm not in favor of these kinda hacks, we are creating expectations
of how things work then only to change them later with a possible
risk of regression things for some users / use-cases. Lets do
this the right way in one go please.

> Seems that SoCs after sun8iw7 (H3) all have this feature. (At least
> I verified it on H3, V3s, A64, H5)
>
> P.S. The implementation on FreeBSD of A64 PHY uses a dedicated
> PHY number for the HCI pair, which seems to break the DT compatibility
> between Linux and FreeBSD.

That is unfortunate and also weird since AFAICT there is only
one phy and it is the phy data lines which get muxed not the
physical phy. Anyways can you contact them and ask them to
please not do that ?

Regards,

Hans

[Icenowy Zheng]

2017年1月18日 04:09于 Chen-Yu Tsai <we...@csie.org>写道：
>
> Hi,

Yes you got it.

The MUSB controller can also be used in host mode, but weaker then EHCI/OHCI.

> ChenYu

[Icenowy Zheng]

2017年1月22日 17:58于 Hans de Goede <hdeg...@redhat.com>写道：
>
> HI,
>
> On 22-01-17 10:39, Icenowy Zheng wrote:
> >
> >
> > 20.01.2017, 16:04, "Hans de Goede" <hdeg...@redhat.com>:
> >> HI,
> >>
> >> On 19-01-17 21:27, Karsten Merker wrote:
> >>>  On Thu, Jan 19, 2017 at 11:10:08PM +0800, Icenowy Zheng wrote:
> >>>>  19.01.2017, 22:34, "Maxime Ripard" <maxime...@free-electrons.com>:

However, currently dr_mode is specified in musb, and it's musb that is responsible for changing the mode (PHY driver only detects ID pin).

> > and MUSB can still work.
> >
> > We can now just enable MUSB, then after the coexistence is done,
> > switch to use MUSB for peripheral and {E,O}HCI for host.
>
> I'm not in favor of these kinda hacks, we are creating expectations
> of how things work then only to change them later with a possible
> risk of regression things for some users / use-cases. Lets do
> this the right way in one go please.

As we should move dr_mode to phy node, we can
just let phy behave like a musb-only phy if such a dr_mode is not specified.

And this patch just makes the phy behave in a way
like the phy in the old SoCs, not a hack.