kernel/linux.git/drivers/gpu, branch v4.7.4

drm/vc4: Fix oops when userspace hands in a bad BO.

2016-09-15T06:20:27+00:00

commit 552416c146fadc67cd9b53ef7adf88d3381c43a6 upstream. We'd end up NULL pointer dereferencing because we didn't take the error path out in the parent. Fixes igt vc4_lookup_fail test. Signed-off-by: Eric Anholt Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.") Signed-off-by: Greg Kroah-Hartman

drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

2016-09-15T06:20:27+00:00

commit 9326e6f25574bbb8bd48206d245654780e3fd665 upstream. Overflow memory handling is tricky: While it's still referenced by the BPO registers, we want to keep it from being freed. When we are putting a new set of overflow memory in the registers, we need to assign the old one to the last rendering job using it. We were looking at "what's currently running in the binner", but since the bin/render submission split, we may end up with the binner completing and having no new job while the renderer is still processing. So, if we don't find a bin job at all, look at the highest-seqno (last) render job to attach our overflow to. Signed-off-by: Eric Anholt Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Signed-off-by: Greg Kroah-Hartman

drm/vc4: Use drm_free_large() on handles to match its allocation.

2016-09-15T06:20:27+00:00

commit d5fb46e0e3b7e49ee83ba92efc3ab4e1a545ecc1 upstream. If you managed to exceed the limit to switch to vmalloc, we'd use the wrong free. Signed-off-by: Eric Anholt Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.") Signed-off-by: Greg Kroah-Hartman

drm/msm: fix use of copy_from_user() while holding spinlock

2016-09-15T06:20:27+00:00

commit 89f82cbb0d5c0ab768c8d02914188aa2211cd2e3 upstream. Use instead __copy_from_user_inatomic() and fallback to slow-path where we drop and re-aquire the lock in case of fault. Reported-by: Vaishali Thakkar Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman

drm: Reject page_flip for !DRIVER_MODESET

2016-09-15T06:20:27+00:00

commit 6f00975c619064a18c23fd3aced325ae165a73b9 upstream. Somehow this one slipped through, which means drivers without modeset support can be oopsed (since those also don't call drm_mode_config_init, which means the crtc lookup will chase an uninitalized idr). Reported-by: Alexander Potapenko Cc: Alexander Potapenko Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/atomic: Don't potentially reset color_mgmt_changed on successive property updates.

2016-09-15T06:20:27+00:00

commit add1fa75101263ab4d74240f93000998d4325624 upstream. Due to assigning the 'replaced' value instead of or'ing it, if drm_atomic_crtc_set_property() gets called multiple times, the last call will define the color_mgmt_changed flag, so a non-updating call to a property can reset the flag and prevent actual hw state updates required by preceding property updates. Signed-off-by: Mario Kleiner Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon: only apply the SS fractional workaround to RS[78]80

2016-09-15T06:20:26+00:00

commit ae5b80d2b68eac945b124227dea34462118a6f01 upstream. Looks like some RV6xx have problems with that. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97099 Reviewed-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix radeon_move_blit on 32bit systems

2016-09-15T06:20:26+00:00

commit 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 upstream. This bug seems to be present for a very long time. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/i915: Enable polling when we don't have hpd

2016-09-07T06:34:51+00:00

commit 84c8e0963da434d37355079b568465cd121af295 upstream. Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get their display to turn on. For instance; if we boot a Valleyview system without any monitors connected, it won't need any of it's power wells and thus shut them off. Since this causes us to lose HPD, this means that unless the user knows how to ssh into their machine and do a manual reprobe for monitors, none of the monitors they connect after booting will actually work. Eventually we should come up with a better fix then having to enable polling for this, since this makes rpm a lot less useful, but for now the infrastructure in i915 just isn't there yet to get hpd in these situations. Changes since v1: - Add comment explaining the addition of the if (!mode_config->poll_running) in intel_hpd_init() - Remove unneeded if (!dev->mode_config.poll_enabled) in i915_hpd_poll_init_work() - Call to drm_helper_hpd_irq_event() after we disable polling - Add cancel_work_sync() call to intel_hpd_cancel_work() Changes since v2: - Apparently dev->mode_config.poll_running doesn't actually reflect whether or not a poll is currently in progress, and is actually used for dynamic module paramter enabling/disabling. So now we instead keep track of our own poll_running variable in dev_priv->hotplug - Clean i915_hpd_poll_init_work() a little bit Changes since v3: - Remove the now-redundant connector loop in intel_hpd_init(), just rely on intel_hpd_poll_enable() for setting connector->polled correctly on each connector - Get rid of poll_running - Don't assign enabled in i915_hpd_poll_init_work before we actually lock dev->mode_config.mutex - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE() for doc purposes - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in intel_hpd_poll_enable() - Add some comments about racing not mattering in intel_hpd_poll_enable Changes since v4: - Rename intel_hpd_poll_enable() to intel_hpd_poll_init() - Drop the bool argument from intel_hpd_poll_init() - Remove redundant calls to intel_hpd_poll_init() - Rename poll_enable_work to poll_init_work - Add some kerneldoc for intel_hpd_poll_init() - Cross-reference intel_hpd_poll_init() in intel_hpd_init() - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init() Changes since v5: - Minor kerneldoc nitpicks Cc: stable@vger.kernel.org Cc: Ville Syrjälä Reviewed-by: Daniel Vetter Signed-off-by: Lyude Signed-off-by: Daniel Vetter (cherry picked from commit 19625e85c6ec56038368aa72c44f5f55b221f0fc) Signed-off-by: Greg Kroah-Hartman

drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

2016-09-07T06:34:51+00:00

commit 21842ea84f161ae37ba25f0250c377fd19c5b307 upstream. One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the ADPA - output_poll_exec does force probe on VGA, triggering a hpd - HPD handler waits for poll to unlock dev->mode_config.mutex - output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex - HPD handler runs, resets ADPA and brings us back to the start This results in an endless irq storm getting sent from the ADPA whenever a VGA connector gets detected in the middle of polling. Somewhat based off of the "drm/i915: Disable CRT HPD around force trigger" patch Ville Syrjälä sent a while back Cc: stable@vger.kernel.org Cc: Ville Syrjälä Signed-off-by: Lyude Signed-off-by: Daniel Vetter (cherry picked from commit b236d7c8421969ac0693fc571e47ee5c2a62fb90) Signed-off-by: Greg Kroah-Hartman