public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: mathias nyman <mathias.nyman@nokia.com>
To: felipe.balbi@nokia.com
Cc: ext Riku Voipio <riku.voipio@iki.fi>,
	Tony Lindgren <tony@atomide.com>,
	linux-omap@vger.kernel.org, rpurdie@rpsys.net
Subject: Re: [PATCH 3/3] lp5521: move to drivers/leds
Date: Mon, 06 Oct 2008 16:32:13 +0300	[thread overview]
Message-ID: <48EA135D.3070104@nokia.com> (raw)
In-Reply-To: <20081006125809.GR7437@gandalf.research.nokia.com>

Felipe Balbi wrote:
> On Mon, Oct 06, 2008 at 03:54:57PM +0300, ext Riku Voipio wrote:
>   
>> On Mon, Oct 06, 2008 at 02:51:03PM +0300, Felipe Balbi wrote:
>>     
>>> On Mon, Oct 06, 2008 at 02:17:23PM +0300, Tony Lindgren wrote:
>>>       
>>>> * Riku Voipio <riku.voipio@iki.fi> [081006 14:09]:
>>>>         
>>>>> On Mon, Oct 06, 2008 at 12:11:31PM +0300, Felipe Balbi wrote:
>>>>>           
>>>>>> This driver should be sitting together with the other
>>>>>> led drivers.
>>>>>>             
>>>>> But this driver actually doesn't implement the led sysfs interface.
>>>>> If the driver is changed to implement the led framework interface,
>>>>> we break the existing n810 userland and expose only limited subset
>>>>> of lp5521 features for userland..
>>>>>           
>>>> Maybe this feature should be a distro specific hack on top of
>>>> the mainline tree?
>>>>         
>>> the problem is that led api (afaict) doesn't really have abstraction for
>>> rgb leds like the one we use. It can only handle blinky leds and on/off
>>> transitions and we need more functionality.
>>>       
>> RGB can somewhat be handled, by creating three led devices:
>>
>> n810:red:foo
>> n810:gree:foo
>> n810:blue:foo
>>     
>
> If that's the case I'd expect the driver author to do it since I have no
> time left for that. A few fixes here and there to the driver is fine and
> preparing the driver for mainline integration is also fine since it's a
> simple cp iteration.
>
>   
The driver and chip supports lots of functionality that is not yet in 
the led framework.
Even if there is now support for some "Hardware accelerated blink of 
LEDs" it is not enough.

The lp5521 chip can be programmed with blinking patterns including 
fades, triggers between R, G and B channels and other nice features
Chip has three modes: direct,(set brightness of leds directly through 
sysfs) load (load a pattern to channel) and run.

RGB direct mode could be handled with three led devices but the rest of 
the functionality is a bit trickier.

Patterns are mainly used in n810 as it doesn't require any CPU interaction

At the time of writing this driver led-class.txt stated that:
"Some leds can be programmed to flash in hardware. As this isn't a generic
LED device property, this should be exported as a device specific sysfs
attribute rather than part of the class if this functionality is required."

The driver for the next version of the lp552x chip uses the led class 
for the direct mode

-Mathias


  reply	other threads:[~2008-10-06 13: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 [this message]
2008-10-06 16:33                   ` David Brownell
2008-10-07  8:32                     ` Richard Purdie
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=48EA135D.3070104@nokia.com \
    --to=mathias.nyman@nokia.com \
    --cc=felipe.balbi@nokia.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=riku.voipio@iki.fi \
    --cc=rpurdie@rpsys.net \
    --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