summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/intel_dp.h
AgeCommit message (Collapse)Author
2024-04-09drm/i915: Pass connector to intel_dp_need_bigjoiner()Ville Syrjälä
Pass the connector explicitly to intel_dp_need_bigjoiner() so that it'll actually check the correct place for the bigjoiner force flag. Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-11-ville.syrjala@linux.intel.com
2024-04-09drm/i915: Extract intel_dp_joiner_needs_dsc()Ville Syrjälä
Pull the "does joiner need DSC?" check into a helper. MST will want to use this too at some point. Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-9-ville.syrjala@linux.intel.com
2024-04-09drm/i915: s/intel_dp_can_bigjoiner()/intel_dp_has_bigjoiner()/Ville Syrjälä
Rename intel_dp_can_bigjoiner() to intel_dp_has_bigjoiner() to better reflect its function. Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-8-ville.syrjala@linux.intel.com
2024-04-04drm/i915/dp: Add wrapper function to check AS SDPMitul Golani
Add a wrapper function to check if both the source and sink support Adaptive Sync SDP. --v1: Just use drm/i915/dp in subject line. Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322031157.3823909-6-mitulkumar.ajitkumar.golani@intel.com
2024-03-05drm/i915/dp: Fix connector DSC HW state readoutImre Deak
The DSC HW state of DP connectors is read out during driver loading and system resume in intel_modeset_update_connector_atomic_state(). This function is called for all connectors though and so the state of DSI connectors will also get updated incorrectly, triggering a WARN there wrt. the DSC decompression AUX device. Fix the above by moving the DSC state readout to a new DP connector specific sync_state() hook. This is anyway the logical place to update the connector object's state vs. the connector's atomic state. Fixes: b2608c6b3212 ("drm/i915/dp_mst: Enable MST DSC decompression for all streams") Reported-and-tested-by: Drew Davenport <ddavenport@chromium.org> Closes: https://lore.kernel.org/all/Zb0q8IDVXS0HxJyj@chromium.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205132631.1588577-1-imre.deak@intel.com
2024-02-27drm/i915/dp: Add intel_dp_max_link_data_rate()Imre Deak
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: 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-11-imre.deak@intel.com
2024-02-27drm/i915/dp: Factor out intel_dp_update_sink_caps()Imre Deak
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: 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-9-imre.deak@intel.com
2024-02-27drm/i915/dp: Export intel_dp_max_common_rate/lane_count()Imre Deak
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: 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-8-imre.deak@intel.com
2024-02-27drm/i915/dp: Factor out intel_dp_config_required_rate()Imre Deak
Factor out intel_dp_config_required_rate() 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-7-imre.deak@intel.com
2024-02-27drm/i915/dp: Use drm_dp_max_dprx_data_rate()Imre Deak
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: 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-6-imre.deak@intel.com
2024-02-27drm/i915/dp: Add support to notify MST connectors to retry modesetsImre Deak
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: 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-5-imre.deak@intel.com
2024-01-08drm/i915: Add intel_digital_port lock/unlock hooksImre Deak
Add hooks to intel_digital_port to lock and unlock the port and add a helper to check the connector's detect status while the port is locked already. This simplifies checking the connector detect status in intel_dp_aux_xfer() and intel_digital_port_connected() in the next two patches aborting AUX transfers on all DP connectors (except eDP) and filtering HPD glitches. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-11-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
2023-12-22drm/i915/display: Unify VSC SPD preparationJouni Högander
There is no specific reason to prepare VSC SDP for PSR case somehow differently. Unify PSR and non-PSR preparation. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Shawn Lee <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231220103609.1384523-4-jouni.hogander@intel.com
2023-11-21drm/i915/dp_mst: Fix PBN / MTP_TU size calculation for UHBR ratesImre Deak
Atm the allocated MST PBN value is calculated from the TU size (number of allocated MTP slots) as PBN = TU * pbn_div pbn_div being the link BW for each MTP slot. For DP 1.4 link rates this worked, as pbn_div there is guraranteed to be an integer number, however on UHBR this isn't the case. To get a PBN, TU pair where TU is a properly rounded-up value covering all the BW corresponding to PBN, calculate first PBN and from PBN the TU value. Calculate PBN directly from the effective pixel data rate, instead of calculating it indirectly from the corresponding TU and pbn_div values (which are in turn derived from the pixel data rate and BW overhead). Add a helper function to calculate the effective data rate, also adding a note that callers of intel_dp_link_required() may also need to check the effective data rate (vs. the data rate w/o the BW overhead). While at it add a note to check if WA#14013163432 is applicable. v2: - Fix PBN calculation, deriving it from the effective data rate directly instead of using the indirect TU and pbn_div values for this. - Add a note about WA#14013163432. (Arun) v3: - Fix rounding up quotient while calculating remote_tu. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> (v1) Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231117150929.1767227-3-imre.deak@intel.com
2023-11-21drm/i915/dp: Fix UHBR link M/N valuesImre Deak
The link M/N ratio is the data rate / link symbol clock rate, fix things up accordingly. On DP 1.4 this ratio was correct as the link symbol clock rate in that case matched the link data rate (in bytes/sec units, the symbol size being 8 bits), however it wasn't correct for UHBR rates where the symbol size is 32 bits. Kudos to Arun noticing in Bspec the incorrect use of link data rate in the ratio's N value. Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231116131841.1588781-7-imre.deak@intel.com
2023-11-21drm/i915/dp: Replace intel_dp_is_uhbr_rate() with drm_dp_is_uhbr_rate()Imre Deak
Replace intel_dp_is_uhbr_rate() with the recently added drm_dp_is_uhbr_rate(). Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231116131841.1588781-5-imre.deak@intel.com
2023-11-08drm/i915: Query compressed bpp properly using correct DPCD and DP Spec infoStanislav Lisovskiy
Currently we seem to be using wrong DPCD register for reading compressed bpps, reading min/max input bpc instead of compressed bpp. Fix that, so that we now apply min/max compressed bpp limitations we get from DP Spec Table 2-157 DP v2.0 and/or correspondent DPCD register DP_DSC_MAX_BITS_PER_PIXEL_LOW/HIGH. This might also allow us to get rid of an ugly compressed bpp recalculation, which we had to add to make some MST hubs usable. v2: - Fix operator precedence v3: - Added debug info about compressed bpps v4: - Don't try to intersect Sink input bpp and compressed bpps. v5: - Decrease step while looking for suitable compressed bpp to accommodate. v6: - Use helper for getting min and max compressed_bpp (Ankit) v7: - Fix checkpatch warning (Ankit) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-31-imre.deak@intel.com
2023-11-08drm/i915/dp_mst: Improve BW sharing between MST streamsImre Deak
At the moment modesetting a stream CRTC will fail if the stream's BW along with the current BW of all the other streams on the same MST link is above the total BW of the MST link. Make the BW sharing more dynamic by trying to reduce the link bpp of one or more streams on the MST link in this case. When selecting a stream to reduce the BW for, take into account which link segment in the MST topology ran out of BW and which streams go through this link segment. For instance with A,B,C streams in the same MST topology A and B may share the BW of a link segment downstream of a branch device, stream C not downstream of the branch device, hence not affecting this BW. If this link segment's BW runs out one or both of stream A/B's BW will be reduced until their total BW is within limits. While reducing the link bpp for a given stream DSC may need to be enabled for it, which requires FEC on the whole MST link. Check for this condition and recompute the state for all streams taking the FEC overhead into account (on 8b/10b links). v2: - Rebase on s/min_bpp_pipes/min_bpp_reached_pipes/ change. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-29-imre.deak@intel.com
2023-11-08drm/i915/dp: Enable DSC via the connector decompression AUXImre Deak
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 <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-24-imre.deak@intel.com
2023-11-08drm/i915/dp: Pass actual BW overhead to m_n calculationImre Deak
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 <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-13-imre.deak@intel.com
2023-11-08drm/i915/dp_mst: Enable FEC early once it's known DSC is neededImre Deak
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 <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-11-imre.deak@intel.com
2023-10-16drm/i915/dp: Remove unused DSC caps from intel_dpImre Deak
The previous patches converted all users of the DSC DPCD caps to look these up from the connector, so remove the version stored in intel_dp. A follow-up patchset will read out the MST connector specific capabilities in intel_dp_add_mst_connector() -> intel_dp_mst_read_decompression_port_dsc_caps(). v2: - Rebased on intel_edp_get_dsc_sink_cap() addition in the patchset. v3: - Rebased on read-out fix for eDP in the patchset. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1) 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/20231011171606.2540078-3-imre.deak@intel.com
2023-10-16drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_get_slice_count()Imre Deak
Use the connector's DSC DPCD capabilities in intel_dp_dsc_get_slice_count(). 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/20231006133727.1822579-16-imre.deak@intel.com
2023-10-16drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_max_bpp()Imre Deak
Use the connector's DSC DPCD capabilities in intel_dp_dsc_compute_max_bpp() instead of the version stored in the encoder. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@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/20231006133727.1822579-7-imre.deak@intel.com
2023-10-16drm/i915/dp_mst: Set connector DSC capabilities and decompression AUXImre Deak
Similarly to eDP and SST-DP connectors read out the DSC capabilities for MST connectors as well. Atm these will match the root port's DSC caps and only used after a follow-up change enables the decompression for each stream separately (vs. the current way of enabling it only globally in the first branch device downstream of the root port). Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@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/20231010112504.2156789-3-imre.deak@intel.com
2023-09-28drm/i915/dp: Update the link bpp limits for DSC modeImre Deak
In non-DSC mode the link bpp can be set in 2*3 bpp steps in the pipe bpp range, while in DSC mode it can be set in 1/16 bpp steps to any value up to the maximum pipe bpp. Update the limits accordingly in both modes to prepare for a follow-up patch which may need to reduce the max link bpp value and starts to check the link bpp limits in DSC mode as well. While at it add more detail to the link limit debug print and print it also for DSC mode. v2: - Add to_bpp_frac_dec() instead of open coding it. (Jani) v3: (Ville) - Add BPP_X16_FMT / BPP_X16_ARG. - Add TODO: comment about initializing the DSC link bpp limits earlier. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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/20230921195159.2646027-5-imre.deak@intel.com
2023-09-28drm/i915/dp: Track the pipe and link bpp limits separatelyImre Deak
A follow-up patch will need to limit the output link bpp both in the non-DSC and DSC configuration, so track the pipe and link bpp limits separately in the link_config_limits struct. Use .4 fixed point format for link bpp matching the 1/16 bpp granularity in DSC mode and for now keep this limit matching the pipe bpp limit. v2: (Jani) - Add to_bpp_int(), to_bpp_x16() helpers instead of opencoding them. - Rename link_config_limits::link.min/max_bpp to min/max_bpp_x16. Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Luca Coelho <luciano.coelho@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/20230921195159.2646027-3-imre.deak@intel.com
2023-08-25drm/i915/display: configure SDP split for DP-MSTVinod Govindapillai
Extend the SDP split audio config for DP-MST Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230822204818.109742-3-vinod.govindapillai@intel.com
2023-08-18drm/i915/dp: Rename helper to get DSC max pipe_bppAnkit Nautiyal
The helper intel_dp_dsc_compute_bpp gives the maximum pipe bpp that is allowed with DSC. Rename the this to reflect that it returns max pipe bpp supported with DSC. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230817142459.89764-13-ankit.k.nautiyal@intel.com
2023-08-18drm/i915/dp: Use consistent name for link bpp and compressed bppAnkit Nautiyal
Currently there are many places where we use output_bpp for link bpp and compressed bpp. Lets use consistent naming: output_bpp : The intermediate value taking into account the output_format chroma subsampling. compressed_bpp : target bpp for the DSC encoder. link_bpp : final bpp used in the link. For 444 sampling without DSC: link_bpp = output_bpp = pipe_bpp For 420 sampling without DSC: output_bpp = pipe_bpp / 2 link_bpp = output_bpp For 444 sampling with DSC: output_bpp = pipe_bpp link_bpp = compressed_bpp, computed with output_bpp (i.e. pipe_bpp in this case) For 420 sampling with DSC: output_bpp = pipe_bpp/2 link_bpp = compressed_bpp, computed with output_bpp Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230817142459.89764-5-ankit.k.nautiyal@intel.com
2023-08-18drm/i915/dp_mst: Use output_format to get the final link bppAnkit Nautiyal
The final link bpp used to calculate the m_n values depend on the output_format. Though the output_format is set to RGB for MST case and the link bpp will be same as the pipe bpp, for the sake of semantics, lets calculate the m_n values with the link bpp, instead of pipe_bpp. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230817142459.89764-4-ankit.k.nautiyal@intel.com
2023-08-18drm/i915/dp: Consider output_format while computing dsc bppAnkit Nautiyal
While using DSC the compressed bpp is computed assuming RGB output format. Consider the output_format and compute the compressed bpp during mode valid and compute config steps. For DP-MST we currently use RGB output format only, so continue using RGB while computing compressed bpp for MST case. v2: Use output_bpp instead for pipe_bpp to clamp compressed_bpp. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230817142459.89764-2-ankit.k.nautiyal@intel.com
2023-06-02drm/i915/dp: stop caching has_hdmi_sink in struct intel_dpJani Nikula
Use the information stored in display info. Add intel_dp_has_hdmi_sink() helper to access it. v2: Rebased Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/748103fda572b3552e5bbdafb300d8508d4eeaf4.1685437500.git.jani.nikula@intel.com
2023-05-16drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink ↵Imre Deak
disconnects If the output on a DP-alt link with its sink disconnected is kept enabled for too long (about 20 sec), then some IOM/TCSS firmware timeout will cause havoc on the PCI bus, at least for other GFX devices on it which will stop powering up. Since user space is not guaranteed to do a disabling modeset in time, switch such disconnected but active links to TBT mode - which is without such shortcomings - with a 2 second delay. If the above condition is detected already during the driver load/system resume sanitization step disable the output instead, as at that point no user space or kernel client depends on a consistent output state yet and because subsequent atomic modeset on such connectors - without the actual sink capabilities available - can fail. An active/disconnected port as above will also block the HPD status of other active/disconnected ports to get updated (stuck in the connected state), until the former port is disabled, its PHY is disconnected and a ~10 ms delay has elapsed. This means the link state for all TypeC ports/CRTCs must be rechecked after a CRTC is disabled due to the above reason. For this disconnect the PHY synchronously after the CRTC/port is disabled and recheck all CRTCs for the above condition whenever such a port is disabled. To account for a race condition during driver loading where the sink is disconnected after the above sanitization step and before the HPD interrupts get enabled, do an explicit check/link reset if needed from the encoder's late_register hook, which is called after the HPD interrupts are enabled already. v2: - Handle an active/disconnected port blocking the HPD state update of another active/disconnected port. - Cancel the delayed work resetting the link also from the encoder enable/suspend/shutdown hooks. - Rebase on the earlier intel_modeset_lock_ctx_retry() addition, fixing here the missed atomic state reset in case of a retry. - Fix handling of an error return from intel_atomic_get_crtc_state(). - Recheck if the port needs to be reset after all the atomic state is locked and async commits are waited on. v3: - Add intel_crtc_needs_link_reset(), instead of open-coding it, keep intel_crtc_has_encoders(). (Ville) - Fix state dumping and use a bitmask to track disabled CRTCs in intel_sanitize_all_crtcs(). (Ville) - Set internal in intel_atomic_state right after allocating it. (Ville) - Recheck all CRTCs (not yet force-disabled) after a CRTC is force-disabled for any reason (not only due to a link state) in intel_sanitize_all_crtcs(). - Reduce delay after CRTC disabling to 20ms, and use the simpler msleep(). - Clarify code comment about HPD behaviour in intel_sanitize_all_crtcs(). - Move all the TC link reset logic to intel_tc.c . - Cancel the link reset work synchronously during system suspend, driver unload and shutdown. v4: - Rebased on previous patch, which allows calling the TC port suspend/cleanup handlers without modeset locks held; remove the display driver suspended assert from the link reset work accordingly. v5: (Ville) - Remove reset work canceling from intel_ddi_pre_pll_enable(). - Track a crtc vs. pipe mask in intel_sanitize_all_crtcs(). - Add reset_link_commit() to clarify the intel_modeset_lock_ctx_retry loop. Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5860 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/20230512195513.2699-2-imre.deak@intel.com
2022-12-13drm/i915: Bpp/timeslot calculation fixes for DP MST DSCStanislav Lisovskiy
Fix intel_dp_dsc_compute_config, previously timeslots parameter was used in fact not as a timeslots, but more like a ratio timeslots/64, which of course didn't have any effect for SST DSC, but causes now issues for MST DSC. Secondly we need to calculate pipe_bpp using intel_dp_dsc_compute_bpp only for SST DSC case, while for MST case it has been calculated earlier already with intel_dp_dsc_mst_compute_link_config. Third we also were wrongly determining sink min bpp/max bpp, those limites should be intersected with our limits to find common acceptable bpp's, plus on top of that we should align those with VESA bpps and only then calculate required timeslots amount. Some MST hubs started to work only after third change was made. v2: Make kernel test robot happy(claimed there was unitialzed use, while there is none) v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp (Manasi Navare) Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123100718.29130-1-stanislav.lisovskiy@intel.com
2022-12-13drm/i915: Extract VESA DSC bpp alignment to separate functionStanislav Lisovskiy
We might to use that function separately from intel_dp_dsc_compute_config for DP DSC over MST case, because allocating bandwidth in that case can be a bit more tricky. So in order to avoid code copy-pasta lets extract this to separate function and reuse it for both SST and MST cases. v2: Removed multiple blank lines v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp to reflect its meaning more properly. (Manasi Navare) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123100551.29080-1-stanislav.lisovskiy@intel.com
2022-12-13drm/i915: Add DSC support to MST pathStanislav Lisovskiy
Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST. v2: Removed intel_dp_mst_dsc_compute_config and refactored intel_dp_dsc_compute_config to support timeslots as a parameter(Ville Syrjälä) v3: - Rebased - Added a debug to see that we at least try reserving VCPI slots using DSC, because currently its not visible from the logs, thus making debugging more tricky. - Moved timeslots to numerator, where it should be. v4: - Call drm_dp_mst_atomic_check already during link config computation, because we need to know already by this moment if uncompressed amount of VCPI slots needed can fit, otherwise we need to use DSC. (thanks to Vinod Govindapillai for pointing this out) v5: - Put pipe_config->bigjoiner_pipes back to original condition in intel_dp_dsc_compute_config (don't remember when I lost it) v6: - Removed unnecessary drm_dp_mst_atomic_check as it is now always called in a newly introduced intel_dp_mst_find_vcpi_slots_for_bpp function (Vinod Govindapillai) Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-5-stanislav.lisovskiy@intel.com
2022-09-06Revert "drm/i915: Add DSC support to MST path"Jani Nikula
This reverts commit e1a84ba850128b3984973786829e610ae4ee0e2e. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06drm/i915: Add DSC support to MST pathStanislav Lisovskiy
Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST. v2: Removed intel_dp_mst_dsc_compute_config and refactored intel_dp_dsc_compute_config to support timeslots as a parameter(Ville Syrjälä) v3: - Rebased - Added a debug to see that we at least try reserving VCPI slots using DSC, because currently its not visible from the logs, thus making debugging more tricky. - Moved timeslots to numerator, where it should be. v4: - Call drm_dp_mst_atomic_check already during link config computation, because we need to know already by this moment if uncompressed amount of VCPI slots needed can fit, otherwise we need to use DSC. (thanks to Vinod Govindapillai for pointing this out) v5: - Put pipe_config->bigjoiner_pipes back to original condition in intel_dp_dsc_compute_config (don't remember when I lost it) v6: - Removed unnecessary drm_dp_mst_atomic_check as it is now always called in a newly introduced intel_dp_mst_find_vcpi_slots_for_bpp function (Vinod Govindapillai) Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-5-stanislav.lisovskiy@intel.com
2022-05-27drm/i915/bios: Split VBT data into per-panel vs. global partsVille Syrjälä
Move the panel specific VBT parsing to happen during the output probing stage. Needs to be done because the VBT parsing will need to look at the EDID to determine the correct panel_type on some machines. We split the parsed VBT data (i915->vbt) along the same boundary. For the moment we just hoist all the panel specific stuff into connector->panel.vbt since that seems like the most convenient place for eg. the backlight code. Note that we simply drop the drrs type check from intel_drrs_frontbuffer_update() since that operates on the whole device rather than a specific connector/encoder. But the check was just a micro optimization so removing it doesn't actually mattter for correctness. TODO: Lot's of cleanup to be done in the future. Eg. most of the DSI stuff could probably be eliminated entirely and just parsed on demand during DSI init. v2: Note the intel_drrs_frontbuffer_update() change Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-05-27drm/i915: Extract intel_edp_fixup_vbt_bpp()Ville Syrjälä
We have the same "override eDP VBT bpp with the current bpp" code duplciated in two places. Extract it to a helper function. TODO: Having this in .get_config() is pretty ugly. Should probably try to move it somewhere else (setup_hw_state()/etc.)... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-02drm/i915: Only include i915_reg.h from .c filesMatt Roper
Several of our i915 header files, have been including i915_reg.h. This means that any change to i915_reg.h will trigger a full rebuild of pretty much every file of the driver, even those that don't have any kind of register access. Let's delete the i915_reg.h include from all headers and add an explicit include from the .c files that truly need the register definitions; those that need a definition of i915_reg_t for a function definition can get it from i915_reg_defs.h instead. We also remove two non-register #define's (VLV_DISPLAY_BASE and GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the i915_reg.h include from a couple of headers. There's probably a lot more header dependency optimization possible, but the changes here roughly cut the number of files compiled after 'touch i915_reg.h' in half --- a good first step. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-7-matthew.d.roper@intel.com
2021-12-01drm/i915/dp: Perform 30ms delay after source OUI writeLyude Paul
While working on supporting the Intel HDR backlight interface, I noticed that there's a couple of laptops that will very rarely manage to boot up without detecting Intel HDR backlight support - even though it's supported on the system. One example of such a laptop is the Lenovo P17 1st generation. Following some investigation Ville Syrjälä did through the docs they have available to them, they discovered that there's actually supposed to be a 30ms wait after writing the source OUI before we begin setting up the rest of the backlight interface. This seems to be correct, as adding this 30ms delay seems to have completely fixed the probing issues I was previously seeing. So - let's start performing a 30ms wait after writing the OUI, which we do in a manner similar to how we keep track of PPS delays (e.g. record the timestamp of the OUI write, and then wait for however many ms are left since that timestamp right before we interact with the backlight) in order to avoid waiting any longer then we need to. As well, this also avoids us performing this delay on systems where we don't end up using the HDR backlight interface. V3: * Move last_oui_write into intel_dp V2: * Move panel delays into intel_pps Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211130212912.212044-1-lyude@redhat.com
2021-09-30drm/i915: Enable TPS3/4 on all platforms that support themVille Syrjälä
Stop using HBR2/3 support as a proxy for TPS3/4 support. The two are no longer 1:1 in the hardware, arguably they never were due to HSW ULX which does support TPS3 while being limited to HBR1. In more recent times GLK gained support for TPS4 while being limited to HBR2. And on CNL+ some ports support HBR3 while others are limited to HBR2, but all ports support TPS4. v2: s/INTEL_GEN/DISPLAY_VER/ Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929162404.6717-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2021-09-23drm/i915/display: Only keep PSR enabled if there is active planesJosé Roberto de Souza
PSR always had a requirement to only be enabled if there is active planes but not following that never caused any issues. But that changes in Alderlake-P, leaving PSR enabled without active planes causes transcoder/port underruns. Similar behavior was fixed during the pipe disable sequence by commit 84030adb9e27 ("drm/i915/display: Disable audio, DRRS and PSR before planes"). intel_dp_compute_psr_vsc_sdp() had to move from intel_psr_enable_locked() to intel_psr_compute_config() because we need to be able to disable/enable PSR from atomic states without connector and encoder state. Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210922215242.66683-3-jose.souza@intel.com
2021-09-20drm/i915/dp: add helper for checking for UHBR link rateJani Nikula
Helpful abstraction to avoid duplication. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fe9a222ad900da797c989de9f7fa13928d2c9861.1631191763.git.jani.nikula@intel.com
2021-08-30drm/i915/display: Move DRRS code its own fileJosé Roberto de Souza
intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce some lines from it. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210827174253.51122-2-jose.souza@intel.com
2021-08-24drm/i915/dp: add max data rate calculation for UHBR ratesJani Nikula
DP 2.0 UHBR link rates always use 128b/132b channel encoding, which has a different data bandwidth efficiency from 8b/10b. The computation is slightly convoluted due to the units we use; this is all explained in the added comment. v2: Clarified comment (Manasi) Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8afd8d97a04c2d86c2dcadfed9f8e1f84272a13c.1629735412.git.jani.nikula@intel.com
2021-08-24drm/i915/dp: use actual link rate values in struct link_config_limitsJani Nikula
The MST code uses actual link rates in the limits struct, while the DP code in general uses indexes to the ->common_rates[] array. Fix the confusion by using actual link rate values everywhere. This is a better abstraction than some obscure index. Rename the struct members while at it to ensure all the places are covered. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d70ab7261abacd367d3a6a47102575eb88a55cd4.1629735412.git.jani.nikula@intel.com
2021-04-28drm/i915/hdcp: add intel_dp_hdcp.h and rename init accordinglyJani Nikula
Add separate intel_dp_hdcp.h to go with intel_dp_hdcp.c, and rename the init function intel_dp_hdcp_init() to follow naming where function prefix matches the file name. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210427114520.4740-1-jani.nikula@intel.com
generated by cgit (git 2.34.1) at 2025-04-25 16:01:38 +0000