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

[alsa-devel] [PATCH] ALSA: hda: option to enable arbitrary buffer/period sizes
by Pierre-Louis Bossart 04 Aug '11

04 Aug '11

Add new parameter to disable rounding of buffer/period sizes to multiples of 128 bytes. This is more efficient in terms of memory access but isn't required by the HDA spec and prevents users from specifying exact period/buffer sizes. For example for 44.1kHz, a period size set to 20ms will be rounded to 19.59ms. Tested and enabled on Intel HDA controllers. Option is disabled by default for other controllers. Tested-by: Wu Fengguang <fengguang.wu(a)intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- Documentation/sound/alsa/ALSA-Configuration.txt | 5 ++ sound/pci/hda/hda_intel.c | 68 ++++++++++++++++++----- 2 files changed, 58 insertions(+), 15 deletions(-) diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 8975701..27126c4 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -886,6 +886,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. disable) power_save_controller - Reset HD-audio controller in power-saving mode (default = on) + align_buffer_size - Force rounding of buffer/period sizes to multiples + of 128 bytes. This is more efficient in terms of memory + access but isn't required by the HDA spec and prevents + users from specifying exact period/buffer sizes. + (default = on) This module supports multiple cards and autoprobe. diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index be69822..2a8bed9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -116,6 +116,11 @@ module_param(power_save_controller, bool, 0644); MODULE_PARM_DESC(power_save_controller, "Reset controller in power save mode."); #endif +static int align_buffer_size = 1; +module_param(align_buffer_size, bool, 0644); +MODULE_PARM_DESC(align_buffer_size, + "Force buffer and period sizes to be multiple of 128 bytes."); + MODULE_LICENSE("GPL"); MODULE_SUPPORTED_DEVICE("{{Intel, ICH6}," "{Intel, ICH6M}," @@ -481,6 +486,7 @@ enum { #define AZX_DCAPS_NO_64BIT (1 << 18) /* No 64bit address */ #define AZX_DCAPS_SYNC_WRITE (1 << 19) /* sync each cmd write */ #define AZX_DCAPS_OLD_SSYNC (1 << 20) /* Old SSYNC reg for ICH */ +#define AZX_DCAPS_BUFSIZE (1 << 21) /* no buffer size alignment */ /* quirks for ATI SB / AMD Hudson */ #define AZX_DCAPS_PRESET_ATI_SB \ @@ -1599,6 +1605,7 @@ static int azx_pcm_open(struct snd_pcm_substream *substream) struct snd_pcm_runtime *runtime = substream->runtime; unsigned long flags; int err; + int buff_step; mutex_lock(&chip->open_mutex); azx_dev = azx_assign_device(chip, substream); @@ -1613,10 +1620,25 @@ static int azx_pcm_open(struct snd_pcm_substream *substream) runtime->hw.rates = hinfo->rates; snd_pcm_limit_hw_rates(runtime); snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); + if (align_buffer_size) + /* constrain buffer sizes to be multiple of 128 + bytes. This is more efficient in terms of memory + access but isn't required by the HDA spec and + prevents users from specifying exact period/buffer + sizes. For example for 44.1kHz, a period size set + to 20ms will be rounded to 19.59ms. */ + buff_step = 128; + else + /* Don't enforce steps on buffer sizes, still need to + be multiple of 4 bytes (HDA spec). Tested on Intel + HDA controllers, may not work on all devices where + option needs to be disabled */ + buff_step = 4; + snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, - 128); + buff_step); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, - 128); + buff_step); snd_hda_power_up(apcm->codec); err = hinfo->ops.open(hinfo, apcm->codec, substream); if (err < 0) { @@ -2616,6 +2638,10 @@ static int __devinit azx_create(struct snd_card *card, struct pci_dev *pci, gcap &= ~ICH6_GCAP_64OK; } + /* disable buffer size rounding to 128-byte multiples if supported */ + if (chip->driver_caps & AZX_DCAPS_BUFSIZE) + align_buffer_size = 0; + /* allow 64bit DMA address if supported by H/W */ if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64))) pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64)); @@ -2817,37 +2843,49 @@ static void __devexit azx_remove(struct pci_dev *pci) static DEFINE_PCI_DEVICE_TABLE(azx_ids) = { /* CPT */ { PCI_DEVICE(0x8086, 0x1c20), - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP }, + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP | + AZX_DCAPS_BUFSIZE }, /* PBG */ { PCI_DEVICE(0x8086, 0x1d20), - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP }, + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP | + AZX_DCAPS_BUFSIZE}, /* Panther Point */ { PCI_DEVICE(0x8086, 0x1e20), - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP }, + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP | + AZX_DCAPS_BUFSIZE}, /* SCH */ { PCI_DEVICE(0x8086, 0x811b), - .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP }, + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP | + AZX_DCAPS_BUFSIZE}, { PCI_DEVICE(0x8086, 0x2668), - .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC }, /* ICH6 */ + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | + AZX_DCAPS_BUFSIZE }, /* ICH6 */ { PCI_DEVICE(0x8086, 0x27d8), - .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC }, /* ICH7 */ + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | + AZX_DCAPS_BUFSIZE }, /* ICH7 */ { PCI_DEVICE(0x8086, 0x269a), - .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC }, /* ESB2 */ + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | + AZX_DCAPS_BUFSIZE }, /* ESB2 */ { PCI_DEVICE(0x8086, 0x284b), - .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC }, /* ICH8 */ + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | + AZX_DCAPS_BUFSIZE }, /* ICH8 */ { PCI_DEVICE(0x8086, 0x293e), - .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC }, /* ICH9 */ + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | + AZX_DCAPS_BUFSIZE }, /* ICH9 */ { PCI_DEVICE(0x8086, 0x293f), - .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC }, /* ICH9 */ + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | + AZX_DCAPS_BUFSIZE }, /* ICH9 */ { PCI_DEVICE(0x8086, 0x3a3e), - .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC }, /* ICH10 */ + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | + AZX_DCAPS_BUFSIZE }, /* ICH10 */ { PCI_DEVICE(0x8086, 0x3a6e), - .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC }, /* ICH10 */ + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_OLD_SSYNC | + AZX_DCAPS_BUFSIZE }, /* ICH10 */ /* Generic Intel */ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID), .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, .class_mask = 0xffffff, - .driver_data = AZX_DRIVER_ICH }, + .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_BUFSIZE }, /* ATI SB 450/600/700/800/900 */ { PCI_DEVICE(0x1002, 0x437b), .driver_data = AZX_DRIVER_ATI | AZX_DCAPS_PRESET_ATI_SB }, -- 1.7.6

2 1

[alsa-devel] [PATCH] Fix Jack plugin
by Kevin Ross 04 Aug '11

04 Aug '11

I've uploaded a patch to ticket 2727, at https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2727 My background: I'm a software developer, but I know nothing about ALSA development. But I use Jack, and needed to get the Jack plugin working. Since no one has touched the plugin in years, I figured I'd take a stab at fixing it myself. The symptom: Using the Jack plugin causes whatever program is outputting audio to hang after about 10-20 seconds. The cause: The plugin creates a pipe, so that the fd's could be polled to indicate completion of a transfer. However, the call to write() blocks when playing audio, as nothing actually reads from the pipe, and it fills up until it blocks. The solution: This is where my inexperience with ALSA shows up. I don't know the best way to fix it. Making the socket non-blocking fixes the problem, and testing with playback and capture both work properly for me now. However, comparing the code with that of pcm-pulse.c (for piping ALSA output to PulseAudio), it's obvious that the Jack plugin was a hack. It could use more work. However, my fix at least gets me running. The patch: --- alsa-plugins-1.0.23/jack/pcm_jack.c 2010-04-16 04:11:10.000000000 -0700 +++ alsa-plugins-1.0.23.new/jack/pcm_jack.c 2011-08-03 21:54:51.795378947 -0700 @@ -307,6 +308,18 @@ return 0; } +static int make_nonblock(int fd) { + int fl; + + if ((fl = fcntl(fd, F_GETFL)) < 0) + return fl; + + if (fl & O_NONBLOCK) + return 0; + + return fcntl(fd, F_SETFL, fl | O_NONBLOCK); +} + static int snd_pcm_jack_open(snd_pcm_t **pcmp, const char *name, snd_config_t *playback_conf, snd_config_t *capture_conf, @@ -363,6 +376,9 @@ socketpair(AF_LOCAL, SOCK_STREAM, 0, fd); + make_nonblock(fd[0]); + make_nonblock(fd[1]); + jack->fd = fd[0]; jack->io.version = SND_PCM_IOPLUG_VERSION;

3 3

[alsa-devel] ASoC updates for 3.1
by Mark Brown 04 Aug '11

04 Aug '11

The following changes since commit 06132fdf63c7d9acc19f136623bf2201f49e73b5: ASoC: Fix txx9aclc.c build (2011-07-29 07:53:08 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-3.1 Mark Brown (1): ASoC: Disable wm_hubs periodic DC servo update Wolfram Sang (1): ASoC: sgtl5000: fix cache handling sound/soc/codecs/sgtl5000.c | 128 ++++++++++++------------------------------- sound/soc/codecs/wm_hubs.c | 3 +- 2 files changed, 36 insertions(+), 95 deletions(-)

2 1

[alsa-devel] ALSA pcm1808-at91sam9g20 driver
by Sergio Arroutbi 04 Aug '11

04 Aug '11

Hello. I would like to develop a driver for and ADC PCM1808. This PCM is connected to the SSC of a CPU ATMEL SAM91G20 Which driver/drivers could I have as reference? Is pcm3008 the best codec to look at? Thanks a lot -- Sergio Arroutbi Braojos Ingeniero de Desarrollo Software Grupo GMIS SEPSA, SISTEMAS CONTROL E INFORMACIÓN sarroutbi(a)sepsa.es Tel: (+34) 91 495 70 00 - Ext. 1587 Fax: (+34) 91 692 63 37 C/ALBATROS, 7 - 9 Polígono Industrial "Pinto Estación" 28320 - Pinto (MADRID)

1 0

[alsa-devel] EeePC 1005PE microphone is "stereo only", silent in mono
by Pavel Roskin 04 Aug '11

04 Aug '11

Hello! I have discovered that the microphone on my ASUS EeePC 1005PE only works in stereo. If recording in mono, the result is inaudible. When I open the stereo recording in audacity, I see that the two channels are in counterphase. If I convert stereo to mono in audacity, I get a straight line, and it's inaudible when played. The driver itself requires stereo recording: $ arecord --rate 44100 -D hw:0 -f S16_LE --channels 1 >test.wav Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono arecord: set_params:1065: Channels count non available However, pulse audio doesn't enforce it. So it's possible to record a mono file through pulse audio, and it's inaudible. Some programs simply assume a mono microphone and thus get no sound. I can work it around by setting the level on one of the channels to 100% and to 0% on the other in alsamixer. However, the GNOME volume manager removes that imbalance when adjusting the input level. I would prefer to have a robust solution. Perhaps one of the channels should be inverted. Or maybe the difference between the channels should be reported as mono input. I don't really care about stereo input. I'm using Linux 3.0 on Fedora 15. I checked out and tested the master branch of sound-2.6.git, and it has the same problem. It looks like the problem is known. I found this comment in alc882_quirks.c: /* DMIC fix * This laptop has a stereo digital microphone. The mics are only 1cm apart * which makes the stereo useless. However, either the mic or the ALC889 * makes the signal become a difference/sum signal instead of standard * stereo, which is annoying. So instead we flip this bit which makes the * codec replicate the sum signal to both channels, turning it into a * normal mono mic. */ My laptop has ALC269, bit it also used the DMIC quirk: SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_DMIC), That's the detailed lspci output: $ lspci -vvnn -s 00:1b.0 00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: ASUSTeK Computer Inc. Device [1043:83ce] 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: 32 bytes Interrupt: pin A routed to IRQ 45 Region 0: Memory at f7cf8000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel I'm not using any module parameters. No external devices are connected to the laptop. -- Regards, Pavel Roskin

3 10

Re: [alsa-devel] [PATCH v3] pass ELD to HDMI/DP audio driver
by Wu Fengguang 04 Aug '11

04 Aug '11

> On Mon, 1 Aug 2011 21:51:40 +0800, Wu Fengguang <fengguang.wu(a)intel.com> wrote: > > > 1) intel_write_eld() is not called at all > > It seems we need to call intel_write_eld() in other places besides > > inside ->mode_set(). Is ->detect() the right place to do so? In > > other words, are there established connector<=>encoder mapping > > that can be queried inside intel_hdmi_detect()/intel_dp_detect()? > > The connector has a link to the encoder (struct intel_connector contains a > pointer to a struct intel_encoder). Right. I actually have this chunk. dmesg shows that in intel_hdmi_detect(), the drm_encoder object is there, however encoder->crtc is NULL at the time. @@ -269,6 +271,12 @@ intel_hdmi_detect(struct drm_connector * status = connector_status_connected; intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid); intel_hdmi->has_audio = drm_detect_monitor_audio(edid); + drm_edid_to_eld(connector, edid); + if (intel_hdmi->base.base.crtc) + intel_write_eld(&intel_hdmi->base.base, + &intel_hdmi->base.base.crtc->mode); + else + printk("intel_hdmi_detect: cannot write eld: NULL crtc\n"); } connector->display_info.raw_edid = NULL; kfree(edid); You may wonder why the mode parameter is needed in intel_write_eld(). This is because the ELD field aud_synch_delay (ie. A/V sync delay) may have different values in progressive/interleaved display modes. > > 2) intel_dp_detect() is called even though it's an HDMI monitor > > connected to an HDMI jack.. It may be a bug specific to the > > hardware I'm testing (attached its full dmesg). > > We run all of the hotplug functions when any connector change is > detected; easier than trying to track what happened from the bits > visible from the interrupt. Ah yes. I figured it out later. > I note that this patch does not include the necessary hooks for > Ivybridge; we'll need that included (and tested) for this to be > considered for kernel 3.1. I'd be surprised if it couldn't use > ironlake_write_eld just fine, so it should just be a matter of setting > the write_eld field and testing it on actual hardware. I tested Ivybridge yesterday and ironlake_write_eld seems to not work properly for Ivybridge. Need to double check its spec. Thanks, Fengguang

1 0

[alsa-devel] [PATCH] ASoC: Allow userspace control of Speyside headphone output
by Mark Brown 04 Aug '11

04 Aug '11

In order to facilitate the widest range of use cases (especially things like speakerphone) allow the headphone output to be enabled and disabled by the application layer. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/speyside.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/sound/soc/samsung/speyside.c b/sound/soc/samsung/speyside.c index 590e927..bfed1ff 100644 --- a/sound/soc/samsung/speyside.c +++ b/sound/soc/samsung/speyside.c @@ -125,10 +125,6 @@ static struct snd_soc_jack_pin speyside_headset_pins[] = { .pin = "Headset Mic", .mask = SND_JACK_MICROPHONE, }, - { - .pin = "Headphone", - .mask = SND_JACK_HEADPHONE, - }, }; /* Default the headphone selection to active high */ @@ -252,6 +248,7 @@ static const struct snd_kcontrol_new controls[] = { SOC_DAPM_PIN_SWITCH("Main AMIC"), SOC_DAPM_PIN_SWITCH("WM1250 Input"), SOC_DAPM_PIN_SWITCH("WM1250 Output"), + SOC_DAPM_PIN_SWITCH("Headphone"), }; static struct snd_soc_dapm_widget widgets[] = { -- 1.7.5.4

1 0

[alsa-devel] memory leak in mmap ops
by Scott Jiang 04 Aug '11

04 Aug '11

Hi all, I found there is a memory leak about 128K every time in linux-2.6.34, but it doesn't exist in linux-3.0. If I use mmap ops in driver the bug will come out, while use copy ops no memory leak. This driver is based on asoc. I tested with aplay to play a wav file. Because there is a lot of changes in ALSA between 2.6.34 and 3.0, so can anyone who familiar with the change history tell me which patch has solved this bug? Thanks in advance. Scott

2 2

Re: [alsa-devel] Regression in 3.0-git after commit c82693db52beced0419cecf09a3c81adfe95a544 - sound does not work
by Takashi Iwai 04 Aug '11

04 Aug '11

At Wed, 03 Aug 2011 16:41:08 -0500, Larry Finger wrote: > > In the latest git pull of 3.0-git from Linus's tree, the sound on my HP laptop > does not work. This problem was bisected to the commit in the subject. > > The lspci output for my sound device is: > > 00:07.0 Audio device [0403]: nVidia Corporation MCP67 High Definition Audio > [10de:055c] (rev a1) > Subsystem: Hewlett-Packard Company Device [103c:30d6] > Kernel driver in use: snd_hda_intel > > I further isolated the problem to the following hunk: > > diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c > index 6e90b6b..4ca880b 100644 > --- a/sound/pci/hda/patch_conexant.c > +++ b/sound/pci/hda/patch_conexant.c > @@ -1994,10 +1990,8 @@ static int patch_cxt5051(struct hda_codec *codec) > board_config = snd_hda_check_board_config(codec, CXT5051_MODELS, > cxt5051_models, > cxt5051_cfg_tbl); > -#if 0 /* use the old method just for safety */ > if (board_config < 0) > - board_config = CXT5051_AUTO; > -#endif > + board_config = CXT5051_AUTO; /* model=auto as default */ > if (board_config == CXT5051_AUTO) > return patch_conexant_auto(codec); > > In my case, snd_hda_check_board_config() returns -1. Thus, the new code returns > the value of patch_conexant_auto(), whereas the original version fell through to > the setup code below. Clearly, this is needed for my device. And reverting the above fixes your problem, right? Then please give alsa-info.sh outputs on both working and non-working kernels (run with --no-upload option). thanks, Takashi

1 0

[alsa-devel] [PATCH RESEND] ASoC: sgtl5000: fix cache handling
by Wolfram Sang 03 Aug '11

03 Aug '11

Cache handling in this driver is broken. The chip has 16-bit registers, yet the register numbers also increase by 2 per register, i.e. there are only even-numbered registers. The cache in this driver, though, simply increments register numbers, so it does need some mapping as seen in sgtl5000_restore_regs(), note the '>> 1': snd_soc_write(codec, SGTL5000_CHIP_LINREG_CTRL, cache[SGTL5000_CHIP_LINREG_CTRL >> 1]); That, of course, won't work with snd_soc_update_bits(). (Thus, we won't even notice the missing register 0x1c in the default regs which shifted all follwing registers to wrong values.) Noticed on the MX28EVK where enabling the regulators simply locked up the chip. Refactor the routines and use a properly sized default_regs array which matches the register layout of the underlying chip, i.e. create a truly flat cache. This also saves some code which should make up for the bigger array a little. When soc-core will somewhen have another cache type which handles a step size, this conversion will also ease the transition. Signed-off-by: Wolfram Sang <w.sang(a)pengutronix.de> Tested-by: Dong Aisheng <b29396(a)freescale.com> Tested-by: Shawn Guo <shawn.guo(a)linaro.org> Cc: Zeng Zhaoming <b32542(a)freescale.com> Cc: Liam Girdwood <lrg(a)ti.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- Resending as suggested in a previous thread. sound/soc/codecs/sgtl5000.c | 128 ++++++++++++------------------------------- 1 files changed, 35 insertions(+), 93 deletions(-) diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index 76258f2..7e4066e 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -33,73 +33,31 @@ #define SGTL5000_DAP_REG_OFFSET 0x0100 #define SGTL5000_MAX_REG_OFFSET 0x013A -/* default value of sgtl5000 registers except DAP */ -static const u16 sgtl5000_regs[SGTL5000_MAX_REG_OFFSET >> 1] = { - 0xa011, /* 0x0000, CHIP_ID. 11 stand for revison 17 */ - 0x0000, /* 0x0002, CHIP_DIG_POWER. */ - 0x0008, /* 0x0004, CHIP_CKL_CTRL */ - 0x0010, /* 0x0006, CHIP_I2S_CTRL */ - 0x0000, /* 0x0008, reserved */ - 0x0008, /* 0x000A, CHIP_SSS_CTRL */ - 0x0000, /* 0x000C, reserved */ - 0x020c, /* 0x000E, CHIP_ADCDAC_CTRL */ - 0x3c3c, /* 0x0010, CHIP_DAC_VOL */ - 0x0000, /* 0x0012, reserved */ - 0x015f, /* 0x0014, CHIP_PAD_STRENGTH */ - 0x0000, /* 0x0016, reserved */ - 0x0000, /* 0x0018, reserved */ - 0x0000, /* 0x001A, reserved */ - 0x0000, /* 0x001E, reserved */ - 0x0000, /* 0x0020, CHIP_ANA_ADC_CTRL */ - 0x1818, /* 0x0022, CHIP_ANA_HP_CTRL */ - 0x0111, /* 0x0024, CHIP_ANN_CTRL */ - 0x0000, /* 0x0026, CHIP_LINREG_CTRL */ - 0x0000, /* 0x0028, CHIP_REF_CTRL */ - 0x0000, /* 0x002A, CHIP_MIC_CTRL */ - 0x0000, /* 0x002C, CHIP_LINE_OUT_CTRL */ - 0x0404, /* 0x002E, CHIP_LINE_OUT_VOL */ - 0x7060, /* 0x0030, CHIP_ANA_POWER */ - 0x5000, /* 0x0032, CHIP_PLL_CTRL */ - 0x0000, /* 0x0034, CHIP_CLK_TOP_CTRL */ - 0x0000, /* 0x0036, CHIP_ANA_STATUS */ - 0x0000, /* 0x0038, reserved */ - 0x0000, /* 0x003A, CHIP_ANA_TEST2 */ - 0x0000, /* 0x003C, CHIP_SHORT_CTRL */ - 0x0000, /* reserved */ -}; - -/* default value of dap registers */ -static const u16 sgtl5000_dap_regs[] = { - 0x0000, /* 0x0100, DAP_CONTROL */ - 0x0000, /* 0x0102, DAP_PEQ */ - 0x0040, /* 0x0104, DAP_BASS_ENHANCE */ - 0x051f, /* 0x0106, DAP_BASS_ENHANCE_CTRL */ - 0x0000, /* 0x0108, DAP_AUDIO_EQ */ - 0x0040, /* 0x010A, DAP_SGTL_SURROUND */ - 0x0000, /* 0x010C, DAP_FILTER_COEF_ACCESS */ - 0x0000, /* 0x010E, DAP_COEF_WR_B0_MSB */ - 0x0000, /* 0x0110, DAP_COEF_WR_B0_LSB */ - 0x0000, /* 0x0112, reserved */ - 0x0000, /* 0x0114, reserved */ - 0x002f, /* 0x0116, DAP_AUDIO_EQ_BASS_BAND0 */ - 0x002f, /* 0x0118, DAP_AUDIO_EQ_BAND0 */ - 0x002f, /* 0x011A, DAP_AUDIO_EQ_BAND2 */ - 0x002f, /* 0x011C, DAP_AUDIO_EQ_BAND3 */ - 0x002f, /* 0x011E, DAP_AUDIO_EQ_TREBLE_BAND4 */ - 0x8000, /* 0x0120, DAP_MAIN_CHAN */ - 0x0000, /* 0x0122, DAP_MIX_CHAN */ - 0x0510, /* 0x0124, DAP_AVC_CTRL */ - 0x1473, /* 0x0126, DAP_AVC_THRESHOLD */ - 0x0028, /* 0x0128, DAP_AVC_ATTACK */ - 0x0050, /* 0x012A, DAP_AVC_DECAY */ - 0x0000, /* 0x012C, DAP_COEF_WR_B1_MSB */ - 0x0000, /* 0x012E, DAP_COEF_WR_B1_LSB */ - 0x0000, /* 0x0130, DAP_COEF_WR_B2_MSB */ - 0x0000, /* 0x0132, DAP_COEF_WR_B2_LSB */ - 0x0000, /* 0x0134, DAP_COEF_WR_A1_MSB */ - 0x0000, /* 0x0136, DAP_COEF_WR_A1_LSB */ - 0x0000, /* 0x0138, DAP_COEF_WR_A2_MSB */ - 0x0000, /* 0x013A, DAP_COEF_WR_A2_LSB */ +/* default value of sgtl5000 registers */ +static const u16 sgtl5000_regs[SGTL5000_MAX_REG_OFFSET] = { + [SGTL5000_CHIP_CLK_CTRL] = 0x0008, + [SGTL5000_CHIP_I2S_CTRL] = 0x0010, + [SGTL5000_CHIP_SSS_CTRL] = 0x0008, + [SGTL5000_CHIP_DAC_VOL] = 0x3c3c, + [SGTL5000_CHIP_PAD_STRENGTH] = 0x015f, + [SGTL5000_CHIP_ANA_HP_CTRL] = 0x1818, + [SGTL5000_CHIP_ANA_CTRL] = 0x0111, + [SGTL5000_CHIP_LINE_OUT_VOL] = 0x0404, + [SGTL5000_CHIP_ANA_POWER] = 0x7060, + [SGTL5000_CHIP_PLL_CTRL] = 0x5000, + [SGTL5000_DAP_BASS_ENHANCE] = 0x0040, + [SGTL5000_DAP_BASS_ENHANCE_CTRL] = 0x051f, + [SGTL5000_DAP_SURROUND] = 0x0040, + [SGTL5000_DAP_EQ_BASS_BAND0] = 0x002f, + [SGTL5000_DAP_EQ_BASS_BAND1] = 0x002f, + [SGTL5000_DAP_EQ_BASS_BAND2] = 0x002f, + [SGTL5000_DAP_EQ_BASS_BAND3] = 0x002f, + [SGTL5000_DAP_EQ_BASS_BAND4] = 0x002f, + [SGTL5000_DAP_MAIN_CHAN] = 0x8000, + [SGTL5000_DAP_AVC_CTRL] = 0x0510, + [SGTL5000_DAP_AVC_THRESHOLD] = 0x1473, + [SGTL5000_DAP_AVC_ATTACK] = 0x0028, + [SGTL5000_DAP_AVC_DECAY] = 0x0050, }; /* regulator supplies for sgtl5000, VDDD is an optional external supply */ @@ -1023,12 +981,10 @@ static int sgtl5000_suspend(struct snd_soc_codec *codec, pm_message_t state) static int sgtl5000_restore_regs(struct snd_soc_codec *codec) { u16 *cache = codec->reg_cache; - int i; - int regular_regs = SGTL5000_CHIP_SHORT_CTRL >> 1; + u16 reg; /* restore regular registers */ - for (i = 0; i < regular_regs; i++) { - int reg = i << 1; + for (reg = 0; reg <= SGTL5000_CHIP_SHORT_CTRL; reg += 2) { /* this regs depends on the others */ if (reg == SGTL5000_CHIP_ANA_POWER || @@ -1038,35 +994,31 @@ static int sgtl5000_restore_regs(struct snd_soc_codec *codec) reg == SGTL5000_CHIP_CLK_CTRL) continue; - snd_soc_write(codec, reg, cache[i]); + snd_soc_write(codec, reg, cache[reg]); } /* restore dap registers */ - for (i = SGTL5000_DAP_REG_OFFSET >> 1; - i < SGTL5000_MAX_REG_OFFSET >> 1; i++) { - int reg = i << 1; - - snd_soc_write(codec, reg, cache[i]); - } + for (reg = SGTL5000_DAP_REG_OFFSET; reg < SGTL5000_MAX_REG_OFFSET; reg += 2) + snd_soc_write(codec, reg, cache[reg]); /* * restore power and other regs according * to set_power() and set_clock() */ snd_soc_write(codec, SGTL5000_CHIP_LINREG_CTRL, - cache[SGTL5000_CHIP_LINREG_CTRL >> 1]); + cache[SGTL5000_CHIP_LINREG_CTRL]); snd_soc_write(codec, SGTL5000_CHIP_ANA_POWER, - cache[SGTL5000_CHIP_ANA_POWER >> 1]); + cache[SGTL5000_CHIP_ANA_POWER]); snd_soc_write(codec, SGTL5000_CHIP_CLK_CTRL, - cache[SGTL5000_CHIP_CLK_CTRL >> 1]); + cache[SGTL5000_CHIP_CLK_CTRL]); snd_soc_write(codec, SGTL5000_CHIP_REF_CTRL, - cache[SGTL5000_CHIP_REF_CTRL >> 1]); + cache[SGTL5000_CHIP_REF_CTRL]); snd_soc_write(codec, SGTL5000_CHIP_LINE_OUT_CTRL, - cache[SGTL5000_CHIP_LINE_OUT_CTRL >> 1]); + cache[SGTL5000_CHIP_LINE_OUT_CTRL]); return 0; } @@ -1454,16 +1406,6 @@ static __devinit int sgtl5000_i2c_probe(struct i2c_client *client, if (!sgtl5000) return -ENOMEM; - /* - * copy DAP default values to default value array. - * sgtl5000 register space has a big hole, merge it - * at init phase makes life easy. - * FIXME: should we drop 'const' of sgtl5000_regs? - */ - memcpy((void *)(&sgtl5000_regs[0] + (SGTL5000_DAP_REG_OFFSET >> 1)), - sgtl5000_dap_regs, - SGTL5000_MAX_REG_OFFSET - SGTL5000_DAP_REG_OFFSET); - i2c_set_clientdata(client, sgtl5000); ret = snd_soc_register_codec(&client->dev, -- 1.7.2.5

3 2