Bug 110901
| Summary: | Macbook8,1 12-inch (Early 2015) Bluetooth not working | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Leif Liddy (leif.liddy) |
| Component: | Bluetooth | Assignee: | linux-bluetooth (linux-bluetooth) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | adborden, andy.shevchenko, bugzilla, christoph.gysin, Derarnold, j, lkml2819, mika.westerberg, olli.salo |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 4.4.0 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
BtwSerialBus-dev.inf.txt
lshw Patch adding IDs to UART and bluetooth driver boot log --with Mika patch lspci -nk proc-interrupts lsmod interrupts cat < /dev/ttyS0 dmesg --nr_uarts=8 ignore_loglevel.... 8250_pci.c acpi dump journal-log-8250 proc-interrupts --with /dev/ttyS4 opened boot-log |
||
Created attachment 200301 [details]
lshw
I tried adding BCM2E7C to hci.bcm.c
Didn't work, but here's what was shown in the logs.
hci_bcm BCM2E7C:00: BCM irq: -22
hci_bcm BCM2E7C:00: invalid platform data
hci_bcm: probe of BCM2E7C:00 failed with error -22
I've posted the output of lshw which shows several unclaimed devices like the
Wildcat Point-LP Serial IO UART Controller #0
Does anyone whether this would prevent the kernel from communicating with the bluetooth device?
I think I may have answered my own question. lspci shows that that all four of these controllers are part of the same device: (**all 4 of these controllers are unclaimed by the kernel) 00:15.0 Intel Corporation Wildcat Point-LP Serial IO DMA Controller (rev 03) 00:15.2 Intel Corporation Wildcat Point-LP Serial IO I2C Controller #1 (rev 03) 00:15.4 Intel Corporation Wildcat Point-LP Serial IO GSPI Controller #1 (rev 03) 00:15.5 Intel Corporation Wildcat Point-LP Serial IO UART Controller #0 (rev 03) sysfs shows that BCM2E7C does fall under the Serial IO UART Controller ./devices/pci0000:00/0000:00:15.5/BCM2E7C:00 ./devices/pci0000:00/0000:00:15.5/BCM2E7C:00/power ./devices/pci0000:00/0000:00:15.5/BCM2E7C:00/power/control ./devices/pci0000:00/0000:00:15.5/BCM2E7C:00/power/async ./devices/pci0000:00/0000:00:15.5/BCM2E7C:00/power/runtime_enabled ..... If anyone has any ideas on how to get this things working let me know.... Windows or Linux compatible hardware is supplying by ACPI tables and ACPI enumerated controllers. Here we have them PCI enumerated. The drivers/dma/dw/pci.c, drivers/spi/spi-pxa2xx-pci.c, drivers/i2c/busses/i2c-designware-pcidrv.c, and drivers/tty/serial/8250/8250_pci.c have to be updated accordingly, i.e. for first step the IDs must be added. Created attachment 200661 [details]
Patch adding IDs to UART and bluetooth driver
Can you try this patch?
Created attachment 200831 [details]
boot log --with Mika patch
It doesn't appear that the 8250_pci.c patch had any effect.
Mika --let me know what information/logs you would find useful. From log it looks like driver can't get interrupt line. Anyway, can you provide % lspci -nk % cat /proc/interrupts % lsmod Have you loaded module? I didn't see ports detected from the log file. Created attachment 200871 [details]
lspci -nk
Created attachment 200881 [details]
proc-interrupts
Created attachment 200891 [details]
lsmod
I used the fedora stock config for my kernel config CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DMA=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=32 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set CONFIG_SERIAL_8250_RSA=y # CONFIG_SERIAL_8250_FSL is not set CONFIG_SERIAL_8250_DW=y CONFIG_SERIAL_8250_RT288X=y # CONFIG_SERIAL_8250_FINTEK is not set CONFIG_SERIAL_8250_MID=y # Non-8250 serial port support **the 8250_pci is built-in, do you want to the contents of sysfs? Can you add 'nr_uarts=8 ignore_loglevel' to the command line? And resend /proc/interrupts when all serial ports are opened? You may achieve this by doing something like % cat < /dev/ttyS0 & Created attachment 200901 [details]
interrupts cat < /dev/ttyS0
**booted with: nr_uarts=8 ignore_loglevel
**this is what I see when running the following cmd:
[root@mac ~]# cat < /dev/ttyS0 &
[1] 2130
[root@mac ~]# cat: -: Input/output error
#I grabbed /proc/interrupts in another terminal at this point
*additional information:
[root@mac ~]# setserial -g /dev/ttyS0
/dev/ttyS0, UART: unknown, Port: 0x03f8, IRQ: 4
[root@mac ~]# setserial -g /dev/ttyS1
/dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3
[root@mac ~]# setserial -g /dev/ttyS2
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
[root@mac ~]# setserial -g /dev/ttyS3
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
[root@mac ~]# setserial -g /dev/ttyS4
/dev/ttyS4, UART: unknown, Port: 0x0000, IRQ: 0
[root@mac ~]# setserial -g /dev/ttyS5
/dev/ttyS5, UART: unknown, Port: 0x0000, IRQ: 0
[root@mac ~]# setserial -g /dev/ttyS6
/dev/ttyS6, UART: unknown, Port: 0x0000, IRQ: 0
[root@mac ~]# setserial -g /dev/ttyS7
/dev/ttyS7, UART: unknown, Port: 0x0000, IRQ: 0
sysfs info: /sys/bus/pci/drivers/8250_mid /sys/bus/pci/drivers/8250_mid/bind /sys/bus/pci/drivers/8250_mid/new_id /sys/bus/pci/drivers/8250_mid/uevent /sys/bus/pci/drivers/8250_mid/unbind /sys/bus/pci/drivers/8250_mid/remove_id /sys/bus/platform/drivers/serial8250 /sys/bus/platform/drivers/serial8250/bind /sys/bus/platform/drivers/serial8250/serial8250 /sys/bus/platform/drivers/serial8250/uevent /sys/bus/platform/drivers/serial8250/unbind /sys/module/8250 /sys/module/8250/parameters /sys/module/8250/parameters/nr_uarts /sys/module/8250/parameters/skip_txen_test /sys/module/8250/parameters/share_irqs /sys/module/8250/parameters/probe_rsa /sys/module/8250/uevent Looks like to the DMA controller is working after this line to ./drivers/dma/dw/pci.c
+ { PCI_VDEVICE(INTEL, 0x9ce0) },
lshw output:
*-generic:0
description: DMA controller
product: Wildcat Point-LP Serial IO DMA Controller
vendor: Intel Corporation
physical id: 15
bus info: pci@0000:00:15.0
version: 03
width: 32 bits
clock: 33MHz
capabilities: pm eisa_dma bus_master cap_list
configuration: driver=dw_dmac_pci latency=0
resources: irq:20 memory:c181c000-c181cfff
Does anyone know how to edit: drivers/spi/spi-pxa2xx-pci.c drivers/i2c/busses/i2c-designware-pcidrv.c To get them working with my hardware? So, the attachment #200901 [details] doesn't make sense since UART driver is not bound. Something prevents this to happen. Boot kernel with 'nr_uarts=8 ignore_loglevel initcall_debug debug' and attach dmesg output.
WRT comment #17 same way like you did for dw_dmac driver. Created attachment 200911 [details]
dmesg --nr_uarts=8 ignore_loglevel....
in drivers/spi/spi-pxa2xx-pci.c
I'm not sure what to put for the PORT_XXX
static const struct pci_device_id pxa2xx_spi_pci_devices[] = {
{ PCI_VDEVICE(INTEL, 0x2e6a), PORT_CE4100 },
{ PCI_VDEVICE(INTEL, 0x0935), PORT_QUARK_X1000 },
{ PCI_VDEVICE(INTEL, 0x0f0e), PORT_BYT },
{ PCI_VDEVICE(INTEL, 0x228e), PORT_BSW0 },
{ PCI_VDEVICE(INTEL, 0x2290), PORT_BSW1 },
{ PCI_VDEVICE(INTEL, 0x22ac), PORT_BSW2 },
{ },
In drivers/i2c/busses/i2c-designware-pcidrv.c
What do I put for the arch?
/* Haswell */
{ PCI_VDEVICE(INTEL, 0x9c61), haswell },
{ PCI_VDEVICE(INTEL, 0x9c62), haswell },
/* Braswell / Cherrytrail */
{ PCI_VDEVICE(INTEL, 0x22C1), baytrail },
{ PCI_VDEVICE(INTEL, 0x22C2), baytrail },
Created attachment 200941 [details]
8250_pci.c
I compiled the 8250_pci as a module, shouldn't I see 0x9ce3 or 0x9ce4 listed as an alias?
# modinfo 8250_pci | grep -i 8086
alias: pci:v00008086d00000936sv*sd*bc*sc*i*
alias: pci:v00008086d0000228Csv*sd*bc07sc*i*
alias: pci:v00008086d0000228Asv*sd*bc07sc*i*
alias: pci:v00008086d00000F0Csv*sd*bc07sc*i*
alias: pci:v00008086d00000F0Asv*sd*bc07sc*i*
alias: pci:v00008086d00002E66sv*sd*bc*sc*i*
alias: pci:v00008086d00001960sv0000E4BFsd*bc*sc*i*
The DMA controller alias shows up fine... # modinfo dw_dmac_pci | grep -i 9ce0 alias: pci:v00008086d00009CE0sv*sd*bc*sc*i* figured it out...had to add these lines to 8250_pci.c
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BDW_UART1,
PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL << 8, 0xff0000,
pbn_byt },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BDW_UART2,
PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL << 8, 0xff0000,
pbn_byt },
lshw output:
*-communication:0
description: Serial controller
product: Wildcat Point-LP Serial IO UART Controller #0
vendor: Intel Corporation
physical id: 15.5
bus info: pci@0000:00:15.5
version: 03
width: 32 bits
clock: 33MHz
capabilities: pm 16550 bus_master cap_list
configuration: driver=serial latency=0
resources: irq:21 memory:c1819000-c1819fff
(In reply to leif from comment #6) > Created attachment 200831 [details] > boot log --with Mika patch > > It doesn't appear that the 8250_pci.c patch had any effect. Are you sure you have the patch applied? It should bind to the PCI UART device and I cannot see it happening from your lspci. Please double check. (In reply to Mika Westerberg from comment #25) > (In reply to leif from comment #6) > > Created attachment 200831 [details] > > boot log --with Mika patch > > > > It doesn't appear that the 8250_pci.c patch had any effect. > > Are you sure you have the patch applied? It should bind to the PCI UART > device and I cannot see it happening from your lspci. Please double check. Ah, I can see now that I missed few places in the patch. BTW, can you attach acpidump from that machine to the bug? Created attachment 200961 [details]
acpi dump
acpidump > acpi.dat
Created attachment 200971 [details]
journal-log-8250
It looks like there might be some issues with the serial driver...
kernel: 0000:00:15.5: ttyS4 at MMIO 0xc1819000 (irq = 21, base_baud = 2764800) is a 16550A I'm having partial success in getting the interface up.. *I've recompiled rawhide bluez 5.37 srpm --and enabled experimental settings --so I could use btattach --which is apparently is the correct tool for the job. # btattach --bredr /dev/ttyS4 -P bcm Attaching BR/EDR controller to /dev/ttyS4 Switched line discipline from 0 to 15 Device index 0 attached **hangs here*** **dmesg log** [ 41.189322] connection1:0: detected conn error (1020) [ 46.160158] Bluetooth: hci0: BCM: failed to write clock (-110) [ 46.499572] connection1:0: detected conn error (1020) [ 48.160154] Bluetooth: hci0 command 0x0c03 tx timeout [ 50.079147] audit_printk_skb: 36 callbacks suppressed [ 50.079154] audit: type=1131 audit(1453489901.105:200): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 51.620184] connection1:0: detected conn error (1020) [ 56.161007] Bluetooth: hci0: BCM: Reset failed (-110) [ 56.945330] connection1:0: detected conn error (1020) [ 84.984370] Bluetooth: hci0: BCM: failed to write clock (-4) [ 84.984517] Bluetooth: hci0: BCM: Reset failed (-4) [ 85.220511] Bluetooth: hci0 command tx timeout [ 85.620177] connection1:0: detected conn error (1020) [root@mac ~]# hciconfig hci0: Type: BR/EDR Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN RX bytes:0 acl:0 sco:0 events:0 errors:0 TX bytes:14 acl:0 sco:0 commands:3 errors:0 I can get the interface to stay up with this: # hciattach /dev/ttyS4 any Device setup complete **dmesg** [ 51.442686] connection1:0: detected conn error (1020) [ 52.887977] serial 0000:00:15.5: found DMA channel "rx" at index 1 [ 52.888401] dmaengine: private_candidate: dma0chan0 busy [ 52.888407] dmaengine: private_candidate: dma0chan1 busy [ 52.888599] dma dma0chan2: dwc_alloc_chan_resources: allocated 64 descriptors [ 52.888604] dmaengine: __dma_request_channel: success (dma0chan2) [ 52.888609] serial 0000:00:15.5: found DMA channel "tx" at index 0 [ 52.888714] dmaengine: private_candidate: dma0chan0 busy [ 52.888717] dmaengine: private_candidate: dma0chan1 busy [ 52.888720] dmaengine: private_candidate: dma0chan2 busy [ 52.889075] dma dma0chan3: dwc_alloc_chan_resources: allocated 64 descriptors [ 52.889079] dmaengine: __dma_request_channel: success (dma0chan3) [ 56.898018] Bluetooth: hci0 command 0x1001 tx timeout [ 58.898059] Bluetooth: hci0 command 0x1009 tx timeout [ 64.544360] connection1:0: detected conn error (1020) [root@mac ~]# hciconfig hci0: Type: BR/EDR Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN RX bytes:0 acl:0 sco:0 events:0 errors:0 TX bytes:12 acl:0 sco:0 commands:3 errors:0 Here are the bluetooth details from OSX: Manufacturer: Broadcom Address: A8-66-7F-20-36-F6 Transport: UART Chipset: 4350C1 Firmware Version: v64 c5236 Vendor ID: 0x05AC Product ID: 0x828E HCI Version: 0x7 HCI Revision: 0x1474 LMP Version: 0x7 LMP Subversion: 0x6140 Device Type (Major): Computer Device Type (Complete): Mac Portable Composite Class Of Device: 0x38010C Device Class (Major): 0x01 Device Class (Minor): 0x03 Service Class: 0x1C0 (In reply to leif from comment #29) > kernel: 0000:00:15.5: ttyS4 at MMIO 0xc1819000 (irq = 21, base_baud = > 2764800) is a 16550A How many such lines do you have in dmesg? You may decrease or drop nr_uarts parameter from kernel command line. (In reply to leif from comment #32) > Here are the bluetooth details from OSX: So, I didn't get do you have it working now? Here's the current status: **I'm running a kernel with patched versions of ./drivers/dma/dw/pci.c ./drivers/tty/serial/8250/8250_pci.c The bluetooth device always gets assigned to /dev/ttyS4 0000:00:15.5: ttyS4 at MMIO 0xc1819000 (irq = 21, base_baud = 2764800) is a 16550A I can get the hci0 interface to show up by running: # btattach --bredr /dev/ttyS4 -P bcm Attaching BR/EDR controller to /dev/ttyS4 Switched line discipline from 0 to 15 Device index 0 attached hci0: Type: BR/EDR Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN RX bytes:0 acl:0 sco:0 events:0 errors:0 TX bytes:14 acl:0 sco:0 commands:3 errors:0 But I can't bring up the interface with "hciconfig hci0 up" [ 678.412771] Bluetooth: hci0 command 0xfc45 tx timeout [ 686.409745] Bluetooth: hci0: BCM: failed to write clock (-110) [ 688.409716] Bluetooth: hci0 command 0x0c03 tx timeout [ 696.409694] Bluetooth: hci0: BCM: Reset failed (-110) I suspect more work needs to be done with with hci_bcm.c or with btbcm.c I'm still seeing these messages at boot: [ 36.775883] hci_bcm BCM2E7C:00: BCM irq: -22 [ 36.779009] hci_bcm BCM2E7C:00: invalid platform data [ 36.822702] hci_bcm: probe of BCM2E7C:00 failed with error -22 I should be seeing something more like this: hci_bcm BCM2E7C:00: BCM2E7C:00 device registered. I posted the info from OSX just to give you more insight into the details of the device. Let me know if what information you would find useful. Created attachment 201091 [details]
proc-interrupts --with /dev/ttyS4 opened
Booted with nr_uarts=8
I did cat < /dev/ttyS[0-7] &
Only worked for /dev/ttyS4
For all other ports, received "Input/output error"
Created attachment 201101 [details]
boot-log
booted with options:
nr_uarts=8 ignore_loglevel initcall_debug debug
It looks like Bluetooth device has his own methods to be controlled. BTPU (power up?), BTPD (power down), BTRS (reset), BTLP (low power). Driver doesn't support that (yet?). Reassign to Bluetooth team since UART driver seems working now. Oops, now for sure. Leif, I'm going to send the uart patch upstream. Since you did changes to the patch as well, can I add your Signed-off-by to it? Yeah, that's fine. Are you also submitting a patch for hci_bcm.c as well? **I've just updated my email address in my profile --please use the new address. Yes, I'll submit them both. And will use your updated email address. Hello Guys. Quick info: I have tested with 4.6-rc3: No change. Do you need some logfiles or can I help somehow? derarnold Hello. I found that on the XPS13 they use the same chip. On the ARCH wiki, they have a link to download ans install the firmware. It seems that you have seperate firmware for the NIC and for bluetooth. Unfortunately this also does not work, but I thought I bring it to your attention. https://wiki.archlinux.org/index.php/Dell_XPS_13_(2016) derarnold FYI: Some work has been done on this at: https://github.com/Dunedan/mbp-2016-linux/issues/29 Commits to use the ACPI methods can be found in: https://github.com/torvalds/linux/compare/master...l1k:hci_bcm This fixes the "invalid platform data". Using btattach still results in the same "command ... tx timeout" though. Cool, thanks for the update. I managed to get bluetooth working on a 4.14-rc1 kernel after applying l1k's hci_bcm.c patch https://github.com/torvalds/linux/compare/master...l1k:hci_bcm and roadrunner2's hci_bcm.c and hci_ldisc.c patches https://github.com/l1k/linux/pull/1/files/61c59e8b2a7f129a339608610069a26f4181c82a..7dd4a90a92b97b017d9210899afcfbe985b10509 There's a pull request to include roadrunner's patches in l1k's repo. Work is also being done to port the patches to 4.14 (I just did it manually) So, this all be cleaned up in the near future. You can read more about the current status on the link Christoph posted: https://github.com/Dunedan/mbp-2016-linux/issues/29 Should have mentioned that I'm using a Macbook9,1 12-inch (2016) model. I got it to work in a MBP13,1 using those same patches. (In reply to Leif Liddy from comment #46) > Cool, thanks for the update. > > I managed to get bluetooth working on a 4.14-rc1 kernel after applying > > l1k's hci_bcm.c patch > https://github.com/torvalds/linux/compare/master...l1k:hci_bcm > > and roadrunner2's hci_bcm.c and hci_ldisc.c patches > https://github.com/l1k/linux/pull/1/files/ > 61c59e8b2a7f129a339608610069a26f4181c82a.. > 7dd4a90a92b97b017d9210899afcfbe985b10509 > > There's a pull request to include roadrunner's patches in l1k's repo. Work > is also being done to port the patches to 4.14 (I just did it manually) > So, this all be cleaned up in the near future. > > You can read more about the current status on the link Christoph posted: > https://github.com/Dunedan/mbp-2016-linux/issues/29 Are these patches still required or have they eventually been merged into the kernel eventually? |
Created attachment 200081 [details] BtwSerialBus-dev.inf.txt Here's what I've found so far... There is a BCM2E7C:APPLE-UART-BLTH device listed in the acpi namespace. P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/BCM2E7C:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:17/BCM2E7C:00 E: ID_VENDOR_FROM_DATABASE=Broadcom E: MODALIAS=acpi:BCM2E7C:APPLE-UART-BLTH: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=7539067 However, there is no listing for BCM2E7C in modules.alias The windows inf file for this device shows that BCM2E7C corresponds to BCM4350 %Bus.DeviceDesc%=BluePinole2E7C, ACPI\BCM2E7C ; BCM4350 no flash In the extracted driver files there is no corresponding hcd file for BCM4350. I'm guessing that's what meant by "no flash" --that no firmware needs to loaded onto the device.