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

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

[Luca Tettamanti]

On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeucher@gmail.com wrote:
> From: Alex Deucher <alexander.deucher@amd.com>
> 
> 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?

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

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

[Alex Deucher]

[-- Attachment #1: Type: text/plain, Size: 2892 bytes --]

On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti <kronos.it@gmail.com> wrote:
> On Wed, Jul 25, 2012 at 01:38:09PM -0400, alexdeucher@gmail.com wrote:
>> From: Alex Deucher <alexander.deucher@amd.com>
>>
>> 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

[-- Attachment #2: 0003-drm-radeon-add-backlight-control-for-atom-devices.patch --]
[-- Type: text/x-patch, Size: 10963 bytes --]

From 31f6dff07ecb4cf092292345405b2151c98f0504 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
Date: Thu, 26 Jul 2012 11:32:03 -0400
Subject: [PATCH 3/3] drm/radeon: add backlight control for atom devices

On systems that use the build in GPU backlight controller,
we can use atom tables to change the brightness level.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
 drivers/gpu/drm/radeon/atombios_encoders.c |  231 ++++++++++++++++++++++++++++
 drivers/gpu/drm/radeon/radeon_connectors.c |   15 --
 drivers/gpu/drm/radeon/radeon_encoders.c   |   18 ++-
 3 files changed, 248 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index 7dfc62f..60c86ce 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -28,9 +28,238 @@
 #include "radeon_drm.h"
 #include "radeon.h"
 #include "atom.h"
+#include <linux/backlight.h>
 
 extern int atom_debug;
 
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+
+static u8
+radeon_atom_get_backlight_level_from_reg(struct radeon_device *rdev)
+{
+	u8 backlight_level;
+	u32 bios_2_scratch;
+
+	if (rdev->family >= CHIP_R600)
+		bios_2_scratch = RREG32(R600_BIOS_2_SCRATCH);
+	else
+		bios_2_scratch = RREG32(RADEON_BIOS_2_SCRATCH);
+
+	backlight_level = ((bios_2_scratch & ATOM_S2_CURRENT_BL_LEVEL_MASK) >>
+			   ATOM_S2_CURRENT_BL_LEVEL_SHIFT);
+
+	return backlight_level;
+}
+
+static void
+radeon_atom_set_backlight_level_to_reg(struct radeon_device *rdev,
+				       u8 backlight_level)
+{
+	u32 bios_2_scratch;
+
+	if (rdev->family >= CHIP_R600)
+		bios_2_scratch = RREG32(R600_BIOS_2_SCRATCH);
+	else
+		bios_2_scratch = RREG32(RADEON_BIOS_2_SCRATCH);
+
+	bios_2_scratch &= ~ATOM_S2_CURRENT_BL_LEVEL_MASK;
+	bios_2_scratch |= ((backlight_level << ATOM_S2_CURRENT_BL_LEVEL_SHIFT) &
+			   ATOM_S2_CURRENT_BL_LEVEL_MASK);
+
+	if (rdev->family >= CHIP_R600)
+		WREG32(R600_BIOS_2_SCRATCH, bios_2_scratch);
+	else
+		WREG32(RADEON_BIOS_2_SCRATCH, bios_2_scratch);
+}
+
+static void
+atombios_set_panel_brightness(struct radeon_encoder *radeon_encoder)
+{
+	struct drm_encoder *encoder = &radeon_encoder->base;
+	struct drm_device *dev = radeon_encoder->base.dev;
+	struct radeon_device *rdev = dev->dev_private;
+	struct radeon_encoder_atom_dig *dig;
+	DISPLAY_DEVICE_OUTPUT_CONTROL_PS_ALLOCATION args;
+	int index;
+
+	if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
+		dig = radeon_encoder->enc_priv;
+		radeon_atom_set_backlight_level_to_reg(rdev, dig->backlight_level);
+
+		switch (radeon_encoder->encoder_id) {
+		case ENCODER_OBJECT_ID_INTERNAL_LVDS:
+		case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+			index = GetIndexIntoMasterTable(COMMAND, LCD1OutputControl);
+			if (dig->backlight_level == 0) {
+				args.ucAction = ATOM_LCD_BLOFF;
+				atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
+			} else {
+				args.ucAction = ATOM_LCD_BL_BRIGHTNESS_CONTROL;
+				atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
+				args.ucAction = ATOM_LCD_BLON;
+				atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
+			}
+			break;
+		case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+		case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+		case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+		case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+			if (dig->backlight_level == 0)
+				atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_LCD_BLOFF, 0, 0);
+			else {
+				atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_BL_BRIGHTNESS_CONTROL, 0, 0);
+				atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_LCD_BLON, 0, 0);
+			}
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static u8 radeon_atom_bl_level(struct backlight_device *bd)
+{
+	u8 level;
+
+	/* Convert brightness to hardware level */
+	if (bd->props.brightness < 0)
+		level = 0;
+	else if (bd->props.brightness > RADEON_MAX_BL_LEVEL)
+		level = RADEON_MAX_BL_LEVEL;
+	else
+		level = bd->props.brightness;
+
+	return level;
+}
+
+static int radeon_atom_backlight_update_status(struct backlight_device *bd)
+{
+	struct radeon_backlight_privdata *pdata = bl_get_data(bd);
+	struct radeon_encoder *radeon_encoder = pdata->encoder;
+
+	if (radeon_encoder->enc_priv) {
+		struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+		dig->backlight_level = radeon_atom_bl_level(bd);
+		atombios_set_panel_brightness(radeon_encoder);
+	}
+
+	return 0;
+}
+
+static int radeon_atom_backlight_get_brightness(struct backlight_device *bd)
+{
+	struct radeon_backlight_privdata *pdata = bl_get_data(bd);
+	struct radeon_encoder *radeon_encoder = pdata->encoder;
+	struct drm_device *dev = radeon_encoder->base.dev;
+	struct radeon_device *rdev = dev->dev_private;
+
+	return radeon_atom_get_backlight_level_from_reg(rdev);
+}
+
+static const struct backlight_ops radeon_atom_backlight_ops = {
+	.get_brightness = radeon_atom_backlight_get_brightness,
+	.update_status	= radeon_atom_backlight_update_status,
+};
+
+void radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
+				struct drm_connector *drm_connector)
+{
+	struct drm_device *dev = radeon_encoder->base.dev;
+	struct radeon_device *rdev = dev->dev_private;
+	struct backlight_device *bd;
+	struct backlight_properties props;
+	struct radeon_backlight_privdata *pdata;
+	struct radeon_encoder_atom_dig *dig;
+	u8 backlight_level;
+
+	if (!radeon_encoder->enc_priv)
+		return;
+
+	if (!rdev->is_atom_bios)
+		return;
+
+	if (!rdev->mode_info.gpu_controls_bl)
+		return;
+
+	pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
+	if (!pdata) {
+		DRM_ERROR("Memory allocation failed\n");
+		goto error;
+	}
+
+	memset(&props, 0, sizeof(props));
+	props.max_brightness = RADEON_MAX_BL_LEVEL;
+	props.type = BACKLIGHT_RAW;
+	bd = backlight_device_register("radeon_bl", &drm_connector->kdev,
+				       pdata, &radeon_atom_backlight_ops, &props);
+	if (IS_ERR(bd)) {
+		DRM_ERROR("Backlight registration failed\n");
+		goto error;
+	}
+
+	pdata->encoder = radeon_encoder;
+
+	backlight_level = radeon_atom_get_backlight_level_from_reg(rdev);
+
+	dig = radeon_encoder->enc_priv;
+	dig->bl_dev = bd;
+
+	bd->props.brightness = radeon_atom_backlight_get_brightness(bd);
+	bd->props.power = FB_BLANK_UNBLANK;
+	backlight_update_status(bd);
+
+	DRM_INFO("radeon atom DIG backlight initialized\n");
+
+	return;
+
+error:
+	kfree(pdata);
+	return;
+}
+
+static void radeon_atom_backlight_exit(struct radeon_encoder *radeon_encoder)
+{
+	struct drm_device *dev = radeon_encoder->base.dev;
+	struct radeon_device *rdev = dev->dev_private;
+	struct backlight_device *bd = NULL;
+	struct radeon_encoder_atom_dig *dig;
+
+	if (!radeon_encoder->enc_priv)
+		return;
+
+	if (!rdev->is_atom_bios)
+		return;
+
+	if (!rdev->mode_info.gpu_controls_bl)
+		return;
+
+	dig = radeon_encoder->enc_priv;
+	bd = dig->bl_dev;
+	dig->bl_dev = NULL;
+
+	if (bd) {
+		struct radeon_legacy_backlight_privdata *pdata;
+
+		pdata = bl_get_data(bd);
+		backlight_device_unregister(bd);
+		kfree(pdata);
+
+		DRM_INFO("radeon atom LVDS backlight unloaded\n");
+	}
+}
+
+#else /* !CONFIG_BACKLIGHT_CLASS_DEVICE */
+
+void radeon_atom_backlight_init(struct radeon_encoder *encoder)
+{
+}
+
+static void radeon_atom_backlight_exit(struct radeon_encoder *encoder)
+{
+}
+
+#endif
+
 /* evil but including atombios.h is much worse */
 bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int index,
 				struct drm_display_mode *mode);
@@ -2272,6 +2501,8 @@ static const struct drm_encoder_helper_funcs radeon_atom_dac_helper_funcs = {
 void radeon_enc_destroy(struct drm_encoder *encoder)
 {
 	struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+	if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
+		radeon_atom_backlight_exit(radeon_encoder);
 	kfree(radeon_encoder->enc_priv);
 	drm_encoder_cleanup(encoder);
 	kfree(radeon_encoder);
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index 895e628..748c5f2 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -40,10 +40,6 @@ radeon_atombios_connected_scratch_regs(struct drm_connector *connector,
 				       struct drm_encoder *encoder,
 				       bool connected);
 
-extern void
-radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
-			     struct drm_connector *drm_connector);
-
 void radeon_connector_hotplug(struct drm_connector *connector)
 {
 	struct drm_device *dev = connector->dev;
@@ -2008,15 +2004,4 @@ radeon_add_legacy_connector(struct drm_device *dev,
 		connector->polled = DRM_CONNECTOR_POLL_HPD;
 	connector->display_info.subpixel_order = subpixel_order;
 	drm_sysfs_connector_add(connector);
-	if (connector_type == DRM_MODE_CONNECTOR_LVDS) {
-		struct drm_encoder *drm_encoder;
-
-		list_for_each_entry(drm_encoder, &dev->mode_config.encoder_list, head) {
-			struct radeon_encoder *radeon_encoder;
-
-			radeon_encoder = to_radeon_encoder(drm_encoder);
-			if (radeon_encoder->encoder_id == ENCODER_OBJECT_ID_INTERNAL_LVDS)
-				radeon_legacy_backlight_init(radeon_encoder, connector);
-		}
-	}
 }
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
index 7467069..93b0d64 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -29,6 +29,14 @@
 #include "radeon.h"
 #include "atom.h"
 
+extern void
+radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
+			     struct drm_connector *drm_connector);
+extern void
+radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
+			   struct drm_connector *drm_connector);
+
+
 static uint32_t radeon_encoder_clones(struct drm_encoder *encoder)
 {
 	struct drm_device *dev = encoder->dev;
@@ -153,6 +161,7 @@ radeon_get_encoder_enum(struct drm_device *dev, uint32_t supported_device, uint8
 void
 radeon_link_encoder_connector(struct drm_device *dev)
 {
+	struct radeon_device *rdev = dev->dev_private;
 	struct drm_connector *connector;
 	struct radeon_connector *radeon_connector;
 	struct drm_encoder *encoder;
@@ -163,8 +172,15 @@ radeon_link_encoder_connector(struct drm_device *dev)
 		radeon_connector = to_radeon_connector(connector);
 		list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
 			radeon_encoder = to_radeon_encoder(encoder);
-			if (radeon_encoder->devices & radeon_connector->devices)
+			if (radeon_encoder->devices & radeon_connector->devices) {
 				drm_mode_connector_attach_encoder(connector, encoder);
+				if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
+					if (rdev->is_atom_bios)
+						radeon_atom_backlight_init(radeon_encoder, connector);
+					else
+						radeon_legacy_backlight_init(radeon_encoder, connector);
+				}
+			}
 		}
 	}
 }
-- 
1.7.7.5


[-- Attachment #3: 0002-drm-radeon-rework-legacy-backlight-control.patch --]
[-- Type: text/x-patch, Size: 3443 bytes --]

From f55f2a468c48494b8111bf732a9f8d3586d8541e Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
Date: Thu, 26 Jul 2012 11:05:22 -0400
Subject: [PATCH 2/3] drm/radeon: rework legacy backlight control

To better enable sharing with atom backlight control.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |   19 ++++++-------------
 drivers/gpu/drm/radeon/radeon_mode.h            |   11 +++++++++++
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 670e991..9910fe4 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -271,13 +271,6 @@ static const struct drm_encoder_helper_funcs radeon_legacy_lvds_helper_funcs = {
 
 #if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
 
-#define MAX_RADEON_LEVEL 0xFF
-
-struct radeon_backlight_privdata {
-	struct radeon_encoder *encoder;
-	uint8_t negative;
-};
-
 static uint8_t radeon_legacy_lvds_level(struct backlight_device *bd)
 {
 	struct radeon_backlight_privdata *pdata = bl_get_data(bd);
@@ -286,13 +279,13 @@ static uint8_t radeon_legacy_lvds_level(struct backlight_device *bd)
 	/* Convert brightness to hardware level */
 	if (bd->props.brightness < 0)
 		level = 0;
-	else if (bd->props.brightness > MAX_RADEON_LEVEL)
-		level = MAX_RADEON_LEVEL;
+	else if (bd->props.brightness > RADEON_MAX_BL_LEVEL)
+		level = RADEON_MAX_BL_LEVEL;
 	else
 		level = bd->props.brightness;
 
 	if (pdata->negative)
-		level = MAX_RADEON_LEVEL - level;
+		level = RADEON_MAX_BL_LEVEL - level;
 
 	return level;
 }
@@ -336,7 +329,7 @@ static int radeon_legacy_backlight_get_brightness(struct backlight_device *bd)
 	backlight_level = (RREG32(RADEON_LVDS_GEN_CNTL) >>
 			   RADEON_LVDS_BL_MOD_LEVEL_SHIFT) & 0xff;
 
-	return pdata->negative ? MAX_RADEON_LEVEL - backlight_level : backlight_level;
+	return pdata->negative ? RADEON_MAX_BL_LEVEL - backlight_level : backlight_level;
 }
 
 static const struct backlight_ops radeon_backlight_ops = {
@@ -370,7 +363,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
 	}
 
 	memset(&props, 0, sizeof(props));
-	props.max_brightness = MAX_RADEON_LEVEL;
+	props.max_brightness = RADEON_MAX_BL_LEVEL;
 	props.type = BACKLIGHT_RAW;
 	bd = backlight_device_register("radeon_bl", &drm_connector->kdev,
 				       pdata, &radeon_backlight_ops, &props);
@@ -449,7 +442,7 @@ static void radeon_legacy_backlight_exit(struct radeon_encoder *radeon_encoder)
 	}
 
 	if (bd) {
-		struct radeon_legacy_backlight_privdata *pdata;
+		struct radeon_backlight_privdata *pdata;
 
 		pdata = bl_get_data(bd);
 		backlight_device_unregister(bd);
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h
index 33cbf97..46d7801 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -256,6 +256,17 @@ struct radeon_mode_info {
 	bool gpu_controls_bl;
 };
 
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
+
+#define RADEON_MAX_BL_LEVEL 0xFF
+
+struct radeon_backlight_privdata {
+	struct radeon_encoder *encoder;
+	uint8_t negative;
+};
+
+#endif
+
 #define MAX_H_CODE_TIMING_LEN 32
 #define MAX_V_CODE_TIMING_LEN 32
 
-- 
1.7.7.5


[-- Attachment #4: 0001-drm-radeon-track-whether-the-GPU-controls-the-backli.patch --]
[-- Type: text/x-patch, Size: 1652 bytes --]

From a56ac560e34032ca803e0909c8a92a9037046790 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
---
 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

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

[Luca Tettamanti]

On Thu, Jul 26, 2012 at 11:35:25AM -0400, Alex Deucher wrote:
> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti <kronos.it@gmail.com> 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

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

[Alex Deucher]

On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti <kronos.it@gmail.com> 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 <kronos.it@gmail.com> 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

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

[Alex Deucher]

On Thu, Jul 26, 2012 at 3:42 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti <kronos.it@gmail.com> 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 <kronos.it@gmail.com> 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

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

[joeyli]

於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
> - 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). 

I welcome this approach!

On some ATI machine's DSDT also issue ACPI_VIDEO_NOTIFY_PROBE when
AC-power unplug, because BIOS want to nodify video driver do some power
saving stuff.
It causes KEY_SWITCHVIDEOMODE issued by acpi/video driver when AC-power
unplug.

At least acpi/video driver need to know this 0x81 event is filed by BIOS
to radeon-acpi for notify but not do video mode switch. That means the
radeon drm need take the video switch responsibility.


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alex Deucher]

On Thu, Jul 26, 2012 at 10:50 PM, joeyli <jlee@suse.com> wrote:
> 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
>> - 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).
>
> I welcome this approach!
>
> On some ATI machine's DSDT also issue ACPI_VIDEO_NOTIFY_PROBE when
> AC-power unplug, because BIOS want to nodify video driver do some power
> saving stuff.
> It causes KEY_SWITCHVIDEOMODE issued by acpi/video driver when AC-power
> unplug.
>
> At least acpi/video driver need to know this 0x81 event is filed by BIOS
> to radeon-acpi for notify but not do video mode switch. That means the
> radeon drm need take the video switch responsibility.

Probably we'd just want the radeon acpi handler to just forward the
events to userspace so that the user can choose what to do with it
(xrandr command, etc.), otherwise we'll need to define policy in the
driver.

Alex

>
>
> Thanks a lot!
> Joey Lee
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[joeyli]

於 四，2012-07-26 於 23:31 -0400，Alex Deucher 提到：
> On Thu, Jul 26, 2012 at 10:50 PM, joeyli <jlee@suse.com> wrote:
> > 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
> >> - 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).
> >
> > I welcome this approach!
> >
> > On some ATI machine's DSDT also issue ACPI_VIDEO_NOTIFY_PROBE when
> > AC-power unplug, because BIOS want to nodify video driver do some power
> > saving stuff.
> > It causes KEY_SWITCHVIDEOMODE issued by acpi/video driver when AC-power
> > unplug.
> >
> > At least acpi/video driver need to know this 0x81 event is filed by BIOS
> > to radeon-acpi for notify but not do video mode switch. That means the
> > radeon drm need take the video switch responsibility.
> 
> Probably we'd just want the radeon acpi handler to just forward the
> events to userspace so that the user can choose what to do with it
> (xrandr command, etc.), otherwise we'll need to define policy in the
> driver.
> 
> Alex
> 

Any kernel module can issue KEY_SWITCHVIDEOMODE to user space, then
gnome-settings-daemon(on Gnome) and  krandr(on KDE) will call xrandr
library to switch video mode.


The 0x81 ACPI event for acpi/video driver is ACPI_VIDEO_NOTIFY_PROBE,
means need issue KEY_SWITCHVIDEOMODE. But, 0x81 for radeon is a general
notification event.
I didn't see probe state in GET_SYSTEM_BIOS_REQUESTS, how can we
distinguish this 0x81 is a ACPI_VIDEO_NOTIFY_PROBE or a ATI general
notification event?

+ * flags
+ * bits 1:0:
+ * 0 - Notify(VGA, 0x81) is not used for notification
+ * 1 - Notify(VGA, 0x81) is used for notification

Per the above flags, when we detect bit set to 1, means 0x81 used for radeon-acpi
to be a general notification event. My question is: what's the event number for
ACPI_VIDEO_NOTIFY_PROBE on this AMD/ATI machine when 0x81 not available for acpi/video?


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Luca Tettamanti]

On Fri, Jul 27, 2012 at 12:46:50PM +0800, joeyli wrote:
> 於 四，2012-07-26 於 23:31 -0400，Alex Deucher 提到：
> > On Thu, Jul 26, 2012 at 10:50 PM, joeyli <jlee@suse.com> wrote:
> > > 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
> > >> - 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).
> > >
> > > I welcome this approach!
> > >
> > > On some ATI machine's DSDT also issue ACPI_VIDEO_NOTIFY_PROBE when
> > > AC-power unplug, because BIOS want to nodify video driver do some power
> > > saving stuff.
> > > It causes KEY_SWITCHVIDEOMODE issued by acpi/video driver when AC-power
> > > unplug.
> > >
> > > At least acpi/video driver need to know this 0x81 event is filed by BIOS
> > > to radeon-acpi for notify but not do video mode switch. That means the
> > > radeon drm need take the video switch responsibility.
> > 
> > Probably we'd just want the radeon acpi handler to just forward the
> > events to userspace so that the user can choose what to do with it
> > (xrandr command, etc.), otherwise we'll need to define policy in the
> > driver.
> 
> Any kernel module can issue KEY_SWITCHVIDEOMODE to user space, then
> gnome-settings-daemon(on Gnome) and  krandr(on KDE) will call xrandr
> library to switch video mode.

Exacly, and if we have pending system bios requests then the event is
not a real ACPI_VIDEO_NOTIFY_PROBE and (IMHO) it should not be forwarded
to the userspace as such.
The "vanilla" ACPI_VIDEO_NOTIFY_PROBE is already forwared to userspace.

> The 0x81 ACPI event for acpi/video driver is ACPI_VIDEO_NOTIFY_PROBE,
> means need issue KEY_SWITCHVIDEOMODE. But, 0x81 for radeon is a general
> notification event.
> I didn't see probe state in GET_SYSTEM_BIOS_REQUESTS, how can we
> distinguish this 0x81 is a ACPI_VIDEO_NOTIFY_PROBE or a ATI general
> notification event?

+#define ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS                     0x2
+/* ARG0: ATIF_FUNCTION_GET_SYSTEM_BIOS_REQUESTS
+ * ARG1: none
+ * OUTPUT:
+ * WORD  - structure size in bytes (includes size field)
+ * DWORD - pending sbios requests
+ * BYTE  - panel expansion mode
+ * BYTE  - thermal state: target gfx controller
+ * BYTE  - thermal state: state id (0: exit state, non-0: state)
+ * BYTE  - forced power state: target gfx controller
+ * BYTE  - forced power state: state id
+ * BYTE  - system power source
+ * BYTE  - panel backlight level (0-255)

I guess that if "pending sbios requests" == 0 then the event is the
general purpose one, and is not handled by radeon driver.

Luca
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Alex Deucher]

On Fri, Jul 27, 2012 at 12:46 AM, joeyli <jlee@suse.com> wrote:
> 於 四，2012-07-26 於 23:31 -0400，Alex Deucher 提到：
>> On Thu, Jul 26, 2012 at 10:50 PM, joeyli <jlee@suse.com> wrote:
>> > 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
>> >> - 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).
>> >
>> > I welcome this approach!
>> >
>> > On some ATI machine's DSDT also issue ACPI_VIDEO_NOTIFY_PROBE when
>> > AC-power unplug, because BIOS want to nodify video driver do some power
>> > saving stuff.
>> > It causes KEY_SWITCHVIDEOMODE issued by acpi/video driver when AC-power
>> > unplug.
>> >
>> > At least acpi/video driver need to know this 0x81 event is filed by BIOS
>> > to radeon-acpi for notify but not do video mode switch. That means the
>> > radeon drm need take the video switch responsibility.
>>
>> Probably we'd just want the radeon acpi handler to just forward the
>> events to userspace so that the user can choose what to do with it
>> (xrandr command, etc.), otherwise we'll need to define policy in the
>> driver.
>>
>> Alex
>>
>
> Any kernel module can issue KEY_SWITCHVIDEOMODE to user space, then
> gnome-settings-daemon(on Gnome) and  krandr(on KDE) will call xrandr
> library to switch video mode.
>
>
> The 0x81 ACPI event for acpi/video driver is ACPI_VIDEO_NOTIFY_PROBE,
> means need issue KEY_SWITCHVIDEOMODE. But, 0x81 for radeon is a general
> notification event.
> I didn't see probe state in GET_SYSTEM_BIOS_REQUESTS, how can we
> distinguish this 0x81 is a ACPI_VIDEO_NOTIFY_PROBE or a ATI general
> notification event?
>
> + * flags
> + * bits 1:0:
> + * 0 - Notify(VGA, 0x81) is not used for notification
> + * 1 - Notify(VGA, 0x81) is used for notification
>
> Per the above flags, when we detect bit set to 1, means 0x81 used for radeon-acpi
> to be a general notification event. My question is: what's the event number for
> ACPI_VIDEO_NOTIFY_PROBE on this AMD/ATI machine when 0x81 not available for acpi/video?
>


+/* ARG0: ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
+ * ARG1: none
+ * OUTPUT:
+ * WORD  - structure size in bytes (includes size field)
+ * DWORD - valid flags mask
+ * DWORD - flags
+ *
+ * OR
+ *
+ * WORD  - structure size in bytes (includes size field)
+ * DWORD - valid flags mask
+ * DWORD - flags
+ * BYTE  - notify command code
+ *
+ * flags
+ * bits 1:0:
+ * 0 - Notify(VGA, 0x81) is not used for notification
+ * 1 - Notify(VGA, 0x81) is used for notification
+ * 2 - Notify(VGA, n) is used for notification where
+ * n (0xd0-0xd9) is specified in notify command code.
+ * bit 2:
+ * 1 - lid changes not reported though int10
+ */

if bits 1:0 == 0, there is no notify event for radeon.  When bits 1:0
== 1, it uses 0x81; when bits 1:0 == 2 it uses the event number
specified in the following byte (notify command code) which would be
something in the 0xd0-0xd9 range.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[joeyli]

於 五，2012-07-27 於 09:21 -0400，Alex Deucher 提到：
> On Fri, Jul 27, 2012 at 12:46 AM, joeyli <jlee@suse.com> wrote:
> >
> > + * flags
> > + * bits 1:0:
> > + * 0 - Notify(VGA, 0x81) is not used for notification
> > + * 1 - Notify(VGA, 0x81) is used for notification
> >
> > Per the above flags, when we detect bit set to 1, means 0x81 used for radeon-acpi
> > to be a general notification event. My question is: what's the event number for
> > ACPI_VIDEO_NOTIFY_PROBE on this AMD/ATI machine when 0x81 not available for acpi/video?
> >
> 
> 
> +/* ARG0: ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
> + * ARG1: none
> + * OUTPUT:
> + * WORD  - structure size in bytes (includes size field)
> + * DWORD - valid flags mask
> + * DWORD - flags
> + *
> + * OR
> + *
> + * WORD  - structure size in bytes (includes size field)
> + * DWORD - valid flags mask
> + * DWORD - flags
> + * BYTE  - notify command code
> + *
> + * flags
> + * bits 1:0:
> + * 0 - Notify(VGA, 0x81) is not used for notification
> + * 1 - Notify(VGA, 0x81) is used for notification
> + * 2 - Notify(VGA, n) is used for notification where
> + * n (0xd0-0xd9) is specified in notify command code.
> + * bit 2:
> + * 1 - lid changes not reported though int10
> + */
> 
> if bits 1:0 == 0, there is no notify event for radeon.  When bits 1:0
> == 1, it uses 0x81; when bits 1:0 == 2 it uses the event number
> specified in the following byte (notify command code) which would be
> something in the 0xd0-0xd9 range.
> 
> Alex

Did you mean every time we received 0x81 event in kernel module, we need
access GET_SYSTEM_PARAMETERS to get the flags for distinguish between
ACPI_VIDEO_NOTIFY_PROBE?

Or just need access ONE time when system boot?


I have a machine the GET_SYSTEM_PARAMETERS looks like this:

Method (AF01, 0, NotSerialized)                 /* ATIF_FUNCTION_GET_SYSTEM_PARAMETERS 0x1 */
{
    CreateWordField (ATIB, Zero, SSZE)
    CreateDWordField (ATIB, 0x02, VMSK)
    CreateDWordField (ATIB, 0x06, FLGS)         /* flags bits 1:0 */
    Store (0x0A, SSZE)		/* structure SIZE fixed */
    Store (0x03, VMSK)		/* valid flags mask fixed to 0x03 */
    Store (One, FLGS)		/* FLAGS always set to 1 */
    Return (ATIB)
}

Looks like just need access ONE time when system boot because those
return value of AF01 fixed in DSDT.

On this machine doesn't support probe event, I didn't see any event
issued when I plug D-Sub. Does that means those kind of ATI/AMD machines
do NOT support probe notify?

If YES, then we can just direct disable acpi/video driver by radeon-acpi
when we detected FLAGS is 1.


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[joeyli]

於 五，2012-07-27 於 23:32 +0800，joeyli 提到：
> 於 五，2012-07-27 於 09:21 -0400，Alex Deucher 提到：
> > On Fri, Jul 27, 2012 at 12:46 AM, joeyli <jlee@suse.com> wrote:
> > >
> > > + * flags
> > > + * bits 1:0:
> > > + * 0 - Notify(VGA, 0x81) is not used for notification
> > > + * 1 - Notify(VGA, 0x81) is used for notification
> > >
> > > Per the above flags, when we detect bit set to 1, means 0x81 used for radeon-acpi
> > > to be a general notification event. My question is: what's the event number for
> > > ACPI_VIDEO_NOTIFY_PROBE on this AMD/ATI machine when 0x81 not available for acpi/video?
> > >
> > 
> > 
> > +/* ARG0: ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
> > + * ARG1: none
> > + * OUTPUT:
> > + * WORD  - structure size in bytes (includes size field)
> > + * DWORD - valid flags mask
> > + * DWORD - flags
> > + *
> > + * OR
> > + *
> > + * WORD  - structure size in bytes (includes size field)
> > + * DWORD - valid flags mask
> > + * DWORD - flags
> > + * BYTE  - notify command code
> > + *
> > + * flags
> > + * bits 1:0:
> > + * 0 - Notify(VGA, 0x81) is not used for notification
> > + * 1 - Notify(VGA, 0x81) is used for notification
> > + * 2 - Notify(VGA, n) is used for notification where
> > + * n (0xd0-0xd9) is specified in notify command code.
> > + * bit 2:
> > + * 1 - lid changes not reported though int10
> > + */
> > 
> > if bits 1:0 == 0, there is no notify event for radeon.  When bits 1:0
> > == 1, it uses 0x81; when bits 1:0 == 2 it uses the event number
> > specified in the following byte (notify command code) which would be
> > something in the 0xd0-0xd9 range.
> > 
> > Alex
> 
> Did you mean every time we received 0x81 event in kernel module, we need
> access GET_SYSTEM_PARAMETERS to get the flags for distinguish between
> ACPI_VIDEO_NOTIFY_PROBE?
> 
> Or just need access ONE time when system boot?
> 
> 
> I have a machine the GET_SYSTEM_PARAMETERS looks like this:
> 
> Method (AF01, 0, NotSerialized)                 /* ATIF_FUNCTION_GET_SYSTEM_PARAMETERS 0x1 */
> {
>     CreateWordField (ATIB, Zero, SSZE)
>     CreateDWordField (ATIB, 0x02, VMSK)
>     CreateDWordField (ATIB, 0x06, FLGS)         /* flags bits 1:0 */
>     Store (0x0A, SSZE)		/* structure SIZE fixed */
>     Store (0x03, VMSK)		/* valid flags mask fixed to 0x03 */
>     Store (One, FLGS)		/* FLAGS always set to 1 */
>     Return (ATIB)
> }
> 
> Looks like just need access ONE time when system boot because those
> return value of AF01 fixed in DSDT.
> 
> On this machine doesn't support probe event, I didn't see any event
> issued when I plug D-Sub. Does that means those kind of ATI/AMD machines
> do NOT support probe notify?
> 
> If YES, then we can just direct disable acpi/video driver by radeon-acpi
					^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> when we detected FLAGS is 1.
> 

I mean disable the ACPI_VIDEO_NOTIFY_PROBE related code in acpi/video
driver.


Thanks
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alex Deucher]

On Fri, Jul 27, 2012 at 11:32 AM, joeyli <jlee@suse.com> wrote:
> 於 五，2012-07-27 於 09:21 -0400，Alex Deucher 提到：
>> On Fri, Jul 27, 2012 at 12:46 AM, joeyli <jlee@suse.com> wrote:
>> >
>> > + * flags
>> > + * bits 1:0:
>> > + * 0 - Notify(VGA, 0x81) is not used for notification
>> > + * 1 - Notify(VGA, 0x81) is used for notification
>> >
>> > Per the above flags, when we detect bit set to 1, means 0x81 used for radeon-acpi
>> > to be a general notification event. My question is: what's the event number for
>> > ACPI_VIDEO_NOTIFY_PROBE on this AMD/ATI machine when 0x81 not available for acpi/video?
>> >
>>
>>
>> +/* ARG0: ATIF_FUNCTION_GET_SYSTEM_PARAMETERS
>> + * ARG1: none
>> + * OUTPUT:
>> + * WORD  - structure size in bytes (includes size field)
>> + * DWORD - valid flags mask
>> + * DWORD - flags
>> + *
>> + * OR
>> + *
>> + * WORD  - structure size in bytes (includes size field)
>> + * DWORD - valid flags mask
>> + * DWORD - flags
>> + * BYTE  - notify command code
>> + *
>> + * flags
>> + * bits 1:0:
>> + * 0 - Notify(VGA, 0x81) is not used for notification
>> + * 1 - Notify(VGA, 0x81) is used for notification
>> + * 2 - Notify(VGA, n) is used for notification where
>> + * n (0xd0-0xd9) is specified in notify command code.
>> + * bit 2:
>> + * 1 - lid changes not reported though int10
>> + */
>>
>> if bits 1:0 == 0, there is no notify event for radeon.  When bits 1:0
>> == 1, it uses 0x81; when bits 1:0 == 2 it uses the event number
>> specified in the following byte (notify command code) which would be
>> something in the 0xd0-0xd9 range.
>>
>> Alex
>
> Did you mean every time we received 0x81 event in kernel module, we need
> access GET_SYSTEM_PARAMETERS to get the flags for distinguish between
> ACPI_VIDEO_NOTIFY_PROBE?
>
> Or just need access ONE time when system boot?

Just once at start up to see what event, if any, the sbios will use to
signal the driver.

>
>
> I have a machine the GET_SYSTEM_PARAMETERS looks like this:
>
> Method (AF01, 0, NotSerialized)                 /* ATIF_FUNCTION_GET_SYSTEM_PARAMETERS 0x1 */
> {
>     CreateWordField (ATIB, Zero, SSZE)
>     CreateDWordField (ATIB, 0x02, VMSK)
>     CreateDWordField (ATIB, 0x06, FLGS)         /* flags bits 1:0 */
>     Store (0x0A, SSZE)          /* structure SIZE fixed */
>     Store (0x03, VMSK)          /* valid flags mask fixed to 0x03 */
>     Store (One, FLGS)           /* FLAGS always set to 1 */
>     Return (ATIB)
> }
>
> Looks like just need access ONE time when system boot because those
> return value of AF01 fixed in DSDT.
>
> On this machine doesn't support probe event, I didn't see any event
> issued when I plug D-Sub. Does that means those kind of ATI/AMD machines
> do NOT support probe notify?

Analog connectors don't support hotplug at all.  And hotplug on
digital connectors is already handled by the driver.  As far as I know
ACPI doesn't provide any events for these.  The driver gets interrupts
directly from the hw.  The only events the sbios uses the notify event
for are the ones listed in the supported notifications mask from
ATIF_FUNCTION_VERIFY_INTERFACE:

+#define ATIF_FUNCTION_VERIFY_INTERFACE                             0x0
+/* ARG0: ATIF_FUNCTION_VERIFY_INTERFACE
+ * ARG1: none
+ * OUTPUT:
+ * WORD  - structure size in bytes (includes size field)
+ * WORD  - version
+ * DWORD - supported notifications mask
+ * DWORD - supported functions bit vector
+ */
+/* Notifications mask */
+#       define ATIF_DISPLAY_SWITCH_REQUEST_SUPPORTED               (1 << 0)
+#       define ATIF_EXPANSION_MODE_CHANGE_REQUEST_SUPPORTED        (1 << 1)
+#       define ATIF_THERMAL_STATE_CHANGE_REQUEST_SUPPORTED         (1 << 2)
+#       define ATIF_FORCED_POWER_STATE_CHANGE_REQUEST_SUPPORTED    (1 << 3)
+#       define ATIF_SYSTEM_POWER_SOURCE_CHANGE_REQUEST_SUPPORTED   (1 << 4)
+#       define ATIF_DISPLAY_CONF_CHANGE_REQUEST_SUPPORTED          (1 << 5)
+#       define ATIF_PX_GFX_SWITCH_REQUEST_SUPPORTED                (1 << 6)
+#       define ATIF_PANEL_BRIGHTNESS_CHANGE_REQUEST_SUPPORTED      (1 << 7)
+#       define ATIF_DGPU_DISPLAY_EVENT_SUPPORTED                   (1 << 8)


They are things like the user presses the display switch hotkey or
presses the brightness up hotkey.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pali Rohár]

Alex Deucher <alexdeucher <at> gmail.com> writes:
> 
> On Thu, Jul 26, 2012 at 8:58 AM, Luca Tettamanti 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.
> 
> Alex
> 

Hi, thank you very much for patches. With these patches now I'm able to adjust
brightness on my notebook HP EliteBook 8460p with Radeon 6470M card via file
/sys/class/backlight/radeon_bl/brightness

It has only one problem: When I enable Ambient Ligth Sensor via hp-wmi.ko
driver (echo 1 > /sys/devices/platform/hp-wmi/als which auto adjust some
brightness level based on sensor data on HW level) and I set radeon brightness
to 0 or 255 (min or max value) screen is turned off. Values 1..254 are OK.

What about to disable values 0 and 255 in radeon brightness driver?