- 17 Jun, 2024 11 commits
-
-
Jani Nikula authored
Instead of duplicating the CLKCFG parsing, reuse i9xx_fsb_freq() to figure out rawclk_freq where applicable. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/21511f155f1f446e066117bc6ed3165618d7afd6.1718356614.git.jani.nikula@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
Reuse i9xx_fsb_freq() for GT clock frequency initialization instead of depending on rawclk_freq. Note: If the init order was changed, we could use i915->fsb_freq directly. However, GT clock initialization is done in i915_driver_mmio_probe(), but intel_dram_detect() later in i915_driver_hw_probe(), with a dependency on intel_pcode_init(). Reviewed-by:
-
Jani Nikula authored
Initialize fsb frequency for more platforms to be able to use it for GT clock and rawclk frequency initialization. Note: There's a discrepancy between existing pnv_fsb_freq() and i9xx_hrawclk() regarding CLKCFG interpretation. Presume all PNV is mobile. Default to 1333 MHz for unknown values, similar to i9xx_hrawclk(). v2: - Add MISSING_CASE() (Ville) - Default to the same frequency for both branches (Ville) Reviewed-by:
-
Jani Nikula authored
We'll want to use fsb frequency for deriving GT clock and rawclk frequencies in the future. Increase the accuracy by converting to kHz. Do the same for mem freq to be aligned. Round the frequencies ending in 666 to 667. v2: Also handle mem_freq in gen5_rps_init() (Ville) Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Jani Nikula authored
It's a bit out of place, and only printed for VLV/CHV. Reviewed-by:
-
Jani Nikula authored
Follow the same style in mem freq init as in fsb freq init, returning the value instead of assigning in multiple places. Reviewed-by:
-
Jani Nikula authored
Split out the PNV DDR3 detection to a distinct step instead of conflating it with mem freq detection. Reviewed-by:
-
Jani Nikula authored
To simplify further changes, add separate functions for reading the fsb frequency. This ends up reading CLKCFG register twice, but it's not a big deal. Reviewed-by:
-
Jani Nikula authored
Clarify and unify the logging on not finding PNV CxSR latency config. Just let the i915->fsb_freq == 0 || i915->mem_freq == 0 case go through the table instead of checking for it separately. v2: Do not check for fsb == 0 || mem == 0 separately (Matt) Reviewed-by:
-
Jani Nikula authored
Clarify that the function is specific to PNV, making subsequent changes slightly easier to grasp. Reviewed-by:
-
Jani Nikula authored
It's not possible to use the joiner at the same time with eDP MSO. When a panel needs MSO, it's not optional, so MSO trumps joiner. v3: Only change intel_dp_has_joiner(), leave debugfs alone (Ville) Fixes: bc71194e ("drm/i915/edp: enable eDP MSO during link training") Cc: <stable@vger.kernel.org> # v5.13+ Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1668Reviewed-by:
-
- 14 Jun, 2024 13 commits
-
-
Ville Syrjälä authored
No idea what this MST checks is doing in intel_dp_has_audio(). Looks completely pointless, so get rid of it. Signed-off-by:
-
Ville Syrjälä authored
Disable eDP DSC usage when instructed to do so by the VBT. Signed-off-by:
-
Ville Syrjälä authored
intel_dp_supports_dsc() now works for MST as well, reuse it. Signed-off-by:
-
Ville Syrjälä authored
Reuse intel_dp_has_dsc() during .compute_config() instead of repeating some of the checks again by hand. We'll be adding more checks to intel_dp_has_dsc() and this will make sure we cover both .mode_valid() and .compute_config() with them. Signed-off-by:
-
Ville Syrjälä authored
Utilize intel_dp_has_dsc() for MST as well. Signed-off-by:
-
Ville Syrjälä authored
Extract a helper to check whether the source+sink combo supports DSC. That basic check is needed both during mode validation and compute config. We'll also need to add extra checks to both places, so having a single place for it is nicer. Signed-off-by:
-
Ville Syrjälä authored
If we have no dsc_decompression_aux (only possible on MST) then we won't have the dsc_dpcd caps either. So checking both is not needed. Signed-off-by:
-
Jani Nikula authored
None of these are used. The parametrized register macros all depend on the pipe/plane A offset macros alone. Remove the unused ones. v2: Rebase Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/16d278bea466a69cdce94fd83d98dd15ce1a8c89.1717773890.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Some plane B/C specific bits were left next to the unused _DSPBCNTR macro. Move them next to the DSPCNTR() macro. Reviewed-by:
-
Jani Nikula authored
Do not rely on having dev_priv local variable, pass it to the macro. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.wang.linux@gmail.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by:
Zhi Wang <zhiwang@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/2ff78ebd0dc84178f5feacee7ef2a6cb4132b9ae.1717773890.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Range is a bit odd name for what really is stride. Rename. Switch to u32 while at it. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.wang.linux@gmail.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by:
-
Jani Nikula authored
In order to be able to use the proper register macros instead of the underscore prefixed ones, pass i915_reg_t for the calc_index() parameters. Side note: DSPSURF is really about planes, not pipes. Fixed stride doesn't work for plane C for CHV (but that's okay for gvt). This doesn't support planes beyond C either. But all that is unrelated to the change at hand. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.wang.linux@gmail.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by:
-
Jani Nikula authored
All callers of calc_index() pass 0 for the end parameter. Remove it. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.wang.linux@gmail.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by:
-
- 13 Jun, 2024 16 commits
-
-
Imre Deak authored
Add a connector debugfs entry showing if link retraining is disabled. Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240610164933.2947366-22-imre.deak@intel.com
-
Imre Deak authored
Add a connector debugfs entry to force retrain an active link. This can be used to test both custom link parameters (previously forced via the force_link_rate/lane_count entries) or link train failure scenarios (previously forced via the force_link_training_failure entry). The entry will autoreset after the link-retrain is complete. v2: Add the entry from intel_dp_link_training.c (Jani) v3: Lock connection_mutex only for the required intel_dp state. (Ville) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Add a connector debugfs entry to force a failure during the following 1-2 link training. The entry will auto-reset after the specified link training events are complete. v2: Add the entry from intel_dp_link_training.c (Jani) v3: Lock connection_mutex only for the required intel_dp state. (Ville) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Add connector debugfs entries to get the maximum link rate and lane count. v2: Lock connection_mutex only for the required intel_dp state. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Add connector debugfs entries to force the link rate/lane count to be used by a link training afterwards. These settings will be clamped to the supported, i.e. the source's and sink's common rate/lane count. After forcing the link rate/lane count reset the link training parameters and for a non-auto setting disable reducing the link parameters via the fallback logic. The former one can be used after testing link training failure scenarios - via debugfs entries added later - to reset the reduced link parameters after the test. v2: - Add the entries from intel_dp_link_training.c (Jani) - Rename the entries to i915_dp_set_link_rate/lane_count. v3: (Ville) - Rename the entries/struct fields to force_link_rate/lane_count. - Lock connection_mutex only for the required intel_dp state. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Reduce the link parameters after a link training failure for MST outputs, similarly to how this is done for SST. For now allow the reduction only by staying in the 8b/10b vs. 128b/132b mode. Enabling the mode switch is left for a follow-up patchset, after taking measures ensuring that the mode switch happens properly. In particular a rediscovery of the whole MST topology may be required for such a switch, see the References below. Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10970Reviewed-by:
-
Imre Deak authored
Reset the flag indicating an active link after disabling an MST link, similarly to how this is done for SST outputs. This avoids trying to retrain an MST link while its disabled. Reviewed-by:
-
Imre Deak authored
After a link training failure if the link parameters can't be further reduced, there is no point in trying to retrain the link in the driver. This avoids excessive retrain attempts after detecting a bad link, for instance while handling MST HPD IRQs, which is likely redundant as the link training failed already twice with the same minimum link parameters. Userspace can still try to retrain the link with these parameters via a modeset. While at it make the error message more accurate. v2: Move converting the error to a debug message to the relevant follow-up patch. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: -
Imre Deak authored
Simplify things by retraining a DP link if a bad link is detected in the HPD IRQ handler from the encoder's check link state work, similarly to how this is done after a modeset link training failure. Reviewed-by:
-
Imre Deak authored
Simplify things by retraining a DP link if a bad link is detected in the connector detect handler from the encoder's check link state work, similarly to how this is done after a modeset link training failure. v2: Add TODO: comment to remove the detect-time link state check. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: -
Imre Deak authored
Simplify things by retraining a DP link if a bad link is detected in the hotplug handler from the encoder's check link state work, similarly to how this is done after a modeset link training failure. Reviewed-by:
-
Imre Deak authored
Send a modeset-retry uevent to all connectors in the same MST topology after a link training failure and reduction of the link parameters. This matches the way the same uevent is sent after a DP tunnel BW allocation failure. v2: Add NOTE that the atomic state may not be valid for SST links and assert that it's valid for MST links. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: -
Imre Deak authored
The next patch adds sending a modeset-retry uevent after a link training failure to all MST connectors on link. This requires the atomic state, so pass it to intel_dp_start_link_train(). In case of SST where retraining still happens by calling this function directly instead of a modeset commit the atomic state is not available and NULL is passed instead. This is ok, since in this case the encoder's only DP connector is available from intel_dp->attached_connector not requiring the atomic state. v2: Add NOTE that the atomic state may not be valid for SST links and assert that it's valid for MST links. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:Imre Deak <imre.deak@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240610164933.2947366-10-imre.deak@intel.com
-
Imre Deak authored
Try to maintain the current link parameters by retrying the link training with unchanged link parameters before reducing these parameters (sending an uevent to userspace to retrain the link instead). Signed-off-by:
-
Imre Deak authored
Recheck the link state after a passing link training, with a 2 sec delay to account for cases where the link goes bad following the link training and the sink doesn't report this via an HPD IRQ. The delayed work added here will be also used by a later patch after a failed link training to try to retrain the link with unchanged link params before reducing the link params. v2: Don't flush an uninitialized delayed work (on HDMI-only DDI ports). v3: - Move the helpers to a new intel_encoder.c file, rename them accordingly. (Ville) - Add the work to intel_encoder instead of intel_digital_port. - Call the encoder specific link check function via an encoder hook. - Flush the link check work during encoder destroy from intel_dp_encoder_flush_work(). - Flush the link check work during encoder suspend as well. v4: Call intel_encoder_link_check_init() with a valid encoder pointer. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Instead of direct calls to the link train functions, retrain the link via a commit modeset. The direct call means that the output port will be disabled/re-enabled while the rest of the pipeline (transcoder) is active, which doesn't seem to work on MST at least. It leads to underruns and black screen, presumedly because the transcoder is not disabled/re-enabled along the port. Leave switching to a commit modeset on SST for a later patchset, as that seems to work ok currently (though better to using a commit there too, due to the suppressed underruns). v2: Keep reverse line length order for local variables. (Ville) Reviewed-by:
-
