- 09 Dec, 2011 6 commits
-
-
Axel Lin authored
Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
The device only supports SPI. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Stephen Warren authored
Transform some loops from: for_each(x) { if (f(x)) { work_on(x); } } to new structure: for_each(x) { if (!f(x)) continue; work_on(x); } This will allow future modification of f(x) with less impact to the code. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
- 08 Dec, 2011 7 commits
-
-
Stephen Warren authored
Move DAS routing setup into the DAS driver itself. This removes the need to duplicate this in each machine driver, of which we'll soon have three. An added advantage is that the machine drivers no longer call the Tegra20- specific DAS functions by name, so the machine driver no longer needs to be split up into Tegra20 and Tegra30 versions. If individual machine drivers need a different routing setup to this default, they can still call the DAS functions to set that up. Long-term, DAS will be a codec driver, and user-space will be able to control its routing, possibly within constraints that the machine driver sets up. Configuring the DAS routing from the DAS driver is a very slight move in that direction. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Use snd_soc_update_bits for read-modify-write register access instead of open-coding it using snd_soc_read and snd_soc_write Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
No need to do this in the driver now. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
As for PCMs take a runtime power management reference to devices that are in a non-off bias, avoiding the need to do this in individual drivers. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
Now that the core holds a pm_runtime reference to the device while the link is active there is no need for the driver to do so. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
-
Mark Brown authored
Now that the core holds a pm_runtime reference to the device while the link is active there is no need for the driver to do so. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
-
Mark Brown authored
Every device that implements runtime power management for DAIs is doing it in pretty much the same way: in the startup callback they take a runtime PM reference and then in the shutdown callback they release that reference, keeping the device active while the DAI is active. Given the frequency with which this is done and the obviousness of the need to keep the device active in this period factor the code out into the core, taking references on the device for each CPU DAI, CODEC DAI and DMA device in the core. As runtime PM is reference counted this shouldn't interfere with any other reference holding by the drivers, and since (in common with the existing implementations) we don't check for errors on enabling it shouldn't matter if the device actually has runtime PM enabled or not. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
-
- 07 Dec, 2011 9 commits
-
-
Mark Brown authored
-
Axel Lin authored
Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Fix a typo introduced by commit e00c3f55 "ASoC: Convert Samsung directory to module_platform_driver". This fixes the build error: CC sound/soc/samsung/s3c24xx_simtec_tlv320aic23.o sound/soc/samsung/s3c24xx_simtec_tlv320aic23.c: In function 'simtec_audio_tlv320aic32_driver_init': sound/soc/samsung/s3c24xx_simtec_tlv320aic23.c:105: error: 'simtec_audio_tlv320aic32_driver' undeclared (first use in this function) sound/soc/samsung/s3c24xx_simtec_tlv320aic23.c:105: error: (Each undeclared identifier is reported only once sound/soc/samsung/s3c24xx_simtec_tlv320aic23.c:105: error: for each function it appears in.) sound/soc/samsung/s3c24xx_simtec_tlv320aic23.c: In function 'simtec_audio_tlv320aic32_driver_exit': sound/soc/samsung/s3c24xx_simtec_tlv320aic23.c:105: error: 'simtec_audio_tlv320aic32_driver' undeclared (first use in this function) make[3]: *** [sound/soc/samsung/s3c24xx_simtec_tlv320aic23.o] Error 1 make[2]: *** [sound/soc/samsung] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 I think we had better naming it with *driver, thus I change it to simtec_audio_tlv320aic23_driver. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Include linux/module.h to fix below build error: CC sound/soc/samsung/smdk2443_wm9710.o sound/soc/samsung/smdk2443_wm9710.c:64: error: expected declaration specifiers or '...' before string constant sound/soc/samsung/smdk2443_wm9710.c:64: warning: data definition has no type or storage class sound/soc/samsung/smdk2443_wm9710.c:64: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR' sound/soc/samsung/smdk2443_wm9710.c:64: warning: function declaration isn't a prototype sound/soc/samsung/smdk2443_wm9710.c:65: error: expected declaration specifiers or '...' before string constant sound/soc/samsung/smdk2443_wm9710.c:65: warning: data definition has no type or storage class sound/soc/samsung/smdk2443_wm9710.c:65: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION' sound/soc/samsung/smdk2443_wm9710.c:65: warning: function declaration isn't a prototype sound/soc/samsung/smdk2443_wm9710.c:66: error: expected declaration specifiers or '...' before string constant sound/soc/samsung/smdk2443_wm9710.c:66: warning: data definition has no type or storage class sound/soc/samsung/smdk2443_wm9710.c:66: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE' sound/soc/samsung/smdk2443_wm9710.c:66: warning: function declaration isn't a prototype make[3]: *** [sound/soc/samsung/smdk2443_wm9710.o] Error 1 make[2]: *** [sound/soc/samsung] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Fix a typo in jive_wm8750 that introduces below build error. Also removes an unused err variable. CC sound/soc/samsung/jive_wm8750.o sound/soc/samsung/jive_wm8750.c: In function 'jive_wm8750_init': sound/soc/samsung/jive_wm8750.c:104: warning: unused variable 'err' sound/soc/samsung/jive_wm8750.c: At top level: sound/soc/samsung/jive_wm8750.c:134: error: unknown field 'dapm_widgtets' specified in initializer sound/soc/samsung/jive_wm8750.c:134: warning: initialization from incompatible pointer type make[3]: *** [sound/soc/samsung/jive_wm8750.o] Error 1 make[2]: *** [sound/soc/samsung] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Sangbeom Kim <sbkim73@samsung.com>
-
Stephen Warren authored
This allows the device to be matched against the device tree using the compatible flag directly, as is standard, rather than falling back to matching .id_table against the non-vendor portion of the first compatible property value. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
- 06 Dec, 2011 10 commits
-
-
Mark Brown authored
-
Axel Lin authored
Currently SND_SOC_JZ4740_CODEC depends on SOC_JZ4740 but SOC_JZ4740 is not defined in any Kconfig. Thus the codec driver will not be built when select "Build all ASoC CODEC drivers". (Unless it is selected by SND_JZ4740_SOC_QI_LB60). Remove the dependency with SOC_JZ4740, then this code driver can be built when select "Build all ASoC CODEC drivers". Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Include linux/io.h to fix below build errors: CC sound/soc/codecs/jz4740.o sound/soc/codecs/jz4740.c: In function 'jz4740_codec_read': sound/soc/codecs/jz4740.c:82: error: implicit declaration of function 'readl' sound/soc/codecs/jz4740.c: In function 'jz4740_codec_write': sound/soc/codecs/jz4740.c:92: error: implicit declaration of function 'writel' sound/soc/codecs/jz4740.c: In function 'jz4740_codec_probe': sound/soc/codecs/jz4740.c:373: error: implicit declaration of function 'ioremap' sound/soc/codecs/jz4740.c:373: warning: assignment makes pointer from integer without a cast sound/soc/codecs/jz4740.c:393: error: implicit declaration of function 'iounmap' make[3]: *** [sound/soc/codecs/jz4740.o] Error 1 make[2]: *** [sound/soc/codecs] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
If we fail to read the IRQ type from the interrupt controller don't fail, just assume a value and solider on - we may fail later when we try to request the IRQ but it's possible we'll succeed. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Stephen Warren authored
Document the device tree binding for the WM8903 codec, and modify the driver to extract platform data from the device tree, if present. Based on work by John Bonesio, but significantly reworked since then. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Stephen Warren authored
If the WM8903 is hooked up to an interrupt, set the irq_active_low flag in the default platform data based on the IRQ's IRQ_TYPE. Map IRQ_TYPE_NONE (a lack of explicit configuration/restriction) to irq_active_low = false; the previous default. This code is mainly added to support device tree interrupt bindings, although will work perfectly well in a non device tree system too. Any interrupt controller that supports only a single IRQ_TYPE could set each IRQ's type based on that restriction. This applies equally with and without device tree. To cater for interrupt controllers that don't do this, for which irqd_get_trigger_type() will return IRQ_TYPE_NONE, the platform data irq_active_low field may be used in systems that don't use device tree. With device tree, every IRQ must have some IRQ_TYPE set. Controllers that support DT and multiple IRQ_TYPEs must define the interrupts property (as used in interrupt source nodes) such that it defines the IRQ_TYPE to use. When the core DT setup code initializes wm8903->irq, the interrupts property will be parsed, and as a side- effect, set the IRQ's IRQ_TYPE for the WM8903 probe() function to read. Controllers that support DT and a single IRQ_TYPE could arrange to set the IRQ_TYPE somehow during their initialization, or hard-code it during the processing of the child interrupts property. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Stephen Warren authored
The pdata pointer is now always valid. Remove any conditions that check its validity. This patch is mostly just removing an indentation level. One variable had to be moved due to the removal of a scope, and one comment was split into two. Viewing the patch with git show/diff -b will show that it's actually very small. Note that WM8903_MIC_BIAS_CONTROL_0 is now written unconditionally, whereas it used to be written only if pdata was supplied. Since defpdata.micdet_cfg = 0, this unconditional write simply echos the HW defaults in the case where pdata is not supplied. Based on work by John Bonesio, but significantly reworked since then. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Stephen Warren authored
wm8903_platform_data.gpio_cfg[] was intended to be interpreted as follows: 0: Don't touch this GPIO's configuration register 1..7fff: Write that value to the GPIO's configuration register 8000: Write zero to the GPIO's configuration register other: Undefined (invalid) The rationale is that platform data is usually global data, and a value of zero means that the field wasn't explicitly set to anything (e.g. because the field was new to the pdata type, and existing users weren't update to initialize it) and hence the value zero should be ignored. 0x8000 is an explicit way to get 0 in the register. The code worked this way until commit 7cfe5617 "ASoC: wm8903: Expose GPIOs through gpiolib", where the behaviour was changed due to my lack of awareness of the above rationale. This patch reverts to the intended behaviour, and updates all in-tree users to use the correct scheme. This also makes WM8903 consistent with other devices that use a similar scheme. WM8903_GPIO_NO_CONFIG is also renamed to WM8903_GPIO_CONFIG_ZERO so that its name accurately reflects its purpose. Signed-off-by: Stephen Warren <swarren@nvidia.com> Cc: Olof Johansson <olof@lixom.net> Cc: Colin Cross <ccross@android.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
-
Mark Brown authored
Allow userspace applications to do more parameter setting by providing a more complete stub DMA driver specifying a wildcard set of formats and channels and essentially random values for the DMA parameters. This is required for useful runtime operation of the dummy DMA driver until we are able to figure out how to power up links and do hw_params() from DAPM. Sending to stable as without this the dummy driver is not terribly useful. Reported-by: Kyung-Kwee Ryu <Kyung-Kwee.Ryu@wolfsonmicro.com> Tested-by: Kyung-Kwee Ryu <Kyung-Kwee.Ryu@wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org
-
- 05 Dec, 2011 6 commits
-
-
Mark Brown authored
-
Mark Brown authored
They're not currently actively worked on, the hardware being rather obsolete by now. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Vinod Koul authored
lower level drivers typically register with upper layers. So fix by exporting symbols from sst_platform driver for dsp driver to register to sst platform driver Now this driver doesnt depend on sst driver, so remove the dependency and the header files Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
reg_cache_size is supposed to be the number of elements in the register cache, not the size in bytes. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Using gpio_request_one can make the error handling simpler. Also remove a redundant "Failed to issue reset" error message. We already show the error message in uda1380_reset() error path. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Axel Lin authored
Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
- 04 Dec, 2011 2 commits
-
-
Mark Brown authored
-
Axel Lin authored
SND_SOC_MX27VIS_AIC32X4 selects SND_SOC_TLV320AIC32X4, but SND_SOC_TLV320AIC32X4 needs CONFIG_I2C. So we need to make SND_SOC_MX27VIS_AIC32X4 depend on I2C. otherwise I got below build error if CONFIG_I2C is not selected. CC sound/soc/codecs/tlv320aic32x4.o sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_read': sound/soc/codecs/tlv320aic32x4.c:323: error: implicit declaration of function 'i2c_smbus_read_byte_data' sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_probe': sound/soc/codecs/tlv320aic32x4.c:641: error: 'i2c_master_send' undeclared (first use in this function) sound/soc/codecs/tlv320aic32x4.c:641: error: (Each undeclared identifier is reported only once sound/soc/codecs/tlv320aic32x4.c:641: error: for each function it appears in.) sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_modinit': sound/soc/codecs/tlv320aic32x4.c:763: error: implicit declaration of function 'i2c_add_driver' sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_exit': sound/soc/codecs/tlv320aic32x4.c:774: error: implicit declaration of function 'i2c_del_driver' make[3]: *** [sound/soc/codecs/tlv320aic32x4.o] Error 1 make[2]: *** [sound/soc/codecs] Error 2 make[1]: *** [sound/soc] Error 2 make: *** [sound] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-