LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Trent Piepho <tpiepho@freescale.com>
To: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org,
	Anton Vorontsov <avorontsov@ru.mvista.com>,
	Richard Purdie <rpurdie@rpsys.net>,
	Sean MacLennan <smaclennan@pikatech.com>,
	Wolfram Sang <w.sang@pengutronix.de>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: OpenFirmware GPIO LED driver
Date: Fri, 24 Oct 2008 16:04:57 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0810241442240.3790@t2.domain.actdsltmp> (raw)

This series of patches adds support for OpenFirmware bindings for GPIO based
LEDs.

I last posted a version of this in July but discussion of the OF binding
details didn't seem to be going anywhere.

I've since been contacted by some people who are actually using the previous
patches and have been motivated to try again.

All the users of this code are satisfied with the current version and it does
everything they need it to do.

The first patch extends the of_get_gpio() function to provide the gpio flags.

The way this already works (i.e., this is not something I'm adding, it's
what's already there) is that the OF gpio specifier is an opaque sequence of
words.  The GPIO controller driver (of which only one currently exists)
provides an ->xlate() method that turns this into a Linux gpiolib gpio number. 
All current gpio controllers have flags in their gpio specifier, but there is
no way to get them.  So I extend the xlate method to also produce the flags in
a Linux format, the same way it produces a Linux gpio number.

The second patch adds OF bindings to the gpio-leds driver.  The existing code
is refactored so that almost all of the common code is shared between the two
binding methods.  Either or both bindings can be selected via Kconfig.  The
bindings do have one "linux," property, but no one has been able to come up
with something close to workable that avoids this and still satisfies the
*requirement* that the default trigger be settable from the OF bindings.

The second and third patches add some additional capabilities for gpio leds
that some users need.

One is to have a LED start in the on state when it's made known to Linux. 
There is already a "default-on" trigger that does this, but it produces a
glitch where an LED that is already on will turn off then back on.  My (tiny)
patch avoids this problem.

The next lets an LED stay, without glitches, in whatever state it was already
in when it's made known to Linux.  It may have been put into this state by the
BIOS, firmware, bootloader, or the hardware itself.

             reply	other threads:[~2008-10-24 23:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-24 23:04 Trent Piepho [this message]
2008-10-24 23:08 ` [PATCH 1/4] of_gpio: Return GPIO flags from of_get_gpio() Trent Piepho
2008-10-24 23:32   ` Grant Likely
2008-10-28 14:39   ` Anton Vorontsov
2008-10-28 14:53     ` Grant Likely
2008-10-28 15:16       ` Anton Vorontsov
2008-10-28 15:42         ` Grant Likely
2008-10-28 16:56           ` Anton Vorontsov
2008-10-28 17:40             ` Grant Likely
2008-10-30  2:21     ` [PATCH 1/4] of_gpio: Return GPIO flags from of_get_gpio()A Trent Piepho
2008-10-30 11:15       ` Anton Vorontsov
2008-10-31  2:03         ` [PATCH v2] of_gpio: Return GPIO flags from of_get_gpio() Trent Piepho
2008-11-26 16:20           ` Anton Vorontsov
2008-11-26 21:38             ` Paul Mackerras
2008-11-26 22:31               ` Anton Vorontsov
2008-11-26 22:35               ` Trent Piepho
2008-11-26 22:58                 ` Anton Vorontsov
2008-11-26 23:32                 ` Paul Mackerras
2008-10-24 23:08 ` [PATCH 2/4] leds: Support OpenFirmware led bindings Trent Piepho
2008-10-24 23:50   ` Grant Likely
2008-10-24 23:09 ` [PATCH 3/4] leds: Add option to have GPIO LEDs start on Trent Piepho
2008-10-24 23:59   ` Grant Likely
2008-10-24 23:09 ` [PATCH 4/4] leds: Let GPIO LEDs keep their current state Trent Piepho
2008-10-25  0:04   ` Grant Likely
2008-11-17 14:50   ` Richard Purdie
2008-11-21  1:05     ` Trent Piepho
2008-11-23 12:31       ` Pavel Machek
2008-12-03 10:04         ` Richard Purdie
2008-12-10  4:33           ` Trent Piepho

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=Pine.LNX.4.64.0810241442240.3790@t2.domain.actdsltmp \
    --to=tpiepho@freescale.com \
    --cc=avorontsov@ru.mvista.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=rpurdie@rpsys.net \
    --cc=smaclennan@pikatech.com \
    --cc=w.sang@pengutronix.de \
    --subject='Re: OpenFirmware GPIO LED driver' \
    /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

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).