Adding dri-devel
On Fri, 5 Jul 2024 at 17:14, Stefan Wahren <wahrenst@xxxxxxx> wrote:
Hi,
last year my Raspberry Pi 3B Plus died, so i didn't noticed this sooner.
If I ran Raspberry Pi OS Bullseye with X11 and a recent Mainline Kernel
(arm/multi_v7_defconfig) on my new Raspberry Pi 3 B+, i'm getting the
following errors:
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 6.10.0-rc1-g685505219723
(stefanw@stefanw-SCHENKER) (arm-linux-gnueabihf-gcc (GCC) 11.3.1
20220604 [releases/gcc-11 revision
591c0f4b92548e3ae2e8173f4f93984b1c7f62bb], GNU ld
(Linaro_Binutils-2022.06) 2.37.20220122) #1 SMP Wed Jul 3 19:57:14 CEST
2024
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7),
cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
[ 0.000000] random: crng init done
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: UEFI not found.
[ 0.000000] Reserved memory: created CMA memory pool at 0x37000000,
size 64 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible
id shared-dma-pool
[ 0.000000] OF: reserved mem: 0x37000000..0x3affffff (65536 KiB) map
reusable linux,cma
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000030000000-0x000000003b3fffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003b3fffff]
[ 0.000000] Initmem setup node 0 [mem
0x0000000000000000-0x000000003b3fffff]
[ 0.000000] percpu: Embedded 17 pages/cpu s40404 r8192 d21036 u69632
[ 0.000000] pcpu-alloc: s40404 r8192 d21036 u69632 alloc=17*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Kernel command line: video=HDMI-A-1:1920x1200M@60
dma.dmachans=0x7ff5 bcm2709.boardrev=0xa020d3 bcm2709.serial=0x51972538
bcm2709.uart_clock=48000000 bcm2709.disk_led_gpio=29
bcm2709.disk_led_active_low=0 vc_mem.mem_base=0x3ec00000
vc_mem.mem_size=0x40000000 console=ttyS1,115200 console=tty1
root=PARTUUID=ecfed651-02 rootfstype=ext4 fsck.repair=yes rootwait
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 242688
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off,
mlocked free:off
[ 0.000000] Memory: 868880K/970752K available (15360K kernel code,
2535K rwdata, 6708K rodata, 2048K init, 426K bss, 36336K reserved,
65536K cma-reserved, 118784K highmem)
...
[ 56.187787] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
GEM DMA helper:
[ 56.187870] vc4-drm soc:gpu: [drm] V3D: 36316kb BOs (40)
[ 56.187884] vc4-drm soc:gpu: [drm] V3D shader:
124kb BOs (31)
[ 56.187893] vc4-drm soc:gpu: [drm] dumb: 4564kb BOs (5)
[ 56.187900] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
[ 56.187909] vc4-drm soc:gpu: [drm] total purged BO:
19540kb BOs (15)
[ 56.188269] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
GEM DMA helper:
[ 56.188315] vc4-drm soc:gpu: [drm] V3D: 35072kb BOs (30)
[ 56.188325] vc4-drm soc:gpu: [drm] V3D shader:
124kb BOs (31)
[ 56.188337] vc4-drm soc:gpu: [drm] dumb: 4564kb BOs (5)
[ 56.188345] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
[ 56.188354] vc4-drm soc:gpu: [drm] total purged BO:
19540kb BOs (15)
...
Except of these errors, X11 works as expected. Since I knew that this
setup shouldn't throw these errors without CMA modifications, I bisected
this to this commit:
commit 47c07e46c86f310bed73b9c895155a49df3d5e71 (HEAD)
Author: Maíra Canal <mcanal@xxxxxxxxxx>
Date: Thu Feb 2 08:19:43 2023 -0300
drm/vc4: replace drm_gem_dma_object for drm_gem_object in vc4_exec_info
After that I increased the CMA to 128 MB via Kernel cmdline and compared
/proc/meminfo before and after the patch:
Before
CmaTotal: 131072 kB
CmaFree: 20132 kB
After
CmaTotal: 131072 kB
CmaFree: 5644 kB
So my question: is this noticable CMA increase expected by this change?
No, it shouldn't change anything. All it does is change the type we use to iterate over objects from the subclass to the base class in the command submission code. The resulting code should be entirely unchanged, if the compiler doesn't get confused at least and applies all the same optimizations.
Can you please double-check that it's really this commit that makes the difference, and nothing else changed in the system?
Thanks, Sima
