linux-stable.git/drivers/gpu, branch v3.18.10

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

2015-03-24T01:02:49+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-24T01:02:49+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-24T01:02:49+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-24T01:02:49+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/radeon: fix 1 RB harvest config setup for TN/RL

2015-03-24T01:02:49+00:00

commit dbfb00c3e7e18439f2ebf67fe99bf7a50b5bae1e upstream.

The logic was reversed from what the hw actually exposed.
Fixes graphics corruption in certain harvest configurations.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh

2015-03-24T01:02:48+00:00

commit 3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284 upstream.

Just in case it hasn't been calculated for the mode.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: enable native backlight control on old macs

2015-03-24T01:02:48+00:00

commit 7a26f9ad1b5badfd0200ce2262ad696e2a6b7fbb upstream.

Commit b7bc596ebbe0 ("drm/radeon: disable native
backlight control on pre-r6xx asics (v2)") accidently
broke backlight control on old mac laptops that use the
on-GPU backlight controller.

Signed-off-by: Nathan-J. Hirschauer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

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

2015-03-14T19:37:18+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: Sasha Levin

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

2015-03-14T19:37:18+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: Sasha Levin

drm/i915: Drop vblank wait from intel_dp_link_down

2015-03-14T19:37:18+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: Sasha Levin