linux/drivers/gpu/drm/exynos, branch v6.4

drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl

2023-06-07T04:03:16Z

If it is async, runqueue_node is freed in g2d_runqueue_worker on another worker thread. So in extreme cases, if g2d_runqueue_worker runs first, and then executes the following if statement, there will be use-after-free. Signed-off-by: Min Li Reviewed-by: Andi Shyti Signed-off-by: Inki Dae

drm/exynos: vidi: fix a wrong error return

2023-06-07T04:03:17Z

Fix a wrong error return by dropping an error return. When vidi driver is remvoed, if ctx->raw_edid isn't same as fake_edid_info then only what we have to is to free ctx->raw_edid so that driver removing can work correctly - it's not an error case. Signed-off-by: Inki Dae Reviewed-by: Andi Shyti

drm/exynos: fix g2d_open/close helper function definitions

2023-05-15T05:10:34Z

The empty stub functions are defined as global functions, which causes a warning because of missing prototypes: drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: error: no previous prototype for 'g2d_open' drivers/gpu/drm/exynos/exynos_drm_g2d.h:42:5: error: no previous prototype for 'g2d_close' Mark them as 'static inline' to avoid the warning and to make them behave as intended. Fixes: eb4d9796fa34 ("drm/exynos: g2d: Convert to driver component API") Signed-off-by: Arnd Bergmann Reviewed-by: Andi Shyti Signed-off-by: Inki Dae

drm/exynos: Implement fbdev emulation as in-kernel client

2023-04-17T07:47:55Z

Move code from ad-hoc fbdev callbacks into DRM client functions and remove the old callbacks. The functions instruct the client to poll for changed output or restore the display. The DRM core calls both, the old callbacks and the new client helpers, from the same places. The new functions perform the same operation as before, so there's no change in functionality. Replace all code that initializes or releases fbdev emulation throughout the driver. Instead initialize the fbdev client by a single call to exynos_fbdev_setup() after exynos has registered its DRM device. As in most drivers, exynos' fbdev emulation now acts like a regular DRM client. The fbdev client setup consists of the initial preparation and the hot-plugging of the display. The latter creates the fbdev device and sets up the fbdev framebuffer. The setup performs display hot-plugging once. If no display can be detected, DRM probe helpers re-run the detection on each hotplug event. A call to drm_dev_unregister() releases the client automatically. No further action is required within exynos. If the fbdev framebuffer has been fully set up, struct fb_ops.fb_destroy implements the release. For partially initialized emulation, the fbdev client reverts the initial setup. Signed-off-by: Thomas Zimmermann Tested-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: Initialize fbdev DRM client

2023-04-17T07:47:55Z

Initialize the fbdev client in the fbdev code with empty helper functions. Also clean up the client. The helpers will later implement various functionality of the DRM client. No functional changes. Signed-off-by: Thomas Zimmermann Tested-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: Remove fb_helper from struct exynos_drm_private

2023-04-17T07:47:55Z

The DRM device stores a pointer to the fbdev helper. Remove struct exynos_drm_private.fb_helper, which contains the same value. No functional changes. Signed-off-by: Thomas Zimmermann Tested-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: Remove struct exynos_drm_fbdev

2023-04-17T07:47:55Z

Remove struct exynos_drm_fbdev, which is an empty wrapper around struct drm_fb_helper. Use the latter directly. No functional changes. Signed-off-by: Thomas Zimmermann Tested-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: Remove exynos_gem from struct exynos_drm_fbdev

2023-04-17T07:47:54Z

Fbdev's framebuffer stores a pointer to the GEM object. Remove struct exynos_drm_fbdev.exynos_gem, which contains the same value. No functional changes. Signed-off-by: Thomas Zimmermann Tested-by: Marek Szyprowski Signed-off-by: Inki Dae

drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

2023-03-28T00:05:41Z

Samsung MIPI DSIM controller is common DSI IP that can be used in various SoCs like Exynos, i.MX8M Mini/Nano. In order to access this DSI controller between various platform SoCs, the ideal way to incorporate this in the drm stack is via the drm bridge driver. We already have a consolidated code for supporting component and bridge based DRM drivers, so keep the exynos component based code in existing exynos_drm_dsi.c and move generic bridge code as part of samsung-dsim.c Tested-by: Marek Szyprowski Reviewed-by: Marek Vasut Signed-off-by: Marek Szyprowski Signed-off-by: Jagan Teki Signed-off-by: Inki Dae

drm: exynos: dsi: Add host helper for te_irq_handler

2023-03-28T00:05:40Z

IRQ handler for te-gpio seems to be common across DSIM host. However, Exynos is handling this via CRTC drivers but there is no clear evidence on how the same has been handled in i.MX8MM. Keeping the handler as-it-is can be a viable option but adding DSIM bridge core in upcoming patches is not possible to call Exynos CRTC handler as DSIM bridge has to be common across DRM bridge core instead of platform specific DRM drivers like Exynos here. So, this patch handles the handler via platform host helper, so-that handling platform specific hook across Exynos and generic can be reasonable till it makes it generic across all platforms. Tested-by: Marek Szyprowski Reviewed-by: Marek Vasut Signed-off-by: Jagan Teki Signed-off-by: Inki Dae