<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Technicalities &#187; Linux</title>
	<atom:link href="http://www.sirena.org.uk/log/category/tech/linux/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sirena.org.uk/log</link>
	<description>Just another random blog</description>
	<lastBuildDate>Sat, 21 Jan 2012 23:41:17 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>regmap updates in 3.2</title>
		<link>http://www.sirena.org.uk/log/2012/01/06/regmap-updates-in-3-2/</link>
		<comments>http://www.sirena.org.uk/log/2012/01/06/regmap-updates-in-3-2/#comments</comments>
		<pubDate>Fri, 06 Jan 2012 23:59:19 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[regmap]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[ASoC]]></category>
		<category><![CDATA[kernel]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=458</guid>
		<description><![CDATA[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. Support for register [...]]]></description>
			<content:encoded><![CDATA[<p>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.</p>
<ul>
<li>Support for register caches &#8211; 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.</li>
<li>Support for a wider range of SPI register transfer formats contributed by Lars-Peter Clausen.</li>
<li>Tracepoints supporting both register access logging and monitoring of the time spent on register I/O operations.</li>
<li>Register map dumps via debugfs to help provide diagnostic information during development.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2012/01/06/regmap-updates-in-3-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ASoC updates in 3.2</title>
		<link>http://www.sirena.org.uk/log/2012/01/06/asoc-updates-in-3-2/</link>
		<comments>http://www.sirena.org.uk/log/2012/01/06/asoc-updates-in-3-2/#comments</comments>
		<pubDate>Fri, 06 Jan 2012 19:07:48 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[ASoC]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[ADAU1373]]></category>
		<category><![CDATA[Alchemy]]></category>
		<category><![CDATA[Analog]]></category>
		<category><![CDATA[Freescale]]></category>
		<category><![CDATA[MXS]]></category>
		<category><![CDATA[Realtek]]></category>
		<category><![CDATA[RT5631]]></category>
		<category><![CDATA[WM1811]]></category>
		<category><![CDATA[WM5100]]></category>
		<category><![CDATA[Wolfson]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=435</guid>
		<description><![CDATA[Linux 3.2 was released yesterday. It&#8217;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. Substantial optimization of the DAPM algorithm, substantially reducing the CPU [...]]]></description>
			<content:encoded><![CDATA[<p>Linux 3.2 was released yesterday. It&#8217;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.</p>
<ul>
<li>Substantial optimization of the DAPM algorithm, substantially reducing the CPU usage when power states change. This is especially beneficial with larger modern devices.</li>
<li>Support for CODEC drivers using the regmap API.</li>
<li>Some smaller API updates &#8211; support for larger register maps, support for specifying a source when setting a sysclk.</li>
<li>New CPU drivers for Alchemy and Freescale MXS.</li>
<li>New CODEC drivers for Analog ADAU1373, Realtek RT5631 and Wolfson Microelectronics WM1811 and WM5100.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2012/01/06/asoc-updates-in-3-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>What&#8217;s wrong with switch statements?</title>
		<link>http://www.sirena.org.uk/log/2011/12/20/whats-wrong-with-switch-statements/</link>
		<comments>http://www.sirena.org.uk/log/2011/12/20/whats-wrong-with-switch-statements/#comments</comments>
		<pubDate>Tue, 20 Dec 2011 13:24:55 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[C]]></category>
		<category><![CDATA[code]]></category>
		<category><![CDATA[code review]]></category>
		<category><![CDATA[kernel]]></category>
		<category><![CDATA[review]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=463</guid>
		<description><![CDATA[Recently I&#8217;ve been noticing a surprising pattern in code I&#8217;m reviewing for the kernel. A lot of people seem to have taken to writing code that I&#8217;d expect to look like this: switch (thing) { case VALUE: /* Stuff */ break; case BAR: /* Nonsense */ break; default: /* Whatever */ break; } with if [...]]]></description>
			<content:encoded><![CDATA[<p>Recently I&#8217;ve been noticing a surprising pattern in code I&#8217;m reviewing for the kernel. A lot of people seem to have taken to writing code that I&#8217;d expect to look like this:</p>
<pre>switch (thing) {
case VALUE:
        /* Stuff */
        break;
case BAR:
        /* Nonsense */
        break;
default:
        /* Whatever */
        break;
}</pre>
<p>with if statements instead:</p>
<pre>if (thing == VALUE) {
        /* Stuff */
} else if (thing == BAR) {
        /* Nonsense */
} else {
        /* Whatever */
}</pre>
<p>(where stuff, nonsense and whatever are usually a bit larger). I really don&#8217;t understand where this has come from &#8211; the if based form isn&#8217;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?</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2011/12/20/whats-wrong-with-switch-statements/feed/</wfw:commentRss>
		<slash:comments>13</slash:comments>
		</item>
		<item>
		<title>ASoC updates in 3.1</title>
		<link>http://www.sirena.org.uk/log/2011/10/24/asoc-updates-in-3-1/</link>
		<comments>http://www.sirena.org.uk/log/2011/10/24/asoc-updates-in-3-1/#comments</comments>
		<pubDate>Mon, 24 Oct 2011 09:36:56 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[ASoC]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[ADAV80x]]></category>
		<category><![CDATA[Analog]]></category>
		<category><![CDATA[DAPM]]></category>
		<category><![CDATA[register cache]]></category>
		<category><![CDATA[Sigmatel]]></category>
		<category><![CDATA[STA326]]></category>
		<category><![CDATA[STA328]]></category>
		<category><![CDATA[STA329]]></category>
		<category><![CDATA[STA32x]]></category>
		<category><![CDATA[WM8728]]></category>
		<category><![CDATA[WM8983]]></category>
		<category><![CDATA[Wolfson]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=403</guid>
		<description><![CDATA[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. Lots of cleanups to the register cache code in preparation for moving the code to the [...]]]></description>
			<content:encoded><![CDATA[<p>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.</p>
<ul>
<li>Lots of cleanups to the register cache code in preparation for moving the code to the <a href="http://www.sirena.org.uk/log/2011/09/30/regmap-a-register-map-abstraction-for-the-linux-kernel/">regmap API</a>.</li>
<li>Support for maintaining lower power when in mostly idle states like microphone detection.</li>
<li>Support for weak DAPM routes, enabling better pop/click performance for paths like sidetones.</li>
<li>New CODEC drivers for Analog Devices ADAV80x, Sigmatel STA32x and Wolfson WM8728 and WM8983.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2011/10/24/asoc-updates-in-3-1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>regmap &#8211; a register map abstraction for the Linux kernel</title>
		<link>http://www.sirena.org.uk/log/2011/09/30/regmap-a-register-map-abstraction-for-the-linux-kernel/</link>
		<comments>http://www.sirena.org.uk/log/2011/09/30/regmap-a-register-map-abstraction-for-the-linux-kernel/#comments</comments>
		<pubDate>Fri, 30 Sep 2011 12:46:54 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[regmap]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[I2C]]></category>
		<category><![CDATA[kernel]]></category>
		<category><![CDATA[SPI]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=422</guid>
		<description><![CDATA[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 &#8211; 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 [...]]]></description>
			<content:encoded><![CDATA[<p>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 &#8211; 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&#8217;s been an implementation of this in ASoC for some time now, the regmap API makes it available to all drivers.</p>
<p>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:</p>
<pre>int regmap_read(struct regmap *map, unsigned int reg, unsigned int *val);
int regmap_write(struct regmap *map, unsigned int reg, unsigned int val);</pre>
<p>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.</p>
<p>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.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2011/09/30/regmap-a-register-map-abstraction-for-the-linux-kernel/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Making patches easy to review</title>
		<link>http://www.sirena.org.uk/log/2011/09/09/making-patches-easy-to-review/</link>
		<comments>http://www.sirena.org.uk/log/2011/09/09/making-patches-easy-to-review/#comments</comments>
		<pubDate>Fri, 09 Sep 2011 10:44:33 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[ASoC]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[regmap]]></category>
		<category><![CDATA[regulator]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[code]]></category>
		<category><![CDATA[code review]]></category>
		<category><![CDATA[development]]></category>
		<category><![CDATA[gerrit]]></category>
		<category><![CDATA[git]]></category>
		<category><![CDATA[process]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=416</guid>
		<description><![CDATA[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 [...]]]></description>
			<content:encoded><![CDATA[<p>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&#8217;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&#8217;ve seen the difficulty . I&#8217;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&#8217;re using a tool like <a href="http://code.google.com/p/gerrit/">gerrit</a> to do the reviews; it&#8217;s also mostly focused on detailed review rather than design level review.</p>
<p>The basic idea is fairly simple &#8211; the goal is to make it as easy as possible for someone to read and understand the change that&#8217;s being made.</p>
<ul>
<li>Make sure the code matches the coding style of the code being modified.</li>
<li>Make patches as small and self contained as possible &#8211; having many patches is much easier than having complicated patches.</li>
<li>Provide a changelog clearly describing everything that&#8217;s going on in the patch.</li>
</ul>
<p>The result here should be something that&#8217;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 &#8211; the idea itself is easier to keep in your head and there&#8217;s fewer things to check so the process of validating things is easier.</p>
<p>It&#8217;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&#8217;s being done much more clearly than might happen otherwise. There&#8217;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 <a href="http://www.kernel.org/pub/software/scm/git/docs/git-annotate.html">git annotate</a> it&#8217;s usually reasonably straightforward to find the changes that introduced the code that you&#8217;re looking at. Small changes with good changelog entries mean it&#8217;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&#8217;s much harder for documentation to go missing from the SCM than it is for it to go missing elsewhere, and it&#8217;s much more likely that documentation in the commit is going to be up to date than external documentation, especially prewritten design documentation.</p>
<p>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.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2011/09/09/making-patches-easy-to-review/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ASoC updates in 3.0</title>
		<link>http://www.sirena.org.uk/log/2011/07/22/asoc-updates-in-3-0/</link>
		<comments>http://www.sirena.org.uk/log/2011/07/22/asoc-updates-in-3-0/#comments</comments>
		<pubDate>Fri, 22 Jul 2011 08:49:47 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[ASoC]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[AK4641]]></category>
		<category><![CDATA[Asahi Kasei]]></category>
		<category><![CDATA[hx4700]]></category>
		<category><![CDATA[iPAQ]]></category>
		<category><![CDATA[kernel]]></category>
		<category><![CDATA[MAX98095]]></category>
		<category><![CDATA[Maxim]]></category>
		<category><![CDATA[Samsung]]></category>
		<category><![CDATA[WM8580]]></category>
		<category><![CDATA[WM8996]]></category>
		<category><![CDATA[Wolfson Microelectronics]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=398</guid>
		<description><![CDATA[Linux 3.0 was released today &#8211; another fairly quiet release for the ASoC core, plus the usual collection of new drivers: Support DAPM controls that affect multiple paths &#8211; 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 [...]]]></description>
			<content:encoded><![CDATA[<p>Linux 3.0 was released today &#8211; another fairly quiet release for the ASoC core, plus the usual collection of new drivers:</p>
<ul>
<li>Support DAPM controls that affect multiple paths &#8211; mainly used for single register bits that affect the routing for a stereo pair of audio streams.</li>
<li>Simplifications in the cache infrastructure.</li>
<li>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.</li>
<li>New CODEC drivers for AK4641, MAX98095 and WM8996.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2011/07/22/asoc-updates-in-3-0/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ASoC updates in 2.6.39</title>
		<link>http://www.sirena.org.uk/log/2011/05/19/asoc-updates-in-2-6-39/</link>
		<comments>http://www.sirena.org.uk/log/2011/05/19/asoc-updates-in-2-6-39/#comments</comments>
		<pubDate>Thu, 19 May 2011 21:26:18 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[ASoC]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[2.6.37]]></category>
		<category><![CDATA[alsa]]></category>
		<category><![CDATA[Cirrus]]></category>
		<category><![CDATA[CS4271]]></category>
		<category><![CDATA[Freescale]]></category>
		<category><![CDATA[Intel]]></category>
		<category><![CDATA[LM4857]]></category>
		<category><![CDATA[MAX8950]]></category>
		<category><![CDATA[Maxim]]></category>
		<category><![CDATA[Medfield]]></category>
		<category><![CDATA[Natsemi]]></category>
		<category><![CDATA[release]]></category>
		<category><![CDATA[SGTL5000]]></category>
		<category><![CDATA[SN95031]]></category>
		<category><![CDATA[TI]]></category>
		<category><![CDATA[Visstrim M10]]></category>
		<category><![CDATA[WM8991]]></category>
		<category><![CDATA[Wolfson]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=344</guid>
		<description><![CDATA[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. Support for registering machine drivers as first class devices rather than using the soc-audio device. Support for the soc-audio device will [...]]]></description>
			<content:encoded><![CDATA[<p>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.</p>
<ul>
<li>Support for registering machine drivers as first class devices rather than using the soc-audio device. Support for the soc-audio device will be removed at some point in the future.</li>
<li>Support for ordering widget power changes within widget types, helping with large CODECs and multi-stage amplifiers.</li>
<li>Support for waiting for multiple slow events to complete during DAPM sequences, making it easier to handle things like DC offset correction on multiple outputs.</li>
<li>CPU support for Intel Medfield and nVidia Tegra2.</li>
<li>CODEC support for Cirrus CS4271, Freescale SGTL5000, Maxim MAX8950, National Semiconductors ﻿LM4857, TI SN95031 and Wolfson WM8991</li>
<li>Machine support for Intel Medfield MID reference platforms, nVidia Harmony, ﻿﻿and Visstrim M10.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2011/05/19/asoc-updates-in-2-6-39/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ASoC conference 2011 &#8211; Edinburgh, 4-5th May</title>
		<link>http://www.sirena.org.uk/log/2011/03/26/asoc-conference-2011-edinburgh-4-5th-may/</link>
		<comments>http://www.sirena.org.uk/log/2011/03/26/asoc-conference-2011-edinburgh-4-5th-may/#comments</comments>
		<pubDate>Sat, 26 Mar 2011 00:20:06 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[ASoC]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[conference]]></category>
		<category><![CDATA[Edinburgh]]></category>
		<category><![CDATA[SMWS]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=395</guid>
		<description><![CDATA[There will be an ASoC conference in Edinburgh 4th-5th May this year, held in the Scotch Malt Whisky Society in Edinburgh. Full details are in the announcement &#8211; if you&#8217;ve got an interest in embedded audio on Linux I recommend you attend, there&#8217;s a lot of development going on in this area right now and [...]]]></description>
			<content:encoded><![CDATA[<p>There will be an ASoC conference in Edinburgh 4th-5th May this year, held in the <a href="http://www.smws.co.uk/">Scotch Malt Whisky Society</a> in Edinburgh. <a href="http://www.slimlogic.co.uk/?p=268">Full details are in the announcement</a> &#8211; if you&#8217;ve got an interest in embedded audio on Linux I recommend you attend, there&#8217;s a lot of development going on in this area right now and it promises to be a great opportunity to coordinate development plans and make sure things work well for everyone. Having met quite a few of the attendees who&#8217;ve signed up already I can also say that it should be an opportunity to meet some really excellent people.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2011/03/26/asoc-conference-2011-edinburgh-4-5th-may/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ASoC updates in 2.6.38</title>
		<link>http://www.sirena.org.uk/log/2011/03/15/asoc-updates-in-2-6-38/</link>
		<comments>http://www.sirena.org.uk/log/2011/03/15/asoc-updates-in-2-6-38/#comments</comments>
		<pubDate>Tue, 15 Mar 2011 12:58:48 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[ASoC]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[ALC5621]]></category>
		<category><![CDATA[ALC5622]]></category>
		<category><![CDATA[ALC5623]]></category>
		<category><![CDATA[alsa]]></category>
		<category><![CDATA[Samsung]]></category>
		<category><![CDATA[WM8737]]></category>
		<category><![CDATA[WM8770]]></category>
		<category><![CDATA[WM8958]]></category>
		<category><![CDATA[Wolfson]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=325</guid>
		<description><![CDATA[Linux 2.6.38 was just released, with another big update to ASoC including: Enhancements to multi-component from Jarkko Nikula allowing multiple devices of the same type to be included in one system (and handling other overlaps between devices) and support cross device DAPM. Support from Dimitris Papastamos for compressing the register cache in memory using either [...]]]></description>
			<content:encoded><![CDATA[<p>Linux 2.6.38 was just released, with another big update to ASoC including:</p>
<ul>
<li>Enhancements to multi-component from <a href="http://bitmer.com/">Jarkko Nikula</a> allowing multiple devices of the same type to be included in one system (and handling other overlaps between devices) and support cross device DAPM.</li>
<li>Support from <a href="http://opensource.wolfsonmicro.com/">Dimitris Papastamos</a> for compressing the register cache in memory using either an rbtree or LZO, giving substantial memory savings on CODECs with large register maps, especially those that are sparse. This is especially beneficial to modern devices with integrated DSPs. This can be enabled by machine drivers, though CODECs can also provide defaults.</li>
<li>Addition of trace points around DAPM and register I/O operation, allowing very low overhead logging without interfering with the main system log, useful for collecting verbose diagnostics without interfering with system operation and for always enabled flight recorder style tracking for intermittent problems. I blogged about <a href="http://www.sirena.org.uk/log/2011/01/22/tracing-asoc-with-trace-points/">ASoC trace points</a> in more detail at the time.</li>
<li>Restructuring of the Samsung CPU support from <a href="http://www.samsung.com/">Jassi Brar</a>, including a number of really good usability improvements. This supports features of more modern CPUs such as the ability to run two audio streams to a single I2S port and includes a number of API simplifications which should also make developing drivers for Samsung systems much easier.</li>
<li>New CODEC drivers for ALC5621/2/3, WM8737, WM8770 and WM8958.</li>
<li>Machine support for HP iPAQ H1940, HP t5325 thin clients and OpenRC Ultimate.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2011/03/15/asoc-updates-in-2-6-38/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

