From: David Brownell <[email protected]>
The atmel_serial driver is mismanaging its clock by leaving it on
at all times ... the whole point of clock management is to leave
it off unless it's actively needed, which conserves power!!
Signed-off-by: David Brownell <[email protected]>
---
drivers/serial/atmel_serial.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/serial/atmel_serial.c
+++ b/drivers/serial/atmel_serial.c
@@ -1258,6 +1258,8 @@ static void __devinit atmel_init_port(st
atmel_port->clk = clk_get(&pdev->dev, "usart");
clk_enable(atmel_port->clk);
port->uartclk = clk_get_rate(atmel_port->clk);
+ clk_disable(atmel_port->clk);
+ /* only enable clock when USART is in use */
}
atmel_port->use_dma_rx = data->use_dma_rx;
@@ -1544,7 +1546,6 @@ err_add_port:
port->rx_ring.buf = NULL;
err_alloc_ring:
if (!atmel_is_console_port(&port->uart)) {
- clk_disable(port->clk);
clk_put(port->clk);
port->clk = NULL;
}
@@ -1568,7 +1569,6 @@ static int __devexit atmel_serial_remove
/* "port" is allocated statically, so we shouldn't free it */
- clk_disable(atmel_port->clk);
clk_put(atmel_port->clk);
return ret;
David Brownell <[email protected]> wrote:
> From: David Brownell <[email protected]>
>
> The atmel_serial driver is mismanaging its clock by leaving it on
> at all times ... the whole point of clock management is to leave
> it off unless it's actively needed, which conserves power!!
>
> Signed-off-by: David Brownell <[email protected]>
Hmm...the only remaining clk_enable() is in atmel_serial_pm(). Is that
really enough?
It looks like the serial core calls ->pm() to power the port up before
doing anything that might touch the registers, but I can't see that the
console layer does the same thing...
Haavard
On Tuesday 28 October 2008, Haavard Skinnemoen wrote:
> David Brownell <[email protected]> wrote:
> > From: David Brownell <[email protected]>
> >
> > The atmel_serial driver is mismanaging its clock by leaving it on
> > at all times ... the whole point of clock management is to leave
> > it off unless it's actively needed, which conserves power!!
> >
> > Signed-off-by: David Brownell <[email protected]>
>
> Hmm...the only remaining clk_enable() is in atmel_serial_pm(). Is that
> really enough?
>
> It looks like the serial core calls ->pm() to power the port up before
> doing anything that might touch the registers, but I can't see that the
> console layer does the same thing...
I verified it on AT91, where the console is normally DBGU and the
other USARTs do get an open().
Didn't verify on AVR32, since 2.6.28-rc can't see the root FS because
of that NOR flash problem. Though I suppose I can try it on an older
kernel.
As a rule the boot loader will be using that USART, and thus will
have enabled its clock. :)
- Dave
>
> Haavard
>
>
David Brownell <[email protected]> wrote:
> On Tuesday 28 October 2008, Haavard Skinnemoen wrote:
> > David Brownell <[email protected]> wrote:
> > > From: David Brownell <[email protected]>
> > >
> > > The atmel_serial driver is mismanaging its clock by leaving it on
> > > at all times ... the whole point of clock management is to leave
> > > it off unless it's actively needed, which conserves power!!
> > >
> > > Signed-off-by: David Brownell <[email protected]>
> >
> > Hmm...the only remaining clk_enable() is in atmel_serial_pm(). Is that
> > really enough?
> >
> > It looks like the serial core calls ->pm() to power the port up before
> > doing anything that might touch the registers, but I can't see that the
> > console layer does the same thing...
>
> I verified it on AT91, where the console is normally DBGU and the
> other USARTs do get an open().
>
> Didn't verify on AVR32, since 2.6.28-rc can't see the root FS because
> of that NOR flash problem. Though I suppose I can try it on an older
> kernel.
>
> As a rule the boot loader will be using that USART, and thus will
> have enabled its clock. :)
Hmm. But in the cases when "normally" and "as a rule" don't apply, the
board will lock up solid with no console output since it will wait
forever for the TXRDY bit to be set...
I'd like to know for sure that it cannot happen, please.
Haavard
On Tuesday 28 October 2008, Haavard Skinnemoen wrote:
> David Brownell <[email protected]> wrote:
> > On Tuesday 28 October 2008, Haavard Skinnemoen wrote:
> > > David Brownell <[email protected]> wrote:
> > > > From: David Brownell <[email protected]>
> > > >
> > > > The atmel_serial driver is mismanaging its clock by leaving it on
> > > > at all times ... the whole point of clock management is to leave
> > > > it off unless it's actively needed, which conserves power!!
> > > >
> > > > Signed-off-by: David Brownell <[email protected]>
> > >
> > > Hmm...the only remaining clk_enable() is in atmel_serial_pm(). Is that
> > > really enough?
> > >
> > > It looks like the serial core calls ->pm() to power the port up before
> > > doing anything that might touch the registers, but I can't see that the
> > > console layer does the same thing...
> >
> > I verified it on AT91, where the console is normally DBGU and the
> > other USARTs do get an open().
> >
> > Didn't verify on AVR32, since 2.6.28-rc can't see the root FS because
> > of that NOR flash problem. Though I suppose I can try it on an older
> > kernel.
> >
> > As a rule the boot loader will be using that USART, and thus will
> > have enabled its clock. :)
>
> Hmm. But in the cases when "normally" and "as a rule" don't apply, the
> board will lock up solid with no console output since it will wait
> forever for the TXRDY bit to be set...
>
> I'd like to know for sure that it cannot happen, please.
I'd just like to know that this bug is fixed. Do you have a
better fix? (And a board broken by this patch, to verify it?)
- Dave
David Brownell <[email protected]> wrote:
> > > I verified it on AT91, where the console is normally DBGU and the
> > > other USARTs do get an open().
> > >
> > > Didn't verify on AVR32, since 2.6.28-rc can't see the root FS because
> > > of that NOR flash problem. Though I suppose I can try it on an older
> > > kernel.
> > >
> > > As a rule the boot loader will be using that USART, and thus will
> > > have enabled its clock. :)
> >
> > Hmm. But in the cases when "normally" and "as a rule" don't apply, the
> > board will lock up solid with no console output since it will wait
> > forever for the TXRDY bit to be set...
> >
> > I'd like to know for sure that it cannot happen, please.
>
> I'd just like to know that this bug is fixed. Do you have a
> better fix? (And a board broken by this patch, to verify it?)
Fixing a bug by introducing a worse one isn't much of an improvement.
The bug may be difficult to trigger, but that makes it even worse,
IMO.
I'll see if I can come up with a fix. Basically, we need to enable the
clock when initializing the console, and disable it after calling
uart_add_one_port() if the port is the console.
Haavard
hi David,
> I verified it on AT91, where the console is normally DBGU and the
> other USARTs do get an open().
The DBGU is part of the system peripherals, which are clocked from MCK
and which is always enabled.
Therefore I don't think this is a valid test-case.
Regards,
Andrew Victor
On Tuesday 28 October 2008, Andrew Victor wrote:
> hi David,
>
> > I verified it on AT91, where the console is normally DBGU and the
> > other USARTs do get an open().
>
> The DBGU is part of the system peripherals, which are clocked from MCK
> and which is always enabled.
Exactly.
> Therefore I don't think this is a valid test-case.
Not for the oddball case Haavard mentioned, no: the console port
being something the boot loader wasn't using, which couldn't show
the early boot messages (before console setup) in any case. Those
kinds of systems aren't especially debuggable (it's JTAG or nothing).
I don't have any issue with getting that fixed too ... but unless
someone has a platform that relies on that case (or can be made to
do so, for testing), then it's hard for me to worry about it!
- Dave
>
> Regards,
> Andrew Victor
>
>
David Brownell <[email protected]> wrote:
> On Tuesday 28 October 2008, Andrew Victor wrote:
> > hi David,
> >
> > > I verified it on AT91, where the console is normally DBGU and the
> > > other USARTs do get an open().
> >
> > The DBGU is part of the system peripherals, which are clocked from MCK
> > and which is always enabled.
>
> Exactly.
Exactly what? That your patch has exactly zero effect on your test case?
> > Therefore I don't think this is a valid test-case.
>
> Not for the oddball case Haavard mentioned, no: the console port
> being something the boot loader wasn't using, which couldn't show
> the early boot messages (before console setup) in any case. Those
> kinds of systems aren't especially debuggable (it's JTAG or nothing).
Since when is it acceptable to lock up solid in "oddball" cases? Not to
mention that I don't think this is an "oddball" case at all -- the
bootloader has absolutely _no_ way of influencing the initial enable
count of the clock, so the kernel will turn it off as soon as it gets
the chance.
The oddball case is when the clock happens to be shared with
peripherals that are always enabled. Then it doesn't matter if the
clock management in atmel_serial is screwed up.
> I don't have any issue with getting that fixed too ... but unless
> someone has a platform that relies on that case (or can be made to
> do so, for testing), then it's hard for me to worry about it!
David, I can't believe you're taking such an easy attitude towards
basic correctness!
I agree that the clock management is already wrong, but keeping a
couple of clocks enabled when they could have been disabled is far less
of a problem than locking up the console.
I also understand if you don't want to fix the console issue I pointed
out, but I'm surprised that you aren't even willing to acknowledge the
problem, brushing it off with words like "normally" and "as a rule".
Haavard
On Wednesday 29 October 2008, Haavard Skinnemoen wrote:
> David Brownell <[email protected]> wrote:
> > On Tuesday 28 October 2008, Andrew Victor wrote:
> > >
> > > > I verified it on AT91, where the console is normally DBGU and the
> > > > other USARTs do get an open().
> > >
> > > The DBGU is part of the system peripherals, which are clocked from MCK
> > > and which is always enabled.
> >
> > Exactly.
>
> Exactly what?
Exactly the point I was making by describing the testing:
it covered "normal" behavior where the console was clocked
when Linux started. But not the case you described.
> That your patch has exactly zero effect on your test case?
Hardly; if that were the case, I wouldn't have posted it!
The other UARTs' clocks again behaved correctly during normal
operation ... acting like they did a few years ago when last I
happened to look at how clocks interacted with this driver.
(Or maybe "with its predecessor".)
> > > Therefore I don't think this is a valid test-case.
> >
> > Not for the oddball case Haavard mentioned, no: the console port
> > being something the boot loader wasn't using, which couldn't show
> > the early boot messages (before console setup) in any case. Those
> > kinds of systems aren't especially debuggable (it's JTAG or nothing).
>
> Since when is it acceptable to lock up solid in "oddball" cases?
I'm not sure why you're asking *me* that, instead of some
person who said it was OK. I pointed out that a system
configured like that would have a lot more rude failure
modes than just the one you were pointing out. Enough to
ensure such configurations wouldn't find much use at all.
> Not to work
> mention that I don't think this is an "oddball" case at all -- the
> bootloader has absolutely _no_ way of influencing the initial enable
> count of the clock, so the kernel will turn it off as soon as it gets
> the chance.
That's a nuance that the platform's clock code needs to handle.
Rule of thumb: don't turn off "unused" clocks until late in the
system boot sequence ... when drivers for various devices, like
the console, have been fully initialized. Else you'll turn off
something that was used implicitly during booting: clocks for
intermediate busses, boot media, console, etc.
> > I don't have any issue with getting that fixed too ... but unless
> > someone has a platform that relies on that case (or can be made to
> > do so, for testing), then it's hard for me to worry about it!
>
> David, I can't believe you're taking such an easy attitude towards
> basic correctness!
Call it pragmatism. In a choice between fixing a bug that's been
observed to happen, or not doing so because of an issue that's never
been observed (and won't appear on production systems) ... I'd fix
the bug, and worry about that issue later (if at all).
> I agree that the clock management is already wrong, but keeping a
> couple of clocks enabled when they could have been disabled is far less
> of a problem than locking up the console.
And I asked what systems would actually see such a lockup. What
system will let me talk to the boot loader on a console, telling
it how to boot, but then lock up when it gets into Linux?
> I also understand if you don't want to fix the console issue I pointed
> out, but I'm surprised that you aren't even willing to acknowledge the
> problem, brushing it off with words like "normally" and "as a rule".
Reread the words of mine that you quoted above; I acknowledged the
issue but can't see it being critical.
- Dave