- 15 Jan, 2024 5 commits
-
-
Jani Nikula authored
Backmerge to bring Xe driver to drm-intel-next. Signed-off-by:Jani Nikula <jani.nikula@intel.com>
-
Dave Airlie authored
It appears on TU106 GPUs (2070), that some of the nvdec engines are in the runlist but have no valid nonstall interrupt, nouveau didn't handle that too well. This should let nouveau/gsp work on those. Cc: stable@vger.kernel.org # v6.7+ Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/all/20240110011826.3996289-1-airlied@gmail.com/
-
Jouni Högander authored
CAN_PSR and CAN_PANEL_REPLAY are not used outside intel_psr.c anymore. Make them as intel_psr.c local defines. Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240109100517.1947414-3-jouni.hogander@intel.com
-
Jouni Högander authored
There is no specific reason to force full modeset if psr is enabled. Signed-off-by:
Paz Zcharya <pazz@chromium.org> Reviewed-by:
Stanislav Lisovskiy <staniskav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240109100517.1947414-2-jouni.hogander@intel.com
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2024-01-11' of git://anongit.freedesktop.org/drm/drm-misc into drm-next A fix for the v3d register readout, and two compilation fixes for rockchip. Signed-off-by:
-
- 14 Jan, 2024 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2024-01-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Fixes for kernel-doc warnings enforced in linux-next - Another build warning fix for string formatting of intel_wakeref_t - Display fixes for DP DSC BPC and C20 PLL state verification Signed-off-by:
-
- 10 Jan, 2024 9 commits
-
-
Randy Dunlap authored
Document nested struct members with full names as described in Documentation/doc-guide/kernel-doc.rst. i915_perf_types.h:341: warning: Excess struct member 'ptr_lock' description in 'i915_perf_stream' i915_perf_types.h:341: warning: Excess struct member 'head' description in 'i915_perf_stream' i915_perf_types.h:341: warning: Excess struct member 'tail' description in 'i915_perf_stream' 3 warnings as Errors Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Randy Dunlap authored
Document nested struct members with full names as described in Documentation/doc-guide/kernel-doc.rst. intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'num_guc_ids' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids_bitmap' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_id_list' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'guc_ids_in_use' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'destroyed_contexts' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'destroyed_worker' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'reset_fail_worker' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'reset_fail_mask' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'sched_disable_delay_ms' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'sched_disable_gucid_threshold' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'gt_stamp' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'ping_delay' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'work' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'shift' description in 'intel_guc' intel_guc.h:305: warning: Excess struct member 'last_stat_jiffies' description in 'intel_guc' 18 warnings as Errors Signed-off-by:
-
Randy Dunlap authored
Document nested struct members with full names as described in Documentation/doc-guide/kernel-doc.rst. intel_gsc.h:34: warning: Excess struct member 'gem_obj' description in 'intel_gsc' Also add missing field member descriptions. Signed-off-by:
-
Randy Dunlap authored
Document nested struct members with full names as described in Documentation/doc-guide/kernel-doc.rst. i915_gem_context_types.h:420: warning: Excess struct member 'lock' description in 'i915_gem_context' Signed-off-by:
-
Ankit Nautiyal authored
Use correct helper for getting max DSC bpc supported by the source. Fixes: 1c56e9a3 ("drm/i915/dp: Get optimal link config to have best compressed bpp") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Swati Sharma <swati2.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213091632.431557-3-ankit.k.nautiyal@intel.com (cherry picked from commit cd7b0b2d) Signed-off-by:
-
Jani Nikula authored
intel_wakeref_t is supposed to be a mostly opaque cookie to its users. It should only be checked for being non-zero and set to zero. Debug logging its actual value is meaningless. Switch to just debug logging whether the async_put_wakeref is non-zero. The issue dates back to much earlier than commit b49e894c ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library"), but this is the one that brought about a build failure due to the printf format. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20240102111222.2db11208@canb.auug.org.au Fixes: b49e894c ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
Imre Deak authored
MST connectors don't have a static attached encoder, as their encoder can change depending on the pipe they use; so the encoder for an MST connector can't be retrieved using intel_dp_attached_encoder() (which may return NULL for MST). Most of the PSR debugfs entries depend on a static connector -> encoder mapping which is only true for eDP and SST DP connectors and not for MST. These debugfs entries were enabled for MST connectors as well recently to provide PR information for them, but handling MST connectors needs more changes. Fix this by not adding for now the PSR entries on MST connectors. To make things more uniform add the entries for SST connectors on all platforms, not just on platforms supporting DP2.0. v2: - Keep adding the entries for SST connectors. (Jouni) - Add a TODO: comment for MST support. Fixes: ef75c25e ("drm/i915/panelreplay: Debugfs support for panel replay") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850 Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
Mika Kahola authored
Add pll selection check for C20 as well as clock state verification0. We have been relying on sw state to select A or B pll's. This is incorrect as the hw might see this selection differently. This patch fixes this shortcoming by reading pll selection for both sw and hw states and compares if these two selections match. Fixes: 59be9024 ("drm/i915/mtl: C20 state verification") v2: reword commit message and include fix to a original commit (Imre) Compare pll selection (Jani) Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2023-12-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Eliminate use of kmap_atomic() in i915 (Zhao) - Add Wa_14019877138 for DG2 (Haridhar) - Static checker and spelling fixes (Colin, Karthik, Randy) Signed-off-by:
-
- 09 Jan, 2024 9 commits
-
-
Maíra Canal authored
RPi 4 uses V3D 4.2, which is currently not supported by the register definition stated at `v3d_core_reg_defs`. We should be able to support V3D 4.2, therefore, change the maximum version of the register definition to 42, not 41. Fixes: 0ad5bc1c ("drm/v3d: fix up register addresses for V3D 7.x") Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Iago Toral Quiroga <itoral@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240109113126.929446-1-mcanal@igalia.com
-
Jouni Högander authored
Early transport validation is currently incomplete. Due to this disable the feature by default. Signed-off-by:
-
Jouni Högander authored
Check source and sink support for psr2 early transport and enable it if not disabled by debug flag. Bspec: 68934 Signed-off-by:
-
Jouni Högander authored
There is a new register used to configure selective update area size for early transport. Configure PIPE_SRCSZ_ERLY_TPT using calculated selective update area carried in crtc_state->su_area. Bspec: 68927 Signed-off-by:
-
Jouni Högander authored
New register CUR_POS_ERLY_TPT related to early transport is supposed to be configured when early transport is in use. This register is used to configure cursor vertical postion from beginning of selective update area. Bspec: 68927 Signed-off-by:
-
Jouni Högander authored
Su_area is needed when configuring CUR_POS_ERLY_TPT and PIPE_SRC_SZ_ERLY_TPT. Store it into intel_crtc_state->psr2_su_area. Signed-off-by:
-
Jouni Högander authored
In case early transport is enabled SU area needs to be extended to cover cursor area fully when cursor is in SU area. Bspec: 68927 Signed-off-by:
-
Jouni Högander authored
Add DP_PSR_ENABLE_SU_REGION_ET to enable panel early transport. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Ankit Nautiyal authored
Use correct helper for getting max DSC bpc supported by the source. Fixes: 1c56e9a3 ("drm/i915/dp: Get optimal link config to have best compressed bpp") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 08 Jan, 2024 16 commits
-
-
https://gitlab.freedesktop.org/agd5f/linuxDave Airlie authored
amd-drm-next-6.8-2024-01-05: amdgpu: - VRR fixes - PSR-SU fixes - SubVP fixes - DCN 3.5 fixes - Documentation updates - DMCUB fixes - DML2 fixes - UMC 12.0 updates - GPUVM fix - Misc code cleanups and whitespace cleanups - DP MST fix - Let KFD sync with GPUVM fences - GFX11 reset fix - SMU 13.0.6 fixes - VSC fix for DP/eDP - Navi12 display fix - RN/CZN system aperture fix - DCN 2.1 bandwidth validation fix - DCN INIT cleanup amdkfd: - SVM fixes - Revert TBA/TMA location change Signed-off-by:
-
Gustavo Sousa authored
The function bxt_cdclk_ctl() is responsible for deriving the value for CDCLK_CTL; use it instead of repeating the same logic. v2: - Use a better commit message body by making it more self-contained and not referring to stuff from the subject line. (Matt) Reviewed-by:Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Make the sequence of steps in bxt_sanitize_cdclk() more logical by grouping things related to the check on the value of CDCLK_CTL into a single "block". Also, this will make an upcoming change replacing that block with a single function call easier to follow. v2: - Improve body of commit message to be more self-contained. Reviewed-by:
-
Gustavo Sousa authored
Extract logic for deriving the value for CDCLK_CTL into bxt_cdclk_ctl(). This makes the code better readable and will be used later in bxt_sanitize_cdclk(). v2: - Improve body of commit message to be more self-contained. Reviewed-by:
-
Gustavo Sousa authored
With Xe2_LPD, there were changes to the way CDCLK_CTL must be programmed. Those were reflected on _bxt_set_cdclk() with commit 3d3696c0 ("drm/i915/lnl: Start using CDCLK through PLL"), but bxt_sanitize_cdclk() was left out. This was causing some issues when loading the driver with a pre-existing active display configuration: the driver would mistakenly take the current value of CDCLK_CTL as wrong and the sanitization would be triggered. In a scenario where the display was already configured with a high CDCLKC and had plane(s) enabled, FIFO underrun errors were reported, because the current sanitization code selects the minimum possible CDCLK. Fix that by updating bxt_sanitize_cdclk() to match the changes made in _bxt_set_cdclk(). Ideally, we would have a common function to derive the value for CDCLK_CTL, but that can be done in a future change. Reviewed-by:
-
Imre Deak authored
An AUX transfer on any disconnected DP port results in long timeout/retry delays the same way as this is described for TypeC port in commit a972cd3f ("drm/i915/tc: Abort DP AUX transfer on a disconnected TC port") Prevent the delay on non-TypeC ports as well by aborting the transfer if the port is disconnected. For eDP keep the current behavior as the support for HPD signaling is optional for it. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-13-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
Glitches deasserting the connector HPD line can lead to incorrectly detecting a disconnect event (a glitch asserting the line will only cause a redundant connect->disconnect transition). The source of such a glitch can be noise on the line or a 0.5ms-1ms MST IRQ_HPD pulse. TypeC ports in the DP-alt or TBT-alt mode filter out these glitches inernally, but for others the driver has to do this. Make it so by polling the HPD line on these connectors for 4 ms. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-12-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
Add hooks to intel_digital_port to lock and unlock the port and add a helper to check the connector's detect status while the port is locked already. This simplifies checking the connector detect status in intel_dp_aux_xfer() and intel_digital_port_connected() in the next two patches aborting AUX transfers on all DP connectors (except eDP) and filtering HPD glitches. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-11-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
As described in the previous two patches an unexpected connector detection can happen during the init/shutdown sequences. Prevent these by returning the connector's current status from the detection handlers. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-10-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
As described in the previous patch, an unexpected connector detection/modeset started from the intel_hotplug::hotplug_work can happen during the driver init/shutdown sequence. Prevent these by disabling the queuing of and flushing all the intel_hotplug work that can start them at the beginning of the init/shutdown sequence and allow the queuing only while the display is in the initialized state. Other work items - like the intel_connector::modeset_retry_work or the MST probe works - are still enabled and can start a detection/modeset, but after the previous patch these will be rejected. Disabling these works as well is for a follow-up patchset. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-9-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
An unexpected modeset or connector detection by a user (user space or FB console) during the initialization/shutdown sequence is possible either via a hotplug IRQ handling work or via the connector sysfs (status/detect) interface. These modesets/detections should be prevented by disabling/flushing all related hotplug handling work and unregistering the interfaces that can start them at the beginning of the shutdown sequence. Some of this - disabling all related intel_hotplug work - will be done by the next patch, but others - for instance disabling the MST hotplug works - require a bigger rework. It makes sense - for diagnostic purpose, even with all the above work and interface disabled - to detect and reject any such user access. This patch does that for modeset accesses and a follow-up patch for connector detection. During driver loading/unloading/system suspend/shutdown and during system resume after calling intel_display_driver_disable_user_access() or intel_display_driver_resume_access() correspondigly, the current thread is allowed to modeset (as this thread requires to do an initial/restoring modeset or a disabling modeset), other threads (the user threads) are not allowed to modeset. During driver loading/system resume after calling intel_display_driver_enable_user_access() all threads are allowed to modeset. During driver unloading/system suspend/shutdown after calling intel_display_driver_suspend_access() no threads are allowed to modeset (as the HW got disabled and should stay in this state). v2: Call intel_display_driver_suspend_access()/resume_access() only for HAS_DISPLAY(). (CI) v3: (Jouni) - Add commit log comments explaining how the permission of modeset changes during HW init/deinit wrt. to the current and other user processes. Link: https://patchwork.freedesktop.org/patch/msgid/20240104132335.2766434-1-imre.deak@intel.comReviewed-by: -
Imre Deak authored
Suspend the FB console early during system suspend to prevent new FB probe/modeset cycles interfering with the HW uninitialization steps in a similar way as during driver shutdown as described in the previous patch. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-7-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
Suspend the FB console during driver shutdown the same way this is done during system resume. This should prevent any HPD event to trigger a new FB probe/modeset cycle happening in parallel with the display HW disable/uninitialize steps. A preceding FB HPD event handling may be still pending, resulting in a probe/modeset like the above, these will be prevented by a later change in this patchset. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-6-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
The only purpose of intel_hpd_poll_disable() during driver loading and system resume - at which point polling should be disabled anyway, except for connectors in an IRQ storm, for which the polling will stay enabled - is to force-detect all the connectors. However this detection in i915_hpd_poll_init_work() depends on drm.mode_config.poll_enabled, which will get set in drm_kms_helper_poll_init(), possibly after i915_hpd_poll_init_work() is scheduled. Hence the initial detection of connectors during driver loading may not happen. Fix the above by moving intel_hpd_poll_disable() after i915_hpd_poll_init_work(), the proper place anyway for doing the above detection after all the HW initialization steps are complete. Change the order the same way during system resume as well. The above race condition shouldn't matter here - as drm.mode_config.poll_enabled will be set - but the detection should happen here as well after the HW init steps are done. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-5-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
Deinitialize audio during driver unload after disabling polling. This is in preparation to do all the display HW init/deinit steps at a point where no HPD IRQ or polling initiated connector detection or modeset can change the HW state. This may still happen here via an HPD IRQ -> hotplug detection work or a connector sysfs (state/detect) access, but these will be prevented by later changes in this patchset. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-4-imre.deak@intel.comReviewed-by:
-
Imre Deak authored
If an HPD IRQ storm is detected on a connector during driver loading or system suspend/resume - disabling the IRQ and switching to polling - the polling may get disabled too early - before the intended 2 minute HPD_STORM_REENABLE_DELAY - with the HPD IRQ staying disabled for this duration. One such sequence is: Thread#1 Thread#2 intel_display_driver_probe()-> intel_hpd_init()-> (HPD IRQ gets enabled) . intel_hpd_irq_handler()-> . intel_hpd_irq_storm_detect() . intel_hpd_irq_setup()-> . (HPD IRQ gets disabled) . queue_delayed_work(hotplug.hotplug_work) . ... . i915_hotplug_work_func()-> . intel_hpd_irq_storm_switch_to_polling()-> . (polling enabled) . intel_hpd_poll_disable()-> queue_work(hotplug.poll_init_work) ... i915_hpd_poll_init_work()-> (polling gets disabled, HPD IRQ is still disabled) ... (Connector is neither polled or detected via HPD IRQs for 2 minutes) intel_hpd_irq_storm_reenable_work()-> (HPD IRQ gets enabled) To avoid the above 2 minute state without either polling or enabled HPD IRQ, leave the connector's polling mode unchanged in i915_hpd_poll_init_work() if its HPD IRQ got disabled after an IRQ storm indicated by the connector's HPD_DISABLED pin state. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-3-imre.deak@intel.comReviewed-by:
-
