October 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v2] ALSA: ASoC: cs4271: add support for AMUTEB=BMUTEC feature
by Daniel Mack 04 Oct '12

04 Oct '12

The CS4271 has a feature to sync its analog mute flags, so one mute circuitry can be used for both channels. Give users access to this feature with a new DT property and a flag in the platform data. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Cc: Alexander Sverdlin <subaparts(a)yandex.ru> --- Documentation/devicetree/bindings/sound/cs4271.txt | 2 ++ include/sound/cs4271.h | 1 + sound/soc/codecs/cs4271.c | 21 ++++++++++++++++++--- 3 files changed, 21 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/cs4271.txt b/Documentation/devicetree/bindings/sound/cs4271.txt index c81b5fd..a850fb9 100644 --- a/Documentation/devicetree/bindings/sound/cs4271.txt +++ b/Documentation/devicetree/bindings/sound/cs4271.txt @@ -18,6 +18,8 @@ Optional properties: - reset-gpio: a GPIO spec to define which pin is connected to the chip's !RESET pin + - cirrus,amuteb-eq-bmutec: When given, the Codec's AMUTEB=BMUTEC flag + is enabled. Examples: diff --git a/include/sound/cs4271.h b/include/sound/cs4271.h index 50a059e..6d9e15e 100644 --- a/include/sound/cs4271.h +++ b/include/sound/cs4271.h @@ -19,6 +19,7 @@ struct cs4271_platform_data { int gpio_nreset; /* GPIO driving Reset pin, if any */ + int amutec_eq_bmutec:1; /* flag to enable AMUTEC=BMUTEC */ }; #endif /* __CS4271_H */ diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index f994af3..2ac5fe6 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -474,15 +474,25 @@ static int cs4271_probe(struct snd_soc_codec *codec) struct cs4271_platform_data *cs4271plat = codec->dev->platform_data; int ret; int gpio_nreset = -EINVAL; + int amutec_eq_bmutec = 0; #ifdef CONFIG_OF - if (of_match_device(cs4271_dt_ids, codec->dev)) + if (of_match_device(cs4271_dt_ids, codec->dev)) { gpio_nreset = of_get_named_gpio(codec->dev->of_node, "reset-gpio", 0); + + if (!of_get_property(codec->dev->of_node, + "cirrus,amutec-eq-bmutec", NULL)) + amutec_eq_bmutec = 1; + } #endif - if (cs4271plat && gpio_is_valid(cs4271plat->gpio_nreset)) - gpio_nreset = cs4271plat->gpio_nreset; + if (cs4271plat) { + if (gpio_is_valid(cs4271plat->gpio_nreset)) + gpio_nreset = cs4271plat->gpio_nreset; + + amutec_eq_bmutec = cs4271plat->amutec_eq_bmutec; + } if (gpio_nreset >= 0) if (gpio_request(gpio_nreset, "CS4271 Reset")) @@ -528,6 +538,11 @@ static int cs4271_probe(struct snd_soc_codec *codec) /* Power-up sequence requires 85 uS */ udelay(85); + if (amutec_eq_bmutec) + snd_soc_update_bits(codec, CS4271_MODE2, + CS4271_MODE2_MUTECAEQUB, + CS4271_MODE2_MUTECAEQUB); + return snd_soc_add_codec_controls(codec, cs4271_snd_controls, ARRAY_SIZE(cs4271_snd_controls)); } -- 1.7.11.4

2 1

[alsa-devel] snd_hwdep_open() as non-root user
by Rafal Powierski 04 Oct '12

04 Oct '12

Developers, I would like to access pin verb hda interface using snd_hwdep_open() function. It works fine if I run as root. I hope there is a way to configure my kubuntu so I can do it as non-root user (e.g. debugging) so far, I have been trying changing access flags for devices in /dev/snd/ directory to crwxrwxrwx no plus character. It did not change my privileges for snd_hwdep_open() - still returns –13. I assume that the device-file responsible is /dev/snd/hwC1D0, the same as parameter given to “hda-verb” program. I am developing a new hardware, using HDA codec. Please help

2 2

[alsa-devel] [PATCH] ALSA: ASoC: cs4271: add DT property for AMUTEB=BMUTEC feature
by Daniel Mack 04 Oct '12

04 Oct '12

The CS4271 has a feature to sync its analog mute flags, so one mute circuitry can be used for both channels. Give DT uses access to this feature with a new property. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Cc: Alexander Sverdlin <subaparts(a)yandex.ru> --- Documentation/devicetree/bindings/sound/cs4271.txt | 2 ++ sound/soc/codecs/cs4271.c | 13 ++++++++++++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/cs4271.txt b/Documentation/devicetree/bindings/sound/cs4271.txt index c81b5fd..a850fb9 100644 --- a/Documentation/devicetree/bindings/sound/cs4271.txt +++ b/Documentation/devicetree/bindings/sound/cs4271.txt @@ -18,6 +18,8 @@ Optional properties: - reset-gpio: a GPIO spec to define which pin is connected to the chip's !RESET pin + - cirrus,amuteb-eq-bmutec: When given, the Codec's AMUTEB=BMUTEC flag + is enabled. Examples: diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index f994af3..56ec8dd2 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -474,11 +474,17 @@ static int cs4271_probe(struct snd_soc_codec *codec) struct cs4271_platform_data *cs4271plat = codec->dev->platform_data; int ret; int gpio_nreset = -EINVAL; + int amutec_eq_bmutec = 0; #ifdef CONFIG_OF - if (of_match_device(cs4271_dt_ids, codec->dev)) + if (of_match_device(cs4271_dt_ids, codec->dev)) { gpio_nreset = of_get_named_gpio(codec->dev->of_node, "reset-gpio", 0); + + if (!of_get_property(codec->dev->of_node, + "cirrus,amutec-eq-bmutec", NULL)) + amutec_eq_bmutec = 1; + } #endif if (cs4271plat && gpio_is_valid(cs4271plat->gpio_nreset)) @@ -528,6 +534,11 @@ static int cs4271_probe(struct snd_soc_codec *codec) /* Power-up sequence requires 85 uS */ udelay(85); + if (amutec_eq_bmutec) + snd_soc_update_bits(codec, CS4271_MODE2, + CS4271_MODE2_MUTECAEQUB, + CS4271_MODE2_MUTECAEQUB); + return snd_soc_add_codec_controls(codec, cs4271_snd_controls, ARRAY_SIZE(cs4271_snd_controls)); } -- 1.7.11.4

2 2

Re: [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
by Daniel Mack 04 Oct '12

04 Oct '12

On 04.10.2012 12:28, Matt Porter wrote: > On Thu, Oct 04, 2012 at 11:57:30AM +0200, Daniel Mack wrote: >> On 04.10.2012 11:38, Porter, Matt wrote: >>> >>> On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote: >>> >>>> >>>> >>>> On 02.10.2012 18:50, Daniel Mack wrote: >>>>> On 02.10.2012 18:41, Matt Porter wrote: >>>>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote: >>>>>>> On 02.10.2012 13:06, Sekhar Nori wrote: >>>>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote: >>>>>>>>> On 02.10.2012 11:37, Mark Brown wrote: >>>>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote: >>>>>>>>>> >>>>>>>>>>> I also agree that ifdef is not a good solution. >>>>>>>>>>> It is better to have this information passed as device_data and via DT it can >>>>>>>>>>> be decided based on the compatible property for the device. >>>>>>>>>> >>>>>>>>>> That's not really the problem here - the problem is that the APIs used >>>>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP >>>>>>>>>> or other platforms. The SRAM code needs to move to a standard API. >>>>>>>>> >>>>>>>>> What about following Matt Porter's idea and ignore the SRAM code >>>>>>>>> entirely and port the entire PCM code to generic dmaengine code first? >>>>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I >>>>>>>>> might give that a try in near future. >>>>>>>>> >>>>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc >>>>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has >>>>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here. >>>>>>>> >>>>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required >>>>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc >>>>>>>> (conversion should be straightforward and I can help test it) and the >>>>>>>> code that uses SRAM can probably keep using the private EDMA API till >>>>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already >>>>>>>> posted patches to move private EDMA APIs to a common location. That >>>>>>>> should keep AM335x build from breaking. Is this something that is feasible? >>>>>>> >>>>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably >>>>>>> right, we can also do that first. >>>>>>> >>>>>>> I'm looking at that right now and the problem seems that we don't have a >>>>>>> sane way to dynamically look up gen_pools independently of the actual >>>>>>> run-time platform. All users of gen_pools seem to know which platform >>>>>>> they run on and access a platform-specific pool. So I don't currently >>>>>>> see how we could implement multi-platform code, gen_pools are fine but >>>>>>> don't solve the problem here. >>>>>>> >>>>>>> Would it be an idea to add a char* member to gen_pools and a function >>>>>>> that can be used to dynamically look it up again? If a buffer with a >>>>>>> certain name exists, we can use it and install that ping-pong buffer, >>>>>>> otherwise we just don't. While that would be easy to do, it's a >>>>>>> tree-wide change. >>>>>>> >>>>>>> Is there a better way that I miss? >>>>>> >>>>>> At the high level there's two platform models we have to handle, the >>>>>> boot from board file !DT case, and then the boot from DT case. Since >>>>>> Davinci is just starting DT conversion, we mostly care about the !DT >>>>>> base in which the struct gen_pool * is passed in pdata to the ASoC >>>>>> driver. It is then selectable on a per-platform basis where the decision >>>>>> should be made. >>>>>> >>>>>> Given a separate discussion with Sekhar, we're only going to have one >>>>>> SRAM pool on any DaVinci part right now...this was only a question on >>>>>> L138 anyway. But regardless, the created gen_pool will be passed via >>>>>> pdata. >>>>> >>>>> I thought about this too, as mmp does it that way. >>>>> >>>>>> Since DT conversion is starting and we need to consider that now, >>>>>> the idea there is to use the DT-based generic sram driver [1] such that >>>>>> when we do boot from DT on Davinci, the genpool is provided via phandle >>>>>> and the pointer extracted with the OF helpers that are part of the >>>>>> series. >>>>> >>>>> A phandle is the cleanest way I think, yes. >>>>> >>>>>> That's pretty much it. I'm reworking the backend support as discussed >>>>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series >>>>>> that just replaces sram_* with genalloc for davinci ASoC. >>>>> >>>>> As you can also test it, it would be easiest if you came up with a patch >>>>> for that, yes. I can have a look at the dma bits laters, once my OMAP >>>>> board finally works with the code as it currently stands. I'm still >>>>> fighting with the mcasp driver right now ... >>>> >>>> I quickly prepared two patches to change that, so that topic is out of >>>> the way. But I did only compile-test them on OMAP - could you check on >>>> your Davinci platform? Note that these apply on top of the patch in >>>> discussion here (which isn't applied to the asoc tree yet). >>> >>> I put a series together yesterday, just ran out of time to post >>> last night after testing. I'm posting that now...it's on top of my >>> uio_pruss/genalloc series and only addresss switching davinci-pcm to >>> genalloc (and actually enabling ping-pon from sram). >> >> Ok, I don't care which version makes it in after all :) > > Ok :) > >>> I'll take a look a your OMAP patches. >> >> The patches I just sent out are only for Davinci and change the SRAM >> functions to genalloc in the mcasp driver. They work just fine on OMAP >> of course, as the code is disabled in there. > > Ok, same thing as I did and just sent out. These are tested on AM180x > and hook up ping-pong buffering so that there's actually one user of > all this ping-pong code. It's been sitting idle for a long time. > > I didn't see your patches come by yet but will take a look to see if > we need to combine. I attached them to my mail for a quick review. I wanted to queue them up to a bigger series I'll send out later ... Daniel

1 0

[alsa-devel] HDA-Intel: despite `power_save=1` device hwC0D0 uses 100 % according to Powertop 2.x
by Paul Menzel 04 Oct '12

04 Oct '12

Dear ALSA folks, running Debian Wheezy with Linux 3.2.23 on a T60 with 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xee240000 irq 46 29 [ThinkPadEC ]: ThinkPad EC - ThinkPad Console Audio Control ThinkPad Console Audio Control at EC reg 0x30, fw 79HT50WW-1.07 (attached `alsa-info.sh` output from before running the following command) despite enabling power saving $ echo 1 | sudo tee /sys/module/snd_hda_intel/parameters/power_save 1 and touching the device or playing some music, I am able to hear a pop/click before playing another piece of music, so some power saving mode seems to be enabled, Powertop 2.1 built from Git still shows the device using 100 %. Others seem to have similar problem with other devices though [1]. Thanks, Paul [1] http://mancoosi.org/~abate/audio-codec-hwc0d0-conexant-and-powertop

1 0

Re: [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
by Daniel Mack 04 Oct '12

04 Oct '12

On 04.10.2012 11:38, Porter, Matt wrote: > > On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote: > >> >> >> On 02.10.2012 18:50, Daniel Mack wrote: >>> On 02.10.2012 18:41, Matt Porter wrote: >>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote: >>>>> On 02.10.2012 13:06, Sekhar Nori wrote: >>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote: >>>>>>> On 02.10.2012 11:37, Mark Brown wrote: >>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote: >>>>>>>> >>>>>>>>> I also agree that ifdef is not a good solution. >>>>>>>>> It is better to have this information passed as device_data and via DT it can >>>>>>>>> be decided based on the compatible property for the device. >>>>>>>> >>>>>>>> That's not really the problem here - the problem is that the APIs used >>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP >>>>>>>> or other platforms. The SRAM code needs to move to a standard API. >>>>>>> >>>>>>> What about following Matt Porter's idea and ignore the SRAM code >>>>>>> entirely and port the entire PCM code to generic dmaengine code first? >>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I >>>>>>> might give that a try in near future. >>>>>>> >>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc >>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has >>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here. >>>>>> >>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required >>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc >>>>>> (conversion should be straightforward and I can help test it) and the >>>>>> code that uses SRAM can probably keep using the private EDMA API till >>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already >>>>>> posted patches to move private EDMA APIs to a common location. That >>>>>> should keep AM335x build from breaking. Is this something that is feasible? >>>>> >>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably >>>>> right, we can also do that first. >>>>> >>>>> I'm looking at that right now and the problem seems that we don't have a >>>>> sane way to dynamically look up gen_pools independently of the actual >>>>> run-time platform. All users of gen_pools seem to know which platform >>>>> they run on and access a platform-specific pool. So I don't currently >>>>> see how we could implement multi-platform code, gen_pools are fine but >>>>> don't solve the problem here. >>>>> >>>>> Would it be an idea to add a char* member to gen_pools and a function >>>>> that can be used to dynamically look it up again? If a buffer with a >>>>> certain name exists, we can use it and install that ping-pong buffer, >>>>> otherwise we just don't. While that would be easy to do, it's a >>>>> tree-wide change. >>>>> >>>>> Is there a better way that I miss? >>>> >>>> At the high level there's two platform models we have to handle, the >>>> boot from board file !DT case, and then the boot from DT case. Since >>>> Davinci is just starting DT conversion, we mostly care about the !DT >>>> base in which the struct gen_pool * is passed in pdata to the ASoC >>>> driver. It is then selectable on a per-platform basis where the decision >>>> should be made. >>>> >>>> Given a separate discussion with Sekhar, we're only going to have one >>>> SRAM pool on any DaVinci part right now...this was only a question on >>>> L138 anyway. But regardless, the created gen_pool will be passed via >>>> pdata. >>> >>> I thought about this too, as mmp does it that way. >>> >>>> Since DT conversion is starting and we need to consider that now, >>>> the idea there is to use the DT-based generic sram driver [1] such that >>>> when we do boot from DT on Davinci, the genpool is provided via phandle >>>> and the pointer extracted with the OF helpers that are part of the >>>> series. >>> >>> A phandle is the cleanest way I think, yes. >>> >>>> That's pretty much it. I'm reworking the backend support as discussed >>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series >>>> that just replaces sram_* with genalloc for davinci ASoC. >>> >>> As you can also test it, it would be easiest if you came up with a patch >>> for that, yes. I can have a look at the dma bits laters, once my OMAP >>> board finally works with the code as it currently stands. I'm still >>> fighting with the mcasp driver right now ... >> >> I quickly prepared two patches to change that, so that topic is out of >> the way. But I did only compile-test them on OMAP - could you check on >> your Davinci platform? Note that these apply on top of the patch in >> discussion here (which isn't applied to the asoc tree yet). > > I put a series together yesterday, just ran out of time to post > last night after testing. I'm posting that now...it's on top of my > uio_pruss/genalloc series and only addresss switching davinci-pcm to > genalloc (and actually enabling ping-pon from sram). Ok, I don't care which version makes it in after all :) > I'll take a look a your OMAP patches. The patches I just sent out are only for Davinci and change the SRAM functions to genalloc in the mcasp driver. They work just fine on OMAP of course, as the code is disabled in there. Daniel

1 0

Re: [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
by Daniel Mack 04 Oct '12

04 Oct '12

On 02.10.2012 18:41, Matt Porter wrote: > On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote: >> On 02.10.2012 13:06, Sekhar Nori wrote: >>> On 10/2/2012 4:03 PM, Daniel Mack wrote: >>>> On 02.10.2012 11:37, Mark Brown wrote: >>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote: >>>>> >>>>>> I also agree that ifdef is not a good solution. >>>>>> It is better to have this information passed as device_data and via DT it can >>>>>> be decided based on the compatible property for the device. >>>>> >>>>> That's not really the problem here - the problem is that the APIs used >>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP >>>>> or other platforms. The SRAM code needs to move to a standard API. >>>> >>>> What about following Matt Porter's idea and ignore the SRAM code >>>> entirely and port the entire PCM code to generic dmaengine code first? >>>> The EDMA driver needs to learn support for cyclic DMA for that, and I >>>> might give that a try in near future. >>>> >>>> Later on, the SRAM ping-pong code can get added back using genalloc >>>> functions, as Sekhar proposed. That needs to be done by someone who has >>>> access to a Davinci board though, I only have a AM33xx/OMAP here. >>> >>> We cannot "get rid" of SRAM code and add it back "later". It is required >>> for most DaVinci parts. The SRAM code can be converted to use genalloc >>> (conversion should be straightforward and I can help test it) and the >>> code that uses SRAM can probably keep using the private EDMA API till >>> the dmaengine EDMA driver has cyclic DMA support. Matt has already >>> posted patches to move private EDMA APIs to a common location. That >>> should keep AM335x build from breaking. Is this something that is feasible? >> >> Yes - by "later" I just meant in a subsequent patch. But you're probably >> right, we can also do that first. >> >> I'm looking at that right now and the problem seems that we don't have a >> sane way to dynamically look up gen_pools independently of the actual >> run-time platform. All users of gen_pools seem to know which platform >> they run on and access a platform-specific pool. So I don't currently >> see how we could implement multi-platform code, gen_pools are fine but >> don't solve the problem here. >> >> Would it be an idea to add a char* member to gen_pools and a function >> that can be used to dynamically look it up again? If a buffer with a >> certain name exists, we can use it and install that ping-pong buffer, >> otherwise we just don't. While that would be easy to do, it's a >> tree-wide change. >> >> Is there a better way that I miss? > > At the high level there's two platform models we have to handle, the > boot from board file !DT case, and then the boot from DT case. Since > Davinci is just starting DT conversion, we mostly care about the !DT > base in which the struct gen_pool * is passed in pdata to the ASoC > driver. It is then selectable on a per-platform basis where the decision > should be made. > > Given a separate discussion with Sekhar, we're only going to have one > SRAM pool on any DaVinci part right now...this was only a question on > L138 anyway. But regardless, the created gen_pool will be passed via > pdata. I thought about this too, as mmp does it that way. > Since DT conversion is starting and we need to consider that now, > the idea there is to use the DT-based generic sram driver [1] such that > when we do boot from DT on Davinci, the genpool is provided via phandle > and the pointer extracted with the OF helpers that are part of the > series. A phandle is the cleanest way I think, yes. > That's pretty much it. I'm reworking the backend support as discussed > with Sekhar wrt to my uio_pruss series. I can post a standalone series > that just replaces sram_* with genalloc for davinci ASoC. As you can also test it, it would be easiest if you came up with a patch for that, yes. I can have a look at the dma bits laters, once my OMAP board finally works with the code as it currently stands. I'm still fighting with the mcasp driver right now ... Daniel

1 1

[alsa-devel] [PATCH 0/2] ASoC: omap-mcpdm updates for 3.7
by Peter Ujfalusi 04 Oct '12

04 Oct '12

Hello Mark, Tony, The mcpdm driver no longer needs to include any plat/*.h file, clearing the way for the single kernel image. Regards, Peter --- Peter Ujfalusi (1): ASoC: omap-mcpdm: Remove OMAP revision check Tony Lindgren (1): ASoC: Fix wrong include for McPDM sound/soc/omap/omap-mcpdm.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) -- 1.7.12

1 3

[alsa-devel] ASoC: Fix wrong include for McPDM
by Tony Lindgren 04 Oct '12

04 Oct '12

McPDM needs platt/cpu.h for omap_rev and not omap_hwmod.h. Drivers must not include omap_hwmod.h at, it will be private to mach-omap2 soon. Fix the problem before other drivers will also start including omap_hwmod.h. Note that also plat/cpu.h will be going away, so the omap_rev check needs to be replaced with mcpdm-watchdog flag from platform_data or DT. Signed-off-by: Tony Lindgren <tony(a)atomide.com> --- Can you guys please queue this as fix for -rc1? This removes and unnecessary dependency for making omap_hwmod.h local to mach-omap2. Then I'm hoping Peter will remove the plat/cpu.h dependency for v3.8 merge window ;) --- a/sound/soc/omap/omap-mcpdm.c +++ b/sound/soc/omap/omap-mcpdm.c @@ -40,7 +40,7 @@ #include <sound/pcm_params.h> #include <sound/soc.h> -#include <plat/omap_hwmod.h> +#include <plat/cpu.h> #include "omap-mcpdm.h" #include "omap-pcm.h"

2 1

[alsa-devel] [PATCH] ASoC: wm2200: Fix non-inverted OUT2 mute control
by Mark Brown 02 Oct '12

02 Oct '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm2200.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm2200.c b/sound/soc/codecs/wm2200.c index 664067c..6ca9bcc 100644 --- a/sound/soc/codecs/wm2200.c +++ b/sound/soc/codecs/wm2200.c @@ -1028,7 +1028,7 @@ SOC_DOUBLE_R_TLV("OUT2 Digital Volume", WM2200_DAC_DIGITAL_VOLUME_2L, WM2200_DAC_DIGITAL_VOLUME_2R, WM2200_OUT2L_VOL_SHIFT, 0x9f, 0, digital_tlv), SOC_DOUBLE("OUT2 Switch", WM2200_PDM_1, WM2200_SPK1L_MUTE_SHIFT, - WM2200_SPK1R_MUTE_SHIFT, 1, 0), + WM2200_SPK1R_MUTE_SHIFT, 1, 1), }; WM2200_MIXER_ENUMS(OUT1L, WM2200_OUT1LMIX_INPUT_1_SOURCE); -- 1.7.10.4

1 0