kernel/linux.git/drivers/gpu/drm/i915, branch v3.11.10

drm/i915/dp: workaround BIOS eDP bpp clamping issue

2013-11-20T20:31:39+00:00

commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf upstream. This isn't a real fix to the problem, but rather a stopgap measure while trying to find a proper solution. There are several laptops out there that fail to light up the eDP panel in UEFI boot mode. They seem to be mostly IVB machines, including but apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot. The difference between UEFI and CSM is that the BIOS provides a different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and 1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz link, and for reasons yet unknown fail to light up the panel. Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with 2.7 GHz link, the eDP panel lights up. So essentially this is a link speed issue, and *not* a bpp clamping issue. The bug raised its head since commit 657445fe8660100ad174600ebfa61536392b7624 Author: Daniel Vetter Date: Sat May 4 10:09:18 2013 +0200 Revert "drm/i915: revert eDP bpp clamping code changes" which started clamping bpp *before* computing the link requirements, and thus affecting the required bandwidth. Clamping after the computations kept the link at 2.7 GHz. Even though the BIOS tells us to use 18 bpp through the VBT, it happily boots up at 24 bpp and 2.7 GHz itself! Use this information to selectively ignore the VBT provided value. We can't ignore the VBT eDP bpp altogether, as there are other laptops that do require the clamping to be used due to EDID reporting higher bpp than the panel can support. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950 Tested-by: Ulf Winkelvos Tested-by: jkp Signed-off-by: Jani Nikula Signed-off-by: Daniel Vetter [Jani: stable 3.11 backport] Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb

2013-11-13T03:08:12+00:00

commit 1fbc0d789d12fec313c91912fc11733fdfbab863 upstream. Originally I've thought that this is leftover hw state dirt from the BIOS. But after way too much helpless flailing around on my part I've noticed that the actual bug is when we change the state of an already active pipe. For example when we change the fdi lines from 2 to 3 without switching off outputs in-between we'll never see the crucial on->off transition in the ->modeset_global_resources hook the current logic relies on. Patch version 2 got this right by instead also checking whether the pipe is indeed active. But that in turn broke things when pipes have been turned off through dpms since the bifurcate enabling is done in the ->crtc_mode_set callback. To address this issues discussed with Ville in the patch review move the setting of the bifurcate bit into the ->crtc_enable hook. That way we won't wreak havoc with this state when userspace puts all other outputs into dpms off state. This also moves us forward with our overall goal to unify the modeset and dpms on paths (which we need to have to allow runtime pm in the dpms off state). Unfortunately this requires us to move the bifurcate helpers around a bit. Also update the commit message, I've misanalyzed the bug rather badly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507 Tested-by: Jan-Michael Brummer Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: No LVDS hardware on Intel D410PT and D425KT

2013-11-13T03:08:11+00:00

commit 645378d85ee524e429aa4cf52806047b56cdc596 upstream. The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as having LVDS but the hardware is not populated. This patch adds them to the list of such systems. Patch is against 3.11.4 v2: Patch revised to match the D425KT exactly as the D425KTW does have LVDS. According to Intel's documentation, the D410PTL and D410PLTW don't. Signed-off-by: Rob Pearce [danvet: Pimp commit message to my liking and add cc: stable.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Add support for pipe_bpp readout

2013-11-13T03:08:11+00:00

commit 4f56d12ebb28fceac4c6e60c8993fbfc122e1399 upstream. On CTG+ read out the pipe bpp setting from hardware and fill it into pipe config. Also check it appropriately. v2: Don't do the pipe_bpp extraction inside the PCH only code block on ILK+. Avoid the PIPECONF read as we already have read it for the PIPECONF_EANBLE check. Note: This is already in drm-intel-next-queued as commit 42571aefafb1d330ef84eb29418832f72e7dfb4c Author: Ville Syrjälä Date: Fri Sep 6 23:29:00 2013 +0300 drm/i915: Add support for pipe_bpp readout but is needed for the following bugfix. Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Add HSW CRT output readout support

2013-11-13T03:08:11+00:00

commit 7195a50b5c7e00cc3312934fd022c3006b533d12 upstream. Call intel_ddi_get_config() to get the pipe_bpp settings from DDI. The sync polarity settings from DDI are irrelevant for CRT output, so override them with data from the ADPA register. Note: This is already merged in drm-intel-next-queued as commit 6801c18c0a43386bb44712cbc028a7e05adb9f0d Author: Ville Syrjälä Date: Tue Sep 24 14:24:05 2013 +0300 drm/i915: Add HSW CRT output readout support but is required for the following edp bpp bugfix. v2: Extract intel_crt_get_flags() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691 Tested-by: Qingshuai Tian Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Retry DP aux_ch communications with a different clock after failure

2013-11-13T03:08:11+00:00

commit bc86625a4ff7574d4d4dba79723457711eb784e0 upstream. The w/a db makes the recommendation to both use a non-default value for the initial clock and then to retry with an alternative clock for Haswell with the Lakeport PCH. "On LPT:H, use a divider value of 63 decimal (03Fh). If there is a failure, retry at least three times with 63, then retry at least three times with 72 decimal (048h)." Signed-off-by: Chris Wilson Reviewed-by: Jani Nikula Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: split aux_clock_divider logic in a separated function for reuse.

2013-11-13T03:08:11+00:00

commit b84a1cf8950ed075c4ab2630514d4caaae504176 upstream. Prep patch for reuse aux_clock_divider with EDP_PSR_AUX_CTL setup. Reviewed-by: Paulo Zanoni Signed-off-by: Rodrigo Vivi Reviewed-by: Shobhit Kumar Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: fix rps.vlv_work initialization

2013-10-18T17:54:58+00:00

commit 671952a2a290a90017c64e75b7dd0343b0d005b4 upstream. During driver loading we are initializing rps.vlv_work in valleyview_enable_rps() via the rps.delayed_resume_work delayed work. This is too late since we are using vlv_work already via i915_driver_load()->intel_uncore_sanitize()-> intel_disable_gt_powersave(). This at least leads to the following kernel warning: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Fix this by initialzing vlv_work before we call intel_uncore_sanitize(). The regression was introduced in commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 Author: Konstantin Khlebnikov Date: Wed Jul 17 10:22:58 2013 +0400 drm/i915: fix long-standing SNB regression in power consumption after resume though there was no good reason to initialize the static vlv_work from another delayed work to begin with (especially since this will happen multiple times). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69397 Tested-by: shui yangwei Signed-off-by: Imre Deak Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Only apply DPMS to the encoder if enabled

2013-10-18T17:54:58+00:00

commit c9976dcf55c8aaa7037427b239f15e5acfc01a3a upstream. The current test for an attached enabled encoder fails if we have multiple connectors aliased to the same encoder - both connectors believe they own the enabled encoder and so we attempt to both enable and disable DPMS on the encoder, leading to hilarity and an OOPs: [ 354.803064] WARNING: CPU: 0 PID: 482 at /usr/src/linux/dist/3.11.2/drivers/gpu/drm/i915/intel_display.c:3869 intel_modeset_check_state+0x764/0x770 [i915]() [ 354.803064] wrong connector dpms state [ 354.803084] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_intel coretemp kvm_intel snd_hda_codec i915 kvm snd_hwdep snd_pcm_oss snd_mixer_oss crc32_pclmul snd_pcm crc32c_intel e1000e intel_agp igb ghash_clmulni_intel intel_gtt aesni_intel cfbfillrect aes_x86_64 cfbimgblt lrw cfbcopyarea drm_kms_helper ptp video thermal processor gf128mul snd_page_alloc drm snd_timer glue_helper 8250_pci snd pps_core ablk_helper agpgart cryptd sg soundcore fan i2c_algo_bit sr_mod thermal_sys 8250 i2c_i801 serial_core hwmon cdrom i2c_core evdev button [ 354.803086] CPU: 0 PID: 482 Comm: kworker/0:1 Not tainted 3.11.2 #1 [ 354.803087] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.00 05/03/2013 [ 354.803091] Workqueue: events console_callback [ 354.803092] 0000000000000009 ffff88023611db48 ffffffff814048ac ffff88023611db90 [ 354.803093] ffff88023611db80 ffffffff8103d4e3 ffff880230d82800 ffff880230f9b800 [ 354.803094] ffff880230f99000 ffff880230f99448 ffff8802351c0e00 ffff88023611dbe0 [ 354.803094] Call Trace: [ 354.803098] [] dump_stack+0x54/0x8d [ 354.803101] [] warn_slowpath_common+0x73/0x90 [ 354.803103] [] warn_slowpath_fmt+0x47/0x50 [ 354.803109] [] ? intel_ddi_connector_get_hw_state+0x5e/0x110 [i915] [ 354.803114] [] intel_modeset_check_state+0x764/0x770 [i915] [ 354.803117] [] intel_connector_dpms+0x3b/0x60 [i915] [ 354.803120] [] drm_fb_helper_dpms.isra.11+0x120/0x160 [drm_kms_helper] [ 354.803122] [] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper] [ 354.803123] [] fb_blank+0x52/0xc0 [ 354.803125] [] fbcon_blank+0x21b/0x2d0 [ 354.803127] [] ? update_rq_clock.part.74+0x13/0x30 [ 354.803129] [] ? lock_timer_base.isra.30+0x26/0x50 [ 354.803130] [] ? internal_add_timer+0x12/0x40 [ 354.803131] [] ? mod_timer+0xf8/0x1c0 [ 354.803133] [] do_unblank_screen+0xa1/0x1c0 [ 354.803134] [] poke_blanked_console+0xc7/0xd0 [ 354.803136] [] console_callback+0x13f/0x160 [ 354.803137] [] process_one_work+0x148/0x3d0 [ 354.803138] [] worker_thread+0x119/0x3a0 [ 354.803140] [] ? manage_workers.isra.30+0x2a0/0x2a0 [ 354.803141] [] kthread+0xbb/0xc0 [ 354.803142] [] ? kthread_create_on_node+0x120/0x120 [ 354.803144] [] ret_from_fork+0x7c/0xb0 [ 354.803145] [] ? kthread_create_on_node+0x120/0x120 This regression goes back to the big modeset rework and the conversion to the new dpms helpers which started with: commit 5ab432ef4997ce32c9406721b37ef6e97e57dae1 Author: Daniel Vetter Date: Sat Jun 30 08:59:56 2012 +0200 drm/i915/hdmi: convert to encoder->disable/enable Fixes: igt/kms_flip/dpms-off-confusion Reported-and-tested-by: Wakko Warner Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030 Link: http://lkml.kernel.org/r/20130928185023.GA21672@animx.eu.org Signed-off-by: Chris Wilson [danvet: Add regression citation, mention the igt testcase this fixes and slap a cc: stable on the patch.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915/hsw: Disable L3 caching of atomic memory operations.

2013-10-18T17:54:58+00:00

commit f3fc4884ebe6ae649d3723be14b219230d3b7fd2 upstream. Otherwise using any atomic memory operation will lock up the GPU due to a Haswell hardware bug. v2: Use the _MASKED_BIT_ENABLE macro. Drop drm parameter definition. Signed-off-by: Francisco Jerez Reviewed-by: Ben Widawsky Cc: Daniel Vetter [danvet: Fix checkpatch fail.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman