[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120501082209.0b560708@notabene.brown>
Date: Tue, 1 May 2012 08:22:09 +1000
From: NeilBrown <neilb@...e.de>
To: linux-serial@...r.kernel.org, linux-pm@...r.kernel.org
Cc: lkml <linux-kernel@...r.kernel.org>
Subject: Question: How to power-manage UART-attached devices.
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
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists