[UPSTREAM] Move backlight handling out of pcf50633 driver

Andy Green andy at openmoko.com
Mon Oct 20 06:21:56 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|> With Andy's suggestion to also change the default max value, things
|> get worse, because this also breaks code that thinks it knows the max
|> value and scales accordingly. This code currently works, even though
|> it takes an unsafe shortcut.

Yeah that broken code needs to use the already provided max value.  What
do you mean "worse"?  The proposed bad code you're talking about won't
survive us changing PMU or working on a different phone with another PMU
that has different scaling.  When fixed, it is independent of what it's
running on, that's "worse"?

| This is the best reasoning I've seen to leave the value as-is. Thanks,

No the best reasoning was "it ain't broken so don't break it" from
Mickey, but there are reasons for this.

| Werner, for your insight. I still wouldn't mind a #define so it can be
| adjusted in the kernel in 1 place if necessary, but I'd have to say
| unilaterally changing to 0-255 is probably not a good idea as stated

First getting our stock kernel to do what you need here is very
important for us for reasons that will become clear later.

Second, I know you changed this to 0 - 255 in a patch you held locally
for a long while...  Did any of these scare stories actually occur?  I
seem to recall there is an actual_brightness in there as well, if it
does what I think it does I don't see why any code using all the
information provided by the standard Linux backlight implementation
correctly would break.

Balaji, if you have some interest and time, please implement this 0-255
in a patch and give it some small tries down /sys and see what the facts

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list