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

Re: [alsa-devel] [PATCH] ASoC: wm1250-ev1: Define "WM1250 Output" with SND_SOC_DAPM_OUTPUT
by Liam Girdwood 26 May '11

26 May '11

On 26/05/11 03:54, Axel Lin wrote: > Codec output pin should be defined with SND_SOC_DAPM_OUTPUT. > > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> > --- > Note: > Just found this bug while reading the code. > I don't have this hardware handy. I appreciate if someone can test it. > > Axel > The fix does look correct. Acked-by: Liam Girdwood <lrg(a)ti.com>

1 0

[alsa-devel] Patch series for Fast Track Ultra mixer quirks
by Daniel Mack 26 May '11

26 May '11

Here's the set of patches to make Fast Track Ultra mixer quirks possible. It's just a split version of the patch we've discussed on the ALSA ML before. These patches can as well be pulled from git@github.com:zonque/linux-2.6.git usb-audio Daniel Mack (5): ALSA: usb-audio: move assignment of chip->ctrl_intf ALSA: usb-audio: rework add_control_to_empty() ALSA: usb-audio: export snd_usb_feature_unit_ctl ALSA: usb-audio: add new quirk type QUIRK_AUDIO_STANDARD_MIXER ALSA: usb-audio: more control quirks for M-Audio FastTrack devices sound/usb/card.c | 17 ++++++----- sound/usb/mixer.c | 32 ++++++++------------ sound/usb/mixer.h | 14 ++++++++- sound/usb/mixer_quirks.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++ sound/usb/quirks-table.h | 4 +- sound/usb/quirks.c | 18 +++++++++++- sound/usb/usbaudio.h | 1 + 7 files changed, 125 insertions(+), 31 deletions(-)

4 11

Re: [alsa-devel] [PATCH] sound core: remove unused variables.
by Takashi Iwai 26 May '11

26 May '11

At Wed, 25 May 2011 22:43:27 +0200, Luca Tettamanti wrote: > > Drop a few variables that are never read. > > Signed-off-by: Luca Tettamanti <kronos.it(a)gmail.com> Applied now. Thanks. Takashi > --- > sound/core/control.c | 3 +-- > sound/core/init.c | 3 --- > sound/core/oss/linear.c | 3 --- > sound/core/pcm_native.c | 8 -------- > sound/core/seq/seq_queue.c | 2 -- > 5 files changed, 1 insertions(+), 18 deletions(-) > > diff --git a/sound/core/control.c b/sound/core/control.c > index 5d98194..f8c5be4 100644 > --- a/sound/core/control.c > +++ b/sound/core/control.c > @@ -704,13 +704,12 @@ static int snd_ctl_elem_list(struct snd_card *card, > struct snd_ctl_elem_list list; > struct snd_kcontrol *kctl; > struct snd_ctl_elem_id *dst, *id; > - unsigned int offset, space, first, jidx; > + unsigned int offset, space, jidx; > > if (copy_from_user(&list, _list, sizeof(list))) > return -EFAULT; > offset = list.offset; > space = list.space; > - first = 0; > /* try limit maximum space */ > if (space > 16384) > return -ENOMEM; > diff --git a/sound/core/init.c b/sound/core/init.c > index 30ecad4..2c041bb 100644 > --- a/sound/core/init.c > +++ b/sound/core/init.c > @@ -342,7 +342,6 @@ static const struct file_operations snd_shutdown_f_ops = > int snd_card_disconnect(struct snd_card *card) > { > struct snd_monitor_file *mfile; > - struct file *file; > int err; > > if (!card) > @@ -366,8 +365,6 @@ int snd_card_disconnect(struct snd_card *card) > > spin_lock(&card->files_lock); > list_for_each_entry(mfile, &card->files_list, list) { > - file = mfile->file; > - > /* it's critical part, use endless loop */ > /* we have no room to fail */ > mfile->disconnected_f_op = mfile->file->f_op; > diff --git a/sound/core/oss/linear.c b/sound/core/oss/linear.c > index 13b3f6f..2045697 100644 > --- a/sound/core/oss/linear.c > +++ b/sound/core/oss/linear.c > @@ -90,11 +90,8 @@ static snd_pcm_sframes_t linear_transfer(struct snd_pcm_plugin *plugin, > struct snd_pcm_plugin_channel *dst_channels, > snd_pcm_uframes_t frames) > { > - struct linear_priv *data; > - > if (snd_BUG_ON(!plugin || !src_channels || !dst_channels)) > return -ENXIO; > - data = (struct linear_priv *)plugin->extra_data; > if (frames == 0) > return 0; > #ifdef CONFIG_SND_DEBUG > diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c > index 1a07750..3a5f86d 100644 > --- a/sound/core/pcm_native.c > +++ b/sound/core/pcm_native.c > @@ -1518,13 +1518,11 @@ static int snd_pcm_drain(struct snd_pcm_substream *substream, > static int snd_pcm_drop(struct snd_pcm_substream *substream) > { > struct snd_pcm_runtime *runtime; > - struct snd_card *card; > int result = 0; > > if (PCM_RUNTIME_CHECK(substream)) > return -ENXIO; > runtime = substream->runtime; > - card = substream->pcm->card; > > if (runtime->status->state == SNDRV_PCM_STATE_OPEN || > runtime->status->state == SNDRV_PCM_STATE_DISCONNECTED || > @@ -2056,7 +2054,6 @@ static int snd_pcm_open_file(struct file *file, > { > struct snd_pcm_file *pcm_file; > struct snd_pcm_substream *substream; > - struct snd_pcm_str *str; > int err; > > if (rpcm_file) > @@ -2073,7 +2070,6 @@ static int snd_pcm_open_file(struct file *file, > } > pcm_file->substream = substream; > if (substream->ref_count == 1) { > - str = substream->pstr; > substream->file = pcm_file; > substream->pcm_release = pcm_release_private; > } > @@ -3015,11 +3011,9 @@ static const struct vm_operations_struct snd_pcm_vm_ops_status = > static int snd_pcm_mmap_status(struct snd_pcm_substream *substream, struct file *file, > struct vm_area_struct *area) > { > - struct snd_pcm_runtime *runtime; > long size; > if (!(area->vm_flags & VM_READ)) > return -EINVAL; > - runtime = substream->runtime; > size = area->vm_end - area->vm_start; > if (size != PAGE_ALIGN(sizeof(struct snd_pcm_mmap_status))) > return -EINVAL; > @@ -3054,11 +3048,9 @@ static const struct vm_operations_struct snd_pcm_vm_ops_control = > static int snd_pcm_mmap_control(struct snd_pcm_substream *substream, struct file *file, > struct vm_area_struct *area) > { > - struct snd_pcm_runtime *runtime; > long size; > if (!(area->vm_flags & VM_READ)) > return -EINVAL; > - runtime = substream->runtime; > size = area->vm_end - area->vm_start; > if (size != PAGE_ALIGN(sizeof(struct snd_pcm_mmap_control))) > return -EINVAL; > diff --git a/sound/core/seq/seq_queue.c b/sound/core/seq/seq_queue.c > index e7a8e9e..f907736 100644 > --- a/sound/core/seq/seq_queue.c > +++ b/sound/core/seq/seq_queue.c > @@ -467,13 +467,11 @@ int snd_seq_queue_timer_open(int queueid) > int snd_seq_queue_timer_close(int queueid) > { > struct snd_seq_queue *queue; > - struct snd_seq_timer *tmr; > int result = 0; > > queue = queueptr(queueid); > if (queue == NULL) > return -EINVAL; > - tmr = queue->timer; > snd_seq_timer_close(queue); > queuefree(queue); > return result; > -- > 1.7.5.1 >

1 0

[alsa-devel] [PATCH] ALSA: ASoC: Fix comment in cs4270 codec driver
by Daniel Mack 26 May '11

26 May '11

The comment does not reflect reality anymore since the multi-component monster patch landed. Things are matched by names now, and not by exporting and referencing a struct. Fix it to avoid confusion. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg(a)slimlogic.co.uk> --- sound/soc/codecs/cs4270.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/cs4270.c b/sound/soc/codecs/cs4270.c index 0206a17..6cc8678 100644 --- a/sound/soc/codecs/cs4270.c +++ b/sound/soc/codecs/cs4270.c @@ -636,10 +636,7 @@ static int cs4270_soc_resume(struct snd_soc_codec *codec) #endif /* CONFIG_PM */ /* - * ASoC codec device structure - * - * Assign this variable to the codec_dev field of the machine driver's - * snd_soc_device structure. + * ASoC codec driver structure */ static const struct snd_soc_codec_driver soc_codec_device_cs4270 = { .probe = cs4270_probe, -- 1.7.5.1

4 4

[alsa-devel] Driver debugging help: OSS emulation and different results
by Mike Crowe 26 May '11

26 May '11

Hi folks, I know this is vague, and probably not worthy of this list. However, I'm struggling with where to go next. Here's the deal: - I have an embedded system where we have developed the soc driver, and it appears to be working fine - We have a VoIP library we are integrating, and only have object files and almost no support - The VoIP library uses OSS interface with our hardware - We validated our hardware using vrec/vplay, both OSS applications. They record and play fine (as does the ALSA arecord/aplay as well) - I have the output (playback) working on the VoIP library side, but the recording is choppy (though seems to be at the right frequency now) So, what I need to do next is try and understand how the library is opening OSS differently from vrec/vplay. However, I'm not sure where to start. Can somebody give me a high level pointer as to how to add some debugging output to my system to capture what is different between these two sessions? Where should I start? TIA Mike

1 0

[alsa-devel] EDID-like data for audio: Port correlation between ALSA and X
by Stephen Warren 25 May '11

25 May '11

(starting a new cross-mailing-list thread following some small discussion on this topic on alsa-devel) Background: Many recent graphics cards support sending an audio stream over HDMI or DisplayPort. This is supported by an HD-audio controller built into the graphics card. It'd be nice if configuration tools could easily determine which ALSA devices correspond to which X displays. Current implementation details: The X driver reads the EDID from the display, reformats it as an ELD ("EDID-Like Data"), as specified by the Intel HD-audio specification, and somehow communicates this into the HD-audio controller that's embedded into the graphics card, using a card-specific mechanism. The HD-audio controller then communicates the ELD to the driver in a standard-specified manner: The HW triggers an "unsolicited response" to notify the ALSA driver of a change in the data, and then the ALSA driver reads the ELD data using HD-audio commands (verbs). Finally, the eventual idea is that user-space applications will be able to read the ELD data from the ALSA driver for each PCM. In the HD-audio controller, there is a "pin widget" for each video output (HDMI port, DP port). ELD data is associated with a specific pin widget. ALSA creates a single "PCM" or audio device per pin widget. New discussion: We need some way of tying pin widgets or ALSA PCMs to the X display path that the audio data will be merged into. Option A: We can pass some X-specific data in the ELD. The ELD contains an 8-byte Port_ID field for this purpose. The display driver is supposed to fill this with some meaningful data, and ALSA (or an application) is supposed to interpret the field. Some possibilities for this field are: A1) An XRandR property, such as ConnectorNumber or Output. To me, this seems the simplest option overall; the X driver already has access to this information, so it should be fairly easy to place it into the ELD. The only downside here is that the NVIDIA binary driver doesn't currently implement recent XRandR versions, so we probably couldn't do this right now. A2) NVIDIA's graphics driver fills this field with an internal "display ID" value, which I believe is usable without our NV-CTRL X extension. This obviously isn't ideal for applications interpreting this data, since the format isn't cross-vendor. Applications don't want to interpret the ELD in N different ways. Option B: We can invent some X/XRandR property that refers to some ALSA HW or SW property. Applications can then enumerate this X/XRandR property for all outputs, and use that data to access the appropriate ALSA device. That data could be: B1) ALSA PCM name (e.g. "hw:1,3"). While perhaps technically feasible, it'd be pretty painful to determine this from the X driver. Sysfs parsing of ALSA-related data would probably work, but this kind of thing would be better done elsewhere than the X driver, especially if the ELD handoff is implemented in the kernel by a KMS driver. B2) HD-audio controller pin widget ID. This requires the X driver to know the internal architecture of the HD-audio controller. While technically perhaps not too hard, it'd most likely mean maintaining tables of audio-related data in the X driver, which is probably not something we'd want to do. Equally, the pin widget ID might not be the most useful thing to an application. AFAIK, ALSA doesn't have an API for exposing this information at present, except through user-oriented debug files in /proc. Does anyone see any other options? Do people agree that option A1 is the best? Related issues: There are issues correlating ALSA and X data such as XRandR connector numbers in the face of multiple X servers, remote X servers, VT-switching, etc. However, I believe most of these issues need to be solved outside the context of this discussion anyway, and hence probably don't affect this discussion much. Probably, PulseAudio already interfaces with DeviceKit or SomethingKit to solve some of these issues? Thanks for reading! -- nvpublic

1 0

[alsa-devel] [PATCH] ASoc: wm8731: fix wm8731_check_osc() connected condition
by Nicolas Ferre 25 May '11

25 May '11

The crystal oscillator is only enabled if the WM8731_SYSCLK_XTAL master clock is specified. Fix the connected() struct snd_soc_dapm_route function to take this into account. Oscillator is not enabled on machine that need it otherwise. Machine drivers have to make sure that they use the proper SYSCLK value. Signed-off-by: Nicolas Ferre <nicolas.ferre(a)atmel.com> --- sound/soc/codecs/wm8731.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c index 6dec7ce..2dc964b 100644 --- a/sound/soc/codecs/wm8731.c +++ b/sound/soc/codecs/wm8731.c @@ -198,7 +198,7 @@ static int wm8731_check_osc(struct snd_soc_dapm_widget *source, { struct wm8731_priv *wm8731 = snd_soc_codec_get_drvdata(source->codec); - return wm8731->sysclk_type == WM8731_SYSCLK_MCLK; + return wm8731->sysclk_type == WM8731_SYSCLK_XTAL; } static const struct snd_soc_dapm_route wm8731_intercon[] = { -- 1.7.3

3 3

[alsa-devel] [PATCH] ASoc: sam9g20_wm8731: use the proper SYSCKL value
by Nicolas Ferre 25 May '11

25 May '11

at91sam9g20 is providing master clock to wm8731: not using a crystal but an external MCLK. We can avoid conflict and save power using WM8731_SYSCLK_MCLK as we do not need oscillator to be powered. Signed-off-by: Nicolas Ferre <nicolas.ferre(a)atmel.com> --- sound/soc/atmel/sam9g20_wm8731.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/atmel/sam9g20_wm8731.c b/sound/soc/atmel/sam9g20_wm8731.c index 28afbbf..95572d2 100644 --- a/sound/soc/atmel/sam9g20_wm8731.c +++ b/sound/soc/atmel/sam9g20_wm8731.c @@ -146,7 +146,7 @@ static int at91sam9g20ek_wm8731_init(struct snd_soc_pcm_runtime *rtd) "at91sam9g20ek_wm8731 " ": at91sam9g20ek_wm8731_init() called\n"); - ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL, + ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_MCLK, MCLK_RATE, SND_SOC_CLOCK_IN); if (ret < 0) { printk(KERN_ERR "Failed to set WM8731 SYSCLK: %d\n", ret); -- 1.7.3

3 3

[alsa-devel] [PATCH 0/6] ASoC: davinci-pcm: some fixes and convert to BATCH
by Ben Gardiner 25 May '11

25 May '11

This patchset is a collection of changes for the davinci-pcm driver that were accumulated during previous forays into the davinci-mcasp and davinci-pcm drivers [1]. The first three patches are minor changes that cleanup the ping-pong DMA params setup, expand the davinci-pcm reported format and also its maximum channels. The fourth patch in the series corrects an audible glitch that can be heard on da850evm's McASP when ping-pong buffers are enabled. The glitch occurs only on the second and susequent playbacks, not the first. Reversing the order in which the dma channels are started and moving the start to the trigger function from the prepare function fixes the glitch. The fifth and sixth patches in the series convert the davinci-pcm driver to BATCH mode. I noticed that the davinci-pcm pointer function is returning a value that is retrieved from within the running EDMA channel's state -- which is contrary to the warning in the comments of arch/arm/mach-davinci/dma.c:edma_get_position(): " * Returns current source and destination addresses for a particular * parameter RAM slot. Its channel should not be active when this is called. " To that end, we begin with some refactoring to centralize the modification of the davinci_runtime_data.period member. Followed by wholesale replacement of davinci_pcm_pointer() function so that it returns the position as reported by the last update of the period member -- along with corresponding changes to davinci_pcm_enqueue_dma() davinci_pcm_dma_irq() davinci_pcm_trigger() and reporting SNDRV_PCM_INFO_BATCH on playback and capture. The series has been tested with and without ping-pong buffers enabled [1]; furthermore, the pointer behaviour was inspected using both XRUN_DEBUG_PERIODUPDATE and XRUN_DEBUG_HWPTRUPDATE as well as the audio checked with headphones. Playback was tested with: echo 24 > /proc/asound/EVM/pcm0p/xrun_debug aplay -d 1 -t wav -D "default:CARD=EVM" test.wav echo 0 > /proc/asound/EVM/pcm0p/xrun_debug and capture was tested with (while playing test.wav on my PC into the capture input on the da850evm): #!/bin/bash echo 24 > /proc/asound/EVM/pcm0c/xrun_debug arecord -d 2 -t wav -D "default:CARD=EVM" -f dat - |aplay -t wav echo 0 > /proc/asound/EVM/pcm0c/xrun_debug Playback behaviour before (similar both with and without ping-pong buffers) ========================= hwptr_update: pcmC0D0p:0: pos=42/2048/32768, hwptr=42/0/42/0 hwptr_update: pcmC0D0p:0: pos=369/2048/32768, hwptr=327/42/369/0 hwptr_update: pcmC0D0p:0: pos=709/2048/32768, hwptr=340/369/709/0 hwptr_update: pcmC0D0p:0: pos=994/2048/32768, hwptr=285/709/994/0 hwptr_update: pcmC0D0p:0: pos=1367/2048/32768, hwptr=373/994/1367/0 hwptr_update: pcmC0D0p:0: pos=1729/2048/32768, hwptr=362/1367/1729/0 hwptr_update: pcmC0D0p:0: pos=2037/2048/32768, hwptr=308/1729/2037/0 period_update: pcmC0D0p:0: pos=2335/2048/32768, hwptr=298/2037/2335/0 hwptr_update: pcmC0D0p:0: pos=2762/2048/32768, hwptr=427/2335/2762/0 hwptr_update: pcmC0D0p:0: pos=3147/2048/32768, hwptr=385/2762/3147/0 hwptr_update: pcmC0D0p:0: pos=3456/2048/32768, hwptr=309/3147/3456/0 hwptr_update: pcmC0D0p:0: pos=3851/2048/32768, hwptr=395/3456/3851/0 period_update: pcmC0D0p:0: pos=4150/2048/32768, hwptr=299/3851/4150/0 [...] Playback behaviour after (identical both with and without ping-pong buffers) ======================== hwptr_update: pcmC0D0p:0: pos=0/2048/32768, hwptr=0/0/0/0 period_update: pcmC0D0p:0: pos=2048/2048/32768, hwptr=2048/0/2048/0 hwptr_update: pcmC0D0p:0: pos=2048/2048/32768, hwptr=0/2048/2048/0 period_update: pcmC0D0p:0: pos=4096/2048/32768, hwptr=2048/2048/4096/0 [...] [Capture behaviour was very similarly modified by this patchset] The playback behaviour before shows inconsistent increments of the pointers in syscall and interrupt context -- this is due to the pointer function peeking into the parameters of the dma channel. The playback behaviour afterwards shows regular increments from interrupt context. Which is to be expected since the driver now reports an incremented pointer after each dma completion. It seems that the conversion to BATCH mode is beneficial -- other than obeying the warning comment in dma.c -- since there appear to be fewer syscalls per execution of aplay. [1] http://article.gmane.org/gmane.linux.alsa.devel/85122 Ben Gardiner (6): ASoC: davinci-pcm: trivial: make ping-pong params setup symmetrical ASoC: davinci-pcm: expand the .formats ASoC: davinci-pcm: increase the maximum channels ASoC: davinci-pcm: fix audible glitch on 2nd ping-pong playback ASoC: davinci-pcm: extract period elapsed functions ASoC: davinci-pcm: convert to BATCH mode sound/soc/davinci/davinci-pcm.c | 127 ++++++++++++++++++++------------------- 1 files changed, 65 insertions(+), 62 deletions(-) -- 1.7.4.1

3 13

[alsa-devel] [PATCH] ALSA: HDA: Use AZX_DRIVER_ATI for AMD/ATI platforms
by Andiry Xu 25 May '11

25 May '11

This commit makes AMD/ATI platforms use AZX_DRIVER_ATI for SB HD Audio and AZX_DRIVER_ATIHDMI for HDMI Audio, so some quirks can be applied to AMD/ATI platforms without checking the pci vendor ID. This also spearate SB and HDMI audio, since some quirks should only apply to SB audio. Signed-off-by: Andiry Xu <andiry.xu(a)amd.com> --- sound/pci/hda/hda_intel.c | 31 +++++++++++-------------------- 1 files changed, 11 insertions(+), 20 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 43a0367..05f551c 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1062,7 +1062,9 @@ static void azx_init_pci(struct azx *chip) switch (chip->driver_type) { case AZX_DRIVER_ATI: - /* For ATI SB450 azalia HD audio, we need to enable snoop */ + /* For ATI SB450/600/700/800/900 and AMD Hudson azalia + * HD audio, we need to enable snoop. + */ update_pci_byte(chip->pci, ATI_SB450_HDAUDIO_MISC_CNTR2_ADDR, 0x07, ATI_SB450_HDAUDIO_ENABLE_SNOOP); @@ -1092,13 +1094,6 @@ static void azx_init_pci(struct azx *chip) ? "Failed" : "OK"); } break; - default: - /* AMD Hudson needs the similar snoop, as it seems... */ - if (chip->pci->vendor == PCI_VENDOR_ID_AMD) - update_pci_byte(chip->pci, - ATI_SB450_HDAUDIO_MISC_CNTR2_ADDR, - 0x07, ATI_SB450_HDAUDIO_ENABLE_SNOOP); - break; } } @@ -1457,8 +1452,7 @@ static int __devinit azx_codec_create(struct azx *chip, const char *model) * sequence like the pin-detection. It seems that forcing the synced * access works around the stall. Grrr... */ - if (chip->pci->vendor == PCI_VENDOR_ID_AMD || - chip->pci->vendor == PCI_VENDOR_ID_ATI) { + if (chip->driver_type == AZX_DRIVER_ATI) { snd_printk(KERN_INFO SFX "Enable sync_write for AMD chipset\n"); chip->bus->sync_write = 1; chip->bus->allow_bus_reset = 1; @@ -2370,13 +2364,8 @@ static int __devinit check_position_fix(struct azx *chip, int fix) /* Use link position directly, avoid any transfer problem. */ return POS_FIX_VIACOMBO; case AZX_DRIVER_ATI: - /* ATI chipsets don't work well with position-buffer */ + /* ATI/AMD chipsets don't support position-buffer */ return POS_FIX_LPIB; - case AZX_DRIVER_GENERIC: - /* AMD chipsets also don't work with position-buffer */ - if (chip->pci->vendor == PCI_VENDOR_ID_AMD) - return POS_FIX_LPIB; - break; } return POS_FIX_AUTO; @@ -2800,9 +2789,11 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = { .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, .class_mask = 0xffffff, .driver_data = AZX_DRIVER_ICH }, - /* ATI SB 450/600 */ + /* ATI SB 450/600/700/800/900 */ { PCI_DEVICE(0x1002, 0x437b), .driver_data = AZX_DRIVER_ATI }, { PCI_DEVICE(0x1002, 0x4383), .driver_data = AZX_DRIVER_ATI }, + /* AMD Hudson */ + { PCI_DEVICE(0x1022, 0x780d), .driver_data = AZX_DRIVER_ATI }, /* ATI HDMI */ { PCI_DEVICE(0x1002, 0x793b), .driver_data = AZX_DRIVER_ATIHDMI }, { PCI_DEVICE(0x1002, 0x7919), .driver_data = AZX_DRIVER_ATIHDMI }, @@ -2849,15 +2840,15 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = { { PCI_DEVICE(0x17f3, 0x3010), .driver_data = AZX_DRIVER_GENERIC }, /* VMware HDAudio */ { PCI_DEVICE(0x15ad, 0x1977), .driver_data = AZX_DRIVER_GENERIC }, - /* AMD/ATI Generic, PCI class code and Vendor ID for HD Audio */ + /* AMD/ATI Generic, PCI class code and Vendor ID for HDMI Audio */ { PCI_DEVICE(PCI_VENDOR_ID_ATI, PCI_ANY_ID), .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, .class_mask = 0xffffff, - .driver_data = AZX_DRIVER_GENERIC }, + .driver_data = AZX_DRIVER_ATIHDMI }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_ANY_ID), .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, .class_mask = 0xffffff, - .driver_data = AZX_DRIVER_GENERIC }, + .driver_data = AZX_DRIVER_ATIHDMI }, { 0, } }; MODULE_DEVICE_TABLE(pci, azx_ids); -- 1.7.1

3 3