drm/i915/wm: convert i9xx_wm.c internally to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of i9xx_wm.c to struct
intel_display.

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/bbee93f837fe7fedfd1627ff6fa295da8881df8d.1744119460.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: convert i9xx_wm.c to intel_de_*() register interface

The registers handled in i9xx_wm.c are mostly display registers. The
MCH_SSKPD and MLTR_ILK registers are not. Convert register access to
intel_de_*() interface where applicaple.

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/68367382759570413669d5648895a1da8f6c68f7.1744119460.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: convert i9xx_wm.h external interfaces to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert the i9xx_wm.h interface to struct intel_display.

With this, we can make intel_wm.c independent of i915_drv.h.

v2: Also remove i915_drv.h, fix commit message

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/3e30634d85c0e0aac9c95f9a2f928131ba400271.1744119460.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: convert skl_watermarks.c internally to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of skl_watermarks.c to struct
intel_display.

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/61ae2013c5db962e90e072be7d37d630cb7dfc34.1744119460.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: convert skl_watermark.h external interfaces to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert the skl_watermark.h interface to struct intel_display.

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/cd2b1863dee25b69b4766090dd183a7467c4edea.1744119460.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: convert intel_wm.c internally to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_wm.c to struct
intel_display.

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/6106c0313190ee904c7f7737d0b78b61983eed91.1744119460.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wm: convert intel_wm.h external interfaces to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert the intel_wm.h interface as well as the hooks in struct
intel_wm_funcs to struct intel_display.

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/1085900b4e46bbb514e6918c321639ac380331ce.1744119460.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: unify naming and simplify checks for dphy params

Unify the naming of the data and clock lane timing parameters, and
simplify their bounds checks. Drop the debug messages on out of bounds
parameters as excessive.

Clarify the comment while at it.

Cc: William Tseng <william.tseng@intel.com>
Reviewed-by: William Tseng <william.tseng@intel.com>
Tested-by: William Tseng <william.tseng@intel.com>
Link: https://lore.kernel.org/r/d1a75ae7b9d93a0b50976b5de45ba2ca798991ad.1743682608.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: separate clock and data lane prepare timing

The history of why the max of VBT clock and data lane prepare timing
parameter is used for both instead of each individually is
unknown. Separate them to follow what the Windows driver does.

Cc; William Tseng <william.tseng@intel.com>

Reviewed-by: William Tseng <william.tseng@intel.com>
Tested-by: William Tseng <william.tseng@intel.com>
Link: https://lore.kernel.org/r/079a26d0aae79f299aee0397dad2d6519cd55071.1743682608.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dp_mst: Rename intel_dp::mst.active_links to mst.active_streams

intel_dp::mst.active_links actually indicates the number of MST streams,
not the number of MST links (one MST link carrying one or more MST
streams), rename the field accordingly.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-7-imre.deak@intel.com

drm/i915/dp_mst: Use intel_dp_mst_active_streams() instead of open-coding it

Use intel_dp_mst_active_streams() everywhere, instead of open-coding it.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-6-imre.deak@intel.com

drm/i915/dp_mst: Rename intel_dp_mst_encoder_active_links() to intel_dp_mst_active_streams()

It's not clear which encoder intel_dp_mst_encoder_active_links() refers
to (primary/stream), but there is also no reason to call the queried
property an encoder property; remove encoder from the name. Also it's
the number of MST streams being queried, vs. the number of MST links
(there is one MST link carrying one or more MST streams), so rename link
to stream as well.

While at it pass intel_dp to the function, which is more logical and
makes it easier to re-use the function later (without the need to get
the digital port pointer).

Also move the function earlier, next to the related ones.

Suggested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-5-imre.deak@intel.com

drm/i915/dp_mst: Remove stream count assert from intel_dp_check_mst_status()

There doesn't seem to be a reason to assert for a non-negative stream
counter in intel_dp_check_mst_status() in particular, remove it. There
is now an equivalent assert in intel_dp_mst_dec_active_streams().

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-4-imre.deak@intel.com

drm/i915/dp_mst: Add intel_dp_mst_{inc, dec}_active_streams()

Add helpers to increment/decrement the active MST stream count, instead
of open-coding these.

In mst_stream_pre_enable(), the increment will happen earlier, this is
ok, since nothing depends on the counter between the two points.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-3-imre.deak@intel.com

drm/i915/dp: Rename intel_dp::link_trained to link.active

The intel_dp::link_trained flag indicates whether the link is active,
regardless of whether the link training passed or failed. For clarity
rename the flag to 'active'. While at it move the flag under
intel_dp::link.

Suggested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-2-imre.deak@intel.com

drm/i915/vrr: Add vrr.vsync_{start, end} in vrr_params_changed

Add the missing vrr parameters in vrr_params_changed() helper.
This ensures that changes in vrr.vsync_{start,end} trigger a call to
appropriate helpers to update the VRR registers.

Fixes: e8cd188e91bb ("drm/i915/display: Compute vrr_vsync params")
Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.10+
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250404080540.2059511-1-ankit.k.nautiyal@intel.com

drm/i915: Eliminate intel_compute_sagv_mask()

intel_compute_sagv_mask() has become pointless. Just inline
its contents into the existing loop in skl_compute_wm().

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

drm/i915: Skip bw stuff if per-crtc sagv state doesn't change

If there are no changes to intel_crtc_can_enable_sagv() there
is no need to do all the sagv bw_state recomputation.

The only slight caveat here is hw state takeover where we
initially disable SAGV, and want it to get re-enabled once
we've determined that it's safe to do so.  That can now be
achieved by having intel_crtc_can_enable_sagv() reject SAGV
as long as the crtc_state->inherited flag is set. Once the
flag gets cleared (during initial commit for inactive pipes,
during the first userspace commit for active pipes), we
will naturally recompute all the sagv related state.

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

drm/i915: Make intel_bw_modeset_checks() internal to intel_bw_atomic_check()

Now that all the sagv computation has been moved from the
skl+ watermark code into intel_bw_atomic_check() there is
no point in calling intel_bw_modeset_checks() before the
wm computation. Hide it within intel_bw_atomic_check().

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

drm/i915: Make intel_bw_check_sagv_mask() internal to intel_bw.c

The only thing between the current intel_bw_check_sagv_mask() call
site and intel_bw_atomic_check() is skl_wm_add_affected_planes()
which no longer depends on the sagv mask, so we can make life
a lot less confusing by calling intel_bw_check_sagv_mask() from
intel_bw_atomic_check() instead.

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

drm/i915: Extract intel_bw_check_sagv_mask()

Move the bw_state->pipe_sagv_reject computation into intel_bw.c
where it belongs.

Previously we had a complicated dance between watermarks and
sagv which required this to be computed earlier, but that was
changed in commit 5e8146251f7b ("extract intel_bw_check_sagv_mask()")
which allows the whole thing to be cleaned up quite a bit.

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

drm/i915: Extract intel_bw_modeset_checks()

Pull the new_bw_state->active_pipes computation out from
intel_compute_sagv_mask() and move it into the intel_bw.c
(which is arguably the correct place for it).

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

drm/i915: Drop force_check_qgv

Remove the force_check_qgv flag and just fill the pipe_sagv_reject
bitmask properly during readout. This will cause the initial commit
to re-enable SAGV if possible.

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

drm/i915: Flag even inactive crtcs as "inherited"

I want to use the crtc_state->inherited flag to clean up some
of the early SAGV handling. To make that work nicely I need to
flag even the inactive crtcs as "inherited".

Since we can't expect user space to perform any real commits
on inactive crtcs we'll clear the flag already during
initial_commit().

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

drm/i915: Do more bw readout

Update a bunch of bw related stuff during readout:
- bw_state->dbuf_bw possible now that the wm readout
  has given us access to the plane ddb data
- cdclk_state->bw_min_cdclk

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

drm/i915: Avoid triggering unwanted cdclk changes due to dbuf bandwidth changes

Currently intel_bw_calc_min_cdclk() always adds the bw_state
to the atomic state. Not only does it result in potentially
redundant work later, it's also currently causing unwanted cdclk
changes during driver load.

Check if the dbuf bw is actually changing before we decide to
pull in the bw state.

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

drm/i915: Pass intel_dbuf_bw to skl_*_calc_dbuf_bw() explicitly

Make skl_*_calc_dbuf_bw() a bit lower level passing in the
to be mutated dbuf_bw struct in explicitly. This will allow
more reuse later.

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

drm/i915: Extract intel_dbuf_bw_changed()

Extract the struct intel_dbuf_bw comparison into a small
helper. We'll get more users later.

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

drm/i915: s/intel_crtc_bw/intel_dbuf_bw/

Rename the intel_crtc_bw struct to intel_dbuf_bw to better
reflect what it does.

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

drm/i915: Drop the cached per-pipe min_cdclk[] from bw state

intel_bw_crtc_min_cdclk() only depends on the pipe data rate,
which we already have stashed in bw_state->data_rate[]. So
stashing the resulting min_cdclk[] as well is redundant. Get
rid of it.

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

drm/i915/dp: Reject HBR3 when sink doesn't support TPS4

According to the DP spec TPS4 is mandatory for HBR3. We have
however seen some broken eDP sinks that violate this and
declare support for HBR3 without TPS4 support.

At least in the case of the icl Dell XPS 13 7390 this results
in an unstable output.

Reject HBR3 when TPS4 supports is unavailable on the sink.

v2: Leave breadcrumbs in dmesg to avoid head scratching (Jani)

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

drm/i915/psr: Prevent DP Panel Replay as well when CRC is enable

We are seeing timeouts in opening CRC fd when testing on setup where DP
Panel Replay can be enabled. Fix these by checking if CRC is enabled for DP
Panel Replay as well.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250331090747.2964028-1-jouni.hogander@intel.com

drm/i915: Eliminate the initial_plane_phys_{smem,lmem}() duplication

initial_plane_phys_lmem() and initial_plane_phys_smem() are
now identical. Remove one of them.

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

drm/i915: Use intel_memory_region_type_is_local() in the BIOS FB takeover

Replace the hardcoded PTE vs. memory region is_local checks
in the BIOS FB takeover with intel_memory_region_type_is_local().

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

drm/i915: Lookup the memory region first in the BIOS FB takeover

When doing the BIOS FB takeover let's look up the appropriate
memory region first. If it doesn't exist there's not much point
in doing the PTE read/etc either.

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

drm/i915: Use a nicer way to lookup the memory region in BIOS FB takeover

Use intel_memory_region_by_type() to find the appropriate memory
region for the BIOS FB takeover.

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

drm/i915: Verify the BIOS FB first PTE on non-LMEMBAR systems

Now that we have intel_ggtt_read_entry() we can easily read out the
first PTE of the BIOS FB and verify that it looks correct. We'll
also use the extracted dma address to figure out where in stolen
the FB lives (so far we've just assumed that it sits at offset 0,
and in practice that does seem to be true, but better safe than
sorry).

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

drm/i915: Use intel_ggtt_read_entry() in the BIOS FB takeover

Use intel_ggtt_read_entry() instead of open coding the PTE
read/decode in the BIOS FB takeover code. So far this codepath
only covers platforms with LMEMBAR.

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

drm/i915/ggtt: Add intel_ggtt_read_entry()

The BIOS FB takeover code wants to read out the PTEs (or at least
one of them) to figure out where the FB is located in memory.
Currently we only do that for systems with LMEMBAR, and we've
open coded the PTE decoding in the display code. Introduce a more
proper abstract interface (intel_ggtt_read_entry()) for this purpose,
and implement it for all platforms.

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

agp/intel-gtt: Add intel_gmch_gtt_read_entry()

i915 wants to read out the PTE(s) populated by the BIOS/GOP
to verify that the framebuffer is in the correct location.
Introduce intel_gmch_gtt_read_entry() that reads out the
PTE and decodes it to a somewhat abstract form. For now
we just return the dma_addr, present bit, and local memory
bit. I didn't bother with the snoop bit/etc.

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

drm/i915: Expose intel_memory_type_str()

Rename region_type_str() into intel_memory_type_str() and
expose it outside intel_memory_region.c. I'll have another
use for this in the BIOS FB takeover code.

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

drm/i915: Extract intel_memory_type_is_local()

Extract the "is this memory region local?" check into a helper.
I'll have another use for this in the BIOS FB takeover.

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

drm/i915/gvt: use hardcoded reference clocks

Usually I'd argue hardcoding values is the wrong thing to do, but in
this case, GVT looking deep into the guts of the DPLL manager for the
reference clocks is worse. This is done for BDW and BXT only, and there
shouldn't be any reason to try to be so dynamic about it.

This helps reduce the direct pokes at display guts from non-display
code.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Link: https://lore.kernel.org/r/20250321125114.750062-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: reduce intel_wakeref.h dependencies

Forward declare struct drm_printer instead of including drm/drm_print.h,
as we only need the pointer. Turns out quite a few places depend on this
include implicitly. Make them explicit.

Some of the includes are just stale and unnecessary. Group the forward
declarations together while at it.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250326115452.2090275-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/gvt: update MAINTAINERS

Update GVT-g MAINTAINERS entry to reflect the current status of
maintenance and repositories.

Cc: Dave Airlie <airlied@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Simona Vetter <simona.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Cc: Zhenyu Wang <zhenyuw.linux@gmail.com>
Cc: Zhi Wang <zhi.wang.linux@gmail.com>
Acked-by: Zhi Wang <zhi.wang.linux@gmail.com>
Acked-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://lore.kernel.org/r/20250227093805.2217658-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/gvt: fix unterminated-string-initialization warning

Initializing const char opregion_signature[16] = OPREGION_SIGNATURE
(which is "IntelGraphicsMem") drops the NUL termination of the
string. This is intentional, but the compiler doesn't know this.

Switch to initializing header->signature directly from the string
litaral, with sizeof destination rather than source. We don't treat the
signature as a string other than for initialization; it's really just a
blob of binary data.

Add a static assert for good measure to cross-check the sizes.

Reported-by: Kees Cook <kees@kernel.org>
Closes: https://lore.kernel.org/r/20250310222355.work.417-kees@kernel.org
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13934
Tested-by: Nicolas Chauvet <kwizart@gmail.com>
Tested-by: Damian Tometzki <damian@riscv-rocks.de>
Cc: stable@vger.kernel.org
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Link: https://lore.kernel.org/r/20250327124739.2609656-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dram: Consolidate logging of DRAM type

Instead of logging the dram type in the per version/platform function,
do it in the generic one. This fixes a few discrepancies depending on
the platform:

- There was no DRAM type logging for graphics version 12 and
  above
- For graphics version 11, it would log the DRAM type in
  skl_get_dram_info(), but could possibly override it later
  without any log in icl_pcode_read_mem_global_info()

For bxt_get_dram_info(), there's no need to log the type for each dimm,
as the drm_WARN_ON() already covers the case they are not all the same.

This maintains the behavior of skl_get_dram_info() that would log the
DRAM type even on failures.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20250324-dram-type-v1-2-bf60ef33ac01@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

drm/i915/dram: Add missing INTEL_DRAM str conversions

Some new dram types were added without adding the corresponding string
conversion, probably because it's not being used by recent platforms.
Add them, together with a BUILD_BUG_ON() to ensure it keeps in sync, in
preparation to make use of them in recent platforms.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20250324-dram-type-v1-1-bf60ef33ac01@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

drm/i915/display: Fix htmldocs build

Fixes a wrong documentation block indentation:

Documentation/gpu/i915:141: ./drivers/gpu/drm/i915/display/intel_hotplug.c:1080: ERROR: Unexpected indentation.
Documentation/gpu/i915:141: ./drivers/gpu/drm/i915/display/intel_hotplug.c:1082: WARNING: Block quote ends without a blank line; unexpected unindent.

v2: Use an empty line instead of changing block indentation (Imre)

Fixes: 0d77a3e0ea90 ("drm/i915/hpd: Add support for blocking the IRQ handling on an HPD pin")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/intel-gfx/20250312232506.47451f83@canb.auug.org.au/
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250328180829.25892-1-rodrigo.vivi@intel.com
Link: https://lore.kernel.org/r/20250328193202.40884-1-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/display: implement wa_18038517565

Disable FBC compressor clock gating before enabling FBC and
clear it after disabling FBC.

v2: update the DG2 registers for this wa

v3: use local variable and single line reg definition (Jani)

Bspec: 74212, 72197, 69741, 65555
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20250330172616.718188-1-vinod.govindapillai@intel.com

drm/i915/psr: Add PSR pause/resume reference count

We have now seen this:

<4> [2120.434153] i915 0000:00:02.0: [drm] drm_WARN_ON(psr->paused)
<4> [2120.434196] WARNING: CPU: 3 PID: 4430 at drivers/gpu/drm/i915/display/intel_psr.c:2227 intel_psr_pause+0x16e/0x180 [i915]

Comment for drm_WARN_ON(display->drm, psr->paused) in intel_psr_pause says:

"If we ever hit this, we will need to add refcount to pause/resume"

This patch is implementing PSR pause/resume refcount.

v3: Incorporate changes missing from v2
v2: Add drm_warn for detecting possible unbalanced pause/resume

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://lore.kernel.org/r/20250328080623.1183669-1-jouni.hogander@intel.com

drm/i915/display: Avoid use of VTOTAL.Vtotal bits

For platforms that always use VRR Timing Generator, the VTOTAL.Vtotal
bits are not required. Since the support for these bits is going to
be deprecated in upcoming platforms, avoid writing these bits for the
platforms that do not use legacy Timing Generator.

Since for these platforms vrr.vmin is always filled with crtc_vtotal,
use TRAN_VRR_VMIN to get the vtotal for adjusted_mode.

v2: Avoid having a helper for manipulating VTOTAL register, and instead
just make the change where required. (Ville)
v3: Set crtc_vtotal instead of working with the bits directly (Ville).
Use intel_vrr_vmin_vtotal() to set the vtotal during readout. (Ville)
v4: Keep the reading part unchanged, and let it get overwritten for
cases where we use vrr.vmin. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250327144629.648306-3-ankit.k.nautiyal@intel.com

drm/i915/display: Introduce transcoder_has_vrr() helper

Introduce a new helper to check transcoder_has_vrr() and use
that to exclude transcoders which do not support VRR.

v2: Include HAS_VRR into the helper. (Ville)
v3: Drop the usage in places where not applicable. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250327144629.648306-2-ankit.k.nautiyal@intel.com

drm/i915/display: drop some unnecessary intel_de_* compatibility wrappers

intel_de_wait_for_set(), intel_de_wait_for_clear(), intel_de_read_fw(),
and intel_de_write_fw() are only passed struct intel_display. Remove the
unnecessary compatibility wrappers.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/35589d84ee7996f8972ddb3ebc1aae1b53077b19.1742906146.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/wa: convert intel_display_wa.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_display_wa.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/821937f9fcdcb7d5516be0c48c2cee009936ecb8.1742906146.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/psr: further conversions to struct intel_display

intel_psr.c still uses the old platform identification macros. Convert
them and some other stragglers to struct intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/7d032bd621a56536b4d53c5c415cad624e5dc628.1742906146.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/crc: convert intel_pipe_crc.c to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_pipe_crc.c to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/9bb18395d57d5353535e0d385119366821162a86.1742906146.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/ddi: convert intel_ddi.c to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_ddi.c to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/44aebcf93b2211e917b2ee725433b1f9b5e4e6f6.1742906146.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpll: convert intel_dpll.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_dpll.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/16fe331ba51c269d6f9871d7b0a3b8df3c7b5342.1742906146.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: let HW maintain the HS-TRAIL timing

This change is to avoid over-specification of the TEOT timing
parameter, which is derived from software in current design.

Supposed that THS-TRAIL and THS-EXIT have the minimum values,
i.e., 60 and 100 in ns. If SW is overriding the HW default,
the TEOT value becomes 150 ns, approximately calculated by
the following formula.

  DIV_ROUND_UP(60/50)*50 + DIV_ROUND_UP(100/50))*50/2, where 50
  is LP Escape Clock time in ns.

The TEOT value 150 ns is larger than the maximum value,
around 136 ns if UI is 1.8ns, (105 ns + 12*UI, defined by MIPI
DPHY specification).

However, the TEOT value will meet the specification if THS-TRAIL
is set to the HW default, instead of software overriding.

The timing change is made for both data lane and clock lane.

v1: initial version.
v2: change clock lane dphy timings.
v3: remove calculation of trail cnt.
v4: rebase.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13891
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: William Tseng <william.tseng@intel.com>
Acked-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://lore.kernel.org/r/20250311100626.533888-1-william.tseng@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Move intel_disable_shared_dpll() into ilk_pch_post_disable()

On ILK-IVB only PCH outputs use shared dplls. Move the relevant
intel_disable_shared_dpll() into ilk_pch_post_disable() to make
that clear (and if we extend the dpll mgr to cover all plls we need
different enable/disable points anyway for the PCH vs. CPU eDP cases).
The intel_enable_shared_dpll() counterpart was already in
ilk_pch_enable() anyway, so this is the more symmetric place for the
disable as well.

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

drm/i915: Enable/disable shared dplls just the once for joined pipes

Currently we loop over all joined pipes and enable/disable the
shared dplls for each. We don't really have to do that since
all joined pipes will be using the same dpll. So let's just do
the enable/disable once for the whole set of joined pipes.
We can still keep tracking the dpll active set as pipes as long
as we remember to flip the bits for all the joined pipes on one go.

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

drm/i915/vrr: Set trans_vrr_ctl in intel_vrr_set_transcoder_timings()

We now always set vrr.flipline, vmin, and vmax for all platforms that
support VRR. Therefore, we should set all TRANS_VRR_CTL bits except
VRR_ENABLE. Without this, the readback for these bits will fail because we
only read vrr.flipline, vmin, and vmax if TRANS_VRR_CTL has the
FLIPLINE_EN bit set.

For platforms that always have the VRR Timing Generator enabled,
the FLIPLINE_EN bit is always set in TRANS_VRR_CTL during
intel_transcoder_vrr_enable(). However, for the remaining platforms
(that do not always have the VRR Timing Generator enabled) if a full
modeset doesn't occur and VRR is not enabled, the bit is not set.

This results in a mismatch between the software state and hardware state
because the software state expects VRR timings like flipline, vmin, and
vmax to be set, but the readout for these doesn't happen since the
FLIPLINE_EN bit is not set in TRANS_VRR_CTL.

To avoid this mismatch, write trans_vrr_ctl in
intel_vrr_set_transcoder_timings() even when VRR is not enabled
for platforms that do not have the VRR Timing Generator always enabled.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-15-ankit.k.nautiyal@intel.com

drm/i915/vrr: Always use VRR timing generator for PTL+

Currently, the VRR timing generator is used only when VRR is enabled by
userspace for sinks that support VRR. Starting with PTL+, gradually move
away from the legacy timing generator and use the VRR timing generator
for both variable and fixed timings.

Note: For platforms where we always enable the VRR timing generator,
the LRR fastset is not allowed to avoid live programming of vrr.guardband
with VRR TG enabled. This effectively breaks the LRR fastset functionality
for these platforms and needs to be addressed.

v2: Use this for PTL for now to avoid losing LRR fastset for older
platforms. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-14-ankit.k.nautiyal@intel.com

drm/i915/vrr: Allow fixed_rr with pipe joiner

VRR with joiner is currently disabled as it still needs some work to
correctly sequence the primary and secondary transcoders. However, we can
still use VRR Timing generator in fixed refresh rate for joiner and since
it just need to program vrr timings once and does not involve changing
timings on the fly. We still need to skip the VRR and LRR for joiner.

To achieve this set vrr.in_range to 0 for joiner case, so that we do not
try VRR and LRR for the joiner case.

v2: Avoid checks for secondary pipes, where not required. (Ville)
v3: Remove a redundant check and reset vrr.in_range to false. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-13-ankit.k.nautiyal@intel.com

drm/i915/display: Move vrr.guardband/pipeline_full out of !fastset block

Since the vrr.guardband can now change for platforms that always use the
VRR Timing Generator, and it is unsafe to reprogram the guardband on the
fly, move the guardband and pipeline_full checks from the pure !fastboot
path and add a check for intel_vrr_always_use_vrr_tg().

For older platforms the vrr.guardband change happens when VRR Timing
generator is off. For the platforms that always use the VRR Timing
Generator, this will prevent reprogramming the vrr.guardband without a
full modeset. However, this will disrupt LRR functionality for these
platforms.

v2: Modify the check to avoid breaking the LRR on older platform.
(Ville)
v3: Correct the oversight of not removing the lines from the original
location. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-12-ankit.k.nautiyal@intel.com

drm/i915/display: Use fixed rr timings in intel_set_transcoder_timings_lrr()

Update the intel_set_transcoder_timings_lrr() function to use
fixed refresh rate timings.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-11-ankit.k.nautiyal@intel.com

drm/i915/vrr: Use fixed timings for platforms that support VRR

For fixed refresh rate use fixed timings for all platforms that support
VRR. For this add checks to avoid computing and reading VRR for
platforms that do not support VRR.

v2: Avoid touching check for VRR_CTL_FLIP_LINE_EN. (Ville)
v3: Avoid redundant statements in vrr_{compute/get}_config. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-10-ankit.k.nautiyal@intel.com

drm/i915/display: Use fixed_rr timings in modeset sequence

During modeset enable sequence, program the fixed timings, and turn on the
VRR Timing Generator (VRR TG) for platforms that always use VRR TG.

For this intel_vrr_set_transcoder now always programs fixed timings.
Later if vrr timings are required, vrr_enable() will switch
to the real VRR timings.

For platforms that will always use VRR TG, the VRR_CTL Enable bit is set
and reset in the transcoder enable/disable path.

v2: Update intel_vrr_set_transcoder_timings for fixed_rr.
v3: Update intel_set_transcoder_timings_lrr for fixed_rr. (Ville)
v4: Have separate functions to enable/disable VRR CTL
v5:
-For platforms that do not always have VRRTG on, do write bits other
than enable bit and also use write the TRANS_VRR_PUSH register. (Ville)
-Avoid writing trans_ctl_vrr if !vrr_possible().
v6:
-Disable VRR just before intel_ddi_disable_transcoder_func(). (Ville)
-Correct the sequence of configuring PUSH and VRR Enable/Disable. (Ville)
v7: Reset trans_vrr_ctl to 0 unconditionally in
intel_vrr_transcoder_disable(). (Ville)
v8: Reset trans_vrr_ctl if flipline is not set. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-9-ankit.k.nautiyal@intel.com

drm/i915/vrr: Set vrr.enable for VRR TG with fixed_rr

For platforms that enable VRR TG only for variable timings, the
VRR_CTL.VRR_ENABLE bit indicates VRR is active. For platforms that
always have VRR TG enabled, the VRR_CTL.VRR_ENABLE bit indicates VRR
is active only when not in fixed refresh rate mode.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-8-ankit.k.nautiyal@intel.com

drm/i915/vrr: Always set vrr vmax/vmin/flipline in vrr_{enable/disable}

For platforms for which vrr timing generator is always set, VRR_CTL
enable bit does not need to toggle, so modify the vrr_{enable/disable}
for this.
At the moment the helper intel_vrr_always_use_vrr_tg() return false for
all cases. This will be set later when all other bits are in place.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-7-ankit.k.nautiyal@intel.com

drm/i915/vrr: Refactor condition for computing vmax and LRR

LRR and Vmax can be computed only if VRR is supported and vrr.in_range
is set. Currently we proceed with vrr timings only for VRR supporting
panels and return otherwise. For using VRR TG with fix timings, need to
continue even for panels that do not support VRR.

To achieve this, refactor the condition for computing vmax and
update_lrr so that we can continue for fixed timings for panels that do
not support VRR.

v2: Set vmax = vmin for non VRR panels. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-6-ankit.k.nautiyal@intel.com

drm/i915/display: Move intel_psr_post_plane_update() at the later

In intel_post_plane_update() there are things which might need to do
vblank waits, so enabling PSR as early as we do now is simply
counter-productive. Therefore move intel_psr_post_plane_update() at the
last of intel_post_plane_update().

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-5-ankit.k.nautiyal@intel.com

drm/i915/display: Disable PSR before disabling VRR

As per bspec 49268: Disable PSR before disabling VRR.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-4-ankit.k.nautiyal@intel.com

drm/i915/dp_mst: Use VRR Timing generator for DP MST for fixed_rr

Currently the variable timings are supported only for DP and eDP and not
for DP MST. Call intel_vrr_compute_config() for MST which will configure
fixed refresh rate timings irrespective of whether VRR is supported or
not. Since vrr_capable still doesn't have support for DP MST this will be
just treated as non VRR case and vrr.vmin/vmax/flipline will be all set
to adjusted_mode->crtc_vtotal.

This will help to move away from the legacy timing generator and
always use VRR timing generator by default.

With this change, we need to exclude MST in intel_vrr_is_capable for
now, to avoid having LRR with MST.

v2: Exclude MST in intel_vrr_is_capable() for now. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250324133248.4071909-3-ankit.k.nautiyal@intel.com

drm/i915/hdmi: Use VRR Timing generator for HDMI for fixed_rr

Currently VRR is not supported with HDMI, but we can still leverage
the VRR Timing Generator to achieve a fixed refresh rate.
Call intel_vrr_compute_config() for HDMI which will handle the vrr
timings to have fixed refresh rate with VRR Timing Generator.

v2: Improve commit message. (Ville).

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> (#v1)
Link: https://lore.kernel.org/r/20250324133248.4071909-2-ankit.k.nautiyal@intel.com

drm/i915/gvt: Stop using intel_runtime_pm_put_unchecked()

intel_runtime_pm_put_unchecked() is not meant to be used
outside the runtime pm implementation, so don't.

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

drm/i915: Replace the HAS_DDI() in intel_crtc_scanline_offset() with specific platform checks

The HDMI vs. not scanline offset stuff no longer applies to the
latest platforms, so using HAS_DDI() is a bit confusing. Replace
with a more specific set of conditions.

Also let's just deal with the platform types in the if ladder
itself, and handle the HDMI vs. not within the specific branch
for those platforms.

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

drm/i915: Reverse the scanline_offset if ladder

Make intel_crtc_scanline_offset() a bit less confusing by
fully reordering the if ladder to use the new->old platform
order.

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

drm/i915: Fix scanline_offset for LNL+ and BMG+

Turns out LNL+ and BMG+ no longer have the weird extra scanline
offset for HDMI outputs. Fix intel_crtc_scanline_offset()
accordingly so that scanline evasion/etc. works correctly on
HDMI outputs on these new platforms.

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

drm/i915/dp_mst: Fix side-band message timeouts due to long PPS delays

The Panel Power Sequencer lock held on an eDP port (a) blocks a DP AUX
transfer on another port (b), since the PPS lock is device global, thus
shared by all ports. The PPS lock can be held on port (a) for a longer
period due to the various PPS delays (panel/backlight on/off,
power-cycle delays). This in turn can cause an MST down-message request
on port (b) time out, if the above PPS delay defers the handling of the
reply to the request by more than 100ms: the MST branch device sending
the reply (signaling this via the DP_DOWN_REP_MSG_RDY flag in the
DP_DEVICE_SERVICE_IRQ_VECTOR DPCD register) may cancel the reply
(clearing DP_DOWN_REP_MSG_RDY and the reply message buffer) after 110
ms, if the reply is not processed by that time.

Avoid MST down-message timeouts described above, by locking the PPS
state for AUX transfers only if this is actually required: on eDP ports,
where the VDD power depends on the PPS state and on all DP and eDP ports
on VLV/CHV, where the PPS is a pipe instance and hence a modeset on any
port possibly affecting the PPS state.

v2: Don't move PPS locking/VDD enabling to a separate function. (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250324180145.142884-3-imre.deak@intel.com

drm/i915/pps: Let calling intel_pps_vdd_{on, off}_unlocked() w/o PPS lock held

After a follow-up change on non-eDP outputs
intel_pps_vdd_{on,off}_unlocked() can be called without the PPS lock
held, allow for this.

Suggested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250324180145.142884-2-imre.deak@intel.com

drm/i915/pch: convert intel_pch_refclk.c to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_pch_refclk.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/1bf35f05dc921e0ca548b0d0d8d7f5b7098e8140.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/pch: convert intel_pch_display.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_pch_display.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/0341f0c14a4770cfd41708200cd6c5416b8a17b9.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: convert intel_crtc_state_dump.c to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert intel_crtc_state_dump.c to struct intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/b0d7c61f40e26e8d74de2217963d333fe8c304c4.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/atomic: convert intel_atomic.c to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert intel_atomic.c to struct intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/7ef6fe795e4e5c26ae0d546e57f64f494aaf56fc.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/tc: convert intel_tc.c to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert intel_tc.c to struct intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/bbff21269f348ac72eb749b6cf3f692234bed9f2.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/lvds: convert intel_lvds.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_lvds.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/2b5205db60f956dba788cc894531cc74d0dd853d.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dvo: convert intel_dvo.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert intel_dvo.[ch] to struct intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/a78b5c8d0030957523eb467401b06e2d290cf14d.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: convert intel_dsi_dcs_backlight.c to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert intel_dsi_dcs_backlight.c to struct intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/19ed78f51ac153016fbe60c49037bef840a9cc1b.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: convert intel_dsi_vbt.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_dsi_vbt.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/d2a327c7121263cd67986a2d9199e18d7bf03acd.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: convert parameter printing to drm_printer

The DSI VBT initialization debug logs a lot of parameters. Convert this
to use struct drm_printer with a prefix.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/50ff85e66c058a12b2fe0d0cba6a542f7cfa71cf.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: convert vlv_dsi_pll.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of vlv_dsi_pll.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/9d34d8b91c6bc8b2dd8e2081194ee496b251bbf3.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of vlv_dsi.[ch] to struct
intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/320449f3b58c6eca6fdbb16e4e819cd0e133887a.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: Read panel replay source status through PSR2 status register

PTL onwards get panel replay status from PSR2 status register
instead of SRD status.

Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324100823.3111564-1-animesh.manna@intel.com

drm/i915/xe2hpd: Identify the memory type for SKUs with GDDR + ECC

Some SKUs of Xe2_HPD platforms (such as BMG) have GDDR memory type
with ECC enabled. We need to identify this scenario and add a new
case in xelpdp_get_dram_info() to handle it. In addition, the
derating value needs to be adjusted accordingly to compensate for
the limited bandwidth.

Bspec: 64602
Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 3adcf970dc7e ("drm/xe/bmg: Drop force_probe requirement")
Cc: stable@vger.kernel.org
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324-tip-v2-1-38397de319f8@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

drm/i915/fbc: update the panel_replay dependency in fbc wa's

There are two panel_replay scenarios fbc wa need to be aware of,
panel replay with and without selective update capability.
Panel replay without selective update don't have any fbc wa.
So keep the fbc psr1 wa as it is.

The current fbc psr2 wa is mainly about selective fetch and we
need to apply the fbc wa if selective fetch is on - irrespective
of panel replay. Hence we can't exclude panel replay from the
fbc psr2 wa.

v1: keep panel_replay exclusion in PSR1 case (Jouni)
    Patch description updated

Bspec: 66624, 50442
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321094529.197397-3-vinod.govindapillai@intel.com

drm/i915/fbc: keep FBC disabled if selective update is on in xe2lpd

FBC was disabled in case PSR2 selective update in display 12 to
14 as part of a wa. From xe2lpd onwards there is a logic to be
implemented to decide between FBC and selective update. Until
that logic is implemented keep FBC disabled in case selective
update is enabled.

v1: updated patch description and some explanation and todo

Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321094529.197397-2-vinod.govindapillai@intel.com

drm/i915/dmc: Create debugfs entry for dc6 counter

Starting from MTL we don't have a platform agnostic way to validate
DC6 state due to dc6 counter has been removed to validate DC state.

The goal is to validate that the display HW can reach the DC6 power
state. There is no HW DC6 residency counter (and there wasn't such
a counter earlier either), so an alternative way is required. According
to the HW team the display driver has programmed everything correctly in
order to allow the DC6 power state if the DC5 power state is reached
(indicated by the HW DC5 residency counter incrementing) and DC6 is
enabled by the driver.

Driver could take a snapshot of the DC5 residency counter right
after it enables DC6 (dc5_residency_start) and increment the SW
DC6 residency counter right before it disables DC6 or when user space
reads the DC6 counter. So the driver would update the counter at these
two points in the following way:
dc6_residency_counter += dc5_current_count - dc5_start_count

v2: Update the discription. (Imre)
    Read dc5 count during dc6 enable and disable then and update
    dc6 residency counter. (Imre)
    Remove variable from dmc structure. (Jani)
    Updated the subject title.
v3: Add i915_power_domains lock to updated dc6 count in debugfs. (Imre)
    Use flags to check dc6 enable/disable states. (Imre)
    Move the display version check and counter read/update to
    a helper. (Imre)
    Resize the variable length. (Rodrigo)
    Use old dc6 debugfs entry for every platform. (Rodrigo)
v4: Remove superfluous whitespace. (Jani)
    Read DMC registers in intel_dmc.c (Jani)
    Rename dc6_en_dis to dc6_enabled and change its type to bool. (Jani)
    Rename update_dc6_count and move it to intel_dmc.c (Jani)
    Rename dc6_en_dis to start_tracking. (Imre)
    Have lock for dc6 state read aswelll. (Imre)
    Keep the existing way print 'DC5 -> DC6 count' along with
    new 'DC6 Allowed Count' print. (Imre)
    Add counters in intel_dmc struct. (Imre)
    Have interface to return dc6 allowed count. (Imre)
    Rename dc6_count to dc6_allowed_count. (Rodrigo)
v5: Rename counters and move in to dc6_allowed structure. (Imre)
    Order declaration lines in decreasing line length. (Imre)
    Update start_tacking logic. (Imre)
    Move get couner inside lock and DISPLAY_VER code to helper. (Imre)
v6: Change intel_dmc_get_dc6_allowed_count return type to bool. (Imre)
    Update debugfs print to better allien with old print. (Imre)
    Remove braces at if/else for signle line statements. (Imre)
v7: Remove in line variable declaration. (Imre)
v8: Rebase the changes.

Signed-off-by: Mohammed Thasleem <mohammed.thasleem@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321123707.287745-1-mohammed.thasleem@intel.com

drm/i915/vrr: Avoid reading vrr.enable based on fixed_rr check

Currently, vrr.enable is intended only for variable refresh rate timings.
At this point, we do not set fixed refresh rate timings, but the GOP can,
which creates a problem during the readback of vrr.enable.

The GOP enables the VRR timing generator with fixed timings, while the
driver only recognizes the VRR timing generator as enabled with
variable timings. This discrepancy causes an issue due to the
fixed refresh rate check during readback. Since the VRR timing generator
is enabled and we do not support fixed timings, the readback should set
vrr.enable so that the driver can disable the VRR timing generator.
However, the current check does not allow this.

Therefore, remove the fixed refresh rate check during readback.

Fixes: 27217f9d1856 ("drm/i915/vrr: Track vrr.enable only for variable timing")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250322044345.3827137-3-ankit.k.nautiyal@intel.com