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.
Implement something comparable as a GNSS interface.
With some userspace tools a proof-of-concept can be shown. A position
can be successfully read out. Basic properties of the protocol are
understood.
This was tested on the Epson Moverio BT-200.
This is sent out as an early RFC to ensure I am going onto the right
track:
So the main questions I see:
- is the approach right to abandon drivers/misc/ti-st?
- Output at /dev/gnssX:
AI2 vs. NMEA
The chip can be configured into sending AI2-encapsulated NMEA,
or proving data in a binary format.
Some research has to be done yet for the details.
A pile of logs is waiting for further analysis...
Arguments for/against NMEA:
+ Userspace is prepared to handle it
+ Power management can be easily done by the kernel
- Less functionality can be used.
Arguments for/against AI2:
+ Full functionality can be accessed from userspace (incl. A-GPS,
maybe raw satellite data)
- Userspace has to behave to have proper power management
- No freely (not even as in beer) tool available to fully use AI2,
so there will be only a real advantage after long "French Cafe"
sessions.
More detailed tings:
- Some live cycle management is left out. Since it depends
on the decisions above, I have not put much thought into it.
- Should some pieces go into drivers/gnss?
- detection for GNSS availability: For now the node name is
used. But the device should be there if the chip supports it
and things are wired up properly.
Andreas Kemnade (3):
gnss: Add AI2 protocol used by some TI combo chips.
bluetooth: ti-st: add GNSS support for TI Wilink chips
drivers: misc: ti-st: begin to deorbit
drivers/bluetooth/hci_ll.c | 154 ++++++++++++++++++++++++++++++++++++-
drivers/gnss/core.c | 1 +
drivers/misc/ti-st/Kconfig | 2 +-
include/linux/gnss.h | 1 +
4 files changed, 156 insertions(+), 2 deletions(-)
--
2.39.2
