lkml.org 
[lkml]   [2011]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Locking in the clk API
On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:

> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
> > I really don't like the fact that people are doing these things in
> > atomic contexts, and I think we should apply some pressure to move
> > the atomic caller cases to use systems where they can sleep such as
> > using threaded-irq handlers (they work very nicely)
>
> How do you ensure that printk is always called from a non-atomic
> context?

Is this a good example? I don't think that power sensitive systems such
as a cellphone should keep printk() enabled in the final product. The
output from printk() over a serial port is a debugging convenience, and
trying to aggressively turn on/off the serial clock around each call to
printk() is a bit silly. Better simply turn the serial clock on
whenever its console facility is opened, and turn it off when the
console is closed, which should be good enough in that context.


Nicolas


\
 
 \ /
  Last update: 2011-01-20 22:33    [W:0.113 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site