drm/radeon: add new AMD ACPI header and update relevant code

Commit Message

Alex Deucher July 26, 2012, 3:35 p.m. UTC

On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti <[e-mail]> wrote:
> On Wed, Jul 25, 2012 at 01:38:09PM -0400, [e-mail] wrote:
>> From: Alex Deucher <[e-mail]>
>>
>> Add a new header that defines the AMD ACPI interface used
>> for laptops, PowerXpress, and chipset specific functionality
>> and update the current code to use it.
>
> Great! Now my DSDT makes sense ;)
>
>> Todo:
>> - properly verify the ACPI interfaces
>> - hook up and handle ACPI notifications
>
> I see a problem here, I've hacked up a standalone test module, but:
>
>> +#define ATIF_FUNCTION_GET_SYSTEM_PARAMETERS                        0x1
> [...]
>> + * flags
>> + * bits 1:0:
>> + * 0 - Notify(VGA, 0x81) is not used for notification
>> + * 1 - Notify(VGA, 0x81) is used for notification
>
> My system has this bit set, and the brightness control method does send
> the notification.
> My module register itself with register_acpi_notifier and gets 2
> notifications, one with ACPI_VIDEO_NOTIFY_PROBE (0x81) and the other
> with ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS (or DEC, depending on what I
> press).
>
> The standard acpi "video" module, however, in response to
> ACPI_VIDEO_NOTIFY_PROBE generates a key press sending
> KEY_SWITCHVIDEOMODE.
>
> This greatly confuses KDE which messes up my dual screen configuration;
> I guess that the spurious KEY_SWITCHVIDEOMODE may be problematic also
> with other DEs...
>
> In more detail what happens is the following:
> - I press the brightness hotkey, firmware generates a notification on
>   the relevant device (_SB.PCI0.PEG0.VGA.LCD)
> - ACPI video module gets the ACPI_VIDEO_NOTIFY_{DEC,INC}_BRIGHTNESS
>   notification and tries to adjust the brightness with
>   acpi_video_device_lcd_set_level, which in turns calls _BCM
> - _BCM sets the relevant bits in the AMD-specific structure and does a
>   Notify (VGA, 0x81)
> - again ACPI video module gets the nodification (in this case
>   ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE
> - KDE seems this and muck with the screen configuration :(
> - meanwhile the brightness notification is propagated, the hypothetical
>   radeon driver does its magic to adjust the screen.
>
> My first idea would be to make ACPI_VIDEO_NOTIFY_PROBE also call to the
> acpi notifier chain, and allow the handlers to veto the key press (like
> it's done for ACPI_VIDEO_NOTIFY_SWITCH).
>
> Zhang Rui what do you think about this?
>
> The other missing bit is how to actually change the brightness... Alex,
> do you know what registers to poke?

You need to check if the GPU controls the backlight or the system
does.  I think the attached patches should point you in the right
direction.

Alex

>
> My card is a:
>
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Thames XT/GL [Radeon HD 600M Series] [1002:6840]
>
> on a Toshiba L855.
>
> Luca

Comments

Luca Tettamanti July 26, 2012, 7:33 p.m. UTC | #1

On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti <[e-mail]> wrote:
> > The other missing bit is how to actually change the brightness... Alex,
> > do you know what registers to poke?
> 
> You need to check if the GPU controls the backlight or the system
> does.  I think the attached patches should point you in the right
> direction.

Yep :)

0050:  ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability :
  0050:  (union) ATOM_FIRMWARE_CAPABILITY sbfAccess          :
    USHORT GPUControlsBL:1                              = 0x0001     (1)

The panel is using the INTERNAL_UNIPHY encoder, and I see the
UNIPHYTransmitterControl command table.

Interaction with video.ko is still a bit messy...

Do you already have code for handling the notifications? I'll work on it
in the weekend otherwise ;)

Luca

Alex Deucher July 26, 2012, 7:42 p.m. UTC | #2

On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti <[e-mail]> wrote:
> On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
>> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti <[e-mail]> wrote:
>> > The other missing bit is how to actually change the brightness... Alex,
>> > do you know what registers to poke?
>>
>> You need to check if the GPU controls the backlight or the system
>> does.  I think the attached patches should point you in the right
>> direction.
>
> Yep :)
>
> 0050:  ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability :
>   0050:  (union) ATOM_FIRMWARE_CAPABILITY sbfAccess          :
>     USHORT GPUControlsBL:1                              = 0x0001     (1)
>
> The panel is using the INTERNAL_UNIPHY encoder, and I see the
> UNIPHYTransmitterControl command table.
>
> Interaction with video.ko is still a bit messy...
>
> Do you already have code for handling the notifications? I'll work on it
> in the weekend otherwise ;)

I don't have patches for that.  Please feel free to work on it :)

Thanks,

Alex

Alex Deucher July 26, 2012, 7:58 p.m. UTC | #3

On Thu, Jul 26, 2012 at 3:42 PM, Alex Deucher <[e-mail]> wrote:
> On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti <[e-mail]> wrote:
>> On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
>>> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti <[e-mail]> wrote:
>>> > The other missing bit is how to actually change the brightness... Alex,
>>> > do you know what registers to poke?
>>>
>>> You need to check if the GPU controls the backlight or the system
>>> does.  I think the attached patches should point you in the right
>>> direction.
>>
>> Yep :)
>>
>> 0050:  ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability :
>>   0050:  (union) ATOM_FIRMWARE_CAPABILITY sbfAccess          :
>>     USHORT GPUControlsBL:1                              = 0x0001     (1)
>>
>> The panel is using the INTERNAL_UNIPHY encoder, and I see the
>> UNIPHYTransmitterControl command table.
>>
>> Interaction with video.ko is still a bit messy...
>>
>> Do you already have code for handling the notifications? I'll work on it
>> in the weekend otherwise ;)
>
> I don't have patches for that.  Please feel free to work on it :)

One thing worth checking, the sbios may write the requested backlight
level to the bios scratch reg, in which case the driver only has to
execute the BL_BRIGHTNESS action rather than writing the requested
level to the register first.

Alex

>
> Thanks,
>
> Alex

Luca Tettamanti July 28, 2012, 2:56 p.m. UTC | #4

On Thu, Jul 26, 2012 at 03:42:26PM -0400, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti <[e-mail]> wrote:
> > On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
> >> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti <[e-mail]> wrote:
> >> > The other missing bit is how to actually change the brightness... Alex,
> >> > do you know what registers to poke?
> >>
> >> You need to check if the GPU controls the backlight or the system
> >> does.  I think the attached patches should point you in the right
> >> direction.
> >
> > Yep :)
> >
> > 0050:  ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability :
> >   0050:  (union) ATOM_FIRMWARE_CAPABILITY sbfAccess          :
> >     USHORT GPUControlsBL:1                              = 0x0001     (1)
> >
> > The panel is using the INTERNAL_UNIPHY encoder, and I see the
> > UNIPHYTransmitterControl command table.
> >
> > Interaction with video.ko is still a bit messy...
> >
> > Do you already have code for handling the notifications? I'll work on it
> > in the weekend otherwise ;)
> 
> I don't have patches for that.  Please feel free to work on it :)

I just found the first problem (probably a BIOS bug):
ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
I intended to use the method to set up the notification handler but now
my BIOS says that it's not there even if it is...
Can I assume some default values (e.g. notifications are enabled and will
use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
different)?

thanks,
Luca

Alex Deucher July 28, 2012, 9:29 p.m. UTC | #5

On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti <[e-mail]> wrote:
> On Thu, Jul 26, 2012 at 03:42:26PM -0400, Alex Deucher wrote:
>> On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti <[e-mail]> wrote:
>> > On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
>> >> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti <[e-mail]> wrote:
>> >> > The other missing bit is how to actually change the brightness... Alex,
>> >> > do you know what registers to poke?
>> >>
>> >> You need to check if the GPU controls the backlight or the system
>> >> does.  I think the attached patches should point you in the right
>> >> direction.
>> >
>> > Yep :)
>> >
>> > 0050:  ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability :
>> >   0050:  (union) ATOM_FIRMWARE_CAPABILITY sbfAccess          :
>> >     USHORT GPUControlsBL:1                              = 0x0001     (1)
>> >
>> > The panel is using the INTERNAL_UNIPHY encoder, and I see the
>> > UNIPHYTransmitterControl command table.
>> >
>> > Interaction with video.ko is still a bit messy...
>> >
>> > Do you already have code for handling the notifications? I'll work on it
>> > in the weekend otherwise ;)
>>
>> I don't have patches for that.  Please feel free to work on it :)
>
> I just found the first problem (probably a BIOS bug):
> ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
> corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
> I intended to use the method to set up the notification handler but now
> my BIOS says that it's not there even if it is...
> Can I assume some default values (e.g. notifications are enabled and will
> use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
> different)?

The spec says that the bits in the supported functions vector mean
that if bit n is set, function n+1 exists, but it's possible that the
spec is wrong and it's actually a 1 to 1 mapping; if bit n is set,
function n is supported.  In which case the the supported functions
vector bits should be:
+/* supported functions vector */
+#       define ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED               (1 << 1)
+#       define ATIF_GET_SYSTEM_BIOS_REQUESTS_SUPPORTED            (1 << 2)
+#       define ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED              (1 << 3)
+#       define ATIF_GET_LID_STATE_SUPPORTED                       (1 << 4)
+#       define ATIF_GET_TV_STANDARD_FROM_CMOS_SUPPORTED           (1 << 5)
+#       define ATIF_SET_TV_STANDARD_IN_CMOS_SUPPORTED             (1 << 6)
+#       define ATIF_GET_PANEL_EXPANSION_MODE_FROM_CMOS_SUPPORTED  (1 << 7)
+#       define ATIF_SET_PANEL_EXPANSION_MODE_IN_CMOS_SUPPORTED    (1 << 8)
+#       define ATIF_TEMPERATURE_CHANGE_NOTIFICATION_SUPPORTED     (1 << 13)
+#       define ATIF_GET_GRAPHICS_DEVICE_TYPES_SUPPORTED           (1 << 15)

See if that lines up better.  I'm still new to these ACPI interfaces
so I'm not an expert yet.

Alex

Luca Tettamanti July 29, 2012, 1:06 p.m. UTC | #6

On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti <[e-mail]> wrote:
> > I just found the first problem (probably a BIOS bug):
> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
> > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
> > I intended to use the method to set up the notification handler but now
> > my BIOS says that it's not there even if it is...
> > Can I assume some default values (e.g. notifications are enabled and will
> > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
> > different)?
> 
> The spec says that the bits in the supported functions vector mean
> that if bit n is set, function n+1 exists, 

Hum, I don't follow. The vector in my case is 0x2 (1 << 1), that would
mean that ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED (1 << 2) is supported?

Maybe if the bit n is set then functions 0..n are available? That would
(almost) match what I see...

> but it's possible that the
> spec is wrong and it's actually a 1 to 1 mapping; if bit n is set,
> function n is supported.  In which case the the supported functions
> vector bits should be:
> +/* supported functions vector */
> +#       define ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED               (1 << 1)
> +#       define ATIF_GET_SYSTEM_BIOS_REQUESTS_SUPPORTED            (1 << 2)
> +#       define ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED              (1 << 3)
> +#       define ATIF_GET_LID_STATE_SUPPORTED                       (1 << 4)
> +#       define ATIF_GET_TV_STANDARD_FROM_CMOS_SUPPORTED           (1 << 5)
> +#       define ATIF_SET_TV_STANDARD_IN_CMOS_SUPPORTED             (1 << 6)
> +#       define ATIF_GET_PANEL_EXPANSION_MODE_FROM_CMOS_SUPPORTED  (1 << 7)
> +#       define ATIF_SET_PANEL_EXPANSION_MODE_IN_CMOS_SUPPORTED    (1 << 8)
> +#       define ATIF_TEMPERATURE_CHANGE_NOTIFICATION_SUPPORTED     (1 << 13)
> +#       define ATIF_GET_GRAPHICS_DEVICE_TYPES_SUPPORTED           (1 << 15)
> 
> See if that lines up better. 

Not really... the value returned by VERIFY_INTERFACE is 0x2, but in the
DSDT I see:

ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS
ATIF_FUNCTION_GET_TV_STANDARD_FROM_CMOS
ATIF_FUNCTION_SET_TV_STANDARD_IN_CMOS

The implementation of the first one makes sense, the second is used for
brightness control. The other two _might_ be a leftover (the machine
does not have an analog TV out).

> I'm still new to these ACPI interfaces
> so I'm not an expert yet.

I've been exposed to a lot of ACPI code (I wrote the asus_atk0110
driver), in my experience the DSDT is full of crap: code copied&pasted
from other machines, leftover no longer used, and other stuff that's
plainly wrong.

Luca

Luca Tettamanti July 29, 2012, 1:10 p.m. UTC | #7

On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
> Hi Luca, 
> 
> ? ??2012-07-28 ? 16:56 +0200?Luca Tettamanti ???
> > I just found the first problem (probably a BIOS bug):
> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
> > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
> > I intended to use the method to set up the notification handler but now
> > my BIOS says that it's not there even if it is...
> > Can I assume some default values (e.g. notifications are enabled and will
> > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
> > different)?
> > 
> 
> Did you check your DSDT for there have some "Notify (VGA, 0x81)"
> statement in AFN0..AFN15?
> If YES, I think that means your machine in case the 0x81 is for ATI used
> by default.

Yes, my point is that the nofication is there, but since
GET_SYSTEM_PARAMETERS is not announced I have not way to check it.
IOW, what is implemented in the DSDT does not match what is announced by
VERIFY_INTERFACE.
For reference this is the DSDT: http://pastebin.com/KKS7ZsTt

Luca

Luca Tettamanti July 30, 2012, 2:16 p.m. UTC | #8

On Mon, Jul 30, 2012 at 04:32:47PM +0800, joeyli wrote:
> ? ??2012-07-29 ? 15:10 +0200?Luca Tettamanti ???
> > On Sun, Jul 29, 2012 at 11:51:48AM +0800, joeyli wrote:
> > > Hi Luca, 
> > > 
> > > ? ??2012-07-28 ? 16:56 +0200?Luca Tettamanti ???
> > > > I just found the first problem (probably a BIOS bug):
> > > > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
> > > > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
> > > > I intended to use the method to set up the notification handler but now
> > > > my BIOS says that it's not there even if it is...
> > > > Can I assume some default values (e.g. notifications are enabled and will
> > > > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
> > > > different)?
> > > > 
> > > 
> > > Did you check your DSDT for there have some "Notify (VGA, 0x81)"
> > > statement in AFN0..AFN15?
> > > If YES, I think that means your machine in case the 0x81 is for ATI used
> > > by default.
> > 
> > Yes, my point is that the nofication is there, but since
> > GET_SYSTEM_PARAMETERS is not announced I have not way to check it.
> > IOW, what is implemented in the DSDT does not match what is announced by
> > VERIFY_INTERFACE.
> > For reference this is the DSDT: http://pastebin.com/KKS7ZsTt
> > 
> > Luca
> > 
> 
> Yes, saw the problem in your DSDT:
> 
>         Method (AF00, 0, NotSerialized)
>         {
>             CreateWordField (ATIB, Zero, SSZE)
> 		...
>             Store (0x80, NMSK)
>             Store (0x02, SFUN)		<=== 10b, bit 0 is 0
>             Return (ATIB)
>         }
> 
> But, AF01 still supported in ATIF on this machine, maybe we should still
> try GET_SYSTEM_PARAMETERS even the function vector set to 0?
> No idea...

That's what I'm doing right now... if SBIOS_REQUESTS is supported I try
and call GET_SYSTEM_PARAMETERS even if it's not announced.

> On the other hand, 
> My patch to avoid 0x81 event conflict with acpi/video driver like below.
> This patch woks on my notebook. Your patches do much more things then
> mine, so I think my patch just for reference.  

I ignored the event handling for now... I'd like to hear something back
from ACPI camp before committing to this solution.

> There have a problem is:
> If we want use acpi_notifier_call_chain to check does event consume by
> any notifier in acpi's blocking notifier chain, then we need return
> NOTIFY_BAD in radeon_acpi but not NOTIFY_OK.
> 
> So, I suggest radeon_acpi should register to acpi notifier chain by
> itself but not append on radeon_acpi_event in radeon_pm. 

It shouldn't matter, once I change radeon_atif_handler to return
NOTIFY_BAD the call chain will be stopped anyway.

> And,
> suggest also check the device class is ACPI_VIDEO_CLASS like following:
> 
> +static int radeon_acpi_video_event(struct notifier_block *nb,
> ...
> +	if (strcmp(event->device_class, ACPI_VIDEO_CLASS) != 0)
> +		return NOTIFY_DONE;
> +

Will do. I'll use the package structs in the next iteration.

Luca

Alex Deucher July 30, 2012, 2:20 p.m. UTC | #9

On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti <[e-mail]> wrote:
> On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote:
>> On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti <[e-mail]> wrote:
>> > I just found the first problem (probably a BIOS bug):
>> > ATIF_FUNCTION_GET_SYSTEM_PARAMETERS is implemented in the DSDT, but the
>> > corresponding bit ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED is not set :(
>> > I intended to use the method to set up the notification handler but now
>> > my BIOS says that it's not there even if it is...
>> > Can I assume some default values (e.g. notifications are enabled and will
>> > use 0x81 unless ATIF_FUNCTION_GET_SYSTEM_PARAMETERS says something
>> > different)?
>>
>> The spec says that the bits in the supported functions vector mean
>> that if bit n is set, function n+1 exists,
>
> Hum, I don't follow. The vector in my case is 0x2 (1 << 1), that would
> mean that ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED (1 << 2) is supported?
>
> Maybe if the bit n is set then functions 0..n are available? That would
> (almost) match what I see...

From the spec:

Supported     DWORD Bit vector providing supported functions
information. Each bit marks
Functions Bit              support for one specific function of the
ATIF method. Bit n, if set,
Vector                        indicates that Function n+1 is supported.

I don't know how wonky bioses in the wild are however.  I can see what
our internal teams do in these sort of cases.

>
>> but it's possible that the
>> spec is wrong and it's actually a 1 to 1 mapping; if bit n is set,
>> function n is supported.  In which case the the supported functions
>> vector bits should be:
>> +/* supported functions vector */
>> +#       define ATIF_GET_SYSTEM_PARAMETERS_SUPPORTED               (1 << 1)
>> +#       define ATIF_GET_SYSTEM_BIOS_REQUESTS_SUPPORTED            (1 << 2)
>> +#       define ATIF_SELECT_ACTIVE_DISPLAYS_SUPPORTED              (1 << 3)
>> +#       define ATIF_GET_LID_STATE_SUPPORTED                       (1 << 4)
>> +#       define ATIF_GET_TV_STANDARD_FROM_CMOS_SUPPORTED           (1 << 5)
>> +#       define ATIF_SET_TV_STANDARD_IN_CMOS_SUPPORTED             (1 << 6)
>> +#       define ATIF_GET_PANEL_EXPANSION_MODE_FROM_CMOS_SUPPORTED  (1 << 7)
>> +#       define ATIF_SET_PANEL_EXPANSION_MODE_IN_CMOS_SUPPORTED    (1 << 8)
>> +#       define ATIF_TEMPERATURE_CHANGE_NOTIFICATION_SUPPORTED     (1 << 13)
>> +#       define ATIF_GET_GRAPHICS_DEVICE_TYPES_SUPPORTED           (1 << 15)
>>
>> See if that lines up better.
>
> Not really... the value returned by VERIFY_INTERFACE is 0x2, but in the
> DSDT I see:
>
> ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
> ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS
> ATIF_FUNCTION_GET_TV_STANDARD_FROM_CMOS
> ATIF_FUNCTION_SET_TV_STANDARD_IN_CMOS
>
> The implementation of the first one makes sense, the second is used for
> brightness control. The other two _might_ be a leftover (the machine
> does not have an analog TV out).

Yeah, probably unless there is a TV-out on a docking station or
something like that.  The TV-out port should show up in the connector
table in the vbios even if it has a port on the docking station
however.

Alex

Patch

From a56ac560e34032ca803e0909c8a92a9037046790 Mon Sep 17 00:00:00 2001
From: Alex Deucher <[e-mail]>
Date: Thu, 26 Jul 2012 09:50:57 -0400
Subject: [PATCH 1/3] drm/radeon: track whether the GPU controls the backlight

A table in the vbios tells us whether the GPU backlight controller
is used or not.  If the bit is set, the GPU backlight controller is
used; if it is not set, an off-chip backlight controller is used.

Signed-off-by: Alex Deucher <[e-mail]>
---
 drivers/gpu/drm/radeon/radeon_atombios.c |    4 ++++
 drivers/gpu/drm/radeon/radeon_mode.h     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c
index b1e3820..92267a8 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -1254,6 +1254,10 @@  bool radeon_atom_get_clock_info(struct drm_device *dev)
 		if (rdev->clock.max_pixel_clock == 0)
 			rdev->clock.max_pixel_clock = 40000;
 
+		/* not technically a clock, but... */
+		if (firmware_info->info.usFirmwareCapability.sbfAccess.GPUControlsBL)
+			rdev->mode_info.gpu_controls_bl = true;
+
 		return true;
 	}
 
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h
index f380d59..33cbf97 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -252,6 +252,8 @@  struct radeon_mode_info {
 
 	/* pointer to fbdev info structure */
 	struct radeon_fbdev *rfbdev;
+	/* GPU controls backlight */
+	bool gpu_controls_bl;
 };
 
 #define MAX_H_CODE_TIMING_LEN 32
-- 
1.7.7.5