Hardware Support

By Corbet - January 26, 2009 - 12:11pm

1 NVidia graphics adapters
2 AMD/ATI graphics adapters
3 The TTM memory manager
4 The GEM memory manager
5 Atheros chipsets
6 User-space drivers
7 Power management

NVidia graphics adapters

While NVidia provides a binary-only driver for its hardware, many distributors refuse to ship it for all of the usual reasons. The Nouveau project is working on a set of free drivers which can be used instead. It is also important to remember that there is an open source driver developed by the community and very well maintained which only does 2D rendering.

Forecast: this project is making rapid progress, and has also, recently, been the recipient of some significant funds by way of a donation campaign. The Fedora distribution has begun distributing the nouveau driver on an experimental basis. It will probably be some months yet, however, before the driver reaches production quality.

For more information:

The state of the Nouveau project (January, 2007)

AMD/ATI graphics adapters

ATI adaptors have suffered from a lack of vendor support for many years; that situation changed in 2007, though, when ATI began to release documentation and support the development community.

Forecast: Work continues toward the goal of getting newer-generation ATI chipsets working with the Linux kernel; by the end of 2009, this problem should be mostly solved.

The TTM memory manager

Modern graphical processing units (GPUs) have complex memory management needs which, to date, have been handled in a substandard way through a complicated combination of kernel code, X window system server code, and proprietary modules. That situation is likely to improve greatly for a number of reasons, one of which being the "Translation Table Manager" memory management code. TTM is a from-the-beginning attempt to nail down and properly support the memory-management needs of graphics adapters which should result in cleaner and more robust support for most devices.

Forecast: an early TTM implementation was proposed for merger in 2.6.25, but did not get in. TTM was replaced by GEM for use with the Intel graphics drivers, but it is still an important component of the drivers for ATI hardware. A version of TTM was finally merged into the mainline for 2.6.31.

For more information:

Memory management for graphics processors (November, 2007)

The GEM memory manager

Developers working with TTM found a number of difficulties with that API; it did not fit the task as well as had been hoped. Eventually, some developers at Intel gave up and implemented their own memory manager for graphical processing units. The Graphics Execution Manager (GEM) is now being used for the development of 3D technology for Intel chipsets, and it may be adopted by some of the other drivers as well.

Forecast: GEM (with support in the Intel i915 driver) was merged for 2.6.28. The addition of the kernel mode setting support in 2.6.29 signals the beginning of the end of the long process of getting top-quality 3D graphics support into Linux.

For more information:

GEM v. TTM (May, 2008)

Atheros chipsets

The Atheros 5k chipsets found in many laptops and wireless routers has long lacked a free driver for Linux. OpenBSD has such a driver, but there have been legal concerns about its provenance which prevented it from being merged into the Linux kernel. Those concerns appear to have been resolved after a series of audits by the Software Freedom Law Center, clearing the path for the ath5k driver to be merged. As a result, ath5k was merged for 2.6.25.

Since then, Atheros has adopted a new, more open policy and hired some developers from the community. The company contributed the new "ath9k" driver for 802.11n hardware; that driver has been merged for 2.6.27. Atheros is quickly headed toward top-quality support in the mainline Linux kernel.

Forecast: At this point, support for most Atheros chipsets appears to be solid in mainline kernels.

For more information:

Toward a free Atheros driver (November, 2006)
The case of the unwelcome attribution (September, 2007)

User-space drivers

For various reasons, some developers (and vendors) prefer to implement device drivers in user space. These reasons include ease of development and a desire to avoid the GPL licensing required for in-kernel code. Various frameworks exist for the implementation of user-space drivers, most of which have design problems which can put system stability at risk. Over the last year or so, some core kernel developers have been working toward the implementation of a standard user-space driver framework which would unify user-space driver efforts and make the resulting kernels safer.

Forecast: the UIO patches were merged for 2.6.23.

For more information:

User-space device drivers (January, 2004; this code seems to be abandoned)
Support for drivers in user space (September, 2006]
UIO: user-space drivers (May, 2007)

Power Management

Achieving proper power management in Linux has been a multi-year effort. For a long time, this work consisted mainly of (1) properly supporting ACPI, and (2) getting suspend and hibernate working properly. Those tasks are mostly done, so there is an increasing amount of emphasis being placed on runtime power management - minimizing power use in a running system.

Forecast: the power management core (written primarily by Rafael Wysocki) has been through several review cycles and appears to be poised for merger into 2.6.32. That code will give Linux much of the infrastructure it needs to do proper runtime power management. Actually making use of that core requires further work, though. Patches are circulating, but that code will not be ready until 2.6.33 at the earliest.

For more information: