summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-10-13drm/xe: Enable 2M pages in xe_migrate_vramMatthew Brost1-8/+45
Using 2M pages in xe_migrate_vram has two benefits: we issue fewer instructions per 2M copy (1 vs. 512), and the cache hit rate should be higher. This results in increased copy engine bandwidth, as shown by benchmark IGTs. Enable 2M pages by reserving PDEs in the migrate VM and using 2M pages in xe_migrate_vram if the DMA address order matches 2M. v2: - Reuse build_pt_update_batch_sram (Stuart) - Fix build_pt_update_batch_sram for PAGE_SIZE > 4K v3: - More fixes for PAGE_SIZE > 4K, align chunk, decrement chunk as needed - Use stack incr var in xe_migrate_vram_use_pde (Stuart) v4: - Split PAGE_SIZE > 4K fix out in different patch (Stuart) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20251013034555.4121168-3-matthew.brost@intel.com
2025-10-13drm/xe: Fix build_pt_update_batch_sram for non-4K PAGE_SIZEMatthew Brost1-8/+22
The build_pt_update_batch_sram function in the Xe migrate layer assumes PAGE_SIZE == XE_PAGE_SIZE (4K), which is not a valid assumption on non-x86 platforms. This patch updates build_pt_update_batch_sram to correctly handle PAGE_SIZE > 4K by programming multiple 4K GPU pages per CPU page. v5: - Mask off non-address bits during compare Signed-off-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Simon Richter <Simon.Richter@hogyros.de> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20251013034555.4121168-2-matthew.brost@intel.com
2025-10-13drm/xe: Fix comments in xe_gt structShuicheng Lin1-5/+5
Correct several spelling and grammar issues in xe_gt struct documentation to improve readability: - Fix "to not" -> "do not". - Fix "mmigrations" -> "migrations". - Fix "Multiple queues exists" -> "Multiple queues exist". - Fix "are be processed" -> "to be processed". - Fix "have being processed" -> "have been processed". These changes are purely cosmetic and do not affect functionality. v2: drop kernel-doc formatting change. (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251006151317.2553182-2-shuicheng.lin@intel.com
2025-10-13drm/i915/gem: fix typo in comment (I915_EXEC_NO_RELOC)Marlon Henrique Sanches1-1/+1
The comment referenced the flag name incorrectly as 'I915_EXEC_NORELOC' (missing underscore). This patch corrects the spelling in the comment only; there is no functional change. Signed-off-by: Marlon Henrique Sanches <marlonsanches@estudante.ufscar.br> Link: https://lore.kernel.org/r/20251013183123.438573-1-marlonsanches@estudante.ufscar.br Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-13drm/amd: Drop calls to restore power limit and clock from smu_resume()Mario Limonciello1-13/+0
User requested power limits and clock settings are already restored as part of smu_restore_dpm_user_profile(). It's unnecessary to call the same restore as part of smu_resume(). Revert the following commits to drop that extra restore: commit ed4efe426a49 ("drm/amd: Restore cached power limit during resume") commit 796ff8a7e01b ("drm/amd: Restore cached manual clock settings during resume") commit f9b80514a722 ("drm/amd: Only restore cached manual clock settings in restore if OD enabled") Suggested-by: Lijo Lazar <Lijo.Lazar@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: update remove after reset flag for MES remove queueJonathan Kim5-2/+13
Remove queue after reset flag is required to remove a queue that has been successfully reset to clean up the MES' internal state. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: Add ras module files into amdgpuYiPeng Chai11-18/+20
Add ras module files into amdgpu. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu/userqueue: validate userptrs for userqueuesSunil Khatri1-0/+79
userptrs could be changed by the user at any time and hence while locking all the bos before GPU start processing validate all the userptr bos. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: update the functions to use amdgpu version of hmmSunil Khatri13-44/+56
At times we need a bo reference for hmm and for that add a new struct amdgpu_hmm_range which will hold an optional bo member and hmm_range. Use amdgpu_hmm_range instead of hmm_range and let the bo as an optional argument for the caller if they want to the bo reference to be taken or they want to handle that explicitly. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: Reserve discovery TMR only if neededLijo Lazar3-14/+19
For legacy SOCs, discovery binary is sideloaded. Instead of checking for binary blob, use a flag to determine if discovery region needs to be reserved. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/pm: export a function amdgpu_smu_ras_send_msg to allow send msg directlyYiPeng Chai3-0/+41
provide a interface that allows ras client send msg to smu/pmfw directly. Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/pm: Grant interface access after full initLijo Lazar1-1/+2
Allow access to user interfaces like sysfs/hwmon only after full initialization of the device. When device is part of XGMI hive and a reset is required during initialization, the inteface files will be created as part of minimal device initialization. Full initialization of the device will be done only after all devices in XGMI hive are probed and a reset is done together on all. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: Move reset-on-init sequence earlierLijo Lazar1-3/+2
Complete reset-on-init sequence before sysfs interfaces are created. Devices get properly initiaized only after reset, and then only sysfs interfaces should be made available. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: Add amdgpu_discovery_infoLijo Lazar6-97/+129
Add amdgpu_discovery_info structure to keep all discovery related information. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: Reorganize sysfs ini/fini callsLijo Lazar1-37/+51
Aggregate sysfs ini/fini calls into separate functions. No functional change. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: clean up and unify hw fence handlingAlex Deucher8-167/+63
Decouple the amdgpu fence from the amdgpu_job structure. This lets us clean up the separate fence ops for the embedded fence and other fences. This also allows us to allocate the vm fence up front when we allocate the job. v2: Additional cleanup suggested by Christian v3: Additional cleanups suggested by Christian v4: Additional cleanups suggested by David and vm fence fix v5: cast seqno (David) Cc: David.Wu3@amd.com Cc: christian.koenig@amd.com Tested-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Reviewed-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Save and restore all limit typesMario Limonciello2-8/+14
Vangogh has separate limits for default PPT and fast PPT. Add infrastructure to save both of these limits and restore both of them. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Remove second call to set_power_limit()Mario Limonciello1-12/+9
The min/max limits only make sense for default PPT. Restructure smu_set_power_limit() to only use them in that case. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Stop overloading power limit with limit typeMario Limonciello7-13/+10
When passed around internally the upper 8 bits of power limit include the limit type. This is non-obvious without digging into the nuances of each function. Instead pass the limit type as an argument to all applicable layers. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu/userq: drop VCN and VPE doorbell handlingAlex Deucher1-11/+0
VCN and VPE userqs are not yet supported and this code is not correct. Userspace should provide the correct doorbell offset with in their doorbell page for the IP. Adjusting it here will not work as expected as userspace and the queue itself will have different offsets. We need to add a INFO IOCTL query to get the offset and range for each IP within the doorbell page to handle this properly. Cc: Saleemkhan Jamadar <saleemkhan.jamadar@amd.com> Reviewed-by: Saleemkhan Jamadar <saleemkhan.jamadar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Pass userq suspend failures up to callerMario Limonciello1-1/+3
If a userq failed to suspend the rest of the suspend sequence may have problems. Pass the error code up to the caller for a decision on what to do. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Fix error handling with multiple userq IDRsMario Limonciello1-14/+11
If multiple userq IDR are in use and there is an error handling one at suspend or resume it will be silently discarded. Switch the suspend/resume() code to use guards and return immediately. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Pass IP suspend errors up to callersMario Limonciello1-3/+8
If IP suspend fails the callers should be notified so that they can potentially react. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Don't always set IP block HW status to falseMario Limonciello1-1/+0
amdgpu_device_ip_suspend_phase2() calls amdgpu_ip_block_suspend() which already sets HW block status to false when succeeding with IP suspend. Remove the explicit call in amdgpu_device_ip_suspend_phase2() so that the status is accurate. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Remove comment about handling errors in ↵Mario Limonciello1-1/+0
amdgpu_device_ip_suspend_phase1() Error handling was introduced in commit e095026f0066 ("drm/amdgpu: validate suspend before function call") so the comment about TODO is no longer needed. Fixes: e095026f0066 ("drm/amdgpu: validate suspend before function call") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Stop exporting amdgpu_device_ip_suspend() outside amdgpu_deviceMario Limonciello2-2/+1
amdgpu_device_ip_suspend() doesn't have a caller outside of amdgpu_device.c. Make it static. No intended functional changes. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Unify shutdown() callback behaviorMario Limonciello1-1/+2
[Why] The shutdown() callback uses amdgpu_ip_suspend() which doesn't notify drm clients during shutdown. This could lead to hangs. [How] Change amdgpu_pci_shutdown() to call the same sequence as suspend/resume. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: validate userq va for GEM unmapPrike Liang3-0/+46
When a user unmaps a userq VA, the driver must ensure the queue has no in-flight jobs. If there is pending work, the kernel should wait for the attached eviction (bookkeeping) fence to signal before deleting the mapping. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: validate the queue va for resuming the queuePrike Liang1-0/+44
It requires validating the userq VA whether is mapped before trying to resume the queue. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: keeping waiting userq fence infinitelyPrike Liang1-4/+9
Keeping waiting the userq fence infinitely until hang detection, and then suspend the hang queue and set the fence error. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: track the userq bo va for its obj managementPrike Liang1-0/+36
Track the userq obj for its life time, and reference and dereference the buffer flag at its creating and destroying period. Suggested-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: add userq object va track helpersPrike Liang4-21/+52
Add the userq object virtual address list_add() helpers for tracking the userq obj va address usage. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: reduce queue timeout to 2 seconds v2Christian König2-58/+47
There has been multiple complains that 10 seconds are usually to long. The original requirement for longer timeout came from compute tests on AMDVLK, since that is no longer a topic reduce the timeout back to 2 seconds for all queues. While at it also remove any special handling for compute queues under SRIOV or pass through. v2: fix checkpatch warning. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Remove some unncessary header includesMario Limonciello1-3/+0
Unnecessary headers can slow down the build, drop em. No intended functional changes. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Tested-by: Robert Beckett <bob.beckett@collabora.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Adjust whitespace for vangogh_pptMario Limonciello1-7/+5
A few changes have more whitespace than needed. Clean them up. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Tested-by: Robert Beckett <bob.beckett@collabora.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu/mes: adjust the VMID masksAlex Deucher1-2/+2
The firmware limits the max vmid, but align the settings with the hw limits as well just to be safe. Reviewed-by: Shaoyun liu <Shaoyun.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: Skip SDMA suspend during mode-2 resetLijo Lazar1-0/+4
For SDMA IP versions >= v4.4.2, firmware will take care of quiescing SDMA before mode-2 reset. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: remove gart_window_lock usage from gmc v12Pierre-Eric Pelloux-Prayer1-2/+0
This lock was part of the SDMA workaround originally implemented in gmc_v10_0_flush_gpu_tlb (a70cb2176f7ef6f moved it to amdgpu_gmc_flush_gpu_tlb). This means this lock is useless and be safely dropped. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: make non-NULL out fence mandatoryPierre-Eric Pelloux-Prayer2-15/+8
amdgpu_ttm_copy_mem_to_mem has a single caller, make sure the out fence is non-NULL to simplify the code. Since none of the pointers should be NULL, we can enable __attribute__((nonnull))__. While at it make the function static since it's only used from amdgpuu_ttm.c. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: Remove redundant return valueLijo Lazar1-12/+6
gfx_v9_4_3_xcc_kcq_init_queue doesn't have a fail condition. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu/userq: extend userq statePrike Liang1-0/+1
Extend the userq state for identifying the userq invalid cases. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: Promote DC to 3.2.353Taimur Hassan1-1/+1
- [FW Promotion] Release 0.1.30.0 - Driver implementation for cursor offloading to DMU - Incorrect Mirror Cositing - Enable Dynamic DTBCLK Switch - Remove comparing uint32_t to zero - Remove inaccessible URL Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: [FW Promotion] Release 0.1.30.0Taimur Hassan1-0/+104
Add new SMART_POWER_HDR commands to optimize power consumption on certain OLED LED panels by sending MaxCLL per frame to TCON. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: Driver implementation for cursor offloading to DMUNicholas Kazlauskas25-79/+567
[Why] We require an interlock between driver and firmware for upcoming features and given that this could possibly happen on any single cursor programming call (and that we can't asynchronously wait for firmware to respond because of it) we'd be regressing cursor performance by at least an extra 40us per call. When we could possibly have cursor update every 20us - 100s from high frequency gaming mice this means that we'd be stuttering or dropping updates and impacting overall cursor performance. We want a solution that can: 1. Interlock between other firmware features 2. Not stall out or require the DMCUB lock for every single update [How] When cursor offloading is enabled and supported by an ASIC driver will route the cursor programming through to DMU as part of the regular DC stream cursor programming interfaces for attributes and position. The atomic pipe programming version will not be updated: this will still follow the existing programming path by keeping track of a field that specifies when the register writes should be deferred to DMU. Cursor locking is not required when cursor offload is in progress since the updates are consolidated and processed by DMU once at the end of the frame in a periodic manner. The shared buffer the firmware queries from is allocated along with the rest of the scratch state region in an area that's accessible by both firmware and driver. The size of the cursor offload (v1) state will not change, but it does have a unique union per ASIC version with room for expansion if needed. When firmware features notifying DMU of DRR updates are not enabled we now send an explicit vtotal min/max update via driver to DMU firmware whenever the vtotal max changes. This is to allow the cursor programming to determine the appropriate latch update point offset from vupdate. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: Remove comparing uint32_t to zeroAlex Hung2-8/+8
[WHAT] These *bypass are uint32_t and they will never be less than zero. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: Remove inaccessible URLClay King1-2/+0
[WHAT] Remove inaccessible link. Reviewed-by: Joshua Aberback <joshua.aberback@amd.com> Signed-off-by: Clay King <clayking@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: Promote DC to 3.2.352Taimur Hassan1-1/+1
- Fix slice width calculation for YCbCr420 - Fix DTBCLK gating - Use NRD cap as lttpr cap - Consolidate DML2 FP guards - DML2.1 Update - Firmware Release 0.1.29.0 changes Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: [FW Promotion] Release 0.1.29.0Taimur Hassan1-1/+203
Add new interface for offloading cursor programming to DMUB. Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: Prevent Gating DTBCLK before It Is Properly LatchedFangzhi Zuo2-2/+4
[why] 1. With allow_0_dtb_clk enabled, the time required to latch DTBCLK to 600 MHz depends on the SMU. If DTBCLK is not latched to 600 MHz before set_mode completes, gating DTBCLK causes the DP2 sink to lose its clock source. 2. The existing DTBCLK gating sequence ungates DTBCLK based on both pix_clk and ref_dtbclk, but gates DTBCLK when either pix_clk or ref_dtbclk is zero. pix_clk can be zero outside the set_mode sequence before DTBCLK is properly latched, which can lead to DTBCLK being gated by mistake. [how] Consider both pixel_clk and ref_dtbclk when determining when it is safe to gate DTBCLK; this is more accurate. Reviewed-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/display: lttpr cap should be nrd cap in bw_alloc modePeichen Huang1-2/+36
[WHY] When bw allocation mode enabled, dpia may reports lttpr cap with reduced common cap. It would cause driver not start pre-training with max available bandwidth. [How] When bw allocation mode enabled, use NRD cap as lttpr cap. Reviewed-by: Cruise Hung <cruise.hung@amd.com> Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Peichen Huang <PeiChen.Huang@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-06 08:35:57 +0300