Re: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger
On Thu, 2011-01-06 at 16:08 +0900, Paul Mundt wrote:
> (Trying an alternate address for Richard, and adding Andrew to Cc..)
>
> On Thu, Dec 09, 2010 at 02:41:50PM +0100, Janusz Krzysztofik wrote:
> > This patch extends the LED backlight tirgger driver with an option that
> > allows
> > for inverting the trigger output polarity.
> >
> > With the invertion option provided, I (ab)use the backlight trigger for
> > driving a LED that indicates LCD display blank condtition on my Amstrad
> > Delta
> > videophone. Since the machine has no dedicated power LED, it was not
> > possible
> > to distinguish if the display was blanked, or the machine was turned off,
> > without touching it.
> >
> > The invert sysfs control is patterned after a similiar function of the GPIO
> > trigger driver.
> >
> > Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
> > Retested on linux-2.6.37-rc4.
> >
> > Signed-off-by: Janusz Krzysztofik
> > Cc: Richard Purdie
Acked-by: Richard Purdie
I'll let Andrew take the patch though.
> > ---
> >
> > Resent because I still can't see any response received, while yet another
> > merge window is going to pass away soon.
> >
> > Applies cleanly on top of 2.6.37-rc4, so no need for yet another refresh.
> > Only
> > tried to clean up the commit message slightly - maybe my English is not
> > good
> > enough to bother with, if not the code?
> >
> > v1 -> v2 changes:
> > - improve some conditional expressions to be more readable; thanks to Ralph
> > Corderoy (from e3-hacking) and Lars-Peter Clausen for their suggestions,
> > - refresh against linux-2.6.36-rc5.
> >
> > drivers/leds/ledtrig-backlight.c | 60
> > ---
> > 1 file changed, 56 insertions(+), 4 deletions(-)
> >
> > diff -upr linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c
> > linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c
> > --- linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c 2010-09-24
> > 15:35:13.0 +0200
> > +++ linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c 2010-10-03
> > 15:59:49.0 +0200
> > @@ -26,6 +26,7 @@ struct bl_trig_notifier {
> > int brightness;
> > int old_status;
> > struct notifier_block notifier;
> > + unsigned invert;
> > };
> >
> > static int fb_notifier_callback(struct notifier_block *p,
> > @@ -36,23 +37,63 @@ static int fb_notifier_callback(struct n
> > struct led_classdev *led = n->led;
> > struct fb_event *fb_event = data;
> > int *blank = fb_event->data;
> > + int new_status = *blank ? BLANK : UNBLANK;
> >
> > switch (event) {
> > case FB_EVENT_BLANK :
> > - if (*blank && n->old_status == UNBLANK) {
> > + if (new_status == n->old_status)
> > + break;
> > +
> > + if ((n->old_status == UNBLANK) ^ n->invert) {
> > n->brightness = led->brightness;
> > led_set_brightness(led, LED_OFF);
> > - n->old_status = BLANK;
> > - } else if (!*blank && n->old_status == BLANK) {
> > + } else {
> > led_set_brightness(led, n->brightness);
> > - n->old_status = UNBLANK;
> > }
> > +
> > + n->old_status = new_status;
> > +
> > break;
> > }
> >
> > return 0;
> > }
> >
> > +static ssize_t bl_trig_invert_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct led_classdev *led = dev_get_drvdata(dev);
> > + struct bl_trig_notifier *n = led->trigger_data;
> > +
> > + return sprintf(buf, "%s\n", n->invert ? "yes" : "no");
> > +}
> > +
> > +static ssize_t bl_trig_invert_store(struct device *dev,
> > + struct device_attribute *attr, const char *buf, size_t num)
> > +{
> > + struct led_classdev *led = dev_get_drvdata(dev);
> > + struct bl_trig_notifier *n = led->trigger_data;
> > + unsigned invert;
> > + int ret;
> > +
> > + ret = sscanf(buf, "%u", &invert);
> > + if (ret < 1) {
> > + dev_err(dev, "invalid value\n");
> > + return -EINVAL;
> > + }
> > +
> > + n->invert = !!invert;
>
RE: [PATCH] Backlight driver for omap3evm
On Tue, 2009-02-10 at 22:52 +0530, Hiremath, Vaibhav wrote:
> [Hiremath, Vaibhav] Now I will be following up for OMAP3EVM backlight
> driver patch initiated/posted by Sanjeev. I was just referring to the
> backlight drives currently available under Linux tree, and observed
> that almost all drivers have been implemented in different way. I
> could not able to get one driver to which I can refer to for adding
> support for OMAP3EVM backlight driver.
>
> Can anybody tell me the expected way of implementation for backlight driver
> is?
>
> I have some questions here,
>
> - If I understand correctly (and as mentioned and pointed out by
> Richard in the mail-chain), platform_device should get added in
> platform file where it registers the pointer to the structure "struct
> generic_bl_info".
> This I believe should be standard way everybody should follow, which
> is not the case.
> Am I missing something here?
>
> - The below question may sound foolish, but to is important for me to
> understand the framework.
>
> If I have simple and straight control of backlight, do I really
> required to have separate backlight driver for my platform? Can I make
> use of generic-bl driver?
> The only difference (atleast to my platform) would be the SYSFS entry,
> the entry will get created something like
> /sys/class/backlight/generic-bl/
>
> Is it required to make driver, Power aware and differentiate from generic
> driver?
You should be able to make the driver power aware and still use the
generic driver.
The basic idea is that your platform would register a platform device
and some code to control the backlight, e.g.:
void omap_set_bl_intensity(int X)
{
/* Code to set backlight intensity to X */
}
static struct generic_bl_info bl_platform_data = {
.name = "omap-bl",
.max_intensity = 5,
.default_intensity = 2,
.set_bl_intensity = omap_set_bl_intensity,
};
static struct platform_device backlight_device = {
.name = "generic-bl",
.id = -1,
.dev.platform_data = &bl_platform_data,
};
and that should be all you need as the core class and generic-bl code
will take care of most other things for you. The code above would go
somewhere in arch/arm/mach-omap*/.
If any improvements are needed to generic-bl to make it useful, please
let me know (set_bl_intensity could maybe do with being passed more
information).
Regards,
Richard
--
Richard Purdie
Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Backlight driver for omap3evm
On Wed, 2009-01-07 at 20:25 +0530, Sanjeev Premi wrote: > This patch implements the backlight driver for OMAP3EVM. > The mechanism for backlight control is reused from the > existing controls in lcd_omap3evm.c. Please see the reply to the email you sent me offlist. What happens when you run this driver on something that isn't an omap3evm? The problem is that this bit: omap_backlight_dev = platform_device_alloc(OMAPBL_DEVNAME, -1); should be done in the platform code for the board, not in the general driver. If you do that, you should be able to reuse most of the generic-bl device code. Regards, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query on backlight driver
On Wed, 2009-01-07 at 01:46 +0530, Premi, Sanjeev wrote: > I have implemented a basic backlight driver for OMAP3EVM (patch below). > > However, have been having few problems. Any suggestions would be useful. > > 1) Though build was successful; the print from the backlight driver did >not appear during the kernel boot. Your patch adds the platform driver but do you have a corresponding platform device? Also, please do not just copy the corgibl file, just install a corresponding platform device and reuse the existing corgibl driver instead. For reference, corgibl will be renamed genericbl soon to make it clearer that its actually generic code that can be reused. Regards, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lp5521: move to drivers/leds
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
