drm/i915: Extract link_nv12_planes()

Pull the code linking the UV and Y planes together into a
sensible function instead of having the code plastered inside
the higher level loop.

v2: Rebase due to intel_display changes

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-8-ville.syrjala@linux.intel.com

drm/i915: Remove pointless visible check in unlink_nv12_plane()

visible can't be true when is_y_plane is true. Replace the
bogus check with an WARN_ON(). Flatten the function while
at it.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-7-ville.syrjala@linux.intel.com

drm/i915: Extract unlink_nv12_plane()

Pull the details of the nv12 plane unlinking to a small
function to make the higher level code less messy.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-6-ville.syrjala@linux.intel.com

drm/i915: s/planar_slave/is_y_plane/

Bspec talks about Y planes, not planar slaves. Switch to using the
same terminology to make life a bit less confusing.

v2: Adjust some comments too (Maarten)

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-5-ville.syrjala@linux.intel.com

drm/i915: Rework joiner and Y plane dependency handling

The current code tries to handle joiner vs. Y planes completely
independently. That does not really work since each pipe selects
its Y planes completely independently, and any plane pulled into
the state by one of the secondary pipes needs to have the plane
on the primary pipe also included in the state (for the uapi
state copy). The current code sometimes forgets to pull in planes
that we need, leading to weird things like the Y<->UV plane link
only getting torn down from one side but not the other.

Remedy the situation by pulling in the exact same set planes
on all the joined pipes. To calculate the set we simply
look through each joined crtc and any plane in the state gets
added to the set. However due to the way the Y plane selection
works we may not be able to determine the set in one go. One
plane on one pipe may pull in a Y plane, which may have to pull
in another plane because it's not acting in the same role on
another pipe, etc. The simple approach taken here is to keep
looping and adding planes to the set until it stops growing.

I suppose if we tracked more of this Y plane stuff in the
crtc state rather than the plane state we might be able to
do it in one go. But this works, and it's not going to loop
for long anyway since we only have so many pipes and Y planes
to consider.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-4-ville.syrjala@linux.intel.com

Revert "drm/i915: Fix NULL ptr deref by checking new_crtc_state"

This reverts commit 1d5b09f8daf859247a1ea65b0d732a24d88980d8.

Now that the root cause the missing crtc state has been fixed
we can get rid of the duct tape.

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-3-ville.syrjala@linux.intel.com

drm/i915: Make sure all planes in use by the joiner have their crtc included

Any active plane needs to have its crtc included in the atomic
state. For planes enabled via uapi that is all handler in the core.
But when we use a plane for joiner the uapi code things the plane
is disabled and therefore doesn't have a crtc. So we need to pull
those in by hand. We do it first thing in
intel_joiner_add_affected_crtcs() so that any newly added crtc will
subsequently pull in all of its joined crtcs as well.

The symptoms from failing to do this are:
- duct tape in the form of commit 1d5b09f8daf8 ("drm/i915: Fix NULL
  ptr deref by checking new_crtc_state")
- the plane's hw state will get overwritten by the disabled
  uapi state if it can't find the uapi counterpart plane in
  the atomic state from where it should copy the correct state

Cc: stable@vger.kernel.org
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212164330.16891-2-ville.syrjala@linux.intel.com

drm/i915/ddi: Sanitize DDI_BUF_CTL register definitions

Align the DDI_BUF_CTL register flag definitions with how this is done
elsewhere.

v2: Robustify macro calls with parens. (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-12-imre.deak@intel.com

drm/i915/ddi: Add a helper to enable a port

Add a helper to enable a port instead of open-coding it.

While at it rename intel_disable_ddi_buf() to intel_ddi_buf_disable()
for consistency.

v2: (Jani)
- s/intel_enable_ddi_buf/intel_ddi_buf_enable
- s/intel_disable_ddi_buf/intel_ddi_buf_disable

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-11-imre.deak@intel.com

drm/i915/ddi: Unify the platform specific functions disabling a port

The functions disabling a port for MTL+ and earlier platforms only
differ by an extra step on MTL+ (to disable the D2D link) and the point
at which the port's idle state is waited for. Combine the two functions
accounting for the above differences, removing the duplication.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-10-imre.deak@intel.com

drm/i915/ddi: Move platform checks within mtl_ddi_enable/disable_d2d_link()

The prefix of the mtl_ddi_enable_d2d() / mtl_ddi_disable_d2d_link()
names show already what are the relevant platforms, so the corresponding
platform check is a detail that can be hidden in the functions, do so.

While at it rename mtl_ddi_disable_d2d_link() to mtl_ddi_disable_d2d()
for symmetry with mtl_ddi_enable_d2d().

v2: s/mtl_ddi_disable_d2d_link/mtl_ddi_disable_d2d (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-9-imre.deak@intel.com

drm/i915/ddi: Simplify waiting for a port to get active/idle via DDI_BUF_CTL

When waiting for a port to get active/idle there is no point in the
complexity of specifying an exact timeout and for that the suitable wait
API instead of just using the maximum timeout. The sequence in
particular is not performance critical at all either and due to
scheduling it's not guaranteed anyhow how long the wait will last at the
given timescale. In the usual case where the wait succeeds the actual
time waited does not change with the increased timeout.

Simplify things accordingly, describing the bspec platform specific
timeouts in code comments.

v2: Clarify the rationale in the commit log. (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-8-imre.deak@intel.com

drm/i915/ddi: Simplify the port disabling via DDI_BUF_CTL

A port can be disabled only via a modeset (or during HW state
sanitization) when the port is enabled. Thus it's not required to check
the port's enabled state before disabling it. In any case if the port
happened to be disabled, the following disabling would be just a nop and
waiting for the buffer's idle state should succeed. Simplify the
disabling sequence accordingly.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-7-imre.deak@intel.com

drm/i915/ddi: Simplify the port enabling via DDI_BUF_CTL

In the past intel_digital_port::dp.prepare_link_retrain() could be
called directly (vs. from a modeset) to retrain an enabled link. In that
case the port had to be first disabled and then re-enabled. That changed
with commit 2885d283cce5 ("drm/i915/dp: Retrain SST links via a modeset
commit"), after which the only way prepare_link_retrain() can be called
is from a modeset during link training when the port is still disabled.
Simplify things accordingly, assuming the disabled port state.

v2: Don't use drm_i915_private in intel_ddi_prepare_link_retrain(). (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-6-imre.deak@intel.com

drm/i915/ddi: Set missing TC DP PHY lane stagger delay in DDI_BUF_CTL

Add the missing PHY lane stagger delay programming for ICL-ADL
platforms on TypeC DP outputs.

v2: (Jani)
- Clarify code comment about lane stagger programming.
- Robustify macro calls with parens.

Bspec: 7534, 49533
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-5-imre.deak@intel.com

drm/i915/ddi: Make all the PORT_WIDTH macros work the same way

Make the PORT_WIDTH macro of the XELPDP_PORT_CTL1 register work the same
way as those used for the DDI_BUF_CTL and the TRANS_DDI_FUNC_CTL
registers: accept a width parameter and convert it to the given
register's encoding.

v2: Robustify macro calls with parens. (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-4-imre.deak@intel.com

drm/i915/ddi: Fix HDMI port width programming in DDI_BUF_CTL

Fix the port width programming in the DDI_BUF_CTL register on MTLP+,
where this had an off-by-one error.

Cc: <stable@vger.kernel.org> # v6.5+
Fixes: b66a8abaa48a ("drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-3-imre.deak@intel.com

drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro

The format of the port width field in the DDI_BUF_CTL and the
TRANS_DDI_FUNC_CTL registers are different starting with MTL, where the
x3 lane mode for HDMI FRL has a different encoding in the two registers.
To account for this use the TRANS_DDI_FUNC_CTL's own port width macro.

Cc: <stable@vger.kernel.org> # v6.5+
Fixes: b66a8abaa48a ("drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-2-imre.deak@intel.com

drm/i915/psr: Allow DSB usage when PSR is enabled

Now as we have correct PSR2_MAN_TRK_CTL handling in place we can allow DSB
usage also when PSR is enabled for LunarLake onwards.

v2: rebase

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

drm/i915/display: Ensure we have "Frame Change" event in DSB commit

We may have commit which doesn't have any non-arming plane register
writes. In that case there aren't "Frame Change" event before DSB vblank
evasion which hangs as PIPEDSL register is reading as 0 when PSR state is
SRDENT(PSR1) or DEEP_SLEEP(PSR2). Handle this by ensuring "Frame Change"
event at the begin of DSB commit if using PSR/PR.

v3: dsb_commit as a first parameter
v2: use intel_psr_trigger_frame_change_event

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

drm/i915/psr: Add function for triggering "Frame Change" event

Add new function to trigger "Frame Change" event for ensuring we are waking
up before vblank evasion.

v2: dsb as a first parameter

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

drm/i915/display: Evade scanline 0 as well if PSR1 or PSR2 is enabled

PIPEDSL is reading as 0 when in SRDENT(PSR1) or DEEP_SLEEP(PSR2). On
wake-up scanline counting starts from vblank_start - 1. We don't know if
wake-up is already ongoing when evasion starts. In worst case PIPEDSL could
start reading valid value right after checking the scanline. In this
scenario we wouldn't have enough time to write all registers. To tackle
this evade scanline 0 as well. As a drawback we have 1 frame delay in flip
when waking up.

v2:
  - use intel_dsb_emit_wait_dsl
  - add evasion of scanline 0 also for Panel Replay

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

drm/i915/psr: Remove DSB_SKIP_WAITS_EN chicken bit

We have different approach on how flip is considered being complete. We are
waiting for vblank on DSB and generate interrupt when it happens and this
interrupt is considered as indication of completion -> we definitely do not
want to skip vblank wait.

Also not skipping scanline wait shouldn't cause any problems if we are in
DEEP_SLEEP PIPEDSL register is returning 0 -> evasion does nothing and if
we are not in DEEP_SLEEP evasion works same way as without PSR.

v2: add comment explaining why we are not setting DSB_SKIP_WAITS_EN

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

drm/i915/display: Warn on use_dsb in non-dsb pipe update functions

Add drm_WARN_ON(use_dsb) into commit_pipe_{pre,post}_planes() and
intel_pipe_update_{start,end}() as they are not supposed to get called on
non-dsb updates.

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

drm/i915/psr: Write PSR2_MAN_TRK_CTL on DSB commit as well

Add PSR2_MAN_TRK_CTL writing into DSB commit in intel_atomic_dsb_finish.

Taking PSR lock over DSB commit is not needed because PSR2_MAN_TRK_CTL is
now written only by DSB.

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

drm/i915/psr: Allow writing PSR2_MAN_TRK_CTL using DSB

Allow writing PSR2_MAN_TRK_CTL using DSB by using intel_de_write_dsb. Do
not check intel_dp->psr.lock being held when using DSB. This assertion
doesn't make sense as in case of using DSB the actual write happens later
and we are not taking intel_dp->psr.lock mutex over dsb commit.

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

drm/i915/psr: Use SFF_CTL on invalidate/flush for LunarLake onwards

In LunarLake we have SFF_CTL register which contains SFF bit ored with
respective SFF bit in PSR2_MAN_TRK_CTL register. Use this register instead
of the bit in PSR2_MAN_TRK_CTL on frontbuffer tracking callbacks. This
helps us avoiding taking psr mutex when performing atomic commit.

We don't need to set the CFF bit as selective update configuration in
PSR2_MAN_TRL_CTL is not overwritten anymore. I.e. we have valid
configuration in PSR2_MAN_TRK_CTL and in plane SEL_FETCH_* registers when
SFF bit gets cleared by the HW in case something triggers "frame change"
event after SFF bit is cleared.

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

drm/i915/psr: Add register definitions for SFF_CTL and CFF_CTL registers

Add register definitions for SFF_CTL and CFF_CTL registers. Name them as
LNL_SFF_CTL and LNL_CFF_CTL.

v2: use _MMIO_TRANS instead of _MMIO_TRANS2

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

drm/i915/psr: Split setting sff and cff bits away from intel_psr_force_update

This is a clean-up and a preparation for adding own SFF and CFF registers
for LunarLake onwards.

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

drm/i915/psr: Rename psr_force_hw_tracking_exit as intel_psr_force_update

psr_force_hw_tracking_exit is misleading name as it is used for PSR1, PSR2
HW tracking and PSR2 selective fetch. Due to this rename it as
intel_psr_force_update.

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

drm/i915/psr: Use PSR2_MAN_TRK_CTL CFF bit only to send full update

We are preparing for a change where only frontbuffer flush will use
single full frame bit of a new register (SFF_CTL) available on LunarLake
onwards.

It shouldn't be necessary to have SFF bit set if CFF bit is set in
PSR2_MAN_TRK_CTL -> removing setting it on all platforms as there is not
reason to have it different on older platforms.

v2: commit message improved

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

drm/i915/display: convert i915_pipestat_enable_mask() to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert i915_pipestat_enable_mask() to struct intel_display,
allowing further conversions elsewhere.

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/975b382c703cfb62f24643e40eac247b8e8bbea8.1739378096.git.jani.nikula@intel.com

drm/i915/display: convert intel_fifo_underrun.[ch] to struct intel_display

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

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/682e667013e1726a6f2f78484b7e9618cee3b639.1739378096.git.jani.nikula@intel.com

drm/i915/combo-phy: convert intel_combo_phy.[ch] to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_combo_phy.[ch] to struct
intel_display, along with intel_phy_is_combo() in intel_display.c.

Drive-by convert some drm_dbg() to drm_dbg_kms() while at it.

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/c2e0a6294a8eaa4c16632881edc4f2d23c576101.1739378096.git.jani.nikula@intel.com

drm/i915/dsi: convert platform checks to display->platform.<platform> style

These are stragglers from a time the display->platform mechanism didn't
exist. Finish the conversion.

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/493e4c550f9c515e2e82df1afd8a74a24156e76e.1739378096.git.jani.nikula@intel.com

drm/i915/display: convert intel_mode_valid_max_plane_size() to intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert the intel_mode_valid_max_plane_size() helper to struct
intel_display, allowing further conversions elsewhere.

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/6e7810c793ecc8ff6a31569830bf162156245668.1739378095.git.jani.nikula@intel.com

drm/i915/display: convert intel_cpu_transcoder_mode_valid() to intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert the intel_cpu_transcoder_mode_valid()() helper to
struct intel_display, allowing further conversions elsewhere.

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/f9246a00a2e7aabaffb86f863915a4307e1fd3f8.1739378095.git.jani.nikula@intel.com

drm/i915/sdvo: convert intel_sdvo.[ch] to struct intel_display

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

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/2e79909f8a060d7ff1744911f8da9300eb1f225c.1739378095.git.jani.nikula@intel.com

drm/i915/display: convert intel_set_{cpu,pch}_fifo_underrun_reporting() to intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert intel_set_cpu_fifo_underrun_reporting() and
intel_set_pch_fifo_underrun_reporting() to struct intel_display, along
with some of the call chains from there.

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/3b984d0183214d05d0cdecad35184ea8d89ae050.1739378095.git.jani.nikula@intel.com

drm/i915/hpd: drop dev_priv parameter from intel_hpd_pin_default()

The function doesn't use the parameter for anything. Drop it.

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/4347a0f71a1a8c515617cf06471486d9bbb4a026.1739378095.git.jani.nikula@intel.com

drm/i915/display: convert assert_port_valid() to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert the assert_port_valid() helper to struct intel_display,
allowing further conversions elsewhere.

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/e06ef0e2cc34d42918f3208362587a17ea34e28f.1739378095.git.jani.nikula@intel.com

drm/i915/display: convert assert_transcoder*() to struct intel_display

Going forward, struct intel_display is the main display device data
pointer. Convert the assert_transcoder*() helpers to struct
intel_display, allowing further conversions elsewhere.

Do a few small opportunistic conversions right away.

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/430c2f3c899bc98beeb6ba8608f841c9271d0971.1739378095.git.jani.nikula@intel.com

drm/i915/ips: convert hsw_ips.c to struct intel_display

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

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/ebea40784fca6cfb4dbacec570bc9bef49393fc1.1739378095.git.jani.nikula@intel.com

drm/i915/hdmi: convert g4x_hdmi.[ch] to struct intel_display

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

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/4fbaaa4cdab8ec020e5b3fb2f615b3c244c9da2d.1739378095.git.jani.nikula@intel.com

drm/i915/dp: convert g4x_dp.[ch] to struct intel display

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

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/89ce4f7e6aa31f3db6316537f54c5bc7df852322.1739378095.git.jani.nikula@intel.com

drm/i915/dsb: Decode DSB error interrupts

Decode the DSB error interrupts into human readable
form for easier debugging.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207223159.14132-9-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/vrr: Check that the push send bit is clear after delayed vblank

Since we don't do mailbox updates the push send bit
should alwyas clear by the time the delay vblank fires
and the flip completes. Check for that to make sure we
haven't screwed up the sequencing/vblank evasion/etc.

On the DSB path we should be able to guarantee this
since we don't have to deal with any scheduler latencies
and whatnot. I suppose unexpected DMA/memory latencies
might be the only thing that might trip us up here.

For the MMIO path we do always have a non-zero chance
that vblank evasion fails (since we can't really guarantee
anything about the scheduling behaviour). That could trip
up this check, but that seems fine since we already print
errors for other types of vblank evasion failures.

Should the CPU vblank evasion actually fail, then the push
send bit can still be set when the next commit happens. But
both the DSB and MMIO paths should handle that situation
gracefully.

v2: Only check once instead of polling for two scanlines
    since we should now be guaranteed to be past the
    delayed vblank.
    Also check in the MMIO path for good measure
v3: Skip the push send check when VRR is disabled.
    With joiner the secondary pipe's DSBs doen't have access
    to the transcoder registers, and so doing this check
    there triggers a reponse timeout error on the DSB. VRR
    is not currently allowed when using joiner, so this will
    prevent the bogus register access.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250210160711.24010-1-ville.syrjala@linux.intel.com

drm/i915/vrr: Reorder the DSB "wait for safe window" vs. TRANS_PUSH

Currently we trigger the push send first, then follow it with
a "wait for safe window". That approach no longer works on
PTL+ because triggering the push send immediately ends the safe
window. On prior hardware the safe window extended past the
push being sent (presumably all the way to the pipe's delayed
vblank).

In order to deal with the new hardware behaviour we must reverse
the order of these two operations: first wait for safe window,
then trigger the push.

The only slight danger with this approach is that if we mess up
the vblank evasion around the vmax decision boundary the push
might get postponed until after the next frame's vactive. But
assuming we don't mess up the vblank evasion this approach is
completely safe.

As a slight bonus we can perform the push after we've done the
LUT writes as well, meaning we no longer have to worry about
extending the vblank delay to provide enough time for LUT
programming. Instead we will now depend on the vblank evasion
at vmax decision boundary to guarantee this.

However vblank delay (or framestart delay) is still the only
way to provide extra time for the LUT programming in the
non-VRR use cases. Let's assume we don't need anything extra
for now, but eventually we should come up with some proper
estimates on how long the LUT programming can take and
configure the vblank delay accordingly for the non-VRR use
cases.

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207223159.14132-7-ville.syrjala@linux.intel.com

drm/i915/dsb: Introduce intel_dsb_poll()

Add a function for emitting a DSB poll instruction. We'll allow
the caller to specify the poll parameters.

v2: s/wait/wait_us/ (Ankit)

Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207223159.14132-6-ville.syrjala@linux.intel.com

drm/i915/dsb: Compute use_dsb earlier

Skip all the commit completion interrupt stuff on the
chained DSB when we don't take the full DSB path (ie. when
the plane/pipe programming is done via MMIO). The commit
completion will be done via the CPU side vblank interrupt.

Currently this is just a redundant interrupt, so not a big
deal. But in the future we'll be moving the TRANS_PUSH write
into the chained DSB as well, and that we definitely don't
want to do when it's also being done by the CPU from
intel_pipe_update_end().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207223159.14132-5-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/vrr: Account for TRANS_PUSH delay

When we send a push during vblank the TRANS_PUSH write happens
at some point during a scanline, and the hardware picks it up
on the next scanline. Thus there is up to one extra scanline
of delay between the TRANS_PUSH write and the delayed vblank
triggering. Account for that during intel_dsb_wait_vblank_delay()
so that we are guaranteed to be past the delayed vblank before
we trigger the completion interrupt for the commit.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207223159.14132-4-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/vrr: Don't send push for legacy cursor updates

We don't really want legacy cursor updates to trigger
VRR pushes because these can happen willy nilly and we
generally want more precise control over the pushes.
The fastpath in intel_legacy_cursor_update() doesn't
send pushes, but if we punt to the full commit path
(with the flip completion short circuited) we are currently
sending pushes. Skip those as well so that they don't
interfere with the push handling from normal commits.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207223159.14132-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/dsb: Move the +1 usec adjustment into dsb_wait_usec()

The "wait usec" DSB command doesn't quite seem to able to
guarantee that it always waits at least the specified
amount of usecs. Some of that could be just because it
supposedly just does some kind of dumb timestamp comparison
internally. But I also see cases where two hardware timestamps
sampled on each side of the "wait usec" command come out one
less than expected. So it looks like we always need at least a
+1 to guarantee that we never wait less than specified. Always
apply that adjustment in dsb_wait_usec().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207223159.14132-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/pch: Remove unused i915->pch_id

With the PCH checks based on PCH types instead of IDs, the i915->pch_id
member has become unused. Remove it.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fac1c59800128e8f398e83d718a3a5dc235d0526.1738923308.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/pch: Hide PCH device IDs

Only the PCH identification code needs the PCH device IDs, as all the
PCH checks are now based on PCH type. Hide the PCH device IDs inside
intel_pch.c. Remove the unused INTEL_PCH_ID() macro while at it.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d1ceb9fc461cf21e1b885a55293f593eba1458ea.1738923308.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/pch: Make LPT LP a dedicated PCH type

Add PCH type PCH_LPT_LP and rename PCH_LPT to PCH_LPT_H for
consistency. Keep the existing HAS_PCH_LPT*() macros, but express them
in terms of the PCH types instead of looking at the device IDs
directly. This makes the PCH checks independent of the PCH device IDs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/777b63f50b10fba1d768af25870e81b33267bdc8.1738923308.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dpll: Replace all other leftover drm_i915_private

Replace all other left over drm_i915_private with intel_display
in dpll_mgr.c.

--v2
-Don't use inline to_intel_display() [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-9-suraj.kandpal@intel.com

drm/i915/dpll: Accept intel_display as argument for shared_dpll_init

Use intel_display as an argument for intel_shared_dpll_init() and
replace drm_i915_private in function wherever possible.
While at it prefer using display->platform.xx over IS_PLATFORM.
Initialize dpio_phy and dpio_channel since with IS_GEMINILAKE()
and IS_BROXTON() compiler knows it will return false for xe but
since display->platform.xx is a runtime check which means the
compiler sees a potential path where uninitialized variables
could be accessed and raises a warning.

--v2
-Amend commit message to explain why some variables were
initialized [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-8-suraj.kandpal@intel.com

drm/i915/dpll: Use intel_display for update_refclk hook

Use intel_display instead of drm_i915_private for update_refclk hook.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-7-suraj.kandpal@intel.com

drm/i915/dpll: Use intel_display for asserting pll

Use intel_display instead of drm_i915_private to assert pll enabled
and disabled and the corresponding changes needed to make that happen.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-6-suraj.kandpal@intel.com

drm/i915/dpll: Use intel_display possible in shared_dpll_mgr hooks

We use intel_display for function hooks of shared_dpll_mgr and
any function that gets called when we use for_each_shared_dpll.
This also contains some opportunistic display->platform.xx changes
all to reductate the use of drm_i915_private.

--v2
-rebase

--v3
-Don't use inline to_i915 [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-5-suraj.kandpal@intel.com

drm/i915/dpll: Use intel_display for dpll dump and compare hw state

Let's use intel_display for dpll dump and compare hw state. This also
helps elimanate drm_i915_private dependency from i915_shared_dplls_info
in intel_display_debugfs.c

--v2
-Fix commit message [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-4-suraj.kandpal@intel.com

drm/i915/dpll: Change param to intel_display in for_each_shared_dpll

Change the argument of for_each_shared_dpll to take intel_display which
helps move as an ongoing effort to get rid off the dependency on
drm_i915_private. Some opportunistic changes in intel_pch_refclk done
too.

--v2
-Prefer using &i915->display [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-3-suraj.kandpal@intel.com

drm/i915: Use intel_display wherever possible

Use struct intel_display wherever possible in intel_display_debug_fs.c
to reduce the use of drm_i915_private.
While at it do the opportunistic display->platform.xx replacement.

--v2
-Rebase

--v3
-Don't use inline to_intel_display [Jani]
-Don't use display debug fs as subject prefix [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250212074542.3569452-2-suraj.kandpal@intel.com

drm/i915: Continue intel_display_power struct intel_display conversion

Convert the remaining intel_display_power.h interfaces to
take struct intel_display instead of struct drm_i915_private.
intel_display_power.c still has some internal uses due to
i915->runtime_pm.

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

drm/i915: Fix CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n build

Looks like I missed one of myriad CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
special cases when converting the intel_display_power_{get,put}()
code to use struct intel_display. Only noticed after the fact
when building a EXPERT=n kernel :/

Fixes: 5dcfda5cfa42 ("drm/i915: Convert intel_display_power_{get,put}*() to intel_display")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250211000135.6096-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Pimp plane debugs

Include the standard "[PLANE:%d:s]" stuff in all plane debugs
(or rather all I was able to find), to provide better information
on which plane we're actually talking about.

There are a few spots where we care about the CRTC as well, so
include that where appropriate.

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

drm/i915: Use DRM_RECT_FMT & co. for plane debugs

Switch the plane debugs to use DRM_RECT_FMT & co. instead
of drm_rect_debug_print() so that the debugs go on the same line.

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

drm/i915: Convert skl_univeral_plane.c to struct intel_display

struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the skl+ universal plane
code to use it.

Note that we still have two straggles in the form on
HAS_FLAT_CCS() and the pxp stuff.

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

drm/i915: Convert intel_cursor.c to struct intel_display

struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the cursor code to
use it.

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

drm/i915: Finish intel_sprite.c struct intel_display conversion

intel_sprite.c was partially converted to struct intel_display.
Finish the job now that we can deal with the platform checks
as well.

And while at it we also move the 'display' variable declaration
to be the first thing in most functions, consistency. We can
actually do that now since intel_display() accepts the intel_plane
and intel_plane_state types.

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

drm/i915: Convert i9xx_plane.c to struct intel_display

struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the pre-skl primary plane
code to use it.

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

drm/i915: Convert intel_display_power_{get,put}*() to intel_display

Pass intel_display to the display power stuff. These are spread
all over the place so tend to hinder clean conversions of whole
files.

TODO: The gt part/unpark power domain shenanigans need some
kind of more abstract interface...

v2: Deal with cmtg

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

drm/i915: Convert intel_fb.c to struct intel_display

struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the fb code to
use it.

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

drm/i915: Convert intel_crtc.c to struct intel_display

struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert intel_crtc.c code to
use it.

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

drm/i915: Decouple intel_fb_bo.h interfaces from driver specific types

Make the intel_fb_bo.h interfaces operated purely in base
drm_ types so that each driver (i915 and xe) doesn't have to
know about each other, or the display stuff.

v2: s/dev/drm/ (Jani)

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

drm/i915: Decouple i915_gem_dumb_create() from the display a bit

Pass the device argument as drm_device to intel_plane_fb_max_stride()
to decouple i915_gem_dumb_create() vs. the display code a bit.

xe currently doesn't even call this, but it probably should...

v2: s/dev/drm/ (Jani)

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

drm/i915: Pass intel_display to intel_scanout_needs_vtd_wa()

Now that intel_scanout_needs_vtd_wa() is no longer used from
the gem code we can convert it to take struct intel_display.
which will help with converting the low level plane code over
as well.

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

drm/i915/hdcp: Make some functions static

With the debugfs implementation moved next to the implementation, we no
longer need to expose some of the functions. Make them static.

Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250207105838.179805-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/hdcp: Convert platform checks to use display->platform

Prefer display->platform.<platform> over IS_<PLATFORM>(i915), and
reducate struct drm_i915_private usages while at it.

Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/58bad1e888a57a014acbaae67ccddd4f895091a7.1738924826.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/hdcp: rename intel_connector to connector

Follow the current convention of naming struct intel_connector pointers
connector.

Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8f43542a8f0ce0ec5725b769c077d3cea723bde0.1738924826.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/hdcp: Move HDCP debugfs to intel_hdcp.c

Continue with placing debugfs next to the implementation.
intel_connector_info() still needs intel_hdcp_info(), so we'll need to
expose that too.

Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c118e992673f6b054aacaff0e1850fcea329e000.1738924826.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dp_mst: Fix disabling the minimum HBlank time

Disable the minimum HBlank time only on LNL+, where this functionality
and corresponding register exists.

Bspec: 74379
Fixes: a5ebe00c2ace ("drm/i915/dp: Guarantee a minimum HBlank time")
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206164624.3185280-1-imre.deak@intel.com

Revert "drm/i915/dp: Compute as_sdp based on if vrr possible"

This reverts commit 08277aa5d5a44befd71717de35b956f55e1e8401.

Compute AS SDP params only when VRR is enabled to maintain
PSR exclusivity.

Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206045001.2919360-3-mitulkumar.ajitkumar.golani@intel.com

drm/i915/display: Skip state checker for AS SDP infoframe enable

Avoid full modeset by skipping infoframe.enable check when toggling
AS SDP while enabling VRR, preventing full modeset while pipe
config changes.

--v2:
- Add check for exclude_infoframe. (Ankit)
- Update commit message. (Ankit)

--v3:
- Optimise PIPE_CONF_CHECK for infoframes.enable. [Ankit]

Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206045001.2919360-2-mitulkumar.ajitkumar.golani@intel.com

drm/i915/backlight: Enable nits based luminance

Enable nits based luminance by writing the PANEL_LUMINANCE_CONTROL
bit and set the correct register to change brightness.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-9-suraj.kandpal@intel.com

drm/i915/backlight: Setup nits based luminance via VESA

Modify backlight setup function for VESA interface to take into
account the nits based luminance.

--v2
-Prefer using luminance over nits [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-8-suraj.kandpal@intel.com

drm/i915/backlight: Add function to change brightness in nits for VESA

Create a function that fills in the value for
PANEL_TARGET_LUMINANCE_VALUE which helps in changing the luminance in
nits using VESA interface.

--v2
-Prefer using luminance over nits [Jani]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-7-suraj.kandpal@intel.com

drm/i915/backlight: Modify function to get VESA brightness in Nits

Modify vesa_get_brightness function to take into account
luminance_control_support and based on that read the appropriate
register and return the value.

--v2
-Changes since we now use luminance instead of nits

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-6-suraj.kandpal@intel.com

drm/i915/backlight: Check Luminance based brightness control for VESA

Check if we are capable of controlling brightness via luminance
which is dependent on PANEL_LUMINANCE_CONTROL_CAPABLE bit being set
on EDP_GENERAL_CAPABILITY_2 register.

--v2
-Prefer using luminance rather than nits [Jani]
-Fix commit message

--v3
-Fix the bit name used in commit message [Arun]
-Use correct edp_dpcd[] to check the capability [Arun]

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-5-suraj.kandpal@intel.com

drm/i915/backlight: Use proper interface based on eDP version

eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-4-suraj.kandpal@intel.com

drm/dp: Increase eDP display control capability size

Increase the eDP display control capability size to take into
account the general capability register 703 and 704 that have
recently been added.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-3-suraj.kandpal@intel.com

drm/dp: Add eDP 1.5 bit definition

Add the eDP revision bit value for 1.5.

Spec: eDPv1.5 Table 16-5
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Tested-by: Ben Kao <ben.kao@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206063253.2827017-2-suraj.kandpal@intel.com

drm/i915/dp_mst: Fix getting display pointer in intel_dp_mst_compute_min_hblank()

The MST intel_connector::encoder pointer is NULL if the connector hasn't
been enabled before, so it can't be used to retrieve the display
pointer. Use instead the crtc_state and drop the unused connector
parameter.

v2: Use the crtc_state and drop the unused connector parameter.

Fixes: a5ebe00c2ace ("drm/i915/dp: Guarantee a minimum HBlank time")
Reported-and-tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Closes: https://lore.kernel.org/all/16754ee4cd21d99c1e81c5953134b496dd07630f.camel@intel.com
Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com> #v1
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206001726.3021787-1-imre.deak@intel.com

drm/i915/fbdev: Use fb->normal_view.gtt

Grab the GTT view for the fbdev fb pinning from
fb->normal_view.gtt instead of having and extra one on
the stack. Seems safer in case we ever put any new
information into normal GTT views.

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

drm/i915: Use per-plane VT-d guard numbers

Bspec lists different VT-d guard numbers (the number of dummy
padding PTEs) for different platforms and plane types. Use those
instead of just assuming the max glk+ number for everything.
This could avoid a bit of overhead on older platforms due to
reduced padding, and it makes it easier to cross check with the
spec.

Note that VLV/CHV do not document this w/a at all, so not sure
if it's actually needed or not. Nor do we actually know how much
padding is required if it is needed. For now use the same 128
PTEs that we use for snb-bdw primary planes.

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

drm/i915: Calculate the VT-d guard size in the display code

Currently i915_gem_object_pin_to_display_plane() uses
i915_gem_object_get_tile_row_size() to calculate the tile row
size for the VT-d guard w/a. That's not really proper since
i915_gem_object_get_tile_row_size() only works for fenced BOs,
nor does it take rotation into account.

Remedy the situation by calculating the VT-d guard size in the
display code where we have more information readily available.
Although the default guard size (168 PTEs now) should cover
the more typical fb size use cases anyway, and only very large
Y/Yf-tiled framebuffers might have tile row size that exceeds it.

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

drm/i915: Use more optimal VTd alignment for planes

Depending on the platform and/or plane type we can get away
with a bit less alignment in the VT-d w/a. Reduce the numbers
accordingly.

Note that it's not actually clear in VLV/CHV need this w/a,
and if they do we don't actually know what kind of alignment
is sufficient. Leave the 256k alignment in place for now, but
toss in a FIXME.

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

drm/i915: Move VT-d alignment into plane->min_alignment()

Currently we don't account for the VT-d alignment w/a in
plane->min_alignment() which means that panning inside a larger
framebuffer can still cause the plane SURF to be misaligned.
Fix the issue by moving the VT-d alignment w/a into
plane->min_alignment() itself (for the affected platforms).

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

drm/i915/psr: clarify intel_psr_pre_plane_update() conditions

Make the conditions easier to follow. We don't do anything for
!psr->enabled, so hoist psr->enabled check higher, avoiding all the
checks when !psr->enabled. Stop the bitwise OR abuse on booleans by
removing the temporary variable altogether.

v2: Rebase

Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1
Link: https://patchwork.freedesktop.org/patch/msgid/20250204140518.2971530-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>