linux.git/drivers/gpu/drm/i915, branch v3.11

drm/i915: ivb: fix edp voltage swing reg val

2013-08-29T22:07:27+00:00

Fix the typo introduced in

commit 1a2eb4604b85c5efb343da8a4dcf41288fcfca85
Author: Keith Packard 
Date:   Wed Nov 16 16:26:07 2011 -0800

    drm/i915: Hook up Ivybridge eDP

This fixes eDP link-training failures and cases where all voltage swing
/pre-emphasis levels were tried and failed during clock recovery and -
as a fallback - we go on to do channel equalization with the last voltage
swing/pre-emphasis level which will succeed. Both issues can lead to a
blank screen.

v2:
- improve commit message

CC: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880
Tested-by: Jeremy Moles 
Signed-off-by: Imre Deak 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter

Merge tag 'drm-intel-fixes-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

2013-08-23T08:52:37+00:00

Just one patch that soaked for quite a bit to fix a resume issue,
resulting in gpu hangs (or worse) due to tlb containing garbage.

* tag 'drm-intel-fixes-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Invalidate TLBs for the rings after a reset

Merge tag 'drm-intel-fixes-2013-08-15' of git://people.freedesktop.org/~danvet/drm-intel

2013-08-19T03:49:20+00:00

* tag 'drm-intel-fixes-2013-08-15' of git://people.freedesktop.org/~danvet/drm-intel: (153 commits)
  drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code

drm/i915: unpin backing storage in dmabuf_unmap

2013-08-19T03:24:54+00:00

This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.

v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev->struct_mutex held that won't
result in an immediate deadlock since we never go through the dma_buf
interfaces for our own, reimported buffers. But it's still easy to
blow up and anger lockdep, but that's already the case with our ->map
implementation. Fixing this for real will involve per dma-buf ww mutex
locking by the callers. And lots of fun. So go with the duct-tape
approach for now.

Cc: Chris Wilson 
Reported-by: Maarten Lankhorst 
Cc: Maarten Lankhorst 
Tested-by: Armin K.  (v1)
Tested-by: Dave Airlie 
Acked-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm/i915: Invalidate TLBs for the rings after a reset

2013-08-18T17:37:41+00:00

After any "soft gfx reset" we must manually invalidate the TLBs
associated with each ring. Empirically, it seems that a
suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is
that the hardware would fail to note the new address for its status
page, and so it would continue to write the shadow registers and
breadcrumbs into the old physical address (now used by something
completely different, scary). Whereas the driver would read the new
status page and never see any progress, it would appear that the GPU
hung immediately upon resume.

Based on a patch by naresh kumar kachhi 

Reported-by: Thiago Macieira 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725
Signed-off-by: Chris Wilson 
Tested-by: Thiago Macieira 
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter

drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code

2013-08-14T18:26:49+00:00

If we get an error event really early in the driver setup sequence,
which gen3 is especially prone to with various display GTT faults we
Oops. So try to avoid this.

Additionally with Haswell the transcoders are a separate bank of
registers from the pipes (4 transcoders, 3 pipes). In event of an
error, we want to be sure we have a complete and accurate picture of
the machine state, so record all the transcoders in addition to all
the active pipes.

This regression has been introduced in

commit 702e7a56af3780d8b3a717f698209bef44187bb0
Author: Paulo Zanoni 
Date:   Tue Oct 23 18:29:59 2012 -0200

    drm/i915: convert PIPECONF to use transcoder instead of pipe

Based on the patch "drm/i915: Dump all transcoder registers on error"
from Chris Wilson:

v2: Rebase so that we don't try to be clever and try to figure out the
cpu transcoder from hw state. That exercise should be done when we
analyze the error state offline.

The actual bugfix is to not call intel_pipe_to_cpu_transcoder in the
error state capture code in case the pipes aren't fully set up yet.

v3: Simplifiy the err->num_transcoders computation a bit. While at it
make the error capture stuff save on systems without a display block.

v4: Fix fail, spotted by Jani.

v5: Completely new commit message, cc: stable.

Cc: Paulo Zanoni 
Cc: Damien Lespiau 
Cc: Jani Nikula 
Cc: Chris Wilson 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60021
Cc: stable@vger.kernel.org
Tested-by: Dustin King 
Reviewed-by: Jani Nikula 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter

drm/i915: do not disable backlight on vgaswitcheroo switch off

2013-08-07T09:57:09+00:00

On muxed systems, the other vgaswitcheroo client may depend on i915 to
handle the backlight. We began switching off the backlight since

commit a261b246ebd552fd5d5a8ed84cc931bb821c427f
Author: Daniel Vetter 
Date:   Thu Jul 26 19:21:47 2012 +0200

    drm/i915: disable all crtcs at suspend time

breaking backlight on discreet graphics in (some) muxed systems.

Keep the backlight on when the state is changed through vgaswitcheroo.

Note: The alternative would be to add a quirk table to achieve the same
based on system identifiers, but AFAICS it would asymptotically approach
effectively the same as this patch as more IDs are added, but with the
maintenance burden of the quirk table.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55311
Tested-by: Fede 
Tested-by: Aximab 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59785
Tested-by: sfievet 
Signed-off-by: Jani Nikula 
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter

drm/i915: Don't call encoder's get_config unless encoder is active

2013-08-07T09:57:09+00:00

The SDVO code tries to compare the encoder's and crtc's idea of the
pixel_multiplier. Normally they have to match, but when transitioning
to DPMS off, we turn off the pipe before reading out the pipe_config,
so the pixel_multiplier in the pipe_config will be 0, whereas the
encoder will still have its pixel_multiplier set to whatever value we
were using when the display was active. This leads to a warning
from intel_modeset_check_state().

WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378 intel_sdvo_get_config+0x158/0x160()
SDVO pixel multiplier mismatch, port: 0, encoder: 1
Modules linked in: snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep
CPU: 1 PID: 2846 Comm: Xorg Not tainted 3.11.0-rc3-00208-gbe1e8d7-dirty #19
Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS  MM11.88Z.0055.B03.0604071521 04/07/06
 00000000 00000000 ef0afa54 c1597bbb c1737ea4 ef0afa84 c10392ca c1737e6c
 ef0afab0 00000b1e c1737ea4 00000562 c12dfbe8 c12dfbe8 ef0afb14 00000000
 f697ec00 ef0afa9c c103936e 00000009 ef0afa94 c1737e6c ef0afab0 ef0afadc
Call Trace:
 [] dump_stack+0x41/0x56
 [] warn_slowpath_common+0x7a/0xa0
 [] warn_slowpath_fmt+0x2e/0x30
 [] intel_sdvo_get_config+0x158/0x160
 [] check_crtc_state+0x1e0/0xb10
 [] intel_modeset_check_state+0x29d/0x7c0
 [] intel_sdvo_dpms+0x5c/0xa0
 [] drm_mode_obj_set_property_ioctl+0x40e/0x420
 [] drm_mode_connector_property_set_ioctl+0x35/0x40
 [] drm_ioctl+0x3e4/0x540
 [] do_vfs_ioctl+0x72/0x570
 [] SyS_ioctl+0x8f/0xa0
 [] sysenter_do_call+0x12/0x22
---[ end trace 7ce940aff1366d60 ]---

Fix the problem by skipping the encoder get_config() function for
inactive encoders.

Tested-by: Linus Torvalds 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter

drm/i915: avoid brightness overflow when doing scale

2013-08-07T09:57:08+00:00

Some card's max brightness level is pretty large, e.g. on Acer Aspire
4732Z, the max level is 989910. If user space set a large enough level
then the current scale done in intel_panel_set_backlight will cause an
integer overflow and the scaled level will be mistakenly small, leaving
user with an almost black screen. This patch fixes this problem.

Signed-off-by: Aaron Lu 
[danvet: Add a comment to explain what's going on.]
Signed-off-by: Daniel Vetter

drm/i915: update last_vblank when disabling the power well

2013-08-07T09:57:06+00:00

The DRM layer keeps track of our vblanks and it assumes our vblank
counters only go back to zero when they overflow. The problem is that
when we disable the power well our counters also go to zero, but it
doesn't mean they did overflow. So on this patch we grab the lock and
update last_vblank so the DRM layer won't think our counters
overflowed.

This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblank

Regression introduced by the following commit:

commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
Author: Paulo Zanoni 
Date:   Wed Jul 3 17:12:13 2013 -0300
    drm/i915: switch disable_power_well default value to 1

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808
Signed-off-by: Paulo Zanoni 
[danvet: Added a comment that this might be better done in
drm_vblank_post_modeset in general.]
Signed-off-by: Daniel Vetter