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

[NeilBrown]

On Tue, 1 May 2012 00:34:20 +0100 Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, 30 Apr 2012 15:51:59 -0700
> "H. Peter Anvin" <hpa@xxxxxxxxx> 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: signature.asc
Description: PGP signature