summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-02-03drm/ast: Inline ast_get_vbios_mode_info()Thomas Zimmermann
The helper ast_get_vbios_mode_info() retrieves hardware-specific format and display-mode information. Inline the function into its only caller. While at it, also replace a use of struct drm_format_info.cpp with the correct DRM 4CC codes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-13-tzimmermann@suse.de
2025-02-03drm/ast: Validate DRM display modes against VBIOS modesThomas Zimmermann
Test DRM display modes against the list of modes supported by the VBIOS. The helper will respect the supported-modes flags in struct ast_device. Hence only DRM display modes supported by the VBIOS will be reported; without the current duplication of this information. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-12-tzimmermann@suse.de
2025-02-03drm/ast: Add helpers for VBIOS mode lookupThomas Zimmermann
Mode lines are independent from hardware Gen or TX chip, so hide all VBIOS mode tables in ast_vbios.c. Move the look-up code for VBIOS modes from ast_vbios_get_mode_info() to ast_vbios_find_mode(). The new look-up function respects the supported-mode flags in struct ast_device. For example, if a device does not have struct ast_device.support_fullhd set, the helper does not return a valid mode for 1920x1080. Taking the supported-mode flags into account allows for making the VBIOS tables the single reference for validating and setting display modes against hardware capabilities. v2: - replace mode switch with look-up table (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-11-tzimmermann@suse.de
2025-02-03drm/ast: Add empty initializer for VBIOS modesThomas Zimmermann
VBIOS mode tables are terminated by an entry with a refresh rate of 0xff. The code is hard to read and fragile to use. Therefore create an empty entry with AST_VBIOS_MODE_INVALID to terminate each mode list. Stop at the invalid entry when searching for modes in the tables. Instead of testing for refresh == 0xff, test with a helper function if the mode's size and refresh have meaningful values. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-10-tzimmermann@suse.de
2025-02-03drm/ast: Find VBIOS mode from regular display sizeThomas Zimmermann
The ast driver looks up supplied display modes from an internal list of display modes supported by the VBIOS. Do not use the crtc_-prefixed display values from struct drm_display_mode for looking up the VBIOS mode. The fields contain raw values that the driver programs to hardware. They are affected by display settings like double-scan or interlace. Instead use the regular vdisplay and hdisplay fields for lookup. As the programmed values can now differ from the values used for lookup, set struct drm_display_mode.crtc_vdisplay and .crtc_hdisplay from the VBIOS mode. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-9-tzimmermann@suse.de
2025-02-03drm/ast: Always validate H/V sync flagsThomas Zimmermann
The ast driver matches DRM display modes against an internal list of modes supported by the VBIOS. Matching H/V sync flags between modes is preferred, but optional. If sync flags are not matching, the driver would program the VBIOS settings to hardware and let the display handle the difference. DRM modes are generated from attached displays or standard mode lines. Therefore differences to the VBIOS modes are not just cosmetical, but signal possible incompatibility with the display hardware. Hence make matching H/V sync flags mandatory. If the VBIOS does not support a certain mode, we should report it as unsupported. Note that the VBIOS mode tables all appear to refer to standard modes. (If sync flags really make no difference to the VBIOS, the ast driver shouldn't match them in the first place.) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-8-tzimmermann@suse.de
2025-02-03drm/ast: Add support_wuxga flag to struct ast_deviceThomas Zimmermann
Detect support for 1920x1200 (WUXGA) in ast_detect_widescreen(). The flag is cleared by default. The test logic has been taken from existing code in ast_crtc_helper_mode_valid(). The code in that function is being replaced by the new flag. v2: - move shared detection code into helper (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-7-tzimmermann@suse.de
2025-02-03drm/ast: Add support_fullhd flag to struct ast_deviceThomas Zimmermann
Detect support for 1920x1080 (FullHD) in ast_detect_widescreen(). The flag is cleared by default. The test logic has been taken from existing code in ast_crtc_helper_mode_valid(). The code in that function is being replaced by the new flag. For Gen3, a new branch duplicates the Gen2 logic and adds a test for AST2200. Gen2 adds a test for AST2100. v2: - use fullhd flag for setting max width/height Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-6-tzimmermann@suse.de
2025-02-03drm/ast: Reorganize widescreen test around hardware GensThomas Zimmermann
Testing for support of widescreen modes mixes up various hardware Gens. First branch by hardware Gen, then do specific tests for each Gen. By default, widesscreen support is disabled. Later patches will add more specific tests for each Gen. v2: - move shared detection code into helper (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-5-tzimmermann@suse.de
2025-02-03drm/ast: Rename support_wide_screen to support_wsxga_pThomas Zimmermann
The flag support_wide_screen in struct ast_device selects devices that support resolutions of at least 1680x1050 (WSXGA+). Name it accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-4-tzimmermann@suse.de
2025-02-03drm/ast: Align naming in widescreen detection code to manualThomas Zimmermann
Rename variables and register constants to align with the programming manual. Add new constants where necessary. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-3-tzimmermann@suse.de
2025-02-03drm/ast: Remove 1152x864 from list of widescreen resolutionsThomas Zimmermann
The resolution 1152x864 has a ratio of 4:3 and is already handled as such. Remove it from the list of widescreen resolutions. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131092257.115596-2-tzimmermann@suse.de
2025-01-31Merge tag 'drm-next-2025-02-01' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "This is only AMD fixes: amdgpu: - GC 12 fix - Aldebaran fix - DCN 3.5 fix - Freesync fix amdkfd: - Per queue reset fix - MES fix" * tag 'drm-next-2025-02-01' of https://gitlab.freedesktop.org/drm/kernel: drm/amd/display: restore invalid MSA timing check for freesync drm/amdkfd: only flush the validate MES contex drm/amd/display: Correct register address in dcn35 drm/amd/pm: Mark MM activity as unsupported drm/amd/amdgpu: change the config of cgcg on gfx12 drm/amdkfd: Block per-queue reset when halt_if_hws_hang=1
2025-01-31drm/i915/dp: Return min bpc supported by source instead of 0Ankit Nautiyal
Currently, intel_dp_dsc_max_src_input_bpc can return 0 for platforms not supporting DSC, which could theoretically cause issues in clamp() due to a low limit being greater than the high limit. Instead, return the minimum bpc supported by the source to prevent such issues. Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Closes: https://lore.kernel.org/all/CA+G9fYtNfM399_=_ff81zeRJv=0+z7oFJfPGmJgTp6yrJmU+1w@mail.gmail.com/ Fixes: 160672b86b0d ("drm/i915/dp: Use clamp for pipe_bpp limits with DSC") Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Tested-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131041342.3086716-1-ankit.k.nautiyal@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-31gpu: drm_dp_cec: fix broken CEC adapter properties checkHans Verkuil
If the hotplug detect of a display is low for longer than one second (configurable through drm_dp_cec_unregister_delay), then the CEC adapter is unregistered since we assume the display was disconnected. If the HPD went low for less than one second, then we check if the properties of the CEC adapter have changed, since that indicates that we actually switch to new hardware and we have to unregister the old CEC device and register a new one. Unfortunately, the test for changed properties was written poorly, and after a new CEC capability was added to the CEC core code the test always returned true (i.e. the properties had changed). As a result the CEC device was unregistered and re-registered for every HPD toggle. If the CEC remote controller integration was also enabled (CONFIG_MEDIA_CEC_RC was set), then the corresponding input device was also unregistered and re-registered. As a result the input device in /sys would keep incrementing its number, e.g.: /sys/devices/pci0000:00/0000:00:08.1/0000:e7:00.0/rc/rc0/input20 Since short HPD toggles are common, the number could over time get into the thousands. While not a serious issue (i.e. nothing crashes), it is not intended to work that way. This patch changes the test so that it only checks for the single CEC capability that can actually change, and it ignores any other capabilities, so this is now safe as well if new caps are added in the future. With the changed test the bit under #ifndef CONFIG_MEDIA_CEC_RC can be dropped as well, so that's a nice cleanup. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Reported-by: Farblos <farblos@vodafonemail.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: 2c6d1fffa1d9 ("drm: add support for DisplayPort CEC-Tunneling-over-AUX") Tested-by: Farblos <farblos@vodafonemail.de> Link: https://patchwork.freedesktop.org/patch/msgid/361bb03d-1691-4e23-84da-0861ead5dbdc@xs4all.nl Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-31drm/xe: Skip survivability mode for VFRiana Tauro
Follow the probe flow in case of VF and do not enter survivability mode in case of pcode init failure. Fixes: 5e940312a2ac ("drm/xe: Add functions and sysfs for boot survivability") Suggested-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250131080527.2256475-1-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-31drm/xe/display: Use a single early init call for displayMaarten Lankhorst
Now that interrupts are disabled for xe_display_init_noaccel, both xe_display_init_noirq and xe_display_init_noaccel run in the same context. This means that we can get rid of the 3 different init calls. Without interrupts, nothing is touching display up to this point. Unify those 3 early display calls into a single xe_display_init_early(), this makes the init sequence cleaner, and display less tangled during init. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250121142850.4960-3-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-01-31drm/xe: Defer irq init until after xe_display_init_noaccelMaarten Lankhorst
As stated in previous commit, we have to move interrupt handling until after xe_display_init_noaccel, as using memirqs would require an allocation. A full solution will of course require memirq allocation to be moved, but the first part only focuses on the required changes to display. Reviewed-by: Ilia Levi <ilia.levi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250121142850.4960-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-01-31drm/xe/display: Add intel_plane_initial_vblank_waitMaarten Lankhorst
We're changing the driver to have no interrupts during early init for Xe, so we poll the PIPE_FRMSTMSMP counter instead. Interrupts cannot be enabled during FB readout because memirq's requires an allocation. This would overwrite the FB we want to read out. While it might be possible to also run do the same in i915 and run it without interrupts, the platforms i915 supports had a less clear distinction between display and graphics. For this reason I choose only to touch Xe for now. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250121142850.4960-1-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-01-31drm/i915/mst: use min_array() and max_array() instead of hand-rollingJani Nikula
Improve code clarity by using existing min_array() and max_array() helpers to find the lowest and highest values in an array. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/62a104535c01c667a99ec209c3218a13355568cf.1738161945.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-31drm/i915/mst: remove unnecessary mst_stream_find_vcpi_slots_for_bpp()Jani Nikula
mst_stream_find_vcpi_slots_for_bpp() has become a thin wrapper that merely juggles parameters around. Remove it. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/abdd205087dc2ab0bdae09d7374d5f262f605aba.1738161945.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-31drm/i915/mst: handle mst pbn_div in intel_dp_mtp_tu_compute_config()Jani Nikula
Move mst_state->pbn_div calculation to intel_dp_mtp_tu_compute_config() to allow further refactoring. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0cc1b507601c9964ebae7d50b1f90b1ce00acb11.1738161945.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-31drm/i915/mst: change where lane_count and port_clock are setJani Nikula
Semantically mst_stream_find_vcpi_slots_for_bpp() does not seem like the place to make decisions about lane_count and port_clock. Move them to the callers, and remove the limits parameter that becomes unused. This leads to slight duplication, but a) this makes further refactoring easier, and b) also the SST code sets link parameters in different places for uncompressed and compressed paths. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/101ce3fc6afff55d966336f3ab72090317750f82.1738161945.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-31drm/i915/dp: change the order of intel_dp_mtp_tu_compute_config() paramsJani Nikula
Pointers first, bpp params in min, max, step. This is slightly more natural to follow. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ea9669edc5973cdbca92aeb4e168850015e9d1bb.1738161945.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-31drm/i915/dp: constify struct link_config_limits pointersJani Nikula
The limits get passed around, but are only modified in a few places. Constify the pointers elsewhere so it's easier to follow where they can be modified. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6ab2f68eef7849aca18e82ad788e44e9f82b576e.1738161945.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-01-30Merge drm/drm-next into drm-xe-nextLucas De Marchi
Backmerge drm-next to get the common APIs and refactors as well as getting the display changes from i915 in xe so the probe order can be improved. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-01-30drm/xe/pf: Add runtime registers for graphics gen >= 30Jakub Kolakowski
Add missing runtime registers for graphics versions of 3000 or higher. This is required for Xe3 where additionally we have MIRROR_L3BANK_ENABLE register. Signed-off-by: Jakub Kolakowski <jakub1.kolakowski@intel.com> Suggested-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Adam Miszczak <adam.miszczak@linux.intel.com> Cc: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Cc: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piorkowski <piotr.piorkowski@intel.com> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Tested-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250128110300.2840596-2-jakub1.kolakowski@intel.com
2025-01-30drm/xe: Fix sort order of .o lists in MakefileGustavo Sousa
The Makefile for xe asks us to keep the lists of object files sorted: # Please keep these build lists sorted! Reshuffle the lists into the correct sort order. That was done by filtering each unsorted list through 'LC_ALL=C sort'. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250115140812.20799-1-gustavo.sousa@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-30drm/xe/pf: Reset GuC VF config when unprovisioning critical resourceMichal Wajdeczko
GuC firmware counts received VF configuration KLVs and may start validation of the complete VF config even if some resources where unprovisioned in the meantime, leading to unexpected errors like: $ echo 1 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/contexts_quota $ echo 0 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/contexts_quota $ echo 1 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/doorbells_quota $ echo 0 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/doorbells_quota $ echo 1 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/ggtt_quota tee: '/sys/kernel/debug/dri/0000:00:02.0/gt0/vf1/ggtt_quota': Input/output error To mitigate this problem trigger explicit VF config reset after unprovisioning any of the critical resources (GGTT, context or doorbell IDs) that GuC is monitoring. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250129195947.764-3-michal.wajdeczko@intel.com
2025-01-30drm/xe/pf: Don't send BEGIN_ID if VF has no context/doorbellsMichal Wajdeczko
It turned out that GuC validates VF configuration immediately after receiving "some" set of configuration KLVs and complains if one of the critical, from GuC understanding, resource is left unprovisioned, even if PF should be still allowed to make late VF config adjustments, since VF was not yet started. This issue was discovered after we decided to asynchronously re-send configuration KLVs after GT reset/resume, as then fair VF auto-provisioning could already allocate some of the resources, which was a prerequiste for sending those config KLVs: # fair GGTT provisioning [] xe 0000:00:02.0: [drm] GT0: PF: pushed VF1 config with 2 KLVs: [] xe 0000:00:02.0: [drm] GT0: { key 0x0001 : 64b value 0x176a000 } # ggtt_start [] xe 0000:00:02.0: [drm] GT0: { key 0x0002 : 64b value 0xfd696000 } # ggtt_size [] xe 0000:00:02.0: [drm] GT0: PF: VF1 provisioned with 4251541504 (3.96 GiB) GGTT # re-provisioning worker [] xe 0000:00:02.0: [drm] *ERROR* GT0: H2G request 0x5503 failed: error 0x60 hint 0x0 [] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF1 14 config KLVs (-EIO) [] xe 0000:00:02.0: [drm] GT0: { key 0x0001 : 64b value 0x176a000 } # ggtt_start [] xe 0000:00:02.0: [drm] GT0: { key 0x0002 : 64b value 0xfd696000 } # ggtt_size [] xe 0000:00:02.0: [drm] GT0: { key 0x8a0b : 32b value 0 } # begin_ctx_id [] xe 0000:00:02.0: [drm] GT0: { key 0x0004 : 32b value 0 } # num_contexts [] xe 0000:00:02.0: [drm] GT0: { key 0x8a0a : 32b value 0 } # begin_db_id [] xe 0000:00:02.0: [drm] GT0: { key 0x0006 : 32b value 0 } # num_doorbells [] xe 0000:00:02.0: [drm] GT0: { key 0x8a01 : 32b value 0 } # exec_quantum [] xe 0000:00:02.0: [drm] GT0: { key 0x8a02 : 32b value 0 } # preempt_timeout [] xe 0000:00:02.0: [drm] GT0: { key 0x8a03 : 32b value 0 } # cat_error_count [] xe 0000:00:02.0: [drm] GT0: { key 0x8a04 : 32b value 0 } # engine_reset_count [] xe 0000:00:02.0: [drm] GT0: { key 0x8a05 : 32b value 0 } # page_fault_count [] xe 0000:00:02.0: [drm] GT0: { key 0x8a06 : 32b value 0 } # guc_time_us [] xe 0000:00:02.0: [drm] GT0: { key 0x8a07 : 32b value 0 } # irq_time_us [] xe 0000:00:02.0: [drm] GT0: { key 0x8a08 : 32b value 0 } # doorbell_time_us [] xe 0000:00:02.0: [drm] GT0: PF: Failed to push VF1 configuration (-EIO) To avoid such errors stop sending BEGIN_CONTEXT/DOORBELL_ID KLVs if no GuC context/doorbell IDs were provisioned to VF. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4176 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250129195947.764-2-michal.wajdeczko@intel.com
2025-01-30drm/i915/display: Move as sdp params change to fastsetMitul Golani
as_sdp param changes from vrr to cmrr should happen to fastset. Changing as_sdp params should not trigger any modeset. Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250130051609.1796524-7-mitulkumar.ajitkumar.golani@intel.com
2025-01-30drm/i915/dp: Compute as_sdp based on if vrr possibleMitul Golani
Adaptive sync sdp param computation, we can configure during full modeset as well when sink is having vrr support, where it doesn't need dependency on vrr.enable status and can also match vrr enable/disable fastset requirement. --v2: - Separate the change from as_sdp.vtotal. [Ankit] Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250130051609.1796524-6-mitulkumar.ajitkumar.golani@intel.com
2025-01-30drm/i915/dp: Compute as_sdp.vtotal based on vrr timingsMitul Golani
Compute as_sdp.vtotal based on minimum vtotal calculated during vrr computation. --v2: - make a separate patch and update to vmin only [Ankit]. --v3: - Update vtotal to vmin for cmrr case as well [Ankit]. --v4: - update vtotal with wrapper function of vmin [Ville] Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250130051609.1796524-5-mitulkumar.ajitkumar.golani@intel.com
2025-01-30drm/i915/dp: fix the Adaptive sync Operation mode for SDPAnkit Nautiyal
Currently we support Adaptive sync operation mode with dynamic frame rate, but instead the operation mode with fixed rate is set. This was initially set correctly in the earlier version of changes but later got changed, while defining a macro for the same. Fixes: a5bd5991cb8a ("drm/i915/display: Compute AS SDP parameters") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250130051609.1796524-4-mitulkumar.ajitkumar.golani@intel.com
2025-01-30drm/i915/vrr: Compute vrr.vsync_{start, end} during full modesetMitul Golani
vrr.vsync_{start,end} computation should not depend on crtc_state->vrr.enable. --v1: - Explain commit message more clearly [Jani] - Instead of tweaking to fastset use vrr.flipline while computing AS_SDP. --v2: - Correct computation of vrr.vsync_start/end should not depend on vrr.enable.[ville] - vrr enable disable requirement should not obstruct by SDP enable disable requirements. [Ville] --v3: - Create separate patch for crtc_state_dump [Ankit]. --v4: - Update commit message and header [Ankit]. Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250130051609.1796524-3-mitulkumar.ajitkumar.golani@intel.com
2025-01-30drm/i915/vrr: Add crtc_state dump for vrr.vsync paramsMitul Golani
Add crtc_state dump for vrr.vsync_{start/end} params to track the state correctly. --v2: - remove vrr_ pretext and use space instead of underscore (Jani). --v3: - Rebase to latest drm-tip. Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250130051609.1796524-2-mitulkumar.ajitkumar.golani@intel.com
2025-01-30Revert "drm/i915/gt: Log reason for setting TAINT_WARN at reset"Sebastian Brzezinka
This reverts commit 835443da6f50d9516b58bba5a4fdf9e563d961c7. Logging with gt_err() causes CI to detect an error even in cases of intentional error injection. Since real errors are already correctly reported by CI, this additional message is unnecessary. Furthermore, a GT wedge is already being logged elsewhere, so instead of adjusting the log level, revert the above mentioned commit to prevent redundant error reporting. Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/pynwwza2xyvicokflxc6lduwwrzwoihihaan54ago3m2xzzagu@qva2ue4tydie
2025-01-30drm/xe/gt_pagefault: Print engine class stringFrancois Dugast
The engine class index which is printed here is an internal representation for debugging. It is _not_ an index based on DRM_XE_ENGINE_CLASS_* values provided in the uAPI. Add the string representation of the engine class to the output in order to limit possible confusion by users when analyzing the logs. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250129175241.338043-1-francois.dugast@intel.com Signed-off-by: Francois Dugast <francois.dugast@intel.com>
2025-01-29drm/komeda: Add check for komeda_get_layer_fourcc_list()Haoxiang Li
Add check for the return value of komeda_get_layer_fourcc_list() to catch the potential exception. Fixes: 5d51f6c0da1b ("drm/komeda: Add writeback support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20241219090256.146424-1-haoxiang_li2024@163.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2025-01-29drm/xe/guc: Fix size_t print formatLucas De Marchi
Use %zx format to print size_t to remove the following warning when building for i386: >> drivers/gpu/drm/xe/xe_guc_ct.c:1727:43: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] 1727 | drm_printf(p, "[CTB].length: 0x%lx\n", snapshot->ctb_size); | ~~~ ^~~~~~~~~~~~~~~~~~ | %zx Cc: José Roberto de Souza <jose.souza@intel.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501281627.H6nj184e-lkp@intel.com/ Fixes: cb1f868ca137 ("drm/xe: Make GUC binaries dump consistent with other binaries in devcoredump") Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250128154242.3371687-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-01-29Merge tag 'constfy-sysctl-6.14-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl Pull sysctl table constification from Joel Granados: "All ctl_table declared outside of functions and that remain unmodified after initialization are const qualified. This prevents unintended modifications to proc_handler function pointers by placing them in the .rodata section. This is a continuation of the tree-wide effort started a few releases ago with the constification of the ctl_table struct arguments in the sysctl API done in 78eb4ea25cd5 ("sysctl: treewide: constify the ctl_table argument of proc_handlers")" * tag 'constfy-sysctl-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl: treewide: const qualify ctl_tables where applicable
2025-01-29drm/i915/guc: Debug print LRC state entries only if the context is pinnedDaniele Ceraolo Spurio
After the context is unpinned the backing memory can also be unpinned, so any accesses via the lrc_reg_state pointer can end up in unmapped memory. To avoid that, make sure to only access that memory if the context is pinned when printing its info. v2: fix newline alignment Fixes: 28ff6520a34d ("drm/i915/guc: Update GuC debugfs to support new GuC") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v5.15+ Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250115001334.3875347-1-daniele.ceraolospurio@intel.com
2025-01-29Revert "drm/xe/lnl: Enable GuC SLPC DCC task"Rodrigo Vivi
This reverts commit 50554bf3e56dd0c78ef1eedb685d0ab36c9c9987. DCC in LNL should be disabled. It was a mistake to decide to go against GuC platform defaults in this case and this could lead to regressions in some TDP limited scenarios instead of helping. Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250128223248.660748-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-29drm/ast: Fix ast_dp connection statusJocelyn Falempe
ast_dp_is_connected() used to also check for link training success to report the DP connector as connected. Without this check, the physical_status is always connected. So if no monitor is present, it will fail to read the EDID and set the default resolution to 640x480 instead of 1024x768. Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Fixes: 2281475168d2 ("drm/ast: astdp: Perform link training during atomic_enable") Reported-by: Jerry Hoemann <jerry.hoemann@hpe.com> Tested-by: Jose Lopez <jose.lopez@hpe.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250124141142.2434138-1-jfalempe@redhat.com
2025-01-28drm/amd/display: restore invalid MSA timing check for freesyncMelissa Wen
This restores the original behavior that gets min/max freq from EDID and only set DP/eDP connector as freesync capable if "sink device is capable of rendering incoming video stream without MSA timing parameters", i.e., `allow_invalid_MSA_timing_params` is true. The condition was mistakenly removed by 0159f88a99c9 ("drm/amd/display: remove redundant freesync parser for DP"). CC: Mario Limonciello <mario.limonciello@amd.com> CC: Alex Hung <alex.hung@amd.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3915 Fixes: 0159f88a99c9 ("drm/amd/display: remove redundant freesync parser for DP") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2025-01-28drm/amdkfd: only flush the validate MES contexPrike Liang
The following page fault was observed duringthe KFD process release. In this particular error case, the HIP test (./MemcpyPerformance -h) does not require the queue. As a result, the process_context_addr was not assigned when the KFD process was released, ultimately leading to this page fault during the execution of the function kfd_process_dequeue_from_all_devices(). [345962.294891] amdgpu 0000:03:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:153 vmid:0 pasid:0) [345962.295333] amdgpu 0000:03:00.0: amdgpu: in page starting at address 0x0000000000000000 from client 10 [345962.295775] amdgpu 0000:03:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B33 [345962.296097] amdgpu 0000:03:00.0: amdgpu: Faulty UTCL2 client ID: CPC (0x5) [345962.296394] amdgpu 0000:03:00.0: amdgpu: MORE_FAULTS: 0x1 [345962.296633] amdgpu 0000:03:00.0: amdgpu: WALKER_ERROR: 0x1 [345962.296876] amdgpu 0000:03:00.0: amdgpu: PERMISSION_FAULTS: 0x3 [345962.297135] amdgpu 0000:03:00.0: amdgpu: MAPPING_ERROR: 0x1 [345962.297377] amdgpu 0000:03:00.0: amdgpu: RW: 0x0 [345962.297682] amdgpu 0000:03:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:169 vmid:0 pasid:0) Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Jonathan Kim <jonathan.kim@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2025-01-28drm/amd/display: Correct register address in dcn35loanchen
[Why] the offset address of mmCLK5_spll_field_8 was incorrect for dcn35 which causes SSC not to be enabled. Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Lo-An Chen <lo-an.chen@amd.com> Signed-off-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2025-01-28drm/amd/pm: Mark MM activity as unsupportedLijo Lazar
Aldebaran doesn't support querying MM activity percentage. Keep the field as 0xFFs to mark it as unsupported. 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> Cc: stable@vger.kernel.org
2025-01-28drm/amd/amdgpu: change the config of cgcg on gfx12Kenneth Feng
change the config of cgcg on gfx12 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.12.x
2025-01-28drm/amdkfd: Block per-queue reset when halt_if_hws_hang=1Jay Cornwall
The purpose of halt_if_hws_hang is to preserve GPU state for driver debugging when queue preemption fails. Issuing per-queue reset may kill wavefronts which caused the preemption failure. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Jonathan Kim <Jonathan.Kim@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.12.x
generated by cgit v1.3 (git 2.53.0) at 2026-11-09 06:05:23 +0000