linux.git/drivers/video/console/Kconfig, branch for-next

vgacon: drop IA64 reference in VGA_CONSOLE dependency list

2023-11-28T19:04:20+00:00

Commit e9e3300b6e77 ("vgacon: rework Kconfig dependencies") turns the
dependencies into a positive list of supported architectures, which
includes the IA64 architecture, but in the meantime, this architecture is
removed in commit cf8e8658100d ("arch: Remove Itanium (IA-64)
architecture").

Drop the reference to IA64 architecture in the dependency list of the
VGA_CONSOLE config definition.

Signed-off-by: Lukas Bulwahn 
Acked-by: Arnd Bergmann 
Reviewed-by: Javier Martinez Canillas 
Link: https://lore.kernel.org/r/20231110114400.30882-1-lukas.bulwahn@gmail.com
Signed-off-by: Greg Kroah-Hartman

dummycon: limit Arm console size hack to footbridge

2023-10-17T08:17:02+00:00

The dummycon default console size used to be determined by architecture,
but now this is a Kconfig setting on everything except ARM. Tracing this
back in the historic git trees, this was used to match the size of VGA
console or VGA framebuffer on early machines, but nowadays that code is
no longer used, except probably on the old footbridge/netwinder since
that is the only one that supports vgacon.

On machines with a framebuffer, booting with DT so far results in always
using the hardcoded 80x30 size in dummycon, while on ATAGS the setting
can come from a bootloader specific override. Both seem to be worse
choices than the Kconfig setting, since the actual text size for fbcon
also depends on the selected font.

Make this work the same way as everywhere else and use the normal
Kconfig setting, except for the footbridge with vgacon, which keeps
using the traditional code. If vgacon is disabled, footbridge can
also ignore the setting. This means the screen_info only has to be
provided when either vgacon or EFI are enabled now.

To limit the amount of surprises on Arm, change the Kconfig default
to the previously used 80x30 setting instead of the usual 80x25.

Reviewed-by: Thomas Zimmermann 
Tested-by: Linus Walleij 
Reviewed-by: Javier Martinez Canillas 
Acked-by: Helge Deller 
Signed-off-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/20231009211845.3136536-4-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman

vgacon: rework Kconfig dependencies

2023-10-17T08:17:01+00:00

The list of dependencies here is phrased as an opt-out, but this is missing
a lot of architectures that don't actually support VGA consoles, and some
of the entries are stale:

 - powerpc used to support VGA consoles in the old arch/ppc codebase, but
   the merged arch/powerpc never did

 - arm lists footbridge, integrator and netwinder, but netwinder is actually
   part of footbridge, and integrator does not appear to have an actual
   VGA hardware, or list it in its ATAG or DT.

 - mips has a few platforms (malta, sibyte, and sni) that initialize
   screen_info, on everything else the console is selected but cannot
   actually work.

 - csky, hexgagon, loongarch, nios2, riscv and xtensa are not listed
   in the opt-out table and declare a screen_info to allow building
   vga_con, but this cannot work because the console is never selected.

Replace this with an opt-in table that lists only the platforms that
remain. This is effectively x86, plus a couple of historic workstation
and server machines that reused parts of the x86 system architecture.

Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Thomas Zimmermann 
Reviewed-by: Khalid Aziz 
Acked-by: Helge Deller 
Signed-off-by: Arnd Bergmann 
Reviewed-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20231009211845.3136536-2-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman

drm: fix up fbdev Kconfig defaults

2023-09-18T08:52:55+00:00

As a result of the recent Kconfig reworks, the default settings for the
framebuffer interfaces changed in unexpected ways:

Configurations that leave CONFIG_FB disabled but use DRM now get
DRM_FBDEV_EMULATION by default. This also turns on the deprecated /dev/fb
device nodes for machines that don't actually want it.

In turn, configurations that previously had DRM_FBDEV_EMULATION enabled
now only get the /dev/fb front-end but not the more useful framebuffer
console, which is not selected any more.

We had previously decided that any combination of the three frontends
(FB_DEVICE, FRAMEBUFFER_CONSOLE and LOGO) should be selectable, but the
new default settings mean that a lot of defconfig files would have to
get adapted.

Change the defaults back to what they were in Linux 6.5:

 - Leave DRM_FBDEV_EMULATION turned off unless CONFIG_FB
   is enabled. Previously this was a hard dependency but now the two are
   independent. However, configurations that enable CONFIG_FB probably
   also want to keep the emulation for DRM, while those without FB
   presumably did that intentionally in the past.

 - Leave FB_DEVICE turned off for FB=n. Following the same
   logic, the deprecated option should not automatically get enabled
   here, most users that had FB turned off in the past do not want it,
   even if they want the console

 - Turn the FRAMEBUFFER_CONSOLE option on if
   DRM_FBDEV_EMULATION is set to avoid having to change defconfig
   files that relied on it being selected unconditionally in the past.
   This also makes sense since both LOGO and FB_DEVICE are now disabled
   by default for builds without CONFIG_FB, but DRM_FBDEV_EMULATION
   would make no sense if all three are disabled.

Fixes: a5ae331edb02b ("drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION")
Fixes: 701d2054fa317 ("fbdev: Make support for userspace interfaces configurable")
Reported-by: Geert Uytterhoeven 
Signed-off-by: Arnd Bergmann 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Thomas Zimmermann 
Signed-off-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20230911205338.2385278-1-arnd@kernel.org

fbdev: Split frame buffer support in FB and FB_CORE symbols

2023-07-22T10:25:04+00:00

Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
drivers are needed (e.g: only to have support for framebuffer consoles).

The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB
and so it can only be enabled if that dependency is enabled as well.

That means fbdev drivers have to be explicitly disabled if users want to
enable CONFIG_FB, only to use fbcon and/or the DRM fbdev emulation layer.

This patch introduces a non-visible CONFIG_FB_CORE symbol that could be
enabled just to have core support needed for CONFIG_DRM_FBDEV_EMULATION,
allowing CONFIG_FB to be disabled (and automatically disabling all the
fbdev drivers).

Nothing from fb_backlight.o and fbmon.o is used by the DRM fbdev emulation
layer so these two objects can be compiled out when CONFIG_FB is disabled.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Arnd Bergmann 
Tested-by: Arnd Bergmann 
Acked-by: Helge Deller 
Link: https://patchwork.freedesktop.org/patch/msgid/20230719081544.741051-4-javierm@redhat.com

video: Move HP PARISC STI core code to shared location

2023-04-20T08:04:51+00:00

STI core files have been located in console and fbdev code. Move
the source code and header to the directories for video helpers.
Also update the config and build rules such that the code depends
on the config symbol CONFIG_STI_CORE, which STI console and STI
framebuffer select automatically.

Cleans up the console makefile and prepares PARISC to implement
fb_is_primary_device() within the arch/ directory. No functional
changes.

Signed-off-by: Thomas Zimmermann 
Acked-by: Arnd Bergmann 
Acked-by: Helge Deller 
Link: https://patchwork.freedesktop.org/patch/msgid/20230417125651.25126-12-tzimmermann@suse.de

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

nds32: Remove the architecture

2022-03-07T12:54:59+00:00

The nds32 architecture, also known as AndeStar V3, is a custom 32-bit
RISC target designed by Andes Technologies. Support was added to the
kernel in 2016 as the replacement RISC-V based V5 processors were
already announced, and maintained by (current or former) Andes
employees.

As explained by Alan Kao, new customers are now all using RISC-V,
and all known nds32 users are already on longterm stable kernels
provided by Andes, with no development work going into mainline
support any more.

While the port is still in a reasonably good shape, it only gets
worse over time without active maintainers, so it seems best
to remove it before it becomes unusable. As always, if it turns
out that there are mainline users after all, and they volunteer
to maintain the port in the future, the removal can be reverted.

Link: https://lore.kernel.org/linux-mm/YhdWNLUhk+x9RAzU@yamatobi.andestech.com/
Link: https://lore.kernel.org/lkml/20220302065213.82702-1-alankao@andestech.com/
Link: https://www.andestech.com/en/products-solutions/andestar-architecture/
Signed-off-by: Alan Kao 
[arnd: rewrite changelog to provide more background]
Signed-off-by: Arnd Bergmann

fbcon: Add option to enable legacy hardware acceleration

2022-02-02T14:16:26+00:00

Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
enable bitblt and fillrect hardware acceleration in the framebuffer
console. If disabled, such acceleration will not be used, even if it is
supported by the graphics hardware driver.

If you plan to use DRM as your main graphics output system, you should
disable this option since it will prevent compiling in code which isn't
used later on when DRM takes over.

For all other configurations, e.g. if none of your graphic cards support
DRM (yet), DRM isn't available for your architecture, or you can't be
sure that the graphic card in the target system will support DRM, you
most likely want to enable this option.

In the non-accelerated case (e.g. when DRM is used), the inlined
fb_scrollmode() function is hardcoded to return SCROLL_REDRAW and as such the
compiler is able to optimize much unneccesary code away.

In this v3 patch version I additionally changed the GETVYRES() and GETVXRES()
macros to take a pointer to the fbcon_display struct. This fixes the build when
console rotation is enabled and helps the compiler again to optimize out code.

Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org # v5.10+
Signed-off-by: Helge Deller 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20220202135531.92183-4-deller@gmx.de

um: allow disabling NO_IOMEM

2021-06-17T19:44:50+00:00

Adjust the kconfig a little to allow disabling NO_IOMEM in UML. To
make an "allyesconfig" with CONFIG_NO_IOMEM=n build, adjust a few
Kconfig things elsewhere and add dummy asm/fb.h and asm/vga.h files.

Signed-off-by: Johannes Berg 
Signed-off-by: Richard Weinberger