aboutsummaryrefslogtreecommitdiff
path: root/sound/pci/hda/patch_hdmi.c
AgeCommit message (Collapse)Author
2011-11-22ALSA: hda - repoll ELD content for multiple timesWu Fengguang
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 - move eld->spk_alloc fixup to hdmi_update_eld()Wu Fengguang
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 Fengguang
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 Fengguang
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 Torvalds
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 Iwai
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 Gortmaker
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 Bossart
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 Henningsson
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 Warren
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 Warren
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 Warren
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 Warren
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 Warren
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 Warren
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 Warren
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 Warren
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 Fengguang
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 Henningsson
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 Iwai
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-04-07ALSA: hda - HDMI: Fix MCP7x audio infoframe checksumsAaron Plattner
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 Iwai
2011-03-03ALSA: hda - add new Fermi 5xx codec IDs to snd-hdaRichard Samson
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 Iwai
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2011-02-08ALSA: hda - Fix missing CA initialization for HDMI/DPTakashi Iwai
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 Iwai
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 Iwai
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 Iwai
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 Daga
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 Iwai
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 Iwai
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 Henningsson
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 Iwai
2010-12-07ALSA: hda - Do not wrongly restrict min_channels based on ELDAnssi Hannula
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 Hannula
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 Zhou
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 Fengguang
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 Iwai
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 Iwai
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>
2010-08-13ALSA: hda - Restrict PCM parameters per ELD information over HDMITakashi Iwai
When a device is plugged over HDMI, it passes some information in ELD including the supported PCM parameters like formats, rates, channels. This patch adds the check to PCM open callback of HDMI streams so that only valid parameters the device supports are used. When no device is plugged, the parameters the codec supports are used; it's mostly all parameters the hardware can work. This is for apps that are started before device plugging and do probing (e.g. a sound daemon), so that at least, probing would work even before the device plugging. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-08-03ALSA: hda - Define AC_FMT_* constantsTakashi Iwai
Define constants for the HD-audio stream format bits, and replace the magic numbers in codes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-08-03ALSA: hda - Add support for HDMI HBR passthroughAnssi Hannula
Passing IEC 61937 encapsulated compressed audio at bitrates over 6.144 Mbps (i.e. more than a single 2-channel 16-bit 192kHz IEC 60958 link) over HDMI requires the use of HBR Audio Stream Packets instead of Audio Sample Packets. Enable HBR mode when the stream has 8 channels and the Non-PCM bit is set. If the audio converter is not connected to any HBR-capable pins, return -EINVAL in prepare(). Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-07-28ALSA: hda - Fix pin-detection of Nvidia HDMITakashi Iwai
The behavior of Nvidia HDMI codec regarding the pin-detection unsol events is based on the old HD-audio spec, i.e. PD bit indicates only the update and doesn't show the current state. Since the current code assumes the new behavior, the pin-detection doesn't work relialby with these h/w. This patch adds a flag for indicating the old spec, and fixes the issue by checking the pin-detection explicitly for such hardware. Tested-by: Wei Ni <wni@nvidia.com> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-05-17ALSA: hdmi - dont fail on extra nodesWu Fengguang
The number of HDMI nodes is expected to go up in future. So don't fail hard on seeing extra converter/pin nodes. We can still operate safely on the nodes within MAX_HDMI_CVTS/MAX_HDMI_PINS. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-03-08ALSA: hdmi - show debug message on changing audio infoframeWu Fengguang
Also change printk level for the two others. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2010-03-08ALSA: hdmi - merge common code for intelhdmi and nvhdmiWu Fengguang
Create patch_hdmi.c to hold common code from intelhdmi and nvhdmi. For now the patch_hdmi.c file is simply included by patch_intelhdmi.c and patch_nvhdmi.c, and does not represent a real codec. There are no behavior changes to intelhdmi. However nvhdmi made several changes when copying code out of intelhdmi, which are all reverted in this patch. Wei Ni confirmed that the reverted code actually works fine. Tested-by: Wei Ni <wni@nvidia.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>