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.000000] 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=0xFFFFFFFF "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=0xFFFFFFFF log_buf_len=5M
> > > > 
> > > > summary:
> > > >         acpi.debug_level=0xF acpi.debug_layer=0xFFFFFFFF 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 0x000000000000000B
> > ...
> > 
> > And after writing 10:
> > [   99.865208] [ACPI Debug]  Integer 0x0000000000000048
> > [   99.865295]   evmisc-0120 [4294967289] ev_queue_notify_reques:
> > Dispatching Notify on [DGFX] Node ffff880136246c80 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 ffff8      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=00000000BF7ACE1C
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=00000000BF7ACE1C
...
83179 Jan 20 17:17:51 Pali-EliteBook kernel: [   57.675070] [ACPI Debug]  
Integer 0x000000000000000B    # 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 
ffff880136246c80 Value 0xD0 (**Device Specific**)
83181 Jan 20 17:17:51 Pali-EliteBook kernel: [   57.675099]    video-1474 
[4294967288] video_bus_notify      : Unsupported event [0xd0]
...
83197 Jan 20 17:18:33 Pali-EliteBook kernel: [   99.863593] ACPI: Execute 
Method [\_SB_.PCI0.PEGP.DGFX.LCD_._BCM] (Node ffff8      801362472a8)
83198 Jan 20 17:18:33 Pali-EliteBook kernel: [   99.863817] exregion-0199 [01] 
ex_system_memory_space: System-Memory (width 8      ) R/W 0 
Address=00000000BF7ACE1C
83243 Jan 20 17:18:33 Pali-EliteBook kernel: [   99.865208] [ACPI Debug]  
Integer 0x0000000000000048    # brightness value is 72 
83244 Jan 20 17:18:33 Pali-EliteBook kernel: [   99.865295]   evmisc-0120 
[4294967289] ev_queue_notify_reques: Dispatching Notify on [DGFX] Node 
ffff880136246c80 Value 0xD0 (**Device Specific**)
83245 Jan 20 17:18:33 Pali-EliteBook kernel: [   99.865350]    video-1474 
[4294967289] video_bus_notify      : Unsupported event [0xd0]

The brightness values are 11(0x0B) and 72(0x48), that means the BCM
method return a good value and set to ABRI, ABRI waiting the guy who
take the 0xD0 event to read then change brightness.

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




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

Reply via email to