[PATCH] backlight: Avoid double fbcon backlight handling
On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote:
> Backlights controlled by i915.ko and only associated with its connectors
> and also only associated with the intel_drmfb fbcon, controlled by
> i915.ko. In this situation, we already handle adjusting the backlight
> when the fbcon is blanked/unblanked and do not require backlight trying
> to do the same.
>
> Attempting to register with the fbdev as a client causes lockdep to warn
> about a dependency cycle:
>
> [ 18.983763] ==
> [ 18.983763] [ INFO: possible circular locking dependency detected ]
> [ 18.983766] 4.7.0-rc5+ #524 Tainted: G O
> [ 18.983767] ---
> [ 18.983767] kworker/u8:0/6 is trying to acquire lock:
> [ 18.983777] (&dev->mode_config.mutex){+.+.+.}, at: []
> drm_modeset_lock_all+0x40/0x120
> [ 18.983777]
>but task is already holding lock:
> [ 18.983782] ((fb_notifier_list).rwsem){.+}, at: []
> __blocking_notifier_call_chain+0x35/0x70
> [ 18.983783]
>which lock already depends on the new lock.
>
> [ 18.983783]
>the existing dependency chain (in reverse order) is:
> [ 18.983785]
>-> #1 ((fb_notifier_list).rwsem){.+}:
> [ 18.983789][] lock_acquire+0xb1/0x200
> [ 18.983792][] down_write+0x44/0x80
> [ 18.983795][]
> blocking_notifier_chain_register+0x21/0xb0
> [ 18.983798][] fb_register_client+0x18/0x20
> [ 18.983800][]
> backlight_device_register+0x136/0x260
> [ 18.983852][]
> intel_backlight_device_register+0xa2/0x160 [i915]
> [ 18.983892][] intel_connector_register+0xe/0x10
> [i915]
> [ 18.983932][]
> intel_dp_connector_register+0x1b/0x80 [i915]
> [ 18.983936][] drm_connector_register+0x4a/0x80
> [ 18.983938][]
> drm_connector_register_all+0x64/0xf0
> [ 18.983940][]
> drm_modeset_register_all+0x174/0x1c0
> [ 18.983942][] drm_dev_register+0xc2/0xd0
> [ 18.983976][] i915_driver_load+0x1547/0x2200
> [i915]
> [ 18.984010][] i915_pci_probe+0x4f/0x70 [i915]
> [ 18.984014][] local_pci_probe+0x45/0xa0
> [ 18.984015][] pci_device_probe+0xdb/0x130
> [ 18.984018][] driver_probe_device+0x223/0x440
> [ 18.984020][] __driver_attach+0xd5/0x100
> [ 18.984022][] bus_for_each_dev+0x66/0xa0
> [ 18.984023][] driver_attach+0x1e/0x20
> [ 18.984025][] bus_add_driver+0x1ee/0x280
> [ 18.984028][] driver_register+0x60/0xe0
> [ 18.984030][] __pci_register_driver+0x60/0x70
> [ 18.984063][] i915_init+0x5b/0x62 [i915]
> [ 18.984067][] do_one_initcall+0x3d/0x150
> [ 18.984070][] do_init_module+0x5f/0x1d9
> [ 18.984073][] load_module+0x20e6/0x27e0
> [ 18.984075][] SYSC_finit_module+0xc3/0xf0
> [ 18.984076][] SyS_finit_module+0xe/0x10
> [ 18.984079][] entry_SYSCALL_64_fastpath+0x1c/0xac
> [ 18.984081]
>-> #0 (&dev->mode_config.mutex){+.+.+.}:
> [ 18.984083][] __lock_acquire+0x10fc/0x1260
> [ 18.984085][] lock_acquire+0xb1/0x200
> [ 18.984088][] mutex_lock_nested+0x67/0x3c0
> [ 18.984090][] drm_modeset_lock_all+0x40/0x120
> [ 18.984093][]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
> [ 18.984095][] drm_fb_helper_set_par+0x2d/0x50
> [ 18.984134][] intel_fbdev_set_par+0x1a/0x60
> [i915]
> [ 18.984136][] fbcon_init+0x586/0x610
> [ 18.984139][] visual_init+0xca/0x130
> [ 18.984141][] do_bind_con_driver+0x1c1/0x3a0
> [ 18.984143][] do_take_over_console+0x116/0x180
> [ 18.984145][] do_fbcon_takeover+0x57/0xb0
> [ 18.984147][] fbcon_event_notify+0x658/0x750
> [ 18.984150][] notifier_call_chain+0x3e/0xb0
> [ 18.984152][]
> __blocking_notifier_call_chain+0x4d/0x70
> [ 18.984154][]
> blocking_notifier_call_chain+0x16/0x20
> [ 18.984156][] fb_notifier_call_chain+0x1b/0x20
> [ 18.984158][] register_framebuffer+0x251/0x330
> [ 18.984160][]
> drm_fb_helper_initial_config+0x25f/0x3f0
> [ 18.984199][]
> intel_fbdev_initial_config+0x18/0x30 [i915]
> [ 18.984201][] async_run_entry_fn+0x48/0x150
> [ 18.984203][] process_one_work+0x1e7/0x750
> [ 18.984205][] worker_thread+0x4b/0x4f0
> [ 18.984207][] kthread+0xef/0x110
> [ 18.984208][] ret_from_fork+0x1f/0x40
> [ 18.984209]
>other info that might help us debug this:
>
> [ 18.984210] Possible unsafe locking scenario:
>
> [ 18.984210]CPU0CPU1
> [ 18.984211]
> [ 18.984212] lock((fb_notifier_list).rwsem);
> [ 18.984213]lo
[PATCH 14/32] acer-wmi: Port to new backlight interface selection API
On Wed, Jun 10, 2015 at 03:01:14PM +0200, Hans de Goede wrote:
> Port the backlight selection logic to the new backlight interface
> selection API.
>
> This commit also removes various obsolete pr_xxx messages related to
> backlight interface selection. These are obsolete because they assume
> there is only a vendor or acpi backlight driver and no other choice.
> Also they are not necessary, if the user wants to know which backlight
> interfaces are registered a simple "ls /sys/class/backlight" suffices.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Lee, Chun-Yi
Thanks a lot!
Joey Lee
> ---
> drivers/platform/x86/acer-wmi.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index 3ac29a1..f6b280d 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -2246,14 +2246,10 @@ static int __init acer_wmi_init(void)
> set_quirks();
>
> if (dmi_check_system(video_vendor_dmi_table))
> - acpi_video_dmi_promote_vendor();
> - if (acpi_video_backlight_support()) {
> + acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
> +
> + if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
> interface->capability &= ~ACER_CAP_BRIGHTNESS;
> - pr_info("Brightness must be controlled by acpi video driver\n");
> - } else {
> - pr_info("Disabling ACPI video driver\n");
> - acpi_video_unregister_backlight();
> - }
>
> if (wmi_has_guid(WMID_GUID3)) {
> if (ec_raw_mode) {
> --
> 2.4.2
>
[PATCH 3/4] acer-wmi: Stop selecting VIDEO_OUTPUT_CONTROL
On Mon, Mar 17, 2014 at 03:48:23PM +0100, Jean Delvare wrote: > ACPI_VIDEO no longer depends on VIDEO_OUTPUT_CONTROL, so drivers which > want to select ACPI_VIDEO no longer have to select > VIDEO_OUTPUT_CONTROL. > > Signed-off-by: Jean Delvare > Cc: "Lee, Chun-Yi" > Cc: Matthew Garrett > --- > drivers/platform/x86/Kconfig |2 -- > 1 file changed, 2 deletions(-) > > --- linux-3.14-rc7.orig/drivers/platform/x86/Kconfig 2014-03-17 > 14:23:31.511815259 +0100 > +++ linux-3.14-rc7/drivers/platform/x86/Kconfig 2014-03-17 > 14:24:32.100155709 +0100 > @@ -27,8 +27,6 @@ config ACER_WMI > depends on ACPI_WMI > select INPUT_SPARSEKMAP > # Acer WMI depends on ACPI_VIDEO when ACPI is enabled > - # but for select to work, need to select ACPI_VIDEO's dependencies, ick > -select VIDEO_OUTPUT_CONTROL if ACPI > select ACPI_VIDEO if ACPI > ---help--- > This is a driver for newer Acer (and Wistron) laptops. It adds > > > -- > Jean Delvare > SUSE L3 Support Acked-by: "Lee, Chun-Yi" Thanks a lot! Joey Lee
[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
? ??2013-06-09 ? 19:01 -0400?Matthew Garrett ??? > Windows 8 leaves backlight control up to individual graphics drivers rather > than making ACPI calls itself. There's plenty of evidence to suggest that > the Intel driver for Windows doesn't use the ACPI interface, including the > fact that it's broken on a bunch of machines when the OS claims to support > Windows 8. The simplest thing to do appears to be to disable the ACPI > backlight interface on these systems. > > Signed-off-by: Matthew Garrett > --- > drivers/gpu/drm/i915/i915_dma.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > index 3b315ba..23b6292 100644 > --- a/drivers/gpu/drm/i915/i915_dma.c > +++ b/drivers/gpu/drm/i915/i915_dma.c > @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned > long flags) > /* Must be done after probing outputs */ > intel_opregion_init(dev); > acpi_video_register(); > + /* Don't use ACPI backlight functions on Windows 8 platforms */ > + if (acpi_osi_version() >= ACPI_OSI_WIN_8) > + acpi_video_backlight_unregister(); > } > > if (IS_GEN5(dev)) This patch set works to me on Acer Aspire V3 notebook for unregister the backlight interface of acpi video driver when i915 loaded. Acer Aspire V3 has the Windows8 support in DSDT. Tested-by: Lee, Chun-Yi Thanks a lot! Joey Lee
Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8
於 日，2013-06-09 於 19:01 -0400，Matthew Garrett 提到： > Windows 8 leaves backlight control up to individual graphics drivers rather > than making ACPI calls itself. There's plenty of evidence to suggest that > the Intel driver for Windows doesn't use the ACPI interface, including the > fact that it's broken on a bunch of machines when the OS claims to support > Windows 8. The simplest thing to do appears to be to disable the ACPI > backlight interface on these systems. > > Signed-off-by: Matthew Garrett > --- > drivers/gpu/drm/i915/i915_dma.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > index 3b315ba..23b6292 100644 > --- a/drivers/gpu/drm/i915/i915_dma.c > +++ b/drivers/gpu/drm/i915/i915_dma.c > @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned > long flags) > /* Must be done after probing outputs */ > intel_opregion_init(dev); > acpi_video_register(); > + /* Don't use ACPI backlight functions on Windows 8 platforms */ > + if (acpi_osi_version() >= ACPI_OSI_WIN_8) > + acpi_video_backlight_unregister(); > } > > if (IS_GEN5(dev)) This patch set works to me on Acer Aspire V3 notebook for unregister the backlight interface of acpi video driver when i915 loaded. Acer Aspire V3 has the Windows8 support in DSDT. Tested-by: Lee, Chun-Yi Thanks a lot! Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
? ??2012-08-01 ? 15:49 +0200?Luca Tettamanti ???
> AMD ACPI interface may overload the standard event
> ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
> userspace because the user did not press the mode switch key (the
> spurious keypress confuses the DE which usually changes the
> display configuration and messes up a dual-screen setup).
> This patch gives the radeon driver the chance to examine the event and
> block the keypress if the event is an "AMD event".
>
> Signed-off-by: Luca Tettamanti
Tested-by: Lee, Chun-Yi
This patch works to me on my HP notebook to avoid (VGA, 0x81) notify
event issued when AC-power unpluged.
Thanks
Joey Lee
> ---
> Any comment from ACPI front?
>
> drivers/acpi/video.c | 10 --
> drivers/gpu/drm/radeon/radeon_acpi.c |7 ++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 1e0a9e1..a8592c4 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -1457,7 +1457,12 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> acpi_video_device_enumerate(video);
> acpi_video_device_rebind(video);
> acpi_bus_generate_proc_event(device, event, 0);
> - keycode = KEY_SWITCHVIDEOMODE;
> + /* This event is also overloaded by AMD ACPI interface, don't
> + * send the key press if the event has been handled elsewhere
> + * (e.g. radeon DRM driver).
> + */
> + if (!acpi_notifier_call_chain(device, event, 0))
> + keycode = KEY_SWITCHVIDEOMODE;
> break;
>
> case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
> */
> @@ -1479,7 +1484,8 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> break;
> }
>
> - if (event != ACPI_VIDEO_NOTIFY_SWITCH)
> + if (event != ACPI_VIDEO_NOTIFY_SWITCH &&
> + event != ACPI_VIDEO_NOTIFY_PROBE)
> acpi_notifier_call_chain(device, event, 0);
>
> if (keycode) {
> diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
> b/drivers/gpu/drm/radeon/radeon_acpi.c
> index 96de08d..ee0d29e 100644
> --- a/drivers/gpu/drm/radeon/radeon_acpi.c
> +++ b/drivers/gpu/drm/radeon/radeon_acpi.c
> @@ -273,7 +273,12 @@ int radeon_atif_handler(struct radeon_device *rdev,
> }
> /* TODO: check other events */
>
> - return NOTIFY_OK;
> + /* We've handled the event, stop the notifier chain. The ACPI interface
> + * overloads ACPI_VIDEO_NOTIFY_PROBE, we don't want to send that to
> + * userspace if the event was generated only to signal a SBIOS
> + * request.
> + */
> + return NOTIFY_BAD;
> }
>
> /* Call all ACPI methods here */
Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
於 三，2012-08-01 於 15:49 +0200，Luca Tettamanti 提到：
> AMD ACPI interface may overload the standard event
> ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
> userspace because the user did not press the mode switch key (the
> spurious keypress confuses the DE which usually changes the
> display configuration and messes up a dual-screen setup).
> This patch gives the radeon driver the chance to examine the event and
> block the keypress if the event is an "AMD event".
>
> Signed-off-by: Luca Tettamanti
Tested-by: Lee, Chun-Yi
This patch works to me on my HP notebook to avoid (VGA, 0x81) notify
event issued when AC-power unpluged.
Thanks
Joey Lee
> ---
> Any comment from ACPI front?
>
> drivers/acpi/video.c | 10 --
> drivers/gpu/drm/radeon/radeon_acpi.c |7 ++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 1e0a9e1..a8592c4 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -1457,7 +1457,12 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> acpi_video_device_enumerate(video);
> acpi_video_device_rebind(video);
> acpi_bus_generate_proc_event(device, event, 0);
> - keycode = KEY_SWITCHVIDEOMODE;
> + /* This event is also overloaded by AMD ACPI interface, don't
> + * send the key press if the event has been handled elsewhere
> + * (e.g. radeon DRM driver).
> + */
> + if (!acpi_notifier_call_chain(device, event, 0))
> + keycode = KEY_SWITCHVIDEOMODE;
> break;
>
> case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
> */
> @@ -1479,7 +1484,8 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> break;
> }
>
> - if (event != ACPI_VIDEO_NOTIFY_SWITCH)
> + if (event != ACPI_VIDEO_NOTIFY_SWITCH &&
> + event != ACPI_VIDEO_NOTIFY_PROBE)
> acpi_notifier_call_chain(device, event, 0);
>
> if (keycode) {
> diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
> b/drivers/gpu/drm/radeon/radeon_acpi.c
> index 96de08d..ee0d29e 100644
> --- a/drivers/gpu/drm/radeon/radeon_acpi.c
> +++ b/drivers/gpu/drm/radeon/radeon_acpi.c
> @@ -273,7 +273,12 @@ int radeon_atif_handler(struct radeon_device *rdev,
> }
> /* TODO: check other events */
>
> - return NOTIFY_OK;
> + /* We've handled the event, stop the notifier chain. The ACPI interface
> + * overloads ACPI_VIDEO_NOTIFY_PROBE, we don't want to send that to
> + * userspace if the event was generated only to signal a SBIOS
> + * request.
> + */
> + return NOTIFY_BAD;
> }
>
> /* Call all ACPI methods here */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: Brightness on HP EliteBook 8460p
於 一，2012-07-30 於 10:17 +0200，Artur Flinta 提到： > On Sat, Jul 28, 2012 at 4:47 PM, Pali Rohár wrote: > > Hello, I have some good news. Radeon patches from this post > > http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html > > export brightness file /sys/class/backlight/radeon_bl/brightness > > And finally with these patches I'm able to change brightness on my > > EliteBook. > > Wow, it's great news :) I was reading yesterday info about ACPI > patches from AMD on Phronix and thinking will it help or no, and now I > have an answer :) > > Regards > Artur Yes, thanks for Alex's 3 patches, those patches also works to me on my machine for backlight control. Thanks 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
於 日，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...
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.
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.
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;
+
Thanks a lot!
Joey Lee
>From 9c0c42ab8f37dafd3b512ca395b64bf39819d26b Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi
Date: Mon, 30 Jul 2012 16:17:05 +0800
Subject: [PATCH] drm/radeon avoid 0x81 acpi event conflict with acpi video
driver
drm/radeon avoid 0x81 acpi event conflict with acpi video driver
Signed-off-by: Lee, Chun-Yi
---
drivers/acpi/video.c |6 +-
drivers/gpu/drm/radeon/radeon_acpi.c | 150 ++
2 files changed, 139 insertions(+), 17 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..e32492d 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1457,7 +1457,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
acpi_video_device_enumerate(video);
acpi_video_device_rebind(video);
acpi_bus_generate_proc_event(device, event, 0);
- keycode = KEY_SWITCHVIDEOMODE;
+ if (!acpi_notifier_call_chain(device, event, 0))
+ keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
*/
@@ -1479,7 +1480,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
break;
}
- if (event != ACPI_VIDEO_NOTIFY_SWITCH)
+ if (event != ACPI_VIDEO_NOTIFY_SWITCH ||
+ event != ACPI_VIDEO_NOTIFY_PROBE)
acpi_notifier_call_chain(device, event, 0);
if (keycode) {
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5b32e49..37ed5e1 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
#include "drmP.h"
#include "drm.h"
@@ -13,36 +14,150 @@
#include
+struct atif_verify_output {
+ u16 size; /* structure size in bytes (includes size
field) */
+ u16 version;/* version */
+ u32 notif_mask; /* supported notifications mask */
+ u32 func_bits; /* supported functions bit vector */
+} __attribute__((packed));
+
+static struct atif_verify_output *verify_output;
+
+struct atif_get_sysparams_output {
+ u16 size;
Fwd: Brightness on HP EliteBook 8460p
? ??2012-07-30 ? 10:17 +0200?Artur Flinta ??? > On Sat, Jul 28, 2012 at 4:47 PM, Pali Roh?r wrote: > > Hello, I have some good news. Radeon patches from this post > > http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html > > export brightness file /sys/class/backlight/radeon_bl/brightness > > And finally with these patches I'm able to change brightness on my > > EliteBook. > > Wow, it's great news :) I was reading yesterday info about ACPI > patches from AMD on Phronix and thinking will it help or no, and now I > have an answer :) > > Regards > Artur Yes, thanks for Alex's 3 patches, those patches also works to me on my machine for backlight control. Thanks Joey LEe
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
? ??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...
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.
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.
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;
+
Thanks a lot!
Joey Lee
>From 9c0c42ab8f37dafd3b512ca395b64bf39819d26b Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi
Date: Mon, 30 Jul 2012 16:17:05 +0800
Subject: [PATCH] drm/radeon avoid 0x81 acpi event conflict with acpi video
driver
drm/radeon avoid 0x81 acpi event conflict with acpi video driver
Signed-off-by: Lee, Chun-Yi
---
drivers/acpi/video.c |6 +-
drivers/gpu/drm/radeon/radeon_acpi.c | 150 ++
2 files changed, 139 insertions(+), 17 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..e32492d 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1457,7 +1457,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
acpi_video_device_enumerate(video);
acpi_video_device_rebind(video);
acpi_bus_generate_proc_event(device, event, 0);
- keycode = KEY_SWITCHVIDEOMODE;
+ if (!acpi_notifier_call_chain(device, event, 0))
+ keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
*/
@@ -1479,7 +1480,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
break;
}
- if (event != ACPI_VIDEO_NOTIFY_SWITCH)
+ if (event != ACPI_VIDEO_NOTIFY_SWITCH ||
+ event != ACPI_VIDEO_NOTIFY_PROBE)
acpi_notifier_call_chain(device, event, 0);
if (keycode) {
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5b32e49..37ed5e1 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
#include "drmP.h"
#include "drm.h"
@@ -13,36 +14,150 @@
#include
+struct atif_verify_output {
+ u16 size; /* structure size in bytes (includes size
field) */
+ u16 version;/* version */
+ u32 notif_mask; /* supported notifications mask */
+ u32 func_bits; /* supported functions bit vector */
+} __attribute__((packed));
+
+static struct atif_verify_output *verify_output;
+
+struct atif_get_sysparams_output {
+ u16 size; /* structure size
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
Hi Luca,
於 六，2012-07-28 於 16:56 +0200，Luca Tettamanti 提到：
> On Thu, Jul 26, 2012 at 03:42:26PM -0400, Alex Deucher wrote:
> > On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti
> > 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
> > >> 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
>
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.
On the other hand,
I am also trying to write patch for avoid my AC-power problem. Like your
idea, I think just add radeon-acpi to acpi notifier chain then
acpi/video feed event to chain before issue KEY code like Matthew's code
for ACPI_VIDEO_NOTIFY_SWITCH with intel_opregion on 0x80.
The following code for reference:
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..fc138fd 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -91,6 +91,8 @@ static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device, int type);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+static u16 video_notify_block_map;
+
static const struct acpi_device_id video_device_ids[] = {
{ACPI_VIDEO_HID, 0},
{"", 0},
@@ -1457,7 +1459,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
acpi_video_device_enumerate(video);
acpi_video_device_rebind(video);
acpi_bus_generate_proc_event(device, event, 0);
- keycode = KEY_SWITCHVIDEOMODE;
+ if (!acpi_notifier_call_chain(device, event, 0))
+ keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
*/
@@ -1479,7 +1482,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
break;
}
- if (event != ACPI_VIDEO_NOTIFY_SWITCH)
+ if (event != ACPI_VIDEO_NOTIFY_SWITCH ||
+ event != ACPI_VIDEO_NOTIFY_PROBE)
acpi_notifier_call_chain(device, event, 0);
if (keycode) {
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
於 五，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 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
___
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
於 五，2012-07-27 於 09:21 -0400，Alex Deucher 提到：
> On Fri, Jul 27, 2012 at 12:46 AM, joeyli 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
___
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
於 四，2012-07-26 於 23:31 -0400，Alex Deucher 提到： > On Thu, Jul 26, 2012 at 10:50 PM, joeyli 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 ___ 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
於 四，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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
Hi Luca,
? ??2012-07-28 ? 16:56 +0200?Luca Tettamanti ???
> On Thu, Jul 26, 2012 at 03:42:26PM -0400, Alex Deucher wrote:
> > On Thu, Jul 26, 2012 at 3:33 PM, Luca Tettamanti
> > 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 > >> 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 :)
>
> 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
>
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.
On the other hand,
I am also trying to write patch for avoid my AC-power problem. Like your
idea, I think just add radeon-acpi to acpi notifier chain then
acpi/video feed event to chain before issue KEY code like Matthew's code
for ACPI_VIDEO_NOTIFY_SWITCH with intel_opregion on 0x80.
The following code for reference:
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..fc138fd 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -91,6 +91,8 @@ static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device, int type);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+static u16 video_notify_block_map;
+
static const struct acpi_device_id video_device_ids[] = {
{ACPI_VIDEO_HID, 0},
{"", 0},
@@ -1457,7 +1459,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
acpi_video_device_enumerate(video);
acpi_video_device_rebind(video);
acpi_bus_generate_proc_event(device, event, 0);
- keycode = KEY_SWITCHVIDEOMODE;
+ if (!acpi_notifier_call_chain(device, event, 0))
+ keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
*/
@@ -1479,7 +1482,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
break;
}
- if (event != ACPI_VIDEO_NOTIFY_SWITCH)
+ if (event != ACPI_VIDEO_NOTIFY_SWITCH ||
+ event != ACPI_VIDEO_NOTIFY_PROBE)
acpi_notifier_call_chain(device, event, 0);
if (keycode) {
Thanks a lot!
Joey Lee
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
? ??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 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
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
? ??2012-07-27 ? 09:21 -0400?Alex Deucher ???
> On Fri, Jul 27, 2012 at 12:46 AM, joeyli 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
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
? ??2012-07-26 ? 23:31 -0400?Alex Deucher ??? > On Thu, Jul 26, 2012 at 10:50 PM, joeyli 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
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
? ??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
[PATCH] gpu: remove gma500 stub driver
? ??2012-05-25 ? 16:07 +0900?Greg KH ??? > On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > Cc: randy.dunlap at oracle.com > > Cc: mjg59 at srcf.ucam.org > > Cc: gregkh at suse.de > > Note, my email address has changed :) > Sorry~~~! I will keep in mind! :-) > Acked-by: Greg Kroah-Hartman > > Thanks a lot! Joey Lee
[PATCH] gpu: schedule gma500 stub driver for feature removal
? ??2012-05-25 ? 04:53 +0900?Greg KH ??? > On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > So, my plan is remove gma500 stub driver at Dec. 2012. > > Why not just remove it right now as it's not needed at all anymore? > > thanks, > > greg k-h > > . Just I thought remove anything from kernel need add to schedule file first. OK, I will send another patch to direct remove it. Thanks Joey Lee
Re: [PATCH] gpu: remove gma500 stub driver
於 五，2012-05-25 於 16:07 +0900，Greg KH 提到： > On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > Cc: randy.dun...@oracle.com > > Cc: mj...@srcf.ucam.org > > Cc: gre...@suse.de > > Note, my email address has changed :) > Sorry~~~! I will keep in mind! :-) > Acked-by: Greg Kroah-Hartman > > Thanks a lot! Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: schedule gma500 stub driver for feature removal
於 五，2012-05-25 於 04:53 +0900，Greg KH 提到： > On Mon, May 21, 2012 at 11:23:36PM +0800, Lee, Chun-Yi wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > So, my plan is remove gma500 stub driver at Dec. 2012. > > Why not just remove it right now as it's not needed at all anymore? > > thanks, > > greg k-h > > . Just I thought remove anything from kernel need add to schedule file first. OK, I will send another patch to direct remove it. Thanks Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: schedule gma500 stub driver for feature removal
Hi Alex, ? ??2012-05-22 ? 12:01 -0400?Alex Deucher ??? > On Mon, May 21, 2012 at 11:15 AM, Lee, Chun-Yi > wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > So, my plan is remove gma500 stub driver at Dec. 2012. > > > December 2013? > > Alex My plan is December 2012, end of this year. Thanks Joey Lee > > > > Signed-off-by: Lee, Chun-Yi > > --- > > Documentation/feature-removal-schedule.txt | 11 +++ > > 1 files changed, 11 insertions(+), 0 deletions(-) > > > > diff --git a/Documentation/feature-removal-schedule.txt > > b/Documentation/feature-removal-schedule.txt > > index a0ffac0..219d6f1 100644 > > --- a/Documentation/feature-removal-schedule.txt > > +++ b/Documentation/feature-removal-schedule.txt > > @@ -524,3 +524,14 @@ Files: arch/arm/mach-at91/at91cap9.c > > Why: The code is not actively maintained and platforms are now hard to > > find. > > Who: Nicolas Ferre > >Jean-Christophe PLAGNIOL-VILLARD > > + > > + > > + > > +What: Intel GMA500 Stub Driver > > +When: December 2012 > > +Why: In v3.3, the gma500 drm driver moved from staging to drm group by > > + Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > + brightness well and don't need gma500 stub driver anymore. > > + > > + So, my plan is remove gma500 stub driver at Dec. 2012. > > +Who: Lee, Chun-Yi > > -- > > 1.6.0.2 > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
Re: [PATCH] gpu: schedule gma500 stub driver for feature removal
Hi Alex, 於 二，2012-05-22 於 12:01 -0400，Alex Deucher 提到： > On Mon, May 21, 2012 at 11:15 AM, Lee, Chun-Yi > wrote: > > In v3.3, the gma500 drm driver moved from staging to drm group by > > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > brightness well and don't need gma500 stub driver anymore. > > > > So, my plan is remove gma500 stub driver at Dec. 2012. > > > December 2013? > > Alex My plan is December 2012, end of this year. Thanks Joey Lee > > > > Signed-off-by: Lee, Chun-Yi > > --- > > Documentation/feature-removal-schedule.txt | 11 +++ > > 1 files changed, 11 insertions(+), 0 deletions(-) > > > > diff --git a/Documentation/feature-removal-schedule.txt > > b/Documentation/feature-removal-schedule.txt > > index a0ffac0..219d6f1 100644 > > --- a/Documentation/feature-removal-schedule.txt > > +++ b/Documentation/feature-removal-schedule.txt > > @@ -524,3 +524,14 @@ Files: arch/arm/mach-at91/at91cap9.c > > Why: The code is not actively maintained and platforms are now hard to > > find. > > Who: Nicolas Ferre > >Jean-Christophe PLAGNIOL-VILLARD > > + > > + > > + > > +What: Intel GMA500 Stub Driver > > +When: December 2012 > > +Why: In v3.3, the gma500 drm driver moved from staging to drm group by > > + Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > > + brightness well and don't need gma500 stub driver anymore. > > + > > + So, my plan is remove gma500 stub driver at Dec. 2012. > > +Who: Lee, Chun-Yi > > -- > > 1.6.0.2 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Fwd: Brightness on HP EliteBook 8460p
? ??2012-03-20 ? 23:03 +0100?Pali Roh?r ???
> >
> > Another doubt is the latest statement in _BCM, it emit a BEVT event:
> >
> > Signal (\_SB.BEVT)
> >
> > Only HKFR(HotkeyFunctionResponse) method is waiting this event, it
> > should related to how the HP implement brightness function key on
> > Windows through wmi.
> >
> > Of course this issue really close related to video driver, even
> > more, we might need to know hp wmi for how to implement on Windows.
> >
> > Unfortunately, sorry for I don't have any solution to you, now, I
> > will continue to trace and find any support from other experts.
> >
> >
> > Thanks a lot!
> > Joey Lee
>
> Hi!
>
> now I found that ALS button which enable/disable ambient light sensor
> working with linux and ALS can also decrease/increase brightness.
>
> ALS can be enabled or disabled via WMI (acpi) on linux too. I found
> function which enable ALS in linux kernel. See source code of function
> set_als in hp-wmi.c: http://tomoyo.sourceforge.jp/cgi-
> bin/lxr/source/drivers/platform/x86/hp-wmi.c#L443
>
> This function can enable ALS which can decrease brightness (but only
> to specific one level) via WMI. And WMI is ACPI extension, so maybe it
> is really possible to change brightness via acpi without DRI support.
>
> But I do not WMI, ACPI and DSDT code. Can you try to decode what is
> called in acpi when that set_als function in hp-wmi is called? I think
> here in acpi can be some magic which can manipulate with display
> brightness. At least ACPI must call somewhat to change brightness...
>
> Note: Enabling ALS on my notebook change brightness to some specific
> level and disabling ALS will revert brightness back. From userspace
> ALS can be enabled/disabled via this sysfs entry:
> /sys/devices/platform/hp-wmi/als
>
> --
> Pali Roh?r
> pali.rohar at gmail.com
Traced the your dsdt from 8460p.
Let's see "set ALS" first, when set ALS enable, BIOS didn't _eat_ any
input value for brightness level:
Method (WHCM, 2, NotSerialized)
{
CreateDWordField (Arg1, 0x00, SNIN) /* signature */
CreateDWordField (Arg1, 0x04, COMD) /* command = write ? 0x2 : 0x1
*/
CreateDWordField (Arg1, 0x08, CMTP) /* commandtype */
CreateDWordField (Arg1, 0x0C, DASI)
Store ("HandleWMICommand Enter", Debug)
...
If (LEqual (COMD, 0x02))/* command write */
{
Store ("write BIOS command", Debug)
If (LEqual (CMTP, 0x03))/* write HPWMI_ALS_QUERY 0x3 */
{
Store (^WSAL (DDWD), Local2) /* call ^WSAL and feed DDWD */
Store (0x00, RTCD)
}
Method (WSAL, 1, NotSerialized) /* write HPWMI_ALS_QUERY 0x3 */
{
If (LEqual (PRDT, 0x03))
{
Return (Package (0x02)
{
0x04,
0x00
})
}
\_SB.SSMI (0xEA75, 0x02, 0x03, 0x574D4953, 0x00) /* emit SMI,
BIOS code take job but didn't feed Arg0 to BIOS */
Return (WFDA ())
}
Everything handle by BIOS function after emit SMI event, and it didn't
give BIOS any input value of brightness.
So, didn't find any way to change brightness through set ALS.
Then, I found another interesting command for 'write brightness', hp-wmi
doesn't have implementation for this command:
If (LEqual (CMTP, 0x06))/* set brightness? */
{
Store ("write Brightness", Debug)
Store (^SBBC (DDWD), Local2)/* call DDWD */
Store (Local2, Debug)
Store (0x00, RTCD)
}
Method (SBBC, 1, NotSerialized) /* write brighenss? didn't do
anything? */
{
Return (Package (0x02) /* just only return a package */
{
0x04,
0x00
})
}
Unfortunately, the 0x06 command also doesn't do anything for change
brightness on your machine.
Sorry! Didn't find any way can change brightness on your machine unless
we have drm driver support ATI acpi events.
Thanks a lot!
Joey Lee
Re: Fwd: Brightness on HP EliteBook 8460p
於 二，2012-03-20 於 23:03 +0100，Pali Rohár 提到：
> >
> > Another doubt is the latest statement in _BCM, it emit a BEVT event:
> >
> > Signal (\_SB.BEVT)
> >
> > Only HKFR(HotkeyFunctionResponse) method is waiting this event, it
> > should related to how the HP implement brightness function key on
> > Windows through wmi.
> >
> > Of course this issue really close related to video driver, even
> > more, we might need to know hp wmi for how to implement on Windows.
> >
> > Unfortunately, sorry for I don't have any solution to you, now, I
> > will continue to trace and find any support from other experts.
> >
> >
> > Thanks a lot!
> > Joey Lee
>
> Hi!
>
> now I found that ALS button which enable/disable ambient light sensor
> working with linux and ALS can also decrease/increase brightness.
>
> ALS can be enabled or disabled via WMI (acpi) on linux too. I found
> function which enable ALS in linux kernel. See source code of function
> set_als in hp-wmi.c: http://tomoyo.sourceforge.jp/cgi-
> bin/lxr/source/drivers/platform/x86/hp-wmi.c#L443
>
> This function can enable ALS which can decrease brightness (but only
> to specific one level) via WMI. And WMI is ACPI extension, so maybe it
> is really possible to change brightness via acpi without DRI support.
>
> But I do not WMI, ACPI and DSDT code. Can you try to decode what is
> called in acpi when that set_als function in hp-wmi is called? I think
> here in acpi can be some magic which can manipulate with display
> brightness. At least ACPI must call somewhat to change brightness...
>
> Note: Enabling ALS on my notebook change brightness to some specific
> level and disabling ALS will revert brightness back. From userspace
> ALS can be enabled/disabled via this sysfs entry:
> /sys/devices/platform/hp-wmi/als
>
> --
> Pali Rohár
> pali.ro...@gmail.com
Traced the your dsdt from 8460p.
Let's see "set ALS" first, when set ALS enable, BIOS didn't _eat_ any
input value for brightness level:
Method (WHCM, 2, NotSerialized)
{
CreateDWordField (Arg1, 0x00, SNIN) /* signature */
CreateDWordField (Arg1, 0x04, COMD) /* command = write ? 0x2 : 0x1
*/
CreateDWordField (Arg1, 0x08, CMTP) /* commandtype */
CreateDWordField (Arg1, 0x0C, DASI)
Store ("HandleWMICommand Enter", Debug)
...
If (LEqual (COMD, 0x02))/* command write */
{
Store ("write BIOS command", Debug)
If (LEqual (CMTP, 0x03))/* write HPWMI_ALS_QUERY 0x3 */
{
Store (^WSAL (DDWD), Local2) /* call ^WSAL and feed DDWD */
Store (0x00, RTCD)
}
Method (WSAL, 1, NotSerialized) /* write HPWMI_ALS_QUERY 0x3 */
{
If (LEqual (PRDT, 0x03))
{
Return (Package (0x02)
{
0x04,
0x00
})
}
\_SB.SSMI (0xEA75, 0x02, 0x03, 0x574D4953, 0x00) /* emit SMI,
BIOS code take job but didn't feed Arg0 to BIOS */
Return (WFDA ())
}
Everything handle by BIOS function after emit SMI event, and it didn't
give BIOS any input value of brightness.
So, didn't find any way to change brightness through set ALS.
Then, I found another interesting command for 'write brightness', hp-wmi
doesn't have implementation for this command:
If (LEqual (CMTP, 0x06))/* set brightness? */
{
Store ("write Brightness", Debug)
Store (^SBBC (DDWD), Local2)/* call DDWD */
Store (Local2, Debug)
Store (0x00, RTCD)
}
Method (SBBC, 1, NotSerialized) /* write brighenss? didn't do
anything? */
{
Return (Package (0x02) /* just only return a package */
{
0x04,
0x00
})
}
Unfortunately, the 0x06 command also doesn't do anything for change
brightness on your machine.
Sorry! Didn't find any way can change brightness on your machine unless
we have drm driver support ATI acpi events.
Thanks a lot!
Joey Lee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]
Add Cc. to platform-driver-x86 and linux-acpi Hi Baptiste ? ??2011-12-04 ? 17:07 +0100?Baptiste Jonglez ??? > Hi, > > I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't > have a keyboard, but two displays with touchscreens) > > The Intel GPU is integrated into the Core i5-480M CPU: it's a bit > older than Sandybridge, as it seems to be based on the Arrandale > micro-architecture. > > In the BIOS, both displays work fine; but as soon as the kernel boots > up, the second display (i.e. the one where you usually find a > keyboard) is turned off. The main display works as expected. > > xrandr reports two LVDS displays: LVDS1, which is connected, and > LVDS2, which is marked as "disconnected". No matter what I tried, I > can't bring that second display up. > > During the boot, just after the drm is set up, the following message > shows up: > > [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions > > (attached is the relevant part of dmesg [1]) > > Have no idea for this _DSM error, need help from drm and acpi experts. > > I then tried booting with "video=LVDS-2:e". The same message shows up > while booting, with these two following: > > [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:4] > fbcon_init: detected unhandled fb_set_par error, error code -22 > > (attached is the relevant part of dmesg [2]) > > With that kernel command line forcing LVDS2, the > "drm_crtc_helper_set_config" error shows up each time I switch tty; > additionally, X does not want to start anymore (spewing out the > aforementioned error multiple times before giving up) > > > I'm currently using the latest 3.2 kernel from linus' tree > (af968e29acd91ebeb4224e899202c46c93171ecd), but the behavior was > similar with a vanilla 3.1.2. > > > Other notes about this issue: > > - with an Ubuntu 2.6.35 kernel, the second display is on but >flickering (with the picture distorted like an old analog TV...). >The main display is working fine, as always. > > - with an Archlinux 2.6.37.5 kernel, the behavior is the same as with >3.2, the main display is ok and the second one is off. > > - I did succeed, only once and out of pure luck, to get the second >screen to work with the 3.1.2 kernel. I haven't been able to >reproduce that... I had booted with "video=LVDS-2:e" and let the >laptop running ; pressing a key a few hours later turned back >*both* displays on (the main display had been turned off by DPMS, >and the second, well, was off from the start, as always) >While not very helpful, it shows that it's definitely possible. > What does Windows platform's behavior? Does there have any physical key that can turn on/off the second LVDS on Windows? > - there are a some unhandled WMI events logged from the acer-wmi >module [3] when closing the lid, opening it, and most importantly, >when the (main) screen is turned on or off by DPMS. > I will look at your dsdt and log from acer-wmi then try to improve acer-wmi. > > > What do you think? I haven't really succeeded in nailing the source of > the issue down, but here are a few possibilities I'm thinking of: > > - the driver is not aware it can drive two LVDS displays (not very >likely, and it has worked once, see above) > > - there is some kind of switch that is able to turn the second screen >on or off (I'm thinking of something like rfkill). If so, it looks >like something non-standard and undocumented. This would explain >the WMI events (see the last note above) > What's the behavior of Windows? > - buggy ACPI implementation. I tried to extract then recompile the >DSDT [4], and iasl spews out 17 errors and 12 warnings. Also worth >noticing is that line in dmesg: > "pci:00: ACPI _OSC request failed (AE_ERROR), returned control mask: 0x1d" > > > The Archlinux userland is: > - libdrm 2.4.27 > - xorg-server 1.11.2 > - intel-dri 7.11.1 > - xf86-video-intel 2.17.0 > > > Please let me know if there are any other details I should provide. > Regards, > Baptiste > > Attachments: > [1] dmesg-DSM-functions.log - drm errors when booting normally > [2] dmesg-video-lvds2.log - drm errors when forcing LVDS2 on the cmdline > [3] acer_wmi.log - WMI events that land in dmesg > [4] dsdt - /sys/firmware/acpi/tables/DSDT Please also attached on dmidecode log. Thank's a lot! Joey Lee
Re: [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]
Add Cc. to platform-driver-x86 and linux-acpi Hi Baptiste 於 日，2011-12-04 於 17:07 +0100，Baptiste Jonglez 提到： > Hi, > > I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't > have a keyboard, but two displays with touchscreens) > > The Intel GPU is integrated into the Core i5-480M CPU: it's a bit > older than Sandybridge, as it seems to be based on the Arrandale > micro-architecture. > > In the BIOS, both displays work fine; but as soon as the kernel boots > up, the second display (i.e. the one where you usually find a > keyboard) is turned off. The main display works as expected. > > xrandr reports two LVDS displays: LVDS1, which is connected, and > LVDS2, which is marked as "disconnected". No matter what I tried, I > can't bring that second display up. > > During the boot, just after the drm is set up, the following message > shows up: > > [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions > > (attached is the relevant part of dmesg [1]) > > Have no idea for this _DSM error, need help from drm and acpi experts. > > I then tried booting with "video=LVDS-2:e". The same message shows up > while booting, with these two following: > > [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:4] > fbcon_init: detected unhandled fb_set_par error, error code -22 > > (attached is the relevant part of dmesg [2]) > > With that kernel command line forcing LVDS2, the > "drm_crtc_helper_set_config" error shows up each time I switch tty; > additionally, X does not want to start anymore (spewing out the > aforementioned error multiple times before giving up) > > > I'm currently using the latest 3.2 kernel from linus' tree > (af968e29acd91ebeb4224e899202c46c93171ecd), but the behavior was > similar with a vanilla 3.1.2. > > > Other notes about this issue: > > - with an Ubuntu 2.6.35 kernel, the second display is on but >flickering (with the picture distorted like an old analog TV...). >The main display is working fine, as always. > > - with an Archlinux 2.6.37.5 kernel, the behavior is the same as with >3.2, the main display is ok and the second one is off. > > - I did succeed, only once and out of pure luck, to get the second >screen to work with the 3.1.2 kernel. I haven't been able to >reproduce that... I had booted with "video=LVDS-2:e" and let the >laptop running ; pressing a key a few hours later turned back >*both* displays on (the main display had been turned off by DPMS, >and the second, well, was off from the start, as always) >While not very helpful, it shows that it's definitely possible. > What does Windows platform's behavior? Does there have any physical key that can turn on/off the second LVDS on Windows? > - there are a some unhandled WMI events logged from the acer-wmi >module [3] when closing the lid, opening it, and most importantly, >when the (main) screen is turned on or off by DPMS. > I will look at your dsdt and log from acer-wmi then try to improve acer-wmi. > > > What do you think? I haven't really succeeded in nailing the source of > the issue down, but here are a few possibilities I'm thinking of: > > - the driver is not aware it can drive two LVDS displays (not very >likely, and it has worked once, see above) > > - there is some kind of switch that is able to turn the second screen >on or off (I'm thinking of something like rfkill). If so, it looks >like something non-standard and undocumented. This would explain >the WMI events (see the last note above) > What's the behavior of Windows? > - buggy ACPI implementation. I tried to extract then recompile the >DSDT [4], and iasl spews out 17 errors and 12 warnings. Also worth >noticing is that line in dmesg: > "pci:00: ACPI _OSC request failed (AE_ERROR), returned control mask: 0x1d" > > > The Archlinux userland is: > - libdrm 2.4.27 > - xorg-server 1.11.2 > - intel-dri 7.11.1 > - xf86-video-intel 2.17.0 > > > Please let me know if there are any other details I should provide. > Regards, > Baptiste > > Attachments: > [1] dmesg-DSM-functions.log - drm errors when booting normally > [2] dmesg-video-lvds2.log - drm errors when forcing LVDS2 on the cmdline > [3] acer_wmi.log - WMI events that land in dmesg > [4] dsdt - /sys/firmware/acpi/tables/DSDT Please also attached on dmidecode log. Thank's a lot! Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
