- 31 Jul, 2024 14 commits
-
-
Imre Deak authored
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 <suraj.kandpal@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-14-imre.deak@intel.com
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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 <suraj.kandpal@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
In the if (old_ddps != port->ddps || !created) if (port->ddps && !port->input) ret = drm_dp_send_enum_path_resources(); sequence the first if's condition is true if the port exists already (!created) or the port was created anew (hence old_ddps==0) and it was in the plugged state (port->ddps==1). The second if's condition is true for output ports in the plugged state. So the function is called for an output port in the plugged state, regardless if it already existed or not and regardless of the old plugged state. In all other cases port->full_pbn can be zeroed as the port is either an input for which full_pbn is never set, or an output in the unplugged state for which full_pbn was already zeroed previously or the port was just created (with port->full_pbn==0). Simplify the condition, making it clear that the path resources are always enumerated for an output port in the plugged state. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Imre Deak authored
A follow up i915 patch will need to reprobe the MST topology after the initial probing, add a helper for this. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Imre Deak authored
Factor out a function to queue a work for probing the topology, also used by the next patch. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Jani Nikula authored
The comments do not add any value. Remove. Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240729173320.1053791-1-jani.nikula@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
- 30 Jul, 2024 3 commits
-
-
Nikita Zhandarovich authored
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: 82d35437 ("drm/i915/skl: Implementation of SKL DPLL programming") Cc: stable@vger.kernel.org Signed-off-by:
Nikita Zhandarovich <n.zhandarovich@fintech.ru> Reviewed-by:
-
Suraj Kandpal authored
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: d631b984 ("drm/i915/hdcp: Add HDCP 2.2 stream register") Signed-off-by:
-
Mitul Golani authored
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: b2013783 ("drm/i915/display: Cache adpative sync caps to use it later") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
- 29 Jul, 2024 1 commit
-
-
Lucas De Marchi authored
Being part o the display, ideally the setup and cleanup would be done by display itself. However this is a bigger refactor that needs to be done on both i915 and xe. For now, just fix the leak: unreferenced object 0xffff8881a0300008 (size 192): comm "modprobe", pid 4354, jiffies 4295647021 hex dump (first 32 bytes): 00 00 87 27 81 88 ff ff 18 80 9b 00 00 c9 ff ff ...'............ 18 81 9b 00 00 c9 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc 99260e31): [<ffffffff823ce65b>] kmemleak_alloc+0x4b/0x80 [<ffffffff81493be2>] kmalloc_trace_noprof+0x312/0x3d0 [<ffffffffa1345679>] intel_opregion_setup+0x89/0x700 [xe] [<ffffffffa125bfaf>] xe_display_init_noirq+0x2f/0x90 [xe] [<ffffffffa1199ec3>] xe_device_probe+0x7a3/0xbf0 [xe] [<ffffffffa11f3713>] xe_pci_probe+0x333/0x5b0 [xe] [<ffffffff81af6be8>] local_pci_probe+0x48/0xb0 [<ffffffff81af8778>] pci_device_probe+0xc8/0x280 [<ffffffff81d09048>] really_probe+0xf8/0x390 [<ffffffff81d0937a>] __driver_probe_device+0x8a/0x170 [<ffffffff81d09503>] driver_probe_device+0x23/0xb0 [<ffffffff81d097b7>] __driver_attach+0xc7/0x190 [<ffffffff81d0628d>] bus_for_each_dev+0x7d/0xd0 [<ffffffff81d0851e>] driver_attach+0x1e/0x30 [<ffffffff81d07ac7>] bus_add_driver+0x117/0x250 Fixes: 44e69495 ("drm/xe/display: Implement display support") Reviewed-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240724215309.644423-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
- 25 Jul, 2024 4 commits
-
-
Suraj Kandpal authored
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 authored
Sometimes xe_gsc is not initialized when checked at HDCP capability check. Add gsc structure check to avoid null pointer error. Signed-off-by:
Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722064451.3610512-4-suraj.kandpal@intel.com
-
Suraj Kandpal authored
Add encoder check in intel_hdcp2_get_capability to avoid null pointer error. Signed-off-by:
-
Suraj Kandpal authored
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:
-
- 24 Jul, 2024 1 commit
-
-
Colin Ian King authored
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 <colin.i.king@gmail.com> Signed-off-by:
-
- 22 Jul, 2024 4 commits
-
-
Easwar Hariharan authored
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:
Zhi Wang <zhiwang@kernel.org> Signed-off-by:
Easwar Hariharan <eahariha@linux.microsoft.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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 <ankit.k.nautiyal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 12 Jul, 2024 13 commits
-
-
Ville Syrjälä authored
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240705145254.3355-14-ville.syrjala@linux.intel.comReviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
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ä authored
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ä authored
Rearrange the max CFB max height platform into the more common "new first, old last" order. Signed-off-by:
-
Ville Syrjälä authored
Use the more customary name 'height' instead of 'lines'. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
_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ä authored
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ä authored
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:
-
