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

[Frank Wunderlich]

> Gesendet: Mittwoch, 04. August 2021 um 02:14 Uhr
> Von: "Sungbo Eo" <mans0n@xxxxxxxxxx>

> > 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...

> > 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.

i've found out that usb-stick is powered if i first connect otg-cable and then the stick to the cable...regulator always on does not change anything for me (only supporess "disabling vusb" message on boot). traceback on poweroff is still there.

role switch happen on inserting stick into cable, not before (insert cable into r2) as i expected.

need to figure out which CONFIG options i need to get USB-Stick as mass storage working.

i wonder why it works on your board without the vusb/connector subnodes

> +&pio {
> +       musb_pins: musb {
> +               pins-musb {
> +                       pinmux = <MT7623_PIN_237_EXT_SDIO2_FUNC_DRV_VBUS>;
> +               };
> +       };
> +};

imho it's the same gpio used for regulator, right? whats the difference?
i tried this instead of the regulator-node => not powered (cable first, then stick).

> +&usb3 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&musb_pins>;
> +       status = "okay";
> +
> +       dr_mode = "host";
> +
> +       connector {
> +               compatible = "usb-a-connector";
> +       };
> +};
>
> root@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@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
> >
>