gnss: add new GNSS subsystem

Add binding for u-blox GNSS receivers.

Note that the u-blox product names encodes form factor (e.g. "neo"), chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and chipset is used for the compatible strings (for now).

Signed-off-by Johan Hovold <[email protected]>

---
 .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt

Documentation/devicetree/bindings/gnss/u-blox.txt new file +0 -0

new file mode 100644
index 000000000000..caef9ace0b0c

Documentation/devicetree/bindings/gnss/u-blox.txt new file +10 -0

+
+			"u-blox,neo-8"
+			"u-blox,neo-m8"
+
+- vcc-supply	: Main voltage regulator
+
+Required properties (DDC):
+- reg		: DDC (I2C) slave address
+
+Required properties (SPI):

Documentation/devicetree/bindings/gnss/u-blox.txt new file +14 -0

+- v-bckp-supply	: Backup voltage regulator
+
+Example:
+
+serial@1234 {
+	compatible = "ns16550a";
+
+	gnss {
+		compatible = "u-blox,neo-8";
+
+		v-bckp-supply = <&gnss_v_bckp_reg>;
+		vcc-supply = <&gnss_vcc_reg>;
+	};
+};

Documentation/devicetree/bindings/vendor-prefixes.txt +1 -0

index b5f978a4cac6..2128dfdf73f1 100644
@@ -374,6 +374,7 @@ tronsmart	Tronsmart
 truly	Truly Semiconductors Limited
 tsd	Theobroma Systems Design und Consulting GmbH
 tyan	Tyan Computer Corporation
+u-blox	u-blox
 ucrobotics	uCRobotics
 ubnt	Ubiquiti Networks
 udoo	Udoo

Signature · 1 line

2.17.0

Quoted 23 lines · Johan Hovold

Add binding for u-blox GNSS receivers.

Note that the u-blox product names encodes form factor (e.g. "neo"), chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and chipset is used for the compatible strings (for now).

Signed-off-by Johan Hovold <[email protected]>

---
 .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt

Documentation/devicetree/bindings/gnss/u-blox.txt new file +4 -0

new file mode 100644
index 000000000000..caef9ace0b0c
@@ -0,0 +1,44 @@
+u-blox GNSS Receiver DT binding
+
+The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
+

Documentation/devicetree/bindings/gnss/u-blox.txt line 10

Quoted 6 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +6 -0

+Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
+properties.
+
+Required properties:
+
+- compatible 	: Must be one of

mixture of space and tab here.

Quoted 14 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +14 -0

+
+			"u-blox,neo-8"
+			"u-blox,neo-m8"
+
+- vcc-supply	: Main voltage regulator
+
+Required properties (DDC):
+- reg		: DDC (I2C) slave address
+
+Required properties (SPI):
+- reg		: SPI chip select address
+
+Required properties (USB):
+- reg		: Number of the USB hub port or the USB host-controller port

Documentation/devicetree/bindings/gnss/u-blox.txt line 30

Quoted 6 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +6 -0

+                  to which this device is attached
+
+Optional properties:
+
+- timepulse-gpios	: Time pulse GPIO
+- u-blox,extint-gpios	: External interrupt GPIO

This should be interrupts property instead of a gpio.

Quoted 24 lines · Rob Herring

Quoted 23 lines · Johan Hovold

Add binding for u-blox GNSS receivers.

Note that the u-blox product names encodes form factor (e.g. "neo"), chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and chipset is used for the compatible strings (for now).

Signed-off-by Johan Hovold <[email protected]>

---
 .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt

Documentation/devicetree/bindings/gnss/u-blox.txt new file +4 -0

new file mode 100644
index 000000000000..caef9ace0b0c
@@ -0,0 +1,44 @@
+u-blox GNSS Receiver DT binding
+
+The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
+

Quoted 8 lines

Documentation/devicetree/bindings/gnss/u-blox.txt line 10

Quoted 6 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +6 -0

+Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
+properties.
+
+Required properties:
+
+- compatible       : Must be one of

mixture of space and tab here.

Oops. Same single space character before the tab here in all three binding docs (and in the in-tree slave_devices.txt which I think I used as a template).

Do you want me to fix this even if this turns out to be the only thing that needs to be addressed in a v3?

Quoted 15 lines

Quoted 15 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +14 -0

+
+                   "u-blox,neo-8"
+                   "u-blox,neo-m8"
+
+- vcc-supply       : Main voltage regulator
+
+Required properties (DDC):
+- reg              : DDC (I2C) slave address
+
+Required properties (SPI):
+- reg              : SPI chip select address
+
+Required properties (USB):
+- reg              : Number of the USB hub port or the USB host-controller port

Quoted 8 lines

Documentation/devicetree/bindings/gnss/u-blox.txt line 30

Quoted 6 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +6 -0

+                  to which this device is attached
+
+Optional properties:
+
+- timepulse-gpios  : Time pulse GPIO
+- u-blox,extint-gpios      : External interrupt GPIO

This should be interrupts property instead of a gpio.

Contrary to what the name may suggest, this pin is actually an input which can be used to control active power or to provide time or frequency aiding data to the receiver (see section 1.13 in [1]).

I only added it for completeness as the driver does not use it currently. Remove, leave as is, or add "input" to the description as in:

- u-blox,extint-gpios : External interrupt input GPIO

Quoted 34 lines · Johan Hovold

Quoted 32 lines · Rob Herring

Quoted 19 lines · Johan Hovold

Add binding for u-blox GNSS receivers.

Note that the u-blox product names encodes form factor (e.g. "neo"), chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and chipset is used for the compatible strings (for now).

Signed-off-by Johan Hovold <[email protected]>

---
 .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt

Documentation/devicetree/bindings/gnss/u-blox.txt new file +0 -0

new file mode 100644
index 000000000000..caef9ace0b0c

Documentation/devicetree/bindings/gnss/u-blox.txt line 10

Quoted 10 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +10 -0

@@ -0,0 +1,44 @@
+u-blox GNSS Receiver DT binding
+
+The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
+
+Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
+properties.
+
+Required properties:
+
+- compatible       : Must be one of

mixture of space and tab here.

Quoted 3 lines

Oops. Same single space character before the tab here in all three binding docs (and in the in-tree slave_devices.txt which I think I used as a template).

Who wrote that crap? ;)

Quoted 28 lines

Quoted 15 lines

Quoted 15 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +14 -0

+
+                   "u-blox,neo-8"
+                   "u-blox,neo-m8"
+
+- vcc-supply       : Main voltage regulator
+
+Required properties (DDC):
+- reg              : DDC (I2C) slave address
+
+Required properties (SPI):
+- reg              : SPI chip select address
+
+Required properties (USB):
+- reg              : Number of the USB hub port or the USB host-controller port

Quoted 8 lines

Documentation/devicetree/bindings/gnss/u-blox.txt line 30

Quoted 6 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +6 -0

+                  to which this device is attached
+
+Optional properties:
+
+- timepulse-gpios  : Time pulse GPIO
+- u-blox,extint-gpios      : External interrupt GPIO

This should be interrupts property instead of a gpio.

Contrary to what the name may suggest, this pin is actually an input which can be used to control active power or to provide time or frequency aiding data to the receiver (see section 1.13 in [1]).

Quoted 4 lines

I only added it for completeness as the driver does not use it currently. Remove, leave as is, or add "input" to the description as in:

- u-blox,extint-gpios : External interrupt input GPIO

Yes. You should also define the active level.

Quoted 35 lines · Rob Herring

Quoted 34 lines · Johan Hovold

Quoted 32 lines · Rob Herring

Quoted 19 lines · Johan Hovold

Add binding for u-blox GNSS receivers.

Note that the u-blox product names encodes form factor (e.g. "neo"), chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and chipset is used for the compatible strings (for now).

Signed-off-by Johan Hovold <[email protected]>

---
 .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt   |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt

Documentation/devicetree/bindings/gnss/u-blox.txt new file +0 -0

new file mode 100644
index 000000000000..caef9ace0b0c

Documentation/devicetree/bindings/gnss/u-blox.txt line 10

Quoted 10 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +10 -0

@@ -0,0 +1,44 @@
+u-blox GNSS Receiver DT binding
+
+The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
+
+Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
+properties.
+
+Required properties:
+
+- compatible       : Must be one of

mixture of space and tab here.

Quoted 5 lines

Quoted 3 lines

Oops. Same single space character before the tab here in all three binding docs (and in the in-tree slave_devices.txt which I think I used as a template).

Who wrote that crap? ;)

Heh.

Quoted 33 lines

Quoted 32 lines

Quoted 15 lines

Quoted 15 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +14 -0

+
+                   "u-blox,neo-8"
+                   "u-blox,neo-m8"
+
+- vcc-supply       : Main voltage regulator
+
+Required properties (DDC):
+- reg              : DDC (I2C) slave address
+
+Required properties (SPI):
+- reg              : SPI chip select address
+
+Required properties (USB):
+- reg              : Number of the USB hub port or the USB host-controller port

Quoted 8 lines

Documentation/devicetree/bindings/gnss/u-blox.txt line 30

Quoted 6 lines

Documentation/devicetree/bindings/gnss/u-blox.txt new file +6 -0

+                  to which this device is attached
+
+Optional properties:
+
+- timepulse-gpios  : Time pulse GPIO
+- u-blox,extint-gpios      : External interrupt GPIO

This should be interrupts property instead of a gpio.

Contrary to what the name may suggest, this pin is actually an input which can be used to control active power or to provide time or frequency aiding data to the receiver (see section 1.13 in [1]).

I only added it for completeness as the driver does not use it currently. Remove, leave as is, or add "input" to the description as in:

- u-blox,extint-gpios : External interrupt input GPIO

Quoted 1 line

Yes. You should also define the active level.

The active level appears to be runtime configurable and dependent on the selected function. For power control it can be used to control force-on (active high), force-off (active low) or both; and for time aiding sampling on falling or rising edge is also configurable. And who knows what else this pin is used for next time they update the firmware. ;)

Shall I remove the property, or just add "input" as suggested above?

Quoted 22 lines · Johan Hovold

Quoted 21 lines · Rob Herring

Quoted 19 lines · Johan Hovold

Quoted 9 lines · Rob Herring

Documentation/devicetree/bindings/gnss/u-blox.txt line 30

Quoted 6 lines · Johan Hovold

Add binding for u-blox GNSS receivers.

Documentation/devicetree/bindings/gnss/u-blox.txt new file +4 -0

+Optional properties:
+
+- timepulse-gpios  : Time pulse GPIO
+- u-blox,extint-gpios      : External interrupt GPIO

This should be interrupts property instead of a gpio.

Contrary to what the name may suggest, this pin is actually an input which can be used to control active power or to provide time or frequency aiding data to the receiver (see section 1.13 in [1]).

I only added it for completeness as the driver does not use it currently. Remove, leave as is, or add "input" to the description as in:

- u-blox,extint-gpios : External interrupt input GPIO

Quoted 7 lines

Quoted 1 line

Yes. You should also define the active level.

The active level appears to be runtime configurable and dependent on the selected function. For power control it can be used to control force-on (active high), force-off (active low) or both; and for time aiding sampling on falling or rising edge is also configurable. And who knows what else this pin is used for next time they update the firmware. ;)

Okay.

Quoted 1 line

Shall I remove the property, or just add "input" as suggested above?

Just add "input".

Another possible extension is to add generic 1PPS support.

Quoted 1 line · Johan Hovold

Another possible extension is to add generic 1PPS support.

There are two possibilities to consider.

1. If the PPS causes an interrupt, then it should hook into the PPS subsystem.

2. If the PPS is a HW signal routed for example to the input pin of a MAC based PTP Hardware Clock (PHC), then it would make sense to model the GNSS device as a PHC as well. This PHC would be readable but not writable, and more importantly it would offer an output signal. Then user space could use the existing interfaces to dial the PPS signal from one device the another.

(Come to think of it, modeling the GNSS as PHC would also give you the interface for #1 as well.)

Am 31.05.2018 um 10:52 schrieb Johan Hovold <[email protected]>:

Quoted 1 line · Richard Cochran

On Wed, May 30, 2018 at 12:32:34PM +0200, Johan Hovold wrote:

Quoted 6 lines

Quoted 1 line

Another possible extension is to add generic 1PPS support.

There are two possibilities to consider.

1. If the PPS causes an interrupt, then it should hook into the PPS subsystem.

Registering a PPS child device is what I had in mind for this.

Quoted 5 lines

Am 31.05.2018 um 10:52 schrieb Johan Hovold <[email protected]>:

Quoted 1 line · Richard Cochran

On Wed, May 30, 2018 at 12:32:34PM +0200, Johan Hovold wrote:

Quoted 8 lines

Quoted 6 lines

Quoted 1 line

Another possible extension is to add generic 1PPS support.

There are two possibilities to consider.

1. If the PPS causes an interrupt, then it should hook into the PPS subsystem.

Registering a PPS child device is what I had in mind for this.

This seems to be duplicating functionality that is already solved by

https://elixir.bootlin.com/linux/v4.17-rc7/source/Documentation/devicetree/bindings/pps/pps-gpio.txt

and

https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/pps/clients/pps-gpio.c

Or what is bad with just using that?

Am 31.05.2018 um 13:47 schrieb Johan Hovold <[email protected]>:

Quoted 20 lines · H. Nikolaus Schaller

Quoted 5 lines

Am 31.05.2018 um 10:52 schrieb Johan Hovold <[email protected]>:

Quoted 1 line · Richard Cochran

On Wed, May 30, 2018 at 12:32:34PM +0200, Johan Hovold wrote:

Quoted 8 lines

Quoted 6 lines

Quoted 1 line

Another possible extension is to add generic 1PPS support.

There are two possibilities to consider.

1. If the PPS causes an interrupt, then it should hook into the PPS subsystem.

Registering a PPS child device is what I had in mind for this.

This seems to be duplicating functionality that is already solved by

https://elixir.bootlin.com/linux/v4.17-rc7/source/Documentation/devicetree/bindings/pps/pps-gpio.txt

and

Quoted 3 lines

https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/pps/clients/pps-gpio.c

Or what is bad with just using that?

Using pps-gpio would not allow you to describe the hardware properly, something which, for example, may be needed for power management (e.g. to power on the GNSS receiver when the pps device is being accessed).

Quoted 5 lines

Am 31.05.2018 um 13:47 schrieb Johan Hovold <[email protected]>:

Using pps-gpio would not allow you to describe the hardware properly, something which, for example, may be needed for power management (e.g. to power on the GNSS receiver when the pps device is being accessed).

Yes, that is indeed a very valid reason to do it that way as the pps-gpio seems to assume an always-on impulse source.

On the other hand it looks as if the pps framework can't tell the source when to power on/off because it does not notify when it is being accessed or not:

https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/pps/pps.c#L305