Messages in this thread | | | Date | Sun, 8 Mar 2009 09:29:02 +0100 | From | Pavel Machek <> | Subject | Re: introduce delayed-leds.h to reduce code duplication |
| |
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
| |