[UPSTREAM] Move backlight handling out of pcf50633 driver

[Sean McNeil]

Hi Balaji,

Balaji Rao wrote:
> On Sun, Oct 19, 2008 at 10:24:22AM +0100, Andy Green wrote:
>   
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Somebody in the thread at some point said:
>>
>> Nice work Balaji.
>>
>>     
> Andy,
>
> Thank you.
>   
>> | Can you make the max brightness a #define where it can be an arbitrary
>> | value such as 100 or 255? I'm also curious about suspend/resume ordering
>>
>> This will be more important than it sounds.  How about we ourselves
>> change to 255 as the logical max brightness.  Existing code can find our
>> actual max brightness down /sys and scale accordingly.
>>     
>
> Hmmm.. Are we sure we need to do this ? I'm mildly interested in it
> because the max_brightness is exported as well and any good userspace code
> that tries to control the backlight must read the max_brightness value.
>   

It is unfortunate, but there are still some very high profile software
stacks that assume brightness ranges from 0-255. A smaller amount that
expects 0-100. These will get fixed over time, but it is nice to be able
to specify an arbitrary max value in the kernel and have it scale
appropriately. I can live with just making it a max of 255, though, as
that is what I'm dealing with here.

>> | and turning on the lcd backlight. You need to make sure the lcds are on
>> | before the backlight to prevent white screen flashes and should turn off
>> | backlight before the lcds.
>>
>> Ah Balaji has taken care about it I see, he has added a probe completion
>> callback into mach_gta02.c that creates the backlight device and forces
>> its parent to the jbt6k74.  So if I have it right the full device
>> subtree there is like this
>>
>> i2c bus ->
>> ~  pcf50633 ->
>> ~    Glamo ->
>> ~      Glamo fb ->
>> ~        Glamo SPI bb bus ->
>> ~          jbt6k74 ->
>> ~             backlight
>>
>> That looks great for not only killing races but also avoiding white flash.
>>     
>
> Yes, it helps a great deal. I've found the same patch to break on
> stable-tracking but works perfectly on andy-tracking.
>
> One more thing, I think I noticed  a LEDPWRFAIL interrupt generated
> when the brightness is changed. I think this happens because
> of the led ramp. The output value stays lower than 90% of the target
> value for longer than the debounce time which is 100ms by default.(Table
> 42) So, as I understand, when the led_dimstep has a value of 5, it takes
> about 2.5 ms for the voltage to reach the target. I'm wondering how can
> this happen ? Can anyone shed some light on this ?
>
> 	- Balaji
>