linux-toradex.git/drivers/gpu/drm/i915, branch v3.19.2

drm/i915: Check for driver readyness before handling an underrun interrupt

2015-03-18T13:11:09+00:00

commit 54fc7c1c961cb39edfe31f8a3f5ba6414e134b37 upstream.

When we takeover from the BIOS and install our interrupt handler, the
BIOS may have left us a few surprises in the form of spontaneous
interrupts. (This is especially likely on hardware like 965gm where
display fifo underruns are continuous and the GMCH cannot filter that
interrupt souce.) As we enable our IRQ early so that we can use it
during hardware probing, our interrupt handler must be prepared to
handle a few sources prior to being fully configured. As such, we need
to add a simple is-ready check prior to dereferencing our KMS state for
reporting underruns.

Reported-by: Rob Clark 
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972
Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
[Jani: dropped the extra !]
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: avoid processing spurious/shared interrupts in low-power states

2015-03-18T13:11:09+00:00

commit 2dd2a883aad7c852400027c2261bcab69d9e238e upstream.

Atm, it's possible that the interrupt handler is called when the device
is in D3 or some other low-power state. It can be due to another device
that is still in D0 state and shares the interrupt line with i915, or on
some platforms there could be spurious interrupts even without sharing
the interrupt line. The latter case was reported by Klaus Ethgen using a
Lenovo x61p machine (gen 4). He noticed this issue via a system
suspend/resume hang and bisected it to the following commit:

commit e11aa362308f5de467ce355a2a2471321b15a35c
Author: Jesse Barnes 
Date:   Wed Jun 18 09:52:55 2014 -0700

    drm/i915: use runtime irq suspend/resume in freeze/thaw

This is a problem, since in low-power states IIR will always read
0xffffffff resulting in an endless IRQ servicing loop.

Fix this by handling interrupts only when the driver explicitly enables
them and so it's guaranteed that the interrupt registers return a valid
value.

Note that this issue existed even before the above commit, since during
runtime suspend/resume we never unregistered the handler.

v2:
- clarify the purpose of smp_mb() vs. synchronize_irq() in the
  code comment (Chris)

v3:
- no need for an explicit smp_mb(), we can assume that synchronize_irq()
  and the mmio read/writes in the install hooks provide for this (Daniel)
- remove code comment as the remaining synchronize_irq() is self
  explanatory (Daniel)

v4:
- drm_irq_uninstall() implies synchronize_irq(), so no need to call it
  explicitly (Daniel)

Reference: https://lkml.org/lkml/2015/2/11/205
Reported-and-bisected-by: Klaus Ethgen 
Signed-off-by: Imre Deak 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Dell Chromebook 11 has PWM backlight

2015-03-18T13:11:09+00:00

commit cf6f0af9fbdd90b81af14fa6375387131cd8adf1 upstream.

Add quirk for Dell Chromebook 11 backlight.

Reported-and-tested-by: Owen Garland 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93451
Acked-by: Damien Lespiau 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Check obj->vma_list under the struct_mutex

2015-03-18T13:11:09+00:00

commit 6c31a614c43ae274546f736b2a33363e149c3dc2 upstream.

When we walk the list of vma, or even for protecting against concurrent
framebuffer creation, we must hold the struct_mutex or else a second
thread can corrupt the list as we walk it.

Fixes regression from
commit d7f46fc4e7323887494db13f063a8e59861fefb0
Author: Ben Widawsky 
Date:   Fri Dec 6 14:10:55 2013 -0800

    drm/i915: Make pin count per VMA

References: https://bugs.freedesktop.org/show_bug.cgi?id=89085
Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915/bdw: PCI IDs ending in 0xb are ULT.

2015-03-18T13:11:08+00:00

commit 0dc6f20b9803f09726bbb682649d35cda8ef5b5d upstream.

When reviewing patch that fixes VGA on BDW Halo Jani noticed that
we also had other ULT IDs that weren't listed there.

So this follow-up patch add these pci-ids as halo and fix comments
on i915_pciids.h

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Clamp efficient frequency to valid range

2015-03-18T13:10:57+00:00

commit 46efa4abe5712276494adbce102f46e3214632fd upstream.

The efficient frequency (RPe) should stay in the range
RPn <= RPe <= RP0.  The pcode clamps the returned value
internally on Broadwell but not on Haswell.

Fix for missing range check in
commit 93ee29203f506582cca2bcec5f05041526d9ab0a
Author: Tom O'Rourke 
Date:   Wed Nov 19 14:21:52 2014 -0800

    drm/i915: Use efficient frequency for HSW/BDW

Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/059802.html
Reported-by: Michael Auchter 
Suggested-by: Chris Wilson 
Signed-off-by: Tom O'Rourke 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Correct the IOSF Dev_FN field for IOSF transfers

2015-03-18T13:10:57+00:00

commit d180d2bbb66579e3bf449642b8ec2a76f4014fcd upstream.

As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target
device and not the source. So PCI_DEVFN(2,0) is not correct. Further the
port ID should be enough to identify devices unless they are MFD. The
SB_DevFn was intended to remove ambiguity in case of these MFD devices.

For non MFD devices the recommendation for the target device IP was to
ignore these fields, but not all of them followed the recommendation.
Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so
does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because
of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0).
It turned out that this did not follow the recommendation and expected 0
in this field.

In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for
all devices except target PCI devices.

Signed-off-by: Shobhit Kumar 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Prevent use-after-free in invalidate_range_start callback

2015-03-18T13:10:57+00:00

commit 460822b0b1a77db859b0320469799fa4dbe4d367 upstream.

It's possible for invalidate_range_start mmu notifier callback to race
against userptr object release. If the gem object was released prior to
obtaining the spinlock in invalidate_range_start we're hitting null
pointer dereference.

Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close
Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap
Cc: Chris Wilson 
Signed-off-by: Michał Winiarski 
Reviewed-by: Chris Wilson 
[Jani: added code comment suggested by Chris]
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Drop vblank wait from intel_dp_link_down

2015-03-18T13:10:57+00:00

commit 0ca09685546fed5fc8f0535204f0626f352140f4 upstream.

Nothing in Bspec seems to indicate that we actually needs this, and it
looks like can't work since by this point the pipe is off and so
vblanks won't really happen any more.

Note that Bspec mentions that it takes a vblank for this bit to
change, but _only_ when enabling.

Dropping this code quenches an annoying backtrace introduced by the
more anal checking since

commit 51e31d49c89055299e34b8f44d13f70e19aaaad1
Author: Daniel Vetter 
Date:   Mon Sep 15 12:36:02 2014 +0200

    drm/i915: Use generic vblank wait

Note: This fixes the fallout from the above commit, but does not address
the shortcomings of the IBX transcoder select workaround implementation
discussed during review [1].

[1] http://mid.gmane.org/87y4o7usxf.fsf@intel.com

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86095
Signed-off-by: Daniel Vetter 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Insert a command barrier on BLT/BSD cache flushes

2015-03-18T13:10:57+00:00

commit f0a1fb10e5f79f5aaf8d7e94b9fa6bf2fa9aeebf upstream.

This looked like an odd regression from

commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b
Author: Chris Wilson 
Date:   Thu Jun 12 10:28:55 2014 +0100

    drm/i915: Restrict GPU boost to the RCS engine

but in reality it undercovered a much older coherency bug. The issue that
boosting the GPU frequency on the BCS ring was masking was that we could
wake the CPU up after completion of a BCS batch and inspect memory prior
to the write cache being fully evicted. In order to serialise the
breadcrumb interrupt (and so ensure that the CPU's view of memory is
coherent) we need to perform a post-sync operation in the MI_FLUSH_DW.

v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists).

Also fix the invalidate_domains mask in gen8_emit_flush() for ring !=
VCS.

Testcase: gpuX-rcs-gpu-read-after-write
Signed-off-by: Chris Wilson 
Acked-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman