Hi Russell, > -----Original Message----- > From: Russell King - ARM Linux [mailto:linux@xxxxxxxxxxxxxxxx] > 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@xxxxxxxxxxxxxxx; > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
