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? Thanks, Vitaly -- 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
