summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2019-07-31drm/i915: Make the semaphore saturation mask globalChris Wilson
commit 44d89409a12eb8333735958509d7d591b461d13d upstream. The idea behind keeping the saturation mask local to a context backfired spectacularly. The premise with the local mask was that we would be more proactive in attempting to use semaphores after each time the context idled, and that all new contexts would attempt to use semaphores ignoring the current state of the system. This turns out to be horribly optimistic. If the system state is still oversaturated and the existing workloads have all stopped using semaphores, the new workloads would attempt to use semaphores and be deprioritised behind real work. The new contexts would not switch off using semaphores until their initial batch of low priority work had completed. Given sufficient backload load of equal user priority, this would completely starve the new work of any GPU time. To compensate, remove the local tracking in favour of keeping it as global state on the engine -- once the system is saturated and semaphores are disabled, everyone stops attempting to use semaphores until the system is idle again. One of the reason for preferring local context tracking was that it worked with virtual engines, so for switching to global state we could either do a complete check of all the virtual siblings or simply disable semaphores for those requests. This takes the simpler approach of disabling semaphores on virtual engines. The downside is that the decision that the engine is saturated is a local measure -- we are only checking whether or not this context was scheduled in a timely fashion, it may be legitimately delayed due to user priorities. We still have the same dilemma though, that we do not want to employ the semaphore poll unless it will be used. v2: Explain why we need to assume the worst wrt virtual engines. Fixes: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated systems") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Dmitry Ermilov <dmitry.ermilov@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618074153.16055-8-chris@chris-wilson.co.uk Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-31drm/panel: Add support for Armadeus ST0700 AdaptSébastien Szymanski
commit c479450f61c7f1f248c9a54aedacd2a6ca521ff8 upstream. This patch adds support for the Armadeus ST0700 Adapt. It comes with a Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so that it can be connected on the TFT header of Armadeus Dev boards. Cc: stable@vger.kernel.org # v4.19 Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190507152713.27494-1-sebastien.szymanski@armadeus.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-31drm/msm: Depopulate platform on probe failureSean Paul
[ Upstream commit 4368a1539c6b41ac3cddc06f5a5117952998804c ] add_display_components() calls of_platform_populate, and we depopluate on pdev remove, but not when probe fails. So if we get a probe deferral in one of the components, we won't depopulate the platform. This causes the core to keep references to devices which should be destroyed, which causes issues when those same devices try to re-initialize on the next probe attempt. I think this is the reason we had issues with the gmu's device-managed resources on deferral (worked around in commit 94e3a17f33a5). Reviewed-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190617201301.133275-3-sean@poorly.run Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/msm/adreno: Ensure that the zap shader region is big enoughJordan Crouse
[ Upstream commit 6672e11cad662ce6631e04c38f92a140a99c042c ] Before loading the zap shader we should ensure that the reserved memory region is big enough to hold the loaded file. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/rockchip: Properly adjust to a true clock in adjusted_modeDouglas Anderson
[ Upstream commit 99b9683f2142b20bad78e61f7f829e8714e45685 ] When fixing up the clock in vop_crtc_mode_fixup() we're not doing it quite correctly. Specifically if we've got the true clock 266666667 Hz, we'll perform this calculation: 266666667 / 1000 => 266666 Later when we try to set the clock we'll do clk_set_rate(266666 * 1000). The common clock framework won't actually pick the proper clock in this case since it always wants clocks <= the specified one. Let's solve this by using DIV_ROUND_UP. Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-1-dianders@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/bridge: tfp410: fix use of cancel_delayed_work_syncTomi Valkeinen
[ Upstream commit b1622cb3be4557fd086831ca7426eafe5f1acc2e ] We use delayed_work in HPD handling, and cancel any scheduled work in tfp410_fini using cancel_delayed_work_sync(). However, we have only initialized the delayed work if we actually have a HPD interrupt configured in the DT, but in the tfp410_fini, we always cancel the work, possibly causing a WARN(). Fix this by doing the cancel only if we actually had the delayed work set up. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610135739.6077-2-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: fix compilation errorHariprasad Kelam
[ Upstream commit 88099f53cc3717437f5fc9cf84205c5b65118377 ] this patch fixes below compilation error drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In function ‘dcn10_apply_ctx_for_surface’: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2378:3: error: implicit declaration of function ‘udelay’ [-Werror=implicit-function-declaration] udelay(underflow_check_delay_us); Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: set link->dongle_max_pix_clk to 0 on a disconnectSamson Tam
[ Upstream commit 233d87a579b8adcc6da5823fa507ecb6675e7562 ] [Why] Found issue in EDID Emulation where if we connect a display using a passive HDMI-DP dongle, disconnect it and then try to emulate a display using DP, we could not see 4K modes. This was because on a disconnect, dongle_max_pix_clk was still set so when we emulate using DP, in dc_link_validate_mode_timing(), it would think we were still using a dongle and limit the modes we support. [How] In dc_link_detect(), set dongle_max_pix_clk to 0 when we detect a hotplug out ( if new_connection_type = dc_connection_none ). Signed-off-by: Samson Tam <Samson.Tam@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/virtio: Add memory barriers for capset cache.David Riley
[ Upstream commit 9ff3a5c88e1f1ab17a31402b96d45abe14aab9d7 ] After data is copied to the cache entry, atomic_set is used indicate that the data is the entry is valid without appropriate memory barriers. Similarly the read side was missing the corresponding memory barriers. Signed-off-by: David Riley <davidriley@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20190610211810.253227-5-davidriley@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: Update link rate from DPCD 10Wesley Chalmers
[ Upstream commit 53c81fc7875bc2dca358485dac3999e14ec91a00 ] [WHY] Some panels return a link rate of 0 (unknown) in DPCD 0. In this case, an appropriate mode cannot be set, and certain panels will show corruption as they are forced to use a mode they do not support. [HOW] Read DPCD 10 in the case where supported link rate from DPCD 0 is unknown, and pass that value on to the reported link rate. This re-introduces behaviour present in previous versions that appears to have been accidentally removed. Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: Always allocate initial connector state stateNicholas Kazlauskas
[ Upstream commit f04bee34d6e35df26cbb2d65e801adfd0d8fe20d ] [Why] Unlike our regular connectors, MST connectors don't start off with an initial connector state. This causes a NULL pointer dereference to occur when attaching the bpc property since it tries to modify the connector state. We need an initial connector state on the connector to avoid the crash. [How] Use our reset helper to allocate an initial state and reset the values to their defaults. We were already doing this before, just not for MST connectors. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/omap: don't check dispc timings for DSISebastian Reichel
[ Upstream commit ad9df7d91b4a6e8f4b20c2bf539ac09b3b2ad6eb ] While most display types only forward their VM to the DISPC, this is not true for DSI. DSI calculates the VM for DISPC based on its own, but it's not identical. Actually the DSI VM is not even a valid DISPC VM making this check fail. Let's restore the old behaviour and avoid checking the DISPC VM for DSI here. Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly") Acked-by: Pavel Machek <pavel@ucw.cz> Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/vkms: Forward timer right after drm_crtc_handle_vblankDaniel Vetter
[ Upstream commit 7355965da22b8d9ebac8bce4b776399fb0bb9d32 ] In commit def35e7c592616bc09be328de8795e5e624a3cf8 Author: Shayenne Moura <shayenneluzmoura@gmail.com> Date: Wed Jan 30 14:06:36 2019 -0200 drm/vkms: Bugfix extra vblank frame we fixed the vblank counter to give accurate results outside of drm_crtc_handle_vblank, which fixed bugs around vblank timestamps being off-by-one and causing the vblank counter to jump when it shouldn't. The trouble is that this completely broke crc generation. Shayenne and Rodrigo tracked this down to the vblank timestamp going backwards in time somehow. Which then resulted in an underflow in drm_vblank.c code, which resulted in all kinds of things breaking really badly. The reason for this is that once we've called drm_crtc_handle_vblank and the hrtimer isn't forwarded yet, we're returning a vblank timestamp in the past. This race is really hard to hit since it's small, except when you enable crc generation: In that case there's a call to drm_crtc_accurate_vblank right in-betwen, so we're guaranteed to hit the bug. The fix is to roll the hrtimer forward _before_ we do the vblank processing (which has a side-effect of incrementing the vblank counter), and we always subtract one frame from the hrtimer - since now it's always one frame in the future. To make sure we don't hit this again also add a WARN_ON checking for whether our timestamp is somehow moving into the past, which is never should. This also aligns more with how real hw works: 1. first all registers are updated with the new timestamp/vblank counter values. 2. then an interrupt is generated 3. kernel interrupt handler eventually fires. So doing this aligns vkms closer with what drm_vblank.c expects. Document this also in a comment. Cc: Shayenne Moura <shayenneluzmoura@gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606084404.12014-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/crc-debugfs: Also sprinkle irqrestore over early exitsDaniel Vetter
[ Upstream commit d99004d7201aa653658ff2390d6e516567c96ebc ] I. was. blind. Caught with vkms, which has some really slow crc computation function. Fixes: 1882018a70e0 ("drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entry") Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606211544.5389-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/crc-debugfs: User irqsafe spinlock in drm_crtc_add_crc_entryDaniel Vetter
[ Upstream commit 1882018a70e06376234133e69ede9dd743b4dbd9 ] We can be called from any context, we need to be prepared. Noticed this while hacking on vkms, which calls this function from a normal worker. Which really upsets lockdep. Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190605194556.16744-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31gpu: host1x: Increase maximum DMA segment sizeThierry Reding
[ Upstream commit 1e390478cfb527e34c9ab89ba57212cb05c33c51 ] Recent versions of the DMA API debug code have started to warn about violations of the maximum DMA segment size. This is because the segment size defaults to 64 KiB, which can easily be exceeded in large buffer allocations such as used in DRM/KMS for framebuffers. Technically the Tegra SMMU and ARM SMMU don't have a maximum segment size (they map individual pages irrespective of whether they are contiguous or not), so the choice of 4 MiB is a bit arbitrary here. The maximum segment size is a 32-bit unsigned integer, though, so we can't set it to the correct maximum size, which would be the size of the aperture. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: Increase Backlight Gain Step SizeEryk Brol
[ Upstream commit e25228b02e4833e5b0fdd262801a2ae6cc72b39d ] [Why] Some backlight tests fail due to backlight settling taking too long. This happens because the step size used to change backlight levels is too small. [How] 1. Change the size of the backlight gain step size 2. Change how DMCU firmware gets the step size value so that it is passed in by driver during DMCU initn Signed-off-by: Eryk Brol <eryk.brol@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: CS_TFM_1D only applied post EOTFKrunoslav Kovac
[ Upstream commit 6ad34adeaec5b56a5ba90e90099cabf1c1fe9dd2 ] [Why] There's some unnecessary mem allocation for CS_TFM_ID. What's worse, it depends on LUT size and since it's 4K for CS_TFM_1D, it is 16x bigger than in regular case when it's actually needed. This leads to some crashes in stress conditions. [How] Skip ramp combining designed for RGB256 and DXGI gamma with CS_TFM_1D. Signed-off-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: Reset planes for color management changesNicholas Kazlauskas
[ Upstream commit 7316c4ad299663a16ca9ce13e5e817b4ca760809 ] [Why] For commits with allow_modeset=false and CRTC degamma changes the planes aren't reset. This results in incorrect rendering. [How] Reset the planes when color management has changed on the CRTC. Technically this will include regamma changes as well, but it doesn't really after legacy userspace since those commit with allow_modeset=true. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHzJyri Sarha
[ Upstream commit 8dbfc5b65023b67397aca28e8adb25c819f6398c ] The pixel clock unit in the first two registers (0x00 and 0x01) of sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by 10 fixes the issue. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1a2a8eae0b9d6333e7a5841026bf7fd65c9ccd09.1558964241.git.jsarha@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/bridge: tc358767: read display_props in get_modes()Tomi Valkeinen
[ Upstream commit 3231573065ad4f4ecc5c9147b24f29f846dc0c2f ] We need to know the link bandwidth to filter out modes we cannot support, so we need to have read the display props before doing the filtering. To ensure we have up to date display props, call tc_get_display_props() in the beginning of tc_connector_get_modes(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528082747.3631-22-tomi.valkeinen@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/edid: Fix a missing-check bug in drm_load_edid_firmware()Gen Zhang
[ Upstream commit 9f1f1a2dab38d4ce87a13565cf4dc1b73bef3a5f ] In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr is dereferenced in the following codes. However, memory allocation functions such as kstrdup() may fail and returns NULL. Dereferencing this null pointer may cause the kernel go wrong. Thus we should check this kstrdup() operation. Further, if kstrdup() returns NULL, we should return ERR_PTR(-ENOMEM) to the caller site. Signed-off-by: Gen Zhang <blackgod016574@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190524023222.GA5302@zhanggen-UX430UQ Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amdkfd: Fix sdma queue map issueOak Zeng
[ Upstream commit 065e4bdfa1f3ab2884c110394d8b7e7ebe3b988c ] Previous codes assumes there are two sdma engines. This is not true e.g., Raven only has 1 SDMA engine. Fix the issue by using sdma engine number info in device_info. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amdkfd: Fix a potential memory leakOak Zeng
[ Upstream commit e73390d181103a19e1111ec2f25559a0570e9fe0 ] Free mqd_mem_obj it GTT buffer allocation for MQD+control stack fails. Signed-off-by: Oak Zeng <ozeng@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: Disable ABM before destroy ABM structPaul Hsieh
[ Upstream commit 1090d58d4815b1fcd95a80987391006c86398b4c ] [Why] When disable driver, OS will set backlight optimization then do stop device. But this flag will cause driver to enable ABM when driver disabled. [How] Send ABM disable command before destroy ABM construct Signed-off-by: Paul Hsieh <paul.hsieh@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amdgpu/sriov: Need to initialize the HDP_NONSURFACE_BAStETiecheng Zhou
[ Upstream commit fe2b5323d2c3cedaa3bf943dc7a0d233c853c914 ] it requires to initialize HDP_NONSURFACE_BASE, so as to avoid using the value left by a previous VM under sriov scenario. v2: it should not hurt baremetal, generalize it for both sriov and baremetal Signed-off-by: Emily Deng <Emily.Deng@amd.com> Signed-off-by: Tiecheng Zhou <Tiecheng.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amdgpu: Reserve shared fence for eviction fenceFelix Kuehling
[ Upstream commit dd68722c427d5b33420dce0ed0c44b4881e0a416 ] Need to reserve space for the shared eviction fence when initializing a KFD VM. Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: Fill plane attrs only for valid pxl formatRoman Li
[ Upstream commit 1894478ad1f8fd7366edc5cee49ee9caea0e3d52 ] [Why] In fill_plane_buffer_attributes() we calculate chroma/luma assuming that the surface_pixel_format is always valid. If it's not the case, there's a risk of divide by zero error. [How] Check if format valid before calculating pixel format attributes Signed-off-by: Roman Li <Roman.Li@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: Disable cursor when offscreen in negative directionNicholas Kazlauskas
[ Upstream commit e371e19c10a264bd72c2ff1d21e2167b994710d1 ] [Why] When x or y is negative we set the x and y values to 0 and compensate with a positive cursor hotspot in DM since DC expects positive cursor values. When x or y is less than or equal to the maximum cursor width or height the cursor hotspot is clamped so the hotspot doesn't exceed the cursor size: if (x < 0) { xorigin = min(-x, amdgpu_crtc->max_cursor_width - 1); x = 0; } if (y < 0) { yorigin = min(-y, amdgpu_crtc->max_cursor_height - 1); y = 0; } This incorrectly forces the cursor to be at least 1 pixel on the screen in either direction when x or y is sufficiently negative. [How] Just disable the cursor when it goes far enough off the screen in one of these directions. This fixes kms_cursor_crc@cursor-256x256-offscreen. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/msm/a6xx: Avoid freeing gmu resources multiple timesSean Paul
[ Upstream commit 606ec90fc2266284f584a96ebf7f874589f56251 ] The driver checks for gmu->mmio as a sign that the device has been initialized, however there are failures in probe below the mmio init. If one of those is hit, mmio will be non-null but freed. In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which will in turn call a6xx_gmu_remove which checks gmu->mmio and tries to free resources for a second time. This causes a great boom. Fix this by adding an initialized member to gmu which is set on successful probe and cleared on removal. Changes in v2: - None Cc: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190523171653.138678-1-sean@poorly.run Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: fix multi display seamless boot caseAnthony Koo
[ Upstream commit 4cd75ff096f4ef49c343093b52a952f27aba7796 ] [Why] There is a scenario that causes eDP to become blank if there are multiple displays connected, and the external display is set as the primary display such that the first flip comes to the external display. In this scenario, we call our optimize function before the eDP even has a chance to flip. [How] There is a check that prevents bandwidth optimize from occurring before first flip is complete on the seamless boot display. But actually it assumed the seamless boot display is the first one to flip. But in this scenario it is not. Modify the check to ensure the steam with the seamless boot flag set is the one that has completed the first flip. Signed-off-by: Anthony Koo <anthony.koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/amd/display: Fill prescale_params->scale for RGB565Nicholas Kazlauskas
[ Upstream commit 1352c779cb74d427f4150cbe779a2f7886f70cae ] [Why] An assertion is thrown when using SURFACE_PIXEL_FORMAT_GRPH_RGB565 formats on DCE since the prescale_params->scale wasn't being filled. Found by a dmesg-fail when running the igt@kms_plane@pixel-format-pipe-a-planes test on Baffin. [How] Fill in the scale parameter. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/msm/a6xx: Check for ERR or NULL before iounmapSean Paul
[ Upstream commit 5ca4a094ba7e1369363dcbcbde8baf06ddcdc2d1 ] pdcptr and seqptr aren't necessarily valid, check them before trying to unmap them. Changes in v2: - None Cc: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190523171653.138678-3-sean@poorly.run Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/bochs: Fix connector leak during driver unloadSam Bobroff
[ Upstream commit 3c6b8625dde82600fd03ad1fcba223f1303ee535 ] When unloading the bochs-drm driver, a warning message is printed by drm_mode_config_cleanup() because a reference is still held to one of the drm_connector structs. Correct this by calling drm_atomic_helper_shutdown() in bochs_pci_remove(). Fixes: 6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up helpers.") Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com> Link: http://patchwork.freedesktop.org/patch/msgid/93b363ad62f4938d9ddf3e05b2a61e3f66b2dcd3.1558416473.git.sbobroff@linux.ibm.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/virtio: set seqno for dma-fenceChia-I Wu
[ Upstream commit efe2bf965522bf0796d413b47a2abbf81d471d6f ] This is motivated by having meaningful ftrace events, but it also fixes use cases where dma_fence_is_later is called, such as in sync_file_merge. In other drivers, fence creation and cmdbuf submission normally happen atomically, mutex_lock(); fence = dma_fence_create(..., ++timeline->seqno); submit_cmdbuf(); mutex_unlock(); and have no such issue. But in our driver, because most ioctls queue commands into ctrlq, we do not want to grab a lock. Instead, we set seqno to 0 when a fence is created, and update it when the command is finally queued and the seqno is known. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-1-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/panel: simple: Fix panel_simple_dsi_probePeter Ujfalusi
[ Upstream commit 7ad9db66fafb0f0ad53fd2a66217105da5ddeffe ] In case mipi_dsi_attach() fails remove the registered panel to avoid added panel without corresponding device. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226081153.31334-1-peter.ujfalusi@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-31drm/lima: handle shared irq case for lima_pp_bcast_irq_handlerPeter Griffin
[ Upstream commit 409c53f07a81f8db122c461f3255c6f43558c881 ] On Hikey board all lima ip blocks are shared with one irq. This patch avoids a NULL ptr deref crash on this platform on startup. Tested with Weston and kmscube. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Cc: Rob Herring <robh@kernel.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Qiang Yu <yuq825@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/1555662781-22570-7-git-send-email-peter.griffin@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-26gpu: ipu-v3: ipu-ic: Fix saturation bit offset in TPMEMSteve Longerbeam
commit 3d1f62c686acdedf5ed9642b763f3808d6a47d1e upstream. The saturation bit was being set at bit 9 in the second 32-bit word of the TPMEM CSC. This isn't correct, the saturation bit is bit 42, which is bit 10 of the second word. Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit") Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-26drm/edid: parse CEA blocks embedded in DisplayIDAndres Rodriguez
commit e28ad544f462231d3fd081a7316339359efbb481 upstream. DisplayID blocks allow embedding of CEA blocks. The payloads are identical to traditional top level CEA extension blocks, but the header is slightly different. This change allows the CEA parser to find a CEA block inside a DisplayID block. Additionally, it adds support for parsing the embedded CTA header. No further changes are necessary due to payload parity. This change fixes audio support for the Valve Index HMD. Signed-off-by: Andres Rodriguez <andresx7@gmail.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.15 Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619180901.17901-1-andresx7@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-26drm/nouveau/i2c: Enable i2c pads & busses during preinitLyude Paul
commit 7cb95eeea6706c790571042a06782e378b2561ea upstream. It turns out that while disabling i2c bus access from software when the GPU is suspended was a step in the right direction with: commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()") We also ended up accidentally breaking the vbios init scripts on some older Tesla GPUs, as apparently said scripts can actually use the i2c bus. Since these scripts are executed before initializing any subdevices, we end up failing to acquire access to the i2c bus which has left a number of cards with their fan controllers uninitialized. Luckily this doesn't break hardware - it just means the fan gets stuck at 100%. This also means that we've always been using our i2c busses before initializing them during the init scripts for older GPUs, we just didn't notice it until we started preventing them from being used until init. It's pretty impressive this never caused us any issues before! So, fix this by initializing our i2c pad and busses during subdev pre-init. We skip initializing aux busses during pre-init, as those are guaranteed to only ever be used by nouveau for DP aux transactions. Signed-off-by: Lyude Paul <lyude@redhat.com> Tested-by: Marc Meledandri <m.meledandri@gmail.com> Fixes: 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()") Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-05Merge tag 'imx-drm-fixes-2019-07-04' of ↵Dave Airlie
git://git.pengutronix.de/git/pza/linux into drm-fixes drm/imx: fix stale vblank timestamp after a modeset This series fixes stale vblank timestamps in the first event sent after a crtc was disabled. The core now is notified via drm_crtc_vblank_off before sending the last pending event in atomic_disable. If the crtc is reenabled right away during to a modeset, the event is not sent at all, as the next vblank will take care of it. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/1562237119.6641.16.camel@pengutronix.de
2019-07-04drm/imx: only send event on crtc disable if kept disabledRobert Beckett
The event will be sent as part of the vblank enable during the modeset if the crtc is not being kept disabled. Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 step 1: Use atomic configuration") Signed-off-by: Robert Beckett <bob.beckett@collabora.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-07-04drm/imx: notify drm core before sending event during crtc disableRobert Beckett
Notify drm core before sending pending events during crtc disable. This fixes the first event after disable having an old stale timestamp by having drm_crtc_vblank_off update the timestamp to now. This was seen while debugging weston log message: Warning: computed repaint delay is insane: -8212 msec This occurred due to: 1. driver starts up 2. fbcon comes along and restores fbdev, enabling vblank 3. vblank_disable_fn fires via timer disabling vblank, keeping vblank seq number and time set at current value (some time later) 4. weston starts and does a modeset 5. atomic commit disables crtc while it does the modeset 6. ipu_crtc_atomic_disable sends vblank with old seq number and time Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression") Signed-off-by: Robert Beckett <bob.beckett@collabora.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-07-04Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux ↵Dave Airlie
into drm-fixes Fix a kernel nullptr deref on module unload when any etnaviv GPU failed to initialize properly. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/1561974148.2321.1.camel@pengutronix.de
2019-07-04Merge tag 'drm-misc-fixes-2019-07-03' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes panfrost- Avoid double free by deleting GEM handle in create_bo failure path (Boris) Cc: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190704001302.GA260390@art_vandelay
2019-07-04Merge tag 'drm-fixes-5.2-2019-07-02' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-fixes drm-fixes-5.2-2019-07-02: Fixes for stable amdgpu: - stability fix for gfx9 - regression fix for HG on some polaris boards - crash fix for some new OEM boards Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703015705.3162-1-alexander.deucher@amd.com
2019-07-02drm/i915/ringbuffer: EMIT_INVALIDATE *before* switch contextChris Wilson
Despite what I think the prm recommends, commit f2253bd9859b ("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out to be a huge mistake when enabling Ironlake contexts as the GPU would hang on either a MI_FLUSH or PIPE_CONTROL immediately following the MI_SET_CONTEXT of an active mesa context (more vanilla contexts, e.g. simple rendercopies with igt, do not suffer). Ville found the following clue, "[DevCTG+]: For the invalidate operation of the pipe control, the following pointers are affected. The invalidate operation affects the restore of these packets. If the pipe control invalidate operation is completed before the context save, the indirect pointers will not be restored from memory. 1. Pipeline State Pointer 2. Media State Pointer 3. Constant Buffer Packet" which suggests by us emitting the INVALIDATE prior to the MI_SET_CONTEXT, we prevent the context-restore from chasing the dangling pointers within the image, and explains why this likely prevents the GPU hang. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190419111749.3910-1-chris@chris-wilson.co.uk (cherry picked from commit 928f8f42310f244501a7c70daac82c196112c190 in drm-intel-next) Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111014 Fixes: f2253bd9859b ("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-07-01drm/amdgpu/gfx9: use reset default for PA_SC_FIFO_SIZEAlex Deucher
Recommended by the hw team. Reviewed-and-Tested-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-07-01drm/amdgpu: Don't skip display settings in hwmgr_resume()Lyude Paul
I'm not entirely sure why this is, but for some reason: 921935dc6404 ("drm/amd/powerplay: enforce display related settings only on needed") Breaks runtime PM resume on the Radeon PRO WX 3100 (Lexa) in one the pre-production laptops I have. The issue manifests as the following messages in dmesg: [drm] UVD and UVD ENC initialized successfully. amdgpu 0000:3b:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring vce1 test failed (-110) [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <vce_v3_0> failed -110 [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-110). And happens after about 6-10 runtime PM suspend/resume cycles (sometimes sooner, if you're lucky!). Unfortunately I can't seem to pin down precisely which part in psm_adjust_power_state_dynamic that is causing the issue, but not skipping the display setting setup seems to fix it. Hopefully if there is a better fix for this, this patch will spark discussion around it. Fixes: 921935dc6404 ("drm/amd/powerplay: enforce display related settings only on needed") Cc: Evan Quan <evan.quan@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: Rex Zhu <Rex.Zhu@amd.com> Cc: Likun Gao <Likun.Gao@amd.com> Cc: <stable@vger.kernel.org> # v5.1+ Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-01drm/amd/powerplay: use hardware fan control if no powerplay fan tableEvan Quan
Otherwise, you may get divided-by-zero error or corrput the SMU fan control feature. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Slava Abramov <slava.abramov@amd.com> Acked-by: Slava Abramov <slava.abramov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-27 02:35:19 +0000