Cleanup the intel_phy_is_combo
to accommodate for cases where combo phy is not available.
v2: retain comment that explains DG2 returning false from
intel_phy_is_combo() (Arun)
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220725225028.98612-1-anusha.srivatsa@intel.com
HDMI2.1 requires some higher resolution video modes to be enumerated
only if HDMI2.1 Fixed Rate Link (FRL) is supported.
Current platforms do not support FRL transmission so prune modes that
require HDMI2.1 FRL.
v2: Fixed the condition to check for dotclock > 600.
Return MODE_CLOCK_HIGH as mode status.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> (v1)
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220721084645.3411219-1-ankit.k.nautiyal@intel.com
Add debug print statement to print scaler filter property
value. Since property can be set as either default or integer
scaler; its good if we can get debug print for the same in dmesg
log.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220706102240.21414-1-swati2.sharma@intel.com
The issue here was on for_each_intel_encoder_mask_with_psr() over the
new_crtc_state encoder mask, so if the CRTC was being disabled mask
would be zero and it would not have any chance to disable PSR.
So here doing for_each_intel_encoder_mask_with_psr() over the
old_crtc_state encoder mask and then using the new_crtc_state to
check if PSR needs to be disabled.
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220714150755.154985-2-jose.souza@intel.com
This patches fixes a issue but not in the right way as
for_each_oldnew_intel_crtc_in_state() will interate over all CRTCs
not only the crtc passed as parameter, also this two for_each loops
are not necessary and only make code harder to understand.
Proper fix will be discussed in the next patch.
This reverts commit 75f664903d.
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220714150755.154985-1-jose.souza@intel.com
Starting with TGL the disabling order of HDMI transcoder clock vs. DDI
BUF has swapped, fix this. There hasn't been any issues seen related to
this, but let's follow the spec.
Reported-by: Sandeep K Lakkakula <sandeep.k.lakkakula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220617112807.1586621-1-imre.deak@intel.com
Currently PSR is left enabled when all planes are disabled if there
is no attached encoder in new state. This seems to be causing FIFO
underruns.
Fix this by checking if encoder exists in new crtc state and disable
PSR if it doesn't.
v2: Unify disable logic with existing
Cc: Mika Kahola <mika.kahola@intel.com>
Reported-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220711111750.881552-1-jouni.hogander@intel.com
JSP is based on ICP and we don't really need to differentiate
between the two. So let's just delcare JSP to be ICP.
The only slight change here is for Wa_14011294188 which we
used to apply for JSP but now we'll only apply to MCC. This
should be fine since the issue being dealt with was introduced
in TGP and inherited into MCC. JSP being derived from ICP
should not need this workaround.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220630150600.24611-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Display is turned off by i915_drm_suspend() during the suspend
procedure, removing the last reference of some gem objects that were
used by display.
The issue is that those objects are only actually freed when
mm.free_work executed and that can happen very late in the suspend
process causing issues.
So here draining all freed objects released by display fixing suspend
issues.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220629134721.48375-1-jose.souza@intel.com
We've just set up device info in i915_driver_create() so we can use
DISPLAY_VER() intead of looking at match_info directly.
Semantically we want to check the display version instead of the
graphics version, and for the earlier platforms they are always the
same.
v2: Use DISPLAY_VER() instead of GRAPHICS_VER() (Ville)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220628141005.226252-1-jani.nikula@intel.com
The ddc pin and aux channel sanitization may disable DVI/HDMI and DP,
respectively, of ports parsed earlier, in "last one wins" fashion. With
parsing and printing interleaved, we'll end up logging support first and
disabling later anyway.
Now that we've split ddi port info parsing and printing, take it further
by doing the printing in a separate loop, fixing the logging.
Note that this also changes the logging order from VBT child device
order to port number order.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220621123732.1118437-1-jani.nikula@intel.com
If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.
Fixes: 091a4f9194 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.com
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
This function is supposed to return zero or negative error codes but it
accidentally returns true on failure.
Fixes: 92a020747d ("drm/i915: Split shared dpll .get_dplls() into compute and get phases")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YrVcHArNMTGCSy+9@kili
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Stop hand rolling _MMIO_TRANS2() and just use the real thing.
Note that this register isn't even used atm, hence why this
builds despite the _PIPE2() macro not actually existing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220623130900.26078-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Eliminate the PIPECONF RMWs from .comit_commit() so
that we can finally declare the whole vblank evade part
(and the noarm() part) of the pipe commit free of register
reads. Or at least I hope that's the last read...
Only the i9xx/ilk codepaths need this for now, but let's
add the same thing for hsw+ just in case we want to start
calling that during fastsets at some point (eg. to change
dithering settings/etc.).
Should open up the way to start experimenting with
different DSB usage approaches for pipe commits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220413192607.27533-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Currently i915 disables d3cold for i915 pci dev.
This blocks D3 for i915 gfx pci upstream bridge (VSP).
Let's disable d3cold at gfx root port to make sure that
i915 gfx VSP can transition to D3 to save some power.
We don't need to disable/enable d3cold in rpm, s2idle
suspend/resume handlers. Disabling/Enabling d3cold at
gfx root port in probe/remove phase is sufficient.
Fixes: 1a085e2341 ("drm/i915: Disable D3Cold in s2idle and runtime pm")
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Acked-by:: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220616122249.5007-1-anshuman.gupta@intel.com
When the last reference of a gem object is removed it is added to the
mm.free_list list and mm.free_work is queued to actually free the
object.
So gem objects that had their last reference removed by display during
drm_atomic_helper_shutdown() are added to mm.free_list what could
cause that mm.free_work is executed at the same time as
intel_runtime_pm_driver_release() causing raw-wakerefs warning.
So here only calling i915_gem_suspend() and by consequence
i915_gem_drain_freed_objects() only after display is down making
sure all display gem objecs are freed when
intel_runtime_pm_driver_release() is executed.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220617190629.355356-1-jose.souza@intel.com
Each LFP may have different panel type which is stored in LFP data
data block. Based on the child device index respective panel-type/
panel-type2 field will be used.
v1: Initial rfc verion.
v2: Based on review comments from Jani,
- Used panel-type instead addition panel-index variable.
- DEVICE_HANDLE_* name changed and placed before DEVICE_TYPE_*
macro.
v3:
- passing intel_bios_encoder_data as argument of
intel_bios_init_panel(). Passing NULL to indicate encoder is not
initialized yet for dsi as current focus is to enable dual EDP. [Jani]
v4:
- encoder->devdata used which is initialized before from vbt
structure. [Jani]
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220620065138.5126-1-animesh.manna@intel.com
This reverts commit 73867c8709 ("drm/i915/display: Remove check for
low voltage sku for max dp source rate"), which, on an i7-11850H iGPU
with a Thinkpad X1 Extreme Gen 4, attached to a LG LP160UQ1-SPB1
embedded panel, causes wild flickering glitching technicolor
pyrotechnics on resumption from suspend. The display shows strobing
colors in an utter disaster explosion of pantone, as though bombs were
dropped on the leprechauns at the base of the rainbow.
Rebooting the machine fixes the issue, presumably because the display is
initialized by firmware rather than by i915. Otherwise, the GPU appears
to work fine.
Bisection traced it back to this commit, which makes sense given the
issues.
Note: This re-opens, and puts back to the drawing board,
https://gitlab.freedesktop.org/drm/intel/-/issues/5272 which was fixed
by the regressing commit.
Fixes: 73867c8709 ("drm/i915/display: Remove check for low voltage sku for max dp source rate")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220613102241.9236-1-Jason@zx2c4.com
Add new file intel_modeset_verify.c for high level modeset verification
code to declutter intel_display.h. The new file is supposed to be about
crtc/encoder/connector verification; the state verification for very
specific functionality such as plls or wm should be placed next to the
code it verifies.
Fix some minor checkpatch issues while at it.
v2: Rebase
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b9b47c14316a9edb772a8b8f934eabe7e928dd76.1655372759.git.jani.nikula@intel.com
Older VBTs don't have all the stuff we've defined for the
LVDS options block (40). In particular we're currently parsing
the DPS panel type bits even though they may not exist, which
could mean we end up flagging the machine as supporting static
DRRS when the VBT declared no such thing.
We don't actually have a clear idea which VBT versions have
which bits so we rely on the block size instead.
Here's a quick list from my VBT stash:
mgm version 108 -> 4 bytes
alv version 120 -> 4 bytes
cst version 134 -> 14 bytes
pnv version 144 -> 14 bytes
cl version 142 -> 16 bytes
ctg version 155 -> 24 bytes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220615151445.8531-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Parsing the panel_type is a bit special and should be done
before we parse anything else potentially panel-specific from
the VBT. So move it out from parse_panel_options(). It doesn't
neet to be there anyway since it'll do its own LVDS options
block lookup.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220615151445.8531-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The WARN shouldn't have been added yet. For the moment the
clock that gets passed here is just what the user has requested
(via the modeline) and may not be exactly what iCLKIP can
generate.
Later on the plan is to change things so that we already get
passed the exact clock here, at which point the WARN should
be reintroduced.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6246
Fixes: 97708335b0 ("drm/i915: Introduce struct iclkip_params")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220616095530.15024-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Make sure FIFO underrun reporting is flagged as disabled very
early during the state readout so that we don't get any
spurious FIFO underruns reports from intel_crtc_disable_noatomic().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220615174851.20658-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Anusha Srivatsa
Ankit Nautiyal
Swati Sharma
José Roberto de Souza
Imre Deak
Matt Roper
Jouni Högander
Stanislav Lisovskiy
Ville Syrjälä
Tom Rix
Jani Nikula
Hangyu Hua
Dan Carpenter
Anshuman Gupta
Animesh Manna
Jason A. Donenfeld