drm/i915/frontbuffer: convert frontbuffer->obj to struct drm_gem_object

Prefer the driver agnostic struct drm_gem_object over i915 specific
struct drm_i915_gem_object.

Do some opportunistic struct

drm/i915/frontbuffer: convert frontbuffer->obj to struct drm_gem_object

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

show more ...

drm/i915/frontbuffer: convert intel_frontbuffer_get() to struct drm_gem_object

Prefer the driver agnostic struct drm_gem_object over i915 specific
struct drm_i915_gem_object.

Reviewed-by: Maarten L

drm/i915/frontbuffer: convert intel_frontbuffer_get() to struct drm_gem_object

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

show more ...

drm/i915: Add new frontbuffer tracking interface to queue flush

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_call

drm/i915: Add new frontbuffer tracking interface to queue flush

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]

show more ...

drm/i915/display: Remove i915_gem_object_types.h from intel_frontbuffer.h

Now as we have removed all the references to internals of i915_gem_object
from the frontbuffer header we can also remove inc

drm/i915/display: Remove i915_gem_object_types.h from intel_frontbuffer.h

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]

show more ...

drm/i915: Add getter/setter for i915_gem_object->frontbuffer

Add getter/setter for i915_gem_object->frontbuffer and use it instead of
directly touching i915_gem_object->frontbuffer frontbuffer point

drm/i915: Add getter/setter for i915_gem_object->frontbuffer

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]

show more ...

drm/i915: move INTEL_FRONTBUFFER_* macros to intel_frontbuffer.h

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_trac

drm/i915: move INTEL_FRONTBUFFER_* macros to intel_frontbuffer.h

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

show more ...

drm/i915/fb: reduce include dependencies

We actually need i915_active_types.h, not i915_active.h.

Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Jani Nikula <jani.nikula@

drm/i915/fb: reduce include dependencies

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

show more ...

drm/i915/display: Fix glitches when moving cursor with PSR2 selective fetch enabled

Legacy cursor APIs are handled by intel_legacy_cursor_update(), that
calls drm_atomic_helper_update_plane() when g

drm/i915/display: Fix glitches when moving cursor with PSR2 selective fetch 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]

show more ...

drm/i915: Nuke ORIGIN_GTT

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

drm/i915: Nuke ORIGIN_GTT

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]

show more ...

drm/i915: Hold reference to intel_frontbuffer as we track activity

Since obj->frontbuffer is no longer protected by the struct_mutex, as we
are processing the execbuf, it may be removed. Mark the
in

drm/i915: Hold reference to intel_frontbuffer as we track activity

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]

show more ...

drm/i915: Hold reference to intel_frontbuffer as we track activity

Since obj->frontbuffer is no longer protected by the struct_mutex, as we
are processing the execbuf, it may be removed. Mark the
in

drm/i915: Hold reference to intel_frontbuffer as we track activity

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

show more ...

drm/i915: Extract intel_frontbuffer active tracking

Move the active tracking for the frontbuffer operations out of the
i915_gem_object and into its own first class (refcounted) object. In the
proces

drm/i915: Extract intel_frontbuffer active tracking

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]

show more ...

drm/i915: move modesetting core code under display/

Now that we have a new subdirectory for display code, continue by moving
modesetting core code.

display/intel_frontbuffer.h sticks out like a sor

drm/i915: move modesetting core code under display/

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]

show more ...