- 01 Mar, 2024 1 commit
-
-
Animesh Manna authored
Move psr_init_dpcd() from init-connector to connector-detect function. The dpcd probe for checking panel replay capability for external dp connector is causing delay during boot which can be optimized by moving dpcd probe to connector specific detect(). v1: Initial version. v2: Add details in commit description. [Jani] Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10284Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Fixes: cceeaa31 ("drm/i915/panelreplay: Enable panel replay dpcd initialization for DP") Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240229043716.4065760-1-animesh.manna@intel.com
-
- 29 Feb, 2024 7 commits
-
-
Ville Syrjälä authored
Just return the correct thing from within the loop to make the code more readable. We have no ref counts/etc. to deal with here so no point in breaking from the loop just to return something. Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
The icl+ power well code currently assumes that every AUX power well maps to an encoder which is using said power well. That is by no menas guaranteed as we: - only register encoders for ports declared in the VBT - combo PHY HDMI-only encoder no longer get an AUX CH since commit 9856308c ("drm/i915: Only populate aux_ch if really needed") However we have places such as intel_power_domains_sanitize_state() that blindly traverse all the possible power wells. So these bits of code may very well encounbter an aux power well with no associated encoder. In this particular case the BIOS seems to have left one AUX power well enabled even though we're dealing with a HDMI only encoder on a combo PHY. We then proceed to turn off said power well and explode when we can't find a matching encoder. As a short term fix we should be able to just skip the PHY related parts of the power well programming since we know this situation can only happen with combo PHYs. Another option might be to go back to always picking an AUX CH for all encoders. However I'm a bit wary about that since we might in theory end up conflicting with the VBT AUX CH assignment. Also that wouldn't help with encoders not declared in the VBT, should we ever need to poke the corresponding power wells. Longer term we need to figure out what the actual relationship is between the PHY vs. AUX CH vs. AUX power well. Currently this is entirely unclear. Cc: stable@vger.kernel.org Fixes: 9856308c ("drm/i915: Only populate aux_ch if really needed") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10184Signed-off-by:
-
Christophe JAILLET authored
'name' may still be "intel_backlight" when backlight_device_register() is called. In such a case, using kstrdup_const() saves a memory duplication when dev_set_name() is called in backlight_device_register(). Use kfree_const() accordingly. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Jani Nikula authored
Add a function to return the expected child device size. Flip the if ladder around and use the same versions as in documentation to make it easier to verify. Return an error for unknown versions. No functional changes. v2: Move BUILD_BUG_ON() next to the expected sizes Reviewed-by:
-
Jani Nikula authored
Separate the child device size check to a separate function for clarity. No functional changes. Reviewed-by:
-
Jani Nikula authored
VBT versions since 256 have an extra byte for EFP index. v2: Update BUILD_BUG_ON() (Matt) Reviewed-by:
-
Jani Nikula authored
Sync to get the drm_printer changes to drm-intel-next. Signed-off-by:
-
- 28 Feb, 2024 4 commits
-
-
Gustavo Sousa authored
Improve documentation by giving an overview of the components involved in the generation of the CDCLK. v2: Fix htmldoc error because of missing blank line at the start of bulleted list. Reviewed-by:Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221185131.287302-2-gustavo.sousa@intel.com
-
Gustavo Sousa authored
Looks like the name and description of intel_cdclk_needs_modeset() became inaccurate as of commit 59f9e9ca ("drm/i915: Skip modeset for cdclk changes if possible"), when it became possible to update the cdclk without requiring disabling the pipes when only changing the cd2x divider was enough. Later on we also added the same type of support with squash and crawling with commit 25e0e5ae ("drm/i915/display: Do both crawl and squash when changing cdclk"), commit d4a23930 ("drm/i915: Allow cdclk squasher to be reconfigured live") and commit d62686ba ("drm/i915/adl_p: CDCLK crawl support for ADL"). As such, update that function's name and documentation to something more appropriate, since the real checks for requiring modeset are done elsewhere. v2: - Rename to intel_cdclk_clock_changed instead of intel_cdclk_params_changed. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a drm_dbg_kms message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240228092042.4125617-1-colin.i.king@gmail.comSigned-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2024-02-27-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 feature pull #2 for v6.9: Features and functionality: - DP tunneling and bandwidth allocation support (Imre) - Add more ADL-N PCI IDs (Gustavo) - Enable fastboot also on older platforms (Ville) - Bigjoiner force enable debugfs option for testing (Stan) Refactoring and cleanups: - Remove unused structs and struct members (Jiri Slaby) - Use per-device debug logging (Ville) - State check improvements (Ville) - Hardcoded cd2x divider cleanups (Ville) - CDCLK documentation updates (Ville, Rodrigo) Fixes: - HDCP MST Type1 fixes (Suraj) - Fix MTL C20 PHY PLL values (Ravi) - More hardware access prevention during init (Imre) - Always enable decompression with tile4 on Xe2 (Juha-Pekka) - Improve LNL package C residency (Suraj) drm core changes: - DP tunneling and bandwidth allocation helpers (Imre) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87sf1devbj.fsf@intel.com
-
- 27 Feb, 2024 27 commits
-
-
Imre Deak authored
Detect DP tunnels and enable the BW allocation mode on them. Send a hotplug notification to userspace in response to a BW change. Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
Imre Deak authored
The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager depends on the GFX driver reading out the sink's DPRX capabilities in response to a long HPD pulse. Since in i915 this read-out can be blocked by another connector's/encoder's hotplug event handling (which is serialized by drm_mode_config::connection_mutex), do a dummy DPRX read-out in the encoder's HPD pulse handler (which is not blocked by other encoders). Reviewed-by:
-
Imre Deak authored
Suspend and resume DP tunnels during system suspend/resume, disabling the BW allocation mode during suspend, re-enabling it after resume. This reflects the link's BW management component (Thunderbolt CM) disabling BWA during suspend. Before any BW requests the driver must read the sink's DPRX capabilities (since the BW manager requires this information, so snoops for it on AUX), so ensure this read takes place. Reviewed-by:
-
Imre Deak authored
A follow-up change will need to resume DP tunnels during system resume, so call intel_dp_sync_state() always for DDI encoders, so this function can resume the tunnels for all DP connectors. Reviewed-by:
-
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:
-
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:
-
Maxime Ripard authored
Now that the main DRM tree has moved to Gitlab, adjust the MAINTAINERS git trees to reflect the location change. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20240226152123.131406-1-mripard@kernel.orgSigned-off-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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 1 commit
-
-
Daniel Vetter authored
Thomas Zimmermann asked to backmerge -rc6 for drm-misc branches, there's a few same-area-changed conflicts (xe and amdgpu mostly) that are getting a bit too annoying. Signed-off-by:
-
