kernel/linux.git/drivers/video/fbdev/Kconfig, branch v6.1.168

fbdev: sh7760fb: allow modular build

2024-06-12T09:03:25+00:00

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ] There is no reason to prohibit sh7760fb from being built as a loadable module as suggested by Geert, so change the config symbol from bool to tristate to allow that and change the FB dependency as needed. Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y") Suggested-by: Geert Uytterhoeven Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: John Paul Adrian Glaubitz Cc: Sam Ravnborg Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Acked-by: John Paul Adrian Glaubitz Acked-by: Javier Martinez Canillas Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbdev/sh7760fb: Depend on FB=y

2023-10-06T12:56:58+00:00

[ Upstream commit f75f71b2c418a27a7c05139bb27a0c83adf88d19 ] Fix linker error if FB=m about missing fb_io_read and fb_io_write. The linker's error message suggests that this config setting has already been broken for other symbols. All errors (new ones prefixed by >>): sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_probe': sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc' sh4-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to `fb_videomode_to_var' sh4-linux-ld: sh7760fb.c:(.text+0x39c): undefined reference to `fb_alloc_cmap' sh4-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to `register_framebuffer' sh4-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to `fb_dealloc_cmap' sh4-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to `framebuffer_release' sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_remove': sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer' sh4-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to `fb_dealloc_cmap' sh4-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to `framebuffer_release' >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined reference to `fb_io_read' >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined reference to `fb_io_write' sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined reference to `cfb_fillrect' sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined reference to `cfb_copyarea' sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined reference to `cfb_imageblit' Suggested-by: Randy Dunlap Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202309130632.LS04CPWu-lkp@intel.com/ Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: John Paul Adrian Glaubitz Link: https://patchwork.freedesktop.org/patch/msgid/20230918090400.13264-1-tzimmermann@suse.de Signed-off-by: Sasha Levin

fbdev: uvesafb: don't build on UML

2022-12-31T12:32:43+00:00

[ Upstream commit 35b4f4d4a725cf8f8c10649163cd12aed509b953 ] The uvesafb fbdev driver uses memory management information that is not available on ARCH=um, so don't allow this driver to be built on UML. Prevents these build errors: ../drivers/video/fbdev/uvesafb.c: In function ‘uvesafb_vbe_init’: ../drivers/video/fbdev/uvesafb.c:807:21: error: ‘__supported_pte_mask’ undeclared (first use in this function) 807 | if (__supported_pte_mask & _PAGE_NX) { ../drivers/video/fbdev/uvesafb.c:807:44: error: ‘_PAGE_NX’ undeclared (first use in this function) 807 | if (__supported_pte_mask & _PAGE_NX) { Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Randy Dunlap Cc: Johannes Berg Cc: Richard Weinberger Cc: linux-um@lists.infradead.org Cc: Daniel Vetter Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Michal Januszewski Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbdev: ssd1307fb: Drop optional dependency

2022-12-31T12:32:43+00:00

[ Upstream commit 025e3b507a3a8e1ee96a3112bb67495c77d6cdb6 ] Only a single out of three devices need a PWM, so from driver it's optional. Moreover it's a single driver in the entire kernel that currently selects PWM. Unfortunately this selection is a root cause of the circular dependencies when we want to enable optional PWM for some other drivers that select GPIOLIB. Fixes: a2ed00da5047 ("drivers/video: add support for the Solomon SSD1307 OLED Controller") Signed-off-by: Andy Shevchenko Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

drm: Implement DRM aperture helpers under video/

2022-06-27T09:07:55+00:00

Implement DRM's aperture helpers under video/ for sharing with other sub-systems. Remove DRM-isms from the interface. The helpers track the ownership of framebuffer apertures and provide hand-over from firmware, such as EFI and VESA, to native graphics drivers. Other subsystems, such as fbdev and vfio, also have to maintain ownership of framebuffer apertures. Moving DRM's aperture helpers to a more public location allows all subsystems to interact with each other and share a common implementation. The aperture helpers are selected by the various firmware drivers within DRM and fbdev, and the VGA text-console driver. The original DRM interface is kept in place for use by DRM drivers. v3: * prefix all interfaces with aperture_ (Javier) * rework and simplify documentation (Javier) * rename struct dev_aperture to struct aperture_range * rebase onto latest DRM * update MAINTAINERS entry Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Tested-by: Laszlo Ersek Link: https://patchwork.freedesktop.org/patch/msgid/20220622140134.12763-3-tzimmermann@suse.de

Revert "fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled"

2022-06-13T17:21:12+00:00

This reverts commit fa0e256450f27a7d85f65c63f05e6897954a1d53. The kernel test robot reported that attempting to build the vesafb driver fails on some architectures, because these don't define a `struct screen_info`. This leads to linking errors, for example on parisc with allyesconfig: hppa-linux-ld: drivers/video/fbdev/vesafb.o: in function `vesafb_probe': >> (.text+0x738): undefined reference to `screen_info' >> hppa-linux-ld: (.text+0x73c): undefined reference to `screen_info' hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init': >> (.init.text+0x28): undefined reference to `screen_info' >> hppa-linux-ld: (.init.text+0x30): undefined reference to `screen_info' hppa-linux-ld: (.init.text+0x78): undefined reference to `screen_info' The goal of commit fa0e256450f2 ("fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled") was to have more build coverage for the driver but it wrongly assumed that all architectures would define a screen_info. Reported-by: kernel test robot Signed-off-by: Javier Martinez Canillas Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220610085450.1341880-1-javierm@redhat.com

fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled

2022-05-13T12:05:19+00:00

The driver has runtime but no build time dependency with X86, so it can be built for testing purposes if the COMPILE_TEST option is enabled. This is useful to have more build coverage and make sure that the driver is not affected by changes that could cause build regressions. Signed-off-by: Javier Martinez Canillas Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220505120419.314136-1-javierm@redhat.com

Merge drm/drm-next into drm-misc-next

2022-04-05T09:06:58+00:00

Let's start the 5.19 development cycle. Signed-off-by: Maxime Ripard

sysfb: Enable boot time VESA graphic mode selection

2022-03-04T19:55:33+00:00

Since switch to simplefb/simpledrm VESA graphic mode selection with vga= kernel parameter is no longer available with legacy BIOS. The x86 realmode boot code enables the VESA graphic modes when option FB_BOOT_VESA_SUPPORT is enabled. This option is selected by vesafb but not simplefb/simpledrm. To enable use of VESA modes with simplefb in legacy BIOS boot mode drop dependency of BOOT_VESA_SUPPORT on FB, also drop the FB_ prefix. Select the option from sysfb rather than the drivers that depend on it. The BOOT_VESA_SUPPORT is not specific to framebuffer but rather to x86 platform, move it from fbdev to x86 Kconfig. Fixes: e3263ab389a7 ("x86: provide platform-devices for boot-framebuffers") Signed-off-by: Michal Suchanek Reviewed-by: Javier Martinez Canillas Acked-by: Borislav Petkov Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/948c39940a4e99f5b43bdbcbe537faae71a43e1d.1645822213.git.msuchanek@suse.de

sysfb: Make config option dependencies explicit

2022-03-04T19:55:20+00:00

efifb and vesafb requires sysfb implicitly but this is not stated in Kconfig. Add the dependency. With that all drivers that require sysfb depend on it so it can default to disabled. Signed-off-by: Michal Suchanek Reviewed-by: Javier Martinez Canillas Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/a0fa41e9186653e4c41ad0a28259e5cdc71b1f66.1645822213.git.msuchanek@suse.de