Since an HDMI output can only be enabled in legacy mode on TC ports,
assume that VBT is wrong and the port is legacy if VBT says the port is
non-legacy and has HDMI. If VBT says to enable DP as well leave the
non-legacy flag enabled, relying on the flag getting fixed up based on
the HPD status during sink detection.
v2: Fix the legacy port flag only if DP is not enabled.
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/20230321220101.983366-1-imre.deak@intel.com
Atm, a TC port's initial mode will be read out as TBT mode in any case
the PHY ownership is not held. This isn't correct for legacy ports which
should be used only in legacy mode.
Fix the above initial mode to be disconnected mode for a legacy port and
TBT mode for DP-alt/TBT ports. Determine the port type by checking first
the HPD state and then the legacy VBT flag (so the HPD state can correct
a bogus VBT flag). If a sink is connected on a disabled port the PHY
will get also connected (switching it to legacy mode on a legacy port).
Also connect the PHY on a legacy port if it's enabled but BIOS
incorrectly left it in the disconnected state for some reason.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-10-imre.deak@intel.com
Atm, the target TC mode - which the PHY should be switched to at any
point it's used - is TBT in case there is no sink connected. However
legacy ports are only used in the legacy mode regardless of the sink
connected state. Fix the mode returned by
intel_tc_port_get_target_mode() accordingly.
Despite of the above issue, the PHY got disconnected as expected in
response to a sink disconnect event, causing only a redundant
PHY disconnect->reconnect sequence whenever the port was used.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-8-imre.deak@intel.com
During boot-up/system resume, the TC PHY on legacy ports will be
initialized by the IOM/TCSS firmware regardless of a sink being
connected or not (as opposed to DP-alt/TBT ports, which the FW only
inits once a sink is connected).
Wait for the above initialization to complete during HW readout, so that
connecting the PHY later will already see the expected PHY ready state.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-6-imre.deak@intel.com
At least restoring the MST topology during system resume needs to use
AUX before the display HW readout->sanitization sequence is complete,
but on TC ports the PHY may be in the wrong mode for this, resulting in
the AUX transfers to fail.
The initial TC port mode is kept fixed as BIOS left it for the above HW
readout sequence (to prevent changing the mode on an enabled port). If
the port is disabled this initial mode is TBT - as in any case the PHY
ownership is not held - even if a DP-alt sink is connected. Thus, the
AUX transfers during this time will use TBT mode instead of the expected
DP-alt mode and so time out.
Fix the above by connecting the PHY during port initialization if the
port is disabled, which will switch to the expected mode (DP-alt in the
above case).
As the encoder/pipe HW state isn't read-out yet at this point, check if
the port is enabled based on the DDI_BUF enabled flag. Save the read-out
initial mode, so intel_tc_port_sanitize_mode() can check this wrt. the
read-out encoder HW state.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-5-imre.deak@intel.com
On TC ports the 4ms AUX timeout combined with the 5 * 32 retry
attempts during DPCD accesses adds a 640ms delay to each access if the
sink is disconnected. This in turn slows down a modeset during which the
sink is disconnected (for instance a disabling modeset).
Prevent the above delay by aborting AUX transfers on a TC port with a
disconnected sink.
The DP 1.4a link CTS (4.2.1.5 Source Device Inactive HPD / Inactive AUX
Test") also requires not to initiate AUX transfers on disconnected DP
ports in general, however this patch doesn't change the behavior on
non-TC ports, leaving that for a follow-up.
Reported-and-tested-by: Chris Chiu <chris.chiu@canonical.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8279
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230316131724.359612-2-imre.deak@intel.com
Keeping DC states enabled is incompatible with the _noarm()/_arm()
split we use for writing pipe/plane registers. When DC5 and PSR
are enabled, all pipe/plane registers effectively become self-arming
on account of DC5 exit arming the update, and PSR exit latching it.
What probably saves us most of the time is that (with PIPE_MISC[21]=0)
all pipe register writes themselves trigger PSR exit, and then
we don't re-enter PSR until the idle frame count has elapsed.
So it may be that the PSR exit happens already before we've
updated the state too much.
Also the PSR1 panel (at least on this KBL) seems to discard the first
frame we trasmit, presumably still scanning out from its internal
framebuffer at that point. So only the second frame we transmit is
actually visible. But I suppose that could also be panel specific
behaviour. I haven't checked out how other PSR panels behave, nor
did I bother to check what the eDP spec has to say about this.
And since this really is all about DC states, let's switch from
the MODESET domain to the DC_OFF domain. Functionally they are
100% identical. We should probably remove the MODESET domain...
And for good measure let's toss in an assert to the place where
we do the _noarm() register writes to make sure DC states are
in fact off.
v2: Just use intel_display_power_is_enabled() (Imre)
Cc: <stable@vger.kernel.org> #v5.17+
Cc: Manasi Navare <navaremanasi@google.com>
Cc: Drew Davenport <ddavenport@chromium.org>
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Fixes: d13dde4495 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair")
Fixes: f8a005eb89 ("drm/i915: Optimize icl+ universal plane programming")
Fixes: 890b6ec4a5 ("drm/i915: Split skl+ plane update into noarm+arm pair")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320183532.17727-1-ville.syrjala@linux.intel.com
SKL/GLK CSC unit suffers from a nasty issue where a CSC
coeff/offset register read or write between DC5 exit and
PSR exit will undo the CSC arming performed by DMC, and
then during PSR exit the hardware will latch zeroes into
the active CSC registers. This causes any plane going
through the CSC to output all black.
We can sidestep the issue by making sure the PSR exit has
already actually happened before we touch the CSC coeff/offset
registers. Easiest way to guarantee that is to just move the
CSC programming back into the .color_commir_arm() as we force
a PSR exit (and crucially wait for it to actually happen)
prior to touching the arming registers.
When PSR (and thus also DC states) are disabled we don't
have anything to worry about, so we can keep using the
more optional _noarm() hook for writing the CSC registers.
Cc: <stable@vger.kernel.org> #v5.19+
Cc: Manasi Navare <navaremanasi@google.com>
Cc: Drew Davenport <ddavenport@chromium.org>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8283
Fixes: d13dde4495 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320095438.17328-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Enable SDP error detection configuration, this will set CRC16 in
128b/132b link layer.
For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
added to enable/disable SDP CRC applicable for DP2.0 only, but the
default value of this bit will enable CRC16 in 128b/132b hence
skipping this write.
Corrective actions on SDP corruption is yet to be defined.
v2: Moved the CRC enable to link training init(Jani N)
v3: Moved crc enable to ddi pre enable <Jani N>
v4: Separate function for SDP CRC16 (Jani N)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230302081532.765821-3-arun.r.murthy@intel.com
Add some (probably overkill) locking to protect the vblank
timestamping constants updates during seamless M/N fastsets.
As everything should be naturally aligned I think the individual
pieces should probably end up updating atomically enough. So this
is only really meant to guarantee everyone sees a consistent whole.
All the drm_vblank.c usage is covered by vblank_time_lock,
and uncore.lock will take care of __intel_get_crtc_scanline()
that can also be called from outside the core vblank functionality.
Currently only crtc_clock and framedur_ns can change, but in
the future might fastset also across eg. vtotal/vblank_end
changes, so let's just grab the locks across the whole thing.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-2-ville.syrjala@linux.intel.com
When we change the M/N values seamlessly during a fastset we should
also update the vblank timestamping stuff to make sure the vblank
timestamp corrections/guesstimations come out exact.
Note that only crtc_clock and framedur_ns can actually end up
changing here during fastsets. Everything else we touch can
only change during full modesets.
Technically we should try to do this exactly at the start of
vblank, but that would require some kind of double buffering
scheme. Let's skip that for now and just update things right
after the commit has been submitted to the hardware. This
means the information will be properly up to date when the
vblank irq handler goes to work. Only if someone ends up
querying some vblanky stuff in between the commit and start
of vblank may we see a slight discrepancy.
Also this same problem really exists for the DRRS downclocking
stuff. But as that is supposed to be more or less transparent
to the user, and it only drops to low gear after a long delay
(1 sec currently) we probably don't have to worry about it.
Any time something is actively submitting updates DRRS will
remain in high gear and so the timestamping constants will
match the hardware state.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Fixes: e6f29923c0 ("drm/i915: Allow M/N change during fastset on bdw+")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-1-ville.syrjala@linux.intel.com
Some panels generate long HPD events even while connected to
the port. This cause some unexpected CI execution issues. A
new flag is added to track if such spurious long HPDs can be
ignored and are not processed further if the flag is set.
Debugfs entry is added to control the ignore long hpd flag.
v2: Address patch styling comments (Jani Nikula)
v3: Ignoring the HPD moved to hotplug handler and now applies
to all types of outputs (Imre Deak)
v4: use debugfs_create_bool and squash patches (Jani Nikula)
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230215083832.287519-2-vinod.govindapillai@intel.com
The pipe needs a certain amount of time during vblank to prefill
sufficiently. If the vblank is too short the relevant watermark
level must be disabled.
Start implementing the necessary calculations to check this.
Scaler and DSC prefill are left out for now as handling those
is not entirely trivial.
Also the PSR latency reporting override chicken bits would
need to be correctly configured based on the results of these
calculations. Just add some FIXMEs for now.
TODO: bspec isn't exactly crystal clear in its explanations
so quite a few open questions remain...
v2: Skip inacive pipes
Handle SAGV latency
v3: Rebase
v4: Fix handling of disabled wm levels (latency == 0)
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230306164854.25928-1-ville.syrjala@linux.intel.com
Atm, during system resume, the driver updates the display connector
information required by the opregion video extensions during system
resume, on platforms both with and without display being present. On
!HAS_DISPLAY platforms this will result in the crash with the stack
trace below, since the driver's connector state is not initialized on
those.
Bspec doesn't specify when each of the opregion functionality is
supported (depending on the presence of display), however we can presume
that none of the video extensions, nor the ACPI _DSM functions are
supported on !HAS_DISPLAY platforms; accordingly skip the corresponding
opregion/ACPI setup on those (also matching the Windows driver in this).
Keep sending the opregion notification about suspending/resuming the
whole adapter (vs. the display only which is a separate power state
notification) on all platforms, similarly to runtime suspend/resume.
This fixes the following:
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 1443 Comm: kworker/u40:55 Tainted: G U 6.2.0-rc8+ #58
Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW 04/26/2022
Workqueue: events_unbound async_run_entry_fn
RIP: 0010:drm_connector_list_iter_next+0x4f/0xb0
Call Trace:
<TASK>
intel_acpi_device_id_update+0x80/0x160 [i915]
intel_opregion_resume+0x2f/0x1e0 [i915]
? dg2_init_clock_gating+0x49/0xf0 [i915]
i915_drm_resume+0x137/0x190 [i915]
? __pfx_pci_pm_resume+0x10/0x10
dpm_run_callback+0x47/0x150
Cc: iczero <iczero@hellomouse.net>
Reported-and-tested-by: iczero <iczero@hellomouse.net>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230308162503.3219200-1-imre.deak@intel.com
intel_crtc_prepare_cleared_state() is unintentionally losing
the "inherited" flag. This will happen if intel_initial_commit()
is forced to go through the full modeset calculations for
whatever reason.
Afterwards the first real commit from userspace will not get
forced to the full modeset path, and thus eg. audio state may
not get recomputed properly. So if the monitor was already
enabled during boot audio will not work until userspace itself
does an explicit full modeset.
Cc: stable@vger.kernel.org
Tested-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230223152048.20878-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
We currently have an issue with some BPPs when using DSC.
According to the HW team, the reason is that a single VDSC engine
instance has some BW limitations that must be accounted for.
So, whenever we approach around 90% of the CDCLK, a second VDSC engine
has to be used.
This always means using two slices. However, in our current code,
the amount of slices is calculated independently of whether
we need to enable the second VDSC engine or not.
This leads to some logical issues when, according to the pixel clock needs,
we need to enable the second VDSC engine.
But as we calculated previously that we can only use a single slice,
we can't do that and fail.
So, we need to fix that so that the number of VDSC engines enabled
should depend on the number of slices, and the number of slices
should also depend on BW requirements.
Lastly, we didn't have BPP limitation for ADLP/MTL/DG2 implemented,
which says that DSC output BPPs can only be chosen within the range of 8 to 27
(BSpec 49259).
All of this applied together allows us to fix existing FIFO underruns,
which we have in many DSC tests.
v2: - Replace min with clamp_t(Jani Nikula)
- Fix commit message(Swati Sharma)
- Added "Closes"(Swati Sharma)
BSpec: 49259
HSDES: 18027167222
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8231
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230306080401.22552-1-stanislav.lisovskiy@intel.com
