Enable memory compaction and RK630 PHY on Rockchip vendor kernels

[lukaszsobala]

Description

The motivation for this change is that memory compaction is a useful feature, and it is disabled on the Rockchip vendor kernel as a stale remnant from the 32-bit era.
Here is some context:
rockchip-linux/kernel@6fd9def
rockchip-linux/kernel@45cee0c

Compaction was probably not enabled to guard against some minimal latency issues in case of real-time media processing (which is Rockchip's intended use case), but it causes problems with memory management under pressure. If running the board as a server, this is a must-have. In my experience, running a Rock 5B with some memory regions masked due to physical degradation, it completely alleviated out of memory issues. It is enabled on the mainline kernel and many other vendor kernels.

Also, RK630, which is needed for some Ethernet ports on lower end Rockchip boards is missing; adding it to the config does not hurt anything.

How Has This Been Tested?

• Improved memory management issues on my Rockchip board, no ill effects.
• The RK630 module builds and runs correctly on a board with this interface.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings

Summary by CodeRabbit

• New Features

  • Enabled support for the Rockchip RK630 PHY as a loadable module.

• Bug Fixes

  • Updated kernel memory compaction configuration to avoid explicitly disabling it.

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)

• Needs review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 364ea6a2-70df-4167-8121-726c7e00cbe2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

📝 Walkthrough

Walkthrough

The RK35xx vendor kernel configuration no longer explicitly disables memory compaction and now enables the RK630 PHY driver as a loadable module.

Changes

RK35xx kernel configuration

Layer / File(s)	Summary
Vendor kernel configuration updates config/kernel/linux-rk35xx-vendor.config	Removes the explicit compaction disable and adds CONFIG_RK630_PHY=m.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Suggested reviewers: prahal, rpardini, ginkage, lanefu, amazingfate

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main changes: enabling memory compaction and RK630 PHY support in Rockchip vendor kernels.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[rpardini]

Hmm... 'real-time media' is the main use-case for rk vendor kernel, isn't it? If CONFIG_COMPACTION affects rkmpp/rknpu (eg via the CMA?) then this might be the reason it's disabled in the first place.

(For a typical non-media rk35xx server, mainline is definitely better suited).

[lukaszsobala]

In my experience it doesn't really affect anything badly, other than fixing problems when not enabled. If any latency issues exist, they are indistinguishable, at least to me. But I understand if you think it must be tested somehow first. Maybe the jellyfin magicians will know.

I agree that mainline is better for non-media uses. But it seemed to have been a purely theoretical preventive measure by Rockchip. I can test it on an RK3566, maybe a slower board could be a bit more revealing.

[rpardini]

I can test a bit with Frigate NVR -- I've a setup that does rkmpp mjpeg->hevc transcode on the way in, then hevc->frames for NPU detection, all based on a single 1080p@30 webcam. I will pick this and report back in a few days

[lukaszsobala]

Thank you!

[rpardini]

I can test a bit with Frigate NVR -- I've a setup that does rkmpp mjpeg->hevc transcode on the way in, then hevc->frames for NPU detection, all based on a single 1080p@30 webcam. I will pick this and report back in a few days

I've been running with this PR for a few days in this setup and couldn't notice any change at all. The machine is not under memory pressure, so I think my tests are inconclusive. Sincerely I'd just merge and keep an ear up for possible trouble...

[github-actions]

✅ This PR has been reviewed and approved — all set for merge!