On Tue, 1 May 2012 00:34:20 +0100 Alan Cox [off-list ref] wrote:

On Mon, 30 Apr 2012 15:51:59 -0700
"H. Peter Anvin" [off-list ref] wrote:

quoted

On 04/30/2012 03:22 PM, NeilBrown wrote:

quoted

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