- 27 Feb, 2024 22 commits
-
-
Imre Deak authored
Handle DP tunnel IRQs a sink (or rather a BW management component like the Thunderbolt Connection Manager) raises to signal the completion of a BW request by the driver, or to signal any state change related to the link BW. 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-18-imre.deak@intel.com
-
Imre Deak authored
Allocate and free the DP tunnel BW required by a stream while enabling/disabling the stream during a modeset. v2: - Move the allocation up from encoder hooks to intel_atomic_commit_tail(). v3: - Update the commit subject. (Ville) Reviewed-by: Uma Shankar <uma.shankar@intel.com> (v1) Reviewed-by:
-
Imre Deak authored
Compute the BW required through a DP tunnel on links with such tunnels detected and add the corresponding atomic state during a modeset. v2: - Fix error check of intel_dp_tunnel_compute_stream_bw(). (Ville) - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to this patch. (Ville) - Move intel_dp_tunnel_atomic_clear_stream_bw() to this patch. Reviewed-by: Uma Shankar <uma.shankar@intel.com> (v1) Reviewed-by:
-
Imre Deak authored
Take any link BW limitation into account in intel_dp_max_link_data_rate(). Such a limitation can be due to multiple displays on (Thunderbolt) links with DP tunnels sharing the link BW. Reviewed-by:
-
Imre Deak authored
Add the atomic state during a modeset required to enable the DP tunnel BW allocation mode on links where such a tunnel was detected. This state applies to an already enabled output, the state added for a newly enabled output will be computed and added/cleared to/from the atomic state in a follow-up patch. v2: - s/old_crtc_state/crtc_state in intel_crtc_duplicate_state(). - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up patch adding the corresponding state. (Ville) - Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up patch adding the corresponding state. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Add support to enable the DP tunnel BW allocation mode. Follow-up patches will call the required helpers added here to prepare for a modeset on a link with DP tunnels, the last change in the patchset actually enabling BWA. With BWA enabled, the driver will expose the full mode list a display supports, regardless of any BW limitation on a shared (Thunderbolt) link. Such BW limits will be checked against only during a modeset, when the driver has the full knowledge of each display's BW requirement. If the link BW changes in a way that a connector's modelist may also change, userspace will get a hotplug notification for all the connectors sharing the same link (so it can adjust the mode used for a display). The BW limitation can change at any point, asynchronously to modesets on a given connector, so a modeset can fail even though the atomic check for it passed. In such scenarios userspace will get a bad link notification and in response is supposed to retry the modeset. v2: - Fix old vs. new connector state in intel_dp_tunnel_atomic_check_state(). (Ville) - Fix propagating the error from intel_dp_tunnel_atomic_compute_stream_bw(). (Ville) - Move tunnel==NULL checks from driver to DRM core helpers. (Ville) - Simplify return flow from intel_dp_tunnel_detect(). (Ville) - s/dp_tunnel_state/inherited_dp_tunnels (Ville) - Simplify struct intel_dp_tunnel_inherited_state. (Ville) - Unconstify object pointers (vs. states) where possible. (Ville) - Init crtc_state while declaring it in check_group_state(). (Ville) - Join obj->base.id, obj->name arg lines in debug prints to reduce LOC. (Ville) - Add/rework intel_dp_tunnel_atomic_alloc_bw() to prepare for moving the BW allocation from encoder hooks up to intel_atomic_commit_tail() later in the patchset. - Disable BW alloc mode during system suspend. - Allocate the required BW for all tunnels during system resume. - Add intel_dp_tunnel_atomic_clear_stream_bw() instead of the open-coded sequence in a follow-up patch. - Add function documentation to all exported functions. - Add CONFIG_USB4 dependency to CONFIG_DRM_I915_DP_TUNNEL. v3: - Rebase on intel_dp_get_active_pipes() change in previous patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Sync instead of only try-sync non-blocking commits when getting the active pipes through a given DP port. Atm intel_dp_get_active_pipes() will only try to sync a given pipe and if that would block ignore the pipe. This was supposed to avoid link retraining in case a pending modeset would do that anyway, however that could incorrectly ignore fastset pipes as well for instance (which don't retraing the link). The TC port reset path needs to handle all pipes, even if a waiting for a pending commit would block. To account for the above cases sync all the pipes unconditionally. This also prepares for a follow-up change enabling the DP tunnel BW allocation mode which needs to ensure that all active pipes are synced and returned from intel_dp_get_active_pipes(). v2: - Add a separate function to try-sync the pipes. (Ville) v3: - Just sync the pipes unconditionally in intel_dp_get_active_pipes(). (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> (v2) Reviewed-by:
-
Imre Deak authored
Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX BW used by a follow-up patch enabling the DP tunnel BW allocation mode. The link BW can be below the DPRX BW due to a BW limitation on a link shared by multiple sinks. Reviewed-by:
-
Imre Deak authored
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:
-
Imre Deak authored
Factor out a function updating the sink's link rate and lane count capabilities, used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by:
-
Imre Deak authored
Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by:
-
Imre Deak authored
Factor out intel_dp_config_required_rate() used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by:
-
Imre Deak authored
Instead of intel_dp_max_data_rate() use the equivalent drm_dp_max_dprx_data_rate() which was copied from the former one in a previous patch. Reviewed-by:
-
Imre Deak authored
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:
-
Imre Deak authored
The system resume display mode restoration should happen with an output configuration matching that of the suspend time saved mode. Since the restored mode configuration is subject to the bpp fallback logic, starting out with an unlimited bpp and reducing the bpp as required by any (MST) link BW limit, the resulting bpp will match the one during suspend only if the BW limit checks during suspend and resume are applied in an identical way. The latter is not guaranteed at the moment, since the pre-suspend MST topology may not be in place during resume (for instance if the MST sink was disconnected while being suspended), which makes the MST link BW check accept the unlimited bpp mode configuration unconditionally without ensuring that the required BW fits into the available MST link BW. To fix the above, initialize the bpp fallback logic with the max link bpp / force-FEC limits left behind by the suspend time mode save. Reviewed-by:
-
Imre Deak authored
Add support for Display Port tunneling. For now this includes the support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay support for later. BWA allows using displays that share the same (Thunderbolt) link with their maximum resolution. Atm, this may not be possible due to the coarse granularity of partitioning the link BW among the displays on the link: the BW allocation policy is in a SW/FW/HW component on the link (on Thunderbolt it's the SW or FW Connection Manager), independent of the driver. This policy will set the DPRX maximum rate and lane count DPCD registers the GFX driver will see (0x00000, 0x00001, 0x02200, 0x02201) based on the available link BW. The granularity of the current BW allocation policy is coarse, based on the required link rate in the 1.62Gbs..8.1Gbps range and it may prevent using higher resolutions all together: the display connected first will get a share of the link BW which corresponds to its full DPRX capability (regardless of the actual mode it uses). A subsequent display connected will only get the remaining BW, which could be well below its full capability. BWA solves the above coarse granularity (reducing it to a 250Mbs..1Gps range) and first-come/first-served issues by letting the driver request the BW for each display on a link which reflects the actual modes the displays use. This patch adds the DRM core helper functions, while a follow-up change in the patchset takes them into use in the i915 driver. v2: - Fix prepare_to_wait vs. wake-up cond check order in allocate_tunnel_bw(). (Ville) - Move tunnel==NULL checks from callers in drivers to here. (Ville) - Avoid var inits in declaration blocks that can fail or have side-effects. (Ville) - Use u8 for driver and group IDs. (Ville) - Simplify API removing drm_dp_tunnel_get/put_untracked(). (Ville) - Reuse str_yes_no() instead of a local yes_no_chr(). (Ville) - s/drm_dp_tunnel_atomic_clear_state()/free_tunnel_state() and unexport the function. (Ville) - s/clear_tunnel_group_state()/free_group_state() and move kfree() to this function. (Ville) - Add separate group_free_bw() helper and describe what the tunnel estimated BW includes. (Ville) - Improve help text for CONFIG_DRM_DISPLAY_DP_TUNNEL. (Ville) - Add code comment explaining the purpose of DPCD reg read helpers. (Ville) - Add code comment describing the tunnel group name prefix format. (Ville) - Report the allocated BW as undetermined until the first allocation request. - Skip allocation requests matching the previous request. - Clear any stale BW request status flags before a new request. - Add missing error return check of drm_dp_tunnel_atomic_get_group_state() in drm_dp_tunnel_atomic_set_stream_bw(). - Add drm_dp_tunnel_get_allocated_bw(). - s/drm_dp_tunnel_atomic_get_tunnel_bw/drm_dp_tunnel_atomic_get_required_bw - Fix return value description in function doc of drm_dp_tunnel_detect(). - Add function documentation to all exported functions. v3: - Improve grouping of fields in drm_dp_tunnel_group struct. (Uma) - Fix validating the BW granularity DPCD reg value. (Uma) - Document return value of check_and_clear_status_change(). (Uma) - Fix resetting drm_dp_tunnel_ref::tunnel in drm_dp_tunnel_ref_put(). (Ville) - Allow for ALLOCATED_BW to change after a BWA enable/disable sequence. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Copy intel_dp_max_data_rate() to DRM core. It will be needed by a follow-up DP tunnel patch, checking the maximum rate the DPRX (sink) supports. Accordingly use the drm_dp_max_dprx_data_rate() name for clarity. This patchset will also switch calling the new DRM function in i915 instead of intel_dp_max_data_rate(). While at it simplify the function documentation/comments, removing parts described already by drm_dp_bw_channel_coding_efficiency(). v2: (Ville) - Remove max_link_rate_kbps. - Simplify the function documentation. v3: - Rebased on latest drm-tip. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Suraj Kandpal authored
We see some monitors and docks report incorrect hdcp version and capability in first few reads so we read rx_caps three times before we conclude the monitor's or docks HDCP capability --v2 -Add comment to justify the 3 time read loop for hdcp capability[Ankit] Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Allocate stream id after HDCP AKE stage and not before so that it can also be done during link integrity check. Right now for MST scenarios LIC fails after hdcp enablement for this reason. --v2 -no need for else block in prepare_streams function [Ankit] --v3 -remove intel_hdcp argument from required_content_stream function [Ankit] Signed-off-by:
-
Suraj Kandpal authored
Whenever LIC fails instead of moving from ENABLED to DESIRED CP property we directly enable HDCP1.4 without informing the userspace of this failure in link integrity check. Now we will just update the value to DESIRED send the event to userspace and then continue with the normal flow of HDCP enablement. Signed-off-by:
-
Suraj Kandpal authored
Whenever LIC fails instead of moving from ENABLED to DESIRED CP property we directly enable HDCP2.2 without informing the userspace of this failure in link integrity check. Now we will just update the value to DESIRED send the event to userspace and then continue with the normal flow of HDCP enablement. --v2 -Don't change the function prototype in this function [Ankit] Signed-off-by:
-
Suraj Kandpal authored
Currently intel_hdcp is not being extracted from primary connector this patch fixes that. Fixes: 524240b2 ("drm/i915/hdcp: Propagate aux info in DP HDCP functions") Signed-off-by:
-
- 26 Feb, 2024 9 commits
-
-
Suraj Kandpal authored
Now that we have moved back to direct reads the additional timing is not required hence this can be removed. --v2 -Add Fixes tag [Ankit] Fixes: 3974f9c1 ("drm/i915/hdcp: Adjust timeout for read in DPMST Scenario") Signed-off-by:
-
Suraj Kandpal authored
Currently we are only checking capability of remote device and not immediate downstream device but during capability check we need are concerned with only the HDCP capability of downstream device. During i915_display_info reporting we need HDCP Capability for both the monitors and downstream branch device if any this patch adds that. --v2 -Use MST Hub HDCP version [Ankit] --v3 -Redefined how we seprate remote and direct read to make sure HDMI shim functions are not touched [Ankit] --v4 - Fix the conditions so that hdcp_info with remote_req true is sent only when encoder is mst [Ankit] --v5 -No need to have the MST Hub version in i915_hdcp_sink_capability[Ankit] Signed-off-by:
-
Suraj Kandpal authored
Create a remote HDCP capability shim function which can read the remote monitor HDCP capability when in MST configuration. --v2 -Add an assertion to make sure only mst encoder call this remote_cap function [Ankit] --v3 -rename remote_hdcp_cap to remote_hdcp_capability [Jani] --v4 -fix hdcp2_prerequisite check condition -Move intel_dp_hdcp_get_remote_capability to dp_mst shim instead of having it in dp shim [Ankit] Signed-off-by:
-
Suraj Kandpal authored
Rename hdcp_capable and hdcp_2_2_capable to hdcp_get_capability and hdcp_2_2_get_capability to properly reflect what these functions are doing. Signed-off-by:
-
Suraj Kandpal authored
Pass drm_dp_aux to intel_dp_hdcp_read_bcaps function so as to aid in reading the bcaps for the remote monitor later on. Signed-off-by:
-
Suraj Kandpal authored
Break intel_dp_hdcp2_capable so that the common the code can be reused for the remote capability check. Signed-off-by:
-
Suraj Kandpal authored
Move checks on the source side for HDCP2.2 into its own function so that they can be used in the HDCP remote capability check function. Signed-off-by:
-
Suraj Kandpal authored
Even for MST scenarios we need to do direct reads only on the immediate downstream device the rest of the authentication is taken care by that device. Remote reads will only be used to check capability of the monitors in MST topology. --v2 -Add fixes tag [Ankit] -Derive aux where needed rather than through a function [Ankit] Fixes: ae4f902b ("drm/i915/hdcp: Send the correct aux for DPMST HDCP scenario") Signed-off-by:
-
Bhanuprakash Modem authored
If the connected panel supports both DRRS & PSR, driver gives preference to PSR ("DRRS enabled: no"). Even though the hardware supports DRRS, IGT treats ("DRRS enabled: yes") as not capable. Introduce a new entry "DRRS capable" to debugfs i915_drrs_status, so that IGT will read the DRRS capability as "DRRS capable: yes". Signed-off-by:Bhanuprakash Modem <bhanuprakash.modem@intel.com> Reviewed-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by:
-
- 23 Feb, 2024 3 commits
-
-
Rodrigo Vivi authored
Fixing some doc build issues: Documentation/gpu/i915:222: drivers/gpu/drm/i915/display/intel_cdclk.c:69: ERROR: Unexpected indentation. Documentation/gpu/i915:222: ./drivers/gpu/drm/i915/display/intel_cdclk.c:70: WARNING: Block quote ends without a blank line; unexpected unindent. v2: Minimize the empty lines (Gustavo) Closes: https://lore.kernel.org/all/20240219161747.0e867406@canb.auug.org.au/ Fixes: 79e2ea2e ("drm/i915/cdclk: Document CDCLK update methods") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221155453.94208-1-rodrigo.vivi@intel.com
-
Suraj Kandpal authored
If fixed refresh rate program the PKGC_LATENCY register with the highest latency from level 1 and above LP registers and program ADDED_WAKE_TIME = DSB execution time. else program PKGC_LATENCY with all 1's and ADDED_WAKE_TIME as 0. This is used to improve package C residency by sending the highest latency tolerance requirement (LTR) when the planes are done with the frame until the next frame programming window (set context latency, window 2) starts. Bspec: 68986 --v2 -Fix indentation [Chaitanya] --v3 -Take into account if fixed refrersh rate or not [Vinod] -Added wake time dependengt on DSB execution time [Vinod] -Use REG_FIELD_PREP [Jani] -Call program_pkgc_latency from appropriate place [Jani] -no need for the ~0 while setting max latency [Jani] -change commit message to add the new changes made in. --v4 -Remove extra blank line [Vinod] -move the vrr.enable check to previous loop [Vinod] Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219063638.1467114-1-suraj.kandpal@intel.com
-
Suraj Kandpal authored
Add the register that needs to read and written onto for deep pkgc programming. Signed-off-by:
-
- 20 Feb, 2024 1 commit
-
-
Maxime Ripard authored
Commit 1fd4a5a3 ("drm/connector: Rename legacy TV property") failed to update all the users of the struct drm_tv_connector_state mode field, which resulted in a build failure in i915. However, a subsequent commit in the same series reintroduced a mode field in that structure, with a different semantic but the same type, with the assumption that all previous users were updated. Since that didn't happen, the i915 driver now compiles, but mixes accesses to the legacy_mode field and the newer mode field, but with the previous semantics. This obviously doesn't work very well, so we need to update the accesses that weren't in the legacy renaming commit. Fixes: 1fd4a5a3 ("drm/connector: Rename legacy TV property") Reported-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
-
- 19 Feb, 2024 5 commits
-
-
Jiri Slaby (SUSE) authored
intel_memory_region_ops::flags was never used since its addition in commit 232a6eba (drm/i915: introduce intel_memory_region). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jiri Slaby (SUSE) authored
i915_vma::obj_hash was never used since its addition in commit 4ff4b44c (drm/i915: Store a direct lookup from object handle to vma). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
execute_cb::signal is not used since commit 5ac545b8 (drm/i915/request: Remove the hook from await_execution). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
intel_gvt_irq::pending_events was never used since its addition in commit c8fe6a68 (drm/i915/gvt: vGPU interrupt virtualization.). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
intel_gvt_event_info::policy was never used since its addition in commit c8fe6a68 (drm/i915/gvt: vGPU interrupt virtualization.). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
