github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-07-31 03:27:03 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph
1,382,797 Commits 1 Branch 940 Tags 24 GiB
c2e04017fb
Commit Graph

1382797 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
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
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
Ville Syrjälä
3a3d9cb0b1 drm/i915/pm: Allow drivers/pci to manage our pci state normally 
Stop doing the pci_save_state(), except when we need to prevent
D3 due to BIOS bugs, so that the code in drivers/pci is allowed
to manage the state of the PCI device. Less chance something
getting left by the wayside by i915 if/when the things change in
drivers/pci.

Cc: Badal Nilawar <badal.nilawar@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-6-ville.syrjala@linux.intel.com
 2025-09-22 19:34:53 +03:00
Ville Syrjälä
03a37f5c3a drm/i915/pm: Do pci_restore_state() in switcheroo resume hook 
Since this switcheroo garbage bypasses all the core pm we
have to manually manage the pci state. To that end add the
missing pci_restore_state() to the switcheroo resume hook.
We already have the pci_save_state() counterpart on the
suspend side.

Arguably none of this code should exist in the driver
in the first place, and instead the entire switcheroo
mechanism should be rewritten and properly integrated into
core pm code...

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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-5-ville.syrjala@linux.intel.com
 2025-09-22 19:34:50 +03:00
Ville Syrjälä
f3d8e898ce drm/i915/pm: Move the hibernate+D3 quirk stuff into noirq() pm hooks 
If the driver doesn't call pci_save_state() drivers/pci will
normally save+power manage the device from the _noirq() pm hooks.

We can't let that happen as some old BIOSes fail to hibernate
when the device is in D3. However, we can get very close to
the standard behaviour by doing our explicit pci_save_state()
and pci_set_power_state() stuff from driver provided _noirq()
hooks.

This results in a change of behaviour where we no longer go
into D3 at the end of freeze_late, so when it comes time
to thaw() we'll already be in D0, and thus we can drop the
explicit pci_set_power_state(D0) call.

Presumably switcheroo suspend will want to go into D3 so
call the _noirq() stuff from the switcheroo suspend hook,
and since we dropped the pci_set_power_state(D0) from
resume_early() we'll need to add one back into the
switcheroo resume hook.

Cc: Rodrigo Vivi <rodrigo.vivi@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-4-ville.syrjala@linux.intel.com
 2025-09-22 19:34:48 +03:00
Ville Syrjälä
cead397a97 drm/i915/pm: Hoist pci_save_state()+pci_set_power_state() to the end of pm _late() hook 
drivers/pci does the pci_save_state()+pci_set_power_state() from
the _noirq() pm hooks. Move our manual calls (needed for the
hibernate vs. D3 workaround with buggy BIOSes) towards that same
point. We currently have no _noirq() hooks, so end of _late()
hooks is the best we can do right now.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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-3-ville.syrjala@linux.intel.com
 2025-09-22 19:34:45 +03:00
Ville Syrjälä
bc412f9a99 drm/i915/pm: Simplify pm hook documentation 
Stop spelling out each variant of the hook ("" vs. "_late" vs.
"_early") and just say eg. "@thaw*" to indicate all of them.
Avoids having to update the docs whenever we start/stop using
one of the variants.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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-2-ville.syrjala@linux.intel.com
 2025-09-22 19:34:39 +03:00
Michał Grzelak
90930b637d drm/i915: rename vlv_get_cck_clock() to vlv_clock_get_cck() 
Keep the convention of naming vlv_clock* instead of vlv_*_clock.

Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://lore.kernel.org/r/20250919215413.1006296-1-michal.grzelak@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-22 12:43:27 +03:00
Suraj Kandpal
c8e8e9ab14 drm/i915/ddi: Guard reg_val against a INVALID_TRANSCODER 
Currently we check if the encoder is INVALID or -1 and throw a
WARN_ON but we still end up writing the temp value which will
overflow and corrupt the whole programmed value.

--v2
-Assign a bogus transcoder to master in case we get a INVALID
TRANSCODER [Jani]

Fixes: 6671c367a9 ("drm/i915/tgl: Select master transcoder for MST stream")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250908042208.1011144-1-suraj.kandpal@intel.com
 2025-09-22 09:38:44 +05:30
Ville Syrjälä
50720b6708 drm/i915/vrr: s/intel_vrr_flipline_offset/intel_vrr_vmin_flipline_offset/ 
Rename intel_vrr_flipline_offset() to intel_vrr_vmin_flipline_offset()
to better reflect the fact that it gives us the minimum offset allowed
between vmin and flipline.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250918232226.25295-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-09-20 03:58:52 +03:00
Ville Syrjälä
fab82f4724 drm/i915/vrr: Hide the ICL/TGL intel_vrr_flipline_offset() mangling better 
ICL/TGL VRR hardware won't allow us to program flipline==vmin. If we do
that the actual effect will be the same as if we had programmed
flipline=vmin+1, which would make the minimum vtotal one scanline taller
than expected.

To compensate for this we reduce vmin by one, and then program
flipline=vmin+1. So we end up with a flipline value that matches
the expected minimum vtotal. Currently this adjustment happens
in intel_vrr_compute_config() which means that crtc_state->vrr.vmin
will no longer be directly usable for the remainder of the high
level VRR code. That is annoying at best, fragile at worst.

Hide the adjustment in low level code instead. This will allow most
of the higher level VRR code to remain blissfully ignorant about this
fact. Afterwards crtc_state->vrr.{vmin,flipline} will be equal
and match the minimum vtotal, exactly how things already work
on ADL+.

The only slight downside is that the actual register value will no
longer match crtc_state->vrr.vmin on ICL/TGL, but that may already
be the case on TGL because the register value will also have been
adjusted by the SCL.

Note that we must change the guardband calculation to account
for intel_vrr_extra_vblank_delay() explicitly. Previously that
was accidentally handled by the earlier vmin reduction by
intel_vrr_flipline_offset().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250918232226.25295-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
 2025-09-20 03:58:33 +03:00
Luca Coelho
db7944458f drm/i915/dmc: explicitly sanitize num_entries from package_header 
num_entries comes from package_header, which is read from an external
firmware blob and thus untrusted.  In parse_dmc_fw_package() we assign
package_header->num_entries to a local variable, but the range check
still uses the struct field directly.

Switch the check to use the local copy instead.  This makes the
sanitization explicit and avoids a redundant dereference.

Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/20250909083042.1292672-1-luciano.coelho@intel.com
 2025-09-19 12:50:56 +03:00
Nemesa Garg
cef58ce505 drm/i915: Soft defeature of cursor size reduction 
From display 14 onward do not enable the cursor
size reduction bit as it has been defeatured.

Bspec: 50372

Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://lore.kernel.org/r/20250813052017.3591331-1-nemesa.garg@intel.com
 2025-09-19 14:07:55 +05:30
Jani Nikula
4c26361cc6 drm/i915/irq: add ilk_display_irq_reset() 
Abstract ilk_display_irq_reset(), moving display related reset
there. This results in a slightly different order between GT and PCH
reset, hopefully with no impact.

v3: Reset display first (Ville)

v2: Also move GEN7_ERR_INT (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250918133835.2412980-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 10:07:23 +03:00
Jani Nikula
a5ef491e90 drm/i915/irq: rename de_irq_mask[] to de_pipe_imr_mask[] 
Rename the struct intel_display de_irq_mask[] member to
de_pipe_imr_mask[] to reflect its usage more accurately.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/55bbf17df871331c2c34af748cf9cf812d6a65d7.1758198300.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 10:07:17 +03:00
Jani Nikula
cb4242e34f drm/i915/irq: rename irq_mask to gen2_imr_mask 
Rename the struct drm_i915_private irq_mask member to gen2_imr_mask to
reflect its usage more accurately.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/2c193663cd3ae524d8159b4216e45462017042fa.1758198300.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 10:07:12 +03:00
Jani Nikula
f2c6777dd9 drm/i915/irq: use a dedicated IMR cache for gen 5-7 
There are three groups of platforms using i915->irq_mask independently:
gen 2-4, VLV/CHV, and gen 5-7.

The gen 5-7 usage is primarily limited to display. Move its irq_mask
usage to struct intel_display as ilk_de_imr_mask for gen 5-7.

ilk_de_imr_mask could be put inside a union with with vlv_imr_mask and
de_irq_mask[], but keep them separate to avoid accidental aliasing of
the values.

With this, we can also drop the irq_mask member from struct xe_device.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/adf60e74b890d52dd20ab4673111ae2063d33b49.1758198300.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 10:07:06 +03:00
Jani Nikula
96b8ccbe7f drm/i915/irq: use a dedicated IMR cache for VLV/CHV 
There are three groups of platforms using i915->irq_mask independently:
gen 2-4, VLV/CHV, and gen 5-7.

The VLV/CHV usage is purely limited to display. Move its irq_mask usage
to struct intel_display as vlv_imr_mask for VLV/CHV.

vlv_imr_mask could be put inside a union with de_irq_mask[], but keep
them separate to avoid accidental aliasing of the values.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/cef6dee8d0b02ff76180c5879f3056e102947a57.1758198300.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 10:06:41 +03:00
Jani Nikula
ffce45f241 drm/i915/fbdev: drop dependency on display in i915 specific code 
This code is in fact i915 driver core rather than display specific. Stop
using struct intel_display, and drop the dependency on display headers.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/a2faad2b47c63ea773a96b2885fb759602374264.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
5c3a68857d drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_fill_info() 
This code is in fact driver core rather than display specific. Pass
struct drm_device instead of struct intel_display.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/1f633154f5f3106f55d7525a711bf347f5635ea7.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
f379035fdf drm/{i915,xe}/fbdev: deduplicate fbdev creation 
With the bo creation helper in place, we can lift
intel_framebuffer_create() part to common code.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/7289deac730a877ab1bfcc467f9d063fdccf3930.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
a170c6ca8b drm/{i915, xe}/fbdev: add intel_fbdev_fb_bo_destroy() 
i915 and xe do different things on the failure path; i915 calls
drm_gem_object_put() while xe calls xe_bo_unpin_map_no_vm(). Add a
helper to enable further refactoring.

v2: Call drm_gem_object_put() on intel_fbdev_fb_bo_destroy()

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/22bc3c3158f5a22ab258ada8684766fdf75fefec.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
ec4dae5e9b drm/xe/fbdev: abstract bo creation 
Separate fbdev bo creation into a separate function
intel_fbdev_fb_bo_create().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/74dfb9f3e6e05a93d54a8ab534e4384145b52571.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
7326099d71 drm/i915/fbdev: abstract bo creation 
Separate fbdev bo creation into a separate function
intel_fbdev_fb_bo_create().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/cb3999ceae43d56e075c28a1f4581169ce457ab0.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
f9ff39f940 drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init 
Pull struct drm_mode_fb_cmd2 initialization out of the driver dependent
code into shared display code.

v2: Rebase on xe stride alignment change

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/e922e47bfd39f9c5777f869ff23c23309ebbb380.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
9e5cf822a2 drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc() 
The function doesn't actually need struct drm_fb_helper for anything,
just pass struct drm_device.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/16360584f80cdc5ee35fd94cfd92fd3955588dfd.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
6979d2c80c drm/i915/fbdev: make intel_framebuffer_create() error return handling explicit 
It's sketchy to pass error pointers via to_intel_framebuffer(). It
probably works as long as struct intel_framebuffer embeds struct
drm_framebuffer at offset 0, but be explicit about it.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/17631db227d527d6c67f5d6b67adec1ff8dc6f8d.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00
Jani Nikula
4a36b339a1 drm/xe/fbdev: use the same 64-byte stride alignment as i915 
For reasons unknown, xe uses XE_PAGE_SIZE alignment for
stride. Presumably it's just a confusion between stride alignment and bo
allocation size alignment. Switch to 64 byte alignment to, uh, align
with i915.

This will also be helpful in deduplicating and unifying the xe and i915
framebuffer allocation.

Link: https://lore.kernel.org/r/aLqsC87Ol_zCXOkN@intel.com
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/7f4972104de8b179d5724ae83892ee294d3f3fd3.1758184771.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
 2025-09-19 09:32:36 +03:00