- 08 Nov, 2023 25 commits
-
-
Imre Deak authored
Enable DSC decompression for all streams. In particular atm if a sink is connected to a last branch device that is downstream of the first branch device connected to the source, decompression is not enabled for it. Similarly it's not enabled if the sink supports this with the last branch device passing through the compressed stream to it. Enable DSC in the above cases as well. Since last branch devices may handle the decompression for multiple ports, toggling DSC needs to be refcounted, add this using the DSC AUX device as a reference. v2: - Fix refcounting, setting/clearing connector->dp.dsc_decompression_enabled always as needed. (Stan) - Make the refcounting more uniform for the SST vs. MST case. - Add state checks for connector->dp.dsc_decompression_enabled and connector crtc. - Sanitize connector DSC decompression state during HW setup. - s/use_count/ref_count/ v3: - Remove stale TODO: comment to set the actual decompression_aux. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107001505.3370108-6-imre.deak@intel.com
-
Imre Deak authored
Enable passing through DSC streams to the sink in last branch devices. v2: - Fix the DPCD register address while setting/clearing the passthrough flag. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Enable DSC using the DSC AUX device stored for this purpose in the connector. For clarity add separate functions to enable/disable the decompression, since these sequences will diverge more in follow-up patches that also enable/disable DSC passthrough and on MST do the actual enabling/disabling only for the first/last user of the given AUX device. As a preparation for the latter refcounting change, also pass the atomic state to the functions. While at it set/clear only the DP_DECOMPRESSION_EN flag in the DP_DSC_ENABLE DPCD register, preserving the reserved register bits. Besides preserving the reserved register bits, the behavior stays as before, as DSC is still only enabled for the first MST stream (which a follow-up patch changes, enabling it for all streams). v2: - Add a helper function setting/clearing the decompression flag, preserving the reserved register bits. v3: - Add separate functions to enable/disable decompression and pass the atomic state to these. - Add DocBook for both functions. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v2) Signed-off-by:
-
Imre Deak authored
Enable/disable the DSC decompression in the sink/branch from the MST encoder hooks. This prepares for an upcoming patch toggling DSC for each stream as needed, but for now keeps the current behavior, as DSC is only enabled for the first MST stream. v2: - Rebased on latest drm-tip. Reviewed-by:
-
Imre Deak authored
The Synaptics MST hubs expose some sink EDID modes with a reduced HBLANK period, presumedly to save BW, which the hub expands before forwarding the stream to the sink. In particular a 4k mode with a standard CVT HBLANK period is exposed with either a CVT reduced blank RBv1,v2 (80, 160 pixel) or a non-CVT 56 pixel HBLANK period. The DP standard describes the above HBLANK expansion functionality, but it requires enabling this explicitly, whereas these hubs apply the expansion transparently. In some TBT docks with such a Synaptics hub (DELL WD22TB4) the above modes will work okay until DSC decompression is enabled in the hub for the given sink, but after this the same mode will not work reliably in decompressed mode. In another TBT dock (Thinkpad 40B0) the above modes will not work in uncompressed/18bpp mode (regardless of whether DSC decompression was enabled before or not). As a workaround force enable DSC for such modes. Apply the WA when the HBLANK period is 300ns or below, matching the above tested modes with a 533.25MHz dotclock and maximum 160 HBLANK pixels. OTOH DSC for these modes will only work above a certain compressed bpp threshold which depends on the link rate, so apply this limit as well in the workaround. On platforms, pipe/port configurations where DSC is not supported, for instance on ICL where DSC/MST is still work-in-progress, limit the minimum link bpp to 24. Apply the workaround only for Synaptics hubs which support the HBLANK expansion. v2: - Apply the WA whenever the HBLANK period is 300ns or below. v3: - Clarify in the commit log the failure modes of the different docks. - Handle platforms/pipe/port configurations without DSC support. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1) Signed-off-by:
-
Imre Deak authored
Disable the FEC ready flag in the sink during a disabling modeset. Reviewed-by:
-
Imre Deak authored
As required by the DP standard wait for the sink to detect the FEC decode enabling symbol sent by the source. There is a difference between SST and MST when the source enables the FEC encoding: on SST this happens only after enabling the transcoder, whereas on MST it happens already after enabling the transcoder function (before enabling the transcoder). Wait for the detected status at the earliest spot accordingly. v2: - Wait for the FEC detected status on SST after the transcoder is enabled. Reviewed-by:
-
Imre Deak authored
Rename intel_ddi_disable_fec_state() to intel_ddi_disable_fec(), for symmetry with intel_ddi_enable_fec(). Reviewed-by:
-
Imre Deak authored
Add the missing DSC compression disabling step for MST streams, similarly to how this is done for SST outputs. Reviewed-by:
-
Imre Deak authored
Atm the DSC PPS SDP will stay enabled after enabling and disabling DSC. This leaves an output blank after switching off DSC on it. Make sure the SDP is disabled for an uncompressed output. v2: - Disable the SDP already during output disabling. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Atm the DSC PPS SDP is programmed only if the first stream is compressed and then it's programmed only for the first stream. This left all other compressed streams blank. Program the SDP for all streams. v2: - Rebase on upstream include "intel_vdsc.h" change. Reviewed-by:
-
Imre Deak authored
If an MST stream is modeset, its state must be checked along all the other streams on the same MST link, for instance to resolve a BW overallocation of a non-sink MST port or to make sure that the FEC is enabled/disabled the same way for all these streams. To prepare for that this patch adds all the stream CRTCs to the atomic state and marks them for modeset similarly to tgl+ platforms. (If the state computation doesn't change the state the CRTC is switched back to fastset mode.) So far on tgl+ this was required because all streams in the topology shared the master transcoder. For older platforms this didn't apply but adding all the state is required now on all platforms based on the above. v2: - Add code and commit log comment clarifying the requirements on old/new platforms. (Stan) - Rename the function based on the new semantic. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
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 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:
-
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:
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:
-
