From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [PATCH] radeon: Expose backlight class device for legacy LVDS encoder Date: Wed, 8 Sep 2010 18:03:20 +0100 Message-ID: <20100908170320.GA4888@srcf.ucam.org> References: <1283963539-4039-1-git-send-email-mjg@redhat.com> <1283963539-4039-3-git-send-email-mjg@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from cavan.codon.org.uk (cavan.codon.org.uk [93.93.128.6]) by gabe.freedesktop.org (Postfix) with ESMTP id D233F9E7A6 for ; Wed, 8 Sep 2010 10:03:29 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alex Deucher Cc: Michel =?iso-8859-1?Q?D=E4nzer?= , Michel =?iso-8859-1?Q?D=E4nzer?= , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org 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