June 2011 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] HDSPM - Problems with SyncIn
by Andre Schramm 19 Oct '12

19 Oct '12

Hello, I did some tests with the SyncIn-Feature of the HDSPe cards. [root@localhost ~]# lspci |grep Mult 01:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) 02:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) The SyncOut of card 2:00 was plugged to the SyncIn of 1:00 and 1:00 was put to AutoSync-mode automatically upon boot. Problem is that the amixer output seems to be inconsistent and differs from the proc output as well, so I'm not sure which one to trust. [root@localhost ~]# amixer -c0 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=3 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=2 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=1 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=47999 'Preferred Sync Reference' is SyncIn, 'SYNC IN SyncCheck' says 'No Lock', meaning no signal at all, but the 'System Sample Rate' coming from the master card is detected with 1Hz offset. When putting the master to 32000Hz, 31999Hz are shown and so on. [root@localhost ~]# cat /proc/asound/card0/hdspm RME MADI (Card #1) Rev.d2 Status2first3bits: 1 HW Serial: 0x0000019196d4 IRQ: 16 Registers bus: 0xfe9f0000 VM: 0xf8920000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10344ca, ctrl2=0x0, status1=0xc30004, status2=0xc0020361 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: AutoSync Preferred Sync Reference: TCO System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Sync In, Freq=0 (MADI = 3, Word = 3) Input: Coax, Mode=56 channels Now the proc-output reports 'No TCO module detected', which is correct, as no expansion modules where plugged to the cards. But it also says 'Preferred Sync Reference: TCO' and 'Freq=0', where amixer said SyncIn and 47999? Output of the master card is below. Regards, Andre [root@localhost ~]# amixer -c1 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=4 numid=15,iface=MIXER,name='Input Select' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'optical' ; Item #1 'coaxial' : values=0 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=0 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=0 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=48000 [root@localhost ~]# cat /proc/asound/card1/hdspm RME MADI (Card #2) Rev.d2 Status2first3bits: 1 HW Serial: 0x000001b1c606 IRQ: 17 Registers bus: 0xfeaf0000 VM: 0xf9280000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10004da, ctrl2=0x0, status1=0x2800000, status2=0xc0020701 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: Master Preferred Sync Reference: Word Clock System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Input not valid, Freq=0 (MADI = 10, Word = 0) Input: Optical, Mode=56 channels

2 2

Re: [alsa-devel] [PATCH 2.6.39-rc3] hda_intel: ALSA HD Audio patch for Intel Panther Point DeviceIDs
by Takashi Iwai 09 Oct '12

09 Oct '12

At Wed, 20 Apr 2011 10:59:57 -0700, Seth Heasley wrote: > > This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH. > > Signed-off-by: Seth Heasley <seth.heasley(a)intel.com> Applied now. Thanks. Takashi > --- > --- linux-2.6.39-rc3/sound/pci/hda/hda_intel.c.orig 2011-04-11 17:21:51.000000000 -0700 > +++ linux-2.6.39-rc3/sound/pci/hda/hda_intel.c 2011-04-14 11:44:40.000000000 -0700 > @@ -126,6 +126,7 @@ > "{Intel, ICH10}," > "{Intel, PCH}," > "{Intel, CPT}," > + "{Intel, PPT}," > "{Intel, PBG}," > "{Intel, SCH}," > "{ATI, SB450}," > @@ -2759,6 +2760,8 @@ > { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH }, > /* PBG */ > { PCI_DEVICE(0x8086, 0x1d20), .driver_data = AZX_DRIVER_PCH }, > + /* Panther Point */ > + { PCI_DEVICE(0x8086, 0x1e20), .driver_data = AZX_DRIVER_PCH }, > /* SCH */ > { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH }, > /* Generic Intel */ >

3 2

[alsa-devel] [PATCH] snd-usb-us122l: Fix missing NULL checks
by Karsten Wiese 27 Apr '12

27 Apr '12

Fix missing NULL checks in usb_stream_hwdep_poll() and usb_stream_hwdep_ioctl(). Wake up poll waiters before returning from usb_stream_hwdep_ioctl(). Signed-off-by: Karsten Wiese <fzu(a)wemgehoertderstaat.de> Cc: stable(a)kernel.org --- sound/usb/usx2y/us122l.c | 41 ++++++++++++++++++++--------------------- 1 files changed, 20 insertions(+), 21 deletions(-) diff --git a/sound/usb/usx2y/us122l.c b/sound/usb/usx2y/us122l.c index 91bb296..7abda8d 100644 --- a/sound/usb/usx2y/us122l.c +++ b/sound/usb/usx2y/us122l.c @@ -269,29 +269,26 @@ static unsigned int usb_stream_hwdep_poll(struct snd_hwdep *hw, struct file *file, poll_table *wait) { struct us122l *us122l = hw->private_data; - struct usb_stream *s = us122l->sk.s; unsigned *polled; unsigned int mask; poll_wait(file, &us122l->sk.sleep, wait); - switch (s->state) { - case usb_stream_ready: - if (us122l->first == file) - polled = &s->periods_polled; - else - polled = &us122l->second_periods_polled; - if (*polled != s->periods_done) { - *polled = s->periods_done; - mask = POLLIN | POLLOUT | POLLWRNORM; - break; + mask = POLLIN | POLLOUT | POLLWRNORM | POLLERR; + if (mutex_trylock(&us122l->mutex)) { + struct usb_stream *s = us122l->sk.s; + if (s && s->state == usb_stream_ready) { + if (us122l->first == file) + polled = &s->periods_polled; + else + polled = &us122l->second_periods_polled; + if (*polled != s->periods_done) { + *polled = s->periods_done; + mask = POLLIN | POLLOUT | POLLWRNORM; + } else + mask = 0; } - /* Fall through */ - mask = 0; - break; - default: - mask = POLLIN | POLLOUT | POLLWRNORM | POLLERR; - break; + mutex_unlock(&us122l->mutex); } return mask; } @@ -377,6 +374,7 @@ static int usb_stream_hwdep_ioctl(struct snd_hwdep *hw, struct file *file, { struct usb_stream_config *cfg; struct us122l *us122l = hw->private_data; + struct usb_stream *s; unsigned min_period_frames; int err = 0; bool high_speed; @@ -422,18 +420,18 @@ static int usb_stream_hwdep_ioctl(struct snd_hwdep *hw, struct file *file, snd_power_wait(hw->card, SNDRV_CTL_POWER_D0); mutex_lock(&us122l->mutex); + s = us122l->sk.s; if (!us122l->master) us122l->master = file; else if (us122l->master != file) { - if (memcmp(cfg, &us122l->sk.s->cfg, sizeof(*cfg))) { + if (!s || memcmp(cfg, &s->cfg, sizeof(*cfg))) { err = -EIO; goto unlock; } us122l->slave = file; } - if (!us122l->sk.s || - memcmp(cfg, &us122l->sk.s->cfg, sizeof(*cfg)) || - us122l->sk.s->state == usb_stream_xrun) { + if (!s || memcmp(cfg, &s->cfg, sizeof(*cfg)) || + s->state == usb_stream_xrun) { us122l_stop(us122l); if (!us122l_start(us122l, cfg->sample_rate, cfg->period_frames)) err = -EIO; @@ -444,6 +442,7 @@ unlock: mutex_unlock(&us122l->mutex); free: kfree(cfg); + wake_up_all(&us122l->sk.sleep); return err; } -- 1.7.2.3

2 5

[alsa-devel] [PATCH] ALSA: HDA: Remove unconnected PCM devices for Intel HDMI
by David Henningsson 01 Feb '12

01 Feb '12

Since I'm a little new in HDMI land and the patch is non-trivial, I wouldn't mind some comments on this one. Also thanks to Jaroslav who cleared a few things out about the logical and physical devices which helped me figure out what I should do about it :-) Anyway, here's the patch. Some newer chips have more than one HDMI output, but usually not all of them are exposed as physical jacks. Removing the unused PCM devices (as indicated by BIOS in the pin config default) will reduce user confusion as they currently have to choose between several HDMI devices, some of them not working anyway. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

4 14

[alsa-devel] [PATCH] ASoC: WM8903: Implement DMIC support
by Stephen Warren 14 Oct '11

14 Oct '11

In addition to the currently supported analog capture path, the WM8903 also supports digital mics. The analog and digital capture paths are exclusive; a mux is present to select the capture source. Logically, the mux exists to select the decimator's input, from either the ADC or DMIC block outputs. However, the ADC power domain also includes the DMIC interface. Consequently, this change represents the mux as existing immediately before the ADC, and selecting between the Input PGA and DMIC block outputs. An alternative might be to represent the mux in its correct location, and associate the ADC power enable controls with both the real ADC, and a fake ADC for the DMIC? Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- sound/soc/codecs/wm8903.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8903.c b/sound/soc/codecs/wm8903.c index d53f206..f3cab84 100644 --- a/sound/soc/codecs/wm8903.c +++ b/sound/soc/codecs/wm8903.c @@ -634,6 +634,13 @@ static const struct soc_enum lsidetone_enum = static const struct soc_enum rsidetone_enum = SOC_ENUM_SINGLE(WM8903_DAC_DIGITAL_0, 0, 3, sidetone_text); +static const char *adcinput_text[] = { + "ADC", "DMIC" +}; + +static const struct soc_enum adcinput_enum = + SOC_ENUM_SINGLE(WM8903_CLOCK_RATE_TEST_4, 9, 2, adcinput_text); + static const char *aif_text[] = { "Left", "Right" }; @@ -767,6 +774,9 @@ static const struct snd_kcontrol_new lsidetone_mux = static const struct snd_kcontrol_new rsidetone_mux = SOC_DAPM_ENUM("DACR Sidetone Mux", rsidetone_enum); +static const struct snd_kcontrol_new adcinput_mux = + SOC_DAPM_ENUM("ADC Input", adcinput_enum); + static const struct snd_kcontrol_new lcapture_mux = SOC_DAPM_ENUM("Left Capture Mux", lcapture_enum); @@ -817,6 +827,7 @@ SND_SOC_DAPM_INPUT("IN2L"), SND_SOC_DAPM_INPUT("IN2R"), SND_SOC_DAPM_INPUT("IN3L"), SND_SOC_DAPM_INPUT("IN3R"), +SND_SOC_DAPM_INPUT("DMICDAT"), SND_SOC_DAPM_OUTPUT("HPOUTL"), SND_SOC_DAPM_OUTPUT("HPOUTR"), @@ -842,6 +853,9 @@ SND_SOC_DAPM_MUX("Right Input Mode Mux", SND_SOC_NOPM, 0, 0, &rinput_mode_mux), SND_SOC_DAPM_PGA("Left Input PGA", WM8903_POWER_MANAGEMENT_0, 1, 0, NULL, 0), SND_SOC_DAPM_PGA("Right Input PGA", WM8903_POWER_MANAGEMENT_0, 0, 0, NULL, 0), +SND_SOC_DAPM_MUX("Left ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), +SND_SOC_DAPM_MUX("Right ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), + SND_SOC_DAPM_ADC("ADCL", NULL, WM8903_POWER_MANAGEMENT_6, 1, 0), SND_SOC_DAPM_ADC("ADCR", NULL, WM8903_POWER_MANAGEMENT_6, 0, 0), @@ -979,6 +993,11 @@ static const struct snd_soc_dapm_route wm8903_intercon[] = { { "Left Input PGA", NULL, "Left Input Mode Mux" }, { "Right Input PGA", NULL, "Right Input Mode Mux" }, + { "Left ADC Input", "ADC", "Left Input PGA" }, + { "Left ADC Input", "DMIC", "DMICDAT" }, + { "Right ADC Input", "ADC", "Right Input PGA" }, + { "Right ADC Input", "DMIC", "DMICDAT" }, + { "Left Capture Mux", "Left", "ADCL" }, { "Left Capture Mux", "Right", "ADCR" }, @@ -988,9 +1007,9 @@ static const struct snd_soc_dapm_route wm8903_intercon[] = { { "AIFTXL", NULL, "Left Capture Mux" }, { "AIFTXR", NULL, "Right Capture Mux" }, - { "ADCL", NULL, "Left Input PGA" }, + { "ADCL", NULL, "Left ADC Input" }, { "ADCL", NULL, "CLK_DSP" }, - { "ADCR", NULL, "Right Input PGA" }, + { "ADCR", NULL, "Right ADC Input" }, { "ADCR", NULL, "CLK_DSP" }, { "Left Playback Mux", "Left", "AIFRXL" }, -- 1.7.1

4 4

[alsa-devel] [PATCHv2] ASoC: omap-mcbsp: Do not attempt to change DAI sysclk if stream is active
by Jarkko Nikula 23 Sep '11

23 Sep '11

Attempt to change McBSP CLKS source while another stream is active is not safe after commit d135865 ("OMAP: McBSP: implement functional clock switching via clock framework") in 2.6.37. CLKS parent clock switching using clock framework have to idle the McBSP before switching and then activate it again. This short break can cause a DMA transaction error to already running stream which halts and recovers only by closing and restarting the stream. This goes more fatal after commit e2fa61d ("OMAP3: l3: Introduce l3-interconnect error handling driver") in 2.6.39 where l3 driver detects a severe timeout error and does BUG_ON(). Fix this by not changing any configuration in omap_mcbsp_dai_set_dai_sysclk if the McBSP is already active. This test should have been here just from the beginning anyway. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> Cc: stable(a)kernel.org --- v2: - Returns -EBUSY from omap_mcbsp_dai_set_dai_sysclk if the input clock rate doesn't match with another stream's configuration and 0 otherwise. For 2.6.37 and onward. This issue is valid to those machine drivers that use the McBSP as a DAI link master and are configuring the CLKS source (like sound/soc/omap/omap3pandora.c in mainline). --- sound/soc/omap/omap-mcbsp.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 07b7723..4b82290 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -516,6 +516,12 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai, struct omap_mcbsp_reg_cfg *regs = &mcbsp_data->regs; int err = 0; + if (mcbsp_data->active) + if (freq == mcbsp_data->in_freq) + return 0; + else + return -EBUSY; + /* The McBSP signal muxing functions are only available on McBSP1 */ if (clk_id == OMAP_MCBSP_CLKR_SRC_CLKR || clk_id == OMAP_MCBSP_CLKR_SRC_CLKX || -- 1.7.4.4

4 5

[alsa-devel] Noise on snd-hda-intel
by Sune Mølgaard 18 Sep '11

18 Sep '11

Plugging almost any headset into the front headset jacks on my machine results in noise in the headphones as well as in Skype conversations and/or recording. Said noise is, however not head in the regular speakers (except when playing back recordings, of course. lspci -vvnn gives 00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller [8086:3a3e] Subsystem: ASUSTeK Computer Inc. Device [1043:82ea] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 256 bytes Interrupt: pin A routed to IRQ 70 Region 0: Memory at f7ff8000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel and aplay -l gives **** List of PLAYBACK Hardware Devices **** card 0: Device [USB Multimedia Audio Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 I have tried with no modules options as well as options snd_hda_intel model=6stack and options snd_hda_intel model=6stack-dig Best regards, Sune Mølgaard -- You buy Windows, and you put it on your machine-you can't do a whole lot with it. - Bob Muglia, Microsoft Senior Vice President

4 14

[alsa-devel] Dell XPS 13 (Codec: IDT 92HD73C1X5) and 3 stereo jack output
by Ruben Van Boxem 14 Sep '11

14 Sep '11

Hi, I have been trying to get my Dell XPS 13 to output 5.1 sound through the stereo jacks (because the NVIDIA HDMI only does 2.1). Attached is alsa-info output. I can't seem to be able to set the Line/Mic In to output. I have tried several things, going from fiddling with Kmix to fiddling with the modprobe "model=" parameter, and even looking through the hda_analyzer.py output. This last one lifted a tiny corner of the solution, but I don't think a vanilla Alsa install will get me through this. In Windows, I can use the three jacks to output 2 channels each, so I am sure the hardware is capable of it. In HDA analyzer I can see that there are several "Line Out" entries, but since they all have the node cap "Unsolicited Capabilities", I'm pretty sure the problem is alsa not knowing about the, well, capabilities. I searched the web and documentation for anything sane to try, but nothing worked. The default modprobe "model=" is the best (I can get 4.0 output from the jacks, and everything works, except the third jack). If you need more input or information, please ask, I'm very willing to get this solved! Thanks, Ruben

2 3

[alsa-devel] asoc: no valid backend routes for PCM: SDP4430 Media
by hong zhang 19 Aug '11

19 Aug '11

List, After capturing data from DMIC on OMAP4 blaze board with kernel 2.6.38 and save wav data to 38.wav. But aplay complains "no valid backend routes". See following, $aplay -f dat 38.wav [ 157.167724] asoc: no valid backend routes for PCM: SDP4430 Media aplay: main:654: audio open error: Invalid argument $ uname -a Linux ubuntu 2.6.38.4+ #58 SMP PREEMPT Fri Jun 3 09:44:19 PDT 2011 armv7l GNU/Linux Does ALSA add new functionality of backend? Thanks. ---henry

3 10

[alsa-devel] [PATCH] ASoC: dapm - Refactor widget IO functions in preparation for platform widgets.
by Liam Girdwood 27 Jul '11

27 Jul '11

Currently widget IO is tightly coupled to the CODEC drivers. Future platform DSP devices have mixer components that can alter power usage and hence require full DAPM support. This provides a generic widget IO operation wrapper in preparation for future patches that implement platform driver DAPM. Signed-off-by: Liam Girdwood <lrg(a)ti.com> --- sound/soc/soc-dapm.c | 55 ++++++++++++++++++++++++++++++++++++++++++++----- 1 files changed, 49 insertions(+), 6 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 34106bc..7b7af9f 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -124,6 +124,49 @@ static inline struct snd_soc_dapm_widget *dapm_cnew_widget( return kmemdup(_widget, sizeof(*_widget), GFP_KERNEL); } +static int soc_widget_read(struct snd_soc_dapm_widget *w, int reg) +{ + if (w->codec) + return snd_soc_read(w->codec, reg); + return 0; +} + +static int soc_widget_write(struct snd_soc_dapm_widget *w,int reg, int val) +{ + if (w->codec) + return snd_soc_write(w->codec, reg, val); + return 0; +} + +int soc_widget_update_bits(struct snd_soc_dapm_widget *w, unsigned short reg, + unsigned int mask, unsigned int value) +{ + int change; + unsigned int old, new; + + old = soc_widget_read(w, reg); + new = (old & ~mask) | value; + change = old != new; + if (change) + soc_widget_write(w, reg, new); + + return change; +} + +int soc_widget_test_bits(struct snd_soc_dapm_widget *w, unsigned short reg, + unsigned int mask, unsigned int value) +{ + int change; + unsigned int old, new; + + old = soc_widget_read(w, reg); + new = (old & ~mask) | value; + change = old != new; + + return change; +} + + /** * snd_soc_dapm_set_bias_level - set the bias level for the system * @dapm: DAPM context @@ -181,7 +224,7 @@ static void dapm_set_path_status(struct snd_soc_dapm_widget *w, unsigned int mask = (1 << fls(max)) - 1; unsigned int invert = mc->invert; - val = snd_soc_read(w->codec, reg); + val = soc_widget_read(w, reg); val = (val >> shift) & mask; if ((invert && !val) || (!invert && val)) @@ -197,7 +240,7 @@ static void dapm_set_path_status(struct snd_soc_dapm_widget *w, for (bitmask = 1; bitmask < e->max; bitmask <<= 1) ; - val = snd_soc_read(w->codec, e->reg); + val = soc_widget_read(w, e->reg); item = (val >> e->shift_l) & (bitmask - 1); p->connect = 0; @@ -227,7 +270,7 @@ static void dapm_set_path_status(struct snd_soc_dapm_widget *w, w->kcontrol_news[i].private_value; int val, item; - val = snd_soc_read(w->codec, e->reg); + val = soc_widget_read(w, e->reg); val = (val >> e->shift_l) & e->mask; for (item = 0; item < e->max; item++) { if (val == e->values[item]) @@ -669,7 +712,7 @@ int dapm_reg_event(struct snd_soc_dapm_widget *w, else val = w->off_val; - snd_soc_update_bits(w->codec, -(w->reg + 1), + soc_widget_update_bits(w, -(w->reg + 1), w->mask << w->shift, val << w->shift); return 0; @@ -877,7 +920,7 @@ static void dapm_seq_run_coalesced(struct snd_soc_dapm_context *dapm, "pop test : Applying 0x%x/0x%x to %x in %dms\n", value, mask, reg, card->pop_time); pop_wait(card->pop_time); - snd_soc_update_bits(dapm->codec, reg, mask, value); + soc_widget_update_bits(w, reg, mask, value); } list_for_each_entry(w, pending, power_list) { @@ -1878,7 +1921,7 @@ int snd_soc_dapm_new_widgets(struct snd_soc_dapm_context *dapm) /* Read the initial power state from the device */ if (w->reg >= 0) { - val = snd_soc_read(w->codec, w->reg); + val = soc_widget_read(w, w->reg); val &= 1 << w->shift; if (w->invert) val = !val; -- 1.7.4.1

3 4