- 21 Jun, 2011 2 commits
-
-
Takashi Iwai authored
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Ian Minett authored
Create patch_ca0132.c, to add support for devices featuring the Creative CA0132 HD-audio codec. This driver implements :- * 1 playback subdevice to headphone and speaker * 2 capture subdevices: i - Mic-in ii- Line-in * mixer device Advanced DSP features are not yet included. Developed and maintained by Creative Labs, Inc. Signed-off-by: Ian Minett <ian_minett@creativelabs.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 20 Jun, 2011 1 commit
-
-
Takashi Iwai authored
Just a minor clean up; nid-mapping can be set directly to the smart51 mixer element. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 17 Jun, 2011 1 commit
-
-
David Henningsson authored
Now that we have changed the position_fix default for ATI and AMD to be LPIB (see commit 50e3bbf9), we can remove the quirks that were added for ATI chipsets. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 13 Jun, 2011 4 commits
-
-
Greg Thelen authored
If given a -1 cmd parameter then make_exec_verb() returns -1 without setting the res output value. Prior to this change snd_hda_codec_read() assumed that make_exec_verb() unconditionally set res regardless of the cmd value. This change explicitly checks the make_exec_verb() return value before consuming the potentially unset res value. Signed-off-by: Greg Thelen <gthelen@google.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
-
Joe Perches authored
Using static inline functions can reduce compilation messages and macro misuse. sound/pci/hda/patch_conexant.c: In function ‘patch_cxt5045’: sound/pci/hda/patch_conexant.c:1232:3: warning: statement with no effect Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The auto-mute setup for Acer Aspire-one with ALC268 was set wrongly during the clean-up of auto-mute function. Fixed now. Tested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 12 Jun, 2011 4 commits
-
-
Florian Zeitz authored
This patch adds the necessary details to support the PCIe version of E-MU's 0404 card. From comparing the PCBs it seems the PCIe version just added a PCIe chipset and left all other components pretty much in place. For anyone intrigued to take a look at the PCB there are pictures I took at <http://babelmonkeys.de/~florob/E-MU%200404/>. Signed-off-by: Florian Zeitz <florob@babelmonkeys.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Adrian Knoth authored
The PCI version of the RME HDSP MADI card uses 0xcf as revision ID. Just add this to the list of supported cards. Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Adrian Knoth authored
When using Word Clock on RME MADI cards, AutoSync mode was alternating betweeen MADI and WC due to a typo: AutoSync is indicated in the second status register (status2), not the first one (status). While the proc output was always correct, the reported WC frequency to ALSA was unstable as mentioned in http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006723.htmlSigned-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Adrian Knoth authored
For the MIDI part, we need to acquire (and release) the hmidi->lock, access to the global hdspm structure is serialized through hmidi->hdspm->lock instead. Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 10 Jun, 2011 8 commits
-
-
Takashi Iwai authored
-
Daniel T Chen authored
BugLink: https://launchpad.net/bugs/761171 The original reporter needs the model=auto quirk for his internal speakers to be audible in the latest daily snapshot, so add an entry in the quirk table for his PCI SSID. A trivially different version of this patch using the model=asus quirk should be applied to the 2.6.38 and 2.6.39 stable kernels. We don't use the asus quirk in 3.0-rc2, because 3.0-rc2's autoparser is much improved. Reported-and-tested-by: tomdeering7 Signed-off-by: Daniel T Chen <crimsun@ubuntu.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Clean up snd_printk() helper using the %pV prefix for recursive printks. This also automagically fixes an Oops with RO/NX-enabled modules. Tested-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Some Reatlek model quirks use master_mute bool switch for controlling the master-mute of outputs. For these cases, the initialization of HP pins/amps were forgotten during the transition to the common automute helper function in 3.0 development time, and resulted in the muted HP output as default. This patch fixes the issue by adjusting the HP output explicitly with master_mute switch. Tested-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The tag number was forgotten to be fixed after cleaning up the model quirks for ALC262 fujitsu and lenovo-3000 models. Tested-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
SSYNC register was once defined as 0x34-37 in the old Intel datasheet, but corrected later to 0x38-3b. For fixing the register usage, a new bit-flag is introduced for indicating the old ICH SSYNC register, and ICH* PCI entries are added explicitly to enable this quirk. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Some HP laptops with AD1981 have SPDIF connections, but currently the driver disables it statically. Better to check the pin default config to judge whether to enable or disable the SPDIF. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Sangbeom Kim authored
If DMA active status should be checked, I2SCON register should be referenced. In this patch, Fix the incorrect referencing of I2SCON register. Reported-by : Lakkyung Jung <lakkyung.jung@samsung.com> Signed-off-by: Sangbeom Kim <sbkim73@samsung.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org
-
- 09 Jun, 2011 3 commits
-
-
Lars-Peter Clausen authored
Currently it is possible that snd_soc_new_{mixer,mux,pga} is called with a DAPM context not matching the widgets context. This can lead to a wrong prefix_len calculation, which will result in undefined behaviour. To avoid this always use the DAPM context from the widget itself. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org
-
Timur Tabi authored
The DMA (PCM) driver used by some Freescale PowerPC supports separate DAIs for playback and capture, so DMA buffers should be allocated only for the initialized streams. Instead of checking for the number of active channels, which apparently is not reliable, check to see if the actual stream object exists. Also provide a better name for the DMA interrupt. Signed-off-by: Timur Tabi <timur@freescale.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-
Mark Brown authored
Reported-by: Kieran O'Leary <Kieran.O'Leary@wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Cc: stable@kernel.org
-
- 08 Jun, 2011 1 commit
-
-
Mark Brown authored
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Cc: stable@kernel.org
-
- 07 Jun, 2011 4 commits
-
-
Takashi Iwai authored
Instead of checking the azx_dev index with a fixed number (4), check the stream direction of the assigned substream. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
When reading from the position-buffer results in -1, handle as it's invalid and falls back to LPIB mode as well as 0. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Lars-Peter Clausen authored
Fix the codec_name field of the dai_link to match the actual device name of the codec. Otherwise the card won't be instantiated. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org
-
Daniel T Chen authored
BugLink: https://launchpad.net/bugs/792712 The original reporter states that sound from the internal speakers is inaudible until using the model=auto quirk. This symptom is due to an existing quirk mask for 0x102802b* that uses the model=dell quirk. To limit the possible regressions, leave the existing quirk mask but add a higher priority specific mask for the reporter's PCI SSID. Reported-and-tested-by: rodni hipp Cc: <stable@kernel.org> [2.6.38+] Signed-off-by: Daniel T Chen <crimsun@ubuntu.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 06 Jun, 2011 12 commits
-
-
Lars-Peter Clausen authored
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org
-
Mark Brown authored
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
-
Mark Brown authored
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
-
Mark Brown authored
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
-
Stephen Warren authored
The general concept of this change is to create a PCM device for each pin widget instead of each converter widget. Whenever a PCM is opened, a converter is dynamically selected to drive that pin based on those available for muxing into the pin. The one thing this model doesn't support is a single PCM/converter sending audio to multiple pin widgets at once. Note that this means that a struct hda_pcm_stream's nid variable is set to 0 except between a stream's open and cleanup calls. The dynamic de-assignment of converters to PCMs occurs within cleanup, not close, in order for it to co-incide with when controller stream IDs are cleaned up from converters. While the PCM for a pin is not open, the pin is disabled (its widget control's PIN_OUT bit is cleared) so that if the currently routed converter is used to drive a different PCM/pin, that audio does not leak out over a disabled pin. We use the recently added SPDIF virtualization feature in order to create SPDIF controls for each pin widget instead of each converter widget, so that state is specific to a PCM. In order to support this, a number of more mechanical changes are made: * s/nid/pin_nid/ or s/nid/cvt_nid/ in many places in order to make it clear exactly what the code is dealing with. * We now have per_pin and per_cvt arrays in hdmi_spec to store relevant data. In particular, we store a converter's capabilities in the per_cvt entry, rather than relying on a combination of codec_pcm_pars and the struct hda_pcm_stream. * ELD-related workarounds were removed from hdmi_channel_allocation into hdmi_instrinsic in order to simplifiy infoframe calculations and remove HW dependencies. * Various functions only apply to a single pin, since there is now only 1 pin per PCM. For example, hdmi_setup_infoframe, hdmi_setup_stream. * hdmi_add_pin and hdmi_add_cvt are more oriented at pure codec parsing and data retrieval, rather than determining which pins/converters are to be used for creating PCMs. This is quite a large change; it may be appropriate to simply read the result of the patch rather than the diffs. Some small parts of the change might be separable into different patches, but I think the bulk of the change will probably always be one large patch. Hopefully the change isn't too opaque! This has been tested on: * NVIDIA GeForce 400 series discrete graphics card. This model has the classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM audio to a PC monitor that supports audio. * NVIDIA GeForce 520 discrete graphics card. This model is the new 1 codec n converters m pins m>n model. Tested stereo PCM audio to a PC monitor that supports audio. * NVIDIA GeForce 400 series laptop graphics chip. This model has the classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM, multi-channel PCM, and AC3 pass-through to an AV receiver. * Intel Ibex Peak laptop. This model is the new 1 codec n converters m pins m>n model. Tested stereo PCM, multi-channel PCM, and AC3 pass- through to an AV receiver. Note that I'm not familiar at all with AC3 pass-through. Hence, I may not have covered all possible mechanisms that are applicable here. I do know that my receiver definitely received AC3, not decoded PCM. I tested with mplayer's "-afm hwac3" and/or "-af lavcac3enc" options, and alsa a WAV file that I believe has AC3 content rather than PCM. I also tested: * Play a stream * Mute while playing * Stop stream * Play some other streams to re-assign the converter to a different pin, PCM, set of SPDIF controls, ... hence hopefully triggering cleanup for the original PCM. * Unmute original stream while not playing * Play a stream on the original pin/PCM. This was to test SPDIF control virtualization. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Stephen Warren authored
A future change won't store an entire hda_pcm_stream just to represent the capabilities of a codec; a custom data-structure will be used. To ease that transition, modify hdmi_eld_update_pcm_info to expect the hda_pcm_stream to be pre-initialized with the codec's capabilities, and to update those capabilities in-place based on the ELD. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Stephen Warren authored
A future change will significantly rework the generic implementation in order to support codecs with a different number of pins and converters. Isolate the more custom codec variants from this change by duplicating the small portions of generic code they share. This simplifies the later rework of that previously shared code, since we don't have to consider the more custom codecs, and also prevents support for those codecs from regressing. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Stephen Warren authored
The SPDIF output controls apply to converter widgets. A future change will create a PCM device per pin widget, and hence a set of SPDIF output controls per pin widget, for certain HDMI codecs. To support this, we need the ability to virtualize the SPDIF output controls. Specifically: * Controls can be "unassigned" from real hardware when a converter is not used for the PCM the control was created for. * Control puts only write to hardware when they are assigned. * Controls can be "assigned" to real hardware when a converter is picked to support output for a particular PCM. * When a converter is assigned, the hardware is updated to the cached configuration. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Stephen Warren authored
Currently, the data that backs the kcontrols created by snd_hda_create_spdif_out_ctls is stored directly in struct hda_codec. When multiple sets of these controls are stored, they will all manipulate the same data, causing confusion. Instead, store an array of this data, one copy per converter, to isolate the controls. This patch would cause a behavioural change in the case where snd_hda_create_spdif_out_ctls was called multiple times for a single codec. As best I can tell, this is never the case for any codec. This will be relevant at least for some HDMI audio codecs, such as the NVIDIA GeForce 520 and Intel Ibex Peak. A future change will modify the driver's handling of those codecs to create multiple PCMs per codec. Note that this issue isn't affected by whether one creates a PCM-per-converter or PCM-per-pin; there are multiple of both within a single codec in both of those codecs. Note that those codecs don't currently create multiple PCMs for the codec due to the default HW mux state of all pins being to point at the same converter, hence there is only a single converter routed to any pin, and hence only a single PCM. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Stephen Warren authored
It's perfectly valid for an ELD to contain no SADs. This simply means that only basic audio is supoprted. In this case, we still want to limit a PCM's capabilities based on the ELD. History: * Originally, ELD application was limited solely by sad_count>0, which was used to check that an ELD had been read. * Later, eld_valid was added to the conditions to satisfy. This change removes the original sad_count>0 check, which when squashed with the above two changes ends up replacing if (sad_count) with if (eld_valid). Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Mark Brown authored
Merge branch 'for-3.0' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into for-3.0
-
Linus Torvalds authored
-