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 >
