public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: David Brownell <david-b@pacbell.net>
Cc: mathias nyman <mathias.nyman@nokia.com>,
	felipe.balbi@nokia.com, ext Riku Voipio <riku.voipio@iki.fi>,
	Tony Lindgren <tony@atomide.com>,
	linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/3] lp5521: move to drivers/leds
Date: Tue, 07 Oct 2008 09:32:45 +0100	[thread overview]
Message-ID: <1223368365.5201.2.camel@dax.rpnet.com> (raw)
In-Reply-To: <200810060933.49739.david-b@pacbell.net>

On Mon, 2008-10-06 at 09:33 -0700, David Brownell wrote:
> This would seem like a good motivation to add some features
> to the LED framework.  Here are three types of LED that it
> doesn't support well today:
> 
>  - Bicolor leds with two leads ... R-or-G, two wires,
>    opposite diode directions.
> 
>  - Bicolor LEDs with three leads ... like R-and-Y, three
>    wires, common anode or common cathode
> 
>  - RGB leds, four leads ... like R-and-G-and-B, etc
> 
> Except for the first case, these can be stuffed into the
> framework by modeling them as multiple LEDs.  But when you
> do that it gets awkward to make sure that for example you
> get a purple (+R, -G, +B) blink, since the timers need to
> be exactly in phase.  Or to combine blinking with PWM, so
> you could for example mix in a little green...
> 
> Surely some features that would support RGB (RG, YG, etc)
> LEDs better could support both fancy (lp5521) and simple
> (GPIO without PWM) implementations ...

The question is how and what you add to the class to support these
types. It could be as simple as some more obvious naming conventionto
associate LEDs and a way of sharing triggers amongst LEDs I guess...

Cheers,

Richard



  reply	other threads:[~2008-10-07  8:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-06  9:11 [PATCH 0/3] lp5521 Felipe Balbi
2008-10-06  9:11 ` [PATCH 1/3] i2c: lp5521: remove dead code Felipe Balbi
2008-10-06  9:11   ` [PATCH 2/3] i2c: lp5521: cosmetic fixes Felipe Balbi
2008-10-06  9:11     ` [PATCH 3/3] lp5521: move to drivers/leds Felipe Balbi
2008-10-06 11:08       ` Riku Voipio
2008-10-06 11:17         ` Tony Lindgren
2008-10-06 11:51           ` Felipe Balbi
2008-10-06 12:54             ` Riku Voipio
2008-10-06 12:58               ` Felipe Balbi
2008-10-06 13:32                 ` mathias nyman
2008-10-06 16:33                   ` David Brownell
2008-10-07  8:32                     ` Richard Purdie [this message]
2008-10-07  9:09                       ` David Brownell
2008-10-06  9:47   ` [PATCH 1/3] i2c: lp5521: remove dead code Daniel Stone
2008-10-06 10:02     ` Felipe Balbi

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=1223368365.5201.2.camel@dax.rpnet.com \
    --to=rpurdie@rpsys.net \
    --cc=david-b@pacbell.net \
    --cc=felipe.balbi@nokia.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=mathias.nyman@nokia.com \
    --cc=riku.voipio@iki.fi \
    --cc=tony@atomide.com \
    /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