[Letux-kernel] Letux-4.11-rc and Bluetooth
H. Nikolaus Schaller
hns at goldelico.com
Thu Apr 27 12:40:20 CEST 2017
> Am 25.04.2017 um 21:56 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>
>
>> Am 25.04.2017 um 21:46 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>
>>
>>> Am 25.04.2017 um 21:31 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>
>>> Hi,
>>>
>>>> Am 25.04.2017 um 21:05 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>>>
>>>> On Tue, 25 Apr 2017 20:02:39 +0200
>>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>>>
>>>>> I just realized that we have switched for the serdev driver for GPS
>>>>> in Letux-4.11-rc.
>>>>>
>>>>> Since we have a special misc/w2cbw003 driver which similarily
>>>>> checks for open()/close() on the /dev/tty we have broken
>>>>> Bluetooth power management...
>>>>>
>>>>> It is not difficult to fix, just some copy&paste the serdev parts
>>>>> into the w2cbw003 bluetooth power driver. I will try to do asap.
>>>
>>> Well, the copy&paste part was simple and I have pushed it to the w2sg-serdev branch.
>>>
>>> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-serdev
>>>
>>> But it is definitively not enough :(
>>>
>>> The problem is that we have again a man-in-the-middle approach, i.e. on one
>>> side the serdev interface and on the other a new /dev/tty. This works in
>>> one direction only. The other is missing because we don't need it for GPS.
>>>
>>> Next, hciattach assumes that it can tamper with the tty port's baud rate, flow
>>> control etc. So this has to be passed to the serdev.
>>>
>>> Makes a lot of additional glue code which has to be developed :(
>>>
>>> Hm. Maybe a better strategy would be to not open the serdev?
>>> AFAIR, this should make the /dev/ttyO remain available as standard UART.
>>>
>>> But then we must install some "line discipline" to get notified about the
>>> open()/close() actions. And I have no idea if the serdev API provides enough
>>> struct pointers to get up to the pointer where we can install the ldisc.
>>>
>>
>> It seems to be possible through:
>>
>> struct serdev_controller *ctrl = serdev->ctrl;
>> struct serport *serport = serdev_controller_get_drvdata(ctrl);
>> struct tty_struct *tty = serport->tty;
>>
>> and then
>>
>> * struct tty_ldisc_ops ops = { .open = open_handler; .close = close_handler; };
>> * create ldisc
>> * int tty_register_ldisc(int disc, struct tty_ldisc_ops *new_ldisc)
>> * tty_set_ldisc(struct tty_struct *tty, int disc)
>>
>> An unanswered question is where to get the 'disc' number from. Can we
>> assign it freely? It seems to be an index into an array [0..NR_LDISCS-1]
>
> Ah, I got it:
>
> http://lxr.free-electrons.com/source/include/uapi/linux/tty.h#L8
>
> Well, there are currently 25 LDICSs and NR_LDISCS is 30. So there is not much
> room for arbitrarily assigning new ones. And likely there is some Cerberus
> disallowing to add new constants for such a simple thing as power control.
>
> But wait: there is N_HCI for Bluetooth...
>
> So, maybe, should we extend http://lxr.free-electrons.com/source/drivers/bluetooth/hci_ldisc.c#L863
> for handling the W2CBW explicitly and just control power? But then it can't be a serdev any
> more...
>
> Argh... No obvious solution :(
I did take another look into the serdev based solution and there wasn't much
missing. Just properly handling set_termios. So we do not have to think about
line disciplines any more.
Now, I have a version where Bluetooth is working again (/dev/ttyBT0):
It has debugging code enabled so that we e.g. see
[ 4397.009552] w2cbw_tty_open() data = dcc3b410 open_count = ++0
[ 4397.020294] w2cbw_set_power(...,1)
[ 4397.035980] w2cbw_tty_set_termios() flow = 0
[ 4397.040466] w2cbw_tty_set_termios() baud rate = 9600
[ 4397.054809] w2cbw_tty_set_termios() flow = 0
[ 4397.059295] w2cbw_tty_set_termios() baud rate = 3000000
[ 4397.081604] w2cbw_tty_set_termios() flow = 0
[ 4397.093749] w2cbw_tty_set_termios() baud rate = 3000000
Device setup complete
[ 4397.172302] w2cbw003: tty->uart 4 chars
[ 4397.810668] w2cbw003: uart->tty 11 chars
[ 4397.815704] w2cbw003: tty->uart 4 chars
[ 4397.821990] w2cbw003: uart->tty 15 chars
[ 4397.828338] w2cbw003: tty->uart 4 chars
[ 4397.833923] w2cbw003: uart->tty 13 chars
[ 4397.840270] w2cbw003: tty->uart 4 chars
[ 4397.847290] w2cbw003: uart->tty 8 chars
[ 4397.851562] w2cbw003: uart->tty 6 chars
[ 4397.857391] w2cbw003: tty->uart 4 chars
[ 4397.862548] w2cbw003: uart->tty 10 chars
[ 4397.869110] w2cbw003: tty->uart 4 chars
[ 4397.878845] w2cbw003: uart->tty 167 chars
One messages indicates some flow control, buffer flushing, parity? or timeout issue:
[ 4397.883239] Bluetooth: hci0: Frame reassembly failed (-84)
Another issue is that it is probed a second time by the call
to tty_port_register_device() (the same as observed with the
w2sg00x4 driver).
But it is basically useable (maybe slow):
root at letux:~# ./bt-scan <--- patched for /dev/ttyBT0
Scanning ...
BD Address: 00:23:12:3D:07:A2 [mode 0, clkoffset 0x7226]
Device name: iMac
Manufacturer: Broadcom Corporation (15)
LMP version: 2.1 (0x4) [subver 0x21d0]
LMP features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
<power control> <transparent SCO> <broadcast encrypt>
<EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <inquiry with RSSI>
<extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave>
<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>
<sniff subrating> <pause encryption> <AFH cap. master>
<AFH class. master> <EDR eSCO 2 Mbps> <EDR eSCO 3 Mbps>
<3-slot EDR eSCO> <extended inquiry> <simple pairing>
<encapsulated PDU> <err. data report> <non-flush flag> <LSTO>
<inquiry TX power> <extended features>
root at letux:~#
Latest git branch is here:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-serdev
BR,
Nikolaus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170427/eeca6c84/attachment.asc>
More information about the Letux-kernel
mailing list