linux-toradex.git/drivers/gpu/drm/i915, branch v4.0.3

drm/i915: cope with large i2c transfers

2015-05-06T20:04:04+00:00

commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream.

The hardware, according to the specs, is limited to 256 byte transfers,
and current driver has no protections in case users attempt to do larger
transfers. The code will just stomp over status register and mayhem
ensues.

Let's split larger transfers into digestable chunks. Doing this allows
Atmel MXT driver on Pixel 1 function properly (it hasn't since commit
9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts -
implement T44 message handling" which tries to consume multiple
touchscreen/touchpad reports in a single transaction).

Reviewed-by: Chris Wilson 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg

2015-05-06T20:04:04+00:00

commit b5f1c97f944482e98e6e39208af356630389d1ea upstream.

Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across
suspend/resume, so fix this.

This was introduced in

commit ddeea5b0c36f3665446518c609be91f9336ef674
Author: Imre Deak 
Date:   Mon May 5 15:19:56 2014 +0300

    drm/i915: vlv: add runtime PM support

I noticed this only by reading the code. To my knowledge it shouldn't
cause any real problems at the moment, since the power well backing this
register remains on across a runtime s/r. This may change once
system-wide s0ix functionality is enabled in the kernel.

v2:
- resend after a missing git add -u :/

Signed-off-by: Imre Deak 
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Mika Kuoppala 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Dont enable CS_PARSER_ERROR interrupts at all

2015-05-06T20:04:03+00:00

commit 37ef01ab5d24d1d520dc79f6a98099d451c2a901 upstream.

We stopped handling them in

commit aaecdf611a05cac26a94713bad25297e60225c29
Author: Daniel Vetter 
Date:   Tue Nov 4 15:52:22 2014 +0100

    drm/i915: Stop gathering error states for CS error interrupts

but just clearing is apparently not enough: A sufficiently dead gpu
left behind by firmware (*cough* coreboot *cough*) can keep the gpu in
an endless loop of such interrupts, eventually leading to the nmi
firing. And definitely to what looks like a machine hang.

Since we don't even enable these interrupts on gen5+ let's do the same
on earlier platforms.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171
Tested-by: Mono 
Tested-by: info@gluglug.org.uk
Reviewed-by: Mika Kuoppala 
Signed-off-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915/vlv: remove wait for previous GFX clk disable request

2015-04-07T13:14:12+00:00

Looks like it was introduced in:

commit 650ad970a39f8b6164fe8613edc150f585315289
Author: Imre Deak 
Date:   Fri Apr 18 16:35:02 2014 +0300

    drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of

but I'm not sure why.  It has caused problems for us in the past (see
85250ddff7a6 "drm/i915/chv: Remove Wait for a previous gfx force-off"
and 8d4eee9cd7a1 "drm/i915: vlv: increase timeout when forcing on the
GFX clock") and doesn't seem to be required, so let's just drop it.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89611
Signed-off-by: Jesse Barnes 
Tested-by: Darren Hart 
Reviewed-by: Deepak S 
Cc: stable@vger.kernel.org # c9c52e24194a: drm/i915/chv: Remove Wait ...
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula

drm/i915/chv: Remove Wait for a previous gfx force-off

2015-04-07T12:36:40+00:00

On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence

Signed-off-by: Deepak S 
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Signed-off-by: Jani Nikula

drm/i915/vlv: save/restore the power context base reg

2015-04-07T12:36:30+00:00

Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this
reg.  If it's unlocked, we can just restore the previous value, and if
it's locked (in case the BIOS re-programmed it for us) the write will be
ignored and we'll still have "did it move" sanity check in the PM code to
warn us if something is still amiss.

References: https://bugs.freedesktop.org/show_bug.cgi?id=89611
Signed-off-by: Jesse Barnes 
Tested-by: Darren Hart 
Cc: stable@vger.kernel.org
Reviewed-by: Imre Deak 
Reviewed-by: Deepak S 
Signed-off-by: Jani Nikula

drm/i915: Reject the colorkey ioctls for primary and cursor planes

2015-04-02T08:25:50+00:00

The legcy colorkey ioctls are only implemented for sprite planes, so
reject the ioctl for primary/cursor planes. If we want to support
colorkeying with these planes (assuming we have hw support of course)
we should just move ahead with the colorkey property conversion.

Testcase: kms_legacy_colorkey
Cc: Tommi Rantala 
Cc: stable@vger.kernel.org
Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.com
Reported-and-tested-by: Tommi Rantala 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula

drm/i915: Skip allocating shadow batch for 0-length batches

2015-03-30T14:59:47+00:00

Since

commit 17cabf571e50677d980e9ab2a43c5f11213003ae
Author: Chris Wilson 
Date:   Wed Jan 14 11:20:57 2015 +0000

    drm/i915: Trim the command parser allocations

we may then try to allocate a zero-sized object and attempt to extract
its pages. Understandably this fails.

Note that the real offender seems to be

commit b9ffd80ed659c559152c042e74741f4f60cac691
Author: Brad Volkin 
Date:   Thu Dec 11 12:13:10 2014 -0800

    drm/i915: Use batch length instead of object size in command parser

Testcase: igt/gem_exec_nop #ivb,byt,hsw
Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
[cherry picked from commit 743e78c1d726d875b98ff9689cc77c4d3d5d9ae2
from drm-intel-next because 4.0 seems to be affected by this too,
despite that the obvious culprit is definitely not in 4.0. Whatever,
if fixes a bug.
Signed-off-by: Daniel Vetter

drm/i915: Fixup legacy plane->crtc link for initial fb config

2015-03-26T11:39:04+00:00

This is a very similar bug in the load detect code fixed in

commit 9128b040eb774e04bc23777b005ace2b66ab2a85
Author: Daniel Vetter 
Date:   Tue Mar 3 17:31:21 2015 +0100

    drm/i915: Fix modeset state confusion in the load detect code

But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...

Cc: Matt Roper 
Cc: Linus Torvalds 
Cc: Chris Wilson 
Cc: Josh Boyer 
Cc: Jani Nikula 
Reported-and-tested-by: Josh Boyer 
Signed-off-by: Daniel Vetter 
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com
Signed-off-by: Jani Nikula

drm/i915: Fix atomic state when reusing the firmware fb

2015-03-26T11:38:10+00:00

Right now, we get a warning when taking over the firmware fb:

  [drm:drm_atomic_plane_check] FB set but no CRTC

with the following backtrace:

  [] drm_atomic_check_only+0x35d/0x510 [drm]
  [] drm_atomic_commit+0x17/0x60 [drm]
  [] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
  [] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
  [] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
  [] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
  [] intel_fbdev_set_par+0x1a/0x60 [i915]
  [] fbcon_init+0x4f4/0x580

That's because we update the plane state with the fb from the firmware, but we
never associate the plane to that CRTC.

We don't quite have the full DRM take over from HW state just yet, so
fake enough of the plane atomic state to pass the checks.

v2: Fix the state on which we set the CRTC in the case we're sharing the
    initial fb with another pipe. (Matt)

Signed-off-by: Damien Lespiau 
Reviewed-by: Matt Roper 
Signed-off-by: Daniel Vetter 
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com
Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com
Signed-off-by: Jani Nikula