From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 673C3C47080 for ; Mon, 31 May 2021 15:01:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4451A61008 for ; Mon, 31 May 2021 15:01:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232114AbhEaPCk (ORCPT ); Mon, 31 May 2021 11:02:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:51030 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234142AbhEaPAj (ORCPT ); Mon, 31 May 2021 11:00:39 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4BD3460FEF; Mon, 31 May 2021 14:12:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622470351; bh=wkKztpo64XTQBWAnbxSKsTIGW62NyR1Cw1YrVMh3Z2s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JwYXnjd3T+Uk7jc/j3e+LtOttEOMKrNQ3Jhwc/jfMvZwIox3gh61RW790EEGQq97Z H6IYYS7WEHKkIdW3w6KJhwpWjGordesLIuoarJv/zWjz2MDLgvONdxt6lwXwWLQxna 3dHiLeYJFdnwbfAqM85Uoy2CTK4WyzpUI+hRBa5g= Date: Mon, 31 May 2021 15:21:54 +0200 From: Greg Kroah-Hartman To: Andre Przywara Cc: Ondrej Jirman , Chen-Yu Tsai , Maxime Ripard , Jernej =?utf-8?Q?=C5=A0krabec?= , Jiri Slaby , linux-serial@vger.kernel.org, Linux ARM Mailing List , Linux Kernel Mailing List , Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , linux-bluetooth@vger.kernel.org, linux-sunxi@lists.linux.dev, Josh Triplett , tuxd3v@sapo.pt Subject: Re: sunxi: Bluetooth broken since 5.6-rc1 Message-ID: References: <20210530173454.5ab1dcf5@slackpad.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210530173454.5ab1dcf5@slackpad.fritz.box> Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org 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 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C79B1C47080 for ; Mon, 31 May 2021 14:13:56 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8939661370 for ; Mon, 31 May 2021 14:13:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8939661370 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tnKACqjkLvYJI9y0q0iKGgTqwrT7upgTdt7WNIjD54w=; b=q8558kCLoPtNE5 Ow9jVV+OwhTP4PATdFqb/5sj14Y+UCEE13GUvwIdEhUDdSGCigm4IsD7uGLk8Ie/ZV3ST7/BODOdH 2q5vnlbCdO43/+TMMGPurmzR7ld337aZ/qnOS/4KGHbWSW0UGyaKJZgIshAzyEGwNWRsXcw/YXyqk Cf0gw+ZCYHJ5D1EcSpfLa/IffPFLbG0yqW1U+KAie71RxVq9I7N89RWoDbpzAUSO1QTUULwbaI2hn c/qMJHm33UFBcVLAfL1D1zkBqLQye6tbXSIoroIw8MBibRvJ1H1ZbFw3E+ZCWZX/WCugYHfdVR2sH LZ688Soy3hks5n/ye1Yg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lnieh-00CWfk-61; Mon, 31 May 2021 14:12:35 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lnied-00CWfB-Gu for linux-arm-kernel@lists.infradead.org; Mon, 31 May 2021 14:12:32 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4BD3460FEF; Mon, 31 May 2021 14:12:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1622470351; bh=wkKztpo64XTQBWAnbxSKsTIGW62NyR1Cw1YrVMh3Z2s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JwYXnjd3T+Uk7jc/j3e+LtOttEOMKrNQ3Jhwc/jfMvZwIox3gh61RW790EEGQq97Z H6IYYS7WEHKkIdW3w6KJhwpWjGordesLIuoarJv/zWjz2MDLgvONdxt6lwXwWLQxna 3dHiLeYJFdnwbfAqM85Uoy2CTK4WyzpUI+hRBa5g= Date: Mon, 31 May 2021 15:21:54 +0200 From: Greg Kroah-Hartman To: Andre Przywara Cc: Ondrej Jirman , Chen-Yu Tsai , Maxime Ripard , Jernej =?utf-8?Q?=C5=A0krabec?= , Jiri Slaby , linux-serial@vger.kernel.org, Linux ARM Mailing List , Linux Kernel Mailing List , Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , linux-bluetooth@vger.kernel.org, linux-sunxi@lists.linux.dev, Josh Triplett , tuxd3v@sapo.pt Subject: Re: sunxi: Bluetooth broken since 5.6-rc1 Message-ID: References: <20210530173454.5ab1dcf5@slackpad.fritz.box> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210530173454.5ab1dcf5@slackpad.fritz.box> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210531_071231_600982_2CC5CB9F X-CRM114-Status: GOOD ( 23.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel