Re: drivers/platform/x86: Backlight-Add-backlight-type-v2.patch
Hi Corentin, 於 三，2010-10-27 於 13:39 +0200，Corentin Chary 提到： On Wed, Oct 27, 2010 at 1:06 PM, Sedat Dilek sedat.di...@googlemail.com wrote: Hi, while testing linux-next I wanted to reactivate the backlight type patches laying in my build-dir. Within 2.6.36-rcX cycle I had successfully tested the backlight type patch [1] with an additional patch for radeon by Michel (posted to dri-devel ML, see [2]). The main patch needs a little refreshing. v2: drivers/platform/x86/asus-laptop.c: Refreshed to fit linux-next (next-20101027) Kind Regards, - Sedat - [1] https://patchwork.kernel.org/patch/163971/ [2] https://patchwork.kernel.org/patch/182352/ Hi, I think rfkill has the same problem, on some platforms, the platform driver will add a rfkill switch, but the network (wlan/wimax/whatever) driver may also add one. AFAIK, the platform one is more likely to be able to power down the device completly. Agreed your point! x86/laptop or wmi driver borrow rfkill interface for power control but confuse with userland applications. Thank's Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add Intel GMA500(Poulsbo) Stub Driver
Hi Rui,
First, thank's for your review and take care.
於 五，2010-11-12 於 09:31 +0800，Zhang Rui 提到：
Hi, Lee,
there are several regressions caused by this patch,
http://marc.info/?l=linux-acpim=128872402020412w=2
http://marc.info/?l=linux-acpim=128858111022621w=2
Yes, We can fix it by select INPUT if ACPI/select
VIDEO_OUTPUT_CONTROL if ACPI.
But IMO, STUB_POULSBO should not select ACPI_VIDEO at all,
what do you think?
Yes, I agreed.
We can just remove the _select ACPI_VIDEO if ACPI_ because user should
select it when they want to use.
If CONFIG_ACPI_VIDEO doesn't select, the stub poulsbo just do _not_
thing but will have no any bad thing.
So, let's direct remove it from Kconfig. Should I submit patch again?
Thank's
Joey Lee
thanks,
rui
On Wed, 2010-11-03 at 09:19 +0800, Zhang Rui wrote:
Hi, Lee,
Sorry I missed this thread.
On Wed, 2010-10-20 at 13:51 +0800, Lee, Chun-Yi wrote:
Currently, there have no GMA500(Poulsbo) native video driver to support
intel opregion. So, use this stub driver to enable the acpi backlight
control sysfs entry files by requrest acpi_video_register.
If you want the acpi backlight control, why not set CONFIG_ACPI_VIDEO
driver directly?
The reason why i915 driver selects ACPI_VIDEO is that it needs some
cooperation between these two drivers during initialization, or else the
system may hang.
thanks,
rui
Signed-off-by: Lee, Chun-Yi j...@novell.com
---
drivers/gpu/Makefile |2 +-
drivers/gpu/stub/Kconfig | 13 +
drivers/gpu/stub/Makefile |1 +
drivers/gpu/stub/poulsbo.c | 63
drivers/video/Kconfig |2 +
5 files changed, 80 insertions(+), 1 deletions(-)
create mode 100644 drivers/gpu/stub/Kconfig
create mode 100644 drivers/gpu/stub/Makefile
create mode 100644 drivers/gpu/stub/poulsbo.c
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index 30879df..cc92778 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y+= drm/ vga/
+obj-y+= drm/ vga/ stub/
diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig
new file mode 100644
index 000..8f5a540
--- /dev/null
+++ b/drivers/gpu/stub/Kconfig
@@ -0,0 +1,13 @@
+config STUB_POULSBO
+ tristate Intel GMA500 Stub Driver
+ depends on PCI
+# Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
+# but for select to work, need to select ACPI_VIDEO's
dependencies, ick
+select ACPI_VIDEO if ACPI
+ help
+ Choose this option if you have a system that has Intel GMA500
+ (Poulsbo) integrated graphics. If M is selected, the module will
+ be called Poulsbo. This driver is a stub driver for Poulsbo that
+ will call poulsbo.ko to enable the acpi backlight control sysfs
+ entry file because there have no poulsbo native driver can support
+ intel opregion.
diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile
new file mode 100644
index 000..cd940cc
--- /dev/null
+++ b/drivers/gpu/stub/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_STUB_POULSBO) += poulsbo.o
diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
new file mode 100644
index 000..d8aa636
--- /dev/null
+++ b/drivers/gpu/stub/poulsbo.c
@@ -0,0 +1,63 @@
+/*
+ * Intel Poulsbo Stub driver
+ *
+ * Copyright (C) 2010 Novell j...@novell.com
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ */
+
+#include linux/module.h
+#include linux/pci.h
+#include acpi/video.h
+
+#define DRIVER_NAME poulsbo
+
+enum {
+ CHIP_PSB_8108 = 0,
+ CHIP_PSB_8109 = 1,
+};
+
+static struct pci_device_id pciidlist[] = {
+ {0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
+ {0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
+ {0, 0, 0}
+};
+
+static int poulsbo_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
+{
+ return acpi_video_register();
+}
+
+static void poulsbo_remove(struct pci_dev *pdev)
+{
+ acpi_video_unregister();
+}
+
+static struct pci_driver poulsbo_driver = {
+ .name = DRIVER_NAME,
+ .id_table = pciidlist,
+ .probe = poulsbo_probe,
+ .remove = poulsbo_remove,
+};
+
+static int __init poulsbo_init(void)
+{
+ return pci_register_driver(poulsbo_driver);
+}
+
+static void __exit poulsbo_exit(void)
+{
+ pci_unregister_driver(poulsbo_driver);
+}
+
+module_init(poulsbo_init);
+module_exit(poulsbo_exit);
+
+MODULE_AUTHOR(Lee, Chun-Yi j...@novell.com);
+MODULE_DESCRIPTION(Poulsbo Stub Driver
Re: i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)
Hi Melchior, 於 六，2011-04-30 於 13:34 +0200，Melchior FRANZ 提到： Dropping Linus from the CC. * Takashi Iwai -- Saturday 30 April 2011: * * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote: Yes, backlight adjustment generally works on this notebook, but only with acpi_osi=Linux on the command line. acpi_osi quirk should be better added statically, then. No, I guess the problem here is that acer_wmi doesn't support this machine yet. I told the ACER WMI maintainer and sent a DSDT image, but this message was thoroughly ignored. $ dmesg|grep -i acer [0.00] DMI: Acer TM5735/BA51_MV, BIOS V1.04 09/23/2010 [ 71.850534] acer_wmi: Acer Laptop ACPI-WMI Extras [ 72.350278] acer_wmi: Unable to detect available WMID devices Machine: Acer Travelmate 5735Z-452G32Mnss m. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Could you please attach DSDT on this mail or share your kernel bugzilla number to us? I found cann't access BKO now? Thank's Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)
Hi Melchior, 於 一，2011-05-02 於 14:08 +0200，Takashi Iwai 提到： At Sat, 30 Apr 2011 13:34:51 +0200, Melchior FRANZ wrote: Dropping Linus from the CC. * Takashi Iwai -- Saturday 30 April 2011: * * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote: Yes, backlight adjustment generally works on this notebook, but only with acpi_osi=Linux on the command line. acpi_osi quirk should be better added statically, then. No, I guess the problem here is that acer_wmi doesn't support this machine yet. I told the ACER WMI maintainer and sent a DSDT image, but this message was thoroughly ignored. $ dmesg|grep -i acer [0.00] DMI: Acer TM5735/BA51_MV, BIOS V1.04 09/23/2010 [ 71.850534] acer_wmi: Acer Laptop ACPI-WMI Extras [ 72.350278] acer_wmi: Unable to detect available WMID devices Machine: Acer Travelmate 5735Z-452G32Mnss Hm, but the backlight control is done via the standard ACPI, no? If so, the fact that acer_wmi doesn't work sounds irrelevant. BTW, did you try my previous patch? Takashi Yes, please try Takashi's previous patch. I am tracing bko#34142, but this issue does not related to your backlight control, because there have _BCM, _BQC declare in your DSDT, your machine MUST SUPPORTED by standard acpi backlight interface. Even the acer-wmi can probed on your machine, it cann't help anything for your backlight control. Thank's a lot! Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem
Hi Melchior, 於 五，2011-05-06 於 10:52 +0200，Melchior FRANZ 提到： * Melchior FRANZ -- Thursday 05 May 2011: This revised patch works correctly for me. ... and changing backlight brightness worked with acpi_osi=Linux, too. Unfortunately, that does no longer work now, although I haven't changed anything. Pressing the brightness buttons causes some ACPI debug output, but it doesn't adjust anything. m. hmm Takashi's patch works before, but doesn't work now? Does that because my new patch for bko#34142 ? Could you please add acer-wmi to /etc/modprobe.d/blacklist then reboot machine ? Step: - add acer-wmi to /etc/modprobe.d/blacklist - shutdown your machine - remove AC power and notebook's battery - plugin AC power then boot your notebook - check the brightness control Thank's Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem
於 六，2011-05-07 於 22:22 +0200，Melchior FRANZ 提到： * Melchior FRANZ -- Friday 06 May 2011: last patch prevents the backlight from being turned off, but it also breaks the brightness adjustment keys at runtime with acpi_osi=Linux. It has turned out that acpi key events seem to be handled correctly and even the state of /sys/class/backlight/acer-wmi/brightness is That's interesting for acer-wmi generated brightness interface when this machine declare acpi brightness interface in DSDT. updated accordingly. The only problem is that this maintained Does it work to you direct control brightness by access by /sys/class/backlight/acer-wmi/brightness ? brightness state isn't applied to the actual backlight. It remains at highest level. Google pointed me to this workaround for another Acer notebook: https://help.ubuntu.com/community/AspireTimeline/Fixes#Alternative%20fix%20for%2010.10 This uses the acpid to write the brightness value to the display using setpci. And this works on my notebook as well (Acer Travelmate As I remember, use setpci to control brightness is not recommended because BIOS or ACPI will also touch brightness level. That will be better control brightness by the function that was provided by BIOS. e.g. ACPI or WMI interface, or direct control by EC. That means that will be better fix your Fn key control brightness like before, you just need press Fn key to change brightness and don't need have any workaround. 5735Z-452G32Mnss). Not pretty but better than nothing. Is Acer not able to build proper notebooks? Or is it a kernel bug? m. Looks like current status is we try to fix bko#31522 but the patch causes your brightness no work by press Fn key even with acpi_osi=Linux. Does it right? Could you please also help to check: replace acpi_osi=Linux by acpi_osi=!Windows 2006 Does it also works to you for backlight control? Thank's Joey Lee ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem
於 一，2011-05-09 於 11:00 +0200，Takashi Iwai 提到：
At Mon, 09 May 2011 02:50:50 -0600,
Joey Lee wrote:
We need to know some run time value when intel_panel_set_backlight call by
funciton key.
Yes, that'll help understanding.
Please help to apply the attached debug patch to intel_panel.c then
attached dmesg.
The patch has an obvious typo :)
Also, we should track the value in intel_panel_get_backlight(), too.
Takashi
Thank's for Takashi's review and sorry for my typo.
Follow Takashi's suggestion, I added a debug message in get_backlight,
the following is new debug patch:
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index f8f86e5..9695840 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -199,6 +199,7 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CPU_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
} else {
val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
+ DRM_DEBUG_DRIVER(get backlight val = %d\n, val);
if (IS_PINEVIEW(dev))
val = 1;
@@ -236,17 +237,22 @@ void intel_panel_set_backlight(struct drm_device *dev,
u32 level)
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;
+ DRM_DEBUG_DRIVER(set backlight max = %d\n, max);
lbpc = level * 0xfe / max + 1;
+ DRM_DEBUG_DRIVER(set backlight lbpc = %d\n, lbpc);
level /= lbpc;
pci_write_config_byte(dev-pdev, PCI_LBPC, lbpc);
}
tmp = I915_READ(BLC_PWM_CTL);
+ DRM_DEBUG_DRIVER(set backlight tmp(1) = %d\n, tmp);
if (IS_PINEVIEW(dev)) {
tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level = 1;
} else
tmp = ~BACKLIGHT_DUTY_CYCLE_MASK;
+ DRM_DEBUG_DRIVER(set backlight tmp(2) = %d\n, tmp);
+ DRM_DEBUG_DRIVER(set backlight level = %d\n, level);
I915_WRITE(BLC_PWM_CTL, tmp | level);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915/kms/backlight-combo mode problem
Forward to upstream for more discussion. 於 五，2011-05-13 於 17:27 +0800，Michael Chang 提到： Melchior, I tried to puzzle out the possible cause of the problem, but sorry that no further progress to give you. I'd like to debug this issue, also did Joey. But there's more questions in my mind, made me feel not able to proceed any further.. :( 1. is_backlight_combination_mode() really returns 0x4 ..? I understand your words, but if this is true then Joey Lee provided patch should log out some information about changing the LPBC set backlight lbpc = ... but I didn't see any of the log output .. :( 2. I dig the old mailing thread .. found a post http://marc.info/?l=linux-kernelm=130462815211684w=2 If you rebase this patch to your currently git commit, will it fixes all problems for you now (only vanilla kernel with this patch)? (You replied that this patch works for you ..) Also another interesting finding... + if (!lbpc) + combo_mode = 0; Looks like the purpose of it is to NOT touch the LPBC registers if lbpc is zero ...(since this forces is_backlight_combination_mode return 0). This would make contradiction about the assumption that you could change to back-light via LPBC .. (using setpci is actually access the LPBC registers .. IMHO). Total a mess for me now .. Did I made anything wrong .. I know I may lose some details. I'm thinking is it ok for us to discuss in IRC, the communication would be more efficient. Would this be convenient for you ? This is up to you. Have nice weekend .. :) Regards, Michael Chang 2011/5/10 Melchior FRANZ melchior.fr...@gmail.com: * Michael Chang -- Tuesday 10 May 2011: Could you please try this patch and get the log ? We wonder why is_backlight_combination_mode () returns false. This information was already buried in the bugzilla thread: https://bugzilla.kernel.org/show_bug.cgi?id=31522 It turned out that on this machine INTEL_INFO(dev)-gen equals 4, and is_backlight_combination_mode() returns 0x4000. But to say it again in your words: :-) [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 (0x4000) 6x during boot-up, and several times later when changing the backlight brightness. This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now I have a little shocker for you (and me): because this was a vanilla kernel (apart from these debug messages), the screen went black again, like I knew it. But pressing the brightness down key turns the backlight on! I can't believe that I haven't tested that. I guess I've only tried brightness up and display toggle. Those don't turn backlight on. Or maybe somethine else relevant meanwhile changed in the i915 drivers. (I've regularly been updating to HEAD.) So, the problem was just the initial state all the time? m. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: Brightness on HP EliteBook 8460p
Add Cc. to dri mail
Hi Pali,
於 五，2012-02-03 於 16:24 +0100，Pali Rohár 提到：
On Friday 20 January 2012 17:55:57 Pali Rohár wrote:
On Friday 20 January 2012 11:28:59 joeyli wrote:
於 五，2012-01-20 於 11:12 +0800，joeyli 提到：
Hi Pali,
Sorry for I am late reply you.
於 二，2012-01-17 於 19:10 +0100，Pali Rohár 提到：
On Wednesday 21 December 2011 12:45:07 Pali Rohár wrote:
Hello,
I tried to boot with all 3 strings in acpi_os_name, but nothing was
changed. I'm attaching dmesg outputs, one from BIOS mode, one from
UEFI mode. Both are with Microsoft Windows NT.
Did you looked at my logs?
I checked your dmesg log, found the acpi_os_name kernel parameter is :
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-generic
root=UUID=4ec6272a-8551-40f3-a1b1-3e10984f3e69 ro pcie_aspm=force
acpi.debug_level=0x2 acpi.debug_layer=0x acpi_os_name=Microsoft
Windows NT splash vt.handoff=7
We still need by-pass the os name check in DSDT when test function key,
please help to feed:
acpi_os_name=Windows 2009
And,
looks like the acpi debug level not enough, please kindly change acpi
debug parameter to:
acpi.debug_level=0xF acpi.debug_layer=0x log_buf_len=5M
summary:
acpi.debug_level=0xF acpi.debug_layer=0x log_buf_len=5M
acpi_os_name=Windows 2009
Forgot remind,
please remember press brightness function key a couple of times before
you dump the dmesg and messages log.
Thanks a lot!
Joey Lee
Hello,
there was no acpi log, so I recompiled ubuntu kernel with
CONFIG_ACPI_DEBUG=y and CONFIG_ACPI_DEBUG_FUNC_TRACE. Then I started kernel
with your params.
Now I'm attaching very long debug output. I belive it will be now usefull.
Pressing brightness keys did not show anything in log.
After writing 0 to /sys/class/backlight/acpi_video0/brightness in log
appear: [ 57.675070] [ACPI Debug] Integer 0x000B
...
And after writing 10:
[ 99.865208] [ACPI Debug] Integer 0x0048
[ 99.865295] evmisc-0120 [4294967289] ev_queue_notify_reques:
Dispatching Notify on [DGFX] Node 880136246c80 Value 0xD0 (**Device
Specific**) [ 99.865350]video-1474 [4294967289] video_bus_notify
: Unsupported event [0xd0]
Do you need more logs? Or is this enought?
Yes, as you point out, this is a doubt for video bus received 0xD0 event
but nobody take care it.
Traced dsdt of EliteBook 8460p from you, the _BCM like this:
Method (_BCM, 1, Serialized)/* ATI _BCM, per log, run this
_BCM */
{
Store (\_SB.BCM (Arg0), Local0) /* set next level, normally
return 0x1 if XP sp2 or later */
If (Local0) /* if XP sp2 or later */
{
Store (BRID, Local1)
If (LEqual (SBRV (), 0x00)) /* normally SBRV return 1, will
not emit SMI */
{
\_SB.SSMI (0xEA74, 0x04, Local1, 0x00, 0x00)
}
Signal (\_SB.BEVT) /* emit BEVT event, HKFR
(HotkeyFunctionResponse) waiting it, but why? */
}
}
_BCM call SBRV to setup brightness value to variable ABRI:
Method (SBRV, 0, Serialized)/* call by ATI _BCM */
{
Store (\_SB.SBRC (), ABRI) /* SBRC() return the brightness value,
why store to ABRI? only used in PEGP.DGFX.AFN2 */
Or (PSBR, 0x80, PSBR)
Notify (^, 0xD0)/* notify method's parent: PEGP.DGFX by
0xD0 */
Return (0x01) /* normally return 1 */
}The PEGP.DGFX acpi device was binding to acpi/video driver, the above
ASL code emit a 0xD0 bus event to video.c but cann't process it. Even we
add a new bus event in video.c and generate a acpi event, there still
need another acpi driver should take care it.
I thought this acpi event might need take care by radeon drm, but I am
not good for radeon, need more help.
Per your acpi debug log, the brightness value was changed normally when
you access _BCM:
83133 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674669] ACPI: Execute
Method [\_SB_.PCI0.PEGP.DGFX.LCD_._BCM] (Node 8 801362472a8) #
start test _BCM manually
83134 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674736] exregion-0199 [01]
ex_system_memory_space: System-Memory (width 8 ) R/W 0
Address=BF7ACE1C
83135 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674748] exregion-0199 [02]
ex_system_memory_space: System-Memory (width 8 ) R/W 1
Address=BF7ACE1C
...
83179 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.675070] [ACPI Debug]
Integer 0x000B# brightness value is 11
83180 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.675090] evmisc-0120
[4294967289] ev_queue_notify_reques: Dispatching No tify on [DGFX] Node
Re: Fwd: Brightness on HP EliteBook 8460p
Hi Artur,
於 六，2012-02-04 於 20:19 -0700，Joey Lee 提到：
Add Cc. to dri mail
Hi Pali,
於 五，2012-02-03 於 16:24 +0100，Pali Rohár 提到：
On Friday 20 January 2012 17:55:57 Pali Rohár wrote:
On Friday 20 January 2012 11:28:59 joeyli wrote:
於 五，2012-01-20 於 11:12 +0800，joeyli 提到：
Hi Pali,
Sorry for I am late reply you.
於 二，2012-01-17 於 19:10 +0100，Pali Rohár 提到：
On Wednesday 21 December 2011 12:45:07 Pali Rohár wrote:
Hello,
I tried to boot with all 3 strings in acpi_os_name, but nothing
was
changed. I'm attaching dmesg outputs, one from BIOS mode, one from
UEFI mode. Both are with Microsoft Windows NT.
Did you looked at my logs?
I checked your dmesg log, found the acpi_os_name kernel parameter is :
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-generic
root=UUID=4ec6272a-8551-40f3-a1b1-3e10984f3e69 ro pcie_aspm=force
acpi.debug_level=0x2 acpi.debug_layer=0x
acpi_os_name=Microsoft
Windows NT splash vt.handoff=7
We still need by-pass the os name check in DSDT when test function
key,
please help to feed:
acpi_os_name=Windows 2009
And,
looks like the acpi debug level not enough, please kindly change acpi
debug parameter to:
acpi.debug_level=0xF acpi.debug_layer=0x log_buf_len=5M
summary:
acpi.debug_level=0xF acpi.debug_layer=0x log_buf_len=5M
acpi_os_name=Windows 2009
Forgot remind,
please remember press brightness function key a couple of times before
you dump the dmesg and messages log.
Thanks a lot!
Joey Lee
Hello,
there was no acpi log, so I recompiled ubuntu kernel with
CONFIG_ACPI_DEBUG=y and CONFIG_ACPI_DEBUG_FUNC_TRACE. Then I started
kernel
with your params.
Now I'm attaching very long debug output. I belive it will be now usefull.
Pressing brightness keys did not show anything in log.
After writing 0 to /sys/class/backlight/acpi_video0/brightness in log
appear: [ 57.675070] [ACPI Debug] Integer 0x000B
...
And after writing 10:
[ 99.865208] [ACPI Debug] Integer 0x0048
[ 99.865295] evmisc-0120 [4294967289] ev_queue_notify_reques:
Dispatching Notify on [DGFX] Node 880136246c80 Value 0xD0 (**Device
Specific**) [ 99.865350]video-1474 [4294967289] video_bus_notify
: Unsupported event [0xd0]
Do you need more logs? Or is this enought?
Yes, as you point out, this is a doubt for video bus received 0xD0 event
but nobody take care it.
Traced dsdt of EliteBook 8460p from you, the _BCM like this:
Method (_BCM, 1, Serialized)/* ATI _BCM, per log, run
this _BCM */
{
Store (\_SB.BCM (Arg0), Local0) /* set next level, normally
return 0x1 if XP sp2 or later */
If (Local0) /* if XP sp2 or later */
{
Store (BRID, Local1)
If (LEqual (SBRV (), 0x00)) /* normally SBRV return 1,
will not emit SMI */
{
\_SB.SSMI (0xEA74, 0x04, Local1, 0x00, 0x00)
}
Signal (\_SB.BEVT) /* emit BEVT event, HKFR
(HotkeyFunctionResponse) waiting it, but why? */
}
}
_BCM call SBRV to setup brightness value to variable ABRI:
Method (SBRV, 0, Serialized)/* call by ATI _BCM */
{
Store (\_SB.SBRC (), ABRI) /* SBRC() return the brightness
value, why store to ABRI? only used in PEGP.DGFX.AFN2 */
Or (PSBR, 0x80, PSBR)
Notify (^, 0xD0)/* notify method's parent: PEGP.DGFX
by 0xD0 */
Return (0x01) /* normally return 1 */
}The PEGP.DGFX acpi device was binding to acpi/video driver, the above
ASL code emit a 0xD0 bus event to video.c but cann't process it. Even we
add a new bus event in video.c and generate a acpi event, there still
need another acpi driver should take care it.
I thought this acpi event might need take care by radeon drm, but I am
not good for radeon, need more help.
Per your acpi debug log, the brightness value was changed normally when
you access _BCM:
83133 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674669] ACPI: Execute
Method [\_SB_.PCI0.PEGP.DGFX.LCD_._BCM] (Node 8 801362472a8)
# start test _BCM manually
83134 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674736] exregion-0199
[01] ex_system_memory_space: System-Memory (width 8 ) R/W 0
Address=BF7ACE1C
83135 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674748] exregion-0199
[02] ex_system_memory_space: System-Memory (width 8 ) R/W 1
Address=BF7ACE1C
...
83179 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.675070] [ACPI Debug
Fwd: Brightness on HP EliteBook 8460p
Add Cc. to dri mail
Hi Pali,
? ??2012-02-03 ? 16:24 +0100?Pali Roh?r ???
> On Friday 20 January 2012 17:55:57 Pali Roh?r wrote:
> > On Friday 20 January 2012 11:28:59 joeyli wrote:
> > > ? ??2012-01-20 ? 11:12 +0800?joeyli ???
> > >
> > > > Hi Pali,
> > > >
> > > > Sorry for I am late reply you.
> > > >
> > > > ? ??2012-01-17 ? 19:10 +0100?Pali Roh?r ???
> > > >
> > > > > On Wednesday 21 December 2011 12:45:07 Pali Roh?r wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I tried to boot with all 3 strings in acpi_os_name, but nothing was
> > > > > > changed. I'm attaching dmesg outputs, one from BIOS mode, one from
> > > > > > UEFI mode. Both are with "Microsoft Windows NT".
> > > > >
> > > > > Did you looked at my logs?
> > > >
> > > > I checked your dmesg log, found the acpi_os_name kernel parameter is :
> > > >
> > > > [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-generic
> > > > root=UUID=4ec6272a-8551-40f3-a1b1-3e10984f3e69 ro pcie_aspm=force
> > > > acpi.debug_level=0x2 acpi.debug_layer=0x "acpi_os_name=Microsoft
> > > > Windows NT" splash vt.handoff=7
> > > >
> > > > We still need by-pass the os name check in DSDT when test function key,
> > > >
> > > > please help to feed:
> > > > acpi_os_name="Windows 2009"
> > > >
> > > > And,
> > > > looks like the acpi debug level not enough, please kindly change acpi
> > > >
> > > > debug parameter to:
> > > > acpi.debug_level=0xF acpi.debug_layer=0x log_buf_len=5M
> > > >
> > > > summary:
> > > > acpi.debug_level=0xF acpi.debug_layer=0x log_buf_len=5M
> > > > acpi_os_name="Windows 2009"
> > >
> > > Forgot remind,
> > > please remember press brightness function key a couple of times before
> > > you dump the dmesg and messages log.
> > >
> > >
> > > Thanks a lot!
> > > Joey Lee
> >
> > Hello,
> >
> > there was no acpi log, so I recompiled ubuntu kernel with
> > CONFIG_ACPI_DEBUG=y and CONFIG_ACPI_DEBUG_FUNC_TRACE. Then I started kernel
> > with your params.
> >
> > Now I'm attaching very long debug output. I belive it will be now usefull.
> >
> > Pressing brightness keys did not show anything in log.
> >
> > After writing 0 to /sys/class/backlight/acpi_video0/brightness in log
> > appear: [ 57.675070] [ACPI Debug] Integer 0x000B
> > ...
> >
> > And after writing 10:
> > [ 99.865208] [ACPI Debug] Integer 0x0048
> > [ 99.865295] evmisc-0120 [4294967289] ev_queue_notify_reques:
> > Dispatching Notify on [DGFX] Node 880136246c80 Value 0xD0 (**Device
> > Specific**) [ 99.865350]video-1474 [4294967289] video_bus_notify
> > : Unsupported event [0xd0]
>
> Do you need more logs? Or is this enought?
>
Yes, as you point out, this is a doubt for video bus received 0xD0 event
but nobody take care it.
Traced dsdt of EliteBook 8460p from you, the _BCM like this:
Method (_BCM, 1, Serialized)/* ATI _BCM, per log, run this
_BCM */
{
Store (\_SB.BCM (Arg0), Local0) /* set next level, normally
return 0x1 if XP sp2 or later */
If (Local0) /* if XP sp2 or later */
{
Store (BRID, Local1)
If (LEqual (SBRV (), 0x00)) /* normally SBRV return 1, will
not emit SMI */
{
\_SB.SSMI (0xEA74, 0x04, Local1, 0x00, 0x00)
}
Signal (\_SB.BEVT) /* emit BEVT event, HKFR
(HotkeyFunctionResponse) waiting it, but why? */
}
}
_BCM call SBRV to setup brightness value to variable ABRI:
Method (SBRV, 0, Serialized)/* call by ATI _BCM */
{
Store (\_SB.SBRC (), ABRI) /* SBRC() return the brightness value,
why store to ABRI? only used in PEGP.DGFX.AFN2 */
Or (PSBR, 0x80, PSBR)
Notify (^, 0xD0)/* notify method's parent: PEGP.DGFX by
0xD0 */
Return (0x01) /* normally return 1 */
}The PEGP.DGFX acpi device was binding to acpi/video driver, the above
ASL code emit a 0xD0 bus event to video.c but cann't process it. Even we
add a new bus event in video.c and generate a acpi event, there still
need another acpi driver should take care it.
I thought this
Fwd: Brightness on HP EliteBook 8460p
Hi Artur,
? ??2012-02-04 ? 20:19 -0700?Joey Lee ???
> Add Cc. to dri mail
>
> Hi Pali,
>
> ? ??2012-02-03 ? 16:24 +0100?Pali Roh?r ???
> > On Friday 20 January 2012 17:55:57 Pali Roh?r wrote:
> > > On Friday 20 January 2012 11:28:59 joeyli wrote:
> > > > ? ??2012-01-20 ? 11:12 +0800?joeyli ???
> > > >
> > > > > Hi Pali,
> > > > >
> > > > > Sorry for I am late reply you.
> > > > >
> > > > > ? ??2012-01-17 ? 19:10 +0100?Pali Roh?r ???
> > > > >
> > > > > > On Wednesday 21 December 2011 12:45:07 Pali Roh?r wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > I tried to boot with all 3 strings in acpi_os_name, but nothing
> > > > > > > was
> > > > > > > changed. I'm attaching dmesg outputs, one from BIOS mode, one from
> > > > > > > UEFI mode. Both are with "Microsoft Windows NT".
> > > > > >
> > > > > > Did you looked at my logs?
> > > > >
> > > > > I checked your dmesg log, found the acpi_os_name kernel parameter is :
> > > > >
> > > > > [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-generic
> > > > > root=UUID=4ec6272a-8551-40f3-a1b1-3e10984f3e69 ro pcie_aspm=force
> > > > > acpi.debug_level=0x2 acpi.debug_layer=0x
> > > > > "acpi_os_name=Microsoft
> > > > > Windows NT" splash vt.handoff=7
> > > > >
> > > > > We still need by-pass the os name check in DSDT when test function
> > > > > key,
> > > > >
> > > > > please help to feed:
> > > > > acpi_os_name="Windows 2009"
> > > > >
> > > > > And,
> > > > > looks like the acpi debug level not enough, please kindly change acpi
> > > > >
> > > > > debug parameter to:
> > > > > acpi.debug_level=0xF acpi.debug_layer=0x log_buf_len=5M
> > > > >
> > > > > summary:
> > > > > acpi.debug_level=0xF acpi.debug_layer=0x log_buf_len=5M
> > > > > acpi_os_name="Windows 2009"
> > > >
> > > > Forgot remind,
> > > > please remember press brightness function key a couple of times before
> > > > you dump the dmesg and messages log.
> > > >
> > > >
> > > > Thanks a lot!
> > > > Joey Lee
> > >
> > > Hello,
> > >
> > > there was no acpi log, so I recompiled ubuntu kernel with
> > > CONFIG_ACPI_DEBUG=y and CONFIG_ACPI_DEBUG_FUNC_TRACE. Then I started
> > > kernel
> > > with your params.
> > >
> > > Now I'm attaching very long debug output. I belive it will be now usefull.
> > >
> > > Pressing brightness keys did not show anything in log.
> > >
> > > After writing 0 to /sys/class/backlight/acpi_video0/brightness in log
> > > appear: [ 57.675070] [ACPI Debug] Integer 0x000B
> > > ...
> > >
> > > And after writing 10:
> > > [ 99.865208] [ACPI Debug] Integer 0x0048
> > > [ 99.865295] evmisc-0120 [4294967289] ev_queue_notify_reques:
> > > Dispatching Notify on [DGFX] Node 880136246c80 Value 0xD0 (**Device
> > > Specific**) [ 99.865350]video-1474 [4294967289] video_bus_notify
> > >
> > > : Unsupported event [0xd0]
> >
> > Do you need more logs? Or is this enought?
> >
>
> Yes, as you point out, this is a doubt for video bus received 0xD0 event
> but nobody take care it.
>
> Traced dsdt of EliteBook 8460p from you, the _BCM like this:
>
> Method (_BCM, 1, Serialized)/* ATI _BCM, per log, run
> this _BCM */
> {
> Store (\_SB.BCM (Arg0), Local0) /* set next level, normally
> return 0x1 if XP sp2 or later */
> If (Local0) /* if XP sp2 or later */
> {
> Store (BRID, Local1)
> If (LEqual (SBRV (), 0x00)) /* normally SBRV return 1,
> will not emit SMI */
> {
> \_SB.SSMI (0xEA74, 0x04, Local1, 0x00, 0x00)
> }
>
> Signal (\_SB.BEVT) /* emit BEVT event, HKFR
> (HotkeyFunctionResponse) waiting it, but why? */
> }
> }
>
> _BCM call SBRV to setup brightness
[PATCH] Add Intel GMA500(Poulsbo) Stub Driver
Hi Rui, First, thank's for your review and take care. ? ??2010-11-12 ? 09:31 +0800?Zhang Rui ??? > Hi, Lee, > > there are several regressions caused by this patch, > http://marc.info/?l=linux-acpi=128872402020412=2 > http://marc.info/?l=linux-acpi=128858111022621=2 > > Yes, We can fix it by "select INPUT if ACPI"/"select > VIDEO_OUTPUT_CONTROL if ACPI". > But IMO, STUB_POULSBO should not select ACPI_VIDEO at all, > what do you think? > Yes, I agreed. We can just remove the _select ACPI_VIDEO if ACPI_ because user should select it when they want to use. If CONFIG_ACPI_VIDEO doesn't select, the stub poulsbo just do _not_ thing but will have no any bad thing. So, let's direct remove it from Kconfig. Should I submit patch again? Thank's Joey Lee > thanks, > rui > > On Wed, 2010-11-03 at 09:19 +0800, Zhang Rui wrote: > > Hi, Lee, > > > > Sorry I missed this thread. > > > > On Wed, 2010-10-20 at 13:51 +0800, Lee, Chun-Yi wrote: > > > Currently, there have no GMA500(Poulsbo) native video driver to support > > > intel opregion. So, use this stub driver to enable the acpi backlight > > > control sysfs entry files by requrest acpi_video_register. > > > > > If you want the acpi backlight control, why not set CONFIG_ACPI_VIDEO > > driver directly? > > The reason why i915 driver selects ACPI_VIDEO is that it needs some > > cooperation between these two drivers during initialization, or else the > > system may hang. > > > > thanks, > > rui > > > > > Signed-off-by: Lee, Chun-Yi > > > --- > > > drivers/gpu/Makefile |2 +- > > > drivers/gpu/stub/Kconfig | 13 + > > > drivers/gpu/stub/Makefile |1 + > > > drivers/gpu/stub/poulsbo.c | 63 > > > > > > drivers/video/Kconfig |2 + > > > 5 files changed, 80 insertions(+), 1 deletions(-) > > > create mode 100644 drivers/gpu/stub/Kconfig > > > create mode 100644 drivers/gpu/stub/Makefile > > > create mode 100644 drivers/gpu/stub/poulsbo.c > > > > > > diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile > > > index 30879df..cc92778 100644 > > > --- a/drivers/gpu/Makefile > > > +++ b/drivers/gpu/Makefile > > > @@ -1 +1 @@ > > > -obj-y+= drm/ vga/ > > > +obj-y+= drm/ vga/ stub/ > > > diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig > > > new file mode 100644 > > > index 000..8f5a540 > > > --- /dev/null > > > +++ b/drivers/gpu/stub/Kconfig > > > @@ -0,0 +1,13 @@ > > > +config STUB_POULSBO > > > + tristate "Intel GMA500 Stub Driver" > > > + depends on PCI > > > +# Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled > > > +# but for select to work, need to select ACPI_VIDEO's > > > dependencies, ick > > > +select ACPI_VIDEO if ACPI > > > + help > > > + Choose this option if you have a system that has Intel GMA500 > > > + (Poulsbo) integrated graphics. If M is selected, the module will > > > + be called Poulsbo. This driver is a stub driver for Poulsbo that > > > + will call poulsbo.ko to enable the acpi backlight control sysfs > > > + entry file because there have no poulsbo native driver can support > > > + intel opregion. > > > diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile > > > new file mode 100644 > > > index 000..cd940cc > > > --- /dev/null > > > +++ b/drivers/gpu/stub/Makefile > > > @@ -0,0 +1 @@ > > > +obj-$(CONFIG_STUB_POULSBO) += poulsbo.o > > > diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c > > > new file mode 100644 > > > index 000..d8aa636 > > > --- /dev/null > > > +++ b/drivers/gpu/stub/poulsbo.c > > > @@ -0,0 +1,63 @@ > > > +/* > > > + * Intel Poulsbo Stub driver > > > + * > > > + * Copyright (C) 2010 Novell > > > + * > > > + * This program is free software; you can redistribute it and/or modify > > > it > > > + * under the terms of the GNU General Public License version 2 as > > > published by > > > + * the Free Software Foundation. > > > + * > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > + > > > +#define DRIVER_NAME "poulsbo" > > > +
drivers/platform/x86: Backlight-Add-backlight-type-v2.patch
Hi Corentin, ? ??2010-10-27 ? 13:39 +0200?Corentin Chary ??? > On Wed, Oct 27, 2010 at 1:06 PM, Sedat Dilek > wrote: > > Hi, > > > > while testing linux-next I wanted to reactivate the backlight type > > patches laying in my build-dir. > > > > Within 2.6.36-rcX cycle I had successfully tested the backlight type > > patch [1] with an additional patch for radeon by Michel (posted to > > dri-devel ML, see [2]). > > > > The main patch needs a little refreshing. > > > > v2: drivers/platform/x86/asus-laptop.c: Refreshed to fit linux-next > > (next-20101027) > > > > > > Kind Regards, > > - Sedat - > > > > [1] https://patchwork.kernel.org/patch/163971/ > > [2] https://patchwork.kernel.org/patch/182352/ > > > > Hi, > > I think rfkill has the same problem, on some platforms, the platform > driver will add a rfkill switch, but the network (wlan/wimax/whatever) > driver may also add one. AFAIK, the platform one is more likely to be > able to power down the device completly. > Agreed your point! x86/laptop or wmi driver borrow rfkill interface for power control but confuse with userland applications. Thank's Joey Lee
i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)
Hi Melchior, ? ??2011-04-30 ? 13:34 +0200?Melchior FRANZ ??? > Dropping Linus from the CC. > > > * Takashi Iwai -- Saturday 30 April 2011: > * * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote: > > > Yes, backlight adjustment generally works on this notebook, but only > > > with "acpi_osi=Linux" on the command line. > > > > acpi_osi quirk should be better added statically, then. > > No, I guess the problem here is that acer_wmi doesn't support this > machine yet. I told the ACER WMI maintainer and sent a DSDT image, > but this message was thoroughly ignored. > > > $ dmesg|grep -i acer > [0.00] DMI: Acer TM5735/BA51_MV, BIOS V1.04 09/23/2010 > [ 71.850534] acer_wmi: Acer Laptop ACPI-WMI Extras > [ 72.350278] acer_wmi: Unable to detect available WMID devices > > Machine: Acer Travelmate 5735Z-452G32Mnss > > m. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Could you please attach DSDT on this mail or share your kernel bugzilla number to us? I found cann't access BKO now? Thank's Joey Lee
i915/kms/backlight-combo mode problem (was: Re: Linux 2.6.39-rc5)
Hi Melchior, ? ??2011-05-02 ? 14:08 +0200?Takashi Iwai ??? > At Sat, 30 Apr 2011 13:34:51 +0200, > Melchior FRANZ wrote: > > > > Dropping Linus from the CC. > > > > > > * Takashi Iwai -- Saturday 30 April 2011: > > * * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote: > > > > Yes, backlight adjustment generally works on this notebook, but only > > > > with "acpi_osi=Linux" on the command line. > > > > > > acpi_osi quirk should be better added statically, then. > > > > No, I guess the problem here is that acer_wmi doesn't support this > > machine yet. I told the ACER WMI maintainer and sent a DSDT image, > > but this message was thoroughly ignored. > > > > > > $ dmesg|grep -i acer > > [0.00] DMI: Acer TM5735/BA51_MV, BIOS V1.04 09/23/2010 > > [ 71.850534] acer_wmi: Acer Laptop ACPI-WMI Extras > > [ 72.350278] acer_wmi: Unable to detect available WMID devices > > > > Machine: Acer Travelmate 5735Z-452G32Mnss > > Hm, but the backlight control is done via the standard ACPI, no? > If so, the fact that acer_wmi doesn't work sounds irrelevant. > > BTW, did you try my previous patch? > > > Takashi Yes, please try Takashi's previous patch. I am tracing bko#34142, but this issue does not related to your backlight control, because there have _BCM, _BQC declare in your DSDT, your machine MUST SUPPORTED by standard acpi backlight interface. Even the acer-wmi can probed on your machine, it cann't help anything for your backlight control. Thank's a lot! Joey Lee
i915/kms/backlight-combo mode problem
Hi Melchior, ? ??2011-05-06 ? 10:52 +0200?Melchior FRANZ ??? > * Melchior FRANZ -- Thursday 05 May 2011: > > This revised patch works correctly for me. > > ... and changing backlight brightness worked with acpi_osi=Linux, too. > Unfortunately, that does no longer work now, although I haven't changed > anything. Pressing the brightness buttons causes some ACPI debug output, > but it doesn't adjust anything. > > m. hmm Takashi's patch works before, but doesn't work now? Does that because my new patch for bko#34142 ? Could you please add acer-wmi to /etc/modprobe.d/blacklist then reboot machine ? Step: - add acer-wmi to /etc/modprobe.d/blacklist - shutdown your machine - remove AC power and notebook's battery - plugin AC power then boot your notebook - check the brightness control Thank's Joey Lee
i915/kms/backlight-combo mode problem
? ??2011-05-07 ? 22:22 +0200?Melchior FRANZ ??? > * Melchior FRANZ -- Friday 06 May 2011: > > last patch prevents the backlight from being turned off, but it also > > breaks the brightness adjustment keys at runtime with acpi_osi=Linux. > > It has turned out that acpi key events seem to be handled correctly > and even the state of /sys/class/backlight/acer-wmi/brightness is That's interesting for acer-wmi generated brightness interface when this machine declare acpi brightness interface in DSDT. > updated accordingly. The only problem is that this maintained Does it work to you direct control brightness by access by /sys/class/backlight/acer-wmi/brightness ? > brightness state isn't applied to the actual backlight. It remains > at highest level. Google pointed me to this workaround for another > Acer notebook: > > > https://help.ubuntu.com/community/AspireTimeline/Fixes#Alternative%20fix%20for%2010.10 > > This uses the acpid to write the brightness value to the display > using setpci. And this works on my notebook as well (Acer Travelmate As I remember, use setpci to control brightness is not recommended because BIOS or ACPI will also touch brightness level. That will be better control brightness by the function that was provided by BIOS. e.g. ACPI or WMI interface, or direct control by EC. That means that will be better fix your Fn key control brightness like before, you just need press Fn key to change brightness and don't need have any workaround. > 5735Z-452G32Mnss). Not pretty but better than nothing. Is Acer > not able to build proper notebooks? Or is it a kernel bug? > > m. Looks like current status is we try to fix bko#31522 but the patch causes your brightness no work by press Fn key even with acpi_osi=Linux. Does it right? Could you please also help to check: replace acpi_osi=Linux by acpi_osi="!Windows 2006" Does it also works to you for backlight control? Thank's Joey Lee
i915/kms/backlight-combo mode problem
Add Cc. Michael Chang for he is our i915 expert.
Hi Melchior,
? ??2011-05-08 ? 16:05 +0200?Melchior FRANZ ???
>
> > Does it work to you direct control brightness by access
> > by /sys/class/backlight/acer-wmi/brightness ?
>
> No. A number written to this virtual file is accepted and remembered,
> but it doesn't actually change the brightness. It takes setpci to do
> that.
>
I thought the video driver still is the KEY component for backlight
issues, need fix the problem in video driver first.
>
>
> > As I remember, use setpci to control brightness is not recommended
> > because BIOS or ACPI will also touch brightness level. That will be
> > better control brightness by the function that was provided by BIOS.
> > e.g. ACPI or WMI interface, or direct control by EC.
>
> Well, sounds plausible. And I wouldn't do it if it weren't the only
> way at the moment. :-)
>
>
>
> > That means that will be better fix your Fn key control brightness like
> > before, you just need press Fn key to change brightness and don't need
> > have any workaround.
>
> OK. I have added a lot of debug messages to intel_panel.c yesterday.
> All it told me was that it seems to work correctly wiht acpi_osi=Linux.
> Except that it doesn't actually change the brightness. Without acpi_osi
> the functions aren't called at all and none of my messages showed up.
>
I traced _Q event in your DSDT, when acpi_osi=Linux, it run the Intel
OpRegion logic for change brightness. And, finally, intel_opregion will
access the function the were provided by intel_panel. So, the problem
still back to intel_panel.
After discuss with Michael chang, we thought there have problem in your
brightness level after add combination mode:
vi driver/gpu/drm/i915/intel_panel.c
void intel_panel_set_backlight(struct drm_device *dev, u32 level)
{
struct drm_i915_private *dev_priv = dev->dev_private;
u32 tmp;
DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
if (is_backlight_combination_mode(dev)){
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;
lbpc = level * 0xfe / max + 1;
level /= lbpc; /* maybe the level changed by
lbpc */
pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
}
tmp = I915_READ(BLC_PWM_CTL);
if (IS_PINEVIEW(dev)) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level <<= 1;
} else
tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
I915_WRITE(BLC_PWM_CTL, tmp | level);
}
We need to know some run time value when intel_panel_set_backlight call by
funciton key.
Please help to apply the attached debug patch to intel_panel.c then attached
dmesg.
>
>
> > Looks like current status is we try to fix bko#31522 but the patch
> > causes your brightness no work by press Fn key even with acpi_osi=Linux.
> > Does it right?
>
> The history is: with acpi_osi=Linux everything worked with 2.6.38-rc8.
> With 2.6.38 the screen stayed black. The patch that only ignored lbpc=0
> worked (IIRC) including key adjustment. Later patches broke keys.
>
>
>
> > replace acpi_osi=Linux by acpi_osi="!Windows 2006"
> >
> > Does it also works to you for backlight control?
>
> No, doesn't work.
>
We can test the acpi_osi="!Windows 2006" again after we fix the i915's
problem.
Thank's
Joey Lee
The following is debug patch, and please add kernel parameter
drm.debug=0x02 :
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index f8f86e5..f62dbd9 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -236,17 +236,22 @@ void intel_panel_set_backlight(struct drm_device *dev,
u32 level)
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;
+ DRM_DEBUG_DRIVER("set backlight max = % lbpc =
level * 0xfe / max + 1;
+ DRM_DEBUG_DRIVER("set backlight lbpc = %d\n", lbpc);
level /= lbpc;
pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
}
tmp = I915_READ(BLC_PWM_CTL);
+ DRM_DEBUG_DRIVER("set backlight tmp(1) = %d\n", tmp);
if (IS_PINEVIEW(dev)) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level <<= 1;
} else
tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
+ DRM_DEBUG_DRIVER("set backlight tmp(2) = %d\n", tmp);
+ DRM_DEBUG_DRIVER("set backlight level = %d\n", level);
I915_WRITE(BLC_PWM_CTL, tmp | level);
}
i915/kms/backlight-combo mode problem
? ??2011-05-09 ? 11:00 +0200?Takashi Iwai ???
> At Mon, 09 May 2011 02:50:50 -0600,
> Joey Lee wrote:
> >
> > We need to know some run time value when intel_panel_set_backlight call by
> > funciton key.
>
> Yes, that'll help understanding.
>
> > Please help to apply the attached debug patch to intel_panel.c then
> > attached dmesg.
>
> The patch has an obvious typo :)
> Also, we should track the value in intel_panel_get_backlight(), too.
>
>
> Takashi
>
Thank's for Takashi's review and sorry for my typo.
Follow Takashi's suggestion, I added a debug message in get_backlight,
the following is new debug patch:
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index f8f86e5..9695840 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -199,6 +199,7 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CPU_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
} else {
val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
+ DRM_DEBUG_DRIVER("get backlight val = %d\n", val);
if (IS_PINEVIEW(dev))
val >>= 1;
@@ -236,17 +237,22 @@ void intel_panel_set_backlight(struct drm_device *dev,
u32 level)
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;
+ DRM_DEBUG_DRIVER("set backlight max = %d\n", max);
lbpc = level * 0xfe / max + 1;
+ DRM_DEBUG_DRIVER("set backlight lbpc = %d\n", lbpc);
level /= lbpc;
pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
}
tmp = I915_READ(BLC_PWM_CTL);
+ DRM_DEBUG_DRIVER("set backlight tmp(1) = %d\n", tmp);
if (IS_PINEVIEW(dev)) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level <<= 1;
} else
tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
+ DRM_DEBUG_DRIVER("set backlight tmp(2) = %d\n", tmp);
+ DRM_DEBUG_DRIVER("set backlight level = %d\n", level);
I915_WRITE(BLC_PWM_CTL, tmp | level);
}
i915/kms/backlight-combo mode problem
Forward to upstream for more discussion. ? ??2011-05-13 ? 17:27 +0800?Michael Chang ??? > Melchior, > > I tried to puzzle out the possible cause of the problem, but sorry > that no further progress to give you. I'd like to debug this issue, > also did Joey. But there's more questions in my mind, made me feel not > able to proceed any further.. :( > > 1. is_backlight_combination_mode() really returns 0x4 ..? I understand > your words, but if this is true then Joey Lee provided patch should > log out some information about changing the LPBC > > set backlight lbpc = ... > > but I didn't see any of the log output .. :( > > 2. I dig the old mailing thread .. found a post > > http://marc.info/?l=linux-kernel=130462815211684=2 > > If you rebase this patch to your currently git commit, will it fixes > all problems for you now (only vanilla kernel with this patch)? (You > replied that this patch works for you ..) Also another interesting > finding... > > > + if (!lbpc) > > + combo_mode = 0; > > Looks like the purpose of it is to NOT touch the LPBC registers if > lbpc is zero ...(since this forces is_backlight_combination_mode > return 0). This would make contradiction about the assumption that you > could change to back-light via LPBC .. (using setpci is actually > access the LPBC registers .. IMHO). > > Total a mess for me now .. Did I made anything wrong .. I know I may > lose some details. > > I'm thinking is it ok for us to discuss in IRC, the communication > would be more efficient. Would this be convenient for you ? This is up > to you. > > Have nice weekend .. :) > > Regards, > Michael Chang > > 2011/5/10 Melchior FRANZ : > > * Michael Chang -- Tuesday 10 May 2011: > >> Could you please try this patch and get the log ? We wonder why > >> is_backlight_combination_mode () returns false. > > > > This information was already buried in the bugzilla thread: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=31522 > > "It turned out that on this machine INTEL_INFO(dev)->gen equals 4, > > and is_backlight_combination_mode() returns 0x4000." > > > > > > But to say it again in your words: :-) > > > > [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 > > (0x4000) > > > > 6x during boot-up, and several times later when changing the backlight > > brightness. > > > > > > This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now > > I have a little shocker for you (and me): because this was a > > vanilla kernel (apart from these debug messages), the screen went > > black again, like I knew it. But pressing the "brightness down" > > key turns the backlight on! I can't believe that I haven't tested > > that. I guess I've only tried "brightness up" and "display toggle". > > Those don't turn backlight on. Or maybe somethine else relevant > > meanwhile changed in the i915 drivers. (I've regularly been > > updating to HEAD.) > > > > So, the problem was just the initial state all the time? > > > > m. > >
