| Message ID | 20170405183005.20570-1-robh@kernel.org |
|---|---|
| Headers | show |
| Series | TI Bluetooth serdev support | expand |
On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@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. adam > > The series is available on this git branch[1]. Patch 2 is just clean-up > and can be applied independently. Patch 3 is dependent on the series > "Nokia H4+ support". I'd suggest both series are merged thru the BT tree. > > Rob > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth > > Rob Herring (4): > dt-bindings: net: Add TI WiLink shared transport binding > bluetooth: hci_uart: remove unused hci_uart_init_tty > bluetooth: hci_uart: add LL protocol serdev driver support > arm64: dts: hikey: add WL1835 Bluetooth device node > > .../devicetree/bindings/net/ti,wilink-st.txt | 35 +++ > arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 + > drivers/bluetooth/hci_ldisc.c | 19 -- > drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++- > drivers/bluetooth/hci_uart.h | 1 - > 5 files changed, 300 insertions(+), 21 deletions(-) > create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt > > -- > 2.10.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi, On Fri, May 05, 2017 at 09:51:33AM -0500, Adam Ford wrote: > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@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@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) > > Since the pdata-quirks and original ti-st drivers work together, I > know the hardware is fine. The only change to the device tree is the > addition of the Bluetooth container: > > bluetooth { > compatible = "ti,wl1283-st"; > enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; > }; > > Any thoughts or suggestions to try? I get similar behavior on an > i.MX6 board with a wl1837-st module as well. Looks like its loosing bytes. I suggest to have a look at pinmuxing (esp. for cts & rts) and maybe add some debug prints to see where it starts failing. -- Sebastian
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@gmail.com> wrote: > > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@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@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 baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
On Fri, Oct 27, 2017 at 5:55 AM, Adam Ford <aford173@gmail.com> wrote: > On Tue, May 9, 2017 at 9:14 AM, Rob Herring <robh@kernel.org> wrote: >> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch@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@gmail.com> wrote: >>>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@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@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@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. > Nevermind. Sorry for the noise, I got past this part. I had a typo in my device tree. > thanks > > adam >> >> Rob