aboutsummaryrefslogtreecommitdiffstats
path: root/sound/pci/hda/patch_hdmi.c
AgeCommit message (Collapse)AuthorFilesLines
2012-05-10ALSA: hda - Protect SPDIF-related stuff via spdif_mutexTakashi Iwai1-2/+2
Add the missing mutex protection or move into the protected part for SPDIF access codes for codecs. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2012-04-10ALSA: hda - hide HDMI/ELD printks unless snd.debug=2Fengguang Wu1-5/+4
Also remove two warnings when CONFIG_SND_DEBUG is not set: sound/pci/hda/patch_hdmi.c: In function ‘hdmi_intrinsic_event’: sound/pci/hda/patch_hdmi.c:761:6: warning: unused variable ‘eldv’ [-Wunused-variable] sound/pci/hda/patch_hdmi.c:760:6: warning: unused variable ‘pd’ [-Wunused-variable] Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2012-02-23ALSA: hda - add id for Atom Cedar Trail HDMI codecWu Fengguang1-0/+2
[the order sorted by tiwai] Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-12-20ALSA: hda - Fix left-over merge issues in patch_hdmi.cTakashi Iwai1-3/+1
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-12-20Merge branch 'test/hda-jack' into topic/hdaTakashi Iwai1-17/+20
Conflicts: sound/pci/hda/patch_hdmi.c sound/pci/hda/patch_via.c
2011-12-01ALSA: hda - Integrate input-jack stuff into kctl-jackTakashi Iwai1-16/+6
Instead of managing input-jack stuff separately, call all stuff inside the kctl-jack creation, deletion and report. The caller no longer needs to care about input-jack. The better integration between input-jack and kctl-jack should be done in the upper layer in near future, but for now, it's implemented locally for more tests. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-26ALSA: hda - Increase the max number of coverters/pins in patch_hdmi.cTakashi Iwai1-10/+10
The new hardware tends to have more and more. As a temporary fix, just increase the number for now. For a long-term solution, we should assign the cvts/pins dynamically. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-22ALSA: hda - repoll ELD content for multiple timesWu Fengguang1-6/+10
Improve the one-shot ELD repoll to up to 6 retries. Up to now the 300ms looks sufficient for the test boxes. However I'm a bit worried about how well it can fit the wider user base. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-16ALSA: hda - Merge input-jack helpers to hda_jack.cTakashi Iwai1-1/+0
We can use the very same table in hda_jack.c for managing the list for input-jack elements, too. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-16ALSA: hda - Manage unsol tags in hda_jack.cTakashi Iwai1-3/+10
Manage the tags assigned for unsolicited events dynamically together with the jack-detection routines. Basically this is almost same as what we've done in patch_sigmatel.c. Assign the new tag number for each new unsol event, associate with the given NID and the action type, etc. With this change, now all pins looked over in snd_hda_jack_add_kctls() are actually enabled for detection now even if the pins aren't used for jack-retasking by the driver. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-16ALSA: hda - Create jack-detection kcontrolsTakashi Iwai1-0/+6
Create kcontrols for pin jack-detections, which work similarly like jack-input layer. Each control will notify when the jack is plugged or unplugged, and also user can read the value at any time via the normal control API. The control elements are created with iface=CARD, so that they won't appear in the mixer apps. So far, only the pins that enabled the jack-detection are registered. For covering all pins, the transition of the common unsol-tag handling would be needed. Stay tuned. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-16ALSA: hda - Cache the jack-detection valueTakashi Iwai1-3/+3
Introduce a table containing the pins and their jack-detection states for avoiding the unnecessary verbs to check the pin status at each time. When the unsol event is enabled via snd_hda_jack_detect_enable(), it automatically adds the given NID to the table. Then the driver supposes that the codec driver will set the dirty flag appropariately when an unsolicited event is invoked for that pin. The behavior for reading other pins that aren't registered in the table doesn't change. Only the pins assigned to the table are cached, so far. In near futre, this table can be extended to use the central place for the unsolicited events of all pins, etc, and eventually include the jack-detect kcontrols that replace the current input-jack stuff. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-16ALSA: hda - move eld->spk_alloc fixup to hdmi_update_eld()Wu Fengguang1-10/+0
It looks more natural and saves two lines of code. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-16ALSA: hda - delayed ELD repollWu Fengguang1-7/+29
The Intel HDMI chips (ironlake at least) are found to have ~250ms delay between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes actually readable. During the time the ELD buffer is mysteriously all 0. Fix it by scheduling a delayed work to re-read ELD buffer after 300ms. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-16ALSA: hda - fix ELD memory leakWu Fengguang1-6/+5
memset(eld) clears eld->proc_entry which will leak the struct snd_info_entry when unloading module. Fix it by - memset only the fields before eld->eld_buffer - set eld->eld_valid to true _after_ all eld fields have been filled Cc: <stable@kernel.org> Cc: Pierre-louis Bossart <pierre-louis.bossart@intel.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-11-06Merge branch 'modsplit-Oct31_2011' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux * 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits) Revert "tracing: Include module.h in define_trace.h" irq: don't put module.h into irq.h for tracking irqgen modules. bluetooth: macroize two small inlines to avoid module.h ip_vs.h: fix implicit use of module_get/module_put from module.h nf_conntrack.h: fix up fallout from implicit moduleparam.h presence include: replace linux/module.h with "struct module" wherever possible include: convert various register fcns to macros to avoid include chaining crypto.h: remove unused crypto_tfm_alg_modname() inline uwb.h: fix implicit use of asm/page.h for PAGE_SIZE pm_runtime.h: explicitly requires notifier.h linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h miscdevice.h: fix up implicit use of lists and types stop_machine.h: fix implicit use of smp.h for smp_processor_id of: fix implicit use of errno.h in include/linux/of.h of_platform.h: delete needless include <linux/module.h> acpi: remove module.h include from platform/aclinux.h miscdevice.h: delete unnecessary inclusion of module.h device_cgroup.h: delete needless include <linux/module.h> net: sch_generic remove redundant use of <linux/module.h> net: inet_timewait_sock doesnt need <linux/module.h> ... Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in - drivers/media/dvb/frontends/dibx000_common.c - drivers/media/video/{mt9m111.c,ov6650.c} - drivers/mfd/ab3550-core.c - include/linux/dmaengine.h
2011-11-02ALSA: hda - Remove unused variablesTakashi Iwai1-4/+1
Just clean-up what GCC caught. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-10-31sound: fix drivers needing module.h not moduleparam.hPaul Gortmaker1-1/+1
The implicit presence of module.h lured several users into incorrectly thinking that they only needed/used modparam.h but once we clean up the module.h presence, these will show up as build failures, so fix 'em now. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-03ALSA: hda/hdmi: expose ELD controlPierre-Louis Bossart1-0/+68
Applications may want to read ELD information to understand what codecs are supported on the HDMI receiver and handle the a-v delay for better lip-sync. ELD information is exposed in a device-specific IFACE_PCM kcontrol. Tested both with amixer and PulseAudio; with a corresponding patch passthrough modes are enabled automagically. ELD control size is set to zero in case of errors or wrong configurations. No notifications are implemented for now, it is expected that jack detection is used to reconfigure the audio outputs. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-09-21ALSA: hda: hdmi: Hint matching between input devices and pcm devicesDavid Henningsson1-7/+24
Since modern HDMI cards often have more than one output pin and thus input device, we need to know which one has actually been plugged in. This patch adds a name hint that indicates which PCM device is connected to which pin. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-06-06ALSA: hda: HDMI: Support codecs with fewer cvts than pinsStephen Warren1-265/+346
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>
2011-06-06ALSA: hda: hdmi_eld_update_pcm_info: update a stream in placeStephen Warren1-8/+10
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>
2011-06-06ALSA: hda: Separate generic and non-generic implementationsStephen Warren1-9/+66
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>
2011-06-06ALSA: hda: Virtualize SPDIF out controlsStephen Warren1-1/+2
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>
2011-06-06ALSA: hda: Allow multple SPDIF controls per codecStephen Warren1-8/+11
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>
2011-06-06ALSA: hda: Gate ELD usage only by whether ELD is validStephen Warren1-1/+1
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>
2011-05-26ALSA: HDA: Increase MAX_HDMI_PINSStephen Warren1-2/+3
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>
2011-05-25ALSA: HDA: Unify HDMI hotplug handling.Stephen Warren1-69/+49
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>
2011-05-20ALSA: hda - add Intel Panther Point HDMI codec idWu Fengguang1-0/+2
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-05-19ALSA: HDA: Add jack detection for HDMIDavid Henningsson1-0/+11
Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-05-02ALSA: hda - Constify fixup and other array data in patch_hdmi.cTakashi Iwai1-13/+13
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-04-07ALSA: hda - HDMI: Fix MCP7x audio infoframe checksumsAaron Plattner1-26/+44
The MCP7x hardware computes the audio infoframe channel count automatically, but requires the audio driver to set the audio infoframe checksum manually via the Nv_VERB_SET_Info_Frame_Checksum control verb. When audio starts playing, nvhdmi_8ch_7x_pcm_prepare sets the checksum to (0x71 - chan - chanmask). For example, for 2ch audio, chan == 1 and chanmask == 0 so the checksum is set to 0x70. When audio playback finishes and the device is closed, nvhdmi_8ch_7x_pcm_close resets the channel formats, causing the channel count to revert to 8ch. Since the checksum is not reset, the hardware starts generating audio infoframes with invalid checksums. This causes some displays to blank the video. Fix this by updating the checksum and channel mask when the device is closed and also when it is first initialized. In addition, make sure that the channel mask is appropriate for an 8ch infoframe by setting it to 0x13 (FL FR LFE FC RL RR RLC RRC). Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-03-03Merge branch 'fix/hda' into topic/hdaTakashi Iwai1-0/+5
2011-03-03ALSA: hda - add new Fermi 5xx codec IDs to snd-hdaRichard Samson1-0/+5
Added the missing HDMI codec IDs for new Nvidia stuff. Note that ID 0x17 isn't assigned to anything so far, as suggested by Stephen. [Modified to get rid of 0x17 by tiwai] Signed-off-by: Richard Samson <samson.richard@gmail.com> Acked-by: Acked-By: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-02-11ALSA: hda - Avoid cast with union data for HDMI audio infoframeTakashi Iwai1-9/+13
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-02-08ALSA: hda - Fix missing CA initialization for HDMI/DPTakashi Iwai1-0/+2
The commit 53d7d69d8ffdfa60c5b66cc2e9ee0774aaaef5c0 ALSA: hdmi - support infoframe for DisplayPort dropped the initialization of CA field accidentally. This resulted in only two-channel LPCM mode on Nvidia machines. Reference: kernel bug 28592 https://bugzilla.kernel.org/show_bug.cgi?id=28592 Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: <stable@kernel.org>
2011-01-14ALSA: hda - More coverage for odd-number channels elimination for HDMITakashi Iwai1-0/+3
The commit ad09fc9d2156f3d37537b34418a6b79309013d33 didn't cover the case for Intel and Nvidia HDMIs, where hdmi_pcm_open() is called. Put the hw_constraint there, too. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-01-14ALSA: hda - Store PCM parameters properly in HDMI open callbackTakashi Iwai1-0/+6
In hdmi_pcm_open(), the evaluated PCM hw parameters are stored in hinfo, but these aren't properly set back to the current runtime record since these have been set beforehand in azx_pcm_open(). This patch fixes the behavior. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-01-14ALSA: hda - Suppress the odd number of channels for HDMITakashi Iwai1-0/+3
It looks like that HDMI codecs don't support the odd number of channels although HD-audio spec doesn't have the restriction. Add the hw_constraint to limit to only the even number of channels. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-01-12ALSA: hda: Disable 4/6 channels on some NVIDIA GPUs.Nitin Daga1-0/+42
Added hardware constraint in patch_hdmi.c to disable channels 4/6 which are not supported by some older NVIDIA GPUs. Signed-off-by: Nitin Daga <ndaga@nvidia.com> Acked-By: Stephen Warren <swarren@nvidia.com> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-01-12ALSA: hda - Add static_hdmi_pcm option to HDMI codec parserTakashi Iwai1-1/+6
The dynamic PCM restriction based on ELD information may lead to the problem in some cases, e.g. when the receiver is turned off. Then it may send a TV HDMI default such as channels = 2. Since it's still plugged, the driver doesn't know whether it's the right configuration for future use. Now, when an app opens the device at this moment, then turn on the receiver, the app still sends channels=2. The right solution is to implement some kind of notification and automatic re-open mechanism. But, this is a goal far ahead. This patch provides a workaround for such a case by providing a new module option static_hdmi_pcm for snd-hda-codec-hdmi module. When this is set to true, the driver doesn't change PCM parameters per ELD information. For users who need the static configuration like the scenario above, set this to true. The parameter can be changed dynamically via sysfs, too. Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: <stable@kernel.org>
2011-01-12ALSA: hda - Don't refer ELD when unpluggedTakashi Iwai1-1/+1
When unplugged, we shouldn't refer to ELD information for PCM open any more. Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: <stable@kernel.org>
2010-12-08ALSA: HDA: Remove unconnected PCM devices for Intel HDMIDavid Henningsson1-9/+32
Some newer chips have more than one HDMI output, but usually not all of them are exposed as physical jacks. Removing the unused PCM devices (as indicated by BIOS in the pin config default) will reduce user confusion as they currently have to choose between several HDMI devices, some of them not working anyway. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-12-08Merge branch 'fix/hda' into topic/hdaTakashi Iwai1-1/+0
2010-12-07ALSA: hda - Do not wrongly restrict min_channels based on ELDAnssi Hannula1-1/+0
Commit bbbe33900d1f3c added functionality to restrict PCM parameters based on ELD info (derived from EDID data) of the audio sink. However, it wrongly assumes that the bits 0-2 of the first byte of CEA Short Audio Descriptors mean a supported number of channels. In reality, they mean the maximum number of channels (as per CEA-861-D 7.5.2). This means that the channel count can only be used to restrict max_channels, not min_channels. Restricting min_channels causes us to deny opening the device in stereo mode if the sink only has SADs that declare larger numbers of channels (like Primare SP32 AV Processor does). Fix that by not restricting min_channels based on ELD information. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Reported-by: Jean-Yves Avenard <jyavenard@gmail.com> Tested-by: Jean-Yves Avenard <jyavenard@gmail.com> Cc: stable@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-12-05ALSA: hda - use generic hdmi parser for ATI R6xx codecAnssi Hannula1-1/+1
Switch to the generic hdmi parser for codec id 1002:aa01 (ATI R6xx HDMI), as the codec appears to work fine with it. Note that the codec is still limited to stereo output only, despite it reportedly being multichannel capable. Some as of yet unknown quirks will be needed to get that working. Testing was done on 2.6.36 by John Ettedgui. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Tested-by: John Ettedgui <john.ettedgui@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-09-21ALSA: hdmi - fix surround41 channel mappingJerry Zhou1-1/+1
Channel 2 and channel 3 were all wrongly mapped to HDMI slot 4. This shows up as a bug that one channel is "lost" when playing in surround41 mode. Signed-off-by: Jerry Zhou <jerry.zhou@intel.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-09-21ALSA: hdmi - support infoframe for DisplayPortWu Fengguang1-37/+73
DisplayPort works mostly in the same way as HDMI, except that it expects a slightly different audio infoframe format. Citations from "HDA036-A: Display Port Support and HDMI Miscellaneous Corrections": The HDMI specification defines a data island packet with a header of 4 bytes (3 bytes content + 1 byte ECC) and packet body of 32 bytes (28 bytes content and 4 bytes ECC). Display Port specification on the other hand defines a data island packet (secondary data packet) with header of 4 bytes protected by 4 bytes of parity, and data of theoretically up to 1024 bytes with each 16 bytes chunk of data protected by 4 bytes of parity. Note that the ECC or parity bytes are not present in the DIP content populated by software and are hardware generated. It tests DP connection based on the ELD conn_type field, which will be set by the graphics driver and can be overriden manually by users through the /proc/asound/card0/eld* interface. The DP infoframe is tested OK on Intel SandyBridge/CougarPoint platform. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-09-20ALSA: hda - Merge all HDMI modules into the unified moduleTakashi Iwai1-3/+682
This patch merges all three patch_*hdmi variants to the single HDMI parser. There is only one snd-hda-codec-hdmi module now. In this patch, the behavior of each parser isn't changed much. The old ATI parser still doesn't use the dynamic parser yet. In later patches, they'll be cleaned up. Also, this patch gets rid of the individual snd-hda-eld module and builds into snd-hda-codec-hdmi, since this is referred only from the HDMI parser. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-08-20ALSA: hda - Fix conflict of sticky PCM parameter in HDMI codecsTakashi Iwai1-20/+1
Intel and Nvidia HDMI codec drivers have own implementations of sticky PCM parameters. Now HD-audio core part already has it, thus both setups conflict. The fix is simply remove the part in patch_intelhdmi.c and patch_nvhdmi.c and simply call snd_hda_codec_setup_stream() as usual. Reported-and-tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-19 06:58:07 +0000