Older blog entries for broonie (starting at number 98)

Changing core code

One of the biggest differences between working on most other OSs and working upstream on drivers for the Linux kernel is that elsewhere the core is usually a fixed thing that has been released and can’t really be changed, even if source is available (which may not even be the case). If whatever subsystem you’re working in can’t cope with the thing you’re trying to express then one of the things it’s really useful to be good at is working out ways to implement the behaviour that’s required behind the back of the subsystem. It’s very common to see such code in drivers submitted by hardware vendors, particularly those that are new to Linux, as this is such a big mindset shift.

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.

Syndicated 2011-03-13 21:12:10 from Technicalities

Updating the kernel on the Nexus S

Building the kernel for the Nexus S is straightforward – the kernel is public as one would expect so it’s simply a matter of building it using the standard Linux build system (the machine is called herring in the code). There is one gotcha, though – the driver for the BCM4329 WiFi controller is a loadable kernel module rather than being built into the image. This means you need to copy it onto the device filesystem separately to flashing the kernel itself if you’re only updating the kernel. The procedure I use for this is below – it’s straightforward but I’m posting it here to make it a bit more discoverable.

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.

Syndicated 2011-02-14 13:12:15 from Technicalities

Tracing ASoC with trace events

Kernel 2.6.38 will add support for tracing ASoC using trace points. Previously all logging for ASoC had been done using printk(), meaning that changing the active logging required a kernel rebuild and that when trace was enabled the volume of trace could easily become very disruptive to other logging within the system. Trace points solve these problems by providing a framework for enabling and disabling individual traces dynamically and separate logging infrastructure designed for easy filtering and post-processing. When using trace points it’s reasonable to leave them enabled all the time, making life much easier especially when debugging intermittent problems.

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_event_start and snd_soc_dapm_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.

Syndicated 2011-01-22 16:21:50 from Technicalities

ASoC changes in 2.6.37

2.6.37, which was released today, has been a very big release for ASoC – about 40,000 lines of changes covering every single file within the subsystem plus a bunch of new drivers. The highlights are:

  • 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

Syndicated 2011-01-05 11:34:45 from Technicalities

Building firmware images for Nexus S

Since I couldn’t seem to readily find any useful instructions for building firmware images for the Nexus S I thought I’d publish some. In a clean directory this sequence of commands should result in a working set of application layer images. They assume you’ve already got all the Android build dependencies installed:

repo init -u git://android.git.kernel.org/platform/manifest.git -b gingerbread
repo sync
export MYDROID
. ./build/envsetup.sh
make PRODUCT-full_crespo-user

The resulting images will be in the directory out/target/product/crespo. You can get this running on your device by flashing the boot, recovery and system images:

out/host/linux-x86/bin/fastboot flash boot out/target/product/crespo/boot.img
out/host/linux-x86/bin/fastboot flash recovery out/target/product/crespo/recovery.img
out/host/linux-x86/bin/fastboot flash system out/target/product/crespo/system.img

Note that using these firmware images will void any warranty you have on the phone – you’ll need to unlock the phone using fastboot oem unlock, but note that this is irreversible.

Similar instructions should work for Nexus One too, using passion instead of crespo in the make command above.

Syndicated 2011-01-04 16:03:54 from Technicalities

ASoC changes in 2.6.36

Linux 2.6.36 was released today. This has been a very quiet release for the ASoC core code but one of the busiest releases for a while for new CPU support, with four new architectures added:

  • CODEC support for  JZ4740, WM8741, and WM8987
  • CPU drivers for EP93xx, JZ4740, Marvell Kirkwood/Orion I2S, NUC900, and SH S/PDIF
  • Machine support for Eureka, OpenRD, qi_lb60, SmartQ, and Snapper CL15

Syndicated 2010-10-21 00:42:43 from Technicalities


Recently I’ve been using ebook readers rather a lot – mostly the Kindle DX, though I have given iBooks a spin as well. Obviously, as with MP3 players, the main win they offer is the ability to easily carry about an entire library without the inconvenience of the physical media. I’ve been reading an awful lot more than before since I started using them, mostly by virtue of it being very easy to keep several books on the go at once. What I’ve found especially good with the Kindle is the ease with which I can flip between devices, taking advantage of the tradeoffs between the different form factors.

Phones are obviously portable and these days have clear, easy to read screens (in most lights anyway) and are very light and easy to hold. They’re great if you’re stuck in a queue or on a bus but the small screen size and the fact that keeping the screen on for an extended period of time runs down the battery which isn’t always desirable. Computers are similar, trading off portability and convenience in the form factor for the larger form factor.

The iPad deals with the screen size issue without much impact on either the form factor or the battery life but the LCD display is hard to read in sunlight and can be hard on the eyes for extended use. E-Ink displays deal with those issues by swapping them for others that mean they can only work for eBooks so the devices aren’t at all general purpose. The first generation of displays had problems with frustratingly long refresh times and less than ideal contrast ratios but these have been largely addressed in current generations of device – current generation displays are beautiful.

Thus far I’ve pretty much just been reading copies of books I already have physical copies of so I’ve not really had a think about how I feel about any of the models for eBook publishing that are floating about out there, or about the DRM issues.

Syndicated 2010-08-27 23:47:07 from Technicalities

Editor (and other) customisations

A discussion the other night suggested that I’m quite unusual among geeks in doing vanishingly little customisation of my system – most of my systems have something very close to their default configuration, individual programs are usually at most a very few tweaks away from their upstream settings.

For Emacs all I tend to do is install revbufs, set Linux mode by default for C and turn on syntax highlighting and line number mode (sometimes the last two only get done when I start Emacs). For vim it’s just configuring a 72 column word wrap if my main use for vi on the system will be writing e-mail. For GNOME it’s putting a terminal launcher in one of the panels and setting focus follows mouse. All very trivial stuff done in five minutes.

The theory here is partly that I just can’t be bothered to spend more time on tweaking things (and the subsequent carrying around of those tweaks) and partly that it ensures that I’m not confused when I end up using a new system or someone else’s for whatever reason. I find it somewhat odd that this would be something you’d want to spend any time on.

Syndicated 2010-08-25 18:54:00 from Technicalities

ASoC updates in 2.6.35

Linux 2.6.35 has been a fairly interesting release from an ASoC point of view, with several notable framework enhancements:

  • 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.

Syndicated 2010-08-03 07:08:40 from Technicalities

LPC 2010 – submit your papers now!

As Lennart just posted the Call for Papers for the 2010 Linux Plumbers Conference (LPC)closes this Monday (the 19th of July). The goal of LPC is to get people working on the various projects that make up the key Linux infrastructure where the kernel and application layers meet together so that everyone understands everyone else’s needs and all the components of the system can be made to work together as well as possible. This is the third year the conference has been run, with the previous two years having been very productive, and we hope that the event this year will be equally successful.

This year I’ll be joining Lennart Poettering in helping to organize the audio track, with my particular focus being on the needs of embedded systems. Embedded audio is currently undergoing a rapid evolution, especially for mobile phones, so there’s a lot of exciting work to be done to make sure that the software stack can readily meet the needs of practical applications. Things like the move from analogue to digital audio routing within devices and the increasingly rich audio feature sets provided by systems like smartphones are driving rapid development in this area that has an impact over the full software stack from device drivers up to the application layer.

If you are involved with implementing or deploying the Linux audio infrastructure please join us there to discuss the work that needs doing and help improve the Linux audio experience even further, and please also submit a proposal.

Syndicated 2010-07-16 17:24:50 from Technicalities

89 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!