- 15 Aug, 2024 1 commit
-
-
Suraj Kandpal authored
We are checking cp_irq_count from the wrong hdcp structure which ends up giving timed out errors. We only increment the cp_irq_count of the primary connector's hdcp structure but here in case of multidisplay setup we end up checking the secondary connector's hdcp structure, which will not have its cp_irq_count incremented. This leads to a timed out at CP_IRQ error even though a CP_IRQ was raised. Extract it from the correct intel_hdcp structure. --v2 -Explain why it was the wrong hdcp structure [Jani] Fixes: 8c9e4f68 ("drm/i915/hdcp: Use per-device debugs") Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240809114127.3940699-2-suraj.kandpal@intel.com
-
- 14 Aug, 2024 1 commit
-
-
Jani Nikula authored
The function isn't used outside of intel_display_power.c. Make it static. Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240813151216.2573845-1-jani.nikula@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
- 13 Aug, 2024 1 commit
-
-
Jani Nikula authored
We have a helper for converting pci device to i915 device, use it. v2: Also convert i915_pci_probe() (Gustavo) Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240812103415.1540096-1-jani.nikula@intel.comSigned-off-by:
-
- 12 Aug, 2024 5 commits
-
-
Jani Nikula authored
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_bios.[ch] to struct intel_display. Do one drive-by conversion of unnecessary hex usage to decimal. Reviewed-by:
-
Jani Nikula authored
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_opregion.[ch] to struct intel_display. v2: - Fix declarations for !CONFIG_ACPI (Imre, kernel test robot) - Pass encoder/connector directly to intel_display() (Imre) Reviewed-by:
-
Jani Nikula authored
Prefer the short encoder/connector names for struct intel_encoder/intel_connector variables and parameters. Reviewed-by:
-
Jani Nikula authored
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_acpi.[ch] to struct intel_display. Reviewed-by:
-
Mitul Golani authored
Log the address of the register that caused the timeout interrupt by reading RMTIMEOUTREG_CAPTURE --v2: - Update RMTIMEOUTREG_CAPTURE naming (Suraj) --v3: - XeLpdp naming convention. - Use if condition instead of else if Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
- 08 Aug, 2024 4 commits
-
-
Jani Nikula authored
With the previous cleanups, the last remaining user of __i915_printk() is i915_probe_error(). Switch that to use drm_dbg() and drm_err() instead, dropping the request to report bugs in the few remaining specific cases. It's not common for drivers to log bug filing requests to begin with, but these cases are in init, which is most likely to be tested in CI and least likely to be hit by end users anyway. Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/be9baeab281f75999e96cc7ad1c06c6680494bc1.1722951405.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
i915_report_error() presently acts as a wrapper for __i915_printk(). In practice, it would be better to use drm level error reporting wherever possible, so replace all uses of i915_report_error() with the equivalent drm_err() call. These cases are not worth having a dedicated wrapper to also print bug reporting info. Replacing the calls leaves i915_report_error() with no users, so remove it. Reviewed-by:
-
Jani Nikula authored
__i915_printk() does nothing special for notice/info levels. Just use the regular drm_notice() and drm_info() calls. Reviewed-by:
-
Andi Shyti authored
Do not use double blanks, ", " in function parameters where it's not required by any alignment purpose. Replase it with a single blank, ", ". Signed-off-by:
-
- 06 Aug, 2024 7 commits
-
-
Imre Deak authored
The Display Engine's DSC register values are deducted from the DSC configuration stored in intel_crtc_state::dsc. The latter one is dumped in a human-readable format, so dumping the register values is redundant, remove it. Acked-by:
-
Imre Deak authored
Dump the DSC state to dmesg during HW readout and state computation as well as the i915_display_info debugfs entry. v2: Rebase on the s/DRM_X16/FXP_Q4 change. Acked-by:
-
Imre Deak authored
Replace the BPP_X16_FMT()/ARGS() helpers defined by the driver with the equivalent FXP_Q4_FMT()/ARGS() helpers defined by DRM core. v2: Rebase on the s/DRM_X16/FXP_Q4 change. Acked-by:
-
Imre Deak authored
Replace the to_bpp_frac() helper defined by the driver with the equivalent fxp_q4_to_frac() helper defined by DRM core. v2: Rebase on the s/drm_x16/fxp_q4 change. Acked-by:
-
Imre Deak authored
Replace the to_bpp_int_roundup() helper defined by the driver with the equivalent fxp_q4_to_int_roundup() helper defined by DRM core. v2: Rebase on s/drm_x16/fxp_q4 change. Acked-by:
-
Imre Deak authored
Replace the to_bpp_int() helper defined by the driver with the equivalent fxp_q4_to_int() helper defined by DRM core. v2: Rebase on the s/drm_x16/fxp_q4 change. Acked-by:
-
Imre Deak authored
Replace the to_bpp_x16() helper defined by the driver with the equivalent fxp_q4_from_int() helper defined by DRM core. v2: Rebase on the s/drm_x16/fxp_q4 change. Acked-by:
-
- 05 Aug, 2024 1 commit
-
-
Dnyaneshwar Bhadane authored
On the PCH side the second PPS was introduced in ICP+.Add condition On MTL_PCH and greater platform also having the second PPS. Note that DG1/2 south block only has the single PPS, so need to exclude the fake DG1/2 PCHs Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11488 Fixes: 93cbc1ac ("drm/i915/mtl: Add fake PCH for Meteor Lake") Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by:
Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by:
-
- 01 Aug, 2024 4 commits
-
-
Thomas Zimmermann authored
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Reviewed-by:
-
Jani Nikula authored
Sync with v6.11-rc1 in general, and specifically get the new BACKLIGHT_POWER_ constants for power states. Signed-off-by: -
Jani Nikula authored
The last users have been removed years ago. Finish the job. Reviewed-by:
-
Suraj Kandpal authored
DPKGC can now be enabled with VRR enabled if Vmin = Vmax = Flipline is met. Bspec: 68986 Signed-off-by:
-
- 31 Jul, 2024 15 commits
-
-
Imre Deak authored
Enable switching between UHBR and non-UHBR link rates on MST links when reducing the link parameters after an LT failure. Reviewed-by:
-
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:
-
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:
-
- 30 Jul, 2024 1 commit
-
-
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:
-
