mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-05-23 07:56:49 -04:00
Code Issues Packages Projects Releases Wiki Activity
1,384,787 Commits 1 Branch 931 Tags
994c74ea5e07ec93a8616602caaca95a70efdb21
Commit Graph

118347 Commits

Author SHA1 Message Date
Jani Nikula
994c74ea5e drm/{i915, xe}/stolen: use the stored i915/xe device pointer 
Now that we store the i915/xe device pointer in struct
intel_stolen_node, we can reduce parameter passing in a number of
functions.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/6f31114c8113ce2254d422ca53992088b673fb2f.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
e8848d3d37 drm/{i915, xe}/stolen: add device pointer to struct intel_stolen_node 
Add backpointers to i915/xe to allow simplifying some interfaces in
follow-up.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/321354d47f9e530159caefef510d5394f4177470.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
f74bab2d90 drm/{i915, xe}/stolen: make struct intel_stolen_node opaque 
Add i915_gem_stolen_node_alloc() and i915_gem_stolen_node_free(),
returning struct intel_stolen_node pointer. Make struct
intel_stolen_node an opaque pointer, with different implementations in
i915 and xe.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/3fe71bbb4c75ee86b4d129fafa3d4cd6526363f4.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
33c8d948bc drm/xe/stolen: convert compat static inlines to proper functions 
Add display/xe_stolen.c as the implementation for the stolen interface
exposed to display. This allows hiding the implementation details that
shouldn't be exposed to display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/8e807c6aafc6151b18df08dda20053516813e001.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
59998644b7 drm/i915/stolen: convert intel_stolen_node into a real struct of its own 
i915_gem_stolen.h simply defines intel_stolen_node as drm_mm_node. Make
struct intel_stolen_node an actual struct of its own right, and embed
struct drm_mm_node inside. This allow better unification between i915
and xe.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/36762f611566d81427e702369f4e8207ead5f26c.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
9f697958bb drm/xe/stolen: switch from BUG_ON() to WARN_ON() in compat 
We're pretty much never supposed to be using BUG_ON(). Switch to
WARN_ON().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/d14c693a3387a5d89bb88e81349639b5ec5663fb.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
b6500640ac drm/xe/stolen: convert compat stolen macros to inline functions 
Improve type safety. Allows getting rid of a __maybe_unused annotation
too.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/1ec1fa59e0e54da49a1ec4fd1d535288066db502.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
511d2d70df drm/xe/stolen: rename fb to node in stolen compat header 
It's more about node than fb, and this makes more sense now that the
struct is also named intel_stolen_node.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/71a7872e47da5f3fbe61cc21723bfcf8ff6518b8.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
3198609ecc drm/{i915, xe}/stolen: rename i915_stolen_fb to intel_stolen_node 
Use a more generic name than one that refers to "i915" and "fb".

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/925fd07d3f2a6115c71984f5a40a06c9eb46a539.1758732183.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:41:30 +03:00
Jani Nikula
996ad9cd3e Merge drm/drm-next into drm-intel-next 
Backmerge to sync with drm/xe changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-29 12:13:00 +03:00
Jouni Högander
924adb0bbd drm/i915/psr: Deactivate PSR only on LNL and when selective fetch enabled 
Using intel_psr_exit in frontbuffer flush on older platforms seems to be
causing problems.

Sending single full frame update using intel_psr_force_update is anyways
more optimal compared to psr deactivate/activate -> move back to this
approach on PSR1, PSR HW tracking and Panel Replay full frame update and
use deactivate/activate only on LunarLake and only when selective fetch is
enabled.

Tested-by: Lemen <lemen@lemen.xyz>
Tested-by: Koos Vriezen <koos.vriezen@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14946
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250922102725.2752742-1-jouni.hogander@intel.com
 2025-09-26 08:52:59 +03:00
Dave Airlie
a2caae58f8 Merge tag 'drm-misc-next-fixes-2025-09-25' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next 
Short summary of fixes pull:

bridge:
- waveshare-dsi: Fix error handling in probe function

pixpaper:
- select GEM SHMEM helpers

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250925064257.GA9107@linux.fritz.box
 2025-09-26 13:06:39 +10:00
Madhur Kumar
40ac9b3eb0 drm/i915: i915_pmu: Use sysfs_emit() instead of sprintf() 
Follow the advice in Documentation/filesystems/sysfs.rst:
show() should only use sysfs_emit() or sysfs_emit_at() when formatting
the value to be returned to user space.

Signed-off-by: Madhur Kumar <madhurkumar004@gmail.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250923195051.1277855-1-madhurkumar004@gmail.com
 2025-09-26 00:38:01 +02:00
Jonathan Cavitt
22a2f2e35f drm/i915/gvt: Improve intel_vgpu_ioctl hdr error handling 
Add error handling for the following VFIO_DEVICE_SET_IRQS cases with
respect to the hdr struct:

- More than one VFIO_IRQ_DATA_TYPE_MASK flag is set in hdr.flags
- More than one VFIO_IRQ_ACTION_TYPE_MASK flag is set in hdr.flags
- hdr.count is not specified

Note that since hdr.count != 0, data_size != 0 is guaranteed unless
vfio_set_irqs_validate_and_prepare fails and returns an error.  So, we
no longer need to check data_size before running memdup_user because
checking the return value of the function is sufficient.

v2: Use correct name for mask

v3: Use is_power_of_2 over hweight32 as it's more efficient (Andi)

Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250923212332.112137-2-jonathan.cavitt@intel.com
 2025-09-26 00:27:54 +02:00
Jonathan Cavitt
69b4d367ff drm/i915/gvt: Simplify case switch in intel_vgpu_ioctl 
We do not need a case switch to check cap_type_id in intel_vgpu_ioctl
for various reasons (it's impossible to hit the default case in the
current code, there's only one valid case to check, the error handling
code overlaps in both cases, etc.).  Simplify the case switch into a
single if statement.  This has the additional effect of simplifying the
error handling code.

Note that it is still currently impossible for
'if (cap_type_id == VFIO_REGION_INFO_CAP_SPARSE_MMAP)'
to fail, but we should still guard against the possibility of this
changing in the future.

Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250918214515.66926-2-jonathan.cavitt@intel.com
 2025-09-25 18:27:06 +02:00
Ankit Nautiyal
fe3c035330 drm/i915/dsb: Inline dsb_vblank_delay() into intel_dsb_wait_for_delayed_vblank() 
Drop the now single-use dsb_vblank_delay() helper and inline its logic
directly into intel_dsb_wait_for_delayed_vblank().

This will help to keep all VRR related wait stuff in one place.

v2: Use intel_scanlines_to_usecs() in intel_dsb_wait_usec(). (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/20250925022352.3129859-1-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:21 +05:30
Ankit Nautiyal
68f1d1764d drm/i915/display: Drop intel_vrr_vblank_delay and use set_context_latency 
The helper intel_vrr_vblank_delay() was used to keep track of the SCL
lines + the extra vblank delay required for ICL/TGL.
This was used to wait for sufficient lines for:
-push send bit to clear for VRR case
-evasion to delay the commit.

For first case we are using safe window scanline wait and with that we
just need to wait for SCL lines, we do not need to wait for the extra
vblank delay required for ICL/TGL. For the second case, we actually
do not need to wait for extra lines before the undelayed vblank, if we
are already in the safe window.

To sum up, SCL lines is sufficient for both cases.

So drop the helper intel_vrr_vblank_delay and just use
crtc_state->set_context_latency instead.

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/20250924141542.3122126-10-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:20 +05:30
Ankit Nautiyal
5f9172bf6f drm/i915/vrr: Clamp guardband as per hardware and timing constraints 
The maximum guardband value is constrained by two factors:
- The actual vblank length minus set context latency (SCL)
- The hardware register field width:
  - 8 bits for ICL/TGL (VRR_CTL_PIPELINE_FULL_MASK -> max 255)
  - 16 bits for ADL+ (XELPD_VRR_CTL_VRR_GUARDBAND_MASK -> max 65535)

Remove the #FIXME and clamp the guardband to the maximum allowed value.

v2:
- Use REG_FIELD_MAX(). (Ville)
- Separate out functions for intel_vrr_max_guardband(),
  intel_vrr_max_vblank_guardband(). (Ville)

v3:
- Fix Typo: Add the missing adjusted_mode->crtc_vdisplay in guardband
  computation. (Ville)
- Refactor intel_vrr_max_hw_guardband() and use else for consistency.
  (Ville)

v4:
- Drop max_guardband from intel_vrr_max_hw_guardband(). (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (#v2)
Link: https://lore.kernel.org/r/20250924141542.3122126-9-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:19 +05:30
Ankit Nautiyal
94da8e5eee drm/i915/reg_defs: Add REG_FIELD_MAX wrapper for FIELD_MAX() 
Introduce REG_FIELD_MAX macro as local wrapper around FIELD_MAX() to return
the maximum value representable by a bit mask. The value is cast to u32
for consistency with other REG_* macros and assumes the bitfield fits
within 32 bits.

v2: Use __mask as macro argument aligning with other macros. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250924141542.3122126-8-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:19 +05:30
Ankit Nautiyal
4e5c033cfe drm/i915/display: Wait for scl start instead of dsb_wait_vblanks 
Until LNL, intel_dsb_wait_vblanks() used to wait for the undelayed vblank
start. However, from PTL onwards, it waits for the start of the
safe-window defined by the number of lines programmed in the register
TRANS_SET_CONTEXT_LATENCY. This change was introduced to move the SCL
window out of the vblank region, supporting modes with higher refresh
rates and smaller vblanks. This change introduces a "safe window" a
scanline range from (undelayed vblank - SCL) to (delayed vblank - SCL).

As a result, on PTL+ platforms, the DSB wait for vblank completes exactly
SCL lines earlier than the undelayed vblank start (safe window start).
If the flip occurs in the active region and the push happens before the
vmin decision boundary, the DSB wait fires early, and the push is sent
inside this safe window. In such cases, the push bit is cleared at the
delayed vblank, but our wait logic does not account for the early trigger,
leading to DSB poll errors.

To fix this, we add an explicit wait for the end of the safe window i.e.,
the scanline range from (undelayed vblank - SCL) to (delayed vblank - SCL).
Once past this window, we are exactly SCL lines away from the delayed
vblank, and our existing wait logic works as intended.

This additional wait is only effective if the push occurs before the vmin
decision boundary. If the push happens after the boundary, the hardware
already guarantees we're SCL lines away from the delayed vblank, and the
extra wait becomes a no-op.

v2:
- Use helpers for safe window start/end. (Ville)
- Move the extra wait inside the helper to wait for delayed vblank. (Ville)
- Update the commit message.

v3:
- Add more documentation for explanation for the wait. (Ville)
- Rename intel_vrr_vmin_safe_window_start/end as this is vmin safe
  window. (Ville)
- Minor refactoring to align with the code. (Ville)
- Update the commit message for more clarity.

v4:
- Retain name for intel_vrr_safe_window_start as it doesn't change with
  vmin/vmax etc. (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/20250924141542.3122126-7-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:18 +05:30
Ankit Nautiyal
2a3831cd80 drm/i915/dsb: s/intel_dsb_wait_vblank_delay/intel_dsb_wait_for_delayed_vblank 
The helper intel_dsb_wait_vblank_delay() is used in DSB to wait for the
delayed vblank after the send push operation. Rename it to
intel_dsb_wait_for_delayed_vblank() to align with the semantics.

v2: Rename to intel_dsb_wait_vblank_delay instead of the proposed SCL
semantics, as this will be ot only about SCL lines with different timing
generator and different refresh rate modes. (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/20250924141542.3122126-6-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:16 +05:30
Ankit Nautiyal
b811a7635a drm/i915/vrr: Use SCL for computing guardband 
For now guardband is equal to the vblank length so ideally it should be
computed as difference between the vmin vtotal and vactive. However
since we are having few lines as SCL, we need to account for this while
computing the guardband.

Since the vblank start is moved by SCL lines from the vactive, the delta
between the vmin vtotal and new vblank start was used to account for this.
Now that SCL is explicitly tracked using the `set_context_latency` member,
use it directly in the guardband calculation.

In the future, when the guardband is shortened or optimized, we may need
to factor in both the change in the vblank start and SCL lines. For now,
explicitly accounting for SCL is sufficient.

v2: Fix typo: replace adjusted_mode->vdisplay with
adjusted_mode->crtc_vdisplay. (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/20250924141542.3122126-5-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:16 +05:30
Ankit Nautiyal
6441d9038f drm/i915/vrr: Use set_context_latency instead of intel_vrr_real_vblank_delay() 
The helper intel_vrr_real_vblank_delay() was added to account for the
SCL lines for TGL where we do not have the TRANS_SET_CONTEXT_LATENCY.

Now, since we already are tracking the SCL with new member
`set_context_latency` use it directly instead of the helper.

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/20250924141542.3122126-4-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:15 +05:30
Ankit Nautiyal
419daf7d83 drm/i915/display: Add set_context_latency to crtc_state 
'Set context latency' (SCL, Window W2) is defined as the number of lines
before the double buffering point, which are required to complete
programming of the registers, typically when DSB is used to program the
display registers.

Since we are not using this window for programming the registers, this
is mostly set to 0, unless there is a requirement for few cases related
to PSR/PR where the 'set context latency' should be at least 1.

Currently we are using the 'set context latency' (if required) implicitly
by moving the vblank start by the required amount and then measuring the
delay i.e. the difference between undelayed vblank start and delayed vblank
start.

Since our guardband matches the vblank length, this was not a problem as
the difference between the undelayed vblank and delayed vblank was at
the most equal to the 'set context latency' lines.

However, if we want to optimize the guardband, the difference between the
undelayed and the delayed vblank will be large and we cannot use this
difference as the 'set context latency' lines.

To make way for this optimization of guardband, formally introduce the
'set context latency' or SCL and track it as a new member
`set_context_latency` of the structure intel_crtc_state.

Eventually, all references of vblank delay where we mean to use set
context latency will be replaced by this new `set_context_latency`
member.

Note: for TGL the TRANS_SET_CONTEXT_LATENCY doesn't exist to account for
the SCL. However, the VBLANK_START-VACTIVE difference plays an identical
role here ie. it can be used to create the SCL window ahead of the
undelayed vblank.

While readback since there is no specific register to read out the SCL, use
the difference between vblank start and vactive to populate the new member
for TGL.

v2:
- Use u16 for set_context_latency. (Ville)
- s/vblank_delay/set_context_latency. (Ville)
- Meld the changes for TGL with this change. (Ville)

v3:
- Update comment to clarify the TGL case. (Ville)
- Fix typo in commit message.

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/20250924141542.3122126-3-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:14 +05:30
Ankit Nautiyal
6131428a47 drm/i915/psr: s/intel_psr_min_vblank_delay/intel_psr_min_set_context_latency 
Rename intel_psr_min_vblank_delay to intel_psr_min_set_context_latency
to reflect that it provides the minimum value for 'Set context
latency'(SCL or Window W2) for PSR/Panel Replay to work correctly across
different platforms.

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/20250924141542.3122126-2-ankit.k.nautiyal@intel.com
 2025-09-25 18:38:12 +05:30
Jani Nikula
c2e04017fb drm/i915/gem: add i915_gem_fence_wait_priority_display() helper 
Add i915_gem_fence_wait_priority_display() helper to wait with
I915_PRIORITY_DISPLAY. This drops the intel_plane.c dependency on
i915_scheduler_types.h, and allows us to remove the compat header from
xe.

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250924085129.146173-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-25 11:41:59 +03:00
Ankit Nautiyal
d90c0a5ccd drm/i915/vrr: Refactor VRR live status wait into common helper 
Add a helper to consolidate timeout handling and error logging when waiting
for VRR live status to clear. Log an error message if the VRR live status
bit fails to clear within the timeout.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Link: https://lore.kernel.org/r/20250902122850.3649828-1-ankit.k.nautiyal@intel.com
 2025-09-24 16:30:58 +05:30
Jani Nikula
c989cb4c64 drm/i915/irq: split ILK display irq handling 
Split out display irq handling on ilk. Since the master IRQ enable is in
DEIIR, we'll need to do this in two parts. First, add
ilk_display_irq_master_disable() to disable master and south interrupts,
and second, add (repurposed) ilk_display_irq_handler() to finish display
irq handling.

It's not the prettiest thing you ever saw, but improves separation of
display irq handling. And removes HAS_PCH_NOP() and DISPLAY_VER() checks
from core irq code.

v2:
- Separate ilk_display_irq_master_enable() (Ville)
- Use _fw mmio accessors (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/e8ea7c985c3f3a80870f3333bde2e1bf30d653b0.1758637773.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-24 09:31:07 +03:00
Jani Nikula
c39d3e2dd9 drm/i915/irq: move check for HAS_HOTPLUG() inside i9xx_hpd_irq_ack() 
We want to avoid using the display dependent HAS_HOTPLUG() in generic
irq code. Since the enabling of I915_DISPLAY_PORT_INTERRUPT depends on
HAS_HOTPLUG() to begin with, we don't really expect to get the irqs for
!HAS_HOTPLUG(). At least in theory, checking for HAS_HOTPLUG() inside
i9xx_hpd_irq_ack() should not have any impact.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/2f97c077e67667bf420196c7381553d5286da958.1758637773.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-24 09:31:07 +03:00
Jani Nikula
d54c636db5 drm/i915/irq: abstract i9xx_display_irq_enable_mask() 
Figure out the enable mask for display things in display code. Reuse the
same function for both i915 and i965 code, the end result remains the
same.

This removes a pair of DISPLAY_VER() and HAS_HOTPLUG() checks from core
irq code.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/dd7cd63a4019ff24098d565b67ea827df6b9ed45.1758637773.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-24 09:31:07 +03:00
Jani Nikula
381f04d8c0 drm/i915/irq: initialize gen2_imr_mask in terms of enable_mask 
Instead of initializing gen2_imr_mask and enable_mask independently, use
the latter for initializing the former. This also highlights the
differences in the masks, i.e. what's set to enable_mask after it's been
used to initialize gen2_imr_mask.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/e3b612ce4decea699bde2c52aeaef48bf95f7abc.1758637773.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-24 09:31:07 +03:00
Jani Nikula
3dc4223878 drm/i915/irq: drop intel_psr_regs.h include 
i915_irq.c no longer needs display/intel_psr_regs.h. Drop it.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/29752bb1942fc2ceceb5140bb49f67e44e1b0676.1758637773.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-24 09:31:07 +03:00
Dnyaneshwar Bhadane
8147f7a1c0 drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A 
On PTL, no combo PHY is connected to PORT B. However, PORT B can
still be used for Type-C and will utilize the C20 PHY for eDP
over Type-C. In such configurations, VBTs also enumerate PORT B.

This leads to issues where PORT B is incorrectly identified as using the
C10 PHY, due to the assumption that returning true for PORT B in
intel_encoder_is_c10phy() would not cause problems.

From PTL's perspective, only PORT A/PHY A uses the C10 PHY.

Update the helper intel_encoder_is_c10phy() to return true only for
PORT A/PHY on PTL.

v2: Change the condition code style for ptl/wcl

Bspec: 72571,73944
Fixes: 9d10de78a3 ("drm/i915/wcl: C10 phy connected to port A and B")
Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250922150317.2334680-4-dnyaneshwar.bhadane@intel.com
 2025-09-23 21:44:34 +05:30
Dnyaneshwar Bhadane
4dfaae643e drm/i915/display: Add definition for wcl as subplatform 
We will need to differentiate between WCL and PTL in
intel_encoder_is_c10phy(). Since WCL and PTL use the same display
architecture, let's define WCL as a subplatform of PTL to allow the
differentiation.

v2: Update commit message and reorder wcl define (Gustavo)

Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250922150317.2334680-3-dnyaneshwar.bhadane@intel.com
 2025-09-23 21:44:33 +05:30
Dnyaneshwar Bhadane
32620e1764 drm/pcids: Split PTL pciids group to make wcl subplatform 
To form the WCL platform as a subplatform of PTL in definition,
WCL pci ids are splited into saparate group from PTL.
So update the pciidlist struct to cover all the pci ids.

v2:
- Squash wcl description in single patch for display and xe.(jani,gustavo)

Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250922150317.2334680-2-dnyaneshwar.bhadane@intel.com
 2025-09-23 21:44:33 +05:30
Ville Syrjälä
840f6b9e48 drm/i915: Make sure wm block/lines are non-decreasing 
The watermark algorithm sometimes produces results where higher
watermark levels have smaller blocks/lines watermarks than the lower
levels. That doesn't really make sense as the corresponding latencies
are supposed to be non-decreasing. It's unclear how the hardware
responds to such watermark values, so it seems better to avoid that
case and just make sure the values are always non-decreasing.

Here's an example how things change for such a case on a GLK NUC:
 [PLANE:70:cursor A]   level  wm0, wm1, wm2, wm3, wm4, wm5, wm6, wm7, twm, swm, stwm -> *wm0,*wm1,*wm2,*wm3,*wm4,*wm5,*wm6,*wm7,*twm, swm, stwm
 [PLANE:70:cursor A]   lines    0,   0,   0,   0,   0,   0,   0,   0,   0,   0,    0 ->    4,   4,   4,   2,   2,   2,   2,   2,   0,   0,    0
 [PLANE:70:cursor A]  blocks    0,   0,   0,   0,   0,   0,   0,   0,   0,   0,    0 ->   11,  11,  12,   7,   7,   7,   7,   7,  25,   0,    0
 [PLANE:70:cursor A] min_ddb    0,   0,   0,   0,   0,   0,   0,   0,   0,   0,    0 ->   12,  12,  13,   8,   8,   8,   8,   8,  26,   0,    0
->
 [PLANE:70:cursor A]   level  wm0, wm1, wm2, wm3, wm4, wm5, wm6, wm7, twm, swm, stwm -> *wm0,*wm1,*wm2,*wm3,*wm4,*wm5,*wm6,*wm7,*twm, swm, stwm
 [PLANE:70:cursor A]   lines    0,   0,   0,   0,   0,   0,   0,   0,   0,   0,    0 ->    4,   4,   4,   4,   4,   4,   4,   4,   0,   0,    0
 [PLANE:70:cursor A]  blocks    0,   0,   0,   0,   0,   0,   0,   0,   0,   0,    0 ->   11,  11,  12,  12,  12,  12,  12,  12,  25,   0,    0
 [PLANE:70:cursor A] min_ddb    0,   0,   0,   0,   0,   0,   0,   0,   0,   0,    0 ->   12,  12,  13,  13,  13,  13,  13,  13,  26,   0,    0

Whether this actually helps on any display blinking issues is unclear.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8683
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-14-ville.syrjala@linux.intel.com
 2025-09-23 18:12:46 +03:00
Ville Syrjälä
b86cb7beed drm/i915: Print both the original and adjusted wm latencies 
In order to help with debugging print both the original wm
latencies read from the mailbox/etc., and the final fixed/adjusted
values.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-13-ville.syrjala@linux.intel.com
 2025-09-23 18:12:39 +03:00
Ville Syrjälä
d49564a5f7 drm/i915: Make wm latencies monotonic 
Some systems (eg. LNL Lenovo Thinkapd X1 Carbon) declare
semi-bogus non-monotonic WM latency values:
 WM0 latency not provided
 WM1 latency 100 usec
 WM2 latency 100 usec
 WM3 latency 100 usec
 WM4 latency 93 usec
 WM5 latency 100 usec

Apparently Windows just papers over the issue by bumping the
latencies for the higher watermark levels to make them monotonic
again. Do the same.

Cc: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-12-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
 2025-09-23 18:12:01 +03:00
Ville Syrjälä
15bdae1072 drm/i915: Flatten sanitize_wm_latency() a bit 
Move the inner loop out from the outer loop in
sanitize_wm_latency() to flatten things a bit.
Easier to read flat code.

v2: Move the inner loop out completely (Luca)

Cc: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-11-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
 2025-09-23 18:11:37 +03:00
Ville Syrjälä
e407ea78ab drm/i915: Extract sanitize_wm_latency() 
Pull the "zero out invalid WM latencies" stuff into a helper.
Mainly to avoid mixing higher level and lower level stuff in
the same adjust_wm_latency() function.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-10-ville.syrjala@linux.intel.com
 2025-09-23 18:11:03 +03:00
Ville Syrjälä
84953731f9 drm/i915: Use increase_wm_latency() for the 16Gb DIMM w/a 
Bump the latency for all watermark levels in the
16Gb+ DIMM w/a. The spec does ask us to do it only for level
0, but it seems more sane to bump all the levels. If the actual
memory access is slower then the wakeup (WM1+) should also
potentially happen earlier.

This also avoids the theoretical case that WM0 would get bumped
higher than WM1+. Not that it is likely to happen because the WM0
latency is always significantly lower than the WM1 latency.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-9-ville.syrjala@linux.intel.com
 2025-09-23 18:10:57 +03:00
Ville Syrjälä
030778ab8d drm/i915: Extract increase_wm_latency() 
Extract the "increase wm latencies by some amount" code into
a helper that can be reused.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-8-ville.syrjala@linux.intel.com
 2025-09-23 18:10:40 +03:00
Ville Syrjälä
91acc63178 drm/i915: Extract multiply_wm_latency() from skl_read_wm_latency() 
I want skl_read_wm_latency() to just do what it says on
the tin, ie. read the latency values from the pcode mailbox.
Move the DG2 "multiply by two" trick elsewhere.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-7-ville.syrjala@linux.intel.com
 2025-09-23 18:10:26 +03:00
Ville Syrjälä
e6619d22c8 drm/i915: Move adjust_wm_latency() out from {mtl,skl}_read_wm_latency() 
{mtl,skl}_read_wm_latency() are doing way too many things for
my liking. Move the adjustment stuff out into the caller.
This also gives us one place where we specify the 'read_latency'
for all the platforms, instead of two places.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-6-ville.syrjala@linux.intel.com
 2025-09-23 18:09:52 +03:00
Ville Syrjälä
76742daf75 drm/i915: Don't pass the latency array to {skl,mtl}_read_wm_latency() 
We always operate on i915->display.wm.skl_latency in
{skl,mtl}_read_wm_latency(). No real need for the caller
to have to pass that in explicitly.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-5-ville.syrjala@linux.intel.com
 2025-09-23 18:09:39 +03:00
Ville Syrjälä
07816e8117 drm/i915: Tweak the read latency fixup code 
If WM0 latency is zero we need to bump it (and the WM1+ latencies)
but a fixed amount. But any WM1+ level with zero latency must
not be touched since that indicates that corresponding WM level
isn't supported.

Currently the loop doing that adjustment does work, but only because
the previous loop modified the num_levels used as the loop boundary.
This all seems a bit too fragile. Remove the num_levels adjustment
and instead adjust the read latency loop to abort when it encounters
a zero latency value.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-4-ville.syrjala@linux.intel.com
 2025-09-23 18:09:30 +03:00
Ville Syrjälä
8ebb8e1a0e drm/i915: Apply the 16Gb DIMM w/a only for the platforms that need it 
Currently the code assumes that every platform except dg2 need the
16Gb DIMM w/a, while in reality it's only needed by skl and icl (and
derivatives). Switch to a more specific platform check.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-3-ville.syrjala@linux.intel.com
 2025-09-23 18:09:21 +03:00
Ville Syrjälä
a1d0a0549d drm/i915/dram: Also apply the 16Gb DIMM w/a for larger DRAM chips 
While the spec only asks us to do the WM0 latency bump for 16Gb
DRAM devices I believe we should apply it for larger DRAM chips.
At the time the w/a was added there were no larger chips on
the market, but I think I've seen at least 32Gb DDR4 chips
being available these days.

Whether it's possible to actually find suitable DIMMs for the
affected systems with largers chips I don't know. Also it's
not known whether the 1 usec latency bump would be sufficient
for larger chips. Someone would need to find such DIMMs and
test this. Fortunately we do have a bit of extra latency already
with the 1 usec bump, as the actual requirement was .4 usec for
for 16Gb chips.

Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-2-ville.syrjala@linux.intel.com
 2025-09-23 18:08:08 +03:00
LiangCheng Wang
0c4932f6dd drm/tiny: pixpaper: Fix missing dependency on DRM_GEM_SHMEM_HELPER 
The driver uses drm_gem_shmem_prime_import_no_map() and
drm_gem_shmem_dumb_create(), but the Kconfig currently selects
DRM_GEM_DMA_HELPER instead of DRM_GEM_SHMEM_HELPER. This causes
link failures when DRM_GEM_SHMEM_HELPER is not enabled.

Select DRM_GEM_SHMEM_HELPER to fix the build.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202509220320.gfFZjmyg-lkp@intel.com/
Fixes: c9e70639f5 ("drm: tiny: Add support for Mayqueen Pixpaper e-ink panel")
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250922-bar-v1-1-b2a1f54ace82@gmail.com
 2025-09-23 14:07:04 +02:00
Ville Syrjälä
97fd25f8b6 drm/i915/pm: Drop redundant pci stuff from suspend/resume paths 
I don't think there should be any need for us to call any of
pci_enable_device(), pci_disable_device() or pci_set_master()
from the suspend/resume paths. The config space save/restore should
take care of all of this.

Cc: Karthik Poosa <karthik.poosa@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250919185015.14561-7-ville.syrjala@linux.intel.com
 2025-09-22 19:34:57 +03:00