Inactive crtcs are supposed to have their crtc_state completely
cleared. Currently we are clobbering crtc_state->cpu_transcoder
before determining whether it's actually enabled or not. Don't
do that.
I want to rework the inherited flag handling for inactive crtcs
a bit, and having a bogus cpu_transcoder in the crtc state can
then cause confusing fastset mismatches even when the crtc never
changes state during the commit.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250306163420.3961-3-ville.syrjala@linux.intel.com
The compat i915_drv.h contains things that aren't there in the original
i915_drv.h. Split out gem/i915_gem_object.h and i915_scheduler_types.h,
moving the corresponding pieces out, including FORCEWAKE_ALL to
intel_uncore.h.
Technically I915_PRIORITY_DISPLAY should be in i915_priolist_types.h,
but it's a bit overkill to split out another file just for
that. i915_scheduler_types.h shall do.
With this, the compat i915_drv.h becomes a strict subset of the
original.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d6bd95bf52aa37f48ddec3e675b7a3cc66829eef.1741192597.git.jani.nikula@intel.com
[Jani: fix i915_gem_object.h header guard while applying]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We currently call intel_set_cdclk_post_plane_update() far
too early. When pipes are active during the reprogramming
the current spot only works for the cd2x divider update
case, as that is synchronize to the pipe's vblank. Squashing
and crawling are not synchronized in any way, so doing the
programming while the pipes/planes are potentially still using
the old hardware state could lead to underruns.
Move the post plane reprgramming to a spot where we know
that the pipes/planes have switched over the new hardware
state.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250218211913.27867-2-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
The callback fb_probe in struct drm_fb_helper is unused. Remove it.
New drivers should set struct drm_driver.fbdev_probe instead and call
drm_client_setup() to instantiate in-kernel DRM clients.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-13-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
If fbdev support has been disabled, no output will be shown. Remove
the fbdev-related compile guard from the driver's debugfs code.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-12-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Rework fbdev probing to support fbdev_probe in struct drm_driver
and remove the old fb_probe callback. Provide an initializer macro
that sets the callback in struct drm_driver according to the kernel
configuration. Call drm_client_setup_with_color_mode() to run the
kernel's default client setup for DRM.
This commit also prepares support for the kernel's drm_log client
(or any future client) in i915. Using drm_log will also require vmap
support in GEM objects.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-11-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Move fbdev code around in the source file before switching to DRM's
generic fbdev client. This will make the conversion less intrusive.
No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-10-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Store instances of drm_fb_helper and struct intel_fbdev separately.
This will allow i915 to use the common fbdev client, which allocates
its own instance of struct drm_fb_helper.
There is at most one instance of type each per DRM device, so both can
be referenced directly from the i915 and DRM device structures. A later
patchset might rework the common fbdev client to allow for storing
both, drm_fb_helper and intel_fbdev, together in the same place.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-9-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
The value preferred_bpp in struct intel_fbdev duplicates preferred_bpp
in struct drm_fb_helper. Remove the former.
Instead let intel_fbdev_init_bios() read the framebuffer from the
hardware. Then derive preferred_bpp from its format and initialize
struct drm_fb_helper with the value. The default is 32 (i.e., XRGB8888).
Also removes one of those deprecated references to the cpp field of
struct drm_format_info.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-8-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
If the fbdev buffer is backed by stolen memory, it has to be cleared
upon resume from hibernation. Move the code into the new callback
fb_set_suspend, so that it can run from DRM's generic fbdev client.
No functional change. Other drivers are not affected.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-7-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
i915's fbdev contains code for restoring the client's framebuffer. It
is specific to i195 and cannot be ported to the common fbdev client.
Introduce the callback struct drm_fb_helper.fb_restore and implement
it for i915. The fbdev helpers invoke the callback after restoring the
fbdev client.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-6-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
The DRM client code already tracks suspend status and hotplug events
for each client. Remove similar code from i915's fbdev client.
Allows for the removal of all hdp_* fields form struct intel_fbdev.
Calls to intel_fbdev_output_poll_changed() are reduced the shared
helper drm_fb_helper_hotplug_event().
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-5-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
If a hotplug event arrives while the client has been suspended,
DRM's client code will deliver the event after resuming. The
functionality has been taken form i915, where it can be removed
by a later commit.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-4-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Move client hotplug calls to drm_client_hotplug(). We'll need this
helper to send hotplug events after resuming.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-3-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Implement drm_client_dev_suspend() and drm_client_dev_resume() for
i915's fbdev emulation and call the helper via DRM client interfaces.
This is required to convert i915 and xe to DRM's generic fbdev client.
No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241212170913.185939-2-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
FBDEV ggtt is not restored correctly, add missing GGTT flag to
intel_fbdev_fb_alloc to make it work. This ensures that the global
GGTT mapping is always restored on resume. The GGTT mapping would
otherwise be created in intel_fb_pin_to_ggtt() by intel_fbdev anyway.
This fixes the fbdev device not working after resume.
Fixes: 67a98f7e27 ("drm/xe/display: Re-use display vmas when possible")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250305110106.564366-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Since commit d59cf7bb73 ("drm/i915/display: Use dma_fence interfaces
instead of i915_sw_fence") we don't have anyone waiting on the
I915_RESET_MODESET bit, and there's no need for its semantics. Instead,
simply return true from intel_display_reset_prepare() to indicate that
intel_display_reset_finish() should be called.
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/294690db3fae8fec7f356edf467e79882ed494db.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add a helper for checking if we want to test display reset regardless of
whether it's strictly necessary. This will come in handy in follow-up
work where we want to check this from gt reset side.
v2: Drop superfluous newline
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/487dec72f753302cd565c3a8164afa7fc1e12ed7.1741001054.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During enabling FBC, for the very first frame, the prepare dirty
rect routine wouldnt have executed as at that time the plane
reference in the fbc_state would be NULL. So this could make
driver program some invalid entries as the damage area. Though
fbc hw ignores the dirty rect values programmed for the first
frame after enabling FBC, driver must ensure that valid dirty
rect coords are programmed. So ensure that for the first frame
correct dirty rect coords are updated to the HW.
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-10-vinod.govindapillai@intel.com
It is not recommended to have both FBC dirty rect and PSR2
selective fetch be enabled at the same time. Mark FBC as not
possible, if PSR2 selective fetch is enabled.
v2: fix the condition to disable FBC if PSR2 enabled (Jani)
v3: use HAS_FBC_DIRTY_RECT()
v4: Update to patch description
Bspec: 68881
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-9-vinod.govindapillai@intel.com
Dirty rectangle feature allows FBC to recompress a subsection
of a frame. When this feature is enabled, display will read
the scan lines between dirty rectangle start line and dirty
rectangle end line in subsequent frames.
Use the merged damage clip stored in the plane state to
configure the FBC dirty rect areas.
v2: - Move dirty rect handling to fbc state (Ville)
v3: - Use intel_fbc_dirty_rect_update_noarm (Ville)
- Split plane damage collection and dirty rect preparation
- Handle case where dirty rect fall outside the visible region
v4: - A state variable to check if we need to update dirty rect
registers in case intel_fbc_can_flip_nuke() (Ville)
v5: - No need to use a separate valid flag, updates to the
conditions for prepare damage rect (Ville)
- Usage of locks in fbc dirty rect related functions (Ville)
v6: - updates dirty rect handling (Ville)
v7: - Loop through all planes in atomic state is good enough (Ville)
Bspec: 68881, 71675, 73424
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-8-vinod.govindapillai@intel.com
If FBC is already active, we don't need to call FBC activate
routine again unless there are changes to the fences. So skip
this on all platforms that don't have fences. Any FBC register
updates done after enabling the dirty rect support in xe3 will
trigger nuke by FBC which is counter productive to the fbc
dirty rect feature.
The front buffer rendering sequence will call intel_fbc_flush()
and which will call intel_fbc_nuke() or intel_fbc_activate()
based on FBC status explicitly and won't get impacted by this
change.
v2: use HAS_FBC_DIRTY_RECT()
move this functionality within intel_fbc_activate()
v3: update to intel_fbc_activate logic (Ville)
update to the patch description
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-7-vinod.govindapillai@intel.com
Introduce a macro to check if the platform supports FBC dirty
rect capability.
v2: - update to the patch subject
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-6-vinod.govindapillai@intel.com
Userspace can pass damage area clips per plane to track
changes in a plane and some display components can utilze
these damage clips for efficiently handling use cases like
FBC, PSR etc. A merged damage area is generated and its
coordinates are updated relative to viewport and HW and
stored in the plane_state. This merged damage areas will be
used for FBC dirty rect support in xe3 in the follow-up
patch.
Big thanks to Ville Syrjala for his contribuitions in shaping
up of this series.
v1: - Move damage_merged helper to cover bigjoiner case and use
the correct plane state for damage find helper (Ville)
- Damage handling code under HAS_FBC_DIRTY_RECT() so the
the related part will be executed only for xe3+
- Changed dev_priv to i915 in one of the functions
v2: - damage reported is stored in the plane state after coords
adjustmentments irrespective of fbc dirty rect support.
- Damage to be empty in case of plane not visible (Ville)
- Handle fb could be NULL and plane not visible cases (Ville)
v3: - No need to empty damage in case disp ver < 12 (Ville)
- update to the patch subject
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-4-vinod.govindapillai@intel.com
Add a const qualifier for the "state" parameter as well as we could
use this helper to get the combined damage in cases of const
drm_plane_state as well. Needed mainly for xe driver big joiner cases
where we need to track the damage from immutable plane state.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-3-vinod.govindapillai@intel.com
In the interest of limiting the display dependencies on i915 core
headers, split out i915_gtt_view_types.h from i915_vma_types.h, and only
include the new header from intel_display_types.h.
Reuse the new header from xe compat code too, failing build if partial
view is used in display code.
Side note: Why would we ever have set enum i915_gtt_view_type values to
size of each type?! What an insane hack.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bb31885c32dbddad76d634c6fdb98a73b546b42e.1740412806.git.jani.nikula@intel.com
With the primary goal of removing #include "i915_vma.h" from
intel_display_types.h, move intel_plane_ggtt_offset() to a proper
function in intel_atomic_plane.c. This reveals tons of implicit
dependencies all over the place that we pulled in via i915_vma.h. Fix
the fallout.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/70ac6d19518f355abf37ac8c4b0f1d18878be28c.1740412806.git.jani.nikula@intel.com
It's undesirable to have to figure out the pxp pointer in display
code. For one thing, its type is different for i915 and xe.
Since we can figure the pxp pointer out in the pxp code from the gem
object, offload it there.
v2: Rebase
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228114527.3091620-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move hdcp_mutex, num_hdcp_streams, hdcp_auth_status, hdcp_port_data, and
hdcp_mst_type1_capable members of struct intel_digital_port under an
hdcp sub-struct to group hdcp related things together.
Rename them mutex, num_streams, auth_status, port_data, and
mst_type1_capable for clarity.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9da4be57b068acd06dec8b93977f0a70627103d4.1740746939.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move active_mst_links, mst_encoders[], and mst_mgr members of struct
intel_dp under an mst sub-struct to group mst related things together.
Rename them active_links, stream_encoders[] and mgr for clarity.
Note that is_mst and mst_detect are not included, as they're also
relevant for non-mst. The sub-struct is for active mst.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6f282f90bfe2dd9162e2dee8f681c84313971992.1740746939.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In the hope of contributing to type safety in our code, let's ensure
that the type returned by the POWER_DOMAIN_*() macros is always of type
enum intel_display_power_domain.
v2:
- Remove accidental +1 in definition of POWER_DOMAIN_PIPE(). (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250227-improve-type-safey-power-domain-macros-v3-2-b6eaa00f9c33@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Although we have comments in intel_display_limits.h saying that the
code expects PIPE_A and TRANSCODER_A to be zero, it doesn't hurt to add
them as explicit base values for calculating the power domain offset in
POWER_DOMAIN_*() macros.
On the plus side, we have that this:
* Fixes a warning reported by kernel test robot <lkp@intel.com>
about doing arithmetic with two different enum types.
* Makes the code arguably more robust (in the unlikely event of those
bases becoming non-zero).
v2:
- Prefer using explicit base values instead of simply casting the
macro argument to int. (Ville)
- Update commit message to match the new approach (for reference, the
old message subject was "drm/i915/display: Use explicit cast in
POWER_DOMAIN_*() macros").
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202502120809.XfmcqkBD-lkp@intel.com/
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250227-improve-type-safey-power-domain-macros-v3-1-b6eaa00f9c33@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
