linux-toradex.git/drivers/gpu/drm, 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/radeon: fix 1 RB harvest config setup for TN/RL

2015-03-18T13:11:08+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-18T13:11:08+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-18T13:11:08+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: 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