Now that we have changed the position_fix default for ATI and AMD
to be LPIB (see commit 50e3bbf989), 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>
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>
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>
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>
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>
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>
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.html
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
In the original code if auto detect failed and tea575x_tuner == 4
then we copy bogus information to chip->tea.card. I've changed the
autodetect code to cleanup and return -ENODEV on error instead.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In ad198x_power_eapd(), wrong pin NIDs are used for controlling EAPD for
HP and Front outputs of AD1988/AD1989. These are actually same with the
ones for AD1984 & co, port-A is 0x11 and port-D 0x12.
Reported-by: Raymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 9477c58e33 ("ALSA: hda - Reorganize controller quriks with bit
flags") changed the driver type compares into various quirk bits.
However, the check for AZX_DCAPS_NO_TCSEL got reverted: instead of
clearing TCSEL for chipsets that have that standard capability, it
cleared then when the NO_TCSEL bit was set.
This can lead to noise and repeated sounds - a weird "echo" behavior.
As the comment just above says: "Ensuring these bits are 0 clears
playback static on some HD Audio codecs". Which is definitely true at
least on my Core i5 Westmere system.
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Introduce bit-flags indicating the necessary controller quirks, and
set them in pci driver_data field. This simplifies the checks in the
driver code and avoids the pci-id lookup in different places.
Also, this patch adds the PCI ID entry for AMD Hudson. AMD Hudson
requires a similar workaround like ATI SB while other generic ATI and
AMD controllers don't need but some ATI-HDMI quirks. So, we need a
different entry for Hudson.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fixed the wrong usage of snd_printdd() for debug prints of input
entries. It should be snd_printd() like others.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recently introduced NVIDIA GeForce GT 520 has 4 pins within a single
codec. Bump MAX_HDMI_PINS to accomodate this. Also bump MAX_HDMI_CVTS
to match it; this might be needed later too.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This change unifies the initial handling of a pin's state with the code to
update a pin's state after a hotplug (unsolicited response) event. The
initial probing, and all updates, are now routed through hdmi_present_sense.
The stored PD and ELDV status is now always derived from GetPinSense verb
execution, and not from the data in the unsolicited response. This means:
a) The WAR for NVIDIA codec's UR.PD values ("old_pin_detect") can be
removed, since this only affected the no-longer-used unsolicited
response payload.
b) In turn, this means that most NVIDIA codecs can simply use
patch_generic_hdmi instead of having a custom variant just to set
old_pin_detect.
c) When PD && ELDV becomes true, no extra verbs are executed, because the
GetPinSense that was previously executed by snd_hdmi_get_eld (really,
hdmi_eld_valid) has simply moved into hdmi_present_sense.
d) When PD && ELDV becomes false, there is a single extra GetPinSense verb
executed for codecs where old_pin_detect wasn't set, i.e. some NVIDIA,
and all ATI/AMD and Intel codecs. I doubt this will be a performance
issue.
The new unified code in hdmi_present_sense also ensures that eld->eld_valid
is not set unless eld->monitor_present is also set. This protects against
potential invalid combinations of PD and ELDV received from HW, and
transitively from a graphics driver.
Also, print the derived PD/ELDV bits from hdmi_present_sense so the kernel
log always displays the actual state stored, which will differ from the
values in the unsolicited response for NVIDIA HW where old_pin_detect was
previously set.
Finally, a couple of small tweaks originally by Takashi:
* Clear the ELD content to zero before reading it, so that if it's not
read (i.e. when !(PD && ELDV)) it's in a known state.
* Don't show ELD fields in /proc ELD files when the ELD isn't valid.
The only possibility I can see for regression here is a codec where the
GetPinSense verb returns incorrect data. However, we're already exposed
to that, since that data is used (a) from hdmi_add_pin to set up the
initial pin state, and (b) within snd_hda_input_jack_report to query
a pin's presence value. As such, I don't believe any HW has bugs here.
Includes-changes-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The microphone input on the back panel (pink connector)
stopped operating correctly after an upgrade from
2.6.35 to 2.6.38; the actual problem manifests itself
as a lack of microphone bias voltage (VREF_HIZ) on
node 0x17.
With AD1988_6STACK_DIG the maximum bias voltage (VREF_80)
is applied and the headset operates correctly.
Signed-off-by: Tony Vroon <tony@linx.net>
Tested-by: Doug Redlich <pbrigade@nxltech.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix some logic failures in auto-mute handling in Conexant auto-parser.
Also, modify codes to be a bit more understandable.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add model=asus quirk for Lenovo Ideapad U350 to make internal mic
work correctly.
Cc: stable@kernel.org (2.6.38+)
BugLink: http://bugs.launchpad.net/bugs/751681
Reported-by: Kent Baxley <kent.baxley@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ATI and AMD chipsets seem not providing the proper position-buffer
information, and it also doesn't provide FIFO register required by
VIACOMBO fix. It's better to use LPIB for these.
Reported-by: David Henningsson <david.henningsson@canonical.com>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 447ee6a7cb.
The workaround introduced by this commit seems bogus.
The AMD chipsets don't provide proper position-buffer nor FIFO value
required by VIACOMBO fix.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As the "Wave", "Wave Surround" or "Front" Playback Volume must be
changed to 70% (i.e. -12 dB) so that distortion won't occur when
increase Bass and Treble from 50% to 100%, so the maximum gain in
Bass and Treble are +12 dB.
Signed-off-by: Raymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Afer commit aa202455ee , none of realtek
codec has hardware volume control "PCM Playback Volume" and
"PCM Playback Switch".
As Virtual Master require all slave controls must have same number of step
and dB range.
Signed-off-by: Raymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Compare pin type enum to the pin type and not the array index.
Fixes bug#0005368.
Signed-off-by: Adrian Wilkins <adrian.wilkins@nhs.net>
Cc: <stable@kernel.org> (2.6.37 and later)
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This fixes the input layer beep not working on some EeePC 1000 models by
adding the subsystem id into whitelist. Otherwise the corresponding ALSA
mixer is not enabled and stays muted, resulting in no console beep.
Signed-off-by: Madis Janson <madis@cyber.ee>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
AMD 8111 southbridges contain a controller for MC'97 modem. Enable support
for this controller in intel8x0m driver.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
