- 08 Nov, 2023 13 commits
-
-
Imre Deak authored
Atm, the BW allocated for an MST stream doesn't take into account the DSC control symbol (EOC) and data alignment overhead on the local (first downstream) MST link (reflected by the data M/N/TU values) and - besides the above overheads - the FEC symbol overhead on 8b/10b remote (after a downstream branch device) MST links. In addition the FEC overhead used on the local link is a fixed amount, which only applies to certain modes, but not enough for all modes; add a code comment clarifying this. Fix the above by calculating the data M/N values with the total BW overhead (not including the SSC overhead, since this isn't enabled by the source device) and using this the PBN and TU values for the local link and PBN for remote links (including SSC, since this is mandatory for links after downstream branch devices). For now keep the current fixed FEC overhead as a minimum, since this is what bspec requires for audio functionality. Calculate the effective link BW in a clearer way, applying the channel coding efficiency based on the coding type. The calculation was correct for 8b/10b, but not for 128b/132b links; this patch leaves the behavior for this unchanged, leaving the fix for a follow-up. v2: - Fix TU size programmed to the HW, making it match the payload size programmed to the payload table. v3: - Add code comment about the connection between the payload's size in the payload table and the corresponding PBN value. (Ville) - Add WARN_ON(remote_m_n.tu < dp_m_n.tu). (Ville) - Add code comment about factors not accounted for by the BW calculation in intel_dp_mst_mode_valid_ctx() (and compute config). (Ville) - Simplify calculation of PBN to remote_m_n.tu * mst_state->pbn_div. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1) Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107001505.3370108-2-imre.deak@intel.com
-
Imre Deak authored
A follow-up MST patch will need to specify the total BW allocation overhead, prepare for that here by passing the amount of overhead to intel_link_compute_m_n(), keeping the existing behavior. v2: - Fix passing the correct crtc_state->fec_enable param in intel_dp_mst_compute_link_config() / intel_dp_dsc_mst_compute_link_config(). Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1) Signed-off-by:
-
Imre Deak authored
A follow-up patch will add up all the overheads on a DP link, where it makes more sense to specify each overhead factor in terms of the added overhead amount vs. the reciprocal remainder (of usable BW remaining after deducting the overhead). Prepare for that here, keeping the existing behavior. Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Imre Deak authored
Enable FEC in crtc_state, as soon as it's known it will be needed by DSC. This fixes the calculation of BW allocation overhead, in case DSC is enabled by falling back to it during the encoder compute config phase (vs. enabling FEC due to DSC being enabled on other streams). v2: - Enable FEC only in intel_dp_mst_find_vcpi_slots_for_bpp(), since only by that will crtc_state->port_clock be set, which in turn is needed by intel_dp_is_uhbr(). Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1) Signed-off-by:
-
Imre Deak authored
Add helpers drivers can use to calculate the BW allocation overhead - due to SSC, FEC, DSC and data alignment on symbol cycles - and the channel coding efficiency - due to the 8b/10b, 128b/132b encoding. On 128b/132b links the FEC overhead is part of the coding efficiency, so not accounted for in the BW allocation overhead. The drivers can use these functions to calculate a ratio, controlling the stream symbol insertion rate of the source device in each SST TU or MST MTP frame. Drivers can calculate this m/n = (pixel_data_rate * drm_dp_bw_overhead()) / (link_data_rate * drm_dp_bw_channel_coding_efficiency()) ratio for a given link and pixel stream and with that the slots_per_mtp = CEIL(64 * m / n) allocated slots per MTP for the stream in a link frame and with that the pbn = slots_per_mtp * drm_mst_get_pbn_divider() allocated PBNs for the stream on the MST link path. Take drm_dp_bw_overhead() into use in drm_dp_calc_pbn_mode(), for drivers calculating the PBN value directly. v2: - Add dockbook description to drm_dp_bw_channel_coding_efficiency(). (LKP). - Clarify the way m/n ratio is calculated in the commit log. v3: - Fix compile breakage for !CONFIG_BACKLIGHT_CLASS_DEVICE. (LKP) - Account for FEC_PM overhead (+ 0.0015625 %), add comment with the formula to calculate the total FEC overhead. (Ville) v4: - Rename DRM_DP_OVERHEAD_SSC to DRM_DP_OVERHEAD_SSC_REF_CLK. (Ville) v5: - Clarify in the commit log what MTP means. - Simplify the commit log's formula to calculate PBN. Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: kernel test robot <lkp@intel.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v2) Acked-by:Maxime Ripard <mripard@kernel.org> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Imre Deak authored
Add a quirk for Synaptics MST hubs, which require a workaround - at leat on i915 - for some modes, on which the hub applies HBLANK expansion. These modes will only work by enabling DSC decompression for them, a follow-up patch will do this in i915. v2: - Fix the quirk name in its DocBook description. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Imre Deak authored
Add the DPCD flag to enable DSC passthrough in a last branch device, used in a follow-up i915 patch. Also add a flag to detect HBLANK expansion support in a branch device, used by a workaround in a follow-up i915 patch. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Imre Deak authored
The Synaptics MST branch devices support DSC decompression on all their output ports, provided that they are last branch devices (with their output ports connected to the sinks). The Thinkpad 40B0 TBT dock for instance has two such branch devices, a secondary one connected to one of the output ports of the primary; hence the decompression needs to be enabled in both branch devices to enable decompression for all the sinks. Based on the above add support for enabling decompression in last Synaptics branch devices. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
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:
-
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 8 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:
-
