From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Tettamanti Subject: Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code Date: Sun, 29 Jul 2012 15:06:44 +0200 Message-ID: <20120729130644.GA12378@growl> References: <1343237889-5220-1-git-send-email-alexdeucher@gmail.com> <20120726125838.GA28853@growl> <20120726193346.GA11288@growl> <20120728145626.GA6304@growl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 0FFD59E812 for ; Sun, 29 Jul 2012 06:06:51 -0700 (PDT) Received: by wgbdr1 with SMTP id dr1so3342207wgb.12 for ; Sun, 29 Jul 2012 06:06:51 -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: Alex Deucher , joeyli , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Sat, Jul 28, 2012 at 05:29:25PM -0400, Alex Deucher wrote: > On Sat, Jul 28, 2012 at 10:56 AM, Luca Tettamanti 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