[PATCH] pl011: added clock management feature
Russell King - ARM Linux
linux at arm.linux.org.uk
Mon Dec 6 05:14:27 EST 2010
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 at 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.
More information about the linux-arm-kernel
mailing list