summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd
AgeCommit message (Collapse)AuthorFilesLines
2019-07-10drm/amdgpu/gfx9: use reset default for PA_SC_FIFO_SIZEAlex Deucher1-19/+0
commit 25f09f858835b0e9a06213811031190a17d8ab78 upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-10drm/amd/powerplay: use hardware fan control if no powerplay fan tableEvan Quan3-1/+8
commit f78c581e22d4b33359ac3462e8d0504735df01f4 upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-15drm/amd/display: Use plane->color_space for dpp if specifiedNicholas Kazlauskas2-2/+6
[ Upstream commit a1e07ba89d49581471d64c48152dbe03b42bd025 ] [Why] The input color space for the plane was previously ignored even if it was set. If a limited range YUV format was given to DC then the wrong color transformation matrix was being used since DC assumed that it was full range instead. [How] Respect the given color_space format for the plane if it isn't COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM didn't specify. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-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-06-11drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-inAaron Liu1-2/+1
commit bdb1ccb080dafc1b4224873a5b759ff85a7d1c10 upstream. In amdgpu_atif_handler, when hotplug event received, remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check. This bit's check will cause missing system resume. Signed-off-by: Aaron Liu <aaron.liu@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>
2019-06-11drm/amdgpu/psp: move psp version specific function pointers to early_initAlex Deucher1-9/+10
commit 9d6fea5744d6798353f37ac42a8a653a2607ca69 upstream. In case we need to use them for GPU reset prior initializing the asic. Fixes a crash if the driver attempts to reset the GPU at driver load time. Acked-by: Christian König <christian.koenig@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>
2019-05-31drm/amd/display: Set stream->mode_changed when connectors changeNicholas Kazlauskas1-2/+1
[ Upstream commit b9952f93cd2cf5fca82b06a8179c0f5f7b769e83 ] [Why] The kms_plane@plane-position-covered-pipe-*-planes subtests can produce a sequence of atomic commits such that neither active_changed nor mode_changed but connectors_changed. When this happens we remove the old stream from the context and add a new stream but the new stream doesn't have mode_changed=true set. This incorrect programming sequence causes CRC mismatches to occur in the test. The stream->mode_changed value should be set whenever a new stream is created. [How] A new stream is created whenever drm_atomic_crtc_needs_modeset is true. We previously covered the active_changed and mode_changed conditions for the CRTC but connectors_changed is also checked within drm_atomic_crtc_needs_modeset. So just use drm_atomic_crtc_needs_modeset directly to determine the mode_changed flag. 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-05-31drm/amd/display: Fix Divide by 0 in memory calculationsMurton Liu1-5/+15
[ Upstream commit 59979bf8be1784ebfc44215031c6c88ca22ae65d ] Check if we get any values equal to 0, and set to 1 if so. Signed-off-by: Murton Liu <murton.liu@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by: Sivapiriyan Kumarasamy <Sivapiriyan.Kumarasamy@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31drm/amd/display: fix releasing planes when exiting odmDmytro Laktyushkin1-2/+4
[ Upstream commit bc2193992b00488f5734613ac95b78ef2d2803ab ] Releasing planes should not release the 2nd odm pipe right away, this change leaves us with 2 pipes with null planes and same stream when planes are released during odm. Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@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-05-31drm/amdgpu: fix old fence check in amdgpu_fence_emitChristian König1-7/+17
[ Upstream commit 3d2aca8c8620346abdba96c6300d2c0b90a1d0cc ] We don't hold a reference to the old fence, so it can go away any time we are waiting for it to signal. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16drm/amd/display: If one stream full updates, full update all planesDavid Francis2-0/+22
[ Upstream commit c238bfe0be9ef7420f7669a69e27c8c8f4d8a568 ] [Why] On some compositors, with two monitors attached, VT terminal switch can cause a graphical issue by the following means: There are two streams, one for each monitor. Each stream has one plane current state: M1:S1->P1 M2:S2->P2 The user calls for a terminal switch and a commit is made to change both planes to linear swizzle mode. In atomic check, a new dc_state is constructed with new planes on each stream new state: M1:S1->P3 M2:S2->P4 In commit tail, each stream is committed, one at a time. The first stream (S1) updates properly, triggerring a full update and replacing the state current state: M1:S1->P3 M2:S2->P4 The update for S2 comes in, but dc detects that there is no difference between the stream and plane in the new and current states, and so triggers a fast update. The fast update does not program swizzle, so the second monitor is corrupted [How] Add a flag to dc_plane_state that forces full updates When a stream undergoes a full update, set this flag on all changed planes, then clear it on the current stream Subsequent streams will get full updates as a result Signed-off-by: David Francis <David.Francis@amd.com> 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> Acked-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-16drm/amd/display: extending AUX SW TimeoutMartin Leung2-6/+9
[ Upstream commit f4bbebf8e7eb4d294b040ab2d2ba71e70e69b930 ] [Why] AUX takes longer to reply when using active DP-DVI dongle on some asics resulting in up to 2000+ us edid read (timeout). [How] 1. Adjust AUX poll to match spec 2. Extend the SW timeout. This does not affect normal operation since we exit the loop as soon as AUX acks. Signed-off-by: Martin Leung <martin.leung@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Joshua Aberback <Joshua.Aberback@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-05-10drm/amd/display: fix cursor black issuetiancyin1-0/+1
[ Upstream commit c1cefe115d1cdc460014483319d440b2f0d07c68 ] [Why] the member sdr_white_level of struct dc_cursor_attributes was not initialized, then the random value result that dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal value is 0x3c00), this cause the black cursor issue. [how] just initilize the obj of struct dc_cursor_attributes to zero to avoid the random value. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Tianci Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-27drm/amdgpu/gmc9: fix VM_L2_CNTL3 programmingAlex Deucher1-0/+1
commit 1925e7d3d4677e681cc2e878c2bdbeaee988c8e2 upstream. Got accidently dropped when 2+1 level support was added. Fixes: 6a42fd6fbf534096 ("drm/amdgpu: implement 2+1 PD support for Raven v3") Reviewed-by: Christian König <christian.koenig@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>
2019-04-20drm/amdkfd: use init_mqd function to allocate object for hid_mqd (CI)Kevin Wang1-51/+1
[ Upstream commit cac734c2dbd2514f14c8c6a17caba1990d83bf1d ] if use the legacy method to allocate object, when mqd_hiq need to run uninit code, it will be cause WARNING call trace. eg: (s3 suspend test) [ 34.918944] Call Trace: [ 34.918948] [<ffffffff92961dc1>] dump_stack+0x19/0x1b [ 34.918950] [<ffffffff92297648>] __warn+0xd8/0x100 [ 34.918951] [<ffffffff9229778d>] warn_slowpath_null+0x1d/0x20 [ 34.918991] [<ffffffffc03ce1fe>] uninit_mqd_hiq_sdma+0x4e/0x50 [amdgpu] [ 34.919028] [<ffffffffc03d0ef7>] uninitialize+0x37/0xe0 [amdgpu] [ 34.919064] [<ffffffffc03d15a6>] kernel_queue_uninit+0x16/0x30 [amdgpu] [ 34.919086] [<ffffffffc03d26c2>] pm_uninit+0x12/0x20 [amdgpu] [ 34.919107] [<ffffffffc03d4915>] stop_nocpsch+0x15/0x20 [amdgpu] [ 34.919129] [<ffffffffc03c1dce>] kgd2kfd_suspend.part.4+0x2e/0x50 [amdgpu] [ 34.919150] [<ffffffffc03c2667>] kgd2kfd_suspend+0x17/0x20 [amdgpu] [ 34.919171] [<ffffffffc03c103a>] amdgpu_amdkfd_suspend+0x1a/0x20 [amdgpu] [ 34.919187] [<ffffffffc02ec428>] amdgpu_device_suspend+0x88/0x3a0 [amdgpu] [ 34.919189] [<ffffffff922e22cf>] ? enqueue_entity+0x2ef/0xbe0 [ 34.919205] [<ffffffffc02e8220>] amdgpu_pmops_suspend+0x20/0x30 [amdgpu] [ 34.919207] [<ffffffff925c56ff>] pci_pm_suspend+0x6f/0x150 [ 34.919208] [<ffffffff925c5690>] ? pci_pm_freeze+0xf0/0xf0 [ 34.919210] [<ffffffff926b45c6>] dpm_run_callback+0x46/0x90 [ 34.919212] [<ffffffff926b49db>] __device_suspend+0xfb/0x2a0 [ 34.919213] [<ffffffff926b4b9f>] async_suspend+0x1f/0xa0 [ 34.919214] [<ffffffff922c918f>] async_run_entry_fn+0x3f/0x130 [ 34.919216] [<ffffffff922b9d4f>] process_one_work+0x17f/0x440 [ 34.919217] [<ffffffff922bade6>] worker_thread+0x126/0x3c0 [ 34.919218] [<ffffffff922bacc0>] ? manage_workers.isra.25+0x2a0/0x2a0 [ 34.919220] [<ffffffff922c1c31>] kthread+0xd1/0xe0 [ 34.919221] [<ffffffff922c1b60>] ? insert_kthread_work+0x40/0x40 [ 34.919222] [<ffffffff92974c1d>] ret_from_fork_nospec_begin+0x7/0x21 [ 34.919224] [<ffffffff922c1b60>] ? insert_kthread_work+0x40/0x40 [ 34.919224] ---[ end trace 38cd9f65c963adad ]--- Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Oak Zeng <Oak.Zeng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05drm/amd/display: Enable vblank interrupt during CRC captureNicholas Kazlauskas2-22/+34
[ Upstream commit 428da2bdb05d76c48d0bd8fbfa2e4c102685be08 ] [Why] In order to read CRC events when CRC capture is enabled the vblank interrput handler needs to be running for the CRTC. The handler is enabled while there is an active vblank reference. When running IGT tests there will often be no active vblank reference but the test expects to read a CRC value. This is valid usage (and works on i915 since they have a CRC interrupt handler) so the reference to the vblank should be grabbed while capture is active. This issue was found running: igt@kms_plane_multiple@atomic-pipe-b-tiling-none The pipe-b is the only one in the initial commit and was not previously active so no vblank reference is grabbed. The vblank interrupt is not enabled and the test times out. [How] Keep a reference to the vblank as long as CRC capture is enabled. If userspace never explicitly disables it then the reference is also dropped when removing the CRTC from the context (stream = NULL). Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@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-04-05drm/amd/display: Disconnect mpcc when changing tgNicholas Kazlauskas1-3/+4
[ Upstream commit 77476360f173c127c191bfe8ca8113130ef283b8 ] [Why] This fixes an mpc programming error for the following sequence of atomic commits when pipe split is enabled: Commit 1: CRTC0 (plane 4, plane 3) Pipe 0: old_plane_state = A0, new_plane_state = A1, new_tg = T0 Pipe 1: old_plane_state = B0, new_plane_state = B1, new_tg = T0 Pipe 2: old_plane_state = A0, new_plane_state = A1, new_tg = T0 Pipe 3: old_plane_state = B0, new_plane_state = B1, new_tg = T0 Commit 2: CRTC0 (plane 3), CRTC1 (plane 2) Pipe 0: old_plane_state = A1, new_plane_state = A2, new_tg = T0 Pipe 1: old_plane_state = B1, new_plane_state = B2, new_tg = T1 Pipe 2: old_plane_state = A1, new_plane_state = NULL, new_tg = NULL Pipe 3: old_plane_state = B1, new_plane_state = NULL, new_tg = NULL In the second commit the assertion for mpcc in use is hit because mpcc disconnect never occurs for pipe 1. This is because the stream changes for pipe 1 and the opp_list is empty. This sequence occurs when running the "igt@kms_plane_multiple@atomic-pipe-A-tiling-none" test with two displays connected. [How] Expand the reset condition to include: "old_pipe_ctx->stream_res.tg != new_pipe_ctx->stream_res.tg" ...but only when the plane state is non-NULL for both old and new. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@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-04-05drm/amd/display: Don't re-program planes for DPMS changesNicholas Kazlauskas1-1/+2
[ Upstream commit 5062b797db4103218fa00ee254417b8ecaab7401 ] [Why] There are opt1c lock warnings and CRTC read timeouts when running the "igt@kms_plane@plane-position-hole-dpms-pipe-*" tests. These are caused by trying to reprogram planes that are not in the current context. DPMS off removes the stream from the context. In this case: new_crtc_state->active_changed = true new_crtc_state->mode_changed = false The planes are reprogrammed before the stream is removed from the context because stream_state->mode_changed = false. For DPMS adds the stream and planes back to the context: new_crtc_state->active_changed = true new_crtc_state->mode_changed = false The planes are also reprogrammed here before the stream is added to the context because stream_state->mode_changed = true. They were not previously in the current context so warnings occur here. [How] Set stream_state->mode_changed = true when new_crtc_state->active_changed = true too. This prevents reprogramming before the context is applied in DC. The programming will be done after the context is applied. 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> Acked-by: Tony Cheng <Tony.Cheng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05drm/amd/display: Clear stream->mode_changed after commitNicholas Kazlauskas1-0/+3
[ Upstream commit d8d2f174bcc2c26c3485c70e0c6fe22b27bce739 ] [Why] The stream->mode_changed flag can persist in the following sequence of atomic commits: Commit 1: Enable CRTC0 (mode_changed = true), Enable CRTC1 (mode_changed = true) Commit 2: Disable CRTC1 (mode_changed = false) In this sequence we want to keep the exiting CRTC0 but it's not in the atomic state for the commit since it hasn't been modified. In this case the stream->mode_changed flag persists as true and we don't re-program the planes for the existing stream. [How] The flag needs to be cleared and it makes the most sense to do it within DC after the state has been committed. Nothing following dc_commit_state should think that the stream's mode has changed. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Acked-by: Tony Cheng <Tony.Cheng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-23drm/amd/display: don't call dm_pp_ function from an fpu blockHarry Wentland1-2/+6
commit 59d3191f14dc18881fec1172c7096b7863622803 upstream. Powerplay functions called from dm_pp_* functions tend to do a mutex_lock which isn't safe to do inside a kernel_fpu_begin/end block as those will disable/enable preemption. Rearrange the dm_pp_get_clock_levels_by_type_with_voltage calls to make sure they happen outside of kernel_fpu_begin/end. Cc: stable@vger.kernel.org Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-23drm/amd/powerplay: correct power reading on fijiEvan Quan1-3/+3
commit f5742ec36422a39b57f0256e4847f61b3c432f8c upstream. Set sampling period as 500ms to provide a smooth power reading output. Also, correct the register for power reading. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@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>
2019-03-14drm/amdgpu: use spin_lock_irqsave to protect vm_manager.pasid_idrPhilip Yang1-2/+3
[ Upstream commit 0a5f49cbf9d6ad3721c16f8a6d823363ea7a160f ] amdgpu_vm_get_task_info is called from interrupt handler and sched timeout workqueue, we should use irq version spin_lock to avoid deadlock. Signed-off-by: Philip Yang <Philip.Yang@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-03-14drm/amdgpu: Transfer fences to dmabuf importerChris Wilson1-8/+51
[ Upstream commit 6e11ea9de9576a644045ffdc2067c09bc2012eda ] amdgpu only uses shared-fences internally, but dmabuf importers rely on implicit write hazard tracking via the reservation_object.fence_excl. For example, the importer use the write hazard for timing a page flip to only occur after the exporter has finished flushing its write into the surface. As such, on exporting a dmabuf, we must either flush all outstanding fences (for we do not know which are writes and should have been exclusive) or alternatively create a new exclusive fence that is the composite of all the existing shared fences, and so will only be signaled when all earlier fences are signaled (ensuring that we can not be signaled before the completion of any earlier write). v2: reservation_object is already locked by amdgpu_bo_reserve() v3: Replace looping with get_fences_rcu and special case the promotion of a single shared fence directly to an exclusive fence, bypassing the fence array. v4: Drop the fence array ref after assigning to reservation_object Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341 Testcase: igt/amd_prime/amd-to-i915 References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@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-03-14drm/amdgpu: Add missing power attribute to APU checkAlex Deucher1-1/+2
[ Upstream commit dc14eb12f6bb3e779c5461429c1889a339c67aab ] Add missing power_average to visible check for power attributes for APUs. Was missed before. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-05drm/amd/powerplay: OD setting fix on Vega10Kenneth Feng1-1/+21
[ Upstream commit 6d87dc97eb3341de3f7b1efa3156cb0e014f4a96 ] gfxclk for OD setting is limited to 1980M for non-acg ASICs of Vega10 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-27drm/amd/display: Fix MST reboot/poweroff sequenceLeo (Hanghong) Ma1-2/+3
commit d2f0b53bda3193874f3905bc839888f895d1c0cf upstream. [Why] drm_dp_mst_topology_mgr_suspend() is added into the new reboot sequence, which disables the UP request at the beginning. Therefore sideband messages are blocked. [How] Finish MST sideband message transaction before UP request is suppressed. Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Acked-by: Leo Li <sunpeng.li@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>
2019-02-27drm/amdgpu: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtimeAlex Deucher1-0/+1
commit d33158530660bc89be3cc870a2152e4e9a76cac7 upstream. Based on a similar patch from Rafael for radeon. When using ATPX to control dGPU power, the state is not retained across suspend and resume cycles by default. This can probably be loosened for Hybrid Graphics (_PR3) laptops where I think the state is properly retained. Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks") Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-27drm/amd/display: fix PME notification not working in RV desktopCharlene Liu1-1/+6
[ Upstream commit 20300db4aec5ba5edf6f0ad6f7111a51fbea7e10 ] [Why] PPLIB not receive the PME when unplug. Signed-off-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Chris Park <Chris.Park@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-02-27drm/amdkfd: Don't assign dGPUs to APU topology devicesFelix Kuehling1-3/+9
[ Upstream commit bbdf514fe5648566b0754476cbcb92ac3422dde2 ] dGPUs need their own topology devices. Don't assign them to APU topology devices with CPU cores. Bug: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/66 Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Tested-by: Elias Konstantinidis <ekondis@gmail.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-20drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hangJim Qu1-1/+2
[ Upstream commit 0c6c8125582714e1fd3544983eba3d750db0f5b8 ] effect asics: VEGA10 and VEGA12 Signed-off-by: Jim Qu <Jim.Qu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-20drm/amdgpu/sriov:Correct pfvf exchange logicEmily Deng2-5/+5
[ Upstream commit b8cf66182eddb22e9c7539821ed6eecdb4f86d1a ] The pfvf exchange need be in exclusive mode. And add pfvf exchange in gpu reset. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-By: Xiangliang Yu <Xiangliang.Yu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-15drm/amd/powerplay: Fix missing break in switchGustavo A. R. Silva1-0/+1
commit 2f10d823739680d2477ce34437e8a08a53117f40 upstream. Add missing break statement in order to prevent the code from falling through to the default case. The resoning for this is that pclk_vol_table is an automatic variable. So, it makes no sense to update it just before falling through to the default case and return -EINVAL. This bug was found thanks to the ongoing efforts to enabling -Wimplicit-fallthrough. Fixes: cd70f3d6e3fa ("drm/amd/powerplay: PP/DAL interface changes for dynamic clock switch") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12drm/amd/display: validate extended dongle capsWenjing Liu1-1/+2
[ Upstream commit 99b922f9ed6a6313c0d2247cde8aa1e4a0bd67e4 ] [why] Some dongle doesn't have a valid extended dongle caps, but we still set the extended dongle caps to be valid. This causes validation fails for all timing. [how] If no dp_hdmi_max_pixel_clk is provided, don't use extended dongle caps. Signed-off-by: Wenjing Liu <Wenjing.Liu@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Abdoulaye Berthe <Abdoulaye.Berthe@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-02-12drm/amd/display: fix YCbCr420 blank colorEric Yang2-1/+19
[ Upstream commit 12750d1647f118496f1da727146f255f5e44d500 ] [Why] YCbCr420 packing format uses two chanels for luma, and 1 channel for both chroma component. Our previous implementation did not account for this and results in every other pixel having very high luma value, showing greyish color instead of black. YCbCr444 = <Y1, Cb1, Cr1>; <Y2, Cb2, Cr2> ..... YCbCr420 = <Y1, Y2, Cb1>; <Y3, Y4, Cr1> ..... [How] Program the second channel with the black color value for luma as well. Signed-off-by: Eric Yang <Eric.Yang2@amd.com> Reviewed-by: Hugo Hu <Hugo.Hu@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-02-12drm/amd/display: Add retry to read ddc_clock pinPaul Hsieh1-6/+17
[ Upstream commit bd4905a9583c760da31ded7256dca6f71483c3dc ] [WHY] On customer board, there is one pluse (1v , < 1ms) on DDC_CLK pin when plug / unplug DP cable. Driver will read it and config DP to HDMI/DVI dongle. [HOW] If there is a real dongle, DDC_CLK should be always pull high. Try to read again to recovery this special case. Retry times = 3. Need additional 3ms to detect DP passive dongle(3 failures) Signed-off-by: Paul Hsieh <paul.hsieh@amd.com> Reviewed-by: Eric Yang <eric.yang2@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-02-12drm/amdgpu/powerplay: fix clock stretcher limits on polaris (v2)Alex Deucher1-2/+15
[ Upstream commit de4aaab5cc9770a8c4dc13d9bfb6a83b06bba57e ] Adjust limits for newer polaris variants. v2: fix polaris11 kicker (Jerry) Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-12drm/amd/display: calculate stream->phy_pix_clk before clock mappingYogesh Mohan Marimuthu1-0/+2
[ Upstream commit 08e1c28dd521c7b08d1b0af0bae9fb22ccc012a4 ] [why] phy_pix_clk is one of the variable used to check if one PLL can be shared with displays having common mode set configuration. As of now phy_pix_clock varialbe is calculated in function dc_validate_stream(). dc_validate_stream() function is called after clocks are assigned for the new display. Due to this during hotplug, when PLL sharing conditions are checked for new display phy_pix_clk variable will be 0 and for displays that are already enabled phy_pix_clk will have some value. Hence PLL will not be shared and if the display hardware doesn't have any more PLL to assign, mode set will fail due to resource unavailability. [how] Instead of only calculating the phy_pix_clk variable after the PLL is assigned for new display, this patch calculates phy_pix_clk also during the before assigning the PLL for new display. Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@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-02-12drm/amd/display: fix gamma not being applied correctlyMurton Liu1-1/+2
[ Upstream commit 8ce504b9389be846bcdf512ed5be8f661b3bf097 ] [why] Gamma was always being set as identity on SDR monitor, leading to no changes in gamma. This caused nightlight to not apply correctly. [how] Added a default gamma structure to compare against in the sdr case. Signed-off-by: Murton Liu <murton.liu@amd.com> Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@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-01-31drm/amdgpu: Add APTX quirk for Lenovo laptopAlex Deucher1-0/+1
commit f15f3eb26e8d9d25ea2330ed1273473df2f039df upstream. Needs ATPX rather than _PR3 for dGPU power control. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=202263 Reviewed-by: Jim Qu <Jim.Qu@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>
2019-01-26drm/amdgpu: Reorder uvd ring init before uvd resumeChris Wilson4-16/+16
[ Upstream commit 3b34c14fd50c302db091f020f26dd00ede902c80 ] As amd_uvd_resume() accesses the uvd ring, it must be initialised first or else we trigger errors like: [ 5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17 [ 5.595969] [drm] PSP loading UVD firmware [ 5.596266] ------------[ cut here ]------------ [ 5.596268] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: (null) [ 5.596285] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80 [ 5.596286] Modules linked in: amdgpu(+) hid_logitech_hidpp(+) chash gpu_sched amd_iommu_v2 ttm drm_kms_helper crc32c_intel drm hid_sony ff_memless igb hid_logitech_dj nvme dca i2c_algo_bit nvme_core wmi pinctrl_amd uas usb_storage [ 5.596299] CPU: 0 PID: 507 Comm: systemd-udevd Tainted: G W 4.20.0-0.rc1.git4.1.fc30.x86_64 #1 [ 5.596301] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0901 07/23/2018 [ 5.596303] RIP: 0010:debug_print_object+0x6a/0x80 [ 5.596305] Code: 8b 43 10 83 c2 01 8b 4b 14 4c 89 e6 89 15 e6 82 b0 02 4c 8b 45 00 48 c7 c7 60 fd 34 a6 48 8b 14 c5 a0 da 08 a6 e8 6a 6a b8 ff <0f> 0b 5b 83 05 d0 45 3e 01 01 5d 41 5c c3 83 05 c5 45 3e 01 01 c3 [ 5.596306] RSP: 0018:ffffa02ac863f8c0 EFLAGS: 00010282 [ 5.596307] RAX: 0000000000000000 RBX: ffffa02ac863f8e0 RCX: 0000000000000006 [ 5.596308] RDX: 0000000000000007 RSI: ffff9160e9a7bfe8 RDI: ffff9160f91d6c60 [ 5.596310] RBP: ffffffffa6742740 R08: 0000000000000002 R09: 0000000000000000 [ 5.596311] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa634ff69 [ 5.596312] R13: 00000000000b79d0 R14: ffffffffa80f76d8 R15: 0000000000266000 [ 5.596313] FS: 00007f762abf7940(0000) GS:ffff9160f9000000(0000) knlGS:0000000000000000 [ 5.596314] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.596315] CR2: 000055fdc593f000 CR3: 00000007e999c000 CR4: 00000000003406f0 [ 5.596317] Call Trace: [ 5.596321] debug_object_assert_init+0x14a/0x180 [ 5.596327] del_timer+0x2e/0x90 [ 5.596383] amdgpu_fence_process+0x47/0x100 [amdgpu] [ 5.596430] amdgpu_uvd_resume+0xf6/0x120 [amdgpu] [ 5.596475] uvd_v7_0_sw_init+0xe0/0x280 [amdgpu] [ 5.596523] amdgpu_device_init.cold.30+0xf97/0x14b6 [amdgpu] [ 5.596563] ? amdgpu_driver_load_kms+0x53/0x330 [amdgpu] [ 5.596604] amdgpu_driver_load_kms+0x86/0x330 [amdgpu] [ 5.596614] drm_dev_register+0x115/0x150 [drm] [ 5.596654] amdgpu_pci_probe+0xbd/0x120 [amdgpu] [ 5.596658] local_pci_probe+0x41/0x90 [ 5.596661] pci_device_probe+0x188/0x1a0 [ 5.596666] really_probe+0xf8/0x3b0 [ 5.596669] driver_probe_device+0xb3/0xf0 [ 5.596672] __driver_attach+0xe1/0x110 [ 5.596674] ? driver_probe_device+0xf0/0xf0 [ 5.596676] bus_for_each_dev+0x79/0xc0 [ 5.596679] bus_add_driver+0x155/0x230 [ 5.596681] ? 0xffffffffc07d9000 [ 5.596683] driver_register+0x6b/0xb0 [ 5.596685] ? 0xffffffffc07d9000 [ 5.596688] do_one_initcall+0x5d/0x2be [ 5.596691] ? rcu_read_lock_sched_held+0x79/0x80 [ 5.596693] ? kmem_cache_alloc_trace+0x264/0x290 [ 5.596695] ? do_init_module+0x22/0x210 [ 5.596698] do_init_module+0x5a/0x210 [ 5.596701] load_module+0x2137/0x2430 [ 5.596703] ? lockdep_hardirqs_on+0xed/0x180 [ 5.596714] ? __do_sys_init_module+0x150/0x1a0 [ 5.596715] __do_sys_init_module+0x150/0x1a0 [ 5.596722] do_syscall_64+0x60/0x1f0 [ 5.596725] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 5.596726] RIP: 0033:0x7f762b877dee [ 5.596728] Code: 48 8b 0d 9d 20 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6a 20 0c 00 f7 d8 64 89 01 48 [ 5.596729] RSP: 002b:00007ffc777b8558 EFLAGS: 00000246 ORIG_RAX: 00000000000000af [ 5.596730] RAX: ffffffffffffffda RBX: 000055fdc48da320 RCX: 00007f762b877dee [ 5.596731] RDX: 00007f762b9f284d RSI: 00000000006c5fc6 RDI: 000055fdc527a060 [ 5.596732] RBP: 00007f762b9f284d R08: 0000000000000003 R09: 0000000000000002 [ 5.596733] R10: 000055fdc48ad010 R11: 0000000000000246 R12: 000055fdc527a060 [ 5.596734] R13: 000055fdc48dca20 R14: 0000000000020000 R15: 0000000000000000 [ 5.596740] irq event stamp: 134618 [ 5.596743] hardirqs last enabled at (134617): [<ffffffffa513d52e>] console_unlock+0x45e/0x610 [ 5.596744] hardirqs last disabled at (134618): [<ffffffffa50037e8>] trace_hardirqs_off_thunk+0x1a/0x1c [ 5.596746] softirqs last enabled at (133146): [<ffffffffa5e00365>] __do_softirq+0x365/0x47c [ 5.596748] softirqs last disabled at (133139): [<ffffffffa50c64f9>] irq_exit+0x119/0x120 [ 5.596749] ---[ end trace eaee508abfebccdc ]--- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108709 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-01-26drm/amdkfd: fix interrupt spin lockChristian König1-2/+3
[ Upstream commit 2383a767c0ca06f96534456d8313909017c6c8d0 ] Vega10 has multiple interrupt rings, so this can be called from multiple calles at the same time resulting in: [ 71.779334] ================================ [ 71.779406] WARNING: inconsistent lock state [ 71.779478] 4.19.0-rc1+ #44 Tainted: G W [ 71.779565] -------------------------------- [ 71.779637] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 71.779740] kworker/6:1/120 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 71.779832] 00000000ad761971 (&(&kfd->interrupt_lock)->rlock){?...}, at: kgd2kfd_interrupt+0x75/0x100 [amdgpu] [ 71.780058] {IN-HARDIRQ-W} state was registered at: [ 71.780115] _raw_spin_lock+0x2c/0x40 [ 71.780180] kgd2kfd_interrupt+0x75/0x100 [amdgpu] [ 71.780248] amdgpu_irq_callback+0x6c/0x150 [amdgpu] [ 71.780315] amdgpu_ih_process+0x88/0x100 [amdgpu] [ 71.780380] amdgpu_irq_handler+0x20/0x40 [amdgpu] [ 71.780409] __handle_irq_event_percpu+0x49/0x2a0 [ 71.780436] handle_irq_event_percpu+0x30/0x70 [ 71.780461] handle_irq_event+0x37/0x60 [ 71.780484] handle_edge_irq+0x83/0x1b0 [ 71.780506] handle_irq+0x1f/0x30 [ 71.780526] do_IRQ+0x53/0x110 [ 71.780544] ret_from_intr+0x0/0x22 [ 71.780566] cpuidle_enter_state+0xaa/0x330 [ 71.780591] do_idle+0x203/0x280 [ 71.780610] cpu_startup_entry+0x6f/0x80 [ 71.780634] start_secondary+0x1b0/0x200 [ 71.780657] secondary_startup_64+0xa4/0xb0 Fix this by always using irq save spin locks. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-01-26drm/amd/display: Guard against null stream_state in set_crc_sourceNicholas Kazlauskas1-0/+5
[ Upstream commit f41a895026b8cb6f765190de7d2e7bc3ccbbd183 ] [Why] The igt@kms_plane@pixel-format-pipe tests can create a sequence where stream_state is NULL during amdgpu_dm_crtc_set_crc_source which results in a null pointer dereference. [How] Guard against stream_state being NULL before accessing its fields. This doesn't fix the root cause of the issue so a DRM_ERROR is generated to still fail the tests. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@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-01-17drm/amdgpu: Don't fail resume process if resuming atomic state failsLyude Paul1-3/+2
commit 2d1af6a11cb9d88e0e3dd10258904c437fe1b315 upstream. This is an ugly one unfortunately. Currently, all DRM drivers supporting atomic modesetting will save the state that userspace had set before suspending, then attempt to restore that state on resume. This probably worked very well at one point, like many other things, until DP MST came into the picture. While it's easy to restore state on normal display connectors that were disconnected during suspend regardless of their state post-resume, this can't really be done with MST because of the fact that setting up a downstream sink requires performing sideband transactions between the source and the MST hub, sending out the ACT packets, etc. Because of this, there isn't really a guarantee that we can restore the atomic state we had before suspend once we've resumed. This sucks pretty bad, but so far I haven't run into any compositors that this actually causes serious issues with. Most compositors will notice the hotplug we send afterwards, and then reprobe state. Since nouveau and i915 also don't fail the suspend/resume process due to failing to restore the atomic state, let's make amdgpu match this behavior. Better to resume the GPU properly, then to stop the process half way because of a potentially unavoidable atomic commit failure. Eventually, we'll have a real fix for this problem on the DRM level. But we've got some more important low-hanging fruit to deal with first. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: <stable@vger.kernel.org> # v4.15+ Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-3-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-17drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()Lyude Paul1-9/+23
commit fe7553bef8d676d1d8b40666868b33ec39b9df5d upstream. drm_dp_mst_topology_mgr_resume() returns whether or not it managed to find the topology in question after a suspend resume cycle, and the driver is supposed to check this value and disable MST accordingly if it's gone-in addition to sending a hotplug in order to notify userspace that something changed during suspend. Currently, amdgpu just makes the mistake of ignoring the return code from drm_dp_mst_topology_mgr_resume() which means that if a topology was removed in suspend, amdgpu never notices and assumes it's still connected which leads to all sorts of problems. So, fix this by actually checking the rc from drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the function while we're at it to fix the over-indenting. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: <stable@vger.kernel.org> # v4.15+ Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-2-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-17drm/amd/display: Fix MST dp_blank REG_WAIT timeoutJerry (Fangzhi) Zuo1-2/+2
commit 8c9d90eebd23b6d40ddf4ce5df5ca2b932336a06 upstream. Need to blank stream before deallocate MST payload. [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:944 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2201 at /var/lib/dkms/amdgpu/18.50-690240/build/amd/amdgpu/../display/dc/dc_helper.c:249 generic_reg_wait+0xe7/0x160 [amdgpu] Call Trace: dce110_stream_encoder_dp_blank+0x11c/0x180 [amdgpu] core_link_disable_stream+0x40/0x230 [amdgpu] ? generic_reg_update_ex+0xdb/0x130 [amdgpu] dce110_reset_hw_ctx_wrap+0xb7/0x1f0 [amdgpu] dce110_apply_ctx_to_hw+0x30/0x430 [amdgpu] ? dce110_apply_ctx_for_surface+0x206/0x260 [amdgpu] dc_commit_state+0x2ba/0x4d0 [amdgpu] amdgpu_dm_atomic_commit_tail+0x297/0xd70 [amdgpu] ? amdgpu_bo_pin_restricted+0x58/0x260 [amdgpu] ? wait_for_completion_timeout+0x1f/0x120 ? wait_for_completion_interruptible+0x1c/0x160 commit_tail+0x3d/0x60 [drm_kms_helper] drm_atomic_helper_commit+0xf6/0x100 [drm_kms_helper] drm_atomic_connector_commit_dpms+0xe5/0xf0 [drm] drm_mode_obj_set_property_ioctl+0x14f/0x250 [drm] drm_mode_connector_property_set_ioctl+0x2e/0x40 [drm] drm_ioctl+0x1e0/0x430 [drm] ? drm_mode_connector_set_obj_prop+0x70/0x70 [drm] ? ep_read_events_proc+0xb0/0xb0 ? ep_scan_ready_list.constprop.18+0x1e6/0x1f0 ? timerqueue_add+0x52/0x80 amdgpu_drm_ioctl+0x49/0x80 [amdgpu] do_vfs_ioctl+0x90/0x5f0 SyS_ioctl+0x74/0x80 do_syscall_64+0x74/0x140 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 ---[ end trace 3ed7b77a97d60f72 ]--- Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-17drm/amdgpu: Add new VegaM pci idAlex Deucher1-0/+1
commit f6653a0e0877572c87f6dab5351e7bd6b6b7100c upstream. Add a new pci id. Reviewed-by: Leo Liu <leo.liu@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>
2019-01-13drm/amd/display: Fix unintialized max_bpc state valuesNicholas Kazlauskas1-0/+2
commit 49f1c44b581b08e3289127ffe58bd208c3166701 upstream. [Why] If the "max bpc" isn't explicitly set in the atomic state then it have a value of 0. This has the correct behavior of limiting a panel to 8bpc in the case where the panel supports 8bpc. In the case of eDP panels this isn't a true assumption - there are panels that can only do 6bpc. Banding occurs for these displays. [How] Initialize the max_bpc when the connector resets to 8bpc. Also carry over the value when the state is duplicated. Bugzilla: https://bugs.freedesktop.org/108825 Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector property") Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-13drm/amdgpu: Fix DEBUG_LOCKS_WARN_ON(depth <= 0) in amdgpu_ctx.lockAndrey Grodzovsky1-2/+2
[ Upstream commit c554206077428af56cc2e0314b86b41cd030458c ] If CS is submitted using guilty ctx, we terminate amdgpu_cs_parser_init before locking ctx->lock, latter in amdgpu_cs_parser_fini we still are trying to release the lock just becase parser->ctx != NULL. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@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>
2018-12-21drm/amdgpu/vcn: Update vcn.cur_state during suspendJames Zhu1-1/+2
[ Upstream commit 0a9b89b2e2e7b6d90f81ddc47e489be1043e01b1 ] Replace vcn_v1_0_stop with vcn_v1_0_set_powergating_state during suspend, to keep adev->vcn.cur_state update. It will fix VCN S3 hung issue. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-12-21drm/amd/powerplay: issue pre-display settings for display change eventEvan Quan2-2/+3
[ Upstream commit 10cb3e6b63bf4266a5198813526fdd7259ffb8be ] For display config change event only, pre-display config settings are needed. 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-12-21drm/amdgpu: wait for IB test on first device openChristian König1-3/+3
[ Upstream commit 3bfa8897e4d08f822d1d58cf6cbbffbccef82e08 ] Instead of delaying that to the first query. Otherwise we could try to use the SDMA for VM updates before the IB tests are done. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@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 05:14:48 +0300