summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/psr: CAN_PSR and CAN_PANEL_REPLAY can be now local definesJouni Högander2024-01-152-6/+6
| | | | | | | | | 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
* drm/i915/display: No need for full modeset due to psrJouni Högander2024-01-152-14/+0
| | | | | | | | | There is no specific reason to force full modeset if psr is enabled. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Tested-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
* drm/i915/psr: Disable early transport by defaultJouni Högander2024-01-091-0/+3
| | | | | | | | | Early transport validation is currently incomplete. Due to this disable the feature by default. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-8-jouni.hogander@intel.com
* drm/i915/psr: Enable psr2 early transport as possibleJouni Högander2024-01-093-8/+31
| | | | | | | | | | | 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 <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-7-jouni.hogander@intel.com
* drm/i915/psr: Configure PIPE_SRCSZ_ERLY_TPT for psr2 early transportJouni Högander2024-01-092-0/+15
| | | | | | | | | | | | | | 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 <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-6-jouni.hogander@intel.com
* drm/i915/psr: Calculate and configure CUR_POS_ERLY_TPTJouni Högander2024-01-092-7/+27
| | | | | | | | | | | | | | 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 <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-5-jouni.hogander@intel.com
* drm/i915/psr: Carry su area in crtc_stateJouni Högander2024-01-092-28/+36
| | | | | | | | | 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 <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-4-jouni.hogander@intel.com
* drm/i915/psr: Extend SU area to cover cursor fully if neededJouni Högander2024-01-091-1/+37
| | | | | | | | | | | 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 <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-3-jouni.hogander@intel.com
* drm: Add eDP 1.5 early transport definitionJouni Högander2024-01-091-0/+1
| | | | | | | | | | Add DP_PSR_ENABLE_SU_REGION_ET to enable panel early transport. Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-2-jouni.hogander@intel.com
* drm/i915/dp: Fix the max DSC bpc supported by sourceAnkit Nautiyal2024-01-091-1/+1
| | | | | | | | | | | | | Use correct helper for getting max DSC bpc supported by the source. Fixes: 1c56e9a39833 ("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
* drm/i915/cdclk: Re-use bxt_cdclk_ctl() when sanitizingGustavo Sousa2024-01-081-23/+3
| | | | | | | | | | | | | | 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: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105140538.183553-5-gustavo.sousa@intel.com
* drm/i915/cdclk: Reorder bxt_sanitize_cdclk()Gustavo Sousa2024-01-081-12/+12
| | | | | | | | | | | | | | | 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: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105140538.183553-4-gustavo.sousa@intel.com
* drm/i915/cdclk: Extract bxt_cdclk_ctl()Gustavo Sousa2024-01-081-22/+35
| | | | | | | | | | | | | | 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: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105140538.183553-3-gustavo.sousa@intel.com
* drm/i915/xe2lpd: Update bxt_sanitize_cdclk()Gustavo Sousa2024-01-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | With Xe2_LPD, there were changes to the way CDCLK_CTL must be programmed. Those were reflected on _bxt_set_cdclk() with commit 3d3696c0fed1 ("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: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105140538.183553-2-gustavo.sousa@intel.com
* drm/i915/dp: Abort AUX on disconnected native DP portsImre Deak2024-01-081-4/+1
| | | | | | | | | | | | | | | 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 a972cd3f0eb5 ("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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Filter out glitches on HPD lines during hotplug detectionImre Deak2024-01-083-2/+21
| | | | | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Add intel_digital_port lock/unlock hooksImre Deak2024-01-087-31/+56
| | | | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Disable hotplug detection handlers during driver init/shutdownImre Deak2024-01-088-0/+39
| | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Disable hotplug detection works during driver init/shutdownImre Deak2024-01-085-20/+154
| | | | | | | | | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Prevent modesets during driver init/shutdownImre Deak2024-01-085-2/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Suspend the framebuffer console earlier during system suspendImre Deak2024-01-081-2/+1
| | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Suspend the framebuffer console during driver shutdownImre Deak2024-01-081-0/+1
| | | | | | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Disable intel HPD poll after DRM poll init/enableImre Deak2024-01-082-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Move audio deinit after disabling pollingImre Deak2024-01-081-2/+3
| | | | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Keep the connector polled state disabled after stormImre Deak2024-01-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915: Init DRM connector polled field earlyImre Deak2024-01-086-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | After an HPD IRQ storm on a connector intel_hpd_irq_storm_detect() will set the connector's HPD pin state to HPD_MARK_DISABLED and the IRQ gets disabled. Subsequently intel_hpd_irq_storm_switch_to_polling() will enable polling for these connectors, setting the pin state to HPD_DISABLED, but only if the connector's base.polled field is set to DRM_CONNECTOR_POLL_HPD. intel_hpd_irq_storm_reenable_work() will reenable the IRQ - after 2 minutes - if the pin state is HPD_DISABLED. The connectors will be created with their base.polled field set to 0, which gets initialized only later in i915_hpd_poll_init_work() (using intel_connector::polled). If a storm is detected on a connector after it's created and IRQs are enabled on it - by intel_hpd_init() - and before its bease.polled field is initialized in the above work, the connector's HPD pin will stay in the HPD_MARK_DISABLED state - leaving the IRQ disabled indefinitely - and polling will not get enabled on it as intended. I can't see a reason for initializing base.polled in a delayed manner, so do this already when creating the connector, to prevent the above race condition. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-2-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
* drm/i915/display: Use helper to select C20 MPLLA/BMika Kahola2024-01-081-6/+11
| | | | | | | | | | | | | | We used to select between MPLLA/B with the following state->tx[0] & C20_PHY_USE_MPLLB Since this is used a few places within C20 PLL setting, let's introduce a helper function to clean up the code a bit. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105112243.224199-1-mika.kahola@intel.com
* drm/i915: Disable DSB in Xe KMDJosé Roberto de Souza2024-01-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Often getting DSB overflows when starting Xorg or Wayland compositors when running Xe KMD. Issue was reported but nothing was done, so disabling DSB as whole until properly fixed in Xe KMD. v2: - move check to HAS_DSB(Jani) v3: - use IS_ENABLED(I915) check in intel_dsb_prepare() Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/989 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1031 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1072 Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104162411.56085-1-jose.souza@intel.com
* drm/i915/tv: use DISPLAY_VER instead of GRAPHICS_VERJani Nikula2024-01-051-1/+1
| | | | | | | | | Display code should not care about graphics version. It's only comments here, but update anyway. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-5-jani.nikula@intel.com
* drm/i915/display: use IS_DISPLAY_VER instead of IS_GRAPHICS_VERJani Nikula2024-01-051-1/+1
| | | | | | | | Display code should not care about graphics version. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-4-jani.nikula@intel.com
* drm/i915/hdcp: use DISPLAY_VER instead of GRAPHICS_VERJani Nikula2024-01-051-13/+15
| | | | | | | | | Display code should not care about graphics version. While at it, abstract the version check to a separate macro. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-3-jani.nikula@intel.com
* drm/i915/dmc: use DISPLAY_VER instead of GRAPHICS_VERJani Nikula2024-01-051-1/+1
| | | | | | | | Display code should not care about graphics version. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-2-jani.nikula@intel.com
* drm/i915/irq: use DISPLAY_VER instead of GRAPHICS_VERJani Nikula2024-01-051-1/+1
| | | | | | | | Display code should not care about graphics version. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-1-jani.nikula@intel.com
* drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectorsImre Deak2024-01-041-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: ef75c25e8fed ("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: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240103152609.2434100-1-imre.deak@intel.com
* drm/i915/display: Skip C10 state verification in case of fastsetMika Kahola2024-01-041-0/+3
| | | | | | | | | | | | PLL's are not programmed in case of fastset so the state verification compares bios programmed PLL values against sw PLL values. To overcome this limitation, we can skip the state verification for C10 in fastset case as the driver is not writing PLL values. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219123246.832245-1-mika.kahola@intel.com
* drm/i915/display: Cleanup mplla/mpllb selectionMika Kahola2024-01-041-24/+15
| | | | | | | | | | | | | | | The function intel_c20_use_mplla() is not really widely used and can be replaced with the more suitable pll->tx[0] & C20_PHY_USE_MPLLB expression. Let's remove the intel_c20_use_mplla() alltogether and replace mplla/mpllb selection by checking mpllb bit. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240102115741.118525-4-mika.kahola@intel.com
* drm/i915/display: Store hw clock for C20Mika Kahola2024-01-041-45/+52
| | | | | | | | | | | We can calculate the hw port clock during the hw readout and store it as pll_state->clock for C20 state verification. In order to do that we need to move intel_c20pll_calc_port_clock() function. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240102115741.118525-3-mika.kahola@intel.com
* drm/i915/display: Fix C20 pll selection for state verificationMika Kahola2024-01-041-10/+15
| | | | | | | | | | | | | | | | | | | | 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: 59be90248b42 ("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: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240102115741.118525-2-mika.kahola@intel.com
* drm/i915/mtl: Add fake PCH for Meteor LakeHaridhar Kalvala2024-01-039-29/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | Correct the implementation trying to detect MTL PCH with the MTL fake PCH id. On MTL, both the North Display (NDE) and South Display (SDE) functionality reside on the same die (the SoC die in this case), unlike many past platforms where the SDE was on a separate PCH die. The code is (badly) structured today in a way that assumes the SDE is always on the PCH for modern platforms, so on platforms where we don't actually need to identify the PCH to figure out how the SDE behaves (i.e., all DG1/2 GPUs as well as MTL and LNL),we've been assigning a "fake PCH" as a quickhack that allows us to avoid restructuring a bunch of the code.we've been assigning a "fake PCH" as a quick hack that allows us to avoid restructuring a bunch of the code. Removed unused macros of LNL amd MTL as well. v2: Reorder PCH_MTL conditional check (Matt Roper) Reverting to PCH_MTL for PICA interrupt(Matt Roper) Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219185233.1469675-1-haridhar.kalvala@intel.com
* drm/i915/bios: remove some unused leftover declarationsJani Nikula2023-12-291-3/+0
| | | | | | | | | Remove some unused declarations probably left behind after some refactoring. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231221105414.1518267-1-jani.nikula@intel.com
* drm/i915/display: Take care of VSC select field in video dip ctl registerJouni Högander2023-12-221-3/+5
| | | | | | | | | | | We need to configure VSC Select field in video dip ctl if we want to have e.g. colorimetry date in our VSC SDP. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Shawn Lee <shawn.c.lee@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231220103609.1384523-8-jouni.hogander@intel.com
* drm/i915/display: Read PSR configuration before VSC SDPJouni Högander2023-12-221-2/+2
| | | | | | | | | | | | | VSC SDP sending is taken care by PSR HW and it's not enabled in VIDEO_DIP_CTL when PSR is enabled. Readback of VSC SDP is depending on VSC_SDP being set in intel_crtc_state->infoframes.enabled. In case of PSR setting this flag is taken care by PSR code -> read back PSR configuration before reading VSC SDP otherwise we get pipeconfig mismatch error. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Shawn Lee <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231220103609.1384523-7-jouni.hogander@intel.com
* drm/i915/display: Ignore only psr specific part of vsc sdpJouni Högander2023-12-222-7/+6
| | | | | | | | | | | | Pipe config check is currently ignoring vsc sdp changes completely if psr is enabled. We want to ignore only PSR part of it as there might be changes in colorimetry data. Also read back vsc_sdp when psr is used. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Shawn Lee <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231220103609.1384523-6-jouni.hogander@intel.com
* drm/i915/display: Fix vsc_sdp computationJouni Högander2023-12-221-29/+19
| | | | | | | | | | Currently colorimetry data is not added for psr1 or non-psr case. Fix this by adding it as needed. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Shawn Lee <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231220103609.1384523-5-jouni.hogander@intel.com
* drm/i915/display: Unify VSC SPD preparationJouni Högander2023-12-223-50/+6
| | | | | | | | | | There is no specific reason to prepare VSC SDP for PSR case somehow differently. Unify PSR and non-PSR preparation. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Shawn Lee <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231220103609.1384523-4-jouni.hogander@intel.com
* drm/i915/display: Move colorimetry_support from intel_psr to intel_dpJouni Högander2023-12-223-8/+10
| | | | | | | | | | Colorimetry support is not really a PSR specific thing. Move it to intel_dp struct and use it also when preparing vsc sdp for non-PSR case. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Shawn Lee <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231220103609.1384523-3-jouni.hogander@intel.com
* drm/i915/display: Remove intel_crtc_state->psr_vscJouni Högander2023-12-222-3/+2
| | | | | | | | | | There is no really need to have separate vsc for psr usage. Use intel_crtc_state->infoframes.vsc instead. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Shawn Lee <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231220103609.1384523-2-jouni.hogander@intel.com
* drm/i915/hdcp: Fail Repeater authentication if Type1 device not presentSuraj Kandpal2023-12-221-0/+6
| | | | | | | | | | | | | | | | | Fail repeater authentication step in case RX_INFO indicates HDCP1.x or HDCP2.0/2.1 device is present downstream in repeater topology and content type set by userspace is Type1. --v2 -Fix build error. --v3 -remove mst encoder check as branch device also act as repeater Signed-off-by: Suraj Kandpal <suraj.kandpal@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/20231215050915.2070119-1-suraj.kandpal@intel.com
* drm/i915/cdclk: Remove divider field from tablesGustavo Sousa2023-12-201-135/+134
| | | | | | | | | | | | The cdclk tables were introduced with commit 736da8112fee ("drm/i915: Use literal representation of cdclk tables"). It has been almost 4 years and the divider field was not really used yet. Let's remove it. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231124205522.57696-2-gustavo.sousa@intel.com
* drm/i915/dp: Fix passing the correct DPCD_REV for drm_dp_set_phy_test_patternKhaled Almahallawy2023-12-191-1/+1
| | | | | | | | | | | | | Using link_status to get DPCD_REV fails when disabling/defaulting phy pattern. Use intel_dp->dpcd to access DPCD_REV correctly. Fixes: 8cdf72711928 ("drm/i915/dp: Program vswing, pre-emphasis, test-pattern") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213211542.3585105-3-khaled.almahallawy@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-20 05:15:34 +0100