aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)AuthorFilesLines
2024-08-01drm/i915/dpkgc: Add VRR condition for DPKGC EnablementSuraj Kandpal1-11/+13
DPKGC can now be enabled with VRR enabled if Vmin = Vmax = Flipline is met. Bspec: 68986 Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Mitul Golani <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp_mst: Enable LT fallback between UHBR/non-UHBR link ratesImre Deak1-5/+0
Enable switching between UHBR and non-UHBR link rates on MST links when reducing the link parameters after an LT failure. Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp_mst: Ensure link parameters are up-to-date for a disabled linkImre Deak3-0/+35
As explained in the previous patch, the MST link BW reported by branch devices during topology probing/path resources enumeration depends on the link parameters programmed to DPCD to be up-to-date. After a sink is plugged this is not ensured, as those DPCD values start out zeroed. The target link parameters (for a subsequent modeset) are the maximum that is supported, so make sure these maximum values are programmed before the topology probing. Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp_mst: Reprobe the MST topology after a link parameter changeImre Deak3-1/+41
The MST link BW reported by branch devices via the ENUM_PATH_RESOURCES message depends on the channel coding and link rate/lane count parameters programmed to DPCD. This is the case at least for some branch devices, while for others the reported BW is independent of the link parameters. In any case the DP standard requires the branch device to adjust the returned value to both account for the different way the BW for FEC is accounted for (included in the returned value for non-UHBR and not included for UHBR rates) and to limit the returned value to the (trained) link BW between the source and first downstream branch device, see DP v2.0/v2.1 Figure 2-94, DP v2.1 5.9.7. Presumedly this is also the reason why the standard requires the DPCD link rate/lane count values being up-to-date before sending the ENUM_PATH_RESOURCES message, see DP v2.1 2.14.9.4. Based on the above reprobe the MST topology after the link is retrained with new link parameters to make sure that the MST link BW tracked in the MST topology state (via each topology port's full_pbn value) is up-to-date. The next patch will make sure that the MST link BW is also kept up-to-date if the link is disabled. Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp_mst: Queue modeset-retry after a failed payload BW allocationImre Deak1-4/+7
If the MST payload allocation failed, enabling the output also failed most probably, so send a uevent accordinly requesting the user to retry the modeset. While at it remove the driver specific debug message, there is already one printed by drm_dp_add_payload_part1(). Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp_mst: Configure MST after the link parameters are resetImre Deak1-2/+2
The MST topology probing depends on the maximum link parameters - programmed to DPCD if required by a follow-up patch - so make sure these parameters are up-to-date before configuring and probing the MST topology. Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp_mst: Reduce the link parameters in BW order after LT failuresImre Deak4-2/+159
On MST links - at least for some MST branch devices - the list of modes returned to users on an enabled link depends on the current link rate/lane count parameters (besides the DPRX link capabilities, any MST branch BW limit and the maximum link parameters reduced after LT failures). In particular the MST branch BW limit may depend on the link rate/lane count parameters programmed to DPCD. After an LT failure and limiting the maximum link parameters accordingly, users should see a mode list reflecting these new limits. However with the current fallback order this isn't ensured, as the new limit could allow for modes requiring a higher link BW, but these modes will be filtered out due to the enabled link's lower link BW. Ensure that the mode list changes in a consistent way after a link training failure and reducing the link parameters by changing the fallback order on MST links to happen in BW order. v2: - s/INTEL_DP_MAX_SUPPORTED_LANE_COUNTS/INTEL_DP_MAX_SUPPORTED_LANE_CONFIGS and s/num_common_lane_counts/num_common_lane_configs to make the difference wrt. max lane counts clearer. (Suraj) - Add a TODO comment to make the SST fallback logic work the same way as MST. (Arun) - Use sort_r()'s default swap function instead of a custom one. Cc: Suraj Kandpal <[email protected]> Cc: Arun R Murthy <[email protected]> Reviewed-by: Suraj Kandpal <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp: Add helpers to set link training mode, BW parametersImre Deak2-11/+29
Add helpers to set the link mode and BW parameters. These are required by a follow-up patch setting the parameters for a disabled link. Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp: Add a separate function to reduce the link parametersImre Deak1-8/+31
A follow-up patch will add an alternative way to reduce the link parameters in BW order on MST links, prepare for that here. Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp: Send only a single modeset-retry uevent for a commitImre Deak2-0/+7
There are multiple failure cases a modeset-retry uevent can be sent for a link (TBT tunnel BW allocation failure, unrecoverable link training failure), a follow-up patch adding the handling for a new case where the DP MST payload allocation fails. The uevent is the same in all cases, sent to all the connectors on the link, so in case of multiple failures there is no point in sending a separate uevent for each failure; prevent this, sending only a single modeset-retry uevent for a commit. Reviewed-by: Arun R Murthy <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/dp: Initialize the link parameters during HW readoutImre Deak1-1/+4
Initialize the DP link parameters during HW readout. These need to be up-to-date at least for the MST topology probing, which depends on the link rate and lane count programmed in DPCD. A follow-up patch will program the DPCD values to reflect the maximum link parameters before the first MST topology probing, but should do so only if the link is disabled (link_trained==false). Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/ddi: For an active output call the DP encoder sync_state() only for DPImre Deak1-1/+2
If the DDI encoder output is enabled in HDMI mode there is no point in calling intel_dp_sync_state(), as in that case the DPCD initialization will fail - as expected - with AUX timeouts. Prevent calling the hook in this case. Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-31drm/i915/bios: remove stale and useless commentsJani Nikula1-8/+0
The comments do not add any value. Remove. Reviewed-by: Vandita Kulkarni <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-07-30drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll()Nikita Zhandarovich1-3/+3
On the off chance that clock value ends up being too high (by means of skl_ddi_calculate_wrpll() having been called with big enough value of crtc_state->port_clock * 1000), one possible consequence may be that the result will not be able to fit into signed int. Fix this issue by moving conversion of clock parameter from kHz to Hz into the body of skl_ddi_calculate_wrpll(), as well as casting the same parameter to u64 type while calculating the value for AFE clock. This both mitigates the overflow problem and avoids possible erroneous integer promotion mishaps. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming") Cc: [email protected] Signed-off-by: Nikita Zhandarovich <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 833cf12846aa19adf9b76bc79c40747726f3c0c1) Signed-off-by: Joonas Lahtinen <[email protected]>
2024-07-30drm/i915/hdcp: Fix HDCP2_STREAM_STATUS macroSuraj Kandpal1-1/+1
Fix HDCP2_STREAM_STATUS macro, it called pipe instead of port never threw a compile error as no one used it. --v2 -Add Fixes [Jani] Fixes: d631b984cc90 ("drm/i915/hdcp: Add HDCP 2.2 stream register") Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 73d7cd542bbd0a7c6881ea0df5255f190a1e7236) Signed-off-by: Joonas Lahtinen <[email protected]>
2024-07-30drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll()Nikita Zhandarovich1-3/+3
On the off chance that clock value ends up being too high (by means of skl_ddi_calculate_wrpll() having been called with big enough value of crtc_state->port_clock * 1000), one possible consequence may be that the result will not be able to fit into signed int. Fix this issue by moving conversion of clock parameter from kHz to Hz into the body of skl_ddi_calculate_wrpll(), as well as casting the same parameter to u64 type while calculating the value for AFE clock. This both mitigates the overflow problem and avoids possible erroneous integer promotion mishaps. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming") Cc: [email protected] Signed-off-by: Nikita Zhandarovich <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-30drm/i915/hdcp: Fix HDCP2_STREAM_STATUS macroSuraj Kandpal1-1/+1
Fix HDCP2_STREAM_STATUS macro, it called pipe instead of port never threw a compile error as no one used it. --v2 -Add Fixes [Jani] Fixes: d631b984cc90 ("drm/i915/hdcp: Add HDCP 2.2 stream register") Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-30drm/i915/display/dp: Compute AS SDP when vrr is also enabledMitul Golani1-1/+1
AS SDP should be computed when VRR timing generator is also enabled. Correct the compute condition to compute params of Adaptive sync SDP when VRR timing genrator is enabled along with sink support indication. --v2: Modify if condition (Jani). Fixes: b2013783c445 ("drm/i915/display: Cache adpative sync caps to use it later") Cc: Mitul Golani <[email protected]> Cc: Arun R Murthy <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Ankit Nautiyal <[email protected]> (added prefix drm in subject) Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-25drm/i915/dp: Clear VSC SDP during post ddi disable routineSuraj Kandpal1-2/+5
Clear VSC SDP if intel_dp_set_infoframes is called from post ddi disable routine i.e with the variable of enable as false. This is to avoid an infoframes.enable mismatch issue which is caused when pipe is connected to eDp which has psr then connected to DPMST. In this case eDp's post ddi disable routine does not clear infoframes.enable VSC for the given pipe and DPMST does not recompute VSC SDP and write infoframes.enable which causes a mismatch. --v2 -Make the comment match the code [Jani] Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-25drm/i915/hdcp: Add encoder check in hdcp2_get_capabilitySuraj Kandpal1-2/+9
Add encoder check in intel_hdcp2_get_capability to avoid null pointer error. Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Dnyaneshwar Bhadane <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-25drm/i915/hdcp: Add encoder check in intel_hdcp_get_capabilitySuraj Kandpal1-1/+6
Sometimes during hotplug scenario or suspend/resume scenario encoder is not always initialized when intel_hdcp_get_capability add a check to avoid kernel null pointer dereference. Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Dnyaneshwar Bhadane <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-24drm/i915/dp: Make read-only array bw_gbps static constColin Ian King1-1/+1
Don't populate the read-only array bw_gbps on the stack at run time, instead make it static const. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-22drm/i915: Make I2C terminology more inclusiveEaswar Hariharan15-101/+101
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Acked-by: Zhi Wang <[email protected]> Signed-off-by: Easwar Hariharan <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-22drm/i915/dp: Don't WARN on failed link-retrain modesetImre Deak1-3/+0
After a bad link state is detected, the sink capabilities with which the link was originally trained could have changed: for instance another sink got connected or the retraining was forced after the rate/lane count got decreased (as a fallback). In these cases the retraining modeset fails as expected also printing a debug message, so don't WARN on it. Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-22drm/i915/dp: Require a valid atomic state for SST link trainingImre Deak2-19/+0
After the previous patch link training happens always with a valid atomic state, so remove the NOTE comments and asserts which required a valid state only for DP-MST and allowed for a NULL state for DP-SST. Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-22drm/i915/dp: Retrain SST links via a modeset commitImre Deak1-58/+9
Instead of direct calls of the link training functions, use a modeset commit to retrain a DP link in SST mode, similarly to how this is done in DP-MST mode. Originally the current way was chosen presumedly, because there wasn't a well-established way in place for the driver to do an internal (vs. userspace/kernel client) commit. Since then such internal commits became a common place (initial-, HDMI/TC link reset commit), so there is no reason to handle the DP-SST link-retraining case differently. At the end of the current sequence the HW reported a FIFO underrun - without other issues visible to users - because during retraining the link's encoder/port was disabled/re-enabled without also disabling/re-enabling the corresponding pipe/transcoder (as required by the spec); the corresponding underrun error message was suppressed as a known issue. Based on Ankit's test on DG2 the underrun error was still reported as it got detected with some (vblank) delay wrt. other platforms. Switching to a modeset commit resolves these underrun related issues. Cc: Ankit Nautiyal <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-16drm/i915/dp: Don't switch the LTTPR mode on an active linkImre Deak1-7/+48
Switching to transparent mode leads to a loss of link synchronization, so prevent doing this on an active link. This happened at least on an Intel N100 system / DELL UD22 dock, the LTTPR residing either on the host or the dock. To fix the issue, keep the current mode on an active link, adjusting the LTTPR count accordingly (resetting it to 0 in transparent mode). v2: Adjust code comment during link training about reiniting the LTTPRs. (Ville) Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Reported-and-tested-by: Gareth Yu <[email protected]> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10902 Cc: <[email protected]> # v5.15+ Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 211ad49cf8ccfdc798a719b4d1e000d0a8a9e588) Signed-off-by: Tvrtko Ursulin <[email protected]>
2024-07-16drm/i915/dp: Reset intel_dp->link_trained before retraining the linkImre Deak1-0/+2
Regularly retraining a link during an atomic commit happens with the given pipe/link already disabled and hence intel_dp->link_trained being false. Ensure this also for retraining a DP SST link via direct calls to the link training functions (vs. an actual commit as for DP MST). So far nothing depended on this, however the next patch will depend on link_trained==false for changing the LTTPR mode to non-transparent. Cc: <[email protected]> # v5.15+ Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a4d5ce61765c08ab364aa4b327f6739b646e6cfa) Signed-off-by: Tvrtko Ursulin <[email protected]>
2024-07-12drm/i915/fbc: Extract intel_fbc_cfb_cpp()Ville Syrjälä1-6/+12
Extract a helper to determine the CFB bytes per pixel value. Currently this is always 4, but that could change in the future. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2024-07-12drm/i915/fbc: Extract _intel_fbc_cfb_size()Ville Syrjälä1-2/+7
Pull the lower level stuff out from intel_fbc_cfb_size() into a separate function that doesn't depend on the plane_state. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2024-07-12drm/i915/fbc: Extract intel_fbc_max_cfb_height()Ville Syrjälä1-7/+20
Pull the code to determine the maximum CFB height into a separate function. To make this work we need to declare an explicit max height for all older platforms as well. But that is actually just the max plane height as pre-HSW hardware supposedly doesn't have the trick of leaving the extra lines uncompressed. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2024-07-12drm/i915/fbc: Reoder CFB max height platform checksVille Syrjälä1-3/+3
Rearrange the max CFB max height platform into the more common "new first, old last" order. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915/fbc: s/lines/height/Ville Syrjälä1-4/+4
Use the more customary name 'height' instead of 'lines'. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915/fbc: Extract _intel_fbc_cfb_stride()Ville Syrjälä1-8/+14
Pull the lower level stuff out from intel_fbc_cfb_stride() into a separate function that doesn't depend on the plane_state. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2024-07-12drm/i915/fbc: Adjust g4x+ platform checksVille Syrjälä1-2/+2
Do the "is this ilk+ or g4x" checks in the customary order instead of the reverse order. Easier for the poor brain to parse this when it's always done the same way. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915/fbc: ↵Ville Syrjälä1-2/+2
s/intel_fbc_hw_tracking_covers_screen()/intel_fbc_surface_size_ok()/ Rename intel_fbc_hw_tracking_covers_screen() to intel_fbc_surface_size_ok() so that the naming scheme is the same for the surface size vs. plane size checks. "surface size" is what bspec talks about. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915/fbc: Extract intel_fbc_max_surface_size()Ville Syrjälä1-17/+24
Extract intel_fbc_max_surface_size() from intel_fbc_hw_tracking_covers_screen(), mainly to mirror the "max plane size" counterparts. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915/fbc: Extract intel_fbc_max_plane_size()Ville Syrjälä1-11/+18
Extract intel_fbc_max_plane_size() from intel_fbc_plane_size_valid(). We'll have another use for this soon in determining how much stolen memory we'd like to keep reserved for FBC. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915/fbc: s/_intel_fbc_cfb_stride()/intel_fbc_plane_cfb_stride()/Ville Syrjälä1-3/+3
_intel_fbc_cfb_stride() calculates the CFB stride the hardware would automagically generate from the plane's stride. Rename the function to intel_fbc_plane_cfb_stride() to better reflect its purpose. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915/fbc: Convert to intel_display, mostlyVille Syrjälä6-207/+238
Switch the FBC code over to intel_display from i915, as much as possible. This is the future direction so that the display code can be shared between i915 and xe more cleanly. Some of the platform checks and the stolen mem facing stiff still need i915 around though. v2: Drop some redundant to_i915() casts Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915/fbc: Extract intel_fbc_has_fences()Ville Syrjälä1-2/+7
Pull the "do we have fences?" check into a single helper in the FBC code. Avoids having to call to outside the display code in multiple places for this. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-07-12drm/i915: Make vrr_{enabling,disabling}() usable outside intel_display.cVille Syrjälä1-9/+17
Give vrr_enabling() and vrr_disabling() slightly fancier names, and pass in the whole atomic state so that they'll be easier to use. We'll need to call at least the disabling part from the DSB code soon enough (so that we can do vblank evasions/etc. correctly on the DSB). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Animesh Manna <[email protected]>
2024-07-12drm/i915: Calculate vblank delay more accuratelyVille Syrjälä1-1/+2
Calculate the vblank delay in the vblank evasion code correctly for interlaced modes. The current code assumes that we won't be using an interlaced mode. That assumption is actually valid since we've defeatured interlaced scanout in commit f71c9b7bc35f ("drm/i915/display: Prune Interlace modes for Display >=12") for DSB capable platforms. However the feature is still present in the hardware, and if we ever find the need to re-enable it seems better to calculate the vblank delay correctly. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Animesh Manna <[email protected]>
2024-07-11drm/i915/dp: Keep cached LTTPR mode up-to-dateImre Deak1-1/+7
Nothing depends on the cached LTTPR mode, however for consistency keep it up-to-date with the value programmed to the DPCD register. Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-11drm/i915/dp: Reset cached LTTPR count if number of LTTPRs is unsupportedImre Deak1-1/+1
After detection the cached LTTPR count can be checked to determine if LTTPRs in non-transparent mode were detected. Reset the cached LTTPR count if the reported number of LTTPRs is invalid to ensure the above checks work as expected. Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-11drm/i915/dp: Don't switch the LTTPR mode on an active linkImre Deak1-7/+48
Switching to transparent mode leads to a loss of link synchronization, so prevent doing this on an active link. This happened at least on an Intel N100 system / DELL UD22 dock, the LTTPR residing either on the host or the dock. To fix the issue, keep the current mode on an active link, adjusting the LTTPR count accordingly (resetting it to 0 in transparent mode). v2: Adjust code comment during link training about reiniting the LTTPRs. (Ville) Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Reported-and-tested-by: Gareth Yu <[email protected]> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10902 Cc: <[email protected]> # v5.15+ Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-11drm/i915/dp: Reset intel_dp->link_trained before retraining the linkImre Deak1-0/+2
Regularly retraining a link during an atomic commit happens with the given pipe/link already disabled and hence intel_dp->link_trained being false. Ensure this also for retraining a DP SST link via direct calls to the link training functions (vs. an actual commit as for DP MST). So far nothing depended on this, however the next patch will depend on link_trained==false for changing the LTTPR mode to non-transparent. Cc: <[email protected]> # v5.15+ Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-10drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clockMitul Golani1-0/+8
The dispcnlunit1_cp_xosc_clk should be de-asserted in display off and only asserted in display on. As part of this workaround, Display driver shall execute set-reset sequence at the end of the initialize sequence to ensure clk does not remain active in display OFF. --v2: - Rebase. --v3: - Correct HSD number in commit message. --v4: - Reformat commit message. - Use intel_de_rmw instead of intel_de_write --v5: - Build Fixes. WA: 15013987218 Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Nemesa Garg <[email protected]> Reviewed-by: Suraj Kandpal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-09drm/i915/display: Cache adpative sync caps to use it laterMitul Golani5-14/+15
Add new member to struct intel_dp to cache support of Adaptive Sync SDP capabilities and use it whenever required to avoid HW access to read capability during each atomic commit. -v2: - Squash both the patches Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-07-05drm/i915: disable fbc due to Wa_16023588340Matthew Auld2-0/+14
On BMG-G21 we need to disable fbc due to complications around the WA. v2: - Try to handle with i915_drv.h and compat layer. (Rodrigo) v3: - For simplicity retreat back to the original design for now. - Drop the extra \ from the Makefile (Jani) Signed-off-by: Matthew Auld <[email protected]> Cc: Jonathan Cavitt <[email protected]> Cc: Matt Roper <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Vinod Govindapillai <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Reviewed-by: Jonathan Cavitt <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.