[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231127135424.GO5169@atomide.com>
Date: Mon, 27 Nov 2023 15:54:24 +0200
From: Tony Lindgren <tony@...mide.com>
To: Andreas Kemnade <andreas@...nade.info>
Cc: marcel@...tmann.org, johan.hedberg@...il.com, luiz.dentz@...il.com,
johan@...nel.org, arnd@...db.de, gregkh@...uxfoundation.org,
linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
tomi.valkeinen@...asonboard.com,
Péter Ujfalusi <peter.ujfalusi@...il.com>,
robh@...nel.org
Subject: Re: [RFC PATCH 0/3] bluetooth/gnss: GNSS support for TiWi chips
* Andreas Kemnade <andreas@...nade.info> [231126 19:18]:
> So the main questions I see:
> - is the approach right to abandon drivers/misc/ti-st?
Yes.
> - 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.
I'd go with NMEA format as the default setting :)
> 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.
Seems AI2 could be optionally enabled as needed with some writes
to /dev/gnss0 to change the mode?
Regards,
Tony
Powered by blists - more mailing lists