On 08/04/2014 06:37 PM, Takashi Iwai wrote:
At Mon, 4 Aug 2014 17:17:50 +0100, Mark Brown wrote:
The following changes since commit 19583ca584d6f574384e17fe7613dfaeadcdc4a6:
Linux 3.16 (2014-08-03 15:25:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-v3.17
for you to fetch changes up to ae34a78c430c37c06404f032fb04e51315204281:
Merge remote-tracking branch 'asoc/topic/wm8985' into asoc-next (2014-08-04 16:32:25 +0100)
ASoC: Updates for v3.17
This has been a pretty exciting release in terms of the framework, we've finally got support for multiple CODECs attached to a single DAI link which has been something there's been interest in as long as I've been working on ASoC. A big thanks to Benoit and Misael for their work on this.
Otherwise it's been a fairly standard release for development, including more componentisation work from Lars-Peter and a good selection of both CODEC and CPU drivers.
- Support for multiple CODECs attached to a single DAI, enabling systems with for example multiple DAC/speaker drivers on a single link, contributed by Benoit Cousson based on work from Misael Lopez Cruz.
- Support for byte controls larger than 256 bytes based on the use of TLVs contributed by Omair Mohammed Abdullah.
- More componentisation work from Lars-Peter Clausen.
- The remainder of the conversions of CODEC drivers to params_width()
- Drivers for Cirrus Logic CS4265, Freescale i.MX ASRC blocks, Realtek RT286 and RT5670, Rockchip RK3xxx I2S controllers and Texas Instruments TAS2552.
- Lots of updates and fixes, especially to the DaVinci, Intel, Freescale, Realtek, and rcar drivers.
Thanks, pulled now. The only build regression I've seen is the warning:
sound/soc/soc-dapm.c: In function ‘snd_soc_dapm_get_enum_double’: sound/soc/soc-dapm.c:2862:15: warning: ‘reg_val’ may be used uninitialized in this function [-Wmaybe-uninitialized]
I guess it came from the recent Lars' change. It just gives the garbage value and shouldn't be serious, but it'd be better to be fixed in anyways.
yep. looks like your compiler is a bit smarter than mine. I'll send a patch. The issue itself is harmless though since we even though we do some transformations on the uninitialized value the result of that is never used since we return a error code.
- Lars