aboutsummaryrefslogtreecommitdiff
path: root/drivers/gnss/Makefile
AgeCommit message (Collapse)Author
2019-02-15gnss: add driver for mediatek receiversLoys Ollivier
Add driver for serial-connected Mediatek-based GNSS receivers. These devices typically boot transmitting vendor specific NMEA output sequences. The serial port bit rate is read from the device tree "current-speed". Note that the driver uses the generic GNSS serial implementation and therefore essentially only manages power abstracted into three power states: ACTIVE, STANDBY, and OFF. For mediatek receivers with a main supply and no enable-gpios, this simply means that the main supply is disabled in STANDBY and OFF (the optional backup supply is kept enabled while the driver is bound). Note that the timepulse-support is left unimplemented. Signed-off-by: Loys Ollivier <lollivier@baylibre.com> [ johan: rename backup supply ] Signed-off-by: Johan Hovold <johan@kernel.org>
2018-06-28gnss: add driver for sirfstar-based receiversJohan Hovold
Add driver for serial-connected SiRFstar-based GNSS receivers. These devices typically boot into hibernate mode from which they can be woken using a pulse on the ON_OFF input pin. Once active, a pulse on the same ON_OFF pin is used to put the device back into hibernate mode. The current state can be determined by sampling the WAKEUP output. Hardware configurations where WAKEUP has been connected to ON_OFF (and where an initial WAKEUP pulse during boot is sufficient to have the device boot into active mode) are also supported. In this case, device power is managed using the main-supply regulator only. Note that configurations where WAKEUP is left not connected, so that the device power state can only indirectly be determined using the I/O interface, is currently not supported. It should be fairly straight-forward to extend the current implementation with such support however (and this this is the main reason for not using the generic serial implementation for this driver). Note that timepulse-support is left unimplemented. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-28gnss: add driver for u-blox receiversJohan Hovold
Add driver for serial-connected u-blox GNSS receivers. Note that the driver uses the generic GNSS serial implementation and therefore essentially only manages power abstracted into three power states: ACTIVE, STANDBY, and OFF. For u-blox receivers with a main supply and no enable-gpios, this simply means that the main supply is disabled in STANDBY and OFF (the optional backup supply is kept enabled while the driver is bound). Note that timepulse-support is not yet implemented. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-28gnss: add generic serial driverJohan Hovold
Add a generic serial GNSS driver (library) which provides a common implementation for the gnss interface and power management (runtime and system suspend). This allows GNSS drivers for specific chip to be implemented by simply providing a set_power() callback to handle three states: ACTIVE, STANDBY and OFF. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-28gnss: add GNSS receiver subsystemJohan Hovold
Add a new subsystem for GNSS (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. 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). Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>