| Message ID | 20240606183032.684481-1-andreas@kemnade.info (mailing list archive) |
|---|---|
| Headers | show |
| Series | Bluetooth/gnss: GNSS support for TiWi chips | expand |
Hi Andreas, On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > Some of these chips have GNSS support. In some vendor kernels > a driver on top of misc/ti-st can be found providing a /dev/tigps > device which speaks the secretive Air Independent Interface (AI2) protocol. > > To be more compatible with userspace send out NMEA by default but > allow a more raw mode by using a module parameter. > > This was tested on the Epson Moverio BT-200. > > Who will take this series (1-3)? GNSS with ack from Bluetooth? > > Changes since V3: > - Finally remove the period from 1/4 subject > - include things directly for get_unaligned_le16() to fix 0-day issues > > Changes since V2: > - Optimize waits > - Fix some packet analysis / checksum computation issue > - Adding a proposal for removing those waits as RFC > - Minor spell corrections and improved descriptions > > Changes since V1: > - Set up things for NMEA output > - Powerup/down at open()/close() > - split out logic between drivers/bluetooth and drivers/gnss > - leave out drivers/misc/ti-st driver removal to avoid > filling up mailboxes during the iterations, this series is > still a proof that it is not needed, will take the brush after > this series is accepted. > > > Andreas Kemnade (4): > gnss: Add AI2 protocol used by some TI combo chips > Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips The bluetooth one looks relatively simple so I could take that one and push to bluetooth-next if there are no dependencies on the other changes. > gnss: Add driver for AI2 protocol > gnss: ai2: replace long sleeps by wait for acks > > drivers/bluetooth/hci_ll.c | 81 +++++ > drivers/gnss/Kconfig | 13 + > drivers/gnss/Makefile | 3 + > drivers/gnss/ai2.c | 560 +++++++++++++++++++++++++++++++++++ > drivers/gnss/core.c | 1 + > include/linux/gnss.h | 1 + > include/linux/ti_wilink_st.h | 8 + > 7 files changed, 667 insertions(+) > create mode 100644 drivers/gnss/ai2.c > > -- > 2.39.2 >
Hi Luiz, On Thu, 6 Jun 2024 16:04:10 -0400 Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi Andreas, > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > Some of these chips have GNSS support. In some vendor kernels > > a driver on top of misc/ti-st can be found providing a /dev/tigps > > device which speaks the secretive Air Independent Interface (AI2) protocol. > > > > To be more compatible with userspace send out NMEA by default but > > allow a more raw mode by using a module parameter. > > > > This was tested on the Epson Moverio BT-200. > > > > Who will take this series (1-3)? GNSS with ack from Bluetooth? > > > > Changes since V3: > > - Finally remove the period from 1/4 subject > > - include things directly for get_unaligned_le16() to fix 0-day issues > > > > Changes since V2: > > - Optimize waits > > - Fix some packet analysis / checksum computation issue > > - Adding a proposal for removing those waits as RFC > > - Minor spell corrections and improved descriptions > > > > Changes since V1: > > - Set up things for NMEA output > > - Powerup/down at open()/close() > > - split out logic between drivers/bluetooth and drivers/gnss > > - leave out drivers/misc/ti-st driver removal to avoid > > filling up mailboxes during the iterations, this series is > > still a proof that it is not needed, will take the brush after > > this series is accepted. > > > > > > Andreas Kemnade (4): > > gnss: Add AI2 protocol used by some TI combo chips > > Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips > > The bluetooth one looks relatively simple so I could take that one and > push to bluetooth-next if there are no dependencies on the other > changes. > There is: include/linux/ti_wilink_st.h | 8 + We have compile time deps here. Patch 3 compile time depends on patch 2. If we cannot take everything in for 6.11, you might opt to take the bluetooth part. That would work. Regards, Andreas
On Thu, Jun 6, 2024 at 3:19 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > Hi Luiz, > > On Thu, 6 Jun 2024 16:04:10 -0400 > Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > > Hi Andreas, > > > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > Some of these chips have GNSS support. In some vendor kernels > > > a driver on top of misc/ti-st can be found providing a /dev/tigps > > > device which speaks the secretive Air Independent Interface (AI2) protocol. I think you may have sent me a file to test, but I can't find the e-mail. Can you tell me what tool you used to test it? I can get gnss0 to enumerate, so I am close. [ 20.759857] hci-ti serial0-0: using DT '/ocp@68000000/serial@4806c000/bluetooth-gnss' for 'enable' GPIO lookup [ 20.770263] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/ocp@68000000/serial@4806c000/bluetooth-gnss[0]' - status (0) [ 29.221588] gnss: GNSS driver registered with major 244 adam > > > > > > To be more compatible with userspace send out NMEA by default but > > > allow a more raw mode by using a module parameter. > > > > > > This was tested on the Epson Moverio BT-200. > > > > > > Who will take this series (1-3)? GNSS with ack from Bluetooth? > > > > > > Changes since V3: > > > - Finally remove the period from 1/4 subject > > > - include things directly for get_unaligned_le16() to fix 0-day issues > > > > > > Changes since V2: > > > - Optimize waits > > > - Fix some packet analysis / checksum computation issue > > > - Adding a proposal for removing those waits as RFC > > > - Minor spell corrections and improved descriptions > > > > > > Changes since V1: > > > - Set up things for NMEA output > > > - Powerup/down at open()/close() > > > - split out logic between drivers/bluetooth and drivers/gnss > > > - leave out drivers/misc/ti-st driver removal to avoid > > > filling up mailboxes during the iterations, this series is > > > still a proof that it is not needed, will take the brush after > > > this series is accepted. > > > > > > > > > Andreas Kemnade (4): > > > gnss: Add AI2 protocol used by some TI combo chips > > > Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips > > > > The bluetooth one looks relatively simple so I could take that one and > > push to bluetooth-next if there are no dependencies on the other > > changes. > > > There is: > > include/linux/ti_wilink_st.h | 8 + > > We have compile time deps here. Patch 3 compile time depends on patch 2. If we > cannot take everything in for 6.11, you might opt to take the bluetooth part. > That would work. > > Regards, > Andreas
Hi Adam, On Sat, 8 Jun 2024 14:00:38 -0500 Adam Ford <aford173@gmail.com> wrote: > On Thu, Jun 6, 2024 at 3:19 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > Hi Luiz, > > > > On Thu, 6 Jun 2024 16:04:10 -0400 > > Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > > > > Hi Andreas, > > > > > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > > > Some of these chips have GNSS support. In some vendor kernels > > > > a driver on top of misc/ti-st can be found providing a /dev/tigps > > > > device which speaks the secretive Air Independent Interface (AI2) protocol. > > I think you may have sent me a file to test, but I can't find the > e-mail. Can you tell me what tool you used to test it? I can get > gnss0 to enumerate, so I am close. > hmm, /bin/cat is sufficient. It should spit out nmea now by default. For playing around with raw mode, you need the ai2raw parameter and then you can play around with read-gps from https://github.com/akemnade/bt200tools > [ 20.759857] hci-ti serial0-0: using DT > '/ocp@68000000/serial@4806c000/bluetooth-gnss' for 'enable' GPIO > lookup > [ 20.770263] of_get_named_gpiod_flags: parsed 'enable-gpios' > property of node '/ocp@68000000/serial@4806c000/bluetooth-gnss[0]' - > status (0) > [ 29.221588] gnss: GNSS driver registered with major 244 > That is nice. Regards, Andreas
On Sat, Jun 8, 2024 at 2:20 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > Hi Adam, > > On Sat, 8 Jun 2024 14:00:38 -0500 > Adam Ford <aford173@gmail.com> wrote: > > > On Thu, Jun 6, 2024 at 3:19 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > Hi Luiz, > > > > > > On Thu, 6 Jun 2024 16:04:10 -0400 > > > Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > > > > > > Hi Andreas, > > > > > > > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > > > > > Some of these chips have GNSS support. In some vendor kernels > > > > > a driver on top of misc/ti-st can be found providing a /dev/tigps > > > > > device which speaks the secretive Air Independent Interface (AI2) protocol. > > > > I think you may have sent me a file to test, but I can't find the > > e-mail. Can you tell me what tool you used to test it? I can get > > gnss0 to enumerate, so I am close. > > > hmm, /bin/cat is sufficient. It should spit out nmea now by default. > > For playing around with raw mode, you need the ai2raw parameter > and then you can play around with read-gps from > https://github.com/akemnade/bt200tools > > > [ 20.759857] hci-ti serial0-0: using DT > > '/ocp@68000000/serial@4806c000/bluetooth-gnss' for 'enable' GPIO > > lookup > > [ 20.770263] of_get_named_gpiod_flags: parsed 'enable-gpios' > > property of node '/ocp@68000000/serial@4806c000/bluetooth-gnss[0]' - > > status (0) > > [ 29.221588] gnss: GNSS driver registered with major 244 > > > That is nice. I think I am stuck. The closed-sourced GPS binary that Logic PD did was done a 3rd party which has since been sold, and Logic PD never had the source code, I just get junk with this driver: $GPGLL,,,,,,V,N*64 $GPRMC,,V,,,,,,,,,,N*53 $GPGGA,,,,,,0,,,,,,,,*66 $GPVTG,,T,,M,,N,,K,N*2C $GPGSA,M,1,,,,,,,,,,,,,,,*12 $GPGSV,1,1,00*79 $GPGLL,,,,,,V,N*64 $GPRMC,,V,,,,,,,,,,N*53 $GPGGA,,,,,,0,,,,,,,,*66 $GPVTG,,T,,M,,N,,K,N*2C $GPGSA,M,1,,,,,,,,,,,,,,,*12 $GPGSV,1,1,00*79 $GPGLL,,,,,,V,N*64 $GPRMC,,V,,,,,,,,,,N*53 $GPGGA,,,,,,0,,,,,,,,*66 $GPVTG,,T,,M,,N,,K,N*2C $GPGSA,M,1,,,,,,,,,,,,,,,*12 $GPGSV,1,1,00*79 I am not 100% positive, but I think the antenna might be required to be powered. I'll talk with the HW engineer who designed the Torpedo + Wireless SOM and see if he remembers anyhthing about the GPS. I know for a fact that Logic PD doesn't have the source code for their GPS demo, and I know it doesn't work with modern kernels, so i can't compare the performance. :-( adam > > Regards, > Andreas
Hi Adam, On Mon, 10 Jun 2024 18:17:05 -0500 Adam Ford <aford173@gmail.com> wrote: > On Sat, Jun 8, 2024 at 2:20 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > Hi Adam, > > > > On Sat, 8 Jun 2024 14:00:38 -0500 > > Adam Ford <aford173@gmail.com> wrote: > > > > > On Thu, Jun 6, 2024 at 3:19 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > > > Hi Luiz, > > > > > > > > On Thu, 6 Jun 2024 16:04:10 -0400 > > > > Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > > > > > > > > Hi Andreas, > > > > > > > > > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <andreas@kemnade.info> wrote: > > > > > > > > > > > > Some of these chips have GNSS support. In some vendor kernels > > > > > > a driver on top of misc/ti-st can be found providing a /dev/tigps > > > > > > device which speaks the secretive Air Independent Interface (AI2) protocol. > > > > > > I think you may have sent me a file to test, but I can't find the > > > e-mail. Can you tell me what tool you used to test it? I can get > > > gnss0 to enumerate, so I am close. > > > > > hmm, /bin/cat is sufficient. It should spit out nmea now by default. > > > > For playing around with raw mode, you need the ai2raw parameter > > and then you can play around with read-gps from > > https://github.com/akemnade/bt200tools > > > > > [ 20.759857] hci-ti serial0-0: using DT > > > '/ocp@68000000/serial@4806c000/bluetooth-gnss' for 'enable' GPIO > > > lookup > > > [ 20.770263] of_get_named_gpiod_flags: parsed 'enable-gpios' > > > property of node '/ocp@68000000/serial@4806c000/bluetooth-gnss[0]' - > > > status (0) > > > [ 29.221588] gnss: GNSS driver registered with major 244 > > > > > That is nice. > > I think I am stuck. The closed-sourced GPS binary that Logic PD did > was done a 3rd party which has since been sold, and Logic PD never had > the source code, I just get junk with this driver: > Well, the whole thing is kept in secrecy. But the junk you get is just plain NMEA which I get also when device is indoors, so you got the chip into a mode which common user space (like gpsd) understands. So IMHO that is a Tested-By. So thanks a lot. I am happy with that result for the first step. So first rpc was tested with a Motorola tablet and the BT200, this one now with two different devices, so it is a good situation. > $GPGLL,,,,,,V,N*64 > $GPRMC,,V,,,,,,,,,,N*53 > $GPGGA,,,,,,0,,,,,,,,*66 > $GPVTG,,T,,M,,N,,K,N*2C > $GPGSA,M,1,,,,,,,,,,,,,,,*12 > $GPGSV,1,1,00*79 > $GPGLL,,,,,,V,N*64 > $GPRMC,,V,,,,,,,,,,N*53 > $GPGGA,,,,,,0,,,,,,,,*66 > $GPVTG,,T,,M,,N,,K,N*2C > $GPGSA,M,1,,,,,,,,,,,,,,,*12 > $GPGSV,1,1,00*79 > $GPGLL,,,,,,V,N*64 > $GPRMC,,V,,,,,,,,,,N*53 > $GPGGA,,,,,,0,,,,,,,,*66 > $GPVTG,,T,,M,,N,,K,N*2C > $GPGSA,M,1,,,,,,,,,,,,,,,*12 > $GPGSV,1,1,00*79 > A note: contrary to other GPS I have seen, this one does not give out satellite reception strength if not much is known about position. So this pattern might continue a bit even if antenna is there and gps reception is good. Much development of this driver was done in a hammock with keyboard in a sleeping bag outside so I know a bit... > I am not 100% positive, but I think the antenna might be required to > be powered. I'll talk with the HW engineer who designed the Torpedo + > Wireless SOM and see if he remembers anyhthing about the GPS. I know > for a fact that Logic PD doesn't have the source code for their GPS > demo, and I know it doesn't work with modern kernels, so i can't > compare the performance. > Well, and demo tools are not easily available anywhere... Well, I think if there is some special antenna powering stuff, that can be done in a second step. Probably just a gpio or something. But that would affect both the testing tools and the in-kernel solution. As said, you might use the ai2raw=1 parameter and try the read_gps from bt200tools. Or the demo might work if you symlink gnss0 to tigps. > :-( Well, no, correct is :-) Regards, Andreas
Hi, Am Thu, 6 Jun 2024 16:04:10 -0400 schrieb Luiz Augusto von Dentz <luiz.dentz@gmail.com>: > Hi Andreas, > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <andreas@kemnade.info> > wrote: > > > > Some of these chips have GNSS support. In some vendor kernels > > a driver on top of misc/ti-st can be found providing a /dev/tigps > > device which speaks the secretive Air Independent Interface (AI2) > > protocol. > > > > To be more compatible with userspace send out NMEA by default but > > allow a more raw mode by using a module parameter. > > > > This was tested on the Epson Moverio BT-200. > > > > Who will take this series (1-3)? GNSS with ack from Bluetooth? > > > > Changes since V3: > > - Finally remove the period from 1/4 subject > > - include things directly for get_unaligned_le16() to fix 0-day > > issues > > > > Changes since V2: > > - Optimize waits > > - Fix some packet analysis / checksum computation issue > > - Adding a proposal for removing those waits as RFC > > - Minor spell corrections and improved descriptions > > > > Changes since V1: > > - Set up things for NMEA output > > - Powerup/down at open()/close() > > - split out logic between drivers/bluetooth and drivers/gnss > > - leave out drivers/misc/ti-st driver removal to avoid > > filling up mailboxes during the iterations, this series is > > still a proof that it is not needed, will take the brush after > > this series is accepted. > > > > > > Andreas Kemnade (4): > > gnss: Add AI2 protocol used by some TI combo chips > > Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips > > The bluetooth one looks relatively simple so I could take that one and > push to bluetooth-next if there are no dependencies on the other > changes. > hmm, nothing happens here. You did not ack it so Johan could not take it. So what about taking the bluetooth patch now and the other ones can go in for maybe 6.13? At least that would reduce spam and the poor bluetooth ci bot will not spam complaints because it sees non-bluetotoh patches. Regards, Andreas
On Mon, Sep 02, 2024 at 11:22:21AM +0200, Andreas Kemnade wrote: > Am Thu, 6 Jun 2024 16:04:10 -0400 > schrieb Luiz Augusto von Dentz <luiz.dentz@gmail.com>: > > > Andreas Kemnade (4): > > > gnss: Add AI2 protocol used by some TI combo chips > > > Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips > > > > The bluetooth one looks relatively simple so I could take that one and > > push to bluetooth-next if there are no dependencies on the other > > changes. > > > hmm, nothing happens here. You did not ack it so Johan could not take > it. So what about taking the bluetooth patch now and the other ones can > go in for maybe 6.13? At least that would reduce spam and the poor > bluetooth ci bot will not spam complaints because it sees non-bluetotoh > patches. No, please don't merge anything before I've looked at this. It's on my list, I'll try to get to this soon. Johan
Am Mon, 2 Sep 2024 11:26:07 +0200 schrieb Johan Hovold <johan@kernel.org>: > On Mon, Sep 02, 2024 at 11:22:21AM +0200, Andreas Kemnade wrote: > > Am Thu, 6 Jun 2024 16:04:10 -0400 > > schrieb Luiz Augusto von Dentz <luiz.dentz@gmail.com>: > > > > > Andreas Kemnade (4): > > > > gnss: Add AI2 protocol used by some TI combo chips > > > > Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips > > > > > > The bluetooth one looks relatively simple so I could take that one and > > > push to bluetooth-next if there are no dependencies on the other > > > changes. > > > > > hmm, nothing happens here. You did not ack it so Johan could not take > > it. So what about taking the bluetooth patch now and the other ones can > > go in for maybe 6.13? At least that would reduce spam and the poor > > bluetooth ci bot will not spam complaints because it sees non-bluetotoh > > patches. > > No, please don't merge anything before I've looked at this. It's on my > list, I'll try to get to this soon. > any updates here? Regards, Andreas > Johan >
[ +CC: Sebastian ] Hi Andreas, and sorry about the late reply on this. On Thu, Jun 06, 2024 at 08:30:28PM +0200, Andreas Kemnade wrote: > Some of these chips have GNSS support. In some vendor kernels > a driver on top of misc/ti-st can be found providing a /dev/tigps > device which speaks the secretive Air Independent Interface (AI2) protocol. Please expand the cover letter and commit messages with more details on the protocols and backstory here. I spent hours over the Christmas break digging through drivers, git logs and mail archives for information that should have been part of the series. Specifically, give a better description of these chips which are WiFi controllers with Bluetooth primarily and then some have (optional?) FM radio and GPS support as well. Some even seem to support NFC too (also over HCI?). Provide some background on the ti-st driver, which have now been removed; the fact that we already had two drivers for these chips with one only supporting the Bluetooth (and later some PM) bits; say something about the FM driver which someone also recently decided to remove on questionable grounds. Please also refer to the prior attempts at adding support for the various subfunctions to the driver (e.g. Sebastian's discussion with Marcel on how to possibly abstract this in Bluetooth core), such as: https://lore.kernel.org/lkml/0C9AD246-B511-4E59-888F-47EAB034D4BF@holtmann.org/ > To be more compatible with userspace send out NMEA by default but > allow a more raw mode by using a module parameter. I'm very hesitant about adding a module parameters for such configuration. There's very little detail about the AI2 protocol in this series, but I'm inclined to just say expose it to user space and let it deal with it. Or you can argue that we'll never be able to reverse engineer the protocol enough, but that enabling NMEA and exposing that is straight-forward enough (and safe) to be done in the kernel. At the least, please provide an overview of the protocol (and also include an example such as the one you provided in a previous thread), what functionality it appears to provide, and how it can be used to generate NMEA (e.g. so we can have a discussion about this). Do all the WiLink devices use AI2? Or could some be exposing raw NMEA? (And how does "TiWi" relate to "WiLink"?) > This was tested on the Epson Moverio BT-200. > > Who will take this series (1-3)? GNSS with ack from Bluetooth? I can take the whole series once we've figured out how to model this. Johan
> Am 14.01.2025 um 12:57 schrieb Johan Hovold <johan@kernel.org>: > > (And how does "TiWi" relate to "WiLink"?) "WiLink" seems to be the Texas Instruments trademark of the chips (e.g. WiLink series 5, 6, 8 etc. [1]). "TiWi" seems to be a nickname for this which is not violating the trademark and potentially distinguishing it better from the other chip brands? Texas Instruments doesn't seem to use "TiWi", but distributors, module manufacturers, and software developers. E.g. [2] [1]: https://www.ti.com/lit/ml/swpb012b/swpb012b.pdf [2]: https://www.cs.utexas.edu/~simon/378/resources/PandaBoardES.pdf
Hi, On Tue, Jan 14, 2025 at 12:57:05PM +0100, Johan Hovold wrote: > [ +CC: Sebastian ] > > Hi Andreas, > > and sorry about the late reply on this. > > On Thu, Jun 06, 2024 at 08:30:28PM +0200, Andreas Kemnade wrote: > > Some of these chips have GNSS support. In some vendor kernels > > a driver on top of misc/ti-st can be found providing a /dev/tigps > > device which speaks the secretive Air Independent Interface (AI2) protocol. > > Please expand the cover letter and commit messages with more details on > the protocols and backstory here. I spent hours over the Christmas break > digging through drivers, git logs and mail archives for information that > should have been part of the series. > > Specifically, give a better description of these chips which are WiFi > controllers with Bluetooth primarily and then some have (optional?) FM > radio and GPS support as well. Some even seem to support NFC too (also > over HCI?). Your TI WiLink chip description matches my understanding. In addition to some chips not support the optional features, there may also be some boards with cripped support (i.e. when an antenna is not connected). So having a DT property flag to describe working GPS would be an option. > Provide some background on the ti-st driver, which have now been > removed; the fact that we already had two drivers for these chips with > one only supporting the Bluetooth (and later some PM) bits; say > something about the FM driver which someone also recently decided to > remove on questionable grounds. > > Please also refer to the prior attempts at adding support for the > various subfunctions to the driver (e.g. Sebastian's discussion with > Marcel on how to possibly abstract this in Bluetooth core), such as: > > https://lore.kernel.org/lkml/0C9AD246-B511-4E59-888F-47EAB034D4BF@holtmann.org/ I haven't really worked with TI WiLink in the last 5 years. The Droid 4, which I played around with, is no usable for me since the 3G network has been killed (and the Droid 4 only supports the US band for 4G). As visible from the series you linked, my last plans were to kill ti-st, which pre-dates serdev. The hcill bluetooth driver was introduced by Rob Herring together with the initial serdev core as a cleaner replacement. Greetings, -- Sebastian