[PATCH 0/4] TI Bluetooth serdev support

[Adam Ford]

On Tue, May 9, 2017 at 9:14 AM, Rob Herring <robh at kernel.org> wrote:
> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch at tkos.co.il> wrote:
>> Hi Rob,
>>
>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173 at gmail.com> wrote:
>>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre at kernel.org> wrote:
>>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh at kernel.org> wrote:
>>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>> >>> > modules and enables support on HiKey board with with the WL1835 module.
>>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>> >>>
>>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>> >>>
>>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>> >>> might have some insight.
>>> >>>
>>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>>> >>> returns a timeout.
>>> >>>
>>> >>> I modified my i.MX6 device tree per the binding documentation and
>>> >>> setup the regulators and enable GPIO pins.
>>> >>
>>> >> If you configured everything correctly no userspace interaction is
>>> >> required. The driver should request the firmware automatically once
>>> >> you power up the bluetooth device.
>>> >>
>>> >> Apart from DT changes make sure, that the following options are
>>> >> enabled and check dmesg for any hints.
>>> >>
>>> >> CONFIG_SERIAL_DEV_BUS
>>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>>> >> CONFIG_BT_HCIUART
>>> >> CONFIG_BT_HCIUART_LL
>>> >
>>> > I have enabled those flags, and I have updated my device tree.
>>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>>> > getting a lot of timeout errors.  I tested this against the original
>>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>>> > the btwilink driver.
>>> >
>>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>>> > am obviously missing something.
>>> >
>>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>>> > (-110)
>>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>>> > (-110)
>>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>>> > [   69.153533] Bluetooth: Data length is too large
>>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>>>
>>> There's a bug in serdev_device_write(), so if you have that function
>>> you need either the fix I sent or the patch to make
>>> serdev_device_writebuf atomic again. Both are on the linux-serial
>>> list, but not in any tree yet.
>>
>> You refer to the patches below, right?
>>
>>   [PATCH] tty: serdev: fix serdev_device_write return value,
>>   http://www.spinics.net/lists/linux-serial/msg26117.html
>>
>>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>>   http://www.spinics.net/lists/linux-serial/msg26113.html
>
> Yes, either one will fix the issue.

I am finally getting back to testing these on my DM3730 board, since
it appears most of the patches appear upstream.  I am having trouble
remembering how to load this.

# modprobe hci_uart
[   31.639892] Bluetooth: Core ver 2.22
[   31.643890] NET: Registered protocol family 31
[   31.648559] Bluetooth: HCI device and connection manager initialized
[   31.655975] Bluetooth: HCI socket layer initialized
[   31.661315] Bluetooth: L2CAP socket layer initialized
[   31.667175] Bluetooth: SCO socket layer initialized
[   31.700408] Bluetooth: HCI UART driver ver 2.3
[   31.705108] Bluetooth: HCI UART protocol H4 registered
[   31.710632] Bluetooth: HCI UART protocol BCSP registered
[   31.716217] Bluetooth: HCI UART protocol Three-wire (H5) registered
#

Unfortunately, any attempt to access the HCI device (ie hciconfig up
hci0) fail.

I have those configs enabled:
CONFIG_SERIAL_DEV_BUS
CONFIG_SERIAL_DEV_CTRL_TTYPORT
CONFIG_BT_HCIUART
CONFIG_BT_HCIUART_LL

I can see that sysfs shows new files appear:

/sys/class/bluetooth
/sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth
/sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/compatible
/sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/enable-gpios
/sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/name

(and more)
So it appears to me like it has loaded, and I don't see any errors during load.

Since this worked under pdata quirks and the older shared transport
driver and UIM, I'm sure it's software and not hardware.  I just can't
figure out what I am missing.

thanks

adam
>
> Rob