[Gta04-owner] power control of devices connected to UART

Dr. H. Nikolaus Schaller hns at goldelico.com
Fri Nov 21 08:43:32 CET 2014

Am 19.11.2014 um 23:20 schrieb NeilBrown <neilb at suse.de>:

> On Wed, 19 Nov 2014 11:16:20 +0100 "Dr. H. Nikolaus Schaller"
> <hns at goldelico.com> wrote:
>> Hi Neil,
>> I just had an idea and would like to know your opinion before we go to LKML with a solution:
>> regulators are wide spread in use and “connect” different drivers.
>> What about adding an optional regulator node “interface-supply” that an uart driver can
>> control when the tty is opened/closed? Similar to “vmmc-supply”.
>> More or less the same thing as we do with the DTR gpio, but a regulator. And triggered
>> through open()/close() instead of DTR state.
>> Then, the w2sg (or the w2cbw) drivers present themselves as “regulators” and in fact it is their
>> only purpose to control the power of these chips. We simply model the LDO that is inside these
>> chips.
> As you say this is much like my "virtual GPIO" approach and I think it would
> be rejected for much the same reason.
> If it isn't a real "supply", then it shouldn't be listed in devicetree as a
> supply.
> You could probably make a case for interface-supply to turn on a regulator.
> I don't think you would win a case for w2sg etc to present itself as a
> regulator.
> My current solution:
> http://git.neil.brown.name/?p=gta04.git;a=commitdiff;h=7fff6334bc57e71113f4952548ba8697a6e3d01f
> allows an arbitrary platform device to be a child of a uart, and runtime
> power management is used to make sure it is on when the tty is open, and
> to allow it to turn off when the tty is closed.
> There are a few little details I want to revise, but I think it is likely to
> find acceptance.
>> Form an uart perspective we would replace:
>> &uart2 { /* GPS /dev/ttyO1 */
>> 	dtr-gpio = <&gps_en 0 GPIO_ACTIVE_HIGH>;	/* w2sg0004 GPS power control through virtual gpio */
>> };
>> with
>> &uart2 { /* GPS /dev/ttyO1 */
>> 	interface-supply = <&gps_regulator>;	/* w2sg0004 GPS power regulator control */
>> };
>> And, the interface-supply could also have a very reasonable use case for different boards. Usually there
>> is aRS232 level shifter connected to the UART pins of the SoC. And that one can also be powered up/down
>> by some interface-supply regulator.
>> For UART3 this could control the “powerdown” mode of the TRS3386 by a standard gpio-regulator.
>> Finally, I think we can’t drop the dtr-gpio.
>> If you look at page 15, there is GPIO21 which also goes through the TRS3386 to the RS232 connector.
>> It is usually connected to the DTR line of this interface.
>> To control it we need (GTA04 only):
>> &uart3 {
>> 	dtr-gpio = <&gpio1 21 GPIO_ACTIVE_HIGH>;	/* DTR line on external RS232 interface */
>> };
>> And we need the DTR driver patch - independently of the GPS control. So it wasn’t good to drop it
>> from mainline before discussing in detail.
> The code can always be added back if there is a demonstrated need.  However I
> suspect it would be more acceptable if the code were generic and not specific
> to the omap3 uar

There is also one more significant change appearing at the horizon:


will replace the older omap-serial.c driver. So patches to omap-serial will likely be rejected

This probably will also influence the device trees and perhaps even user space: /dev/ttyO*
will become /dev/ttyS* (this is a speculation that needs verification).

> i.e.  something needs to go in drivers/tty/serial/serial_core.c - probably
> near the calls to ->set_mctrl.
> It is a little awkward that that function is always called under a spinlock,
> while generic gpios need to be allowed to sleep.  At worst, that can be
> solved with a work-queue.

There is some serial code here:


Documentation/serial/driver says

> Modem control lines via GPIO
> ----------------------------
> Some helpers are provided in order to set/get modem control lines via GPIO.
> mctrl_gpio_init(dev, idx):
> 	This will get the {cts,rts,...}-gpios from device tree if they are
> 	present and request them, set direction etc

So this looks as what we need (except that I have not yet found a bindings documentation).
It might not work with the current omap-serial driver but should with the new 8250_omap.


More information about the Gta04-owner mailing list