[PATCH] pl011: added clock management feature

[Par-Gunnar HJALMDAHL]

Hi Russell,

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: den 6 december 2010 11:14
> To: Vitaly Wool
> Cc: Greg KH; Linus WALLEIJ; Par-Gunnar HJALMDAHL; Greg Kroah-Hartman;
> Lukasz Rymanowski; Grzegorz Sygieda; linux-serial at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] pl011: added clock management feature
> 
> 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.

So I guess the best solution would then be to add function(s) to struct tty_operations in tty_driver.h? Something like
void (*clk_enable)(struct tty_struct *tty);
void (*clk_disable)(struct tty_struct *tty);
and then it is up to each UART driver to implement them? Would such a solution be OK?

/P-G