linux-stable.git/drivers/gpu/drm, branch v3.18.6

drm/i915: fix inconsistent brightness after resume

2015-02-06T06:36:08+00:00

commit 13f3fbe827d09e3182023c8c54058cbf97aa146e upstream.

commit 6dda730e55f412a6dfb181cae6784822ba463847
Author: Jani Nikula 
Date:   Tue Jun 24 18:27:40 2014 +0300

    drm/i915: respect the VBT minimum backlight brightness

introduced a bug which resulted in inconsistent brightness levels on
different machines. If a suspended was entered with the screen off some
machines would resume with the screen at minimum brightness and others
at maximum brightness.

The following commands can be used to produce this behavior.

  xset dpms force off
  sleep 1
  sudo systemctl suspend
  (resume ...)

The root cause of this problem is a comparison which checks to see if
the backlight level is zero when the panel is enabled.  If it is zero,
it is set to the maximum level.  Unfortunately, not all machines have a
minimum level of zero. On those machines the level is left at the
minimum instead of begin set to the maximum.

Fix the bug by updating the comparison to check for the minimum
backlight level instead of zero.  Also, expand the comparison for
the possible case when the level is less than the minimum.

Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness")
Signed-off-by: Jeremiah Mahler 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Init PPGTT before context enable

2015-02-06T06:36:08+00:00

commit f48a01651b1758550c4d3ee65ec726dfa0658780 upstream.

Commit 82460d972 ("drm/i915: Rework ppgtt init to no require an aliasing
ppgtt") introduced a regression on Broadwell, triggering the following
IOMMU fault at startup:

vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
dmar: DRHD: handling fault status reg 2
dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000
DMAR:[fault reason 23] Unknown
fbcon: inteldrmfb (fb0) is primary device

Further commentary from Daniel:

I sugggested this change to David after staring at the offending patch
for a while. I have no idea and theory whatsoever why this would upset
the gpu less than the other way round. But it seems to work. David
promised to chase hw people a bit more to get a more meaningful answer.

Wrt the comment that this deletes: I've done some digging and afaict
loading context before ppgtt enable was once required before our recent
restructuring of the context/ppgtt init code: Before that context sw
setup (i.e. allocating the default context) and hw setup was smashed
together. Also the setup of the default context was the bit that
actually allocated the aliasing ppgtt structures. Which is the reason
for the context before ppgtt depency.

Or was, since with all the untangling there's no no real depency any
more (functional, who knows what the hw is doing), so the comment is
just stale.

Signed-off-by: David Woodhouse
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman

drm/i915: BDW Fix Halo PCI IDs marked as ULT.

2015-02-06T06:36:08+00:00

commit 6b96d705f3cf435b0b8835b12c9742513c77fed6 upstream.

BDW with PCI-IDs ended in "2" aren't ULT, but HALO.
Let's fix it and at least allow VGA to work on this units.

v2: forgot ammend and v1 doesn't compile

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220
Cc: Xion Zhang 
Cc: Guo Jinxian 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Only fence tiled region of object.

2015-02-06T06:36:08+00:00

commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.

When creating a fence for a tiled object, only fence the area that
makes up the actual tiles.  The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.

To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles.  The extra space is considered
un-tiled and now behaves as if it was a linear object.

Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena 
Signed-off-by: Bob Paauwe 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm: fix fb-helper vs MST dangling connector ptrs (v2)

2015-02-06T06:36:08+00:00

commit 2148f18fdb45f31ca269a7787fbc24053cd42e70 upstream.

VT switch back/forth from console to xserver (for example) has potential
to go horribly wrong if a dynamic DP MST connector ends up in the saved
modeset that is restored when switching back to fbcon.

When removing a dynamic connector, don't forget to clean up the saved
state.

v1: original
v2: null out set->fb if no more connectors to avoid making i915 cranky

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968
Signed-off-by: Rob Clark 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Restore GART table contents after pinning it in VRAM v3

2015-02-06T06:36:07+00:00

commit 5636d2f842c7bd7800002868ead3d6b809d385a0 upstream.

The GART table BO has to be moved out of VRAM for suspend/resume. Any
updates to the GART table during that time were silently dropped without
this change. This caused GPU lockups on resume in some cases, see the bug
reports referenced below.

This might also make GPU reset more robust in some cases, as we no longer
rely on the GART table in VRAM being preserved across the GPU
lockup/reset.

v2: Add logic to radeon_gart_table_vram_pin directly instead of
    reinstating radeon_gart_restore
v3: Move code after assignment of rdev->gart.table_addr so that the GART
    TLB flush can work as intended, add code comment explaining why we're
    doing this

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
Reviewed-by: Christian König 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry

2015-02-06T06:36:07+00:00

commit cb65890610dca287718a63bd8a5d9ce3dc80c3d7 upstream.

get_page_entry calculates the GART page table entry, which is just written
to the GART page table by set_page_entry.

This is a prerequisite for the following fix.

Reviewed-by: Christian König 
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Replace the hw mutex with a hw spinlock

2015-02-06T06:36:06+00:00

commit 496eb6fd2c3fd13f4b914e537598e5c86ce4f52a upstream.

Fixes a case where we call vmw_fifo_idle() from within a wait function with
task state !TASK_RUNNING, which is illegal.

In addition, make the locking fine-grained, so that it is performed once
for every read- and write operation. This is of course more costly, but we
don't perform much register access in the timing critical paths anyway. Instead
we have the extra benefit of being sure that we don't forget the hw lock around
register accesses. I think currently the kms code was quite buggy w r t this.

This fixes Red Hat Bugzilla Bug 1180796

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: use rv515_ring_start on r5xx

2015-01-30T01:40:43+00:00

commit d8a74e186949e1a2c2f1309212478b0659bf9225 upstream.

This was accidently lost in 76a0df859def.

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

drm/radeon: add si dpm quirk list

2015-01-30T01:40:43+00:00

commit 5615f890bc6babdc2998dec62f3552326d06eb7b upstream.

This adds a quirks list to fix stability problems with
certain SI boards.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490

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