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

drm/atmel-hlcdc: revert shift by 8

2019-12-05T08:21:33+00:00

commit cbb32079149dbf557fa3f7bab8fa3c5fec857da7 upstream. Revert shift by 8 of state->base.alpha. This introduced a regression on planes. Fixes: 7f73c10b256b ("drm/atmel-hclcdc: Convert to the new generic alpha property") Cc: Maxime Ripard Signed-off-by: Claudiu Beznea Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1556195748-11106-7-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

gpu: ipu-v3: pre: don't trigger update if buffer address doesn't change

2019-12-05T08:21:07+00:00

[ Upstream commit eb0200a4357da100064971689d3a0e9e3cf57f33 ] On a NOP double buffer update where current buffer address is the same as the next buffer address, the SDW_UPDATE bit clears too late. As we are now using this bit to determine when it is safe to signal flip completion to userspace this will delay completion of atomic commits where one plane doesn't change the buffer by a whole frame period. Fix this by remembering the last buffer address and just skip the double buffer update if it would not change the buffer address. Signed-off-by: Lucas Stach [p.zabel@pengutronix.de: initialize last_bufaddr in ipu_pre_configure] Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin

drm/i915/userptr: Try to acquire the page lock around set_page_dirty()

2019-12-01T08:16:12+00:00

commit 2d691aeca4aecbb8d0414a777a46981a8e142b05 upstream. set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules, it is only safe for us to use the plain set_page_dirty calls for shmemfs/anonymous memory. Userptr may be used with real mappings and so needs to use the locked version (set_page_dirty_lock). However, following a try_to_unmap() we may want to remove the userptr and so call put_pages(). However, try_to_unmap() acquires the page lock and so we must avoid recursively locking the pages ourselves -- which means that we cannot safely acquire the lock around set_page_dirty(). Since we can't be sure of the lock, we have to risk skip dirtying the page, or else risk calling set_page_dirty() without a lock and so risk fs corruption. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012 Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") References: cb6d7c7dc7ff ("drm/i915/userptr: Acquire the page lock around set_page_dirty()") References: 505a8ec7e11a ("Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"") References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers") Signed-off-by: Chris Wilson Cc: Lionel Landwerlin Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-1-chris@chris-wilson.co.uk (cherry picked from commit 0d4bbe3d407f79438dc4f87943db21f7134cfc65) Signed-off-by: Joonas Lahtinen (cherry picked from commit cee7fb437edcdb2f9f8affa959e274997f5dca4d) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman

drm/i915/pmu: "Frequency" is reported as accumulated cycles

2019-12-01T08:16:11+00:00

commit add3eeed3683e2636ef524db48e1a678757c8e96 upstream. We report "frequencies" (actual-frequency, requested-frequency) as the number of accumulated cycles so that the average frequency over that period may be determined by the user. This means the units we report to the user are Mcycles (or just M), not MHz. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20191109105356.5273-1-chris@chris-wilson.co.uk (cherry picked from commit e88866ef02851c88fe95a4bb97820b94b4d46f36) Signed-off-by: Joonas Lahtinen (cherry picked from commit a7d87b70d6da96c6772e50728c8b4e78e4cbfd55) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman

drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs

2019-12-01T08:16:11+00:00

commit 355d991cb6ff6ae76b5e28b8edae144124c730e4 upstream. Otherwise, the error message prompted will confuse user. Signed-off-by: Evan Quan Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

msm/gpu/a6xx: Force of_dma_configure to setup DMA for GMU

2019-11-24T07:20:06+00:00

[ Upstream commit 32aa27e15c28d3898ed6f9b3c98f95f34a81eab2 ] The point of the 'force_dma' parameter for of_dma_configure is to force the device to be set up even if DMA capability is not described by the firmware which is exactly the use case we have for GMU - we need SMMU to get set up but we have no other dma capabilities since memory is managed by the GPU driver. Currently we pass false so of_dma_configure() fails and subsequently GMU and GPU probe does as well. Fixes: 4b565ca5a2c ("drm/msm: Add A6XX device support") Signed-off-by: Jordan Crouse Tested-by: Sibi Sankar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

qxl: fix null-pointer crash during suspend

2019-11-20T17:45:56+00:00

[ Upstream commit 7948a2b15873319d1bff4d37c09b9f2bf87b9021 ] "crtc->helper_private" is not initialized by the QXL driver and thus the "crtc_funcs->disable" call would crash (resulting in suspend failure). Fix this by converting the suspend/resume functions to use the drm_mode_config_helper_* helpers. Tested system sleep with QEMU 3.0 using "echo mem > /sys/power/state". During suspend the following message is visible from QEMU: spice/server/display-channel.c:2425:display_channel_validate_surface: canvas address is 0x7fd05da68308 for 0 (and is NULL) spice/server/display-channel.c:2426:display_channel_validate_surface: failed on 0 This seems to be triggered by QXL_IO_NOTIFY_CMD after QXL_IO_DESTROY_PRIMARY_ASYNC, but aside from the warning things still seem to work (tested with both the GTK and -spice options). Signed-off-by: Peter Wu Link: http://patchwork.freedesktop.org/patch/msgid/20180904202747.14968-1-peter@lekensteyn.nl Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin

drm/i915/cmdparser: Fix jump whitelist clearing

2019-11-12T18:21:29+00:00

commit ea0b163b13ffc52818c079adb00d55e227a6da6f upstream. When a jump_whitelist bitmap is reused, it needs to be cleared. Currently this is done with memset() and the size calculation assumes bitmaps are made of 32-bit words, not longs. So on 64-bit architectures, only the first half of the bitmap is cleared. If some whitelist bits are carried over between successive batches submitted on the same context, this will presumably allow embedding the rogue instructions that we're trying to reject. Use bitmap_zero() instead, which gets the calculation right. Fixes: f8c08d8faee5 ("drm/i915/cmdparser: Add support for backward jumps") Signed-off-by: Ben Hutchings Signed-off-by: Jon Bloomfield Signed-off-by: Greg Kroah-Hartman

drm/i915/gen8+: Add RC6 CTX corruption WA

2019-11-12T18:21:28+00:00

commit 7e34f4e4aad3fd34c02b294a3cf2321adf5b4438 upstream. In some circumstances the RC6 context can get corrupted. We can detect this and take the required action, that is disable RC6 and runtime PM. The HW recovers from the corrupted state after a system suspend/resume cycle, so detect the recovery and re-enable RC6 and runtime PM. v2: rebase (Mika) v3: - Move intel_suspend_gt_powersave() to the end of the GEM suspend sequence. - Add commit message. v4: - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API change. v5: rebased on gem/gt split (Mika) Signed-off-by: Imre Deak Signed-off-by: Mika Kuoppala Signed-off-by: Greg Kroah-Hartman

drm/i915: Lower RM timeout to avoid DSI hard hangs

2019-11-12T18:21:27+00:00

commit 1d85a299c4db57c55e0229615132c964d17aa765 upstream. In BXT/APL, device 2 MMIO reads from MIPI controller requires its PLL to be turned ON. When MIPI PLL is turned off (MIPI Display is not active or connected), and someone (host or GT engine) tries to read MIPI registers, it causes hard hang. This is a hardware restriction or limitation. Driver by itself doesn't read MIPI registers when MIPI display is off. But any userspace application can submit unprivileged batch buffer for execution. In that batch buffer there can be mmio reads. And these reads are allowed even for unprivileged applications. If these register reads are for MIPI DSI controller and MIPI display is not active during that time, then the MMIO read operation causes system hard hang and only way to recover is hard reboot. A genuine process/application won't submit batch buffer like this and doesn't cause any issue. But on a compromised system, a malign userspace process/app can generate such batch buffer and can trigger system hard hang (denial of service attack). The fix is to lower the internal MMIO timeout value to an optimum value of 950us as recommended by hardware team. If the timeout is beyond 1ms (which will hit for any value we choose if MMIO READ on a DSI specific register is performed without PLL ON), it causes the system hang. But if the timeout value is lower than it will be below the threshold (even if timeout happens) and system will not get into a hung state. This will avoid a system hang without losing any programming or GT interrupts, taking the worst case of lowest CDCLK frequency and early DC5 abort into account. Signed-off-by: Uma Shankar Reviewed-by: Jon Bloomfield Signed-off-by: Greg Kroah-Hartman