We're hiring!

Kernel 5.8: Collabora's biggest & most significant contributions yet!

Dafna Hirschfeld avatar

Dafna Hirschfeld
August 05, 2020

Share this post:

Earlier this week, the Linux 5.8 kernel was released. It is one of the biggest releases of all time, as if developers started to code more during the recent lockdowns across the globe. As usual, you can the find the most important changes for this release in the always great LWN.net articles - part 1 and part 2.

According to Linus himself, the 5.8 release is big. While Collabora modestly contributed to this massive release, Linux 5.8 marks our biggest and most significant contributions yet. Everyone at Collabora has been impressed by the efforts put together by our kernel developers. Working directly upstream, contributing to the Linux kernel has long been a key objective of Collabora as an organization. Over the past decade we have been growing our participation in this essential effort that Linux is.

The ability for a relatively small software consultancy such as Collabora to contribute at this level demonstrates a fantastic improvement in vendors' mindset when it comes to working Open First (hence Collabora's tagline). Providing mainline support out-of-box as early as possible is really becoming a priority for all our customers and we appreciate them all the more for it.

So a big thank you to all our clients for the continued trust they are placing in Collabora. We look forward to continuing to contribute on their behalf of years to come.

Rockchip Contributions

Collabora is a very active contributor to Rockchip SoC which is used in devices such as Chromebooks, Laptops, several development boards and other devices. We've been contributing especially with graphics (Mali drivers, Panfrost) and multimedia. Here is the list of contributions to this platform:

DRM AFBC support for Rockchip

AFBC (Arm Frame Buffer Compression) is a hardware feature, available on several ARM SoCs, which reduces memory bandwidth used by compressing buffers sent to the display. This feature is very important for better power usage and allows user-space drivers to perform more efficient rendering by reducing the number of copies of the display buffer. For this version, Andrzej Pietrasiewicz added support for AFBC on Rockchip. See his blog post for detailed explanation.

Upstreaming Rockchip VDEC driver

Continuing our work on codec accelerators, Boris Brezillon contributed a series to upstream the Rockchip Video Decoder driver (rkvdec). Part of this work includes moving the H.264 DPB handling to the core, so it can be reused by other drivers.

This driver supports a Rockchip-specific codec IP block that can be found on Rockchip SoCs such as RK3399, RK3326 and PX30.

For now, only H.264 is supported in the rkvdec driver. Support for H.264 High-10 profile is currently being discussed by the community. In addition, VP9 and HEVC are planned to be added soon.

This accelerator driver implements the newly introduced Memory-to-memory Stateless Video Decoder Interface. Being a new interface, some support from the application side is needed. Nicolas Dufresne has recently added support for this in GStreamer. He recently presented the history of codecs support in the kernel at ELCE 2020.

Destaging progress of the Rockchip Camera drivers

The RK3399 Camera ISP driver (rkisp1) reached the mainline kernel's staging area in v5.6. With the goal to improve code quality and provide a stable driver for users, a continuing joint effort between Helen Koike and myself (Dafna Hirschfeld) is being made to destage the rkisp1 driver and the correspondent dphy driver phy-rockchip-dphy-rx0. For this kernel release, we moved a number of steps forward and are getting closer to the goal.

Some major patch(set)s:

The driver is already supported by the libcamera project, which enables applications to work on top of a myriad of different devices without worrying about the underlining hardware.

The rkisp1 driver exports an API which allows user space to implement image enhancement algorithms such as 3A. An Open Source implementation was recently added in libcamera for the Raspberry Pi. It will hopefully be made generic in the future, supporting Rockchip devices and several others.

DRM-master permissions rework

The DRM subsystem provides the means to manage and utilise display outputs (modeset) and rendering devices. To prevent malicious applications from changing a display's resolution, or disabling it all together, the concept of DRM_MASTER exists. This enables a single program to manage which processes are allowed to perform such tasks.

On platforms with systemd, the systemd-logind service is the one with the DRM_MASTER role, orchestrating which processes are allowed to do modeset operations. Yet there are cases where systemd isn't available, or the graphics server (Xorg or a Wayland compositor) cannot make use it for various reasons.

Emil Velikov reworked the SET/DROP_MASTER ioctls, allowing a user space process which has DRM_MASTER privilege to revoke its privilege and regain it easily. Previously, the program had to be run as root or have its setuid bit set (as seen with, Xorg and weston-launch) solely for that purpose. With the patch this artificial requirement has been lifted. Effectively, this makes Xorg work (instead of outright crashing) in a few corner-cases, while allowing distributions to drop the setuid flag from Xorg, weston-launch and others. This improves security by reducing the number of programs running with root privileges.

MTD subsys - converting legacy code to new API

Linux has long been known for its good support of old hardware, the policy being "if there is still one user caring about a specific hardware, support should not be dropped". This is a great thing for users, but it sometimes gets in the way of subsystems refactoring, leaving maintainers with two choices:

  1. Keep supporting the old APIs/interfaces, and add a new one on top;
  2. Patch drivers they don't know anything about, have no hardware to test on, and whose users are hard to find and/or slow to respond.

MTD is pretty old, and as a result, carries a lot of history with no less than three different interfaces exposed to drivers. This is the result of repeatedly going for option #1 without ever pushing driver maintainers to convert their drivers to the latest API. This policy has led to a situation where every evolution of the subsystem internals is a painful operation requiring extra care to not break one of the APIs. Sometimes the amount of work is so big that maintainers/developers just give up, thus leaving new features or potential performance improvement for new hardware unimplemented.

During the last release cycle Boris Brezillon tried to address that problem by converting some of these old drivers to the most recent API called exec_op. Given the number of drivers still using the old APIs, we still have a long way to go before things are unified, but any progress, even small, is better than the status-quo we were in.

Fix MediaTek no display bug

MediaTek has a family of SoCs that are used in (among other devices) several Chromebooks, such as the MT8173 used in the Lenovo N23 Chromebook and Acer Chromebook R13, plus the MT8183 in the Lenovo IdeaPad Duet Chromebook. We are working hard to have better upstream support for these devices, especially Enric Balletbo, who has been involved in kernel and Chromebook upstream support for a long time. The displays on MT8173 based devices were not functional when using the mainline kernel, this has been rectified with this kernel release.

The cause of this defect was a conflict between the clock and DRM drivers. He found that two different drivers - the MT8173 clocks controller driver, and the MT8173 DRM driver were using the same compatible string mediatek,mt8173-mmsys. This is a problem since in such cases only the first matched driver will be probed. The other one, in this case the DRM driver, never gets probed and so the display was not made available for use. In a collaborative effort between Enric Balletbo and the MediaTek SoC maintainer Matthias Brugger, a top level mmsys driver (Multi-Media subsystem) was introduced to register the clock and DRM drivers. See 1, 2.

Support for JPEGs decoding with optimized Huffman tables in the Coda driver (i.MX 6 platforms)

Better compression can be achieved with JPEG images when the Huffman tables they contain are optimized specifically for their individual content, however the Coda driver only supported decoding JPEGs which used standard / non-optimized tables. Adrian Ratiu, with the help of Andrzej Pietrasiewicz, added support to the Coda driver for decoding a wider range of JPEG images with optimized Huffman tables. The Chips&Media CODA960 video decoder is most notably used on NXP i.MX 6 series of SoCs.

Deadlock fix on SCSI subsystem

In a continuation of the work we have been doing for several kernel releases now, as part of the effort to improve the iSCSI driver, Gabriel Krisman Bertazi authored a fix for a deadlock issue that plagued iSCSI drivers in low memory conditions. This bug, which could be triggered by a memory reclaim, stopped the iSCSI daemon from recovering the device and completing the reclaim. This could, in effect, deadlock the system. Gabriel's solution prevents the issue from happening, while hardening the iSCSI driver against several other possible issues that arise from all the iSCSI commands sharing the same execution lock.

Improve Smart Battery System (SBS) support on the power-supply subsystem

Smart Battery System (SBS) is a specification for managing a 'smart battery'. Such batteries can be found on the Novena board, and several Chroombook devices such as Scarlet Chromebooks, veyron-jerry and others. Sebastian Reichel sent a patch set to improve the SBS battery driver. A lot more information (e.g. manufacturer date, max. charge current/voltage requested by battery, ...) from the smart battery controller is now exposed to user space via sysfs and uevents variables 1. It is interesting to mention that the number of uevents variables passed the maximum of 32 defined, and so it had to be updated to 64. Two patches from the series, adding Packet Error and Correction (PEC) support, didn't make it into the release and instead are expected for 5.9.

printk documentation improvement

Kernel developers use the printk function as their primary tool for logging. It is such a fundamental part of the kernel that it deserved some documentation improvements. Ricardo Cañuelo enhanced the documentation of printk and the pr_* macros with this patch.

Debian support on i.MX 6

Supporting Linux distributions such as Debian and its derivatives is one of the many ways Collabora fulfills its mission and helps Open Source end users. Debian's armhf kernel needs to support a variety of different boards so it doesn't use the standard Linux defconfigs. With the Debian's customized defconfig for armhf, the cpufreq failed to probe on i.MX 6 boards. A set of patches were developed to Linux mainline and Linux Debian, the first of them, authored by Walter Lozano is already included in this release.

Continuous contributions with fixes, cleanups, documentation, reviews and tests everywhere

While working with several Open Source projects, very often our Engineers stumble upon minor issues or things worthy improving such as documentation or cleanups.

We try to contribute upstream on a continuous basis. For 5.8 we had various contributions to areas including fixes to the V4L2 core, Device Mapping, I3C, power, clocks , MTD, ASoC and more.

We enjoy and take great pride in being an active part of the community, helping and improving the projects we use. This also includes providing help with reviewing and testing patches from other community members.

Below is a full list of contributions for the 5.8 release, including suggestions, testing and reviews, as recorded in the git commit history:


Adrian Ratiu:

Andrzej Pietrasiewicz:

André Almeida:

Boris Brezillon:

Dafna Hirschfeld:

Emil Velikov:

Enric Balletbo i Serra:

Ezequiel Garcia:

Gabriel Krisman Bertazi:

Guillaume Tucker:

Helen Koike:

Ricardo Cañuelo:

Sebastian Reichel:

Walter Lozano:

Maintainer Committed:

Boris Brezillon:

Enric Balletbo i Serra:

Sebastian Reichel:


Enric Balletbo i Serra:

Gabriel Krisman Bertazi:

Helen Koike:

Sebastian Reichel:

On behalf of:

Andy Shevchenko:


Christophe JAILLET:

Dan Carpenter:

Dan Murphy:

Hongbo Yao:

Jason Yan:

Jean-Francois Dagenais:

Kejia Hu:

Khazhismel Kumykov:

Mathew King:

Matthias Brugger:

Matti Vaittinen:

Michał Mirosław:

Niklas Söderlund:

Qiushi Wu:

Rafael Gandolfi:

Samuel Zou:

Sebastian Reichel:

Serge Semin:

Tang Bin:

Tobias Schramm:


Boris Brezillon:

Daniel Stone:

Emil Velikov:

Enric Balletbo i Serra:

Ezequiel Garcia:

Helen Koike:

Sebastian Reichel:


Andrzej Pietrasiewicz:

Helen Koike:


Enric Balletbo i Serra:

Nicolas Dufresne:

Sebastian Reichel:


Gabriel Krisman Bertazi:

Nicolas Dufresne:


Add a Comment

Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest News & Events

Kernel 5.12: Working to close the gap


With their latest contributions all around the kernel, notably to the Video4Linux APIs and hardware enablement, Collaborans continue to…

PanVk: An Open Source Vulkan driver for Arm Mali Midgard and Bifrost GPUs


The Panfrost project started as a reverse engineering effort to understand Arm Mali Midgard and Bifrost GPU internals. With the driver getting…

Linaro Virtual Connect - Spring 2021


Join us this week at the Spring edition of Linaro Virtual Connect, as we discuss bringing stateless video decoding support to Linux, and…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2021. All rights reserved. Privacy Notice. Sitemap.

Collabora Limited is registered in England and Wales. Company Registration number: 5513718. Registered office: The Platinum Building, St John's Innovation Park, Cambridge, CB4 0DS, United Kingdom. VAT number: 874 1630 19.