summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2023-08-07drm/i915/bdw: s/BDW/BROADWELL for platform/subplatform definesDnyaneshwar Bhadane
Follow consistent naming convention. Replace BDW with BROADWELL. Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801135344.3797924-3-dnyaneshwar.bhadane@intel.com
2023-08-07drm/i915/hsw: s/HSW/HASWELL for platform/subplatform definesDnyaneshwar Bhadane
Follow consistent naming convention. Replace HSW with HASWELL. Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801135344.3797924-2-dnyaneshwar.bhadane@intel.com
2023-08-07drm/msm: Disallow relocs on a6xx+Rob Clark
Mesa stopped using these pretty early in a6xx bringup[1]. Take advantage of this to disallow some legacy UABI. [1] https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ef722861b691ce99be3827ed05f8c0ddf2cd66e Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Patchwork: https://patchwork.freedesktop.org/patch/551175/
2023-08-07drm/msm/a6xx: Fix GMU lockdep splatRob Clark
For normal GPU devfreq, we need to acquire the GMU lock while already holding devfreq locks. But in the teardown path, we were calling dev_pm_domain_detach() while already holding the GMU lock, resulting in this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.4.3-debug+ #3 Not tainted ------------------------------------------------------ ring0/391 is trying to acquire lock: ffffff80a025c078 (&devfreq->lock){+.+.}-{3:3}, at: qos_notifier_call+0x30/0x74 but task is already holding lock: ffffff809b8c1ce8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0x78 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&(c->notifiers)->rwsem){++++}-{3:3}: down_write+0x58/0x74 __blocking_notifier_chain_register+0x64/0x84 blocking_notifier_chain_register+0x1c/0x28 freq_qos_add_notifier+0x5c/0x7c dev_pm_qos_add_notifier+0xd4/0xf0 devfreq_add_device+0x42c/0x560 devm_devfreq_add_device+0x6c/0xb8 msm_devfreq_init+0xa8/0x16c [msm] msm_gpu_init+0x368/0x54c [msm] adreno_gpu_init+0x248/0x2b0 [msm] a6xx_gpu_init+0x2d0/0x384 [msm] adreno_bind+0x264/0x2bc [msm] component_bind_all+0x124/0x1f4 msm_drm_bind+0x2d0/0x5f4 [msm] try_to_bring_up_aggregate_device+0x88/0x1a4 __component_add+0xd4/0x128 component_add+0x1c/0x28 dp_display_probe+0x37c/0x3c0 [msm] platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 deferred_probe_work_func+0xb0/0xc8 process_one_work+0x288/0x3d8 worker_thread+0x1f0/0x260 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 -> #3 (dev_pm_qos_mtx){+.+.}-{3:3}: __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 dev_pm_qos_remove_notifier+0x3c/0xc8 genpd_remove_device+0x40/0x11c genpd_dev_pm_detach+0x88/0x130 dev_pm_domain_detach+0x2c/0x3c a6xx_gmu_remove+0x44/0xdc [msm] a6xx_destroy+0x7c/0xa4 [msm] adreno_unbind+0x50/0x64 [msm] component_unbind+0x44/0x64 component_unbind_all+0xb4/0xbc msm_drm_uninit.isra.0+0x124/0x17c [msm] msm_drm_bind+0x340/0x5f4 [msm] try_to_bring_up_aggregate_device+0x88/0x1a4 __component_add+0xd4/0x128 component_add+0x1c/0x28 dp_display_probe+0x37c/0x3c0 [msm] platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 deferred_probe_work_func+0xb0/0xc8 process_one_work+0x288/0x3d8 worker_thread+0x1f0/0x260 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 -> #2 (&a6xx_gpu->gmu.lock){+.+.}-{3:3}: __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 a6xx_gpu_set_freq+0x38/0x64 [msm] msm_devfreq_target+0x170/0x18c [msm] devfreq_set_target+0x90/0x1e4 devfreq_update_target+0xb4/0xf0 update_devfreq+0x1c/0x28 devfreq_monitor+0x3c/0x10c process_one_work+0x288/0x3d8 worker_thread+0x1f0/0x260 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 -> #1 (&df->lock){+.+.}-{3:3}: __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 msm_devfreq_get_dev_status+0x4c/0x104 [msm] devfreq_simple_ondemand_func+0x5c/0x128 devfreq_update_target+0x68/0xf0 update_devfreq+0x1c/0x28 devfreq_monitor+0x3c/0x10c process_one_work+0x288/0x3d8 worker_thread+0x1f0/0x260 kthread+0xf0/0x100 ret_from_fork+0x10/0x20 -> #0 (&devfreq->lock){+.+.}-{3:3}: __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 qos_notifier_call+0x30/0x74 qos_min_notifier_call+0x1c/0x28 notifier_call_chain+0xf4/0x114 blocking_notifier_call_chain+0x4c/0x78 pm_qos_update_target+0x184/0x190 freq_qos_apply+0x4c/0x64 apply_constraint+0xf8/0xfc __dev_pm_qos_update_request+0x138/0x164 dev_pm_qos_update_request+0x44/0x68 msm_devfreq_boost+0x40/0x70 [msm] msm_devfreq_active+0xc0/0xf0 [msm] msm_gpu_submit+0xc8/0x12c [msm] msm_job_run+0x88/0x128 [msm] drm_sched_main+0x240/0x324 [gpu_sched] kthread+0xf0/0x100 ret_from_fork+0x10/0x20 other info that might help us debug this: Chain exists of: &devfreq->lock --> dev_pm_qos_mtx --> &(c->notifiers)->rwsem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(&(c->notifiers)->rwsem); lock(dev_pm_qos_mtx); lock(&(c->notifiers)->rwsem); lock(&devfreq->lock); *** DEADLOCK *** 4 locks held by ring0/391: #0: ffffff809c811170 (&gpu->lock){+.+.}-{3:3}, at: msm_job_run+0x7c/0x128 [msm] #1: ffffff809c811208 (&gpu->active_lock){+.+.}-{3:3}, at: msm_gpu_submit+0xa8/0x12c [msm] #2: ffffffecbbb46600 (dev_pm_qos_mtx){+.+.}-{3:3}, at: dev_pm_qos_update_request+0x38/0x68 #3: ffffff809b8c1ce8 (&(c->notifiers)->rwsem){++++}-{3:3}, at: blocking_notifier_call_chain+0x34/0x78 stack backtrace: CPU: 6 PID: 391 Comm: ring0 Not tainted 6.4.3debug+ #3 Hardware name: Google Villager (rev1+) with LTE (DT) Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 __mutex_lock+0xc8/0x388 mutex_lock_nested+0x2c/0x38 qos_notifier_call+0x30/0x74 qos_min_notifier_call+0x1c/0x28 notifier_call_chain+0xf4/0x114 blocking_notifier_call_chain+0x4c/0x78 pm_qos_update_target+0x184/0x190 freq_qos_apply+0x4c/0x64 apply_constraint+0xf8/0xfc __dev_pm_qos_update_request+0x138/0x164 dev_pm_qos_update_request+0x44/0x68 msm_devfreq_boost+0x40/0x70 [msm] msm_devfreq_active+0xc0/0xf0 [msm] msm_gpu_submit+0xc8/0x12c [msm] msm_job_run+0x88/0x128 [msm] drm_sched_main+0x240/0x324 [gpu_sched] kthread+0xf0/0x100 ret_from_fork+0x10/0x20 Fix this by only synchronizing access to gmu->initialized. Fixes: 4cd15a3e8b36 ("drm/msm/a6xx: Make GPU destroy a bit safer") Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/551171/
2023-08-07drm/msm/a2xx: Call adreno_gpu_init() earlierFabio Estevam
The adreno_is_a20x() and adreno_is_a225() functions rely on the GPU revision, but such information is retrieved inside adreno_gpu_init(), which is called afterwards. Fix this problem by caling adreno_gpu_init() earlier, so that the GPU information revision is available when adreno_is_a20x() and adreno_is_a225() run. Tested on a imx53-qsb board. Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx") Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543456/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-08-07drm/msm/a6xx: Fix up GMU region reservationsKonrad Dybcio
Change the order of region allocations to make the addresses match downstream. This shouldn't matter very much, but helps eliminate one more difference when comparing register accesses. Also, make the log region 16K long. That's what it is, unconditionally on A6xx and A7xx. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543338/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-08-07drm/msm/a6xx: Improve GMU force shutdown sequenceKonrad Dybcio
The GMU force shutdown sequence involves some additional register cleanup which was not implemented previously. Do so. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543340/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-08-07drm/msm/a6xx: Ensure clean GMU state in a6xx_gmu_fw_startKonrad Dybcio
While it's not very well understood, there is some sort of a fault handler implemented in the GMU firmware which triggers when a certain bit is set, resulting in the M3 core not booting up the way we expect it to. Write a magic value to a magic register to hopefully prevent that from happening. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543335/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-08-07drm/msm/a6xx: Skip empty protection ranges entriesKonrad Dybcio
Some specific SKUs leave certain protection range registers empty. Allow for that behavior. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543334/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-08-07drm/msm/a6xx: Use descriptive bitfield names for CP_PROTECT_CNTLKonrad Dybcio
We have the necessary information, so explain which bit does what. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543332/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-08-07drm/msm/a6xx: Add some missing header definitionsKonrad Dybcio
Add a definition of the GMU_AHB_FENCE_STATUS_CLR reg and CP_PROTECT_CNTL bitfields. This may be substituted with a mesa header sync. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543330/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-08-07drm/msm/a6xx: Fix misleading commentRob Clark
The range is actually len+1. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/545099/
2023-08-07drm/msm/adreno: Switch to chip-id for identifying GPURob Clark
Since the revision becomes an opaque identifier with future GPUs, move away from treating different ranges of bits as having a given meaning. This means that we need to explicitly list different patch revisions in the device table. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549782/
2023-08-07drm/msm/adreno: Move adreno info to configRob Clark
Let's just stash it in adreno_platform_config rather than looking it up in N different places. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549777/
2023-08-07drm/msm/adreno: Add helper for formating chip-idRob Clark
This is used in a few places, including one that is parsed by userspace tools. So let's standardize it a bit better. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549774/
2023-08-07drm/msm/adreno: Add adreno familyRob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in any case, this helps us get away from infering the generation from the numerical chip-id. v2: Fix is_a2xx() typo Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549773/
2023-08-07drm/msm/adreno: Bring the a630 family togetherRob Clark
All of these are derivatives of a630. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549770/
2023-08-07drm/msm/adreno: Move speedbin mapping to device tableRob Clark
This simplifies the code. v2: Use a table of structs instead of flat uint32_t[] Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549769/
2023-08-07drm/msm/adreno: Allow SoC specific gpu device table entriesRob Clark
There are cases where there are differences due to SoC integration. Such as cache-coherency support, and (in the next patch) e-fuse to speedbin mappings. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549767/
2023-08-07drm/msm/adreno: Use quirk to identify cached-coherent supportRob Clark
It is better to explicitly list it. With the move to opaque chip-id's for future devices, we should avoid trying to infer things like generation from the numerical value. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549765/
2023-08-07drm/msm/adreno: Use quirk identify hw_aprivRob Clark
Rather than just open coding a list of gpu-id matches. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549764/
2023-08-07drm/msm/adreno: Remove redundant revn paramRob Clark
This just duplicates what is in adreno_info, and can cause confusion if used before it is set. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549761/
2023-08-07drm/msm/adreno: Remove redundant gmem size paramRob Clark
Even in the ocmem case, the allocated ocmem buffer size should match the requested size. v2: Move stray hunk to previous patch, make OCMEM size mismatch an error condition. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549759/
2023-08-07drm/msm/adreno: Remove GPU nameRob Clark
No real need to have marketing names in the kernel. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/549757/
2023-08-07Merge drm/drm-next into drm-intel-nextRodrigo Vivi
Catching-up with drm-next and drm-intel-gt-next. It will unblock a code refactor around the platform definitions (names vs acronyms). Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-08-07drm/amdgpu: Report vbios version instead of PNLijo Lazar
Report VBIOS version in vbios_version sysfs node instead of part number. Part number remains constant for a SKU type. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Promote DAL to 3.2.246Martin Leung
This version brings along following fixes: - Fix a regression in blank pixel data caused by coding mistake - Fix a bug when searching for insert_above_mpcc - Update add plane to context logic with a new algorithm - Adjust visual confirm dpp height offset to be 1/240 of v addressable - Add interface to enable DPIA trace - Support plane clip with zero recout size - Blocking invalid 420 modes on HDMI TMDS for DCN31 and DCN314 - Make mpc32 functions available to future DCNs - Change HDCP update sequence for DM Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Martin Leung <martin.leung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Change HDCP update sequence for DMBhawanpreet Lakha
Refactor the sequence in hdcp_update_display() to use mod_hdcp_update_display(). Previous sequence: - remove()->add() This Sequence was used to update the display, (mod_hdcp_update_display didn't exist at the time). This meant for any hdcp updates (type changes, enable/disable) we would remove, reconstruct, and add. This leads to unnecessary calls to psp eventually New Sequence using mod_hdcp_update_display(): - add() once when stream is enabled - use update() for all updates The update function checks for prev == new states and will not unnecessarily end up calling psp via add/remove. Reviewed-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: rename acquire_idle_pipe_for_layer to ↵Wenjing Liu
acquire_free_pipe_as_sec_dpp_pipe [why] Secondary DPP pipes are used for rendering secondary layers of planes. The name "for layer" doesn't make it obvious. The function is acquiring a free pipe as secondary dpp pipe only. We rename it so it is more obvious. In a future follow up change, we want to add functions to acquire free pipe as opp head pipe or otg master pipe as well. They will have their separate allocation priority. Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: move idle pipe allocation logic into dcn specific layerWenjing Liu
[why] generic dc resource file should not know what an optimal idle pipe is because this is dcn hardware dependent. [how] We move the optimial pipe searching logic in dcn specific layer. Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Use max memclk variable when setting max memclkAlvin Lee
[Description] In overclocking scenarios the max memclk could be higher than the DC mode limit. However, for configs that don't support MCLK switching we need to set the max memclk to the overclocked max instead of the DC mode max or we could result in underflow. Reviewed-by: Samson Tam <samson.tam@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Alvin Lee <alvin.lee2@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Add vendor Id for referenceMike Hsieh
Add a new vendor ID code for reference Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Mike Hsieh <mike.hsieh@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Blocking invalid 420 modes on HDMI TMDS for DCN314Leo Chen
[Why & How] HDMI TMDS does not have ODM support. Filtering 420 modes that exceed the 4096 FMT limitation on DCN314 will resolve intermittent corruptions issues. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Leo Chen <sancchen@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Blocking invalid 420 modes on HDMI TMDS for DCN31Leo Chen
[Why & How] HDMI TMDS does not have ODM support. Filtering 420 modes that exceed the 4096 FMT limitation on DCN31 will resolve intermittent corruptions issues. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Leo Chen <sancchen@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Revert "drm/amd/display: Read down-spread percentage from ↵Leo Chen
lut to adjust dprefclk." [Why & How] Revert commit 6917b0b71171 ("drm/amd/display: Read down-spread percentage from lut to adjust dprefclk.") This change was causing 240hz display to not light up after s0i3. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Leo Chen <sancchen@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: do not treat clip_rect size change as a scaling changeWenjing Liu
[why] With previous ODM + MPO policy we will only allocate pipes when MPO plane has intersection with current ODM slice. With this policy we have to indicate scaling change when plane clip is updated in case plane clip change causes MPO plane to go in or out current ODM slice. With new ODM + MPO policy we allocate pipe independent from plane clip size so we no longer treat it as a scaling change. There no need to do a full update due to clip size change anymore. Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: adjust visual confirm dpp height offset to be 1/240 of v ↵Wenjing Liu
addressable [why] For timing with large v addressable visual confirm is just too small. It is difficult to tell visually which DPP we are using. On the other hand with timing with small v addressable visual confirm is too large and covers the UI area. [how] We calculate visual confirm dpp height offset based on v addressable so it stays relatively the same height i.e. 1/240 verticle portion of the screen. Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: update add plane to context logic with a new algorithmWenjing Liu
[why] Preivous algorithm for finding an optimal idle pipe for a new plane was implemented to handle dynamic pipe allocation when MPO plane moves from one ODM slice to the other. Now pipe allocation is more static so it no longer depends on the MPO plane's position. We are simplifying our logic and remove unnecessary handling in our code. [how] Apply a new simplified version of pipe resource allocation logic to reduce unnecessary flip delay caused by swapping secondary dpp pipe to other MPC blending tree. Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: always acquire MPO pipe for every blending treeWenjing Liu
[why] We only acquire MPO pipe for blending tree where the plane clip will be rendered. If an MPO plane is outside current ODM slice rect, we will skip pipe allocation. With new programming policy we want to allocate pipes for every ODM slice blending tree even for those whose ODM slice rect doesn't intersect with plane clip. This is aligned with DML validation so the pipe topology is programmed independently from the plane's position and dst plane size. [how] - Remove the logic to allocate pipe only when the MPO plane intersects with ODM slice and replace with the new logic to always allocate pipes. - Remove the logic to tear down ODM configuration in favor for supporting secondary MPO planes. - Remove the logic to use full update when MPO goes accross ODM slice boundary. Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: support plane clip with zero recout sizeWenjing Liu
[why] If plane clip is outside current pipe's ODM slice rect, our logic will fail validation because we assume that when a pipe is acquired to support a plane clip, it must blend some portion of the plane on the screen. This assumption needs to be changed. When a pipe is acquired to render the plane, we are now allowing it to support a case where it can take minimum viewport and draw with zero recout size when the plane clip is outside current ODM slice rect. The reason is that we want to allocate and get the pipe pre-programmed so it is ready to be rendered when user moves the plane over to the current ODM slice with a fast update. Whereas with the existing solution when user moves the plane over, we will need to allocate a pipe as needed and power it up and program it through a full update. This not only impacts the user experience with unnecessary delay of a frame but also doesn't generate any benefit to the user because DML doesn't support it. DML will invalidate based on worst case scenario and it doesn't depend on the plane location. So having our programming sequence support such dynamic pipe allocation is not meaningful anyway. [how] In build scaler params allow recout to be zero size and if viewport is smaller than minimum, set minimum viewport size. Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Use DTBCLK as refclk instead of DPREFCLKAustin Zheng
[Why] Flash of corruption observed when UCLK switching after transitioning from DTBCLK to DPREFCLK on subVP(DP) + subVP(HDMI) config Scenario where DPREFCLK is required instead of DTBCLK is not expected [How] Always set the DTBCLK source as DTBCLK0 Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Austin Zheng <austin.zheng@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Set Stream Update Flags in commit_state_no_checkAustin Zheng
[Why] Front-end would be programmed using the stream update flags set from the previous update and the full update should be triggered whenever commit_state_no_check gets called. [How] Set all stream update flags before programming the front-end Clear all flags that got set to avoid redundant programming Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Austin Zheng <austin.zheng@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Make mpc32 functions available to future DCNsWesley Chalmers
Make the mpc32 functions available for future DCNs to use Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wesley Chalmers <wesley.chalmers@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Fix a bug when searching for insert_above_mpccWesley Chalmers
[WHY] Currently, when insert_plane is called with insert_above_mpcc parameter that is equal to tree->opp_list, the function returns NULL. [HOW] Instead, the function should insert the plane at the top of the tree. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wesley Chalmers <wesley.chalmers@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Enable DPIA trace with DC debug maskStylon Wang
[Why] DPIA traces from DMUB is not enabled by default, which is less convenient to debug DPIA related issues because we have to resort to other means to enable DPIA trace. [How] Reuse existing DC debug mask to enable DPIA trace log from kernel command line. This makes debugging DPIA issues easier especially when system power state (suspend/reboot) is involved. To turn on DPIA trace, simply add "amdgpu.dcdebugmask=0x80" to kernel command line. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Stylon Wang <stylon.wang@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: Add interface to enable DPIA traceStylon Wang
[Why] DPIA traces from DMUB is not enabled by default, which is less convenient to debug DPIA related issues because we have to resort to other debug tools to enable DPIA trace. [How] Exposes interfaces to update trace mask from the DMUB GPINT commands. Also provides DC implementations to enable DPIA trace. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Stylon Wang <stylon.wang@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amd/display: fix a regression in blank pixel data caused by coding mistakeWenjing Liu
[why] There was unfortunately a coding mistake. It gets caught with an ultrawide monitor that requires ODM 4:1 combine. We are blanking or unblanking pixel data we are supposed to enumerate through all ODM pipes and program DPG for each of those pipes. However the coding mistake causes us to program only the first and last ODM pipes. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Martin Leung <martin.leung@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amdgpu: cleanup MES process level doorbellsShashank Sharma
MES allocates process level doorbells, but there is no userspace client to consume it. It was only being used for the MES ring tests (in kernel), and was written by kernel doorbell write. The previous patch of this series has changed the MES ring test code to use kernel level MES doorbells. This patch now cleans up the process level doorbell allocation code which is not required. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian Koenig <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: Arvind Yadav <arvind.yadav@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amdgpu: use doorbell mgr for MES kernel doorbellsShashank Sharma
This patch: - Removes the existing doorbell management code, and its variables from the doorbell_init function, it will be done in doorbell manager now. - uses the doorbell page created for MES kernel level needs (doorbells for MES self tests) - current MES code was allocating MES doorbells in MES process context, but those were getting written using kernel doorbell calls. This patch instead allocates a MES kernel doorbell for this (in add_hw_queue). V2: Create an extra page of doorbells for MES during kernel doorbell creation (Alex) V4: Move MES doorbell size and page offset objects in this patch from patch 6. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian Koenig <christian.koenig@amd.com> Reviewed-by: Christian Koenig <christian.koenig@amd.com> Signed-off-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: Arvind Yadav <arvind.yadav@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-08-07drm/amdgpu: remove unused functions and variablesShashank Sharma
This patch removes some variables and functions from KFD doorbell handling code, which are no more required since doorbell manager is handling doorbell calculations. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Shashank Sharma <shashank.sharma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-21 23:23:47 +0000