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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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: d51f25eb47 ("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
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 e4dd27aadd
("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
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: b2608c6b32 ("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
Compute the BW required through a DP tunnel on links with such tunnels
detected and add the corresponding atomic state during a modeset.
v2:
- Fix error check of intel_dp_tunnel_compute_stream_bw(). (Ville)
- Move intel_dp_tunnel_atomic_cleanup_inherited_state() to this patch.
(Ville)
- Move intel_dp_tunnel_atomic_clear_stream_bw() to this patch.
Reviewed-by: Uma Shankar <uma.shankar@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/20240220211841.448846-16-imre.deak@intel.com
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
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
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
Prevent accessing the HW from the get_modes hooks of connectors deriving
the mode list from the display's EDID. drm_edid_connector_add_modes()
will return the mode list based on the EDID which was cached during a
previous detection/get_modes call.
This also fixes the NULL deref problem (10085) which was
introduced/revealed by
commit bab87ef4db ("drm/i915: Disable hotplug detection handlers during driver init/shutdown")
After the above change MST connectors will not change state during
driver init/shutdown; thus some of these connectors with no I2C/DDC
adapter registered for them (since the given MST port has no sink
connected) may stay then in the 'unknown' connector status. The
get_modes() hook should not try to use the I2C/DDC adapter in this state
(which would lead to the above NULL deref) which this patch ensures.
v2:
- Remove the redundant check from intel_crt_ddc_get_modes().
- Rebase on latest drm-tip.
- Add Fixes: line / related commit notes.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10085
Fixes: bab87ef4db ("drm/i915: Disable hotplug detection handlers during driver init/shutdown")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240212175237.2625812-2-imre.deak@intel.com
As described in the previous two patches an unexpected connector
detection can happen during the init/shutdown sequences. Prevent these
by returning the connector's current status from the detection handlers.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-10-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Use the >= and < operators for the DISPLAY_VER checks everywhere.
This is what most of the code does, but especially recently random
pieces of code have started doing this differently for no good reason.
Conversion done with the following cocci:
@find@
expression i915;
constant ver;
@@
(
DISPLAY_VER(i915) <= ver
|
DISPLAY_VER(i915) > ver
)
@script:python inc@
old_ver << find.ver;
new_ver;
@@
coccinelle.new_ver = str(int(old_ver) + 1)
@@
expression find.i915;
constant find.ver;
identifier inc.new_ver;
@@
(
- DISPLAY_VER(i915) <= ver
+ DISPLAY_VER(i915) < new_ver
|
- DISPLAY_VER(i915) > ver
+ DISPLAY_VER(i915) >= new_ver
)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231127145028.4899-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We have no bigjoiner support in the MST code, so .mode_valid()
pretending otherwise is just going to result black screens for
users. Reject any mode that needs the joiner.
Cc: stable@vger.kernel.org
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: d51f25eb47 ("drm/i915: Add DSC support to MST path")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231127145028.4899-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Apparently some BXT/GLK systems have DSI panels whose timings
don't agree with the normal cpu transcoder hblank>=32 limitation.
This is perhaps fine as there are no specific hblank/etc. limits
listed for the BXT/GLK DSI transcoders.
Move those checks out from the global intel_mode_valid() into
into connector specific .mode_valid() hooks, skipping BXT/GLK
DSI connectors. We'll leave the basic [hv]display/[hv]total
checks in intel_mode_valid() as those seem like sensible upper
limits regardless of the transcoder used.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720
Fixes: 8f4b1068e7 ("drm/i915: Check some transcoder timing minimum limits")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231127145028.4899-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Imre Deak
Jani Nikula
Ville Syrjälä
Stanislav Lisovskiy
Wayne Lin
Vidya Srinivas