Initial mainline video capture and camera support for Rockchip RK3588
collabora.com
collabora.com
Intel's IPU6 has been a ~4 year travail to get going (thankfully IPU7 landed fairly quickly however!) https://www.phoronix.com/news/Intel-IPU6-Camera-Challenge-25 https://www.phoronix.com/news/Intel-IPU7-Linux-6.17
AMD similarly has only just gotten the Strix Halo ISP near working: https://www.phoronix.com/news/AMD-ISP4-For-Linux-7.2
The whole video world seems like a nightmare. Difficult world of hardware. Just the worst Intellectual Property hostage taking banditry from awful awful valent legally predatory people everywhere, a dark forest ready to leap out of the dark and attack you if you dare use a computing to deal in bits that represent moving images.
Has this situation improved?
The work required to get this one piece into mainline over 5-6 years reveals why most chip vendors aren’t aiming for mainline by default:
> A few iterations of the rkcif driver later, the basic driver providing support for the PX30 VIP and the RK3568 VICAP was accepted (October 2025). After more than five years of development, including 25 iterations and three renamings, this was a major milestone. On the other hand, there was still a lot to do, of course. For instance, the Rockchip MIPI CSI-2 receiver unit that is coupled closely to the VICAP required a mainline driver as well.
It’s never as simple as submitting existing work upstream and making a few changes. It takes a lot of development and a willingness to rewrite everything, possibly multiple times, to track the goals of upstream.
after working professionally with their stuff I'm really not a fan of Rockchip
Is that not enough of a reason?
There are chip providers that put more emphasis on mainline support but even those aren’t fully mainlined and their chips are generally much more expensive.
> It’s never as simple as submitting existing work upstream and making a few changes.
If they had started by working with upstream, then they wouldn't have to go through unnecessary revisions trying to adapt the thing they already wrote.
They were experienced with working with upstream and it still took them that long to do it.
LOL. It simply doesn't work that way.
It's all about time to market. A BSP with a custom fork of the Linux kernel that barely works can be done concurrent with hardware development.
But if you say as a manufacturer, we'll first get it upstream-supported by Linux and then release the hardware... by the time the quality is good enough for the proper upstream Linux kernel, the hardware is multiple generations outdated.
And often enough, the software side is an afterthought. The BSP teams get thrown the hardware and told to "make it work", which all too often means having to do horrible hacks to the Linux kernel that would be completely unacceptable upstream. Even if they'd hire Greg KH himself, the fundamental problem remains that the BSP teams aren't asked if the HW designers can make the life of the BSP team easier.
The one notable exception to this unholy mess, however, is Apple. And that is why Apple hardware seamlessly integrates within the ecosystem, why it is so performant and why it is so energy efficient.
Software exists from the vendor, but it’s not open source and/or not part of Linux mainline.
Hence the effort to develop an open source (and mainlined) alternative.
Whether this is a good use of effort and/or whether you believe the vendor should be doing the Linux development or not, and/or whether they should open-source their proprietary drivers, will depend on your personal views.
It's because of the Raspberry Pi foundation we have this perception that embedded Arm chips are like general purpose desktop computers that run Linux desktops. The original Pi SoC was designed for TV set top boxes, STB's hence the loopy booting from GPU which was likely part of some obfuscated secure boot chain to thwart STB hackers. The Pi was a throw away hobby toy based on a chip Broadcom was going to scrap so they got a dumpster deal. It took a lot of effort for the community to fully reverse the Broadcom SoC and bring all the Pi hardware to mainline.
Desktop computer was a reach. Even for BeagleBone.
I am surprised RK3566 and RK3568 still don't have good UEFI-EDK2 support.
RK3588 has great UEFI-EDK2 support. I wish somebody would backport RK356x and RK3399 boards....
The pace of development is too fast. We don't need more aarch64 CPU but better support. RISC-V adds to the mayhem.
Like we need that...
The Open Source Hardware Dream.
So it might be too late as 3688 will be too hot...
Just like routers get dd-wrt when sold out!
Its always IP. Afair even Raspberry Pi didnt open ISP, and support for MIPI took yeaaaaars.
I hope that the more SoCs get mainline V4L2, the more likely the future SoCs are going to be to use it instead of doing something non-standard and awful.