As anticipated, a number of Android specific drivers have now entered the staging area, including some drivers previously merged into the staging area, but later removed as because they were not being maintained (1, 2, 3, 4, 5 and others). These changes mean that the kernel should now contain everything required to boot an Android userland, but is still missing wake lock code or equivalent, which is required to achieve decent battery life.
John Stultz has put together some background information on the status of integration of Android-specific changes in this LWN.net article, in which he reports on a meeting of the Android mainlining interest group.
A rudimentary DRM/KMS driver for Texas Instruments' OMAP platform has been merged into the staging area. Among the code deleted from the staging area by kernel developers is the code for file system pohmelfs, as its inventor is now working on a newly developed successor (1, 2).
The maintainer of the DRM subsystem has merged a DMA buffer sharing mechanism (dma_buf) framework into the kernel. It should allow multiple drivers to share a DMA buffer (1, documentation). This infrastructure, which is not currently used by any drivers, could be useful in embedded systems, enabling the kernel to, for example, forward image data collected by a camera to both a video encoder and to graphics hardware for display without having to duplicate the image data in memory. It should also allow a dedicated graphics chip to reduce overhead in outputting images calculated by the graphics chip via chipset and processor graphics. This could, for example, prove useful for supporting NVIDIA's Optimus technology, which is found in a not insignificant proportion of modern laptops. Discussions on whether proprietary drivers such as NVIDIA's will be permitted to use DMA buffer sharing are ongoing. One month into this discussion, Rob Clark, one of the main developers behind the code, has expressed the view that they should.
Background information on the dma_buf infrastructure can be found in this LWN.net article and in two videos â the first is from a presentation at the Embedded Linux Conference (ELC), in which Rob Clark describes the framework; the second is of a Fosdem presentation in which Daniel Vetter looks into some details of the technology.
- The kernel audio driver developed as part of the Alsa project is able to transfer data sent to the hardware for output in compressed form (1, documentation). The driver for Cirrus HDA codecs now supports the Cirrus Logic 4213. Other changes include further revisions aimed at making the driver rely less on accessing quirks stored in the kernel to correctly configure Realtek audio chips.
- Linux 3.3 also sees the addition of code for the Terratec H7 tuner. Work on merging a driver for this USB box, which allows users to watch digital terrestrial and cable TV and contains a CI module, is ongoing. There have also been various changes and additions to the frontend and tuner driver APIs. Details can be found in the minor gems section on the next page or in an email from media subsystem maintainer Mauro Carvalho Chehab.
- The driver for ALPS touchpads now supports touchpads that use versions 3 and 4 of an ALPS protocol. The kernel has previously used its PS/2 compatibility mode, which emulates a double-click function. This function may now need to be activated explicitly.
- Hardware monitoring driver it87 now supports the IT8728F component used on some motherboards.
- System devices (sysdev) will no longer be subject to special treatment when programming kernel drivers (1, 2). Drivers for platform-specific devices will in future have to make do with regular interfaces and bus functions.
- The new charger manager (documentation) adds functions to the kernel for charging batteries on devices on which the charging process needs to be monitored and managed by software.
The "Coming in 3.3" series
The Kernel Log can already share an overview of the most important new features of Linux 3.3, expected in mid-March, since the kernel hackers have integrated all the major changes in the first two weeks of development. Hence the 3.3 kernel is currently in its stabilisation phase, in which the kernel developers avoid big changes and focus on fixing bugs.
The articles on the changes and additions will discuss the kernel's various functional areas one by one: