linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Craig McQueen <craig.mcqueen@innerrange.com.au>
To: Pavel Machek <pavel@ucw.cz>
Cc: "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Subject: RE: Bug when using both "set" and "blink" functions
Date: Thu, 23 Nov 2017 00:14:13 +0000	[thread overview]
Message-ID: <5bd49c5bd6c24edf93bc9d22ca409235@innerrange.com.au> (raw)
In-Reply-To: <20171122123605.GB10654@amd>

Pavel Machek wrote:
> On Wed 2017-11-22 00:55:12, Craig McQueen wrote:
> > I'd like to control a LED to possibly be any of:
> >
> > * Off
> > * On
> > * Blinking
> >
> > I've had this working fine in 3.14.x kernel.
> >
> > But when upgrading to 4.4.x, I found that the transition from "blinking" to
> "on" didn't work. Namely, if it's blinking and then I call
> led_set_brightness(led_cdev, LED_FULL), then it wouldn't work (I can't
> remember if it turned off, or remained blinking; it wasn't on anyway). I
> worked around it by calling led_set_brightness(led_cdev, LED_OFF) just
> before led_set_brightness(led_cdev, LED_FULL).
> >
> > Now I have upgraded to 4.9.x, and found that the transition from "blinking"
> to "on" again isn't working. The LED ends up being off instead of on.
> >
> > Examining the code of led_set_brightness():
> >
> > * Behaviour is different depending on whether the brightness is LED_OFF
> (it schedules the blink to be turned off "soon") or other (it alters the
> brightness of subsequent blinks).
> > * It looks as though there are race conditions in the transition from blinking
> to steady off -- it schedules the blink to be turned off "soon", so it's difficult
> to guarantee a reliable transition from blinking to on/off.
> >
> > The combination of the above two points makes it seem difficult to
> robustly go from blinking to off/on.
> >
> > So, my questions are:
> >
> > * What is the correct way to use the API to reliably control an LED
> > for a combination of off/on/blinking?
> 
> You should be able to use sysfs from the userland. .. if that is broken we
> need to fix it.
> 
> What are you trying to do?

I've written a kernel driver for a power supply interface on some custom hardware. I'm using LED trigger API to make two LED triggers, "power" and "battery". The "battery" LED trigger should be off when no battery, on when battery is present and okay, or flashing when battery is present but in fault condition.

* Off: led_trigger_event(trigger, LED_OFF)
* On: led_trigger_event(trigger, LED_FULL)
* Flashing: led_trigger_blink(trigger, &delay_on, &delay_off)

But for kernel 4.4, going from flashing to on didn't work. I had to change the On case to:
* On: led_trigger_event(trigger, LED_OFF); led_trigger_event(trigger, LED_FULL);

But for kernel 4.9, that again doesn't work when going from flashing to on (the LED is turned off).

My driver is using triggers, but the trigger calls lead fairly directly to:

* Off: led_trigger_event(trigger, LED_OFF) --> led_set_brightness(led_cdev, LED_OFF)
* On: led_trigger_event(trigger, LED_FULL) --> led_set_brightness(led_cdev, LED_FULL)
* Flashing: led_trigger_blink(trigger, &delay_on, &delay_off) --> led_blink_set(led_cdev, delay_on, delay_off)

-- 
Craig McQueen

  reply	other threads:[~2017-11-23  0:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22  0:55 Bug when using both "set" and "blink" functions Craig McQueen
2017-11-22  3:36 ` Craig McQueen
2017-11-22 12:36 ` Pavel Machek
2017-11-23  0:14   ` Craig McQueen [this message]
2017-11-22 19:53 ` Jacek Anaszewski
2017-11-23  0:55   ` Craig McQueen
2017-11-23 21:36     ` Jacek Anaszewski
2017-11-24  5:23       ` Craig McQueen
2017-11-24 20:13         ` Jacek Anaszewski
2017-11-25 21:42 ` Jacek Anaszewski
2017-11-27  6:51   ` Craig McQueen
2017-11-27 19:26     ` Jacek Anaszewski
2017-11-28  4:32       ` Craig McQueen
2017-11-28 21:35         ` Jacek Anaszewski
2017-11-28 21:44           ` Jacek Anaszewski
2017-11-28 23:40             ` Craig McQueen
2017-11-29 20:45               ` Jacek Anaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5bd49c5bd6c24edf93bc9d22ca409235@innerrange.com.au \
    --to=craig.mcqueen@innerrange.com.au \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).