The struct_mutex will be removed from the DRM subsystem, as it was a
legacy BKL that was only used by i915 driver. After review, it was
concluded that its usage was no longer necessary
This patch updates various comments in the i915 codebase to
either remove or clarify references to struct_mutex, in order to
prevent future misunderstandings.
* i915_drv.h: Removed the statement that stolen_lock is the inner lock
when overlaps with struct_mutex, since struct_mutex is no longer used
in the driver.
* i915_gem.c: Removed parentheses suggesting usage of struct_mutex, which
which is no longer used.
The struct_mutex will be removed from the DRM subsystem, as it was a
legacy BKL that was only used by i915 driver. After review, it was
concluded that its usage was no longer necessary
This patch update a comment about struct_mutex in i915/display, in order
to prevent future misunderstandings.
* intel_fbc.c: Removed the statement that intel_fbc->lock is the inner
lock when overlapping with struct_mutex, since struct_mutex is no
longer used anywhere in the driver.
The struct_mutex will be removed from the DRM subsystem, as it was a
legacy BKL that was only used by i915 driver. After review, it was
concluded that its usage was no longer necessary
This patch updates various comments in the i915/gem and i915/gt
codebase to either remove or clarify references to struct_mutex, in
order to prevent future misunderstandings.
* i915_gem_execbuffer.c: Replace reference to struct_mutex with
vm->mutex, as noted in the eb_reserve() function, which states that
vm->mutex handles deadlocks.
* i915_gem_object.c: Change struct_mutex by
drm_i915_gem_object->vma.lock. i915_gem_object_unbind() in i915_gem.c
states that this lock is who actually protects the unbind.
* i915_gem_shrinker.c: The correct lock is actually i915->mm.obj, as
already documented in its declaration.
* i915_gem_wait.c: The existing comment already mentioned that
struct_mutex was no longer necessary. Updated to refer to a generic
global lock instead.
* intel_reset_types.h: Cleaned up the comment text. Updated to refer to
a generic global lock instead.
Remove the use of struct_mutex from intel_guc_log.c and replace it with
a dedicated lock, guc_lock, defined within the intel_guc_log struct.
The struct_mutex was previously used to protect concurrent access and
modification of intel_guc_log->level in intel_guc_log_set_level().
However, it was suggested that the lock should reside within the
intel_guc_log struct itself.
Initialize the new guc_lock in intel_guc_log_init_early(), alongside the
existing relay.lock. The lock is initialized using drmm_mutex_init(),
which also ensures it is properly destroyed when the driver is unloaded.
drm/i915: Change mutex initialization in intel_guc_log
The intel_guc_log->relay.lock is currently initialized in
intel_guc_log_init_early(), but it lacks a corresponding destructor,
which can lead to a memory leak.
This patch replaces the use of mutex_init() with drmm_mutex_init(),
which ensures the lock is properly destroyed when the driver is
unloaded.
Add a proper function for display && HAS_DISPLAY(display) to hide
indirect struct intel_display access via the macro from a number of
places outside of display. This makes struct intel_display * an opaque
pointer in these places. All HAS_DISPLAY() usage is now constrained
within display.
Jani Nikula [Tue, 2 Sep 2025 17:51:52 +0000 (20:51 +0300)]
drm/{i915,xe}/panic: move framebuffer allocation where it belongs
The struct intel_framebuffer allocation naturally belongs in intel_fb.c,
not hidden inside panic implementation. Separate the panic
allocation. Drop the unnecessary struct i915_framebuffer and struct
xe_framebuffer types.
Jani Nikula [Tue, 2 Sep 2025 17:51:51 +0000 (20:51 +0300)]
drm/{i915,xe}/panic: rename struct {i915,xe}_panic_data to struct intel_panic
Prepare for better shared interfaces between panic implementations. The
struct intel_panic remains an opaque data type, with unique
implementations in i915 and xe.
This allows us to change the panic data pointer from void * to struct
intel_panic *, helping type safety.
Jani Nikula [Tue, 2 Sep 2025 17:51:50 +0000 (20:51 +0300)]
drm/{i915,xe}/fb: add panic pointer member to struct intel_framebuffer
Add a panic data pointer member in struct intel_framebuffer in
preparation for breaking the artificial subclassing between
intel_framebuffer and panic structures.
Jani Nikula [Tue, 2 Sep 2025 17:51:48 +0000 (20:51 +0300)]
drm/{i915,xe}/panic: split out intel_panic.[ch]
intel_bo.[ch] is not the appropriate location for the panic
functionality. Split out intel_panic.[ch] and xe_panic.c in i915 and
xe. Keep the function names for now.
Uma Shankar [Thu, 4 Sep 2025 09:53:38 +0000 (15:23 +0530)]
drm/i915/display: Remove FBC modulo 4 restriction for ADL-P+
WA:22010751166 does not apply past display version 12. Or, in
other words, the FBC restriction where FBC is disabled for
non-modulo 4 plane sizes (including plane size + yoffset) is fixed
from display version 13 and onwards. Relax the restriction for the same.
v4: Dropped redundant commit message
v3: Update comments for clarity (Jonathan Cavitt)
v2: Update the macro for display version check (Vinod)
Suggested-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://lore.kernel.org/r/20250904095338.300813-2-uma.shankar@intel.com
For ternary operators in the form of "a ? false : true", if 'a' itself
returns a boolean result, the ternary operator can be omitted. Remove
redundant ternary operators to clean up the code.
Jani Nikula [Wed, 3 Sep 2025 10:10:50 +0000 (13:10 +0300)]
drm/i915/ddi: abstract figuring out encoder name
The encoder name deduction has become a bit cumbersome within
intel_ddi_init(). Split it out to a separate function to declutter
intel_ddi_init(), even if that means having to use a temp seq buffer for
the name.
Jani Nikula [Fri, 5 Sep 2025 10:41:49 +0000 (13:41 +0300)]
drm/i915/power: fix size for for_each_set_bit() in abox iteration
for_each_set_bit() expects size to be in bits, not bytes. The abox mask
iteration uses bytes, but it works by coincidence, because the local
variable holding the mask is unsigned long, and the mask only ever has
bit 2 as the highest bit. Using a smaller type could lead to subtle and
very hard to track bugs.
Fixes: 62afef2811e4 ("drm/i915/rkl: RKL uses ABOX0 for pixel transfers") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org # v5.9+ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250905104149.1144751-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
drm/i915/psr: Add poll for checking PSR is idle before starting update
We are currently observing crc failures after we started using dsb for PSR
updates as well. This seems to happen because PSR HW is still sending
couple of updates using old framebuffers on wake-up.
Fix this by adding poll ensuring PSR is idle before starting update.
v2: pass new_crtc_state->dsb_commit to intel_psr_wait_for_idle_dsb
drm/i915/psr: New interface adding PSR idle poll into dsb commit
We are currently observing crc failures after we started using dsb for PSR
updates as well. This seems to happen because PSR HW is still sending
couple of updates using old framebuffers on wake-up.
This patch is preparing to fix that by adding interface which can be used
to add poll ensuring PSR HW is idle into dsb commit.
v3: add intel_dsb as a parameter to intel_psr_wait_for_idle_dsb
v2: add pass crtc_state->dsb_commit as parameter
if __waitfor timeout, ret will have -ETIMEDOUT. Then if condition
was met, and read_ret will have error that's handled.
Then if ret was zero, read_ret was zero ksv_ready must have value.
Ville Syrjälä [Tue, 2 Sep 2025 13:31:13 +0000 (16:31 +0300)]
drm/i915/dram: Print memory details even if something went wrong
Print the memory details even if the detection failed in some way
but we continued the driver initialization anyway. It'll be easier
to debug issues if we at least know what the final results were.
And while at it also print the number of PSF GV points. Previously
we only printed the QGV points.
Ville Syrjälä [Tue, 2 Sep 2025 13:31:12 +0000 (16:31 +0300)]
drm/i915/dram: Don't call skl_get_dram_info()/skl_get_dram_type() on icl
Currently the icl codepaths first determine the memory type from the
memory controller registers (via skl_get_dram_info()->skl_get_dram_type())
and then overwrite the results with icl_pcode_read_mem_global_info().
Get rid of the pointless (and potentially incorrect) skl_get_dram_type()
stuff.
Ville Syrjälä [Tue, 2 Sep 2025 13:31:11 +0000 (16:31 +0300)]
drm/i915/dram: Fix some spelling around the 16Gb DIMM w/a
Use consistent spelling when talking about the 16Gb DIMM w/a.
Even currently language is a bit off as the w/a is actually
about DIMMs with 16Gb DRAM devices on them, not the total capacity
of the whole DIMM. But this language does more or less match how
Bspec talks about this stuff.
Ville Syrjälä [Tue, 2 Sep 2025 13:31:10 +0000 (16:31 +0300)]
drm/i915/dram: Move 16Gb DIMM detection fully to the skl/icl codepaths
We are incorrectly applying the 16Gb DIMM w/a (adding 1 extra
usec to WM0 latency) on MTL+ even though the w/a is only needed
for SKL/ICL.
The current way of setting this is up is a bit of a disaster:
1. always set has_16gb_dimms=true for all platforms except BXT/GLK
2. has_16gb_dimms potentially gets overwritten with something else
* BXT/GLK don't do anything since we never set has_16gb_dimms to
begin with
* skl_get_dram_info() overwrites has_16gb_dimms with the actual
detection results for SKL/ICL/derivatives
* gen12_get_dram_info() (correctly) resets has_16gb_dimms
for TGL/ADL/derivatives
* xelpdp_get_dram_info() doesn't do anything, leaving
has_16gb_dimms incorrectly set for MTL+
Clean up the whole mess by only setting has_16gb_dimms in the
SKL/ICL codepaths where we have the actual detection code for
it. This avois applying the w/a incorrectly on MTL+.
Ville Syrjälä [Tue, 2 Sep 2025 13:31:09 +0000 (16:31 +0300)]
drm/i915/dram: s/wm_lv0.../has_16gb_dimms/
The DRAM code shouldn't know anything about watermarks. Rename
wm_lv_0_adjust_needed to has_16gb_dimms. How this gets used is
up to the watermark code.
Imre Deak [Wed, 3 Sep 2025 12:21:52 +0000 (15:21 +0300)]
drm/i915/display: Remove power state verification before HW readout
During system resume the display power state verification will print the
"power well x state mismatch (refcount 0/enabled 1)"
error message from the early resume sequence for a power well left
enabled by BIOS. This power well was probably left enabled by BIOS
inadvertently, since BIOS versions on current platforms do not leave any
display output enabled while resuming from an Sx power state, hence the
enabled display power well is unused. In theory however it is possible
that BIOS leaves a display output enabled, in that case the enabled
power well shouldn't be reported as an error.
According to the above, remove the display power state verification from
the early resume phase to avoid incorrectly reporting an enabled power
well without a power reference as an error.
Note: The refcount for any enabled and used power well (i.e. used for an
enabled display output) will be acquired following the early resume
sequence, after the HW state for display outputs (encoder/crtc etc.) is
read out. Any power well enabled but not used (hence not holding a
reference) will be disabled after the HW state readout. The display
power state will be verified afterwards in intel_power_domains_enable().
Jani Nikula [Thu, 28 Aug 2025 12:21:01 +0000 (15:21 +0300)]
drm/i915/ddi: prefer poll_timeout_us() over readx_poll_timeout()
Unify on using poll_timeout_us() throughout instead of mixing with
readx_poll_timeout(). While the latter can be ever so slightly simpler,
they are both complicated enough that it's better to unify on one
approach only.
While at it, better separate the handling of error returns from
drm_dp_dpcd_readb() and the actual status byte. This is best achieved by
inlining the read_fec_detected_status() function, and switching to
drm_dp_dpcd_read_byte().
Jani Nikula [Thu, 28 Aug 2025 12:20:48 +0000 (15:20 +0300)]
drm/i915/gmbus: use generic poll_timeout*() instead of wait_for*()
Prefer generic poll helpers over i915 custom helpers.
The "two tier" wait_for_us() + wait_for() combination appeared without
much explanation in commit 4e6c2d58ba86 ("drm/i915: Take forcewake once
for the entire GMBUS transaction"). Try to mimic roughly the same with
the generic helpers.
wait_for_us() with 10 us or shorter timeouts ends up in
_wait_for_atomic(). Thus use poll_timeout_us_atomic() for the first try,
with the same 2 us timeout and no sleep.
For the fallback, the functional change is losing the exponentially
growing sleep of wait_for(), which used to be 10, 20, 40, ..., 640, and
1280 us. Use an arbitrary constant 500 us sleep instead. The timeout
remains at 50 ms.
Luca Coelho [Wed, 27 Aug 2025 10:12:06 +0000 (13:12 +0300)]
drm/i915: use REG_BIT on FW_BLC_SELF_* macros
Use REG_BIT() instead of open coding the shift in the FW_BLC_SELF_*
macro definitions to avoid potentially typing them as 'int'.
For example, this happens when we pass them to _MASKED_BIT_ENABLE(),
because of the typeof() construct there. When we pass 1 << 15 (the
FW_BLC_SELF_EN macro), we get typeof(1 << 15), which is 'int'. Then
the value becomes negative (-2147450880) and we try to assign it to a
'u32'.
In practice this is not a problem though, because when we try to
assign -2147450880 to the u32, that becomes 0x80008000, which was the
intended result.
Mika Kahola [Fri, 29 Aug 2025 10:12:26 +0000 (13:12 +0300)]
drm/i915/display: Fix possible overflow on tc power domain selection
There is a possibility that intel_encoder_to_tc() function
returns negative i.e. TC_PORT_NONE (-1) value which may cause
tc_port_power_domain() function to overflow. To fix this,
let's add additional check that returns invalid power domain
i.e. POWER_DOMAIN_INVALID in case tc port equals TC_PORT_NONE.
Lee Shawn C [Mon, 1 Sep 2025 05:57:21 +0000 (05:57 +0000)]
drm/i915: compute pipe bpp from link bandwidth management
Since intel_fdi_compute_pipe_bpp() is no longer FDI-specific and
now applies to all connectors. Move it to intel_link_bw.c,
and rename to intel_link_bw_compute_pipe_bpp().
v2: Remove unused header file.
Cc: Shankar Uma <uma.shankar@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
[Imre: Remove unused intel_fdi.h include from intel_hdmi.c] Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250901055721.219995-3-shawn.c.lee@intel.com
Lee Shawn C [Mon, 1 Sep 2025 05:57:20 +0000 (05:57 +0000)]
drm/i915/hdmi: add debugfs to contorl HDMI bpc
While performing HDMI compliance testing, test equipment may request
different bpc output for signal measurement. However, display driver
typically determines the maximum available bpc based on HW bandwidth.
This change leverages the existing debugfs (intel_force_link_bpp)
to manage HDMI bpc, and making it easier to pass HDMI CTS.
v2: Using exist variable max_requested_bpc.
v3: Extend intel_force_link_bpp to support HDMI as suggested by Imre.
v4: Update commit message suggested by Jani.
v5: Remove unused header file.
Cc: Shankar Uma <uma.shankar@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250901055721.219995-2-shawn.c.lee@intel.com
Suraj Kandpal [Tue, 19 Aug 2025 15:07:29 +0000 (20:37 +0530)]
drm/i915/hdcp: Remove the encoder check in hdcp enable
Remove the intel_encoder NULL check from _intel_hdcp_enable. With
all the changes it has gone through this check has become unnecessary
since at this point the connector is supposed to have the encoder
in it.
Ville Syrjälä [Tue, 26 Aug 2025 12:18:59 +0000 (15:18 +0300)]
iopoll: Reorder the timeout handling in poll_timeout_us()
Currently poll_timeout_us() evaluates 'op' and 'cond' twice
within the loop, once at the start, and a second time after
the timeout check. While it's probably not a big deal to do
it twice almost back to back, it does make the macro a bit messy.
Simplify the implementation to evaluate the timeout at the
very start, then follow up with 'op'/'cond', and finally
check if the timeout did in fact happen or not.
For good measure throw in a compiler barrier between the timeout
and 'op'/'cond' evaluations to make sure the compiler can't reoder
the operations (which could cause false positive timeouts).
The similar i915 __wait_for() macro already has the barrier, though
there it is between the 'op' and 'cond' evaluations, which seems
like it could still allow 'op' and the timeout evaluations to get
reordered incorrectly. I suppose the ktime_get() might itself act
as a sufficient barrier here, but better safe than sorry I guess.
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: David Laight <david.laight.linux@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Matt Wagantall <mattw@codeaurora.org> Cc: Dejin Zheng <zhengdejin5@gmail.com> Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250826121859.15497-3-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 26 Aug 2025 12:18:58 +0000 (15:18 +0300)]
iopoll: Avoid evaluating 'cond' twice in poll_timeout_us()
Currently poll_timeout_us() evaluates 'cond' twice at the end
of the success case. This not desirable in case 'cond' itself
is expensive.
Avoid the double evaluation by tracking the return value in
a variable. Need to use a triple undescore '___ret' name to
avoid a conflict with an existing double undescore '__ret'
variable in the regmap code.
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: David Laight <david.laight.linux@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Matt Wagantall <mattw@codeaurora.org> Cc: Dejin Zheng <zhengdejin5@gmail.com> Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250826121859.15497-2-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 26 Aug 2025 12:18:57 +0000 (15:18 +0300)]
iopoll: Generalize read_poll_timeout() into poll_timeout_us()
While read_poll_timeout() & co. were originally introduced just
for simple I/O usage scenarios they have since been generalized to
be useful in more cases.
However the interface is very cumbersome to use in the general case.
Attempt to make it more flexible by combining the 'op', 'var' and
'args' parameter into just a single 'op' that the caller can fully
specify.
For example i915 has one case where one might currently
have to write something like:
ret = read_poll_timeout(drm_dp_dpcd_read_byte, err,
err || (status & mask),
0 * 1000, 200 * 1000, false,
aux, DP_FEC_STATUS, &status);
which is practically illegible, but with the adjusted macro
we do:
ret = poll_timeout_us(err = drm_dp_dpcd_read_byte(aux, DP_FEC_STATUS, &status),
err || (status & mask),
0 * 1000, 200 * 1000, false);
which much easier to understand.
One could even combine the 'op' and 'cond' parameters into
one, but that might make the caller a bit too unwieldly with
assignments and checks being done on the same statement.
This makes poll_timeout_us() closer to the i915 __wait_for()
macro, with the main difference being that __wait_for() uses
expenential backoff as opposed to the fixed polling interval
used by poll_timeout_us(). Eventually we might be able to switch
(at least most of) i915 to use poll_timeout_us().
v2: Fix typos (Jani)
Fix delay_us docs for poll_timeout_us_atomic() (Jani)
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: David Laight <david.laight.linux@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Matt Wagantall <mattw@codeaurora.org> Cc: Dejin Zheng <zhengdejin5@gmail.com> Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://lore.kernel.org/r/20250826121859.15497-1-ville.syrjala@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jouni Högander [Tue, 26 Aug 2025 07:44:57 +0000 (10:44 +0300)]
drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked
PSR work is using __psr_wait_for_idle_locked to ensure PSR exit is
completed before continuing to PSR activation. __psr_wait_for_idle_locked
is unlocking PSR mutex which allows PSR disable/enable and PSR
pause/resume while PSR idle is being wait. PSR enable status is already
checked after locking again PSR mutex but PSR pause counter check is
missing. Due to this PSR work may continue to PSR activation even PSR is
paused.
Fix this by checking PSR pause counter in __psr_wait_for_idle_locked after
PSR mutex is locked again.
Jouni Högander [Thu, 21 Aug 2025 04:59:17 +0000 (07:59 +0300)]
drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init
Currently we are ignoriong drm_dp_dpcd_read return values when reading PSR
and Panel Replay capability DPCD register. Rework intel_psr_dpcd a bit to
take care of checking the return value.
Suraj Kandpal [Thu, 21 Aug 2025 04:26:53 +0000 (09:56 +0530)]
drm/i915/edp: eDP Data Overrride
We need override certain link rates in favour of the next available
higher link rate. The Link rates that need to be overridden are
indicated by a mask in VBT. To make sure these modes are skipped we
don't add them in them in the sink rates array.
--v2
-Update the link rates after we have a final set of link rates [Ankit]
-Break this patch up [Ankit]
-Optimize the assingment during loop [Ankit]
--v3
-Add protection against broken VBTs [Jani]
--v4
-Fix build errors
-Create a seprate function to check if edp data override is selected
and using the correct vbt
--v5
-Use correct number to check the num of edp rates [Ankit]
--v6
-No seprate function check if vbt is broken in the reject rate function
[Jani]
Suraj Kandpal [Thu, 21 Aug 2025 04:26:52 +0000 (09:56 +0530)]
drm/i915/bios: Add function to check if edp data override is needed
Add a function that helps identify if the rate provided needs to
be overridden. For this we need a function that compares the rate
provided and bitmask of rates provided in VBT.
--v2
-Rename functions [Jani]
-Return the mask instead of parsing it in function [Jani]
-Move the declaration in header [Jani]
--v3
-Change function name to depict what the function does [Ankit]
Jouni Högander [Fri, 15 Aug 2025 08:45:34 +0000 (11:45 +0300)]
drm/i915/psr: Check pause counter before continuing to PSR activation
Currently intel_psr_work is re-activating PSR even when pause_counter > 0
which is incorrect. Fix this by checking pause_counter before re-activating
PSR.
Jouni Högander [Mon, 19 May 2025 07:52:23 +0000 (10:52 +0300)]
drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed vblank
Underrun on idle PSR workaround (Wa_16025596647) is supposed to be
applied only when pkg c latency > delayed vblank. Currently we are
applying it always when other criterias are met.
Fix this by adding new boolean flag which is supposed to be set when
calculating watermark levels and pkgc latency > delayed vblank is
detected. currently this scenario is blocked but might be added
later. Due to this add also TODO comment into
skl_max_wm_level_for_vblank.
Jani Nikula [Mon, 18 Aug 2025 10:07:27 +0000 (13:07 +0300)]
drm/i915/dram: bypass fsb/mem freq detection on dg2 and no display
Non-display now calls the intel_fsb_freq() and intel_mem_freq()
functions, so we don't have to have the frequencies initialized for dg2
or non-display cases.
This is in preparation for unifying the pre-gen9 handling in dram info.
DG2 remains a special case as described in commit 5eb6bf0b44e7
("drm/i915/dg2: Don't read DRAM info").
Jani Nikula [Mon, 18 Aug 2025 07:16:05 +0000 (10:16 +0300)]
drm/i915/switcheroo: check for NULL before dereferencing
Both i915_switcheroo_set_state() and i915_switcheroo_can_switch() check
for i915 == NULL. Commit d2e184f8e16a ("drm/i915/switcheroo: pass
display to HAS_DISPLAY()") started dereferencing it before the NULL
check. Fix it.
Fixes: d2e184f8e16a ("drm/i915/switcheroo: pass display to HAS_DISPLAY()") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202508160035.hmzuKiww-lkp@intel.com/ Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250818071605.2541523-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Update intel_dp_compute_config_limits() to use a minimum of
30 bits per pixel when the connector is in HDR mode
(specifically, when EOTF is SMPTE ST2084), aligning with HDR
display requirements.
To support this, the function now takes a drm_connector_state
instead of an intel_connector, and the required updates are
made in all call sites, including MST handling.
This ensures sufficient bitdepth for HDR content to avoid
banding.
If the required bandwidth for 30 bpp cannot be supported,
the driver will either fall back to DSC or reject the mode
during atomic check if DSC is not supported.
drm/i915/dp: Refactor intel_dp_in_hdr_mode() for broader reuse
The intel_dp_in_hdr_mode() helper was previously defined in
intel_dp_aux_backlight.c but is generally useful beyond that
context. Move the function to intel_dp.c and declare it in
intel_dp.h to make it accessible to other DP-related code
paths that need to check HDR metadata state.
This is a pure refactor with no functional change and
prepares for a follow-up patch that uses this helper.
Jani Nikula [Fri, 1 Aug 2025 12:28:32 +0000 (15:28 +0300)]
drm/i915/audio: drop irq enabled check from LPE audio setup
There shouldn't be anything requiring irqs to be enabled at the point of
LPE audio setup. Regardless, we've never hit the warning, as irqs are
always enabled at the time LPE audio is initialized. Drop the
superfluous warning, and the dependency on i915_drv.h.
Jani Nikula [Wed, 6 Aug 2025 16:55:16 +0000 (19:55 +0300)]
drm/i915/display: drop __to_intel_display() usage
All the places that use __to_intel_display() now get passed a struct
intel_display pointer, and the transitional adaptation macro has served
its purpose. Remove the macro.
Jani Nikula [Wed, 6 Aug 2025 16:55:15 +0000 (19:55 +0300)]
drm/i915/reg: separate VLV_DSPCLK_GATE_D from DSPCLK_GATE_D
All the places that use DSPCLK_GATE_D are specific to certain platforms,
and the parametrization of it to support VLV/CHV MMIO display base isn't
really buying us anything. Add a separate macro for VLV_DSPCLK_GATE_D
and use it.
projects / users / hch / misc.git / log