summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorLines
2025-08-06amdgpu/amdgpu_discovery: increase timeout limit for IFWI initXaver Hugl-2/+2
With a timeout of only 1 second, my rx 5700XT fails to initialize, so this increases the timeout to 2s. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3697 Signed-off-by: Xaver Hugl <xaver.hugl@kde.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-06drm/radeon: Pass along the format info from .fb_create() to ↵Imre Deak-7/+11
drm_helper_mode_fill_fb_struct() Plumb the format info from .fb_create() all the way to drm_helper_mode_fill_fb_struct() to avoid the redundant lookup. For the fbdev case a manual drm_get_format_info() lookup is needed. The patch is based on the driver parts of the patchset at Link: below, which missed converting the radeon driver. Due to the absence of this change in the patchset at Link:, after the Fixed: commit below, radeon_framebuffer_init() -> drm_helper_mode_fill_fb_struct() set drm_framebuffer::format incorrectly to NULL, which lead to the !fb->format WARN() in drm_framebuffer_init() and causing framebuffer creation to fail. This patch fixes both of these issues. v2: Amend the commit log mentioning the functional issues the patch fixes. (Tomi) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: amd-gfx@lists.freedesktop.org Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: 41ab92d35ccd ("drm: Make passing of format info to drm_helper_mode_fill_fb_struct() mandatory") Link: https://lore.kernel.org/all/20250701090722.13645-1-ville.syrjala@linux.intel.com Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250805175752.690504-4-imre.deak@intel.com
2025-08-06drm/nouveau: Pass along the format info from .fb_create() to ↵Imre Deak-6/+6
drm_helper_mode_fill_fb_struct() Plumb the format info from .fb_create() all the way to drm_helper_mode_fill_fb_struct() to avoid the redundant lookup. The patch is based on the driver parts of the patchset at Link: below, which missed converting the nouveau driver. Due to the absence of this change in the patchset at Link:, after the Fixed: commit below, nouveau_framebuffer_new() -> drm_helper_mode_fill_fb_struct() set drm_framebuffer::format incorrectly to NULL, which lead to the !fb->format WARN() in drm_framebuffer_init() and causing framebuffer creation to fail. This patch fixes both of these issues. v2: Amend the commit log mentioning the functional issues the patch fixes. (Tomi) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: nouveau@lists.freedesktop.org Fixes: 41ab92d35ccd ("drm: Make passing of format info to drm_helper_mode_fill_fb_struct() mandatory") Link: https://lore.kernel.org/all/20250701090722.13645-1-ville.syrjala@linux.intel.com Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: James Jones <jajones@nvidia.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: James Jones <jajones@nvidia.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250805175752.690504-3-imre.deak@intel.com
2025-08-06drm/omap: Pass along the format info from .fb_create() to ↵Imre Deak-14/+16
drm_helper_mode_fill_fb_struct() Plumb the format info from .fb_create() all the way to drm_helper_mode_fill_fb_struct() to avoid the redundant lookup. For the fbdev case a manual drm_get_format_info() lookup is needed. The patch is based on the driver parts of the patchset at Link: below, which missed converting the omap driver. Due to the absence of this change in the patchset at Link:, after the Fixed: commit below, omap_framebuffer_init() -> drm_helper_mode_fill_fb_struct() set drm_framebuffer::format incorrectly to NULL, which lead to the !fb->format WARN() in drm_framebuffer_init() and causing framebuffer creation to fail. This patch fixes both of these issues. v2: Amend the commit log mentioning the functional issues the patch fixes. (Tomi) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Fixes: 41ab92d35ccd ("drm: Make passing of format info to drm_helper_mode_fill_fb_struct() mandatory") Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/all/98b3a62c-91ff-4f91-a58b-e1265f84180b@sirena.org.uk Link: https://lore.kernel.org/all/20250701090722.13645-1-ville.syrjala@linux.intel.com Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250805175752.690504-2-imre.deak@intel.com
2025-08-06drm/xe/svm: Migrate folios when possibleFrancois Dugast-0/+10
The DMA mapping can now correspond to a folio (order > 0), so move the iterator by the number of pages in the folio in order to migrate all pages at once. This requires forcing contiguous memory for SVM BOs, which greatly simplifies the code and enables 2MB device page support, allowing a major performance improvement. Negative effects like extra eviction are unlikely as SVM BOs have a maximal size of 2MB. v2: - Improve commit message (Matthew Brost) - Fix increment, chunk, assert match (Matthew Brost) Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250805140028.599361-7-francois.dugast@intel.com Signed-off-by: Francois Dugast <francois.dugast@intel.com>
2025-08-06drm/xe/migrate: Populate struct drm_pagemap_addr arrayFrancois Dugast-0/+19
Workaround to ensure all addresses are populated in the array as this is expected when creating the copy batch. This is required because the migrate layer does not support 2MB GPU pages yet. A proper fix will come in a follow-up. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250805140028.599361-6-francois.dugast@intel.com Signed-off-by: Francois Dugast <francois.dugast@intel.com>
2025-08-06drm/pagemap: Allocate folios when possibleFrancois Dugast-14/+40
If the order is greater than zero, allocate a folio when populating the RAM PFNs instead of allocating individual pages one after the other. For example if 2MB folios are used instead of 4KB pages, this reduces the number of calls to the allocation API by 512. v2: - Use page order instead of extra argument (Matthew Brost) - Allocate with folio_alloc() (Matthew Brost) - Loop for mpages and free_pages based on order (Matthew Brost) v3: - Fix loops in drm_pagemap_migrate_populate_ram_pfn() (Matthew Brost) v4: - Use folio_trylock(), set local variable to NULL (Matthew Brost) Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/20250805140028.599361-5-francois.dugast@intel.com Signed-off-by: Francois Dugast <francois.dugast@intel.com>
2025-08-06drm/pagemap: DMA map folios when possibleFrancois Dugast-7/+18
If the page is part of a folio, DMA map the whole folio at once instead of mapping individual pages one after the other. For example if 2MB folios are used instead of 4KB pages, this reduces the number of DMA mappings by 512. The folio order (and consequently, the size) is persisted in the struct drm_pagemap_device_addr to be available at the time of unmapping. v2: - Initialize order variable (Matthew Brost) - Set proto and dir for completeness (Matthew Brost) - Do not populate drm_pagemap_addr, document it (Matthew Brost) - Add and use macro NR_PAGES(order) (Matthew Brost) Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/20250805140028.599361-4-francois.dugast@intel.com Signed-off-by: Francois Dugast <francois.dugast@intel.com>
2025-08-06drm/pagemap: Use struct drm_pagemap_addr in mapping and copy functionsFrancois Dugast-76/+100
This struct embeds more information than just the DMA address. This will help later to support folio orders greater than zero. At this point, there is no functional change as the only struct member used is addr. In Xe, adapt to the new drm_gpusvm_devmem_ops type signatures using struct drm_pagemap_addr, as well as the internal xe SVM functions implementing those operations. The use of this struct is propagated to xe_migrate as it makes indexed accesses to the next DMA address but they are no longer contiguous. v2: - Rename drm_pagemap_device_addr to drm_pagemap_addr (Matthew Brost) - Squash with patch for Xe (Matthew Brost) - Set proto and dir for completeness (Matthew Brost) - Assess DMA map protocol (Matthew Brost) Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/20250805140028.599361-3-francois.dugast@intel.com Signed-off-by: Francois Dugast <francois.dugast@intel.com>
2025-08-06drm/pagemap: Rename drm_pagemap_device_addr to drm_pagemap_addrFrancois Dugast-11/+11
Rename this struct to the more generic name drm_pagemap_addr so it can be used in a broader context, such as DMA mappings of CPU memory. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/20250805140028.599361-2-francois.dugast@intel.com Signed-off-by: Francois Dugast <francois.dugast@intel.com>
2025-08-06drm/i915/display: keep forward declarations togetherJani Nikula-2/+1
Adhere to prevalent style. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/2c74fa7f2b7d5ecf8247aa5bff05d104ad60cf9e.1753953530.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-06drm/i915/display: make struct __intel_global_objs_state opaqueJani Nikula-8/+8
With struct __intel_global_objs_state only being accessed in intel_global_state.c, we can make it opaque. The double underscore to indicate internal becomes redundant, drop it. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/06cc4d1c506e3a5b1cc50e01c4bd1135bbf0f7bd.1753953530.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-06drm/i915/display: hide global state iterators, remove unusedJani Nikula-28/+25
for_each_{new,old,oldnew}_global_obj_in_state() are only used within intel_global_state.c, hide them there. intel_for_each_global_obj() is unused, remove it. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/a23212d9298423d8971d6ad62f961386f7f927cc.1753953530.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-06drm: bridge: Add waveshare DSI2DPI unit driverJoseph Guo-0/+216
Waveshare touchscreen consists of a DPI panel and a driver board. The waveshare driver board consists of ICN6211 and a MCU to convert DSI to DPI and control the backlight. This driver treats the MCU and ICN6211 board as a whole unit. It can support all resolution waveshare DSI2DPI based panel, the timing table should come from 'panel-dpi' panel in the device tree. Signed-off-by: Joseph Guo <qijian.guo@nxp.com> Suggested-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250806-waveshare-v3-3-fd28e01f064f@nxp.com
2025-08-06drm/i915/scaler: Fix WA_14011503117Suraj Kandpal-2/+3
This introduces and uses a variable id which is just uninitialized. What really needs to be used is the scaler_id. Fixes: 73309ed9d598 ("drm/i915/display: WA_14011503117") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Nemesa Garg <nemesa.garg@intel.com> Link: https://lore.kernel.org/r/20250806030856.3514127-1-suraj.kandpal@intel.com
2025-08-06Merge tag 'drm-intel-next-fixes-2025-08-05' of ↵Dave Airlie-6/+15
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 fixes for v6.17-rc1: - Fixes around DP LFPS (Low-Frequency Periodic Signaling) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/e1147bede8f219682419d198022cfe8d9d4edc28@intel.com
2025-08-05drm/xe/configfs: Allow adding configurations for future VFsMichal Wajdeczko-3/+30
Since we are expecting that all configuration directory names will match some of the existing devices, we can't provide any configuration for the VFs until they are actually enabled. But we can relax that restriction by just checking if there is a PF device that could create given VF. This is easy since all our PF devices are always present at function 0 and we can query PF device for number of VFs it could support. Then for some system with PF device at 0000:00:02.0 we can add configs for all VFs: /sys/kernel/config/xe/ ├── 0000:00:02.0 │   └── ... ├── 0000:00:02.1 │   └── ... ├── 0000:00:02.2 │   └── ... : └── 0000:00:02.7 └── ... Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731212145.179898-1-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe/configfs: Only allow configurations for supported devicesMichal Wajdeczko-0/+19
Since we already lookup for the real PCI device before we allow to create its directory config, we might also check if the found device matches our driver PCI ID list. This will prevent creation of the directory configs for the unsupported devices. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-11-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe/configfs: Keep default device config settings togetherMichal Wajdeczko-4/+13
For easier maintenance add a placeholder where we can keep all default device configuration settings in one place. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-9-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe/configfs: Reintroduce struct xe_config_deviceMichal Wajdeczko-10/+17
This time it will hold just pure configuration parameters, without any configfs related stuff. This will help us define defaults data without wasting space for unneeded data. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-8-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe/configfs: Rename configfs_find_group() helperMichal Wajdeczko-7/+7
This helper name shouldn't suggest that it iss a part of the core configfs API family. While around switch to use different helper to release a reference. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-7-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe/configfs: Rename struct xe_config_deviceMichal Wajdeczko-14/+14
Rename it to struct xe_config_group_device to better match its purpose. It will also help us to reintroduce in the upcoming patch the same struct name but this time to hold only configuration data. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-6-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe/configfs: Drop redundant init() error messageMichal Wajdeczko-4/+1
There is no need to print separate error message since we will also print one in xe_init(). Also drop temporary variable, which was likely just taken from the example code. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-5-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe/configfs: Destroy xe_configfs.su_mutex on exit/errorMichal Wajdeczko-1/+2
While mutex_destroy() is NOP when CONFIG_DEBUG_MUTEXES is not enabled, we should still call it. While around, drop a trailing line. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-4-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe: Print module init abort codeMichal Wajdeczko-0/+2
We should provide a hint to the user why the module refused to load. This will also allow us to drop individual error messages from init steps. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-3-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe: Simplify module initialization codeMichal Wajdeczko-17/+10
There is no need to have extra checks and WARN() in the helpers as instead of an index of the entry with function pointers, we can pass pointer to the entry which we prepare directly in the main loop, that is guaranteed to be valid. add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-180 (-180) Function old new delta xe_exit 109 79 -30 cleanup_module 109 79 -30 xe_init 248 188 -60 init_module 248 188 -60 Total: Before=2774145, After=2773965, chg -0.01% Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250731193339.179829-2-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/xe/xe_guc_ads: Consolidate guc_waklv_enable functionsJonathan Cavitt-97/+39
Presently, multiple versions of the guc_waklv_enable_.* function exist, all with different numbers of dwords added to the klv_entry array. This is not extensible, and more duplicates of the function will need to be created if it ever becomes necessary to support 3 or more dwords per wa in the future. Consolidate the disparate guc_waklv_enable functions into a single guc_waklv_enable function that can take an arbitrary number of dword values. v2: - Update length value properly (Shuicheng) v3: (Harrison) - Use data as a term instead of dwords or arr - Reformat warning message to use hex values - Eliminate need for kzalloc and klv_entry array - Reorder function parameters to fix line wrapping v4: - Miscellaneous formatting fixes (Cavitt) v5: (Harrison) - s/data_range/data_len_dw - Use data_len_dw to calculate size for xe_map_memcpy_to Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Lucas De Marchi <lucas.demarch@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250728194806.68176-2-jonathan.cavitt@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-05drm/i915/display: WA_14011503117Nemesa Garg-0/+47
Mask the ERR_FATAL_MASK before scaler initialization. After enabling the scaler and waiting for one frame, unmask the previously masked bits, PS_ECC and ERR_FATAL_MASK Unmasking of ERR_FATAL_MASK bit is use for validation purpose. There is no functional impact. v2: Remove intel_display_need_wa[Jani] Optimize the ecc_unmask call[Animesh] v3: Add intel_display_wa[Jani] Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250801125835.2337614-1-nemesa.garg@intel.com
2025-08-04drm/amdgpu: Update SDMA firmware version check for user queue supportJesse.Zhang-1/+1
This commit fixes a firmware version check for enabling user queue support in SDMA v7.0. The previous version check (7836028) was incorrect and could lead to issues with PROTECTED_FENCE_SIGNAL commands causing register conflicts between MCU_DBG0 and MCU_DBG1. Fixes: 8c011408ed84 ("drm/amdgpu/sdma7: add ucode version checks for userq support") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 92e2449241516c95aab95eea91faecd0fa2b7ed5) Cc: stable@vger.kernel.org
2025-08-04drm/amdgpu: Add NULL check for asic_funcsLijo Lazar-1/+2
If driver load fails too early, asic_funcs pointer remains unassigned. Add NULL check to sanitize unwind path. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 582bf7c5158dce16f7dc5b8345b7876bd8031224) Cc: stable@vger.kernel.org
2025-08-04drm/amd/display: Revert "drm/amd/display: Fix AMDGPU_MAX_BL_LEVEL value"Mario Limonciello-4/+4
This reverts commit 66abb996999de0d440a02583a6e70c2c24deab45. This broke custom brightness curves but it wasn't obvious because of other related changes. Custom brightness curves are always from a 0-255 input signal. The correct fix was to fix the default value which was done by [1]. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4412 Link: https://lore.kernel.org/amd-gfx/0f094c4b-d2a3-42cd-824c-dc2858a5618d@kernel.org/T/#m69f875a7e69aa22df3370b3e3a9e69f4a61fdaf2 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6ec8a5cbec751625133461600d0d4950ffd3a214) Cc: stable@vger.kernel.org
2025-08-04drm/amd/display: fix a Null pointer dereference vulnerabilitySiyang Liu-9/+10
[Why] A null pointer dereference vulnerability exists in the AMD display driver's (DC module) cleanup function dc_destruct(). When display control context (dc->ctx) construction fails (due to memory allocation failure), this pointer remains NULL. During subsequent error handling when dc_destruct() is called, there's no NULL check before dereferencing the perf_trace member (dc->ctx->perf_trace), causing a kernel null pointer dereference crash. [How] Check if dc->ctx is non-NULL before dereferencing. Link: https://lore.kernel.org/r/tencent_54FF4252EDFB6533090A491A25EEF3EDBF06@qq.com Co-developed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> (Updated commit text and removed unnecessary error message) Signed-off-by: Siyang Liu <Security@tencent.com> Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404) Cc: stable@vger.kernel.org
2025-08-04drm/amd/display: Add primary plane to commits for correct VRR handlingMichel Dänzer-0/+9
amdgpu_dm_commit_planes calls update_freesync_state_on_stream only for the primary plane. If a commit affects a CRTC but not its primary plane, it would previously not trigger a refresh cycle or affect LFC, violating current UAPI semantics. Fixes e.g. atomic commits affecting only the cursor plane being limited to the minimum refresh rate. Don't do this for the legacy cursor ioctls though, it would break the UAPI semantics for those. Suggested-by: Xaver Hugl <xaver.hugl@kde.org> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3034 Signed-off-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit cc7bfba95966251b254cb970c21627124da3b7f4) Cc: stable@vger.kernel.org
2025-08-04drm/amdgpu: update mmhub 3.3 client id mappingsAlex Deucher-1/+104
Update the client id mapping so the correct clients get printed when there is a mmhub page fault. v2: fix typos spotted by David Wu. v3: fix additional typo spotted by David. Reviewed-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e932f4779a2d329841bb9ca70bb80a4bb2d707b6) Cc: stable@vger.kernel.org
2025-08-04drm/amdgpu: update mmhub 3.0.1 client id mappingsAlex Deucher-25/+32
Update the client id mapping so the correct clients get printed when there is a mmhub page fault. Reviewed-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2a2681eda73b99a2c1ee8cdb006099ea5d0c2505) Cc: stable@vger.kernel.org
2025-08-04drm/amdgpu: Retain job->vm in amdgpu_job_prepare_jobYuanShang-7/+0
The field job->vm is used in function amdgpu_job_run to get the page table re-generation counter and decide whether the job should be skipped. Specifically, function amdgpu_vm_generation checks if the VM is valid for this job to use. For instance, if a gfx job depends on a cancelled sdma job from entity vm->delayed, then the gfx job should be skipped. Fixes: 26c95e838e63 ("drm/amdgpu: set the VM pointer to NULL in amdgpu_job_prepare") Signed-off-by: YuanShang <YuanShang.Mao@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ed76936c6b10b547c6df4ca75412331e9ef6d339) Cc: stable@vger.kernel.org
2025-08-04drm/amd/display: Fix DCE 6.0 and 6.4 PLL programming.Timur Kristóf-14/+25
Apparently, both DCE 6.0 and 6.4 have 3 PLLs, but PLL0 can only be used for DP. Make sure to initialize the correct amount of PLLs in DC for these DCE versions and use PLL0 only for DP. Also, on DCE 6.0 and 6.4, the PLL0 needs to be powered on at initialization as opposed to DCE 6.1 and 7.x which use a different clock source for DFS. The following functions were used as reference from the old radeon driver implementation of DCE 6.x: - radeon_atom_pick_pll - atombios_crtc_set_disp_eng_pll Reviewed-by: Rodrigo Siqueira <siqueira@igalia.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 35222b5934ec8d762473592ece98659baf6bc48e) Cc: stable@vger.kernel.org
2025-08-04drm/amd/display: Don't overwrite dce60_clk_mgrTimur Kristóf-1/+0
dc_clk_mgr_create accidentally overwrites the dce60_clk_mgr with the dce_clk_mgr, causing incorrect behaviour on DCE6. Fix it by removing the extra dce_clk_mgr_construct. Fixes: 62eab49faae7 ("drm/amd/display: hide VGH asic specific structs") Reviewed-by: Rodrigo Siqueira <siqueira@igalia.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bbddcbe36a686af03e91341b9bbfcca94bd45fb6) Cc: stable@vger.kernel.org
2025-08-04drm/amdkfd: Fix checkpoint-restore on multi-xccDavid Yat Sin-16/+67
GPUs with multi-xcc have multiple MQDs per queue. This patch saves and restores all the MQDs within the partition. Signed-off-by: David Yat Sin <David.YatSin@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a578f2a58c3ab38f0643b1b6e7534af860233cb1) Cc: stable@vger.kernel.org
2025-08-04drm/amd: Restore cached manual clock settings during resumeMario Limonciello-0/+10
If the SCLK limits have been set before S3 they will not be restored. The limits are however cached in the driver and so they can be restored by running a commit sequence during resume. Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250725031222.3015095-3-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4e9526924d09057a9ba854305e17eded900ced82) Cc: stable@vger.kernel.org
2025-08-04drm/amd: Restore cached power limit during resumeMario Limonciello-0/+6
The power limit will be cached in smu->current_power_limit but if the ASIC goes into S3 this value won't be restored. Restore the value during SMU resume. Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250725031222.3015095-2-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 26a609e053a6fc494403e95403bc6a2470383bec) Cc: stable@vger.kernel.org
2025-08-04drm/amdgpu: Update external revid for GC v9.5.0Lijo Lazar-0/+2
Use different external revid for GC v9.5.0 SOCs. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 21c6764ed4bfaecad034bc4fd15dd64c5a436325) Cc: stable@vger.kernel.org
2025-08-04drm/amdgpu: Update supported modes for GC v9.5.0Lijo Lazar-1/+4
For GC v9.5.0 SOCs, both CPX and QPX compute modes are also supported in NPS2 mode. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Mangesh Gadre <Mangesh.Gadre@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9d1ac25c7f830e0132aa816393b1e9f140e71148) Cc: stable@vger.kernel.org
2025-08-04drm/amd/pm: Make static table support conditionalLijo Lazar-7/+21
Add PMFW version check for static table support on SMU v13.0.6 VFs. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-04drm/amdgpu: Fix vcn v4.0.3 poison irq call trace on sriov guestXiang Liu-1/+1
Sriov guest side doesn't init ras feature hence the poison irq shouldn't be put during hw fini. [25209.468816] Call Trace: [25209.468817] <TASK> [25209.468818] ? srso_alias_return_thunk+0x5/0x7f [25209.468820] ? show_trace_log_lvl+0x28e/0x2ea [25209.468822] ? show_trace_log_lvl+0x28e/0x2ea [25209.468825] ? vcn_v4_0_3_hw_fini+0xaf/0xe0 [amdgpu] [25209.468936] ? show_regs.part.0+0x23/0x29 [25209.468939] ? show_regs.cold+0x8/0xd [25209.468940] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.469038] ? __warn+0x8c/0x100 [25209.469040] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.469135] ? report_bug+0xa4/0xd0 [25209.469138] ? handle_bug+0x39/0x90 [25209.469140] ? exc_invalid_op+0x19/0x70 [25209.469142] ? asm_exc_invalid_op+0x1b/0x20 [25209.469146] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.469241] vcn_v4_0_3_hw_fini+0xaf/0xe0 [amdgpu] [25209.469343] amdgpu_ip_block_hw_fini+0x34/0x61 [amdgpu] [25209.469511] amdgpu_device_fini_hw+0x3b3/0x467 [amdgpu] Fixes: 4c4a89149608 ("drm/amdgpu: Register aqua vanjaram vcn poison irq") Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Stanley.Yang <Stanley.Yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-04drm/amdgpu: Fix jpeg v4.0.3 poison irq call trace on sriov guestXiang Liu-1/+1
Sriov guest side doesn't init ras feature hence the poison irq shouldn't be put during hw fini. [25209.467154] Call Trace: [25209.467156] <TASK> [25209.467158] ? srso_alias_return_thunk+0x5/0x7f [25209.467162] ? show_trace_log_lvl+0x28e/0x2ea [25209.467166] ? show_trace_log_lvl+0x28e/0x2ea [25209.467171] ? jpeg_v4_0_3_hw_fini+0x6f/0x90 [amdgpu] [25209.467300] ? show_regs.part.0+0x23/0x29 [25209.467303] ? show_regs.cold+0x8/0xd [25209.467304] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.467403] ? __warn+0x8c/0x100 [25209.467407] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.467503] ? report_bug+0xa4/0xd0 [25209.467508] ? handle_bug+0x39/0x90 [25209.467511] ? exc_invalid_op+0x19/0x70 [25209.467513] ? asm_exc_invalid_op+0x1b/0x20 [25209.467518] ? amdgpu_irq_put+0x9e/0xc0 [amdgpu] [25209.467613] ? amdgpu_irq_put+0x5f/0xc0 [amdgpu] [25209.467709] jpeg_v4_0_3_hw_fini+0x6f/0x90 [amdgpu] [25209.467805] amdgpu_ip_block_hw_fini+0x34/0x61 [amdgpu] [25209.467971] amdgpu_device_fini_hw+0x3b3/0x467 [amdgpu] Fixes: 1b2231de4163 ("drm/amdgpu: Register aqua vanjaram jpeg poison irq") Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Stanley.Yang <Stanley.Yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-04drm/amdgpu: Add wrapper function for dpc stateLijo Lazar-9/+19
Use wrapper functions to set/indicate dpc status. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Ce Sun <cesun102@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-04drm/amd/pm: Allow static metrics table query in VFLijo Lazar-1/+1
Allow statics metrics table to be queried on SMUv13.0.6 SOCs in VF mode. 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-08-04drm/amdgpu: Update SDMA firmware version check for user queue supportJesse.Zhang-1/+1
This commit fixes a firmware version check for enabling user queue support in SDMA v7.0. The previous version check (7836028) was incorrect and could lead to issues with PROTECTED_FENCE_SIGNAL commands causing register conflicts between MCU_DBG0 and MCU_DBG1. Fixes: 8c011408ed84 ("drm/amdgpu/sdma7: add ucode version checks for userq support") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-04drm/amd/pm: Use cached metrics data on arcturusLijo Lazar-1/+1
Cached metrics data validity is 1ms on arcturus. It's not reasonable for any client to query gpu_metrics at a faster rate and constantly interrupt PMFW. 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>
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-03 10:40:21 +0000