This reverts commit 99510e1afb.
DSB is now getting disabled locally in the color management
code so we don't need to apply this big hammer via the device
info (not that we have other DSB users at the moment).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-12-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
The DSB has problem loading the LUTs at the moment. Some
of that is due to the palette anti collision logic, some
due to what seem real hw issues. Disable it the whole
thing locally in the color management code for now.
Note that we currently have this weird situation where on
adl+ we load parts of the LUT with DSB and parts with mmio.
That is due to the fact that only some parts of the LUT code
are using the DSB register write functions (ivb_load_lut_ext*()),
while the rest is using pure mmio (bdw_load_lut_10()). So now
we'll go back to pure mmio temporarily, until the DSB issues
get fixed (at which point we should be going for pure DSB).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-11-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
We could have many different uses for the DSB(s) during a
single commit, so the current approach of passing the whole
crtc_state to the DSB functions is far too high level. Lower
the abstraction a little bit so each DSB user can decide where
to stick the command buffer/etc.
v2: Document the intel_dsb_prepare() return value (Ankit)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-10-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Since the color management code is the only user of the DSB
at the moment move the DSB prepare/cleanup there too. The
code has to anyway make decisions on whether to use the DSB
or not (and how to use it). Also we'll need a place where we
actually generate the DSB command buffer ahead of time rather
than the current situation where it gets generated too late
during the mmio programming of the hardware.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-9-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
The use of DSB has to be done differently on a case by case basis.
So no way this kind of blind mmio fallback in the guts of the DSB
code will work properly. Move it at least one level up into the
LUT loading code. Not sure if this is the way we want do the
DSB vs. mmio handling in the end, but at least it's a bit
closer than what we had before.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-8-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Various gamma units on various platforms have some problems loading
the LUT index and auto-increment bit at the same time. We have to
do this in two steps. The first known case was the glk degamma LUT,
but at least ADL has another known case.
We're not going to suffer too badly from a couple of extra register
writes here, so let's just standardize on this practice for all
auto-increment LUT loads/reads. This way we never have to worry about
this specific issue again. And for good measure always reset the
index back to zero at the end (we already did this in a few places).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
I've been frobbing the palette anti-collision logic bit
while playing around with DSB. Not sure we'll have real
use for this but let's define the bit anyways so I don't
have to carry it around locally.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
s/GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED/GAMMA_MODE_MODE_12BIT_MULTI_SEG/
to make this thing slightly shorter.
Also fix up the platform comment while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
This patch introduces initial workarounds for mtl platform
v2: switch IS_MTL_DISPLAY_STEP to use IS_METEORLAKE from testing display
ver. (Tvrtko)
v3: clerical issues, extend 16015201720 to mtl. (MattR)
v4: make sure 16015201720 includes display 13. (MattR)
Bspec: 66624
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221209220543.502047-1-matthew.s.atwood@intel.com
Always include both the encoder and PPS instance information
in the debug prints so that we know what piece of hardware
we're actually dealing with.
v2: Make sure pps is selected before debug prints/etc. in
intel_pps_vdd_on_unlocked() on vlv/chv
There is no pps on pipe C on chv
v3: Allow PPS=INVALID_PIPE for vlv/chv
Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221127155239.26973-1-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
On ICP-ADP the pins used by the second PPS can be alternatively
muxed to some other function. In that case the second power
sequencer is unusable.
Unfortunately (on my ADL Thinkpad T14 gen3 at least) the
BIOS still likes to enable the VDD on the second PPS (due
to the VBT declaring the second bogus eDP panel) even when
not correctly muxed, so we need to deal with it somehow.
For now let's just initialize the PPS as normal, and then
use the normal eDP probe failure VDD off path to turn it off
(and release the wakeref the PPS init grabbed). The
alternative of just declaring that the platform has a single
PPS doesn't really work since it would cause the second eDP
probe to also try to use the first PPS and thus clobber the
state for the first (real) eDP panel.
Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-7-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
On the PCH side the second PPS was introduced in ICP. Let's
make sure we examine both power sequencer on ICP+ as well.
Note that DG1/2 south block only has the single PPS, so need
to exclude the fake DG1/2 PCHs.
Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-6-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Currently on bxt/glk we just grab the power sequencer index from
the VBT data even though it may not have been parsed yet. That
could lead us to using the incorrect power sequencer during the
initial panel probe.
To avoid that let's try to read out the current state of the
power sequencer from the hardware. Unfortunately the power
sequencer no longer has anything in its registers to associate
it with the port, so the best we can do is just iterate through
the power sequencers and pick the first one. This should be
sufficient for single panel cases.
For the dual panel cases we probably need to go back to
parsing the VBT before the panel probe (and hope that
panel_type=0xff is never a thing in those cases). To that
end the code always prefers the VBT panel sequencer, if
available.
v2: Restructure a bit for upcoming icp+ dual PPS support
Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-5-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Restate the vlv_pipe_check() stuff in terms of PPS index
(rather than pipe, which it is on VLV/CHV) so that we can
reuse this same mechanim on other platforms as well.
Cc: Animesh Manna <animesh.manna@intel.com>
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/20221125173156.31689-4-ville.syrjala@linux.intel.com
Lots of ADL machines out there with bogus VBTs that declare
two eDP child devices. In order for those to work we need to
figure out which power sequencer to use before we try the EDID
read. So let's do the panel VBT init early if we can, falling
back to the post-EDID init otherwise.
The post-EDID init panel_type=0xff approach of assuming the
power sequencer should already be enabled doesn't really work
with multiple eDP panels, and currently we just end up using
the same power sequencer for both eDP ports, which at least
confuses the wakeref tracking, and potentially also causes us
to toggle the VDD for the panel when we should not.
Cc: Animesh Manna <animesh.manna@intel.com>
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/20221125173156.31689-3-ville.syrjala@linux.intel.com
Introduce a place where we can initialize connector->panel
after it's been allocated. We already have a intel_panel_init()
so had to get creative with the name and came up with
intel_panel_init_alloc().
Cc: Animesh Manna <animesh.manna@intel.com>
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/20221125173156.31689-2-ville.syrjala@linux.intel.com
Bspecs has updated recently to remove the restriction to disable
DDI/Transcoder before setting PHY test pattern. This update is to
address PHY compliance test failures observed on a port with LTTPR.
The issue is that when Transc. is disabled, the main link signals fed
to LTTPR will be dropped invalidating link training, which will affect
the quality of the phy test pattern when the transcoder is enabled again.
v2: Update commit message (Clint)
v3: Add missing Signed-off in v2
v4: Update Bspec and commit message for pre-gen12 (Jani)
Bspec: 50482, 7555
Fixes: 8cdf727119 ("drm/i915/dp: Program vswing, pre-emphasis, test-pattern")
Cc: Imre Deak <imre.deak@intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
CC: Jani Nikula <jani.nikula@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123220926.170034-1-khaled.almahallawy@intel.com
On mtl (at least) clearing the guardband bits in the same write
as the enable bit gets cleared seems to cause an immediate FIFO
underrun. Thus is seems that we need to first clear just the
enable bit, then wait for the VRR live status to indicate the
transcoder has exited VRR mode (this step is documented in Bspec
as well), and finally we can clear out the rest of the TRANS_VRR_CTL
for good measure.
I did this without any RMWs in case we want to toggle VRR on/off
via DSB in the future, and as we know DSB can't read registers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-5-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
On mtl it looks like disabling VRR after the transcoder has
been disabled can cause the pipe/transcoder to get stuck
when re-enabled in non-vrr mode. Reversing the order seems to
help.
Bspec is extremely confused about the VRR enable/disable sequence
anyway, and this now more closely matches the non-modeset VRR
sequence, whereas the full modeset sequence still claims that
the original order is fine. But since we eventually want to toggle
VRR without a full modeset anyway this seems like the better order
to follow.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-4-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
We are miscalculating both the guardband value, and the resulting
vblank exit length on adl+. This means that our start of vblank
(double buffered register latch point) is incorrect, and we also
think that it's not where it actually is (hence vblank evasion/etc.
may not work properly). Fix up the calculations to match the real
hardware behaviour (as reverse engineered by intel_display_poller).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-3-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Account for the framestart delay when calculating the "pipeline full"
value for icl/tgl vrr. This puts the start of vblank (ie. where the
double bufferd registers get latched) to a consistent place regardless
of what framestart delay value is used. framestart delay does not
change where start of vblank occurs in non-vrr mode and I can't see
any reason why we'd want different behaviour in vrr mode.
Currently framestart delay is always set to 1, and the hardcoded 4
scanlines in the code means we're currently delaying the start of
vblank by three extra lines. And with framestart delay set to 4 we'd
have no extra delay.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Despite what I claimed in commit c3c5dc1d92
("drm/i915/audio: Do the vblank waits") the vblank
interrupts are in fact not enabled yet when we do the
audio enable sequence on VLV/CHV (all other platforms are
fine).
Reorder the enable sequence on VLV/CHV to match that of the
other platforms so that the audio enable happens after the
pipe has been enabled.
Fixes: c3c5dc1d92 ("drm/i915/audio: Do the vblank waits")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221207225219.29060-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add more de helpers to be able to avoid direct calls to uncore.
v3 by Jani:
- drop intel_de_write_samevalue/intel_de_rewrite_fw altogether
v2 by Jani:
- drop pcode stuff for now
- rename intel_de_write_samevalue -> intel_de_rewrite_fw
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0d051554dfeeb4d8aa3bc9136ed111fa35f647d8.1670433372.git.jani.nikula@intel.com
Replace integrated with discrete for dgfx platforms.
v2: commit title reword (Jani)
v3: use variable name i915 (Jani)
v4: commit message reword (MattR)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Taylor, Clinton A <clinton.a.taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221129203343.720860-1-clinton.a.taylor@intel.com
Use HAS_DSC(__i915) wrapper containing runtime info of has_dsc
member. Platforms supporting dsc has this flag enabled; no need of
DISPLAY_VER() check.
Also, simplified intel_dsc_source_support() based on above changes.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221110093312.13932-1-swati2.sharma@intel.com
