Hi Johan, On Tue, Apr 24, 2018 at 06:34:51PM +0200, Johan Hovold wrote: > 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). > > This will still allow for better platform integration by allowing GNSS > devices and their resources (e.g. regulators and enable-gpios) to be > described by firmware and managed by kernel drivers rather than > platform-specific scripts and services. > > While the current interface is kept minimal, it could be extended using > IOCTLs, sysfs or uevents as needs and proper abstraction levels are > identified and determined (e.g. for device and feature identification). > > Another possible extension is to add generic 1PPS support. > > I decided to go with a custom character-device interface rather than > pretend that these abstract GNSS devices are still TTY devices (e.g. > /dev/ttyGNSS0). Obviously, modifying line settings or reading modem > control signals does not make any sense for a device using, say, a > USB (not USB-serial) or iomem interface. This also means, however, that > user space would no longer be able to set the line speed to match a new > port configuration that can be set using the various GNSS protocols when > the underlying interface is indeed a UART; instead this would need to be > taken care of by the driver. > > Also note that writes are always synchronous instead of requiring user > space to call tcdrain() after every command. > > This all seems to work well-enough (e.g. with gpsd), but please let me > know if I've overlooked something which would indeed require a TTY > interface instead. > > As proof-of-concept I have implemented drivers for receivers based on > two common GNSS chipsets (SiRFstar and u-blox), but due to lack of > hardware these have so far only been tested using mockup devices and a > USB-serial-based GPS device (using out-of-tree code). [ Let me know if > you've got any evalutation kits to spare. ] > > Finally, note that documentation (including kerneldoc) remains to be > written, but hopefully this will not hinder review given that the > current interfaces are fairly self-describing. 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. 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). (*) I have those in mind: Nokia N900: The phone has GPS integrated into the modem and uses ISI encapsulated data. The protocol has been reverse engineered and it should be possible to write a kernel driver for handling the GPS packets and dumping the raw data to /dev/gnss0. I don't think this is particularly useful without a non-raw interface, though. It would still require a custom userspace implementation. Nokia N950/N9: Those phones have an I2C connected BCM4751, which uses (proprietary, non-reverse-engineered) MEIF binary protocol. Nokia's kernel had a driver, which provides a similar userspace interface (char device with raw data from chip). Droid 4: GPS is similar to N900, but different protocol and QMI encapsulated. This one also has known protocol with userspace implementation. I did not yet have a detailed look, if its possible to (un)wrap this in the kernel. -- Sebastian
Attachment:
signature.asc
Description: PGP signature
