Aw: [PATCH 0/2] Add MUSB for MT7623

Sungbo Eo mans0n at gorani.run
Tue Aug 3 17:14:55 PDT 2021


Hi Frank,

On 2021-08-04 02:15, Frank Wunderlich wrote:
> Hi,
> 
>> Gesendet: Dienstag, 03. August 2021 um 17:13 Uhr
>> Von: "Sungbo Eo" <mans0n at gorani.run>
>> An: linux-mediatek at lists.infradead.org
>> Cc: "Chunfeng Yun" <chunfeng.yun at mediatek.com>, "Greg Kroah-Hartman" <gregkh at linuxfoundation.org>, "Rob Herring" <robh+dt at kernel.org>, "Matthias Brugger" <matthias.bgg at gmail.com>, "Min Guo" <min.guo at mediatek.com>, "Frank Wunderlich" <frank-w at public-files.de>, devicetree at vger.kernel.org, linux-usb at vger.kernel.org, linux-arm-kernel at lists.infradead.org, linux-kernel at vger.kernel.org, "Sungbo Eo" <mans0n at gorani.run>
>> Betreff: [PATCH 0/2] Add MUSB for MT7623
>>
>> These patches add support for the MUSB controller on Mediatek MT7623.
>> Tested on Mercury RUSH-318AC Wi-Fi router.
>>
>> I got to know this from a BPI-R2 forum post [1], and managed to make it work on OpenWrt snapshot.
>> I'd like to know if this also works on BPI-R2, I can happily share the details if needed.
>> And I've just copy & pasted nodes from mt2701, please let me know if I missed some big differences between SoCs...
>>
>> [1] http://forum.banana-pi.org/t/bpi-r2-otg-port/10551
> 
> thanks for working on it. do both otg-roles (host/client) work on your device?

Yes, I tested it with host mode and device mode.
I also tried manual role-switch via sysfs and it worked with some prior setup.
Note that my device has a USB Type-A connector and not micro B, so I can't help with id pin stuff...

> 
> unfortunately at least host-mode does not work (do not know how to test client mode). i guess because iddig and vusb nodes are missing.
> 
> i took your Patchset and enabled the usb-node for bpi-r2.
> 
> +&usb3 {
> +       status = "okay";
> +};
> 
> and added these config-symbols:
> 
> +CONFIG_USB_CONN_GPIO=y
> +CONFIG_USB_MUSB_HDRC=y
> +CONFIG_USB_MUSB_MEDIATEK=y
> +CONFIG_NOP_USB_XCEIV=y
> +CONFIG_USB_CONFIGFS=y
> +#CONFIG_USB_CONFIGFS_MASS_STORAGE=y
> +#CONFIG_PHY_MTK_TPHY=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_MUSB_DUAL_ROLE=y
> +CONFIG_USB_INVENTRA_DMA=y
> 
> btw. imho otg-node should be named usb0 as other dts (kernel 4.4) also use usb0, else i think it's confusing.

You certainly have a point. I'll follow your suggestion. Thanks!

> 
> in my last attempt i had these below usb-node in boards devicetree:
> 
> +       usb_vbus: regulator at 0 {
> +               compatible = "regulator-fixed";
> +               regulator-name = "usb_vbus";
> +               regulator-min-microvolt = <5000000>;
> +               regulator-max-microvolt = <5000000>;
> +               gpio = <&pio 237 GPIO_ACTIVE_HIGH>;
> +               enable-active-high;
> +       };
> +
> +       connector{
> +               compatible = "gpio-usb-b-connector", "usb-b-connector";
> +               type = "micro";
> +               id-gpios = <&pio 44 GPIO_ACTIVE_HIGH>;
> +               vbus-supply = <&usb_vbus>;
> +       };
> 
> after adding these i see the connection of otg-cable with usb-stick in dmesg:
> 
> [   53.656304] usb-conn-gpio 11200000.usb:connector: repeated rot
> [   53.696324] usb-conn-gpio 11200000.usb:connector: repeated role: host
> 
> but usb-stick is not powered (led of the stick is off) and of course i see no mass-storage device.

I observed the same symptom (but different error log).

[    2.722253] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_idle (80, <SessEnd), retry #0, port1 00000104

In my case adding `regulator-always-on;` in the regulator node solved the problem temporarily.
But after that I switched to relying on pinctrl.

+&pio {
+       musb_pins: musb {
+               pins-musb {
+                       pinmux = <MT7623_PIN_237_EXT_SDIO2_FUNC_DRV_VBUS>;
+               };
+       };
+};
+
+&usb3 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&musb_pins>;
+       status = "okay";
+
+       dr_mode = "host";
+
+       connector {
+               compatible = "usb-a-connector";
+       };
+};

root at OpenWrt:~# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=, Driver=usb-storage, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-mtk/1p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-mtk/1p, 480M

I tested device mode with legacy CDC composite device module.
You can also take more complicated configfs approach, though.
https://elinux.org/images/e/ef/USB_Gadget_Configfs_API_0.pdf

+       dr_mode = "host";
-       dr_mode = "peripheral";

root at OpenWrt:/# insmod g_cdc
[   64.565254] using random self ethernet address
[   64.569711] using random host ethernet address
[   64.575966] usb0: HOST MAC 26:36:2d:e5:8f:6f
[   64.580501] usb0: MAC 92:d7:f9:c7:88:01
[   64.584409] g_cdc gadget: CDC Composite Gadget, version: King Kamehameha Day 2008
[   64.592454] g_cdc gadget: g_cdc ready

I also tried usb-role-switch,

-       dr_mode = "host";
+       usb-role-switch;

After boot the initial mode of musb is "none", and it did not turn vbus on even if I set it to host mode.
Later I found out that I need to load any gadget driver before setting it to host mode.

# echo peripheral > /sys/devices/platform/11200000.usb/musb-hdrc.1.auto/mode
# insmod g_cdc
# echo host > /sys/devices/platform/11200000.usb/musb-hdrc.1.auto/mode

That's all I know. Please let me know if I skipped some details.
Thanks.

> 
> and now i'm back on the traceback on power down i've reported Author of musb driver some time ago
> 
> [  156.785185] WARNING: CPU: 0 PID: 1 at drivers/power/reset/mt6323-poweroff.c:4
> [  156.795156] Unable to power off system
> 
> [  156.884496] [<c0cca1ec>] (warn_slowpath_fmt) from [<c090562c>] (mt6323_do_pw)
> [  156.893203]  r8:c3296d40 r7:00000024 r6:0ccccb60 r5:c10fe3d8 r4:00000000
> [  156.900030] [<c09054b0>] (mt6323_do_pwroff) from [<c010ba68>] (machine_power)
> [  156.908558]  r8:fee1dead r7:c1312590 r6:92f61d00 r5:00000000 r4:4321fedc
> [  156.915385] [<c010ba34>] (machine_power_off) from [<c01524bc>] (kernel_power)
> 
> i guess it's related to the usb_vbus.
> 
> regards Frank
> 



More information about the linux-arm-kernel mailing list