Helen Koike
March 31, 2020
Share this post:
Reading time:
The Linux kernel development process has always prided itself in being a distributed effort, with contributions coming in from all parts of the world. Long before video conferencing became the new normal, kernel developers were collaborating remotely, using tools like IRC and mailing lists to successfully work together. It comes to no surprise, then, that despite the challenges presented by COVID-19, kernel development has continued.
Of course, the merge window for kernel 5.6 closed before most countries had implemented any COVID-19 countermeasures. Since then, most of us have been, and continue to be, affected by COVID-19 in one way or another. And while 5.7 already promises to be another great release, what matters most right now is that everyone in the community stays safe. Take care of yourselves and those around you!
That being said, kernel 5.6 was released over the weekend, so let's take a look at the various projects Collaborans have been involved in, and the progress made. As usual, you can learn more about this release in thise LWN posts: part 1, part 2, and development statistics.
The RK3399 SoC can be found in devices such as Scarlet Chromebooks, RockPi boards and Pinebook Pro laptops.
We have been very active contributing with upstreaming Rockchip's graphics drivers (not only in the kernel side, but userspace side as well with Panfrost, and also Video codecs (see about Hantro below).
And now, we are also contributing in the multimedia side for Rockchip SoCs, more specifically the Image Signal Processing Unit, which enables Camera sensors to be used with mainline kernel for RK3399 chips.
The driver was originally written by Rockchip developers and posted to the media mailing list for the first time in November 2017 as an RFC. Collabora picked it up from v6 (submitted on March 2018 by Rockchip).
We did a major refactor of the code, and the rkisp1 is finally upstream in v5.6, with 9k lines of code added to drivers/staging. You can check the full merged series here.
We also contributed with the libcamera.org project, by updating support for the upstream rkisp1 driver. Libcamera's patches are merged and can already be used with RK3399.
We plan to continue to maintain and improve this driver, and we are currently working on moving it out of staging.
The Hantro VPU allows video decoding and encoding acceleration from/to various formats, such as JPEG, H.264, VP8 and VP9.
This hardware unit is present in several Rockchip SoCs, such as RK3399, RK3288, RK3328 (which are already supported by the current kernel driver), PX30 and some others. It's also present in NXP SoCs, such as i.MX8MQ whose, support was added by Philipp Zabel from Pengutronix and is expected to be included in the kernel v5.7.
The upstream driver was introduced by Collabora in the kernel v5.0 supporting only JPEG encoding acceleration.
With our contributions, the driver currently supports JPEG, VP8, H.264 and several post-processing transformations.
Along with a number of cleanups and fixes, in the v5.6 development cycle we contributed support for color conversion via a post-processor hardware block (IPP) to expose the YUY2 format in addition to NV12. We plan to continue to maintaining and improving this driver, with a focus on encoding.
Today, a DRM driver can use an existing i2c adapter exposed by the system and can be used by a single or multiple drm connectors. To make this information easily accessible, drivers create a symbolic link in the connector's sysfs directory, e.g.:
ls -l /sys/class/drm/card0-HDMI-A-1/ddc
lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
-> ../../../../soc/13880000.i2c/i2c-2
This allows the user to determine that their card0-HDMI-A-1 connection uses i2c-2, and can perform operations on i2c-2 knowing which DRM connector it refers to.
This feature was introduced by Collabora for a number of drivers in kernel v5.4.
For the v5.6 release, we extended this feature to other drivers.
A display pipeline is a chain of components ('crtc -> encoder -> [bridge x n ] -> connector -> display' ) where each element must know the pixel stream format sent by the previous element in the chain.
Until now, bridges were lacking support for bus format negotiation, which was acceptable, either because the bridge only accepts one format, or because the format hardcoded in the driver was the one used by everyone.
With bridge drivers being re-used in various setups, the "one setting fits all cases" approach no longer works, hence our decision to contribute support for bus format negotiation between bridge elements.
The DRM authentication mechanism allows a userspace arbitrator to manage which DRM clients (applications) are allowed to do rendering operations.
This is required to enforce security in userspace, as DRM drivers without clear client isolation might allow one client to read other clients' data. An arbitrator has to explicitly acknowledge the client before it can be used.
In v5.6, we contributed a patchset to remove the DRM_AUTH notation, as the driver recently added robust client isolation. The ultimate goal is to keep userspace simple and obvious, while allowing for the clean implementation of EGL_MESA_platform_surfaceless and other functionality.
More details will follow in a separate blog post, coming shortly.
Cros ECs (embedded controllers) are an essential hardware module in Chromebooks, responsible for handling several parts of the hardware the operating system doesn't control.
We are actively working on the maintenance and support for these devices, with the goal to enable Chromebooks to run on top of mainline kernel.
For v5.6, we fixed a deadlock in the voltage regulator driver, and performed several other cleanups.
iSCSI is a protocol for accessing SCSI devices over a network, mainly used in datacenters and very large cloud server infrastructures. Lately, Collabora, in association with Google, made an effort in improving its support in the kernel.
In particular, in v5.6, we solved a bug in drivers/base, which causing an inconsistent state in the iSCSI driver, resulting in the iSCSI connection hanging and not being able to be used or removed by userspace.
Multipath is a device map target that abstracts multiple ways (paths) to reach a storage device. It is used for many reasons, including redundancy to protect against a broken network link. It is particularly important in large data centers and cloud providers
The use of this feature requires a daemon in userspace that performs path management, configures policy and most importantly, reinstates paths when it comes back to life (for example, when the broken node is replaced).
In v5.6, we contributed a timeout mechanism, to prevent the kernel from waiting forever and hanging IO operations, in case the userspace daemon is not responding for some reason. This contributes to the stability and reliability of the multipath feature in Linux.
Distributed Switch Architecture (DSA) is the generic switch chip infrastructure for Linux. It has backend drivers for various switch ICs, and provides common infrastructure to make each port on a switch chip appear as regular NICs. It was specifically written to handle switch chips that can communicate to each other over specially formatted network packets, allowing complex cross device setups.
In response to a customer request to find a way to handle network storms while also ensuring critical data delivery, we added support for some features of Marvell DSA switch chips to enable better prioritization of those critical data packets.
While the main set of kernel patches was refuted in favour of a new userland utility interface within tc, correct handling for pause packets from intel igb was accepted as a needed fix.
The majority of Device Tree bindings are currently in txt format which doesn't allow for automated verification. As a result there is a major effort of converting them to YAML schemas.
Collabora has been contributing to this effort, and we intend to keep working on this systematically.
Several Collabora's engineers maintain drivers or even subsystems in the kernel. This requires reviewing, testing and applying patches.
For v5.6 in particular, we were involved in the i3c , DRM, media, power supply and Cros EC subsystems.
Thanks to all our maintainers for their dedication and hard work.
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, with the goal to improve the project and be part of the community, and this also includes providing help with reviewing and testing patches from other community members.
Andrzej Pietrasiewicz:
André Almeida:
Boris Brezillon:
Dafna Hirschfeld:
Emil Velikov:
Enric Balletbo i Serra:
Ezequiel Garcia:
Gabriel Krisman Bertazi:
Helen Koike:
Robert Beckett:
Tomeu Vizoso:
Alyssas Rosenzweig:
Andrzej Pietrasiewicz:
Boris Brezillon:
Emil Velikov:
Enric Balletbo i Serra:
Ezequiel Garcia:
Sebastian Reichel:
Tomeu Vizoso:
Alyssa Rosenzweig:
Boris Brezillon:
Enric Balletbo i Serra:
Helen Koike:
Sebastian Reichel:
Boris Brezillon:
Enric Balletbo i Serra:
Gabriel Krisman Bertazi:
Gustavo Padovan:
Helen Koike:
Sebastian Reichel:
Antonio Caggiano:
Enric Balletbo i Serra:
Nicolas Dufresne:
Sebastian Reichel:
20/12/2024
The Rockchip RK3588 upstream support has progressed a lot over the last few years. As 2024 comes to a close, it is a great time to have…
09/12/2024
Collabora will be at NeurIPs this week to dive into the latest academic findings in machine learning and research advancements that are…
05/12/2024
Now based on Debian Bookworm, Apertis is a collaborative OS platform that includes an operating system, but also tools and cloud services…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (0)
Add a Comment