kernel/linux.git/drivers/gpu/drm/mxsfb, branch v5.10.92

drm: mxsfb: Fix NULL pointer dereference crash on unload

2021-10-27T07:56:54+00:00

commit 3cfc183052c3dbf8eae57b6c1685dab00ed3db4a upstream. The mxsfb->crtc.funcs may already be NULL when unloading the driver, in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from mxsfb_unload() leads to NULL pointer dereference. Since all we care about is masking the IRQ and mxsfb->base is still valid, just use that to clear and mask the IRQ. Fixes: ae1ed00932819 ("drm: mxsfb: Stop using DRM simple display pipeline helper") Signed-off-by: Marek Vasut Cc: Daniel Abrecht Cc: Emil Velikov Cc: Laurent Pinchart Cc: Sam Ravnborg Cc: Stefan Agner Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20211016210446.171616-1-marex@denx.de Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman

drm: mxsfb: Clear FIFO_CLEAR bit

2021-09-15T07:50:35+00:00

[ Upstream commit 5e23c98178eb1a2cdb7c4fee9a39baf8cabf282d ] Make sure the FIFO_CLEAR bit is latched in when configuring the controller, so that the FIFO is really cleared. And then clear the FIFO_CLEAR bit, since it is not self-clearing. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut Cc: Daniel Abrecht Cc: Emil Velikov Cc: Laurent Pinchart Cc: Lucas Stach Cc: Stefan Agner Reviewed-by: Jagan Teki Tested-by: Jagan Teki # i.Core MX8MM Acked-by: Lucas Stach Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210620224946.189524-1-marex@denx.de Signed-off-by: Sasha Levin

drm: mxsfb: Increase number of outstanding requests on V4 and newer HW

2021-09-15T07:50:35+00:00

[ Upstream commit 9891cb54445bc65bf156bda416b6215048c7f617 ] In case the DRAM is under high load, the MXSFB FIFO might underflow and that causes visible artifacts. This could be triggered on i.MX8MM using e.g. "$ memtester 128M" on a device with 1920x1080 panel. The first "Stuck Address" test of the memtester will completely corrupt the image on the panel and leave the MXSFB FIFO in odd state. To avoid this underflow, increase number of outstanding requests to DRAM from 2 to 16, which is the maximum. This mitigates the issue and it can no longer be triggered. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut Cc: Daniel Abrecht Cc: Emil Velikov Cc: Laurent Pinchart Cc: Lucas Stach Cc: Stefan Agner Reviewed-by: Lucas Stach Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210620224759.189351-1-marex@denx.de Signed-off-by: Sasha Levin

drm: mxsfb: Enable recovery on underflow

2021-09-15T07:50:35+00:00

[ Upstream commit 0c9856e4edcdcac22d65618e8ceff9eb41447880 ] There is some sort of corner case behavior of the controller, which could rarely be triggered at least on i.MX6SX connected to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS bridged 1920x1080 panel (and likely on other setups too), where the image on the panel shifts to the right and wraps around. This happens either when the controller is enabled on boot or even later during run time. The condition does not correct itself automatically, i.e. the display image remains shifted. It seems this problem is known and is due to sporadic underflows of the LCDIF FIFO. While the LCDIF IP does have underflow/overflow IRQs, neither of the IRQs trigger and neither IRQ status bit is asserted when this condition occurs. All known revisions of the LCDIF IP have CTRL1 RECOVER_ON_UNDERFLOW bit, which is described in the reference manual since i.MX23 as " Set this bit to enable the LCDIF block to recover in the next field/frame if there was an underflow in the current field/frame. " Enable this bit to mitigate the sporadic underflows. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut Cc: Daniel Abrecht Cc: Emil Velikov Cc: Laurent Pinchart Cc: Lucas Stach Cc: Stefan Agner Reviewed-by: Lucas Stach Reviewed-by: Laurent Pinchart Reviewed-by: Jagan Teki Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210620224701.189289-1-marex@denx.de Signed-off-by: Sasha Levin

drm/mxsfb: Don't select DRM_KMS_FB_HELPER

2021-07-19T07:44:36+00:00

[ Upstream commit 13b29cc3a722c2c0bc9ab9f72f9047d55d08a2f9 ] Selecting DRM_FBDEV_EMULATION will include the correct settings for fbdev emulation. Drivers should not override this. Signed-off-by: Thomas Zimmermann Acked-by: Stefan Agner Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210415110040.23525-3-tzimmermann@suse.de Signed-off-by: Sasha Levin

drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge

2020-12-30T10:53:53+00:00

[ Upstream commit ee46d16d2e40bebc2aa790fd7b6a056466ff895c ] It can take multiple iterations until all components for an attached DSI bridge are up leading to several: [ 3.796425] mxsfb 30320000.lcd-controller: Cannot connect bridge: -517 [ 3.816952] mxsfb 30320000.lcd-controller: [drm:mxsfb_probe [mxsfb]] *ERROR* failed to attach bridge: -517 Silence this by checking for -EPROBE_DEFER and using dev_err_probe() so we set a deferred reason in case a dependency fails to probe (which quickly happens on small config/DT changes due to the rather long probe chain which can include bridges, phys, panels, backights, leds, etc.). This also removes the only DRM_DEV_ERROR() usage, the rest of the driver uses dev_err(). Signed-off-by: Guido Günther Fixes: c42001e357f7 ("drm: mxsfb: Use drm_panel_bridge") Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/d5761eb871adde5464ba112b89d966568bc2ff6c.1608020391.git.agx@sigxcpu.org Signed-off-by: Sasha Levin

drm: mxsfb: Implement .format_mod_supported

2020-11-26T12:30:57+00:00

This will make sure applications which use the IN_FORMATS blob to figure out which modifiers they can use will pick up the linear modifier which is needed by mxsfb. Such applications will not work otherwise if an incompatible implicit modifier ends up being selected. Before commit ae1ed0093281 ("drm: mxsfb: Stop using DRM simple display pipeline helper"), the DRM simple display pipeline helper took care of this. Signed-off-by: Daniel Abrecht Fixes: ae1ed0093281 ("drm: mxsfb: Stop using DRM simple display pipeline helper") Reviewed-by: Stefan Agner Signed-off-by: Stefan Agner Link: https://patchwork.freedesktop.org/patch/msgid/2a99ffffc2378209307e0992a6e97e70@nodmarc.danielabrecht.ch

drm: mxsfb: fix fence synchronization

2020-11-26T12:30:18+00:00

The conversion away from the simple display pipeline helper missed to convert the prepare_fb plane callback, so no fences are attached to the atomic state, breaking synchronization with other devices. Fix this by plugging in the drm_gem_fb_prepare_fb helper function. Fixes: ae1ed0093281 ("drm: mxsfb: Stop using DRM simple display pipeline helper") Signed-off-by: Lucas Stach Reviewed-by: Stefan Agner Signed-off-by: Stefan Agner Link: https://patchwork.freedesktop.org/patch/msgid/20201120211306.325841-1-l.stach@pengutronix.de

drm: mxsfb: check framebuffer pitch

2020-09-16T09:13:27+00:00

The lcdif IP does not support a framebuffer pitch (stride) other than framebuffer width. Check for equality and reject the framebuffer otherwise. This prevents a distorted picture when using 640x800 and running the Mesa graphics stack. Mesa tries to use a cache aligned stride, which leads at that particular resolution to width != stride. Currently Mesa has no fallback behavior, but rejecting this configuration allows userspace to handle the issue correctly. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Stefan Agner Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20200908141654.266836-1-stefan@agner.ch

drm: mxsfb: Support the alpha plane

2020-07-28T15:21:58+00:00

The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha plane. Support it. Signed-off-by: Laurent Pinchart Reviewed-by: Emil Velikov Reviewed-by: Stefan Agner Signed-off-by: Stefan Agner Link: https://patchwork.freedesktop.org/patch/msgid/20200727020654.8231-23-laurent.pinchart@ideasonboard.com