On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch@xxxxxxxxxx> 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@xxxxxxxxx> wrote: >> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@xxxxxxxxxx> 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@xxxxxxxxxx> 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. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
