[RFC PATCH 0/3] bluetooth/gnss: GNSS support for TiWi chips

From: Andreas Kemnade <andreas@kemnade.info>
To: marcel@holtmann.org, johan.hedberg@gmail.com,
	luiz.dentz@gmail.com, johan@kernel.org, arnd@arndb.de,
	gregkh@linuxfoundation.org, andreas@kemnade.info,
	linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
	tomi.valkeinen@ideasonboard.com,
	"Tony Lindgren" <tony@atomide.com>,
	"Péter Ujfalusi" <peter.ujfalusi@gmail.com>,
	robh@kernel.org
Subject: [RFC PATCH 0/3] bluetooth/gnss: GNSS support for TiWi chips
Date: Sun, 26 Nov 2023 20:18:37 +0100	[thread overview]
Message-ID: <20231126191840.110564-1-andreas@kemnade.info> (raw)

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