summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-09-23drm/mediatek: Use CPU when fail to get cmdq eventChun-Kuang Hu1-7/+13
[ Upstream commit f85acdad07fe36b91f2244263a890bf372528326 ] Even though cmdq client is created successfully, without the cmdq event, cmdq could not work correctly, so use CPU when fail to get cmdq event. Fixes: 60fa8c13ab1a ("drm/mediatek: Move gce event property to mutex device node") Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-23drm/i915/gem: Reduce context termination list iteration guard to RCUChris Wilson1-13/+19
[ Upstream commit c2314b8bd4c009793b6f9d57bc8363af034e02ca ] As we now protect the timeline list using RCU, we can drop the timeline->mutex for guarding the list iteration during context close, as we are searching for an inflight request. Any new request will see the context is banned and not be submitted. In doing so, pull the checks for a concurrent submission of the request (notably the i915_request_completed()) under the engine spinlock, to fully serialise with __i915_request_submit()). That is in the case of preempt-to-busy where the request may be completed during the __i915_request_submit(), we need to be careful that we sample the request status after serialising so that we don't miss the request the engine is actually submitting. Fixes: 4a3174152147 ("drm/i915/gem: Refine occupancy test in kill_context()") References: d22d2d073ef8 ("drm/i915: Protect i915_request_await_start from early waits") # rcu protection of timeline->requests References: https://gitlab.freedesktop.org/drm/intel/-/issues/1622 References: https://gitlab.freedesktop.org/drm/intel/-/issues/2158 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200806105954.7766-1-chris@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 736e785f9b28cd9ef2d16a80960a04fd00e64b22) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-23drm/mediatek: dsi: Fix scrolling of panel with small hfp or hbpJitao Shi1-5/+4
[ Upstream commit 35bf948f1edbf507f6e57e0879fa6ea36d2d2930 ] horizontal_backporch_byte should be hbp * bpp - hbp extra bytes. So remove the wrong subtraction 10. Fixes: 7a5bc4e22ecf ("drm/mediatek: change the dsi phytiming calculate method") Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17drm/msm/gpu: make ringbuffer readonlyRob Clark1-1/+2
[ Upstream commit 352c83fb39cae3eff95a8e1ed23006291abb6196 ] The GPU has no business writing into the ringbuffer, let's make it readonly to the GPU. Fixes: 7198e6b03155 ("drm/msm: add a3xx gpu support") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17drm/msm: Disable the RPTR shadowJordan Crouse6-27/+43
commit f6828e0c4045f03f9cf2df6c2a768102641183f4 upstream. Disable the RPTR shadow across all targets. It will be selectively re-enabled later for targets that need it. Cc: stable@vger.kernel.org Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-17drm/msm: Disable preemption on all 5xx targetsJordan Crouse1-1/+2
commit 7b3f3948c8b7053d771acc9f79810cc410f5e2e0 upstream. Temporarily disable preemption on a5xx targets pending some improvements to protect the RPTR shadow from being corrupted. Cc: stable@vger.kernel.org Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-17drm/msm: Split the a5xx preemption recordJordan Crouse2-5/+21
commit 34221545d2069dc947131f42392fd4cebabe1b39 upstream. The main a5xx preemption record can be marked as privileged to protect it from user access but the counters storage needs to be remain unprivileged. Split the buffers and mark the critical memory as privileged. Cc: stable@vger.kernel.org Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-17drm/tve200: Stabilize enable/disableLinus Walleij1-1/+21
commit f71800228dc74711c3df43854ce7089562a3bc2d upstream. The TVE200 will occasionally print a bunch of lost interrupts and similar dmesg messages, sometimes during boot and sometimes after disabling and coming back to enablement. This is probably because the hardware is left in an unknown state by the boot loader that displays a logo. This can be fixed by bringing the controller into a known state by resetting the controller while enabling it. We retry reset 5 times like the vendor driver does. We also put the controller into reset before de-clocking it and clear all interrupts before enabling the vblank IRQ. This makes the video enable/disable/enable cycle rock solid on the D-Link DIR-685. Tested extensively. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200820203144.271081-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-17drm/amdgpu: Fix bug in reporting voltage for CIKSandeep Raghuraman1-1/+2
[ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17drm/sun4i: backend: Disable alpha on the lowest plane on the A20Maxime Ripard1-1/+0
[ Upstream commit 5e2e2600a3744491a8b49b92597c13b693692082 ] Unlike we previously thought, the per-pixel alpha is just as broken on the A20 as it is on the A10. Remove the quirk that says we can use it. Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane alpha support") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200728134810.883457-2-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17drm/sun4i: backend: Support alpha property on lowest planeMaxime Ripard1-2/+1
[ Upstream commit e359c70462d2a82aae80274d027351d38792dde6 ] Unlike what we previously thought, only the per-pixel alpha is broken on the lowest plane and the per-plane alpha isn't. Remove the check on the alpha property being set on the lowest plane to reject a mode. Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane alpha support") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200728134810.883457-1-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17drm/sun4i: Fix DE2 YVU handlingJernej Skrabec1-1/+1
[ Upstream commit 0ee9f600e69d901d31469359287b90bbe8e54553 ] Function sun8i_vi_layer_get_csc_mode() is supposed to return CSC mode but due to inproper return type (bool instead of u32) it returns just 0 or 1. Colors are wrong for YVU formats because of that. Fixes: daab3d0e8e2b ("drm/sun4i: de2: csc_mode in de2 format struct is mostly redundant") Reported-by: Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Tested-by: Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200901220305.6809-1-jernej.skrabec@siol.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17drm/virtio: fix unblankGerd Hoffmann3-1/+15
[ Upstream commit c6016c6e39c3ee8fd671532520be3cc13e439db2 ] When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. v2: use drm_atomic_crtc_needs_modeset() (Daniel). Cc: 1882851@bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Diego Viola <diego.viola@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200818072511.6745-2-kraxel@redhat.com (cherry picked from commit 1bc371cd0ec907bab870cacb6e898105f9c41dc8) Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17drm/sun4i: Fix dsi dcs long write functionOndrej Jirman1-2/+2
[ Upstream commit fd90e3808fd2c207560270c39b86b71af2231aa1 ] It's writing too much data. regmap_bulk_write expects number of register sized chunks to write, not a byte sized length of the bounce buffer. Bounce buffer needs to be padded too, so that regmap_bulk_write will not read past the end of the buffer. Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support") Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200828125032.937148-1-megous@megous.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-17drm/sun4i: add missing put_device() call in sun8i_r40_tcon_tv_set_mux()Yu Kuai1-2/+6
[ Upstream commit 07b5b12d97dc9f47ff3dff46c4f944a15bd762e5 ] If sun8i_r40_tcon_tv_set_mux() succeed, sun8i_r40_tcon_tv_set_mux() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON") Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200826010826.1785487-1-yukuai3@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/amdgpu: Specify get_argument function for ci_smu_funcsSandeep Raghuraman1-0/+2
commit f7b2e34b4afb8d712913dc199d3292ea9e078637 upstream. Starting in Linux 5.8, the graphics and memory clock frequency were not being reported for CIK cards. This is a regression, since they were reported correctly in Linux 5.7. After investigation, I discovered that the smum_send_msg_to_smc() function, attempts to call the corresponding get_argument() function of ci_smu_funcs. However, the get_argument() function is not defined in ci_smu_funcs. This patch fixes the bug by specifying the correct get_argument() function. Fixes: a0ec225633d9f6 ("drm/amd/powerplay: unified interfaces for message issuing and response checking") Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-09drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp settingEvan Quan1-2/+12
commit 971df65cbf32da9bc9af52c1196ca504dd316086 upstream. Normally softwareshutdowntemp should be greater than Thotspotlimit. However, on some VEGA10 ASIC, the softwareshutdowntemp is 91C while Thotspotlimit is 105C. This seems not right and may trigger some false alarms. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-09drm/i915: Fix sha_text population codeSean Paul1-6/+20
commit 9ab57658a608f879469ffa22b723c4539c05a58f upstream. This patch fixes a few bugs: 1- We weren't taking into account sha_leftovers when adding multiple ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with the beginning of ksv[j] 2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was being placed on the wrong half of sha_text, overlapping the leftover ksv value 3- In the sha_leftovers == 2 case, we need to manually terminate the byte stream with 0x80 since the hardware doesn't have enough room to add it after writing M0 The upside is that all of the HDCP supported HDMI repeaters I could find on Amazon just strip HDCP anyways, so it turns out to be _really_ hard to hit any of these cases without an MST hub, which is not (yet) supported. Oh, and the sha_leftovers == 1 case works perfectly! Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.17+ Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-2-sean@poorly.run (cherry picked from commit 1f0882214fd0037b74f245d9be75c31516fed040) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-09drm/amd/display: Fix memleak in amdgpu_dm_mode_config_initDinghao Liu1-2/+8
[ Upstream commit b67a468a4ccef593cd8df6a02ba3d167b77f0c81 ] When amdgpu_display_modeset_create_props() fails, state and state->context should be freed to prevent memleak. It's the same when amdgpu_dm_audio_init() fails. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/amd/display: Retry AUX write when fail occursWayne Lin1-1/+1
[ Upstream commit ef67d792a2fc578319399f605fbec2f99ecc06ea ] [Why] In dm_dp_aux_transfer() now, we forget to handle AUX_WR fail cases. We suppose every write wil get done successfully and hence some AUX commands might not sent out indeed. [How] Check if AUX_WR success. If not, retry it. Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/amd/display: Keep current gain when ABM disable immediatelyBrandon Syu1-1/+1
[ Upstream commit cba4b52e431e5de3d8012281cfe194f1c39a9052 ] [Why] When system enters s3/s0i3, backlight PWM would set user level. [How] ABM disable function add keep current gain to avoid it. Signed-off-by: Brandon Syu <Brandon.Syu@amd.com> Reviewed-by: Josip Pavic <Josip.Pavic@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/amd/display: Fix passive dongle mistaken as active dongle in EDID emulationSamson Tam1-0/+1
[ Upstream commit efbde23a3b0164cef27fd394e7d548f46af5b51d ] [Why] dongle_type is set during dongle connection but for passive dongles, dongle_type is not set. If user starts with an active dongle and then switches to a passive dongle, it will still report as an active dongle. Trying to emulate the wrong connecter type results in display not lighting up. [How] Set dpcd_caps.dongle_type for passive dongles in detect_dp(). Signed-off-by: Samson Tam <Samson.Tam@amd.com> Reviewed-by: Joshua Aberback <Joshua.Aberback@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/amd/display: Revert HDCP disable sequence changeJaehyun Chung1-1/+1
[ Upstream commit b61f05622ace5b9498ae279cdfd1c9f0c1ce3f75 ] [Why] Revert HDCP disable sequence change that blanks stream before disabling HDCP. PSP and HW teams are currently investigating the root cause of why HDCP cannot be disabled before stream blank, which is expected to work without issues. Signed-off-by: Jaehyun Chung <jaehyun.chung@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in ↵Furquan Shaikh1-0/+2
amdgpu_dm_update_backlight_caps [ Upstream commit 5896585512e5156482335e902f7c7393b940da51 ] In `amdgpu_dm_update_backlight_caps()`, there is a local `amdgpu_dm_backlight_caps` object that is filled in by `amdgpu_acpi_get_backlight_caps()`. However, this object is uninitialized before the call and hence the subsequent check for aux_support can fail since it is not initialized by `amdgpu_acpi_get_backlight_caps()` as well. This change initializes this local `amdgpu_dm_backlight_caps` object to 0. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Furquan Shaikh <furquan@google.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/amd/display: Reject overlay plane configurations in multi-display scenariosNicholas Kazlauskas1-0/+8
[ Upstream commit 168f09cdadbd547c2b202246ef9a8183da725f13 ] [Why] These aren't stable on some platform configurations when driving multiple displays, especially on higher resolution. In particular the delay in asserting p-state and validating from x86 outweights any power or performance benefit from the hardware composition. Under some configurations this will manifest itself as extreme stutter or unresponsiveness especially when combined with cursor movement. [How] Disable these for now. Exposing overlays to userspace doesn't guarantee that they'll be able to use them in any and all configurations and it's part of the DRM contract to have userspace gracefully handle validation failures when they occur. Valdiation occurs as part of DC and this in particular affects RV, so disable this in dcn10_global_validation. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/amd/display: should check error using DC_OKTong Zhang1-4/+4
[ Upstream commit ed9ab229fea24cbcab17f484297dc8344afb7ea9 ] core_link_read_dpcd returns only DC_OK(1) and DC_ERROR_UNEXPECTED(-1), the caller should check error using DC_OK instead of checking against 0 Signed-off-by: Tong Zhang <ztong0001@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/omap: fix incorrect lock stateTomi Valkeinen1-1/+2
[ Upstream commit 7fd5b25499bcec157dd4de9a713425efcf4571cd ] After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken: WARNING: inconsistent lock state 5.8.0-rc2-00483-g92cc68e35863 #13 Tainted: G W -------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: ea98222c (&dev->event_lock#2){?.+.}-{2:2}, at: drm_handle_vblank+0x4c/0x520 [drm] {HARDIRQ-ON-W} state was registered at: trace_hardirqs_on+0x9c/0x1ec _raw_spin_unlock_irq+0x20/0x58 omap_crtc_atomic_enable+0x54/0xa0 [omapdrm] drm_atomic_helper_commit_modeset_enables+0x218/0x270 [drm_kms_helper] omap_atomic_commit_tail+0x48/0xc4 [omapdrm] commit_tail+0x9c/0x190 [drm_kms_helper] drm_atomic_helper_commit+0x154/0x188 [drm_kms_helper] drm_client_modeset_commit_atomic+0x228/0x268 [drm] drm_client_modeset_commit_locked+0x60/0x1d0 [drm] drm_client_modeset_commit+0x24/0x40 [drm] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa8 [drm_kms_helper] drm_fb_helper_set_par+0x2c/0x5c [drm_kms_helper] drm_fb_helper_hotplug_event.part.0+0xa0/0xbc [drm_kms_helper] drm_kms_helper_hotplug_event+0x24/0x30 [drm_kms_helper] output_poll_execute+0x1a8/0x1c0 [drm_kms_helper] process_one_work+0x268/0x800 worker_thread+0x30/0x4e0 kthread+0x164/0x190 ret_from_fork+0x14/0x20 The reason for this is that omapdrm calls drm_crtc_vblank_on() while holding event_lock taken with spin_lock_irq(). It is not clear why drm_crtc_vblank_on() and drm_crtc_vblank_get() are called while holding event_lock. I don't see any problem with moving those calls outside the lock, which is what this patch does. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200819103021.440288-1-tomi.valkeinen@ti.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/msm/a6xx: fix gmu start on newer firmwareDmitry Baryshkov1-1/+11
[ Upstream commit f5749d6181fa7df5ae741788e5d96f593d3a60b6 ] New Qualcomm firmware has changed a way it reports back the 'started' event. Support new register values. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/msm: enable vblank during atomic commitsRob Clark1-0/+36
[ Upstream commit 43906812eaab06423f56af5cca9a9fcdbb4ac454 ] This has roughly the same effect as drm_atomic_helper_wait_for_vblanks(), basically just ensuring that vblank accounting is enabled so that we get valid timestamp/seqn on pageflip events. Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/msm: add shutdown support for display platform_driverKrishna Manikandan1-0/+8
[ Upstream commit 9d5cbf5fe46e350715389d89d0c350d83289a102 ] Define shutdown callback for display drm driver, so as to disable all the CRTCS when shutdown notification is received by the driver. This change will turn off the timing engine so that no display transactions are requested while mmu translations are getting disabled during reboot sequence. Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org> Changes in v2: - Remove NULL check from msm_pdev_shutdown (Stephen Boyd) - Change commit text to reflect when this issue was uncovered (Sai Prakash Ranjan) Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/msm/dpu: fix unitialized variable errorRob Clark1-1/+1
[ Upstream commit 35c719da95c0d28560bff7bafeaf07ebb212665e ] drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error: uninitialized symbol 'request_bandwidth'. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/msm/dpu: Fix scale params in plane validationKalyan Thota1-2/+2
[ Upstream commit 4c978caf08aa155bdeadd9e2d4b026d4ce97ebd0 ] Plane validation uses an API drm_calc_scale which will return src/dst value as a scale ratio. when viewing the range on a scale the values should fall in as Upscale ratio < Unity scale < Downscale ratio for src/dst formula Fix the min and max scale ratios to suit the API accordingly. Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> Tested-by: Kristian H. Kristensen <hoegsberg@google.com> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09drm/msm/dpu: Fix reservation failures in modesetKalyan Thota1-9/+11
[ Upstream commit ccc862b957c6413b008fbe458034372847992d7f ] In TEST_ONLY commit, rm global_state will duplicate the object and request for new reservations, once they pass then the new state will be swapped with the old and will be available for the Atomic Commit. This patch fixes some of missing links in the resource reservation sequence mentioned above. 1) Creation of duplicate state in test_only commit (Rob) 2) Allocate and release the resources on every modeset. 3) Avoid allocation only when active is false. In a modeset operation, swap state happens well before disable. Hence clearing reservations in disable will cause failures in modeset enable. Allow reservations to be cleared/allocated before swap, such that only newly committed resources are pushed to HW. Changes in v1: - Move the rm release to atomic_check. - Ensure resource allocation and free happens when active is not changed i.e only when mode is changed.(Rob) Changes in v2: - Handle dpu_kms_get_global_state API failure as it may return EDEADLK (swboyd). Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-03drm/vmwgfx/ldu: Use drm_mode_config_resetRoland Scheidegger1-6/+2
commit 981243371a5d832af5bc572071172e955d02fe88 upstream. Same problem as in stdu, same fix. Fixes: 51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset") Acked-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/vmwgfx/sou: Use drm_mode_config_resetRoland Scheidegger1-7/+2
commit 1338441cf166e2ef789af5915b961d4e13a4ec31 upstream. Same problem as in stdu, same fix. Fixes: 51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset") Acked-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/vmwgfx/stdu: Use drm_mode_config_resetDaniel Vetter1-7/+2
commit 68745d1edf1700a668c15ecbed466d18f14c7e9b upstream. When converting to atomic the state reset was done by directly calling the functions, and before the modeset object was fully initialized. This means the various ->dev pointers weren't set up. After commit 51f644b40b4b794b28b982fdd5d0dd8ee63f9272 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 12 18:00:49 2020 +0200 drm/atomic-helper: reset vblank on crtc reset this started to oops because now we're trying to derefence drm_crtc->dev. Fix this up by entirely switching over to drm_mode_config_reset, called once everything is set up. Fixes: 51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset") Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Roland Scheidegger <sroland@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/atomic-helper: reset vblank on crtc resetDaniel Vetter11-33/+15
[ Upstream commit 51f644b40b4b794b28b982fdd5d0dd8ee63f9272 ] Only when vblanks are supported ofc. Some drivers do this already, but most unfortunately missed it. This opens up bugs after driver load, before the crtc is enabled for the first time. syzbot spotted this when loading vkms as a secondary output. Given how many drivers are buggy it's best to solve this once and for all in shared helper code. Aside from moving the few existing calls to drm_crtc_vblank_reset into helpers (i915 doesn't use helpers, so keeps its own) I think the regression risk is minimal: atomic helpers already rely on drivers calling drm_crtc_vblank_on/off correctly in their hooks when they support vblanks. And driver that's failing to handle vblanks after this is missing those calls already, and vblanks could only work by accident when enabling a CRTC for the first time right after boot. Big thanks to Tetsuo for helping track down what's going wrong here. There's only a few drivers which already had the necessary call and needed some updating: - komeda, atmel and tidss also needed to be changed to call __drm_atomic_helper_crtc_reset() intead of open coding it - tegra and msm even had it in the same place already, just code motion, and malidp already uses __drm_atomic_helper_crtc_reset(). - Laurent noticed that rcar-du and omap open-code their crtc reset and hence would actually be broken by this patch now. So fix them up by reusing the helpers, which brings the drm_crtc_vblank_reset() back. Only call left is in i915, which doesn't use drm_mode_config_reset, but has its own fastboot infrastructure. So that's the only case where we actually want this in the driver still. I've also reviewed all other drivers which set up vblank support with drm_vblank_init. After the previous patch fixing mxsfb all atomic drivers do call drm_crtc_vblank_on/off as they should, the remaining drivers are either legacy kms or legacy dri1 drivers, so not affected by this change to atomic helpers. v2: Use the drm_dev_has_vblank() helper. v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off instead of drm_crtc_vblank_reset. Adjust them too. v4: Laurent noticed that rcar-du and omap open-code their crtc reset and hence would actually be broken by this patch now. So fix them up by reusing the helpers, which brings the drm_crtc_vblank_reset() back. v5: also mention rcar-du and ompadrm in the proper commit message above (Laurent). Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Maxime Ripard <mripard@kernel.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: syzbot+0871b14ca2e2fb64f6e3@syzkaller.appspotmail.com Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: zhengbin <zhengbin13@huawei.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-tegra@vger.kernel.org Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-03drm/amd/pm: correct the thermal alert temperature limit settingsEvan Quan3-24/+21
commit 28e628645333b7e581c4a7b04d958e4804ea10fe upstream. Do the maths in celsius degree. This can fix the issues caused by the changes below: drm/amd/pm: correct Vega20 swctf limit setting drm/amd/pm: correct Vega12 swctf limit setting drm/amd/pm: correct Vega10 swctf limit setting Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/amd/pm: correct Vega20 swctf limit settingEvan Quan1-2/+4
commit 9b51c4b2ba31396f3894ccc7df8bdf067243e9f5 upstream. Correct the Vega20 thermal swctf limit. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/amd/pm: correct Vega12 swctf limit settingEvan Quan1-2/+4
commit e0ffd340249699ad27a6c91abdfa3e89f7823941 upstream. Correct the Vega12 thermal swctf limit. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/amd/pm: correct Vega10 swctf limit settingEvan Quan1-2/+5
commit b05d71b51078fc428c6b72582126d9d75d3c1f4c upstream. Correct the Vega10 thermal swctf limit. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1267 Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/amd/powerplay: Fix hardmins not being sent to SMU for RVNicholas Kazlauskas1-6/+3
commit e2bf3723db563457c0abe4eaeedac25bbbbd1d76 upstream. [Why] DC uses these to raise the voltage as needed for higher dispclk/dppclk and to ensure that we have enough bandwidth to drive the displays. There's a bug preventing these from actuially sending messages since it's checking the actual clock (which is 0) instead of the incoming clock (which shouldn't be 0) when deciding to send the hardmin. [How] Check the clocks != 0 instead of the actual clocks. Fixes: 9ed9203c3ee7 ("drm/amd/powerplay: rv dal-pplib interface refactor powerplay part") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/amdgpu/gfx10: refine mgcg settingJiansong Chen1-4/+2
commit de7a1b0b8753e1b0000084f0e339ffab295d27ef upstream. 1. enable ENABLE_CGTS_LEGACY to fix specviewperf11 random hang. 2. remove obsolete RLC_CGTT_SCLK_OVERRIDE workaround. Signed-off-by: Jiansong Chen <Jiansong.Chen@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/amd/display: use correct scale for actual_brightnessAlexander Monakov1-41/+40
commit 69d9f4278d0f9d24607645f10e5ac5c59c77a4ac upstream. Documentation for sysfs backlight level interface requires that values in both 'brightness' and 'actual_brightness' files are interpreted to be in range from 0 to the value given in the 'max_brightness' file. With amdgpu, max_brightness gives 255, and values written by the user into 'brightness' are internally rescaled to a wider range. However, reading from 'actual_brightness' gives the raw register value without inverse rescaling. This causes issues for various userspace tools such as PowerTop and systemd that expect the value to be in the correct range. Introduce a helper to retrieve internal backlight range. Use it to reimplement 'convert_brightness' as 'convert_brightness_from_user' and introduce 'convert_brightness_to_user'. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=203905 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1242 Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/amdgpu: Fix buffer overflow in INFO ioctlAlex Deucher1-0/+4
commit b5b97cab55eb71daba3283c8b1d2cce456d511a1 upstream. The values for "se_num" and "sh_num" come from the user in the ioctl. They can be in the 0-255 range but if they're more than AMDGPU_GFX_MAX_SE (4) or AMDGPU_GFX_MAX_SH_PER_SE (2) then it results in an out of bounds read. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/modeset-lock: Take the modeset BKL for legacy driversDaniel Vetter5-10/+9
commit 77ef38574beb3e0b414db48e9c0f04633df68ba6 upstream. This fell off in the conversion in commit 9bcaa3fe58ab7559e71df798bcff6e0795158695 Author: Michal Orzel <michalorzel.eng@gmail.com> Date: Tue Apr 28 19:10:04 2020 +0200 drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers but it's caught by the drm_warn_on_modeset_not_all_locked() that the legacy modeset code uses. Since this is the bkl and it's unclear what's all protected, play it safe and grab it again for legacy drivers. Unfortunately this means we need to sprinkle a few more #includes around. Also we need to add the drm_device as a parameter to the _END macro. Finally remove the mute_lock() from setcrtc, since that's now done by the macro. Cc: Alex Deucher <alexdeucher@gmail.com> References: https://gitlab.freedesktop.org/drm/amd/-/issues/1224 Fixes: 9bcaa3fe58ab ("drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers") Cc: Michal Orzel <michalorzel.eng@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200814093842.3048472-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/dp_mst: Don't return error code when crtc is nullBhawanpreet Lakha1-2/+2
commit 88fee1c9007a38c19f2c558dc0ab1ddb4c323dc5 upstream. [Why] In certain cases the crtc can be NULL and returning -EINVAL causes atomic check to fail when it shouln't. This leads to valid configurations failing because atomic check fails. [How] Don't early return if crtc is null Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> [added stable cc] Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs") Cc: <stable@vger.kernel.org> # v5.6+ Link: https://patchwork.freedesktop.org/patch/msgid/20200814170140.24917-1-Bhawanpreet.Lakha@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/etnaviv: fix external abort seen on GC600 rev 0x19Christian Gmeiner1-2/+9
commit 2c5bf028ef34745e7b3fe768f9c9355ecc7df101 upstream. It looks like that this GPU core triggers an abort when reading VIVS_HI_CHIP_PRODUCT_ID and/or VIVS_HI_CHIP_ECO_ID. I looked at different versions of Vivante's kernel driver and did not found anything about this issue or what feature flag can be used. So go the simplest route and do not read these two registers on the affected GPU core. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reported-by: Josua Mayer <josua.mayer@jm0.eu> Fixes: 815e45bbd4d3 ("drm/etnaviv: determine product, customer and eco id") Cc: stable@vger.kernel.org Tested-by: Josua Mayer <josua.mayer@jm0.eu> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/i915: Fix cmd parser desc matching with masksMika Kuoppala1-4/+10
commit e5f10d6385cda083037915c12b130887c8831d2b upstream. Our variety of defined gpu commands have the actual command id field and possibly length and flags applied. We did start to apply the mask during initialization of the cmd descriptors but forgot to also apply it on comparisons. Fix comparisons in order to properly deny access with associated commands. v2: fix lri with correct mask (Chris) References: 926abff21a8f ("drm/i915/cmdparser: Ignore Length operands during command matching") Reported-by: Nicolai Stange <nstange@suse.de> Cc: stable@vger.kernel.org # v5.4+ Cc: Miroslav Benes <mbenes@suse.cz> Cc: Takashi Iwai <tiwai@suse.de> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200817195926.12671-1-mika.kuoppala@linux.intel.com (cherry picked from commit 3b4efa148da36f158cce3f662e831af2834b8e0f) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-03drm/amdkfd: fix the wrong sdma instance query for renoirHuang Rui1-9/+22
[ Upstream commit 34174b89bfa495bed9cddcc504fb38feca90fab7 ] Renoir only has one sdma instance, it will get failed once query the sdma1 registers. So use switch-case instead of static register array. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 06:27:24 +0300