linux-kernel - Re: [PATCH] leds: driver for ab5500 high voltage leds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 14 Dec 2011 19:34:50 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Shreshtha Kumar SAHU <shreshthakumar.sahu@...ricsson.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Denis Kuzmenko <linux@...onet.org.ua>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	Richard Purdie <rpurdie@...ys.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: [PATCH] leds: driver for ab5500 high voltage leds

On Wed, Dec 14, 2011 at 3:01 PM, Shreshtha Kumar SAHU
<shreshthakumar.sahu@...ricsson.com> wrote:

> I will try to implement this. In AB5500, PWM provides 1024 steps from 0 to
> full current, and current 16 steps from 2.5mA to 40mA. I need to derive a
> way to optmially change both PWM and current to get requested brigtness in
> range of 0-255 (i.e. LED_OFF to LED_FULL).
> Bur I fear that changing both PWM and current may lead to non linear
> variation and equation needs to be derived to get it correct which will
> add complexity to ab5500_led_brightness_set and hence API brightness.
> In addition if platform sets max current to 10mA then brightness_set()
> will have only 4 steps for current variation and in thus an overhead if
> we combined current and PWM control calculation.

Don't fear this, it sounds like fun to me :-D

A simple linearization table with 256 steps 0.255 vs corresponding
16-bit max current and PWM settings could hide all the complexity
we have I guess?

Like

struct hvled_linearization {
    u16 i_max;
    u16 fade_hi;
    u16 fade_lo;
};

#define LIN_TAB_ENTRY(a, b, c) { .i_max = a, .fade_hi = b, fade_lo = c }

struct hvled_linearization lin_table[] = {
    LIN_TAB_ENTRY(0, 0, 0),
    ... insert the hard part here ;-) ...
    LIN_TAB_ENTRY(65535, 65535, 65535),
};

The problem is I think this table is dependent on the LED fitted
and needs to be supplied as platform data from the board,
which knows which LED is on that board.

Methods to generate table is reading the LED data sheet
(if you have it) or using a photometric instrument while locking
yourself in a totally dark room. (This is the fun part...)
http://en.wikipedia.org/wiki/Photometer

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/