Rga on 8GB memory board

amazingfate · May 17, 2022, 6:08am

I have a 8GB rock3a and I’m using a mainline 5.17 kernel. I can enable the rga in dtb with CounterPillow’s patch. But when I use gstreamer command gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! v4l2convert ! video/x-raw,width=640,height=480 ! autovideosink, I get a green window. And I can see rga error:

rockchip-rga fdeb0000.rga: swiotlb buffer is full (sz: 393216 bytes), total 32768 (slots), used 6827 (slots)

After some search on internet, I found that other people using rockchip 4.19 also meet this issue: https://forum.odroid.com/viewtopic.php?f=211&t=44281&sid=8c3a1dedcc2e517ab52168e19f0b6970. I add “mem=4G” to my boot parameter and I can run the above gstreamer command with normal output. It seems that the rockchip rga2 driver is used for chips released before rk3568 which don’t have memory larger than 4GB.

hotnikq · November 11, 2022, 2:11am

Facing same problems here, RK3566 evb3 V10 board with kernel 4.19.219

avaf · November 11, 2022, 11:38am

@amazingfate

Just some of my findings.
This happens also on rk3588, 16GB, kernel 5.10.66 and 5.10.110, librga 1.8.1 If i recall correctly, librga on the official image is 1.7.y and i can’t remember having this issue with 1.7.y when i re-used the rootfs to build my first custom image, but i don’t have the latest SDK. Waiting for the Radxa team to release it and test it.

Obs: using hw decode

amazingfate · December 27, 2023, 11:55am

This patch will save the world: https://lore.kernel.org/linux-arm-kernel/20230914-rockchip-rga-multiplanar-v2-0-bbfa6abf8bbf@pengutronix.de/
I have tested it on rk3588, which works amazing.

nyanmisaka · December 27, 2023, 1:08pm

Rockchip BSP kernel does not require this. The mainline requires it because it was hardcoded in V4L2 driver. You are free to set whether to allocate DMA32 memory via the ROCKCHIP_BO_DMA32 DRM_GEM flag or using the DMA_HEAP device nodes /dev/dma_heap/system-{dma32,uncached-dma32}.

Or simply use the MPP internal allocator and add the following flags.

mpp_buffer_group_get_internal(&buf_group, MPP_BUFFER_TYPE_DRM | MPP_BUFFER_FLAGS_DMA32 | MPP_BUFFER_FLAGS_CACHABLE);

github.com

armbian/linux-rockchip/blob/408b805bfcea97e312e10dd15909e3f4924fcdec/drivers/gpu/drm/rockchip/rockchip_drm_gem.c#L628


	struct rockchip_gem_object *rk_obj;
	struct drm_gem_object *obj;


#ifdef CONFIG_ARM_LPAE
	gfp_t gfp_mask = GFP_HIGHUSER | __GFP_RECLAIMABLE | __GFP_DMA32;
#else
	gfp_t gfp_mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
#endif


	if (flags & ROCKCHIP_BO_DMA32)
		gfp_mask |= __GFP_DMA32;


	size = round_up(size, PAGE_SIZE);


	rk_obj = kzalloc(sizeof(*rk_obj), GFP_KERNEL);
	if (!rk_obj)
		return ERR_PTR(-ENOMEM);


	obj = &rk_obj->base;


	drm_gem_object_init(drm, obj, size);

github.com

armbian/linux-rockchip/blob/408b805bfcea97e312e10dd15909e3f4924fcdec/drivers/dma-buf/heaps/rk_system_heap.c#L771


			int j;


			pr_err("%s: page pool creation failed!\n", __func__);
			for (j = 0; j < i; j++)
				dmabuf_page_pool_destroy(pools[j]);
			return -ENOMEM;
		}
	}


	for (i = 0; i < NUM_ORDERS; i++) {
		dma32_pools[i] = dmabuf_page_pool_create(order_flags[i] | GFP_DMA32, orders[i]);


		if (!dma32_pools[i]) {
			int j;


			pr_err("%s: page dma32 pool creation failed!\n", __func__);
			for (j = 0; j < i; j++)
				dmabuf_page_pool_destroy(dma32_pools[j]);
			goto err_dma32_pool;
		}
	}

avaf · December 27, 2023, 9:28pm

Thanks for the heads up.

I am still running 5.10.110 on rk3588, which i find it more stable for this platform. (16GB RAM).
Rock 3A runs very stable with 5.10.160 (rkr4.1)
What puzzles me is Armbian kernel naming convention, named rkr6 and Rockchip BSP looks like rkr6.1 and is on kernel 6.1 now.
Are you following Rockchip naming convention?

iena2003 · November 28, 2024, 1:24pm

i can’t find the actual changes of this commit, where can i find a patch of this or the actual commit?
and does it fix the 4g issue of the RGA on the rk3588?

nyanmisaka · November 28, 2024, 3:27pm

4GB on RGA2 is a hardware limitation. It can’t be magically fixed with a patch. The error will still occur when you already use more than 4GB of DMA32 memory. This patch just makes the hardware prioritize using DMA32.

Video buffers should now be allocated within
the 4 GB boundary and an import of buffers that have higher addresses
into the driver should fail.