![]() | |||||||||||
Messages in this thread Complete thread (EXPERIMENTAL) |
David Brownell <david-b@pacbell.net> wrote: On Tuesday 18 March 2008, Andrew Morton wrote:
On Sun, 16 Mar 2008 11:46:23 -0800 David Brownell <david-b@pacbell.net> wrote:
On Sunday 16 March 2008, Henrique de Moraes Holschuh wrote:
Is the use of "if (preempt_count())" to know when to defer led gpio work to
a workqueue needed? __Shouldn't "if (in_atomic())" be enough?
At this point, I don't know of any such reason. I remember hunting for the right heuristic, and settling on that one for reasons that I can't recall now. They may even be no longer applicable. Both are incorrect. So something like the appended patch would seem "better"? <greps for in_atomic>
omigawd, what have we done, and how can we fix it? :( ============== It appears that we can't just check to see if we're in a task context ... so instead of trying that, just make the relevant leds always schedule a little worklet. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> --- drivers/leds/leds-gpio.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- g26.orig/drivers/leds/leds-gpio.c 2008-03-18 01:32:08.000000000 -0700 +++ g26/drivers/leds/leds-gpio.c 2008-03-18 02:01:23.000000000 -0700 @@ -49,13 +49,13 @@ static void gpio_led_set(struct led_clas if (led_dat->active_low) level = !level; - /* setting GPIOs with I2C/etc requires a preemptible task context */ + /* Setting GPIOs with I2C/etc requires a task context, and we don't + * seem to have a reliable way to know if we're already in one; so + * let's just assume the worst. + */ if (led_dat->can_sleep) { - if (preempt_count()) { - led_dat->new_level = level; - schedule_work(&led_dat->work); - } else - gpio_set_value_cansleep(led_dat->gpio, level); + led_dat->new_level = level; + schedule_work(&led_dat->work); } else gpio_set_value(led_dat->gpio, level); } Better, I guess. There's a design problem in the LED interface, though. If callers really do want to be able to call led_classdev.brightness_set() from atomic contexts then we should either a) make that function atomic (as you've done). But that's inefficient. b) pass in a mode flag to tell the callee whether it is allowed to sleep. Ugly, but there's lots of precedent: GFP_ATOMIC-vs-GFP_KERNEL. c) create a separate led_classdev.brightness_set_atomic() which callers should use when they're in atomic contexts. Option c) would be best from a cleanness and efficiency POV. | ||||||||||
![]() | |||||||||||
| Last update: 2008-03-19 22:11 [W:0.518 / U:0.020 seconds] ©2003-2005 Jasper Spaans | |||||||||||