[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST
From:       Adam Ford <aford173 () gmail ! com>
Date:       2019-09-30 23:42:13
Message-ID: CAHCN7xKdACg962p+bEO8+jHGHoVdsRXZKZ5hmE4nTO1_zsDmYw () mail ! gmail ! com
[Download RAW message or body]

On Fri, May 10, 2019 at 10:38 AM Marcel Holtmann <marcel@holtmann.org> wrote:
> 
> Hi Adam,
> 
> > > > > > > > This moves all remaining users of the legacy TI_ST driver to hcill (patches
> > > > > > > > 1-3). Then patches 4-7 convert wl128x-radio driver to a standard platform
> > > > > > > > device driver with support for multiple instances. Patch 7 will result in
> > > > > > > > (userless) TI_ST driver no longer supporting radio at runtime. Patch 8-11 do
> > > > > > > > some cleanups in the wl128x-radio driver. Finally patch 12 removes the TI_ST
> > > > > > > > specific parts from wl128x-radio and adds the required infrastructure to use it
> > > > > > > > with the serdev hcill driver instead. The remaining patches 13 and 14 remove
> > > > > > > > the old TI_ST code.
> > > > > > > > 
> > > > > > > > The new code has been tested on the Motorola Droid 4. For testing the audio
> > > > > > > > should be configured to route Ext to Speaker or Headphone. Then you need to
> > > > > > > > plug headphone, since its cable is used as antenna. For testing there is a
> > > > > > > > 'radio' utility packages in Debian. When you start the utility you need to
> > > > > > > > specify a frequency, since initial get_frequency returns an error:
> > > > > > > 
> > > > > > > What is the status of this series?
> > > > > > > 
> > > > > > > Based on some of the replies (from Adam Ford in particular) it appears that
> > > > > > > this isn't ready to be merged, so is a v2 planned?
> > > > > > 
> > > > > > Yes, a v2 is planned, but I'm super busy at the moment. I don't
> > > > > > expect to send something for this merge window. Neither LogicPD
> > > > > > nor IGEP use FM radio, so I can just remove FM support from the
> > > > > > TI_ST framework. Converting those platforms to hci_ll can be done
> > > > > > in a different patchset.
> > > > > > 
> > > > > > If that was the only issue there would be a v2 already. But Marcel
> > > > > > Holtmann suggested to pass the custom packet data through the BT
> > > > > > subsystem, which is non-trivial (at least for me) :)
> > > > > 
> > > > > I am running some tests today on the wl1283-st on the Logic PD Torpedo
> > > > > board.  Tony had suggested a few options, so I'm going to try those.
> > > > > Looking at those today.  If/when you have a V2, please CC me on it. If
> > > > > it's been posted, can you send me a link?  I would really like to see
> > > > > the st-kim driver go away so I'd like to resolve the issues with the
> > > > > torpedo board.
> > > > 
> > > > I have run a bunch of tests on the 5.1 kernel.  I am able to get the
> > > > firmware to load now and the hci0 goes up.  I was able to establish a
> > > > BLE connection to a TI Sensor Tag and read and write data to it with
> > > > good success on the wl1283.
> > > > 
> > > > Unfortunately, when I tried to do some more extensive testing over
> > > > classic Bluetooth, I got an error that repeats itself at seemingly
> > > > random intervals:
> > > > Bluetooth: hci0: Frame reassembly failed (-84)
> > > > 
> > > > I can still scan and pair, but these Frame reassembly failed errors
> > > > appear to come and go.
> > > 
> > > there are only 3 places in h4_recv_buf that return EILSEQ. Just add an extra printk to these to \
> > > figure out which one it is. Maybe it is just extra packet types that we need to handle. If it is \
> > > not the packet type one, print what packet we have that is causing this. 
> > 
> > I added some code around
> > 
> > /* Check for invalid packet type */
> > if (!skb) {
> > printk("Check for invalid packet type %x\n", (unsigned int)
> > (&pkts[i])->type);
> > return ERR_PTR(-EILSEQ);
> > }
> > 
> > I don't know if I did it right or I am reading the packet type
> > correctly, but the frame reassembly errors are being caught here.
> > 
> > [  408.519165] Check for invalid packet type ff
> > [  408.523559] Bluetooth: hci0: Frame reassembly failed (-84)
> 
> so now we need to figure our on how to handle HCI_VENDOR_PKT.
> 
> #define LL_RECV_VENDOR \
> .type = HCI_VENDOR_PKT, \
> .hlen = aaa, \
> .loff = bbb, \
> .lsize = ccc, \
> .maxlen = ddd
> 
> static const struct h4_recv_pkt ll_recv_pkts[] = {
> ...
> { LL_RECV_WAKE_ACK,  .recv = ll_recv_frame  },
> { LL_RECV_VENDOR,    .recv = hci_recv_diag  },
> };
> 
> Can you hexdump the data inside the skb and we can figure out what it uses for the header and size.
> 
> In hci_bcm.c there are a few examples of fixed size packets and bpa10x.c contains one where it follows \
> an actual header definition. Also hci_nokia.c contains a few for their packets.

I haven't forgotten this, but I was highly distracted.  I wanted to
test a bunch of stuff on omap3630 and imx6 boards to prep them for the
upcoming 5.4 LTS kernel.  As of now I 'think' this is the last item on
my to-do list.

I'm going to try and throw some debug code into the older st/kim
driver as well as debug this.  I know some people have stated they
have wl1283-st working on a dm3730.  dump some logs?  I am curious to
see if there is anything that can be gained by sharing the info.  I'd
love to see the older st/kim drivers deprecated.

adam
> 
> Regards
> 
> Marcel
> 


[prev in list] [next in list] [prev in thread] [next in thread]