From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: linux-kernel@vger.kernel.org,
"Michel Dänzer" <michel@daenzer.net>,
dri-devel@lists.freedesktop.org,
"Michel Dänzer" <daenzer@vmware.com>
Subject: Re: [PATCH] radeon: Expose backlight class device for legacy LVDS encoder
Date: Wed, 8 Sep 2010 18:03:20 +0100 [thread overview]
Message-ID: <20100908170320.GA4888@srcf.ucam.org> (raw)
In-Reply-To: <AANLkTi=kDXwRPxfbLv=EGEqARfTkhuhRBrXUL9DOQ_zw@mail.gmail.com>
On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
> The only problem with this is that not all oems use the internal
> backlight controller; systems that don't need to use the acpi methods.
That's why we expose the backlight type. Userspace should use the acpi
or platform mechanism when available, with this being a last-ditch
fallback.
> On atombios systems there is a bit in the
> ATOM_FIRMWARE_CAPABILITY_ACCESS struct in the FirmwareInfo data table
> to determine whether the backlight is controlled by the GPU or some
> external mechanism. Combios may have something similar. If the
> backlight is controlled via the GPU, it can be adjusting using the
> atom OutputControl and TransmitterControl control tables depending on
> the GPU family. However, if the driver chooses to control the
> backlight itself, it needs to set the appropriate bit in the bios
> scratch regs to tell the firmware not to attempt to change the
> backlight itself.
If there's support for probing this more reliably then I'm all for that,
but I'm not keen on taking over control if the BIOS has previous
asserted it.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2010-09-08 17:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-08 16:32 [PATCH] Backlight: Add backlight type Matthew Garrett
2010-09-08 16:32 ` [PATCH] i915: Add native backlight control Matthew Garrett
2010-09-09 17:09 ` [Intel-gfx] " Chris Wilson
2010-09-09 17:14 ` Matthew Garrett
2010-09-10 13:38 ` [PATCH] drm/i915: Expose a native backlight device Chris Wilson
2010-09-10 13:47 ` Matthew Garrett
2010-09-08 16:32 ` [PATCH] radeon: Expose backlight class device for legacy LVDS encoder Matthew Garrett
2010-09-08 16:58 ` Alex Deucher
2010-09-08 17:03 ` Matthew Garrett [this message]
2010-09-08 17:04 ` Alex Deucher
2010-09-13 7:54 ` Michel Dänzer
2010-09-15 11:38 ` Michel Dänzer
2010-09-09 16:59 ` [PATCH] Backlight: Add backlight type Mike Frysinger
2010-11-15 15:48 ` [Intel-gfx] " Matthew Garrett
2010-11-15 16:44 ` Jesse Barnes
2011-03-24 6:53 ` Mike Frysinger
2011-03-24 7:13 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100908170320.GA4888@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=alexdeucher@gmail.com \
--cc=daenzer@vmware.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).