[PATCH 1/1][Oneiric SRU] Platform: Brightness quirk for samsung laptop driver
seth.forshee at canonical.com
Mon Dec 12 15:11:57 UTC 2011
On Thu, Dec 08, 2011 at 10:36:37AM +0000, Andy Whitcroft wrote:
> On Wed, Dec 07, 2011 at 08:29:07AM -0600, Seth Forshee wrote:
> > I actually tried this as on the NF310 as I occasionally see the first
> > part (setting the brightness to zero) succeed and the second part
> > (setting it to the desired value) fail, so I end up with a brightness of
> > 0. These are pretty rare though; I've only seen them when I'm pounding
> > continuously on the backlight controls.
> > When using the loop you suggested, for whatever reason the value the
> > BIOS returns for the current brightness never changes even though the
> > brightness itself is changing, so the loop never terminates. If you
> > read the brightness later on the value is correct, but as long as you're
> > reading it in that loop the value doesn't change. Bouncing through 0
> > seems to be the most reliable method on these models.
> That almost sounds like gcc is not realising the function is volatile
> and optimising it away. You might want to look at the loop and see if
> the function is being inlined, and whether the optimiser has neutered
> it. Stuffing in a full memory barrier in the loop may get gcc's head in
> the game.
I was pretty sure that wasn't the case, but I went back and
double-checked to be sure. read_brightness is in fact being called for
each loop iteration, but the value it returns doesn't always reflect
the actual brightness (sometimes the loop works, but rarely).
More information about the kernel-team