New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bluetooth Problem #29

Open
peterychuang opened this Issue Aug 5, 2017 · 203 comments

Comments

@peterychuang
Contributor

peterychuang commented Aug 5, 2017

So I was poking around the Bluetooth, and I noticed that the DSDT contains this:

If (!OSDW ())
{
    Return (UBUF) /* \_SB_.PCI0.URT0.BLTH._CRS.UBUF */
}

Return (ABUF) /* \_SB_.PCI0.URT0.BLTH._CRS.ABUF */

This might be a stupid question, but isn't this bit the same as the SPI stuff that used to require patching to get the keyboard and touchpad working?

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Aug 5, 2017

@peterychuang The question is far from stupid: you're quite right, this looks very much like SPI stuff and it looks like it would benefit from the generic apple-properties work @l1k has done.

However, on closer examination it turns out the issue is not the missing acpi serial-bus resource, but the missing interrupt information: there's neither an interrupt-resource in the _CRS, nor is there a _GPE name like there is for the SPI device, and hence we get these hci_bcm errors in dmesg:

hci_bcm BCM2E7C:00: BCM irq: -22
hci_bcm BCM2E7C:00: invalid platform data
hci_bcm: probe of BCM2E7C:00 failed with error -22

In fact, I can't find any interrupt info whatsoever for the bluetooth device in the DSDT.

So the first thing to get bluetooth running is to figure out what interrupt it uses. After that, we'll need some small patches to set the oper_speed from the baud apple property, and probably something to call the power-down, power-up, etc acpi methods appropriately (however, I know next to nothing about bluetooth and their drivers in Linux, so take this with a large grain of salt).

@l1k

This comment has been minimized.

l1k commented Aug 6, 2017

Yes I did mention in the commit message of l1k/linux@9ae5c93 that it'll be needed for Bluetooth as well. :-)

Looking at the schematics of the MacBook8,1 I can't find a Bluetooth interrupt pin and apparently none is needed. A quick Google search turns up this:

To a host system, the UART appears as an 8-bit input and output port that it can read from and write to. Whenever the host has data to be sent, it just sends these data to the UART in byte format (8-bit wide), whenever the UART receives data from another serial device it will buffer these data in its FIFO (again 8-bit wide), then it will indicate the availability of these data to the host through an internal register bit, or through a hardware interrupt signal.

So the interrupt is coming from the UART on behalf of the Bluetooth device once data is received into the FIFO.

What's much more interesting are the power management methods which could be used to extend battery life:

  • BTPU = BlueTooth Power Up
  • BTPD = BlueTooth Power Down
  • BTRS = BlueTooth Reset (power down followed by power up)
  • BTLP = BlueTooth Low Power (takes argument 0 or 1, apparently toggles sleep mode)

The MBP13,3 has an additional BTRB method. No idea. The methods are called from IOBluetoothHostControllerUARTTransport.kext and various others.

@l1k

This comment has been minimized.

l1k commented Aug 6, 2017

Ah looking at hci_bcm.c I realize this is not about an interrupt for data reception but for host wakeup. On the MB8,1 that pin is called SMC_PME_S4_WAKE_L and goes into the SMC, the SMC then wakes the system. So this happens transparently to the OS on MacBooks and the driver need not care about it.

The invalid platform data error is emitted because neither the device_wakeup nor shutdown GPIO descriptors are set. On MacBooks the driver should instead detect presence of the BTLP and BTPD/BTPU methods. The BTLP method should be called for device wakeup and BTPD/BTPU for shutdown. The driver should cache the ACPI handles of the methods on probe and invoke them from bcm_gpio_set_power(), bcm_suspend_device() and bcm_resume_device().

Actually this looks fairly straightforward.

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Aug 6, 2017

Ah, silly me, didn't actually look at who was using the interrupt for what. Ok, that indeed simplifies things then.

Regarding sleep and wakeup, the DSDT seems to indicate that BTLP should be called for both, at least on Windows:

    Method (_PTS, 1, NotSerialized)  // _PTS: Prepare To Sleep
        ...
        If (!OSDW ())
        {
            If (Arg0 == 0x03)
            {
                \_SB.PCI0.URT0.BLTH.BTLP (One)
                Sleep (0x03E8)
                \_SB.PCI0.LPCB.EC.EWPM = One
                \_SB.PCI0.LPCB.EC.EWDK = One
            }
        }
    }

    Method (_WAK, 1, NotSerialized)  // _WAK: Wake
    {
        ...
        If (OSDW ()) {}
        ElseIf (Arg0 == 0x03)
        {
            \_SB.PCI0.URT0.BLTH.BTLP (Zero)
        }
    }

This seems a bit odd, though: I (probably naïvely) would expect the runtime PM (bcm_suspend_device and bcm_resume_device) should be calling BTLP, and the system sleep (bcm_suspend and bcm_resume) to call BTPD/BTPU.

And yes, I haven't been able to figure out what the BTRB method is supposed to be for either.

@l1k

This comment has been minimized.

l1k commented Aug 6, 2017

I guess BTLP puts the device in a low power state and enables wakeup. Based on the DSDT snippet you included above it seems Apple also wants this to work in sleep state S3, e.g. to wake the system upon key press on a Bluetooth keyboard. Makes sense to me. For some reason BTLP is not called in the DSDT of the MacBook8,1, this might be a bug.

In any case hci_bcm.c calls BTLP both for runtime suspend as well as system sleep, which is in line with what Apple does in the DSDT, so it seems fine to me. The hci_bcm.c driver only toggles the power enable pin (BTPU/BTPD) upon open() and close() of the device, so apparently it's powered down if Bluetooth isn't used at all.

@peterychuang

This comment has been minimized.

Contributor

peterychuang commented Aug 6, 2017

In my machine (14,1), I actually can't find the \_SB.PCI0.URT0.BLTH.BTLP bits @roadrunner2 had.

In case this helps, this is (maybe) all the bluetooth related stuff from DSDT in my machine.

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Aug 6, 2017

The behaviours seem to be a bit all over the map, then: Looking at MacBook8,1 and MacBook9,1 DSDT's I see that _PTS and _WAK call BTPD and BTPU on the 8, respectively, but on the 9 there are no calls to bluetooth there at all, like on the 14,1.

@l1k I'm slightly confused by your 2nd paragraph about hci_bcm.c: are you saying there's already code there that calls these BTxx acpi methods?

@l1k

This comment has been minimized.

l1k commented Aug 7, 2017

Sorry for not being clear, let me try again. :-)

The combined WiFi/BT chip on these machines has 3 GPIO pins of interest for BT power management: power enable (toggled by BTPU/BTPD), device wake (toggled by BTLP, active low) and host wake (going out of the chip and into the SMC for system wake). I meant to say hci_bcm.c already contains all the necessary code to toggle the GPIO pins, however it assumes that the pins are directly toggled by the driver via the GPIO subsystem. That assumption is not correct on Macs where Apple invented their own abstraction (consisting of the three ACPI methods) to hide the specific pins used on the PCH (which may vary between models).

The driver seems to do the right thing by enabling device wake both for runtime suspend as well as system sleep, I wouldn't worry too much about presence or nonpresence of BTLP in _PTS and _WAK. It's possible that they're invoking it from their Bootcamp driver on newer models, or they just forgot to enable BT power saving on Windows.

So all that's needed is to search for the BTPU/BTPD/BTLP methods in the ->probe hook if x86_apple_machine is true, cache them in struct bcm_device and amend all the places where gpiod_set_value() is called to invoke the appropriate ACPI methods (again, if x86_apple_machine is true).

And perhaps it's also necessary to fetch device properties and adjust baud rate etc.

Let me know if my answer is still too cryptic. :-)

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Aug 7, 2017

Thanks for the elaboration. Ok, so that basically matches my thinking.

@l1k

This comment has been minimized.

l1k commented Aug 13, 2017

I don't know if anyone has started working on this, but in case noone has I've cooked up this branch. Top-most commit adds support for Apple's Bluetooth ACPI methods, the three preceding commits are from the spi_properties material queued for 4.14. Perhaps someone can test if this works, I don't have one of the affected machines. Thanks.

@Dunedan

This comment has been minimized.

Owner

Dunedan commented Aug 13, 2017

@l1k: I tried out your patch, but it still doesn't work. In fact it doesn't look different to the behavior before, printing the same error messages @roadrunner2 mentioned above. Any idea how to debug this?

@peterychuang

This comment has been minimized.

Contributor

peterychuang commented Aug 13, 2017

@l1k I can confirm the patch doesn't work. Below is part of the dmesg:

[    7.708006] Bluetooth: Core ver 2.22
[    7.708051] Bluetooth: HCI device and connection manager initialized
[    7.708054] Bluetooth: HCI socket layer initialized
[    7.708056] Bluetooth: L2CAP socket layer initialized
[    7.708063] Bluetooth: SCO socket layer initialized
[    7.712788] Bluetooth: HCI UART driver ver 2.3
[    7.712789] Bluetooth: HCI UART protocol H4 registered
[    7.712790] Bluetooth: HCI UART protocol BCSP registered
[    7.712790] Bluetooth: HCI UART protocol ATH3K registered
[    7.712791] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    7.712817] Bluetooth: HCI UART protocol Intel registered
[    7.717682] dw-apb-uart.2: ttyS0 at MMIO 0x9282b000 (irq = 20, base_baud = 3000000) is a 16550A
[    7.753856] hci_bcm BCM2E7C:00: BCM irq: -22
[    7.753858] hci_bcm BCM2E7C:00: invalid platform data
[    7.753871] hci_bcm: probe of BCM2E7C:00 failed with error -22
[    7.755161] Bluetooth: HCI UART protocol Broadcom registered
[    7.755161] Bluetooth: HCI UART protocol QCA registered
[    7.755162] Bluetooth: HCI UART protocol AG6XX registered
[   10.383828] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   10.383829] Bluetooth: BNEP filters: protocol multicast
[   10.383831] Bluetooth: BNEP socket layer initialized

Edit: some additional error messages while running btattach --bredr /dev/ttyS0 -P bcm

[ 3970.771762] Bluetooth: hci0 command 0xfc45 tx timeout
[ 3978.665055] Bluetooth: hci0: BCM: failed to write clock (-110)
[ 3980.798334] Bluetooth: hci0 command 0x0c03 tx timeout
[ 3988.691712] Bluetooth: hci0: BCM: Reset failed (-110)
@l1k

This comment has been minimized.

l1k commented Aug 13, 2017

@Dunedan @peterychuang: Thanks for testing, looking at the code with a fresh pair of eyeballs I noticed that I had botched the return code of bcm_apple_probe(), it would return 1 on success and the caller was expecting 0 on success. Should be fixed now and I've added a commit on top to emit some debug printks. Thanks!

@peterychuang

This comment has been minimized.

Contributor

peterychuang commented Aug 13, 2017

@l1k unfortunately it's still not working. Here are the error messages, including the new debug messages from your last commit:

[    9.902071] Bluetooth: Core ver 2.22
[    9.902082] Bluetooth: HCI device and connection manager initialized
[    9.902084] Bluetooth: HCI socket layer initialized
[    9.902086] Bluetooth: L2CAP socket layer initialized
[    9.902090] Bluetooth: SCO socket layer initialized
[    9.908164] Bluetooth: HCI UART driver ver 2.3
[    9.908166] Bluetooth: HCI UART protocol H4 registered
[    9.908166] Bluetooth: HCI UART protocol BCSP registered
[    9.908167] Bluetooth: HCI UART protocol ATH3K registered
[    9.908167] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    9.908189] Bluetooth: HCI UART protocol Intel registered
[    9.923770] hci_bcm BCM2E7C:00: BCM irq: -22
[    9.923773] hci_bcm BCM2E7C:00: oper_speed=3000000
[    9.923792] hci_bcm BCM2E7C:00: BCM2E7C:00 device registered.
[    9.944515] Bluetooth: HCI UART protocol Broadcom registered
[    9.944517] Bluetooth: HCI UART protocol QCA registered
[    9.944518] Bluetooth: HCI UART protocol AG6XX registered
[   10.146949] dw-apb-uart.2: ttyS0 at MMIO 0x9282b000 (irq = 20, base_baud = 3000000) is a 16550A
[   12.409042] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   12.409044] Bluetooth: BNEP filters: protocol multicast
[   12.409047] Bluetooth: BNEP socket layer initialized

The invalid platform data seems to have gone.

@l1k

This comment has been minimized.

l1k commented Aug 13, 2017

@peterychuang: Looks good! The BCM irq: -22 message is normal, we just don't need the IRQ on Macs. What exactly is not working?

BTW I notice that the baud rate (3000000) was already reported by dw-apb-uart without this patch. Perhaps it's not necessary to retrieve the baud device property...

@l1k

This comment has been minimized.

l1k commented Aug 13, 2017

Lest I forget, for the folks with a MacBook8,1: There's a peculiarity on that machine where the UART0 is attached not only to the Bluetooth controller, but also to a debug serial port on the SSD. There's a mux to switch the UART lines between the two, controlled by GPIO36 on the PCH. There is no ACPI method to control this pin directly. I assume it's set by the BIOS but there's a possibility that this GPIO needs to be toggled before Bluetooth will work.

This oddity is not present in the MBP13,3 ACPI dump. I don't have any others for these newer machines.

@christophgysin

This comment has been minimized.

Contributor

christophgysin commented Aug 13, 2017

I just tried the patch on a MBP13,1 and the platform error is gone. /sys/class/bluetooth is still empty though.

I added my DSDT in #30 if that's any help.

@peterychuang

This comment has been minimized.

Contributor

peterychuang commented Aug 13, 2017

@l1k At the moment, I'm not sure. On the surface, the behaviour of the the machine remains more or less unchanged, though I guess we're on the right track.

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Aug 13, 2017

I had tried something like this a week ago (well, just disabled the check that caused the error) and also found that /sys/class/bluetooth/ stayed empty - haven't had the time to dig further yet, though.

@peterychuang

This comment has been minimized.

Contributor

peterychuang commented Aug 13, 2017

/sys/class/bluetooth has stuff inside when I run btattach --bredr /dev/ttyS0 -P bcm. Not that bluetooth works in that circumstance though.

@leifliddy

This comment has been minimized.

leifliddy commented Sep 21, 2017

dmesg output from MacBook9,1
**added print statements so I could follow the flow of the driver (start with xxx)

[    4.407901] SELinux:  Class bluetooth_socket not defined in policy.
[    5.039534] Bluetooth: Core ver 2.22
[    5.039548] Bluetooth: HCI device and connection manager initialized
[    5.039551] Bluetooth: HCI socket layer initialized
[    5.039554] Bluetooth: L2CAP socket layer initialized
[    5.039561] Bluetooth: SCO socket layer initialized
[    5.259673] Bluetooth: HCI UART driver ver 2.3
[    5.259674] Bluetooth: HCI UART protocol H4 registered
[    5.259674] Bluetooth: HCI UART protocol BCSP registered
[    5.259690] Bluetooth: HCI UART protocol LL registered
[    5.259690] Bluetooth: HCI UART protocol ATH3K registered
[    5.259691] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    5.259715] Bluetooth: HCI UART protocol Intel registered
[    5.259731] Bluetooth: xxx bcm_probe start...
[    5.259732] Bluetooth: xxx bcm_acpi_probe start...
[    5.259733] Bluetooth: xxx bcm_platform_probe start...
[    5.259852] hci_bcm BCM2E7C:00: BCM irq: -22
[    5.259852] Bluetooth: xxx bcm_apple_probe start...
[    5.259854] hci_bcm BCM2E7C:00: oper_speed=3000000
[    5.259878] Bluetooth: xxx bcm_resource start...
[    5.259880] hci_bcm BCM2E7C:00: BCM2E7C:00 device registered.
[    5.259881] Bluetooth: xxx bcm_apple_set_power 1
[    5.272356] dw-apb-uart.2: ttyS4 at MMIO 0xc182b000 (irq = 21, base_baud = 115200) is a 16550A
[    5.276115] Bluetooth: HCI UART protocol Broadcom registered
[    5.276116] Bluetooth: HCI UART protocol QCA registered
[    5.276117] Bluetooth: HCI UART protocol AG6XX registered
[    5.276118] Bluetooth: HCI UART protocol Marvell registered
[    5.288794] dw-apb-uart.3: ttyS5 at MMIO 0xc182c000 (irq = 20, base_baud = 3000000) is a 16550A
[   46.903513] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   46.903517] Bluetooth: BNEP filters: protocol multicast
[   46.903521] Bluetooth: BNEP socket layer initialized

[root@mac ~]# btattach --bredr /dev/ttyS5 -P bcm
Attaching Primary controller to /dev/ttyS5
Switched line discipline from 0 to 15
Device index 0 attached

[  287.094406] Bluetooth: xxx bcm_open start...
[  287.094420] Bluetooth: (null): hu ffff9a718ec643c0
[  287.094426] Bluetooth: xxx bcm_open mutex_lock
[  287.094429] Bluetooth: xxx bcm_open mutex_unlock
[  287.095790] Bluetooth: xxx bcm_setup start...
[  287.095801] Bluetooth: hci0: hu ffff9a718ec643c0
[  289.149877] Bluetooth: hci0 command 0x0c03 tx timeout
[  297.469902] Bluetooth: hci0: BCM: Reset failed (-110)
[  297.469906] Bluetooth: xxx bcm_setup bcm_initialize return err...

it's failing on this function in hci_bcm.c :
err = btbcm_initialize(hu->hdev, fw_name, sizeof(fw_name));

if you drill down a bit, the function it's actually failing on is the HCI reset function defined in btbcm.c
skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);

**the purpose of this function is to switch the controller into full HCI mode

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Sep 24, 2017

I took another stab at this and got it mostly working, at least on my laptop - see l1k/linux#1.

In addition to the above kernel patches, I am using the following patch (this assumes you have the systemd btattach-bcm@.service):

--- /usr/libexec/bluetooth/btattach-bcm-service.sh.orig	2017-09-12 07:27:30.000000000 -0700
+++ /usr/libexec/bluetooth/btattach-bcm-service.sh	2017-09-22 21:20:17.616533796 -0700
@@ -15,6 +15,12 @@
 BT_DEV="$(readlink -f $BT_DEV)"
 UART_DEV="$(dirname $BT_DEV)"
 
+# Handle intel-lpss UART devices
+DW_DEV=$(ls -d "$UART_DEV"/dw-apb-uart.* 2>/dev/null)
+if [[ -d "$DW_DEV" ]] ; then
+	UART_DEV="$DW_DEV"
+fi
+
 # Stupid GPD-pocket has USB BT with id 0000:0000, but still claims to have
 # an uart attached bt
 if [ "$1" = "BCM2E7E:00" ] && lsusb | grep -q "ID 0000:0000"; then

With this the bluetooth device is automatically attached on boot, and can be manually attached/detached via

sudo systemctl start btattach-bcm@BCM2E7C:00
sudo systemctl stop btattach-bcm@BCM2E7C:00

Of course, already noted by @leifliddy above, you can also just run this command:

sudo btattach --bredr /dev/ttyS5 -P bcm

@leifliddy The reason for the timeout (-110 is -ETIMEDOUT) is the wrong baudrate being used, which is fixed by the 2nd commit in my pull request.

Lastly, some issues I noticed so far:

  • If the gnome bluetooth settings dialog is open, then audio may stutter and file transfers are really slow (I think it's the scanning that it's doing when that dialog is open that is causing this)
  • The following error can be found in the kernel log, but unsure of its significance:
Sep 23 11:21:59 schlepptouch kernel: DMAR: Allocating domain for idma64.2 failed
Sep 23 11:21:59 schlepptouch kernel: ttyS5 - failed to request DMA
  • attaching sometimes still fails with -110 (timeout) - re-attaching generally succeeds (the -16 (EBUSY) error can be ignored)
@peterychuang

This comment has been minimized.

Contributor

peterychuang commented Sep 24, 2017

@roadrunner2 To which kernel version am I supposed to apply the patches? I think because I am playing with linux-next, the patches aren't working just yet.

@christophgysin

This comment has been minimized.

Contributor

christophgysin commented Sep 24, 2017

@peterychuang The patches are on top of https://github.com/l1k/linux/tree/hci_bcm, which is based on 4.13.0-rc4.

@peterychuang

This comment has been minimized.

Contributor

peterychuang commented Sep 24, 2017

@christophgysin thanks. I've made some changes to this commit in order to apply it to linux-next, then I applied the patches by @roadrunner2. I guess I've done something wrong somewhere.

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Sep 24, 2017

@peterychuang, @christophgysin: I've been testing on 4.13.2 and 4.13.3. I also just pushed a hci_bcm-4.13 branch (currently based on v4.13.3) to make it easier to pull.

There have been a few small changes in 4.14 which may affect these patches, besides the fact that the first three in the set from @l1k are not necessary (they are backporting the properties work that is now part of 4.14). I'm looking into redoing the patches for 4.14 and will push another branch when done.

@leifliddy

This comment has been minimized.

leifliddy commented Sep 24, 2017

great work roadrunner2!!! It's working!!!!
I wasn't aware there was a btattach-bcm@.service, it's now working with your patch!

dmesg output from MacBook9,1 (running kernel 4.14-rc1 with l1k's and roadrunner2's bluetooth patches applied)

[    7.242471] Bluetooth: xxx bcm_open start...
[    7.242473] Bluetooth: (null): hu ffff9fcb63f98400
[    7.242473] Bluetooth: xxx bcm_open mutex_lock
[    7.242475] Bluetooth: BCM2E7C:00: xxx bcm_open bcm_gpio_set_power ffff9fcb61992200 true
[    7.242476] Bluetooth: xxx bcm_apple_set_power 1
[    7.256019] Bluetooth: xxx bcm_open mutex_unlock
[    7.258535] Bluetooth: xxx bcm_set_baudrate start...
[    7.258873] Bluetooth: hci0: BCM: failed to write update baudrate (-16)
[    7.258874] Bluetooth: xxx bcm_setup start...
[    7.258875] Bluetooth: hci0: hu ffff9fcb63f98400
[    7.258875] Bluetooth: xxx bcm_setup btbcm_set_bdaddr set
[    7.371575] Bluetooth: hci0: BCM: chip id 92
[    7.376021] Bluetooth: hci0: BCM: features 0x2f
[    7.380905] Bluetooth: hci0: BCM4350C0 UART 37.4 MHz Gamay Murata UHE
[    7.383183] Bluetooth: hci0: BCM (003.001.082) build 1288
[    7.387472] Bluetooth: xxx bcm_setup firmware...
[    7.389561] bluetooth hci0: Direct firmware load for brcm/BCM.hcd failed with error -2
[    7.391364] Bluetooth: hci0: BCM: Patch brcm/BCM.hcd not found
[    7.478187] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    7.480965] Bluetooth: BNEP filters: protocol multicast
[    7.483563] Bluetooth: BNEP socket layer initialized

If I unattach and reattach the bluetooth device. this error disappears:
hci0: BCM: failed to write update baudrate (-16)

my bluetooth manager (blueberry --based on gnome-bluetooth) can now pair my bluetooth mouse + speaker without issue!!
all bluetoothctl functions work as well.

I'm experiencing the same audio stuttering issue while the bluetooth setting window is open.
However, I don't see any of those 'DMAR: Allocating domain for idma64.2 failed' or 'ttyS5 - failed to request DMA' errors in the dmesg output.

hciconfig doesn't show the controller for some reason
[root@mac ~]# hciconfig -a
Can't get device list: Operation not supported

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Sep 25, 2017

I built and tested 4.14-rc2, and pushed as the hci_bcm-4.14 branch. Other than resolving some conflicts, nothing really needed changing. @peterychuang, I suggest resetting your tree and cherry-picking the last 6 commits (v4.14-rc..hci_bcm-4.14). If that still doesn't work, then we'll need at least to see the dmesg output from when you run sudo rmmod hci_uart; sudo modprobe hci_uart dyndbg=+p.

@leifliddy Thanks for testing and feedback. Interesting that you don't see the DMA errors - which chipset exactly provides UART on your MB? (lscpi -nn | grep UART). Also not sure why hciconfig isn't working for you - needless to say it works fine for me.

Lastly, previous to your edit you were talking about firmware loading: I've been ignoring that so far, but I don't really know if there's anything critical there.

@peterychuang

This comment has been minimized.

Contributor

peterychuang commented Sep 25, 2017

thanks @roadrunner2, unfortunately it isn't working.

The strange thing in linux-next, both with and without the patches, is that in dmesg | grep Bluetooth, this is what I find:

[ 1282.752054] Bluetooth: HCI UART driver ver 2.3
[ 1282.752056] Bluetooth: HCI UART protocol H4 registered
[ 1282.752057] Bluetooth: HCI UART protocol BCSP registered
[ 1282.752057] Bluetooth: HCI UART protocol ATH3K registered
[ 1282.752058] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 1282.752088] Bluetooth: HCI UART protocol Intel registered
[ 1282.752088] Bluetooth: HCI UART protocol QCA registered
[ 1282.752089] Bluetooth: HCI UART protocol AG6XX registered

I would think something like Bluetooth: HCI UART protocol Broadcom registered should appear, but nope. In any case, that is perhaps why running sudo btattach --bredr /dev/ttyS0 -P bcm gives me this:

Attaching Primary controller to /dev/ttyS0
Switched line discipline from 0 to 15
Failed to set protocol: Protocol not supported
No controller attached

With the patches, dmesg with dyndbg=+p enabled on hci_uart now has something like these two lines:

[   56.017372] tty ffff880204c39800
[   56.017420] tty ffff880204c39800

If I run sudo btattach --bredr /dev/ttyS0 instead (i.e. without -P bcm, these additional lines appear:

[   65.490535] tty ffff88023dccf800


[   65.490546] hu ffff8802616e5600


[   65.491031] hci0 ffff880204d42000
[   65.491040] hci0: type 1 len 3
[   65.491042] hu ffff8802616e5600 skb ffff88020ca3d700



[   65.577815] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   65.577819] Bluetooth: BNEP filters: protocol multicast
[   65.577825] Bluetooth: BNEP socket layer initialized

Perhaps I have unknowingly done something wrong when I compile the kernel, or perhaps the 2017 machines are slightly different. I haven't got time to investigate it yet.

@christophgysin

This comment has been minimized.

Contributor

christophgysin commented Sep 25, 2017

@peterychuang Maybe you are missing CONFIG_BT_HCIUART_BCM=y?

@bhvr-fmarceau

This comment has been minimized.

bhvr-fmarceau commented Apr 20, 2018

Nvm, I'm back.... Bluetooth audio is sometimes stuttering :\

@Lostish

This comment has been minimized.

Lostish commented May 15, 2018

I can confirm running 4.17-RC5 with christophgysin/linux@026daba "patch" bluetooth works. on 14.1

But when being away from laptop for a while without any active connection ( 1 - 2 hour's ) Trying to pair, the device is shutdown due to device sleep or something similair. And is not working untill reboot.
Need to make some real test before i can confirm anything. But newly rebooted bluetooth works on MacBook 14.1

@Lostish

This comment has been minimized.

Lostish commented May 16, 2018

Few tests, there were no issues with leaving bluetooth "idle" and then adding device. That may be have been i reboot not to my custom compiled kernel.

One note tho, using HSF/HFP profile, the sound works great no stuttering/lag but the quality is headset quality...
A2DP profile has the stuttering/lag thing everyone talking about, if that may be profile or driver related?? Dunno.
Thats my 2 cents

@Dunedan

This comment has been minimized.

Owner

Dunedan commented May 27, 2018

As @l1k is apparently busy with other stuff, it'd be awesome if somebody else (preferably somebody who owns a MacBookPro13,1 or MacBookPro14,1) would volunteer to put in the effort to get the necessary change to make Bluetooth work out of the box for the MacBookPro13,1 and MacBookPro14,1 upstreamed.

@tudorbarascu

This comment has been minimized.

Contributor

tudorbarascu commented May 27, 2018

@Dunedan I have a 13,1 with Debian installed, do I need to test anything or what should I do?

@Dunedan

This comment has been minimized.

Owner

Dunedan commented May 27, 2018

Bluetooth in the MacBookPro13,1 and MacBookPro14,1 doesn't work out of the box using the mainstream Linux kernel. As mentioned in the comments above, there are two patches, which provide two separate ways to get it working. One of these patches now has to be submitted for inclusion into the Linux kernel (probably best via the linux-bluetooth mailinglist), so one doesn't have to patch the kernel to get Bluetooth working. That's something somebody has to do and take responsibility for until the fix landed in the Linux kernel.

@christophgysin

This comment has been minimized.

Contributor

christophgysin commented May 27, 2018

I don't think either of these patches will be accepted upstream. They are just hacks to make the driver work for one particular hardware. Maybe @l1k could give some guidance how to get this last piece into the mainline kernel?

@kooskaspers

This comment has been minimized.

kooskaspers commented Jun 21, 2018

I'm facing the same problems @Dunedan describes above on my MacbookPro13,1.
When I try to bring it up with:

hciconfig hci0 up

I get:
Can't init device hci0: Connection timed out (110)

Can't find any blocks either:

$ sudo rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

The problem doesn't persist after every reboot, it's like around 50% of the time.

Would like to try one of those 2 workarounds (remove set_device_wakeup or msleep(15)) but have no experience at all if it comes to applying patches to my kernel (4.16.16-300.fc28.x86_64).
Where can I find any documentation on this?

atenart added a commit to MarvellEmbeddedProcessors/mainline-public that referenced this issue Jul 11, 2018

serial: 8250_dw: Revert "Improve clock rate setting"
The commit

  de9e33b ("serial: 8250_dw: Improve clock rate setting")

obviously tries to cure symptoms, and not a root cause.

The root cause is the non-flexible rate calculation inside the
corresponding clock driver. What we need is to provide maximum UART
divisor value to the clock driver to allow it do the job transparently
to the caller.

Since from the initial commit message I have got no clue which clock
driver actually needs to be amended, I leave this exercise to the people
who know better the case.

Moreover, it seems [1] the fix introduced a regression. And possible
even one more [2].

Taking above, revert the commit de9e33b for now.

[1]: https://www.spinics.net/lists/linux-serial/msg28872.html
[2]: Dunedan/mbp-2016-linux#29 (comment)

Fixes: de9e33b ("serial: 8250_dw: Improve clock rate setting")
Cc: stable <stable@vger.kernel.org> # 4.15
Cc: Ed Blake <ed.blake@sondrel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@Dunedan

This comment has been minimized.

Owner

Dunedan commented Sep 20, 2018

Any news regarding the Bluetooth support for the MacBookPro13,1/14,1? I guess it's not working with an upstream kernel yet without one of the patches mentioned above. Still nobody interested in getting the necessary changes for the MacBookPro13,1/14,1 upstream?

@mrdev023

This comment has been minimized.

mrdev023 commented Oct 2, 2018

I'm get same error on linux 4.18.11 of @kooskaspers link

with the patch already present on it

--- a/drivers/nvme/host/pci.c   2017-01-22 21:49:03.710949755 -0800
+++ b/drivers/nvme/host/pci.c   2017-01-22 21:49:23.490761505 -0800
@@ -2121,6 +2121,7 @@
                .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
        { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xffffff) },
        { PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001) },
+       { PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2003) },
        { 0, }
 };
 MODULE_DEVICE_TABLE(pci, nvme_id_table);

And

$ grep CONFIG_BT_HCIUART_BCM= /boot/config-`uname -r`

i get
CONFIG_BT_HCIUART_BCM=y
@Dunedan

This comment has been minimized.

Owner

Dunedan commented Oct 5, 2018

@mrdev023 The patch you mentioned isn't related to Bluetooth at all, but to detecting the NVMe controller properly. It's also already included upstream since Linux 4.11.

@nedclimaterisk

This comment has been minimized.

nedclimaterisk commented Oct 7, 2018

The readme says that bluetooth is working on all models from kernel 4.16, but I have tried kernels 4.16.0 and 4.18.12, from http://kernel.ubuntu.com/~kernel-ppa/mainline/, and bluetooth doesn't seem to work on either on this MBP 14,1. Maybe the README should be updated to say that bluetooth doesn't work out of the box?

@Dunedan

This comment has been minimized.

Owner

Dunedan commented Oct 7, 2018

@nedclimaterisk It already does. You should probably read it more carefully. 😉

@tomaytotomato

This comment has been minimized.

tomaytotomato commented Oct 23, 2018

I am on 4.18.0-10-generic and I cannot get Bluetooth to work on MBP 13,2

Any ideas or advice how to get it working, I have never done a kernel patch before.

@roadrunner2

This comment has been minimized.

Contributor

roadrunner2 commented Oct 23, 2018

@tomaytotomato If you have a 13,2 (i.e. with touchbar) then no patching is needed. At the kernel level, check if the btbcm, hci_uart, and bluetooth modules are loaded (or possibly built-in) - relevant kernel configs that need to enabled are (at least) CONFIG_BT, CONFIG_BT_BCM, CONFIG_BT_HCIUART, CONFIG_BT_HCIUART_SERDEV, and CONFIG_BT_HCIUART_BCM.

Also check your dmesg | grep Bluetooth output - you should see "HCI UART protocol Broadcom registered" and some "hci0: BCM" messages.

If these are all fine, then the issue is most likely with your userspace tools - make sure all relevant packages are installed.

@tomaytotomato

This comment has been minimized.

tomaytotomato commented Oct 24, 2018

@tomaytotomato If you have a 13,2 (i.e. with touchbar) then no patching is needed. At the kernel level, check if the btbcm, hci_uart, and bluetooth modules are loaded (or possibly built-in) - relevant kernel configs that need to enabled are (at least) CONFIG_BT, CONFIG_BT_BCM, CONFIG_BT_HCIUART, CONFIG_BT_HCIUART_SERDEV, and CONFIG_BT_HCIUART_BCM.

Also check your dmesg | grep Bluetooth output - you should see "HCI UART protocol Broadcom registered" and some "hci0: BCM" messages.

If these are all fine, then the issue is most likely with your userspace tools - make sure all relevant packages are installed.

I have a 13,2 (no touchbar) , do the same instructions apply?

https://mresell.macworld.co.uk/wp-content/uploads/2017/09/MacBook-Pro-1322-TBT3-Space-grey-300x300.jpg

@gdaddar

This comment has been minimized.

gdaddar commented Oct 24, 2018

I am a MacBookPro14,1 owner (no touchbar), kernel 4.18.0-10-generic (Ubuntu 18.10). As expected, bluetooth does not work out of the box:

dmesg |grep Bluetooth
[    3.880389] Bluetooth: Core ver 2.22
[    3.880401] Bluetooth: HCI device and connection manager initialized
[    3.880404] Bluetooth: HCI socket layer initialized
[    3.880406] Bluetooth: L2CAP socket layer initialized
[    3.880410] Bluetooth: SCO socket layer initialized
[    3.902383] Bluetooth: HCI UART driver ver 2.3
[    3.902385] Bluetooth: HCI UART protocol H4 registered
[    3.902386] Bluetooth: HCI UART protocol BCSP registered
[    3.902398] Bluetooth: HCI UART protocol LL registered
[    3.902398] Bluetooth: HCI UART protocol ATH3K registered
[    3.902399] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    3.902420] Bluetooth: HCI UART protocol Intel registered
[    3.902444] Bluetooth: HCI UART protocol Broadcom registered
[    3.902450] Bluetooth: HCI UART protocol QCA registered
[    3.902450] Bluetooth: HCI UART protocol AG6XX registered
[    3.902451] Bluetooth: HCI UART protocol Marvell registered
[    6.016147] Bluetooth: hci0: command 0xfc18 tx timeout
[    6.303075] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    6.303076] Bluetooth: BNEP filters: protocol multicast
[    6.303080] Bluetooth: BNEP socket layer initialized
[   14.048018] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   14.048022] Bluetooth: hci0: Failed to set baudrate
[   16.064068] Bluetooth: hci0: command 0x0c03 tx timeout
[   24.288241] Bluetooth: hci0: BCM: Reset failed (-110)
[ 2175.005645] Bluetooth: hci0: command 0xfc18 tx timeout
[ 2183.133570] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[ 2183.133581] Bluetooth: hci0: Failed to set baudrate
[ 2185.153564] Bluetooth: hci0: command 0x0c03 tx timeout
[ 2193.373555] Bluetooth: hci0: BCM: Reset failed (-110)

Should I try the @Lostish workaround or testing something else?

@rwuwon

This comment has been minimized.

rwuwon commented Oct 24, 2018

I have a 13,2 (no touchbar) , do the same instructions apply?

The one without the touch bar is the 13,1 so follow the 13,1 instructions and Bluetooth should work.

@tomaytotomato

This comment has been minimized.

tomaytotomato commented Oct 24, 2018

I have a 13,2 (no touchbar) , do the same instructions apply?

The one without the touch bar is the 13,1 so follow the 13,1 instructions and Bluetooth should work.

Thanks, I looked at this link but I am not sure what to do (or what comment to scroll to).

#29 (comment)

Is there a set of clear instructions?

@nedclimaterisk

This comment has been minimized.

nedclimaterisk commented Oct 31, 2018

@nedclimaterisk It already does. You should probably read it more carefully. wink

@Dunedan the table says

Device Status
Bluetooth all models working

Which seems generous. I wouldn't call Probably working, if you patch a kernel, but maybe not in some cases (e.g. 13,1), and maybe not for all functions "working"... Even if it's working with the patch (which I haven't had time to figure out how to do), that's a lot of work for most people, and if the page is going to be useful e.g. for people wondering whether to buy a new macbook, then it probably should be marked "partial" at least for 14,1 and 13,1.

@cyrusmg

This comment has been minimized.

cyrusmg commented Nov 29, 2018

I seem to have bluetooth working on MacbookPro13,1, ArchLinux, kernel v4.20-rc1 without the patch. Can anyone else confirm this to make sure it's not just some error on my end ?

@Dunedan

This comment has been minimized.

Owner

Dunedan commented Nov 30, 2018

That's awesome news. Any idea which change to the kernel fixed it? I'd like to link to it from the README if we can figure out which one it was.

@christophgysin

This comment has been minimized.

Contributor

christophgysin commented Nov 30, 2018

I can't confirm that. I'm running v4.20-rc4 with trampoline code from v4.16.18. Bluetooth fails with:

[   13.535101] Bluetooth: hci0: command 0xfc18 tx timeout
[   21.641803] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   21.641819] Bluetooth: hci0: Failed to set baudrate
[   23.775080] Bluetooth: hci0: command 0x0c03 tx timeout
[   31.668438] Bluetooth: hci0: BCM: Reset failed (-110)

@mfauvain

This comment has been minimized.

mfauvain commented Dec 8, 2018

compiled kernel (4.16.13) with christophgysin/linux@026daba patch and confirm bluetooth 'works' on 14,1. Sound is very bad tough in HSP/HFP (not usable really, have a much better HSP/HFP sound from usb dongle) and better in A2DP but stuttering a lot as reported above as well. will report back when I can tesr 4.20

@kayateia

This comment has been minimized.

kayateia commented Dec 9, 2018

@mfauvain I tried that patch on a 4.19(.1?) kernel and didn't have any luck with it. Bluetooth wasn't working for me with a 4.17 kernel either, though I didn't try it with the patch.

In all of my tries, I'm seeing the same error output as christophgysin's post two above, and bluetoothctl claims it can't see any adapters.

For reference, I'm on a macbookpro14,1 that was purchased in late 2017. (It's from work, so I don't actually know the exact vintage.)

I'll see if I can try out the 4.16.13 with the patch today for another data point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment