Enable using a fractional (compressed) link bpp on MST links, if this is
supported and the link bpp is forced. Fractional link bpps will be
enabled by default as a follow-up change after testing this
functionality within a set of commonly used MST monitors and docks/hubs
which support it.
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-13-imre.deak@intel.com
Add support for forcing the link bpp on a connector via a connector
debugfs entry. During reducing link bpps due to a link BW limit, keep
bpps close to their forced value.
Add the debugfs entry to all relevant connectors: all DP connectors and
on an FDI link CRT/SDVO/LVDS/HDMI connectors.
v2:
- Move adding the debugfs entries to this patch.
- Rename i915_force_link_bpp to intel_force_link_bpp. (Jani)
- Select the relevant connectors via platform checks. (Jani)
- Use for_each_new_intel_connector_in_state(). (Jani)
- Fix 64 bit division vs. 32 bit build when converting str to q4. (lkp)
- Avoid division and addition overflow when converting str to q4.
v3:
- Add TODO: to make the non-DSC min bpp value connector specific. (Ankit)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-12-imre.deak@intel.com
Add support for a fractional compressed link bpp on an MST link. Leave
the actual enabling of fractional bpps to a follow-up change.
While at it add an assert before the bpp loop, that the min and max bpps
are aligned to the bpp step. This should hold regardless of the non-DSC/DSC
or MST/UHBR-SST modes.
This keeps the mode validation and DSC->DPT BW specific maximum link
bpps as rounded-down integer values still, changing those to a
fractional value is left for later, add here TODO comments for them.
v2:
- Align the min/max bpp value to the bpp step.
- Assert that the min/max bpp values are aligned to the bpp step.
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-9-imre.deak@intel.com
The maximum link bpp - determined by the link BW for instance - can be
fractional, handle this properly during computing the link bpp on SST.
This keeps the pipe joiner specific maximum link bpp as a rounded-down
integer value still, changing that to a fractional value is left for
later.
v2: Align the min/max bpp value to the bpp step.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-8-imre.deak@intel.com
Adjusting the compressed bpp range min/max limits in
intel_dp_dsc_nearest_valid_bpp() is unnecessary:
- The source/sink min/max values are enforced already by the
link_config_limits::min_bpp_x16/max_bpp_x16 values computed early in
intel_dp_compute_config_link_bpp_limits().
- The fixed set of valid bpps are enforced already - for all bpps in the
min .. max range by intel_dp_dsc_valid_compressed_bpp() called from
intel_dp_mtp_tu_compute_config().
The only thing needed is limiting max compressed bpp below the
uncompressed pipe bpp, do that one thing only instead of calling
intel_dp_dsc_nearest_valid_bpp().
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-7-imre.deak@intel.com
Check the BW requirement of a selected compressed bpp against the total
MST link BW early. This didn't cause a problem, since all the BW limits
within the MST topology are checked during the later MST topology BW
check. However it doesn't make sense to defer the total link BW check,
since for resolving a BW limit issue due to this later also (a) requires
selecting a pipe to reduce its bpp, ending up reducing the bpp for
another pipe, which is not ideal (b) requires recomputing the state for
all CRTC/stream's in the topology which may slow down the commit
considerably (especially when using fractional bpps).
Based on the above, check a stream bpp's BW requirement against the MST
link's total BW early.
Ideally drm_dp_atomic_find_time_slots() should check internally the
corresponding PBN/TU slot BW against the total link BW, returning an
error if the check fails, however that change would also affect other
drivers, so leaving this for a follow-up.
v2: Rephrase description of pipe selection/bpp reduction in commit
message. (Ankit)
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-6-imre.deak@intel.com
A follow up change will check a selected bpp's BW requirement in
intel_dp_mtp_tu_compute_config(), however that requires the total link
slot count to be up-to-date. The latter in turn depends on the channel
encoding and hence the link rate used, so it can be set after the
link rate used is selected.
This also allows simplifying mst_stream_update_slots(), do that as well,
moving the function definition before its use.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-5-imre.deak@intel.com
Atm TGL supports only a fixed set of valid DSC compressed bpps
(6,8,10,12,15), but this is not taken into account while looking for a
bpp in the minimum..maximum compressed bpp range.
This happened to work only by chance since atm from the above min..max
range it's always the maximum bpp that is selected, which is one of the
above valid bpps (see mst_stream_dsc_compute_link_config() ->
intel_dp_dsc_nearest_valid_bpp()). Before selecting a bpp however, the
bpp's BW requirement should be checked wrt. to the MST total link BW;
after doing that - in a follow-up change - the validity of any bpp in
the min..max range must be ensured before the bpp is selected, do that
here.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-4-imre.deak@intel.com
Atm, on an MST link in DSC mode
intel_dp_compute_config_link_bpp_limits() calculates the maximum link
bpp limit using the MST root connector's DSC capabilities. That's not
correct in general: the decompression could be performed by a branch
device downstream of the root branch device or the sink itself.
Fix the above by passing to intel_dp_compute_config_link_bpp_limits()
the actual connector being modeset, containing the correct DSC
capabilities.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Fixes: 1c5b72daff ("drm/i915/dp: Set the DSC link limits in intel_dp_compute_config_link_bpp_limits")
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250509180340.554867-2-imre.deak@intel.com
Determining the SST/MST mode during state computation must be done based
on the output type stored in the CRTC state, which in turn is set once
based on the modeset connector's SST vs. MST type and will not change as
long as the connector is using the CRTC. OTOH the MST mode indicated by
the given connector's intel_dp::is_mst flag can change independently of
the above output type, based on what sink is at any moment plugged to
the connector.
Fix the state computation accordingly.
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: f6971d7427 ("drm/i915/mst: adapt intel_dp_mtp_tu_compute_config() for 128b/132b SST")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4607
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250507151953.251846-1-imre.deak@intel.com
Observe that i915->irq_lock is no longer used to protect anything
outside of display. Make it a display thing.
This allows us to remove the ugly #define irq_lock irq.lock hack from xe
compat header.
Note that this is slightly more subtle than it first looks. For i915,
there's no functional change here. The lock is moved. However, for xe,
we'll now have *two* locks, xe->irq.lock and display->irq.lock. These
should protect different things, though. Indeed, nesting in the past
would've lead to a deadlock because they were the same lock.
With the i915 references gone, we can make a handful more files
independent of i915_drv.h.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/6d8d2ce0f34a9c7361a5e2fcf96bb32a34c57e76.1746536745.git.jani.nikula@intel.com
[Jani: Fixed a comment while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The gsc_hdcp_ops is duplicated and initialized exactly the same way in
two different places (for i915 and xe), and requires forward
declarations for all the hooks. Deduplicate, and make the functions
static.
There are slight differences in the i915 and xe implementations of
intel_hdcp_gsc_init() and intel_hdcp_gsc_fini(). Take the best of both,
and improve.
We need to expose intel_hdcp_gsc_hdcp2_init() and
intel_hdcp_gsc_free_message() for this, and create the latter for xe.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/21e7871b35d4c7d13f016b5ecb4f10e5be72c531.1745524803.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We haven't updated the DRIVER_TIMESTAMP since commit 3570bd989a
("drm/i915: Update DRIVER_DATE to 20230929") 1½ years ago. Before then,
the previous update was commit 139caf7ca2 ("drm/i915: Update
DRIVER_DATE to 20201103") 4+ years ago. The DRIVER_DATE has also been
removed altogether.
We've used the DRIVER_TIMESTAMP to log suggestions to file bugs on GPU
hangs when they happen on a driver less than six months old. Combined
with the sporadic DRIVER_TIMESTAMP updates, we really haven't logged the
suggestions for years.
Just stop logging the suggestion to file bugs altogether, and remove
DRIVER_TIMESTAMP. This doesn't really change anything wrt to logging GPU
errors or how we handle bugs. And effectively we already stopped logging
the message a year ago when we stopped updating DRIVER_TIMESTAMP.
Instead, add an unconditional message about the GPU error state
location.
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Link: https://lore.kernel.org/r/20250429115055.2133143-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Minimum HBlank is programmed to address jitter for high resolutions with
high refresh rates that have small Hblank, specifically where Hblank is
smaller than one MTP.
TODO: Add the min_hblank calculation for hdmi as well.
v2: move from intel_audio.c to intel_dp.c
some correction in link_bpp_x16 (Imre)
v3: min_hblank for 8b/10b MST and 128b/132b SST/MST
handle error for intel_dp_mst_dsc_get_slice_count
reset min_hblank before disabling transcoder (Imre)
v4: compute link_bpp_x16 within compute_min_hblank,
return error in case of compute failure
call compute_min_hblank() before vrr_compute_config (Imre)
v5: readout MIN_HBLAN reg for Xe3+
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250424-hblank-v7-2-8b002f1506cc@intel.com
Unify the function to calculate the link symbol cycles for both dsc and
non-dsc case and export the function so that it can be used in the
respective platform display drivers for other calculations.
v2: unify the fn for both dsc and non-dsc case (Imre)
v3: rename drm_dp_link_symbol_cycles to drm_dp_link_data_symbol_cycles
retain slice_eoc_cycles as is (Imre)
v4: Expose only drm_dp_link_symbol_cycles() (Imre)
v6: Add slice pixels which was removed unknowingly (Vinod)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250424-hblank-v7-1-8b002f1506cc@intel.com
Following the convention, convert intel_hdmi.c to use an intel_connector
pointer everywhere, calling this pointer connector. If the intel
connector must be casted from a drm_connector, call this pointer
_connector and use this pointer only for the casting.
v2: Use for_each_new_intel_connector_in_state(). (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250428134716.3396802-3-imre.deak@intel.com
