Created attachment 83161 [details]
dmesg before with defaults

Created attachment 83162 [details]
dmesg after with defaults

Created attachment 83163 [details]
dmi decode log

Created attachment 83164 [details]
proc acpi capture

Created attachment 83165 [details]
kernel command line with defaults

Created attachment 83166 [details]
/sys/class/backlight list with defaults

Created attachment 83167 [details]
ia reg dump before with defaults

Created attachment 83168 [details]
ia reg dump after with defaults

Created attachment 83169 [details]
dmesg before with vendor

Created attachment 83170 [details]
dmesg after with vendor

Created attachment 83171 [details]
/sys/class/backlight list with vendor

Created attachment 83172 [details]
ia reg dump before with vendor

Created attachment 83173 [details]
ia reg dump after with vendor

Created attachment 83174 [details]
kernel command line with vendor

Created attachment 83175 [details]
version of kernel

Tested with Fedora 19.

Built same kernel with CONFIG_PM_DEBUG enabled.  Captured logs.  In addition to the backight not working the screen is all messed up.  Attaching logs.

Created attachment 83176 [details]
kernel command line with defaults and CONFIG_PM_DEBUG enabled

Created attachment 83177 [details]
version of kernel with CONFIG_PM_DEBUG enabled

Created attachment 83179 [details]
dmesg before with defaults with CONFIG_PM_DEBUG enabled

executing core/processors/devices on /sys/power/pm_test

Created attachment 83181 [details]
dmesg after with defaults with CONFIG_PM_DEBUG enabled

executing core/processors/devices on /sys/power/pm_test

Created attachment 83182 [details]
ia reg dump after with defaults with CONFIG_PM_DEBUG enabled

executing core/processors/devices on /sys/power/pm_test

All the dmesgs were without drm.debug=6, and they don't contain the information from our driver about what is happening. :(

My mistake.  Will correct and regenerate the dmesgs.  I have the macbook air here with me.

Created attachment 83233 [details]
Updated log files for default kernel (non vendor)

Using drm.debug=6

Created attachment 83234 [details]
Updated log files for default kernel  (vendor acpi_backlight)

(In reply to comment #26)
> Created attachment 83234 [details]
> Updated log files for default kernel  (vendor acpi_backlight)

Using drm.debug=6

Created attachment 83235 [details]
Updated log files for CONFIG_PM_DEBUG kernel  (non vendor)

Using drm.debug=6

Created attachment 83236 [details]
Updated log files for CONFIG_PM_DEBUG kernel  (vendor acpi_backlight)

Using drm.debug=6

When using a kernel with CONFIG_PM_DEBUG, the backlight adjustment issue goes away with and without acpi_backlight set to vendor.  In other words I can fully exercise the range.

I am trying to duplicate the display corruption that I saw previously.

(In reply to comment #30)
> I am trying to duplicate the display corruption that I saw previously.

Known bug in fence restoration across resume, already fixed.

Sean, please try 3.11-rc3 kernel. There were a number of fixes in the backlight code, including locking. If CONFIG_PM_DEBUG makes a difference, a race condition comes to mind.

(In reply to comment #32)
> Sean, please try 3.11-rc3 kernel. There were a number of fixes in the
> backlight code, including locking. If CONFIG_PM_DEBUG makes a difference, a
> race condition comes to mind.

Same problem seen with my 3.11-rc3 build tonight.  I should point out that the CONFIG_PM_DEBUG does not always prevent the problem from happening.  Tonight when using it, I consistently hit the problem.

Hi there,

I have tested this against 3.12-rc1 and the issue is still there. 

MacBook Air 6,2
Intel Core i7-4650U 1.7Ghz
8GB RAM
128GB SSD

The display resumes but the brightness controls allow only full brightness or off.

(In reply to comment #0)
> The hotkeys still
> technically work and show the percentage correctly (and
> /sys/class/backlight/intel_backlight/brightness appears to show the correct
> value too), but the actual screen is either all on or all off.

Does /sys/class/backlight/intel_backlight/actual_brightness change as expected too when you observe the issue?

This is while I go from full brightness to dark and bright again (after a resume):

% for i in $(seq 0 10); do sleep 1; cat /sys/class/backlight/intel_backlight/brightness; cat /sys/class/backlight/intel_backlight/actual_brightness; echo "*" ; done
2550
2550
*
2210
2210
*
2040
2040
*
1860
1860
*
1860
1860
*
1860
1860
*
2040
2040
*
2370
2370
*
2370
2370
*
2370
2370
*
2550
2550
*

If you change the brightness through /sys/class/backlight/intel_backlight/brightness, do you have a full range from dark to bright when trying values between 1860 and 2550?

e.g. su -c "echo 1860 > /sys/class/backlight/intel_backlight/brightness"

Please attach /sys/kernel/debug/dri/0/i915_opregion from the debugfs.

1860 completely dark 
1900 "
2100 "
2200 "
2250 "
2260 "
2270 completely bright
2280 "
2300 "
2400 "

Created attachment 86483 [details]
/sys/kernel/debug/dri/0/i915_opregion

MacAir 6,2 with Linux Kernel 3.12-rc1 on Debian has the same issue.

I have tested with xbacklight and echo to /sys/class/backlight/acpi_video0/brightness result is the same.

Requested brightness value seems to be set correctly (tested with  brightness_down; cat value; sleep 2; brightness_up) but physical brightness is either on (100% brightness command) or off (any other brightness level).

Desperately waiting for "the patch" : )

I've noticed that if I set the "sweet spot" of 2233 the backlight goes crazy and brightness changes randomly up and down (but smoothly). Anything above is full brightness and anything below is 0 brightness.

-Patrik

Let me get this straight: the backlight works all right before suspend, but fails after resume? I'm a bit surprised there isn't anything in the before/after register dumps that would explain this. Do they really reflect the working and broken states?

Jani, you are correct. I just tested with the 3.12-rc4 released yesterday on MacAir 6,2 (Mid 2013) and result is the same.

Created attachment 87227 [details] [review]
save/restore some more backlight registers

Here's a patch to try, mostly for the sake of trying something, as there's no evidence this should help.

Patched 3.12-rc4 on MacAir 6,2 alas no change : (

Any other help I can provide?

Thanks.

Maybe this bug report will help when it is solved:

https://bugzilla.kernel.org/show_bug.cgi?id=62881

(In reply to comment #46)
> Maybe this bug report will help when it is solved:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=62881

Definitely related or duplicate.

All,

This issue has been raised at the Kernel Bugzilla at: https://bugzilla.kernel.org/show_bug.cgi?id=62881

However, that bug report has been marked CLOSED MOVED with this final comment: "No more info is needed and no work can be done in ACPI to solve this, please follow the bug [at freedesktop.org]"

Please advise on further troubleshooting steps? Those of us who have this hardware would like to help fix this problem. :)

Thanks in advance.

I am also experiencing this issue on my MBA running Arch and was following the kernel bug before it was closed: 
https://bugzilla.kernel.org/show_bug.cgi?id=62881


I am willing to help with any testing to see this get fixed.

This is an odd bug, but then all backlight ones are. :(

Please get current intel-gpu-tools, boot, get reg dump using intel_reg_dumper, suspend, wait a minute, resume, get reg dump using intel_reg_dumper, make sure the problem is present at this stage, attach dumps clearly named.

Created attachment 88822 [details]
intel_reg_dump: after booting, backlight fully functional

Created attachment 88823 [details]
intel_reg_dump: after resuming, backlight only 0% or 100%

Jani,

Thanks so much for your quick reply!

(In reply to comment #50)
> Please get current intel-gpu-tools, boot, get reg dump using
> intel_reg_dumper, suspend, wait a minute, resume, get reg dump using
> intel_reg_dumper, make sure the problem is present at this stage, attach
> dumps clearly named.

Done. Running release kernel 3.12.

I don't know much about the GPU registers, but diff didn't appear to show anything interesting, so I'm guessing you'll still need more information.

Please advise on next troubleshooting steps and I'll be glad to oblige.

Thanks!

(In reply to comment #53)
> Jani,
> 
> Thanks so much for your quick reply!
> 
> (In reply to comment #50)
> > Please get current intel-gpu-tools, boot, get reg dump using
> > intel_reg_dumper, suspend, wait a minute, resume, get reg dump using
> > intel_reg_dumper, make sure the problem is present at this stage, attach
> > dumps clearly named.
> 
> Done. Running release kernel 3.12.
> 
> I don't know much about the GPU registers, but diff didn't appear to show
> anything interesting, so I'm guessing you'll still need more information.
> 
> Please advise on next troubleshooting steps and I'll be glad to oblige.

If you're *aching* for something, anything, to try, there's backlight-rework branch at [1] that I'm working on. It's an *UNTESTED* work-in-progress series towards fixing some issues we have, but no guarantees it will work al all. You've been warned.

[1] git://gitorious.org/jani/drm.git

No luck with the backlight-rework branch either. I've been digging in the DSDT but everything seems ok there.

One observation, which may be helpful?

I use pm-hibernate command to hibernate the computer. After I issue the command screen goes blank after a moment. Then screen comes back on again and stays on for a second. Then screen goes blank and computer is turned off.

I have this issue too on my MacBook Air 6,1.

BUT, I have installed Manjarobox (Arch-based distro) on a USB drive and when using it, I have no issues with the brightness after resume. I have looked and compared every file on both systems (made a script, running diff on all files with same name), but couldn't find anything related to the issue.

Alright. I solved the brightness issue by booting my main system from a USB drive with normal GRUB, no fancy EFI boot. This boots my linux system on the SSD, and suspend-resume-brightness works just as one would expect, without this bug.

Great news : ) What is the kernel version on your USB drive?

(In reply to comment #57)
> I have this issue too on my MacBook Air 6,1.
> 
> BUT, I have installed Manjarobox (Arch-based distro) on a USB drive and when
> using it, I have no issues with the brightness after resume. I have looked
> and compared every file on both systems (made a script, running diff on all
> files with same name), but couldn't find anything related to the issue.

I run 3.12.1-1-MANJARO on both. I think it's a GRUB issue, because when booting the SSD-install from the USB, it works.

(In reply to comment #59)
> Great news : ) What is the kernel version on your USB drive?

Is there a kernel flag difference between the two bootloader configurations?

Perhaps a comparative dump between the two dmesg buffers would help?

I can confirm that this works for me as well. And when booting into BIOS mode, the available backlight levels for the i915 only go up to 937 (or something similar).

I extracted the ACPI tables from both BIOS and UEFI but they are identical so no luck there.

Jani's backlight patches are now merged to drm-intel-next and will land in 3.14.

The backlight rework doesn't fix the problem so reopening. To clarify, booting into BIOS mode instead of UEFI fixes the problem.

(In reply to comment #64)
> To clarify, booting into BIOS mode instead of UEFI fixes the problem.

Patrik, can you please explain what that means? I would like to have this problem solved personally.

Do these patches fix this problem? If yes I will try to run these in latest kernel release. Thanks

(In reply to comment #63)
> Jani's backlight patches are now merged to drm-intel-next and will land in
> 3.14.

@Can Kavaklıoğlu
No the patches doesn't help. But booting into legacy BIOS mode seems to work.

@Alex Markley
Depending on how you've installed your system it can boot into UEFI mode or legacy BIOS mode. I don't think you can force the Apple bootloader to pick BIOS mode but perhaps you can with "refind". You can read some about Ubuntu and UEFI vs BIOS here: https://help.ubuntu.com/community/UEFI

If you just wanna try it out you can download an Arch Linux image and install it to a USB-stick. Plug it in and power up and hold down the "option" key and you'll see it in the apple bootloader as a "Legacy device". I hope that helps.

BIOS Boot on Macbook Air 6,2 comes with other problems:
https://bugzilla.kernel.org/show_bug.cgi?id=60635

Was excited to see Ben Widawsky's patches in 3.13-rc5 http://www.kernelhub.org/?msg=385232&p=2 

Compiled and booted it on MacBook Air 6,2 but no luck : (

Any other patches I can test?

*** Bug 72976 has been marked as a duplicate of this bug. ***

Issue still persists on 3.13-rc7.

Any further testing or fixes that could be tried?

MacBook Air 6,2
Intel Core i7-4650U 1.7Ghz
8GB RAM
128GB SSD

(In reply to comment #64)
> The backlight rework doesn't fix the problem so reopening. To clarify,
> booting into BIOS mode instead of UEFI fixes the problem.

An idea, please attach /sys/kernel/debug/dri/0/i915_opregion for both BIOS mode and UEFI boot.

Created attachment 91732 [details]
i915_opregion dump from UEFI

Max brightness in UEFI mode is 2777

Created attachment 91733 [details]
i915_opregion dump from BIOS/Legacy

Max brightness is 937

I confirm this bug on Macbook Air 6,1. 
Running Debian sid.

I have found some more information suggesting booting method may be the culprit. I am using refind boot loader to dual boot Mac and Debian jessie/sid. During boot sequence first refind screen is displayed and then the normal grub screen. I thought this meant I was booting in bios mode. But today I learnt this is not the case. http://www.rodsbooks.com/refind/bootmode.html It appears the grub I am using is an efi aware grub, not the legacy bios grub. This cleared my confusions about the Arch linux solution posted here.

Another point http://www.rodsbooks.com/ubuntu-efi/ says "Missing hardware features—I've seen reports that Linux features such as screen brightness control and suspend/resume may not work correctly when booting using EFI. I don't use such features, so I can't comment personally."

It also appears to be tricky to get legacy grub working in this dual boot scenario due to use of "protective MBR".

It is really amazing for me to see that booting method to effect the display driver. So I thought maybe driver developers may be inspired by this experience as well.

Anxiously waiting to get suspend my MacBook Air : (

Strangely, when booting from a usb stick using grub2, the problem does not arise,
as was already noted in comment 58.

I've managed to work around the issue by programming the backlight driver directly. This is not an optimal solution but consider it a workaround for now. I've written a driver and tested it on my MBA 6,2 but the 6,1 should work as well. Use it at your own risk, I take no responsibility. Don't try to load this driver unless you have a MacBook Air (mid 2013) 6,1 or 6,2.

To get it running you need to download and build the driver:

# git clone https://github.com/patjak/mba6x_bl
# cd mba6x_bl/ && make && make install

Make sure the module is loaded at boot time. E.g add "mba6x_bl" to /etc/modules
You also need to configure i915 to hand over the backlight control to mba6x_bl. I added this to my /etc/X11/xorg.conf:

Section "Device"
        Identifier      "Intel Graphics"
        Driver          "intel"
        Option          "Backlight"     "mba6x_backlight"
EndSection

Now reboot and you should have working brightness even after suspend/resume. Unloading the module (modprobe -r mba6x_bl) will restore the backlight to whatever state we had when loading it.

Thank you Patrick! Good work -  your module works great on my Macbook Air 6.2 in EFI-Mode. (Kernel 3.13-rc3). I'd love to understand the actual problem, did you figure out, why the standard backlight mechanism in i915 doesn't work?

Patrick's module also works for me (macbook air 6,1, kernel 3.12-1, efi). I had to manually run depmod, otherwise the module wasn't found. 
Thanks!

(In reply to comment #79)
> Thank you Patrick! Good work -  your module works great on my Macbook Air
> 6.2 in EFI-Mode. (Kernel 3.13-rc3). I'd love to understand the actual
> problem, did you figure out, why the standard backlight mechanism in i915
> doesn't work?

I still don't understand what the actual problem is but the backlight driver (LP8550) that my module is controlling doesn't change any of it's settings after suspend. It takes a PWM signal on one of the input pins and that signal must be getting screwed up. How that pin is wired might be harder to figure out.

What my module does is to ignore that input pin and instead write the brightness value to an on-chip register and set it up so it becomes the source for the LP8550. I access the LP8550 over SMBUS through ACPI methods. It might be better to access the SMBUS directly but this was the fastest way to get something working.

If you find any bugs/issues with mba6x_bl please report it on github.

I've packaged it into a dkms module for debian/ubuntu. See my fork on github: https://github.com/miekg/mba6x_bl/tree/dkms (pull request outstanding). Actually building such a deb is quite annoying. Feel free to download from: http://miek.nl/downloads/2013/mba6xbl-dkms_0.0.1_all.deb

Biggest plus: it should automatically follow your kernel upgrades. Also this is my first attempt to do a dkms-debian-package, so YMMV. Be warned :)

@Patrik Jakobsson, thanks a lot!!! Your module is working on my MacBook 6,2 as well. Great work!!!

@Miek Gieben, your .deb file gave the following error:

# dpkg -i mba6xbl-dkms_0.0.1_all.deb 
Selecting previously unselected package mba6xbl-dkms.
(Reading database ... 303473 files and directories currently installed.)
Unpacking mba6xbl-dkms (from .../mba6xbl-dkms_0.0.1_all.deb) ...
Setting up mba6xbl-dkms (0.0.1) ...
First Installation: checking all kernels...
Building only for 3.13.0-rc5
Building for architecture amd64
This package appears to be a binaries-only package
 you will not be able to build against kernel 3.13.0-rc5
 since the package source was not provided

[ Quoting <bugzilla-daemon@freedeskt> in "[Bug 67454] After suspend/resume, s..." ]
> https://bugs.freedesktop.org/show_bug.cgi?id=67454
> 
> --- Comment #83 from Can Kavaklıoğlu <eposta@cankavaklioglu.name.tr> ---
> @Patrik Jakobsson, thanks a lot!!! Your module is working on my MacBook 6,2 as
> well. Great work!!!
> 
> @Miek Gieben, your .deb file gave the following error:
> 
> # dpkg -i mba6xbl-dkms_0.0.1_all.deb 
> Selecting previously unselected package mba6xbl-dkms.
> (Reading database ... 303473 files and directories currently installed.)
> Unpacking mba6xbl-dkms (from .../mba6xbl-dkms_0.0.1_all.deb) ...
> Setting up mba6xbl-dkms (0.0.1) ...
> First Installation: checking all kernels...
> Building only for 3.13.0-rc5
> Building for architecture amd64
> This package appears to be a binaries-only package
>  you will not be able to build against kernel 3.13.0-rc5
>  since the package source was not provided

darn, I double checked this and "some" deb installed on my machine. I will
check later this evening. You can build the deb ourself by following the
instruction via the link in dkms.conf (which has been added to the mba6x_bl
repo).

grtz Miek

(In reply to comment #81)
> (In reply to comment #79)
> > Thank you Patrick! Good work -  your module works great on my Macbook Air
> > 6.2 in EFI-Mode. (Kernel 3.13-rc3). I'd love to understand the actual
> > problem, did you figure out, why the standard backlight mechanism in i915
> > doesn't work?
> 
> I still don't understand what the actual problem is but the backlight driver
> (LP8550) that my module is controlling doesn't change any of it's settings
> after suspend. It takes a PWM signal on one of the input pins and that
> signal must be getting screwed up. How that pin is wired might be harder to
> figure out.
> 
> What my module does is to ignore that input pin and instead write the
> brightness value to an on-chip register and set it up so it becomes the
> source for the LP8550. I access the LP8550 over SMBUS through ACPI methods.
> It might be better to access the SMBUS directly but this was the fastest way
> to get something working.
> 
> If you find any bugs/issues with mba6x_bl please report it on github.

Hi Patrick,

Trying to make install from the git repository fails for me with:

"Can't read private key
  DEPMOD  3.11.0-15-generic
make[1]: Leaving directory `/usr/src/linux-headers-3.11.0-15-generic'"

Anything obvious i'm doing wrong?

(In reply to comment #81)
> If you find any bugs/issues with mba6x_bl please report it on github.

Kindly please direct the mba6x_bl related discussion there, and don't clutter this bug. Thank you.

I am still experiencing this issue in Fedora 20 with kernel 3.12.8-300.fc20.x86_64 on MacBookAir6,2.

Why is this bug marked NEEDINFO? Can we get some clarity on what testers with this hardware can do to help troubleshoot this?

Is there any way to implement the fix from mba6x_bl directly in the proper driver? mba6x_bl works for me, so obviously whatever the intel driver is doing wrong could be corrected with a patch.

(In reply to comment #87)
> Is there any way to implement the fix from mba6x_bl directly in the proper
> driver? mba6x_bl works for me, so obviously whatever the intel driver is
> doing wrong could be corrected with a patch.

The mba6x_bl is a platform specific driver for the mba. What that driver does can not be duplicated within the i915 driver. These drivers control the backlight in completely different ways.

If we figure out what changes in a suspend/resume cycle that breaks the backlight control in i915, we'll obviously try to fix it. But it might just as well be that the breakage is outside of i915. I don't have a mba, I don't know how it's wired up.

Hmm, please provide a reg dump at boot, *before* i915 is loaded.

(In reply to comment #89)
> Hmm, please provide a reg dump at boot, *before* i915 is loaded.

Hello, I have a MBA mid 2013. Could you provide some directions to generate this dump before i915 is loaded?

I'm using ArchLinux and Linux Kernel 3.12.9.

(In reply to comment #78)
> I've managed to work around the issue by programming the backlight driver
> directly. This is not an optimal solution but consider it a workaround for
> now. I've written a driver and tested it on my MBA 6,2 but the 6,1 should
> work as well. Use it at your own risk, I take no responsibility. Don't try
> to load this driver unless you have a MacBook Air (mid 2013) 6,1 or 6,2.
> 
> To get it running you need to download and build the driver:
> 
> # git clone https://github.com/patjak/mba6x_bl
> # cd mba6x_bl/ && make && make install
> 
> Make sure the module is loaded at boot time. E.g add "mba6x_bl" to
> /etc/modules
> You also need to configure i915 to hand over the backlight control to
> mba6x_bl. I added this to my /etc/X11/xorg.conf:
> 
> Section "Device"
>         Identifier      "Intel Graphics"
>         Driver          "intel"
>         Option          "Backlight"     "mba6x_backlight"
> EndSection
> 
> Now reboot and you should have working brightness even after suspend/resume.
> Unloading the module (modprobe -r mba6x_bl) will restore the backlight to
> whatever state we had when loading it.

It doesn't work on my MBA 13 :( (UEFI)

Oh, sorry. It works! Thanks!

Hi all, and thanks for the job, that work great.
But i've try today on my Debian Wheezy with my MBA6.2 to boot on the 3.14 backported-kernel, and unfortunately, the driver dont work at his best. When my computeur start and when the  video driver load, the screen stay black. If, binded, i try to lunch X or make suspend to relunch after, the screen back to life.
I don't know exactly if it's the same bug, but i've saw this on Patrik Jakobson GitHub : https://github.com/patjak/mba6x_bl/issues/11. I try again to compile the driver with the new souces, but no result.

of course i speak about the mba6x_bl driver

Probably i dont use the right place to report this bug, but if someone arrive on this site, this can help:
I report some days ago that my screen become black on the boot after applied the mba6x_bl patch. I found a solution to fix that; say to initramfs to lunch your video driver as a module (but i dont know why install the mba6x_bl dkms remove this initial loading) :

# /etc/initramfs-tools/modules 

intel_agp
drm
i915 modeset=1

Let me know if there anything I could do to help test or debug this problem.

(In reply to comment #96)
> Let me know if there anything I could do to help test or debug this problem.

*shrug* out of ideas a bit, but you could always try the latest drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel

Could you please retest with latest drm-intel-nightly?

Timing out on this one.  Hopefully it's resolved; if not please re-open (but make sure it really is this bug, otherwise please file a new one).  Thanks.

I see this bug on Fedora 21 with 3.17.6 kernel with MacBook Air 6.2 2013.

Sorry for the "me too" nature of this update, but just to keep things open, I'm still seeing this issue on 3.19.0 on Debian jessie (vanilla Linus kernel, self-built).

Not in a position to restart X right now, but I will give mba6x_bl a try when convenient.

There are still issues with mba6x_bl for some people. That's why it's not upstream yet. When I figure it out I'll make a new attempt to get it included.

Long time no updates, and the truth of the matter, AFAICS, is that this is really not an i915 bug nor is it a regression. A non-i915 backlight control would be needed.

The same problem still exists on Ubuntu 16.04 with MacBook Air 6,2. I also tried the latest kernel 4.8-rc3, and found the issue is still there.

Following a similar [Bug 97486], I checked the register values before and after
S3 suspend:

$ sudo ./intel_reg read 0xc2004
                                    (0x000c2004): 0x00000024
$ sudo ./intel_reg read 0xc2000
                                    (0x000c2000): 0x00000000

$ sudo pm-suspend; sleep 10; sudo ./intel_reg read 0xc2004
                                    (0x000c2004): 0x00000004
$ sudo ./intel_reg read 0xc2000
                                    (0x000c2000): 0x00000000

Then trying to write back the value of 0xc2004, the back light level seems to
become normal. A similar patch from [Bug 97486] would be applied here?

Created attachment 126443 [details] [review]
proposed patch to store extra registers

Here is a proposed patch based on comment 14 of [Bug 97486].

(In reply to Yuan Chao from comment #105)
> Created attachment 126443 [details] [review] [review]
> proposed patch to store extra registers
> 
> Here is a proposed patch based on comment 14 of [Bug 97486].

Sorry, that won't do.

Please report the output of 'lspci -nns 2' and try http://patchwork.freedesktop.org/patch/msgid/1473329920-4449-1-git-send-email-shawn.c.lee@intel.com

The output of MBA 6,2 (2013) is 

00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a26] (rev 09)

Just tested the patch by shawn.c.lee on kernel 4.8.0 RC3, it actually works.

(In reply to Yuan Chao from comment #107)
> The output of MBA 6,2 (2013) is 
> 
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT
> Integrated Graphics Controller [8086:0a26] (rev 09)
> 
> Just tested the patch by shawn.c.lee on kernel 4.8.0 RC3, it actually works.

Ah, good, thanks. 

Anyway, here's updated patches:

https://patchwork.freedesktop.org/patch/111128/
https://patchwork.freedesktop.org/patch/111129/

Also confirmed the updated patches work on MBA 6,2 (2013) too.

Just under certain condition, the backlight dimmed again right after resuming. One need to change the backlight level (hot key) to recover.

I'm not making any claims about us fixing the bug, but these commits might help:

commit 32b421e79e6b546da1d469f1229403ac9142d695
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Sep 19 13:35:25 2016 +0300

    drm/i915/backlight: setup and cache pwm alternate increment value

and

commit e29aff05f239f8dd24e9ee7816fd96726e20105a
Author: Shawn Lee <shawn.c.lee@intel.com>
Date:   Mon Sep 19 13:35:26 2016 +0300

    drm/i915/backlight: setup backlight pwm alternate increment on backlight enable

in drm-intel-next-queued.

(In reply to Yuan Chao from comment #109)
> Also confirmed the updated patches work on MBA 6,2 (2013) too.
> 
> Just under certain condition, the backlight dimmed again right after
> resuming. One need to change the backlight level (hot key) to recover.


I just stumbled upon this thread trying to fix the same problem everybody is with their 6,2 Macbook Airs running linux.

If the patch in this thread actually works that is absolutely amazing work.

I'm not familiar with the .patch type. What is the way of installing this patch?

Thank you very much.

Morten

Closing old verified.