Older blog entries for broonie (starting at number 90)

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

ASoC updates in 2.6.34

Linux 2.6.34 was released today. This contains a fairly substantial batch of ASoC updates, including:

• 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, WM8994

Posted from Fresno, California, United States.

Syndicated 2010-05-17 04:03:43 from Technicalities

Network I/O

I’ve had the opportunity to use a bunch of different smartphone OSs for extended periods recently. They’ve all taken interestingly different tacks on some of the key stuff, normally all within the bounds of reasonable implementation decisions but with very different results and useful to different people.

One of the most interesting decisions I’ve noticed is the model that things have for handling network I/O. At one end of the scale you’ve got iPhone OS which does very little network I/O off-line – it will fetch mail in the background and there’s MobileMe sync but that’s about it. Everything else is triggered by direct user action and is generally visible to them. Even with the mail there’s an element of interactivity – it will notify the user about mail before it’s actually been downloaded, for example. At the other end of the scale the Blackberry does its level best to mask the existence of the network – any updates go on in the background, with the fact that there’s any interaction with a remote system being hidden everywhere except with things like unsent messages. Both these are reasonable choices.

The iPhone model flows from the same place as the decision not to allow background apps, trading interactive performance and a degree of usability (especially where the network is slow or intermittent) for a tight control on things that incur power and bandwidth costs. This avoids surprises, especially given the number of third party apps out there, ensuring that the system always behaves as expected.

The Blackberry avoids the user being troubled by the vagaries of spotty connectivity but also means resources get consumed without user interaction, which can impact performance all round without it being clear to users what the device has been spending resources on. Then again, it’s much less common to use anything except the standard application set on a Blackberry and that is highly optimized for its function – there’s less to be worried about.

I’m not sure I’d say either approach is better – they’re not solving quite the same problem and they’re certainly part of very different systems – so it’s interesting to consider the differences. Personally I find waiting for the network annoying, but then I’m a pretty technical user so the drawbacks in terms of understanding power consumption aren’t so important for me as they will be for many other users.

Syndicated 2010-03-27 12:17:59 from Technicalities

ASoC updates in 2.6.33

This has been another fairly quiet release for ASoC.  Aside from the
addition of virtual mux support to DAPM and some further preparatory
work for multi-CODEC cards the majority of changes have been driver
updates, including:

• New CODEC drivers for ADS117x, AK4671, TLV320DAC33, TPA6130A2, WM8711 and WM8727.
• Support for the PCM port on Samsung SoCs.
• Substantial improvements to DMA performance and reliability on MPC5200 and DaVinci.
• Capture support for the FSI port on SH.

Syndicated 2010-02-25 09:32:32 from Technicalities

Oh dear…

Subject: zlib_1.2.3.3.dfsg-16_amd64.changes REJECTED

Reject Reasons:
lib32z1: lintian output: 'embedded-zlib ./usr/lib32/libz.so.1.2.3.3',
+automatically rejected package.
lib32z1: If you have a good reason, you may override this lintian tag.

I guess I should’ve actually reported the lintian bug rather than just ignoring the bogus warning.

Syndicated 2009-12-09 13:10:43 from Technicalities

ASoC updates in 2.6.32

Linux 2.6.32 was released overnight. This has been a fairly busy release for ASoC, with changes including:

• Redone power sequencing code, giving shorter power sequences which
  should reduce the effect of any artifacts that exist.
• Reporting of power management decisions via debugfs, enabling much
  easier diagnosis of path setup problems.
• Beginning of work to factor out the register access and caching code
  from the individual CODEC drivers into a shared file.  This needs to
  be rolled out over more CODEC drivers.
• New CODEC drivers for AD1836, AK4642, MAX9877, WM8523, WM8776, WM8961, WM8974 and WM8993
• New CPU support for multi-channel Blackfin SPORT, DaVinci McASP, i.MX2x SSI, and OMAP 1510 McBSP.

Syndicated 2009-12-03 10:02:43 from Technicalities

Setting up regulator consumers with dev_name

The Linux kernel regulator API requires that each system sets up the connections between the various voltage and current regulators in the system and the devices they supply, known as consumers within the regulator API. This is done using the struct device for the consumer device as the key for consumer access. This works well for things like platform devices which are generally always allocated at system startup but is not really usable with buses like I2C which only allocate the struct device late on during system startup.

To help work with these buses Linux 2.6.32 will follow the clock API and allow the use of the dev_name() for the device instead. A new field dev_name has been added to struct regulator_consumer_supply which should be used instead of dev – this is now the preferred mechanism. It is a simple string and so does not depend on any other initialization.

For those backporting the relevant commit is 9e41f08b9558c0a783826892335088a028d49ca1.

Syndicated 2009-09-16 12:29:13 from Technicalities

ASoC updates in 2.6.31

Linux 2.6.31 was released today. This was a fairly busy release for the ASoC subsystem, with updates including:

• DAPM supply widget, for automatically managing things like charge pumps and gateable clocks which may be used by more than one widget.
• Core support for setting up constraints for symmetric sample rates (for systems with a shared LRCLK).
• Support for a range of new CODECs: STAC9766, WM8940, WM8960, WM8988, and WM9081
• New CPU support too: MPC5200 AC97 and the I2S interface of the Stretch S6000.

Plus lots of updates and fixes to existing code, especially to the OMAP and TWL4030 drivers.

Syndicated 2009-09-10 10:33:07 from Technicalities

Let’s hope people can make this work

The new PS3 firmware has an iPlayer client with fullscreen support. It’s not quite broadcast SD quality, never mind HD, but that’s a fairly straightforward problem to resolve and sitting using it last night I couldn’t help but think that this is exactly how TV should work. Full TV screen, on demand and a good UI.

It’d be nice if it were free software (but again, not the most complex problem). More of an issue are the political and licensing issues that mean it’s BBC only for the forseeable future.

Syndicated 2009-09-06 20:16:41 from Technicalities