A new kernel version is out and, as usual, Collabora's engineers have contributed changes spanning different domains of expertise. With more SoC support, a new V4L2 driver and a new dma-buf locking convention among its contributions, Collabora was one of the most active employers for this latest kernel development cycle.

After basic infrastructure for Rust drivers landed in the previous release, kernel 6.2 brings new changes that continue to improve Rust support. Driver authors notably gained access to the new #[vtable] macro, which makes it easier to both declare and implement structs of function pointers - also known generically as 'ops' - as Rust traits. This macro provides a Trait::HAS_* constant for each of the trait's functions that are set when drivers actually provide a implementation, thus making it easier to set the function pointers accordingly in the C data structures. The rest of the pr_ macros were implemented as well, which now makes it possible to call the likes of pr_err!() and other previously unsupported friends from Rust code, enhancing logging for Rust drivers.

Also noteworthy is the new and shiny 'accel' subsystem, the origins of which have been brewing for quite some time on the kernel mailing lists. The accel subsystem is dedicated to compute accelerators which can either be standalone ASICs or IP blocks within SoCs/GPUs. The accel core code remains inside the DRM subsystem, and accel devices will be a new type of DRM device. This should facilitate the sharing of code and developer expertise between GPUs and compute devices, as well as provide a more uniform interface to common userspace layers such as PyTorch and TensorFlow.

Here is a closer look at Collabora's contributions for this cycle:

SoC Support

Support for RK3588 upstream is ongoing and this cycle has seen clock and reset unit driver patches by Sebastian Reichel, which completes the basic boot support for that chip apart from the initial device-tree support queued for 6.3. This SoC is key for our multimedia upstream work, as Benjamin Gaignard is working on the V4L2 driver support for the AV1 decoder in the chip, bringing the total of drivers using the tentative AV1 stateless uAPI developed by Collabora to two.

As part of the continued improvement of support for MediaTek SoCs, Nícolas F. R. A. Prado fixed the sound card drivers which were not not being automatically loaded as modules on several MediaTek platforms, and fixed devicetree bindings for RT5682 and RT5682s audio codecs. Several configurations were also enabled on the ARM64 defconfig to get full functionality for mt8183-juniper-jacuzzi devices.

AngeloGioacchino Del Regno added initial support for the MediaTek-powered Sony Xperia M5 smartphone. The device now boots under Linux and a serial connection can be established. This is a result of his work to support the device's underlying SoC, the MT6795. By the same token, there's now support for the Sony Xperia X and X Compact smartphones, which use Qualcomm's Snapdragon 650 (MSM8956) chip. Some other notable work by Angelo this cycle includes device tree and clock cleanups for Mediatek devices, some devicetree patches that increase scheduler performance for the MediaTek's MT8195 SoC and L2 cache power management support for the Snapdragon 650 (MSM8956) and Snapdragon 652 (MSM8976) chips.

Cristian Ciocaltea enabled initial support for the StarFive VisionFive V1 SBC, built around the JH7100 SoC, and claimed to be the world's first generation of affordable RISC-V boards designed to run Linux. There is currently no network or SD card support, but these are some areas we are looking to further improve.

Multimedia

The V4L2 subsystem gained a new virtual driver in 6.2: visl is a virtual stateless decoder driver written by Daniel Almeida for the purposes of aiding V4L2 stateless decoding uAPI development. In a nutshell, userspace applications can use visl to run a decoding loop even when no hardware is available or when the kernel uAPI for the codec has not been upstreamed yet. This can reveal bugs at an early stage. One can also use visl to trace the submitted V4L2 controls via ftrace, or to dump the VB2 buffers through debugfs. The driver is capable of producing capture buffers with various debug information printed to it using V4L2's test pattern generator.

DMA-BUF

In the past, there was no locking convention for dma-buf exporters and importers. When both dma-buf exporter and importer drivers decided to acquire the same nested dma-buf reservation lock, a deadlock happened in kernel. The v6.2 got a new dma-buf locking convention, explicitly telling when exporter and importer shall take the lock and when not. The locking convention was added by Dmitry Osipenko, he also moved all the kernel drivers using dma-buf to the new locking convention. This work allows kernel subsystems to start managing dma-buf locking for the drivers, since now the locking rules are strictly specified. The GPU subsystem core code was already prepared in v6.2 to the new locking convention. In the future this will allow all DRM drivers to transition to using a common reservation GEM lock, which is a longstanding item in the GPU subsystem TODO list.

Below is a full list of contributions made by Collaborans for the 6.2 release, as recorded in the git commit history:

Related Posts

Kernel 6.1: Multi-generational improvements

Kernel 6.0: Start of a new series and dawn of Rust

Kernel 5.19: Probably the final release of the 5.x series

Related Posts

Kernel 6.1: Multi-generational improvements

Kernel 6.0: Start of a new series and dawn of Rust

Kernel 5.19: Probably the final release of the 5.x series