kernel/linux.git/drivers/gpu/drm/drm_fbdev_generic.c, branch linux-6.9.y

drm/fbdev-generic: Fix framebuffer on big endian devices

2024-07-11T10:51:11+00:00

[ Upstream commit 740b8dad05bee39e1e3b926f05bb4a8274b8ba49 ] Starting with kernel 6.7, the framebuffer text console is not working anymore with the virtio-gpu device on s390x hosts. Such big endian fb devices are usinga different pixel ordering than little endian devices, e.g. DRM_FORMAT_BGRX8888 instead of DRM_FORMAT_XRGB8888. This used to work fine as long as drm_client_buffer_addfb() was still calling drm_mode_addfb() which called drm_driver_legacy_fb_format() internally to get the right format. But drm_client_buffer_addfb() has recently been reworked to call drm_mode_addfb2() instead with the format value that has been passed to it as a parameter (see commit 6ae2ff23aa43 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()"). That format parameter is determined in drm_fbdev_generic_helper_fb_probe() via the drm_mode_legacy_fb_format() function - which only generates formats suitable for little endian devices. So to fix this issue switch to drm_driver_legacy_fb_format() here instead to take the device endianness into consideration. Fixes: 6ae2ff23aa43 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()") Closes: https://issues.redhat.com/browse/RHEL-45158 Signed-off-by: Thomas Huth Reviewed-by: Javier Martinez Canillas Acked-by: Thomas Zimmermann Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20240627173530.460615-1-thuth@redhat.com Signed-off-by: Sasha Levin

drm/fbdev-generic: Do not set physical framebuffer address

2024-06-16T11:51:01+00:00

commit 87cb4a612a89690b123e68f6602d9f6581b03597 upstream. Framebuffer memory is allocated via vzalloc() from non-contiguous physical pages. The physical framebuffer start address is therefore meaningless. Do not set it. The value is not used within the kernel and only exported to userspace on dedicated ARM configs. No functional change is expected. v2: - refer to vzalloc() in commit message (Javier) Signed-off-by: Thomas Zimmermann Fixes: a5b44c4adb16 ("drm/fbdev-generic: Always use shadow buffering") Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: Zack Rusin Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: # v6.4+ Reviewed-by: Javier Martinez Canillas Reviewed-by: Zack Rusin Reviewed-by: Sui Jingfeng Tested-by: Sui Jingfeng Acked-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240419083331.7761-2-tzimmermann@suse.de (cherry picked from commit 73ef0aecba78aa9ebd309b10b6cd17d94e632892) Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman

fbdev: Align deferred I/O with naming of helpers

2023-07-31T18:07:24+00:00

Deferred-I/O generator macros generate callbacks for struct fb_ops that operate on memory ranges in I/O address space or system address space. Rename the macros to use the _IOMEM_ and _SYSMEM_ infixes of their underlying helpers. Adapt all users. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Acked-by: Helge Deller Link: https://patchwork.freedesktop.org/patch/msgid/20230729193157.15446-5-tzimmermann@suse.de

drm: Remove flag FBINFO_DEFAULT from fbdev emulation

2023-07-24T14:50:38+00:00

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Patrik Jakobsson Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-2-tzimmermann@suse.de

drm/client: Send hotplug event after registering a client

2023-07-11T12:02:01+00:00

Generate a hotplug event after registering a client to allow the client to configure its display. Remove the hotplug calls from the existing clients for fbdev emulation. This change fixes a concurrency bug between registering a client and receiving events from the DRM core. The bug is present in the fbdev emulation of all drivers. The fbdev emulation currently generates a hotplug event before registering the client to the device. For each new output, the DRM core sends an additional hotplug event to each registered client. If the DRM core detects first output between sending the artificial hotplug and registering the device, the output's hotplug event gets lost. If this is the first output, the fbdev console display remains dark. This has been observed with amdgpu and fbdev-generic. Fix this by adding hotplug generation directly to the client's register helper drm_client_register(). Registering the client and receiving events are serialized by struct drm_device.clientlist_mutex. So an output is either configured by the initial hotplug event, or the client has already been registered. The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is done"), in which adding a client and receiving a hotplug event switched order. It was hidden, as most hardware and drivers have at least on static output configured. Other drivers didn't use the internal DRM client or still had struct drm_mode_config_funcs.output_poll_changed set. That callback handled hotplug events as well. After not setting the callback in amdgpu in commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct drm_driver.output_poll_changed"), amdgpu did not show a framebuffer console if output events got lost. The bug got copy-pasted from fbdev-generic into the other fbdev emulation. Reported-by: Moritz Duge Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649 Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is done") Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate source file") Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA helpers") Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel client") Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel client") Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation") Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client") Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel client") Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation") Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client") Fixes: 0e3172bac3f4 ("drm/amdgpu: Don't set struct drm_driver.output_poll_changed") Signed-off-by: Thomas Zimmermann Tested-by: Moritz Duge Tested-by: Torsten Krah Tested-by: Paul Schyska Cc: Daniel Vetter Cc: David Airlie Cc: Noralf Trønnes Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Javier Martinez Canillas Cc: Russell King Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Krzysztof Kozlowski Cc: Patrik Jakobsson Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Tomi Valkeinen Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: Thierry Reding Cc: Mikko Perttunen Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: # v5.2+ Reviewed-by: Javier Martinez Canillas Reviewed-by: Dmitry Baryshkov # msm Link: https://patchwork.freedesktop.org/patch/msgid/20230710091029.27503-1-tzimmermann@suse.de

drm/fbdev-generic: Implement dedicated fbdev I/O helpers

2023-06-01T10:41:40+00:00

Implement dedicated fbdev helpers for framebuffer I/O instead of using DRM's helpers. Use an fbdev generator macro for deferred I/O to create the callbacks. Fbdev-generic was the only caller of the DRM helpers, so remove them from the helper module. v4: * generate deferred-I/O helpers * use initializer macros for fb_ops v2: * use FB_SYS_HELPERS_DEFERRED option Signed-off-by: Thomas Zimmermann Tested-by: Sui Jingfeng Reviewed-by: Sui Jingfeng Link: https://patchwork.freedesktop.org/patch/msgid/20230530151228.22979-13-tzimmermann@suse.de

drm/fbdev-generic: Rename symbols

2023-03-22T12:32:54+00:00

Rename symbols to match the style of other fbdev-emulation source code. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Zack Rusin Tested-by: Sui Jingfeng Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-9-tzimmermann@suse.de

drm/fbdev-generic: Clean up after failed probing

2023-03-22T12:32:52+00:00

Clean up fbdev and client state if the probe function fails. It used to leak allocated resources. Also reorder the individual steps to simplify cleanup. v2: * move screen_size update into separate patches Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Zack Rusin Tested-by: Sui Jingfeng Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-7-tzimmermann@suse.de

drm/fbdev-generic: Set screen size to size of GEM buffer

2023-03-22T12:32:51+00:00

The size of the screen memory should be equivalent to the size of the screen's GEM buffer. Don't recalculate the value. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Tested-by: Sui Jingfeng Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-6-tzimmermann@suse.de

drm/fbdev-generic: Always use shadow buffering

2023-03-22T12:32:46+00:00

Remove all codepaths that implement fbdev output directly on GEM buffers. Always allocate a shadow buffer in system memory and set up deferred I/O for mmap. The fbdev code that operated directly on GEM buffers was used by drivers based on GEM DMA helpers. Those drivers have been migrated to use fbdev-dma, a dedicated fbdev emulation for DMA memory. All remaining users of fbdev-generic require shadow buffering. Memory management of the remaining callers uses TTM, GEM SHMEM helpers or a variant of GEM DMA helpers that is incompatible with fbdev-dma. Therefore remove the unused codepaths from fbdev-generic and simplify the code. Using a shadow buffer with deferred I/O is probably the best case for most remaining callers. Some of the TTM-based drivers might benefit from a dedicated fbdev emulation that operates directly on the driver's video memory. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Zack Rusin Tested-by: Sui Jingfeng Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-2-tzimmermann@suse.de