Re: [PATCH 0/4] TI Bluetooth serdev support

2017-10-28 Thread Adam Ford 
On Fri, Oct 27, 2017 at 5:55 AM, Adam Ford  wrote:
> 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 300 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
>

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-10-27 Thread Adam Ford 
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 300 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@6800/serial@4806c000/bluetooth

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-05-09 Thread Rob Herring 
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 300 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

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-05-08 Thread Baruch Siach 
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 300 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{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-05-08 Thread Rob Herring 
On Fri, May 5, 2017 at 9:51 AM, Adam Ford  wrote:
> On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel  wrote:
>> Hi,
>>
>> 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 300 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.

Rob

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-05-08 Thread Sebastian Reichel 
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  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 300 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 = < 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


signature.asc
Description: PGP signature

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-05-05 Thread Adam Ford 
On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel  wrote:
> Hi,
>
> 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 300 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 = < 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.

adam
> -- Sebastian

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-04-30 Thread Sebastian Reichel 
Hi,

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 300 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

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-04-30 Thread Adam Ford 
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 300 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-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/4] TI Bluetooth serdev support

2017-04-05 Thread Rob Herring 
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.

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