Question: How to power-manage UART-attached devices.

Question: How to power-manage UART-attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]


Greetings.
 I have a conundrum that I am hoping someone could help me with.

 I have a mobile device (Openmoko successor: GTA04) which has two devices
 that are attached by UARTs - bluetooth and GPS.

 Each of these can usefully be power-managed:  The bluetooth shares a
 regulator with WIFI and if both are inactive the regulator can be turned off.
 GPS has a powered antenna which and be powered down when inactive, and also
 has an 'on/off' pin which, when pulsed, toggles the GPS between 'on' and
 'off.

 The question is how can user-space tell the kernel that these devices are
 'inactive'?

 I would like to integrate this into Linux in the most  "natural" way that I
 can but am having trouble.  My current approach involves using "rfkill" but
 that doesn't work very well for reasons that are probably not very relevant
 here.  It probably does make sense for powering the GPS antenna, but not
 much else.

 What I would really like is to integrate it closely with the state of the
 UART.  i.e. if the /dev/ttyO1 device is open, then the GPS is "on".  If not
 then it is "off".  Similarly if /dev/tty/O0 is open, bluetooth is "on", else
 "off".
 However I cannot find any way to "plug in" to the tty or serial drivers to
 perform an arbitrary action on first-open or last-close.  Is something like
 that possible? 
 If not, is it a reasonable thing to ask? 
 Any suggests about where to put such a hook?


 It would be particularly useful if the hooked-in code could also find out
 about received characters when the device is thought to be "off".  This is
 because the only way to find out if the GPS is "on" is to see if it is
 sending data, so to turn it off you check if it is sending data and if it
 does, toggle the 'on/off' line.   I could manage this a different way by
 reprogramming the RX pin on the OMAP3 to be a GPIO and then taking a falling
 interrupt as an indication that the device is 'on', but I would rather
 something more integrated.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Question: How to power-manage UART-attached devices.

[Mark Brown]

On Tue, May 01, 2012 at 08:22:09AM +1000, NeilBrown wrote:

>  The question is how can user-space tell the kernel that these devices are
>  'inactive'?

>  I would like to integrate this into Linux in the most  "natural" way that I
>  can but am having trouble.  My current approach involves using "rfkill" but
>  that doesn't work very well for reasons that are probably not very relevant
>  here.  It probably does make sense for powering the GPS antenna, but not
>  much else.

The userspace consumer was added for users like this that live entirely
in userspace.

Re: Question: How to power-manage UART-attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

On Mon, 30 Apr 2012 23:33:22 +0100 Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:

> On Tue, May 01, 2012 at 08:22:09AM +1000, NeilBrown wrote:
> 
> >  The question is how can user-space tell the kernel that these devices are
> >  'inactive'?
> 
> >  I would like to integrate this into Linux in the most  "natural" way that I
> >  can but am having trouble.  My current approach involves using "rfkill" but
> >  that doesn't work very well for reasons that are probably not very relevant
> >  here.  It probably does make sense for powering the GPS antenna, but not
> >  much else.
> 
> The userspace consumer was added for users like this that live entirely
> in userspace.

Hi Mark,
 thanks for the reply.

 I assume you mean REGULATOR_VIRTUAL_CONSUMER (drivers/regulator/virtual.c)?

 The one where the Kconfig entry says:
    This is mainly useful for test purposes.

 That certainly was useful for test purposes but I want to move beyond
 testing.

 One of the purposes of an operating system is to provide useful abstractions
 and hide irrelevant details, so I don't want user-space to have to
 explicitly enable a regulator.
 I could cope with an 'on/off switch' abstraction.  It might then enable a
 regulator. In the case of the GPS device it would need to both enable a
 regulator and toggle a GPIO line.  I really don't want user-space to "know"
 that it has to turn on a regulator and toggle a gpio line...

 So I'm still hoping for something more abstract.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Question: How to power-manage UART-attached devices.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

On Tue, May 01, 2012 at 09:35:59AM +1000, NeilBrown wrote:
> On Mon, 30 Apr 2012 23:33:22 +0100 Mark Brown
> > On Tue, May 01, 2012 at 08:22:09AM +1000, NeilBrown wrote:

> > The userspace consumer was added for users like this that live entirely
> > in userspace.

>  I assume you mean REGULATOR_VIRTUAL_CONSUMER (drivers/regulator/virtual.c)?

No, that's just for testing drivers in development.  I mean the
userspace consumer which is hidden away in userspace-consumer.c.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Question: How to power-manage UART-attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Tue, 1 May 2012 17:33:03 +0100 Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:

> On Tue, May 01, 2012 at 09:35:59AM +1000, NeilBrown wrote:
> > On Mon, 30 Apr 2012 23:33:22 +0100 Mark Brown
> > > On Tue, May 01, 2012 at 08:22:09AM +1000, NeilBrown wrote:
> 
> > > The userspace consumer was added for users like this that live entirely
> > > in userspace.
> 
> >  I assume you mean REGULATOR_VIRTUAL_CONSUMER (drivers/regulator/virtual.c)?
> 
> No, that's just for testing drivers in development.  I mean the
> userspace consumer which is hidden away in userspace-consumer.c.

Ahhh, of course.  What a cunning hiding place! :-)

However it doesn't suit my need - I want something more abstracted.

I can see there may well be a place for a simple on/off switch for some
components, but then I would prefer to see it as

   /sys/class/power-switch/$devicename/state

rather than

  /sys/devices/platform/reg-userspace-consumer.X/{name,state}


Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Question: How to power-manage UART-attached devices.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Wed, May 02, 2012 at 09:15:16AM +1000, NeilBrown wrote:

> However it doesn't suit my need - I want something more abstracted.

> I can see there may well be a place for a simple on/off switch for some
> components, but then I would prefer to see it as

>    /sys/class/power-switch/$devicename/state

> rather than

>   /sys/devices/platform/reg-userspace-consumer.X/{name,state}

That's a simple matter of programming if someone wants to do it, can't
say it seems worth the effort personally though especially when classes
are supposed to be going away.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Question: How to power-manage UART-attached devices.

[H. Peter Anvin]

On 04/30/2012 03:22 PM, NeilBrown wrote:
> 
> What I would really like is to integrate it closely with the state
> of the UART.  i.e. if the /dev/ttyO1 device is open, then the GPS
> is "on".  If not then it is "off".  Similarly if /dev/tty/O0 is
> open, bluetooth is "on", else "off". However I cannot find any way
> to "plug in" to the tty or serial drivers to perform an arbitrary
> action on first-open or last-close.  Is something like that
> possible? If not, is it a reasonable thing to ask? Any suggests
> about where to put such a hook?
> 

I don't think that's the right interface.  Just because the port is
currently open doesn't mean the device is active, nor vice versa.  ALL
it means is that someone currently has an access handle to it.

Since a serial port models, well, a *port*, it is logical to think of
a (hypothetical) socket containing an RS-232 connector as well as a
power outlet.  Given that, it would be logical to drive the "power
connector" using the same type of interface used for the other parts
of an RS-232 control, meaning either with termios flags or via a
dedicated control ioctl (TIOCPOWER?).

	-hpa

Re: Question: How to power-manage UART-attached devices.

[Alan Cox]

On Mon, 30 Apr 2012 15:51:59 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On 04/30/2012 03:22 PM, NeilBrown wrote:
> > 
> > What I would really like is to integrate it closely with the state
> > of the UART.  i.e. if the /dev/ttyO1 device is open, then the GPS
> > is "on".  If not then it is "off".  Similarly if /dev/tty/O0 is
> > open, bluetooth is "on", else "off". However I cannot find any way
> > to "plug in" to the tty or serial drivers to perform an arbitrary
> > action on first-open or last-close.  Is something like that
> > possible? If not, is it a reasonable thing to ask? Any suggests
> > about where to put such a hook?
> > 
> 
> I don't think that's the right interface.  Just because the port is
> currently open doesn't mean the device is active, nor vice versa.  ALL
> it means is that someone currently has an access handle to it.
> 
> Since a serial port models, well, a *port*, it is logical to think of
> a (hypothetical) socket containing an RS-232 connector as well as a
> power outlet.  Given that, it would be logical to drive the "power
> connector" using the same type of interface used for the other parts
> of an RS-232 control, meaning either with termios flags or via a
> dedicated control ioctl (TIOCPOWER?).

Actually several of our virtual tty interfaces treat open as meaning
powered up. It's a fairly logical power management model. A lot of our
real tty ports do the same as well and kill power on the last close.

At the tty layer the tty_port helper callbacks port->activate() and
port->shutdown() provide the needed functionality.

You don't however want to be "hooking" this - your platform needs to
provide its own versions of the relevant operations in the OMAP serial
driver.

Alan

Re: Question: How to power-manage UART-attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2868 bytes --]

On Tue, 1 May 2012 00:34:20 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Mon, 30 Apr 2012 15:51:59 -0700
> "H. Peter Anvin" <hpa@zytor.com> wrote:
> 
> > On 04/30/2012 03:22 PM, NeilBrown wrote:
> > > 
> > > What I would really like is to integrate it closely with the state
> > > of the UART.  i.e. if the /dev/ttyO1 device is open, then the GPS
> > > is "on".  If not then it is "off".  Similarly if /dev/tty/O0 is
> > > open, bluetooth is "on", else "off". However I cannot find any way
> > > to "plug in" to the tty or serial drivers to perform an arbitrary
> > > action on first-open or last-close.  Is something like that
> > > possible? If not, is it a reasonable thing to ask? Any suggests
> > > about where to put such a hook?
> > > 
> > 
> > I don't think that's the right interface.  Just because the port is
> > currently open doesn't mean the device is active, nor vice versa.  ALL
> > it means is that someone currently has an access handle to it.
> > 
> > Since a serial port models, well, a *port*, it is logical to think of
> > a (hypothetical) socket containing an RS-232 connector as well as a
> > power outlet.  Given that, it would be logical to drive the "power
> > connector" using the same type of interface used for the other parts
> > of an RS-232 control, meaning either with termios flags or via a
> > dedicated control ioctl (TIOCPOWER?).
> 
> Actually several of our virtual tty interfaces treat open as meaning
> powered up. It's a fairly logical power management model. A lot of our
> real tty ports do the same as well and kill power on the last close.
> 
> At the tty layer the tty_port helper callbacks port->activate() and
> port->shutdown() provide the needed functionality.
> 
> You don't however want to be "hooking" this - your platform needs to
> provide its own versions of the relevant operations in the OMAP serial
> driver.

Hi Alan,
 thanks for the pointers.

 Looking at serial_core.c, which appears the be the gateway between tty_port
 and the OMAP serial driver, the activate() function it provides is a no-op,
 and the shutdown() function calls uport->ops->shutdown() (and a couple of
 other things).
 However there is  a uart_port_startup() which claims to be called
 once-per-open even though activate() doesn't call it (tty_operations.open()
 does).  And it calls uport->ops->startup().

 The omap-serial handlers for these are serial_omap_startup() and
 serial_omap_shutdown().  I think you are suggesting that I should plug in
 there somehow.  I wonder how.

 Maybe I could teach it to use a given GPIO as a 'DTR', and then write a
 separate driver which registers with gpiolib as providing an output GPIO and
 which responds to changes on that GPIO by turning the device 'on' or 'off'.

 Does that sound reasonably sane?

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Question: How to power-manage UART-attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]

On Mon, 30 Apr 2012 15:51:59 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:

> On 04/30/2012 03:22 PM, NeilBrown wrote:
> > 
> > What I would really like is to integrate it closely with the state
> > of the UART.  i.e. if the /dev/ttyO1 device is open, then the GPS
> > is "on".  If not then it is "off".  Similarly if /dev/tty/O0 is
> > open, bluetooth is "on", else "off". However I cannot find any way
> > to "plug in" to the tty or serial drivers to perform an arbitrary
> > action on first-open or last-close.  Is something like that
> > possible? If not, is it a reasonable thing to ask? Any suggests
> > about where to put such a hook?
> > 
> 
> I don't think that's the right interface.  Just because the port is
> currently open doesn't mean the device is active, nor vice versa.  ALL
> it means is that someone currently has an access handle to it.
> 
> Since a serial port models, well, a *port*, it is logical to think of
> a (hypothetical) socket containing an RS-232 connector as well as a
> power outlet.  Given that, it would be logical to drive the "power
> connector" using the same type of interface used for the other parts
> of an RS-232 control, meaning either with termios flags or via a
> dedicated control ioctl (TIOCPOWER?).
> 
> 	-hpa

Hi Peter,

 I agree that in general there is not necessarily a 1-1 correspondence between
 "device file is open" and "device is powered", however I think that in a lot
 of real cases it is a very natural correspondence. 

 In my bluetooth case, there is nothing useful that the device can do if
 hciattach isn't running and listening to the device, so it may as well be
 off.
 For GPS it is less clear as the GPS could maintain state (current almanac
 and ephemeris) and could even periodically tune in to the satellites and
 update this state (though as mine cannot power on/off the antenna that
 second case might not be very useful).  This particular GPS device does not
 lose state when I toggle the 'on/off' line.  It just stops sending
 information (and maybe stops doing calculations, I don't know).  And that is
 exactly what I want to happen when the tty device is closed.

 I imagine this proposal as being like a virtual DTR line.  It may not always
 be appropriate to connect DTR to the power switch, but sometimes it is.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Question: How to power-manage UART-attached devices.

[H. Peter Anvin]

On 04/30/2012 04:47 PM, NeilBrown wrote:
> 
> I imagine this proposal as being like a virtual DTR line.  It may
> not always be appropriate to connect DTR to the power switch, but
> sometimes it is.
> 

Yeah, that's pretty much what I'm suggesting.

	-hpa

Re: Question: How to power-manage UART-attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On Mon, 30 Apr 2012 16:50:16 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:

> On 04/30/2012 04:47 PM, NeilBrown wrote:
> > 
> > I imagine this proposal as being like a virtual DTR line.  It may
> > not always be appropriate to connect DTR to the power switch, but
> > sometimes it is.
> > 
> 
> Yeah, that's pretty much what I'm suggesting.
> 
> 	-hpa

Yes, so you are :-)

I was distracted by the TIOCPOWER suggestion, and I really didn't want any
new action by user-space, I would much prefer it all "just works".
But you also mentioned "termios flags" but by that I suspect you are
referring to HUPCL which is documented as:

       HUPCL  Lower modem control lines after last process closes  the  device
              (hang up).

without really saying which modem control lines.  Looking at the code it
seems to be talking about DTR and RTS.  It only says "lower on last close"
but doesn't say "raise on first open" but maybe that is assumed.
So as long as HUPCL is the default, defining a virtual DTR line might be just
what I want, and HUPCL could be disabled of someone want to keep the device
powered on while it is closed.

So I think I want to:
 1/ teach omap-serial to drive a given GPIO as a DTR line
 2/ write a 'gpio-regulator' driver which provides a single GPIO and
    turns a given regulator 'on' or 'off' depending on the state of the GPIO
 3/ write a special-purpose GPIO driver which provides a single GPIO
    and toggles another GPIO whenever the state of the first changes, and also
    monitors the serial RX pin when the device should be 'off', and toggles
    again if it sees RX activity.
 4/ Keeping using rfkill to power the GPS antenna.

Sounds like a plan.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]