2024-06-06 18:31:02

by Andreas Kemnade

[permalink] [raw]
Subject: [PATCH v4 0/4] Bluetooth/gnss: GNSS support for TiWi chips

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



2024-06-06 18:31:08

by Andreas Kemnade

[permalink] [raw]
Subject: [PATCH RFC v4 4/4] gnss: ai2: replace long sleeps by wait for acks

Previously there were long sleeps for everything sent out.
Replace the sleeps by some wait for completion.
Wait times like 60ms are seen.
There are ack packets sent out if requested. Unfortunately
just waiting for them seems not stable, some open()/close()
loop stress-testing brings the communication into complete
disorder. Unfortunately these ack packets arrive before
a complete answer of the command has been received but
apparently after some processing has been done.
Properly declaring expected answers might help but adding
that can only be justified after some wider testing.

So leaving this part of the series as a RFC and base
for future optimzations.

Signed-off-by: Andreas Kemnade <[email protected]>
---
drivers/gnss/ai2.c | 110 +++++++++++++++++++++++++++++----------------
1 file changed, 71 insertions(+), 39 deletions(-)

diff --git a/drivers/gnss/ai2.c b/drivers/gnss/ai2.c
index 930c065050917..be72fb7fcc272 100644
--- a/drivers/gnss/ai2.c
+++ b/drivers/gnss/ai2.c
@@ -6,6 +6,7 @@
* Copyright (C) 2024 Andreas Kemnade <[email protected]>
*/
#include <asm/byteorder.h>
+#include <linux/completion.h>
#include <linux/errno.h>
#include <linux/gnss.h>
#include <linux/init.h>
@@ -68,6 +69,16 @@ struct ai2_device {
struct device *dev;
struct sk_buff *recv_skb;
bool recv_esc;
+ /*
+ * completion for the lower level around
+ * GPS_CH9_OP_COMPLETED_EVT
+ * probably more important if we send large
+ * fragmented packets
+ */
+ struct completion ch9_complete;
+
+ /* completion for AI2 ack packets */
+ struct completion ai2_ack_complete;
};

static struct sk_buff *ai2_skb_alloc(unsigned int len, gfp_t how)
@@ -87,6 +98,7 @@ static int ai2_send_frame(struct ai2_device *ai2dev,
int len;
struct gps_event_hdr *gnssdrv_hdr;
struct hci_dev *hdev;
+ int ret;

if (skb->len >= U16_MAX)
return -EINVAL;
@@ -96,13 +108,25 @@ static int ai2_send_frame(struct ai2_device *ai2dev,
* not needed for simple config commands
*/
len = skb->len;
+ print_hex_dump_bytes("ai2 send frame: ", DUMP_PREFIX_OFFSET, skb->data, skb->len);
+
gnssdrv_hdr = skb_push(skb, sizeof(struct gps_event_hdr));
gnssdrv_hdr->opcode = GPS_CH9_OP_WRITE;
gnssdrv_hdr->plen = __cpu_to_le16(len);
-
hci_skb_pkt_type(skb) = GPS_CH9_PKT_NUMBER;
hdev = st_get_hci(ai2dev->dev->parent);
- return hdev->send(hdev, skb);
+ reinit_completion(&ai2dev->ch9_complete);
+
+ ret = hdev->send(hdev, skb);
+ if (ret)
+ return ret;
+
+ if (!wait_for_completion_timeout(&ai2dev->ch9_complete,
+ msecs_to_jiffies(2000)))
+ return -ETIMEDOUT;
+ dev_dbg(ai2dev->dev, "send finished\n");
+
+ return 0;
}

static void ai2_put_escaped(struct sk_buff *skb, u8 d)
@@ -151,30 +175,50 @@ static struct sk_buff *ai2_compose_frame(bool request_ack,
return skb;
}

-static int ai2_set_receiver_state(struct ai2_device *ai2dev,
- uint8_t state)
+static int ai2_compose_send_frame(struct ai2_device *ai2dev,
+ bool request_ack,
+ u8 cmd,
+ const u8 *data,
+ int len)
{
- struct sk_buff *skb = ai2_compose_frame(true, AI2_CMD_RECEIVER_STATE,
- &state, 1);
+ struct sk_buff *skb = ai2_compose_frame(request_ack, cmd, data, len);
if (!skb)
return -ENOMEM;

+ if (request_ack) {
+ int ret;
+
+ reinit_completion(&ai2dev->ai2_ack_complete);
+
+ ret = ai2_send_frame(ai2dev, skb);
+ if (ret)
+ return ret;
+
+ if (!wait_for_completion_timeout(&ai2dev->ai2_ack_complete,
+ msecs_to_jiffies(2000)))
+ return -ETIMEDOUT;
+
+ return 0;
+ }
+
return ai2_send_frame(ai2dev, skb);
}

+static int ai2_set_receiver_state(struct ai2_device *ai2dev,
+ uint8_t state)
+{
+ return ai2_compose_send_frame(ai2dev, true, AI2_CMD_RECEIVER_STATE,
+ &state, 1);
+}
+
static int ai2_config_nmea_reports(struct ai2_device *ai2dev,
uint8_t mask)
{
u8 buf[4] = {0};
- struct sk_buff *skb;

buf[0] = mask;
- skb = ai2_compose_frame(true, AI2_CMD_CONFIG_NMEA,
- buf, sizeof(buf));
- if (!skb)
- return -ENOMEM;
-
- return ai2_send_frame(ai2dev, skb);
+ return ai2_compose_send_frame(ai2dev, true, AI2_CMD_CONFIG_NMEA,
+ buf, sizeof(buf));
}

/*
@@ -187,22 +231,12 @@ static int gnss_ai2_init(struct ai2_device *ai2dev)
{
int ret;
u8 d = 0x01;
- struct sk_buff *skb = ai2_compose_frame(true, 0xf5, &d, 1);
-
- if (!skb)
- return -ENOMEM;
-
- ret = ai2_send_frame(ai2dev, skb);
+ ret = ai2_compose_send_frame(ai2dev, true, 0xf5, &d, 1);
if (ret)
return ret;

- msleep(200); /* seen some 60ms response time here, so wait a bit */
d = 5;
- skb = ai2_compose_frame(true, 0xf1, &d, 1);
- if (!skb)
- return -ENOMEM;
-
- return ai2_send_frame(ai2dev, skb);
+ return ai2_compose_send_frame(ai2dev, true, 0xf1, &d, 1);
}

static int gnss_ai2_open(struct gnss_device *gdev)
@@ -220,18 +254,14 @@ static int gnss_ai2_open(struct gnss_device *gdev)
if (ret)
goto err;

- /* TODO: find out on what kind of ack we should wait */
- msleep(50);
ret = ai2_set_receiver_state(ai2dev, RECEIVER_STATE_IDLE);
if (ret)
goto err;

- msleep(100);
ret = ai2_config_nmea_reports(ai2dev, NMEA_MASK_ALL);
if (ret)
goto err;

- msleep(50);
ret = ai2_set_receiver_state(ai2dev, RECEIVER_STATE_ON);
if (ret)
goto err;
@@ -254,13 +284,9 @@ static void gnss_ai2_close(struct gnss_device *gdev)
{
struct ai2_device *ai2dev = gnss_get_drvdata(gdev);

- /* TODO: find out on what kind of ack we should wait */
if (!ai2raw) {
- msleep(50);
ai2_set_receiver_state(ai2dev, RECEIVER_STATE_IDLE);
- msleep(50);
ai2_set_receiver_state(ai2dev, RECEIVER_STATE_OFF);
- msleep(200); /* seen some longer response time here, so wait */
}

mutex_lock(&ai2dev->gdev_mutex);
@@ -345,8 +371,10 @@ static void process_ai2_frame(struct ai2_device *ai2dev)
}

/* reached if byte 1 in the command packet is set to 1 */
- if (data[1] == AI2_ACK)
+ if (data[1] == AI2_ACK) {
+ complete(&ai2dev->ai2_ack_complete);
return;
+ }

head = skb_pull(ai2dev->recv_skb, 2); /* drop frame start marker */
while (head && (ai2dev->recv_skb->len >= 3)) {
@@ -434,11 +462,9 @@ static void gnss_recv_frame(struct device *dev, struct sk_buff *skb)
gnss_hdr = (struct gps_event_hdr *)skb->data;

data = skb_pull(skb, sizeof(*gnss_hdr));
- /*
- * REVISIT: maybe do something with the completed
- * event
- */
- if (gnss_hdr->opcode == GPS_CH9_OP_READ) {
+
+ switch (gnss_hdr->opcode) {
+ case GPS_CH9_OP_READ:
mutex_lock(&ai2dev->gdev_mutex);
if (ai2dev->gdev_open) {
if (ai2raw)
@@ -450,6 +476,10 @@ static void gnss_recv_frame(struct device *dev, struct sk_buff *skb)
"receiving data while chip should be off\n");
}
mutex_unlock(&ai2dev->gdev_mutex);
+ break;
+ case GPS_CH9_OP_COMPLETED_EVT:
+ complete(&ai2dev->ch9_complete);
+ break;
}
kfree_skb(skb);
}
@@ -475,6 +505,8 @@ static int gnss_ai2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ai2dev);
st_set_gnss_recv_func(pdev->dev.parent, gnss_recv_frame);
mutex_init(&ai2dev->gdev_mutex);
+ init_completion(&ai2dev->ch9_complete);
+ init_completion(&ai2dev->ai2_ack_complete);

ret = gnss_register_device(gdev);
if (ret)
--
2.39.2


2024-06-06 18:37:41

by Andreas Kemnade

[permalink] [raw]
Subject: [PATCH v4 2/4] Bluetooth: ti-st: Add GNSS subdevice for TI Wilink chips

Some of these chips have GNSS support. GNSS support is available through
channel 9 whilst FM is through channel 8. Add a platform subdevice for
GNSS so that a driver for that functionality can be build. To avoid having
useless GNSS devices, do it only when the devicetree node name contains
gnss.

Signed-off-by: Andreas Kemnade <[email protected]>
Reviewed-by: Paul Menzel <[email protected]>
---
drivers/bluetooth/hci_ll.c | 81 ++++++++++++++++++++++++++++++++++++
include/linux/ti_wilink_st.h | 8 ++++
2 files changed, 89 insertions(+)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 4a0b5c3160c2b..09e5a4dbd2f8c 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -32,6 +32,7 @@
#include <linux/signal.h>
#include <linux/ioctl.h>
#include <linux/of.h>
+#include <linux/platform_device.h>
#include <linux/serdev.h>
#include <linux/skbuff.h>
#include <linux/ti_wilink_st.h>
@@ -68,6 +69,9 @@ struct ll_device {
struct gpio_desc *enable_gpio;
struct clk *ext_clk;
bdaddr_t bdaddr;
+
+ void (*gnss_recv_func)(struct device *dev, struct sk_buff *skb);
+ struct platform_device *gnssdev;
};

struct ll_struct {
@@ -78,6 +82,8 @@ struct ll_struct {
struct sk_buff_head tx_wait_q; /* HCILL wait queue */
};

+static int ll_gnss_register(struct ll_device *lldev);
+static int ll_gnss_recv_frame(struct hci_dev *hdev, struct sk_buff *skb);
/*
* Builds and sends an HCILL command packet.
* These are very simple packets with only 1 cmd byte
@@ -411,6 +417,13 @@ static int ll_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
.lsize = 0, \
.maxlen = 0

+#define LL_RECV_GNSS \
+ .type = 9, \
+ .hlen = 3, \
+ .loff = 1, \
+ .lsize = 2
+
+
static const struct h4_recv_pkt ll_recv_pkts[] = {
{ H4_RECV_ACL, .recv = hci_recv_frame },
{ H4_RECV_SCO, .recv = hci_recv_frame },
@@ -419,6 +432,7 @@ static const struct h4_recv_pkt ll_recv_pkts[] = {
{ LL_RECV_SLEEP_ACK, .recv = ll_recv_frame },
{ LL_RECV_WAKE_IND, .recv = ll_recv_frame },
{ LL_RECV_WAKE_ACK, .recv = ll_recv_frame },
+ { LL_RECV_GNSS, .recv = ll_gnss_recv_frame },
};

/* Recv data */
@@ -677,9 +691,69 @@ static int ll_setup(struct hci_uart *hu)
}
}

+ if (strstr(of_node_full_name(serdev->dev.of_node), "gnss"))
+ ll_gnss_register(lldev);
+
+ return 0;
+}
+
+struct hci_dev *st_get_hci(struct device *dev)
+{
+ struct ll_device *lldev = dev_get_drvdata(dev);
+
+ return lldev->hu.hdev;
+}
+EXPORT_SYMBOL(st_get_hci);
+
+void st_set_gnss_recv_func(struct device *dev,
+ void (*recv_frame)(struct device *, struct sk_buff *))
+{
+ struct ll_device *lldev = dev_get_drvdata(dev);
+
+ lldev->gnss_recv_func = recv_frame;
+}
+EXPORT_SYMBOL(st_set_gnss_recv_func);
+
+static int ll_gnss_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct hci_uart *hu = hci_get_drvdata(hdev);
+ struct ll_device *lldev = container_of(hu, struct ll_device, hu);
+
+ if (!lldev->gnssdev)
+ return 0;
+
+ if (lldev->gnss_recv_func) {
+ lldev->gnss_recv_func(&lldev->gnssdev->dev, skb);
+ return 0;
+ }
+ kfree_skb(skb);
+
return 0;
}

+static int ll_gnss_register(struct ll_device *lldev)
+{
+ struct platform_device *pdev;
+ int ret;
+
+ pdev = platform_device_alloc("ti-ai2-gnss", PLATFORM_DEVID_AUTO);
+ if (!pdev)
+ return -ENOMEM;
+
+ pdev->dev.parent = &lldev->serdev->dev;
+ lldev->gnssdev = pdev;
+ ret = platform_device_add(pdev);
+ if (ret)
+ goto err;
+
+ return 0;
+
+err:
+ lldev->gnssdev = NULL;
+ platform_device_put(pdev);
+ return ret;
+}
+
static const struct hci_uart_proto llp;

static int hci_ti_probe(struct serdev_device *serdev)
@@ -757,12 +831,19 @@ static int hci_ti_probe(struct serdev_device *serdev)
}

return hci_uart_register_device(hu, &llp);
+
+
+ return 0;
}

+
static void hci_ti_remove(struct serdev_device *serdev)
{
struct ll_device *lldev = serdev_device_get_drvdata(serdev);

+ if (lldev->gnssdev)
+ platform_device_unregister(lldev->gnssdev);
+
hci_uart_unregister_device(&lldev->hu);
}

diff --git a/include/linux/ti_wilink_st.h b/include/linux/ti_wilink_st.h
index 10642d4844f0c..eccc2db004069 100644
--- a/include/linux/ti_wilink_st.h
+++ b/include/linux/ti_wilink_st.h
@@ -381,6 +381,14 @@ unsigned long st_ll_getstate(struct st_data_s *);
unsigned long st_ll_sleep_state(struct st_data_s *, unsigned char);
void st_ll_wakeup(struct st_data_s *);

+/**
+ * various funcs used to interact between FM, GPS and BT
+ */
+struct hci_dev *st_get_hci(struct device *dev);
+void st_set_gnss_recv_func(struct device *dev,
+ void (*recv_frame)(struct device *, struct sk_buff *));
+
+
/*
* header information used by st_core.c for FM and GPS
* packet parsing, the bluetooth headers are already available
--
2.39.2


2024-06-06 20:04:36

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: [PATCH v4 0/4] Bluetooth/gnss: GNSS support for TiWi chips

Hi Andreas,

On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <[email protected]> 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
>


--
Luiz Augusto von Dentz

2024-06-06 20:19:57

by Andreas Kemnade

[permalink] [raw]
Subject: Re: [PATCH v4 0/4] Bluetooth/gnss: GNSS support for TiWi chips

Hi Luiz,

On Thu, 6 Jun 2024 16:04:10 -0400
Luiz Augusto von Dentz <[email protected]> wrote:

> Hi Andreas,
>
> On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <[email protected]> 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

2024-06-08 19:21:24

by Andreas Kemnade

[permalink] [raw]
Subject: Re: [PATCH v4 0/4] Bluetooth/gnss: GNSS support for TiWi chips

Hi Adam,

On Sat, 8 Jun 2024 14:00:38 -0500
Adam Ford <[email protected]> wrote:

> On Thu, Jun 6, 2024 at 3:19 PM Andreas Kemnade <[email protected]> wrote:
> >
> > Hi Luiz,
> >
> > On Thu, 6 Jun 2024 16:04:10 -0400
> > Luiz Augusto von Dentz <[email protected]> wrote:
> >
> > > Hi Andreas,
> > >
> > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <[email protected]> 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

2024-06-10 23:17:49

by Adam Ford

[permalink] [raw]
Subject: Re: [PATCH v4 0/4] Bluetooth/gnss: GNSS support for TiWi chips

On Sat, Jun 8, 2024 at 2:20 PM Andreas Kemnade <[email protected]> wrote:
>
> Hi Adam,
>
> On Sat, 8 Jun 2024 14:00:38 -0500
> Adam Ford <[email protected]> wrote:
>
> > On Thu, Jun 6, 2024 at 3:19 PM Andreas Kemnade <[email protected]> wrote:
> > >
> > > Hi Luiz,
> > >
> > > On Thu, 6 Jun 2024 16:04:10 -0400
> > > Luiz Augusto von Dentz <[email protected]> wrote:
> > >
> > > > Hi Andreas,
> > > >
> > > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <[email protected]> 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

2024-06-11 08:34:10

by Andreas Kemnade

[permalink] [raw]
Subject: Re: [PATCH v4 0/4] Bluetooth/gnss: GNSS support for TiWi chips

Hi Adam,

On Mon, 10 Jun 2024 18:17:05 -0500
Adam Ford <[email protected]> wrote:

> On Sat, Jun 8, 2024 at 2:20 PM Andreas Kemnade <[email protected]> wrote:
> >
> > Hi Adam,
> >
> > On Sat, 8 Jun 2024 14:00:38 -0500
> > Adam Ford <[email protected]> wrote:
> >
> > > On Thu, Jun 6, 2024 at 3:19 PM Andreas Kemnade <[email protected]> wrote:
> > > >
> > > > Hi Luiz,
> > > >
> > > > On Thu, 6 Jun 2024 16:04:10 -0400
> > > > Luiz Augusto von Dentz <[email protected]> wrote:
> > > >
> > > > > Hi Andreas,
> > > > >
> > > > > On Thu, Jun 6, 2024 at 2:30 PM Andreas Kemnade <[email protected]> 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