From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pl011: added clock management feature
Date: Fri, 3 Dec 2010 15:15:47 +0000 [thread overview]
Message-ID: <20101203151547.GA30898@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <AANLkTikUmq7qeFb+0XPpmzcvp5q_Z4SMjBaAgNZaCRqV@mail.gmail.com>
On Fri, Dec 03, 2010 at 12:47:14PM +0100, Vitaly Wool wrote:
> On Tue, Nov 9, 2010 at 11:40 PM, Greg KH <greg@kroah.com> wrote:
> > On Tue, Nov 09, 2010 at 04:30:37PM +0100, Linus Walleij wrote:
> >> From: Grzegorz Sygieda <grzegorz.sygieda@tieto.com>
> >>
> >> This patch allows to control the pl011 clock using set_termios
> >> callback. Any positive baudrate passed enables clock, otherwise
> >> disables. This saves a lot of power on submicron designs since
> >> we can clock off and disable unused UARTs.
> >
> > That's nice, but it seems like an overload of what people traditionally
> > think of when it comes to baud rates. ?Why not just power down ports
> > that are not open instead?
>
> I like the idea as well and this is definitely gonna help conserving
> the power for Bluetooth UARTs.
>
> But using baud rate 0 is something I don't like.
You can't use the baud rate of 0 to power down ports - that already has
a POSIX-defined function (hang up).
> 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.
There are specialist protocols and devices out there which require
RTS and DTR to be held at certain non-standard states for them to work.
One range of devices are car OBD-II interfaces, where RTS controls the
L line and sometimes the TX/RX direction on the bidirectional K data
line.
Similar things are done with DTR, and there's protocols which use
DTR as a handshake.
next prev parent reply other threads:[~2010-12-03 15:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 15:30 [PATCH] pl011: added clock management feature Linus Walleij
2010-11-09 15:44 ` Russell King - ARM Linux
2010-11-09 22:40 ` Greg KH
2010-11-10 0:01 ` Russell King - ARM Linux
2010-11-10 7:54 ` Grzegorz.Sygieda at tieto.com
2010-11-10 8:15 ` Grzegorz.Sygieda at tieto.com
2010-11-10 17:00 ` Greg KH
2010-11-10 17:11 ` Russell King - ARM Linux
2010-11-17 8:24 ` Grzegorz.Sygieda at tieto.com
2010-12-03 11:47 ` Vitaly Wool
2010-12-03 15:15 ` Russell King - ARM Linux [this message]
2010-12-06 9:53 ` Vitaly Wool
2010-12-06 10:14 ` Russell King - ARM Linux
2010-12-06 12:23 ` Par-Gunnar HJALMDAHL
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101203151547.GA30898@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).