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>
Currently our crtc_state->vrr.{vmin.vmax,flipline} are mangled on
TGL to account for the SCL delay (the hardware requires this mangling
or the actual vtotals will become incorrect). Unfortunately this
means that one can't simply use these values directly in many places,
and instead we always have to go through functions that undo the
damage first. This is all rather fragile.
Simplify our lives a bit by hiding this mangling deeper inside
the low level VRR code, leaving the number stored in the crtc
state actually something that humans can use.
This does introduce a dependdency as intel_vrr_get_config()
will now need to know the SCL value, which is read out in
intel_get_transcoder_timings(). I suppose we could simply
duplicate the SCL readout in both places should this become
a real hinderance. For now just leave a note around the
intel_get_transcoder_timings() call to remind us.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250917203446.14374-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
intel_vrr_fixed_rr_*() return values that have had the TGL
SCL adjustment applied to them. So we should indicate that these
values are only really useful when fed to the hardware. Add
a "_hw_" indicator to the function names to reflect that fact.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250917203446.14374-5-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
While ICL/TGL VRR hardware doesn't have a register for the guardband
value, our lives will be simpler if we pretend that it does. Start
by computing the guardband the same as on ADL+ and storing it in
the state, and only then we convert it into the corresponding
pipeline_full value that the hardware can consume. During readout we
do the opposite.
I was debating whether to completely remove pipeline_full from the
crtc state, but decided to keep it for now. Mainly because we check
it in vrr_params_changed() and simply checking the guardband instead
isn't 100% equivalent; Theoretically, framestart_delay may have
changed in the opposite direction to pipeline_full, keeping the
derived guardband value unchaged. One solution would be to also check
framestart_delay, but that feels a bit leaky abstraction wise.
Also note that we don't currently handle the maximum limit of 255
scanlines for the pipeline_full in a very nice way. The actual
position of the delayed vblank will move because of that clamping,
and so some of our code may get confused. But fixing this shall
wait a for now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250917203446.14374-4-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
In order to pretend that ICL/TGL VRR hardware has a similar guardband
as on ADL+ we'll need access to framestart_delay already during
intel_vrr_get_config(). Hoist the framestart_delay to an earlier point
to make that possible.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250917203446.14374-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
I'd like to move towards a world where we can't more or less
pretend that the ICl/TGL VRR hardware works the same way as
ADL+. To that end extract some helpers to convert between
the guardband and pipeline_full representations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250917203446.14374-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
DRRS has been defeatured on LNL+. Adjust HAS_DOUBLE_BUFFERED_M_N()
to match.
Note that the M/N registers still appear to be double buffered under
the hood but the double buffer update point is now documented to be
just the last register write to the M/N registers, so it no longer
happens synchronously with the vblank/MSA transmission. We should
perhaps rename HAS_DOUBLE_BUFFERED_M_N() to more accurately reflect
reality, but couldn't come up with a decent name right now...
Bspec: 68917
HSD: 14016007525
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250912135926.18910-1-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
intel_vgpu_gpa_to_mmio_offset states that it returns
'Zero on success, negative error code if failed'
in the kernel docs.
This is false. The function actually returns
'The MMIO offset of the given GPA'.
Correct the docs.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250916174317.76521-6-jonathan.cavitt@intel.com
The reg >= 0 check in reg_is_mmio is unnecessary because reg is always
greater than zero in all current use cases. This is obvious when
checking 'offset' by itself (as offset is defined as an unsigned
integer), but it's also true for the offset + bytes - 1 use case in
intel_vgpu_emulate_mmio_read because bytes > 0.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250916174317.76521-5-jonathan.cavitt@intel.com
The caching at the initial read is a bit fragile in case, say, a further
refactoring starts reading the frequencies at a time where it's not
possible. Add a note about it.
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/20250917135200.1932903-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Getter for LFPS cycle min/max times is unnecessarily checking faulty port
clock value. This doesn't make sense as erroneous port clock value would
have been noticed already at this point. Remove this check and use 140/800
ns always when port clock > 540000.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250912064035.335329-1-jouni.hogander@intel.com
Perhaps not the ideal place, but better than having to have the fields
in both struct drm_i915_private and struct xe_device.
v2: Rebase
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/cbca9b13f2235a624a21bf7617ffe763e25c848c.1757688216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With vlv_clock_get_czclk() caching the result on first use, we no longer
need a separate initializer. Remove intel_update_czclk() as
unnecessary. Log the CZCLK in vlv_clock_get_czclk() instead.
v2: Rebase
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/3f90b5e67258f485db09b6f48381682cbd96153f.1757688216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use vlv_clock_get_hpll_vco() helper more to avoid looking at
i915->hpll_freq directly. Cache and return the cached results to avoid
repeated lookups.
v2: Rebase
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/14695618682d8d8fad1adc485de7a122c8e1494a.1757688216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add vlv_clock_get_cdclk() helper to hide the details from the callers.
For now, this means running vlv_get_hpll_vco() twice in vlv_get_cdclk(),
but this will be improved later.
v2: Rebase
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/fc93ccf998300048432d18ce7e8690bd54e1e18d.1757688216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move towards VLV/CHV clock interfaces that handle sideband get/put
inside them instead of at the caller.
With this, we can switch to the simpler vlv_punit_get()/vlv_punit_put()
in vlv_get_cdclk().
We'll need to move vlv_init_gpll_ref_freq() outside of the existing
get/put in vlv_rps_init() and chv_rps_init().
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/480b654b6c736a03343dfd17eb130c39fd82c637.1757688216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move towards VLV/CHV clock interfaces that handle sideband get/put
inside them instead of at the caller.
We'll need to move the calls outside of existing get/put.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/1a6553f54619275aa05512421e19115a71cd3eb0.1757688216.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The checks in plane_has_modifier() should check against display version
instead of graphics version.
Bspec: 67165, 70815
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://lore.kernel.org/r/20250903170821.310143-1-matthew.s.atwood@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Move waiting related utilities from i915_utils.h to separate new file
i915_wait_util.h. Clean up related includes.
Note: Many of the various wait macro usages could likely be refactored
to use poll_timeout_us().
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/431396ac8cdb3e2f4ff053a8933290289a66ce42.1757582214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move list related utilities from i915_utils.h to separate new file
i915_list_util.h. Clean up related includes.
Note: Arguably none of this should exist in i915 in the first place. At
least isolate it better.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/d7526809735194137116682f37cfa126a6a87ec9.1757582214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move timer related utilities from i915_utils.[ch] to separate new files
i915_timer_util.[ch]. Clean up related includes.
Note: Arguably none of this should exist in i915 in the first place. At
least isolate it better.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/0a83d9489626121dcefcd4c1a05317399b5708f3.1757582214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The VESA AUX backlight fails to be enable luminance based backlight
mainpulation becaused luminance_set is false by default.
Fix it by using luminance support control capabitliy.
Fixes: e13af5166a ("drm/i915/backlight: Use drm helper to initialize edp backlight")
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250823121647.275834-1-aaron.ma@canonical.com
This patch completes the removal of struct_mutex from the driver.
Remove the related TODO item, as the transition away from struct_mutex
is now complete.
Also clean up references to struct_mutex in i915.rst to avoid outdated
documentation.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-10-luiz.mello@estudante.ufscar.br
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The struct_mutex field in drm_i915_private is no longer used anywhere in
the driver. This patch removes it completely to clean up unused code and
avoid confusion.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-9-luiz.mello@estudante.ufscar.br
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-8-luiz.mello@estudante.ufscar.br
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-7-luiz.mello@estudante.ufscar.br
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-6-luiz.mello@estudante.ufscar.br
Acked-by: Tvrtko Ursulin <tursulin@ursulin.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-5-luiz.mello@estudante.ufscar.br
Acked-by: Tvrtko Ursulin <tursulin@ursulin.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-4-luiz.mello@estudante.ufscar.br
Acked-by: Tvrtko Ursulin <tursulin@ursulin.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Remove struct_mutex from ivb_parity_work() function.
The ivb_parity_work runs in a workqueue so it cannot race with itself.
Also, it is not protecting anything with the other remaining usage of
struct_mutex.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-3-luiz.mello@estudante.ufscar.br
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Move legacy BKL struct_mutex from drm_device to drm_i915_private, which
is the last remaining user.
Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250908131518.36625-2-luiz.mello@estudante.ufscar.br
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250903090408.3492875-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We just return when using luminance control instead we should be
calling the disable helper to get everything cleaned up properly
by default.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://lore.kernel.org/r/20250904044804.948391-1-suraj.kandpal@intel.com
Move the range_overflows() and range_end_overflows() along with the _t
variants over from drm/i915 and drm/buddy to overflow.h.
Cc: Kees Cook <kees@kernel.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: linux-hardening@vger.kernel.org
Reviewed-by: Kees Cook <kees@kernel.org>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250829174601.2163064-3-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Rename range_overflows_end() to range_end_overflows(), along with the _t
variant.
It's all rather subjective, but I think range_end_overflows() reads
better.
Cc: Kees Cook <kees@kernel.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: linux-hardening@vger.kernel.org
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20250829174601.2163064-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_panic_finish() function really needs the struct intel_panic
pointer, not struct intel_framebuffer. Make it so.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/3fdbcbe17e0e90c4a590f2a2486a9ec79a90cf62.1756835342.git.jani.nikula@intel.com
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.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/d29f63e0118d002fc8edd368caea7e8185418e17.1756835342.git.jani.nikula@intel.com
