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

351 lines
11 KiB
Text
Raw Normal View History

drivers: hierarchize drivers Kconfig menu The menuconfig for drivers are getting more and more cluttered and unreadable because too many entries are displayed in a single flat menu. Use hierarchic menu for each category. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Update to apply again in a few places, drop USB hunk] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-07-25 17:46:26 +00:00
#
# Video configuration
#
menu "Graphics support"
dm: video: Add a video uclass U-Boot has separate code for LCDs and 'video' devices. Both now use a very similar API thanks to earlier work by Nikita Kiryanov. With the driver- model conversion we should unify these into a single uclass. Unfortunately there are different features supported by each. This implementation provides for a common set of features which should serve most purposes. The intent is to support: - bitmap devices with 8, 16 and 32 bits per pixel - text console wih white on black or vice versa - rotated text console - bitmap display (BMP format) More can be added as additional boards are ported over to use driver model for video. The name 'video' is chosen for the uclass since it is more generic than LCD. Another option would be 'display' but that would introduce a third concept to U-Boot which seems like the wrong approach. The existing LCD and video init functions are not needed now, so this uclass makes no attempt to implement them. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:15 +00:00
config DM_VIDEO
bool "Enable driver model support for LCD/video"
depends on DM
help
This enables driver model for LCD and video devices. These support
a bitmap display of various sizes and depths which can be drawn on
to display a command-line console or splash screen. Enabling this
option compiles in the video uclass and routes all LCD/video access
through this.
config VIDEO_BPP8
bool "Support 8-bit-per-pixel displays"
depends on DM_VIDEO
default y if DM_VIDEO
help
Support drawing text and bitmaps onto a 8-bit-per-pixel display.
Enabling this will include code to support this display. Without
this option, such displays will not be supported and console output
will be empty.
config VIDEO_BPP16
bool "Support 16-bit-per-pixel displays"
depends on DM_VIDEO
default y if DM_VIDEO
help
Support drawing text and bitmaps onto a 16-bit-per-pixel display.
Enabling this will include code to support this display. Without
this option, such displays will not be supported and console output
will be empty.
config VIDEO_BPP32
bool "Support 32-bit-per-pixel displays"
depends on DM_VIDEO
default y if DM_VIDEO
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 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
config VIDEO_ROTATION
bool "Support rotated displays"
depends on DM_VIDEO
help
Sometimes, for example if the display is mounted in portrait
mode or even if it's mounted landscape but rotated by 180degree,
we need to rotate our content of the display relative to the
framebuffer, so that user can read the messages which are
printed out. Enable this option to include a text driver which can
support this. The rotation is set by the 'rot' parameter in
struct video_priv: 0=unrotated, 1=90 degrees clockwise, 2=180
degrees, 3=270 degrees.
x86: Add a VESA video driver Add a driver intended to cope with any VESA-compatible x86 graphics adapter. It will not support ROMs which use OpenFirmware (Forth) since there is no support for that in U-Boot. This means that MAC OS cards will not work. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-12-30 02:32:28 +00:00
config VIDEO_VESA
bool "Enable VESA video driver support"
default n
help
Turn on this option to enable a very simple driver which uses vesa
to discover the video mode and then provides a frame buffer for use
by U-Boot. This can in principle be used with any platform that
supports PCI and video cards that support VESA BIOS Extension (VBE).
x86: Move FRAMEBUFFER_SET_VESA_MODE etc to video Kconfig CONFIG_FRAMEBUFFER_SET_VESA_MODE and CONFIG_FRAMEBUFFER_VESA_MODE are not x86-specific, so move them to drivers/video/Kconfig and make them depend on VIDEO_VESA driver. Some cosmetic fixes are applied to the Kconfig help text as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-05-10 23:36:29 +00:00
config FRAMEBUFFER_SET_VESA_MODE
bool "Set framebuffer graphics resolution"
depends on VIDEO_VESA
help
Set VESA/native framebuffer mode (needed for bootsplash and graphical
framebuffer console)
choice
prompt "framebuffer graphics resolution"
default FRAMEBUFFER_VESA_MODE_117
depends on FRAMEBUFFER_SET_VESA_MODE
help
This option sets the resolution used for the U-Boot framebuffer (and
bootsplash screen).
config FRAMEBUFFER_VESA_MODE_100
bool "640x400 256-color"
config FRAMEBUFFER_VESA_MODE_101
bool "640x480 256-color"
config FRAMEBUFFER_VESA_MODE_102
bool "800x600 16-color"
config FRAMEBUFFER_VESA_MODE_103
bool "800x600 256-color"
config FRAMEBUFFER_VESA_MODE_104
bool "1024x768 16-color"
config FRAMEBUFFER_VESA_MODE_105
video: vesa: Correct a typo in the Kconfig VESA mode string There is one typo in the VESA mode 105h string. Correct it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-08-10 06:26:59 +00:00
bool "1024x768 256-color"
x86: Move FRAMEBUFFER_SET_VESA_MODE etc to video Kconfig CONFIG_FRAMEBUFFER_SET_VESA_MODE and CONFIG_FRAMEBUFFER_VESA_MODE are not x86-specific, so move them to drivers/video/Kconfig and make them depend on VIDEO_VESA driver. Some cosmetic fixes are applied to the Kconfig help text as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-05-10 23:36:29 +00:00
config FRAMEBUFFER_VESA_MODE_106
bool "1280x1024 16-color"
config FRAMEBUFFER_VESA_MODE_107
bool "1280x1024 256-color"
config FRAMEBUFFER_VESA_MODE_108
bool "80x60 text"
config FRAMEBUFFER_VESA_MODE_109
bool "132x25 text"
config FRAMEBUFFER_VESA_MODE_10A
bool "132x43 text"
config FRAMEBUFFER_VESA_MODE_10B
bool "132x50 text"
config FRAMEBUFFER_VESA_MODE_10C
bool "132x60 text"
config FRAMEBUFFER_VESA_MODE_10D
bool "320x200 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_10E
bool "320x200 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_10F
bool "320x200 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_110
bool "640x480 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_111
bool "640x480 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_112
bool "640x480 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_113
bool "800x600 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_114
bool "800x600 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_115
bool "800x600 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_116
bool "1024x768 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_117
bool "1024x768 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_118
bool "1024x768 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_119
bool "1280x1024 32k-color (1:5:5:5)"
config FRAMEBUFFER_VESA_MODE_11A
bool "1280x1024 64k-color (5:6:5)"
config FRAMEBUFFER_VESA_MODE_11B
bool "1280x1024 16.8M-color (8:8:8)"
config FRAMEBUFFER_VESA_MODE_USER
bool "Manually select VESA mode"
endchoice
# Map the config names to an integer (KB).
config FRAMEBUFFER_VESA_MODE
prompt "VESA mode" if FRAMEBUFFER_VESA_MODE_USER
hex
default 0x100 if FRAMEBUFFER_VESA_MODE_100
default 0x101 if FRAMEBUFFER_VESA_MODE_101
default 0x102 if FRAMEBUFFER_VESA_MODE_102
default 0x103 if FRAMEBUFFER_VESA_MODE_103
default 0x104 if FRAMEBUFFER_VESA_MODE_104
default 0x105 if FRAMEBUFFER_VESA_MODE_105
default 0x106 if FRAMEBUFFER_VESA_MODE_106
default 0x107 if FRAMEBUFFER_VESA_MODE_107
default 0x108 if FRAMEBUFFER_VESA_MODE_108
default 0x109 if FRAMEBUFFER_VESA_MODE_109
default 0x10A if FRAMEBUFFER_VESA_MODE_10A
default 0x10B if FRAMEBUFFER_VESA_MODE_10B
default 0x10C if FRAMEBUFFER_VESA_MODE_10C
default 0x10D if FRAMEBUFFER_VESA_MODE_10D
default 0x10E if FRAMEBUFFER_VESA_MODE_10E
default 0x10F if FRAMEBUFFER_VESA_MODE_10F
default 0x110 if FRAMEBUFFER_VESA_MODE_110
default 0x111 if FRAMEBUFFER_VESA_MODE_111
default 0x112 if FRAMEBUFFER_VESA_MODE_112
default 0x113 if FRAMEBUFFER_VESA_MODE_113
default 0x114 if FRAMEBUFFER_VESA_MODE_114
default 0x115 if FRAMEBUFFER_VESA_MODE_115
default 0x116 if FRAMEBUFFER_VESA_MODE_116
default 0x117 if FRAMEBUFFER_VESA_MODE_117
default 0x118 if FRAMEBUFFER_VESA_MODE_118
default 0x119 if FRAMEBUFFER_VESA_MODE_119
default 0x11A if FRAMEBUFFER_VESA_MODE_11A
default 0x11B if FRAMEBUFFER_VESA_MODE_11B
default 0x117 if FRAMEBUFFER_VESA_MODE_USER
video: Add support for the ANX9804 parallel lcd to dp bridge chip Add support for the ANX9804 bridge chip, which can take pixel data coming from a parallel LCD interface and translate it on the fly into a DP interface for driving eDP TFT displays. It uses I2C for configuration. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-08-08 14:03:29 +00:00
config VIDEO_LCD_ANX9804
bool "ANX9804 bridge chip"
default n
---help---
Support for the ANX9804 bridge chip, which can take pixel data coming
from a parallel LCD interface and translate it on the fy into a DP
interface for driving eDP TFT displays. It uses I2C for configuration.
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
config VIDEO_LCD_SSD2828
bool "SSD2828 bridge chip"
default n
---help---
Support for the SSD2828 bridge chip, which can take pixel data coming
from a parallel LCD interface and translate it on the fly into MIPI DSI
interface for driving a MIPI compatible LCD panel. It uses SPI for
configuration.
config VIDEO_LCD_SSD2828_TX_CLK
int "SSD2828 TX_CLK frequency (in MHz)"
depends on VIDEO_LCD_SSD2828
video: ssd2828: Allow using 'pclk' as the PLL clock source Instead of using the internal 'tx_clk' clock source, it is also possible to use the pixel clock signal from the parallel LCD interface ('pclk') as the reference clock for PLL. The 'tx_clk' clock speed may be different on different boards/devices (the allowed range is 8MHz - 30MHz). Which is not very convenient, especially considering the need to know the exact 'tx_clk' clock speed. This clock speed may be difficult to identify without having device schematics and/or accurate documentation/sources every time. Using 'pclk' is free from all these problems. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:35 +00:00
default 0
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
---help---
The frequency of the crystal, which is clocking SSD2828. It may be
anything in the 8MHz-30MHz range and the exact value should be
retrieved from the board schematics. Or in the case of Allwinner
hardware, it can be usually found as 'lcd_xtal_freq' variable in
video: ssd2828: Allow using 'pclk' as the PLL clock source Instead of using the internal 'tx_clk' clock source, it is also possible to use the pixel clock signal from the parallel LCD interface ('pclk') as the reference clock for PLL. The 'tx_clk' clock speed may be different on different boards/devices (the allowed range is 8MHz - 30MHz). Which is not very convenient, especially considering the need to know the exact 'tx_clk' clock speed. This clock speed may be difficult to identify without having device schematics and/or accurate documentation/sources every time. Using 'pclk' is free from all these problems. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:35 +00:00
FEX files. It can be also set to 0 for selecting PCLK from the
parallel LCD interface instead of TX_CLK as the PLL clock source.
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
config VIDEO_LCD_SSD2828_RESET
string "RESET pin of SSD2828"
depends on VIDEO_LCD_SSD2828
default ""
---help---
The reset pin of SSD2828 chip. This takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
video: Add support for Hitachi tx18d42vm LVDS LCD panels Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-01-20 08:22:26 +00:00
config VIDEO_LCD_HITACHI_TX18D42VM
bool "Hitachi tx18d42vm LVDS LCD panel support"
depends on VIDEO
default n
---help---
Support for Hitachi tx18d42vm LVDS LCD panels, these panels have a
lcd controller which needs to be initialized over SPI, once that is
done they work like a regular LVDS panel.
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
config VIDEO_LCD_SPI_CS
string "SPI CS pin for LCD related config job"
video: Add support for Hitachi tx18d42vm LVDS LCD panels Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-01-20 08:22:26 +00:00
depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
default ""
---help---
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
config VIDEO_LCD_SPI_SCLK
string "SPI SCLK pin for LCD related config job"
video: Add support for Hitachi tx18d42vm LVDS LCD panels Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-01-20 08:22:26 +00:00
depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
default ""
---help---
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
config VIDEO_LCD_SPI_MOSI
string "SPI MOSI pin for LCD related config job"
video: Add support for Hitachi tx18d42vm LVDS LCD panels Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2015-01-20 08:22:26 +00:00
depends on VIDEO_LCD_SSD2828 || VIDEO_LCD_HITACHI_TX18D42VM
video: Add support for SSD2828 (parallel LCD to MIPI bridge) SSD2828 can take pixel data coming from a parallel LCD interface and translate it on the fly into MIPI DSI interface for driving a MIPI compatible TFT display. SSD2828 is configured over SPI interface, which may or may not have MISO pin wired up on some hardware. So a write-only SPI mode also has to be supported. The SSD2828 support code is implemented as a utility function and needs to be called from real display drivers, which are responsible for driving parallel LCD hardware in front of the video pipeline. The usage instructions are provided as comments in the header file. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Anatolij Gustschin <agust@denx.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-19 03:23:32 +00:00
default ""
---help---
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. The option takes a string in the format
understood by 'name_to_gpio' function, e.g. PH1 for pin 1 of port H.
config VIDEO_LCD_SPI_MISO
string "SPI MISO pin for LCD related config job (optional)"
depends on VIDEO_LCD_SSD2828
default ""
---help---
This is one of the SPI communication pins, involved in setting up a
working LCD configuration. The exact role of SPI may differ for
different hardware setups. If wired up, this pin may provide additional
useful functionality. Such as bi-directional communication with the
hardware and LCD panel id retrieval (if the panel can report it). The
option takes a string in the format understood by 'name_to_gpio'
function, e.g. PH1 for pin 1 of port H.
dm: video: Add a uclass for display port eDP (Embedded DisplayPort) is a standard widely used in laptops to drive LCD panels. Add a uclass for this which supports a few simple operations. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 03:03:38 +00:00
video: Add support for Armada XP LCD controller This patch adds basic support for the LCD controller of the Marvell Armada XP SoC. An AXP based custom board port will be added later, to use this driver to display a splash screen via the bmp command later. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Anatolij Gustschin <agust@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr> [agust: rebased] Signed-off-by: Anatolij Gustschin <agust@denx.de>
2016-01-20 07:13:28 +00:00
config VIDEO_MVEBU
bool "Armada XP LCD controller"
default n
---help---
Support for the LCD controller integrated in the Marvell
Armada XP SoC.
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"
depends on DM_I2C
default n
help
This enables library for accessing EDID data from an LCD panel.
dm: video: Repurpose the 'displayport' uclass to 'display' The current DisplayPort uclass is too specific. The operations it provides are shared with other types of output devices, such as HDMI and LVDS LCD displays. Generalise the uclass so that it can be used with these devices as well. Adjust the uclass to handle the EDID reading and conversion to display_timing internally. Also update nyan-big which is affected by this. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:45:00 +00:00
config DISPLAY
bool "Enable Display support"
depends on DM
video: add CONFIG_I2C_EDID and disable CONFIG_DISPLAY by default Enabling CONFIG_DISPLAY breaks building for some architectures (microblaze-generic), so we disable CONFIG_DISPLAY in Kconfig by default and enable this option in defconfigs. CONFIG_DISPLAY depends on CONFIG_I2C_EDID, so add and enable it in defconfigs, too. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reported-by: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Anatolij Gustschin <agust@denx.de>
2016-01-25 16:17:22 +00:00
default n
select I2C_EDID
dm: video: Add a uclass for display port eDP (Embedded DisplayPort) is a standard widely used in laptops to drive LCD panels. Add a uclass for this which supports a few simple operations. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 03:03:38 +00:00
help
dm: video: Repurpose the 'displayport' uclass to 'display' The current DisplayPort uclass is too specific. The operations it provides are shared with other types of output devices, such as HDMI and LVDS LCD displays. Generalise the uclass so that it can be used with these devices as well. Adjust the uclass to handle the EDID reading and conversion to display_timing internally. Also update nyan-big which is affected by this. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-01-22 02:45:00 +00:00
This supports drivers that provide a display, such as eDP (Embedded
DisplayPort) and HDMI (High Definition Multimedia Interface).
The devices provide a simple interface to start up the display,
read display information and enable it.
tegra: video: support eDP displays on Tegra124 devices Connect up the clocks and the eDP driver to make these displays work with Tegra124-based devices. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Tom Warren <twarren@nvidia.com>
2015-04-15 03:03:42 +00:00
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
config VIDEO_ROCKCHIP
bool "Enable Rockchip video support"
depends on DM_VIDEO
help
Rockchip SoCs provide video output capabilities for High-Definition
Multimedia Interface (HDMI), Low-voltage Differential Signalling
(LVDS), embedded DisplayPort (eDP) and Display Serial Interface
(DSI). This driver supports the on-chip video output device, and
targets the Rockchip RK3288.
sandbox: Move CONFIG_VIDEO_SANDBOX_SDL to Kconfig Move this option to Kconfig. This is quite simple as only sandbox uses the driver. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-01-19 02:52:24 +00:00
config VIDEO_SANDBOX_SDL
bool "Enable sandbox video console using SDL"
depends on SANDBOX
help
When using sandbox you can enable an emulated LCD display which
appears as an SDL (Simple DirectMedia Layer) window. This is a
console device and can display stdout output. Within U-Boot is is
a normal bitmap display and can display images as well as text.
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
endmenu
Reference in a new issue Copy permalink