[RK3588]Add H.265 Hardware Encoding Support & HDMIRX fix by @rcawston #10091
[RK3588]Add H.265 Hardware Encoding Support & HDMIRX fix by @rcawston #10091pdapandapda wants to merge 39 commits into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughHDMIRX handling is updated across three kernel branches to change EDID, hotplug, and signal-lock sequencing, and plugout now reports active V4L2 streaming errors. A new RK3588 rkvenc MPP overlay is also added and registered in the overlay Makefiles. ChangesHDMIRX EDID/hotplug and signal-lock fixes
HDMIRX plugout vb2 error signaling
rkvenc MPP DT overlay for RK3588 VEPU580 encoder
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@patch/kernel/archive/rockchip64-6.18/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch`:
- Around line 40-52: The delayed hotplug path is still being scheduled even when
EDID is cleared, which can let a stale worker reassert HPD after the clear-EDID
branch resets state. Update the hotplug scheduling and worker flow around
hdmirx_write_edid, delayed_work_hotplug, and the code that checks edid->blocks
so the delayed work is only queued for non-empty EDID and the worker/plugin path
also verifies edid_blocks_written before driving HPD. Keep the existing
enable_irq handling, but gate any HPD reassertion on valid written EDID state.
In
`@patch/kernel/archive/rockchip64-6.18/0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patch`:
- Line 1: Remove the stray .DS_Store binary diff marker from the patch so the
archive only contains the intended Rockchip HDMIRX change; update the patch
content to exclude any .DS_Store references in all branch copies, keeping the
diff focused on the actual synopsys/HDMIRX modification.
In
`@patch/kernel/archive/rockchip64-6.18/overlay/rockchip-rk3588-rkvenc-mpp.dtso`:
- Around line 9-10: The usage example is referencing the wrong overlay filename,
so update the comment in the rk3588 rkvenc MPP overlay to match the actual
source name. In the overlay documentation block near the top of
rockchip-rk3588-rkvenc-mpp.dtso, change the armbian-add-overlay example to use
the .dtso filename or otherwise match the real artifact name, so users can copy
the command without hitting a missing-file error.
In
`@patch/kernel/archive/rockchip64-7.1/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch`:
- Around line 40-52: The hotplug delayed work is being queued unconditionally in
this EDID update path, so it also runs when edid->blocks is zero and can raise
HPD without a valid EDID. Update the logic around hdmirx_write_edid,
hdmirx_hpd_ctrl, and delayed_work_hotplug so the work is only queued after a
successful EDID write, and either cancel or skip it on the clear-EDID branch
where cec_phys_addr_invalidate and edid_blocks_written reset happen.
In `@patch/kernel/archive/rockchip64-7.1/overlay/rockchip-rk3588-rkvenc-mpp.dtso`:
- Around line 9-10: The usage example is inconsistent with the overlay source
filename and should match the actual .dtso name. Update the usage text in the
rockchip-rk3588-rkvenc-mpp overlay comments so the example refers to
rockchip-rk3588-rkvenc-mpp.dtso, keeping the documented invocation consistent
with the source file and the overlay’s real identifier.
In
`@patch/kernel/archive/rockchip64-7.2/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch`:
- Around line 40-52: Only schedule the delayed hotplug after a successful EDID
write in the EDID handling path around hdmirx_write_edid/hdmirx_hpd_ctrl, and do
not queue it when edid->blocks is zero. When EDID is cleared, also cancel any
pending delayed_work_hotplug so hdmirx_plugin() cannot reassert HPD against an
empty EDID; keep the IRQ enable calls separate from the hotplug queuing logic.
In `@patch/kernel/archive/rockchip64-7.2/overlay/rockchip-rk3588-rkvenc-mpp.dtso`:
- Around line 9-10: The usage example in the overlay header is inconsistent with
the actual source filename; update the Usage line in the
rockchip-rk3588-rkvenc-mpp overlay comment so it references the .dtso name used
by this file. Keep the example aligned with the overlay’s real basename so users
see the correct armbian-add-overlay target.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 066808d4-feab-4154-a137-4d3cc7e34338
📒 Files selected for processing (15)
patch/kernel/archive/rockchip64-6.18/0001-rockchip-rk3588-vepu580-encoder-support-v3.patchpatch/kernel/archive/rockchip64-6.18/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patchpatch/kernel/archive/rockchip64-6.18/0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patchpatch/kernel/archive/rockchip64-6.18/overlay/Makefilepatch/kernel/archive/rockchip64-6.18/overlay/rockchip-rk3588-rkvenc-mpp.dtsopatch/kernel/archive/rockchip64-7.1/0001-rockchip-rk3588-vepu580-encoder-support-v3.patchpatch/kernel/archive/rockchip64-7.1/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patchpatch/kernel/archive/rockchip64-7.1/0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patchpatch/kernel/archive/rockchip64-7.1/overlay/Makefilepatch/kernel/archive/rockchip64-7.1/overlay/rockchip-rk3588-rkvenc-mpp.dtsopatch/kernel/archive/rockchip64-7.2/0001-rockchip-rk3588-vepu580-encoder-support-v3.patchpatch/kernel/archive/rockchip64-7.2/0002-rockchip-rk3588-hdmirx-edid-fix-v1.patchpatch/kernel/archive/rockchip64-7.2/0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patchpatch/kernel/archive/rockchip64-7.2/overlay/Makefilepatch/kernel/archive/rockchip64-7.2/overlay/rockchip-rk3588-rkvenc-mpp.dtso
Removed usage instructions and added modifier credit.
…rx-plugout-fix-v1.patch Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
This patch adds support for the VPU580 encoder in the Rockchip RK3588 kernel.
This patch adds support for the VPU580 encoder in the Rockchip RK3588 kernel.
This patch adds support for the VPU encoder in the Rockchip RK3588.
Add support for VPU580 encoder in Rockchip RK3588.
This patch updates the rockchip64 kernel files related to HDMI RX functionality.
This patch updates the rockchip64 kernel files to fix the HDMI RX plug-out issue.
|
Err... I don't think this belongs. Does it? It seems to shoehorn pieces of mpp from vendor into mainline so one could use rkmpp userspace for encoding. A kind-of Might fit into a separate branch or such, but not for regular edge, much less current. |
Thank you for the feedback, @rpardini. You are right, I have mixed the HDMIRX plugout/EDID stability fixes with the VPU580 encoder support. I understand that the encoder support might be too experimental or out of scope for the regular edge kernel. For the VPU580 support, I realize it's out of scope for the stable/regular edge kernel. I'll maintain that separately as a user-level/DKMS module or an optional patch for those who need it. Could you please review the cleaned-up PR once I push the changes |
|
I am the author of these patches originally. The EDID fix has been simplified and exists in mainline Linux kernel already - it probably should not be included. The encoder does work in extensive testing, put is a stop-gap to using MPP on mainline - fine if desired, but I would suggest it might be best left as an optional patch. This patch series is indeed stable in my own testing. |
Hey @rcawston -- does the whole of rkmpp work (eg also decoding, h264, av1, vp9, etc) or is this only about the hevc encoding? I ask because ffmpeg-rockchip / kodi eg https://github.com/armsurvivors/kodi-rockchip-deb -- it would be fun to get it on mainline, even if a stop-gap. |
Here is my result with ffmpeg-rockchip https://github.com/nyanmisaka/ffmpeg-rockchip/tree/8.1 |
The patch is specific to HEVC encoding on the VEPU580 IP. H264 would fairly easy to add, but I didn't have a use case personally. Most decoding functionality already exists in mainline (VP8. MPEG2, MPEG4, H264, HEVC) and VP9 is in-progress (dvab-sarma/android_kernel_rk_opi@aa00b89). |
|
Ok, thanks. The way I see it, if we
Then only the With that, if and when there is any progress in the encoder upstream, we can easily switch this off and go mainline. @amazingfate what do you think? did I miss something? I remember you also had a dkms or such for rkmpp-on-mainline in the past? |
|
I have some concerns:
|
|
Indeed. Having the full encode+decode rkmpp in a dkms would justify the effort. Still, there's changes to |
Adding decoder would conflict with the current upstreamed decoder nodes. About the changes at rockchip-iommu.c, I don't see why it is necessary. Is there anywhere else calling get_resv_regions from iommu_ops? |
Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
As the mainline kernel haven't fixed the vepu580 hardware encoder and hdmirx for months, I think it is safe to port the patches by @rcawston from https://github.com/rcawston/rockchip-rk3588-mainline-patches. I have been using the patches as userpatch for months, from 6.18 to 7.2 rc1.
Documentation summary for feature / change
The following is just a copy-paste from https://github.com/rcawston/rockchip-rk3588-mainline-patches
This repository contains an out-of-tree patches for RK3588 to a near-mainline kernel (tested on v6.19-rc8)
Current Patches:
H.265 Hardware Encoding Support: 0001-rockchip-rk3588-vepu580-encoder-support-v2.patch
Set EDID Fix: 0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch
Fix buffer overflow on repeated HDMIRX replug: 0003-rockchip-rk3588-hdmirx-plugout-fix-v1.patch
Testing is done on Rock 5B[+] and Orange Pi 5 Ultra.
VEPU580 H.265 Encoder Driver
Latest version: 0001-rockchip-rk3588-vepu580-encoder-support-v2.patch
This repository contains an out-of-tree patch series adding stateful H.265 (HEVC) encoding support for the Rockchip RK3588's VEPU580 encoder block to a near-mainline kernel (tested on v6.19-rc8).
Status: Functional dual-core encoding. Produces valid H.265 bitstreams at 4K@60. Multi-core load balancing works.
Goal: Provide a practical, high-performance encoder driver for RK3588 boards (Orange Pi 5 Ultra, Radxa Rock 5B[+], etc.) while staying as close to mainline as possible. Not intended for upstream merge — although feedback welcome on design and upstreamability.
Motivation: Enable low-latency hardware-accelerated H.265 encoding for applications like IPKVM (e.g., SentinelKVM project) on mainline kernels without full vendor BSP dependency.
Pre-Requisite: Build & Install MPP
Build directly on the RK3588 device (or cross-compile for faster results).
Install Dependencies:
sudo apt update
sudo apt install cmake build-essential libdrm-dev libva-dev
Clone & Build:
git clone https://github.com/tsukumijima/mpp-rockchip.git
cd mpp-rockchip
mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
make -j$(nproc)
sudo make install
sudo ldconfig # Update library cache
Verify
mpp_info # Should show MPP version and supported codecs (including HEVC encode)
Should enable rockchip-rk3588-rkvenc-mpp.dtbo in armbian-config
Set EDID Fix
Latest version: 0002-rockchip-rk3588-hdmirx-edid-fix-v1.patch
This patch addresses an issue where the EDID is not being written correctly to the HDMIRX block. The patch ensures that the EDID is correctly written and that the source device sees the newly set EDID.
Tested with various EDID including 4k@60hz support.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.
Checklist:
Please delete options that are not relevant.
Summary by CodeRabbit