Enable basic 128b/132b SST functionality without compression. Reuse
intel_dp_mtp_tu_compute_config() to figure out the TU after we've
determined we need to use an UHBR rate.
It's slightly complicated as the M/N computation is done in different
places in MST and SST paths, so we need to avoid trashing the values
later for UHBR.
If uncompressed UHBR fails, we drop to compressed non-UHBR, which is
quite likely to fail as well. We still lack 128b/132b SST+DSC.
We need mst_master_transcoder also for 128b/132b SST. Use cpu_transcoder
directly. Enhanced framing is "don't care" for 128b/132b link.
v2: mst_master_transcoder, enhanced framing (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/084e4e05bf25a5dd396dd391014943d42b11c88d.1735912293.git.jani.nikula@intel.com
Currently, when bandwidth is insufficient for a given mode, we attempt
to use DSC. This is indicated by a debug print, followed by a check for
DSC support.
The debug message states that we are trying DSC, but DSC might not be
supported, which can give an incorrect picture in the logs if we bail
out later.
Correct the order for both DP and DP MST to:
- Check if DSC is required and supported, and return early if DSC is
not supported.
- Print a debug message to indicate that DSC will be tried next.
Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250103031424.1732774-1-ankit.k.nautiyal@intel.com
The helper intel_dp_compute_config_link_bpp_limits is the correct place
to set the DSC link limits. Move the code to this function and remove
the #TODO item.
v2: Add argument intel_connector to the helper to get correct connector
for DP MST. (Imre)
v3: Remove redundant calls to intel_dp_dsc_sink_max_compressed_bpp as
its already accounted while setting link bpp limits.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217093244.3938132-14-ankit.k.nautiyal@intel.com
Currently to get the max pipe_bpp with dsc we take the min of
limits->pipe.max_bpp and dsc max bpp (dsc max bpc * 3). This can result
in problems when limits->pipe.max_bpp is less than the computed dsc min bpp
(dsc min bpc * 3).
Replace the min/max functions with clamp while computing
limits->pipe.max/min_bpp to ensure that the pipe_bpp limits are constrained
within the DSC-defined minimum and maximum values.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217093244.3938132-12-ankit.k.nautiyal@intel.com
Currently we are including both max_requested_bpc and
limits->pipe.bpp_max while computing maximum possible pipe bpp with dsc.
However, while setting limits->pipe.max_bpp, the max_requested_bpc is
already taken into account.
Drop the redundant check for max_requested_bpc and use only
limits->pipe.bpp_max. This will also result in dropping conn_state
argument in functions where it was used only to get max_requested_bpc.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217093244.3938132-9-ankit.k.nautiyal@intel.com
Forward Error Correction is required for DP if we are using DSC but
is optional for eDP.
Currently the helper intel_dp_supports_dsc checks if fec_enable is set for
DP or not. The helper is called after fec_enable is set in crtc_state.
Instead of this a better approach would be to:
first, call intel_dp_supports_dsc to check for DSC support
(along with FEC requirement for DP) and then set fec_enable for DP
(if not already set) in crtc_state.
To achieve this, remove the check for fec_enable in the helper and instead
check for FEC support for DP. With this change the helper
intel_dp_supports_dsc can be called earlier and return early if DSC is
not supported. The structure intel_dp is added to the helper to get the
FEC support for DP.
v2: Pass intel_dp to adjust_limits_for_dsc_hblank_expansion_quirk
instead of deriving it from connector. (Jani)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217093244.3938132-2-ankit.k.nautiyal@intel.com
While forcing DSC when it is not actually required, the max compressed
bpp from the source gets picked for compression for some pipe bpps.
Apparently, when DSC is not required, forcing DSC to the maximum compressed
bpp seems to cause underruns.
To avoid this, limit the max compressed bpp to 18 while forcing DSC. This
value works across platforms with different pipe bpps and prevents
underruns.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Naga Venkata Srikanth V <nagavenkata.srikanth.v@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241030084100.1361689-1-ankit.k.nautiyal@intel.com
Certain resolutions require 12 DSC slices support along with ultrajoiner.
For such cases, the third DSC Engine per Pipe is enabled. Each DSC
Engine processes 1 Slice, resulting in a total of 12 VDSC slices
(4 Pipes * 3 DSC Instances per Pipe).
Add support for 12 DSC slices and 3 DSC engines for such modes.
v2: Add missing check for 3 slices support only with 4 joined pipes.
(Suraj)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-8-ankit.k.nautiyal@intel.com
According to the DSC spec, the slice width should be chosen such that
the picture width (hactive) is evenly divisible by the slice width.
If not, extra pixels (padding) must be added to the last slice to
ensure all slices have the same width.
Currently, we do not support handling these extra pixels.
Therefore, select a slice count that evenly divides the hactive
(slice_width = hactive / slice_count).
This check is already implemented for DSI, where the slice count is
selected from the BIOS.
For DP, currently with 1, 2, 4 slices per pipe it is unlikely to have
slice count not being able to divide hactive, but with 3 DSC engines
and 3 slices, we can have such cases. Adding this check prepares for
future scenarios where such configurations might be used.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-7-ankit.k.nautiyal@intel.com
At the moment dsc_split represents whether the dsc splitter is used
or not. With 3 DSC engines, the splitter can split into two streams
or three streams.
Instead of representing the splitter's state, it is more effective to
represent the number of DSC streams per pipe.
Replace the `dsc.dsc_split` member with `dsc.num_streams` to indicate the
number of DSC streams used per pipe. This change will implicitly
convey the splitter's operation mode.
v2: Avoid new enum for dsc split. (Suraj)
v3:
-Replace dsc_split with num_stream. (Suraj)
-Avoid extra parentheses. (Jani)
v4: Set num_streams to 1, if VDSC_JOINER not set while readout.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-3-ankit.k.nautiyal@intel.com
For some platforms, the maximum slices per DSC engine is 4, while for
others it is 2. Update the comment to reflect this and clarify that
the 'valid_dsc_slicecount' list represents the valid number of slices
per pipe.
Currently, we are working with 1, and 2 slices per DSC engine,
which works for all platforms. With this the number of slices per pipe
can be 1,2 or 4 with different slice & DSC engine configuration.
Add a #TODO for adding support for 4 slices per DSC engine where
supported.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241030041036.1238006-2-ankit.k.nautiyal@intel.com
We are currently seeing unexpected link trainings with several different
eDP panels. These are caused by these panels stating bad link status in
their dpcd registers. This can be observed by doing following test:
1. Boot up without Xe module loaded
2. Load Xe module with PSR disabled:
$ modprobe xe enable_psr=0
3. Read panel link status register
$ dpcd_reg read --offset 0x200e --count=1
0x200e: 00
4. Enable PSR, sleep for 2 seconds and disable PSR again:
$ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
$ echo "-1" > /sys/kernel/debug/dri/0000:00:02.0/xe_params/enable_psr
$ echo 0x0 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
$ sleep 2
$ cat /sys/kernel/debug/dri/0/i915_edp_psr_status | grep status
$ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
Source PSR/PanelReplay status: DEEP_SLEEP [0x80310030]
5. Now read panel link status registers again:
$ dpcd_reg read --offset 0x200e --count=1
0x200e: 80
Workaround this by not trusting link status registers after PSR is enabled
until first short pulse interrupt is received.
v2:
- clear link_ok flag on pipe disable
- remove useless comment
- modify intel_dp_needs_link_retrain return statement
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241029122415.1789528-1-jouni.hogander@intel.com
While updating the source OUI on the sink the driver should avoid
writing the OUI if it's already up-to-date to prevent the sink from
resetting itself in response to the update. On eDP - the only output
type where the OUI was updated so far - the driver ensured this by
comparing the current source OUI DPCD register values with the expected
Intel OUI value, skipping the update in case of a match. On some non-eDP
sinks - at least on Synaptics branch devices - this method doesn't work,
since the source OUI DPCD registers read back as all 0, even after
updating the registers.
Handle the above kind of sinks by tracking when the OUI was updated and
so should be valid, regardless of what the DPCD registers contain.
eDP sinks reset the written source OUI value when the panel power is
disabled, invalidate the OUI state accordingly.
This is required by a follow-up patch updating the source OUI for
non-eDP sink types as well.
v2: Fix setting intel_dp::oui_valid=true, if the DPCD register contains
already the expected value.
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-5-imre.deak@intel.com
If the source OUI DPCD register value matches the expected Intel OUI
value, the write timestamp doesn't get updated leaving it at the 0
initial value if the OUI wasn't written before. This can lead to an
incorrect wait duration in intel_dp_wait_source_oui(), since jiffies is
not inited to 0 in general (on a 32 bit system INITIAL_JIFFIES is set to
5 minutes ahead of wrap-around). Fix this by intializing the write
timestamp in the above case as well.
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-4-imre.deak@intel.com
The sink's capabilities, like the DSC caps, depend on the source OUI
written to the sink's DPCD registers and so this OUI value should be
valid for the whole duration of the detection. An eDP sink will reset
this OUI value when the panel power is disabled, so prevent the
disabling - happening by default after a 1 sec idle period - for the
whole duration of detection.
v2: Update the documentation for intel_pps_on(). (Jani)
Cc: Jani Nikula <jani.nikula@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/20241025160259.3088727-3-imre.deak@intel.com
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
Use x100, or ver * 100 + rel, versions for full IP version checks,
similar to what xe driver does:
- Replace IP_VER(14, 1) inline with 1401, etc.
- Convert DISPLAY_VER_FULL() to DISPLAY_VERx100()
- Convert IS_DISPLAY_VER_FULL() to IS_DISPLAY_VERx100()
- Convert IS_DISPLAY_VER_STEP() to IS_DISPLAY_VERx100_STEP()
This makes ver.rel versions easier to use, follows the xe driver
pattern, and drops the dependency on the IP_VER() macro.
v2: Rebase, drop IP_VER() from xe compat headers
v3: Rebase
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241029155536.753413-1-jani.nikula@intel.com
