[lkml]   [2018]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/7] gnss: add new GNSS subsystem
Hi Johan,

>>> This series adds a new subsystem for GNSS receivers (e.g. GPS
>>> receivers).
>>> While GNSS receivers are typically accessed using a UART interface they
>>> often also support other I/O interfaces such as I2C, SPI and USB, while
>>> yet other devices use iomem or even some form of remote-processor
>>> messaging (rpmsg).
>>> The new GNSS subsystem abstracts the underlying interface and provides a
>>> new "gnss" class type, which exposes a character-device interface (e.g.
>>> /dev/gnss0) to user space. This allows GNSS receivers to have a
>>> representation in the Linux device model, something which is important
>>> not least for power management purposes and which also allows for easy
>>> detection and (eventually) identification of GNSS devices.
>>> Note that the character-device interface provides raw access to whatever
>>> protocol the receiver is (currently) using, such as NMEA 0183, UBX or
>>> SiRF Binary. These protocols are expected to be continued to be handled
>>> by user space for the time being, even if some hybrid solutions are also
>>> conceivable (e.g. to have kernel drivers issue management commands).
>> Great work. I like your design decisions. I have quite a few devices
>> with have non-serial based GPS peripherals using binary protocols (*).
>> As far as I can see it should be possible to add support for those.
> Thanks! Yeah, the aim here was to abstract the actual I/O interface
> used.
>> I have one concern, though. While providing raw data by
>> default is fine generally, it is a problem with device
>> auto-discovery. I think there should be some IOCTL from
>> the start, that can be used to inform userspace about
>> the raw protocol being used (i.e. "NMEA"). I fear, that
>> userspace may start to just assume raw = NMEA without
>> having this (especially since all initial drivers provide
>> NMEA).
> One problem I see here would be that the driver does not necessarily
> know either what protocol is currently being used. Some devices have
> boot-pins which can be used to configure the initial protocol used (and
> this could perhaps be reflected in DT), but this can often later be
> changed (by user space) and even be made persistent using battery-backed
> ram or eeproms.
> Also note that at least u-blox devices supports having more than one
> protocol active on the same port...

as long as userspace can determine that it is GNSS hardware and what hardware it is, then you deal with the rest in userspace.



 \ /
  Last update: 2018-05-07 21:07    [W:0.098 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site