Jerome,
>>> I've just taken a look at the data listed by the ACPI subsystem on
>>> this tablet:
>>>
>>> $ ls /sys/bus/acpi/devices/BCM* -d1
>>> /sys/bus/acpi/devices/BCM2E3C:00
>>> /sys/bus/acpi/devices/BCM2E55:00
>>
>> Usually, Broadcom BT controller is described in the ACPI table.
>> You can retrieve your ACPI table at /sys/firmware/acpi/tables/DSDT and
>> decompile it with iasl.
>> You should have a Bluetooth node (BTHX):
>> Device (BTH1)
>> {
>> Name (_HID, "BCM...")
>>
>> With some gpio/irq resources. (0: wakeup, 1: power-, 2:host-wakeup).
>>
>> Check in your acpi table if one of them matches a bluetooth node.
> Both of them are matching a Bluetooth node it seems to me, with BTH0
> and BTH1 entries respectively. I've attached the original DSDT ACPI
> table (dsdt.dat) and the decompiled version (dsdt.dsl). Any useful
> information in there?
from your DSDT:
BTH0 _STA (status) method returns 0x00 meaning that this device is not
present.
BTH1 _STA method returns 0x0F meaning that this device is present.
So your BT controller is BTH1 (BCM2E55).
The ACPI table for this BTH1 looks good (1 irq + 2 gpios ) so it should
be compatible with hci_bcm.
>> Second step is to attach the device, but you need to find the correct tty to
>> use.
>> If your ACPI table is correct, BCM acpi device should appear as a child of a
>> tty device in sysfs.
>> The physical_node symlink in your device directory (sys/bus/acpi...) gives
>> you the hierarchical path.
> Before applying any patches to hci_bcm.c , BCM2E55 has already the
> following hierarchical path:
>
> /sys/bus/acpi/devices/BCM2E55:00$ ls -l physical_node
> lrwxrwxrwx 1 root root 0 f?vr. 28 21:45 physical_node ->
> ../../../../platform/80860F0A:00/BCM2E55:00
80860F0A is the UART controller (8250_dw), looks good.
So you should also find BCM2E55 id into:
/sys/class/ttyS*/device/
> while BCM2E3C has none:
>
> sys/bus/acpi/devices/BCM2E3C:00$ ls
> hid modalias path power status subsystem uevent
Yes because BCM2E3C is not enabled.
Regards,
Loic
--
Intel Open Source Technology Center
http://oss.intel.com/
Hi Jerome
> What about the other ACPI ID (BCM2E3C) that I've found in the ACPI
> table of that ThinkPad 8 tablet? Is it included in its table to cover
> another HW variant of that product, using a different Broadcom
> chipset? Any value for you if I create a similar patch (without being
> able to test it)? I guess the answer will be "No" from your message
> above but just let me know.
Yes, ACPI table is often filled with different optional components so
that it can be compatible with several platform variants without impact
on the ACPI data. Then, components are enabled/disabled depending board ID.
This BCM2E3C is disabled on your platform, but seems compatible with
hci_bcm UART driver (2GPIOs + 1IRQ). Should be only a revision of BCM2Ex.
Broadcom input is welcome here.
Regards,
Loic
--
Intel Open Source Technology Center
http://oss.intel.com/
Hi Loic,
> New ACPI ID means that this is a different hardware. So it needs to be
> tested before being added into the driver supported list. An already
> supported hardware should keep the same ACPI ID, making it work out-of
> the-box.
That makes sense.
What about the other ACPI ID (BCM2E3C) that I've found in the ACPI
table of that ThinkPad 8 tablet? Is it included in its table to cover
another HW variant of that product, using a different Broadcom
chipset? Any value for you if I create a similar patch (without being
able to test it)? I guess the answer will be "No" from your message
above but just let me know.
>> Finally, is btattach the only command recommended and supported moving
>> forward
>
>
> Absolutely, think btattach is the only recommended way.
> Even if you can make it work with hciattach by adding device entry with
> correct protocol ID, it is not recommended since hciattach is dedicated
> to user-space initialisation (old-way) and code is pretty deprecated.
That's what I thought, thanks for the confirmation.
Regards,
J=C3=A9r=C3=B4me
Hi Jerome,
> Maybe this is a naive question about ACPI ID, and not specific to
> Broadcom by the way: could there be a more generic way to gather ACPI
> IDs used by new devices and add them to the kernel on a regular basis?
> They seem to be added almost one by one mainly upon user reports when
> looking at the mailing list. So Bluetooth doesn't work out-of-the-box
> on some systems which would be compatible otherwise, especially the
> less popular ones. Is there no existing driver list to re-use perhaps?
New ACPI ID means that this is a different hardware. So it needs to be
tested before being added into the driver supported list. An already
supported hardware should keep the same ACPI ID, making it work out-of
the-box.
Since this driver is pretty new, this is not surprising that some IDs
are regularly added. This is a good thing. Meaning that people use this
driver and that Broadcom controllers keep good compatibility across
hardware versions.
> Indeed, it is working fine with ttyS1 and the correct binary firmware
> stored at /lib/firmware/brcm/BCM.hcd:
>
> # btattach -B /dev/ttyS1 -P bcm
> Attaching BR/EDR controller to /dev/ttyS1
> Switched line discipline from 0 to 15
> Device index 0 attached
>
> Finally, is btattach the only command recommended and supported moving
> forward, or should hciattach work as well with that specific
> chipset/tablet (as a transition until most Linux distros switch to
> btattach)?
Absolutely, think btattach is the only recommended way.
Even if you can make it work with hciattach by adding device entry with
correct protocol ID, it is not recommended since hciattach is dedicated
to user-space initialisation (old-way) and code is pretty deprecated.
Regards,
Loic
--
Intel Open Source Technology Center
http://oss.intel.com/
Hi,
> So your BT controller is BTH1 (BCM2E55).
> The ACPI table for this BTH1 looks good (1 irq + 2 gpios ) so it should b=
e
> compatible with hci_bcm.
I can confirm that it is compatible with hci_bcm; Bluetooth is indeed
fully working using the bluetooth-next tree on the ThinkPad Tablet 8.
Thanks again Marcel to have applied the patch and Loic to have helped
me find the right ACPI ID.
Maybe this is a naive question about ACPI ID, and not specific to
Broadcom by the way: could there be a more generic way to gather ACPI
IDs used by new devices and add them to the kernel on a regular basis?
They seem to be added almost one by one mainly upon user reports when
looking at the mailing list. So Bluetooth doesn't work out-of-the-box
on some systems which would be compatible otherwise, especially the
less popular ones. Is there no existing driver list to re-use perhaps?
> Now, you can run btattach (bluez tool):
> $ btattach -B /dev/ttySX -P bcm
Indeed, it is working fine with ttyS1 and the correct binary firmware
stored at /lib/firmware/brcm/BCM.hcd:
# btattach -B /dev/ttyS1 -P bcm
Attaching BR/EDR controller to /dev/ttyS1
Switched line discipline from 0 to 15
Device index 0 attached
Finally, is btattach the only command recommended and supported moving
forward, or should hciattach work as well with that specific
chipset/tablet (as a transition until most Linux distros switch to
btattach)?
Regards,
J=C3=A9r=C3=B4me
P.S. for information if it can be useful to someone else:
> And check that hci0 has been created
> $ hciconfig
$ hciconfig -a
hci0: Type: BR/EDR Bus: UART
BD Address: B0:10:41:B8:16:6C ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:110596 acl:4422 sco:0 events:328 errors:0
TX bytes:35333 acl:36 sco:0 commands:273 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'thinkpad8'
Class: 0x10011c
Service Classes: Object Transfer
Device Class: Computer, Unknown (reserved) minor device class
HCI Version: 4.0 (0x6) Revision: 0x3492
LMP Version: 4.0 (0x6) Subversion: 0x4606
Manufacturer: Broadcom Corporation (15)