Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Lukas Wunner <lukas@wunner.de>]

On Thu, Mar 08, 2018 at 01:02:38AM +0100, Stefan Wahren wrote:
> > >>>>> after applying Loic's patch and the necessary patch for the
> > >>>>> RPi 3 dts file (see below), i will get this output:
> > >>>>> 
> > >>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> > >>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> > >>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> > >>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> > >>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> > >>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> > >>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> > >>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> > >>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> > >>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> > >>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
> > >>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> > >>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> > >>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> > >>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> > >>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> > >>>>> 
> > >>>>> I don't see these errors on RPi Zero W. Maybe the reason for
> > >>>>> this is the lack of hardware flowcontrol on RPi 3.
> > >>>> 
> > >>>> maybe it needs some time after switching the hardware on. Have
> > >>>> you tried to sleep for a bit at the end of bcm_gpio_set_power?
>  
> after applying this patch [1] the RPi 3 specific probing errors disappear.
> 
> But this is only a quick hack. The proper solution would be to extend
> hci_h5 in order to support the BCM43438.
> 
> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881

Users of the MacBookPro13,1 and MacBookPro14,1 are reporting similar
timeouts when the Bluetooth controller is reset on ->setup.

These are the models without touchbar.  The models with touchbar
(MBP13,2, MBP13,3, MBP14,2, MBP14,3) as well as the 12" MacBooks
(MB8,1, MB9,1, MB10,1) do not suffer from this issue.

Christoph Gysin (+cc) reports that applying your patch on 4.16-rc4 gets
Bluetooth working on his MBP13,1:
https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-371434970

For some reason, not toggling the device_wake pin in bcm_gpio_set_power()
also fixed the issue for those users.  They did complain about stuttering
audio though.

Users of the touchbar models reported that stuttering audio only occurs
when the GNOME Bluetooth control panel is open. Closing it made the
stuttering audio go away.  But apparently on the non-touchbar models,
the stuttering persisted regardless.  Both the stuttering audio as well as
the timeouts on ->setup might be explained by a lack of hardware flow
control on those models.  The chipset (and thus the UART) is identical
on the touchbar versus non-touchbar models.  It would seem odd if Apple
did not wire CTS consistently on all models.

Thanks,

Lukas