* Re: [linux-sunxi] Allwinner A40i USB-OTG host GPIO pin ID interrupt doesn't run handler
[not found] <CAKoaSuT7Juvff7Rt8TDmAof9sOZ-C_okTY34s4rkLZ+7Jt=X8Q@mail.gmail.com>
@ 2023-12-21 17:14 ` Andre Przywara
2024-01-12 7:22 ` Сергей Мосолов
0 siblings, 1 reply; 2+ messages in thread
From: Andre Przywara @ 2023-12-21 17:14 UTC (permalink / raw)
To: Сергей Мосолов
Cc: linux-sunxi, linux-sunxi@lists.linux.dev
On Thu, 21 Dec 2023 11:24:57 +0400
Сергей Мосолов <mosolovs1987@gmail.com> wrote:
(adding the proper sunxi mailing list for a wider audience)
Hi Sergej,
> I kindly ask for an advice about interrupt working with USB-OTG usb0 on
> Allwinner A40i.
> I need to make work usb0 as USB-OTG.
>
> Looks like it's possible somehow:
> https://lore.kernel.org/linux-arm-kernel/daf5c543-a1d1-04d2-6486-6cc9cd72d8e5@sholland.org/T/#md5e9ce01feb201041467c136f09e80628f414557
>
> I've used usb-phy driver with support of muxing ohci0(host) and
> usb0(client) on usb0 pins, mentioned in the link above:
> https://github.com/wirenboard/linux/blob/dev/v5.10.y/drivers/phy/allwinner/phy-sun4i-usb.c
some good checking and detective work!
I am afraid the problem is somewhere deeper, though, in the way our sunxi
PHY interacts with the OTG framework. I actually believe it's broken
for every Allwinner system at the moment. Some months ago I spent some
time in the code, and it looks like there is some race between the
OHCI/EHCI controllers and the MUSB controller for the PHY. Both the MUSB
and the HCI drivers claim the PHY and set their preferred mode (OTG and
host, respectively), but if I remember correctly, the HCI driver always
wins, regardless of the order. I can't remember exactly, but I think the
problem was in sun4i_usb_phy_set_mode. You can try to insert debug
messages there to see what's going on.
The short summary at the moment seems to be: forcing the mode (peripheral
or host) works, but the dynamic switching does not.
You might want to try disabling the ehci0/ohci0 nodes, as a quick check, to
see if that improves thing. I haven't tried that, though, as doing so is
not correct and breaks U-Boot.
Also keep an eye on the interrupt counter in /proc/interrupts, you should
see some non-zero number if you connect and disconnect the cable a few
times. But if the PHY is in host mode, then it won't activate the IRQ, I
believe.
Пока,
Andre
> In my case I have pin ID USB OTG = PI11.
>
> Some excerpts from my dts file:
> [quote]
> / {
> ...
> /* ohci0 and ehci0 need to be included to work with USB OTG */
> ohci0: usb@1c14400 {
> compatible = "allwinner,sun8i-r40-ohci", "generic-ohci";
> reg = <0x01c14400 0x100>;
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>,
> <&ccu CLK_USB_OHCI0>;
> resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
> status = "okay";
> };
>
> ehci0: usb@1c14000 {
> compatible = "allwinner,sun8i-r40-ehci", "generic-ehci";
> reg = <0x01c14000 0x100>;
> interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>;
> resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
> status = "okay";
> };
> ...
> }
> ...
> &usb_otg {
> /* в dtsi defines of usb_otg as dr_mode = "peripheral"; */
> status = "okay";
> };
>
> &usbphy {
> dr_mode = "otg";
> usb0_id_det-gpios = <PIN_PI 11 GPIO_ACTIVE_HIGH>;
> usb0_vbus-supply = <®_vcc5v0>;
> status = "okay";
> };
> [/quote]
>
> USB-OTG works, but the problem is USB-OTG reads pin ID and choose client or
> host only on OS startup once.
>
> After adding many printk and -DDEBUG for several subsystems it seems to me
> that the problem is PI11 GPIO irq just doesn't run it's handler requested
> here:
> https://github.com/wirenboard/linux/blob/dev/v5.10.y/drivers/phy/allwinner/phy-sun4i-usb.c#L951
>
> I observed EINT23 registration in pinctrl sunxi driver:
> [quote]
> [ 11.578919] sun4i-pinctrl 1c20800.pinctrl: 1c20800.pinctrl: request IRQ
> for GPIO 267, return 23
> [ 11.587657] devm_request_irq data->id_det_irq: 74, ret: 0
>
> 74: 0 0 0 0 sunxi_pio_edge 23 Edge
> usb0-id-det
>
> # cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 26: 0 0 0 0 GICv2 54 Level
> timer@1c20c00
> 27: 0 0 0 0 GICv2 29 Level
> arch_timer
> 28: 198416 45783 21540 10341 GICv2 30 Level
> arch_timer
> 31: 0 0 0 0 GICv2 152 Level
> arm-pmu
> 32: 0 0 0 0 GICv2 153 Level
> arm-pmu
> 33: 0 0 0 0 GICv2 154 Level
> arm-pmu
> 34: 0 0 0 0 GICv2 155 Level
> arm-pmu
> 35: 0 0 0 0 GICv2 59 Level
> 1c02000.dma-controller
> 37: 0 0 0 0 GICv2 102 Level
> gpmmu
> 38: 0 0 0 0 GICv2 104 Level
> ppmmu0
> 39: 0 0 0 0 GICv2 107 Level
> ppmmu1
> 40: 175 0 0 0 GICv2 101 Level gp
> 41: 128 0 0 0 GICv2 103 Level pp0
> 42: 128 0 0 0 GICv2 106 Level pp1
> 43: 0 0 0 0 GICv2 71 Level
> ehci_hcd:usb1
> 44: 0 0 0 0 GICv2 72 Level
> ohci_hcd:usb2
> 45: 1289 0 0 0 GICv2 61 Level
> sun4i-ts
> 46: 0 0 0 0 GICv2 56 Level
> 1c20400.rtc
> 47: 0 0 0 0 GICv2 125 Level
> 1400000.deinterlace
> 48: 0 0 0 0 GICv2 126 Level
> sun8i-ce-ns
> 49: 0 0 0 0 GICv2 85 Level
> 1c0e000.video-codec
> 74: 0 0 0 0 sunxi_pio_edge 23 Edge
> usb0-id-det
> 83: 28 0 0 0 GICv2 33 Level
> ttyS0
> 84: 0 0 0 0 GICv2 44 Level
> sun6i-spi
> 85: 80306 0 0 0 GICv2 39 Level
> mv64xxx_i2c
> 86: 0 0 0 0 sunxi-nmi 0 Level
> axp22x_irq_chip
> 109: 0 0 0 0 axp22x_irq_chip 22 Edge
> axp20x-pek-dbr
> 110: 0 0 0 0 axp22x_irq_chip 23 Edge
> axp20x-pek-dbf
> 113: 0 0 0 0 GICv2 40 Level
> mv64xxx_i2c
> 114: 0 0 0 0 GICv2 41 Level
> mv64xxx_i2c
> 115: 0 0 0 0 GICv2 120 Level
> mv64xxx_i2c
> 116: 0 0 0 0 GICv2 121 Level
> mv64xxx_i2c
> 117: 0 0 0 0 GICv2 129 Level
> tvd0
> 118: 0 0 0 0 GICv2 130 Level
> tvd1
> 119: 0 0 0 0 GICv2 131 Level
> tvd2
> 120: 0 0 0 0 GICv2 132 Level
> tvd3
> 121: 10281 0 0 0 GICv2 68 Level ths
> 122: 245 0 0 0 GICv2 66 Level
> sunxi-mmc
> 123: 5690 0 0 0 GICv2 64 Level
> sunxi-mmc
> 129: 0 0 0 0 GICv2 88 Level
> ahci-sunxi[1c18000.sata]
> 130: 168336 0 0 0 GICv2 87 Level
> eth0
> 131: 81204 0 0 0 GICv2 117 Level
> eth1
> 132: 401 0 0 0 GICv2 70 Level
> musb-hdrc.2.auto
> 133: 0 0 0 0 GICv2 96 Level
> ohci_hcd:usb3
> 134: 0 0 0 0 GICv2 97 Level
> ohci_hcd:usb4
> 135: 9114 0 0 0 GICv2 76 Level
> 1c71000.lcd-controller
> 136: 13939 0 0 0 GICv2 83 Level
> 1c73000.lcd-controller
> 137: 515 0 0 0 GICv2 90 Level
> 1ee0000.hdmi
> 138: 0 0 0 0 GICv2 110 Level
> ehci_hcd:usb5
> 139: 0 0 0 0 GICv2 108 Level
> ehci_hcd:usb6
> IPI0: 0 0 0 0 CPU wakeup interrupts
> IPI1: 0 0 0 0 Timer broadcast
> interrupts
> IPI2: 71 81 134 106 Rescheduling interrupts
> IPI3: 5850 17893 6323 6836 Function call interrupts
> IPI4: 0 0 0 0 CPU stop interrupts
> IPI5: 16353 2205 1054 417 IRQ work interrupts
> IPI6: 0 0 0 0 completion interrupts
> Err: 0
> [/quote]
>
> I've reconfigured PI11 as GPIO and I've observed change of input state on
> USB-OTG cable.
> External interrupt is possible on PI11 - PI11/SPI0_CLK/UART5_RX/EINT23 -
> everything else is turned of like spi0 or routed to different pins as uart5.
>
> Link to syslog excerpts and dts with dtsi:
> https://disk.yandex.ru/d/0H5tnCl1qQIE2g
>
> I really appreciate an advice with links to how debug that.
>
> Please, notify my if I can provide some additional info.
>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [linux-sunxi] Allwinner A40i USB-OTG host GPIO pin ID interrupt doesn't run handler
2023-12-21 17:14 ` [linux-sunxi] Allwinner A40i USB-OTG host GPIO pin ID interrupt doesn't run handler Andre Przywara
@ 2024-01-12 7:22 ` Сергей Мосолов
0 siblings, 0 replies; 2+ messages in thread
From: Сергей Мосолов @ 2024-01-12 7:22 UTC (permalink / raw)
To: linux-sunxi
(just mentioned that another mailing list was added, I'm not sure what
I'm doing but I've resend the message to <linux-sunxi@lists.linux.dev>
in case that it can help anyone else, excuse me please for duplicate
email, googlegroups ui too complicated for me but it looks like
response from googlegroups from webui was sended only to
linux-sunxi@googlegroups.com ignoring <linux-sunxi@lists.linux.dev>
email)
Hi Andre!
Thanks for sharing that info.
Actually the problem was that the GPIO interrupts not working, there
just no irq 60 (PIO) generated for some reason at all, at any EXTI
PIN.
After conforming to recommendation in A40i datasheet:
"(24).A 10MOhm resister is connected in parallel between X32KOUT and
X32KIN, the resistor can create negative feedback in an inverter to
ensure amplifier in linear amplifier region."
GPIO interrupts start working and, in particular, USB OTG PIN
correctly detects Host or Client connected. I've used mentioned above:
https://github.com/wirenboard/linux/blob/dev/v5.10.y/drivers/phy/allwinner/phy-sun4i-usb.c
and during quick test it looks to me that USB OTG is fully worked now.
Bye, wish you all the best! Thanks again!
On Thu, Dec 21, 2023 at 9:14 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Thu, 21 Dec 2023 11:24:57 +0400
> Сергей Мосолов <mosolovs1987@gmail.com> wrote:
>
> (adding the proper sunxi mailing list for a wider audience)
>
> Hi Sergej,
>
> > I kindly ask for an advice about interrupt working with USB-OTG usb0 on
> > Allwinner A40i.
> > I need to make work usb0 as USB-OTG.
> >
> > Looks like it's possible somehow:
> > https://lore.kernel.org/linux-arm-kernel/daf5c543-a1d1-04d2-6486-6cc9cd72d8e5@sholland.org/T/#md5e9ce01feb201041467c136f09e80628f414557
> >
> > I've used usb-phy driver with support of muxing ohci0(host) and
> > usb0(client) on usb0 pins, mentioned in the link above:
> > https://github.com/wirenboard/linux/blob/dev/v5.10.y/drivers/phy/allwinner/phy-sun4i-usb.c
>
> some good checking and detective work!
>
> I am afraid the problem is somewhere deeper, though, in the way our sunxi
> PHY interacts with the OTG framework. I actually believe it's broken
> for every Allwinner system at the moment. Some months ago I spent some
> time in the code, and it looks like there is some race between the
> OHCI/EHCI controllers and the MUSB controller for the PHY. Both the MUSB
> and the HCI drivers claim the PHY and set their preferred mode (OTG and
> host, respectively), but if I remember correctly, the HCI driver always
> wins, regardless of the order. I can't remember exactly, but I think the
> problem was in sun4i_usb_phy_set_mode. You can try to insert debug
> messages there to see what's going on.
> The short summary at the moment seems to be: forcing the mode (peripheral
> or host) works, but the dynamic switching does not.
>
> You might want to try disabling the ehci0/ohci0 nodes, as a quick check, to
> see if that improves thing. I haven't tried that, though, as doing so is
> not correct and breaks U-Boot.
> Also keep an eye on the interrupt counter in /proc/interrupts, you should
> see some non-zero number if you connect and disconnect the cable a few
> times. But if the PHY is in host mode, then it won't activate the IRQ, I
> believe.
>
> Пока,
> Andre
>
> > In my case I have pin ID USB OTG = PI11.
> >
> > Some excerpts from my dts file:
> > [quote]
> > / {
> > ...
> > /* ohci0 and ehci0 need to be included to work with USB OTG */
> > ohci0: usb@1c14400 {
> > compatible = "allwinner,sun8i-r40-ohci", "generic-ohci";
> > reg = <0x01c14400 0x100>;
> > interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>,
> > <&ccu CLK_USB_OHCI0>;
> > resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
> > status = "okay";
> > };
> >
> > ehci0: usb@1c14000 {
> > compatible = "allwinner,sun8i-r40-ehci", "generic-ehci";
> > reg = <0x01c14000 0x100>;
> > interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>;
> > resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
> > status = "okay";
> > };
> > ...
> > }
> > ...
> > &usb_otg {
> > /* в dtsi defines of usb_otg as dr_mode = "peripheral"; */
> > status = "okay";
> > };
> >
> > &usbphy {
> > dr_mode = "otg";
> > usb0_id_det-gpios = <PIN_PI 11 GPIO_ACTIVE_HIGH>;
> > usb0_vbus-supply = <®_vcc5v0>;
> > status = "okay";
> > };
> > [/quote]
> >
> > USB-OTG works, but the problem is USB-OTG reads pin ID and choose client or
> > host only on OS startup once.
> >
> > After adding many printk and -DDEBUG for several subsystems it seems to me
> > that the problem is PI11 GPIO irq just doesn't run it's handler requested
> > here:
> > https://github.com/wirenboard/linux/blob/dev/v5.10.y/drivers/phy/allwinner/phy-sun4i-usb.c#L951
> >
> > I observed EINT23 registration in pinctrl sunxi driver:
> > [quote]
> > [ 11.578919] sun4i-pinctrl 1c20800.pinctrl: 1c20800.pinctrl: request IRQ
> > for GPIO 267, return 23
> > [ 11.587657] devm_request_irq data->id_det_irq: 74, ret: 0
> >
> > 74: 0 0 0 0 sunxi_pio_edge 23 Edge
> > usb0-id-det
> >
> > # cat /proc/interrupts
> > CPU0 CPU1 CPU2 CPU3
> > 26: 0 0 0 0 GICv2 54 Level
> > timer@1c20c00
> > 27: 0 0 0 0 GICv2 29 Level
> > arch_timer
> > 28: 198416 45783 21540 10341 GICv2 30 Level
> > arch_timer
> > 31: 0 0 0 0 GICv2 152 Level
> > arm-pmu
> > 32: 0 0 0 0 GICv2 153 Level
> > arm-pmu
> > 33: 0 0 0 0 GICv2 154 Level
> > arm-pmu
> > 34: 0 0 0 0 GICv2 155 Level
> > arm-pmu
> > 35: 0 0 0 0 GICv2 59 Level
> > 1c02000.dma-controller
> > 37: 0 0 0 0 GICv2 102 Level
> > gpmmu
> > 38: 0 0 0 0 GICv2 104 Level
> > ppmmu0
> > 39: 0 0 0 0 GICv2 107 Level
> > ppmmu1
> > 40: 175 0 0 0 GICv2 101 Level gp
> > 41: 128 0 0 0 GICv2 103 Level pp0
> > 42: 128 0 0 0 GICv2 106 Level pp1
> > 43: 0 0 0 0 GICv2 71 Level
> > ehci_hcd:usb1
> > 44: 0 0 0 0 GICv2 72 Level
> > ohci_hcd:usb2
> > 45: 1289 0 0 0 GICv2 61 Level
> > sun4i-ts
> > 46: 0 0 0 0 GICv2 56 Level
> > 1c20400.rtc
> > 47: 0 0 0 0 GICv2 125 Level
> > 1400000.deinterlace
> > 48: 0 0 0 0 GICv2 126 Level
> > sun8i-ce-ns
> > 49: 0 0 0 0 GICv2 85 Level
> > 1c0e000.video-codec
> > 74: 0 0 0 0 sunxi_pio_edge 23 Edge
> > usb0-id-det
> > 83: 28 0 0 0 GICv2 33 Level
> > ttyS0
> > 84: 0 0 0 0 GICv2 44 Level
> > sun6i-spi
> > 85: 80306 0 0 0 GICv2 39 Level
> > mv64xxx_i2c
> > 86: 0 0 0 0 sunxi-nmi 0 Level
> > axp22x_irq_chip
> > 109: 0 0 0 0 axp22x_irq_chip 22 Edge
> > axp20x-pek-dbr
> > 110: 0 0 0 0 axp22x_irq_chip 23 Edge
> > axp20x-pek-dbf
> > 113: 0 0 0 0 GICv2 40 Level
> > mv64xxx_i2c
> > 114: 0 0 0 0 GICv2 41 Level
> > mv64xxx_i2c
> > 115: 0 0 0 0 GICv2 120 Level
> > mv64xxx_i2c
> > 116: 0 0 0 0 GICv2 121 Level
> > mv64xxx_i2c
> > 117: 0 0 0 0 GICv2 129 Level
> > tvd0
> > 118: 0 0 0 0 GICv2 130 Level
> > tvd1
> > 119: 0 0 0 0 GICv2 131 Level
> > tvd2
> > 120: 0 0 0 0 GICv2 132 Level
> > tvd3
> > 121: 10281 0 0 0 GICv2 68 Level ths
> > 122: 245 0 0 0 GICv2 66 Level
> > sunxi-mmc
> > 123: 5690 0 0 0 GICv2 64 Level
> > sunxi-mmc
> > 129: 0 0 0 0 GICv2 88 Level
> > ahci-sunxi[1c18000.sata]
> > 130: 168336 0 0 0 GICv2 87 Level
> > eth0
> > 131: 81204 0 0 0 GICv2 117 Level
> > eth1
> > 132: 401 0 0 0 GICv2 70 Level
> > musb-hdrc.2.auto
> > 133: 0 0 0 0 GICv2 96 Level
> > ohci_hcd:usb3
> > 134: 0 0 0 0 GICv2 97 Level
> > ohci_hcd:usb4
> > 135: 9114 0 0 0 GICv2 76 Level
> > 1c71000.lcd-controller
> > 136: 13939 0 0 0 GICv2 83 Level
> > 1c73000.lcd-controller
> > 137: 515 0 0 0 GICv2 90 Level
> > 1ee0000.hdmi
> > 138: 0 0 0 0 GICv2 110 Level
> > ehci_hcd:usb5
> > 139: 0 0 0 0 GICv2 108 Level
> > ehci_hcd:usb6
> > IPI0: 0 0 0 0 CPU wakeup interrupts
> > IPI1: 0 0 0 0 Timer broadcast
> > interrupts
> > IPI2: 71 81 134 106 Rescheduling interrupts
> > IPI3: 5850 17893 6323 6836 Function call interrupts
> > IPI4: 0 0 0 0 CPU stop interrupts
> > IPI5: 16353 2205 1054 417 IRQ work interrupts
> > IPI6: 0 0 0 0 completion interrupts
> > Err: 0
> > [/quote]
> >
> > I've reconfigured PI11 as GPIO and I've observed change of input state on
> > USB-OTG cable.
> > External interrupt is possible on PI11 - PI11/SPI0_CLK/UART5_RX/EINT23 -
> > everything else is turned of like spi0 or routed to different pins as uart5.
> >
> > Link to syslog excerpts and dts with dtsi:
> > https://disk.yandex.ru/d/0H5tnCl1qQIE2g
> >
> > I really appreciate an advice with links to how debug that.
> >
> > Please, notify my if I can provide some additional info.
> >
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-01-12 7:22 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAKoaSuT7Juvff7Rt8TDmAof9sOZ-C_okTY34s4rkLZ+7Jt=X8Q@mail.gmail.com>
2023-12-21 17:14 ` [linux-sunxi] Allwinner A40i USB-OTG host GPIO pin ID interrupt doesn't run handler Andre Przywara
2024-01-12 7:22 ` Сергей Мосолов
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox