Texas Instruments (TI) supplies chips to roughly 100,000 customers around the world, with product life cycles measured in years and decades. These long-tail chips include TI’s DaVinci SoC which is particularly popular in IP network cameras, video communications, and portable media players, and also include the OMAP SoC, featured heavily on single-board computer development platforms such as the BeagleBone and the PandaBoard.

A large portion of the devices containing these SoCs will run Linux, and that makes Linux kernel support a priority. However, because the Linux kernel is routinely updated with bug fixes and new features, ensuring on-going support for TI’s SoCs requires constant development effort to keep out-of-tree patches up to date.

Luckily, there’s a way to lessen the load: by keeping TI’s SoCs supported in the upstream kernel.

The Business Case for Upstreaming

The biggest headache with supporting long-tail chips for years with out-of-tree patches is that it requires forward porting those patches to newer Long-Term Support (LTS) kernel releases. It’s a huge investment of engineering time, not just to update the patches, but also because every time that happens tests need to be run to check that no bugs have been introduced.

Merging TI SoC support upstream doesn’t completely eliminate this problem but does make it much more manageable. Instead of having to deal with migrating patches to a brand new LTS version, code can be updated piecemeal, as and when things like new APIs and bug fixes are merged.

And this is where BayLibre comes in. We’ve been working on the upstream kernel to ensure that, not only does every release work on the DaVinci and OMAP SoCs, but that those SoCs also take advantage of the latest bug fixes and features.

Our Upstream Contributions

The majority of our work has been on the DaVinci SoC. In the last two years, we’ve contributed 99 patches to the Linux kernel. Bartosz Golaszewski and Kevin Hilman added support to the Video Port Interface (VPIF) driver to allow it to be initialised with device tree (DT) bindings; for many SoCs, DT bindings are the preferred way to describe hardware characteristics. In addition, Bartosz and Kevin added support for raw image capture with sensors supporting the 10-bit SGRBG10 format. Along the way, the guys cleaned up a slew of hard-coded assumptions about image formats in the VPIF driver that came from it only previously being tested with a single sensor that supported a single 8-bit format.

We’ve also worked on performance improvements by taking advantage of the DMA hardware in DaVinci SoCs. Fabian Parent enabled DMA channels for the SPI driver so that it correctly maps data buffers passed from the MTD layer. And Alex Baildon made CCPI DMA work on the DA850/OMAP-L138/AM18xx platforms to improve the performance of USB. Both of these efforts reduce the work the CPU has to do when transferring data to and from devices, which means a more stable workload.

Lastly, we helped with a large effort to move DaVinci to the common clock framework (CCF). This work involved rewriting hand-crafted clock drivers to use the CCF. A huge part of the migration to the CCF was done by an independent developer, David Lechner, and he deserves special mention. From BayLibre, Bartosz modified some of the clock driver consumers, including updating the remoteproc driver to use the reset framework and deduplicated code that existed in both the platform-specific support and the generic aemif driver.

Plans for 2019

As we said at the beginning of this post, maintaining support upstream requires on-going effort and we have further plans for the TI SoC code in 2019. We’ll be creating a proper clocksource driver to tidy up the random bits in the platform support, enabling support for sparse interrupts (critical for supporting some hardware), and eventually building DaVinci as part of the multi_v5_defconfig kernel config.