kernel/drivers/gpu/drm/i915/intel_display.c, branch linux-3.6.y

drm/i915: do not default to 18 bpp for eDP if missing from VBT

2012-12-17T17:26:53Z

commit 9a30a61f3516871c5c638fd7c025fbaa11ddf7fe upstream. commit 500a8cc466a24e2fbc4c86ef9c6467ae2ffdeb0c Author: Zhenyu Wang Date: Wed Jan 13 11:19:52 2010 +0800 drm/i915: parse eDP panel color depth from VBT block originally introduced parsing bpp for eDP from VBT, with a default of 18 bpp if the eDP BIOS data block is not present. Turns out that default seems to break the Macbook Pro with retina display, as noted in commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter Date: Fri Aug 10 11:10:20 2012 +0200 drm/i915: ignore eDP bpc settings from vbt Since we can't ignore bpc settings from VBT completely after all, get rid of the default. Do not clamp eDP to 18 bpp by default if the eDP BDB is missing from VBT. Signed-off-by: Jani Nikula Tested-by: Henrik Rydberg [danvet: paste in the updated commit message from irc.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: do not ignore eDP bpc settings from vbt

2012-12-17T17:26:52Z

commit 2f4f649a69a9eb51f6e98130e19dd90a260a4145 upstream. There are laptops out there that need the eDP bpc from VBT. This is effectively a revert of commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter Date: Fri Aug 10 11:10:20 2012 +0200 drm/i915: ignore eDP bpc settings from vbt but putting the VBT check after the EDID check to see them both in dmesg if this clamps more than the EDID. We have enough history with bpc clamping to warrant the extra debug info. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47641 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56401 Signed-off-by: Jani Nikula Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag

2012-10-21T16:32:42Z

commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 upstream. The dithering introduced in commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf Author: Adam Jackson Date: Tue Dec 13 15:41:00 2011 -0800 drm/i915/dp: Dither down to 6bpc if it makes the mode fit stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use the original mode, without the flag, so it would never have any effect. However, the BPC was clamped by VBT settings, making things work by coincidence, until that part was removed in commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter Date: Fri Aug 10 11:10:20 2012 +0200 Use adjusted_mode instead of mode when checking for INTEL_MODE_DP_FORCE_6BPC to make the flag have effect. v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by Daniel both before and after sending the first patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621 CC: Adam Jackson Signed-off-by: Jani Nikula Reviewed-by: Adam Jackson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Flush the pending flips on the CRTC before modification

2012-10-12T20:50:29Z

commit 5bb61643f6a70d48de9cfe91ad0fee0d618b6816 upstream. This was meant to be the purpose of the intel_crtc_wait_for_pending_flips() function which is called whilst preparing the CRTC for a modeset or before disabling. However, as Ville Syrjala pointed out, we set the pending flip notification on the old framebuffer that is no longer attached to the CRTC by the time we come to flush the pending operations. Instead, we can simply wait on the pending unpin work to be finished on this CRTC, knowning that the hardware has therefore finished modifying the registers, before proceeding with our direct access. Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply schedule the flip immediately when the pipe is disabled, leading to other funny issues. Signed-off-by: Chris Wilson [danvet: Added i-g-t note and cc: stable] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: prevent possible pin leak on error path

2012-10-12T20:50:26Z

commit ab3951eb74e7c33a2f5b7b64d72e82f1eea61571 upstream. We should not hit this under any sane conditions, but still, this does not looks right. Reported-by: Herton Ronaldo Krzesinski CC: Chris Wilson CC: Daniel Vetter Reviewed-by: Chris Wlison Signed-off-by: Eugeni Dodonov Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: enable lvds pin pairs before dpll on gen2

2012-09-17T08:04:39Z

Otherwise things migt not work too well. Breakage introduced in commit eb1cbe4848b01f9f073064377875bc7d71eb401b Author: Daniel Vetter Date: Wed Mar 28 23:12:16 2012 +0200 drm/i915: split PLL update code out of i9xx_crtc_mode_set Cc: Jesse Barnes Cc: stable@vger.kernel.org (for 3.5 only) Reviewed-by: Jesse Barnes Signed-off-by: Daniel Vetter

drm/i915: fix up the IBX transcoder B check

2012-09-11T15:25:14Z

This has been added in commit de9a35abb3b343a25065449234e47a76c4f3454a Author: Daniel Vetter Date: Tue Jun 5 11:03:40 2012 +0200 drm/i915: assert that the IBX port transcoder select w/a is implemented Unfortunately I've failed to notice that these checks are not just called for the port that is about to be disabled, but for all (which makes sense for an assert ...), and the WARN missfired when disabling another pipe than the one with the dp port. Hence also check whether the port is actually disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54688 Reviewed-by: Paulo Zanoni Signed-Off-by: Daniel Vetter

drm/i915: fix wrong order of parameters in port checking functions

2012-08-23T09:44:53Z

Wrong order of parameters passed-in when calling hdmi/adpa /lvds_pipe_enabled(), 2nd and 3rd parameters are reversed. This bug was indroduced by commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37 Author: Keith Packard Date: Sat Aug 6 10:35:34 2011 -0700 drm/i915: Fix PCH port pipe select in CPT disable paths The reachable tag for this commit is v3.1-rc1-3-g1519b99 Signed-off-by: Anhua Xu Reviewed-by: Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44876 Tested-by: Daniel Schroeder Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter

drm/i915: ignore eDP bpc settings from vbt

2012-08-11T19:42:52Z

This has originally been introduced to not oversubscribe the dp links in commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18 Author: Zhenyu Wang Date: Tue Jan 12 05:38:31 2010 +0800 drm/i915: fix pixel color depth setting on eDP Since then we've fixed up the dp link bandwidth calculation code and should now automatically fall back to 6bpc dithering. So this is unnecessary. Furthermore it seems to break the new MacbookPro with retina display, hence let's just rip this out. Reported-by: Benoit Gschwind Cc: Benoit Gschwind Cc: Francois Rigaut Cc: Greg KH Cc: stable@vger.kernel.org Tested-by: Benoit Gschwind Tested-by: Bernhard Froemel Signed-off-by: Daniel Vetter -- Testing feedback highgly welcome, and thanks for Benoit for finding out that the bpc computations are busted. -Daniel

Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

2012-08-08T23:54:49Z

Daniel writes: "- Regression fixer for an OOPS at boot when i915.ko is built-in and CONFIG_PM=n, introduce in 3.5 (patch from Hunt Xu) - Regression fixer for occlusion query failures, the required w/a wasn't applied in all cases (thanks to Eric for tracking this on down). - dmar vs. dma_buf imprt fix (Dave Airlie) - 2 patches to fight down forcewake issues on snb. This is the stuff I've talked about 2 weeks ago already, it's a minefield. Investigation still going on, but afaict this is the best we have for now. - a few minor things to keep coverty&compiler happy (Alan, Davendra, Stéphane) - tons of hsw pci ids - this one is a bit late because internal approval sometimes takes a while, but ppl in charge finally agreed that world+dog already knows about ult and crw haswell variants ;-) Wrt regressions I'm aware of: - the power regression due to semaphores=1. Ben is running around with a killawatt, unfortunately we have a hard time reproducing this one. And this /shouldn't/ increase power usage. Ben has turned up a few odds bits though already. - the lvds fix in 3.6-rc1 broke a backlight after lid close/open (but can be resurrected with a modeset cycle). I guess we anger the bios - I'm still looking into this one. - gmbus broke edid reading on an odd-ball monitor, we need to fall-back. Due to vacation (both mine&the reporter's) this is stalling for a final patch and a tested-by on it. But issue is fully diagnosed." * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: correctly order the ring init sequence drm/i915: add more Haswell PCI IDs drm/i915: make rc6 in sysfs functions conditional drm/i915: Workaround hang with BSD and forcewake on SandyBridge drm/i915: Make intel_panel_get_backlight static. i915: don't map imported dma-bufs for dmar. drm/i915: remove unused variable drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround. drm/i915: fix forcewake related hangs on snb i915: Remove silly test i915: fix error path leak in intel_sdvo_write_cmd vlv: it might be wise if we initialised the flag value...