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

897 lines
30 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"
video: Rename CONFIG_DM_VIDEO to CONFIG_VIDEO Now that all the old code is gone, rename this option. Driver model migration is now complete. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:46:31 +00:00
config VIDEO
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
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: Rename CONFIG_DM_VIDEO to CONFIG_VIDEO Now that all the old code is gone, rename this option. Driver model migration is now complete. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:46:31 +00:00
if VIDEO
video: Make all video options depend on DM_VIDEO Rather than sprinkly this file with 'depends' statements, make all options depend on DM_VIDEO. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:35:17 +00:00
video: Convert CONFIG_VIDEO_LOGO to Kconfig This converts the following to Kconfig: CONFIG_VIDEO_LOGO Note that this option depends on CONFIG_DM_VIDEO now, since cfb_console is deprecated. The only relevant code is now in splash.c Drop the check for DM_VIDEO in that file. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-11-19 20:24:01 +00:00
config VIDEO_LOGO
bool "Show the U-Boot logo on the display"
video: Show the U-Boot logo by default Enable this for boards with a display, unless they are using the SPLASH feature. This shows a U-Boot logo on boards with a display, which seems like a useful thing. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-11-19 20:24:04 +00:00
default y if !SPLASH_SCREEN
video: Support showing the U-Boot logo Show the U-Boot logo by default. This is only 7KB in size so seems like a useful default for boards that enable a display. If SPLASH_SCREEN is enabled, it is not enabled by default, so as not to conflict with that feature. Also disable it for tests, since we don't want to complicate the output. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-11-19 20:24:03 +00:00
select VIDEO_BMP_RLE8
video: Convert CONFIG_VIDEO_LOGO to Kconfig This converts the following to Kconfig: CONFIG_VIDEO_LOGO Note that this option depends on CONFIG_DM_VIDEO now, since cfb_console is deprecated. The only relevant code is now in splash.c Drop the check for DM_VIDEO in that file. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-11-19 20:24:01 +00:00
help
This enables showing the U-Boot logo on the display when a video
device is probed. It appears at the top right. The logo itself is at
tools/logos/u-boot_logo.bmp and looks best when the display has a
black background.
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"
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"
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
Replace video_uc_platdata with video_uc_plat The video_uc_platdata structure no longer exists. It has been renamed video_uc_plat. Signed-off-by: Dario Binacchi <dariobin@libero.it>
2021-01-23 18:43:52 +00:00
struct video_uc_plat. That memory is then reserved for use after
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
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"
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
Replace video_uc_platdata with video_uc_plat The video_uc_platdata structure no longer exists. It has been renamed video_uc_plat. Signed-off-by: Dario Binacchi <dariobin@libero.it>
2021-01-23 18:43:52 +00:00
struct video_uc_plat.
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
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)
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"
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"
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"
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"
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"
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"
video: Make all video options depend on DM_VIDEO Rather than sprinkly this file with 'depends' statements, make all options depend on DM_VIDEO. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:35:17 +00:00
default y
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
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"
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"
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.
video: Refactor to allow more than one font size At present the truetype console supports only a single font and size. It is useful to be able to support different combinations. As a first step, move the metrics into there own structure and allow having multiple metrics. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-06 14:36:11 +00:00
config CONSOLE_TRUETYPE_MAX_METRICS
int "TrueType maximum number of font / size combinations"
depends on CONSOLE_TRUETYPE
default 10 if EXPO
default 1
help
This sets the number of font / size combinations which can be used by
the console. For simple console use a single font is enough. When
boot menus are in use, this may need to be increased.
Note that a separate entry is needed for each font size, even if the
font itself is the same. This is because the entry caches various
font metrics which are expensive to regenerate each time the font
size changes.
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"
default y
help
This provides panel uclass driver that enables basic panel support.
config SIMPLE_PANEL
bool "Enable simple panel support"
video: SIMPLE_PANEL depends on DM_GPIO SIMPLE_PANEL currently only depends on PANEL && BACKLIGHT, but the code makes references to dm_gpio_set_value and gpio_request_by_name. These are defined in drivers/gpio/gpio-uclass.c, so a dependency on DM_GPIO corrects these link errors: aarch64-linux-gnu-ld.bfd: drivers/built-in.o: in function `simple_panel_set_backlight': /home/kameliya/u-boot/drivers/video/simple_panel.c:42: undefined reference to `dm_gpio_set_value' aarch64-linux-gnu-ld.bfd: drivers/built-in.o: in function `simple_panel_enable_backlight': /home/kameliya/u-boot/drivers/video/simple_panel.c:27: undefined reference to `dm_gpio_set_value' aarch64-linux-gnu-ld.bfd: drivers/built-in.o: in function `simple_panel_of_to_plat': /home/kameliya/u-boot/drivers/video/simple_panel.c:72: undefined reference to `gpio_request_by_name' This issue is only exposed if you have a board which enables CONFIG_DM_VIDEO without CONFIG_DM_GPIO; so far, none do, but soon a QEMU board may. Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
2021-03-03 03:46:47 +00:00
depends on PANEL && BACKLIGHT && DM_GPIO
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
default y
help
This turns on a simple panel driver that enables a compatible
video panel.
video: Move and rename DM_HX8238D option This is actually a panel, not a video device. Rename the option, move it into the right place and make it depend on PANEL. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-06 14:36:07 +00:00
config PANEL_HX8238D
bool "Enable Himax HX-8238D LCD driver"
depends on PANEL
help
Support for HX-8238D LCD Panel
The HX8238-D is a single chip controller and driver LSI that
integrates the power circuit.
It can drive a maximum 960x240 dot graphics on a-TFT panel
displays in 16M colors with dithering.
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"
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"
x86: video: Allow coreboot video to be used on any x86 board When booting from coreboot we need this driver for the video to work. Update the driver to be usable on any board. The driver disables itself if it sees that is not booted from coreboot. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-15 05:00:27 +00:00
depends on X86
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
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"
efi: Add video support to the app The current EFI video driver only works when running in the stub. In that case the stub calls boot services (before jumping to U-Boot proper) and copies the graphics info over to the efi table. This is necessary because the stub exits boot services before jumping to U-Boot. The app maintains access to boot services throughout its life, so does not need to do this. Update the driver to support calling boot services directly. Enable video output for the app. Note that this uses the EFI_GRAPHICS_OUTPUT_PROTOCOL protocol, even though it mentions vesa. A sample qemu command-line for this case is: qemu-system-x86_64 -bios /usr/share/edk2.git/ovmf-ia32/OVMF-pure-efi.fd -drive id=disk,file=try.img,if=none,format=raw -nic none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-11-04 03:09:10 +00:00
depends on EFI_STUB || EFI_APP
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
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"
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"
---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.
Convert CONFIG_ATMEL_LCD et al to Kconfig This converts the following to Kconfig: CONFIG_ATMEL_LCD CONFIG_ATMEL_LCD_BGR555 CONFIG_ATMEL_LCD_RGB565 CONFIG_GURNARD_SPLASH Signed-off-by: Tom Rini <trini@konsulko.com>
2022-03-18 12:38:28 +00:00
config ATMEL_LCD
bool "Atmel LCD panel support"
video: Make all video options depend on DM_VIDEO Rather than sprinkly this file with 'depends' statements, make all options depend on DM_VIDEO. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:35:17 +00:00
depends on ARCH_AT91
Convert CONFIG_ATMEL_LCD et al to Kconfig This converts the following to Kconfig: CONFIG_ATMEL_LCD CONFIG_ATMEL_LCD_BGR555 CONFIG_ATMEL_LCD_RGB565 CONFIG_GURNARD_SPLASH Signed-off-by: Tom Rini <trini@konsulko.com>
2022-03-18 12:38:28 +00:00
config ATMEL_LCD_BGR555
bool "Display in BGR555 mode"
help
Use the BGR555 output mode. Otherwise RGB565 is used.
video: Convert CONFIG_VIDEO_BCM2835 to Kconfig This converts the following to Kconfig: CONFIG_VIDEO_BCM2835 This is the final ad-hoc CONFIG_VIDEO_... to convert. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Matthias Brugger <mbrugger@suse.com>
2022-01-23 14:04:14 +00:00
config VIDEO_BCM2835
bool "Display support for BCM2835"
help
The graphics processor already sets up the display so this driver
simply checks the resolution and then sets up the frame buffer with
that same resolution (or as near as possible) and 32bpp depth, so
that U-Boot can access it with full colour depth.
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"
select VIDEO_MIPI_DSI
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"
select VIDEO_MIPI_DSI
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"
---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
sunxi: gpio: Remove name_to_gpio macro This clarifies which callers must be updated to complete the DM_GPIO conversion. The only remaining caller of name_to_gpio in generic code is inside the !DM_GPIO block in cmd/gpio.c. DM_GPIO is always selected on sunxi, so that code cannot be reached. And after this commit, there are only two remaining implementations of name_to_gpio. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-09-11 21:50:48 +00:00
understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port H.
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
video: add TDO tl070wsh30 panel driver This adds support for the TDO TL070WSH30 TFT-LCD panel module. The panel has a 1024×600 resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI interface to the host, a built-in LED backlight and touch controller. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2020-09-29 09:53:53 +00:00
config VIDEO_LCD_TDO_TL070WSH30
bool "TDO TL070WSH30 DSI LCD panel support"
select VIDEO_MIPI_DSI
help
Say Y here if you want to enable support for TDO TL070WSH30
1024x600 DSI video mode panel.
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"
---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
sunxi: gpio: Remove name_to_gpio macro This clarifies which callers must be updated to complete the DM_GPIO conversion. The only remaining caller of name_to_gpio in generic code is inside the !DM_GPIO block in cmd/gpio.c. DM_GPIO is always selected on sunxi, so that code cannot be reached. And after this commit, there are only two remaining implementations of name_to_gpio. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-09-11 21:50:48 +00:00
understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port H.
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_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
sunxi: gpio: Remove name_to_gpio macro This clarifies which callers must be updated to complete the DM_GPIO conversion. The only remaining caller of name_to_gpio in generic code is inside the !DM_GPIO block in cmd/gpio.c. DM_GPIO is always selected on sunxi, so that code cannot be reached. And after this commit, there are only two remaining implementations of name_to_gpio. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-09-11 21:50:48 +00:00
understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port H.
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_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
sunxi: gpio: Remove name_to_gpio macro This clarifies which callers must be updated to complete the DM_GPIO conversion. The only remaining caller of name_to_gpio in generic code is inside the !DM_GPIO block in cmd/gpio.c. DM_GPIO is always selected on sunxi, so that code cannot be reached. And after this commit, there are only two remaining implementations of name_to_gpio. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-09-11 21:50:48 +00:00
understood by 'sunxi_name_to_gpio' function, e.g. PH1 for pin 1 of port H.
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_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
sunxi: gpio: Remove name_to_gpio macro This clarifies which callers must be updated to complete the DM_GPIO conversion. The only remaining caller of name_to_gpio in generic code is inside the !DM_GPIO block in cmd/gpio.c. DM_GPIO is always selected on sunxi, so that code cannot be reached. And after this commit, there are only two remaining implementations of name_to_gpio. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-09-11 21:50:48 +00:00
option takes a string in the format understood by 'sunxi_name_to_gpio'
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
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"
---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"
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
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
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: Migrate exynos display options to Kconfig Following how it's done for the majority of drivers, add a new VIDEO_EXYNOS option and Kconfig file under drivers/video/exynos and list the current options there. Cc: Anatolij Gustschin <agust@denx.de> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Minkyu Kang <mk7.kang@samsung.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
2022-06-11 02:59:34 +00:00
source "drivers/video/exynos/Kconfig"
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.
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"
video: Make all video options depend on DM_VIDEO Rather than sprinkly this file with 'depends' statements, make all options depend on DM_VIDEO. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:35:17 +00:00
depends on OF_CONTROL
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
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"
sandbox: Rework how SDL is enabled / disabled Given that we can use Kconfig logic directly to see if we have a program available on the host or not, change from passing NO_SDL to instead controlling CONFIG_SANDBOX_SDL in Kconfig directly. Introduce CONFIG_HOST_HAS_SDL as the way to test for sdl2-config and default CONFIG_SANDBOX_SDL on if we have that, or not. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-11-19 23:45:43 +00:00
depends on SANDBOX_SDL
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
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"
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: move MXS to Kconfig Move CONFIG_VIDEO_MXS from board headers to Kconfig and drop it from obsolete cfb_console driver. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Fabio Estevam <festevam@gmail.com>
2021-10-04 15:33:12 +00:00
config VIDEO_MXS
bool "Enable video support on i.MX28/i.MX6UL/i.MX7 SoCs"
help
Enable framebuffer driver for i.MX28/i.MX6UL/i.MX7 processors
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.
video: seps525: Add seps525 SPI driver Add support for the WiseChip Semiconductor Inc. (UG-6028GDEBF02) display using the SEPS525 (Syncoam) LCD Controller. Syncoam Seps525 PM-Oled is RGB 160x128 display. This driver has been tested through zynq-spi driver. ZynqMP> load mmc 1 100000 rainbow.bmp 61562 bytes read in 20 ms (2.9 MiB/s) ZynqMP> bmp info 100000 Image size : 160 x 128 Bits per pixel: 24 Compression : 0 ZynqMP> bmp display 100000 ZynqMP> setenv stdout vidconsole Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-03 08:31:35 +00:00
config VIDEO_SEPS525
bool "Enable video support for Seps525"
video: Make all video options depend on DM_VIDEO Rather than sprinkly this file with 'depends' statements, make all options depend on DM_VIDEO. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:35:17 +00:00
depends on DM_GPIO
video: seps525: Add seps525 SPI driver Add support for the WiseChip Semiconductor Inc. (UG-6028GDEBF02) display using the SEPS525 (Syncoam) LCD Controller. Syncoam Seps525 PM-Oled is RGB 160x128 display. This driver has been tested through zynq-spi driver. ZynqMP> load mmc 1 100000 rainbow.bmp 61562 bytes read in 20 ms (2.9 MiB/s) ZynqMP> bmp info 100000 Image size : 160 x 128 Bits per pixel: 24 Compression : 0 ZynqMP> bmp display 100000 ZynqMP> setenv stdout vidconsole Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-03 08:31:35 +00:00
help
Enable support for the Syncoam PM-OLED display driver (RGB 160x128).
Currently driver is supporting only SPI interface.
video: Add skeleton driver for ZynqMP Display port driver The reason for this driver is to use call power management driver to enable it in PMUFW. There is missing functionality now but should be added in near future. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/598cb9515bbabc803f72e287464e3d107cd106a3.1645627920.git.michal.simek@xilinx.com
2022-02-23 14:52:02 +00:00
config VIDEO_ZYNQMP_DPSUB
bool "Enable video support for ZynqMP Display Port"
video: Make all video options depend on DM_VIDEO Rather than sprinkly this file with 'depends' statements, make all options depend on DM_VIDEO. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:35:17 +00:00
depends on ZYNQMP_POWER_DOMAIN
video: Add skeleton driver for ZynqMP Display port driver The reason for this driver is to use call power management driver to enable it in PMUFW. There is missing functionality now but should be added in near future. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/598cb9515bbabc803f72e287464e3d107cd106a3.1645627920.git.michal.simek@xilinx.com
2022-02-23 14:52:02 +00:00
help
Enable support for Xilinx ZynqMP Display Port. Currently this file
is used as placeholder for driver. The main reason is to record
compatible string and calling power domain driver.
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
source "drivers/video/nexell/Kconfig"
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"
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.
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.
video: Add simple driver for ST-Ericsson MCDE with pre-configured display The U-Boot port for ST-Ericsson Ux500 is currently only used on the "stemmy" board, where U-Boot runs after firmware that already sets up a boot splash screen. This means that the display is already on and we can just continue using it for U-Boot. Add a simple driver that simplifies this by reading the display configuration (e.g. screen size, bpp) from the hardware registers. It also checks the configured "source synchronization" - for some displays (usually DSI command mode displays) we need to explicitly trigger a software sync. This is done through the video_sync() callback that triggers the sync and wait for completion. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2021-07-02 17:21:56 +00:00
config VIDEO_MCDE_SIMPLE
bool "Simple driver for ST-Ericsson MCDE with preconfigured display"
help
Enables a simple display driver for ST-Ericsson MCDE
(Multichannel Display Engine), which reads the configuration from
the MCDE registers.
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.
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
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.
video: Split SPLASH_SCREEN_ALIGN from bmp command The bmp command already has a way to centre the image. Using this CONFIG option to also centre it makes it impossible to control where images are placed on the screen. Drop the extra check. Simplify the Kconfig file we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 12:24:16 +00:00
if SPLASH_SCREEN
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_ALIGN
bool "Allow positioning the splash image anywhere on the display"
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
Convert CONFIG_HIDE_LOGO_VERSION to Kconfig This converts the following to Kconfig: CONFIG_HIDE_LOGO_VERSION Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 12:30:56 +00:00
config HIDE_LOGO_VERSION
bool "Hide the version information on the splash screen"
help
Normally the U-Boot version string is shown on the display when the
splash screen is enabled. This information is not otherwise visible
since video starts up after U-Boot has displayed the initial banner.
Enable this option to hide this information.
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_SOURCE
bool "Control the source of the splash image"
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.
video: Split SPLASH_SCREEN_ALIGN from bmp command The bmp command already has a way to centre the image. Using this CONFIG option to also centre it makes it impossible to control where images are placed on the screen. Drop the extra check. Simplify the Kconfig file we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 12:24:16 +00:00
endif # SPLASH_SCREEN
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.
video: Rename CONFIG_SYS_VIDEO_LOGO_MAX_SIZE This option should not have the SYS_ in it. Drop it so it fits in with the other video options. Also simplify the alignment code in gunzip_bmp(), since malloc() always returns a 32-bit-aligned pointer. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 12:46:08 +00:00
config VIDEO_LOGO_MAX_SIZE
Convert CONFIG_VIDEO_LOGO_MAX_SIZE to Kconfig This converts the following to Kconfig: CONFIG_VIDEO_LOGO_MAX_SIZE Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 12:49:18 +00:00
hex "Maximum size of the bitmap logo in bytes"
default 0x100000
help
Sets the maximum uncompressed size of the logo. This is needed when
decompressing a BMP file using the gzip algorithm, since it cannot
read the size from the bitmap header.
video: Rename CONFIG_SYS_VIDEO_LOGO_MAX_SIZE This option should not have the SYS_ in it. Drop it so it fits in with the other video options. Also simplify the alignment code in gunzip_bmp(), since malloc() always returns a 32-bit-aligned pointer. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 12:46:08 +00:00
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"
help
If this option is set, the 8-bit RLE compressed BMP images
is supported.
configs: migrate CONFIG_BMP_16/24/32BPP to defconfigs Done with: ./tools/moveconfig.py BMP_16BPP BMP_24BPP BMP_32BPP Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-28 09:30:16 +00:00
config BMP_16BPP
bool "16-bit-per-pixel BMP image support"
help
Support display of bitmaps file with 16-bit-per-pixel
config BMP_24BPP
bool "24-bit-per-pixel BMP image support"
help
Support display of bitmaps file with 24-bit-per-pixel.
config BMP_32BPP
bool "32-bit-per-pixel BMP image support"
help
Support display of bitmaps file with 32-bit-per-pixel.
video: Rename CONFIG_DM_VIDEO to CONFIG_VIDEO Now that all the old code is gone, rename this option. Driver model migration is now complete. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:46:31 +00:00
endif # VIDEO
video: Make all video options depend on DM_VIDEO Rather than sprinkly this file with 'depends' statements, make all options depend on DM_VIDEO. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-18 13:35:17 +00:00
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