kernel/linux.git/drivers/gpu/drm/omapdrm, branch v5.17.9

omapdrm: dss: mark runtime PM functions __maybe_unused

2021-12-08T08:04:59+00:00

Using the SET_RUNTIME_PM_OPS() macro causes a warning about the referenced functions when they are marked static but not __maybe_unused: drivers/gpu/drm/omapdrm/dss/dss.c:1572:12: error: unused function 'dss_runtime_suspend' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dss.c:1584:12: error: unused function 'dss_runtime_resume' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dispc.c:4845:12: error: unused function 'dispc_runtime_suspend' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dispc.c:4860:12: error: unused function 'dispc_runtime_resume' [-Werror,-Wunused-function] Fixes: b92f7ea556f8 ("drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()") Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211205131612.3192652-1-arnd@kernel.org

drm/omap: Add a 'right overlay' to plane state

2021-12-08T08:04:54+00:00

If the drm_plane has a source width that's greater than the max width supported by a single hw overlay, then we assign a 'r_overlay' to it in omap_plane_atomic_check(). Both overlays should have the capabilities required to handle the source framebuffer. The only parameters that vary between the left and right hwoverlays are the src_w, crtc_w, src_x and crtc_x as we just even chop the fb into left and right halves. We also take care of not creating odd width size when dealing with YUV formats. Since both halves need to be 'appear' side by side the zpos is recalculated when dealing with dual overlay cases so that the other planes zpos is consistent. Depending on user space usage it is possible that on occasion the number of requested planes exceeds the numbers of overlays required to display them. In that case a failure would be returned for the plane that cannot be handled at that time. It is up to user space to make sure the H/W resource are not over-subscribed. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-10-narmstrong@baylibre.com

drm/omap: add plane_atomic_print_state support

2021-12-08T08:04:50+00:00

Now that we added specific item to our subclassed drm_plane_state we can add omap_plane_atomic_print_state() helper to dump out our own driver specific plane state. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-9-narmstrong@baylibre.com

drm/omap: dynamically assign hw overlays to planes

2021-12-08T08:04:47+00:00

(re)assign the hw overlays to planes based on required caps, and to handle situations where we could not modify an in-use plane. This means all planes advertise the superset of formats and properties. Userspace must (as always) use atomic TEST_ONLY step for atomic updates, as not all planes may be available for use on every frame. The mapping of hwoverlays to plane is stored in omap_global_state, so that state updates are atomically committed in the same way that plane/etc state updates are managed. This is needed because the omap_plane_state keeps a pointer to the hwoverlay, and we don't want global state to become out of sync with the plane state if an atomic update fails, we hit deadlock/ backoff scenario, etc. The use of global_state_lock keeps multiple parallel updates which both re-assign hwoverlays properly serialized. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-8-narmstrong@baylibre.com

drm/omap: Add global state as a private atomic object

2021-12-08T08:04:43+00:00

Global shared resources (like hw overlays) for omapdrm are implemented as a part of atomic state using the drm_private_obj infrastructure available in the atomic core. omap_global_state is introduced as a drm atomic private object. The two funcs omap_get_global_state() and omap_get_existing_global_state() are the two variants that will be used to access omap_global_state. drm_mode_config_init() needs to be called earlier because it creates/initializes the private_obj link list maintained by the atomic framework. The private_obj link list has to exist prior to calling drm_atomic_private_obj_init(). Similarly the cleanup handler are reordered appropriately. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-7-narmstrong@baylibre.com

drm/omap: omap_plane: subclass drm_plane_state

2021-12-08T08:04:41+00:00

In preparation to add omap plane state specific extensions we need to subclass drm_plane_state and add the relevant helpers. The addition of specific extension will be done separately. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-6-narmstrong@baylibre.com

drm/omap: introduce omap_hw_overlay

2021-12-08T08:04:40+00:00

Split out the hardware overlay specifics from omap_plane. To start, the hw overlays are statically assigned to planes. The goal is to eventually assign hw overlays dynamically to planes during plane->atomic_check() based on requested caps (scaling, YUV, etc). And then perform hw overlay re-assignment if required. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-5-narmstrong@baylibre.com

drm/omap: Add ovl checking funcs to dispc_ops

2021-12-08T08:04:38+00:00

In order to be able to dynamically assign overlays to planes we need to be able to asses the overlay capabilities. Add a helper function to be able to retrieve the supported capabilities of an overlay. And export the function to check if a fourcc is supported on a given overlay. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-4-narmstrong@baylibre.com

drm/omap: Add ability to check if requested plane modes can be supported

2021-12-08T08:04:37+00:00

We currently assume that an overlay has the same maximum width and maximum height as the overlay manager. This assumption is incorrect. On some variants the overlay manager maximum width is twice the maximum width that the overlay can handle. We need to add the appropriate data per variant as well as export a helper function to retrieve the data so check can be made dynamically in omap_plane_atomic_check(). Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-3-narmstrong@baylibre.com

drm/omap: add sanity plane state check

2021-12-08T08:04:33+00:00

Call drm_atomic_helper_check_plane_state() from the plane atomic_check() callback in order to add plane state sanity checking. It will permit filtering out totally bad scaling factors, even if the real check are done later in the atomic commit. Calling drm_atomic_helper_check_plane_state() also sets plane_state->visible which will be useful when dynamically assigning hw overlays to planes. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20211117141928.771082-2-narmstrong@baylibre.com