mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-05-13 12:59:33 -04:00
Code Issues Packages Projects Releases Wiki Activity
1,337,599 Commits 1 Branch 930 Tags
b4bd4f219cfed89d6de49e2fa26c0d8633d48211
Commit Graph

1337599 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Jani Nikula
b4bd4f219c 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>
 2025-04-09 17:27:35 +03:00
Jani Nikula
788f205f3c 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>
 2025-04-09 17:27:35 +03:00
Jani Nikula
cdbf0e16fb 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>
 2025-04-09 12:45:17 +03:00
Jani Nikula
ca677505e4 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>
 2025-04-09 12:45:17 +03:00
Imre Deak
8b6b67938e 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
 2025-04-07 16:25:34 +03:00
Imre Deak
4f41071e22 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
 2025-04-07 16:25:28 +03:00
Imre Deak
fa207d2b1d 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
 2025-04-07 16:25:22 +03:00
Imre Deak
39abe4ad13 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
 2025-04-07 16:25:18 +03:00
Imre Deak
59e8cd62f5 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
 2025-04-07 16:25:12 +03:00
Imre Deak
db0f7e20c2 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
 2025-04-07 16:24:59 +03:00
Ankit Nautiyal
ced5e64f01 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: e8cd188e91 ("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
 2025-04-07 17:43:53 +05:30
Ville Syrjälä
669cdda66e 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>
 2025-04-04 20:03:40 +03:00
Ville Syrjälä
da885fdaf9 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>
 2025-04-04 20:02:46 +03:00
Ville Syrjälä
4d5204b304 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>
 2025-04-04 20:02:18 +03:00
Ville Syrjälä
d1381206b1 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>
 2025-04-04 20:01:50 +03:00
Ville Syrjälä
014ea4d39c 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>
 2025-04-04 20:01:13 +03:00
Ville Syrjälä
dacbfc5e9e 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>
 2025-04-04 20:00:32 +03:00
Ville Syrjälä
67ad5b9bab 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>
 2025-04-04 20:00:15 +03:00
Ville Syrjälä
da1c27e4ae 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>
 2025-04-04 19:59:46 +03:00
Ville Syrjälä
0029d2f739 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>
 2025-04-04 19:59:18 +03:00
Ville Syrjälä
074c31271a 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>
 2025-04-04 19:58:47 +03:00
Ville Syrjälä
18e6866615 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>
 2025-04-04 19:58:19 +03:00
Ville Syrjälä
8261fbacd9 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>
 2025-04-04 19:58:10 +03:00
Ville Syrjälä
92512d4827 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>
 2025-04-04 19:58:02 +03:00
Ville Syrjälä
1aa4031257 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>
 2025-04-04 19:57:44 +03:00
Ville Syrjälä
38188a7f57 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>
 2025-04-02 16:18:04 +03:00
Jouni Högander
d354d52c55 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
 2025-04-02 08:35:06 +03:00
Ville Syrjälä
544813fb8c 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>
 2025-04-02 02:23:06 +03:00
Ville Syrjälä
9d29347847 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>
 2025-04-02 02:22:48 +03:00
Ville Syrjälä
a47720c545 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>
 2025-04-02 02:22:19 +03:00
Ville Syrjälä
0cd161e947 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>
 2025-04-02 02:21:12 +03:00
Ville Syrjälä
4bef6b0e10 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>
 2025-04-02 02:20:00 +03:00
Ville Syrjälä
50596bdd4e 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>
 2025-04-02 02:19:19 +03:00
Ville Syrjälä
d1b14231aa 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>
 2025-04-02 02:17:30 +03:00
Ville Syrjälä
8f0d3618c6 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>
 2025-04-02 02:16:12 +03:00
Ville Syrjälä
9e2434f32d 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>
 2025-04-02 02:15:32 +03:00
Ville Syrjälä
33b3c4791e 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>
 2025-04-02 02:15:26 +03:00
Jani Nikula
da1d515eb1 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>
 2025-04-01 11:57:47 +03:00
Jani Nikula
513c1a2ec4 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>
 2025-04-01 11:48:18 +03:00
Jani Nikula
6f5a3b9d6d 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>
 2025-04-01 11:46:58 +03:00
Jani Nikula
4f82074690 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>
 2025-04-01 10:52:02 +03:00
Lucas De Marchi
930af58421 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>
 2025-03-31 08:09:40 -07:00
Lucas De Marchi
8d4bd9bb13 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>
 2025-03-31 08:09:40 -07:00
Rodrigo Vivi
bee964bd14 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: 0d77a3e0ea ("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>
 2025-03-31 10:32:02 -04:00
Vinod Govindapillai
010363c461 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
 2025-03-31 14:36:50 +03:00
Jouni Högander
9900e35a3a 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
 2025-03-31 14:12:14 +03:00
Ankit Nautiyal
94f608992f 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
 2025-03-31 09:28:28 +05:30
Ankit Nautiyal
7a6bf54c5f 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
 2025-03-31 09:28:26 +05:30
Jani Nikula
61601771ee 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>
 2025-03-28 13:52:23 +02:00
Jani Nikula
94fe5f275a 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>
 2025-03-28 13:52:23 +02:00