- 27 Feb, 2024 14 commits
-
-
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:
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
-
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 13 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:
-
Jiri Slaby (SUSE) authored
intel_gvt_irq_info::warned 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
gvt_mmio_block::device is not used since commit e0f74ed4 (i915/gvt: Separate the MMIO tracking table from GVT-g). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
intel_vgpu::intx_trigger was never used since its addition in commit f30437c5 (drm/i915/gvt: add KVMGT support). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
intel_vgpu_opregion::mapped is not used since commit 36774806 (drm/i915/gvt: remove enum hypervisor_type). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
intel_vgpu_fence::base was never used since its addition in commit 28a60dee (drm/i915/gvt: vGPU HW resource management). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
intel_vgpu_gtt::active_ppgtt_mm_bitmap was never used since its addition in commit 2707e444 (drm/i915/gvt: vGPU graphics memory virtualization). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
i915_perf_stream::size_exponent was never used since its addition in commit a37f08a8 (drm/i915/perf: Refactor oa object to better manage resources). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
Jiri Slaby (SUSE) authored
i915_drm_client::id is not used since commit e894b724 (drm/i915: Use the fdinfo helper). Drop it. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
