kernel.git/drivers/gpu/drm/i915, branch linux-3.19.y

drm/i915: cope with large i2c transfers

2015-05-06T20:02:02Z

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:02:02Z

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:02:01Z

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: Push vblank enable/disable past encoder->enable/disable

2015-04-19T08:10:27Z

commit f9b61ff6bce9a44555324b29e593fdffc9a115bc upstream. It is platform/output depenedent when exactly the pipe will start running. Sometimes we just need the (cpu) pipe enabled, in other cases the pch transcoder is enough and in yet other cases the (DP) port is sending the frame start signal. In a perfect world we'd put the drm_crtc_vblank_on call exactly where the pipe starts running, but due to cloning and similar things this will get messy. And the current approach of picking the most conservative place for all combinations also doesn't work since that results in legit vblank waits (in encoder->enable hooks, e.g. the 2 vblank waits for sdvo) failing. Completely going back to the old world before commit 51e31d49c89055299e34b8f44d13f70e19aaaad1 Author: Daniel Vetter Date: Mon Sep 15 12:36:02 2014 +0200 drm/i915: Use generic vblank wait isn't great either since screaming when the vblank wait work because the pipe is off is kinda nice. Pick a compromise and move the drm_crtc_vblank_on right before the encoder->enable call. This is a lie on some outputs/platforms, but after the ->enable callback the pipe is guaranteed to run everywhere. So not that bad really. Suggested by Ville. v2: Same treatment for drm_crtc_vblank_off and encoder->disable: I've missed the ibx pipe B select w/a, which also has a vblank wait in the disable function (while the pipe is obviously still running). Cc: Ville Syrjälä Cc: Chris Wilson Acked-by: Ville Syrjälä Signed-off-by: Daniel Vetter Cc: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Align initial plane backing objects correctly

2015-04-19T08:10:15Z

commit f37b5c2be8979993efee2da50b51126e3908eb8b upstream. Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: Johannes W Cc: Chris Wilson Cc: Jani Nikula Reported-and-tested-by: Johannes W Signed-off-by: Daniel Vetter [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

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

2015-04-19T08:10:14Z

commit 5df0582bf036bb5f9a8ad8db5884fe13a55347d1 upstream. 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 Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

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

2015-04-19T08:10:14Z

commit 9c25210fd30991e68f93e2ec0857de2d967b5766 upstream. 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 Reviewed-by: Imre Deak Reviewed-by: Deepak S Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

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

2015-04-19T08:10:14Z

commit c9c52e24194a741f9fca96e7aa965f0fa36af504 upstream. 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 Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

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

2015-04-19T08:10:13Z

commit 840a1cf0cd533f30da792527ca5ff6a023d4a727 upstream. 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 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 Signed-off-by: Greg Kroah-Hartman

drm/i915: use in_interrupt() not in_irq() to check context

2015-03-26T12:59:51Z

commit 6c51d46f135b00c00373fcd029786ccef2b02b5b upstream. The kernel in_irq() function tests for hard-IRQ context only, so if a system is run with the kernel 'threadirqs' option selected, the test in intel_check_page_flip() generates lots of warnings, because then it gets called in soft-IRQ context. We can instead use in_interrupt() which allows for either type of interrupt, while still detecting and complaining about misuse of the page flip code if it is ever called from non-interrupt context. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321 Signed-off-by: Dave Gordon Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman