| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Going forward, struct intel_display is the main display device data
pointer. Convert intel_frontbuffer.[ch] to struct intel_display.
Reviewed-by: Chaitanya Kumar Borah <[email protected]>
Link: https://lore.kernel.org/r/ef0860583b7d6ad141959f84c25657e0c102d6d2.1744222449.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Prefer the driver agnostic struct drm_gem_object over i915 specific
struct drm_i915_gem_object.
Do some opportunistic struct intel_display conversions while at it,
because it's more convenient to deal with.
Reviewed-by: Maarten Lankhorst <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/51bdb3c9b798e28bd70c259fc3874d80bc9b7443.1726589119.git.jani.nikula@intel.com
|
| |
|
|
|
|
|
|
|
|
| |
Prefer the driver agnostic struct drm_gem_object over i915 specific
struct drm_i915_gem_object.
Reviewed-by: Maarten Lankhorst <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/358cfcb5eb666732cd7ae21e4f63d07837960ec2.1726589119.git.jani.nikula@intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to wait dma fences in dirtyfb ioctl. As we don't want to make
dirtyfb ioctl as blocking call we need to use
dma_fence_add_callback. Callback used for dma_fence_add_callback is
called from atomic context. Due to this we need to add a new
frontbuffer tracking interface to queue flush.
v3:
- Check schedule work success rather than work being pending
- Init flush work when frontbuffer struct is initialized
v2: Check if flush work is already pending
Signed-off-by: Jouni Högander <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
| |
|
|
|
|
|
|
|
|
| |
Now as we have removed all the references to internals of i915_gem_object
from the frontbuffer header we can also remove including
i915_gem_object_types.h.
Signed-off-by: Jouni Högander <[email protected]>
Reviewed-by: Jeevan B <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add getter/setter for i915_gem_object->frontbuffer and use it instead of
directly touching i915_gem_object->frontbuffer frontbuffer pointer.
v3:
- Fix intel_frontbuffer_get return value
- s/front_ret/cur/
v2: Move getter/setter into i915_gem_object.h
Signed-off-by: Jouni Högander <[email protected]>
Reviewed-by: Nirmoy Das <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The macros clearly don't belong in i915_drv.h. Move to
intel_frontbuffer.h.
Also split the BUILD_BUG_ON()s to intel_frontbuffer_track() to avoid
depending on some other macros in the header.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/c899fd1ef2220564a876cd88c03e53c4c7b0168b.1661346845.git.jani.nikula@intel.com
|
| |
|
|
|
|
|
|
| |
We actually need i915_active_types.h, not i915_active.h.
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/aed5f1afda4448ec46c7ff1f95291edebf355790.1639142167.git.jani.nikula@intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
enabled
Legacy cursor APIs are handled by intel_legacy_cursor_update(), that
calls drm_atomic_helper_update_plane() when going through the
slow/atomic path to update cursor, what was the case for PSR2
selective fetch.
drm_atomic_helper_update_plane() sets
drm_atomic_state->legacy_cursor_update to true when updating the
cursor plane, to allow several cursor updates to happen within the
same frame, as userspace does that.
If drivers waited for a vblank increment at the end of every cursor
movement that would cause a visible lag in the cursor.
But this optimization do not properly work with PSR2 selective fetch
dirt area calculation, for example if within a single frame the cursor
had 3 moves the final dirt area programmed to PSR2_MAN_TRK_CTL would
be based in the second movement as old state and third movement as new
state, not updating the area where cursor was in the first state.
So here switching back to the fast path approach in
intel_legacy_cursor_update() and handling cursor movements as
frontbuffer rendering(psr_force_hw_tracking_exit()), that is not the
most optimal for power-savings but is the solution that we have until
mailbox style updates is implemented.
Also removing the cursor workaround as not it is properly undestand
the issue and is know that it will never cover all the cases.
Cc: Ville Syrjälä <[email protected]>
Cc: Gwan-gyeong Mun <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Acked-by: Ville Syrjälä <[email protected]>
Reviewed-by: Gwan-gyeong Mun <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
| |
|
|
|
|
|
|
|
| |
There is no users of it, so no need to keep handling for it.
Reviewed-by: Gwan-gyeong Mun <[email protected]>
Cc: Gwan-gyeong Mun <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since obj->frontbuffer is no longer protected by the struct_mutex, as we
are processing the execbuf, it may be removed. Mark the
intel_frontbuffer as rcu protected, and so acquire a reference to
the struct as we track activity upon it.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/827
Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Matthew Auld <[email protected]>
Cc: <[email protected]> # v5.4+
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit da42104f589d979bbe402703fd836cec60befae1)
Signed-off-by: Jani Nikula <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Move the active tracking for the frontbuffer operations out of the
i915_gem_object and into its own first class (refcounted) object. In the
process of detangling, we switch from low level request tracking to the
easier i915_active -- with the plan that this avoids any potential
atomic callbacks as the frontbuffer tracking wishes to sleep as it
flushes.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
|
Now that we have a new subdirectory for display code, continue by moving
modesetting core code.
display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this
is, again, a surprisingly clean operation.
v2:
- don't move intel_sideband.[ch] (Ville)
- use tabs for Makefile file lists and sort them
Cc: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
Acked-by: Maarten Lankhorst <[email protected]>
Acked-by: Ville Syrjälä <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
