[PATCH] pl011: added clock management feature

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Wed, Nov 10, 2010 at 10:15:53AM +0200, Grzegorz.Sygieda at tieto.com wrote:
> The main goal was to disable/enable clock while port open. This is usefull
> for scenario, where some higher level driver wants to control the power
> consumption (using set_termios). In the same time a user-space app (eg.
> hciattach) is still bounded to the specific /dev/tty* device associated
> with particular uart. From user POV device is always open, and app does
> not have to respawn, and we can save power.

If a port is open, and bound (eg to a bluetooth hci), how does the higher
level decide whether to place the port in low power mode?  How does it
know that there isn't going to be characters sent to the port?

When the port is in this low power mode, it's as good as closed from the
external world point of view.

I don't like this idea because I really can't see how it could be used
effectively - there isn't really any way for a bound protocol to know
whether there's characters expected to be received or not.  Either the
port is open and in use, or it isn't.

Let's take an example of a modem waiting for an incoming call.  It spends
most of its time waiting for the call.  You could argue that you could
shut the clock off to the port to save power - but then how do you receive
the "RING" message from the modem?  As you've shut the clock off, you're
not going to detect the activity on the receive line.

I'm sure that also applies to bluetooth as well, especially if you're a
'client' device - as long as the port is attached, bluetooth probably
expects to be able to listen to what's going on so the device can be
discovered.

It's all very well adding hooks to the transmit path to ensure that there
clock is on while there's characters to be sent, but this really doesn't
help you on the receive side.

I'm worried...