#
363c3178 |
|
20-Feb-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Factor out intel_dp_read_dprx_caps() Factor out a function to read the sink's DPRX capabilities used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-10-imre.deak@intel.com
|
#
d1e217d4 |
|
20-Feb-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Add support to notify MST connectors to retry modesets On shared (Thunderbolt) links with DP tunnels, the modeset may need to be retried on all connectors on the link due to a link BW limitation arising only after the atomic check phase. To support this add a helper function queuing a work to retry the modeset on a given port's connector and at the same time any MST connector with streams through the same port. A follow-up change enabling the DP tunnel Bandwidth Allocation Mode will take this into use. v2: - Send the uevent only to enabled MST connectors. (Jouni) Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-5-imre.deak@intel.com
|
#
23b392b9 |
|
05-Dec-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select The eDP 1.5 spec adds a clarification for eDP 1.4x: > For eDP v1.4x, if the Source device chooses the Main-Link rate by way > of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0]. We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel to ignore the rate set method. Moreover, 0 is a reserved value for DP_LINK_BW_SET, and should not be used. v2: Improve the comments (Ville) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081 Tested-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205180551.2476228-1-jani.nikula@intel.com
|
#
e6861d82 |
|
05-Dec-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select The eDP 1.5 spec adds a clarification for eDP 1.4x: > For eDP v1.4x, if the Source device chooses the Main-Link rate by way > of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0]. We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel to ignore the rate set method. Moreover, 0 is a reserved value for DP_LINK_BW_SET, and should not be used. v2: Improve the comments (Ville) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081 Tested-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205180551.2476228-1-jani.nikula@intel.com (cherry picked from commit 23b392b94acb0499f69706c5808c099f590ebcf4) Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
3072a24c |
|
03-May-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce crtc_state->enhanced_framing Track DP enhanced framing properly in the crtc state instead of relying just on the cached DPCD everywhere, and hook it up into the state check and dump. v2: Actually set enhanced_framing in .compute_config() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230503113659.16305-1-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
#
95c23e20 |
|
07-Aug-2023 |
Arun R Murthy <arun.r.murthy@intel.com> |
drm/i915/dp: Fix LT debug print in SDP CRC enable The debug print for enabling SDP CRC16 is applicable only for DP2.0, but this debug print was not within the uhbr check and was always printed. Fix this by adding proper checks and returning. v2: Fix typo in commit message (Ankit) Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230808042000.3210715-1-arun.r.murthy@intel.com
|
#
848a4e5c |
|
08-Jun-2023 |
Luca Coelho <luciano.coelho@intel.com> |
drm/i915: add a dedicated workqueue inside drm_i915_private In order to avoid flush_scheduled_work() usage, add a dedicated workqueue in the drm_i915_private structure. In this way, we don't need to use the system queue anymore. This change is mostly mechanical and based on Tetsuo's original patch[1]. v6 by Jani: - Also create unordered_wq for mock device Link: https://patchwork.freedesktop.org/series/114608/ [1] Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c816ebe17ef08d363981942a096a586a7658a65e.1686231190.git.jani.nikula@intel.com
|
#
9831a9d1 |
|
06-Jun-2023 |
Khaled Almahallawy <khaled.almahallawy@intel.com> |
drm/i915/dp: Fix log level for "CDS interlane align done" "CDS interlane align done" is a passing condition not an error. Before adding new macros for logs it was drm_dbg_kms. Fixes: f48eab290287 ("drm/i915/dp: Add link training debug and error printing helpers") Cc: Imre Deak <imre.deak@intel.com> CC: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606224428.3791006-1-khaled.almahallawy@intel.com
|
#
f45156ff |
|
10-May-2023 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Prevent link training fallback on disconnected port Prevent downgrading the link training maximum lane count/rate if the sink is disconnected - and so the link training failure is expected. In such cases modeset failures due to the reduced max link params would be just confusing for user space (instead of which the correct thing it should act on is the sink disconnect signaled by a hotplug event, requiring a disabling modeset). v2: - Check the actual HPD state to handle the forced connector state case. (Vinod) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-11-imre.deak@intel.com
|
#
9031c6d4 |
|
10-May-2023 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Convert link training error to debug message on disconnected sink If a sink is disconnected it's expected that link training actions will fail on it, so downgrade the error messages about such actions to be a debug message. Such - expected - link training failures are more frequent after a follow up patch, after which an active TypeC link is reset after the sink is disconnected which also involves a link training. v2: - Check the actual HPD state to handle the forced connector state case. (Vinod) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-10-imre.deak@intel.com
|
#
f48eab29 |
|
10-May-2023 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Add link training debug and error printing helpers Add functions for printing link training debug and error messages, both to prepare for the next patch, which downgrades an error to a debug message if the sink is disconnected and to remove some code duplication. v2: (Ville) - Always print the connector prefix. - Preserve the drm_dbg_kms() debug category. v3: - Keep printing the name of functions calling the helpers. (Jani) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2) Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-9-imre.deak@intel.com
|
#
f60500f3 |
|
24-Apr-2023 |
Arun R Murthy <arun.r.murthy@intel.com> |
drm/i915/display/dp: 128/132b LT requirement For 128b/132b LT prior to LT DPTX should set power state, DP channel coding and then link rate. v2: added separate function to avoid code duplication(Jani N) v3: DP2.1 section 3.5.2.16 is ordered, 3.5.1.2 is unordered and hence discarding <Ville> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230425025944.151744-1-arun.r.murthy@intel.com
|
#
99cfbed1 |
|
21-Mar-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/vrr: Relocate VRR enable/disable Move VRR enabling/disabling into a place where it also works for fastsets. With this we always start the transcoder up in non-VRR mode. Granted we already did that but for a very short period of time. But now that we might end up doing a bit more with the transcoder in non-VRR mode it seems prudent to also update the active timings as the transcoder changes its operating mode. crtc_state->vrr.enable still tracks whether VRR is actually enabled or not, but now we configure all the other VRR timing registers whenever VRR is possible (whether we actually enable it or not). crtc_state->vrr.flipline can now serve as our "is VRR possible" bit of state. I decided to leave the MSA timing ignore bit set all the time whether VRR is actually enabled or not. If the sink can figure out the timings with that information when VRR is active then surely it can also do it when VRR is inactive. v2: Protect intel_vrr_set_transcoder_timings() with HAS_VRR() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230321135615.27338-1-ville.syrjala@linux.intel.com Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
1a324a40 |
|
02-Mar-2023 |
Arun R Murthy <arun.r.murthy@intel.com> |
i915/display/dp: SDP CRC16 for 128b132b link layer Enable SDP error detection configuration, this will set CRC16 in 128b/132b link layer. For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is added to enable/disable SDP CRC applicable for DP2.0 only, but the default value of this bit will enable CRC16 in 128b/132b hence skipping this write. Corrective actions on SDP corruption is yet to be defined. v2: Moved the CRC enable to link training init(Jani N) v3: Moved crc enable to ddi pre enable <Jani N> v4: Separate function for SDP CRC16 (Jani N) Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230302081532.765821-3-arun.r.murthy@intel.com
|
#
c7d18b40 |
|
15-Feb-2023 |
Vinod Govindapillai <vinod.govindapillai@intel.com> |
drm/i915/display: ignore link training failures in CI If the ignore long HPD flag is set, ignore the link training failures as well. Because of spurious HPDs, some unexpected link training failures are happening while executing IGT test cases. Ignore the link training failures for the time being if the long HPDs are also ignored in the environments like CI. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230215083832.287519-3-vinod.govindapillai@intel.com
|
#
fb4651f9 |
|
08-Mar-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't send idle pattern after DP2.0 link training Bspec calls us to select pattern 2 after link training for DP 2.0. Let's do that... by doing nothing because we will be transmitting pattern 2 at the end of the link training already. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230308212627.7601-2-ville.syrjala@linux.intel.com
|
#
7573e657 |
|
12-Sep-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: use drm_dp_phy_name() for logging Drop the local intel_dp_phy_name() function, and replace with drm_dp_phy_name(). This lets us drop a number of local buffers. v2: Rebase Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220912132313.2774603-1-jani.nikula@intel.com
|
#
25899c59 |
|
02-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement WaEdpLinkRateDataReload A lot of modern laptops use the Parade PS8461E MUX for eDP switching. The MUX can operate in jitter cleaning mode or redriver mode, the first one resulting in higher link quality. The jitter cleaning mode needs to know the link rate used and the MUX achieves this by snooping the LINK_BW_SET, LINK_RATE_SELECT and SUPPORTED_LINK_RATES DPCD accesses. When the MUX is powered down (seems this can happen whenever the display is turned off) it loses track of the snooped link rates so when we do the LINK_RATE_SELECT write it no longer knowns which link rate we're selecting, and thus it falls back to the lower quality redriver mode. This results in unstable high link rates (eg. usually 8.1Gbps link rate no longer works correctly). In order to avoid all that let's re-snoop SUPPORTED_LINK_RATES from the sink at the start of every link training. Unfortunately we don't have a way to detect the presence of the MUX. It looks like the set of laptops equipped with this MUX is fairly large and contains devices from multiple manufacturers. It may also still be growing with new models. So a quirk doesn't seem like a very easily maintainable option, thus we shall attempt to do this unconditionally on all machines that use LINK_RATE_SELECT. Hopefully this extra DPCD read doesn't cause issues for any unaffected machine. If that turns out to be the case we'll need to convert this into a quirk in the future. Cc: stable@vger.kernel.org Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902070319.15395-1-ville.syrjala@linux.intel.com Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
672d6ca7 |
|
02-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement WaEdpLinkRateDataReload A lot of modern laptops use the Parade PS8461E MUX for eDP switching. The MUX can operate in jitter cleaning mode or redriver mode, the first one resulting in higher link quality. The jitter cleaning mode needs to know the link rate used and the MUX achieves this by snooping the LINK_BW_SET, LINK_RATE_SELECT and SUPPORTED_LINK_RATES DPCD accesses. When the MUX is powered down (seems this can happen whenever the display is turned off) it loses track of the snooped link rates so when we do the LINK_RATE_SELECT write it no longer knowns which link rate we're selecting, and thus it falls back to the lower quality redriver mode. This results in unstable high link rates (eg. usually 8.1Gbps link rate no longer works correctly). In order to avoid all that let's re-snoop SUPPORTED_LINK_RATES from the sink at the start of every link training. Unfortunately we don't have a way to detect the presence of the MUX. It looks like the set of laptops equipped with this MUX is fairly large and contains devices from multiple manufacturers. It may also still be growing with new models. So a quirk doesn't seem like a very easily maintainable option, thus we shall attempt to do this unconditionally on all machines that use LINK_RATE_SELECT. Hopefully this extra DPCD read doesn't cause issues for any unaffected machine. If that turns out to be the case we'll need to convert this into a quirk in the future. Cc: stable@vger.kernel.org Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902070319.15395-1-ville.syrjala@linux.intel.com Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 25899c590cb5ba9b9f284c6ca8e7e9086793d641) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
eddbb074 |
|
08-Apr-2022 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links To avoid AUX timeouts and subsequent spurious hotplug interrupts, make sure that the first DPCD access during detection is a read from an LTTPR register. Some ADLP DP link configuration at least with multiple LTTPRs expects the first DPCD access during the LTTPR/DPCD detection after hotplug to be a read from the LTTPR range starting with DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of this read is to put each LTTPR into the LTTPR transparent or LTTPR non-transparent mode. The lack of the above read may leave some of the LTTPRs in non-LTTPR mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent mode (for instance LTTPRs after system suspend/resume that kept their mode from before suspend). Due to the different AUX timeouts the different modes imply, the DPCD access from a non-LTTPR range will timeout and lead to an LTTPR generated hotplug towards the source (which the LTTPR firmware uses to account for buggy TypeC adapters with a long wake-up delay). SYSCROS: 72939 v2: Keep DPCD read-out working on non-LTTPR platforms. v3: Summarize what and why the patch does at the beginning of the commit log. (Jani) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220408224629.845887-1-imre.deak@intel.com
|
#
657586e4 |
|
22-Mar-2022 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted DPCD register values when reading from the 0xF0000- LTTPR range with an AUX transaction block size bigger than 1. The DP standard requires 0 to be returned - as for any other reserved/invalid addresses - but these monitors return the DPCD_REV register value repeated in each byte of the read buffer. This will in turn corrupt the values returned by the LTTPRs between the source and the monitor: LTTPRs must adjust the values they read from the downstream DPRX, for instance right-shift/init the downstream DP_PHY_REPEATER_CNT value. Since the value returned by the monitor's DPRX is non-zero the adjusted values will be corrupt. Reading the LTTPR registers one-by-one instead of reading all of them with a single AUX transfer works around the issue. According to the DP standard's 0xF0000 register description: "LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for DPCD r1.4 (or higher)." While it's unclear if DPCD r1.4 refers to the DPCD_REV or to the LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV register (tickets filed at the VESA site to clarify this haven't been addressed), one possibility is that it's a restriction due to non-compliant monitors described above. Disabling the non-transparent LTTPR mode for all such monitors is not a viable solution: the transparent LTTPR mode has its own issue causing link training failures and this would affect a lot of monitors in use with DPCD_REV < 1.4. Instead this patch works around the problem by reading the LTTPR common and PHY cap registers one-by-one for any monitor with a DPCD_REV < 1.4. The standard requires the DPCD capabilities to be read after the LTTPR common capabilities are read, so re-read the DPCD capabilities after the LTTPR common and PHY caps were read out. v2: - Use for instead of a while loop. (Ville) - Add to code comment the monitor model with the problem. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4531 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322143844.42616-1-imre.deak@intel.com
|
#
77f4ec2a |
|
17-Feb-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: remove accidental static on what should be a local variable The variable should obviously be local, not static. Fixes: a421d8a99216 ("drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217083938.3587465-1-jani.nikula@intel.com
|
#
3ee7fab0 |
|
03-Feb-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: add 128b/132b support to link status checks Abstract link status check to a function that takes 128b/132b and 8b/10b into account, and use it. Also dump link status on failures. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cec395d435679a290a1c35fcbfc54555101bfad1.1643878928.git.jani.nikula@intel.com
|
#
a421d8a9 |
|
08-Feb-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata The DP 2.0 errata completely overhauls the 128b/132b link training, with no provisions for backward compatibility with the original DP 2.0 specification. The changes are too intrusive to consider reusing the same code for both 8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is done concurrently instead of serialized. NOTES: * It's a bit unclear when to wait for DP_INTERLANE_ALIGN_DONE and per-lane DP_LANE_SYMBOL_LOCKED. Figure xx4 in the SCR implies the LANEx_CHANNEL_EQ_DONE sequence may end with either 0x77,0x77,0x85 *or* 0x33,0x33,0x84 (for four lane configuration in DPCD 0x202..0x204) i.e. without the above bits set. Text elsewhere seems contradictory or incomplete. * We read entire link status (6 bytes) everywhere instead of individual DPCD addresses. * There are some subtle ambiguities or contradictions in the order of some DPCD access and TPS signal enables/disables. It's also not clear whether these are significant. v4: - Wait for intra-hop clear after link training end (Ville) - Wait instead of single check for intra-hop clear before link train v3: - Use msecs_to_jiffies_timeout() (Ville) - Read status at the beginning of interlane align done loop (Ville) - Try to simplify timeout flag use where possible (Ville) v2: - Always try one last time after timeouts to avoid races (Ville) - Extend timeout to cover the entire LANEx_EQ_DONE sequence (Ville) - Also check for eq interlane align done in LANEx_CDS_DONE Sequence (Ville) - Check for Intra-hop status before link training Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220208143209.2997337-1-jani.nikula@intel.com
|
#
92e43861 |
|
03-Feb-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: move intel_dp_prepare_link_train() call Call it from the higher level function, as it will be shared between two code paths. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c0fffbf7213c09e42be9875d38d3001e0026b063.1643878928.git.jani.nikula@intel.com
|
#
15162c5a |
|
01-Dec-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: stop including i915_drv.h from intel_display_types.h Break the dependency on i915_drv.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ee740f494e416d875e057c2eda585f4e66d65500.1638366969.git.jani.nikula@intel.com
|
#
88a24415 |
|
06-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable per-lane drive settings for icl+ Now that the link buf_trans, link training, and the combo/mg/dkl/snps phy programming are all fixed up we can allow per-lane DP drive settings on icl+. Make it so. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-13-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
b7d5abda |
|
14-Oct-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: use new link training delay helpers Use the new link training delay helpers, fixing the delays for 128b/132b. For existing 8b/10b functionality, this will cause additional 1-byte DPCD reads for LTTPR delays instead of using the cached values. It's just too complicated to combine generic helpers with local caching in a sensible way. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014150059.28957-3-jani.nikula@intel.com
|
#
5c31e9d0 |
|
11-Oct-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dg2: update link training for 128b/132b The 128b/132b channel coding link training uses more straightforward TX FFE preset values. Reuse voltage tries and max vswing for retry logic. The delays for 128b/132b are still all wrong, but this is regardless a step forward. v2: Fix UHBR rate checks, use intel_dp_is_uhbr() helper v3: - Rebase - Modify intel_dp_adjust_request_changed() and intel_dp_link_max_vswing_reached() to take 128b/132b into account. (Ville) v4: - Train request printing for TX FFE (Ville) - Log 8b/10b vs. 128b/132b (Ville) - Add helper for per-lane max vswing / tx ffe (Ville) - Name functions with tx_ffe/vswing instead of 128b132b/8b10b Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211011182144.22074-2-jani.nikula@intel.com
|
#
319f4def |
|
11-Oct-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: abstract intel_dp_lane_max_vswing_reached() Add per-lane abstraction for max vswing reached to make follow-up cleaner, as this one reverses the conditions. v2: both conditions need to be true, reverse (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211011182144.22074-1-jani.nikula@intel.com
|
#
210de399 |
|
04-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Call intel_dp_dump_link_status() for CR failures I suppose intel_dp_dump_link_status() might be useful for diagnosing link training failures. Hoever we only call from the channel EQ phase currently. Let's call it from the CR phase as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-6-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
6c4d4652 |
|
04-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pimp link training debug prints Unify all debug prints during link training to include information on both the encoder and the LTTPR. We unify the format to something like "[ENCODER:1:FOO][LTTPR 1] Something something". Though not sure if those brackets around the dp_phy just make it look like line noise? I'll accept suggestions on better formatting. I'm slightly on the fence about also including the connector, but technically only the DPRX is the SST connector (ie. intel_dp->attached_connector). I suppose you could think of it as the branch device/whatever in the topology, and we're training the link leading to it. So that could argue for its inclusion. But it's all getting a bit long alrady, so not going to do it I think. v2: Keep the connector name in the final passed/failed debug print Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-5-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
1f662675 |
|
04-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Print the DP vswing adjustment request Print out each DP vswing adjustment request we got from the RX. Could help in diagnosing what's going on during link training. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-4-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
be152504 |
|
04-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Show LTTPR in the TPS debug print Indicate which LTTPR we're currently attempting to train when we print which training pattern we're using. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
8bc2f5c3 |
|
04-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Tweak the DP "max vswing reached?" condition Currently we consider the max vswing reached when we transmit a the max voltage level, but we don't consider pre-emphasis at all. This kinda matches older DP specs that only had some vague text about transmitting the maximum voltage swing. Latest versions now say something vague about consider the sum of the vswing and pre-emphasis fields in the ADJUST_REQUEST_LANE registers. Very vague, and super confusing especially the fact that it talks about transmitted voltgage swing in the same sentence as it say to look at the requested values. Also glanced at the link CTS spec, and that one seems to have tests that assume contradicting behaviour. Some say to consider just the vswing level we transmit, others say to check for sum of transmitted vswing+preemph being 3. So let's try to take some kind of sane middle ground here. I think what could make sense is only consider max vswing reached if MAX_SWING_REACHED==1 _and_ vswing+preemph==3. That will allow things to go all the way up to vswing 3 + pre-emph 0 or vswing 2 + pre-emph 1, depending on what the maximum supported vswing is. Only considering the sum of vswing+pre-emph doesn't make much sense to me since we could terminate too early if the sink requests eg. vswing 0 + pre-emph 3. And if we'd stick to the current code we could terminate too early of the sink asks for vswing 2 + pre-emph 0 when vswing level 3 is not supported. Side note: I don't really understand why any of this stuff is "specified" at all. There is already a limit of 5 attempts at the same vswing+pre-emph level, and a total limit of 10 attempts. So might as well stick to the same max 5 attempts across the board IMO. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004170535.4173-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
104c1b3d |
|
01-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Allow per-lane drive settings with LTTPRs LTTPRs should support per-lane drive settings I think, and even if they don't they should implement their own fallback logic to determine suitable common drive settings to use for all the lanes. v2: Actually check the correct thing Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-11-ville.syrjala@linux.intel.com
|
#
c6921d48 |
|
01-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Prepare link training for per-lane drive settings Adjust the link training code to accommodate per-lane drive settings, if supported by the platform. Actually enabling this will involve some changes to each platform's .set_signal_level() implementation, so for the moment all supported platforms will keep using the current codepath that just uses the same drive settings for all the lanes. v2: Fix min() vs. max() fumble v3: Compact the debug print to a single line Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-10-ville.syrjala@linux.intel.com
|
#
e722ab8b |
|
01-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Generalize .set_signal_levels() Currently .set_signal_levels() is only used by encoders in DP mode. For most modern platforms there is no essential difference between DP and HDMI, and both codepaths just end up calling the same function under the hood. Let's get remove the need for that extra indirection by moving .set_signal_levels() into the encoder from intel_dp. Since we already plumb the crtc_state/etc. into .set_signal_levels() the code will do the right thing for both DP and HDMI. HSW/BDW/SKL are the only platforms that need a bit of care on account of having to preload the hardware buf_trans register with the full set of values. So we must still remember to call hsw_prepare_{dp,hdmi}_ddi_buffers() to do said preloading, and .set_signal_levels() will just end up selecting the correct entry for DP, and also setting up the iboost magic for both DP and HDMI. Note that previously on HSW/BDW/SKL we did write to DDI_BUF_CTL to select the correct entry until link training started, now that we call .set_signal_levels() already from hsw_ddi_pre_enable_dp() that is no longer the case. But it's all safe now that the intel_ddi_init_dp_buf_reg() call was hoisted up and it no longer sets up the DDI_BUF_CTL_ENABLE bit (that is still deferred until link training). v2: Rebase due to has_{iboost,buf_trans_select}() Add some notes about the DDI_BUF_CTL situation on HSW/BDW/SKL (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-4-ville.syrjala@linux.intel.com
|
#
f6e3be98 |
|
01-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix DP clock recovery "voltage_tries" handling The DP spec says: "If the receiver keeps the same value in the ADJUST_REQUEST_LANEx_y register(s) while the LANEx_CR_DONE bits remain unset, the transmitter must loop four times with the same voltage swing. On the fifth time, the transmitter must down-shift to the lower bit rate and must repeat the CR-lock training sequence as described below." Lets fix the code to follow that instead of terminating after five times of transmitting the same signal levels. The text in spec feels a little bit ambiguous still, but this is my best guess at its meaning. As a bonus this also gets rid of the train_set[0] stuff which would not work for per-lane drive settings anyway. Cc: Imre Deak <imre.deak@intel.com> CC: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001160826.17080-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
8a1ec3f3 |
|
30-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove DP_PORT_EN stuff from link training code Setting DP_PORT_EN in intel_dp->DP is already handled by intel_dp_enable_port() so there is no point in setting it also from the link training code. For DDI platforms a bit with that name doesn't even exist. The counterpart is DDI_BUF_CTL_ENABLE, which is already set up by intel_ddi_prepare_link_retrain(). Fortunately it is the same bit so there was no harm in doing this from the platform independent code as well. But it's just confusing when platform independent code sets platform specific bits in intel_dp->DP. Just get rid of it. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930134310.31669-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak.intel.com>
|
#
1e39da5a |
|
29-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable TPS3/4 on all platforms that support them Stop using HBR2/3 support as a proxy for TPS3/4 support. The two are no longer 1:1 in the hardware, arguably they never were due to HSW ULX which does support TPS3 while being limited to HBR1. In more recent times GLK gained support for TPS4 while being limited to HBR2. And on CNL+ some ports support HBR3 while others are limited to HBR2, but all ports support TPS4. v2: s/INTEL_GEN/DISPLAY_VER/ Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929162404.6717-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
6114f71b |
|
09-Sep-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: select 128b/132b channel encoding for UHBR rates UHBR rates and 128b/132b channel encoding go hand in hand. v2: Fix check for >= UHBR rates using intel_dp_is_uhbr() (Ville) Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b4ffd0187b306c0abaa08b89ed35c993ad8145c7.1631191763.git.jani.nikula@intel.com
|
#
078397bb |
|
09-Sep-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: use 128b/132b TPS2 for UHBR+ link rates 128b/132b channel encoding has separate TPS1 and TPS2, although the DPCD register values coincide with 8b/10b TPS1 and TPS2 values. Use 128b/132b TPS2 for channel equalization. v2: Use intel_dp_is_uhbr Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> # v1 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/723b29223dc570c8b63c3c6fe5fb772d9db06c0d.1631191763.git.jani.nikula@intel.com
|
#
dab1b47e |
|
06-Jul-2021 |
Lee Shawn C <shawn.c.lee@intel.com> |
drm/i915/dp: return proper DPRX link training result After DPRX link training, intel_dp_link_train_phy() did not return the training result properly. If link training failed, i915 driver would not run into link train fallback function. And no hotplug uevent would be received by user space application. Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210706152541.25021-1-shawn.c.lee@intel.com
|
#
d8959fb3 |
|
16-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: remove superfluous EXPORT_SYMBOL() The symbol isn't needed outside of i915.ko. Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210816071737.2917-1-jani.nikula@intel.com
|
#
9af4bf21 |
|
06-Jul-2021 |
Lee Shawn C <shawn.c.lee@intel.com> |
drm/i915/dp: return proper DPRX link training result After DPRX link training, intel_dp_link_train_phy() did not return the training result properly. If link training failed, i915 driver would not run into link train fallback function. And no hotplug uevent would be received by user space application. Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210706152541.25021-1-shawn.c.lee@intel.com (cherry picked from commit dab1b47e57e053b2a02c22ead8e7449f79961335) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
e3e86f41 |
|
16-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: remove superfluous EXPORT_SYMBOL() The symbol isn't needed outside of i915.ko. Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210816071737.2917-1-jani.nikula@intel.com (cherry picked from commit d8959fb33890ba1956c142e83398e89812450ffc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
cb4920cc |
|
12-May-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4 The driver currently disables the LTTPR non-transparent link training mode for sinks with a DPCD_REV<1.4, based on the following description of the LTTPR DPCD register range in DP standard 2.0 (at the 0xF0000 register description): "" LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for DPCD r1.4 (or higher). """ The transparent link training mode should still work fine, however the implementation for this in some retimer FWs seems to be broken, see the References: link below. After discussions with DP standard authors the above "DPCD r1.4" does not refer to the DPCD revision (stored in the DPCD_REV reg at 0x00000), rather to the "LTTPR field data structure revision" stored in the 0xF0000 reg. An update request has been filed at vesa.org (see wg/Link/documentComment/3746) for the upcoming v2.1 specification to clarify the above description along the following lines: """ LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 1.4 (or higher) """ Based on my tests Windows uses the non-transparent link training mode for DPCD_REV==1.2 sinks as well (so presumably for all DPCD_REVs), and forcing it to use transparent mode on ICL/TGL platforms leads to the same LT failure as reported at the References: link. Based on the above let's assume that the transparent link training mode is not well tested/supported and align the code to the correct interpretation of what the r1.4 version refers to. Reported-and-tested-by: Casey Harkins <caseyharkins@gmail.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3415 Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") Cc: <stable@vger.kernel.org> # v5.11+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512212809.1234701-1-imre.deak@intel.com
|
#
0c4fada6 |
|
23-Apr-2021 |
Lyude Paul <lyude@redhat.com> |
drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay() So that we can start using drm_dbg_*() for drm_dp_link_train_channel_eq_delay() and drm_dp_lttpr_link_train_channel_eq_delay(). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-7-lyude@redhat.com Reviewed-by: Dave Airlie <airlied@redhat.com>
|
#
9e986666 |
|
23-Apr-2021 |
Lyude Paul <lyude@redhat.com> |
drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay() So that we can start using drm_dbg_*() in drm_dp_link_train_clock_recovery_delay(). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-6-lyude@redhat.com Reviewed-by: Dave Airlie <airlied@redhat.com>
|
#
770d4c71 |
|
12-Apr-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Drop redundant address-of op before lttpr_common_caps array The address-of op in front of an array is just an alias to using the array on its own, so drop the op. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-2-imre.deak@intel.com
|
#
e42e7e58 |
|
12-Apr-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Fix modesetting in case of unexpected AUX timeouts In case AUX failures happen unexpectedly during a modeset, the driver should still complete the modeset. In particular the driver should perform the link training sequence steps even in case of an AUX failure, as this sequence also includes port initialization steps. Not doing that can leave the port/pipe in a broken state and lead for instance to a flip done timeout. Fix this by continuing with link training (in a no-LTTPR mode) if the DPRX DPCD readout failed for some reason at the beginning of link training. After a successful connector detection we already have the DPCD read out and cached, so the failed repeated read for it should not cause a problem. Note that a partial AUX read could in theory partly overwrite the cached DPCD (and return error) but this overwrite should not happen if the returned values are corrupted (due to a timeout or some other IO error). Kudos to Ville to root cause the problem. Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308 Cc: stable@vger.kernel.org # 5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-1-imre.deak@intel.com
|
#
543d592a |
|
11-Apr-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disable LTTPR detection on GLK once again The glk display version change is causing us to again attempt LTTPR detection on glk. We must not do tha since glk doesn't have a long enough AUX timeout. Restore the correct logic to skip the detection. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 2b5a4562edd0 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-4-ville.syrjala@linux.intel.com
|
#
e1185142 |
|
12-May-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4 The driver currently disables the LTTPR non-transparent link training mode for sinks with a DPCD_REV<1.4, based on the following description of the LTTPR DPCD register range in DP standard 2.0 (at the 0xF0000 register description): "" LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for DPCD r1.4 (or higher). """ The transparent link training mode should still work fine, however the implementation for this in some retimer FWs seems to be broken, see the References: link below. After discussions with DP standard authors the above "DPCD r1.4" does not refer to the DPCD revision (stored in the DPCD_REV reg at 0x00000), rather to the "LTTPR field data structure revision" stored in the 0xF0000 reg. An update request has been filed at vesa.org (see wg/Link/documentComment/3746) for the upcoming v2.1 specification to clarify the above description along the following lines: """ LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 1.4 (or higher) """ Based on my tests Windows uses the non-transparent link training mode for DPCD_REV==1.2 sinks as well (so presumably for all DPCD_REVs), and forcing it to use transparent mode on ICL/TGL platforms leads to the same LT failure as reported at the References: link. Based on the above let's assume that the transparent link training mode is not well tested/supported and align the code to the correct interpretation of what the r1.4 version refers to. Reported-and-tested-by: Casey Harkins <caseyharkins@gmail.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3415 Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") Cc: <stable@vger.kernel.org> # v5.11+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512212809.1234701-1-imre.deak@intel.com (cherry picked from commit cb4920cc40f630b5a247f4ed7d3dea66749df588) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
36c119c1 |
|
11-Apr-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disable LTTPR detection on GLK once again The glk display version change is causing us to again attempt LTTPR detection on glk. We must not do tha since glk doesn't have a long enough AUX timeout. Restore the correct logic to skip the detection. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 2b5a4562edd0 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-4-ville.syrjala@linux.intel.com (cherry picked from commit 543d592a73d3948737d0ae4880a407c6da28662f) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
005e9537 |
|
19-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate most usage of INTEL_GEN() Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN() in the display code to use DISPLAY_VER() comparisons instead. The following semantic patch was used: @@ expression dev_priv, E; @@ - INTEL_GEN(dev_priv) == E + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; @@ - INTEL_GEN(dev_priv) + DISPLAY_VER(dev_priv) @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_DISPLAY_RANGE(dev_priv, from, until) There are still some display-related uses of INTEL_GEN() in intel_pm.c (watermark code) and i915_irq.c. Those will be updated separately. v2: - Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
|
#
b2ef0661 |
|
18-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Relocate intel_dp_program_link_training_pattern() intel_dp_program_link_training_pattern() clearly belongs in intel_dp_link_training.c. Make it so. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-4-ville.syrjala@linux.intel.com
|
#
1663ad49 |
|
17-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Disable LTTPR support when the LTTPR rev < 1.4 By the specification the 0xF0000 - 0xF02FF range is only valid if the LTTPR revision at 0xF0000 is at least 1.4. Disable the LTTPR support otherwise. Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Cc: <stable@vger.kernel.org> # v5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-4-imre.deak@intel.com
|
#
264613b4 |
|
17-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Disable LTTPR support when the DPCD rev < 1.4 By the specification the 0xF0000-0xF02FF range is only valid when the DPCD revision is 1.4 or higher. Disable LTTPR support if this isn't so. Trying to detect LTTPRs returned corrupted values for the above DPCD range at least on a Skylake host with an LG 43UD79-B monitor with a DPCD revision 1.2 connected. v2: Add the actual version check. v3: Fix s/DRPX/DPRX/ typo. Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Cc: <stable@vger.kernel.org> # v5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317190149.4032966-1-imre.deak@intel.com
|
#
984982f3 |
|
17-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915/ilk-glk: Fix link training on links with LTTPRs The spec requires to use at least 3.2ms for the AUX timeout period if there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming spec update makes this more specific, by requiring a 3.2ms minimum timeout period for the LTTPR detection reading the 0xF0000-0xF0007 range (3.6.5.1). Accordingly disable LTTPR detection until GLK, where the maximum timeout we can set is only 1.6ms. Link training in the non-transparent mode is known to fail at least on some SKL systems with a WD19 dock on the link, which exposes an LTTPR (see the References below). While this could have different reasons besides the too short AUX timeout used, not detecting LTTPRs (and so not using the non-transparent LT mode) fixes link training on these systems. While at it add a code comment about the platform specific maximum timeout values. v2: Add a comment about the g4x maximum timeout as well. (Ville) Reported-by: Takashi Iwai <tiwai@suse.de> Reported-and-tested-by: Santiago Zarate <santiago.zarate@suse.com> Reported-and-tested-by: Bodo Graumann <mail@bodograumann.de> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166 Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: <stable@vger.kernel.org> # v5.11 Cc: Takashi Iwai <tiwai@suse.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-2-imre.deak@intel.com
|
#
41ed4005 |
|
10-Mar-2021 |
Sean Paul <seanpaul@chromium.org> |
drm/i915/dp_link_training: Convert DRM_DEBUG_KMS to drm_dbg_kms One instance of DRM_DEBUG_KMS was leftover in dp_link_training, convert it to the new shiny. Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210310214845.29021-2-sean@poorly.run
|
#
65e3fe10 |
|
10-Mar-2021 |
Sean Paul <seanpaul@chromium.org> |
drm/i915/dp_link_training: Add newlines to debug messages This patch adds some newlines which are missing from debug messages. This will prevent logs from being stacked up in dmesg. Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210310214845.29021-1-sean@poorly.run
|
#
d2b9935d |
|
12-Apr-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Fix modesetting in case of unexpected AUX timeouts In case AUX failures happen unexpectedly during a modeset, the driver should still complete the modeset. In particular the driver should perform the link training sequence steps even in case of an AUX failure, as this sequence also includes port initialization steps. Not doing that can leave the port/pipe in a broken state and lead for instance to a flip done timeout. Fix this by continuing with link training (in a no-LTTPR mode) if the DPRX DPCD readout failed for some reason at the beginning of link training. After a successful connector detection we already have the DPCD read out and cached, so the failed repeated read for it should not cause a problem. Note that a partial AUX read could in theory partly overwrite the cached DPCD (and return error) but this overwrite should not happen if the returned values are corrupted (due to a timeout or some other IO error). Kudos to Ville to root cause the problem. Fixes: 7dffbdedb96a ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308 Cc: stable@vger.kernel.org # 5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-1-imre.deak@intel.com (cherry picked from commit e42e7e585984b85b0fb9dd1fefc85ee4800ca629) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [adjusted Fixes: tag]
|
#
ab036310 |
|
17-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Disable LTTPR support when the LTTPR rev < 1.4 By the specification the 0xF0000 - 0xF02FF range is only valid if the LTTPR revision at 0xF0000 is at least 1.4. Disable the LTTPR support otherwise. Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Cc: <stable@vger.kernel.org> # v5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-4-imre.deak@intel.com (cherry picked from commit 1663ad4936e0679443a315fe342f99636a2420dd) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
7dffbded |
|
17-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Disable LTTPR support when the DPCD rev < 1.4 By the specification the 0xF0000-0xF02FF range is only valid when the DPCD revision is 1.4 or higher. Disable LTTPR support if this isn't so. Trying to detect LTTPRs returned corrupted values for the above DPCD range at least on a Skylake host with an LG 43UD79-B monitor with a DPCD revision 1.2 connected. v2: Add the actual version check. v3: Fix s/DRPX/DPRX/ typo. Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Cc: <stable@vger.kernel.org> # v5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317190149.4032966-1-imre.deak@intel.com (cherry picked from commit 264613b406eb0d74cd9ca582c717c5e2c5a975ea) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
3f3a9bc1 |
|
17-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915/ilk-glk: Fix link training on links with LTTPRs The spec requires to use at least 3.2ms for the AUX timeout period if there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming spec update makes this more specific, by requiring a 3.2ms minimum timeout period for the LTTPR detection reading the 0xF0000-0xF0007 range (3.6.5.1). Accordingly disable LTTPR detection until GLK, where the maximum timeout we can set is only 1.6ms. Link training in the non-transparent mode is known to fail at least on some SKL systems with a WD19 dock on the link, which exposes an LTTPR (see the References below). While this could have different reasons besides the too short AUX timeout used, not detecting LTTPRs (and so not using the non-transparent LT mode) fixes link training on these systems. While at it add a code comment about the platform specific maximum timeout values. v2: Add a comment about the g4x maximum timeout as well. (Ville) Reported-by: Takashi Iwai <tiwai@suse.de> Reported-and-tested-by: Santiago Zarate <santiago.zarate@suse.com> Reported-and-tested-by: Bodo Graumann <mail@bodograumann.de> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166 Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: <stable@vger.kernel.org> # v5.11 Cc: Takashi Iwai <tiwai@suse.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-2-imre.deak@intel.com (cherry picked from commit 984982f3ef7b240cd24c2feb2762d81d9d8da3c2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
3b7bbb36 |
|
18-Jan-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Prevent setting the LTTPR LT mode if no LTTPRs are detected Atm, the driver programs explicitly the default transparent link training mode (0x55) to DP_PHY_REPEATER_MODE even if no LTTPRs are detected. This conforms to the spec (3.6.6.1): "DP upstream devices that do not enable the Non-transparent mode of LTTPRs shall program the PHY_REPEATER_MODE register (DPCD Address F0003h) to 55h (default) prior to link training" however writing the default value to this DPCD register seems to cause occasional link training errors at least for a DELL WD19TB TBT dock, when no LTTPRs are detected. Writing to DP_PHY_REPEATER_MODE will also cause an unnecessary timeout on systems without any LTTPR. To fix the above two issues let's assume that setting the default mode is redundant when no LTTPRs are detected. Keep the existing behavior and program the default mode if more than 8 LTTPRs are detected or in case the read from DP_PHY_REPEATER_CNT returns an invalid value. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2801 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210118183143.1145707-1-imre.deak@intel.com
|
#
1639406a |
|
22-Jan-2021 |
Manasi Navare <manasi.d.navare@intel.com> |
drm/i915/display/vrr: Set IGNORE_MSA_PAR state in DP Sink If VRR is enabled, the sink should ignore MSA parameters and regenerate incoming video stream without depending on these parameters. Hence set the MSA_TIMING_PAR_IGNORE_EN bit if VRR is enabled. Reset this bit on VRR disable. v2: * ACtually set the dpcd msa ignore bit (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-13-manasi.d.navare@intel.com
|
#
147819f6 |
|
18-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disable TRAINING_PATTERN_SET before stopping the TPS transmission DP spec says: "The Source device shall start sending the idle pattern after it has cleared the Training_Pattern byte in the DPCD." Currently we do these in operations in the opposite order. Swap them around to match the spec. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210118162107.18424-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
67fba3f1 |
|
29-Dec-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode The DP PHY vswing/pre-emphasis level programming the driver does is related to the DPTX -> first LTTPR link segment only. Accordingly it should be only programmed when link training the first LTTPR and kept as-is when training subsequent LTTPRs and the DPRX. For these latter PHYs the vs/pe levels will be set in response to writing the DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY). The above is also described in DP Standard v2.0 under 3.6.6.1. While at it simplify and add the LTTPR that is link trained to the debug message in intel_dp_set_signal_levels(). Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-2-imre.deak@intel.com
|
#
1c6e527d |
|
29-Dec-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.c intel_dp_set_signal_levels() is needed for link training, so move it to intel_dp_link_training.c. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-1-imre.deak@intel.com
|
#
88ebe1f5 |
|
29-Dec-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode The DP PHY vswing/pre-emphasis level programming the driver does is related to the DPTX -> first LTTPR link segment only. Accordingly it should be only programmed when link training the first LTTPR and kept as-is when training subsequent LTTPRs and the DPRX. For these latter PHYs the vs/pe levels will be set in response to writing the DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY). The above is also described in DP Standard v2.0 under 3.6.6.1. While at it simplify and add the LTTPR that is link trained to the debug message in intel_dp_set_signal_levels(). Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-2-imre.deak@intel.com (cherry picked from commit 67fba3f1c73b83569d171ae1fa463a537bbfe0a8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
2051c890 |
|
29-Dec-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.c intel_dp_set_signal_levels() is needed for link training, so move it to intel_dp_link_training.c. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-1-imre.deak@intel.com (cherry picked from commit 1c6e527d6947ea77bebabe15bbeaa765a87b70ca) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
b30edfd8 |
|
07-Oct-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Switch to LTTPR non-transparent mode link training The DP Standard's recommendation is to use the LTTPR non-transparent mode link training if LTTPRs are detected, so let's do this. Besides power-saving, the advantages of this are that the maximum number of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in transparent mode), and it provides a way to narrow down the reason for a link training failure to a given link segment. Non-transparent mode is probably also the mode that was tested the most by the industry. The changes in this patchset: - Pass the DP PHY that is currently link trained to all LT helpers, so that these can access the correct LTTPR/DPRX DPCD registers. - During LT take into account the LTTPR common lane rate/count and the per LTTPR-PHY vswing/pre-emph limits. - Switch to LTTPR non-transparent LT mode and train each link segment according to the sequence in DP Standard v2.0 (complete CR/EQ for each segment before continuing with the next segment). v2: - Switch to non-transparent mode during connector detection, which is required before reading the per-PHY LTTPR capabilities. - Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville) - Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the same logic to intel_dp_get_link_status(). (Ville) - Make intel_dp_lttpr_phy_caps() return a pointer to the whole array instead of a pointer to its first element. (Ville) - Add the intel_dp_phy_is_downstream_of_source() helper. (Ville) - Add a code comment about the disable->enable quirk of non-transparent mode. - Add the intel_dp_training_pattern_set_reg() helper. - Fix checkpatch/sparse warns. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
|
#
7b2a4ab8 |
|
07-Oct-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Switch to LTTPR transparent mode link training By default LTTPRs should be in transparent link training mode, nevertheless in this patch we switch to this default mode explicitly. The DP Standard recommends this, supposedly because an LTTPR may be left in the non-transparent mode (by BIOS, previous kernel, or after reset due to a firmware bug). I haven't seen this happening, but let's follow the DP Standard. v2: - Add a code comment about the explicit disabling of non-transparent mode. v3: - Move check to prevent initing LTTPRs on eDP to init_dp_lttpr_init(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-6-imre.deak@intel.com
|
#
c43027a9 |
|
07-Oct-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Factor out a helper to disable the DPCD training pattern To prepare for a follow-up LTTPR change factor out a helper to disable the training pattern in DPCD. We'll need to do this for each LTTPR (without programming the port to output the idle pattern) when training in LTTPR non-transparent mode. While at it also move the disable-link-training logic from intel_dp_set_link_train() to intel_dp_stop_link_train(), since the latter is the only user of this. v2: - Move the disable-link-training logic to intel_dp_stop_link_train() (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-4-imre.deak@intel.com
|
#
0a5991f5 |
|
07-Oct-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Simplify the link training functions Split the prepare, link training, fallback-handling steps into their own functions for clarity and as a preparation for the upcoming LTTPR changes. While at it also: - Unexport and inline intel_dp_set_idle_link_train(), which is used at a single place. - Add some documentation to functions that are exported or that can use a better description about which part of the LT sequence they implement. v2: (Ville) - Unexport/inline intel_dp_set_idle_link_train() - Make the documentation of intel_dp_prepare_link_train()/intel_dp_stop_link_train() more accurate wrt. HW specific details. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-3-imre.deak@intel.com
|
#
6777a855 |
|
07-Oct-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Fix DP link training pattern mask An LTTPR can be trained with training pattern 4 even if the DPCD revision is < 1.4, but drm_dp_training_pattern_mask() would change pattern 4 to pattern 3 on those DPCD revisions. Since intel_dp_training_pattern() makes already sure that the proper training pattern is used, all that needs to be masked out is the scrambling disable flag, which is or'd to the mask later based on the training pattern. v2: - Use a helper instead of open-coding the masking. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-2-imre.deak@intel.com
|
#
a621860a |
|
01-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Plumb crtc_state to link training Get rid of mode crtc->config usage, and some ad-hoc intel_dp state usage by plumbing the crtc state all the way down to the link training code. Unfortunately we do have to keep some cached state in intel_dp so that we can do the "does the link need retraining?" checks from the short hpd handler. v2: Add intel_crtc_state forward declaration v3: Don't kill the PHY test code totally since it's now in the hotplug work where we can get at the states v4: Don't resurrect the debug scrambling disable bit (Imre) Use intel_dp_mst_is_master_trans() (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201001111053.24451-1-ville.syrjala@linux.intel.com
|
#
81619f4a |
|
15-Jul-2020 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Implement HOBL Hours Of Battery Life is a new GEN12+ power-saving feature that allows supported motherboards to use a special voltage swing table for eDP panels that uses less power. So here if supported by HW, OEM will set it in VBT and i915 will try to train link with HOBL vswing table if link training fails it fall back to the original table. intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag instead of do something like is done in intel_ddi_dp_voltage_max() because it is only called after the first entry of the voltage swing table was loaded so the HOBL flag is valid at that point. v3: - removed a few parameters of icl_ddi_combo_vswing_program() that can be taken from encoder v4: - using the HOBL vswing table until training fails completely (Ville) v5: - not reducing lane or link rate when link training fails with HOBL active - duplicated the HOBL voltage swing entry to match DP spec requirement v6: - removed the optional VS 3 & pre-emp 0 from HOBL table - changed from u8:1 to bool to store hobl_failed/active BSpec: 49291 BSpec: 49399 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200715175637.33763-1-jose.souza@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
a133c698 |
|
09-Jul-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: WARN if max vswing/pre-emphasis violates the DP spec According to the DP spec a DPTX must support vswing/pre-emphasis up to and including level 2. Level 3 is optional (actually DP 1.4a seems to make even level 3 mandatory for HBR2/3, while leaving it optional for RBR/HBR1). WARN if out encoders' .voltage_max()/.preemph_max() return an illegal value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200709145845.18118-1-ville.syrjala@linux.intel.com
|
#
3625a1f5 |
|
12-May-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix DP_TRAIN_MAX_{PRE_EMPHASIS,SWING}_REACHED handling The DP spec says: "The transmitter shall support at least three levels of voltage swing (Levels 0, 1, and 2). If only three levels of voltage swing are supported (VOLTAGE SWING SET field (bits 1:0) are programmed to 10 (Level 2)), this bit shall be set to 1, and cleared in all other cases. If all four levels of voltage swing are supported (VOLTAGE SWING SET field (bits 1:0) are programmed to 11 (Level 3)), this bit shall be set to 1,and cleared in all other cases." Let's follow that exactly instead of the current apporach where we can set those also for vswing/preemph levels 0 or 1 (or 2 when the platform max is 3). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-7-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
e2db5524 |
|
12-May-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Replace some hand rolled max()s Use max() instead of hand rolling it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-8-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
f6adb5f0 |
|
12-May-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reverse preemph vs. voltage swing preference The DP spec says: "When the combination of the requested pre-emphasis level and voltage swing exceeds the capability of a DPTX, the DPTX shall set the pre-emphasis level according to the request and use the highest voltage swing it can output with the given pre-emphasis level." and "When a DPTX reads a request beyond the limits of this Standard, the DPTX shall set the pre-emphasis level according to the request and set the highest voltage swing level it can output with the given pre-emphasis level. If a DPTX is requested for 9.5dB of pre-emphasis level (may be supported for a DPTX) and cannot support that level, it shall set the pre-emphasis level to the next highest level, 6dB." Ie. we should first validate the pre-emphasis, and then select the appropriate vswing for it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-6-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
53de0a20 |
|
12-May-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add {preemph,voltage}_max() vfuncs Different platforms have different max vswing/preemph settings. Turn that into a pair vfuncs so we can decouple intel_dp.c and intel_ddi.c further. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-5-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
5d1453d5 |
|
16-Mar-2020 |
Animesh Manna <animesh.manna@intel.com> |
drm/i915/dp: Made intel_dp_adjust_train() non-static vswing/pre-emphasis adjustment calculation is needed in processing of auto phy compliance request other than link training, so have made non-static function. No functional change. v1: initial patch. v2: - used "intel_dp" prefix in function name. (Jani) - used array notation instead pointer for link_status. (Ville) v3: Scrapped the initial patch, modified commit description accordingly. - made non-static function and used intel_dp prefix. (Jani, Manasi) Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200316103759.12867-4-animesh.manna@intel.com
|
#
62e6c08c |
|
06-Feb-2020 |
Wambui Karuga <wambui.karugax@gmail.com> |
drm/i915/dp_link_training: convert to drm_device based logging macros. Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dp_link_training.c. This also involves extracting the drm_i915_private device pointer from the intel_dp type to use in the various macros. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206080014.13759-3-wambui.karugax@gmail.com
|
#
1d455f8d |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: rename intel_drv.h to display/intel_display_types.h Everything about the file is about display, and mostly about types related to display. Move under display/ as intel_display_types.h to reflect the facts. There's still plenty to clean up, but start off with moving the file where it logically belongs and naming according to contents. v2: fix the include guard name in the renamed file Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com
|
#
379bc100 |
|
13-Jun-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move modesetting output/encoder code under display/ Add a new subdirectory for display code, and start off by moving modesetting output/encoder code. Judging by the include changes, this is a surprisingly clean operation. v2: - move intel_sdvo_regs.h too - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-2-jani.nikula@intel.com
|