<?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</title>
	<atom:link href="http://www.sirena.org.uk/log/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sirena.org.uk/log</link>
	<description>Just another random blog</description>
	<lastBuildDate>Fri, 23 Mar 2012 01:26:49 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>ASoC updates in 3.3</title>
		<link>http://www.sirena.org.uk/log/2012/03/23/asoc-updates-in-3-3/</link>
		<comments>http://www.sirena.org.uk/log/2012/03/23/asoc-updates-in-3-3/#comments</comments>
		<pubDate>Fri, 23 Mar 2012 01:26:49 +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[tech]]></category>
		<category><![CDATA[ALC5632]]></category>
		<category><![CDATA[Cirrus]]></category>
		<category><![CDATA[CS42L73]]></category>
		<category><![CDATA[Realtek]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=454</guid>
		<description><![CDATA[Linux 3.3 was released earlier this week. Aside from a few regmap related updates it was an extremely quiet release for the ASoC framework, the next few releases look like they will be much more active: Conversion of a number of CODEC drivers to use regmap directly. This is especially beneficial for drivers for devices [...]]]></description>
			<content:encoded><![CDATA[<p>Linux 3.3 was released earlier this week. Aside from a few regmap related updates it was an extremely quiet release for the ASoC framework, the next few releases look like they will be much more active:</p>
<ul>
<li>Conversion of a number of CODEC drivers to use regmap directly. This is especially beneficial for drivers for devices which are part of MFDs as they can use a central cache for all operations and means that the process of factoring out the more complex register management code in ASoC can begin.</li>
<li>As a result of the move of drivers to regmap the rbtree and LZO cache types have been removed, leaving only the the basic flat cache in ASoC. Drivers which need the more complex cache types should use regmap directly.</li>
<li>Lots of cleanups and fixes from Axel Lin.</li>
<li>New CODEC drivers for Cirrus CS42L73 and Realtek ALC5632.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2012/03/23/asoc-updates-in-3-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>regulator updates in 3.3</title>
		<link>http://www.sirena.org.uk/log/2012/03/19/regulator-updates-in-3/</link>
		<comments>http://www.sirena.org.uk/log/2012/03/19/regulator-updates-in-3/#comments</comments>
		<pubDate>Mon, 19 Mar 2012 19:01:19 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[regulator]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[DA9052]]></category>
		<category><![CDATA[Device Tree]]></category>
		<category><![CDATA[Freescale Dialog]]></category>
		<category><![CDATA[kernel]]></category>
		<category><![CDATA[MC13892]]></category>
		<category><![CDATA[Open Firmware]]></category>
		<category><![CDATA[release]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=468</guid>
		<description><![CDATA[Linux 3.3 was released today. This was the biggest release for the regulator API for quite some time thanks to the contribution of device tree bindings for the API by Rajendra Nayak, the first substantial framework update for a long time, but otherwise was fairly quiet: OpenFirmware bindings for the core and for the fixed regulator [...]]]></description>
			<content:encoded><![CDATA[<p>Linux 3.3 was released today. This was the biggest release for the regulator API for quite some time thanks to the contribution of device tree bindings for the API by Rajendra Nayak, the first substantial framework update for a long time, but otherwise was fairly quiet:</p>
<ul>
<li>OpenFirmware bindings for the core and for the fixed regulator driver, contributed by Rajendra Nayak. Device tree bindings for the Freescale MC13892 PMIC were also added.</li>
<li>A new regulator_bulk_force_disable() operation contributed by Donggeun Kim.</li>
<li>A new driver for the Dialog DA9052 PMIC.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2012/03/19/regulator-updates-in-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>regmap updates in 3.3</title>
		<link>http://www.sirena.org.uk/log/2012/03/19/regmap-updates-in-3-3/</link>
		<comments>http://www.sirena.org.uk/log/2012/03/19/regmap-updates-in-3-3/#comments</comments>
		<pubDate>Mon, 19 Mar 2012 11:41:24 +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[cache]]></category>
		<category><![CDATA[genirq]]></category>
		<category><![CDATA[kernel]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=460</guid>
		<description><![CDATA[After the rush of new features in version 3.2 this has been a fairly quiet cycle for the regmap API, the main change being the wider usage by drivers. In terms of development of the subsystem itself this release sees: Introduction of a generic interrupt controller for regmap based devices, this is already used by [...]]]></description>
			<content:encoded><![CDATA[<p>After the rush of new features in version 3.2 this has been a fairly quiet cycle for the regmap API, the main change being the wider usage by drivers. In terms of development of the subsystem itself this release sees:</p>
<div>
<ul>
<li>Introduction of a generic interrupt controller for regmap based devices, this is already used by a few drivers with more coming.</li>
<li>Support for 10 bit register 14 bit value devices.</li>
<li>Removal of the indexed cache type &#8211; devices which would have used it should use rbtree instead. If anything the rbtree cache is expected to be faster for small devices as where registers are grouped together into blocks it will usually be cheaper to search the rbtree.</li>
<li>Some improvements to the coverage of the tracepoints..</li>
<li>Diagnostics showing the number and size of nodes in an rbtree cache.</li>
</ul>
</div>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2012/03/19/regmap-updates-in-3-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Yahoo! Groups spam</title>
		<link>http://www.sirena.org.uk/log/2012/02/27/yahoo-groups-spam/</link>
		<comments>http://www.sirena.org.uk/log/2012/02/27/yahoo-groups-spam/#comments</comments>
		<pubDate>Mon, 27 Feb 2012 13:39:06 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[Planet Debian]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=504</guid>
		<description><![CDATA[Yahoo! Groups have for a long time had big problems with allowing people to create obvious spam groups (randomly generated names, no meaningful description and so on) and then add people without any confirmation. This was annoying but at least they have an obvious abuse reporting link in the subscription mails. Sadly rather than improve [...]]]></description>
			<content:encoded><![CDATA[<p>Yahoo! Groups have for a long time had big problems with allowing people to create obvious spam groups (randomly generated names, no meaningful description and so on) and then add people without any confirmation. This was annoying but at least they have an obvious abuse reporting link in the subscription mails. Sadly rather than improve the situation they appear to have just changed the link to not be a direct link to the reporting form but instead to be <a href="http://help.yahoo.com/l/us/yahoo/groups/original/members/forms/abuse.html">a generic help page</a>. The link didn&#8217;t change, the content just got even less useful.</p>
<p>I&#8217;m strongly tempted to just block all of Yahoo! from the mail systems I control.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2012/02/27/yahoo-groups-spam/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>TinyHAL</title>
		<link>http://www.sirena.org.uk/log/2012/02/14/tinyhal/</link>
		<comments>http://www.sirena.org.uk/log/2012/02/14/tinyhal/#comments</comments>
		<pubDate>Tue, 14 Feb 2012 21:50:19 +0000</pubDate>
		<dc:creator>Mark Brown</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[Planet Debian]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[android]]></category>
		<category><![CDATA[ASoC]]></category>
		<category><![CDATA[audio]]></category>
		<category><![CDATA[HAL]]></category>
		<category><![CDATA[TinyHAL]]></category>

		<guid isPermaLink="false">http://www.sirena.org.uk/log/?p=498</guid>
		<description><![CDATA[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.]]></description>
			<content:encoded><![CDATA[<p>Earlier today I gave a talk at <a href="https://events.linuxfoundation.org/events/android-builders-summit">Android Builders Summit</a> 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 <a href="http://opensource.wolfsonmicro.com/content/tinyhal">Wolfson Open Source web site.</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.sirena.org.uk/log/2012/02/14/tinyhal/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<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>
	</channel>
</rss>

