kernel/linux.git/drivers/gpu, branch v5.3.6

drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed

2019-10-11T16:36:50+00:00

[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ] Bail from the pci_driver probe function instead of from the drm_driver load function. This avoid /dev/dri/card0 temporarily getting registered and then unregistered again, sending unwanted add / remove udev events to userspace. Specifically this avoids triggering the (userspace) bug fixed by this plymouth merge-request: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 Note that despite that being an userspace bug, not sending unnecessary udev events is a good idea in general. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 Reviewed-by: Michel Dänzer Signed-off-by: Hans de Goede Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amdgpu: Check for valid number of registers to read

2019-10-11T16:36:35+00:00

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ] Do not try to allocate any amount of memory requested by the user. Instead limit it to 128 registers. Actually the longest series of consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and mmGB_MACROTILE_MODE0-15 (0x2644-0x2673). Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273 Signed-off-by: Trek Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amdgpu: Fix KFD-related kernel oops on Hawaii

2019-10-11T16:36:35+00:00

[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ] Hawaii needs to flush caches explicitly, submitting an IB in a user VMID from kernel mode. There is no s_fence in this case. Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job") Signed-off-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/i915: to make vgpu ppgtt notificaiton as atomic operation

2019-10-11T16:36:16+00:00

commit 9e77f5001b9833a6bdd3940df245053c2212a32b upstream. vgpu ppgtt notification was split into 2 steps, the first step is to update PVINFO's pdp register and then write PVINFO's g2v_notify register with action code to tirgger ppgtt notification to GVT side. currently these steps were not atomic operations due to no any protection, so it is easy to enter race condition state during the MTBF, stress and IGT test to cause GPU hang. the solution is to add a lock to make vgpu ppgtt notication as atomic operation. Cc: stable@vger.kernel.org Signed-off-by: Xiaolin Zhang Acked-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/1566543451-13955-1-git-send-email-xiaolin.zhang@intel.com (cherry picked from commit 52988009843160c5b366b4082ed6df48041c655c) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman

drm/i915/gvt: update vgpu workload head pointer correctly

2019-10-11T16:36:15+00:00

commit 0a3242bdb47713e09cb004a0ba4947d3edf82d8a upstream. when creating a vGPU workload, the guest context head pointer should be updated correctly by comparing with the exsiting workload in the guest worklod queue including the current running context. in some situation, there is a running context A and then received 2 new vGPU workload context B and A. in the new workload context A, it's head pointer should be updated with the running context A's tail. v2: walk through guest workload list in backward way. Cc: stable@vger.kernel.org Signed-off-by: Xiaolin Zhang Reviewed-by: Zhenyu Wang Signed-off-by: Zhenyu Wang Signed-off-by: Greg Kroah-Hartman

drm/amd/powerplay: change metrics update period from 1ms to 100ms

2019-10-11T16:36:15+00:00

commit e0e4a2ce7a059d051c66cd7c94314fef3cd91aea upstream. v2: change period from 10ms to 100ms (typo error) too high frequence to update mertrics table will cause smu firmware error,so change mertrics table update period from 1ms to 100ms (navi10, 12, 14) Signed-off-by: Kevin Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 5.3.x Signed-off-by: Greg Kroah-Hartman

drm/nouveau/kms/nv50-: Don't create MSTMs for eDP connectors

2019-10-11T16:36:14+00:00

commit 698c1aa9f83b618de79e9e5e19a58f70a4a6ae0f upstream. On the ThinkPad P71, we have one eDP connector exposed along with 5 DP connectors, resulting in a total of 11 TMDS encoders. Since the GPU on this system is also capable of MST, we create an additional 4 fake MST encoders for each DP port. Unfortunately, we also do this for the eDP port as well, resulting in: 1 eDP port: +1 TMDS encoder +4 DPMST encoders 5 DP ports: +2 TMDS encoders +4 DPMST encoders *5 ports == 35 encoders Which breaks things, since DRM has a hard coded limit of 32 encoders. So, fix this by not creating MSTMs for any eDP connectors. This brings us down to 31 encoders, although we can do better. This fixes driver probing for nouveau on the ThinkPad P71. Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman

drm/msm/dsi: Fix return value check for clk_get_parent

2019-10-11T16:36:14+00:00

commit 5fb9b797d5ccf311ae4aba69e86080d47668b5f7 upstream. clk_get_parent returns an error pointer upon failure, not NULL. So the checks as they exist won't catch a failure. This patch changes the checks and the return values to properly handle an error pointer. Fixes: c4d8cfe516dc ("drm/msm/dsi: add implementation for helper functions") Cc: Sibi Sankar Cc: Sean Paul Cc: Rob Clark Cc: # v4.19+ Signed-off-by: Sean Paul Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman

drm/omap: fix max fclk divider for omap36xx

2019-10-11T16:36:13+00:00

commit e2c4ed148cf3ec8669a1d90dc66966028e5fad70 upstream. The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk (in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not correct, and using divider of 32 breaks DSS with a flood or underflows and sync losts. Dividers up to 31 seem to work fine. There is another patch to the DT files to limit the divider correctly, but as the DSS driver also needs to know the maximum divider to be able to iteratively find good rates, we also need to do the fix in the DSS driver. Signed-off-by: Tomi Valkeinen Cc: Adam Ford Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20191002122542.8449-1-tomi.valkeinen@ti.com Tested-by: Adam Ford Reviewed-by: Jyri Sarha Signed-off-by: Greg Kroah-Hartman

drm: mali-dp: Mark expected switch fall-through

2019-10-11T16:36:13+00:00

commit 28ba1b1da49a20ba8fb767d6ddd7c521ec79a119 upstream. Now that -Wimplicit-fallthrough is passed to GCC by default, the following warnings shows up: ../drivers/gpu/drm/arm/malidp_hw.c: In function ‘malidp_format_get_bpp’: ../drivers/gpu/drm/arm/malidp_hw.c:387:8: warning: this statement may fall through [-Wimplicit-fallthrough=] bpp = 30; ~~~~^~~~ ../drivers/gpu/drm/arm/malidp_hw.c:388:3: note: here case DRM_FORMAT_YUV420_10BIT: ^~~~ ../drivers/gpu/drm/arm/malidp_hw.c: In function ‘malidp_se_irq’: ../drivers/gpu/drm/arm/malidp_hw.c:1311:4: warning: this statement may fall through [-Wimplicit-fallthrough=] drm_writeback_signal_completion(&malidp->mw_connector, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/arm/malidp_hw.c:1313:3: note: here case MW_START: ^~~~ Rework to add a 'break;' in a case that didn't have it so that the compiler doesn't warn about fall-through. Cc: stable@vger.kernel.org # v5.2+ Fixes: b8207562abdd ("drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats") Acked-by: Liviu Dudau Signed-off-by: Anders Roxell Signed-off-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20190730153056.3606-1-anders.roxell@linaro.org Signed-off-by: Greg Kroah-Hartman