aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/display/intel_dp_mst.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-01-07drm/connector: make mode_valid_ctx take a const struct drm_display_modeDmitry Baryshkov1-3/+3
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge take a const struct drm_display_mode argument. Change the mode_valid_ctx callback of drm_connector to also take a const argument. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241214-drm-connector-mode-valid-const-v2-4-4f9498a4c822@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-17drm/i915/dp_mst: Expose a connector to kernel users after it's properly ↵Imre Deak1-8/+9
initialized After a connector is added to the drm_mode_config::connector_list, it's visible to any in-kernel users looking up connectors via the above list. Make sure that the connector is properly initialized before such look-ups, by initializing the connector with drm_connector_dynamic_init() - which doesn't add the connector to the list - and registering it with drm_connector_dynamic_register() - which adds the connector to the list - after the initialization is complete. v2: - Rebase on the change which moves adding the connector to the connector list only later when calling drm_connector_dynamic_register(). v3: - Rebase on drm-misc-next, due to a trivial conflict with commit 5503f8112e52 ("drm/i915/mst: unify MST topology callback naming ..."), which is only in drm-intel-next. - Fix s/drm_connector_dynamic_register()/drm_connector_dynamic_init() typo in the commit log. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241211230328.4012496-6-imre.deak@intel.com
2024-10-31drm/i915/dp: Flush modeset commits during connector detectionImre Deak1-0/+2
Make sure that a DP connector detection doesn't happen in parallel with an ongoing modeset on the connector. The reasons for this are: - Besides reading the capabilities, EDID etc. the detection may change the state of the sink (via the AUX bus), for instance by setting the LTTPR mode or the source OUI (the latter introduced by an upcoming patch). It's better to avoid such changes affecting an onging modeset in any way. - During a modeset's link training any access to DPCD registers, besides the registers used for link training should be avoided, at least in the LTTPR non-transparent and transparent link training modes. Such asynchronous accesses - besides connector detection - can also happen via the AUX device node for instance, for those a parallel modeset will have to be avoided in a similar way to the change in this patch. (A topic for a follow-up change.) - The source OUI written to an eDP sink is valid only while the panel power is enabled. A modeset on eDP will enable/disable the panel power synchronously; this should be prevented in the middle of the connector detection, to ensure a consistent sink state (which depends on the source OUI) for the whole duration of detection. The panel power could still get disabled during detection after an idle period (1 sec), this will be prevented by the next patch. v2: (Ville) - s/wait_for_crtc_hw_done/wait_for_connector_hw_done - Get drm_device using an intel_display instead of drm_i915_private ptr. 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/20241025160259.3088727-2-imre.deak@intel.com
2024-10-14drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible modeImre Deak1-0/+3
If an MST branch device doesn't support DSC for a given mode, but the MST link has enough BW for the mode, assume that the branch device does support the mode using an uncompressed stream. Fixes: 55eaef164174 ("drm/i915/dp_mst: Handle the Synaptics HBlank expansion quirk") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009110135.1216498-2-imre.deak@intel.com
2024-10-14drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculationImre Deak1-12/+27
The MST branch device may not support the number of DSC slices a mode requires, handle the error in this case. Fixes: 4e0837a8d00a ("drm/i915/dp_mst: Account for FEC and DSC overhead during BW allocation") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009110135.1216498-1-imre.deak@intel.com
2024-09-30drm/i915/dp: Add helper to compute num pipes requiredAnkit Nautiyal1-14/+9
Add a helper to compute the number of pipes required. This will depend on whether the joiner is required or is forced through the debugfs. If no joiner is required the helper returns 1. v2: -Return 1 if no joiner is required. (Ville) -Change the suffix from joined_pipes to num_pipes. (Ville) -Use number of pipes while calculating joined_pipe masks and max_dotclk. (Ville) v3: Simplify and rename the helper to intel_dp_num_joined_pipes(). Ville v4: Remove redundant 'fallthrough' statement. (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/20240926134322.3728021-5-ankit.k.nautiyal@intel.com
2024-09-23drm/i915/dp: clean up intel_dp_test.[ch] interfaceJani Nikula1-1/+1
Conform to uniform function naming. Use intel_dp. Hide checks on intel_dp->compliance within intel_dp_test.[ch]. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2905006d2d47040032153ca69052898529a95d5.1726833193.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-23drm/i915/dp: split out intel_dp_test.[ch] to a dedicated fileJani Nikula1-1/+2
intel_dp.c has become huge, over 7k lines. Split out the fairly well isolated chunk of DP test code to a dedicated file intel_dp_test.[ch]. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/262d565fe59715ba297702b67d4bcca81c736dc0.1726833193.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-19drm/i915/display: Enhance iterators for modeset en/disableAnkit Nautiyal1-7/+7
Joiners have specific enabling and disabling order dependent on primary and secondary pipes. This becomes more complex with ultrajoiner where we have ultrajoiner primary/secondary pipes in addition to bigjoiner primary/secondary pipes. To unify the approach that works for present and future joiner cases, use primary and secondary pipe masks to iterate over pipes. If joiner is used, derive bigoiner primary and secondary pipe masks and use following sequences: Disabling : disable primary pipes followed by secondary pipes, Enabling: enable secondary pipes followed by primary pipes. This works well with ultrajoiner too, as ultrajoiner has 2 bigjoiner primary/secondary pairs (AC, BD). For non joiner case, enable/disable based on usual pipe order A-D, D-A respectively. v2: -Simplify the iterator macro. (Ville) -Use struct intel_display. (Ville) -Add prefix _intel to the helper name. (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918063016.2667721-3-ankit.k.nautiyal@intel.com
2024-09-18drm/i915/display: Use joined pipes in dsc helpers for slices, bppAnkit Nautiyal1-3/+5
In preparation of ultrajoiner, use number of joined pipes in the dsc helpers to compute dsc slices and max compressed bpp, instead of using the joiner flag. v2: Adjust the formulae to use num of pipes as 1 (no joiner) or 2 (bigjoiner). (Ankit) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240916102836.2149012-5-ankit.k.nautiyal@intel.com
2024-09-18drm/i915/display: Use joined pipes in intel_mode_valid_max_plane_sizeAnkit Nautiyal1-1/+1
In preparation of ultrajoiner, use number of pipes in the intel_mode_valid_max_plane_size helper, instead of joiner flag. v2: Use num_joined_pipes 1 where there are no joined pipes (Ville) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240916102836.2149012-4-ankit.k.nautiyal@intel.com
2024-09-18drm/i915/display: Use joined pipes in intel_dp_joiner_needs_dscAnkit Nautiyal1-2/+8
In preparation of ultrajoiner, use number of joined pipes in the intel_dp_joiner_needs_dsc helper, instead of joiner flag. v2: Use intel_crtc_num_joined_pipes. (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/20240916102836.2149012-3-ankit.k.nautiyal@intel.com
2024-08-26drm/i915/dp_mst: Fix MST state after a sink resetImre Deak1-0/+40
In some cases the sink can reset itself after it was configured into MST mode, without the driver noticing the disconnected state. For instance the reset may happen in the middle of a modeset, or the (long) HPD pulse generated may be not long enough for the encoder detect handler to observe the HPD's deasserted state. In this case the sink's DPCD register programmed to enable MST will be reset, while the driver still assumes MST is still enabled. Detect this condition, which will tear down and recreate/re-enable the MST topology. v2: - Add a code comment about adjusting the expected DP_MSTM_CTRL register value for SST + SideBand. (Suraj, Jani) - Print a debug message about detecting the link reset. (Jani) - Verify the DPCD MST state only if it wasn't already determined that the sink is disconnected. Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11195 Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> (v1) Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240823162918.1211875-1-imre.deak@intel.com
2024-08-06drm/i915: Replace BPP_X16_FMT()/ARGS() with FXP_Q4_FMT()/ARGS()Imre Deak1-2/+2
Replace the BPP_X16_FMT()/ARGS() helpers defined by the driver with the equivalent FXP_Q4_FMT()/ARGS() helpers defined by DRM core. v2: Rebase on the s/DRM_X16/FXP_Q4 change. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240805150802.3568970-6-imre.deak@intel.com
2024-08-06drm/i915: Replace to_bpp_int_roundup() with fxp_q4_to_int_roundup()Imre Deak1-1/+1
Replace the to_bpp_int_roundup() helper defined by the driver with the equivalent fxp_q4_to_int_roundup() helper defined by DRM core. v2: Rebase on s/drm_x16/fxp_q4 change. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240805150802.3568970-4-imre.deak@intel.com
2024-08-06drm/i915: Replace to_bpp_int() with fxp_q4_to_int()Imre Deak1-3/+3
Replace the to_bpp_int() helper defined by the driver with the equivalent fxp_q4_to_int() helper defined by DRM core. v2: Rebase on the s/drm_x16/fxp_q4 change. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240805150802.3568970-3-imre.deak@intel.com
2024-08-06drm/i915: Replace to_bpp_x16() with fxp_q4_from_int()Imre Deak1-7/+7
Replace the to_bpp_x16() helper defined by the driver with the equivalent fxp_q4_from_int() helper defined by DRM core. v2: Rebase on the s/drm_x16/fxp_q4 change. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240805150802.3568970-2-imre.deak@intel.com
2024-07-31drm/i915/dp_mst: Ensure link parameters are up-to-date for a disabled linkImre Deak1-0/+31
As explained in the previous patch, the MST link BW reported by branch devices during topology probing/path resources enumeration depends on the link parameters programmed to DPCD to be up-to-date. After a sink is plugged this is not ensured, as those DPCD values start out zeroed. The target link parameters (for a subsequent modeset) are the maximum that is supported, so make sure these maximum values are programmed before the topology probing. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-14-imre.deak@intel.com
2024-07-31drm/i915/dp_mst: Reprobe the MST topology after a link parameter changeImre Deak1-1/+31
The MST link BW reported by branch devices via the ENUM_PATH_RESOURCES message depends on the channel coding and link rate/lane count parameters programmed to DPCD. This is the case at least for some branch devices, while for others the reported BW is independent of the link parameters. In any case the DP standard requires the branch device to adjust the returned value to both account for the different way the BW for FEC is accounted for (included in the returned value for non-UHBR and not included for UHBR rates) and to limit the returned value to the (trained) link BW between the source and first downstream branch device, see DP v2.0/v2.1 Figure 2-94, DP v2.1 5.9.7. Presumedly this is also the reason why the standard requires the DPCD link rate/lane count values being up-to-date before sending the ENUM_PATH_RESOURCES message, see DP v2.1 2.14.9.4. Based on the above reprobe the MST topology after the link is retrained with new link parameters to make sure that the MST link BW tracked in the MST topology state (via each topology port's full_pbn value) is up-to-date. The next patch will make sure that the MST link BW is also kept up-to-date if the link is disabled. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-13-imre.deak@intel.com
2024-07-31drm/i915/dp_mst: Queue modeset-retry after a failed payload BW allocationImre Deak1-4/+7
If the MST payload allocation failed, enabling the output also failed most probably, so send a uevent accordinly requesting the user to retry the modeset. While at it remove the driver specific debug message, there is already one printed by drm_dp_add_payload_part1(). Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-12-imre.deak@intel.com
2024-06-19Merge drm/drm-next into drm-intel-nextJani Nikula1-1/+1
Sync to v6.10-rc3. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-06-14drm/i915: Reuse intel_dp_supports_dsc() for MSTVille Syrjälä1-14/+2
intel_dp_supports_dsc() now works for MST as well, reuse it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240517145356.26103-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-06-14drm/i915: Handle MST in intel_dp_has_dsc()Ville Syrjälä1-2/+1
Utilize intel_dp_has_dsc() for MST as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240517145356.26103-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-06-13drm/i915/dp_mst: Reset intel_dp->link_trained during disablingImre Deak1-0/+3
Reset the flag indicating an active link after disabling an MST link, similarly to how this is done for SST outputs. This avoids trying to retrain an MST link while its disabled. 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/20240610164933.2947366-16-imre.deak@intel.com
2024-06-13drm/i915/dp_mst: Align TUs to avoid splitting symbols across MTPsImre Deak1-4/+23
Symbols consisting of multiple (4) TU timeslots may get split across MTPs when using 2 or 1 link lanes. Avoid this, as required by Bspec by aligning the allocated TUs to 2 when using 2 lanes and 4 when using 1 lane. Atm, we also have to align the PBNs used to allocate BW along the MST path, since DRM core keeps track of its own TU value, derived from the PBN and that TU value must match what the driver calculates. On some platforms the alignment is only required on 8b/10b links, a follow-up patch will remove the limitation for those. Bspec: 49266, 68922 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/20240610164933.2947366-2-imre.deak@intel.com
2024-06-13drm/i915/dp_mst: Fix DSC input BPP computationImre Deak1-0/+2
The branch or sink device decompressing a stream may have a limitation on the input/uncompressed BPP, which is lower than the base line BPP (determined by the sink's EDID). In some cases a stream with an input BPP higher than this limit will be converted automatically by the device decompressing the stream, by truncating the BPP, however in some cases - seen at least in Dell dock's DP->HDMI converters - the decompression will fail. Fix the above by limiting the input BPP correctly. This is done already correctly for SST outputs. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240611153351.3013235-1-imre.deak@intel.com
2024-06-12drm/i915: Rename all bigjoiner to joinerStanislav Lisovskiy1-14/+14
Lets unify both bigjoiner and ultrajoiner under simple "joiner" name, because in future we might have multiple configurations, involving multiple bigjoiners, ultrajoiner, however it is possible to use same api for handling both. v2: - Renamed back some bigjoiner specific parts for now(Ville) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> [vsyrjala: Catch a few more cases] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240607075457.15700-1-stanislav.lisovskiy@intel.com
2024-06-07drm/i915: pass dev_priv explicitly to TRANS_DDI_FUNC_CTLJani Nikula1-2/+3
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the TRANS_DDI_FUNC_CTL register macro. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4ccf75561aa0fb209fd71c85e9089b0350570fd6.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-05-21drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2Wayne Lin1-1/+1
[Why] Commit: - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement") accidently overwrite the commit - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2") which cause regression. [How] Recover the original NULL fix and remove the unnecessary input parameter 'state' for drm_dp_add_payload_part2(). Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement") Reported-by: Leon Weiß <leon.weiss@ruhr-uni-bochum.de> Link: https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.camel@ruhr-uni-bochum.de/ Cc: lyude@redhat.com Cc: imre.deak@intel.com Cc: stable@vger.kernel.org Cc: regressions@lists.linux.dev Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240307062957.2323620-1-Wayne.Lin@amd.com (cherry picked from commit 4545614c1d8da603e57b60dd66224d81b6ffc305)
2024-04-19drm/i915/dpio: s/ddi/dpio/ for bxt/glk PHY stuffVille Syrjälä1-1/+1
Since all of this lives in intel_dpio_phy.c let's rename the bxt/glk functions to have bxt_dpio_phy_ namespace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412175818.29217-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-04-19drm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR ratesImre Deak1-4/+18
Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA monitor results in a blank screen, at least on MTL platforms on UHBR link rates with some (<30) uncompressed bpp values. Enabling compression fixes the problem, so do that for now. Windows enables DSC always if the sink supports it and forcing it to enable the mode without compression leads to the same problem above (which suggests a panel issue with uncompressed mode). The same 5k mode on non-UHBR link rates is not affected and lower resolution modes are not affected either. The problem is similar to the one fixed by the HBLANK expansion quirk on Synaptics hubs, with the difference that the problematic mode has a longer HBLANK duration. Also the monitor doesn't report supporting HBLANK expansion; either its internal MST hub does the expansion internally - similarly to the Synaptics hub - or the issue has another root cause, but still related to the mode's short HBLANK duration. Enable the quirk for the monitor adjusting the detection for the above differences. v2: Rebase on drm_dp_128132b_supported() change. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417142217.457902-1-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Make HBLANK expansion quirk work for logical portsImre Deak1-6/+16
The DPCD OUI of the logical port on a Dell UHBR monitor - on which the AUX device is used to enable DSC - is all 0. To detect if the HBLANK expansion quirk is required for this monitor use the OUI of the port's parent instead. Since in the above case the DPCD of both the logical port and the parent port reports being a sink device (vs. branch device) type, read the proper sink/branch OUI based on the DPCD device type. This is required by a follow-up patch enabling the quirk for the above Dell monitor. 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/20240416221010.376865-11-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Sanitize calculating the DSC DPT bpp limitImre Deak1-39/+39
Instead of checking each compressed bpp value against the maximum DSC/DPT bpp, simplify things by calculating the maximum bpp upfront and limiting the range of bpps looped over using this maximum. While at it add a comment about the origin of the DSC/DPT bpp limit. Bspec: 49259, 68912 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/20240416221010.376865-7-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Account with the DSC DPT bpp limit on MTLImre Deak1-1/+1
The DPT/DSC bpp limit should be accounted for on MTL platforms as well, do so. Bspec: 49259 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/20240416221010.376865-6-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Account for channel coding efficiency in the DSC DPT bpp limitImre Deak1-2/+21
The DSC DPT interface BW limit check should take into account the link clock's (aka DDI clock in bspec) channel coding efficiency overhead. Bspec suggests that the FEC overhead needs to be applied, however HW people claim this isn't the case, nor is any overhead applicable. However based on testing various 5k/6k modes both on the DELL U3224KBA monitor and the Unigraf UCD-500 CTS test device, both the channel coding efficiency (which includes the FEC overhead) and an additional 3% overhead must be accounted for to get these modes working. Bspec: 49259 v2: - Apply an additional 3% overhead, add a commit log and code comment about these overheads and the relation to the Bspec BW limit formula. 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/20240416221010.376865-5-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Fix BW limit check when calculating DSC DPT bppImre Deak1-1/+1
The DSC DPT bpp limit check should only fail if the available DPT BW is less than the required BW, fix the check accordingly. 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/20240416221010.376865-4-imre.deak@intel.com
2024-04-19drm/i915/dp_mst: Fix symbol clock when calculating the DSC DPT bpp limitImre Deak1-2/+1
The expected link symbol clock unit when calculating the DSC DPT bpp limit is kSymbols/sec, aligning with the dotclock's kPixels/sec unit based on the crtc clock. As opposed to this port_clock is used - which has a 10 kbits/sec unit - with the resulting symbol clock in 10 kSymbols/sec units (disregarding the rounding error for the 13.5Gbps rate). Fix the calculation using the expected 10x factor. 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/20240416221010.376865-3-imre.deak@intel.com
2024-04-12drm/i915: Allow bigjoiner for MSTVidya Srinivas1-13/+15
We need bigjoiner support with MST functionality for MST monitor resolutions > 5K to work. Adding support for the same. v2: Addressed review comments from Jani. Revert rejection of MST bigjoiner modes and add functionality v3: Fixed pipe_mismatch WARN for mst_master_transcoder Credits-to: Manasi Navare <navaremanasi@chromium.org> v4: Utilize intel_crtc_joined_pipe_mask() also for handling bigjoiner slave pipes for MST case(Stan) [v5: vsyrjala: chunked the modeset squence stuff out, removed bogus mst master transcoder hack, keep mgr_lock near the full_pbn check] [v6: vsyrjala: Calculate DSC slices correctly for bigjoiner (Imre)] Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Co-developed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-7-ville.syrjala@linux.intel.com
2024-04-12drm/i915/mst: Add bigjoiner handling to MST modeset sequenceVille Syrjälä1-7/+27
Loop over all joined pipes at relevant points in the MST modeset sequence. Carved out from Vidya's earlier big patch, with naming/etc. changed to match the earlier hsw_crtc_enable() stuff. Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Co-developed-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409163502.29633-6-ville.syrjala@linux.intel.com
2024-04-10drm/i915/adlp: Add DP MST DPT/DPTP alignment WA (Wa_14014143976)Imre Deak1-0/+3
Add a workaround to fix BS-BS jitter issues on MST links, aligning DPT/DPTP MTPs. Bspec: 50050, 55424 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/20240129175533.904590-4-imre.deak@intel.com
2024-04-10drm/i915/adlp: Add MST short HBlank WA (Wa_14014143976)Imre Deak1-0/+8
Add a workaround to fix BS jitter issues on MST links if the HBLANK period is less than 1 MTP. The WA applies only to UHBR rates while on non-UHBR the specification requires disabling it explicitly - presumedly because the register's reset value has the WA enabled. Bspec: 50050, 55424 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/20240129175533.904590-3-imre.deak@intel.com
2024-04-10drm/i915/adlp: Add MST FEC BS jitter WA (Wa_14013163432)Imre Deak1-0/+24
Add a workaround to fix BS (blank start) to BS jitter issues on MST links when FEC is enabled. Neither Bspec requires this nor Windows clears the WA when disabling the output - presumedly because CHICKEN_MISC_3 gets reset after disabling the pipe/transcoder - so follow suit. Bspec: 50050, 55424 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/20240129175533.904590-2-imre.deak@intel.com
2024-04-09drm/i915: Pass connector to intel_dp_need_bigjoiner()Ville Syrjälä1-2/+3
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/mst: Check intel_dp_joiner_needs_dsc()Ville Syrjälä1-4/+6
intel_dp_mst_compute_config() is missing the "does the joiner need DSC?" check despite claiming to have a lot of other joiner/dsc stuff in there (albeit disabled). Replicate the logic from the SST side. TODO: refactor all this duplicated code! 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-10-ville.syrjala@linux.intel.com
2024-04-09drm/i915: Extract intel_dp_joiner_needs_dsc()Ville Syrjälä1-5/+1
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: move max_dotclk_freq to display substructJani Nikula1-1/+1
The info is related to display, and should be placed under i915->display. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ea012aa72c93f3d436ccacf8f75683757d144b82.1712599670.git.jani.nikula@intel.com
2024-04-03drm/i915/mst: Limit MST+DSC to TGL+Ville Syrjälä1-1/+1
The MST code currently assumes that glk+ already supports MST+DSC, which is incorrect. We need to check for TGL+ actually. ICL does support SST+DSC, but supposedly it can't do MST+FEC which will also rule out MST+DSC. Note that a straight TGL+ check doesn't work here because DSC support can get fused out, so we do need to also check 'has_dsc'. Cc: stable@vger.kernel.org Fixes: d51f25eb479a ("drm/i915: Add DSC support to MST path") 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/20240402135148.23011-6-ville.syrjala@linux.intel.com
2024-04-03drm/i915: Shuffle DP .mode_valid() checksVille Syrjälä1-11/+10
Move some of the more trivial checks in the DP .mode_valid() hooks upwards to lessen the noise amongst the more complex checks. 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/20240402135148.23011-3-ville.syrjala@linux.intel.com
2024-04-03drm/i915: Remove DRM_MODE_FLAG_DBLSCAN checks from .mode_valid() hooksVille Syrjälä1-5/+0
We never set connector->doublescan_allowed, so the probe helper already filters out all doublescan modes for us. Sadly we still need to keep the explicit doublescan checks in .compute_config as outlined in commit e4dd27aadd20 ("drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI") 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/20240402135148.23011-2-ville.syrjala@linux.intel.com
2024-03-05drm/i915/dp: Fix connector DSC HW state readoutImre Deak1-0/+1
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
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-13 20:38:21 +0000