TinyHAL
Earlier today I gave a talk at Android Builders Summit about TinyHAL, a generic audio HAL for Android aimed providing a better basis for system integrators to work from. More details on TinyHAL and slides from the talk can be found over at the Wolfson Open Source web site.
regmap updates in 3.2
Version 3.1 of the Linux kernel was the first release to include regmap support and only included a bare minimum of features in order to ease review so version 3.2 has been a pretty big one for regmap development with some pretty major features being built on top of the core code.
ASoC updates in 3.2
Linux 3.2 was released yesterday. It’s been a fairly busy release for ASoC in terms of the subsystem, including the first piece of work at moving the register I/O code over to regmap to eliminate the duplication there, but a pretty quiet one on the drivers front.
What’s wrong with switch statements?
Recently I’ve been noticing a surprising pattern in code I’m reviewing for the kernel. A lot of people seem to have taken to writing code that I’d expect to look like this:
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?
ASoC updates in 3.1
Linus released version 3.1 of the kernel at Kernel Summit this morning. This has been another fairly quiet release for the framework with a few nice power optimizations, a range of driver enhancements and a fairly small set of new drivers.
regmap – a register map abstraction for the Linux kernel
A good proportion of I2C and SPI device drivers in the kernel contain some very similar code for accessing the register maps of hardware connected to those buses – most hardware designers have solved the problem of providing very similar ways. Linux 3.1 introduces a new kernel API called regmap which factors out this code from the drivers, saving code and making it much easier to share infrastructure. There’s been an implementation of this in ASoC for some time now, the regmap API makes it available to all drivers.
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.
Posted from Santa Rosa, California, United States.
Making patches easy to review
One of the big things that seems to cause a learning curve for many new contributors for Linux and other projects that make a big effort with code review is the process of putting patches together in a way that makes the code review process more smoothly. This is a fairly straightforward thing but it takes a bit of getting used to for people who aren’t used to the idea of patches and commits as a means of communication rather than just a mechanical thing you do to get changes into the codebase. In cases I’ve seen the difficulty . I’m mostly going to talk about this in the Linux context where patches are reviewed by e-mail but the same ideas apply if you’re using a tool like gerrit to do the reviews; it’s also mostly focused on detailed review rather than design level review.
The basic idea is fairly simple – the goal is to make it as easy as possible for someone to read and understand the change that’s being made.
The result here should be something that’s easy for people to review. Keeping in line with the coding style is just a generally good idea for code legibility which is obviously a key thing for people reading the code to review it. Having a clear description of the change means that the reviewer knows what the patch is supposed to do and can verify that the patch does that rather than having to spend effort figuring out if whatever the code is doing is intentional. Making changes small and simple makes them much easier to think about – the idea itself is easier to keep in your head and there’s fewer things to check so the process of validating things is easier.
It’s not just about making life easier for reviewers. The process of making simple changes and describing them clearly can be really helpful for spotting issues when writing code; it forces you to think through what’s being done much more clearly than might happen otherwise. There’s also an ongoing benefit to anyone working with the code in the future. Since each change ends up including at least some explanation of what the code is supposed to do and since revision control systems generally have some equivalent of git annotate it’s usually reasonably straightforward to find the changes that introduced the code that you’re looking at. Small changes with good changelog entries mean it’s much more likely that the changelog will provide a useful explanation as to what the author was thinking and explain why the code is the way that it is. It’s much harder for documentation to go missing from the SCM than it is for it to go missing elsewhere, and it’s much more likely that documentation in the commit is going to be up to date than external documentation, especially prewritten design documentation.
In the context of large scale reviews the usual technique is to combine reviews of individual changes with a read through of the final code after all the individual changes have been applied. Often the build up of the code through incremental changes is a enough to show the overall design but a read through of the final code can be helpful in allowing people to understand where things are going.
Posted from Santa Rosa, California, United States.
ASoC updates in 3.0
Linux 3.0 was released today – another fairly quiet release for the ASoC core, plus the usual collection of new drivers:
I know that place
One slightly unexpected effect of all the travel I’ve been doing recently is that I get a real, visceral sense of place from some slightly surprising places when I see them on the big screen. Having an idea of how the place really is, how people behave, how the air feels, how the food tastes, how it smells, a sense of what’s around the corner and beyond the camera. A sense of memory, not of imagination or of an idea of what a place should be.
San Francisco is one place this happens for and is perhaps not so surprising – it is a pretty distinctive place after all and the imagery was already familiar from countless movies and TV shows before I ever went there. What was a bit more surprising was a random suburban area in South Korea; Korea has had a real building boom amid all the growth it’s had which has resulted in a certain look and feel to the architecture and the cities being very common though not distinctive of any once place. That’s the space where a lot of the more “real world” Korean films are set, and it’s the one I recognise. Don’t think I’ve ever seen a film that ventured into Itaewon (이태원동), mind you.
It’s a much stronger feeling of recognition than I get with anywhere in the UK, I think purely due to the surprise factor. Having a good picture of Edinburgh isn’t a great surprise, finding how quickly I’ve built one up of places on other continents much more so.
ASoC updates in 2.6.39
Linux 2.6.39 was released earlier today. This release includes a few updates, the main user visible one being that machine drivers can now be registered as regular devices rather than using the soc-audio device.
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!