This commit introduces a bug that prevents backlight control from either hotkeys or xbacklight. The video adapter is a Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c).
6d5bbf00d251cc73223a71422d69e069dc2e0b8d is the first bad commit
Author: Len Brown <firstname.lastname@example.org>
Date: Fri Jan 7 01:46:40 2011 +0100
ACPI: Use ioremap_cache()
Although the temporary boot-time ACPI table mappings
were set up with CPU caching enabled, the permanent table
mappings and AML run-time region memory accesses were
set up with ioremap(), which on x86 is a synonym for
Changing this to ioremap_cache() improves performance as
seen when accessing the tables via acpidump,
or /sys/firmware/acpi/tables. It should also improve
AML run-time performance.
No change on ia64.
Reported-by: Jack Steiner <email@example.com>
Signed-off-by: Len Brown <firstname.lastname@example.org>
Signed-off-by: Rafael J. Wysocki <email@example.com>
:040000 040000 2657fb60f4b7176b4c3599d8723222eef4c6c58d a0aa669cc80f2804ebc73818e8df16d7cc147cdf M arch
:040000 040000 a27e58b84f29112d0d2717d71e52fafba08cfdaf 3c51f290a55060d35f04cc1a8768c3b0b5b68b36 M drivers
as there have been a couple of changes in this area,
please verify that the problem is still there with 2.6.38-rc2
please attach the output from acpidump
Confirmed on 2.6.38-rc2 to be still present.
Created attachment 44972 [details]
output of acpidump | cat > acpidump.txt
Please verify that replacing ioremap_cache() with ioremap() in
include/linux/acpi_io.h:acpi_os_ioremap() fixes the issue for you.
Does there exist the interface of /sys/class/backlight/*/brightness ? Can the brightness be changed by using /sys/class/backlight/*/brightness?
>echo X > /sys/class/backlight/*/brightness
Testing with 2.6.38-rc2:
/sys/class/backlight/sony/brightness exists but writing values to it changes nothing (backlight burns at 100% regardless of the value held by brightness file).
In response to Rafael in comment #4 above, yes, making that replacement fixes the issue for me.
From the acpidump it seems that SMI operation will be executed when trying to change the brightness level. And the following memory opregion in AML code is used in couse of triggering SMI.
>OperationRegion (SMI0, SystemMemory, 0xBF6DEB38, 0x00000415)
Field (SMI0, AnyAcc, NoLock, Preserve)
Before the commit 6d5bbf00d, the corresponding memory is mapped as uncacheable. After it is mapped as cacheable, it is not clear whether the system still can keep the cache coherent after triggering the SMI operation. Maybe it is safer to still map them as uncacheable.
I agree, but the question is what we should do now.
I think that operation regions should be mapped as uncacheable, so we'll
need a special OS callback for mapping them. I'll try to prepare a patch for
This bug is gone in 2.6.38-rc3. Is this expected, or should I reverse bisect to find the commit that fixed it?
Well, if you could do that, I would appreciate it.
I _think_ it has been fixed by one of the i915 changes that went in after -rc2.
Anyway, I'm closing the bug as fixed.
This bug was fixed by:
Author: Michael Karcher <firstname.lastname@example.org>
Date: Sun Jan 23 18:17:17 2011 +0000
drm/i915: Use consistent mappings for OpRegion between ACPI and i915
The opregion is a shared memory region between ACPI and the graphics
driver. As the ACPI mapping has been changed to cachable in commit
6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
non-cachable now fails. As no bus-master hardware is involved in the
opregion, cachable map should do no harm.
Tested on a Fujitsu Lifebook P8010.
Signed-off-by: Michael Karcher <email@example.com>
[ickle: convert to acpi_os_ioremap for consistency]
Signed-off-by: Chris Wilson <firstname.lastname@example.org>
:040000 040000 fc5080e1daa2c8d8e113ee0c71c9a267e524520c 192d5b3b1f7f2c6665a8a7f51b5af30e868963d9 M drivers
Thanks for digging that up. I just tried to trace if it was queued for stable, but it seems to have not yet been included. But I found a bisection result returning this commit on lkml... so maybe it shouldn't go to stable? or at least needs a fixup patch on top.
Chris, do you already track this for stable? Or by chance now the correct patch sequence to go to stable?
ok, never mind. This was fixed in time for 2.6.38, so all is well, no need to backport it.