drm/i915: Fix PLL state check for gmch platforms

GMCH DPLL state check was mistakenly removed in
commit 87fc875a2b85 ("drm/i915/dg2: Skip shared DPLL handling").
Bring it back.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240209183809.16887-2-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>

drm/i915: Update ADL-N PCI IDs

Extend the list of ADL-N PCI IDs to contain two new entries.

Bspec: 68397
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240214144629.106702-2-gustavo.sousa@intel.com

drm/i915/display: update pll values in sync with Bspec for MTL

DP/eDP and HDMI C20 PHY PLL values were updated for MTL platform

Signed-off-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240214070930.1028456-1-ravi.kumar.vodapalli@intel.com

drm/i915: Prevent HW access during init from connector get_modes hooks

Prevent accessing the HW from the get_modes hooks of connectors deriving
the mode list from the display's EDID. drm_edid_connector_add_modes()
will return the mode list based on the EDID which was cached during a
previous detection/get_modes call.

This also fixes the NULL deref problem (10085) which was
introduced/revealed by

commit bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown")

After the above change MST connectors will not change state during
driver init/shutdown; thus some of these connectors with no I2C/DDC
adapter registered for them (since the given MST port has no sink
connected) may stay then in the 'unknown' connector status. The
get_modes() hook should not try to use the I2C/DDC adapter in this state
(which would lead to the above NULL deref) which this patch ensures.

v2:
- Remove the redundant check from intel_crt_ddc_get_modes().
- Rebase on latest drm-tip.
- Add Fixes: line / related commit notes.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10085
Fixes: bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240212175237.2625812-2-imre.deak@intel.com

drm/i915: Prevent HW access during init from SDVO TV get_modes hook

Prevent accessing the HW from the SDVO/TV get_modes connector hook.
Returning 0 from the hook will make the caller -
drm_helper_probe_single_connector_modes() - return a default/EDID
override mode list to users. This matches the case where
intel_sdvo_get_tv_modes() fails to retrieve the current mode list due to
a HW access failure.

v2: Clarify the commit message wrt. which modes get_modes() returns. (Jouni)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240212175237.2625812-1-imre.deak@intel.com

drm/i915: Add bigjoiner force enable option to debugfs

For validation purposes, it might be useful to be able to
force Bigjoiner mode, even if current dotclock/resolution
do not require that.
Lets add such to option to debugfs.

v2: - Apparently intel_dp_need_bigjoiner can't be used, when
      debugfs entry is created so lets just check manually
      the DISPLAY_VER.

v3: - Switch to intel_connector from drm_connector(Jani Nikula)
    - Remove redundant modeset lock(Jani Nikula)
    - Use kstrtobool_from_user for boolean value(Jani Nikula)

v4: - Apply the changes to proper function(Jani Nikula)

v5: - Removed unnecessary check from i915_bigjoiner_enable_show
      (Ville Syrjälä)
    - Added eDP connector check to intel_connector_debugfs_add
      (Ville Syrjälä)
    - Removed debug message in order to prevent dmesg flooding
      (Ville Syrjälä)

v6: - Assume now always that m->private is intel_connector
    - Fixed other similar conflicts

v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä)
    - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops
      manually.(Ville Syrjälä)

v8: - Pass intel_connector to debugfs_create_file, instead of drm_connector.
      (Jani Nikula)

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240212125011.66174-1-uma.shankar@intel.com

drm/i915/dvo: Use sizeof(*variable) instead of sizeof(type)

Prefer sizeof(*variable) to sizeof(type) to make it a bit
harder to screw things up.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-14-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dvo/ns2501: Nuke pointless casts

The dvo 'dev_priv' is void* so no need for an explicit cast.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: Use per-device debugs ilk wm code

Switch to drm_dbg_kms() in the ilk wm code so we see which
device generated the debugs. Need to plumb i915 a bit deeper
to make that happen.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-12-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: Use per-device debugs in pre-ilk wm code

Switch to drm_dbg_kms() in the pre-ilk wm code so we see which
device generated the debugs. Need to plumb i915 a bit deeper
to make that happen.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: Pass the whole i915 to intel_get_cxsr_latency()

Just pass the whole i915 to intel_get_cxsr_latency() instead
of having each caller dig out bits and pieces.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/hdcp: Use per-device debugs

Switch to per-device debugs in the hdcp code so we see at least which
device is involved. Should proably also print the connector/encoder/etc.
in there, but left that for the future.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Use per-device debugs for VBT related stuff

Switch to drm_dbg_kms() in the VBT code so we see which
device generated the debugs. Need to plumb i915 a bit deeper
to make that happen.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Switch to kms debugs

The VBT code is all about displays, so switch to UT_KMS debugs
from UT_DRIVER.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/fb: Use per-device debugs

Switch to drm_dbg_kms() in the fb code so we see which
device generated the debugs.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/color: Use per-device debugs

Switch to drm_dbg_kms() in the LUT validation code so we see
which device generated the debugs. Need to plumb i915 a bit
deeper to make that happen.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/sdvo: Fix up code alignment

Realign a bunch of code that has become messy.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/sdvo: Convert to per-device debugs

Use drm_dbg_kms() instead of DRM_DEBUG_KMS() in the sdvo code
to get the device name into the debug prints.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Correct for_each_old_global_obj_in_state() arguments

for_each_old_global_obj_in_state() gives us the old state, not the
new state. Correct the name of the macro argument.

Note that while the argument was misnamed the macro did work
correctly regardless.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dp: Limit SST link rate to <=8.1Gbps

Limit the link rate to HBR3 or below (<=8.1Gbps) in SST mode.
UHBR (10Gbps+) link rates require 128b/132b channel encoding
which we have not yet hooked up into the SST/no-sideband codepaths.

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208154552.14545-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address

Commit bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS
register") defines a new macro to calculate the DSC PPS register
addresses with PPS number as an input. This macro correctly calculates
the addresses till PPS 11 since the addresses increment by 4. So in that
case the following macro works correctly to give correct register
address:

_MMIO(_DSCA_PPS_0 + (pps) * 4)

However after PPS 11, the register address for PPS 12 increments by 12
because of RC Buffer memory allocation in between. Because of this
discontinuity in the address space, the macro calculates wrong addresses
for PPS 12 - 16 resulting into incorrect DSC PPS parameter value
read/writes causing DSC corruption.

This fixes it by correcting this macro to add the offset of 12 for PPS
>=12.

v3: Add correct paranthesis for pps argument (Jani Nikula)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10172
Fixes: bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS register")
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Drew Davenport <ddavenport@chromium.org>
Signed-off-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240205204619.1991673-1-navaremanasi@chromium.org

drm/i915/display: On Xe2 always enable decompression with tile4

With Xe2 always treat tile4 as if it was using flat ccs.

Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202150602.430036-2-juhapekka.heikkila@gmail.com

drm/i915/alpm: Alpm aux wake configuration for lnl

Lunarlake has some configurations in ALPM_CTL register for legacy ALPM as
well. Write these.

Bspec: 71477

v2: move version check to lnl_alpm_configure

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-5-jouni.hogander@intel.com

drm/i915/alpm: Calculate ALPM Entry check

ALPM Entry Check represents the number of lines needed to put the main link
to sleep and keep it in the sleep state before it can be taken out of the
SLEEP state (eDP requires the main link to be in the SLEEP state for a
minimum of 5us).

Bspec: 71477

v2: move display version check into _lnl_compute_alpm_param

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-4-jouni.hogander@intel.com

drm/i915/psr: Add alpm_parameters struct

Add new alpm_parameters struct into intel_psr for all calculated
alpm parameters.

v2: Move alpm_parameters struct definition to intel_psr struct

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-3-jouni.hogander@intel.com

drm/i915/alpm: Add ALPM register definitions

Add ALPM register definitions for Lunar Lake.

v3:
  - Fix ALPM_CTL2_A address
  - Remove duplicate defines
v2:
  - Use REG_BIT instead of BIT
  - Add commit message

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-2-jouni.hogander@intel.com

drm/i915: Annotate more of the BIOS fb takeover failure paths

Annotate a few more of the failure paths on the initial
BIOS fb takeover to avoid having to guess why things
aren't working the way we expect.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-17-ville.syrjala@linux.intel.com

drm/i915: Try to relocate the BIOS fb to the start of ggtt

On MTL the GOP (for whatever reason) likes to bind its framebuffer
high up in the ggtt address space. This can conflict with whatever
ggtt_reserve_guc_top() is trying to do, and the result is that
ggtt_reserve_guc_top() fails and then we proceed to explode when
trying to tear down the driver. Thus far I haven't analyzed what
causes the actual fireworks, but it's not super important as even
if it didn't explode we'd still fail the driver load and the user
would be left with an unusable GPU.

To remedy this (without having to figure out exactly what
ggtt_reserve_guc_top() is trying to achieve) we can attempt to
relocate the BIOS framebuffer to a lower ggtt address. We can do
this at this early point in driver init because nothing else is
supposed to be clobbering the ggtt yet. So we simply change where
in the ggtt we pin the vma, the original PTEs will be left as is,
and the new PTEs will get written with the same dma addresses.
The plane will keep on scanning out from the original PTEs until
we are done with the whole process, and at that point we rewrite
the plane's surface address register to point at the new ggtt
address.

Since we don't need a specific ggtt address for the plane
(apart from needing it to land in the mappable region for
normal stolen objects) we'll just try to pin it without a fixed
offset first. It should end up at the lowest available address
(which really should be 0 at this point in the driver init).
If that fails we'll fall back to just pinning it exactly to the
origianal address.

To make sure we don't accidentlally pin it partially over the
original ggtt range (as that would corrupt the original PTEs)
we reserve the original range temporarily during this process.

v2: Try to pin explicitly to ggtt offset 0 as otherwise DG2 puts it
    even higher (atm we have no PIN_LOW flag to force it low)
v3: "fix" xe

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-16-ville.syrjala@linux.intel.com
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>

drm/i915: Tweak BIOS fb reuse check

Currently we assume that we bind the BIOS fb exactly into the same
ggtt address where the BIOS left it. That is about to change, and
in order to keep intel_reuse_initial_plane_obj() working as intended
we need to compare the original ggtt offset (called 'base' here)
as opposed to the actual vma ggtt offset we selected. Otherwise
the first plane could change the ggtt offset, and then subsequent
planes would no longer notice that they are in fact using the same
ggtt offset that the first plane was already using. Thus the reuse
check will fail and we proceed to turn off these subsequent planes.

TODO: would probably make more sense to do the pure readout first
for all the planes, then check for fb reuse, and only then proceed
to pin the object into the final location in the ggtt...

v2: "fix" xe

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-15-ville.syrjala@linux.intel.com
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>

drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objects

The "io" address of an object is its dma address minus the
region.start. Subtract the latter to make smem_start correct.
The current code happens to work for genuine LMEM objects
as LMEM region.start==0, but for LMEMBAR stolen objects
region.start!=0.

TODO: perhaps just set smem_start=0 always as our .fb_mmap()
implementation no longer depends on it? Need to double check
it's not needed for anything else...

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-14-ville.syrjala@linux.intel.com

drm/i915: Simplify intel_initial_plane_config() calling convention

There's no reason the caller of intel_initial_plane_config() should
have to loop over the CRTCs. Pull the loop into the function to
make life simpler for the caller.

v2: "fix" xe

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-13-ville.syrjala@linux.intel.com
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>

drm/i915: Split the smem and lmem plane readout apart

Declutter initial_plane_vma() a bit by pulling the lmem and smem
readout paths into their own functions.

TODO: the smem path should still be fixed to get and validate
      the dma address from the pte as well

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-12-ville.syrjala@linux.intel.com

drm/i915: s/phys_base/dma_addr/

The address we read from the PTE is a dma address, not a physical
address. Rename the variable to say so.

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-11-ville.syrjala@linux.intel.com

drm/i915: Fix MTL initial plane readout

MTL stolen memory looks more like local memory, so use the
(now fixed) lmem path when doing the initial plane readout.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-10-ville.syrjala@linux.intel.com

drm/i915: Fix region start during initial plane readout

On MTL the stolen region starts at offset 8MiB from the start of
LMEMBAR. The dma addresses are thus also offset by 8MiB. However the
mm_node/etc. is zero based, and i915_pages_create_for_stolen() will
add the appropriate region.start into the sg dma address. So when
we do the readout we need to convert the dma address read from
the PTE to be zero based as well.

Note that currently we don't take this path on MTL, but we should
and thus this needs to be fixed. For lmem this works correctly
already as the lmem region.start==0.

While at it let's also make sure the address points to somewhere within
the memory region. We don't need to check the size as
i915_gem_object_create_region_at() should later fail if the object size
exceeds the region size.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-9-ville.syrjala@linux.intel.com

drm/i915: Fix PTE decode during initial plane readout

When multiple pipes are enabled by the BIOS we try to read out each
in turn. But we do the readout for the second only after the inherited
vma for the first has been rebound into its original place (and thus
the PTEs have been rewritten). Unlike the BIOS we set some high caching
bits in the PTE on MTL which confuses the readout for the second plane.
Filter out the non-address bits from the PTE value appropriately to
fix this.

I suppose it might also be possible that the BIOS would already set
some caching bits as well, in which case we'd run into this same
issue already for the first plane.

TODO:
- should abstract the PTE decoding to avoid details leaking all over
- should probably do the readout for all the planes before
  we touch anything (including the PTEs) so that we truly read
  out the BIOS state

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-8-ville.syrjala@linux.intel.com

drm/i915: Rename the DSM/GSM registers

0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.

v2: Rebase

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-7-ville.syrjala@linux.intel.com

drm/i915: Disable the "binder"

Now that the GGTT PTE updates go straight to GSMBASE (bypassing
GTTMMADR) there should be no more risk of system hangs? So the
"binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer
necessary, disable it.

My main worry with the MI_UPDATE_GTT are:
- only used on this one platform so very limited testing coverage
- async so more opprtunities to screw things up
- what happens if the engine hangs while we're waiting for MI_UPDATE_GTT
  to finish?
- requires working command submission, so even getting a working
  display now depends on a lot more extra components working correctly

TODO: MI_UPDATE_GTT might be interesting as an optimization
though, so perhaps someone should look into always using it
(assuming the GPU is alive and well)?

v2: Keep using MI_UPDATE_GTT on VM guests
v3: use i915_direct_stolen_access()

Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-6-ville.syrjala@linux.intel.com

drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access

On MTL accessing stolen memory via the BARs is somehow borked,
and it can hang the machine. As a workaround let's bypass the
BARs and just go straight to DSMBASE/GSMBASE instead.

Note that on every other platform this itself would hang the
machine, but on MTL the system firmware is expected to relax
the access permission guarding stolen memory to enable this
workaround, and thus direct CPU accesses should be fine.

The raw stolen memory areas won't be passed to VMs so we'll
need to risk using the BAR there for the initial setup. Once
command submission is up we should switch to MI_UPDATE_GTT
which at least shouldn't hang the whole machine.

v2: Don't use direct GSM/DSM access on guests
    Add w/a number
v3: Check register 0x138914 to see if pcode did its job
    Add some debug prints

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-5-ville.syrjala@linux.intel.com

drm/i915: Remove ad-hoc lmem/stolen debugs

Now that intel_memory_regions_hw_probe() prints out each and every
memory region there's no reason to have ad-hoc debugs to do similar
things elsewhere.

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-4-ville.syrjala@linux.intel.com

drm/i915: Print memory region info during probe

Dump the details about every memory region into dmesg at probe time.
Avoids having to dig those out from random places when debugging stuff.

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-3-ville.syrjala@linux.intel.com

drm/i915: Use struct resource for memory region IO as well

mem->region is a struct resource, but mem->io_start and
mem->io_size are not for whatever reason. Let's unify this
and convert the io stuff into a struct resource as well.
Should make life a little less annoying when you don't have
juggle between two different approaches all the time.

Mostly done using cocci (with manual tweaks at all the
places where we mutate io_size by hand):
@@
struct intel_memory_region *M;
expression START, SIZE;
@@
- M->io_start = START;
- M->io_size = SIZE;
+ M->io = DEFINE_RES_MEM(START, SIZE);

@@
struct intel_memory_region *M;
@@
- M->io_start
+ M->io.start

@@
struct intel_memory_region M;
@@
- M.io_start
+ M.io.start

@@
expression M;
@@
- M->io_size
+ resource_size(&M->io)

@@
expression M;
@@
- M.io_size
+ resource_size(&M.io)

Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-2-ville.syrjala@linux.intel.com

drm/i915/hdcp: Pin the hdcp gsc message high in ggtt

AFAICS there is no hardware restriction on where in ggtt
the hdcp gsc message object needs to be bound. And as it's
a regular shmem object we don't need it be in the mappabe
range either. So pin it high to make avoid needlessly
wasting the precious mappable range for it.

Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231215110933.9188-3-ville.syrjala@linux.intel.com
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

drm/i915/hdcp: Do intel_hdcp_component_init() much later during init

intel_hdcp_component_init()->...->intel_hdcp_gsc_initialize_message()
will allocate ggtt address space for some hdcp gsc message thing.
That is currently being done way too early as we haven't even
taken over the BIOS fb yet. So this has the potential of corrupting
ggtt PTEs that need to be preserved until the BIOS fb takover
is done.

Only call intel_hdcp_component_init() once all the BIOS fb takeover,
and full ggtt init (which currently also needs to reserve very
specific ranges of ggtt, thus assuming that no one else has stolen
them yet) is done.

Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231215110933.9188-2-ville.syrjala@linux.intel.com
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>

drm/i915/fbc: Allow FBC with CCS modifiers on SKL+

Only display workarounds 0391 and 0475 call for disabling
FBC with render compression, and those are listed only for
pre-prod SKL steppings. So it should be safe to enable
FB+CCS on production hardware.

AFAIK CCS is limited to 50% bandwidth reduction (perhaps
clear color can do better?). FBC can exceed that number
by quite a bit, given the right kind of framebuffer
contents. So piling on both kinds of compressions could
still make sense.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10125
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240123090244.30025-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Extract intel_atomic_swap_state()

Pull all the state swap stuff into its own function to declutter
intel_atomic_commit() a bit.

Note that currently the state swap is spread across both
sides of the unprepare branch in intel_atomic_commit(), but
we can pull all of it ahead a bit since we bail on the first
error, and thus there is no change in behaviour from the
reordering.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231219130756.25986-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Rework global state serializaiton

Instead of injecting extra crtc commits to serialize the global
state let's hand roll a bit of commit machinery to take care of
the hardware synchronization.

Rather than basing everything on the crtc commits we track these
as their own thing. I think this makes more sense as the hardware
blocks we are working with are not in any way tied to the pipes,
so the completion should not be tied in with the vblank machinery
either.

The difference to the old behaviour is that:
- we no longer pull extra crtcs into the commit which should
  make drm_atomic_check_only() happier
- since those crtcs don't get pulled in we also don't end up
  reprogamming them and thus don't need to wait their vblanks
  to pass/etc. So this should be tad faster as well.

TODO: perhaps have each global object complete its own commit
once the post-plane update phase is done?

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6728
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231219130756.25986-3-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Compute use_sagv_wm differently

drm_atomic_check_only() gets upset if we try to add extra crtcs
to any commit that isn't flagged with DRM_MODE_ATOMIC_ALLOW_MODESET.
This conflicts with how SAGV watermarks work on pre-ADL as we
need to manually switch over the SAGV watermarks before we can
safely enable SAGV.

So in order to make SAGV usage possible we need to compute each
pipe's use of SAGV watermarks as if there aren't any other
active pipes. Ie. if the current pipe isn't the one blocking
SAGV then we make it use the SAGV watermarks, even if some
other pipe prevents SAGV from actually being used. Otherwise
we could end up with a pipes using the normal watermarks (but
not blocking SAGV), and some other pipe in parallel enabling
SAGV, which would likely cause underruns.

The alternative approach of preventing SAGV usage until all
pipes simultanously end up using SAGV watermarks would only
really work if userspace always adds all pipes to every
commits, which isn't the case typically.

The downside of this is that we will end up using the less
optimal SAGV watermarks even if some other pipe prevents
SAGV from actually being enabled. In which case the system
won't achieve the minimum possible power consumption.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231219130756.25986-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915/display: Include debugfs.h in intel_display_debugfs_params.c

Commit 8015bee0bfec ("drm/i915/display: Add framework to add parameters
specific to display") added the file intel_display_debugfs_params.c,
which calls the functions "debugfs_create_{bool, ulong, str}" -- all of
which are defined in <linux/debugfs.h>. The missing inclusion of this
header file is breaking the ChromeOS build -- add an explicit include
to fix that.

Signed-off-by: Paz Zcharya <pazz@chromium.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240131204658.795278-1-pazz@chromium.org

drm/i915/xe2lpd: Move registers to PICA

Some registers for DDI A/B moved to PICA and now follow the same format
as the ones for the PORT_TC ports. The wrapper here deals with 2 issues:

- Share the implementation between xe2lpd and previous
  platforms: there are minor layout changes, it's mostly the
  register location that changed
- Handle offsets after TC ports

v2:
  - Explain better the trick to use just the second range (Matt Roper)
  - Add missing conversions after rebase (Matt Roper)
  - Use macro instead of inline function, avoiding includes in the
    header (Jani)
  - Prefix old macros with underscore so they don't get used by mistake,
    and name the new ones using the previous names
v3: Use the same logic for the recently-introduced XELPDP_PORT_MSGBUS_TIMER
    (Gustavo)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240126224638.4132016-3-lucas.demarchi@intel.com

drm/i915/xe2lpd: Move D2D enable/disable

Bits to enable/disable and check state for D2D moved from
XELPDP_PORT_BUF_CTL1 to DDI_BUF_CTL (now named DDI_CTL_DE in the spec).
Make the functions mtl_ddi_disable_d2d() and mtl_ddi_enable_d2d generic
to work with multiple reg location and bitfield layout.

v2: Set/Clear XE2LPD_DDI_BUF_D2D_LINK_ENABLE in saved_port_bits when
    enabling/disabling D2D so DDI_BUF_CTL is correctly programmed in
    other places without overriding these bits (Clint)
v3: Leave saved_port_bits alone as those bits are not meant to be
    modified outside of the port initialization. Rather propagate the
    additional bit in DDI_BUF_CTL to be set when that register is
    written again after D2D is enabled.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240126224638.4132016-2-lucas.demarchi@intel.com

drm/i915: Convert PLL flags to booleans

No real reason why the PLL flags need to be a bitmask. Switch
to booleans to make the code simpler.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240123093137.9133-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Suppress old PLL pipe_mask checks for MG/TC/TBT PLLs

TC ports have both the MG/TC and TBT PLLs selected simultanously (so
that we can switch from MG/TC to TBT as a fallback). This doesn't play
well with the state checker that assumes that the old PLL shouldn't
have the pipe in its pipe_mask anymore. Suppress that check for these
PLLs to avoid spurious WARNs when you disconnect a TC port and a
non-disabling modeset happens before actually disabling the port.

v2: Only suppress when one of the PLLs is the TBT PLL and the
    other one is not

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9816
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240123093137.9133-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Include the PLL name in the debug messages

Make the log easier to parse by including the name of the PLL
in the debug prints regarding said PLL.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240123093137.9133-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Try to preserve the current shared_dpll for fastset on type-c ports

Currently icl_compute_tc_phy_dplls() assumes that the active
PLL will be the TC PLL (as opposed to the TBT PLL). The actual
PLL will be selected during the modeset enable sequence, but
we need to put *something* into the crtc_state->shared_dpll
already during compute_config().

The downside of assuming one PLL or the other is that we'll
fail to fastset if the assumption doesn't match what was in
use previously. So let's instead keep the same PLL that was
in use previously (assuming there was one). This should allow
fastset to work again when using TBT PLL, at least in the
steady state.

Now, assuming we want keep the same PLL may not be entirely
correct either. But we should be covered by the type-c link
reset handling which will force a full modeset by flagging
connectors_changed=true which means the resulting modeset
can't be converted into a fastset even if the full crtc state
looks identical.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240118142436.25928-1-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>

Revert "drm/i915/xe2lpd: Treat cursor plane as regular plane for DDB allocation"

This reverts commit cfeff354f70bb1d0deb0279506e3f7989bc16e28.

A core design consideration with legacy cursor updates is that the
cursor must not touch any other plane, even if we were to force it
to take the slow path. That is the real reason why the cursor uses
a fixed ddb allocation, not because bspec says so.

Treating cursors as any other plane during ddb allocation
violates that, which means we can now pull other planes into
fully unsynced legacy cursor mailbox commits. That is
definitely not something we've ever considered when designing
the rest of the code. The noarm+arm register write split in
particular makes that dangerous as previous updates can get
disarmed pretty much at any random time, and not necessarily
in an order that is actually safe (eg. against ddb overlaps).

So if we were to do this then:
- someone needs to expend the appropriate amount of brain
  cells thinking through all the tricky details
- we should do it for all skl+ platforms since all
  of those have double buffered wm/ddb registers. The current
  arbitrary mtl+ cutoff doesn't really make sense

For the moment just go back to the original behaviour where
the cursor's ddb alloation does not change outside of
modeset/fastset. As of now anything else isn't safe.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-10-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Perform vblank evasion around legacy cursor updates

Our legacy cursor updates are actually mailbox updates.
Ie. the hardware latches things once per frame on start of
vblank, but we issue an number of updates per frame,
withough any attempt to synchronize against the vblank
in software. So in theory only the last update issued
during the frame will latch, and the previous ones are
discarded.

However this can lead to problems with maintaining the
ggtt/iommu mappings as we have no idea which updates
will actually latch.

The problem is exacerbated by the hardware's annoying disarming
behaviour; any non-arming register write will disarm an already
armed update, only to be rearmed later by the arming register
(CURBASE in case of cursors). If a disarming write happens
just before the start of vblank, and the arming write happens
after start of vblank we have effectively prevented the hardware
from latching anything. And if we manage to straddle multiple
sequential vblank starts in this manner we effectively prevent
the hardware from latching any new registers for an arbitrary
amount of time. This provides more time for the (potentially
still in use by the hardware) gtt/iommu mappings to be torn
down.

A partial solution, of course, is to use vblank evasion to
avoid the register writes from spreading on both sides of
the start of vblank.

I've previously highlighted this problem as a general issue
affecting mailbox updates. I even added some notes to the
{i9xx,skl}_crtc_planes_update_arm() to remind us that the noarm
and arm phases both need to pulled into the vblank evasion
critical section if we actually decided to implement mailbox
updates in general. But as I never impelemented the noarm+arm
split for cursors we don't have to worry about that for the
moment.

We've been lucky enough so far that this hasn't really caused
problems. One thing that does help is that Xorg generally
sticks to the same cursor BO. But igt seems pretty good at
hitting this on MTL now, so apparently we have to start
thinking about this.

v2: Wait for PSR exit to avoid the vblank evasion timeout (1ms)
    tripping due to PSR exit latency (~5ms typically)

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240116204927.23499-1-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Move intel_vblank_evade() & co. into intel_vblank.c

intel_vblank.c seems like the appropriate place for the core
vblank evasion code. Move it there.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-8-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Move the min/max scanline sanity check into intel_vblank_evade()

There isn't really any reason to make the caller suffer through
checking the vblank evasion min/max scanlines. If we somehow
ended up with bogus values (which really shouldn't happen)
then just skip the actual vblank evasion loop but otherwise
plow ahead as normal.

The only "real" change is that we now get+put a vblank reference
even if the min/max values are bogus, previously we skipped
directly to the end.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-7-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Extract intel_vblank_evade()

Pull the core vblank evasion loop into its own function,
so that we can reuse it elsewhere later.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-6-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Include need_vlv_dsi_wa in intel_vblank_evade_ctx

Pull the need_vlv_dsi_wa details into intel_vblank_evade_init()
so that caller doesn't have to care about it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-5-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Introduce struct intel_vblank_evade_ctx

Collect the information needed for vblank evasions into
a structure that we can pass around more easily.

And let's rename intel_crtc_vblank_evade_scanlines() to just
intel_vblank_evade_init() so that better describes the intended
usage of initializing the context.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Reorder drm_vblank_put() vs. need_vlv_dsi_wa

Drop the vblank reference only after we've done the hideous
need_vlv_dsi_wa stuff. This will make it easier to reuse the
the vblank evasion machinery elsewhere.

Keeping the vblank reference for a bit longer is not a
problem. In fact we might want to not drop it at all until
intel_pipe_update_end(), but we'll leave that idea for later.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Decouple intel_crtc_vblank_evade_scanlines() from atomic commits

We'll be needing to do vblank evasion around legacy cursor updates,
which don't have the intel_atomic_state around. So let's remove
this dependency on a full commit and pass the crtc state in by hand.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

drm/i915: Replace a memset() with zero initialization

Declaring a struct and immediately zeroing it with memset()
seems a bit silly to me. Just zero initialize the struct
when declaring it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231124082735.25470-2-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>

drm/i915/psr: Only allow PSR in LPSP mode on HSW non-ULT

On HSW non-ULT (or at least on Dell Latitude E6540) external displays
start to flicker when we enable PSR on the eDP. We observe a much higher
SR and PC6 residency than should be possible with an external display,
and indeen much higher than what we observe with eDP disabled and
only the external display enabled. Looks like the hardware is somehow
ignoring the fact that the external display is active during PSR.

I wasn't able to redproduce this on my HSW ULT machine, or BDW.
So either there's something specific about this particular laptop
(eg. some unknown firmware thing) or the issue is limited to just
non-ULT HSW systems. All known registers that could affect this
look perfectly reasonable on the affected machine.

As a workaround let's unmask the LPSP event to prevent PSR entry
except while in LPSP mode (only pipe A + eDP active). This
will prevent PSR entry entirely when multiple pipes are active.
The one slight downside is that we now also prevent PSR entry
when driving eDP with pipe B or C, but I think that's a reasonable
tradeoff to avoid having to implement a more complex workaround.

Cc: stable@vger.kernel.org
Fixes: 783d8b80871f ("drm/i915/psr: Re-enable PSR1 on hsw/bdw")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10092
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240118212131.31868-1-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Add additional ARL PCI IDs

Our existing MTL driver handling is also sufficient to handle ARL, so
these IDs are simply added to the MTL ID list.

Bspec: 55420
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240108122738.14399-2-haridhar.kalvala@intel.com

drm/i915/opregion: remove unused lid_state

Not sure if lid_state has ever been used, but at least not for a long
time. Remove it.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-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/20240117122546.1551400-1-jani.nikula@intel.com

drm/i915: Drop -Wstringop-overflow

-Wstringop-overflow is broken on GCC11. In future changes it will
be moved to the normal C flags in the top level Makefile (out of
Makefile.extrawarn), but accounting for the compiler support.

Just remove it out of i915's forced extra warnings, preparing for the
upcoming change and avoiding build warnings to show up.

Fixes: 2250c7ead8ad ("drm/i915: enable W=1 warnings by default")
References: https://lore.kernel.org/all/45ad1d0f-a10f-483e-848a-76a30252edbe@paulmck-laptop/
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240112154912.1775199-1-lucas.demarchi@intel.com

Revert "drm/i915/dsi: Do display on sequence later on icl+"

This reverts commit 88b065943cb583e890324d618e8d4b23460d51a3.

Lenovo 82TQ is unhappy if we do the display on sequence this
late. The display output shows severe corruption.

It's unclear if this is a failure on our part (perhaps
something to do with sending commands in LP mode after HS
/video mode transmission has been started? Though the backlight
on command at least seems to work) or simply that there are
some commands in the sequence that are needed to be done
earlier (eg. could be some DSC init stuff?). If the latter
then I don't think the current Windows code would work
either, but maybe this was originally tested with an older
driver, who knows.

Root causing this fully would likely require a lot of
experimentation which isn't really feasible without direct
access to the machine, so let's just accept failure and
go back to the original sequence.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10071
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240116210821.30194-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/opregion: make struct intel_opregion opaque

With the recent cleanups, only intel_opregion.c needs to know the
definition of struct intel_opregion. Allocate it dynamically and make it
opaque.

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3b68d7ff4b2930eaf15d9657618a738b9065f64b.1704992868.git.jani.nikula@intel.com

drm/i915/gvt: use local INTEL_GVT_OPREGION_SIZE

All of gvt uses INTEL_GVT_OPREGION_SIZE for opregion size. Follow suit
here.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8ae6e10fc0929934a14547a973312e82a4d7f7d1.1704992868.git.jani.nikula@intel.com

drm/i915/opregion: abstract ASLE presence check

Add a function to check the opregion ASLE presence instead of accessing
the opregion structures directly.

Reorder the checks in i915_has_asle() to avoid the function call if
possible.

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1829415d3e7b29e78c46b20bca8175ef373bcd92.1704992868.git.jani.nikula@intel.com

drm/i915/opregion: abstract getting the opregion VBT

Add a function to get the opregion VBT instead of accessing the opregion
structures directly.

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8205b8fa724f98bbf1f76c59e661909d874e843e.1704992868.git.jani.nikula@intel.com

drm/i915/opregion: move i915_opregion debugfs to intel_opregion.c

All things about opregion should be placed in intel_opregion.c.

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c10103d2dd775edc1e9f93f09d0834480f880596.1704992868.git.jani.nikula@intel.com

drm/i915/bios: move i915_vbt debugfs to intel_bios.c

All things VBT should be placed in intel_bios.c.

While at it, shove in a FIXME comment about VBT possibly originating
from other places than opregion.

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5e14a9559b6916022b506e5eb8d943783dc627a2.1704992868.git.jani.nikula@intel.com

Merge drm/drm-next into drm-intel-next

Backmerge to bring Xe driver to drm-intel-next.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

nouveau/gsp: handle engines in runl without nonstall interrupts.

It appears on TU106 GPUs (2070), that some of the nvdec engines
are in the runlist but have no valid nonstall interrupt, nouveau
didn't handle that too well.

This should let nouveau/gsp work on those.

Cc: stable@vger.kernel.org # v6.7+
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://lore.kernel.org/all/20240110011826.3996289-1-airlied@gmail.com/

drm/i915/psr: CAN_PSR and CAN_PANEL_REPLAY can be now local defines

CAN_PSR and CAN_PANEL_REPLAY are not used outside intel_psr.c anymore. Make
them as intel_psr.c local defines.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240109100517.1947414-3-jouni.hogander@intel.com

drm/i915/display: No need for full modeset due to psr

There is no specific reason to force full modeset if psr is enabled.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Reviewed-by: Stanislav Lisovskiy <staniskav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240109100517.1947414-2-jouni.hogander@intel.com

Merge tag 'drm-misc-next-fixes-2024-01-11' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

A fix for the v3d register readout, and two compilation fixes for
rockchip.

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/warlsyhbwarbezejzokxvrpnmvoaajonj6khjobvnfrhttrsks@fqoeqrjrct6l

Merge tag 'drm-intel-next-fixes-2024-01-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

- Fixes for kernel-doc warnings enforced in linux-next
- Another build warning fix for string formatting of intel_wakeref_t
- Display fixes for DP DSC BPC and C20 PLL state verification

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ZZ_IOcLiDG9LJafO@jlahtine-mobl.ger.corp.intel.com

drm/i915/perf: reconcile Excess struct member kernel-doc warnings

Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.

i915_perf_types.h:341: warning: Excess struct member 'ptr_lock' description in 'i915_perf_stream'
i915_perf_types.h:341: warning: Excess struct member 'head' description in 'i915_perf_stream'
i915_perf_types.h:341: warning: Excess struct member 'tail' description in 'i915_perf_stream'
3 warnings as Errors

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
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@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231226195432.10891-4-rdunlap@infradead.org
(cherry picked from commit aa253baca534357e033bd29b074ce1eade2a9362)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915/guc: reconcile Excess struct member kernel-doc warnings

Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.

intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_ids' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'num_guc_ids' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_ids_bitmap' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_id_list' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_ids_in_use' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'destroyed_contexts' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'destroyed_worker' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'reset_fail_worker' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'reset_fail_mask' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'sched_disable_delay_ms' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'sched_disable_gucid_threshold' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'gt_stamp' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'ping_delay' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'work' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'shift' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'last_stat_jiffies' description in 'intel_guc'
18 warnings as Errors

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
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@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231226195432.10891-3-rdunlap@infradead.org
(cherry picked from commit e4cf1a70fad3e2107503e99cfe9cc0c9cba19dad)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915/gt: reconcile Excess struct member kernel-doc warnings

Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.

intel_gsc.h:34: warning: Excess struct member 'gem_obj' description in 'intel_gsc'

Also add missing field member descriptions.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
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@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231228234946.12405-1-rdunlap@infradead.org
(cherry picked from commit cd1d91115ff1929ec346d85f512ef260ddf8131e)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915/gem: reconcile Excess struct member kernel-doc warnings

Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.

i915_gem_context_types.h:420: warning: Excess struct member 'lock' description in 'i915_gem_context'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
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@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231226195432.10891-1-rdunlap@infradead.org
(cherry picked from commit 7353c3d7c15017140a8b984e41f94be0bf535e73)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915/dp: Fix the max DSC bpc supported by source

Use correct helper for getting max DSC bpc supported by the source.

Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213091632.431557-3-ankit.k.nautiyal@intel.com
(cherry picked from commit cd7b0b2dd3d9fecc6057c07b40e8087db2f9f71a)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915: don't make assumptions about intel_wakeref_t type

intel_wakeref_t is supposed to be a mostly opaque cookie to its
users. It should only be checked for being non-zero and set to
zero. Debug logging its actual value is meaningless. Switch to just
debug logging whether the async_put_wakeref is non-zero.

The issue dates back to much earlier than
commit b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker
with ref_tracker library"), but this is the one that brought about a
build failure due to the printf format.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/r/20240102111222.2db11208@canb.auug.org.au
Fixes: b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library")
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240104164600.783371-1-jani.nikula@intel.com
(cherry picked from commit de06b42edc5bf05aefbb7e2f59475d6022ed57e1)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors

MST connectors don't have a static attached encoder, as their encoder
can change depending on the pipe they use; so the encoder for an MST
connector can't be retrieved using intel_dp_attached_encoder() (which
may return NULL for MST). Most of the PSR debugfs entries depend on a
static connector -> encoder mapping which is only true for eDP and SST
DP connectors and not for MST. These debugfs entries were enabled for
MST connectors as well recently to provide PR information for them, but
handling MST connectors needs more changes.

Fix this by not adding for now the PSR entries on MST connectors. To
make things more uniform add the entries for SST connectors on all
platforms, not just on platforms supporting DP2.0.

v2:
- Keep adding the entries for SST connectors. (Jouni)
- Add a TODO: comment for MST support.

Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel replay")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240103152609.2434100-1-imre.deak@intel.com
(cherry picked from commit 9b0b61c5bc08e1aa55a0c1e7cda28f952b2d02cc)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915/display: Fix C20 pll selection for state verification

Add pll selection check for C20 as well as
clock state verification0. We have been relying
on sw state to select A or B pll's. This is incorrect
as the hw might see this selection differently. This
patch fixes this shortcoming by reading pll selection
for both sw and hw states and compares if these two
selections match.

Fixes: 59be90248b42 ("drm/i915/mtl: C20 state verification")

v2: reword commit message and include fix to a
    original commit (Imre)
    Compare pll selection (Jani)

Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240102115741.118525-2-mika.kahola@intel.com
(cherry picked from commit f4304beadd88d074333b23fdc7f35d00ee763e14)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Merge tag 'drm-intel-gt-next-2023-12-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

Driver Changes:

- Eliminate use of kmap_atomic() in i915 (Zhao)
- Add Wa_14019877138 for DG2 (Haridhar)
- Static checker and spelling fixes (Colin, Karthik, Randy)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ZXxCibZZQqlqhDN3@jlahtine-mobl.ger.corp.intel.com

drm/v3d: Fix support for register debugging on the RPi 4

RPi 4 uses V3D 4.2, which is currently not supported by the register
definition stated at `v3d_core_reg_defs`. We should be able to support
V3D 4.2, therefore, change the maximum version of the register
definition to 42, not 41.

Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240109113126.929446-1-mcanal@igalia.com

drm/i915/psr: Disable early transport by default

Early transport validation is currently incomplete. Due to this disable the
feature by default.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-8-jouni.hogander@intel.com

drm/i915/psr: Enable psr2 early transport as possible

Check source and sink support for psr2 early transport and enable
it if not disabled by debug flag.

Bspec: 68934

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-7-jouni.hogander@intel.com

drm/i915/psr: Configure PIPE_SRCSZ_ERLY_TPT for psr2 early transport

There is a new register used to configure selective update area size
for early transport.

Configure PIPE_SRCSZ_ERLY_TPT using calculated selective update area
carried in crtc_state->su_area.

Bspec: 68927

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-6-jouni.hogander@intel.com

drm/i915/psr: Calculate and configure CUR_POS_ERLY_TPT

New register CUR_POS_ERLY_TPT related to early transport is
supposed to be configured when early transport is in use.

This register is used to configure cursor vertical postion
from beginning of selective update area.

Bspec: 68927

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-5-jouni.hogander@intel.com

drm/i915/psr: Carry su area in crtc_state

Su_area is needed when configuring CUR_POS_ERLY_TPT and
PIPE_SRC_SZ_ERLY_TPT. Store it into intel_crtc_state->psr2_su_area.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-4-jouni.hogander@intel.com

drm/i915/psr: Extend SU area to cover cursor fully if needed

In case early transport is enabled SU area needs to be extended
to cover cursor area fully when cursor is in SU area.

Bspec: 68927

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-3-jouni.hogander@intel.com

drm: Add eDP 1.5 early transport definition

Add DP_PSR_ENABLE_SU_REGION_ET to enable panel early transport.

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231218175004.52875-2-jouni.hogander@intel.com

drm/i915/dp: Fix the max DSC bpc supported by source

Use correct helper for getting max DSC bpc supported by the source.

Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213091632.431557-3-ankit.k.nautiyal@intel.com