[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c62e3c837d534ef5bc21a95ec1dc408c38cb8a0.camel@ndufresne.ca>
Date: Tue, 07 Oct 2025 14:06:06 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Sven Püschel <s.pueschel@...gutronix.de>, Jacob Chen
<jacob-chen@...wrt.com>, Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
Mauro Carvalho Chehab
<mchehab@...nel.org>, Heiko Stuebner <heiko@...ech.de>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>
Cc: linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH 00/16] media: platform: rga: Add RGA3 support
Hi,
Le mardi 07 octobre 2025 à 10:31 +0200, Sven Püschel a écrit :
> This series adds support for the Raster Graphic Acceleration 3 (RGA3)
> peripheral, which is included in the RK3588 SoC. Unlike the RGA2 it
> can use the existing rockchip-iommu-v2 driver to handle iommu mappings.
> Also the RK3588 contains two independent RGA3 cores.
Thanks for working on this.
>
> Only scaling and format conversions between common 8bit RGB/YUV formats
> are implemented. Also the color space conversion is fixed to BT601F.
> This already allows a practical usage of the RGA3.
This seems quite limiting, can we expect an update on this, can't be that hard
to fully implement.
>
> This was tested on a Radxa Rock 5T. With the increased clock speeds in
> the devicetree around 160 fps were measured when scaling and converting
This is quite vague, I've checked the patch and you didn't extend either there.
Is that an overclock or was it miss-configured ? Does RK implement a devfreq ?
Should that be moved with a voltage adjustement ? Is there any thermal nearby we
should monitor ?
> from RGBA 480x360 to NV12 3840x2160. Without the clock speed scaling a
> default clock division factor of 2 is used and only around 80 fps are
> reached with one core. The v4l2-compliance tests only complain about
> the already failing colorspace propagation:
Did you do any more format testing to validation all supported combinations ?
This is a tool [0] you can use to test this using GStreamer and how to use it
[1].
[0] https://gitlab.collabora.com/mediatek/aiot/lava-test-definitions/-/tree/main/avvideocompare?ref_type=heads
[1] https://gitlab.collabora.com/mediatek/aiot/linux/-/blob/mediatek-next/.gitlab-ci.yml?ref_type=heads#L282
>
> v4l2-compliance 1.28.1, 64 bits, 64-bit time_t
> ...
> fail: v4l2-test-formats.cpp(923): fmt_cap.g_colorspace() !=
> col
> test VIDIOC_S_FMT: FAIL
> ...
> Total for rockchip-rga device /dev/video0: 47, Succeeded: 46, Failed: 1,
> Warnings: 0
>
> v4l2-compliance 1.28.1, 64 bits, 64-bit time_t
> ...
> fail: v4l2-test-formats.cpp(923): fmt_cap.g_colorspace() !=
> col
> test VIDIOC_S_FMT: FAIL
> ...
> Total for rockchip-rga device /dev/video1: 47, Succeeded: 46, Failed: 1,
> Warnings: 0
>
> v4l2-compliance 1.28.1, 64 bits, 64-bit time_t
> ...
> fail: v4l2-test-formats.cpp(923): fmt_cap.g_colorspace() !=
> col
> test VIDIOC_S_FMT: FAIL
> ...
> Total for rockchip-rga device /dev/video2: 47, Succeeded: 46, Failed: 1,
> Warnings: 0
>
> Each RGA core is a separate /dev/video device. To distinguish the RGA2
> core from the RGA3 cores the Card type is set accordingly. Combining all
> cores into a single device and scheduling tasks to the best core might
> be a future improvement, if it is desired by upstream to handle the
> scheduling and selection in kernel space.
It took me some time to understand why you spoke about multicore here. You
forgot to say here that you add RGA3 into RGA2 driver. Some information on why
you went that path instead of a separate driver.
From high level view, I don't think its a good idea to multi-plex over
heterogeneous core. They may not even produce the exact same pixels for the same
operation. They also don't share the same MMU, and at first glance, the use of
rkiommu in RGA3 means it can no longer handle CPU cache (though I don't know if
this is implemented/supported in upstream RGA2 driver).
>
> Patch 1-2 are general cleanups
> Patch 3-12 prepare the rga driver for the RGA3
> Patch 13 documments the RGA3 compatible value
> Patch 14 adds the RGA3 cores to the rk3588 dtsi
> Patch 15 increases the RGA3 core clock speeds
> Patch 16 adds RGA3 support to the rga driver
>
> Signed-off-by: Sven Püschel <s.pueschel@...gutronix.de>
> ---
> Sven Püschel (16):
> media: rockchip: rga: use clk_bulk api
> media: rockchip: rga: use stride for offset calculation
> media: rockchip: rga: align stride to 16 bytes
> media: rockchip: rga: move hw specific parts to a dedicated struct
> media: rockchip: rga: use card type to specify rga type
> media: rockchip: rga: change offset to dma_addresses
> media: rockchip: rga: support external iommus
> media: rockchip: rga: remove size from rga_frame
> media: rockchip: rga: remove stride from rga_frame
> media: rockchip: rga: move rga_fmt to rga-hw.h
> media: rockchip: rga: add iommu restore function
> media: rockchip: rga: handle error interrupt
> media: dt-bindings: media: rockchip-rga: add rockchip,rk3588-rga3
> arm64: dts: rockchip: add rga3 dt nodes
> arm64: dts: rockchip: increase rga3 clock speed
> media: rockchip: rga: add rga3 support
>
> .../devicetree/bindings/media/rockchip-rga.yaml | 1 +
> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 50 +++
> drivers/media/platform/rockchip/rga/Makefile | 2 +-
> drivers/media/platform/rockchip/rga/rga-buf.c | 78 ++--
> drivers/media/platform/rockchip/rga/rga-hw.c | 356 ++++++++++++---
> drivers/media/platform/rockchip/rga/rga-hw.h | 15 +-
> drivers/media/platform/rockchip/rga/rga.c | 404 ++++++-----------
> drivers/media/platform/rockchip/rga/rga.h | 74 ++--
> drivers/media/platform/rockchip/rga/rga3-hw.c | 490
> +++++++++++++++++++++
> drivers/media/platform/rockchip/rga/rga3-hw.h | 186 ++++++++
> 10 files changed, 1246 insertions(+), 410 deletions(-)
> ---
> base-commit: afb100a5ea7a13d7e6937dcd3b36b19dc6cc9328
> change-id: 20251001-spu-rga3-8a00e018b120
>
> Best regards,
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists