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

Dr. H. Nikolaus Schaller hns at goldelico.com
Thu Nov 20 07:21:20 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.

It *is* a regulator (driver)…

> 
> 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.

This is why I only want to present a w2sg-regulator 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.

It could also control a regulator child, couldn’t it?

> 
> 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 uart.

> 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.

Yes, that could be the best way.

BR,
Nikolaus



More information about the Gta04-owner mailing list