On Thu, 17 Nov 2011 17:33:50 +0100, Takashi Iwai <tiwai at suse.de> wrote: > If it's only with 915GM, we'll just need to change IS_PINEVEW() to > IS_PINEVIEW() || IS_I915GM(). This might be a safer option at this > moment unless we check all cases or specs... I read through the hardware docs yesterday and figured out what was going on. On all pre-gen4 hardware, the maximum backlight value has the lowest bit (of 16) hard-wired to zero. This means that the possible backlight duty cycle values are limited to 0 .. 0xfffe. On older hardware, this was managed by reporting this true range. This meant that the set_backlight path didn't need any special code; simply setting the values as provided should have worked just fine. On Pineview, this was changed (for reasons unknown) to use only 15 bits for backlight levels. The range of possible values is then 0 .. 0x7fff. In this case, values have to be shifted by one to convert between the advertised range of 0 .. 0x7fff and the hardware range of 0 .. 0xfffe. Exposing the range of 0 .. 0xfffe introduces a potential problem -- write a value of 0xffff and the hardware gets mightily confused, and probably ends up turning the backlight off. Using the range of 0 .. 0x7fff avoids this issue completely. Using the narrower range does limit the precision of the backlight level setting, but it seems like 32767 possible values is more than sufficient... Here's a patch which just uses the pineview version everywhere (and cleans that up at the same time).
