- 08 Nov, 2023 5 commits
-
-
Imre Deak authored
drm_dp_mst_atomic_check_mgr() should check for BW limitation starting from sink ports continuing towards the root port, so that drivers can use the @failing_port returned to resolve a BW overallocation in an ideal way. For instance from streams A,B,C in a topology A,B going through @failing_port and C not going through it, a BW overallocation of A,B due to a limit of the port must be resolved first before considering the limits of other ports closer to the root port. This way can avoid reducing the BW of stream C unnecessarily due to a BW limit closer to the root port. Based on the above swap the order of the BW check for the root port and the check for all the ports downstream of it (the latter going through the topology already in the sink->root port direction). Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-6-imre.deak@intel.com
-
Imre Deak authored
Factor out a helper to check the atomic state for one MST topology manager, returning the MST port where the BW limit check has failed. This will be used in a follow-up patch by the i915 driver to improve the BW sharing between MST streams. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Imre Deak authored
Add drm_dp_mst_port_downstream_of_parent() required by the i915 driver in a follow-up patch to resolve a BW overallocation of MST streams going through a given MST port. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Ville Syrjälä authored
The current code does '(bpp << 4) / 16' in the MST PBN calculation, but that is just the same as 'bpp' so the DSC codepath achieves absolutely nothing. Fix it up so that the fractional part of the bpp value is actually used instead of truncated away. 64*1006 has enough zero lsbs that we can just shift that down in the dividend and thus still manage to stick to a 32bit divisor. And while touching this, let's just make the whole thing more straightforward by making the passed in bpp value .4 binary fixed point always, instead of having to pass in different things based on whether DSC is enabled or not. v2: - Fix DSC kunit test cases. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: David Francis <David.Francis@amd.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Fixes: dc48529f ("drm/dp_mst: Add PBN calculation for DSC modes") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [Imre: Fix kunit test cases] Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Imre Deak authored
After drm_connector_init() is called the connector is visible to the rest of the kernel via the drm_mode_config::connector_list. Make sure that the DSC AUX device and capabilities are setup by that time. Another race condition is adding the connector to the connector list before drm_connector_helper_add() sets the connector helper functions. That's an unrelated issue, for which the fix is for a follow-up. One solution would be adding the connector to the connector list only during its registration in drm_connector_register(). Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 808b43fa ("drm/i915/dp_mst: Set connector DSC capabilities and decompression AUX") Reviewed-by:
-
- 07 Nov, 2023 3 commits
-
-
Jani Nikula authored
The gem code has no business accessing i915->display directly. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231102155223.2298316-2-jani.nikula@intel.com
-
Jani Nikula authored
The core code has no business accessing i915->display directly. These could be further spread to respective files, but this is a start. Signed-off-by:
-
Mika Kahola authored
Display driver shall read DPCD 00071h[3:1] during configuration to get PSR setup time. This register provides the setup time requirement on the VSC SDP entry packet. If setup time cannot be met with the current timings (e.g., PSR setup time + other blanking requirements > blanking time), driver should enable sending VSC SDP one frame earlier before sending the capture frame. BSpec: 69895 (PSR Entry Setup Frames 17:16) v2: Write frames before su entry to correct register (Ville, Jouni) Move frames before su entry calculation to it's own function (Ville, Jouni) Rename PSR Entry Setup Frames register to indicate Lunarlake specificity (Jouni) v3: Modify setup entry frames calculation function to return the actual frames (Ville) Match comment with actual implementation (Jouni) v4: Drop "set" from function naming (Jouni, Ville) Use i915 instead of dev_priv (Jouni) Signed-off-by:Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231106114228.146574-1-mika.kahola@intel.com
-
- 06 Nov, 2023 10 commits
-
-
Imre Deak authored
Enabling DSC on ICL MST outputs is broken leading to FIFO pipe / transcoder underruns and blank screen. On TGL+ platforms MST/DSC works - after fixing the known issues in [1] - however to make this work on ICL requires more work. So far DSC on MST probably didn't get enabled for users - due to an issue fixed by [2] - but after fixing that, DSC could get enabled, leading to a blank screen in ICL/MST configurations which do work atm. To prevent this disable MST/DSC on ICL for now. [1] https://lore.kernel.org/all/20231030155843.2251023-1-imre.deak@intel.com [2] https://lore.kernel.org/all/20231030155843.2251023-31-imre.deak@intel.com v2 (Ville): - Use DISPLAY_VER >= 12 instead of > 11. - Explain the ICL DSC issue in code comment. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Nirmoy Das authored
Fix below compiler warning: intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 3 [-Werror=format-truncation=] "%c/TC#%d", port_name(port), tc_port + 1); ^~ intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes into a destination of size 8 snprintf(tc->port_name, sizeof(tc->port_name), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%c/TC#%d", port_name(port), tc_port + 1); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v2: use kasprintf(Imre) v3: use const for port_name, and fix tc mem leak(Imre) Fixes: 3eafcddf ("drm/i915/tc: Move TC port fields to a new intel_tc_port struct") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Iterators operate on struct intel_gt so lets move it to intel_gt.h in order to make i915_drv.h less of a dumping ground for stuff. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by:
Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Unused macro after 99919be7 ("drm/i915/gem: Zap the i915_gem_object_blt code") removed some code. Signed-off-by:
-
Ville Syrjälä authored
The code to determine the pre-ICL DSI port control register is repeated several times. Consolidate. vlv_dsi_clear_device_ready() is left with the open-coded version due to the weirdness with port A vs. C on VLV/CHV. Signed-off-by:
-
Ville Syrjälä authored
GLK has its own glk_dsi_clear_device_ready() so remove the dead GLK checks from vlv_dsi_clear_device_ready(). Sadly BXT still uses vlv_dsi_clear_device_ready() so the code still looks like a mess due to the difference in VLV/CHV vs. BXT port A/C shenanigans. Signed-off-by:
-
Ville Syrjälä authored
Stop repeating the same logic to determine the correct config space register for MCHBAR. Signed-off-by:
-
Ville Syrjälä authored
'reg' is a very non-descriptive name. Just get rid of the silly local variable and spell out the full register name always. Signed-off-by:
-
Ville Syrjälä authored
We have the same code to determine the CHICKEN_TRANS register offset sprinkled in a dozen places. Hoover it up into a small helper. TODO: find a better home for this Signed-off-by:
-
Jouni Högander authored
We are preparing for Xe. Xe_bo doesn't have obj->base. Due to this use intel_bo_to_drm_bo instead in intel_prepare_plane_fb. Signed-off-by:
-
- 03 Nov, 2023 1 commit
-
-
Ville Syrjälä authored
On GLK CDCLK frequency needs to be at least 2*96 MHz when accessing the audio hardware. Currently we bump the CDCLK frequency up temporarily (if not high enough already) whenever audio hardware is being accessed, and drop it back down afterwards. With a single active pipe this works just fine as we can switch between all the valid CDCLK frequencies by changing the cd2x divider, which doesn't require a full modeset. However with multiple active pipes the cd2x divider trick no longer works, and thus we end up blinking all displays off and back on. To avoid this let's just bump the CDCLK frequency to >=2*96MHz whenever multiple pipes are active. The downside is slightly higher power consumption, but that seems like an acceptable tradeoff. With a single active pipe we can stick to the current more optiomal (from power comsumption POV) behaviour. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9599Signed-off-by:
-
- 02 Nov, 2023 1 commit
-
-
Jouni Högander authored
We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence implementation. Lets drop i915_sw_fence usage from display code and use dma_fence interfaces directly. For this purpose stack dma fences from related objects into new plane state. Drm_gem_plane_helper_prepare_fb can be used for fences in new fb. Separate local implementation is used for Stacking fences from old fb into new plane state. Then wait for these stacked fences during atomic commit. There is no be need for separate GPU reset handling in intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is detected and GPU is being reset. v4: - Drop to_new_plane_state suffix from add_dma_resv_fences - Use dma_resv_usage_rw(false) (DMA_RESV_USAGE_WRITE) v3: - Rename add_fences and it's parameters - Remove signaled check - Remove waiting old_plane_state fences v2: - Add fences from old fb into new_plane_state->uapi.fence rather than into old_plane_state->uapi.fence Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
- 01 Nov, 2023 4 commits
-
-
Ville Syrjälä authored
Since we're asked to disable FECSTALL_DIS_DPTSTREAM_DPTTG when the transcoder is disabled it seems prudent to also clear it when enabliing the transcoder w/o FEC, just in case someone else left it enabled by mistake. Signed-off-by:
-
Ville Syrjälä authored
Follow the bspec sequence more closely and clear ACT sent just before triggering the allocation. Can't see why we'd want to deviate from the spec sequence here. Signed-off-by:
-
Ville Syrjälä authored
Bspec tells us that we should disable the transcoder before deleting the payload. Looks like this has been reversed since MST support was added. I suppose this shouldn't matter in practice since the downstream device shouldn't really do anything with the new payload until we send the ACT. But I see no compelling reason to deviate from the bspec sequence regardless. Signed-off-by:
-
Ville Syrjälä authored
The DP modeset sequence asks us to disable TRANSCONF before clearing the FECSTALL_DIS_DPTSTREAM_DPTTG bit, although we are still asked to wait for the transcoder to stop only after both steps have been done. Signed-off-by:
-
- 31 Oct, 2023 10 commits
-
-
Nirmoy Das authored
Handle platforms with multiple GTs by iterate over all GTs. Add a Fixes commit so this gets propagated for MTL support. Fixes: 213c4367 ("drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake") Suggested-by:
John Harrison <john.c.harrison@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
-
Suraj Kandpal authored
When we dock a monitor we end up with a enable and disable connector cycle but if hdcp content is running we get the userspace in enabled state and driver maintaining a undesired state which causes the content to stop playing and we only enable hdcp if the userspace state in desired. This patch fixes that. --v2 -Move code to intel_hdcp [Jani] Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Let's convert intel_hdcp_enable to a blanket function which just has some conditions which needs to be checked before connectors enable hdcp. This cleans up code and avoids code duplication. --v3 -Keep function name as intel_hdcp_enable() [Jani] Signed-off-by:
-
Suraj Kandpal authored
Rename hdcp 1.4 enablement function from _intel_hdcp_enable to intel_hdcp1_enable to better represent what version of hdcp is being enabled Signed-off-by:
-
Ville Syrjälä authored
We are asked to reprogram PEG_BAND_GAP_DATA prior to enabling hotplug detection on the g45 HDMI/DP ports. Currently we do said reprogamming from the DP/HDMI connector initialization functions. That code should be mostly platform agnostic so clearly not the best place for this. Move the workaround to the place where we actually enable HPD detection. Signed-off-by:
-
Ville Syrjälä authored
We have a bit of duplicated code around the DPLL disabling. Extract that to a new function, and for symmetry also do the same for the enable direction. Signed-off-by:
-
Ville Syrjälä authored
The extra DPLL power domain is currently handled in three places: - combo_pll_enable() - combo_pll_disable() - readout_dpll_hw_state() First two of those are low level PLL funcs, but the third is a higher level thing. So the current situation is rather inconsistent. Unify this by moving the PLL enable/disable up one level. This also means the extra power domain could be trivially be used by other platforms as well. Signed-off-by:
-
Ville Syrjälä authored
Just include the JSL/EHL DPLL4 extra power domain in the dpll_info struct. This way the same approach could be used by other platforms as well (should the need arise), and we don't have to sprinkle platform checks all over the place. Note that I'm perhaps slightly abusing things here as power_domain==0 (which is actually POWER_DOMAIN_DISPLAY_CORE) now indicates that no extra power domain is needed. I suppose using POWER_DOMAIN_INVALID would be more correct, but then we'd have to sprinkle that to all the other DPLLs. Signed-off-by:
-
Ville Syrjälä authored
Use named initializers when populating the DPLL info. This is just more convenient and less error prone as we no longer have to keep the initializers in a specific order. Signed-off-by:
-
Ville Syrjälä authored
Apparently some BDW machines (eg. HP Pavilion 15-ab) shipped with a VBT inherited from some earlier HSW model. On HSW the HDMI level shift value could go up to 11, whereas on BDW the maximum value is 9. The DDI code does clamp the bogus value, but it does so with a WARN which we don't really want. To avoid that let's just sanitize the bogus VBT HDMI level shift value ahead of time for all BDW machines. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9461Signed-off-by:
-
- 30 Oct, 2023 3 commits
-
-
Jani Nikula authored
Keep the display build lists together. v2: Rebase Reviewed-by:
-
Jani Nikula authored
Unify the line continuations and indents, and sort the build lists. Reviewed-by:
-
Chaitanya Kumar Borah authored
eDP specification supports HBR3 link rate since v1.4a. Moreover, C10 phy can support HBR3 link rate for both DP and eDP. Therefore, do not clamp the supported rates for eDP at 6.75Gbps. Cc: <stable@vger.kernel.org> BSpec: 70073 74224 Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
-
- 29 Oct, 2023 3 commits
-
-
Lucas De Marchi authored
As done with the hw readout, properly abstract the C10/C20 phy details inside intel_cx0_phy.c. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231018222831.4132968-3-lucas.demarchi@intel.com
-
Lucas De Marchi authored
intel_cx0_phy.[ch] should contain the details about C10/C20, not leaking it to the rest of the driver. Start abstracting this by exporting a single PLL hw readout that handles the differences between C20 and C10 internally to that compilation unit. Signed-off-by:
-
Lucas De Marchi authored
With MTL adding PICA between the port and the real phy, the path add for DG2 stopped being followed and newer platforms are simply using the older path for TC phys. LNL is no different than MTL in this aspect, so just add it to the mess. In future the phy and port designation and deciding if it's TC should better be cleaned up. To make it just a bit better, also change intel_phy_is_snps() to show this is DG2-only. Signed-off-by:
-
