BMC/Intel-BMC/linux.git/drivers/gpu/drm/i915, branch dev

drm/i915: Avoid TP3 on CHV

2015-08-19T08:13:59+00:00

This patch removes TP3 support on CHV since there is no support for HBR2 on this platform. v2: rename the function to indicate it checks source rates (Jani) v3: update comment to indicate TP3 dependency on HBR2 supported hardware (Jani) Cc: stable@vger.kernel.org # v4.1+ Reviewed-by: Ville Syrjälä Signed-off-by: Sivakumar Thulasimani [Jani: fixed a couple of checkpatch warnings.] Signed-off-by: Jani Nikula

drm/i915: remove HBR2 from chv supported list

2015-08-19T08:06:26+00:00

This patch removes 5.4Gbps from supported link rate for CHV since it is not supported in it. v2: change the ordering for better readability (Ville) Cc: stable@vger.kernel.org # v4.1+ Reviewed-by: Ville Syrjälä Signed-off-by: Sivakumar Thulasimani Signed-off-by: Jani Nikula

Revert "drm/i915: Add eDP intermediate frequencies for CHV"

2015-08-19T08:04:35+00:00

This reverts commit fe51bfb95c996733150c44d21e1c9f4b6322a326. Author: Ville Syrjälä Date: Thu Mar 12 17:10:38 2015 +0200 CHV does not support intermediate frequencies so reverting the patch that added it in the first place Cc: stable@vger.kernel.org # v4.1+ Reviewed-by: Ville Syrjälä Signed-off-by: Sivakumar Thulasimani Signed-off-by: Jani Nikula

Revert "drm/i915: Allow parsing of variable size child device entries from VBT"

2015-08-19T06:33:17+00:00

This reverts commit 047fe6e6db9161e69271f56daaafdaf2add023b1 Author: David Weinehall Date: Tue Aug 4 16:55:52 2015 +0300 drm/i915: Allow parsing of variable size child device entries from VBT That commit is not valid for v4.2, however it will be valid for v4.3. It was simply queued too early. The referenced regressing commit is just fine until the size of struct common_child_dev_config changes, and that won't happen until v4.3. Indeed, the expected size checks here rely on the increased size of the struct, breaking new platforms. Fixes: 047fe6e6db91 ("drm/i915: Allow parsing of variable size child device entries from VBT") Cc: Daniel Vetter Cc: David Weinehall Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula

drm/i915: Flag the execlists context object as dirty after every use

2015-08-17T07:12:09+00:00

Everytime we use the logical context with execlists it becomes dirty (as the hardware will write the new register values afterwards, as well as the GPU state that will be used). We need to then flag the context as dirty everytime since after a swap-out/swap-in cycle the dirty flag will be cleared, and a further swap-out cycle will then loose the most recent GPU state. Signed-off-by: Chris Wilson Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula

drm/i915: Commit planes on each crtc separately.

2015-08-13T09:09:18+00:00

This patch is based on the upstream commit 5ac1c4bcf073ad and amended for v4.2 to make sure it works as intended. Repeated calls to begin_crtc_commit can cause warnings like this: [ 169.127746] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616 [ 169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip [ 169.127840] 3 locks held by kms_flip/1947: [ 169.127843] #0: (&dev->mode_config.mutex){+.+.+.}, at: [] __drm_modeset_lock_all+0x9c/0x130 [ 169.127860] #1: (crtc_ww_class_acquire){+.+.+.}, at: [] __drm_modeset_lock_all+0xad/0x130 [ 169.127870] #2: (crtc_ww_class_mutex){+.+.+.}, at: [] drm_modeset_lock+0x38/0x110 [ 169.127879] irq event stamp: 665690 [ 169.127882] hardirqs last enabled at (665689): [] _raw_spin_unlock_irqrestore+0x55/0x70 [ 169.127889] hardirqs last disabled at (665690): [] intel_pipe_update_start+0x113/0x5c0 [i915] [ 169.127936] softirqs last enabled at (665470): [] __do_softirq+0x236/0x650 [ 169.127942] softirqs last disabled at (665465): [] irq_exit+0xc5/0xd0 [ 169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+ #4039 [ 169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014 [ 169.127957] ffff8800c49036f0 ffff8800cde5fa28 ffffffff817f6907 0000000080000001 [ 169.127964] 0000000000000000 ffff8800cde5fa58 ffffffff810aebed 0000000000000046 [ 169.127970] ffffffff81c5d518 0000000000000268 0000000000000000 ffff8800cde5fa88 [ 169.127981] Call Trace: [ 169.127992] [] dump_stack+0x4f/0x7b [ 169.128001] [] ___might_sleep+0x16d/0x270 [ 169.128008] [] __might_sleep+0x48/0x90 [ 169.128017] [] mutex_lock_nested+0x29/0x410 [ 169.128073] [] ? vgpu_write64+0x220/0x220 [i915] [ 169.128138] [] ? ironlake_update_primary_plane+0x2ff/0x410 [i915] [ 169.128198] [] intel_frontbuffer_flush+0x25/0x70 [i915] [ 169.128253] [] intel_finish_crtc_commit+0x4c/0x180 [i915] [ 169.128279] [] drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper] [ 169.128338] [] __intel_set_mode+0x684/0x830 [i915] [ 169.128378] [] intel_crtc_set_config+0x49a/0x620 [i915] [ 169.128385] [] ? mutex_unlock+0x9/0x10 [ 169.128391] [] drm_mode_set_config_internal+0x69/0x120 [ 169.128398] [] ? might_fault+0x57/0xb0 [ 169.128403] [] drm_mode_setcrtc+0x253/0x620 [ 169.128409] [] drm_ioctl+0x1a0/0x6a0 [ 169.128415] [] ? get_parent_ip+0x11/0x50 [ 169.128424] [] do_vfs_ioctl+0x2f8/0x530 [ 169.128429] [] ? trace_hardirqs_on+0xd/0x10 [ 169.128435] [] ? selinux_file_ioctl+0x56/0x100 [ 169.128439] [] SyS_ioctl+0x81/0xa0 [ 169.128445] [] system_call_fastpath+0x12/0x6f Solve it by using the newly introduced drm_atomic_helper_commit_planes_on_crtc. The problem here was that the drm_atomic_helper_commit_planes() helper we were using was basically designed to do begin_crtc_commit(crtc #1) begin_crtc_commit(crtc #2) ... commit all planes finish_crtc_commit(crtc #1) finish_crtc_commit(crtc #2) The problem here is that since our hardware relies on vblank evasion, our CRTC 'begin' function waits until we're out of the danger zone in which register writes might wind up straddling the vblank, then disables interrupts; our 'finish' function re-enables interrupts after the registers have been written. The expectation is that the operations between 'begin' and 'end' must be performed without sleeping (since interrupts are disabled) and should happen as quickly as possible. By clumping all of the 'begin' calls together, we introducing a couple problems: * Subsequent 'begin' invocations might sleep (which is illegal) * The first 'begin' ensured that we were far enough from the vblank that we could write our registers safely and ensure they all fell within the same frame. Adding extra delay waiting for subsequent CRTC's wasn't accounted for and could put us back into the 'danger zone' for CRTC #1. This commit solves the problem by using a new helper that allows an order of operations like: for each crtc { begin_crtc_commit(crtc) // sleep (maybe), then disable interrupts commit planes for this specific CRTC end_crtc_commit(crtc) // reenable interrupts } so that sleeps will only be performed while interrupts are enabled and we can be sure that registers for a CRTC will be written immediately once we know we're in the safe zone. The crtc->config->base.crtc update may seem unrelated, but the helper will use it to obtain the crtc for the state. Without the update it will dereference NULL and crash. Changes since v1: - Use Matt Roper's commit message. Signed-off-by: Maarten Lankhorst Reviewed-by: Matt Roper References: https://bugs.freedesktop.org/show_bug.cgi?id=90398 Reviewed-by: Ander Conselvan de Oliveira Signed-off-by: Jani Nikula

drm/i915: calculate primary visibility changes instead of calling from set_config

2015-08-13T09:08:47+00:00

This should be much cleaner, with the same effects. (cherry picked for v4.2 from commit fb9d6cf8c29bfcb0b3c602f7ded87f128d730382) Signed-off-by: Maarten Lankhorst Reviewed-by: Matt Roper References: https://bugs.freedesktop.org/show_bug.cgi?id=90398 Reviewed-by: Ander Conselvan de Oliveira Signed-off-by: Jani Nikula

drm/i915: Only dither on 6bpc panels

2015-08-13T08:31:56+00:00

In commit d328c9d78d64ca11e744fe227096990430a88477 Author: Daniel Vetter Date: Fri Apr 10 16:22:37 2015 +0200 drm/i915: Select starting pipe bpp irrespective or the primary plane we started to select the pipe bpp from sink capabilities and not from the primary framebuffer - that one might change (and we don't want to incur a modeset) and sprites might contain higher bpp content too. We also selected dithering on a 8 bpc screen displaying a 24bpp rgb primary, because pipe_bpp is 24 for such a typical 8 bpc sink, but since the commit mentioned above, base_bpp is always the absolute maximum supported by the hardware, e.g., 36 bpp on my Ironlake chip. Iow. the only way to not get dithering would have been to connect a deep color 12 bpc display, so pipe_bpp == 36 == base_bpp. Hence only enable dithering on 6bpc screens where we difinitely and always want it. Cc: Mario Kleiner Reported-by: Mario Kleiner Signed-off-by: Daniel Vetter Reviewed-and-tested-by: Mario Kleiner Signed-off-by: Jani Nikula

Merge tag 'drm-intel-fixes-2015-08-07' of git://anongit.freedesktop.org/drm-intel

2015-08-08T01:18:14+00:00

Pull drm fixes from Daniel Vetter: "One i915 regression fix and a drm core one since Dave's not around, both introduced in 4.2 so not cc: stable. The fix for the warning Ted reported isn't in here yet since he didn't yet supply a tested-by and I can't repro this one myself (it's in fixup code that needs firmware doing something i915 wouldn't do)" * tag 'drm-intel-fixes-2015-08-07' of git://anongit.freedesktop.org/drm-intel: drm/vblank: Use u32 consistently for vblank counters drm/i915: Allow parsing of variable size child device entries from VBT

drm/i915: Allow parsing of variable size child device entries from VBT

2015-08-06T15:28:26+00:00

VBT version 196 increased the size of common_child_dev_config. The parser code assumed that the size of this structure would not change. The modified code now copies the amount needed based on the VBT version, and emits a debug message if the VBT version is unknown (too new); since the struct config block won't shrink in newer versions it should be harmless to copy the maximum known size in such cases, so that's what we do, but emitting the warning is probably sensible anyway. In the longer run it might make sense to modify the parser code to use a version/feature mapping, rather than hardcoding things like this, but for now the variants are fairly managable. This fixes a regression introduced in commit 90e4f1592bb6e82f6690f0e05a8aadcf04d7bce7 Author: Ville Syrjälä Date: Wed Mar 25 18:45:58 2015 +0200 drm/i915: Fix the VBT child device parsing for BSW since we're hitting a DRM_ERROR on older platforms with this. v2: Stricter size checks Signed-off-by: David Weinehall [danvet: Fixup format string.] Signed-off-by: Daniel Vetter