All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: "Ondrej Jirman" <megous@megous.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Jernej Škrabec" <jernej.skrabec@gmail.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	linux-serial@vger.kernel.org,
	"Linux ARM Mailing List" <linux-arm-kernel@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Marcel Holtmann" <marcel@holtmann.org>,
	"Johan Hedberg" <johan.hedberg@gmail.com>,
	"Luiz Augusto von Dentz" <luiz.dentz@gmail.com>,
	linux-bluetooth@vger.kernel.org, linux-sunxi@lists.linux.dev
Cc: Josh Triplett <josh@joshtriplett.org>, tuxd3v@sapo.pt
Subject: sunxi: Bluetooth broken since 5.6-rc1
Date: Sun, 30 May 2021 17:34:54 +0100	[thread overview]
Message-ID: <20210530173454.5ab1dcf5@slackpad.fritz.box> (raw)

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 <josh@joshtriplett.org>
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

WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara@arm.com>
To: "Ondrej Jirman" <megous@megous.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Jernej Škrabec" <jernej.skrabec@gmail.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	linux-serial@vger.kernel.org,
	"Linux ARM Mailing List" <linux-arm-kernel@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Marcel Holtmann" <marcel@holtmann.org>,
	"Johan Hedberg" <johan.hedberg@gmail.com>,
	"Luiz Augusto von Dentz" <luiz.dentz@gmail.com>,
	linux-bluetooth@vger.kernel.org, linux-sunxi@lists.linux.dev
Cc: Josh Triplett <josh@joshtriplett.org>, tuxd3v@sapo.pt
Subject: sunxi: Bluetooth broken since 5.6-rc1
Date: Sun, 30 May 2021 17:34:54 +0100	[thread overview]
Message-ID: <20210530173454.5ab1dcf5@slackpad.fritz.box> (raw)

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 <josh@joshtriplett.org>
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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2021-05-30 16:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-30 16:34 Andre Przywara [this message]
2021-05-30 16:34 ` sunxi: Bluetooth broken since 5.6-rc1 Andre Przywara
2021-05-31 13:21 ` Greg Kroah-Hartman
2021-05-31 13:21   ` Greg Kroah-Hartman
2021-05-31 14:41   ` Russell King (Oracle)
2021-05-31 14:41     ` Russell King (Oracle)
2021-06-04 17:13     ` Andre Przywara
2021-06-04 17:13       ` Andre Przywara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210530173454.5ab1dcf5@slackpad.fritz.box \
    --to=andre.przywara@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jirislaby@kernel.org \
    --cc=johan.hedberg@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=megous@megous.com \
    --cc=mripard@kernel.org \
    --cc=tuxd3v@sapo.pt \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.