Bug 115011 - [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller
Summary: [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-20 19:02 UTC by Luya Tshimbalanga
Modified: 2016-09-13 05:21 UTC (History)
7 users (show)

See Also:
Kernel Version: 4.4.5-300.fc23.x86_64
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump as stated on kernel 4.4.5-300 on Fedora 23 (859.75 KB, text/plain)
2016-03-21 08:46 UTC, Luya Tshimbalanga
Details
dmesg with 4.6.0-0.rc0.git13.1 (87.93 KB, text/plain)
2016-03-23 01:58 UTC, Luya Tshimbalanga
Details

Description Luya Tshimbalanga 2016-03-20 19:02:57 UTC
I was suggested to report the bug here from Fedora Project:
https://bugzilla.redhat.com/show_bug.cgi?id=1277786

While booting Fedora, I received that error message running on an AMD powered laptop. As a result, I am unable to use the functions keys to manually lower or raise the backlight from the screen.
Comment 1 Lv Zheng 2016-03-21 03:07:10 UTC
I'm not sure if this is a known regression that has been fixed here:
https://bugzilla.kernel.org/show_bug.cgi?id=112911

If your platform contain real ECDT, then it is likely the case.
So please also upload acpidump output for confirmation.

Thanks in advance
Comment 2 Lv Zheng 2016-03-21 03:08:31 UTC
BTW, what the version of the Linux kernel is?

Thanks
-Lv
Comment 3 Luya Tshimbalanga 2016-03-21 08:46:47 UTC
Created attachment 210081 [details]
acpidump as stated on kernel 4.4.5-300 on Fedora 23

Here is the acpidump as requested. It looks like ECDT is listed.
Comment 4 Lv Zheng 2016-03-22 02:33:35 UTC
Hi,

This is a known bug.
original commit contains support to avoid this.
But according to the comment, it is simplied in order to be upstreamed.
I'm going to fix this issue here:
https://bugzilla.kernel.org/show_bug.cgi?id=114201
Let me mask this as duplicate.

Thanks
-Lv
Comment 5 Lv Zheng 2016-03-22 02:37:09 UTC
(In reply to Lv Zheng from comment #4)
> Hi,
> 
> This is a known bug.
> original commit contains support to avoid this.
> But according to the comment, it is simplied in order to be upstreamed.
> I'm going to fix this issue here:
> https://bugzilla.kernel.org/show_bug.cgi?id=114201
> Let me mask this as duplicate.

Sorry, the comment is wrong.
I messed this with other bug.

Thanks
-Lv
Comment 6 Lv Zheng 2016-03-22 02:53:50 UTC
Hi,

After extracting the tables, I found real ECDT:
[000h 0000   4]                    Signature : "ECDT"    [Embedded Controller Boot Resources Table]
[004h 0004   4]                 Table Length : 000000C1
[008h 0008   1]                     Revision : 01
[009h 0009   1]                     Checksum : 13
[00Ah 0010   6]                       Oem ID : "_ASUS_"
[010h 0016   8]                 Oem Table ID : "Notebook"
[018h 0024   4]                 Oem Revision : 00000001
[01Ch 0028   4]              Asl Compiler ID : "OEM."
[020h 0032   4]        Asl Compiler Revision : 00000003


[024h 0036  12]      Command/Status Register : [Generic Address Structure]
[024h 0036   1]                     Space ID : 01 [SystemIO]
[025h 0037   1]                    Bit Width : 08
[026h 0038   1]                   Bit Offset : 00
[027h 0039   1]         Encoded Access Width : 01 [Byte Access:8]
[028h 0040   8]                      Address : 0000000000000066

[030h 0048  12]                Data Register : [Generic Address Structure]
[030h 0048   1]                     Space ID : 01 [SystemIO]
[031h 0049   1]                    Bit Width : 08
[032h 0050   1]                   Bit Offset : 00
[033h 0051   1]         Encoded Access Width : 01 [Byte Access:8]
[034h 0052   8]                      Address : 0000000000000062

[03Ch 0060   4]                          UID : 00000000
[040h 0064   1]                   GPE Number : 15
[041h 0065  19]                     Namepath : "\_SB.PCI0.SBRG.EC0"

The _REG of the EC driver is empty:
    OperationRegion (RAMW, SystemMemory, RAMB, 0x1000)
    Field (RAMW, AnyAcc, NoLock, Preserve)
    {
        ...
        DCPF,   8, 
        DCP2,   8, 
        ....
    }

    Scope (_SB.PCI0.SBRG)
    {
        Device (EC0)
        {
            Name (_HID, EisaId ("PNP0C09"))  // _HID: Hardware ID
            Name (CRS, ResourceTemplate ()
            {
                IO (Decode16,
                    0x0062,             // Range Minimum
                    0x0062,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    )
                IO (Decode16,
                    0x0066,             // Range Minimum
                    0x0066,             // Range Maximum
                    0x00,               // Alignment
                    0x01,               // Length
                    )
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Return (CRS)
            }

            Name (_GPE, 0x15)  // _GPE: General Purpose Events
            ...
            OperationRegion (ECW1, SystemMemory, 0xFE000380, 0x80)
            Field (ECW1, ByteAcc, Lock, Preserve)
            {
                Offset (0x01), 
                EPWS,   8, 
                ...
            }
            ...
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
            }
            ...
            Method (BATP, 1, Serialized)
            {
                And (EPWS, 0x02, Local0)
                If (Local0)
                {
                    Store (One, DCPF)
                }
                Else
                {
                    Store (Zero, DCPF)
                }

                And (EPWS, 0x04, Local0)
                If (Local0)
                {
                    Store (One, DCP2)
                }
                Else
                {
                    Store (Zero, DCP2)
                }

                If (Arg0)
                {
                    Return (DCP2)
                }
                Else
                {
                    Return (DCPF)
                }
            }
            ...
        }
    }

The battery device is:
    Scope (_SB.PCI0)
    {
        Device (BAT0)
        {
            Name (_HID, EisaId ("PNP0C0A"))  // _HID: Hardware ID
            Name (_UID, Zero)  // _UID: Unique ID
            Name (_PCL, Package (0x01)  // _PCL: Power Consumer List
            {
                PCI0
            })
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (^^SBRG.EC0.BATP (Zero))
                {
                    Return (0x1F)
                }
                Else
                {
                    Return (0x0F)
                }
            }

            Method (_BIF, 0, Serialized)  // _BIF: Battery Information
            {
                Return (^^SBRG.EC0.BIFP (Zero))
            }

            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
            {
                If (ATKP)
                {
                    ^^SBRG.EC0.ACAP ()
                    If (ACPF)
                    {
                        Store (One, S4CT)
                    }
                    Else
                    {
                        If (LAnd (LLessEqual (^^SBRG.EC0.B0PN, One), LEqual (ACPF, Zero)))
                        {
                            ^^^ATKD.IANE (0x6D)
                        }
                    }
                }

                Return (^^SBRG.EC0.BSTP (Zero))
            }
        }
    }

And the battery's _STA relies on the EC driver's availability to access EC operation region fields.

This looks a little bit like the same bug as Bug 112911 which can be fixed by this upstream commit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5508df8

Could you first pull upstream Linus tree and try again?
Thanks in advance.

Best regards
-Lv
Comment 7 Luya Tshimbalanga 2016-03-23 01:58:38 UTC
Created attachment 210281 [details]
dmesg with 4.6.0-0.rc0.git13.1

dmesg report using latest git kernel i.e. 4.6.0-0. Same result:

[    7.498283] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller
Comment 8 Lv Zheng 2016-03-23 08:37:09 UTC
(In reply to Luya Tshimbalanga from comment #7)
> Created attachment 210281 [details]
> dmesg with 4.6.0-0.rc0.git13.1
> 
> dmesg report using latest git kernel i.e. 4.6.0-0. Same result:
> 
> [    7.498283] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a
> backlight controller

Sorry.
I was thinking this was against battery which should be controlled by EC.
Let me re-assign this to acpi video owner.

Thanks
-Lv
Comment 9 Zhang Rui 2016-03-28 23:32:19 UTC
Reassign to graphics experts.
Comment 10 Alex Deucher 2016-03-29 14:16:36 UTC
(In reply to Luya Tshimbalanga from comment #7)
> Created attachment 210281 [details]
> dmesg with 4.6.0-0.rc0.git13.1
> 
> dmesg report using latest git kernel i.e. 4.6.0-0. Same result:
> 
> [    7.498283] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a
> backlight controller

This message is harmless.  Your laptop has two GPUs.  The ATIF ACPI method is used to notify the driver of backlight change events so the driver checks to see if it exists.  Depending on the board configuration, the secondary GPU may or may not have access to the backlight controller.  In this case it does not.
Comment 11 Luya Tshimbalanga 2016-03-29 17:30:58 UTC
(In reply to Alex Deucher from comment #10)
> (In reply to Luya Tshimbalanga from comment #7)
> > Created attachment 210281 [details]
> > dmesg with 4.6.0-0.rc0.git13.1
> > 
> > dmesg report using latest git kernel i.e. 4.6.0-0. Same result:
> > 
> > [    7.498283] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a
> > backlight controller
> 
> This message is harmless.  Your laptop has two GPUs.  The ATIF ACPI method
> is used to notify the driver of backlight change events so the driver checks
> to see if it exists.  Depending on the board configuration, the secondary
> GPU may or may not have access to the backlight controller.  In this case it
> does not.

Thank you for explaining the meaning of the message related to dual GPUs. It will be nice to improve the mechanism where one of GPU cannot access to the backlight controller.
Comment 12 Hans de Goede 2016-07-14 10:30:23 UTC
Hi Alex,

(In reply to Alex Deucher from comment #10)
> (In reply to Luya Tshimbalanga from comment #7)
> > Created attachment 210281 [details]
> > dmesg with 4.6.0-0.rc0.git13.1
> > 
> > dmesg report using latest git kernel i.e. 4.6.0-0. Same result:
> > 
> > [    7.498283] [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a
> > backlight controller
> 
> This message is harmless.  Your laptop has two GPUs.  The ATIF ACPI method
> is used to notify the driver of backlight change events so the driver checks
> to see if it exists.  Depending on the board configuration, the secondary
> GPU may or may not have access to the backlight controller.  In this case it
> does not.

Mayebe we need to make the error a bit less scary then, e.g. :

 [drm:radeon_acpi_init [radeon]] *Warning* Cannot find a backlight controller, this is ussualy harmless on dual gpu systems

Yes it is a bit long, but it will likely help to avoid future bug reports about this.

Regards,

Hans
Comment 13 Luya Tshimbalanga 2016-09-13 05:08:24 UTC
Hello, 
I am closing this bug report now it was revealed the bug was triggered by the new ACPI EC scheme from the BIOS first used by Microsoft Windows 8.1 and up. Tested with patch on Kernel 4.8 rc4  properly handle the backlight controller. I no longer see the error message:

$ journalctl -b | grep backlight
Sep 12 09:42:22 muamba-telus1603 kernel: [drm] radeon atom DIG backlight initialized
Sep 12 16:42:59 muamba-telus1603 kernel: audit: type=1130 audit(1473723759.682:64): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-backlight@backlight:radeon_bl0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 12 16:42:39 muamba-telus1603 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-backlight@backlight:radeon_bl0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 12 16:42:39 muamba-telus1603 systemd[1]: Created slice system-systemd\x2dbacklight.slice.
Sep 12 16:42:39 muamba-telus1603 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:radeon_bl0...
Sep 12 16:42:39 muamba-telus1603 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:radeon_bl0.

Thank you for the investigation and the effort.
Comment 14 Alex Deucher 2016-09-13 05:13:25 UTC
You aren't seeing the message because it was removed in newer kernels.
Comment 15 Luya Tshimbalanga 2016-09-13 05:16:35 UTC
(In reply to Alex Deucher from comment #14)
> You aren't seeing the message because it was removed in newer kernels.

Thank you for the clarification. Should I set the status as code fix then?

Note You need to log in before you can comment on or make changes to this bug.