mbp-2016-linux
mbp-2016-linux copied to clipboard
Dunedan
Bluetooth Problem
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?
@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).
Yes I did mention in the commit message of l1k/linux@9ae5c93fcd54dd078dc072cf73cfe9be2b83c225 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.
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.
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.
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.
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.
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?
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. :-)
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.
@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?
@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)
@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!
@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.
@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...
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.
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.
@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.
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.
/sys/class/bluetooth has stuff inside when I run btattach --bredr /dev/ttyS0 -P bcm. Not that bluetooth works in that circumstance though.
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
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 [email protected]):
--- /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)
@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.
@peterychuang The patches are on top of https://github.com/l1k/linux/tree/hci_bcm, which is based on 4.13.0-rc4.
@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.
@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.
great work roadrunner2!!! It's working!!!! I wasn't aware there was a [email protected], 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
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.
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 hm... funny you mention that... I've never turned off that option off, but somehow the option's gone missing in the compiled kernel, and I haven't quite figured out how to turn that option back on as I tried to recompile...
Edit
I've figured out the problem with my kernel. It turns out I've left CONFIG_BT_HCIUART_SERDEV un-set, so that CONFIG_BT_HCIUART_BCM cannot be set to y. The patches now work.
Thanks @christophgysin for pointing out the problem, and of course massive thanks to @roadrunner2!
@roadrunner2 I didn't realize the bluetooth controller was working after applying your patches, and I suspected the firmware not loading was the culprit.
The windows inf file for this device shows that BCM2E7C corresponds to BCM4350 and is presumably indicating that no firmware needs to be flashed, so I think we're good.
%Bus.DeviceDesc%=BluePinole2E7C, ACPI\BCM2E7C ; BCM4350 no flash
Here's the UART controller info of the MacBook9,1: [root@mac ~]# lspci -nn | grep UART
00:19.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO UART Controller #2 [8086:9d66] (rev 21)
00:1e.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO UART Controller #0 [8086:9d27] (rev 21)
This is an excerpt from /proc/interrupts:
16: 0 0 0 0 IR-IO-APIC 16-fasteoi idma64.0, i801_smbus
18: 0 0 0 0 IR-IO-APIC 18-fasteoi idma64.1, i2c_designware.1
20: 5527 3028 16470 3164 IR-IO-APIC 20-fasteoi idma64.3, ttyS5
23: 11830 5177 15820 5385 IR-IO-APIC 23-fasteoi idma64.4, pxa2xx-spi.4
I don't have an idma64.2, doesn't show up in dmesg output either.
FWIW, the schematics of the MB8,1 indicate that the meaning of the host wake and device wake pins is swapped in firmware, which seems to imply that Apple is using a custom firmware. So I'm not sure if flashing a new firmware is recommendable or even possible.
I've never turned off that option off, but somehow the option's gone missing in the compiled kernel
Same for me. I checked the configs and all configs prior to 4.14 contained CONFIG_BT_HCIUART_BCM. The one for 4.14 didn't, even though I used the one from 4.13 as a base.
Apparently CONFIG_BT_HCIUART_BCM got a new dependency on CONFIG_BT_HCIUART_SERDEV in 4.14 which has a dependency on CONFIG_SERIAL_DEV_BUS which wasn't enabled in my config.
So, I finally got to try it out properly with Linux 4.14-rc3 on my MacBookPro13,2 and it works like a charm with KDE's Bluetooth userland tools. :+1:
So I guess we have confirmation now that this works on all MBP13,* models as well as the MB9,1. And most likely therefore on all MBP14,* models too. Good. Thanks for testing.
I'm trying to test on a MacBookPro14,1 but I think I missed some kconfig setting.
No ttySx device seems to be registered: so I don't get the dw-apb-uart.2: ttyS4 at MMIO 0xc182b000 (irq = 21, base_baud = 115200) is a 16550A message in my kernel log.
I tried following the btattach-bcm-service.sh script's logic (which isn't available on Debian), but there's no tty file appearing in /sys/devices/pci0000:00/0000:00:1e.0/dw-apb-uart.2/
Here's my kernel config: config-4.14.0-rc4-mbp-amd64.txt
Does anyone have a hint?
@risen Not having a serial-tty device makes me suspect a missing driver. I looked at your config and see that several SERIAL_8250_* are not set but which I have enabled in my config (these are the drivers for the 16550A device), including what I think might be the crucial one, the SERIAL_8250_LPSS driver. Try enabling that.
Thanks @roadrunner2 – setting CONFIG_SERIAL_8250_DW=y (and maybe CONFIG_SERIAL_8250_LPSS=y too) did the trick.
I can confirm that bluetooth more or less seems to work now: scanning finds the devices in the neighbourhood, pairing works etc.
However, I'm still getting these:
Oct 17 16:38:57 pino kernel: bt_err_ratelimited: 17 callbacks suppressed
Oct 17 16:38:57 pino kernel: Bluetooth: Unknown advertising packet type: 0x13
Oct 17 16:38:57 pino kernel: Bluetooth: Unknown advertising packet type: 0x10
Oct 17 16:38:57 pino kernel: Bluetooth: Unknown advertising packet type: 0x20
Oct 17 16:38:57 pino kernel: Bluetooth: Unknown advertising packet type: 0x24
A2DP sound skips horribly, HSP sound is distorted etc. DUN seems to not be able to connect either. I'm not sure if it's a problem higher up the stack; but I'll report back if I figure it out.
It's definitely a bit flaky. A2DP audio from headphones (MDR-1000X) skips horribly when playing youtube videos --while sound from local video/audio files is fine. A2DP audio from bluetooth speaker (SRS-X11) works well across the board. Bluetooth mouse (Razer Orochi) stops responding when it's been idle for a few minutes --have to disable + re-enable bluetooth controller to get it to reconnect.
I'm seeing similar errors on my system: [ 3339.966021] Bluetooth: Unknown advertising packet type: 0x10 [ 4557.202412] Bluetooth: Unknown advertising packet type: 0x20 [ 4557.202723] Bluetooth: Unknown advertising packet type: 0x24 [ 5030.960145] Bluetooth: Unknown advertising packet type: 0x21 [ 5045.276959] Bluetooth: Unknown advertising packet type: 0x11
@risen Not sure if this is the issue in your case, but make sure the gnome bluetooth-settings window is not open when you play audio etc - I think it's doing excessive scanning or something, and it definitely makes the audio skip.
Regarding unknown advertising packets, I think those are basically harmless (from a quick perusal of the code) - I'd guess they're from a newer BT spec. It might be interesting to know which devices are sending these, though (none of my devices send anything like that, but then again all of them are several years old).
@leifliddy I tried an Apple mouse, and don't see the issue you mention - at worst, after several minutes of inaction, I've seen it take a fraction of a second before the movements register (i.e. the first few movements are lost). So I guess this is device specific.
Sorry for being slightly off-topic but the links to the hci_bcm-4.1{3,4} patches are broken in the Linux-On-MBP-Late-2016.md gist. Just got new bluetooth headphones and I want to use them with my macbook9,1 :)
Try: https://github.com/roadrunner2/linux/tree/hci_bcm https://github.com/roadrunner2/linux/tree/hci_bcm-4.13 https://github.com/roadrunner2/linux/tree/hci_bcm-4.14
Purely FYI, it works with just:
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DW=y
So this one doesn't seem to make a difference:
# CONFIG_SERIAL_8250_LPSS is not set
The skipping audio was indeed most likely due to gnome-bluetooth doing excessive scanning.
Thanks ^_^
Has anyone been able to verify this working on macbook8,1? I've tried most everything, but still get from
~ $sudo btattach --bredr /dev/ttyS0 -P bcm
Attaching Primary controller to /dev/ttyS0
Switched line discipline from 0 to 15
Device index 0 attached
[ 497.056067] Bluetooth: hci0 command 0x0c03 tx timeout
[ 505.312000] Bluetooth: hci0: BCM: Reset failed (-110)
I'm using the newest patches from @roadrunner2
As well, with btmgmt, I'm getting
[mgmt]# power on
Set Powered for hci0 failed with status 0x11 (Invalid Index)
The device appears to be correct in /sys/class/bluetooth/hci0 as well.
@Maximus- for completeness sake: do you have the all of the following kernel config enabled: CONFIG_SERIAL_8250_LPSS, CONFIG_BT_HCIUART_BCM, CONFIG_BT_HCIUART_SERDEV, CONFIG_SERIAL_DEV_BUS, CONFIG_SERIAL_DEV_CTRL_TTYPORT, and CONFIG_SERIAL_8250_DW?
There may well be something missing for 8,1 - see e.g. l1k's comment above about a mux.
Yep! they're all enabled in my config. Hmm. I'm not sure how to deal with the mux at the BIOS level.
@Maximus- could you apply commit l1k/linux@5e30ec7ead67 on top of v4.15-rc4 (or Linus' current tree or linux-next) and post the resulting dmesg in a gist or something? Thanks!
Applied the patch onto tags/v4.15-rc4, ensured the same config flags were enabled that @roadrunner2 specified, and built/installed. Here's the dmesg. (Also now the ttyS0 device doesn't show anymore, and /sys/class/bluetooth is empty)
@Maximus-:
Here's the problem:
[ 0.361650] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.362633] 0000:00:15.5: ttyS0 at MMIO 0xc1819000 (irq = 21, base_baud = 2764800) is a 16550A
[ 0.362769] serial serial0-0: controller busy
[ 0.362815] serial serial0-0: failure adding ACPI serdev device. status -16
[ 0.362860] serial serial0: tty port ttyS0 registered
And the "controller busy" message is coming from serdev_device_add() in case there are multiple devices below the UART. Which is precisely the case on the MB8,1 because of the debug serial port on the SSD I mentioned earlier. serdev currently doesn't support multiple devices below the same UART. It doesn't know how to handle that, noone's implemented a GPIO-controlled mux to switch between multiple serdev slaves yet. What you could try is patching the DSDT to remove:
Scope (\_SB.PCI0.URT0)
{
Device (SSDC)
{
Name (_CID, "apple-uart-ssdc") // _CID: Compatible ID
...
}
}
Try if that helps and post the dmesg output again.
That you're no longer seeing a ttyS0 char device is normal, you also no longer need to run btattach, it all happens automatically.
Some other observations, with 4.11+ you apparently no longer need intremap=nosid on the command line and with 4.14+ you no longer need to patch the DSDT for the SPI topcase. I'm also wondering if pci= nocrs is really necessary.
Good job! it works! dm.txt Removed intremap=nosid, moved to a stock DSDT table, then applied your patch, and everything works. Bluetooth audio is /pretty/ laggy, but I'm hoping that's not your fault. Also there was a stack trace in my dmesg, so maybe an Oops somewhere. Attached new dmesg.
[ 0.571699] Call Trace:
[ 0.571707] bcm_serdev_probe+0x8b/0xc0
@Maximus-:
Okay, if you apply commit l1k/linux@9d8147938ff5 on top of what you currently have, does the WARN splat go away? This doesn't seem to be a Mac-specific issue, it's just that you happen to not have CONFIG_GPIOLIB enabled and this patch should enable it.
I've amended the commit message of the other patch with a paragraph explainig that the DSDT needs to be patched on the MB8,1. Pushed the whole thing to the hci_bcm_v1 branch again.
@l1k I rebased your hci_bcm_v1 branch on v4.15.0-rc5 and verified it works fine on MBP13,3. LGTM. Thanks!
@Maximus- regarding lag: make sure the gnome bluetooth settings window is not open - that causes a lot of stutter and slowdown.
Oh, I did just notice an interesting stack trace in dmesg (but haven't investigated if this is serious or not):
=============================
WARNING: suspicious RCU usage
4.15.0-rc5+ #13 Tainted: G OE
-----------------------------
kernel/rcu/sync.c:69 suspicious rcu_sync_is_idle() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by kworker/u17:5/535:
#0: ((wq_completion)"%s"hdev->name#2){+.+.}, at: [<00000000d7ef3d12>] process_one_work+0x1c3/0x6b0
#1: ((work_completion)(&hdev->cmd_work)){+.+.}, at: [<00000000d7ef3d12>] process_one_work+0x1c3/0x6b0
stack backtrace:
CPU: 4 PID: 535 Comm: kworker/u17:5 Tainted: G OE 4.15.0-rc5+ #13
Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.88Z.0226.B23.1704201604 04/20/2017
Workqueue: hci0 hci_cmd_work [bluetooth]
Call Trace:
dump_stack+0x85/0xbf
hci_uart_tx_wakeup+0x2c/0x130 [hci_uart]
hci_uart_send_frame+0x2e/0x60 [hci_uart]
hci_send_frame+0x6b/0xe0 [bluetooth]
hci_cmd_work+0x79/0x110 [bluetooth]
process_one_work+0x243/0x6b0
worker_thread+0x3a/0x390
? process_one_work+0x6b0/0x6b0
kthread+0x11f/0x140
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x24/0x30
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 4 PID: 535 Comm: kworker/u17:5 Tainted: G OE 4.15.0-rc5+ #13
Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.88Z.0226.B23.1704201604 04/20/2017
Workqueue: hci0 hci_cmd_work [bluetooth]
Call Trace:
dump_stack+0x85/0xbf
register_lock_class+0x17b/0x580
__lock_acquire+0xd1/0x1340
? hci_uart_send_frame+0x2e/0x60 [hci_uart]
? trace_hardirqs_on_thunk+0x1a/0x1c
? retint_kernel+0x10/0x10
? lock_acquire+0x9f/0x1f0
lock_acquire+0x9f/0x1f0
? hci_uart_send_frame+0x2e/0x60 [hci_uart]
? dump_stack+0xb4/0xbf
hci_uart_tx_wakeup+0x69/0x130 [hci_uart]
? hci_uart_send_frame+0x2e/0x60 [hci_uart]
hci_uart_send_frame+0x2e/0x60 [hci_uart]
hci_send_frame+0x6b/0xe0 [bluetooth]
hci_cmd_work+0x79/0x110 [bluetooth]
process_one_work+0x243/0x6b0
worker_thread+0x3a/0x390
? process_one_work+0x6b0/0x6b0
kthread+0x11f/0x140
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x24/0x30
I have tested Evolveo SportLife and Sony MDR-ZX770BN headphones on MBP13,1 running Arch Linux with patched 14.1 kernel. I can hear occasional break with a crack in the headphones and sound is more and more delayed from the video in mplayer and Youtube Videos.
I am not running any applet or anything special. I have paired the headphones using bluetoothctl and then turned scanning off.
The stuttering seems to even itself out after enough time playing... well, ok.
Also, will enable GPIOLIB and try. : )
@Maximus- The GPIOLIB should be enabled automatically with https://github.com/l1k/linux/commit/9d8147938ff5 and you shouldn't need to enable it manually.
In a separate step you could also try enabling CONFIG_LPC_ICH and CONFIG_GPIO_ICH. This should in theory give you access to GPIO 36. But be careful and backup your SSD before fiddling with the pin, it's unclear how it will react if you talk to it over the debug port.
BTW, for the folks with an MBP13,3 and similar models, there's a device called apple-uart-soc-als attached to URT2, could be the adaptive light sensor, someone will probably have to reverse-engineer the protocol and write a hwmon or iio driver. There's also an apple-uart-soc device below URT1, no idea what this could be.
I have my own config I'm using, which is why I didn't just pull yours. But yeah, now the stack trace is gone. I'll considering playing with LPC_ICH and GPIO_ICH when I get some free time and don't need my machine in a working state. 👍
BTW, for the folks with an MBP13,3 and similar models, there's a device called apple-uart-soc-als attached to URT2, could be the adaptive light sensor, someone will probably have to reverse-engineer the protocol and write a hwmon or iio driver. There's also an apple-uart-soc device below URT1, no idea what this could be.
Update: On the MBP14,2 they've changed the names to apple-uart-ssdc (same name as the SSD debug port on MacBook8,1) and apple-uart-als. The baudrate of the latter changed from 115200 to 1250000. The baudrate of the former stayed at 115200. Both devices are missing on the MBP14,1.
I've pushed a new iteration of the Bluetooth patches to the hci_bcm_v2 branch. Could someone test this please?
I've realized that I had a bug in v1 wherein bcm_gpio_set_power() would toggle the device wake pin on non-Macs but not on Macs. This is fixed now. I've also incorporated all the feedback I've received for v1.
Hmm, so now in the v2 version, on powering down we call BTPD followed by BTLP(1) - is that kosher?
@l1k So I cherry-picked your v2 commits onto v4.15-rc5 (commits 43fff7683468 and b8841a08ed93-e982998851a3). It's failing bcm_serdev_probe() because in bcm_get_resources() the devm_gpiod_get_optional(..., "device-wakeup", ...) was changed to devm_gpiod_get(..., "device-wakeup", ...) (which returns -ENOENT) - looks like there's no device-wakeup registered.
@roadrunner2:
Hmm, so now in the v2 version, on powering down we call BTPD followed by BTLP(1) - is that kosher?
That's a good question. I don't know. It's what the driver is doing on non-Macs. Technically these ACPI methods just toggle GPIO pins, they're not accessing the device itself.
It's failing bcm_serdev_probe() because in bcm_get_resources() the devm_gpiod_get_optional() was changed to devm_gpiod_get()
Ugh, right, of course, let me fix that up and get back to you. Thanks for testing!
@roadrunner2:
Okay, I've updated the hci_bcm_v2 branch. bcm_apple_probe() has now become bcm_get_apple_resources() and is called from bcm_get_resources(). The devm_gpiod_get() should thus be skipped.
In theory this should now even work with the legacy hci_ldisc / btattach (instead of serdev).
Also, the code now falls back to probing standard ACPI resources if Apple's custom ACPI methods aren't found (in the unlikely event that Apple migrates away from the custom methods one day).
Threw in some documentation and one additional cleanup commit for good measure.
...should be fixed now.
4.15-rc6 was released yesterday and a lot of maintainers don't accept new features within the two weeks before the merge window (i.e., from rc6), but this cycle is anomalous as patches are currently hurried in to address what appears to be a major security issue, which buys us some time. Torvalds indicated in the rc6 announcement that rc8 is "now almost guaranteed". So there's still a chance to get this into 4.16.
hci_bcm_v2 isn't working for me for some reasons. I'm getting these:
Bluetooth: hci0: command 0x0c03 tx timeout
Bluetooth: hci0: BCM: Reset failed (-110)
@l1k This is working for me (MBP13,3): patches were cherry-picked onto v4.15-rc6.
@peterychuang Does removing and re-loading the hci_uart kernel module help?
@roadrunner2 no it doesn't.
adding dyndbg=+p while reloading hci_uart gives me these:
[ 3237.852327] Bluetooth: HCI UART driver ver 2.3
[ 3237.852329] Bluetooth: HCI UART protocol H4 registered
[ 3237.852330] Bluetooth: HCI UART protocol BCSP registered
[ 3237.852352] Bluetooth: HCI UART protocol LL registered
[ 3237.852352] Bluetooth: HCI UART protocol ATH3K registered
[ 3237.852353] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 3237.852386] Bluetooth: HCI UART protocol Intel registered
[ 3237.852416] Bluetooth: HCI UART protocol Broadcom registered
[ 3237.852417] Bluetooth: HCI UART protocol QCA registered
[ 3237.852418] Bluetooth: HCI UART protocol AG6XX registered
[ 3237.852419] Bluetooth: HCI UART protocol Marvell registered
[ 3237.941585] serial0-0: suspend, delaying 15 ms
[ 3237.956614] (null): hu 0000000088bf1ff6
[ 3238.034507] serial0-0: resume, delaying 15 ms
[ 3238.049879] hci0 00000000dd132b16
[ 3238.049891] hci0: hu 0000000088bf1ff6
[ 3238.049919] hci0: type 1 len 3
[ 3238.049924] hci0: hu 0000000088bf1ff6 skb 000000000d732df6
[ 3240.177007] Bluetooth: hci0: command 0x0c03 tx timeout
[ 3248.070305] Bluetooth: hci0: BCM: Reset failed (-110)
[ 3248.070318] hdev 00000000dd132b16 serdev 00000000c9fa5645
[ 3248.070329] hci0: hu 0000000088bf1ff6
[ 3248.070337] hdev 00000000dd132b16
[ 3248.070339] hdev 00000000dd132b16 serdev 00000000c9fa5645
[ 3248.070342] hci0: hu 0000000088bf1ff6
It could be something wrong with linux-next, I guess? It seems I am usually the one who gets werid errors...
@peterychuang I'll try build the original hci_bcm_v2 tomorrow; but if you want, you can try my hci_bcm_v4.15_v2 branch which is @l1k's patches cherry-picked onto v4.15-rc6 and which is working for me.
I've pushed a hci_bcm_v3 branch which drops the patch "Bluetooth: hci_bcm: Enable runtime PM despite absence of IRQ" and drops a hunk from patch "Bluetooth: hci_bcm: Support Apple GPIO handling". This results in bcm_setup_sleep() no longer being called, so we rely on the default sleep parameters provided by Apple to be sane. (See struct bcm_set_sleep_mode for the parameters that were previously used.)
Does this still work?
@l1k I compiled the hci_bcm_v3 branch, but kernel wouldn't boot (maybe I did something wrong, don't have time to troubleshoot right now). So, I just built hci_uart.ko with your hci_bcm.c source file. Works fine with kernel 4.15.rc6 on macbook9,1
@l1k I'm still not having any luck with hci_bcm_v3. It's probably a linux-next problem, or I may have done something wrong, though I haven't got time to investigate. I'll try to build the mainline kernel when I have time.
@l1k Both your original hci_bcm_v3 branch, as well as cherry-picking the relevant commits onto v4.15-rc6 work fine for me. Suspend and resume didn't show any issues either (nothing logged, Bluetooth still worked fine after resuming).
@roadrunner2 Suspend and resume is working? Sorry...I see the 'Streamline runtime PM code' patch. Going to test that out as well.
@leifliddy Well, suspend/resume work with some notable caveats. Need to write it up.
I have tried the hci_bcm_v2 changes on top of https://github.com/torvalds/linux/archive/v4.15-rc6.tar.gz and I see the same errors as peterychuang.
Debug info:
- Running Arch Linux on MacbookPro13,1
-
hci_bcm-4.14from roadrunner2's repo works for me (except for the lags in audio)
@roadrunner2: When did you test? I reworked the hci_bcm_v3 branch yesterday until a couple of hours before your message came in to include all the feedback I got on the mailing list, in particular from @andy-shev. The most important change now is that I'm using callbacks to toggle the GPIOs, it adds 6 LoC but the code changes to add the Apple stuff then become simpler. A few minutes ago I've also added a commit on top to use msleep(), I believe I've addressed all feedback now I got on the mailing list so am getting ready to post this version. If you could test this once more I'd be grateful.
I have squashed changes from l1k/hci_bcm_v3 to this file
patch.diff.txt
and applied it on top of https://github.com/torvalds/linux/archive/v4.15-rc6.tar.gz and I still end up without working bluetooth. Let me know what more I can test.
linux-mainline (master) $ dmesg | grep Bluetooth
[ 77.872150] Bluetooth: Core ver 2.22
[ 77.872163] Bluetooth: HCI device and connection manager initialized
[ 77.872167] Bluetooth: HCI socket layer initialized
[ 77.872169] Bluetooth: L2CAP socket layer initialized
[ 77.872172] Bluetooth: SCO socket layer initialized
[ 77.877261] Bluetooth: HCI UART driver ver 2.3
[ 77.877263] Bluetooth: HCI UART protocol H4 registered
[ 77.877263] Bluetooth: HCI UART protocol BCSP registered
[ 77.877272] Bluetooth: HCI UART protocol LL registered
[ 77.877273] Bluetooth: HCI UART protocol ATH3K registered
[ 77.877273] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 77.877295] Bluetooth: HCI UART protocol Intel registered
[ 77.877306] Bluetooth: HCI UART protocol Broadcom registered
[ 77.877307] Bluetooth: HCI UART protocol QCA registered
[ 77.877307] Bluetooth: HCI UART protocol AG6XX registered
[ 77.877308] Bluetooth: HCI UART protocol Marvell registered
[ 80.051446] Bluetooth: hci0: command 0x0c03 tx timeout
[ 82.042850] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 82.042852] Bluetooth: BNEP filters: protocol multicast
[ 82.042857] Bluetooth: BNEP socket layer initialized
[ 88.156903] Bluetooth: hci0: BCM: Reset failed (-110)
@cyrusmg Just to be sure you have CONFIG_SERIAL_DEV_BUS=y in your kernel configuration (details may be found here as well: https://github.com/andy-shev/linux/issues/20)
@l1k
I'll go through your v3 branch soon. Done
It doesn't know how to handle that, noone's implemented a GPIO-controlled mux to switch between multiple serdev slaves yet.
Wouldn't be as simple as integrating gpio-mux into serdev?
@andy-shev I can confirm I have CONFIG_SERIAL_DEV_BUS=y. I went through this thread and made sure I have enabled all modules mentioned here. Was anyone else able to run 4.15-rc6 with Bluetooth on MacbookPro13,1 ?
@roadrunner2:
If you could test this once more I'd be grateful.
Actually... hold on, sorry, I've amended the branch once again to fix a bug Andy found and added another commit on top that I'll have to review with a fresh pair of eyeballs tomorrow.
@l1k Ok, tested this series, and works fine too. Also, you asked about which previous set of patches I had tested: they had commit dates of "Wed Jan 3 15:25:xy 2018 (UTC)".
So right now it looks like there's some issue with the 13,1/14,1 models, but things are fine on the 13,3 model.
@peterychuang @cyrusmg
If you get timeouts accessing the device, the most plausible explanation is that either the baudrate is wrong or the device isn't powered on.
To check the first theory, could you checkout the hci_bcm_v3 branch and amend bcm_apple_get_resources() with a printk("init_speed = %llu\n", dev->init_speed); to verify that the init_speed was properly read from the DSDT.
Next, try setting dev->oper_speed = dev->init_speed;. The expected result is that you get a "BCM: failed to write update baudrate" error, which you can silence by changing return err; to return 0; in bcm_set_baudrate().
Next, try amending bcm_apple_set_shutdown() and bcm_apple_set_device_wakeup() to print powered and awake so that you know when the GPIOs are toggled and to which value. The device should be powered and awake when it's accessed.
If possible post full dmesg output of the result. Thanks!
- base: linux v4.15-rc6
- patch created by
git reset --hard l1k/hci_bcm_v3 && git format-patch 0ca30e870ed2~ --stdout > patch.diffpatch.diff.txt - patch containing the changes mentioned above + a fix for a build error that's currently in
hci_bcm_v3(pulsed_host_wakehas a trailing comma and previous line does not) patch2.diff.txt
Result: dmesg.txt
[ 10.579550] init_speed = 0
[ 10.579553] bcm_apple_set_shutdown: powered = 0
[ 10.600014] bcm_apple_set_device_wakeup: awake = 0
[ 10.651068] bcm_apple_set_shutdown: powered = 1
[ 10.670023] bcm_apple_set_device_wakeup: awake = 1
@cyrusmg If init_speed = 0 then communication happens at the wrong baudrate, so that needs to be fixed first. I just took a look at the MBP13,1 DSDT in this repo and it looks normal, baud parameter is there. Are you patching the DSDT? If so, could you try without DSDT patch?
If an incorrect DSDT patch is not the cause, try editing drivers/acpi/x86/apple.c. At the top of acpi_extract_apple_properties(), add something like:
acpi_handle_info(adev->handle, FW_INFO "looking for apple properties\n");
This gives you one line in dmesg for each ACPI device so that you know the function gets executed for the Bluetooth device.
A bit further down there's a for_each_set_bit() loop. At the end of that loop, add something like:
acpi_handle_info(adev->handle, FW_INFO "found apple property: %s\n", newprops[k].string.pointer);
This should give you one line for each property found. Check if any properties are found at all for the Bluetooth device, or any other devices.
@cyrusmg Oh also, if you set dev->init_speed = 3000000; in bcm_apple_get_resources(), does it work?
Oh I notice now in your patch2.diff.txt that the printk is at the top of bcm_apple_get_resources(). You need to move this down after setting dev->init_speed = *(u64 *)obj->buffer.pointer;
Uh, right, sorry. Now I get [ 132.417821] init_speed = 3000000.
I have applied patch.diff.txt, patch2.diff.txt and this: patch3.diff.txt and the result is dmesg2.txt
While I playing with BCM Bluetooth module on Intel Edison I have noticed the similar issue, which had been root caused to misconfigured GPIOs for power. So, for me it 99.99% looks like a problem in powered off BT module you have.
@cyrusmg Sorry, I'm stumped, your dmesg LGTM. The device is powered down during ->probe, then powered up again during ->open. That is correct and matches the code and it seems to work on the other machines. The baudrate is good as well. Still, as soon as you try to communicate with the device you get timeouts. So what else could be wrong? CTS/RTS maybe?
You said that @roadrunner2's hci_bcm-4.14 branch works for you, but that version didn't support serdev yet. What's the behavior with CONFIG_SERIAL_DEV_BUS=n?
Hm, in the serdev case, the driver disables flow control during suspend and runtime suspend, and enables it on resume and runtime resume. It can't find where an initial default setting is applied. I'm wondering if missing flow control could cause the crackles and laggy audio that people have reported. Might make sense to play around with this and set hci_uart_set_flow_control(bdev->hu, false); in bcm_open() or bcm_setup(). Caution, the semantics are reversed, so setting this to false causes flow control to be enabled!
dmesg with CONFIG_SERIAL_DEV_BUS=n -
dmesg3.txt
I will try the flow control suggestion in the evening. Thank you for your time.
@cyrusmg: In dmesg3.txt there are no Bluetooth-related error messages. With CONFIG_SERIAL_DEV_BUS=n you need to invoke btattach, what do you get if you try that?
I have systemd service automatically running /usr/bin/btattach --bredr /dev/ttyS0 -P bcm (that's somewhere in the dmesg). Triggering it manually does not add any output to dmesg.
$ sudo btattach --bredr /dev/ttyS0 -P bcm
Attaching Primary controller to /dev/ttyS0
Switched line discipline from 0 to 15
Failed to set protocol: Protocol not supported
No controller attached
Someone also mentioned ttyS5:
$ sudo btattach --bredr /dev/ttyS5 -P bcm
Attaching Primary controller to /dev/ttyS5
Failed to open serial port: No such file or directory
No controller attached
I have recompiled kernel without those patches and with CONFIG_SERIAL_DEV_BUS=n now, btattach was run by systemd during startup + manually later on. Here is the dmesg
dmesg4.txt