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

Alex Deucher alexdeucher at gmail.com
Mon Jul 30 07:20:15 PDT 2012


On Sun, Jul 29, 2012 at 9:06 AM, Luca Tettamanti <kronos.it at gmail.com> 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 <kronos.it at gmail.com> 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


More information about the dri-devel mailing list