• Support for register caches – Dimitris Papastamos ported his code for rbtree and LZO caches from ASoC over to regmap. This makes it easy for drivers to cache the current values of the device registers, improving performance by eliminating reads when doing read/modify/write cycles and providing functions to restore the register cache when resuming from power down. An indexed cache type was also added but this will be removed in 3.3 as it offers no real advantage over rbtree.
• Support for a wider range of SPI register transfer formats contributed by Lars-Peter Clausen.
• Tracepoints supporting both register access logging and monitoring of the time spent on register I/O operations.
• Register map dumps via debugfs to help provide diagnostic information during development.

switch (thing) {
case VALUE:
        /* Stuff */
        break;
case BAR:
        /* Nonsense */
        break;
default:
        /* Whatever */
        break;
}

with if statements instead:

if (thing == VALUE) {
        /* Stuff */
} else if (thing == BAR) {
        /* Nonsense */
} else {
        /* Whatever */
}

(where stuff, nonsense and whatever are usually a bit larger). I really don’t understand where this has come from – the if based form isn’t nearly so idiomatic for selecting between a range of values and this seems to have come from nowhere pretty much. Is there some code base out there where this is common practice or something?

The version of this API in version 3.1 is very simple, just factoring out the simplest level of physical I/O from the devices. Devices register with the regmap API by providing a struct regmap_config (which currently only allows the sizes of the register addresses and values to be specified) and the bus-specific structure to it. They can then use simple read and write operations on the device:

int regmap_read(struct regmap *map, unsigned int reg, unsigned int *val);
int regmap_write(struct regmap *map, unsigned int reg, unsigned int val);

The API handles everything to do with formatting the data for transmission and parsing data coming back from the device. Block functions are also provided to allow multiple registers to be read or written simultaneously. Even with this basic level of support we end up saving quite a bit of code as drivers are converted to use the API.

The changes sitting in -next for version 3.2 take this a step further, adding support for more variations on SPI registers, a debugfs interface for dumping the device registers, register cache support courtesy of my colleague Dimitris Papastamos and trace points for dynamic instrumentation of the system.

• Support DAPM controls that affect multiple paths – mainly used for single register bits that affect the routing for a stereo pair of audio streams.
• Simplifications in the cache infrastructure.
• New machine drivers for iPAQ hx4700, PCM hookup for WM8580 on Samsung reference platforms and Wolfson Speyside, plus a generalization of the Tegra Harmony driver to cover a range of other platforms based off a similar reference design.
• New CODEC drivers for AK4641, MAX98095 and WM8996.

With kernel development the approach is much more to make sure that the core can cope with whatever needs expressing. It’s not always done in the core – for example, sometimes the issue is due to unusually limited hardware and very likely to never come up again – but it’s very unusual to see code merged that doesn’t at least fit in with the design of the subsystem.

This post is inspired by a brief exchange with Thomas Gleixner on linux-kernel who articulated the advantages of doing things this way very well:

 - It's usually simpler and faster as the core code has all the
   necessary information. So that's even an argument which managers
   might understand.

 - Such workarounds, when not caught, tend to spread themself
   magically because driver writers checkout the existing code of
   similar devices and copy/paste/modify^Wuglify them over and over.

 - In the worst case such workarounds make the core maintainence
   harder and in some cases impossible, because they silently imply
   semantics on the core w/o the core maintainer knowing about them.

The last point is the most important one to me as a subsystem maintainer – I really don’t want to be merging code that is going to create issues with ongoing development of the subsystem. This is all another facet of the policy on stable APIs: APIs are only worth working around if they’re fixed, and the assumptions that end up embedded in a workaroud are as much part of the API as the explicit interfaces.

It’s things like this that make Linux such a pleasure to work on.

First we make the system partition writable:

adb root
adb remount

Then copy the BCM4329 driver over (the path to the driver here is running from the root of the kernel tree:

adb push drivers/net/wireless/bcm4329/bcm4329.ko /system/modules

Finally, reboot into the bootloader and flash the actual kernel:

adb reboot bootloader
fastboot flash zimage arch/arm/boot/zImage
fastboot reboot

Note that some of these commands may return before the operation they’ve started has completed so you may need to wait for the phone at various points.

As with updating the main system firmware the above requires an unlocked device which voids your warranty.

There’s a bunch of existing documentation out there for the trace subsystem, including some in the kernel under Documentation/trace, which I won’t repeat here. The ASoC events are grouped together under ‘asoc’. The raw log can be viewed by looking at the file tracing/trace in debugfs. Here’s a sample output from starting playback of an MP3 on a Samsung SMDK6410 reference system using WM8580, a high performance six channel CODEC with a very simple software interface:

mplayer-1673  [000]   183.920000: snd_soc_dapm_start: card=SMDK-I2S
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Rear val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Center+Sub val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Front val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT3R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT3L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT2R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT2L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT1R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT1L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC3 val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC2 val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC1 val=1
mplayer-1673  [000]   183.920000: snd_soc_bias_level_start: card=SMDK-I2S val=2
mplayer-1673  [000]   183.920000: snd_soc_bias_level_done: card=SMDK-I2S val=2
mplayer-1673  [000]   183.920000: snd_soc_reg_read: codec=wm8580-codec.0-001b.27 reg=32 val=1e
mplayer-1673  [000]   183.920000: snd_soc_reg_write: codec=wm8580-codec.0-001b.27 reg=32 val=2
mplayer-1673  [000]   183.920000: snd_soc_bias_level_start: card=SMDK-I2S val=3
mplayer-1673  [000]   183.920000: snd_soc_bias_level_done: card=SMDK-I2S val=3
mplayer-1673  [000]   183.920000: snd_soc_dapm_done: card=SMDK-I2S
mplayer-1673  [000]   183.920000: snd_soc_reg_read: codec=wm8580-codec.0-001b.27 reg=13 val=10
mplayer-1673  [000]   183.920000: snd_soc_reg_write: codec=wm8580-codec.0-001b.27 reg=13 val=0

Each line represents a trace event, showing the process that initiated the event, the CPU it ran on and the time it was recorded at together with event-specific details. On this system the time is reported with 10ms accuracy and the CODEC is very simple so the timing information is not terribly informative, but more accurate timers can be really helpful in analysing what’s going on with more complex CODECs. The set of events available will change over time, the key ones currently present in the kernel are:

• snd_soc_dapm_start and snd_soc_dapm_done: These events show the start and stop of the DAPM algorithms, showing the time spent on power management decisions.
• snd_soc_dapm_widget_power events are generated for each of the widgets which DAPM has determined needs to change state. The ‘val=1′ means that all these widgets are being powered up, val=0 would show power down.
• snd_soc_reg_write events show values written to registers.
• snd_soc_reg_read events show values read from registers – these reads may be done from the register cache, or may be from the hardware.
• snd_soc_dapm_widget_event_start and snd_soc_dapm_widget_event_done show the time spent in per-widget event callbacks.

The set of events traced will change as the subsystem develops and as people gain more experience with using the trace API.

• Overhaul of the core APIs for registration of all kinds of devices from my co-maintainer Liam Girdwood, reducing the level of direct coupling between machine drivers and their CODEC and CPU drivers allowing ASoC machines to have multiple CODEC devices and multiple instances of the same CODEC device within a system.
• New CODEC drivers for  88PM860x CODEC, MAX98088/9, WL1273, WM8962, WM8804, and WM8985.
• New CPU drivers for EP93xx AC’97 controllers, MPC85xx SSI ports, and SH HDMI controllers.
• Machine support for Freescale P1022 DS, Marvell Tavor and Saarb and Simplemachines Sim.One

• Support for keeping audio paths through the CODEC up during system suspend, primarily intended for use with devices where the Linux system is one of several independent systems running on the device and the other systems (like the cellular modem in a phone) can maintain useful audio paths even when the Linux system is inactive.
• Enhancements to the jack detection infrastructure, including the addition of notifiers on jack status changes (allowing better integration of physical jack detection with electronic methods) and snd_soc_dapm_force_enable_pin() (which allows DAPM managed supplies such as microphone biases to be forced on). For example, jack status change notifications can be used to enable microphone detection via bias current sense only when a microphone is physically present.
• Support for knot and continuous PCM rates in the core.
• SMDK6410 5.1 audio support, TI SDP4030 audio support, and basic support for playback on the 1133-EV1 PMIC module for Freescale i.MX31ADS systems (currently limited by the support for the SSI interface on the i.MX31).
• Support for DaVinci integrated voice CODECs, Philips UDA1345 CODEC, SuperH FSI2 interfaces, TI OMAP4, TWL6040 CODECs, WM9090 audio subsystem.

• Support for turning CODEC biases off completely when idle, providing power savings for modern devices with ground referenced outputs where this can be done quickly at runtime without pops and clicks.
• Support for disabling physical writes to the device in the generic cache control code, allowing devices to be completely powered off when idle while still providing their control to userspace through the standard register interfaces.
• Support for tuning the time ASoC waits before powering things down after playback has finished (in order to involve issues between tracks or similar) at runtime or from the machine driver.
• New drivers for DA7210, DB1200 I2S and AC97 controllers, i.MX3x SSI ports, OMAP4 McPDM ports, S3C64xx AC97 controller, SH SIU (Sound Interface Unit), WM2000, WM8904, WM8912, WM8955, WM8978, and WM8994