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

Re: [alsa-devel] [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams
by Daniel Mack 12 Aug '13

12 Aug '13

[please never drop people from the Cc: list but always use 'reply to all'!] On 12.08.2013 13:27, Jesus R wrote: > On Mon, Aug 12, 2013 at 4:52 AM, Daniel Mack <zonque(a)gmail.com > <mailto:zonque@gmail.com>> wrote: > Given than none of devices have a chance to report their capabilities to > the host, finding out which modes to use is a trial-and-error game, > unless you have access to the firmware sources. > > > Hence, please just look up the USB IDs and alternate interface settings > of your connected device with lsusb, and then augment the code in > snd_usb_interface_dsd_format_quirks() (file sound/usb/quirks.c) and play > around with different possibilities (bitreverse on/off, DSD_U8 vs > DSD_U16 etc). Follow the example that I provided in that function. > > Right now MPD supports DSD/DoP with one selectable on/off option. On > equals DoP output and off equals conversion to PCM. I'm not aware of any > case where it does not work. I would seem to me that there is one > predominant format? It's more complicated than that. Applications were always free to use a usual PCM stream and stuff it with DOP/DSD samples. This is the whole idea of DOP: allow applications to transport DSD samples via regular audio streams. The downside of this is that applications are in charge of adding the DOP markers manually, and information about bit-reversing and marker format (8 bit vs. 16 bit) is up to the application, which is not the right place for it. The patch series I brought in addressed this in a way that all that information about device-specific details is now known to the kernel, which can hence offer a standard compliant interface to userspace. [There's yet one more level of confusion as some file formats store the samples bit-reversed, but there's nothing we can do about that from kernel space except for defining a stable interface application have to obey to in order to be compatible. That is, samples are expected to always carry the oldest bit in the most significant bit of a byte.] So my question is: are you 100% sure that MPD uses the newly introduces ALSA formats, or are they doing the DOP conversion in manually in their own software layers? > You have to recompile and rmmod/insmod the snd-usb driver every time you > make a change, and then you need some sort of userspace tool to test it. > I published one here: > > This may be more than I can do. Can you add the options (bitreverse > on/off, DSD_U8 vs > DSD_U16 etc) to the alas-dsd-player? This would allow me to quickly test > the devices. There are #if0'ed blocks that you can opt-in for bit reversal, but as the marker format is different for 8 and 16 bits, and up to the kernel space now, the dsd player does not know about them. That was the entire intention of bringing that logic to kernel space in the first place. > Take a look at the DSD database so you can see what we are up against. I > could even add the tests results to the database. > https://docs.google.com/spreadsheet/ccc?key=0AgVhKcl_3lHfdFVyenBBNjNpQ2lieG… Nice list. Only devics with USB interface are interesting at this point, but that's a good start. As I said: you need to add the quirks for the devices to the quirks list. Other than that, there's no chance to test them. Copy'n pasting code inside that function and recompiling the kernel is really not as hard as you might think it is. Just search the internet for "compile kernel git <your-distribution-here>" and follow the links. Thanks, Daniel

2 1

[alsa-devel] [PATCH V4 0/4] Add i2s support on smdk5420
by Padmavathi Venna 12 Aug '13

12 Aug '13

Samsung has different versions of I2S introduced in different platforms. Each version has some new support added for multichannel, secondary fifo, s/w reset control, internal mux for rclk src clk and tdm support. Each newly added change has a quirk. So this patch adds all the required quirks as driver data and based on compatible string from dtsi fetches the quirks. This also adds i2s support on exynos5420. Changes since V3: - Addressed review comments by Tomasz Figa related to const qualifier for samsung_i2s_dai_data - Removed passing quirks as driver data for non-dt platforms. - Separated out adding i2s nodes and enabling audio support on 5420 into different patch set as they are dependent on some of already posted but not yet merged i2c, dwmmc, dma and audss clock controller patches. Changes since V2: - Separated out driver side changes and dts changes in two patch sets. - Replaced samsung,s3c6410-i2s-v4 with samsung,s3c6410-i2s-multi for more clarity as suggested by Tomasz Figa. Changes since V1: - Pass quirks as driver data and fetch the quirks based on compatible string from dtsi file as suggested by Tomasz Figa and Mark Brown - Make the I2S driver more flexible with respect to register access as suggested by Tomasz Figa and Mark Brown - Add 5420 support in the driver. - Modify the dtsi files with the corresponding compatible strings and removed the i2s quirks from 5250 dtsi file. - Updated the i2s Documentation with relevent changes and i2s versioning info. - Add i2s nodes on exynos5420.dtsi - Enable sound support on smdk5420 This patch set is made based on Mark Brown for-next branch on sound.git. Padmavathi Venna (4): ASoC: Samsung: I2S: Add quirks as driver data in I2S ASoC: Samsung: I2S: Modify the I2S driver to support I2S on Exynos5420 ARM: dts: exynos5250: move common i2s properties to exynos5 dtsi ARM: dts: Change i2s compatible string on exynos5250 .../devicetree/bindings/sound/samsung-i2s.txt | 22 ++-- arch/arm/boot/dts/exynos5.dtsi | 21 +++ arch/arm/boot/dts/exynos5250.dtsi | 17 +--- include/linux/platform_data/asoc-s3c.h | 1 + sound/soc/samsung/i2s-regs.h | 15 ++ sound/soc/samsung/i2s.c | 143 +++++++++++++++----- 6 files changed, 157 insertions(+), 62 deletions(-) -- 1.7.4.4

5 13

[alsa-devel] [PATCH] ASoC: arizona: Add widget<->mux route into mux route macro
by Charles Keepax 12 Aug '13

12 Aug '13

The routes linking the widget and the input mux were being added manually, rather than by the ARIZONA_MUX_ROUTES macro. This patchs adds the routes to the macro. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.h | 3 ++- sound/soc/codecs/wm5102.c | 41 ++++++++++++----------------------------- sound/soc/codecs/wm5110.c | 8 ++++---- 3 files changed, 18 insertions(+), 34 deletions(-) diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h index b60b08c..bf67d65 100644 --- a/sound/soc/codecs/arizona.h +++ b/sound/soc/codecs/arizona.h @@ -150,7 +150,8 @@ extern int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS]; ARIZONA_MUX(name_str " Aux 5", &name##_aux5_mux), \ ARIZONA_MUX(name_str " Aux 6", &name##_aux6_mux) -#define ARIZONA_MUX_ROUTES(name) \ +#define ARIZONA_MUX_ROUTES(widget, name) \ + { widget, NULL, name " Input" }, \ ARIZONA_MIXER_INPUT_ROUTES(name " Input") #define ARIZONA_MIXER_ROUTES(widget, name) \ diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index 282fd23..9e9a0c1 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -1499,23 +1499,6 @@ static const struct snd_soc_dapm_route wm5102_dapm_routes[] = { { "IN3L PGA", NULL, "IN3L" }, { "IN3R PGA", NULL, "IN3R" }, - { "ASRC1L", NULL, "ASRC1L Input" }, - { "ASRC1R", NULL, "ASRC1R Input" }, - { "ASRC2L", NULL, "ASRC2L Input" }, - { "ASRC2R", NULL, "ASRC2R Input" }, - - { "ISRC1DEC1", NULL, "ISRC1DEC1 Input" }, - { "ISRC1DEC2", NULL, "ISRC1DEC2 Input" }, - - { "ISRC1INT1", NULL, "ISRC1INT1 Input" }, - { "ISRC1INT2", NULL, "ISRC1INT2 Input" }, - - { "ISRC2DEC1", NULL, "ISRC2DEC1 Input" }, - { "ISRC2DEC2", NULL, "ISRC2DEC2 Input" }, - - { "ISRC2INT1", NULL, "ISRC2INT1 Input" }, - { "ISRC2INT2", NULL, "ISRC2INT2 Input" }, - ARIZONA_MIXER_ROUTES("OUT1L", "HPOUT1L"), ARIZONA_MIXER_ROUTES("OUT1R", "HPOUT1R"), ARIZONA_MIXER_ROUTES("OUT2L", "HPOUT2L"), @@ -1567,22 +1550,22 @@ static const struct snd_soc_dapm_route wm5102_dapm_routes[] = { ARIZONA_MIXER_ROUTES("LHPF3", "LHPF3"), ARIZONA_MIXER_ROUTES("LHPF4", "LHPF4"), - ARIZONA_MUX_ROUTES("ASRC1L"), - ARIZONA_MUX_ROUTES("ASRC1R"), - ARIZONA_MUX_ROUTES("ASRC2L"), - ARIZONA_MUX_ROUTES("ASRC2R"), + ARIZONA_MUX_ROUTES("ASRC1L", "ASRC1L"), + ARIZONA_MUX_ROUTES("ASRC1R", "ASRC1R"), + ARIZONA_MUX_ROUTES("ASRC2L", "ASRC2L"), + ARIZONA_MUX_ROUTES("ASRC2R", "ASRC2R"), - ARIZONA_MUX_ROUTES("ISRC1INT1"), - ARIZONA_MUX_ROUTES("ISRC1INT2"), + ARIZONA_MUX_ROUTES("ISRC1INT1", "ISRC1INT1"), + ARIZONA_MUX_ROUTES("ISRC1INT2", "ISRC1INT2"), - ARIZONA_MUX_ROUTES("ISRC1DEC1"), - ARIZONA_MUX_ROUTES("ISRC1DEC2"), + ARIZONA_MUX_ROUTES("ISRC1DEC1", "ISRC1DEC1"), + ARIZONA_MUX_ROUTES("ISRC1DEC2", "ISRC1DEC2"), - ARIZONA_MUX_ROUTES("ISRC2INT1"), - ARIZONA_MUX_ROUTES("ISRC2INT2"), + ARIZONA_MUX_ROUTES("ISRC2INT1", "ISRC2INT1"), + ARIZONA_MUX_ROUTES("ISRC2INT2", "ISRC2INT2"), - ARIZONA_MUX_ROUTES("ISRC2DEC1"), - ARIZONA_MUX_ROUTES("ISRC2DEC2"), + ARIZONA_MUX_ROUTES("ISRC2DEC1", "ISRC2DEC1"), + ARIZONA_MUX_ROUTES("ISRC2DEC2", "ISRC2DEC2"), ARIZONA_DSP_ROUTES("DSP1"), diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c index 2e7cb4b..0cfc5e6 100644 --- a/sound/soc/codecs/wm5110.c +++ b/sound/soc/codecs/wm5110.c @@ -979,10 +979,10 @@ static const struct snd_soc_dapm_route wm5110_dapm_routes[] = { ARIZONA_MIXER_ROUTES("LHPF3", "LHPF3"), ARIZONA_MIXER_ROUTES("LHPF4", "LHPF4"), - ARIZONA_MUX_ROUTES("ASRC1L"), - ARIZONA_MUX_ROUTES("ASRC1R"), - ARIZONA_MUX_ROUTES("ASRC2L"), - ARIZONA_MUX_ROUTES("ASRC2R"), + ARIZONA_MUX_ROUTES("ASRC1L", "ASRC1L"), + ARIZONA_MUX_ROUTES("ASRC1R", "ASRC1R"), + ARIZONA_MUX_ROUTES("ASRC2L", "ASRC2L"), + ARIZONA_MUX_ROUTES("ASRC2R", "ASRC2R"), { "HPOUT1L", NULL, "OUT1L" }, { "HPOUT1R", NULL, "OUT1R" }, -- 1.7.2.5

2 1

[alsa-devel] Another possible race in deferred probing...
by Russell King - ARM Linux 12 Aug '13

12 Aug '13

There is no better way to provoke bugs than to show a device to someone who has never seen it before. Obviously, I didn't get much chance to investigate what happened, so all I have are the kernel messages: kirkwood-spdif-audio kirkwood-spdif-audio.1: ASoC: CPU DAI mvebu-audio.1 not registered kirkwood-spdif-audio kirkwood-spdif-audio.1: failed to register card platform kirkwood-spdif-audio.1: Driver kirkwood-spdif-audio requests probe deferral mvebu-audio mvebu-audio.1: found external clock kirkwood-spdif-audio kirkwood-spdif-audio.1: ASoC: CODEC spdif-dit not registered kirkwood-spdif-audio kirkwood-spdif-audio.1: failed to register card platform kirkwood-spdif-audio.1: Driver kirkwood-spdif-audio requests probe deferral kirkwood-spdif-audio kirkwood-spdif-audio.1: ASoC: CODEC spdif-dit not registered kirkwood-spdif-audio kirkwood-spdif-audio.1: failed to register card platform kirkwood-spdif-audio.1: Driver kirkwood-spdif-audio requests probe deferral and then when manually removing the kirkwood-spdif module and re-inserting it: kirkwood-spdif-audio kirkwood-spdif-audio.1: dit-hifi <-> mvebu-audio.1 mapping ok First, remember that Ubuntu loads kernel modules from separate threads, so module loading here is multithreaded. What I suspect happened was the spdif-dit module was inserted and initialized between kirkwood-spdif starting to be re-probed, and returning from its probe function with -EPROBE_DEFER, and I suspect that spdif-dit was the last module. As there was no further module loading or driver activity, there was no attempt to re-probe the kirkwood-spdif module. This seems to be a very rare event (it's the first time I've seen it since the last fix to the deferred probing, and that's many hundreds of reboots.) Nevertheless, the fact that it has happened indicates that deferred probing still has holes that can leave modular drivers unbound after boot. Let's consider this scenario, which from a quick scan of the code looks like it's possible to happen: Thread 0 Thread 1 deferred probe triggered driver A's probe function called (kirkwood_spdif_probe in my case) takes lock L to lookup resource A checks for resource A (the spdif_dit codec) releases lock L resource A is not found ----- context switch ------ module init function called (to register spdif_dit_driver) driver B's probe function called (to register the spdif_dit codec via snd_soc_register_codec) takes lock L for adding resource A registers resource A releases lock L driver B's probe function completes deferred probe triggered, deferred probe list empty module init completes ----- context switch ------ probe returns -EPROBE_DEFER deferred probe mutex taken added to deferred probe list deferred probe mutex released This can happen because there's no locking between looking up the resource and having the driver added to the list of devices waiting to be probed. Given that deferred probing is becoming the "normal" thing for device drivers, these races are only going to get worse. Consider that as we're working on ARM towards having a single zImage bootable on many boards, most drivers will be modules, and if they're inserted into the kernel in a multi-threaded way, the above race is going to continually come back and bite us. I don't see an easy solution to this; we can't serialise device probes, because we have some places where device driver probe functions register devices themselves, which then go on to have their drivers probed (nested probes). Maybe this reflects back into Greg's whole argument against platform devices: maybe we need a struct device which lists _all_ the resources which a device requires, have the bus layer safely check for the presence of all those resources before calling the probe function, and move the deferred probe out of the core into the bus layer(s). Another solution would be to have a way to attach to the device a list of resources which failed, and have the driver core scan that list after the probe returns rechecking to see if all the resources are now present. That to me sounds particularly horrid, invasive and quite disgusting to implement safely.

1 0

[alsa-devel] [PATCH] ALSA: compress: update the MAINTAINER entry
by Vinod Koul 12 Aug '13

12 Aug '13

add missing uapi/ headers and Documentation files Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- MAINTAINERS | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 38a870e..a40e393 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7667,7 +7667,9 @@ M: Vinod Koul <vinod.koul(a)intel.com> L: alsa-devel(a)alsa-project.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git S: Supported +F: Documentation/sound/alsa/compress_offload.txt F: include/sound/compress_driver.h +F: include/uapi/sound/compress_* F: sound/core/compress_offload.c F: sound/soc/soc-compress.c -- 1.7.0.4

2 1

[alsa-devel] [PATCH 2/2] 6fire: make buffers DMA-able (midi)
by Torsten Schenk 12 Aug '13

12 Aug '13

Patch makes midi output buffer DMA-able by allocating it separately. Signed-off-by: Torsten Schenk <torsten.schenk(a)zoho.com> --- diff -Nur a/sound/6fire/midi.c b/sound/6fire/midi.c --- a/sound/6fire/midi.c 2013-08-04 22:46:46.000000000 +0200 +++ b/sound/6fire/midi.c 2013-08-11 10:51:05.682482388 +0200 @@ -19,6 +19,10 @@ #include "chip.h" #include "comm.h" +enum { + MIDI_BUFSIZE = 64 +}; + static void usb6fire_midi_out_handler(struct urb *urb) { struct midi_runtime *rt = urb->context; @@ -156,6 +160,12 @@ if (!rt) return -ENOMEM; + rt->out_buffer = kzalloc(MIDI_BUFSIZE, GFP_KERNEL); + if (!rt->out_buffer) { + kfree(rt); + return -ENOMEM; + } + rt->chip = chip; rt->in_received = usb6fire_midi_in_received; rt->out_buffer[0] = 0x80; /* 'send midi' command */ @@ -169,6 +179,7 @@ ret = snd_rawmidi_new(chip->card, "6FireUSB", 0, 1, 1, &rt->instance); if (ret < 0) { + kfree(rt->out_buffer); kfree(rt); snd_printk(KERN_ERR PREFIX "unable to create midi.\n"); return ret; @@ -197,6 +208,9 @@ void usb6fire_midi_destroy(struct sfire_chip *chip) { - kfree(chip->midi); + struct midi_runtime *rt = chip->midi; + + kfree(rt->out_buffer); + kfree(rt); chip->midi = NULL; } diff -Nur a/sound/6fire/midi.h b/sound/6fire/midi.h --- a/sound/6fire/midi.h 2013-08-04 22:46:46.000000000 +0200 +++ b/sound/6fire/midi.h 2013-08-11 10:51:05.682482388 +0200 @@ -16,10 +16,6 @@ #include "common.h" -enum { - MIDI_BUFSIZE = 64 -}; - struct midi_runtime { struct sfire_chip *chip; struct snd_rawmidi *instance; @@ -32,7 +28,7 @@ struct snd_rawmidi_substream *out; struct urb out_urb; u8 out_serial; /* serial number of out packet */ - u8 out_buffer[MIDI_BUFSIZE]; + u8 *out_buffer; int buffer_offset; void (*in_received)(struct midi_runtime *rt, u8 *data, int length);

2 1

[alsa-devel] [PATCH] 6fire: fix URB transfer buffer for midi output
by Torsten Schenk 12 Aug '13

12 Aug '13

Patch fixes URB transfer buffer allocation for midi output to be DMA-able. Signed-off-by: Torsten Schenk <torsten.schenk(a)zoho.com> --- diff -Nur a/sound/usb/6fire/midi.c b/sound/usb/6fire/midi.c --- a/sound/usb/6fire/midi.c 2013-08-07 16:32:10.579639391 +0200 +++ b/sound/usb/6fire/midi.c 2013-08-07 16:32:31.363378104 +0200 @@ -19,6 +19,10 @@ #include "chip.h" #include "comm.h" +enum { + MIDI_BUFSIZE = 64 +}; + static void usb6fire_midi_out_handler(struct urb *urb) { struct midi_runtime *rt = urb->context; @@ -156,6 +160,12 @@ if (!rt) return -ENOMEM; + rt->out_buffer = kzalloc(MIDI_BUFSIZE, GFP_KERNEL); + if (!rt->out_buffer) { + kfree(rt); + return -ENOMEM; + } + rt->chip = chip; rt->in_received = usb6fire_midi_in_received; rt->out_buffer[0] = 0x80; /* 'send midi' command */ @@ -169,6 +179,7 @@ ret = snd_rawmidi_new(chip->card, "6FireUSB", 0, 1, 1, &rt->instance); if (ret < 0) { + kfree(rt->out_buffer); kfree(rt); snd_printk(KERN_ERR PREFIX "unable to create midi.\n"); return ret; @@ -197,6 +208,9 @@ void usb6fire_midi_destroy(struct sfire_chip *chip) { - kfree(chip->midi); + struct midi_runtime *rt = chip->midi; + + kfree(rt->out_buffer); + kfree(rt); chip->midi = NULL; } diff -Nur a/sound/usb/6fire/midi.h b/sound/usb/6fire/midi.h --- a/sound/usb/6fire/midi.h 2013-08-07 16:32:10.579639391 +0200 +++ b/sound/usb/6fire/midi.h 2013-08-07 16:32:31.363378104 +0200 @@ -16,10 +16,6 @@ #include "common.h" -enum { - MIDI_BUFSIZE = 64 -}; - struct midi_runtime { struct sfire_chip *chip; struct snd_rawmidi *instance; @@ -32,7 +28,7 @@ struct snd_rawmidi_substream *out; struct urb out_urb; u8 out_serial; /* serial number of out packet */ - u8 out_buffer[MIDI_BUFSIZE]; + u8 *out_buffer; int buffer_offset; void (*in_received)(struct midi_runtime *rt, u8 *data, int length);

4 7

[alsa-devel] LG LW25 pin fix
by Joonas Saarinen 12 Aug '13

12 Aug '13

Hello, I discovered that the LG LW25 laptop needs a small fix to its pin mapping. The functions of blue and green jacks simply have to be interchanged. The rest of the configuration is correct. Can this fix be made permanent in the driver? The fixed mappings are: 0x1a 0x0181344f 0x1b 0x0321403f Here's the full correct map: [codec] 0x10ec0880 0x00001854 0 [pincfg] 0x14 0xb7031110 0x15 0x411111f0 0x16 0x411111f0 0x17 0x411111f0 0x18 0x01a19c22 0x19 0xb7a31120 0x1a 0x0181344f 0x1b 0x0321403f 0x1c 0x411111f0 0x1d 0x411111f0 0x1e 0x0145311e 0x1f 0x411111f0 Thanks, Joonas

2 5

Re: [alsa-devel] [PATCH v3 5/5] ALSA: snd-usb: add quirks handler for DSD streams
by Jesus R 12 Aug '13

12 Aug '13

Daniel/team, I have access to a few DSD devices and or USB based devices. I can provide any information you need to help with allowing ALSA to identify the device's capabilities. Just let me know how to get the information you need from command line:) I also have a list of known DSD/DoP devices in Google Drive that may be helpful. Let me know if it's okay to post the link. Jesus R sonore.us

2 2

[alsa-devel] [PATCH] ASoC: adau1701: Use gpio_set_value_cansleep()
by Mark Brown 12 Aug '13

12 Aug '13

From: Mark Brown <broonie(a)linaro.org> The GPIO manipulation done by this driver is never in atomic context so we can use gpio_set_value_cansleep() and support GPIOs that can't be set from atomic context. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/codecs/adau1701.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/sound/soc/codecs/adau1701.c b/sound/soc/codecs/adau1701.c index 2c10252..ebff112 100644 --- a/sound/soc/codecs/adau1701.c +++ b/sound/soc/codecs/adau1701.c @@ -247,21 +247,21 @@ static int adau1701_reset(struct snd_soc_codec *codec, unsigned int clkdiv) gpio_is_valid(adau1701->gpio_pll_mode[1])) { switch (clkdiv) { case 64: - gpio_set_value(adau1701->gpio_pll_mode[0], 0); - gpio_set_value(adau1701->gpio_pll_mode[1], 0); + gpio_set_value_cansleep(adau1701->gpio_pll_mode[0], 0); + gpio_set_value_cansleep(adau1701->gpio_pll_mode[1], 0); break; case 256: - gpio_set_value(adau1701->gpio_pll_mode[0], 0); - gpio_set_value(adau1701->gpio_pll_mode[1], 1); + gpio_set_value_cansleep(adau1701->gpio_pll_mode[0], 0); + gpio_set_value_cansleep(adau1701->gpio_pll_mode[1], 1); break; case 384: - gpio_set_value(adau1701->gpio_pll_mode[0], 1); - gpio_set_value(adau1701->gpio_pll_mode[1], 0); + gpio_set_value_cansleep(adau1701->gpio_pll_mode[0], 1); + gpio_set_value_cansleep(adau1701->gpio_pll_mode[1], 0); break; case 0: /* fallback */ case 512: - gpio_set_value(adau1701->gpio_pll_mode[0], 1); - gpio_set_value(adau1701->gpio_pll_mode[1], 1); + gpio_set_value_cansleep(adau1701->gpio_pll_mode[0], 1); + gpio_set_value_cansleep(adau1701->gpio_pll_mode[1], 1); break; } } @@ -269,10 +269,10 @@ static int adau1701_reset(struct snd_soc_codec *codec, unsigned int clkdiv) adau1701->pll_clkdiv = clkdiv; if (gpio_is_valid(adau1701->gpio_nreset)) { - gpio_set_value(adau1701->gpio_nreset, 0); + gpio_set_value_cansleep(adau1701->gpio_nreset, 0); /* minimum reset time is 20ns */ udelay(1); - gpio_set_value(adau1701->gpio_nreset, 1); + gpio_set_value_cansleep(adau1701->gpio_nreset, 1); /* power-up time may be as long as 85ms */ mdelay(85); } -- 1.8.4.rc1

2 1