[PATCH] pl011: added clock management feature

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

On Mon, Dec 06, 2010 at 10:53:20AM +0100, Vitaly Wool wrote:
> Hi Russell,
> 
> On Fri, Dec 3, 2010 at 4:15 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> Why don't you stop
> >> the clocks if RTS is cleared? This would have allowed the line
> >> discipline driver to implicitly control the UART clock and there will
> >> be no risk of losing data, as well as no non-standard behavior
> >> involved. In fact, you'll be transparent to the upper layers in this
> >> case.
> >
> > I've no idea what you're thinking, but you can't stop the UART clock
> > because RTS is deasserted - or DTR for that matter. ?Neither of those
> > two define whether characters will be transmitted or received.
> 
> What I'm mostly up to (and I guess Par also is) is how to conserve
> power for the Bluetooth UARTs. For a Bluetooth UART, there usually is
> a kind of signalling protocol, either inband or out-of-band, that
> allows the host and the chip to negotiate about power conservation
> during inactivity periods. These protocols do not belong to UART
> implementation and are usually implemented as line discipline drivers.
> While BT chip is sleeping, we don't need the UART clock running but we
> need to have a decent way of telling the UART driver it can shut those
> off. Using RTS for that, even though not being applicable in all the
> cases, seems to work pretty well for Bluetooth UARTs. So if we just
> add a flag if an UART is used for BT or not and then use RTS for this
> kind of communication, will it be okay with you?

So you want to teach each UART driver a protocol-specific method of
handling power management rather than implementing a sane API to do
this?

Please, come up with a sane API for power management of UARTs rather
than trying to hack protocol specific stuff into UART drivers.