From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Ford Subject: Re: [PATCH 0/4] TI Bluetooth serdev support Date: Fri, 27 Oct 2017 05:55:31 -0500 Message-ID: References: <20170405183005.20570-1-robh@kernel.org> <20170430160430.rmyuo6sdrkrjxjg6@earth> <20170509044837.oje2tfodytyuuuur@sapphire.tkos.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Baruch Siach , Mark Rutland , "devicetree@vger.kernel.org" , Johan Hedberg , Gustavo Padovan , Marcel Holtmann , Sebastian Reichel , Wei Xu , "open list:BLUETOOTH DRIVERS" , Eyal Reizer , netdev , Satish Patel , "linux-arm-kernel@lists.infradead.org" To: Rob Herring Return-path: Received: from mail-vk0-f67.google.com ([209.85.213.67]:46468 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751176AbdJ0Kzc (ORCPT ); Fri, 27 Oct 2017 06:55:32 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, May 9, 2017 at 9:14 AM, Rob Herring wrote: > On Mon, May 8, 2017 at 11:48 PM, Baruch Siach 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 wrote: >>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel 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 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@68000000/serial@4806c000/bluetooth /sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth/compatible /sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth/enable-gpios /sys/firmware/devicetree/base/ocp@68000000/serial@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: aford173@gmail.com (Adam Ford) Date: Fri, 27 Oct 2017 05:55:31 -0500 Subject: [PATCH 0/4] TI Bluetooth serdev support In-Reply-To: References: <20170405183005.20570-1-robh@kernel.org> <20170430160430.rmyuo6sdrkrjxjg6@earth> <20170509044837.oje2tfodytyuuuur@sapphire.tkos.co.il> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, May 9, 2017 at 9:14 AM, Rob Herring wrote: > On Mon, May 8, 2017 at 11:48 PM, Baruch Siach 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 wrote: >>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel 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 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