[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <8F1B0629-A5FD-4794-9A50-BA6D18C0C34C@goldelico.com>
Date: Wed, 7 Jun 2017 12:08:17 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Ladislav Michl <ladis@...ux-mips.org>
Cc: Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
BenoƮt Cousson <bcousson@...libre.com>,
Tony Lindgren <tony@...mide.com>,
Russell King <linux@...linux.org.uk>,
Thierry Reding <treding@...dia.com>,
Jonathan Cameron <jic23@...nel.org>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-omap@...r.kernel.org, letux-kernel@...nphoenux.org,
kernel@...a-handheld.com
Subject: Re: [RFC 2/3] misc: Add w2sg0004 (gps receiver) power control driver
Hi Ladislav,
> Am 07.06.2017 um 09:34 schrieb Ladislav Michl <ladis@...ux-mips.org>:
>
> Dear Nikolaus,
>
> On Sun, May 21, 2017 at 12:44:03PM +0200, H. Nikolaus Schaller wrote:
>> Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart.
>>
>> Use serdev API hooks to monitor and forward the UART traffic to /dev/BTn
>> and turn on/off the module. It also detects if the module is turned on (sends data)
>> but should be off, e.g. if it was already turned on during boot or power-on-reset.
>>
>> Additionally, rfkill block/unblock can be used to control an external LNA
>> (and power down the module if not needed).
>>
>> The driver concept is based on code developed by NeilBrown <neilb@...e.de>
>> but simplified and adapted to use the new serdev API introduced in 4.11.
> [snip]
>> diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> new file mode 100644
>> index 000000000000..b7125c7a598c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> @@ -0,0 +1,20 @@
>> +Wi2Wi GPS module connected through UART
>> +
>> +Should be a subnode of the SoC UART it is connected to (serdev).
>> +
>> +Required properties:
>> +- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
>> +- on-off-gpio: the GPIO that controls the module's on-off toggle input
>> +
>> +Optional properties:
>> +- lna-suppy: an (optional) LNA regulator that is enabled together with the GPS receiver
>> +
>> +Example:
>> +
>> +&uart2 {
>> + gps: w2sg0004 {
>> + compatible = "wi2wi,w2sg0004";
>> + lna-supply = <&vsim>; /* LNA regulator */
>> + on-off-gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>; /* GPIO_145: trigger for turning on/off w2sg0004 */
>> + };
>> +};
>
> Here it seems is nothing specific to GPS receiver in this driver
Well, most serdev subnodes will look similar to this but still will
need different drivers (timing, pulses, other logic, special functions,
firmware download etc.).
> and
> basically UART connected GSM modules could benefit from such functionality
> too - as they need power supply, had reset and ignition pin and often
> status pin. See for example:
> http://simcom.ee/documents/SIM5300E/SIM5300E_Hardware_Design_V1.08.pdf
> page 14 or
> http://www.robotshop.com/media/files/pdf/datasheet-gsm-tc35.pdf
> page 19 for block diagrams.
> So I wonder if you would accept making this driver a bit more generic
> to cover also GSM modems use case.
We also have such a 2G/3G/4G module in the GTA04 and Pyra devices but there
we have significantly different power control needs because they are connected
through USB and not as UART / serdev.
But you could simply try to use and extend our proposed w2cbw003 bluetooth
driver [RFC 3/3] for that purpose.
It already has most of what you need: provides a user-space /dev/tty for the
serdev and controls some power-control gpio or regulator.
This w2sg0004 gps chip is very specific for this chip since it has no simple
power-enable to be controlled. This also differs too much from GSM modules
with ignition. Especially it has no status feedback.
Another aspect is that there are plans to have some gps infrastructure in the
kernel. Then, this driver wouldn't be the right solution for gsm.
Therefore it is and should remain a special purpose driver for this type of
gps chips.
The common denominator of all these things is the serdev and gpio infrastructure.
Feel free to take both drivers as blueprints to propose some new driver
for your chips.
BR,
Nikolaus
Powered by blists - more mailing lists