linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: rpurdie@rpsys.net (Richard Purdie)
To: linux-arm-kernel@lists.infradead.org
Subject: orion5x and GPIO blink question
Date: Wed, 21 Apr 2010 10:21:10 -0700	[thread overview]
Message-ID: <1271870470.1629.85.camel@rex> (raw)
In-Reply-To: <1271836632.2330.128.camel@pasglop>

On Wed, 2010-04-21 at 17:57 +1000, Benjamin Herrenschmidt wrote:
> While fixing up the dns-323 support for rev C I noticed something fishy
> when you use leds-gpio with the "set_blink" callback like the dns323
> code does for using HW blinking.
> 
> The problem is that there's pretty much no clean way to turn the
> blinking off via this API. It sucks, ie, it's a bug in the leds
> subsystem imho, blinking should have it's own enable/disable argument
> rather than relying on set_brightness() to stop blinking but that's how
> they did it so there's no point arguing about it.

If you have blink enabled/disabled options along with set_brightness you
can end up in a state where you disable blinking but the brightness the
LED is left with is effectively random. This is why the LED core does
things that way and I stand by that as it gives defined behaviour (and
mirrors the sysfs interface).

I appreciate in the world of GPIO controllers and the leds-gpio layer
this is tricky to implement but this is more of a mismatch between the
GPIO layer and the LED subsystem which was not addressed in the design
of leds-gpio.

> Now, one way to fix that would be to have the orion5x GPIO stuff simply
> clear the blink bit whenever orion_gpio_set_value() is called.
> 
> Would that break any known setup ? (Other than slightly slowing down
> the GPIO accesses which might be undesirable).
> 
> Another solution might be to be a bit smarter and have leds-gpio
> implement a different set_blink() function that takes an additional
> enable/disable argument, and would call that whenever set_brightness is
> called on a currently blinking GPIO.
> 
> But that means fixing all the in-tree users of leds-gpio set_blink()
> callback (I haven't counted, but it should be easily greppable).
> 
> Opinions ?

I'd be ok with either solution but the bug seems to be in leds-gpio and
therefore fixing it there by adding the extra parameter would have
slight preference rather than having the GPIO layer do magic.

Cheers,

Richard

  parent reply	other threads:[~2010-04-21 17:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-21  7:57 orion5x and GPIO blink question Benjamin Herrenschmidt
2010-04-21 14:29 ` Nicolas Pitre
2010-04-21 21:09   ` Benjamin Herrenschmidt
2010-04-21 17:21 ` Richard Purdie [this message]
2010-04-21 21:31   ` Benjamin Herrenschmidt

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=1271870470.1629.85.camel@rex \
    --to=rpurdie@rpsys.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).