![]() | ||||||||||
Messages in this thread Patch in this message |
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);
}
| |||||||||
| Last update: 2008-03-19 22:37 [W:0.207 / U:0.050 seconds] ©2003-2008 Jasper Spaans | ||||||||||