Re: [PATCH] drm/kms: fix fbdev blanking regression

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Tue, 12 Jan 2010 17:28:33 +0000 (GMT)
James Simmons <jsimmons@infradead.org> wrote:

> 
> > On 01/07/2010 12:42 AM, Johan Hovold wrote:
> > >> Yeap. The fix uncovered a bug in your driver. I haven't heard of
> > >> problems with the other drm drivers.
> > >>  
> > >>> The backlight is handled via the DRI driver I assume. At least
> > >>> i9xx_crtc_dpms is called on powerdown.
> > >>
> > >> Can you post your dmesg and kernel config.
> > 
> > [snip]
> > 
> > Adding the Intel DRM people in CC as well. I have the same issue
> > with my GM45.
> 
> Okay I looked at the code to figure out what is happening and why
> only this driver has problems. The problem is that the framebuffer
> layer expects the backlight to be a seperate device. The reason being
> is that some embedded systems will use a gpio backlight. That way
> power management for a graphics card/backlight has 3 seperate states.
> Currently the intel DRM driver treats the backlight as being apart of
> the encoder. Jesse do you have objections to having the intel driver
> expose a backlight device. The bonus of that is the user can also set
> the backlight levels.

On Intel we usually expect the backlight to be exposed by ACPI or a
platform driver.  On recent platforms, the ACPI driver will actually
send requests to the gfx driver to do the actual register writes to
adjust the backlight, but it's still ACPI driven.

Maybe we just need to wire up the fb backlight hooks appropriately?

-- 
Jesse Barnes, Intel Open Source Technology Center