Hi folks,
This series adds support for the Cedar video engine found in the
Allwinner H616 SoC. On the way, it also fixes some issues with the
DT representation for the Allwinner H6 SoC.
Patch 1 fixes the video engine's number of IOMMU endpoints on the
H6 in the DT binding.
Patch 2 fixes the video engine's number of SRAM regions on the
H6 in the DT binding.
Patch 3 adds a new compatible for the H616's video engine.
Patch 4 adds the new compatible for the H616's video engine to the
cedrus driver.
Patch 5 adds the video engine's missing SRAM region to the H6 dtsi.
Patch 6 adds the video engine's missing IOMMU endpoint to the H6 dtsi.
Patch 7 adds a device node for the video engine to the H616 dtsi.
Patches 1-4 should go through the media tree, while patches 5-7 will go
through the soc tree via the sunxi tree.
Please have a look.
Thanks
ChenYu
Chen-Yu Tsai (6):
dt-bindings: media: sun4i-a10-video-engine: Fix IOMMU count for H6
dt-bindings: media: sun4i-a10-video-engine: Fix SRAM count for H6
dt-bindings: media: sun4i-a10-video-engine: Add H616 compatible
drivers: staging: media: sunxi: cedrus: add H616 variant
arm64: dts: allwinner: sun50i-h6: Add missing SRAM region for video
engine
arm64: dts: allwinner: sun50i-h6: Add missing IOMMU for video engine
Jernej Skrabec (1):
arm64: dts: allwinner: sun50i-h616: Add video engine
.../allwinner,sun4i-a10-video-engine.yaml | 45 ++++++++++++++++++-
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 4 +-
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 12 +++++
drivers/staging/media/sunxi/cedrus/cedrus.c | 4 ++
4 files changed, 61 insertions(+), 4 deletions(-)
--
2.47.3
On the H6, the SRAM C region includes an alias of part of the VE SRAM
used by the video engine. This region should also be claimed so that no
access happens through the alias window.
Add a second SRAM region phandle to the video engine for the H6.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
.../allwinner,sun4i-a10-video-engine.yaml | 21 ++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
@@ -48,11 +48,15 @@ properties:allwinner,sram:$ref:/schemas/types.yaml#/definitions/phandle-array+minItems:1items:-items:-description:phandle to SRAM-description:register value for device-description:Phandle to the device SRAM+-items:+-description:phandle to SRAM alias+-description:register value for device+description:Phandle to the device SRAM(s)iommus:minItems:1
The H616 contains a video engine similar to past SoCs.
Add a new compatible for it.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
.../bindings/media/allwinner,sun4i-a10-video-engine.yaml | 3 +++
1 file changed, 3 insertions(+)
On the H6 SoC, the Video Engine has two memory ports, thus two IOMMU
connections. The secondary one that is missing is likely used for
reading reference frames. The newer H616 is the same. On the other
hand, the D1 only has one memory port.
Add the missing IOMMU connection for the Video Engine.
Fixes: 62a8ccf3a248 ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
.../allwinner,sun4i-a10-video-engine.yaml | 21 ++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
@@ -55,7 +55,10 @@ properties:description:Phandle to the device SRAMiommus:-maxItems:1+minItems:1+items:+-description:VE port on IOMMU+-description:VE_R port on IOMMUmemory-region:maxItems:1
The Allwinner H616 SoC has a video engine hardware block like the one
found on previous generations such as the H6. In addition to the
currently supported features of the H6, it is also supposed to include
a VP9 decoder. However software support for this is currently missing
and still needs to be reverse engineered from the vendor BSP.
Add the compatible for the H616 variant, using the H6 variant data.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 4 ++++
1 file changed, 4 insertions(+)
The video engine on the H6 actually has two IOMMU ports. The one already
listed is simply named "VE" in the user manual. The missing one is named
"VE_R" and is probably either read-only or used for reference frames.
Either way, it should be listed.
Add a reference to the "VE_R" IOMMU port to the video engine node.
Fixes: 62a8ccf3a248 ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jernej Skrabec <jernej.skrabec@gmail.com>
The H616 SoC has a video engine, and two SRAM regions needed by it.
Add the video engine to the dtsi file.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
[wens@kernel.org: Add VE SRAM region and commit message]
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
The SRAM C region contains a partial alias to the VE SRAM already
referenced by the video engine. To avoid access through this alias
window, the region should also be claimed by the video engine.
Add a reference to the SRAM C region to the video engine node.
Fixes: b542570e5605 ("arm64: dts: allwinner: h6: Add Video Engine node")
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Dne torek, 5. maj 2026 ob 15:48:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
On the H6 SoC, the Video Engine has two memory ports, thus two IOMMU
connections. The secondary one that is missing is likely used for
reading reference frames. The newer H616 is the same. On the other
hand, the D1 only has one memory port.
Add the missing IOMMU connection for the Video Engine.
Fixes: 62a8ccf3a248 ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
Dne torek, 5. maj 2026 ob 15:48:06 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
quoted hunk
On the H6, the SRAM C region includes an alias of part of the VE SRAM
used by the video engine. This region should also be claimed so that no
access happens through the alias window.
Add a second SRAM region phandle to the video engine for the H6.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
.../allwinner,sun4i-a10-video-engine.yaml | 21 ++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
@@ -48,11 +48,15 @@ properties:allwinner,sram:$ref:/schemas/types.yaml#/definitions/phandle-array+minItems:1items:-items:-description:phandle to SRAM-description:register value for device-description:Phandle to the device SRAM+-items:+-description:phandle to SRAM alias+-description:register value for device+description:Phandle to the device SRAM(s)iommus:minItems:1
Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
The Allwinner H616 SoC has a video engine hardware block like the one
found on previous generations such as the H6. In addition to the
currently supported features of the H6, it is also supposed to include
Remove "supposed".
a VP9 decoder. However software support for this is currently missing
and still needs to be reverse engineered from the vendor BSP.
Add the compatible for the H616 variant, using the H6 variant data.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
With that:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
Dne torek, 5. maj 2026 ob 15:48:09 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
The SRAM C region contains a partial alias to the VE SRAM already
referenced by the video engine. To avoid access through this alias
window, the region should also be claimed by the video engine.
Add a reference to the SRAM C region to the video engine node.
Fixes: b542570e5605 ("arm64: dts: allwinner: h6: Add Video Engine node")
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
Dne torek, 5. maj 2026 ob 15:48:10 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
The video engine on the H6 actually has two IOMMU ports. The one already
listed is simply named "VE" in the user manual. The missing one is named
"VE_R" and is probably either read-only or used for reference frames.
Either way, it should be listed.
Add a reference to the "VE_R" IOMMU port to the video engine node.
Fixes: 62a8ccf3a248 ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
From: Paul Kocialkowski <paulk@sys-base.io> Date: 2026-05-05 20:35:34
Hi Chen-Yu,
On Tue 05 May 26, 21:48, Chen-Yu Tsai wrote:
The SRAM C region contains a partial alias to the VE SRAM already
referenced by the video engine. To avoid access through this alias
window, the region should also be claimed by the video engine.
Add a reference to the SRAM C region to the video engine node.
It feels very weird to have a reference to the DE2 SRAM region in the
VE node. It seems unlikely that the same region would be used by both DE2 and
VE and I am pretty sure can have both running at the same time without
overstepping.
From what I can see we have so far assumed that the SRAM C and SRAM C1
are two different physical SRAM areas, but this is most likely not the case.
My guess would be that SRAM C1 is actually a part of SRAM C and the DE2 is
using another part of it. The syscon block probably allows switching access
to these different parts of SRAM C.
Also the sram_c1 node implies it's 2 MiB, which sounds quite unlikely.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
On Tue, 05 May 2026 21:48:06 +0800, Chen-Yu Tsai wrote:
On the H6, the SRAM C region includes an alias of part of the VE SRAM
used by the video engine. This region should also be claimed so that no
access happens through the alias window.
Add a second SRAM region phandle to the video engine for the H6.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
.../allwinner,sun4i-a10-video-engine.yaml | 21 ++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
On Tue, 05 May 2026 21:48:05 +0800, Chen-Yu Tsai wrote:
On the H6 SoC, the Video Engine has two memory ports, thus two IOMMU
connections. The secondary one that is missing is likely used for
reading reference frames. The newer H616 is the same. On the other
hand, the D1 only has one memory port.
Add the missing IOMMU connection for the Video Engine.
Fixes: 62a8ccf3a248 ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
.../allwinner,sun4i-a10-video-engine.yaml | 21 ++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
On Tue, 05 May 2026 21:48:07 +0800, Chen-Yu Tsai wrote:
The H616 contains a video engine similar to past SoCs.
Add a new compatible for it.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
---
.../bindings/media/allwinner,sun4i-a10-video-engine.yaml | 3 +++
1 file changed, 3 insertions(+)
On Tue, May 5, 2026 at 10:35 PM Paul Kocialkowski [off-list ref] wrote:
Hi Chen-Yu,
On Tue 05 May 26, 21:48, Chen-Yu Tsai wrote:
quoted
The SRAM C region contains a partial alias to the VE SRAM already
referenced by the video engine. To avoid access through this alias
window, the region should also be claimed by the video engine.
Add a reference to the SRAM C region to the video engine node.
It feels very weird to have a reference to the DE2 SRAM region in the
VE node. It seems unlikely that the same region would be used by both DE2 and
VE and I am pretty sure can have both running at the same time without
overstepping.
From what I can see we have so far assumed that the SRAM C and SRAM C1
are two different physical SRAM areas, but this is most likely not the case.
My guess would be that SRAM C1 is actually a part of SRAM C and the DE2 is
No. It's the opposite. 0x28000 maps to the same SRAM block at 0x1a00000.
If you write to one, you see the results in both. However the alias at
028000 can be disabled while retaining access to 0x1a00000. I don't
remember how much of the alias points to VE SRAM (0x1a00000). Maybe it
was the whole alias on the H6.
Also, I can't remember if this was tested on the H6 or H616, but the
VE indeed writes to VE SRAM (0x1a00000), so that part is indeed used
by the video engine.
using another part of it. The syscon block probably allows switching access
to these different parts of SRAM C.
From what I've seen in the vendor BSP, both drivers toggle the switch.
I believe the goal is to prevent the CPU from having access, rather than
either peripheral claiming it as its own. And that is also what our SRAM
driver does. It claims the SRAM from the CPU. That's all. The toggle bit
pattern used by both drivers is the same.
Also the sram_c1 node implies it's 2 MiB, which sounds quite unlikely.
That is what the memory map says. Calling it SRAM C1 is probably wrong.
ChenYu
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec [off-list ref] wrote:
Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
quoted
The Allwinner H616 SoC has a video engine hardware block like the one
found on previous generations such as the H6. In addition to the
currently supported features of the H6, it is also supposed to include
Remove "supposed".
I can't actually verify that, so "supposed" is accurate from my point of
view.
ChenYu
quoted
a VP9 decoder. However software support for this is currently missing
and still needs to be reverse engineered from the vendor BSP.
Add the compatible for the H616 variant, using the H6 variant data.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
With that:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
Dne sobota, 30. maj 2026 ob 18:43:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec [off-list ref] wrote:
quoted
Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
quoted
The Allwinner H616 SoC has a video engine hardware block like the one
found on previous generations such as the H6. In addition to the
currently supported features of the H6, it is also supposed to include
Remove "supposed".
I can't actually verify that, so "supposed" is accurate from my point of
view.
Isn't info from manual good enough?
In the interest of unblocking this, I would be fine with "supposed" too,
but manual and all my experiments show VP9 is supported.
Best regards,
Jernej
ChenYu
quoted
quoted
a VP9 decoder. However software support for this is currently missing
and still needs to be reverse engineered from the vendor BSP.
Add the compatible for the H616 variant, using the H6 variant data.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
With that:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
On Sat, Jun 13, 2026 at 6:33 PM Jernej Škrabec [off-list ref] wrote:
Dne sobota, 30. maj 2026 ob 18:43:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
quoted
On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec [off-list ref] wrote:
quoted
Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
quoted
The Allwinner H616 SoC has a video engine hardware block like the one
found on previous generations such as the H6. In addition to the
currently supported features of the H6, it is also supposed to include
Remove "supposed".
I can't actually verify that, so "supposed" is accurate from my point of
view.
Isn't info from manual good enough?
The manual says the SoC supports it. Same was said for the H6. Then
we discovered that the VP9 decoder was a separate Hantro block.
So again, *I* cannot claim in the commit message that the hardware
block supports VP9 decoding, because I have not verified it.
In the interest of unblocking this, I would be fine with "supposed" too,
but manual and all my experiments show VP9 is supported.
Please give an ack or reviewed-by with a comment at the end stating
VP9 verified.
Thanks
ChenYu
Best regards,
Jernej
quoted
ChenYu
quoted
quoted
a VP9 decoder. However software support for this is currently missing
and still needs to be reverse engineered from the vendor BSP.
Add the compatible for the H616 variant, using the H6 variant data.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
With that:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
Dne sobota, 13. junij 2026 ob 16:34:00 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
On Sat, Jun 13, 2026 at 6:33 PM Jernej Škrabec [off-list ref] wrote:
quoted
Dne sobota, 30. maj 2026 ob 18:43:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
quoted
On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec [off-list ref] wrote:
quoted
Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
quoted
The Allwinner H616 SoC has a video engine hardware block like the one
found on previous generations such as the H6. In addition to the
currently supported features of the H6, it is also supposed to include
Remove "supposed".
I can't actually verify that, so "supposed" is accurate from my point of
view.
Isn't info from manual good enough?
The manual says the SoC supports it. Same was said for the H6. Then
we discovered that the VP9 decoder was a separate Hantro block.
So again, *I* cannot claim in the commit message that the hardware
block supports VP9 decoding, because I have not verified it.
quoted
In the interest of unblocking this, I would be fine with "supposed" too,
but manual and all my experiments show VP9 is supported.
Please give an ack or reviewed-by with a comment at the end stating
VP9 verified.
Well, just go with original text.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
Thanks
ChenYu
quoted
Best regards,
Jernej
quoted
ChenYu
quoted
quoted
a VP9 decoder. However software support for this is currently missing
and still needs to be reverse engineered from the vendor BSP.
Add the compatible for the H616 variant, using the H6 variant data.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
With that:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej