I have a Dell Latitude e6510, intel i5 CPU and intel integrated graphics. As also reported here https://bugs.freedesktop.org/show_bug.cgi?id=29278 , there seems to be something wrong with the display during startup. The screen flickers, goes white, then I see the boot text instead of the OS's splash, the screen is turned on and off twice, but finally it comes on and I see the login screen. This is under today's drm-intel-next, from ickle's repository. Same behavior is also observed with Jesse Barnes's edp-fixes-2 branch. I should also mention that the problem does not occur when I use kernel 2.6.36, with the two patches mentioned here https://bugs.freedesktop.org/show_bug.cgi?id=29278#c63 . Basically they add a 300 ms delay to ironlake_panel_on and ironlake_panel_off in intel_dp.c . When I increase those delays to 900ms everything works as expected. Let me know if I should attach any logfiles.
A 2 second pause during booting, resume and dpms on... You've got to be kidding me. :(
I don't particularly like the idea either, but it works perfectly. No flickering at all and very reliable, even when suspending mutliple times. I also tried 300ms and 500ms, but that wasn't enough. (In reply to comment #1) > A 2 second pause during booting, resume and dpms on... You've got to be kidding > me. :(
In edp-fixes-2 I had two commits that helped with this on my hw: commit 73a1fe8624176243aed92359d299c29765e546f3 drm/i915: use VDD AUX override to make panel power sequencing look better and commit 45cc75526cd5a8cd64992263562c11f36a408d7e drm/i915: remove now unnecessary delays in eDP panel power sequencing do you have those in your tree? I'll try on my e6510 now...
FWIW I don't see any ugly flicker with drm-intel-next. I do see some boot messages, looks like Ubuntu loads ips before i915 which prints a warning, but other than that it seems fine (no flicker, no white screen).
You could try this patch to avoid the IPS error. The reason you don't see this on 2.6.36 + henk's patch is that 2.6.36 doesn't have IPS at all, so it's not even an option. diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c index 1294a39..f8edbf5 100644 --- a/drivers/platform/x86/intel_ips.c +++ b/drivers/platform/x86/intel_ips.c @@ -1572,7 +1572,7 @@ static int ips_probe(struct pci_dev *dev, const struct pci ips->poll_turbo_status = true; if (!ips_get_i915_syms(ips)) { - dev_err(&dev->dev, "failed to get i915 symbols, graphics turbo d + dev_info(&dev->dev, "failed to get i915 symbols, graphics turbo ips->gpu_turbo_enabled = false; } else { dev_dbg(&dev->dev, "graphics turbo enabled\n");
No, I take that back, 2.6.36 does have IPS, but maybe something else in your config is different causing it to suppress the i915 symbol warning.
The two commits you mentioned were not in my drm-intel-next branch (from git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel), so I got them from your tree and applied them. It's compiling right now. I do get the warning about the i915 symbols, both with 2.6.36 + henk's patches and with drm-intel-next, so that's not what's causing this problem. The solution for those error messages is, indeed, making sure that ips loads after i915. So I blacklisted intel_ips and added it to /etc/modules. (In reply to comment #6) > No, I take that back, 2.6.36 does have IPS, but maybe something else in your > config is different causing it to suppress the i915 symbol warning.
Jesse, you never sent those to the list so I didn't go looking for them buried deep in that branch!
> Jesse, you never sent those to the list so I didn't go looking for them buried > deep in that branch! I committed them right after you warned me not to clean things up anymore; I think I just mentioned them and assumed you'd look & pick them up, but either way I'll post them, sorry!
I applied the two patches mentioned by Jesse to drm-intel-next. The flicker is gone now, but the display is still being turned on and off twice (backlight goes on, screen goes completely black, backlight comes back on, everything goes completely black again). (In reply to comment #9) > > Jesse, you never sent those to the list so I didn't go looking for them buried > > deep in that branch! > > I committed them right after you warned me not to clean things up > anymore; I think I just mentioned them and assumed you'd look & pick > them up, but either way I'll post them, sorry!
I've applied those two patches to drm-intel-next, so it should a suitable base for further testing again.
I am not sure this is the same bug, but I noticed that if I press Esc during the plymouth, the flickering continues to appear in X too. Sometimes it stops booting. I have cloned the drm-intel-next today and installed so it should have the fixes already, right? Please see the video I recorded: http://akovari.eu/26012011004.mp4
One reporter has suggested that this fixed their eDP flicker: commit 2704cf5fbd248871a745d210733c6319959d2b0c Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jul 28 11:52:45 2011 -0700 drm/i915: flush plane control changes on ILK+ as well After writing to the plane control reg we need to write to the surface reg to trigger the double buffered register latch. On previous chipsets, writing to DSPADDR was enough, but on ILK+ DSPSURF is the reg that triggers the double buffer latch. v2: write DSPADDR too to cover pre-965 chipsets v3: use flush_display_plane instead, that's what it's for v4: send the right patch Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Keith Packard <keithp@keithp.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
For the original reporter: Is this still an issue with latest kernels (or whatever you currently have)? If not, please add your the kernel this works for you and close the bug. Thanks. [Everyone else: Please open separate bugs for your issues or quickly ask a dev on #intel-gfx whether we're already tracking that bug somewhere.]
Original reporter seems to have disappeared, closing. Please reopen if this is still an issue for you.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.