Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-11 15:37:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/video/Kconfig

958 lines
32 KiB
Text
Raw Normal View History

drivers: hierarchize drivers Kconfig menu The menuconfig for drivers are getting more and more cluttered and unreadable because too many entries are displayed in a single flat menu. Use hierarchic menu for each category. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Update to apply again in a few places, drop USB hunk] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-07-25 17:46:26 +00:00
#
# Video configuration
#
menu "Graphics support"
dm: video: Add a video uclass U-Boot has separate code for LCDs and 'video' devices. Both now use a very similar API thanks to earlier work by Nikita Kiryanov. With the driver- model conversion we should unify these into a single uclass. Unfortunately there are different features supported by each. This implementation provides for a common set of features which should serve most purposes. The intent is to support: - bitmap devices with 8, 16 and 32 bits per pixel - text console wih white on black or vice versa - rotated text console - bitmap display (BMP format) More can be added as additional boards are ported over to use driver model for video. The name 'video' is chosen for the uclass since it is more generic than LCD. Another option would be 'display' but that would introduce a third concept to U-Boot which seems like the wrong approach. The existing LCD and video init functions are not needed now, so this uclass makes no attempt to implement them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:15 +00:00
config DM_VIDEO
bool "Enable driver model support for LCD/video"
depends on DM
help
This enables driver model for LCD and video devices. These support
a bitmap display of various sizes and depths which can be drawn on
to display a command-line console or splash screen. Enabling this
option compiles in the video uclass and routes all LCD/video access
through this.
video: make backlight and panel drivers optional Not all boards use these drivers, so allow to disable them to fix building boards with U-Boot binary image size restrictions. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-25 22:20:49 +00:00
config BACKLIGHT
bool "Enable panel backlight uclass support"
depends on DM_VIDEO
default y
help
This provides backlight uclass driver that enables basic panel
backlight support.
x86: video: Support copy framebuffer with probed devices For PCI video devices that are not mentioned in the devicetree, U-Boot does not bind a driver before relocation, since PCI is not fully probed at that point. Furthermore it is possible for the video device to be on a secondary bus which is not even scanned. This is fine if the framebuffer is allocated in fixed memory, as it normally is on x86. But when using this as a copy framebuffer, we also need U-Boot to allocate its own cached framebuffer for working in. Since the video driver is never bound before relocation, the framebuffer size is never set and U-Boot does no allocation. Add a new CONFIG option to reserve 16MB of memory for this eventuality. This allows vesa devices to use the copy framebuffer. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-03 03:12:33 +00:00
config VIDEO_PCI_DEFAULT_FB_SIZE
hex "Default framebuffer size to use if no drivers request it"
depends on DM_VIDEO
default 0x1000000 if X86 && PCI
default 0 if !(X86 && PCI)
help
Generally, video drivers request the amount of memory they need for
the frame buffer when they are bound, by setting the size field in
struct video_uc_platdata. That memory is then reserved for use after
relocation. But PCI drivers cannot be bound before relocation unless
they are mentioned in the devicetree.
With this value set appropriately, it is possible for PCI video
devices to have a framebuffer allocated by U-Boot.
Note: the framebuffer needs to be large enough to store all pixels at
maximum resolution. For example, at 1920 x 1200 with 32 bits per
pixel, 2560 * 1600 * 32 / 8 = 0xfa0000 bytes are needed.
video: Add support for copying to a hardware framebuffer Some architectures use a cached framebuffer and flush the cache as needed so that changes are visible. This is supported by U-Boot. However x86 uses an uncached framebuffer with a 'write-combining' feature to speed up writes. Reads are permitted but they are extremely expensive. Unfortunately, reading from the frame buffer is quite common, e.g. to scroll it. This makes scrolling very slow. Add a new feature which supports copying modified parts of the frame buffer to the uncached hardware buffer. This speeds up scrolling by at least 10x on x86 so the extra complexity cost seems worth it. As a starting point, add the Kconfig, update the video structures to keep track of the buffer and add a function to do the copy. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-03 03:12:20 +00:00
config VIDEO_COPY
bool "Enable copying the frame buffer to a hardware copy"
depends on DM_VIDEO
help
On some machines (e.g. x86), reading from the frame buffer is very
slow because it is uncached. To improve performance, this feature
allows the frame buffer to be kept in cached memory (allocated by
U-Boot) and then copied to the hardware frame-buffer as needed.
To use this, your video driver must set @copy_base in
struct video_uc_platdata.
dm: backlight: Add CONFIG_BACKLIGHT_PWM Add a config to select individually the driver for PWM backlights. Manage "depends on" to be backyard compatible. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2017-08-03 10:36:06 +00:00
config BACKLIGHT_PWM
bool "Generic PWM based Backlight Driver"
video: make backlight and panel drivers optional Not all boards use these drivers, so allow to disable them to fix building boards with U-Boot binary image size restrictions. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-25 22:20:49 +00:00
depends on BACKLIGHT && DM_PWM
dm: backlight: Add CONFIG_BACKLIGHT_PWM Add a config to select individually the driver for PWM backlights. Manage "depends on" to be backyard compatible. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2017-08-03 10:36:06 +00:00
default y
help
If you have a LCD backlight adjustable by PWM, say Y to enable
this driver.
This driver can be use with "simple-panel" and
it understands the standard device tree
(leds/backlight/pwm-backlight.txt)
dm: backlight: Add a driver for GPIO backlight Add a driver for GPIO backlights. It understands the standard device tree binding. It can be used with simple-panel when PWM is not necessary. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2017-08-03 10:36:07 +00:00
config BACKLIGHT_GPIO
bool "Generic GPIO based Backlight Driver"
video: make backlight and panel drivers optional Not all boards use these drivers, so allow to disable them to fix building boards with U-Boot binary image size restrictions. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-25 22:20:49 +00:00
depends on BACKLIGHT
dm: backlight: Add a driver for GPIO backlight Add a driver for GPIO backlights. It understands the standard device tree binding. It can be used with simple-panel when PWM is not necessary. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2017-08-03 10:36:07 +00:00
help
If you have a LCD backlight adjustable by GPIO, say Y to enable
this driver.
This driver can be used with "simple-panel" and
it understands the standard device tree
(leds/backlight/gpio-backlight.txt)
video: make vidconsole commands optional Converting some boards to DM_VIDEO results in build breakage due to increased code size. Make video console specific commands optional to reduce binary size. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-25 19:47:19 +00:00
config CMD_VIDCONSOLE
bool "Enable vidconsole commands lcdputs and setcurs"
depends on DM_VIDEO
default y
help
Enabling this will provide 'setcurs' and 'lcdputs' commands which
support cursor positioning and drawing strings on video framebuffer.
dm: video: Add a video uclass U-Boot has separate code for LCDs and 'video' devices. Both now use a very similar API thanks to earlier work by Nikita Kiryanov. With the driver- model conversion we should unify these into a single uclass. Unfortunately there are different features supported by each. This implementation provides for a common set of features which should serve most purposes. The intent is to support: - bitmap devices with 8, 16 and 32 bits per pixel - text console wih white on black or vice versa - rotated text console - bitmap display (BMP format) More can be added as additional boards are ported over to use driver model for video. The name 'video' is chosen for the uclass since it is more generic than LCD. Another option would be 'display' but that would introduce a third concept to U-Boot which seems like the wrong approach. The existing LCD and video init functions are not needed now, so this uclass makes no attempt to implement them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:15 +00:00
config VIDEO_BPP8
bool "Support 8-bit-per-pixel displays"
depends on DM_VIDEO
video: enable VIDEO_ANSI and all VIDEO_BBP options This partially reverts changes by commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional") since it caused issues with other boards (missing LCD console output on pinebook, x86 platform or sandbox). Enable all disabled options again and opt out of not supported color depth in board defconfigs. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reported-by: Vagrant Cascadian <vagrant@debian.org>
2020-02-04 21:43:06 +00:00
default y
dm: video: Add a video uclass U-Boot has separate code for LCDs and 'video' devices. Both now use a very similar API thanks to earlier work by Nikita Kiryanov. With the driver- model conversion we should unify these into a single uclass. Unfortunately there are different features supported by each. This implementation provides for a common set of features which should serve most purposes. The intent is to support: - bitmap devices with 8, 16 and 32 bits per pixel - text console wih white on black or vice versa - rotated text console - bitmap display (BMP format) More can be added as additional boards are ported over to use driver model for video. The name 'video' is chosen for the uclass since it is more generic than LCD. Another option would be 'display' but that would introduce a third concept to U-Boot which seems like the wrong approach. The existing LCD and video init functions are not needed now, so this uclass makes no attempt to implement them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:15 +00:00
help
Support drawing text and bitmaps onto a 8-bit-per-pixel display.
Enabling this will include code to support this display. Without
this option, such displays will not be supported and console output
will be empty.
config VIDEO_BPP16
bool "Support 16-bit-per-pixel displays"
depends on DM_VIDEO
video: enable VIDEO_ANSI and all VIDEO_BBP options This partially reverts changes by commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional") since it caused issues with other boards (missing LCD console output on pinebook, x86 platform or sandbox). Enable all disabled options again and opt out of not supported color depth in board defconfigs. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reported-by: Vagrant Cascadian <vagrant@debian.org>
2020-02-04 21:43:06 +00:00
default y
dm: video: Add a video uclass U-Boot has separate code for LCDs and 'video' devices. Both now use a very similar API thanks to earlier work by Nikita Kiryanov. With the driver- model conversion we should unify these into a single uclass. Unfortunately there are different features supported by each. This implementation provides for a common set of features which should serve most purposes. The intent is to support: - bitmap devices with 8, 16 and 32 bits per pixel - text console wih white on black or vice versa - rotated text console - bitmap display (BMP format) More can be added as additional boards are ported over to use driver model for video. The name 'video' is chosen for the uclass since it is more generic than LCD. Another option would be 'display' but that would introduce a third concept to U-Boot which seems like the wrong approach. The existing LCD and video init functions are not needed now, so this uclass makes no attempt to implement them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:15 +00:00
help
Support drawing text and bitmaps onto a 16-bit-per-pixel display.
Enabling this will include code to support this display. Without
this option, such displays will not be supported and console output
will be empty.
config VIDEO_BPP32
bool "Support 32-bit-per-pixel displays"
depends on DM_VIDEO
video: enable VIDEO_ANSI and all VIDEO_BBP options This partially reverts changes by commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional") since it caused issues with other boards (missing LCD console output on pinebook, x86 platform or sandbox). Enable all disabled options again and opt out of not supported color depth in board defconfigs. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reported-by: Vagrant Cascadian <vagrant@debian.org>
2020-02-04 21:43:06 +00:00
default y
dm: video: Add a video uclass U-Boot has separate code for LCDs and 'video' devices. Both now use a very similar API thanks to earlier work by Nikita Kiryanov. With the driver- model conversion we should unify these into a single uclass. Unfortunately there are different features supported by each. This implementation provides for a common set of features which should serve most purposes. The intent is to support: - bitmap devices with 8, 16 and 32 bits per pixel - text console wih white on black or vice versa - rotated text console - bitmap display (BMP format) More can be added as additional boards are ported over to use driver model for video. The name 'video' is chosen for the uclass since it is more generic than LCD. Another option would be 'display' but that would introduce a third concept to U-Boot which seems like the wrong approach. The existing LCD and video init functions are not needed now, so this uclass makes no attempt to implement them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:15 +00:00
help
Support drawing text and bitmaps onto a 32-bit-per-pixel display.
Enabling this will include code to support this display. Without
this option, such displays will not be supported and console output
will be empty.
dm: video: Add basic ANSI escape sequence support Really just the subset that is needed by efi_console. Perhaps more will be added later, for example color support would be useful to implement efi_cout_set_attribute(). Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-09-13 22:12:21 +00:00
config VIDEO_ANSI
bool "Support ANSI escape sequences in video console"
depends on DM_VIDEO
video: enable VIDEO_ANSI and all VIDEO_BBP options This partially reverts changes by commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional") since it caused issues with other boards (missing LCD console output on pinebook, x86 platform or sandbox). Enable all disabled options again and opt out of not supported color depth in board defconfigs. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reported-by: Vagrant Cascadian <vagrant@debian.org>
2020-02-04 21:43:06 +00:00
default y
dm: video: Add basic ANSI escape sequence support Really just the subset that is needed by efi_console. Perhaps more will be added later, for example color support would be useful to implement efi_cout_set_attribute(). Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-09-13 22:12:21 +00:00
help
Enable ANSI escape sequence decoding for a more fully functional
console.
video: add support of MIPI DSI interface Mipi_display.c contains a set of dsi helpers. This file is a copy of file drm_mipi_dsi.c (linux kernel). Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
2019-10-07 13:29:04 +00:00
config VIDEO_MIPI_DSI
bool "Support MIPI DSI interface"
depends on DM_VIDEO
help
Support MIPI DSI interface for driving a MIPI compatible device.
The MIPI Display Serial Interface (MIPI DSI) defines a high-speed
serial interface between a host processor and a display module.
video kconfig console_normal Signed-off-by: Simon Glass <sjg@chromium.org> [agust: rebased on current master] Signed-off-by: Anatolij Gustschin <agust@denx.de>
2016-01-22 20:53:37 +00:00
config CONSOLE_NORMAL
bool "Support a simple text console"
depends on DM_VIDEO
default y if DM_VIDEO
help
Support drawing text on the frame buffer console so that it can be
used as a console. Rotation is not supported by this driver (see
CONFIG_CONSOLE_ROTATION for that). A built-in 8x16 font is used
for the display.
config CONSOLE_ROTATION
dm: video: Add a driver for a rotated text console Sometimes the console must be rotated. Add a driver which supports rotating the text clockwise to 90, 180 and 270 degrees. This can support devices where the display is rotated for mechanical reasons. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:19 +00:00
bool "Support rotated displays"
depends on DM_VIDEO
help
Sometimes, for example if the display is mounted in portrait
mode or even if it's mounted landscape but rotated by 180degree,
we need to rotate our content of the display relative to the
framebuffer, so that user can read the messages which are
printed out. Enable this option to include a text driver which can
support this. The rotation is set by the 'rot' parameter in
struct video_priv: 0=unrotated, 1=90 degrees clockwise, 2=180
degrees, 3=270 degrees.
video: Add a console driver that uses TrueType fonts The existing 8x16 font is adequate for most purposes. It is small and fast. However for boot screens where information must be presented to the user, the console font is not ideal. Common requirements are larger and better-looking fonts. This console driver can use TrueType fonts built into U-Boot, and render them at any size. This can be used in scripts to place text as needed on the display. This driver is not really designed to operate with the command line. Much of U-Boot expects a fixed-width font. But to keep things working correctly, rudimentary support for the console is provided. The main missing feature is support for command-line editing. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Anatolij Gustschin <agust@denx.de>
2016-01-15 01:10:42 +00:00
config CONSOLE_TRUETYPE
bool "Support a console that uses TrueType fonts"
depends on DM_VIDEO
help
TrueTrype fonts can provide outline-drawing capability rather than
needing to provide a bitmap for each font and size that is needed.
With this option you can adjust the text size and use a variety of
fonts. Note that this is noticeably slower than with normal console.
config CONSOLE_TRUETYPE_SIZE
int "TrueType font size"
depends on CONSOLE_TRUETYPE
default 18
help
This sets the font size for the console. The size is measured in
pixels and is the nominal height of a character. Note that fonts
are commonly measured in 'points', being 1/72 inch (about 3.52mm).
However that measurement depends on the size of your display and
there is no standard display density. At present there is not a
method to select the display's physical size, which would allow
U-Boot to calculate the correct font size.
Convert CONFIG_SYS_WHITE_ON_BLACK to Kconfig This converts the following to Kconfig: CONFIG_SYS_WHITE_ON_BLACK Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Make this default y on various SoCs] Signed-off-by: Tom Rini <trini@konsulko.com>
2017-04-27 04:27:57 +00:00
config SYS_WHITE_ON_BLACK
bool "Display console as white on a black background"
rename symbol: CONFIG_TEGRA -> CONFIG_ARCH_TEGRA Have this symbol follow the pattern of all other such symbols. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
2020-05-06 12:02:41 +00:00
default y if ARCH_AT91 || ARCH_EXYNOS || ARCH_ROCKCHIP || ARCH_TEGRA || X86 || ARCH_SUNXI
Convert CONFIG_SYS_WHITE_ON_BLACK to Kconfig This converts the following to Kconfig: CONFIG_SYS_WHITE_ON_BLACK Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Make this default y on various SoCs] Signed-off-by: Tom Rini <trini@konsulko.com>
2017-04-27 04:27:57 +00:00
help
Normally the display is black on a white background, Enable this
option to invert this, i.e. white on a black background. This can be
better in low-light situations or to reduce eye strain in some
cases.
video: add config option to skip framebuffer clear The use-case is that the thing that loaded u-boot already put a splash image on screen. And we want to preserve that until grub boot menu takes over. Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-08-03 16:47:01 +00:00
config NO_FB_CLEAR
bool "Skip framebuffer clear"
help
If firmware (whatever loads u-boot) has already put a splash image
on screen, you might want to preserve it until whatever u-boot
loads takes over the screen. This, for example, can be used to
keep splash image on screen until grub graphical boot menu starts.
video: make backlight and panel drivers optional Not all boards use these drivers, so allow to disable them to fix building boards with U-Boot binary image size restrictions. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-05-25 22:20:49 +00:00
config PANEL
bool "Enable panel uclass support"
depends on DM_VIDEO
default y
help
This provides panel uclass driver that enables basic panel support.
config SIMPLE_PANEL
bool "Enable simple panel support"
depends on PANEL
default y
help
This turns on a simple panel driver that enables a compatible
video panel.
video: Add a console driver that uses TrueType fonts The existing 8x16 font is adequate for most purposes. It is small and fast. However for boot screens where information must be presented to the user, the console font is not ideal. Common requirements are larger and better-looking fonts. This console driver can use TrueType fonts built into U-Boot, and render them at any size. This can be used in scripts to place text as needed on the display. This driver is not really designed to operate with the command line. Much of U-Boot expects a fixed-width font. But to keep things working correctly, rudimentary support for the console is provided. The main missing feature is support for command-line editing. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Anatolij Gustschin <agust@denx.de>
2016-01-15 01:10:42 +00:00
source "drivers/video/fonts/Kconfig"
dm: video: Add a temporary work-around for old stdout var Boards with a saved environment may use 'lcd' in their stdout environment variable, expecting that this will enable output to the LCD. When the board moves to use driver model for video, this will no-longer work. Add a work-around to fix this. A warning messages is printed, and we will remove the work-around at the end of 2016. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com>
2016-02-06 21:31:37 +00:00
config VIDCONSOLE_AS_LCD
video: restore CONFIG_VIDCONSOLE_AS_LCD as boolean This patch restores CONFIG_VIDCONSOLE_AS_LCD as boolean and introduce a separate sting as CONFIG_VIDCONSOLE_AS_NAME to search this string in stdout used as videoconsole. This patch avoid issue with board defconfig or code expecting CONFIG_VIDCONSOLE_AS_LCD as boolean. Fixes: 22b897a12323 ("video: extend stdout video console work-around for 'vga'") Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-07-01 12:56:10 +00:00
bool "Use 'vidconsole' when CONFIG_VIDCONSOLE_AS_NAME string is seen in stdout"
dm: video: Add a temporary work-around for old stdout var Boards with a saved environment may use 'lcd' in their stdout environment variable, expecting that this will enable output to the LCD. When the board moves to use driver model for video, this will no-longer work. Add a work-around to fix this. A warning messages is printed, and we will remove the work-around at the end of 2016. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com>
2016-02-06 21:31:37 +00:00
depends on DM_VIDEO
video: restore CONFIG_VIDCONSOLE_AS_LCD as boolean This patch restores CONFIG_VIDCONSOLE_AS_LCD as boolean and introduce a separate sting as CONFIG_VIDCONSOLE_AS_NAME to search this string in stdout used as videoconsole. This patch avoid issue with board defconfig or code expecting CONFIG_VIDCONSOLE_AS_LCD as boolean. Fixes: 22b897a12323 ("video: extend stdout video console work-around for 'vga'") Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-07-01 12:56:10 +00:00
help
This is a work-around for boards which have 'lcd' or 'vga' in their
stdout environment variable, but have moved to use driver model for
video. In this case the console will no-longer work. While it is
possible to update the environment, the breakage may be confusing for
users. This option will be removed around the end of 2020.
config VIDCONSOLE_AS_NAME
string "Use 'vidconsole' when string defined here is seen in stdout"
depends on VIDCONSOLE_AS_LCD
video: extend stdout video console work-around for 'vga' cfb_console driver uses 'vga' console name and we still have board environments defining this name. Re-use existing DM_VIDEO work- around for console name to support 'vga' name in stdout environment. Signed-off-by: Anatolij Gustschin <agust@denx.de> Tested-by: Soeren Moch <smoch@web.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-05-23 15:11:20 +00:00
default "lcd" if LCD || TEGRA_COMMON
default "vga" if !LCD
help
This is a work-around for boards which have 'lcd' or 'vga' in their
stdout environment variable, but have moved to use driver model for
video. In this case the console will no-longer work. While it is
possible to update the environment, the breakage may be confusing for
users. This option will be removed around the end of 2020.
dm: video: Add a temporary work-around for old stdout var Boards with a saved environment may use 'lcd' in their stdout environment variable, expecting that this will enable output to the LCD. When the board moves to use driver model for video, this will no-longer work. Add a work-around to fix this. A warning messages is printed, and we will remove the work-around at the end of 2016. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Tested-by: Stephen Warren <swarren@nvidia.com>
2016-02-06 21:31:37 +00:00
dm: video: Add driver for coreboot framebuffer device This adds a DM driver for coreboot framebuffer device. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-09 11:14:16 +00:00
config VIDEO_COREBOOT
bool "Enable coreboot framebuffer driver support"
depends on X86 && SYS_COREBOOT
help
Turn on this option to enable a framebuffer driver when U-Boot is
loaded by coreboot where the graphics device is configured by
coreboot already. This can in principle be used with any platform
that coreboot supports.
dm: video: Add an EFI framebuffer driver This adds a DM video driver for U-Boot as the EFI payload. The driver makes use of all necessary information from the passed EFI GOP info to create a linear framebuffer device, as if it were initialized by U-Boot itself. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Anatolij Gustschin <agust@denx.de>
2018-06-12 15:36:22 +00:00
config VIDEO_EFI
bool "Enable EFI framebuffer driver support"
depends on EFI_STUB
help
Turn on this option to enable a framebuffeer driver when U-Boot is
loaded as a payload (see README.u-boot_on_efi) by an EFI BIOS where
the graphics device is configured by the EFI BIOS already. This can
in principle be used with any platform that has an EFI BIOS.
x86: Add a VESA video driver Add a driver intended to cope with any VESA-compatible x86 graphics adapter. It will not support ROMs which use OpenFirmware (Forth) since there is no support for that in U-Boot. This means that MAC OS cards will not work. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-12-30 02:32:28 +00:00
config VIDEO_VESA
bool "Enable VESA video driver support"
default n
help
Turn on this option to enable a very simple driver which uses vesa
to discover the video mode and then provides a frame buffer for use
by U-Boot. This can in principle be used with any platform that
supports PCI and video cards that support VESA BIOS Extension (VBE).
x86: Move FRAMEBUFFER_SET_VESA_MODE etc to video Kconfig CONFIG_FRAMEBUFFER_SET_VESA_MODE and CONFIG_FRAMEBUFFER_VESA_MODE are not x86-specific, so move them to drivers/video/Kconfig and make them depend on VIDEO_VESA driver. Some cosmetic fixes are applied to the Kconfig help text as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-05-10 23:36:29 +00:00
config FRAMEBUFFER_SET_VESA_MODE
bool "Set framebuffer graphics resolution"
x86: broadwell: Add video support Add a video driver for Intel's broadwell integrated graphics controller. This uses a binary blob for most init, with the driver just performing a few basic tasks. This driver supports VESA as the mode-setting mechanism. Since most boards don't support driver model yet with VESA, a special case is added to the Kconfig for broadwell. Eventually all boards will use driver model and this can be removed. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:30 +00:00
depends on VIDEO_VESA || VIDEO_BROADWELL_IGD
x86: Move FRAMEBUFFER_SET_VESA_MODE etc to video Kconfig CONFIG_FRAMEBUFFER_SET_VESA_MODE and CONFIG_FRAMEBUFFER_VESA_MODE are not x86-specific, so move them to drivers/video/Kconfig and make them depend on VIDEO_VESA driver. Some cosmetic fixes are applied to the Kconfig help text as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-05-10 23:36:29 +00:00
help
Set VESA/native framebuffer mode (needed for bootsplash and graphical
framebuffer console)
choice
prompt "framebuffer graphics resolution"
video: vesa: Change default FRAMEBUFFER_VESA_MODE This changes the default FRAMEBUFFER_VESA_MODE to use 32-bit pixel format for better VxWorks compatibility. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-04-12 05:02:16 +00:00
default FRAMEBUFFER_VESA_MODE_118
x86: Move FRAMEBUFFER_SET_VESA_MODE etc to video Kconfig CONFIG_FRAMEBUFFER_SET_VESA_MODE and CONFIG_FRAMEBUFFER_VESA_MODE are not x86-specific, so move them to drivers/video/Kconfig and make them depend on VIDEO_VESA driver. Some cosmetic fixes are applied to the Kconfig help text as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-05-10 23:36:29 +00:00
depends on FRAMEBUFFER_SET_VESA_MODE
help
This option sets the resolution used for the U-Boot framebuffer (and
bootsplash screen).
config FRAMEBUFFER_VESA_MODE_100
bool "640x400 256-color"
config FRAMEBUFFER_VESA_MODE_101
bool "640x480 256-color"
config FRAMEBUFFER_VESA_MODE_102
bool "800x600 16-color"
config FRAMEBUFFER_VESA_MODE_103
bool "800x600 256-color"
config FRAMEBUFFER_VESA_MODE_104
bool "1024x768 16-color"
config FRAMEBUFFER_VESA_MODE_105
video: vesa: Correct a typo in the Kconfig VESA mode string There is one typo in the VESA mode 105h string. Correct it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-10 06:26:59 +00:00
bool "1024x768 256-color"
x86: Move FRAMEBUFFER_SET_VESA_MODE etc to video Kconfig CONFIG_FRAMEBUFFER_SET_VESA_MODE and CONFIG_FRAMEBUFFER_VESA_MODE are not x86-specific, so move them to drivers/video/Kconfig and make them depend on VIDEO_VESA driver. Some cosmetic fixes are applied to the Kconfig help text as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-05-10 23:36:29 +00:00
config FRAMEBUFFER_VESA_MODE_106
bool "1280x1024 16-color"
config FRAMEBUFFER_VESA_MODE_107
bool "1280x1024 256-color"
config FRAMEBUFFER_VESA_MODE_108
bool "80x60 text"
config FRAMEBUFFER_VESA_MODE_109
bool "132x25 text"
config FRAMEBUFFER_VESA_MODE_10A
bool "132x43 text"
config FRAMEBUFFER_VESA_MODE_10B
bool "132x50 text"
config FRAMEBUFFER_VESA_MODE_10C
bool "132x60 text"
config FRAMEBUFFER_VESA_MODE_10D
bool "320x200 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_10E
bool "320x200 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_10F
bool "320x200 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_110
bool "640x480 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_111
bool "640x480 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_112
bool "640x480 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_113
bool "800x600 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_114
bool "800x600 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_115
bool "800x600 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_116
bool "1024x768 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_117
bool "1024x768 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_118
bool "1024x768 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_119
bool "1280x1024 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_11A
bool "1280x1024 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_11B
bool "1280x1024 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_USER
bool "Manually select VESA mode"
endchoice
# Map the config names to an integer (KB).
config FRAMEBUFFER_VESA_MODE
prompt "VESA mode" if FRAMEBUFFER_VESA_MODE_USER
hex
default 0x100 if FRAMEBUFFER_VESA_MODE_100
default 0x101 if FRAMEBUFFER_VESA_MODE_101
default 0x102 if FRAMEBUFFER_VESA_MODE_102
default 0x103 if FRAMEBUFFER_VESA_MODE_103
default 0x104 if FRAMEBUFFER_VESA_MODE_104
default 0x105 if FRAMEBUFFER_VESA_MODE_105
default 0x106 if FRAMEBUFFER_VESA_MODE_106
default 0x107 if FRAMEBUFFER_VESA_MODE_107
default 0x108 if FRAMEBUFFER_VESA_MODE_108
default 0x109 if FRAMEBUFFER_VESA_MODE_109
default 0x10A if FRAMEBUFFER_VESA_MODE_10A
default 0x10B if FRAMEBUFFER_VESA_MODE_10B
default 0x10C if FRAMEBUFFER_VESA_MODE_10C
default 0x10D if FRAMEBUFFER_VESA_MODE_10D
default 0x10E if FRAMEBUFFER_VESA_MODE_10E
default 0x10F if FRAMEBUFFER_VESA_MODE_10F
default 0x110 if FRAMEBUFFER_VESA_MODE_110
default 0x111 if FRAMEBUFFER_VESA_MODE_111
default 0x112 if FRAMEBUFFER_VESA_MODE_112
default 0x113 if FRAMEBUFFER_VESA_MODE_113
default 0x114 if FRAMEBUFFER_VESA_MODE_114
default 0x115 if FRAMEBUFFER_VESA_MODE_115
default 0x116 if FRAMEBUFFER_VESA_MODE_116
default 0x117 if FRAMEBUFFER_VESA_MODE_117
default 0x118 if FRAMEBUFFER_VESA_MODE_118
default 0x119 if FRAMEBUFFER_VESA_MODE_119
default 0x11A if FRAMEBUFFER_VESA_MODE_11A
default 0x11B if FRAMEBUFFER_VESA_MODE_11B
default 0x117 if FRAMEBUFFER_VESA_MODE_USER
video: Add support for the ANX9804 parallel lcd to dp bridge chip Add support for the ANX9804 bridge chip, which can take pixel data coming from a parallel LCD interface and translate it on the fly into a DP interface for driving eDP TFT displays. It uses I2C for configuration. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-08-08 14:03:29 +00:00
config VIDEO_LCD_ANX9804
bool "ANX9804 bridge chip"
default n
---help---
Support for the ANX9804 bridge chip, which can take pixel data coming
from a parallel LCD interface and translate it on the fy into a DP
interface for driving eDP TFT displays. It uses I2C for configuration.
video: add support of panel OTM8009A Support for Orise Tech otm8009a 480p dsi 2dl video mode panel. Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
2019-10-07 13:29:08 +00:00
config VIDEO_LCD_ORISETECH_OTM8009A
bool "OTM8009A DSI LCD panel support"
depends on DM_VIDEO
select VIDEO_MIPI_DSI
default n
help
Say Y here if you want to enable support for Orise Technology
otm8009a 480x800 dsi 2dl panel.
video: add support of panel RM68200 Support for Raydium RM68200 720p dsi 2dl video mode panel. This rm68200 panel driver is based on the Linux Kernel driver from drivers/gpu/drm/panel/panel-raydium-rm68200.c. Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
2019-10-07 13:29:09 +00:00
config VIDEO_LCD_RAYDIUM_RM68200
bool "RM68200 DSI LCD panel support"
depends on DM_VIDEO
select VIDEO_MIPI_DSI
default n
help
Say Y here if you want to enable support for Raydium RM68200
720x1280 DSI video mode panel.
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
---help---
Support for the SSD2828 bridge chip, which can take pixel data coming
from a parallel LCD interface and translate it on the fly into MIPI DSI
interface for driving a MIPI compatible LCD panel. It uses SPI for
configuration.
config VIDEO_LCD_SSD2828_TX_CLK
int "SSD2828 TX_CLK frequency (in MHz)"
depends on VIDEO_LCD_SSD2828
video: ssd2828: Allow using 'pclk' as the PLL clock source Instead of using the internal 'tx_clk' clock source, it is also possible to use the pixel clock signal from the parallel LCD interface ('pclk') as the reference clock for PLL. The 'tx_clk' clock speed may be different on different boards/devices (the allowed range is 8MHz - 30MHz). Which is not very convenient, especially considering the need to know the exact 'tx_clk' clock speed. This clock speed may be difficult to identify without having device schematics and/or accurate documentation/sources every time. Using 'pclk' is free from all these problems. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:35 +00:00
default 0
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
---help---
The frequency of the crystal, which is clocking SSD2828. It may be
anything in the 8MHz-30MHz range and the exact value should be
retrieved from the board schematics. Or in the case of Allwinner
hardware, it can be usually found as 'lcd_xtal_freq' variable in
video: ssd2828: Allow using 'pclk' as the PLL clock source Instead of using the internal 'tx_clk' clock source, it is also possible to use the pixel clock signal from the parallel LCD interface ('pclk') as the reference clock for PLL. The 'tx_clk' clock speed may be different on different boards/devices (the allowed range is 8MHz - 30MHz). Which is not very convenient, especially considering the need to know the exact 'tx_clk' clock speed. This clock speed may be difficult to identify without having device schematics and/or accurate documentation/sources every time. Using 'pclk' is free from all these problems. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:35 +00:00
FEX files. It can be also set to 0 for selecting PCLK from the
parallel LCD interface instead of TX_CLK as the PLL clock source.
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
config VIDEO_LCD_SSD2828_RESET
string "RESET pin of SSD2828"
depends on VIDEO_LCD_SSD2828
default ""
---help---
The reset pin of SSD2828 chip. This takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
video: Add support for Hitachi tx18d42vm LVDS LCD panels Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-01-20 08:22:26 +00:00
config VIDEO_LCD_HITACHI_TX18D42VM
bool "Hitachi tx18d42vm LVDS LCD panel support"
depends on VIDEO
default n
---help---
Support for Hitachi tx18d42vm LVDS LCD panels, these panels have a
lcd controller which needs to be initialized over SPI, once that is
done they work like a regular LVDS panel.
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
config VIDEO_LCD_SPI_CS
string "SPI CS pin for LCD related config job"
video: Add support for Hitachi tx18d42vm LVDS LCD panels Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-01-20 08:22:26 +00:00
depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
default ""
---help---
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
config VIDEO_LCD_SPI_SCLK
string "SPI SCLK pin for LCD related config job"
video: Add support for Hitachi tx18d42vm LVDS LCD panels Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-01-20 08:22:26 +00:00
depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
default ""
---help---
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
config VIDEO_LCD_SPI_MOSI
string "SPI MOSI pin for LCD related config job"
video: Add support for Hitachi tx18d42vm LVDS LCD panels Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-01-20 08:22:26 +00:00
depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
default ""
---help---
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
config VIDEO_LCD_SPI_MISO
string "SPI MISO pin for LCD related config job (optional)"
depends on VIDEO_LCD_SSD2828
default ""
---help---
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. If wired up, this pin may provide additional
useful functionality. Such as bi-directional communication with the
hardware and LCD panel id retrieval (if the panel can report it). The
option takes a string in the format understood by 'name_to_gpio'
function, e.g. PH1 for pin 1 of port H.
dm: video: Add a uclass for display port eDP (Embedded DisplayPort) is a standard widely used in laptops to drive LCD panels. Add a uclass for this which supports a few simple operations. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 03:03:38 +00:00
video: Add Meson Video Processing Unit Driver This adds video output support for Amlogic GXBB/GXL/GXM chips. The supported ports are CVBS and HDMI (based on DW_HDMI). When using HDMI, only DMT modes are supported. There is support for simple-framebuffer (CONFIG_VIDEO_DT_SIMPLEFB) Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Jorge Ramire-Ortiz <jramirez@baylibre.com> Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> [narmstrong: fixed defines alignment in meson_canvas.c] Reviewed-by: Anatolij Gustschin <agust@denx.de>
2018-07-24 15:45:28 +00:00
source "drivers/video/meson/Kconfig"
video: Add support for Armada XP LCD controller This patch adds basic support for the LCD controller of the Marvell Armada XP SoC. An AXP based custom board port will be added later, to use this driver to display a splash screen via the bmp command later. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Anatolij Gustschin <agust@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr> [agust: rebased] Signed-off-by: Anatolij Gustschin <agust@denx.de>
2016-01-20 07:13:28 +00:00
config VIDEO_MVEBU
bool "Armada XP LCD controller"
default n
---help---
Support for the LCD controller integrated in the Marvell
Armada XP SoC.
Convert CONFIG_VIDEO_OMAP3 to Kconfig This converts the following to Kconfig: CONFIG_VIDEO_OMAP3 Signed-off-by: Adam Ford <aford173@gmail.com>
2018-08-02 13:50:20 +00:00
config VIDEO_OMAP3
bool "Enable OMAP3+ DSS Support"
depends on ARCH_OMAP2PLUS
help
This enables the Display subsystem (DSS) on OMAP3+ boards.
video: add CONFIG_I2C_EDID and disable CONFIG_DISPLAY by default Enabling CONFIG_DISPLAY breaks building for some architectures (microblaze-generic), so we disable CONFIG_DISPLAY in Kconfig by default and enable this option in defconfigs. CONFIG_DISPLAY depends on CONFIG_I2C_EDID, so add and enable it in defconfigs, too. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reported-by: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Anatolij Gustschin <agust@denx.de>
2016-01-25 16:17:22 +00:00
config I2C_EDID
bool "Enable EDID library"
default n
help
This enables library for accessing EDID data from an LCD panel.
dm: video: Repurpose the 'displayport' uclass to 'display' The current DisplayPort uclass is too specific. The operations it provides are shared with other types of output devices, such as HDMI and LVDS LCD displays. Generalise the uclass so that it can be used with these devices as well. Adjust the uclass to handle the EDID reading and conversion to display_timing internally. Also update nyan-big which is affected by this. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:45:00 +00:00
config DISPLAY
bool "Enable Display support"
depends on DM
video: add CONFIG_I2C_EDID and disable CONFIG_DISPLAY by default Enabling CONFIG_DISPLAY breaks building for some architectures (microblaze-generic), so we disable CONFIG_DISPLAY in Kconfig by default and enable this option in defconfigs. CONFIG_DISPLAY depends on CONFIG_I2C_EDID, so add and enable it in defconfigs, too. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reported-by: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Anatolij Gustschin <agust@denx.de>
2016-01-25 16:17:22 +00:00
default n
select I2C_EDID
dm: video: Add a uclass for display port eDP (Embedded DisplayPort) is a standard widely used in laptops to drive LCD panels. Add a uclass for this which supports a few simple operations. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 03:03:38 +00:00
help
dm: video: Repurpose the 'displayport' uclass to 'display' The current DisplayPort uclass is too specific. The operations it provides are shared with other types of output devices, such as HDMI and LVDS LCD displays. Generalise the uclass so that it can be used with these devices as well. Adjust the uclass to handle the EDID reading and conversion to display_timing internally. Also update nyan-big which is affected by this. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:45:00 +00:00
This supports drivers that provide a display, such as eDP (Embedded
DisplayPort) and HDMI (High Definition Multimedia Interface).
The devices provide a simple interface to start up the display,
read display information and enable it.
tegra: video: support eDP displays on Tegra124 devices Connect up the clocks and the eDP driver to make these displays work with Tegra124-based devices. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 03:03:42 +00:00
video: Add support for NXP's TDA19988 HDMI encoder Add support for the NXP TDA19988 HDMI encoder as used on the Juno development board from Arm. Signed-off-by: Liviu Dudau <liviu.dudau@foss.arm.com>
2018-09-28 12:49:31 +00:00
config NXP_TDA19988
bool "Enable NXP TDA19988 support"
depends on DISPLAY
default n
help
This enables support for the NXP TDA19988 HDMI encoder. This encoder
will convert RGB data streams into HDMI-encoded signals.
at91: video: Support driver-model for the HLCD driver Add driver-model support to this driver. Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
2017-04-11 08:33:30 +00:00
config ATMEL_HLCD
bool "Enable ATMEL video support using HLCDC"
help
HLCDC supports video output to an attached LCD panel.
video: omap: add support for DM/DTS Update the driver to support the device tree and the driver model. Timings and panel parameters are now loaded from the device tree. The DM code replaces the am335x_lcdpanel structure with tilcdc_panel_info taken from the linux kernel, as well the management of additional parameters not covered in the legacy code. In addition, the am335x_lcdpanel structure contains parameters and operations that were probably a requirement of the board for which this driver was developed and which, however, were not developed in the linux kernel. All this led to rewrite th DM controller initialization code, except for the pixel clock setting that is executed in a function created in a previous patch with code taken from the legacy am335xfb_init. The patch has been tested on a custom board with u-boot 2018.11-rc2 and the following device-tree configuration: panel { compatible = "ti,tilcdc,panel"; pinctrl-names = "default"; pinctrl-0 = <&lcd_enable_pins>; enable-gpios = <&gpio0 31 0>; backlight = <&backlight>; status = "okay"; u-boot,dm-pre-reloc; panel-info { ac-bias = <255>; ac-bias-intrpt = <0>; dma-burst-sz = <16>; bpp = <16>; fdd = <0x80>; sync-edge = <0>; sync-ctrl = <1>; raster-order = <0>; fifo-th = <0>; }; display-timings { native-mode = <&timing0>; timing0: 800x480 { hactive = <800>; vactive = <480>; hback-porch = <46>; hfront-porch = <210>; hsync-len = <20>; vback-porch = <23>; vfront-porch = <22>; vsync-len = <10>; clock-frequency = <33000000>; hsync-active = <0>; vsync-active = <0>; }; }; }; Signed-off-by: Dario Binacchi <dariobin@libero.it> Tested-by: Dario Binacchi <dariobin@libero.it>
2020-02-22 13:05:45 +00:00
config AM335X_LCD
bool "Enable AM335x video support"
help
Supports video output to an attached LCD panel.
video_display: Add Xilinx LogiCore DP TX Add a driver for the Xilinx LogiCORE DisplayPort IP core, which is a pure DP transmitter core for Xiling FPGA (no display capabilities). Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-08-09 12:51:23 +00:00
config LOGICORE_DP_TX
bool "Enable Logicore DP TX driver"
depends on DISPLAY
help
Enable the driver for the transmitter part of the Xilinx LogiCORE
DisplayPort, a IP core for Xilinx FPGAs that implements a DisplayPort
video interface as defined by VESA DisplayPort v1.2.
Note that this is a pure transmitter device, and has no display
capabilities by itself.
x86: broadwell: Add video support Add a video driver for Intel's broadwell integrated graphics controller. This uses a binary blob for most init, with the driver just performing a few basic tasks. This driver supports VESA as the mode-setting mechanism. Since most boards don't support driver model yet with VESA, a special case is added to the Kconfig for broadwell. Eventually all boards will use driver model and this can be removed. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:30 +00:00
config VIDEO_BROADWELL_IGD
bool "Enable Intel Broadwell integrated graphics device"
depends on X86
help
x86: video: Fix typo in broadwell Kconfig 'enabled' should be 'enables'. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:14 +00:00
This enables support for integrated graphics on Intel broadwell
x86: broadwell: Add video support Add a video driver for Intel's broadwell integrated graphics controller. This uses a binary blob for most init, with the driver just performing a few basic tasks. This driver supports VESA as the mode-setting mechanism. Since most boards don't support driver model yet with VESA, a special case is added to the Kconfig for broadwell. Eventually all boards will use driver model and this can be removed. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Bin Meng <bmeng.cn@gmail.com>
2016-03-12 05:07:30 +00:00
devices. Initialisation is mostly performed by a VGA boot ROM, with
some setup handled by U-Boot itself. The graphics adaptor works as
a VESA device and supports LCD panels, eDP and LVDS outputs.
Configuration of most aspects of device operation is performed using
a special tool which configures the VGA ROM, but the graphics
resolution can be selected in U-Boot.
dm: x86: video: Add a driver-model driver for ivybridge graphics At present we use the legacy vesa driver for graphics. Add a driver which supports driver model. This can be probed only when needed, removing the need to start up the display if it is not used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:15 +00:00
config VIDEO_IVYBRIDGE_IGD
bool "Enable Intel Ivybridge integration graphics support"
depends on X86
help
This enables support for integrated graphics on Intel ivybridge
devices. Initialisation is mostly performed by a VGA boot ROM, with
some setup handled by U-Boot itself. The graphics adaptor works as
a VESA device and supports LCD panels, eDP and LVDS outputs.
Configuration of most aspects of device operation is performed using
a special tool which configures the VGA ROM, but the graphics
resolution can be selected in U-Boot.
Convert CONFIG_FSL_DCU_FB to Kconfig Rename CONFIG_FSL_DCU_FB to CONFIG_VIDEO_FSL_DCU_FB and convert it to Kconfig. Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Reviewed-by: Stefan Agner <stefan.agner@toradex.com> Reviewed-by: Alison Wang <alison.wang@nxp.com>
2017-04-11 05:42:09 +00:00
config VIDEO_FSL_DCU_FB
bool "Enable Freescale Display Control Unit"
video: fsl_dcu_fb: add DM_VIDEO support Extend the driver to build with DM_VIDEO enabled. DTS files must additionally include 'u-boot,dm-pre-reloc' property in soc and child nodes to enable driver binding to fsl_dcu_fb device. Currently display timings aren't obtained from DT. Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com> Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2019-06-10 11:47:50 +00:00
depends on VIDEO || DM_VIDEO
Convert CONFIG_FSL_DCU_FB to Kconfig Rename CONFIG_FSL_DCU_FB to CONFIG_VIDEO_FSL_DCU_FB and convert it to Kconfig. Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Reviewed-by: Stefan Agner <stefan.agner@toradex.com> Reviewed-by: Alison Wang <alison.wang@nxp.com>
2017-04-11 05:42:09 +00:00
help
This enables support for Freescale Display Control Unit (DCU4)
module found on Freescale Vybrid and QorIQ family of SoCs.
video: fsl_dcu_fb: fix framebuffer to the end of memory Fix the framebuffer location to the very end of the available memory. This allows to remove the area from available memory for the kernel, which in turn allows to display the splash screen through the Linux kernel boot process. Ideas has been taken from the sunxi display driver, e.g. 20779ec3a5 ("sunxi: video: Dynamically reserve framebuffer memory") Signed-off-by: Stefan Agner <stefan.agner@toradex.com> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
2017-04-11 05:42:10 +00:00
config VIDEO_FSL_DCU_MAX_FB_SIZE_MB
int "Freescale DCU framebuffer size"
depends on VIDEO_FSL_DCU_FB
default 4194304
help
Set maximum framebuffer size to be used for Freescale Display
Controller Unit (DCU4).
rockchip: video: Kconfig: Add Kconfig for rockchip video driver 1. add Kconfig for rockchip video driver, so that video port can be selected as needed. 2. move VIDEO_ROCKCHIP option to new Kconfig for concision. Signed-off-by: Eric Gao <eric.gao@rock-chips.com> Acked-by: Simon Glass <sjg@chromium.org> Drop indenting in Kconfig: Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-17 14:24:23 +00:00
source "drivers/video/rockchip/Kconfig"
rockchip: video: Add a display driver for rockchip HDMI Some Rockchip SoCs support HDMI output. Add a display driver for this so that these displays can be used on supported boards. Unfortunately this driver is not fully functional. It cannot reliably read EDID information over HDMI. This seems to be due to the clocks being incorrect - the I2C bus speed appears to be up to 100x slower than the clock settings indicate. The root cause may be in the clock logic. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:45:03 +00:00
video: Add support for Arm's Mali Display Processors Add support for Arm Mali Display Processors DP500, DP550 and DP650. Only one layer is being used to display the console or boot logo, even if more layers are supported in the hardware. Signed-off-by: Liviu Dudau <liviu.dudau@foss.arm.com>
2018-09-28 12:50:53 +00:00
config VIDEO_ARM_MALIDP
bool "Enable Arm Mali Display Processor support"
depends on DM_VIDEO && OF_CONTROL
select VEXPRESS_CLK
help
This enables support for Arm Ltd Mali Display Processors from
the DP500, DP550 and DP650 family.
sandbox: Move CONFIG_VIDEO_SANDBOX_SDL to Kconfig Move this option to Kconfig. This is quite simple as only sandbox uses the driver. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:24 +00:00
config VIDEO_SANDBOX_SDL
bool "Enable sandbox video console using SDL"
depends on SANDBOX
help
When using sandbox you can enable an emulated LCD display which
appears as an SDL (Simple DirectMedia Layer) window. This is a
console device and can display stdout output. Within U-Boot is is
a normal bitmap display and can display images as well as text.
video: add STM32 LTDC display controller The STM32 LTDC display controller provides a parallel digital RGB and signals for horizontal, vertical synchronization, Pixel Clock and Data Enable as output to interface directly to a variety of LCD and TFT panels. The LTDC main features are: - 24-bit RGB Parallel Pixel Output, Programmable timings & polarity for HSync, VSync and Data Enable. - 2 layers with Blending, Color Keying, Window position & size, Dithering, Background color, Color Look-Up Table (CLUT). - Supported layer color formats: ARGB8888, RGB888, RGB565, ARGB1555, ARGB4444, L8 CLUT, AL44 & AL88 This LTDC driver: - supports: RGB parallel output with timings & polarity, 1 layer in RGB565. - supports but with hard-coded configurations: blending, window position & size (crop), background color. - does not support yet: rgb888, argb8888, 8-bit clut, dithering. This LTDC driver is compatible with all stm32 platforms with the LTDC IP and has been tested on stm32 f746-disco board. Signed-off-by: Philippe CORNU <philippe.cornu@st.com>
2017-08-03 10:36:08 +00:00
source "drivers/video/stm32/Kconfig"
tegra: video: Rename CONFIG_VIDEO_TEGRA to CONFIG_VIDEO_TEGRA20 This option refers only to the tegra20 video driver, so name it as such to avoid confusion with tegra124. Also move this option to Kconfig. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-01-30 23:37:51 +00:00
config VIDEO_TEGRA20
bool "Enable LCD support on Tegra20"
tegra: video: Move the check for CONFIG_OF_CONTROL to Kconfig We can check this in Kconfig now. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-01-30 23:37:54 +00:00
depends on OF_CONTROL
tegra: video: Rename CONFIG_VIDEO_TEGRA to CONFIG_VIDEO_TEGRA20 This option refers only to the tegra20 video driver, so name it as such to avoid confusion with tegra124. Also move this option to Kconfig. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-01-30 23:37:51 +00:00
help
Tegra20 supports video output to an attached LCD panel as well as
other options such as HDMI. Only the LCD is supported in U-Boot.
This option enables this support which can be used on devices which
have an LCD display connected.
tegra: video: support eDP displays on Tegra124 devices Connect up the clocks and the eDP driver to make these displays work with Tegra124-based devices. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 03:03:42 +00:00
config VIDEO_TEGRA124
bool "Enable video support on Tegra124"
tegra: nyan-big: Move the LCD driver to driver model Adjust the driver to use driver model. The SOR becomes a bridge device. We use the normal simple_panel driver to handle the display itself. We also need to enable some options such as regulators, PWMs and DM_VIDEO itself. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-01-30 23:37:50 +00:00
depends on DM_VIDEO
tegra: video: support eDP displays on Tegra124 devices Connect up the clocks and the eDP driver to make these displays work with Tegra124-based devices. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 03:03:42 +00:00
help
Tegra124 supports many video output options including eDP and
HDMI. At present only eDP is supported by U-Boot. This option
enables this support which can be used on devices which
have an eDP display connected.
dm: video: Add support for video bridges A video bridge typically converts video from one format to another, e.g. DisplayPort to LVDS. Add driver model support for these with a simple interface to control activation and backlight. The uclass supports GPIO control of power and reset lines. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-03 00:16:08 +00:00
source "drivers/video/bridge/Kconfig"
drivers: hierarchize drivers Kconfig menu The menuconfig for drivers are getting more and more cluttered and unreadable because too many entries are displayed in a single flat menu. Use hierarchic menu for each category. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Update to apply again in a few places, drop USB hunk] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-07-25 17:46:26 +00:00
video: move ipuv3 files to subdirectory Place ipuv3 files and headers in custom driver subdirectory. Signed-off-by: Anatolij Gustschin <agust@denx.de>
2019-03-18 22:29:32 +00:00
source "drivers/video/imx/Kconfig"
video: ipuv3: add DM_VIDEO support Extend the driver to build with DM_VIDEO enabled. DTS files must additionally include 'u-boot,dm-pre-reloc' property in soc and ipu nodes to enable driver binding to ipu device. Signed-off-by: Anatolij Gustschin <agust@denx.de>
2019-03-18 22:29:31 +00:00
video: add nexell video driver (display/video driver) Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01: - nexell_display.c: Changed to DM, CONFIG_FB_ADDR can not be used anymore because framebuffer is allocated by video_reserve() in video-uclass.c. Therefore code changed appropriately. - '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where possible (and similar). - livetree API (dev_read_...) is used instead of fdt one (fdt...). Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
2020-07-10 17:07:36 +00:00
config VIDEO_NX
bool "Enable video support on Nexell SoC"
depends on ARCH_S5P6818 || ARCH_S5P4418
help
Nexell SoC supports many video output options including eDP and
HDMI. This option enables this support which can be used on devices
which have an eDP display connected.
source "drivers/video/nexell/Kconfig"
Convert CONFIG_VIDEO to Kconfig This converts the following to Kconfig: CONFIG_VIDEO Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Jagan Teki <jteki@openedev.com>
2016-10-18 02:12:40 +00:00
config VIDEO
bool "Enable legacy video support"
depends on !DM_VIDEO
help
Define this for video support, without using driver model. Some
drivers use this because they are not yet converted to driver
model. Video drivers typically provide a colour text console and
cursor.
Convert CONFIG_CFB_CONSOLE to Kconfig This converts the following to Kconfig: CONFIG_CFB_CONSOLE Signed-off-by: Simon Glass <sjg@chromium.org>
2016-10-18 02:12:41 +00:00
config CFB_CONSOLE
bool "Enable colour frame buffer console"
depends on VIDEO
default y if VIDEO
help
Enables the colour frame buffer driver. This supports colour
output on a bitmap display from an in-memory frame buffer.
Several colour devices are supported along with various options to
adjust the supported features. The driver is implemented in
cfb_console.c
The following defines are needed (cf. smiLynxEM, i8042)
VIDEO_FB_LITTLE_ENDIAN graphic memory organisation
(default big endian)
VIDEO_HW_RECTFILL graphic chip supports
rectangle fill (cf. smiLynxEM)
VIDEO_HW_BITBLT graphic chip supports
bit-blit (cf. smiLynxEM)
VIDEO_VISIBLE_COLS visible pixel columns (cols=pitch)
VIDEO_VISIBLE_ROWS visible pixel rows
VIDEO_PIXEL_SIZE bytes per pixel
VIDEO_DATA_FORMAT graphic data format
(0-5, cf. cfb_console.c)
VIDEO_FB_ADRS framebuffer address
VIDEO_KBD_INIT_FCT keyboard int fct (i.e. rx51_kp_init())
VIDEO_TSTC_FCT test char fct (i.e. rx51_kp_tstc)
VIDEO_GETC_FCT get char fct (i.e. rx51_kp_getc)
CONFIG_VIDEO_LOGO display Linux logo in upper left corner
CONFIG_VIDEO_BMP_LOGO use bmp_logo.h instead of linux_logo.h
for logo. Requires CONFIG_VIDEO_LOGO
CONFIG_CONSOLE_EXTRA_INFO
additional board info beside
the logo
CONFIG_HIDE_LOGO_VERSION
do not display bootloader
version string
When CONFIG_CFB_CONSOLE is defined, the video console is the
default console. The serial console can be forced by setting the
environment 'console=serial'.
Convert CONFIG_CFB_CONSOLE_ANSI to Kconfig This converts the following to Kconfig: CONFIG_CFB_CONSOLE_ANSI Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-18 02:12:42 +00:00
config CFB_CONSOLE_ANSI
bool "Support ANSI escape sequences"
depends on CFB_CONSOLE
help
This allows the colour buffer frame buffer driver to support
a limited number of ANSI escape sequences (cursor control,
erase functions and limited graphics rendition control). Normal
output from U-Boot will pass through this filter.
Convert CONFIG_VGA_AS_SINGLE_DEVICE to Kconfig This converts the following to Kconfig: CONFIG_VGA_AS_SINGLE_DEVICE Once we migrate to driver model for video, we should be able to drop this option. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-10-18 02:12:49 +00:00
config VGA_AS_SINGLE_DEVICE
bool "Set the video as an output-only device"
depends on CFB_CONSOLE
default y
help
If enable the framebuffer device will be initialized as an
output-only device. The Keyboard driver will not be set up. This
may be used if you have no keyboard device, or more than one
(USB Keyboard, AT Keyboard).
Convert CONFIG_VIDEO_SW_CURSOR to Kconfig This converts the following to Kconfig: CONFIG_VIDEO_SW_CURSOR Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> [trini: Re-convert, find all the cases where this is off] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-10-18 02:12:51 +00:00
config VIDEO_SW_CURSOR
bool "Enable a software cursor"
depends on CFB_CONSOLE
default y if CFB_CONSOLE
help
This draws a cursor after the last character. No blinking is
provided. This makes it possible to see the current cursor
position when entering text on the console. It is recommended to
enable this.
Convert CONFIG_CONSOLE_EXTRA_INFO to Kconfig This converts the following to Kconfig: CONFIG_CONSOLE_EXTRA_INFO Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-18 02:12:53 +00:00
config CONSOLE_EXTRA_INFO
bool "Display additional board information"
depends on CFB_CONSOLE
help
Display additional board information strings that normally go to
the serial port. When this option is enabled, a board-specific
function video_get_info_str() is called to get the string for
each line of the display. The function should return the string,
which can be empty if there is nothing to display for that line.
Convert CONFIG_CONSOLE_SCROLL_LINES to Kconfig This converts the following to Kconfig: CONFIG_CONSOLE_SCROLL_LINES Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-18 02:12:57 +00:00
config CONSOLE_SCROLL_LINES
int "Number of lines to scroll the console by"
depends on CFB_CONSOLE || DM_VIDEO || LCD
default 1
help
When the console need to be scrolled, this is the number of
lines to scroll by. It defaults to 1. Increasing this makes the
console jump but can help speed up operation when scrolling
is slow.
Convert CONFIG_SYS_CONSOLE_BG_COL et al to Kconfig This converts the following to Kconfig: CONFIG_SYS_CONSOLE_BG_COL CONFIG_SYS_CONSOLE_FG_COL Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-18 02:12:44 +00:00
config SYS_CONSOLE_BG_COL
hex "Background colour"
video: Drop the ct69000 driver This is not used in U-Boot. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2017-08-04 04:56:50 +00:00
depends on CFB_CONSOLE
Convert CONFIG_SYS_CONSOLE_BG_COL et al to Kconfig This converts the following to Kconfig: CONFIG_SYS_CONSOLE_BG_COL CONFIG_SYS_CONSOLE_FG_COL Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-18 02:12:44 +00:00
default 0x00
help
Defines the background colour for the console. The value is from
0x00 to 0xff and the meaning depends on the graphics card.
Typically, 0x00 means black and 0xff means white. Do not set
the background and foreground to the same colour or you will see
nothing.
config SYS_CONSOLE_FG_COL
hex "Foreground colour"
video: Drop the ct69000 driver This is not used in U-Boot. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2017-08-04 04:56:50 +00:00
depends on CFB_CONSOLE
Convert CONFIG_SYS_CONSOLE_BG_COL et al to Kconfig This converts the following to Kconfig: CONFIG_SYS_CONSOLE_BG_COL CONFIG_SYS_CONSOLE_FG_COL Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-10-18 02:12:44 +00:00
default 0xa0
help
Defines the foreground colour for the console. The value is from
0x00 to 0xff and the meaning depends on the graphics card.
Typically, 0x00 means black and 0xff means white. Do not set
the background and foreground to the same colour or you will see
nothing.
Convert CONFIG_LCD to Kconfig This converts the following to Kconfig: CONFIG_LCD Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Jagan Teki <jteki@openedev.com>
2016-10-18 02:12:56 +00:00
config LCD
bool "Enable legacy LCD support"
help
Define this to enable LCD support (for output to LCD display).
You will also need to select an LCD driver using an additional
CONFIG option. See the README for details. Drives which have been
converted to driver model will instead used CONFIG_DM_VIDEO.
rockchip: video: introduce VIDEO_DW_HDMI and select for Rockchip HDMI Instead of having drivers/video/rockchip/Kconfig point outside of its hierarchy for dw_hdmi.o, we should use a configuration-option to include the Designware HDMI support. This change introduces a new config option (not to be selected via menuconfig, but to be selected from a dependent video driver's configuration option) that enables dw_hdmi.o and selects it whenever the HDMI support for Rockchip SoCs is selected. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-05-05 19:48:26 +00:00
config VIDEO_DW_HDMI
bool
help
Enables the common driver code for the Designware HDMI TX
block found in SoCs from various vendors.
As this does not provide any functionality by itself (but
rather requires a SoC-specific glue driver to call it), it
can not be enabled from the configuration menu.
dm: Add a dsi host uclass Display Serial Interface (DSI) host can usefully be modelled as their own uclass. DSI defines a serial bus and a communication protocol between the host and the device (panel, bridge). Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
2019-10-07 13:29:05 +00:00
config VIDEO_DSI_HOST_SANDBOX
bool "Enable sandbox for dsi host"
depends on SANDBOX
select VIDEO_MIPI_DSI
help
Enable support for sandbox dsi host device used for testing
purposes.
Display Serial Interface (DSI) defines a serial bus and
a communication protocol between the host and the device
(panel, bridge).
video: add MIPI DSI host controller bridge Add a Synopsys Designware MIPI DSI host bridge driver, based on the Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
2019-10-07 13:29:06 +00:00
config VIDEO_DW_MIPI_DSI
bool
select VIDEO_MIPI_DSI
help
Enables the common driver code for the Synopsis Designware
MIPI DSI block found in SoCs from various vendors.
As this does not provide any functionality by itself (but
rather requires a SoC-specific glue driver to call it), it
can not be enabled from the configuration menu.
video: simplefb Not really qcom specific, but for now qcom/lk is the one firmware that is (afaiu) setting up the appropriate dt node for pre-configured display. Uses the generic simple-framebuffer DT bindings so this should be useful on other platforms. Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-08-03 16:47:00 +00:00
config VIDEO_SIMPLE
bool "Simple display driver for preconfigured display"
help
Enables a simple generic display driver which utilizes the
simple-framebuffer devicetree bindings.
This driver assumes that the display hardware has been initialized
before u-boot starts, and u-boot will simply render to the pre-
allocated frame buffer surface.
video: add an option for video simplefb via DT Add an option to indicate that the video driver should setup a SimpleFB node that passes the video framebuffer initialized by U-Boot to the operating system kernel. Currently only the Allwinner DE driver uses this option, and the definition of this option in the sunxi-common.h config header is converted to an imply of this option from CONFIG_VIDEO_SUNXI. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-10-26 03:14:46 +00:00
config VIDEO_DT_SIMPLEFB
bool "Enable SimpleFB support for passing framebuffer to OS"
help
Enables the code to pass the framebuffer to the kernel as a
simple framebuffer in the device tree.
The video output is initialized by U-Boot, and kept by the
kernel.
drivers: Add OSD uclass Some devices offer a text-based OSD (on-screen display) that can be programmatically controlled (i.e. text displayed on). Add a uclass to support such devices. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-09-27 07:19:29 +00:00
config OSD
bool "Enable OSD support"
depends on DM
default n
help
This supports drivers that provide a OSD (on-screen display), which
is a (usually text-oriented) graphics buffer to show information on
a display.
video_osd: Add ihs_video_out driver Add a driver for IHS OSDs on IHS FPGAs. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-09-27 07:19:30 +00:00
video_osd: Add osd sandbox driver and tests Add sandbox driver and tests for the new OSD uclass. Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-09-27 07:19:31 +00:00
config SANDBOX_OSD
bool "Enable sandbox OSD"
depends on OSD
help
Enable support for sandbox OSD device used for testing purposes.
video_osd: Add ihs_video_out driver Add a driver for IHS OSDs on IHS FPGAs. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
2018-09-27 07:19:30 +00:00
config IHS_VIDEO_OUT
bool "Enable IHS video out driver"
depends on OSD
help
Enable support for the gdsys Integrated Hardware Systems (IHS) video
out On-screen Display (OSD) used on gdsys FPGAs to control dynamic
textual overlays of the display outputs.
Convert CONFIG_SPLASH_SCREEN et al to Kconfig This converts the following to Kconfig: CONFIG_SPLASH_SCREEN CONFIG_SPLASH_SCREEN_ALIGN CONFIG_SPLASHIMAGE_GUARD CONFIG_SPLASH_SOURCE Signed-off-by: Simon Glass <sjg@chromium.org>
2020-08-11 17:23:35 +00:00
config SPLASH_SCREEN
bool "Show a splash-screen image"
help
If this option is set, the environment is checked for a variable
"splashimage". If found, the usual display of logo, copyright and
system information on the LCD is suppressed and the BMP image at the
address specified in "splashimage" is loaded instead. The console is
redirected to the "nulldev", too. This allows for a "silent" boot
where a splash screen is loaded very quickly after power-on.
The splash_screen_prepare() function is a weak function defined in
common/splash.c. It is called as part of the splash screen display
sequence. It gives the board an opportunity to prepare the splash
image data before it is processed and sent to the frame buffer by
U-Boot. Define your own version to use this feature.
config SPLASHIMAGE_GUARD
bool "Support unaligned BMP images"
depends on SPLASH_SCREEN
help
If this option is set, then U-Boot will prevent the environment
variable "splashimage" from being set to a problematic address
(see doc/README.displaying-bmps).
This option is useful for targets where, due to alignment
restrictions, an improperly aligned BMP image will cause a data
abort. If you think you will not have problems with unaligned
accesses (for example because your toolchain prevents them)
there is no need to set this option.
config SPLASH_SCREEN_ALIGN
bool "Allow positioning the splash image anywhere on the display"
depends on SPLASH_SCREEN || CMD_BMP
help
If this option is set the splash image can be freely positioned
on the screen. Environment variable "splashpos" specifies the
position as "x,y". If a positive number is given it is used as
number of pixel from left/top. If a negative number is given it
is used as number of pixel from right/bottom. You can also
specify 'm' for centering the image.
Example:
setenv splashpos m,m
=> image at center of screen
setenv splashpos 30,20
=> image at x = 30 and y = 20
setenv splashpos -10,m
=> vertically centered image
at x = dspWidth - bmpWidth - 9
config SPLASH_SOURCE
bool "Control the source of the splash image"
depends on SPLASH_SCREEN
help
Use the splash_source.c library. This library provides facilities to
declare board specific splash image locations, routines for loading
splash image from supported locations, and a way of controlling the
selected splash location using the "splashsource" environment
variable.
This CONFIG works as follows:
- If splashsource is set to a supported location name as defined by
board code, use that splash location.
- If splashsource is undefined, use the first splash location as
default.
- If splashsource is set to an unsupported value, do not load a splash
screen.
A splash source location can describe either storage with raw data, a
storage formatted with a file system or a FIT image. In case of a
filesystem, the splash screen data is loaded as a file. The name of
the splash screen file can be controlled with the environment variable
"splashfile".
To enable loading the splash image from a FIT image, CONFIG_FIT must
be enabled. The FIT image has to start at the 'offset' field address
in the selected splash location. The name of splash image within the
FIT shall be specified by the environment variable "splashfile".
In case the environment variable "splashfile" is not defined the
default name 'splash.bmp' will be used.
configs: migrate CONFIG_VIDEO_BMP_GZIP to defconfigs Done with: ./tools/moveconfig.py VIDEO_BMP_GZIP The 3 suspicious migration because CMD_BMP and SPLASH_SCREEN are not activated in these defconfigs: - trats_defconfig - s5pc210_universal_defconfig - trats2_defconfig Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-28 09:30:14 +00:00
config VIDEO_BMP_GZIP
bool "Gzip compressed BMP image support"
depends on CMD_BMP || SPLASH_SCREEN
help
If this option is set, additionally to standard BMP
images, gzipped BMP images can be displayed via the
splashscreen support or the bmp command.
configs: migrate CONFIG_VIDEO_BMP_RLE8 to defconfigs Done with: ./tools/moveconfig.py VIDEO_BMP_RLE8 Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-28 09:30:15 +00:00
config VIDEO_BMP_RLE8
bool "Run length encoded BMP image (RLE8) support"
depends on DM_VIDEO || CFB_CONSOLE
help
If this option is set, the 8-bit RLE compressed BMP images
is supported.
drivers: hierarchize drivers Kconfig menu The menuconfig for drivers are getting more and more cluttered and unreadable because too many entries are displayed in a single flat menu. Use hierarchic menu for each category. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Update to apply again in a few places, drop USB hunk] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-07-25 17:46:26 +00:00
endmenu
Reference in a new issue Copy permalink