Messages in this thread | | | From | David Brownell <> | Subject | Re: [patch 2.6.28-rc2] atmel_serial: keep clock off when it's not needed | Date | Tue, 28 Oct 2008 10:08:12 -0700 |
| |
On Tuesday 28 October 2008, Haavard Skinnemoen wrote: > David Brownell <david-b@pacbell.net> wrote: > > On Tuesday 28 October 2008, Haavard Skinnemoen wrote: > > > David Brownell <david-b@pacbell.net> wrote: > > > > From: David Brownell <dbrownell@users.sourceforge.net> > > > > > > > > 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 <dbrownell@users.sourceforge.net> > > > > > > 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
| |