Imre Deak [Tue, 24 Oct 2023 01:09:16 +0000 (04:09 +0300)]
drm/i915/dp_mst: Handle the Synaptics HBlank expansion quirk
The Synaptics MST hubs expose some sink EDID modes with a reduced HBLANK
period, presumedly to save BW, which the hub expands before forwarding
the stream to the sink. In particular a 4k mode with a standard CVT
HBLANK period is exposed with either a CVT reduced blank RBv1,v2 (80,
160 pixel) or a non-CVT 56 pixel HBLANK period. The DP standard
describes the above HBLANK expansion functionality, but it requires
enabling this explicitly, whereas these hubs apply the expansion
transparently.
In some TBT docks with such a Synaptics hub (DELL WD22TB4) the above modes
will work okay until DSC decompression is enabled in the hub for the given
sink, but after this the same mode will not work reliably in decompressed
mode. In another TBT dock (Thinkpad 40B0) the above modes will not work
in uncompressed/18bpp mode (regardless of whether DSC decompression was
enabled before or not).
As a workaround force enable DSC for such modes. Apply the WA when the
HBLANK period is 300ns or below, matching the above tested modes with a
533.25MHz dotclock and maximum 160 HBLANK pixels.
OTOH DSC for these modes will only work above a certain compressed bpp
threshold which depends on the link rate, so apply this limit as well
in the workaround.
On platforms, pipe/port configurations where DSC is not supported, for
instance on ICL where DSC/MST is still work-in-progress, limit the
minimum link bpp to 24.
Apply the workaround only for Synaptics hubs which support the HBLANK
expansion.
v2:
- Apply the WA whenever the HBLANK period is 300ns or below.
v3:
- Clarify in the commit log the failure modes of the different docks.
- Handle platforms/pipe/port configurations without DSC support.
Imre Deak [Tue, 24 Oct 2023 01:09:14 +0000 (04:09 +0300)]
drm/i915/dp: Wait for FEC detected status in the sink
As required by the DP standard wait for the sink to detect the FEC
decode enabling symbol sent by the source.
There is a difference between SST and MST when the source enables
the FEC encoding: on SST this happens only after enabling the
transcoder, whereas on MST it happens already after enabling the
transcoder function (before enabling the transcoder). Wait for the
detected status at the earliest spot accordingly.
v2:
- Wait for the FEC detected status on SST after the transcoder is
enabled.
Imre Deak [Tue, 24 Oct 2023 01:09:11 +0000 (04:09 +0300)]
drm/i915/dp: Make sure the DSC PPS SDP is disabled whenever DSC is disabled
Atm the DSC PPS SDP will stay enabled after enabling and disabling DSC.
This leaves an output blank after switching off DSC on it. Make sure the
SDP is disabled for an uncompressed output.
v2:
- Disable the SDP already during output disabling. (Ville)
Imre Deak [Tue, 24 Oct 2023 01:09:10 +0000 (04:09 +0300)]
drm/i915/dp_mst: Program the DSC PPS SDP for each stream
Atm the DSC PPS SDP is programmed only if the first stream is compressed
and then it's programmed only for the first stream. This left all other
compressed streams blank. Program the SDP for all streams.
v2:
- Rebase on upstream include "intel_vdsc.h" change.
Imre Deak [Tue, 24 Oct 2023 01:09:09 +0000 (04:09 +0300)]
drm/i915/dp_mst: Add atomic state for all streams on pre-tgl platforms
If an MST stream is modeset, its state must be checked along all the
other streams on the same MST link, for instance to resolve a BW
overallocation of a non-sink MST port or to make sure that the FEC is
enabled/disabled the same way for all these streams.
To prepare for that this patch adds all the stream CRTCs to the atomic
state and marks them for modeset similarly to tgl+ platforms. (If the
state computation doesn't change the state the CRTC is switched back to
fastset mode.)
So far on tgl+ this was required because all streams in the topology
shared the master transcoder. For older platforms this didn't apply but
adding all the state is required now on all platforms based on the
above.
v2:
- Add code and commit log comment clarifying the requirements on old/new
platforms. (Stan)
- Rename the function based on the new semantic. (Ville)
Imre Deak [Tue, 24 Oct 2023 01:09:08 +0000 (04:09 +0300)]
drm/i915/dp_mst: Account for FEC and DSC overhead during BW allocation
Atm, the BW allocated for an MST stream doesn't take into account the
DSC control symbol (EOC) and data alignment overhead on the local (first
downstream) MST link (reflected by the data M/N/TU values) and - besides
the above overheads - the FEC symbol overhead on 8b/10b remote
(after a downstream branch device) MST links.
In addition the FEC overhead used on the local link is a fixed amount,
which only applies to certain modes, but not enough for all modes; add a
code comment clarifying this.
Fix the above by calculating the data M/N values with the total BW
overhead (not including the SSC overhead, since this isn't enabled by
the source device) and using this the PBN and TU values for the local
link and PBN for remote links (including SSC, since this is mandatory
for links after downstream branch devices).
For now keep the current fixed FEC overhead as a minimum, since this is
what bspec requires for audio functionality.
Calculate the effective link BW in a clearer way, applying the channel
coding efficiency based on the coding type. The calculation was correct
for 8b/10b, but not for 128b/132b links; this patch leaves the behavior
for this unchanged, leaving the fix for a follow-up.
v2:
- Fix TU size programmed to the HW, making it match the payload size
programmed to the payload table.
v3:
- Add code comment about the connection between the payload's size in
the payload table and the corresponding PBN value. (Ville)
- Add WARN_ON(remote_m_n.tu < dp_m_n.tu). (Ville)
- Add code comment about factors not accounted for by the BW
calculation in intel_dp_mst_mode_valid_ctx() (and compute config).
(Ville)
- Simplify calculation of PBN to remote_m_n.tu * mst_state->pbn_div.
Imre Deak [Tue, 24 Oct 2023 01:09:07 +0000 (04:09 +0300)]
drm/i915/dp: Pass actual BW overhead to m_n calculation
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().
Imre Deak [Tue, 24 Oct 2023 01:09:06 +0000 (04:09 +0300)]
drm/i915/dp: Specify the FEC overhead as an increment vs. a remainder
A follow-up patch will add up all the overheads on a DP link, where it
makes more sense to specify each overhead factor in terms of the added
overhead amount vs. the reciprocal remainder (of usable BW remaining
after deducting the overhead). Prepare for that here, keeping the
existing behavior.
Imre Deak [Tue, 24 Oct 2023 01:09:05 +0000 (04:09 +0300)]
drm/i915/dp_mst: Enable FEC early once it's known DSC is needed
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().
Imre Deak [Tue, 24 Oct 2023 10:22:17 +0000 (13:22 +0300)]
drm/dp: Add helpers to calculate the link BW overhead
Add helpers drivers can use to calculate the BW allocation overhead -
due to SSC, FEC, DSC and data alignment on symbol cycles - and the
channel coding efficiency - due to the 8b/10b, 128b/132b encoding. On
128b/132b links the FEC overhead is part of the coding efficiency, so
not accounted for in the BW allocation overhead.
The drivers can use these functions to calculate a ratio, controlling
the stream symbol insertion rate of the source device in each SST TU
or MST MTP frame. Drivers can calculate this
ratio for a given link and pixel stream and with that the
slots_per_mtp = CEIL(64 * m / n)
allocated slots per MTP for the stream in a link frame and with
that the
pbn = slots_per_mtp * drm_mst_get_pbn_divider()
allocated PBNs for the stream on the MST link path.
Take drm_dp_bw_overhead() into use in drm_dp_calc_pbn_mode(), for
drivers calculating the PBN value directly.
v2:
- Add dockbook description to drm_dp_bw_channel_coding_efficiency().
(LKP).
- Clarify the way m/n ratio is calculated in the commit log.
v3:
- Fix compile breakage for !CONFIG_BACKLIGHT_CLASS_DEVICE. (LKP)
- Account for FEC_PM overhead (+ 0.0015625 %), add comment
with the formula to calculate the total FEC overhead. (Ville)
v4:
- Rename DRM_DP_OVERHEAD_SSC to DRM_DP_OVERHEAD_SSC_REF_CLK. (Ville)
v5:
- Clarify in the commit log what MTP means.
- Simplify the commit log's formula to calculate PBN.
Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: kernel test robot <lkp@intel.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v2) Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107001505.3370108-1-imre.deak@intel.com
Imre Deak [Tue, 24 Oct 2023 10:22:16 +0000 (13:22 +0300)]
drm/dp_mst: Add HBLANK expansion quirk for Synaptics MST hubs
Add a quirk for Synaptics MST hubs, which require a workaround - at leat
on i915 - for some modes, on which the hub applies HBLANK expansion.
These modes will only work by enabling DSC decompression for them, a
follow-up patch will do this in i915.
v2:
- Fix the quirk name in its DocBook description.
Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-9-imre.deak@intel.com
Imre Deak [Tue, 24 Oct 2023 01:09:02 +0000 (04:09 +0300)]
drm/dp: Add DP_HBLANK_EXPANSION_CAPABLE and DSC_PASSTHROUGH_EN DPCD flags
Add the DPCD flag to enable DSC passthrough in a last branch device,
used in a follow-up i915 patch.
Also add a flag to detect HBLANK expansion support in a branch device,
used by a workaround in a follow-up i915 patch.
Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-8-imre.deak@intel.com
Imre Deak [Tue, 24 Oct 2023 01:09:01 +0000 (04:09 +0300)]
drm/dp_mst: Allow DSC in any Synaptics last branch device
The Synaptics MST branch devices support DSC decompression on all their
output ports, provided that they are last branch devices (with their
output ports connected to the sinks). The Thinkpad 40B0 TBT dock for
instance has two such branch devices, a secondary one connected to one
of the output ports of the primary; hence the decompression needs to be
enabled in both branch devices to enable decompression for all the
sinks.
Based on the above add support for enabling decompression in last
Synaptics branch devices.
Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-7-imre.deak@intel.com
Imre Deak [Tue, 24 Oct 2023 01:09:00 +0000 (04:09 +0300)]
drm/dp_mst: Swap the order of checking root vs. non-root port BW limitations
drm_dp_mst_atomic_check_mgr() should check for BW limitation starting
from sink ports continuing towards the root port, so that drivers can
use the @failing_port returned to resolve a BW overallocation in an
ideal way. For instance from streams A,B,C in a topology A,B going
through @failing_port and C not going through it, a BW overallocation of
A,B due to a limit of the port must be resolved first before considering
the limits of other ports closer to the root port. This way can avoid
reducing the BW of stream C unnecessarily due to a BW limit closer to the
root port.
Based on the above swap the order of the BW check for the root port and
the check for all the ports downstream of it (the latter going through
the topology already in the sink->root port direction).
Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-6-imre.deak@intel.com
Imre Deak [Tue, 24 Oct 2023 01:08:59 +0000 (04:08 +0300)]
drm/dp_mst: Factor out a helper to check the atomic state of a topology manager
Factor out a helper to check the atomic state for one MST topology
manager, returning the MST port where the BW limit check has failed.
This will be used in a follow-up patch by the i915 driver to improve the
BW sharing between MST streams.
Imre Deak [Tue, 24 Oct 2023 01:08:58 +0000 (04:08 +0300)]
drm/dp_mst: Add helper to determine if an MST port is downstream of another port
Add drm_dp_mst_port_downstream_of_parent() required by the i915
driver in a follow-up patch to resolve a BW overallocation of MST
streams going through a given MST port.
Ville Syrjälä [Tue, 24 Oct 2023 01:08:57 +0000 (04:08 +0300)]
drm/dp_mst: Fix fractional DSC bpp handling
The current code does '(bpp << 4) / 16' in the MST PBN
calculation, but that is just the same as 'bpp' so the
DSC codepath achieves absolutely nothing. Fix it up so that
the fractional part of the bpp value is actually used instead
of truncated away. 64*1006 has enough zero lsbs that we can
just shift that down in the dividend and thus still manage
to stick to a 32bit divisor.
And while touching this, let's just make the whole thing more
straightforward by making the passed in bpp value .4 binary
fixed point always, instead of having to pass in different
things based on whether DSC is enabled or not.
v2:
- Fix DSC kunit test cases.
Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: David Francis <David.Francis@amd.com> Cc: Mikita Lipski <mikita.lipski@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Fixes: dc48529fb14e ("drm/dp_mst: Add PBN calculation for DSC modes") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[Imre: Fix kunit test cases] Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231030155843.2251023-3-imre.deak@intel.com
Imre Deak [Sun, 29 Oct 2023 23:13:08 +0000 (01:13 +0200)]
drm/i915/dp_mst: Fix race between connector registration and setup
After drm_connector_init() is called the connector is visible to the
rest of the kernel via the drm_mode_config::connector_list. Make
sure that the DSC AUX device and capabilities are setup by that time.
Another race condition is adding the connector to the connector list
before drm_connector_helper_add() sets the connector helper functions.
That's an unrelated issue, for which the fix is for a follow-up. One
solution would be adding the connector to the connector list only
during its registration in drm_connector_register().
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 808b43fa7e56 ("drm/i915/dp_mst: Set connector DSC capabilities and decompression AUX") 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-2-imre.deak@intel.com
Mika Kahola [Mon, 6 Nov 2023 11:42:28 +0000 (13:42 +0200)]
drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier
Display driver shall read DPCD 00071h[3:1] during configuration
to get PSR setup time. This register provides the setup time
requirement on the VSC SDP entry packet. If setup time cannot be
met with the current timings
(e.g., PSR setup time + other blanking requirements > blanking time),
driver should enable sending VSC SDP one frame earlier before sending
the capture frame.
BSpec: 69895 (PSR Entry Setup Frames 17:16)
v2: Write frames before su entry to correct register (Ville, Jouni)
Move frames before su entry calculation to it's
own function (Ville, Jouni)
Rename PSR Entry Setup Frames register to indicate
Lunarlake specificity (Jouni)
v3: Modify setup entry frames calculation function to
return the actual frames (Ville)
Match comment with actual implementation (Jouni)
v4: Drop "set" from function naming (Jouni, Ville)
Use i915 instead of dev_priv (Jouni)
Imre Deak [Thu, 2 Nov 2023 19:44:34 +0000 (21:44 +0200)]
drm/i915/dp_mst: Disable DSC on ICL MST outputs
Enabling DSC on ICL MST outputs is broken leading to FIFO pipe /
transcoder underruns and blank screen. On TGL+ platforms MST/DSC works -
after fixing the known issues in [1] - however to make this work on ICL
requires more work.
So far DSC on MST probably didn't get enabled for users - due to an issue
fixed by [2] - but after fixing that, DSC could get enabled, leading to a
blank screen in ICL/MST configurations which do work atm. To prevent
this disable MST/DSC on ICL for now.
Nirmoy Das [Thu, 26 Oct 2023 12:56:36 +0000 (14:56 +0200)]
drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init
Fix below compiler warning:
intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
^~
intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
into a destination of size 8
snprintf(tc->port_name, sizeof(tc->port_name),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%c/TC#%d", port_name(port), tc_port + 1);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
v2: use kasprintf(Imre)
v3: use const for port_name, and fix tc mem leak(Imre)
Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new intel_tc_port struct") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231026125636.5080-1-nirmoy.das@intel.com
Ville Syrjälä [Wed, 1 Nov 2023 11:42:11 +0000 (13:42 +0200)]
drm/i915/dsi: Remove dead GLK checks
GLK has its own glk_dsi_clear_device_ready() so remove
the dead GLK checks from vlv_dsi_clear_device_ready().
Sadly BXT still uses vlv_dsi_clear_device_ready() so the
code still looks like a mess due to the difference in VLV/CHV
vs. BXT port A/C shenanigans.
Ville Syrjälä [Tue, 31 Oct 2023 16:08:00 +0000 (18:08 +0200)]
drm/i915: Bump GLK CDCLK frequency when driving multiple pipes
On GLK CDCLK frequency needs to be at least 2*96 MHz when accessing
the audio hardware. Currently we bump the CDCLK frequency up
temporarily (if not high enough already) whenever audio hardware
is being accessed, and drop it back down afterwards.
With a single active pipe this works just fine as we can switch
between all the valid CDCLK frequencies by changing the cd2x
divider, which doesn't require a full modeset. However with
multiple active pipes the cd2x divider trick no longer works,
and thus we end up blinking all displays off and back on.
To avoid this let's just bump the CDCLK frequency to >=2*96MHz
whenever multiple pipes are active. The downside is slightly
higher power consumption, but that seems like an acceptable
tradeoff. With a single active pipe we can stick to the current
more optiomal (from power comsumption POV) behaviour.
Jouni Högander [Tue, 31 Oct 2023 08:45:57 +0000 (10:45 +0200)]
drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence
We are preparing for Xe driver. Xe driver doesn't have i915_sw_fence
implementation. Lets drop i915_sw_fence usage from display code and
use dma_fence interfaces directly.
For this purpose stack dma fences from related objects into new plane
state. Drm_gem_plane_helper_prepare_fb can be used for fences in new
fb. Separate local implementation is used for Stacking fences from old fb
into new plane state. Then wait for these stacked fences during atomic
commit. There is no be need for separate GPU reset handling in
intel_atomic_commit_fence_wait as the fences are signaled when GPU hang is
detected and GPU is being reset.
v4:
- Drop to_new_plane_state suffix from add_dma_resv_fences
- Use dma_resv_usage_rw(false) (DMA_RESV_USAGE_WRITE)
v3:
- Rename add_fences and it's parameters
- Remove signaled check
- Remove waiting old_plane_state fences
v2:
- Add fences from old fb into new_plane_state->uapi.fence rather than
into old_plane_state->uapi.fence
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231031084557.1181630-1-jouni.hogander@intel.com
Ville Syrjälä [Wed, 18 Oct 2023 15:41:23 +0000 (18:41 +0300)]
drm/i915/mst: Always write CHICKEN_TRANS
Since we're asked to disable FECSTALL_DIS_DPTSTREAM_DPTTG when
the transcoder is disabled it seems prudent to also clear it
when enabliing the transcoder w/o FEC, just in case
someone else left it enabled by mistake.
Ville Syrjälä [Wed, 18 Oct 2023 15:41:22 +0000 (18:41 +0300)]
drm/i915/mst: Clear ACT just before triggering payload allocation
Follow the bspec sequence more closely and clear ACT sent just
before triggering the allocation. Can't see why we'd want to
deviate from the spec sequence here.
Ville Syrjälä [Wed, 18 Oct 2023 15:41:21 +0000 (18:41 +0300)]
drm/i915/mst: Disable transcoder before deleting the payload
Bspec tells us that we should disable the transcoder before
deleting the payload. Looks like this has been reversed since
MST support was added.
I suppose this shouldn't matter in practice since the downstream
device shouldn't really do anything with the new payload until
we send the ACT. But I see no compelling reason to deviate from
the bspec sequence regardless.
Ville Syrjälä [Wed, 18 Oct 2023 15:41:20 +0000 (18:41 +0300)]
drm/i915/mst: Swap TRANSCONF vs. FECSTALL_DIS_DPTSTREAM_DPTTG disable
The DP modeset sequence asks us to disable TRANSCONF before clearing
the FECSTALL_DIS_DPTSTREAM_DPTTG bit, although we are still asked
to wait for the transcoder to stop only after both steps have
been done.
Suraj Kandpal [Thu, 26 Oct 2023 12:11:40 +0000 (17:41 +0530)]
drm/i915/hdcp: Add more conditions to enable hdcp
When we dock a monitor we end up with a enable and disable connector
cycle but if hdcp content is running we get the userspace in
enabled state and driver maintaining a undesired state which causes
the content to stop playing and we only enable hdcp if the userspace
state in desired. This patch fixes that.
Suraj Kandpal [Thu, 26 Oct 2023 12:11:39 +0000 (17:41 +0530)]
drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function
Let's convert intel_hdcp_enable to a blanket function
which just has some conditions which needs to be checked
before connectors enable hdcp.
This cleans up code and avoids code duplication.
--v3
-Keep function name as intel_hdcp_enable() [Jani]
Ville Syrjälä [Thu, 12 Oct 2023 12:40:33 +0000 (15:40 +0300)]
drm/i915: Move the g45 PEG band gap HPD workaround to the HPD code
We are asked to reprogram PEG_BAND_GAP_DATA prior to enabling
hotplug detection on the g45 HDMI/DP ports. Currently we do said
reprogamming from the DP/HDMI connector initialization functions.
That code should be mostly platform agnostic so clearly not the
best place for this. Move the workaround to the place where we
actually enable HPD detection.
We have a bit of duplicated code around the DPLL disabling. Extract
that to a new function, and for symmetry also do the same for the
enable direction.
Ville Syrjälä [Thu, 12 Oct 2023 12:35:21 +0000 (15:35 +0300)]
drm/i915: Move the DPLL extra power domain handling up one level
The extra DPLL power domain is currently handled in three places:
- combo_pll_enable()
- combo_pll_disable()
- readout_dpll_hw_state()
First two of those are low level PLL funcs, but the third is a higher
level thing. So the current situation is rather inconsistent. Unify
this by moving the PLL enable/disable up one level. This also means
the extra power domain could be trivially be used by other platforms
as well.
Ville Syrjälä [Thu, 12 Oct 2023 12:35:20 +0000 (15:35 +0300)]
drm/i915: Abstract the extra JSL/EHL DPLL4 power domain better
Just include the JSL/EHL DPLL4 extra power domain in the dpll_info
struct. This way the same approach could be used by other platforms
as well (should the need arise), and we don't have to sprinkle
platform checks all over the place.
Note that I'm perhaps slightly abusing things here as
power_domain==0 (which is actually POWER_DOMAIN_DISPLAY_CORE) now
indicates that no extra power domain is needed. I suppose using
POWER_DOMAIN_INVALID would be more correct, but then we'd have to
sprinkle that to all the other DPLLs.
Ville Syrjälä [Thu, 12 Oct 2023 12:35:19 +0000 (15:35 +0300)]
drm/i915: Use named initializers for DPLL info
Use named initializers when populating the DPLL info. This
is just more convenient and less error prone as we no longer
have to keep the initializers in a specific order.
Ville Syrjälä [Fri, 13 Oct 2023 14:02:14 +0000 (17:02 +0300)]
drm/i915/bios: Clamp VBT HDMI level shift on BDW
Apparently some BDW machines (eg. HP Pavilion 15-ab) shipped with
a VBT inherited from some earlier HSW model. On HSW the HDMI level
shift value could go up to 11, whereas on BDW the maximum value is
9.
The DDI code does clamp the bogus value, but it does so with
a WARN which we don't really want. To avoid that let's just sanitize
the bogus VBT HDMI level shift value ahead of time for all BDW machines.
drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL
eDP specification supports HBR3 link rate since v1.4a. Moreover,
C10 phy can support HBR3 link rate for both DP and eDP. Therefore,
do not clamp the supported rates for eDP at 6.75Gbps.
Lucas De Marchi [Wed, 18 Oct 2023 22:28:30 +0000 (15:28 -0700)]
drm/i915/display: Abstract C10/C20 pll hw readout
intel_cx0_phy.[ch] should contain the details about C10/C20, not leaking
it to the rest of the driver. Start abstracting this by exporting a
single PLL hw readout that handles the differences between C20 and C10
internally to that compilation unit.
Lucas De Marchi [Thu, 26 Oct 2023 18:40:45 +0000 (11:40 -0700)]
drm/i915/lnl: Fix check for TC phy
With MTL adding PICA between the port and the real phy, the path
add for DG2 stopped being followed and newer platforms are simply using
the older path for TC phys. LNL is no different than MTL in this aspect,
so just add it to the mess. In future the phy and port designation and
deciding if it's TC should better be cleaned up.
To make it just a bit better, also change intel_phy_is_snps() to show
this is DG2-only.
Lucas De Marchi [Thu, 26 Oct 2023 18:40:44 +0000 (11:40 -0700)]
drm/i915/lnl: Extend C10/C20 phy
For Lunar Lake, DDI-A is connected to C10 PHY, while TC1-TC3 are connected
to C20 phy, like in Meteor Lake. Update the check in intel_is_c10phy()
accordingly.
This reverts the change in commit e388ae97e225 ("drm/i915/display:
Eliminate IS_METEORLAKE checks") that turned that into a display engine
version check. The phy <-> port connection is very SoC-specific and not
related to that version.
IS_LUNARLAKE() is defined to 0 in i915 as it's expected that the
(upcoming) xe driver is the one defining the platform, with i915 only
driving the display side.
Mika Kahola [Mon, 16 Oct 2023 12:55:44 +0000 (15:55 +0300)]
drm/i915/display: Reset message bus after each read/write operation
Every know and then we receive the following error when running
for example IGT test kms_flip.
[drm] *ERROR* PHY G Read 0d80 failed after 3 retries.
[drm] *ERROR* PHY G Write 0d81 failed after 3 retries.
Since the error is sporadic in nature, the patch proposes
to reset the message bus after every successful or unsuccessful
read or write operation.
v2: Add FIXME's to indicate the experimental nature of
this workaround (Rodrigo)
v3: Dropping the additional delay as moving reset to *_read_once()
and *_write_once() functions seem unnecessary delay
drm/i915: remove display device info from i915 capabilities
Display device and display runtime info is exposed as part of
i915_display_capabilities debugfs entry. Remove this information
from i915_ capabilities as it is now reduntant.
Jouni Högander [Tue, 24 Oct 2023 12:40:50 +0000 (15:40 +0300)]
drm/i915/display: Move psr related module parameters under display
Move psr related module parameters under display. Also fix error in
enable_psr2_sel_fetch module parameter descrtiption. It was saying disabled
by default while it's vice versa. Also psr_safest_params was missing
default value in description. This is now added.
v2:
- Fix enable_psr2_sel_fetch description.
- Add default value into psr_safest_params description.
Jouni Högander [Tue, 24 Oct 2023 12:40:48 +0000 (15:40 +0300)]
drm/i915/display: Dump also display parameters
GPU error dump contained all module parameters. If we are moving
display parameters to intel_display_params.[ch] they are not dumped
into GPU error dump. This patch is adding moved display parameters
back to GPU error dump. Display parameters are also included in
i915_capabilities
Jouni Högander [Tue, 24 Oct 2023 12:40:47 +0000 (15:40 +0300)]
drm/i915/display: Add framework to add parameters specific to display
Currently all module parameters are handled by i915_param.c/h. This
is a problem for display parameters when Xe driver is used. Add
a mechanism to add parameters specific to the display. This is mainly
copied from i915_[debugfs]_params.[ch]. Parameters are not yet moved. This
is done by subsequent patches.
v2:
- Drop unused predefinition (dentry)
- Clarify need for empty INTEL_DISPLAY_PARAMS_FOR_EACH in comment
drm/i915/display: debugfs entry to list display capabilities
Create a separate debugfs entry to list the display capabilities
IGT can rely on this debugfs entry for tests that depend on
display device and display runtime info for both xe and i915
drivers.
v2: rename the entry to i915_display_capabilities (Chaitanya)
Jouni Högander [Thu, 12 Oct 2023 07:21:57 +0000 (10:21 +0300)]
drm/i915/display: Move releasing gem object away from fb tracking
As a preparation for Xe we want to remove all i915_gem_object details away
from frontbuffer tacking code. Due to this move releasing gem object
reference to i915_gem_object_set_frontbuffer.
drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake
Meteor Lake has demonstrated consistent stability for some time.
All user-space API modifications tide to its core platform
functions are operational.
The necessary firmware components are set up and comprehensive
testing has been condused over a period.
Given the recent faborable CI results, as well, we believe it's
time to eliminate the 'force_probe' prerequisite and activate the
platform by default.
Signed-off-by: Aditya Chauhan <aditya.chauhan@intel.com> Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Lee Shawn C <shawn.c.lee@intel.com> Tested-by: Lee Shawn C <shawn.c.lee@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231008164824.919262-1-andi.shyti@linux.intel.com
Imre Deak [Wed, 11 Oct 2023 17:16:06 +0000 (20:16 +0300)]
drm/i915/dp: Remove unused DSC caps from intel_dp
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.
projects / mirror_ubuntu-kernels.git / log