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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100112093454.57176b8c@jbarnes-piketon>
Date:	Tue, 12 Jan 2010 09:34:54 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	James Simmons <jsimmons@...radead.org>
Cc:	David John <davidjon@...ontk.org>,
	Johan Hovold <jhovold@...il.com>,
	Dave Airlie <airlied@...hat.com>,
	dri-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	Eric Anholt <eric@...olt.net>
Subject: Re: [PATCH] drm/kms: fix fbdev blanking regression

On Tue, 12 Jan 2010 17:28:33 +0000 (GMT)
James Simmons <jsimmons@...radead.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/