drivers: video: Fix CMA Memory Mapping Stalling in Kernel Init

Fail log in Kernel Init:
Starting kernel ...

[ 0.866142] Booting Linux on physical CPU 0xf00
[ 0.866162] Linux version 6.1.99 (z

drivers: video: Fix CMA Memory Mapping Stalling in Kernel Init

Fail log in Kernel Init:
Starting kernel ...

[ 0.866142] Booting Linux on physical CPU 0xf00
[ 0.866162] Linux version 6.1.99 (zjh@ubuntu-191) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621, GNU ld (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 2.36.1.20210621) #76 SMP PREEMPT Fri Feb 21 17:52:06 CST 2025
[ 0.866173] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=50c5387d
[ 0.866183] CPU: div instructions available: patching division code
[ 0.866188] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.866500] OF: fdt: Machine model: Rockchip RK3506G(QFN128) EVB1 V10 Board
[ 0.868656] earlycon: uart8250 at MMIO32 0xff0a0000 (options '')
[ 0.874664] printk: bootconsole [uart8250] enabled
[ 0.875183] Memory policy: Data cache writealloc
[ 0.875888] Reserved memory: created CMA memory pool at 0x05100000, size 32 MiB
[ 0.876563] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.877380] Reserved memory: created DMA memory pool at 0x03d00000, size 1 MiB
[ 0.878045] OF: reserved mem: initialized node rpmsg-dma@3d00000, compatible id shared-dma-pool

Why have this problem?
1. The ARMv7 kernel encountered a deadlock during initialization when creating CMA mappings.
U-Boot reserved DRM logo region starting at 0x7100000, leaving insufficient space above
0x7100000 for a 22MB CMA allocation. So CMA will attempt to allocate downward from
0x5d00000 to 0x7100000.
2. Since PGTABLE_LEVELS=2 by default, kernel will create mapping every 2M, and will adjust
the second region start address to 2M alignment, apparently the first region in this case
is 0x5d00000-0x5e00000.
3. However, kernel can't adjust the last region less than 2M, and it will only wait for the
start and the end to be equal. So the CMA Memory Mapping Stalling happened.

Change-Id: Ib196df8c8ce1f1a19cd6943d2e6cb1c9910752ba
Signed-off-by: Xuhui Lin <xuhui.lin@rock-chips.com>

show more ...

video/drm: vop2: add suppor cubic lut

Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: I5a02c737ba175f4ae65be22d81a0dfa7dd3f85d7

dm: video: add reserve size debug info for rockchip video

Change-Id: I0d2693ea871ea41c84143e0f4e4c52c65b308dd7
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>

rockchip: video: fix compile warning

Change-Id: I05dbb0cdc33f71f66feedad2033d702177b31ede
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: video: reserve memory for fb without bind video driver

The video DM need to bind video driver before relocate in order to
get the size need by video driver, which is fixed in rockchip plat

rockchip: video: reserve memory for fb without bind video driver

The video DM need to bind video driver before relocate in order to
get the size need by video driver, which is fixed in rockchip platform,
we can get it without bind the driver.

With this patch, we don't need to enable the video/display nodes
in pre-reloc, and we can get all these nodes from kernel dtb.

Change-Id: I02d86b69e8c10bbf47e6b421c41b6dae20667a33
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

Signed-off-by: Stefano Babic <sbabic@denx.de>

Merge git://git.denx.de/u-boot-rockchip

video: Use cache-alignment in video_sync()

Sometimes the frame buffer is not a multiple of the cache line size.
Adjust the cache-flushing code to avoid cache warnings/errors in this
case.

Signed-of

video: Use cache-alignment in video_sync()

Sometimes the frame buffer is not a multiple of the cache line size.
Adjust the cache-flushing code to avoid cache warnings/errors in this
case.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-x86

dm: video: Don't do anything in alloc_fb() when plat->size is zero

With DM VESA driver on x86 boards, plat->base/size/align are all
zeroes and starting address passed to alloc_fb() happens to be 1MB

dm: video: Don't do anything in alloc_fb() when plat->size is zero

With DM VESA driver on x86 boards, plat->base/size/align are all
zeroes and starting address passed to alloc_fb() happens to be 1MB
aligned, so this routine does not trigger any issue. On QEMU with
U-Boot as coreboot payload, the starting address is within 1MB
range (eg: 0x7fb0000), thus causes failure in video_post_bind().

Actually if plat->size is zero, it makes no sense to do anything
in this routine. Add such check there.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

video: Allow selection of the driver and font size

Provide a way for the video console driver to be selected. This is
controlled by the video driver's private data. This can be set up when the
drive

video: Allow selection of the driver and font size

Provide a way for the video console driver to be selected. This is
controlled by the video driver's private data. This can be set up when the
driver is probed so that it is ready for the video_post_probe() method.

The font size is provided as well. The console driver may or may not support
this depending on its capability.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Anatolij Gustschin <agust@denx.de>

show more ...

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 u

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>

show more ...

video: Add a function to control cache flushing

Allow the cache-flushing function of a video device to be controlled.

Signed-off-by: Simon Glass <sjg@chromium.org>

Merge git://git.denx.de/u-boot-dm

dm: video: Add a uclass for the text console

The existing LCD/video interface suffers from conflating the bitmap display
with text output on that display. As a result the implementation is more
comp

dm: video: Add a uclass for the text console

The existing LCD/video interface suffers from conflating the bitmap display
with text output on that display. As a result the implementation is more
complex than it needs to me.

We can support multiple text console drivers. Create a separate uclass to
support this, with its own API.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>

show more ...

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 s

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>

show more ...