aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2021-06-23drm/msm: remove unnecessary mmap logic for cached BOsJonathan Marek1-12/+3
No one knows what this is for anymore, so just remove it. Signed-off-by: Jonathan Marek <[email protected]> Acked-by: Jordan Crouse <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm/dsi: add DSI PHY registers to snapshot dataDmitry Baryshkov4-4/+33
Add DSI PHY registers to the msm state snapshots to be able to check their contents. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm: get rid of msm_iomap_sizeDmitry Baryshkov3-21/+14
Instead of looping throught the resources each time to get the DSI CTRL area size, get it at the ioremap time. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm: make msm_disp_state transient data structDmitry Baryshkov4-77/+37
Instead of allocating snapshotting structure at the driver probe time and later handling concurrent access, actual state, etc, make msm_disp_state transient struct. Allocate one when snapshotting happens and free it after coredump data is read by userspace. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm: pass dump state as a function argumentDmitry Baryshkov9-40/+13
Instead of always getting the disp_state from drm device, pass it as an argument. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm: add disp snapshot points across dpu driverAbhinav Kumar3-9/+29
Add snapshot points across dpu driver to trigger dumps when critical errors are hit. changes in v5: - change the callers to use the snapshot function directly Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm: add support to take dsi, dp and dpu snapshotAbhinav Kumar2-0/+17
Add support to take the register snapshot of dsi, dp and dpu modules. Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm/disp/dpu1: add API to take DPU register snapshotAbhinav Kumar2-0/+54
Add an API to take a snapshot of DPU controller registers. This API will be used by the msm_disp_snapshot module to capture the DPU snapshot. Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm/dp: add API to take DP register snapshotAbhinav Kumar4-0/+43
Add an API to take a snapshot of DP controller registers. This API will be used by the msm_disp_snapshot module to capture the DP snapshot. Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm/dsi: add API to take DSI register snapshotAbhinav Kumar3-1/+23
Add an API to take a snapshot of DSI controller registers. This API will be used by the msm_disp_snapshot module to capture the DSI snapshot. Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm: add support to take dpu snapshotAbhinav Kumar11-2/+529
Add the msm_disp_snapshot module which adds supports to dump dpu registers and capture the drm atomic state which can be used in case of error conditions. changes in v5: - start storing disp_state in msm_kms instead of dpu_kms - get rid of MSM_DISP_SNAPSHOT_IN_* enum by simplifying the functions - move snprintf inside the snapshot core by using varargs - get rid of some stale code comments - allow snapshot module for non-DPU targets Reported-by: kernel test robot <[email protected]> Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm: allow drm_atomic_print_state() to accept any drm_printerAbhinav Kumar4-7/+30
Currently drm_atomic_print_state() internally allocates and uses a drm_info printer. Allow it to accept any drm_printer type so that the API can be leveraged even for taking drm snapshot. Rename the drm_atomic_print_state() to drm_atomic_print_new_state() so that it reflects its functionality better. changes in v5: - none Reported-by: kernel test robot <[email protected]> Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm/dp: handle irq_hpd with sink_count = 0 correctlyKuogee Hsieh4-18/+101
irq_hpd interrupt should be handled after dongle plugged in and before dongle unplugged. Hence irq_hpd interrupt is enabled at the end of the plugin handle and disabled at the beginning of unplugged handle. Current irq_hpd with sink_count = 0 is wrongly handled same as the dongle unplugged which tears down the mainlink and disables the phy. This patch fixes this problem by only tearing down the mainlink but keeping phy enabled at irq_hpd with sink_count = 0 handle so that next irq_hpd with sink_count =1 can be handled by setup mainlink only. This patch also set dongle into D3 (power off) state at end of handling irq_hpd with sink_count = 0. Changes in v2: -- add ctrl->phy_Power_count Changes in v3: -- del ctrl->phy_Power_count -- add phy_power_off to dp_ctrl_off_link_stream() Changes in v4: -- return immediately if clock disable failed at dp_ctrl_off_link_stream() Changes in v5: -- set dongle to D3 (power off) state at dp_ctrl_off_link_stream() Changes in v6: -- add Fixes tag Fixes: ea9f337ce81e ("drm/msm/dp: reset dp controller only at boot up and pm_resume") Signed-off-by: Kuogee Hsieh <[email protected]> Tested-by: Stephen Boyd <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23Merge tag 'drm-misc-next-fixes-2021-06-18' of ↵Dave Airlie2-27/+43
git://anongit.freedesktop.org/drm/drm-misc into drm-next Short summary of fixes pull: * hyperv: advertise the correct formatmodifiers for its primary plane * dp_mst: VCPI fixes to make it work with StarTech hub * dp_mst: Fix build error Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-23Merge tag 'drm/tegra/for-5.14-rc1' of ↵Dave Airlie8-20/+223
ssh://git.freedesktop.org/git/tegra/linux into drm-next drm/tegra: Changes for v5.14-rc1 The two major changes here are fixed YUV support as well as scaling on Tegra186 and later. This allows Tegra DRM to be used, for example, as a video sink for the kmssink gstreamer plugin. The remainder of the changes are minor fixes. Signed-off-by: Dave Airlie <[email protected]> From: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-23Backmerge tag 'v5.13-rc7' into drm-nextDave Airlie18-102/+253
Backmerge Linux 5.13-rc7 to make some pulls from later bases apply, and to bake in the conflicts so far.
2021-06-22drm/amdgpu/display: fold DRM_AMD_DC_DCN3_1 into DRM_AMD_DC_DCNAlex Deucher58-319/+45
No need for a separate flag now that DCN3.1 is not in bring up. Fold into DRM_AMD_DC_DCN like previous DCN IPs. Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-22drm/radeon: delete useless function return values & remove meaningless if(r) ↵Bernard Zhao16-48/+16
check code Function radeon_fence_driver_init always returns success, the function type maybe coule be changed to void. This patch first delete the check of the return value of the function call radeon_fence_driver_init, then, optimise the function declaration and function to void type. Reviewed-by: Christian König <[email protected]> Signed-off-by: Bernard Zhao <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-22drm/amd/display: 3.2.141Aric Cyr1-1/+1
Signed-off-by: Aric Cyr <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-22drm/amd/display: [FW Promotion] Release 0.0.71Anthony Koo1-2/+88
- Introduce CMD for EDID CEA block parsing - Add SCR5 definition for reporting eDP power sequencer status Signed-off-by: Anthony Koo <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-22drm/amd/display: do not compare integers of different widthsJosip Pavic2-3/+3
[Why & How] Increase width of some variables to avoid comparing integers of different widths Signed-off-by: Josip Pavic <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-22drm/amd/display: Revert "Guard ASSR with internal display flag"Stylon Wang1-41/+17
This reverts commit 9127daa0a8d88a6e6452eb8b7c9be4c3f42a867e. [Why] 1. Previous patch regresses on some embedded panels. 2. Project coreboot doesn't support passing of internal display flag. [How] This reverts "Guard ASSR with internal display flag" commit. Fixes: 9127daa0a8d88a ("drm/amd/display: Guard ASSR with internal display flag") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1620 Signed-off-by: Stylon Wang <[email protected]> Reviewed-by: Wesley Chalmers <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-06-22drm/kmb: Fix error return code in kmb_hw_init()Zhen Lei1-0/+1
When the call to platform_get_irq() to obtain the IRQ of the lcd fails, the returned error code should be propagated. However, we currently do not explicitly assign this error code to 'ret'. As a result, 0 was incorrectly returned. Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zhen Lei <[email protected]> Signed-off-by: Anitha Chrisanthus <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-22drm/amdgpu: wait for moving fence after pinningChristian König1-1/+13
We actually need to wait for the moving fence after pinning the BO to make sure that the pin is completed. Signed-off-by: Christian König <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> References: https://lore.kernel.org/dri-devel/[email protected]/ CC: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-22drm/radeon: wait for moving fence after pinningChristian König1-3/+13
We actually need to wait for the moving fence after pinning the BO to make sure that the pin is completed. Signed-off-by: Christian König <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> References: https://lore.kernel.org/dri-devel/[email protected]/ CC: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-22drm/nouveau: wait for moving fence after pinning v2Christian König1-1/+16
We actually need to wait for the moving fence after pinning the BO to make sure that the pin is completed. v2: grab the lock while waiting Signed-off-by: Christian König <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> References: https://lore.kernel.org/dri-devel/[email protected]/ CC: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-22Revert "drm: add a locked version of drm_is_current_master"Daniel Vetter1-32/+19
This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f. Unfortunately this inverts the locking hierarchy, so back to the drawing board. Full lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted ------------------------------------------------------ kms_frontbuffer/1087 is trying to acquire lock: ffff88810dcd01a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1b/0x40 but task is already holding lock: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dev->mode_config.mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_probe+0x22e/0xca0 __drm_fb_helper_initial_config_and_unlock+0x42/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #1 (&client->modeset_mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_commit_locked+0x1c/0x180 drm_client_modeset_commit+0x1c/0x40 __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0 drm_fb_helper_set_par+0x34/0x40 intel_fbdev_set_par+0x11/0x40 [i915] fbcon_init+0x270/0x4f0 visual_init+0xc6/0x130 do_bind_con_driver+0x1e5/0x2d0 do_take_over_console+0x10e/0x180 do_fbcon_takeover+0x53/0xb0 register_framebuffer+0x22d/0x310 __drm_fb_helper_initial_config_and_unlock+0x36c/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #0 (&dev->master_mutex){+.+.}-{3:3}: __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &dev->master_mutex --> &client->modeset_mutex --> &dev->mode_config.mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->mode_config.mutex); lock(&client->modeset_mutex); lock(&dev->mode_config.mutex); lock(&dev->master_mutex); *** DEADLOCK *** 1 lock held by kms_frontbuffer/1087: #0: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 stack backtrace: CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 5.13.0-rc7-CI-CI_DRM_10254+ #1 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 Call Trace: dump_stack+0x7f/0xad check_noncircular+0x12e/0x150 __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Note that this broke the intel-gfx CI pretty much across the board because it has to reboot machines after it hits a lockdep splat. Testcase: igt/debugfs_test/read_all_entries Acked-by: Petri Latvala <[email protected]> Fixes: 1815d9c86e30 ("drm: add a locked version of drm_is_current_master") Cc: Desmond Cheong Zhi Xi <[email protected]> Cc: Emil Velikov <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-21drm/amd/display: Fix edp_bootup_bl_level initialization issueLogush Oliver1-1/+1
[why] Updating the file to fix the missing line Signed-off-by: Logush Oliver <[email protected]> Reviewed-by: Charlene Liu <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21drm/amd/display: get refclk from MICROSECOND_TIME_BASE_DIV HW registerCharlene Liu2-3/+13
[why] recent VBIOS dce_infotable reference clock change caused a I2c regression. instead of relying on vbios, let's get it from HW directly. Signed-off-by: Charlene Liu <[email protected]> Reviewed-by: Chris Park <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21drm/amd/display: Delay PSR entryRoman Li3-1/+14
[Why] After panel power up, if PSR entry attempted too early, PSR state may get stuck in transition. This could happen if the panel is not ready to respond to the SDP PSR entry message. In this case dmub f/w is unable to abort PSR entry since abortion is not permitted after the SDP has been sent. [How] Skip 5 pageflips before PSR enable. Signed-off-by: Roman Li <[email protected]> Reviewed-by: Hersen Wu <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21drm/amd/display: get socBB from VBIOS for dcn302 and dcn303Aurabindo Pillai2-0/+40
[why] Some SOC BB paramters may vary per SKU, and it does not make sense for driver to hardcode these values. This change was added for dcn30 and dcn301, but not for dcn302 and dcn303 [how] Parse the values from VBIOS if available, and use them if valid Fixes: 93669c8e480dca ("drm/amd/display: get socBB from VBIOS") Signed-off-by: Aurabindo Pillai <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21drm/amd/display: Fix incorrect variable nameWesley Chalmers1-1/+1
[WHY] extended_end_address can only be calculated from the extended_address and extended_size Signed-off-by: Wesley Chalmers <[email protected]> Reviewed-by: Ashley Thomas <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21drm/amd/display: Clear lane settings after LTTPRs have been trainedMartin Tsai1-0/+4
[Why] The voltage swing has to start from the minimum level when transmit TPS1 over Main-Link in clock recovery sequence. The lane settings from current design will inherit the existing VS/PE values that could be adjusted by Repeater X, and to use the adjusted voltage swing level in Repeater X-1 or DPRX could violate DP specs. [How] To reset VS from lane settings after LTTPRs have been trained to meet the requirement. Signed-off-by: Martin Tsai <[email protected]> Reviewed-by: Wenjing Liu <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21drm/amd/display: Clamp VStartup value at DML calculations timeNikola Cornij1-0/+4
[why] Some timings with a large VBlank cause the value to overflow the register related, while also producing other wrong values in DML output. [how] Clamp VStartup at the DCN3.1 maximum value Signed-off-by: Nikola Cornij <[email protected]> Reviewed-by: Dmytro Laktyushkin <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21drm/amd/display: Multiplane cursor position incorrect when plane rotatedAric Cyr1-4/+11
[Why] When video plane is rotate the cursor position is incorrect and not matching the desktop location. [How] When a plane is rotated 90 or 270 degrees, the src_rect.width and height should be swapped when determining the scaling factor compared to the dst_rect. Signed-off-by: Aric Cyr <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Bindu Ramamurthy <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21Revert "drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue."Yifan Zhang1-5/+1
This reverts commit 631003101c516ea29a74aee59666708857b9a805. Reason for revert: side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases. Signed-off-by: Yifan Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21Revert "drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to cover full ↵Yifan Zhang1-5/+1
doorbell." This reverts commit 1ba7b24ba68e7c04b1e67d986d02b966b4eaaaa0. Reason for revert: Side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases. Signed-off-by: Yifan Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICEJason Gunthorpe1-1/+1
For some reason the vfio_mdev shim mdev_driver has its own module and kconfig. As the next patch requires access to it from mdev.ko merge the two modules together and remove VFIO_MDEV_DEVICE. A later patch deletes this driver entirely. Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Kirti Wankhede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]>
2021-06-21Revert "drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue."Yifan Zhang1-5/+1
This reverts commit 4cbbe34807938e6e494e535a68d5ff64edac3f20. Reason for revert: side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases. Signed-off-by: Yifan Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-06-21Revert "drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to cover full ↵Yifan Zhang1-5/+1
doorbell." This reverts commit 1c0b0efd148d5b24c4932ddb3fa03c8edd6097b3. Reason for revert: Side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases. Signed-off-by: Yifan Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-06-21drm/amdgpu: Call drm_framebuffer_init last for framebuffer initMichel Dänzer1-5/+7
Once drm_framebuffer_init has returned 0, the framebuffer is hooked up to the reference counting machinery and can no longer be destroyed with a simple kfree. Therefore, it must be called last. If drm_framebuffer_init returns 0 but its caller then returns non-0, there will likely be memory corruption fireworks down the road. The following lead me to this fix: [ 12.891228] kernel BUG at lib/list_debug.c:25! [...] [ 12.891263] RIP: 0010:__list_add_valid+0x4b/0x70 [...] [ 12.891324] Call Trace: [ 12.891330] drm_framebuffer_init+0xb5/0x100 [drm] [ 12.891378] amdgpu_display_gem_fb_verify_and_init+0x47/0x120 [amdgpu] [ 12.891592] ? amdgpu_display_user_framebuffer_create+0x10d/0x1f0 [amdgpu] [ 12.891794] amdgpu_display_user_framebuffer_create+0x126/0x1f0 [amdgpu] [ 12.891995] drm_internal_framebuffer_create+0x378/0x3f0 [drm] [ 12.892036] ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm] [ 12.892075] drm_mode_addfb2+0x34/0xd0 [drm] [ 12.892115] ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm] [ 12.892153] drm_ioctl_kernel+0xe2/0x150 [drm] [ 12.892193] drm_ioctl+0x3da/0x460 [drm] [ 12.892232] ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm] [ 12.892274] amdgpu_drm_ioctl+0x43/0x80 [amdgpu] [ 12.892475] __se_sys_ioctl+0x72/0xc0 [ 12.892483] do_syscall_64+0x33/0x40 [ 12.892491] entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: f258907fdd835e "drm/amdgpu: Verify bo size can fit framebuffer size on init." Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-21drm: add a locked version of drm_is_current_masterDesmond Cheong Zhi Xi1-19/+32
While checking the master status of the DRM file in drm_is_current_master(), the device's master mutex should be held. Without the mutex, the pointer fpriv->master may be freed concurrently by another process calling drm_setmaster_ioctl(). This could lead to use-after-free errors when the pointer is subsequently dereferenced in drm_lease_owner(). The callers of drm_is_current_master() from drm_auth.c hold the device's master mutex, but external callers do not. Hence, we implement drm_is_current_master_locked() to be used within drm_auth.c, and modify drm_is_current_master() to grab the device's master mutex before checking the master status. Reported-by: Daniel Vetter <[email protected]> Signed-off-by: Desmond Cheong Zhi Xi <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-21drm/amdgpu: fix amdgpu_preempt_mgr_new()Dan Carpenter1-1/+1
There is a reversed if statement in amdgpu_preempt_mgr_new() so it always returns -ENOMEM. Fixes: 09b020bb05a5 ("Merge tag 'drm-misc-next-2021-06-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-next") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/YMxbQXg/Wqm0ACxt@mwanda Signed-off-by: Christian König <[email protected]>
2021-06-19drm/atmel-hlcdc: Allow async page flipsDan Sneddon1-0/+1
The driver is capable of doing async page flips so we need to tell the core to allow them. Signed-off-by: Dan Sneddon <[email protected]> Tested-by: Ludovic Desroches <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-19drm/panel: ld9040: reference spi_device_id tableKrzysztof Kozlowski1-0/+1
Reference the spi_device_id table to silence W=1 warning: drivers/gpu/drm/panel/panel-samsung-ld9040.c:377:35: warning: ‘ld9040_ids’ defined but not used [-Wunused-const-variable=] This also would be needed for matching the driver if booted without CONFIG_OF (although it's not necessarily real case). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-19drm: atmel_hlcdc: Enable the crtc vblank prior to crtc usage.Dan Sneddon1-7/+10
'commit eec44d44a3d2 ("drm/atmel: Use drm_atomic_helper_commit")' removed the home-grown handling of atomic commits and exposed an issue in the crtc atomic commit handling where vblank is expected to be enabled but hasn't yet, causing kernel warnings during boot. This patch cleans up the crtc vblank handling thus removing the warning on boot. Fixes: eec44d44a3d2 ("drm/atmel: Use drm_atomic_helper_commit") Signed-off-by: Dan Sneddon <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-06-18drm/amdgpu: Call drm_framebuffer_init last for framebuffer initMichel Dänzer1-5/+7
Once drm_framebuffer_init has returned 0, the framebuffer is hooked up to the reference counting machinery and can no longer be destroyed with a simple kfree. Therefore, it must be called last. If drm_framebuffer_init returns 0 but its caller then returns non-0, there will likely be memory corruption fireworks down the road. The following lead me to this fix: [ 12.891228] kernel BUG at lib/list_debug.c:25! [...] [ 12.891263] RIP: 0010:__list_add_valid+0x4b/0x70 [...] [ 12.891324] Call Trace: [ 12.891330] drm_framebuffer_init+0xb5/0x100 [drm] [ 12.891378] amdgpu_display_gem_fb_verify_and_init+0x47/0x120 [amdgpu] [ 12.891592] ? amdgpu_display_user_framebuffer_create+0x10d/0x1f0 [amdgpu] [ 12.891794] amdgpu_display_user_framebuffer_create+0x126/0x1f0 [amdgpu] [ 12.891995] drm_internal_framebuffer_create+0x378/0x3f0 [drm] [ 12.892036] ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm] [ 12.892075] drm_mode_addfb2+0x34/0xd0 [drm] [ 12.892115] ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm] [ 12.892153] drm_ioctl_kernel+0xe2/0x150 [drm] [ 12.892193] drm_ioctl+0x3da/0x460 [drm] [ 12.892232] ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm] [ 12.892274] amdgpu_drm_ioctl+0x43/0x80 [amdgpu] [ 12.892475] __se_sys_ioctl+0x72/0xc0 [ 12.892483] do_syscall_64+0x33/0x40 [ 12.892491] entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: f258907fdd835e "drm/amdgpu: Verify bo size can fit framebuffer size on init." Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-18drm/display: Fix duplicated argumentWan Jiabing1-1/+1
Fix coccicheck warning: ./drivers/gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c: 55:12-42: duplicated argument to && or || Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Wan Jiabing <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-18drm/amd/display: Remove the repeated dpp1_full_bypass declarationShaokun Zhang1-2/+0
Function 'dpp1_full_bypass' is declared twice, so remove the repeated declaration and unnessary blank line. Cc: Harry Wentland <[email protected]> Cc: Leo Li <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Shaokun Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-06-18drm/amd/display: Fix fall-through warning for ClangGustavo A. R. Silva1-1/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix the following warning by replacing a /* fall through */ comment with the new pseudo-keyword macro fallthrough: rivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:672:4: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case AUX_TRANSACTION_REPLY_I2C_OVER_AUX_DEFER: ^ Notice that Clang doesn't recognize /* fall through */ comments as implicit fall-through markings, so in order to globally enable -Wimplicit-fallthrough for Clang, these comments need to be replaced with fallthrough; in the whole codebase. Link: https://github.com/KSPP/linux/issues/115 Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.