This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
At least on modern machines the write-back mechanism for the frame buffer
is quite slow when scrolling, since it must read the entire frame buffer
and write it back.
Enable the VIDEO_COPY feature to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These appear prominently in the main menu at present. Move them to the
video Kconfig where they belong.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This relates to graphics which is only active when CONFIG_VIDEO is
enabled. Move it into that directory.
For most boards there is no harm in compiling it always, since it if not
used it will be dropped by the linker. But for the EFI app this is not
the case, so retain use of the BMP Kconfig.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The documentation for struct phy state that "The content of the
structure is managed solely by the PHY API and PHY drivers".
Change to use the generic_phy_valid() helper to check if phy is valid.
Fixes: b7d8d40346 ("video: rockchip: dw_mipi_dsi: Fix external phy existence check")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
When the fkms dtb overlay is used only the simple-framebuffer is
presented as a usable video display. So, add "simple-framebuffer"
compatible to enable video driver bcm2835.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Meng Li <Meng.Li@windriver.com>
At present vidconsole_measure() tests ops->select_font before calling
ops->measure, which would result in a null dereference when the console
driver provides no ops for measure.
Fixes: b828ed7d79 ("console: Allow measuring the bounding box of text")
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
533ad9dc avoided an overflow but causes compilation
failure on 32bit boards (eg. veyron speedy)
this commit uses div_u64 which has a fallback codepath
for 32bit platforms
Signed-off-by: Alvaro Fernando García <alvarofernandogarcia@gmail.com>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook_jerry
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
At present this feature is enabled in SPL if a bloblist is available.
Some platforms may not want to use this, so add an option to allow the
feature to be disabled.
Note that the feature unfortunately only fills in part of the
video-handoff information, so causes failures on x86 platforms. For now,
disable it there.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com> # qemu-x86_64
It is not a parse error to have a default value of "0" for a "hex" type
entry, instead of "0x0". However, "0" and "0x0" are not treated the
same even by the tools themselves. Correct this by changing the default
value from "0" to "0x0" for all hex type questions that had the
incorrect default. Fix one instance (in two configs) of a default of "0"
being used on a hex question to be "0x0". Remove the cases where a
defconfig had set a value of "0x0" to be used as the default had been
"0".
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Add a little more info to 'cbsysinfo' command
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUEWE0gAMrH0ckwrwqSElQ6ZwxhQFAmTIbdEACgkQqSElQ6Zw
xhSTCg//TESlLII0mIDIP/Ahoac0qBcALRLPiZNzIG8cUtETsLblwQ4ndCyRNohI
EbRAWdZasVB0mn1wpLX58FjeCpz7u73pS+RIdY4YnkGWCebGO1E04fRPWk1euT6N
PsJSfQ4WUXbPOsP89AVDmYQ7KgbdgW7CcN4iRp931h5+Xy2OMjMNlHrBE/iXToaL
wsGU+WM+KPjqt/Z79goyWSm997wXyLzM844f14/Cv+GnZUsaLKDMdW4S7eyM7OSk
tqkTyq/L5Yf15G3gzVBZzXk5PgcfoXugOelfr5m+yQLUIXJIR5c+yptqwKuQ4MM/
PEuL7+3ytodpG1lEVtqAxg08/AQYGr6CpTMXPOZXbsaaQYQcVG/V28eMchgQF/YD
3lE0ZKSv/t6Ar6iRwKsZE5f+8DslnGip5W41mEBEIgSYyt7yXO0p+cQxkPcArK1E
qyQIESmiPF3GaWarAtNWyoASVFLtIXiUaSne2lnvKP4vNlM36/rB72Ii6OX7sSZZ
Xm4yEBeDpNqMQ99QjQurSFOzwQY+BULlNL36h4mWZALKNONWhXL0N/0JcWFJBl+t
ha84lQwr+u/7J+ZSjNNNH4bXJOYyuZBFDl27btSgHN046iJioobf8jgbbx2WxQ5P
khbcYliKf678Xi/HCQD3CyYmyCYw5VHlUTyQlbgCeC6GQumZwnY=
=s8Ab
-----END PGP SIGNATURE-----
Merge tag 'x86-pull-20230801' of https://source.denx.de/u-boot/custodians/u-boot-x86
- MTRR fixes for x86 boards
- Add a little more info to 'cbsysinfo' command
Perform removal of DSS if kconfigs VIDEO_REMOVE or SPL_VIDEO_REMOVE is
set by user. Otherwise if above Kconfigs are not selected, it is assumed
that user wants splash screen to be displayed until linux kernel boots
up. In such scenario, leave the power domain of DSS as "on" so that
splash screen stays intact until kernel boots up.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Change remove method of DSS video driver to disable video port instead
of performing a soft reset, as soft reset takes longer duration. Video
port is disabled by setting enable bit of video port to 0.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
At present the uclass stored frame buffer size is set to a hard
coded value, but we can calculate the correct value based on what
is configured.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # qemu-x86_64
Set up a default frame buffer size of 8MiB for Bochs for non-x86
architecturs as PCI is normally not enumerated before relocation
on these architectures.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
PCI is always selected by X86 architecture hence "X86 && PCI" does
not make it better.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # qemu-x86_64
There is an example in the VIDEO_PCI_DEFAULT_FB_SIZE help text to
tell people how to calculate its value but the resolution given
does not match the value. Fix it.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that the driver is legacy free, remove the x86 dependency so
that it can be used on non-x86 architectures.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # qemu-x86_64
At present the driver uses IO instructions to access the legacy
VGA IO ports, which unfortunately limits the driver to work only
on x86. It turns out the IO instruction is not necessary as Bochs
VGA card remaps the legacy VGA IO ports (0x3c0 -> 0x3df) to its
memory mapped register space from offset 0x400.
Update the driver to use MMIO access for VGA IO port.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # qemu-x86_64
bochs_vga_write() takes 'index' as one argument, but never uses it.
While we are here, use macros instead of magic numbers for the
VGA IO port register name and value.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # qemu-x86_64
The driver does not call any MTRR APIs.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # qemu-x86_64
Some coding convention fixes for video_post_bind().
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # qemu-x86_64
At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:
- mtrr_commit() will re-initialize all MTRR registers from index 0,
using the settings previously added by mtrr_add_request() and saved
in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
has full control with MTRR programming (e.g.: U-Boot without any blob
that does all low-level initialization on its own, or using FSP2 which
does not touch MTRR), but this is not the case with FSP. FSP programs
some MTRRs during its execution but U-Boot does not have the settings
saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
corrupt what was already programmed previously.
Correct this to use mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:
- mtrr_commit() will re-initialize all MTRR registers from index 0,
using the settings previously added by mtrr_add_request() and saved
in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
has full control with MTRR programming (e.g.: U-Boot without any blob
that does all low-level initialization on its own, or using FSP2 which
does not touch MTRR), but this is not the case with FSP. FSP programs
some MTRRs during its execution but U-Boot does not have the settings
saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
corrupt what was already programmed previously.
Correct this to use mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:
- mtrr_commit() will re-initialize all MTRR registers from index 0,
using the settings previously added by mtrr_add_request() and saved
in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
has full control with MTRR programming (e.g.: U-Boot without any blob
that does all low-level initialization on its own, or using FSP2 which
does not touch MTRR), but this is not the case with FSP. FSP programs
some MTRRs during its execution but U-Boot does not have the settings
saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
corrupt what was already programmed previously.
Correct this to use mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This just needs some extra clocks enabled, and different registers
configured. Copied from Linux, just like the original submitter
of this driver did for rk3568.
Tested on Pinephone Pro.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@vrull.eu>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This is required since user may want to either call the remove method
of video driver and reset the display or not call the remove method
to continue displaying until next stage.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
U-boot proper can use frame buffer address passed from SPL to reserve
the memory area used by framebuffer set in SPL so that splash image
set in SPL continues to get displayed while u-boot proper is running.
Put the framebuffer address and size in a bloblist to make them
available at u-boot proper, if in u-boot proper CONFIG_VIDEO is defined.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add method to reserve video framebuffer information using blob,
received from previous stage.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Bochs is convenient with QEMU on x86 since it does not require a video
BIOS. Add a driver for it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This was brought in in 2016 and a number of changes have been made since
then. There does not seem to be much change in functionality, but it is
a good idea to update from time to time.
Bring in the latest version:
5736b15 ("re-add perlin noise again")
Add a few necessary functions, with dummies in some cases. Update the tests
as there are subtle changes in rendering, perhaps not for the better.
Signed-off-by: Simon Glass <sjg@chromium.org>
For laying out text accurately it is necessary to know the width and
height of the text. Add a measure() method to the console API, so this
can be supported.
Add an implementation for truetype and a base implementation for the
normal console.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is sometimes necessary to highlight some text in a different colour.
Add an easy way to do this and then restore the original console colours.
Signed-off-by: Simon Glass <sjg@chromium.org>
The putc_xy() method is supposed to return the amount of space used. The
existing implementation erroneously adds the previous sub-pixel position
to the returned value. This spaces out the characters very slightly more
than it should. It is seldom noticeable but it does make accurate
measurement of the text impossible.
Fix this minor but long-standing bug.
Fixes: a29b012037 ("video: Add a console driver that uses TrueType fonts")
Signed-off-by: Simon Glass <sjg@chromium.org>
This is useful when the background colour must be written before text
is updated, to avoid strange display artifacts.
Add a function for this, using the existing code from the truetype
console.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use proper register base and access method to access GRF registers.
GRF registers start at a completely different base, and need special
access method, that sets the change mask in the 16 MSBs.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
If phy is not defined in DT (eg. on rk3399), generic_phy_get_by_name
will return -ENODATA. Handle that case correctly.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
pllref_clk is unused after being retrieved. fin needs to be set
to dsi->ref clock's rate for the following calculation to work.
Otherwise fin is undefined, and calculation return bogus number
based on undefined variable.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
&priv->phy is always true. Compiler warns about this loudly.
Use a propper check for phy device allocation. Without this fix
using this driver with SoC that doesn't use external phy (eg. RK3399)
doesn't work.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
These must be read from timings->flags, like other DSI HOST drivers do.
And they must not be inverted either. Low means low.
Without this fix, panel drivers that set *SYNC_LOW produce corrupted
output on screen (shifted horizontally and vertically by back porch
distance).
Signed-off-by: Ondrej Jirman <megi@xff.cz>
