Hi,
as recently discovered via IRC discussions, Bluetooth (via UART)
seems to be broken on many (if not all) Allwinner devices using recent
mainline kernels. On *some* occasions it might work, but more often
than not the hci_bcm driver just times out:
....
[ 5.046126] Bluetooth: HIDP socket layer initialized
...
[ 7.809425] Bluetooth: hci0: command 0x0c03 tx timeout
[ 15.969286] Bluetooth: hci0: BCM: Reset failed (-110)
After some guessing, trying, and bisecting I pinned the problem down to:
commit dc56ecb81a0aa46a7e127e916df5c8fdb8364f0b
Author: Josh Triplett [off-list ref]
Date: Fri Jan 10 18:25:13 2020 -0800
serial: 8250: Support disabling mdelay-filled probes of 16550A variants
This seemingly innocent commit shaved off some milliseconds during the
8250 probe, which apparently lets the Bluetooth device trip.
An obvious easy hack-fix is to just define
CONFIG_SERIAL_8250_16550A_VARIANTS, which brings the delays back and
seems to avoid the problem for me.
Another hack which seems to mitigate the problem is to avoid switching
the baudrate to something faster than 115200.
I observed this on a BananaPi-M64 (Allwinner A64 SoC with AP6212 WiFi/BT
chip), but others reported the same issue on a NanoPi Air (Allwinner H3
with 6212), but also other SoCs and devices (at least one AP6210).
Obviously those workarounds are not real solutions, and I was
wondering if anybody has an idea how to properly fix this?
What puzzles me is that the delay is happening during the *UART*
probe, so before we even start dealing with the Bluetooth device.
I see that hci_bcm.c has some history with adding delays, also with
RTS/CTS lines, so does anyone have an idea what's going on here,
exactly, and how to properly fix this problem?
Many thanks,
Andre
On Sun, May 30, 2021 at 05:34:54PM +0100, Andre Przywara wrote:
Hi,
as recently discovered via IRC discussions, Bluetooth (via UART)
seems to be broken on many (if not all) Allwinner devices using recent
mainline kernels. On *some* occasions it might work, but more often
than not the hci_bcm driver just times out:
....
[ 5.046126] Bluetooth: HIDP socket layer initialized
...
[ 7.809425] Bluetooth: hci0: command 0x0c03 tx timeout
[ 15.969286] Bluetooth: hci0: BCM: Reset failed (-110)
After some guessing, trying, and bisecting I pinned the problem down to:
commit dc56ecb81a0aa46a7e127e916df5c8fdb8364f0b
Author: Josh Triplett [off-list ref]
Date: Fri Jan 10 18:25:13 2020 -0800
serial: 8250: Support disabling mdelay-filled probes of 16550A variants
This seemingly innocent commit shaved off some milliseconds during the
8250 probe, which apparently lets the Bluetooth device trip.
What do you mean by "trip"?
And how are the different devices related?
An obvious easy hack-fix is to just define
CONFIG_SERIAL_8250_16550A_VARIANTS, which brings the delays back and
seems to avoid the problem for me.
Another hack which seems to mitigate the problem is to avoid switching
the baudrate to something faster than 115200.
I observed this on a BananaPi-M64 (Allwinner A64 SoC with AP6212 WiFi/BT
chip), but others reported the same issue on a NanoPi Air (Allwinner H3
with 6212), but also other SoCs and devices (at least one AP6210).
Obviously those workarounds are not real solutions, and I was
wondering if anybody has an idea how to properly fix this?
What puzzles me is that the delay is happening during the *UART*
probe, so before we even start dealing with the Bluetooth device.
What type of bluetooth device is this, and what does it have to do with
the serial port? Is the SoC device using the same IP blocks for both?
I see that hci_bcm.c has some history with adding delays, also with
RTS/CTS lines, so does anyone have an idea what's going on here,
exactly, and how to properly fix this problem?
No idea, sorry, as you have the hardware, you have the best chance of
debugging this :(
good luck!
greg k-h
On Mon, May 31, 2021 at 03:21:54PM +0200, Greg Kroah-Hartman wrote:
On Sun, May 30, 2021 at 05:34:54PM +0100, Andre Przywara wrote:
quoted
An obvious easy hack-fix is to just define
CONFIG_SERIAL_8250_16550A_VARIANTS, which brings the delays back and
seems to avoid the problem for me.
Another hack which seems to mitigate the problem is to avoid switching
the baudrate to something faster than 115200.
I observed this on a BananaPi-M64 (Allwinner A64 SoC with AP6212 WiFi/BT
chip), but others reported the same issue on a NanoPi Air (Allwinner H3
with 6212), but also other SoCs and devices (at least one AP6210).
Obviously those workarounds are not real solutions, and I was
wondering if anybody has an idea how to properly fix this?
What puzzles me is that the delay is happening during the *UART*
probe, so before we even start dealing with the Bluetooth device.
What type of bluetooth device is this, and what does it have to do with
the serial port? Is the SoC device using the same IP blocks for both?
Many bluetooth "devices" (I mean the interface from the local machine
to the BT world, not as in remote devices) are connected through a
standard UART. Pictorially, it's:
CPU <---> UART <---> BT chip <---> Bluetooth RF world
The reporter seems to be saying is that a change to the UART driver now
means that the bluetooth chip wired to that UART no longer functions due
to slightly different initialisation timings of the host UART.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, 31 May 2021 15:41:36 +0100
"Russell King (Oracle)" [off-list ref] wrote:
Hi Greg,
On Mon, May 31, 2021 at 03:21:54PM +0200, Greg Kroah-Hartman wrote:
quoted
On Sun, May 30, 2021 at 05:34:54PM +0100, Andre Przywara wrote:
quoted
An obvious easy hack-fix is to just define
CONFIG_SERIAL_8250_16550A_VARIANTS, which brings the delays back and
seems to avoid the problem for me.
Another hack which seems to mitigate the problem is to avoid switching
the baudrate to something faster than 115200.
I observed this on a BananaPi-M64 (Allwinner A64 SoC with AP6212 WiFi/BT
chip), but others reported the same issue on a NanoPi Air (Allwinner H3
with 6212), but also other SoCs and devices (at least one AP6210).
Obviously those workarounds are not real solutions, and I was
wondering if anybody has an idea how to properly fix this?
What puzzles me is that the delay is happening during the *UART*
probe, so before we even start dealing with the Bluetooth device.
What type of bluetooth device is this, and what does it have to do with
the serial port? Is the SoC device using the same IP blocks for both?
Many bluetooth "devices" (I mean the interface from the local machine
to the BT world, not as in remote devices) are connected through a
standard UART. Pictorially, it's:
CPU <---> UART <---> BT chip <---> Bluetooth RF world
The reporter seems to be saying is that a change to the UART driver now
means that the bluetooth chip wired to that UART no longer functions due
to slightly different initialisation timings of the host UART.
Yes, exactly, thanks Russell for clarifying this.
How this works (when it does) is that the UART driver probes, then we
look at the children of the UART devicetree node, to probe for those, by
virtue of the serdev bus.
My question was about if this rings a bell with someone, because I have
a hard time piecing together how a delay in the *UART probe* could
affect devices depending on it. And how to fix this ...
Cheers,
Andre