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>
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>
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>
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
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
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
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>
