Re: introduce delayed-leds.h to reduce code duplication

[Pavel Machek]

On Tue 2009-01-20 10:04:00, Henrique de Moraes Holschuh wrote:
> On Mon, 19 Jan 2009, Pavel Machek wrote:
> > On Mon 2009-01-12 08:05:01, Henrique de Moraes Holschuh wrote:
> > > On Sun, 11 Jan 2009, Pavel Machek wrote:
> > > > What about something like this? 
> > > > 
> > > > [Alternatively, I can add a flag to the leds class, and make delayed
> > > > leds a built-in functionality...]
> > > > 
> > > > [Attached is driver that uses new infrastructure for hp_accel, but it
> > > > does a bit more.]
> > > 
> > > FWIW, I am looking over the thinkpad-acpi side of this.  I like the idea,
> > > but I am not completely sure I agree fully with the changes to
> > > thinkpad-acpi.
> > > 
> > > Which isn't a problem, as long as the thinkpad-acpi hunks are NOT merged to
> > > any tree before my ACK, please.  I will test and comment on the patch before
> > > the weekend.
> > 
> > Any news?
> 
> Sure.  Sorry for not replying earlier.
> 
> I don't like the loss of functionality of the private workqueue.  I kicked
> the thinkpad led handling to a private workqueue in order to never tie up
> the system-wide one with crap spinning around in the ACPI layer, etc.  In
> fact, all thinkpad-acpi deferred work is in the private workqueue for this
> reason.

Is the private workqueue really required? AFAICT workqueues are not
exactly cheap, and leds are not toggled that often. Was it problem in
practice?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/