Mylène Josserand
October 22, 2020
Share this post:
Reading time:
With version 5.9 of the Linux Kernel now released, it is time to, once again, review Collabora's contributions to this release which contains many improvements, primarily in hardware support, multimedia, graphics, testing and continuous contributions to other subsystems.
The importance of software maintenance has been highlighted in the last week with the discovery of a high-severity Bluetooth flaw. Whilst some reports have suggested that 5.9 contains the required fixes, many articles have been updated to reflect the fact that this is not the case. The required changes should be available as part of the 5.10 kernel when it is released and the kernel stable branches have picked them up. Many distributions are also now providing security releases covering this issue, we advise that you look out for (and apply) security fixes from your distribution of choice.
As usual, you can find more details of the changes that made it into v5.9 in the merge-window over at LWN: part 1 and part 2.
Collabora continues to be very active in the Linux kernel, authoring over 150 commits in this release. Here's a look at the changes contributed by Collaborans, including improvements and new features.
Thanks to Enric's work, we have added support for the krane-sku176, also known as the Lenovo IdeaPad Duet Chromebook. This device contains the MediaTek P60T SoC which contains 4x ARM Cortex-A73, 4x ARM Cortex-A53 and an integrated ARM Mali-G72 MP3 GPU. Although graphics support is not yet ready, we're working on DRM support for the next Kernel release. Hopefully it can be one of the first boards upstream to benefit from the open source Panfrost Gallium3D driver effort.
Helen and Dafna are actively contributing to the rkisp1 driver for camera image processing in the Rockchip platform. This driver is currently in the staging area. In this release, we contributed several cleanups, API improvements and bug fixes, especially in the part of the driver that generates statistics for user space to implement Image Enhancement algorithms such as 3A. Helen and Dafna are working on polishing the code to move it out of staging and become a stable driver.
Thanks to Ezequiel, work continues on the Multimedia subsystem, this time with janitorial changes, cleaning of the code and also making debugging easier for developers and users.
In addition to cleaning and minor polishing, the Hantro driver learned to reject unsupported bitstreams, by checking the Sequence Parameter Set as soon as the application sets it, allowing only 4:2:0 and 4:0:0 H.264 videos.
The biggest contribution was migrating drivers to use the lock-less path in the GEM (graphics buffers) management code. To further emphasize the issues with using the locked path (effectively a left-over from the DRM version of the BigKernelLock), Emil took the lead, improving the documentation and renaming the API.
Additionally, we also fixed a unrelated locking issue in the Rockchip driver, while Emil landed a mini-series for the DRM MIPI codebase, effectively eliminating dozens of memory allocations during bringup of DRM panels.
Thermal zone devices (sensors; see documentation) are important even in embedded systems which have no active cooling device like a fan. If the SoC is overheating it makes sense to temporarily reduce its performance, in turn reducing power dissipation, to give the processor a chance to dissipate the excess heat. These thermal zone devices can be either enabled or disabled. When they are enabled it is kernel's responsibility to handle them properly, when they are disabled then they shouldn't be touched by the kernel (it may be that they are being handled from user space). When thermal zone devices were disabled they were still polled by the kernel. Andrzej's work involves some preparatory clean-up, which in itself results in code reduction and ceases the polling of devices which are disabled.
Boris continues work on the conversion of more NAND controller drivers to the new "exec_op()" API. As explained in our 5.8 kernel blog post, this effort will help the MTD community to remove a deprecated API.
In 5.8, we improved the SBS battery driver but unfortunately adding PEC (packet error checking) had to be reverted. It depended on using a feature to read SMBus block data which is not provided by all I2C host controller drivers. The new implementation, added by Sebastian in 5.9, will disable PEC for SMBus block transfer operations if the controller does not support it. In addition, one more change has been added at the last moment to disable PEC for Chromebooks, since the I2C tunnel provided by the embedded controller does not seem to handle PEC properly. This is still being investigated and hopefully Chromebooks can also enable PEC in the future.
Kselftests are small regression tests that run in user space and exercise individual code paths in the kernel. They are widely used to check the integrity of kernel features and many kernel integration test systems, such as the 0-Day Service (https://01.org/lkp/documentation/0-day-test-service) and Linux Kernel Functional Testing (https://lkft.linaro.org/) run them everyday.
Ricardo has extended the collection of kselftests by adding a test suite for the mincore() system call. mincore() returns the status of the requested memory pages of a process, providing information about whether a set of pages is resident in RAM or not, thus letting user space know when certain memory accesses will cause a page fault. This can be useful for applications which keep tighter control of caches and memory management on their own for performance or safety reasons, such as database management systems. For example, to predict which memory accesses will take longer and then decide to prefetch memory pages ahead of time or to check if some critical data still remains in a buffer in memory and needs to be flushed back to disk.
The new kselftest checks that the system call works as documented and it's a way of catching potential new kernel bugs when they're introduced.
The futex() system call allows user space to implement synchronization mechanisms such as mutexes and semaphores for shared resources. The API lacks some useful features that can improve the performance on highly demanding applications, such as modern games. Modifying the current implementation is very dangerous, since it is heavily used, so the community decided to start anew. If you want to see the long term plans we have for this API, check out this LWN article Rethinking the futex API and stay tuned for this upcoming talk from André at Open Source Summit Europe: https://osseu2020.sched.com/event/eCBF
André created a documentation for the Multi-Queue Block IO Queueing Mechanism, explaining how it works for kernel developers (newbies or not) who would like to know more about the design. The design plays an important role for modern storage device performance, ensuring that we can take advantage of the parallelism offered by such hardware. You can read more about the mechanism here
To complete the work started by Sebastian in the last few kernel releases, in 5.9 we added default clock handling for the da7213 audio codec. This makes it possible to use the the generic simple-card driver when a fixed clock is used, rather than requiring a board specific one. Such a scenario is common on embedded boards and this reduces the effort required to support them.
In 5.9, Sebastian cleaned up the exc3000 touchscreen driver and added support for two new models using a very similar protocol: The EXC80H60 and EXC80H84. Both are already used in industrial devices. Adding support for these devices includes support for the optional reset GPIO and a method to query model info and fw_version via sysfs. The sysfs files can also be used to verify the I2C communication works as expected.
As a company focused on Open Source, we use many different Open Source projects.
We not only contribute to the Linux Kernel, but also contribute to many of the projects we use: adding documentation, testing, submitting improvements, cleanups and so on. Anything that can help to improve these projects. As developers, we can't unilaterally make the world a better place but we can make Open Source projects better and be kind and caring to all these communities.
Contributing is at the heart of Open Source projects and we are proud to have a purple one! 
Andrzej Pietrasiewicz (14):
André Almeida (6):
Boris Brezillon (16):
Dafna Hirschfeld (22):
Emil Velikov (43):
Enric Balletbo i Serra (18):
Ezequiel Garcia (13):
Gabriel Krisman Bertazi (1):
Guillaume Tucker (1):
Helen Koike (1):
Mylène Josserand (2):
Ricardo Cañuelo (6):
Sebastian Reichel (13):
Walter Lozano (1):
Enric Balletbo i Serra (17):
Sebastian Reichel (28):
Boris Brezillon (1):
Emil Velikov (1):
Helen Koike (1):
Sebastian Reichel (11):
Alexander A. Klimov (1):
Chunyan Zhang (1):
Crag Wang (1):
Dan Murphy (1):
Daniel González Cabanelas (1):
Dinghao Liu (1):
Emil Velikov (1):
Ian Ray (1):
Keyur Patel (1):
LH Lin (1):
Miquel Raynal (1):
Randy Dunlap (1):
Shunqian Zheng (1):
Wang Qing (1):
Boris Brezillon (31):
Emil Velikov (54):
Enric Balletbo i Serra (16):
Ezequiel Garcia (5):
Helen Koike (3):
Pekka Paalanen (2):
Sebastian Reichel (1):
Alyssa Rosenzweig (1):
Daniel Stone (1):
Emil Velikov (15):
Enric Balletbo i Serra (2):
Helen Koike (22):
Boris Brezillon (5):
Ezequiel Garcia (1):
Gabriel Krisman Bertazi (1):
Enric Balletbo i Serra (1):
15/11/2024
The Linux Foundation Member Summit is an opportune time to gather on the state of open source. Our talk will address the concerns and challenges…
14/11/2024
Today, we are delighted to announce a growing collaboration with MediaTek which will enable Collabora to introduce, improve, and maintain…
06/11/2024
Join us at electronica 2024! In partnership with Renesas, Collabora will be showcasing GStreamer open source AI video analytics on the Renesas…
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