From patchwork Thu Jul 26 15:35:25 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Deucher X-Patchwork-Id: 1243261 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork1.kernel.org (Postfix) with ESMTP id 4DFD23FC5A for ; Thu, 26 Jul 2012 15:35:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1D43CA0E5A for ; Thu, 26 Jul 2012 08:35:41 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by gabe.freedesktop.org (Postfix) with ESMTP id E3B77A0E58 for ; Thu, 26 Jul 2012 08:35:26 -0700 (PDT) Received: by weyr3 with SMTP id r3so1563688wey.36 for ; Thu, 26 Jul 2012 08:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dMpryfZdV5Pi+gwObOIj/USABXCD0g5fd2XLqwKnO8=; b=AYGt5osaUxk1jbF6kHJJZKJwUAb5GHzI3v5cQC7ZjWqY8XTS1ZnlTrvnmSJ72oGp2v 8VBvPi9kUK/qt1mWuySVex38JoamvFYyyvoIhlAxWdAtvLJgDBYuQrn6y8+zdiyIGqj+ 1PSjWDwolTISvR/1cw+QigqWfqi1Fg108Z2sMWwF78v59lnB6dtt+PZG7xLlbiA0/L/z 2KCsLYqsEzsrGhwo+o5iRbzZFtZS/bqtvT41XpoEUmiRC6bSYxRPWaWd5XPCXd2KXoob BKJz6hdSXGT3idTFwM2CcWE6PfjSy8EDDnSnO623xlTOvrujg09eCfxNi0fWrpMcXGmI Fycg== MIME-Version: 1.0 Received: by 10.180.83.106 with SMTP id p10mr14388909wiy.21.1343316926080; Thu, 26 Jul 2012 08:35:26 -0700 (PDT) Received: by 10.227.202.80 with HTTP; Thu, 26 Jul 2012 08:35:25 -0700 (PDT) In-Reply-To: <20120726125838.GA28853@growl> References: <1343237889-5220-1-git-send-email-alexdeucher@gmail.com> <20120726125838.GA28853@growl> Date: Thu, 26 Jul 2012 11:35:25 -0400 Message-ID: Subject: Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code From: Alex Deucher To: Luca Tettamanti Cc: Alex Deucher , linux-acpi@vger.kernel.org, Zhang Rui , dri-devel@lists.freedesktop.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org Errors-To: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti wrote: > On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeucher@gmail.com wrote: >> From: Alex Deucher >> >> 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 From a56ac560e34032ca803e0909c8a92a9037046790 Mon Sep 17 00:00:00 2001 From: Alex Deucher 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 --- 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