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

[alsa-devel] [HELP WANTED] ALSA Driver developer
by Gabriel Beddingfield 16 Aug '11

16 Aug '11

All: A recruiter approached me looking for an ALSA driver developer to enhance an existing driver. This is a short-term, off-site gig. Some details below. Please contact Mr. DeAmelio directly. Thanks, Gabriel ---------- Forwarded message ---------- From: David DeAmelio <david_deamelio(a)oxfordcorp.com> Date: Tue, Aug 16, 2011 at 2:29 PM Subject: Job Description - Oxford International To: gabrbedd(a)gmail.com Hey Gabriel, Here’s the description….Thanks. Location: OFFSITE Start Date: ASAP Duration: 1-2 Weeks Manager needs consultant to come onsite for 1st few days. Client will pay for flight there and back. Must: Linux ALSA Device Drivers—Alsa- advanced linux sound architecture Blackfin Plus: D2D: Consultant will be enhancing an audio driver to support a voice quality recorder __________________________________ David De Amelio Team Lead Software/Hardware Consulting Services Oxford International a division of Oxford Global Resources 100 Cummings Center Suite 206N Beverly, MA 01915 877.258.9982 x 7608 Office 978.922.7547 FAX david_deamelio(a)oxfordcorp.com www.oxfordcorp.com Oxford Europe The Right Talent. Right Now.® This e-mail, and any attachments thereto, is intended only for the addressee(s) named herein and may contain privileged and/or confidential information. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, immediately notify the sender by return e-mail and permanently delete the original, including any attachments thereto, and any copy and printout thereof.

1 0

Re: [alsa-devel] USB Audio questions
by Clemens Ladisch 16 Aug '11

16 Aug '11

Pierre-Louis Bossart wrote: > What is this USB frame counter and what would to enable its use, at > least for playback where there is scope for lots of power > optimizations. USB timing is defined by frames, of which there are about 1000 per second. The audio driver schedules one packet to be sent/received for each frame. Multiple packets are grouped in a URB (USB request buffer); the controller raises an interrupt when the last packet of the URB has been completed. By reading the current frame number, the driver could deduce how many packets (and therefore, how many samples) have been processed by the controller. > > Why more efficient? You cannot avoid double-buffering when a USB packet > > wraps around the end of the ALSA ring buffer. > > What I had in mind is a case where the ring buffer is divided in separate > periods, which would each correspond to an integer number of URBs/packets. This works only when the driver has control over how many samples actually are transmitted in each USB frame. The playback streams of many USB audio devices work this way, but quite a few others, and capture streams, don't. > It's probably less generic than the current driver but a whole lot > simpler/efficient. The code wouldn't be simpler because we'd still need the other algorithm. This would be just an optimization. Regards, Clemens

2 1

Re: [alsa-devel] USB Audio questions
by Clemens Ladisch 16 Aug '11

16 Aug '11

Pierre-Louis Bossart wrote: > - Is there any good reason why the max number of packets per urb defaults to > 8? Not really. It is an attempt to compromise between interrupt frequency and the latency resulting from packet queueing. > - Increasing the number of packets/urbs solves my power issue but not the > synchronization issue. If I reduce the number of urbs to reduce the > interrupt rate, then the accuracy of the hw_pointer is decreased big time > and it becomes difficult to synchronize with video. The .pointer routine > only keeps track of retired urbs, it seems there's no way to know how many > samples were played at a given time? Only the URB completion callback tells us about finished packets. For playback, we know how many bytes we had submitted, so we could derive the current position from the USB frame counter, but for capture, we don't know the precise byte count until the HCD has looked at the descriptors. > Isn't there a direct way to query the usb core to know how many bytes > have been transmitted and make the hw_ptr/delay information independent > of the urb buffer size? No, this information isn't returned earlier than the completion callback. It would be nice to be able to tell the HCD to collect information about all currently completed USB frames, regardless of whether the entire URB has finished or whether its interrupt flag is set, but this would require changes in all host controller drivers. (I'm contemplating something like this for FireWire, but there we have only one controller driver.) > - Is there any reason why the driver relies on vmalloc and memcpy? It seems > like using physically-contiguous memory would be more efficient, as done in > the CAIQ driver? Why more efficient? You cannot avoid double-buffering when a USB packet wraps around the end of the ALSA ring buffer. > - The period information is not updated when the urbs are allocated. In my > case the period specified was 25ms, but with all the approximations the > actual period (number of urbs*buffer_size_per_urb) was 24ms. Please note that URBs are usually not completely filled. For playback, the driver makes URBs shorter so that they end as nearly as possible on or after a period boundary; for capture, we cannot predict sample counts, so the driver just uses one URB per ms. Regards, Clemens

3 3

Re: [alsa-devel] USB Audio questions
by Pierre-Louis Bossart 16 Aug '11

16 Aug '11

> For USB 3.0 host controllers, the HCD doesn't get the information about > which frame exactly the transfer went out in. This is because all the > scheduling is done in hardware, not software. The xHCI driver can only > record the frame that was current when the interrupt for the URB > happened. > > Pierre, I'm not sure you can get the precise measurements you want out > of a USB 3.0 host controller to do the audio/video sync. You're > welcome > to suggest something to Steve McGowan to add to the xHCI spec, and you > should probably double check with him that what I'm saying is correct. Thanks Sarah for the heads-up. I was only looking at existing USB Audio solutions for now, looks like there's some work to be done for USB3 as well. We do need precise timing information for all audio drivers. Probably a good topic for LPC discussions... -Pierre

1 0

[alsa-devel] [PATCH] ASoC: Run Speyside WM8962 at 512fs
by Mark Brown 16 Aug '11

16 Aug '11

Ensure we have access to all the advanced DSP functinality offered by the WM8962 by running the system clock at 512fs. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/speyside_wm8962.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/speyside_wm8962.c b/sound/soc/samsung/speyside_wm8962.c index 0b9eb5f..753e1c2 100644 --- a/sound/soc/samsung/speyside_wm8962.c +++ b/sound/soc/samsung/speyside_wm8962.c @@ -28,13 +28,13 @@ static int speyside_wm8962_set_bias_level(struct snd_soc_card *card, if (dapm->bias_level == SND_SOC_BIAS_STANDBY) { ret = snd_soc_dai_set_pll(codec_dai, WM8962_FLL, WM8962_FLL_MCLK, 32768, - 44100 * 256); + 44100 * 512); if (ret < 0) pr_err("Failed to start FLL: %d\n", ret); ret = snd_soc_dai_set_sysclk(codec_dai, WM8962_SYSCLK_FLL, - 44100 * 256, + 44100 * 512, SND_SOC_CLOCK_IN); if (ret < 0) { pr_err("Failed to set SYSCLK: %d\n", ret); -- 1.7.5.4

1 0

[alsa-devel] [PATCH] ASoC: Clear completions from late WM8996 FLL lock IRQs
by Mark Brown 16 Aug '11

16 Aug '11

In case we have a pending completion, for example due to a problem with the input clock which got corrected after we timed out. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8996.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c index ab8e9d1..a44a0e5 100644 --- a/sound/soc/codecs/wm8996.c +++ b/sound/soc/codecs/wm8996.c @@ -2106,6 +2106,9 @@ static int wm8996_set_fll(struct snd_soc_codec *codec, int fll_id, int source, snd_soc_write(codec, WM8996_FLL_EFS_1, fll_div.lambda); + /* Clear any pending completions (eg, from failed startups) */ + try_wait_for_completion(&wm8996->fll_lock); + snd_soc_update_bits(codec, WM8996_FLL_CONTROL_1, WM8996_FLL_ENA, WM8996_FLL_ENA); -- 1.7.5.4

1 0

[alsa-devel] How to pair Wine with ALSA? part2: buffer&period size / blocking / mmap (long)
by Joerg-Cyril.Hoehle＠t-systems.com 16 Aug '11

16 Aug '11

Dear ALSA developers, [Please refer to part1:intro & underruns for the introductory text] http://mailman.alsa-project.org/pipermail/alsa-devel/2011-August/042746.html Topic T2 period and buffer size and time Wine apps using the old winmm API cannot tell at waveOutOpen time "give me a large buffer" or "give me fast reaction to explosions". R6 A good compromise is needed for when Wine opens ALSA on behalf of winmm. Years later, the mmdevapi introduced with Vista provides "period" and duration parameters. It also implements sort of a dmix device: it appears to mix at a fixed rate (48000 or 44100 samples/sec, user settable) and to mix data in packets of 10ms. Incidentally, that's why MS claims 10ms latency. For compatibility, Wine should match that rate -- at least when accessing the "default" device. Does that really translate to set_period_time? I doubt it. I wonder why Wine up to now insists on particular ALSA buffer and period sizes. I tend to consider it's none of its business. It might make sense for Wine to use a periodic timer that calls snd_pcm_write (see T3 below). *That* timer should be set to mmdevapi's 10ms. Doesn't that translate to set_period_time_*max*(10ms)? However if ALSA wants/requires 50ms, why not? Furthermore, if the app wants to use large buffers, why insist on a tiny period on the ALSA side? (MS appears to stick to 10ms packets regardless of the app's requested buffer size). I expect that setting Wine's timer period to at least ALSA's allows it to actually find room for new data each turn. So here's what makes sense to me: if (shared_mode && device=="default") set_period_time_near(10ms); else if (exclusive_mode) /* mmdevapi:Initialize receives period from the app */ set_period_time_near(clamp(3ms, app's wish in mmdevapi:Intialize, 100ms)); /* 100ms is arbitrary, why not 1s? */ snd_pcm_hw_params() wine_set_timer_rate(clamp(3ms, snd_pcm_get_period_time(), 0.5s)) Topic T2.b Duration / buffer size mmdevapi's Initialize method receives a duration parameter as a hint towards either small latency or large buffering. One would think that it makes perfect sense to forward that to snd_pcm_set_buffer_time. *However*, mmdevapi also requires to hand out a pointer to a buffer that large (GetBuffer). Thus Wine must maintain a buffer that large (possibly even two of them, for reasons not relevant here). Now should ALSA really keep yet another buffer that large? Isn't that precisely why people have gripes with PA's 2s buffer? I'm wondering whether Wine should solely rely on its periodic timer to regularly submit data and e.g. ask ALSA to use a buffer 3 times the period? 30ms (3x10ms) seems to play a role in MS systems. Dmix seems to prefer 4 to 6 times period size. Unfortunately, snd_pcm_get_period_time may be known only after invoking snd_pcm_hw_params(), so I can't express: set_period_time_near(10ms); set_buffer_time_near(3 x actual_period); Prefer set_buffer_time_near(3 x period_above); or simply not call set_buffer at all? Finally, there's that snd_pcm_sw_params_set_avail_min whose purpose I cannot figure out. Should Wine call snd_pcm_sw_params_set_avail_min(1); or snd_pcm_sw_params_set_avail_min(0); or not at all? Topic T3 blocking or not Wine has traditionally used ALSA in non-blocking mode, which ALSA people recommended against (still?). Now suppose every write is preceded with avail_update, for reasons I gave in part1: underruns. Remember my example from part 1, slightly refined: if (snd_pcm_avail_update(&avail) > buffer_size) snd_pcm_reset() /* skip over late samples */ /* should be equivalent to snd_pcm_forward(avail) */ written = snd_pcm_write(min(avail,frames)); My understanding of the semantics is that write(<avail) will not block, thus Wine could as well dispose of SND_PCM_NONBLOCK. In the NONBLOCK case, this could be simplified to written = snd_pcm_write(frames); since I discovered that ALSA can write a little more than what avail returns, and NONBLOCK implies it'll not wait in an attempt to write a 2s data buffer, but return written < frames instead. Actually, I've a slightly more elaborate sequence in mind. I've read that snd_pcm_open() may be delayed because of networking issues, which I want to avoid in the audio thread. Therefore I'm considering using: snd_pcm_open(SND_PCM_NONBLOCK); ... setup hw&sw_params snd_pcm_prepare() snd_pcm_nonblock(0); /* or should it be called before prepare? */ I.e. allow blocking while playing, which does not actually happen thanks to avail_update() and a push model based on periodic timers to feed data with pcm_write(). Note that so far, I've not questioned whether a timer-based push model actually makes sense for Wine with ALSA... Topic T4 mmap After I re-read the mmdevapi documentation, I believe that mmdevapi's GetBuffer/ReleaseBuffer rendering protocol may be compatible with ALSA's snd_pcm_mmap_begin+commit after all. It all depends on whether ALSA grants requests for sizes as large as buffer_size, with buffer_size up to 2 seconds * samples/sec. Hence, as an optimization, one could imagine a driver using mmap, like Winealsa used to have prior to the 2011 rewrite. Yet it always had the fallback without mmap, so let's concentrate on the non-mmap case initially and get that right. Thank you for your help and for reading up to this point, Jörg Höhle

2 3

Re: [alsa-devel] USB Audio questions
by David Henningsson 16 Aug '11

16 Aug '11

On 08/15/2011 10:31 PM, Pierre-Louis Bossart wrote: > - Increasing the number of packets/urbs solves my power issue but not the > synchronization issue. If I reduce the number of urbs to reduce the > interrupt rate, then the accuracy of the hw_pointer is decreased big time > and it becomes difficult to synchronize with video. I think the same thing is a problem for quite a few other devices as well - I wonder if we need some kind of "pointer granularity" variable to be exported through the ALSA API? PulseAudio could use that to determine whether or not to enable timer-based scheduling. And in these cases, maybe a call to hw_pointer could return hw_pointer and time, and then PulseAudio etc could use that for extrapolation (or the extrapolation could be done in alsa-lib). -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

2 1

[alsa-devel] [PATCH] ASoC: Implement WM8994 thermal warning and shutdown interrupt support
by Mark Brown 16 Aug '11

16 Aug '11

ALSA doesn't really have good mechanisms for dealing with these so we just log them - the hardware already has automatic shutdown support. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 26 ++++++++++++++++++++++++++ 1 files changed, 26 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index a0d6274..9412491 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -3045,6 +3045,24 @@ static irqreturn_t wm8994_fifo_error(int irq, void *data) return IRQ_HANDLED; } +static irqreturn_t wm8994_temp_warn(int irq, void *data) +{ + struct snd_soc_codec *codec = data; + + dev_err(codec->dev, "Thermal warning\n"); + + return IRQ_HANDLED; +} + +static irqreturn_t wm8994_temp_shut(int irq, void *data) +{ + struct snd_soc_codec *codec = data; + + dev_crit(codec->dev, "Thermal shutdown\n"); + + return IRQ_HANDLED; +} + static int wm8994_codec_probe(struct snd_soc_codec *codec) { struct wm8994 *control; @@ -3123,6 +3141,10 @@ static int wm8994_codec_probe(struct snd_soc_codec *codec) wm8994_request_irq(codec->control_data, WM8994_IRQ_FIFOS_ERR, wm8994_fifo_error, "FIFO error", codec); + wm8994_request_irq(wm8994->wm8994, WM8994_IRQ_TEMP_WARN, + wm8994_temp_warn, "Thermal warning", codec); + wm8994_request_irq(wm8994->wm8994, WM8994_IRQ_TEMP_SHUT, + wm8994_temp_shut, "Thermal shutdown", codec); ret = wm8994_request_irq(codec->control_data, WM8994_IRQ_DCS_DONE, wm_hubs_dcs_done, "DC servo done", @@ -3387,6 +3409,8 @@ err_irq: wm8994_free_irq(codec->control_data, WM8994_IRQ_DCS_DONE, &wm8994->hubs); wm8994_free_irq(codec->control_data, WM8994_IRQ_FIFOS_ERR, codec); + wm8994_free_irq(codec->control_data, WM8994_IRQ_TEMP_SHUT, codec); + wm8994_free_irq(codec->control_data, WM8994_IRQ_TEMP_WARN, codec); err: kfree(wm8994); return ret; @@ -3409,6 +3433,8 @@ static int wm8994_codec_remove(struct snd_soc_codec *codec) wm8994_free_irq(codec->control_data, WM8994_IRQ_DCS_DONE, &wm8994->hubs); wm8994_free_irq(codec->control_data, WM8994_IRQ_FIFOS_ERR, codec); + wm8994_free_irq(codec->control_data, WM8994_IRQ_TEMP_SHUT, codec); + wm8994_free_irq(codec->control_data, WM8994_IRQ_TEMP_WARN, codec); switch (control->type) { case WM8994: -- 1.7.5.4

1 0

[alsa-devel] [PATCH] ASoC: Add WM8958 noise gate support
by Mark Brown 16 Aug '11

16 Aug '11

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/linux/mfd/wm8994/registers.h | 45 ++++++++++++++++++++++++++++++++++ sound/soc/codecs/wm8994-tables.c | 12 ++++---- sound/soc/codecs/wm8994.c | 38 ++++++++++++++++++++++++++++ 3 files changed, 89 insertions(+), 6 deletions(-) diff --git a/include/linux/mfd/wm8994/registers.h b/include/linux/mfd/wm8994/registers.h index 54dbaa9..d7be463 100644 --- a/include/linux/mfd/wm8994/registers.h +++ b/include/linux/mfd/wm8994/registers.h @@ -138,6 +138,8 @@ #define WM8994_AIF1_DAC1_FILTERS_2 0x421 #define WM8994_AIF1_DAC2_FILTERS_1 0x422 #define WM8994_AIF1_DAC2_FILTERS_2 0x423 +#define WM8958_AIF1_DAC1_NOISE_GATE 0x430 +#define WM8958_AIF1_DAC2_NOISE_GATE 0x431 #define WM8994_AIF1_DRC1_1 0x440 #define WM8994_AIF1_DRC1_2 0x441 #define WM8994_AIF1_DRC1_3 0x442 @@ -195,6 +197,7 @@ #define WM8994_AIF2_ADC_FILTERS 0x510 #define WM8994_AIF2_DAC_FILTERS_1 0x520 #define WM8994_AIF2_DAC_FILTERS_2 0x521 +#define WM8958_AIF2_DAC_NOISE_GATE 0x530 #define WM8994_AIF2_DRC_1 0x540 #define WM8994_AIF2_DRC_2 0x541 #define WM8994_AIF2_DRC_3 0x542 @@ -3040,6 +3043,34 @@ #define WM8994_AIF1DAC2_3D_ENA_WIDTH 1 /* AIF1DAC2_3D_ENA */ /* + * R1072 (0x430) - AIF1 DAC1 Noise Gate + */ +#define WM8958_AIF1DAC1_NG_HLD_MASK 0x0060 /* AIF1DAC1_NG_HLD - [6:5] */ +#define WM8958_AIF1DAC1_NG_HLD_SHIFT 5 /* AIF1DAC1_NG_HLD - [6:5] */ +#define WM8958_AIF1DAC1_NG_HLD_WIDTH 2 /* AIF1DAC1_NG_HLD - [6:5] */ +#define WM8958_AIF1DAC1_NG_THR_MASK 0x000E /* AIF1DAC1_NG_THR - [3:1] */ +#define WM8958_AIF1DAC1_NG_THR_SHIFT 1 /* AIF1DAC1_NG_THR - [3:1] */ +#define WM8958_AIF1DAC1_NG_THR_WIDTH 3 /* AIF1DAC1_NG_THR - [3:1] */ +#define WM8958_AIF1DAC1_NG_ENA 0x0001 /* AIF1DAC1_NG_ENA */ +#define WM8958_AIF1DAC1_NG_ENA_MASK 0x0001 /* AIF1DAC1_NG_ENA */ +#define WM8958_AIF1DAC1_NG_ENA_SHIFT 0 /* AIF1DAC1_NG_ENA */ +#define WM8958_AIF1DAC1_NG_ENA_WIDTH 1 /* AIF1DAC1_NG_ENA */ + +/* + * R1073 (0x431) - AIF1 DAC2 Noise Gate + */ +#define WM8958_AIF1DAC2_NG_HLD_MASK 0x0060 /* AIF1DAC2_NG_HLD - [6:5] */ +#define WM8958_AIF1DAC2_NG_HLD_SHIFT 5 /* AIF1DAC2_NG_HLD - [6:5] */ +#define WM8958_AIF1DAC2_NG_HLD_WIDTH 2 /* AIF1DAC2_NG_HLD - [6:5] */ +#define WM8958_AIF1DAC2_NG_THR_MASK 0x000E /* AIF1DAC2_NG_THR - [3:1] */ +#define WM8958_AIF1DAC2_NG_THR_SHIFT 1 /* AIF1DAC2_NG_THR - [3:1] */ +#define WM8958_AIF1DAC2_NG_THR_WIDTH 3 /* AIF1DAC2_NG_THR - [3:1] */ +#define WM8958_AIF1DAC2_NG_ENA 0x0001 /* AIF1DAC2_NG_ENA */ +#define WM8958_AIF1DAC2_NG_ENA_MASK 0x0001 /* AIF1DAC2_NG_ENA */ +#define WM8958_AIF1DAC2_NG_ENA_SHIFT 0 /* AIF1DAC2_NG_ENA */ +#define WM8958_AIF1DAC2_NG_ENA_WIDTH 1 /* AIF1DAC2_NG_ENA */ + +/* * R1088 (0x440) - AIF1 DRC1 (1) */ #define WM8994_AIF1DRC1_SIG_DET_RMS_MASK 0xF800 /* AIF1DRC1_SIG_DET_RMS - [15:11] */ @@ -3651,6 +3682,20 @@ #define WM8994_AIF2DAC_3D_ENA_WIDTH 1 /* AIF2DAC_3D_ENA */ /* + * R1328 (0x530) - AIF2 DAC Noise Gate + */ +#define WM8958_AIF2DAC_NG_HLD_MASK 0x0060 /* AIF2DAC_NG_HLD - [6:5] */ +#define WM8958_AIF2DAC_NG_HLD_SHIFT 5 /* AIF2DAC_NG_HLD - [6:5] */ +#define WM8958_AIF2DAC_NG_HLD_WIDTH 2 /* AIF2DAC_NG_HLD - [6:5] */ +#define WM8958_AIF2DAC_NG_THR_MASK 0x000E /* AIF2DAC_NG_THR - [3:1] */ +#define WM8958_AIF2DAC_NG_THR_SHIFT 1 /* AIF2DAC_NG_THR - [3:1] */ +#define WM8958_AIF2DAC_NG_THR_WIDTH 3 /* AIF2DAC_NG_THR - [3:1] */ +#define WM8958_AIF2DAC_NG_ENA 0x0001 /* AIF2DAC_NG_ENA */ +#define WM8958_AIF2DAC_NG_ENA_MASK 0x0001 /* AIF2DAC_NG_ENA */ +#define WM8958_AIF2DAC_NG_ENA_SHIFT 0 /* AIF2DAC_NG_ENA */ +#define WM8958_AIF2DAC_NG_ENA_WIDTH 1 /* AIF2DAC_NG_ENA */ + +/* * R1344 (0x540) - AIF2 DRC (1) */ #define WM8994_AIF2DRC_SIG_DET_RMS_MASK 0xF800 /* AIF2DRC_SIG_DET_RMS - [15:11] */ diff --git a/sound/soc/codecs/wm8994-tables.c b/sound/soc/codecs/wm8994-tables.c index 428d4c5..43e6603 100644 --- a/sound/soc/codecs/wm8994-tables.c +++ b/sound/soc/codecs/wm8994-tables.c @@ -1073,8 +1073,8 @@ const struct wm8994_access_mask wm8994_access_masks[WM8994_CACHE_SIZE] = { { 0x0000, 0x0000 }, /* R1069 */ { 0x0000, 0x0000 }, /* R1070 */ { 0x0000, 0x0000 }, /* R1071 */ - { 0x0000, 0x0000 }, /* R1072 */ - { 0x0000, 0x0000 }, /* R1073 */ + { 0x006F, 0x006F }, /* R1072 - AIF1 DAC1 Noise Gate */ + { 0x006F, 0x006F }, /* R1073 - AIF1 DAC2 Noise Gate */ { 0x0000, 0x0000 }, /* R1074 */ { 0x0000, 0x0000 }, /* R1075 */ { 0x0000, 0x0000 }, /* R1076 */ @@ -1329,7 +1329,7 @@ const struct wm8994_access_mask wm8994_access_masks[WM8994_CACHE_SIZE] = { { 0x0000, 0x0000 }, /* R1325 */ { 0x0000, 0x0000 }, /* R1326 */ { 0x0000, 0x0000 }, /* R1327 */ - { 0x0000, 0x0000 }, /* R1328 */ + { 0x006F, 0x006F }, /* R1328 - AIF2 DAC Noise Gate */ { 0x0000, 0x0000 }, /* R1329 */ { 0x0000, 0x0000 }, /* R1330 */ { 0x0000, 0x0000 }, /* R1331 */ @@ -2646,8 +2646,8 @@ const u16 wm8994_reg_defaults[WM8994_CACHE_SIZE] = { 0x0000, /* R1069 */ 0x0000, /* R1070 */ 0x0000, /* R1071 */ - 0x0000, /* R1072 */ - 0x0000, /* R1073 */ + 0x0068, /* R1072 - AIF1 DAC1 Noise Gate */ + 0x0068, /* R1073 - AIF1 DAC2 Noise Gate */ 0x0000, /* R1074 */ 0x0000, /* R1075 */ 0x0000, /* R1076 */ @@ -2902,7 +2902,7 @@ const u16 wm8994_reg_defaults[WM8994_CACHE_SIZE] = { 0x0000, /* R1325 */ 0x0000, /* R1326 */ 0x0000, /* R1327 */ - 0x0000, /* R1328 */ + 0x0068, /* R1328 - AIF2 DAC Noise Gate */ 0x0000, /* R1329 */ 0x0000, /* R1330 */ 0x0000, /* R1331 */ diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index f328369..c45b634 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -299,6 +299,7 @@ static const DECLARE_TLV_DB_SCALE(st_tlv, -3600, 300, 0); static const DECLARE_TLV_DB_SCALE(wm8994_3d_tlv, -1600, 183, 0); static const DECLARE_TLV_DB_SCALE(eq_tlv, -1200, 100, 0); static const DECLARE_TLV_DB_SCALE(mixin_boost_tlv, 0, 900, 0); +static const DECLARE_TLV_DB_SCALE(ng_tlv, -10200, 600, 0); #define WM8994_DRC_SWITCH(xname, reg, shift) \ { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \ @@ -678,8 +679,45 @@ SOC_SINGLE_TLV("AIF2 EQ5 Volume", WM8994_AIF2_EQ_GAINS_2, 6, 31, 0, eq_tlv), }; +static const char *wm8958_ng_text[] = { + "30ms", "125ms", "250ms", "500ms", +}; + +static const struct soc_enum wm8958_aif1dac1_ng_hold = + SOC_ENUM_SINGLE(WM8958_AIF1_DAC1_NOISE_GATE, + WM8958_AIF1DAC1_NG_THR_SHIFT, 4, wm8958_ng_text); + +static const struct soc_enum wm8958_aif1dac2_ng_hold = + SOC_ENUM_SINGLE(WM8958_AIF1_DAC2_NOISE_GATE, + WM8958_AIF1DAC2_NG_THR_SHIFT, 4, wm8958_ng_text); + +static const struct soc_enum wm8958_aif2dac_ng_hold = + SOC_ENUM_SINGLE(WM8958_AIF2_DAC_NOISE_GATE, + WM8958_AIF2DAC_NG_THR_SHIFT, 4, wm8958_ng_text); + static const struct snd_kcontrol_new wm8958_snd_controls[] = { SOC_SINGLE_TLV("AIF3 Boost Volume", WM8958_AIF3_CONTROL_2, 10, 3, 0, aif_tlv), + +SOC_SINGLE("AIF1DAC1 Noise Gate Switch", WM8958_AIF1_DAC1_NOISE_GATE, + WM8958_AIF1DAC1_NG_ENA_SHIFT, 1, 0), +SOC_ENUM("AIF1DAC1 Noise Gate Hold Time", wm8958_aif1dac1_ng_hold), +SOC_SINGLE_TLV("AIF1DAC1 Noise Gate Threshold Volume", + WM8958_AIF1_DAC1_NOISE_GATE, WM8958_AIF1DAC1_NG_THR_SHIFT, + 7, 1, ng_tlv), + +SOC_SINGLE("AIF1DAC2 Noise Gate Switch", WM8958_AIF1_DAC2_NOISE_GATE, + WM8958_AIF1DAC2_NG_ENA_SHIFT, 1, 0), +SOC_ENUM("AIF1DAC2 Noise Gate Hold Time", wm8958_aif1dac2_ng_hold), +SOC_SINGLE_TLV("AIF1DAC2 Noise Gate Threshold Volume", + WM8958_AIF1_DAC2_NOISE_GATE, WM8958_AIF1DAC2_NG_THR_SHIFT, + 7, 1, ng_tlv), + +SOC_SINGLE("AIF2DAC Noise Gate Switch", WM8958_AIF2_DAC_NOISE_GATE, + WM8958_AIF2DAC_NG_ENA_SHIFT, 1, 0), +SOC_ENUM("AIF2DAC Noise Gate Hold Time", wm8958_aif2dac_ng_hold), +SOC_SINGLE_TLV("AIF2DAC Noise Gate Threshold Volume", + WM8958_AIF2_DAC_NOISE_GATE, WM8958_AIF2DAC_NG_THR_SHIFT, + 7, 1, ng_tlv), }; static const struct snd_kcontrol_new wm1811_snd_controls[] = { -- 1.7.5.4

1 0