March 2018 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ALSA: usb-audio: fix memory leak on cval
by Colin King 27 Mar '18

27 Mar '18

From: Colin Ian King <colin.king(a)canonical.com> With the current exit return path of the ctl_info allocation failure cval is not being freed resulting in a memory leak. Fix this by kfree'ing it on the return. Detected by CoverityScan, CID#1466878 ("Resource Leak") Fixes: 21e9b3e931f7 ("ALSA: usb-audio: fix uac control query argument") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/usb/mixer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index 04dab6f65535..301ad61ed426 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -1365,8 +1365,10 @@ static void build_feature_ctl(struct mixer_build *state, void *raw_desc, cval->cmask = ctl_mask; ctl_info = get_feature_control_info(control); - if (!ctl_info) + if (!ctl_info) { + kfree(cval); return; + } if (state->mixer->protocol == UAC_VERSION_1) cval->val_type = ctl_info->type; else /* UAC_VERSION_2 */ -- 2.15.1

2 1

Re: [alsa-devel] [PATCH] [sound] hdac-codec runtime suspended at PM:Suspend.
by Subhransu S. Prusty 27 Mar '18

27 Mar '18

On Thu, Mar 15, 2018 at 09:02:30PM +0530, Anshuman Gupta wrote: > On Thu, Mar 15, 2018 at 04:12:44PM +0530, Subhransu S. Prusty wrote: > > On Wed, Mar 14, 2018 at 09:07:14PM +0530, Anshuman Gupta wrote: > > > On Wed, Mar 14, 2018 at 11:53:58AM +0100, Rafael J. Wysocki wrote: > > > > On Wed, Mar 14, 2018 at 11:38 AM, Anshuman Gupta > > > > <anshuman.gupta(a)intel.com> wrote: > > > > > On Mon, Mar 12, 2018 at 12:26:53PM +0100, Rafael J. Wysocki wrote: > > > > >> On Mon, Mar 12, 2018 at 12:17 PM, Anshuman Gupta > > > > >> <anshuman.gupta(a)intel.com> wrote: > > > > >> > > > > > >> > + if (pm_runtime_status_suspended(dev)) > > > > >> > + return; > > > > >> > > > > >> That, again, is somewhat fragile from the concurrency perspective. > > > > >> > > > > > > > > And here you want to avoid the below if the device is still suspended. > > > Yes, if we do not avoid the code below, complete callback takes about > > > 3 seconds due to snd_hdac_codec_read timed out because hdac controller > > > would be in runtime suspend state. > > > > > > > > Why is the below code located in the ->complete callback anyway? > > > > Shouldn't it be there in the ->resume one? > > > > > > > Yes even i am also having same doubt, why these power down and power up > > > sequences are part of prepare and complete callback. > > > Adding driver author "Subhransu S. Prusty" to provide more inputs on this. > > > > This driver needs a late resume as it receives a jack notification from the > > i915 driver and the skl controller driver resume may not have happened and > > in turn hda controller may not ready. This ensures a synchronization for > > jack event during resume from S3. > Let me give you insight of the issue, this driver blocks the direct complete > of hda controller PCI 00:1f.3, sometimes it takes 280ms to resume hda controller > from S3 and s2idle. So it does not make sense to suspend/resume hda controller > when it is already in runtime suspend. I get it now. I think this patch needs rework to address both the issues. > > > > I think this patch defeats the purpose. > Here in this case PCI driver may kick the direct complete for hda controller > https://elixir.bootlin.com/linux/latest/source/drivers/pci/pci-driver.c#L691 > But hdac hdmi codec driver is blocking it. > So i think it will be ok to keep this codec and hda controller in runtime > suspend while entering S3 or s2idle, both can resume by runtime PM as well, > will it brake any audio functionality? There was some PM and jack detection issues (I don't recollect now) because of which this was added. This was due to the gfx display power and hda controller synchronization. The rework may be required in both hdac_hdmi and skylake drivers. Regards, Subhransu > > > > Regards, > > Subhransu > > > > > > >> > /* Power up afg */ > > > > >> > snd_hdac_codec_read(hdac, hdac->afg, 0, AC_VERB_SET_POWER_STATE, > > > > >> > AC_PWRST_D0); > > > > >> > -- > > > > >> > 2.7.4 > > > > > > -- > > > Thanks, > > > Anshuman > > > > -- > > -- > Thanks, > Anshuman --

3 2

[alsa-devel] [bug report] ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams
by Dan Carpenter 27 Mar '18

27 Mar '18

Hello Takashi Iwai, The patch 40cab6e88cb0: "ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams" from Mar 23, 2018, leads to the following static checker warning: sound/core/oss/pcm_oss.c:1741 snd_pcm_oss_set_rate() warn: inconsistent returns 'mutex:&runtime->oss.params_lock'. Locked on: line 1734 Unlocked on: line 1732 line 1741 sound/core/oss/pcm_oss.c 1717 static int snd_pcm_oss_set_rate(struct snd_pcm_oss_file *pcm_oss_file, int rate) 1718 { 1719 int idx; 1720 1721 for (idx = 1; idx >= 0; --idx) { 1722 struct snd_pcm_substream *substream = pcm_oss_file->streams[idx]; 1723 struct snd_pcm_runtime *runtime; 1724 if (substream == NULL) 1725 continue; 1726 runtime = substream->runtime; 1727 if (rate < 1000) 1728 rate = 1000; 1729 else if (rate > 192000) 1730 rate = 192000; 1731 if (mutex_lock_interruptible(&runtime->oss.params_lock)) 1732 return -ERESTARTSYS; 1733 if (atomic_read(&runtime->oss.rw_ref)) 1734 return -EBUSY; ^^^^^^^^^^^^^ Unlock before returning? 1735 if (runtime->oss.rate != rate) { 1736 runtime->oss.params = 1; 1737 runtime->oss.rate = rate; 1738 } 1739 mutex_unlock(&runtime->oss.params_lock); 1740 } 1741 return snd_pcm_oss_get_rate(pcm_oss_file); 1742 } regards, dan carpenter

2 2

[alsa-devel] [PATCH] ALSA: pcm: potential uninitialized return values
by Dan Carpenter 27 Mar '18

27 Mar '18

Smatch complains that "tmp" can be uninitialized if we do a zero size write. Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/core/oss/pcm_oss.c b/sound/core/oss/pcm_oss.c index a9082f219561..40852c595453 100644 --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -1364,7 +1364,7 @@ static ssize_t snd_pcm_oss_write2(struct snd_pcm_substream *substream, const cha static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes) { size_t xfer = 0; - ssize_t tmp; + ssize_t tmp = 0; struct snd_pcm_runtime *runtime = substream->runtime; if (atomic_read(&substream->mmap_count)) @@ -1474,7 +1474,7 @@ static ssize_t snd_pcm_oss_read2(struct snd_pcm_substream *substream, char *buf, static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes) { size_t xfer = 0; - ssize_t tmp; + ssize_t tmp = 0; struct snd_pcm_runtime *runtime = substream->runtime; if (atomic_read(&substream->mmap_count))

2 1

[alsa-devel] Disable DAPM for click avoidance ?
by Ricard Wanderlof 27 Mar '18

27 Mar '18

I'm having an issue with a codec where the normal DAPM procedure of disabling most of the codec when there is no stream ongoing results in large clicks when a playback stream starts and stops, because the output jumps from 0V when the output is disabled to over a volt when the output is enabled. There appears to be a 'slow stop/start' feature in the codec, however, it takes about one second to ramp up and down the output voltage, and that is too long a delay when starting a stream. In our usecase the power consumtion of the codec is negligable compared to the rest of the electronics, so leaving the codec running at all times is perfectly feasible. Is there any way from a machine driver to disable the DAPM switching, i.e. leave parts of the codec running at all times? In this specific case, there are two internal PM controls which enable the output. One of them is controlled by an output mixer element (SND_SOC_DAPM_MIXER_E), and the other one from set_bias_level(). I've had a look in the core code, but it seems that the whole business of changing the bias level when a stream is started is always performed and that there is no way to say "Set the bias level to ON and leave it there". An alternative would be to augment the codec driver with an 'always on' feature, which effectively always enables PM for certain parts of the chip. But it seems like the wrong place to do this type of thing. Another use for this feature is that we have had a lot of problems over the years with buggy I2S interfaces misbehaving when streams are started and stopped, and there would be an advantage to letting the AIF run the whole time after startup. /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 11

[alsa-devel] [PATCH v2 0/3] ASoC: Add Multi CPU DAI support
by Shreyas NC 27 Mar '18

27 Mar '18

As discussed in [1], ASoC core supports multi codec DAIs on a DAI link. However it does not do so for CPU DAIs. So, add support for multi CPU DAIs on a DAI Link by adding multi CPU DAI in Card instantiation, suspend and resume functions, PCM ops, stream handling functions and DAPM. [1]: https://www.spinics.net/lists/alsa-devel/msg71369.html Changes in v2: - Addressed review comments by Charles - Rebased on latest for-next branch Shreyas NC (3): ASoC: Add initial support for multiple CPU DAIs ASoC: Add Multi CPU DAI support for PCM ops ASoC: Add Multi CPU DAI support in DAPM include/sound/soc.h | 5 + sound/soc/soc-core.c | 283 ++++++++++++++++++++---------- sound/soc/soc-dapm.c | 71 +++++--- sound/soc/soc-pcm.c | 483 +++++++++++++++++++++++++++++++++------------------ 4 files changed, 564 insertions(+), 278 deletions(-) -- 2.7.4

1 3

[alsa-devel] [PATCH] ALSA: aloop: Mark paused device as inactive
by Robert Rosengren 27 Mar '18

27 Mar '18

Show paused ALSA aloop device as inactive, i.e. the control "PCM Slave Active" set as false. Notification sent upon state change. This makes it possible for client capturing from aloop device to know if data is expected. Without it the client expects data even if playback is paused. Signed-off-by: Robert Rosengren <robertr(a)axis.com> --- sound/drivers/aloop.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c index 0333143a1fa7..5404ab11132d 100644 --- a/sound/drivers/aloop.c +++ b/sound/drivers/aloop.c @@ -291,6 +291,8 @@ static int loopback_trigger(struct snd_pcm_substream *substream, int cmd) cable->pause |= stream; loopback_timer_stop(dpcm); spin_unlock(&cable->lock); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + loopback_active_notify(dpcm); break; case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: case SNDRV_PCM_TRIGGER_RESUME: @@ -299,6 +301,8 @@ static int loopback_trigger(struct snd_pcm_substream *substream, int cmd) cable->pause &= ~stream; loopback_timer_start(dpcm); spin_unlock(&cable->lock); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + loopback_active_notify(dpcm); break; default: return -EINVAL; @@ -879,9 +883,11 @@ static int loopback_active_get(struct snd_kcontrol *kcontrol, [kcontrol->id.subdevice][kcontrol->id.device ^ 1]; unsigned int val = 0; - if (cable != NULL) - val = (cable->running & (1 << SNDRV_PCM_STREAM_PLAYBACK)) ? - 1 : 0; + if (cable != NULL) { + unsigned int running = cable->running ^ cable->pause; + + val = (running & (1 << SNDRV_PCM_STREAM_PLAYBACK)) ? 1 : 0; + } ucontrol->value.integer.value[0] = val; return 0; } -- 2.11.0

2 3

[alsa-devel] Question about cpu_dai/codec_dai unbalance
by Kuninori Morimoto 27 Mar '18

27 Mar '18

Hi Mark, ALSA ML Now, I'm investigating cpu_dai/codec_dai, and I noticed there are many unbalance. For example, snd_soc_suspend(), it calls .digital_mute() only for codec_dai, not for cpc_dai, and, calls .suspend() only for cpu_dai, not for codec_dai. It seems there are many unbalance like this on ALSA SoC. I know it is case-by-case, but I think we can have more balance. For example above snd_soc_suspend() case, .digital_mute() is very common for both cpu/codec I think, and, codec can have .suspend() ? But what do you think ? I think it doesn't breaks current system, because each cpu_dai doesn't have .digital_mute(), and codec_dai doesn't have .suspend() for now. Thus, nothing happen if I added it. The reason why I'm asking is that now, I'm thinking to merge cpu_dai/codec_dai into one dai list somehow. This means, we can have non-categorized DAI, this is same as previous codec/platform replacement into component. Then, this kind of DAI unbalance might be problem. Best regards --- Kuninori Morimoto

1 0

[alsa-devel] two cards as one [frederik@ofb.net: [Alsa-user] the mythical "el-cheapo"]
by frederik＠ofb.net 27 Mar '18

27 Mar '18

Dear ALSA devel, I'm forwarding a message I sent to ALSA-user a week ago; it didn't get any replies. It asks some questions about combining stereo devices into a single multi-channel device. Is this the right place to ask? I'll summarize because maybe the original message was a bit verbose: 1. Is this document still correct (i.e. saying that ALSA doesn't do any resampling when you combine two devices in a "multi" configuration): https://github.com/opensrc/alsa/blob/master/lib/md/TwoCardsAsOne.md 2. What is the best way to combine output devices? Pulseaudio? 3. Is there a way to configure an ALSA pcm which routes to a non-default Pulseaudio sink? Thanks, Frederick ----- Forwarded message from frederik(a)ofb.net ----- Date: Mon, 19 Mar 2018 19:10:47 -0700 From: frederik(a)ofb.net To: alsa-user(a)lists.sourceforge.net Subject: [Alsa-user] the mythical "el-cheapo" X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Level: User-Agent: Mutt/1.9.4 (2018-02-28) X-My-Message-ID: <20180320021047.GA4304(a)ofb.net>#2 X-My-Tags: inbox alsa-user Dear ALSA user, I am trying to develop some software to use for a custom sound-masking system where I live (to e.g. mask the sound of construction beeping going on outside). It is crucial to have more than two speakers, because if you can tell where the noise is coming from then it becomes distracting. But I would want this to be an inexpensive solution for students and such and so I don't want to depend on a surround sound system being present. So currently I'm using three $7 USB stereo sound adapters, which control six speakers. For various reasons it would be good for me to be able to combine the USB cards into one audio device. One reason is that users might want to play music on the same speakers that they're using for sound-masking. Another is that having one device with one sample rate would simplify the coding of the noise generation, which might be based on some adaptive algorithm that e.g. listens to a microphone signal, and which might be written in a high-level language where threads are inefficient. However, there are a few documents discouraging me from trying to combine devices in ALSA, saying "you will drift out of sync over time" because of differences in the crystals of the various sound cards. https://www.alsa-project.org/main/index.php/Asoundrc#Virtual_multi_channel_… https://github.com/opensrc/alsa/blob/master/lib/md/TwoCardsAsOne.md But they describe a "route/multi" configuration using ALSA which often seems to work OK for me. For example, I can generate six independent pink noise streams with SoX and it doesn't usually sound glitchy: AUDIODEV=noise play -c 6 -r 44100 -n synth pinknoise gain -10 channels 6 Music also seems to play OK. I've experienced glitches with movie audio, which resolve when I pause/unpause, but sometimes these issues seemed to persist even when I routed the movie audio to a single pair of speakers. I never tracked down the problem but I thought it might be a sample rate issue. Pulseaudio advertises the ability to combine devices correctly using module-combine-sink which tracks the actual frequencies of the various sink crystals: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Mod… However, the pulseaudio latency is very high and it makes movie audio out of sync with the picture. Furthermore, it seems difficult to use with ALSA because the "pulse" ALSA module doesn't seem to take a parameter which would let me specify which pulse sink or source I am interested in. Thus it seems impossible to use ALSA programs like SoX's play command (above) to output to a non-default Pulseaudio sink. Is this correct? I want to be able to write software which other people can easily install and which can coexist alongside other software they have installed, including audio software. For example I don't want my system to force them to adopt a certain Pulseaudio sink as "default". Even depending on Pulseaudio seems somewhat undesirable. But since I lack familiarity with audio software, I am hoping someone on this list can point me to useful projects or sources of information so that I can solve these problems in a standard way, and produce software that might actually end up being useful to others. Thank you, Frederick Eaton pcm.mix1 { type dmix ipc_key 2852 # must be unique slave { pcm "hw:3" </home/frederik/hw-settings> } } pcm.mix2 { type dmix ipc_key 2853 slave { pcm "hw:1" </home/frederik/hw-settings> } } pcm.mix3 { type dmix ipc_key 2842 # must be unique slave { pcm "hw:0" </home/frederik/hw-settings> } } pcm.multi_mix { type multi; slaves.a.pcm "mix1"; slaves.b.pcm "mix2"; slaves.c.pcm "mix3"; slaves.a.channels 2; slaves.b.channels 2; slaves.c.channels 2; bindings.0.slave a; bindings.0.channel 0; bindings.1.slave a; bindings.1.channel 1; bindings.2.slave b; bindings.2.channel 0; bindings.3.slave b; bindings.3.channel 1; bindings.4.slave c; bindings.4.channel 0; bindings.5.slave c; bindings.5.channel 1; } # pcm.multi_mix { # type multi; # slaves.a.pcm "mix2"; # slaves.b.pcm "mix1"; # slaves.a.channels 2; # slaves.b.channels 2; # bindings.0.slave a; # bindings.0.channel 0; # bindings.1.slave a; # bindings.1.channel 1; # bindings.2.slave b; # bindings.2.channel 0; # bindings.3.slave b; # bindings.3.channel 1; # } pcm.upmix { type route; slave.pcm "multi_mix"; ttable.0.0 1; ttable.1.1 1; ttable.0.2 1; ttable.1.3 1; ttable.0.4 1; ttable.1.5 1; } # pcm.upmix { # type route; # slave.pcm "multi_mix"; # ttable.0.0 1; # ttable.1.1 1; # ttable.0.2 1; # ttable.1.3 1; # } pcm.noise { type softvol ## FHE 01 Mar 2018 # why is plug: needed here? if i put plug:multi_mix in the upmix # device it breaks slave.pcm "plug:multi_mix" control { name "Noise" card 1 } } ctl.noise { type hw card 1 } pcm.music { type softvol # slave.pcm "plug:mix1" slave.pcm "plug:upmix" ## the following gives "invalid argument", why? # slave { # pcm "upmix"; # channels 2; # } control { name "Music" card 1 } } ctl.music { type hw card 1 } pcm.music_no_bass { type plug; slave.pcm { type ladspa # slave.pcm "plughw:0,0"; slave.pcm "plug:music"; path "/usr/lib/ladspa/"; plugins [{ label hpf input { controls [ 1000 ] } }] hint { show on description "Highpass filter for music" } } } # pcm.!default { # type asym # #playback.pcm "music" # playback.pcm "plug:music_no_bass" # #playback.pcm "plug:hw0mix" # capture.pcm "hw:0" # } # FHE 10 Mar 2018 ## we need an "asym" with capture and playback to make pulseaudio happy pcm.!default { type asym playback.pcm { ## from https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture/Exam… # set the default device according to the environment # variable ALSA_DEFAULT_PCM and default to plug:music_no_bass @func refer name { @func concat strings [ "pcm." { @func getenv vars [ ALSA_DEFAULT_PCM ] default "music_no_bass" } ] } } capture.pcm "hw:0" } # FHE 10 Mar 2018 old version ## FHE 01 Mar 2018 # pcm.!default { # @func refer # name { @func concat # strings [ "pcm." # { @func getenv # vars [ ALSA_DEFAULT_PCM ] # default "music_no_bass" # } # ] # } # } rate 44100 format S16_LE ## FHE 01 Mar 2018 # Eshelman's settings period_time 0 period_size 2048 buffer_size 65536 buffer_time 0 periods 128 ## overrides # https://www.alsa-project.org/main/index.php/FramesPeriods # buffer size must be >= 2*period_size*(channels*bytes) # = 8*period_size # interrupt frequency is period_size * rate # we seem to get errors with period_size <= 256 # these settings seem to increase CPU usage only slightly, e.g. from # 5.3% (for above settings) to 7.3% (for below) with mpv # period_size 512 # buffer_size 4096 # period_size 1024 # buffer_size 8192 # This will cause the device to interrupt 86 times per second #!/bin/zsh #front-left,front-right,rear-left,rear-right,front-center,lfe pacmd load-module module-alsa-sink device=mix1 sink_name=mix1 channels=2 channel_map=front-left,front-right pacmd load-module module-alsa-sink device=mix2 sink_name=mix2 channels=2 channel_map=rear-left,rear-right pacmd load-module module-alsa-sink device=mix3 sink_name=mix3 channels=2 channel_map=front-center,lfe pacmd load-module module-combine-sink sink_name=mix123 slaves=mix1,mix2,mix3 channels=6 channel_map=front-left,front-right,rear-left,rear-right,front-center,lfe ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Alsa-user mailing list Alsa-user(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user ----- End forwarded message -----

1 0

[alsa-devel] [PATCH v2] ASoC: max98357a: add a delay parameter to avoid speaker pop/crack noise
by Ezequiel Garcia 27 Mar '18

27 Mar '18

From: Mac Chiang <mac.chiang(a)intel.com> Currently, speaker pop/crack noise can happen during PCM playback. This is due to the LRCLK being removed while the BCLK being present, which as per the datasheet can cause large DC output voltage. While on some platforms simply controlling the SD_MODE pin is enough to remove the noise, others have a significant delay between the BCLK and the LRCLK activation. Therefore, this commit adds a delay in the codec driver to guarantee clocks are both active by the time SD_MODE is asserted. Link: https://github.com/raspberrypi/linux/issues/2212 Signed-off-by: Mac Chiang <mac.chiang(a)intel.com> Signed-off-by: Stephen Barber <smbarber(a)chromium.org> [Ezequiel: make the delay a module parameter] Signed-off-by: Ezequiel Garcia <ezequiel(a)collabora.com> --- Changes on v2: * Got rid of spinlock around gpio set. * Make the delay a module parameter, and not a device tree property. sound/soc/codecs/max98357a.c | 65 ++++++++++++++++++++++++++++++++++++++------ 1 file changed, 56 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c index d469576b5a7b..7d9a0ee71487 100644 --- a/sound/soc/codecs/max98357a.c +++ b/sound/soc/codecs/max98357a.c @@ -27,27 +27,58 @@ #include <sound/soc-dai.h> #include <sound/soc-dapm.h> +/* According to the DAC datasheet, if LRCLK is removed while BCLK is present, + * the DAC output can cause loud pop/crack noises. This parameter specifies + * a delay for the SD_MODE pin assert, required to eliminate the noise. + */ +static unsigned int sdmode_delay; +module_param(sdmode_delay, uint, 0444); +MODULE_PARM_DESC(sdmode_delay, "SD_MODE pin delay."); + +struct max98357a_priv { + struct delayed_work enable_sdmode_work; + struct gpio_desc *sdmode; + int sdmode_enabled; +}; + +static void max98357a_enable_sdmode_work(struct work_struct *work) +{ + struct max98357a_priv *priv = container_of(work, + struct max98357a_priv, enable_sdmode_work.work); + + gpiod_set_value(priv->sdmode, priv->sdmode_enabled); +} + static int max98357a_daiops_trigger(struct snd_pcm_substream *substream, int cmd, struct snd_soc_dai *dai) { - struct gpio_desc *sdmode = snd_soc_dai_get_drvdata(dai); + struct snd_soc_component *component = dai->component; + struct max98357a_priv *priv = snd_soc_component_get_drvdata(component); - if (!sdmode) + if (!priv->sdmode) return 0; switch (cmd) { case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: - gpiod_set_value(sdmode, 1); + priv->sdmode_enabled = 1; + if (sdmode_delay) { + queue_delayed_work(system_power_efficient_wq, + &priv->enable_sdmode_work, + msecs_to_jiffies(sdmode_delay)); + return 0; + } break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: - gpiod_set_value(sdmode, 0); + priv->sdmode_enabled = 0; + cancel_delayed_work(&priv->enable_sdmode_work); break; } + gpiod_set_value(priv->sdmode, priv->sdmode_enabled); return 0; } @@ -61,19 +92,35 @@ static const struct snd_soc_dapm_route max98357a_dapm_routes[] = { static int max98357a_component_probe(struct snd_soc_component *component) { - struct gpio_desc *sdmode; + struct max98357a_priv *priv; - sdmode = devm_gpiod_get_optional(component->dev, "sdmode", GPIOD_OUT_LOW); - if (IS_ERR(sdmode)) - return PTR_ERR(sdmode); + priv = kzalloc(sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; - snd_soc_component_set_drvdata(component, sdmode); + priv->sdmode = gpiod_get_optional(component->dev, + "sdmode", GPIOD_OUT_LOW); + if (IS_ERR(priv->sdmode)) + return PTR_ERR(priv->sdmode); + INIT_DELAYED_WORK(&priv->enable_sdmode_work, + max98357a_enable_sdmode_work); + snd_soc_component_set_drvdata(component, priv); return 0; } +static void max98357a_component_remove(struct snd_soc_component *component) +{ + struct max98357a_priv *priv = snd_soc_component_get_drvdata(component); + + cancel_delayed_work_sync(&priv->enable_sdmode_work); + gpiod_put(priv->sdmode); + kfree(priv); +} + static const struct snd_soc_component_driver max98357a_component_driver = { .probe = max98357a_component_probe, + .remove = max98357a_component_remove, .dapm_widgets = max98357a_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(max98357a_dapm_widgets), .dapm_routes = max98357a_dapm_routes, -- 2.16.2

1 0