summaryrefslogtreecommitdiffstats
path: root/sound/pci/hda/hda_eld.c
Commit message (Collapse)AuthorAgeFilesLines
* ALSA: hda - Replace with standard printkTakashi Iwai2014-02-251-9/+8
| | | | | | | | | | | | Use dev_err() and co for messages from HD-audio controller and codec drivers. The codec drivers are mostly bound with codec objects, so some helper macros, codec_err(), codec_info(), etc, are provided. They merely wrap the corresponding dev_xxx(). There are a few places still calling snd_printk() and its variants as they are called without the codec or device context. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - hdmi: Fix wrong baseline length in ATI/AMD generated ELDAnssi Hannula2013-11-111-3/+6
| | | | | | | | | | | | | | | According to the HDA specification the baseline ELD length is counted in DW of 4 bytes instead of in bytes. Fix the code accordingly. Baseline length is not used by the kernel so only the ELD exported to userspace was affected. No issues have been reported. v2: Fixed so that eld_size is adjusted upwards accordingly as well. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - hdmi: Skip out-of-range latency values in AMD ELD generatorAnssi Hannula2013-11-111-4/+19
| | | | | | | | | | | | | The ATI/AMD video/audio latencies are specified in apparent HDMI VSDB format. In this format values above 251 are not valid (or stream component is not supported - 255), but no checking is performed since this was not mentioned in the AMD HDA verbs specification. Check that the latencies are valid before using them, and add a comment describing the formats. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - hdmi: Add error-checking to some codec readsAnssi Hannula2013-11-111-1/+4
| | | | | | | | | | | | Add error checks to HBR status reads (both generic and ATI/AMD) and ATI/AMD codec reads for ELD generation. Unchecked errors in these just caused more errors later on (invalid codec writes for the HBR ones and ELD parsing errors for the ATI/AMD ELD ones), but it is better to catch them earlier. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecsAnssi Hannula2013-10-241-0/+151
| | | | | | | | | | | | | | | | | | | | | | | | | ATI/AMD HDMI/DP codecs do not include standard HDA ELD (EDID-like data) support. In place of providing access to an ELD buffer, various vendor-specific verbs are provided to provide the relevant information. Revision ID 3 and later (0x100300 as reported by procfs codec#X) have support for providing more information than the previous revisions (but only if supported by the display driver). Generate ELD from the information provided by the vendor-specific verbs on ATI/AMD codecs. The specification is available at: http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf v2: moved code to hda_eld.c and cleaned it up v3: adapted to hdmi_ops infrastructure Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Tested-by: Peter Frühberger <fritsch@xbmc.org> # v2 Tested-by: Olivier Langlois <olivier@trillion01.com> # v2 Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - Move mutex from hda_eld to per_pin in HDMI codec driverTakashi Iwai2013-10-171-43/+5
| | | | | | | | | | | | | | Since the lock is used primarily in patch_hdmi.c, it's better to move it in the local struct instead of exporting in hda_eld. The only functions requiring the lock in hda_eld.c are proc accessors. So in this patch, the proc entry and its creation/deletion/accessors are moved into patch_hdmi.c, together with the mutex lock to pin_spec struct. The former proc info functions are exported so that they can be called from patch_hdmi.c. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - bug fix on return value when getting HDMI ELD infoMengdong Lin2013-04-021-1/+1
| | | | | | | | | | | | In function snd_hdmi_get_eld(), the variable 'ret' should be initialized to 0. Otherwise it will be returned uninitialized as non-zero after ELD info is got successfully. Thus hdmi_present_sense() will always assume ELD info is invalid by mistake, and /proc file system cannot show the proper ELD info. Signed-off-by: Mengdong Lin <mengdong.lin@intel.com> Cc: stable@vger.kernel.org Acked-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - hdmi: Protect ELD bufferDavid Henningsson2013-02-191-1/+7
| | | | | | | | | | | | Because the eld buffer can be simultaneously accessed from both workqueue context (updating) and process context (kcontrol read), we need to protect it with a mutex to guarantee consistency. To avoid holding the mutex while reading the ELD info from the codec, we introduce a temporary eld buffer. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - hdmi: Refactor hdmi_eld into parsed_hdmi_eldDavid Henningsson2013-02-191-25/+21
| | | | | | | | For better readability, the information that is parsed out of the ELD data is now put into a separate parsed_hdmi_eld struct. Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - hide HDMI/ELD printks unless snd.debug=2Fengguang Wu2012-04-101-3/+3
| | | | | | | | | | | 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>
* ALSA: hda - fix printing of high HDMI sample ratesAnssi Hannula2012-03-131-2/+2
| | | | | | | | | | | | | | | | | A previous commit af65cbf296 (ALSA: hdmi: fix printout of SAD sampling rates) fixed the sample rates shown in /proc/asound/cardX/eldY and kernel log to not be entirely wrong. However, a missing rate from the array added in the patch causes HDMI rates 88.2 kHz, 96 kHz, 176.4 kHz, and 192 kHz to be shown as 96 kHz, 176.4 kHz, 192 kHz, and 384 kHz, respectively. Fix the reporting by adding the ALSA rate 64 kHz into the conversion array between 48 kHz and 88.2 kHz. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: stable@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - fail ELD reading earlyWu Fengguang2011-11-221-9/+19
| | | | | | | | | With the ELD repoll mechanism, we can (and should) fail the ELD reading immediately when find something obviously wrong and let the caller retry after some delay. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - move eld->spk_alloc fixup to hdmi_update_eld()Wu Fengguang2011-11-161-0/+8
| | | | | | | 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>
* ALSA: hda - fix ELD memory leakWu Fengguang2011-11-161-4/+1
| | | | | | | | | | | | | | | 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>
* ALSA: hda - Moved snd_print_pcm_rates() back into hda_proc.cTakashi Iwai2011-10-061-0/+2
| | | | | | | Since hda_proc.c is now the only user of snd_print_pcm_rates(), better to put it back locally to hda_proc.c and revert to the old style. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hdmi: fix printout of SAD sampling ratesPierre-Louis Bossart2011-10-061-2/+22
| | | | | | | | | | SAD sampling rate information reported in /proc/asound/cardX/eldX is incorrect due to a mismatch between HDA and HDMI frequencies. Add new routine to provide relevant values. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda/hdmi: expose ELD controlPierre-Louis Bossart2011-10-031-5/+8
| | | | | | | | | | | | | | | | | | | 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>
* ALSA: hda - Don't spew too many ELD errorsTakashi Iwai2011-08-201-12/+19
| | | | | | | | | | | | | Currently HD-audio driver shows the all error ELD byte as an error in the kernel message. This is annoying when the video driver doesn't set the correct ELD from the beginning. e.g. radeon sends a zero-byte data, but we still check ELD with the fixed 128 byte as a workaround for some broken devices, it spews 128-times errors. For avoiding this, the driver aborts reading when the first byte is invalid. In such a case, the whole data is certainly invalid. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'fix/hda' into topic/hdaTakashi Iwai2011-07-071-1/+1
|\
| * ALSA: HDMI - fix ELD monitor name lengthWu Fengguang2011-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that the last character of the ELD monitor name is lost, this fixes the issue. This fix should be confirming to the HDA spec, and works together with the DRM part of the ELD patch. The HDA spec does not mention that Monitor_Name_String is an '\0' ending string, and it allows NML to be 1, which is only valid when MNL does not count the possible ending '\0'. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: hda: hdmi_eld_update_pcm_info: update a stream in placeStephen Warren2011-06-061-22/+24
|/ | | | | | | | | | | 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>
* ALSA: HDA: Unify HDMI hotplug handling.Stephen Warren2011-05-251-18/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ALSA: HDA: Fix dmesg output of HDMI supported bitsDavid Henningsson2011-01-251-1/+1
| | | | | | | | | This typo caused the dmesg output of the supported bits of HDMI to be cut off early. Cc: stable@kernel.org Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - Reset sample sizes and max bitrates when reading ELDAnssi Hannula2010-12-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | When a new HDMI/DP device is plugged in, hdmi_update_short_audio_desc() is called for every SAD (Short Audio Descriptor) in the ELD data. For LPCM coding type SAD defines the supported sample sizes. For several other coding types (such as AC-3), a maximum bitrate is defined. The maximum bitrate and sample size fields are not always cleared. Therefore, if a device is unplugged and a different one is plugged in, and the coding types of some SAD positions differ between the devices, the old max_bitrate or sample_bits values will persist if the new SADs do not define those values. The leftover max_bitrate and sample_bits do not cause any issues other than wrongly showing up in eld#X.Y procfs file and kernel log. Fix that by always clearing sample_bits and max_bitrate when reading SADs. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - Always allow basic audio irrespective of ELD infoAnssi Hannula2010-12-071-9/+7
| | | | | | | | | | | | | | | | | | | | | | | Commit bbbe33900d1f3c added functionality to restrict PCM parameters based on ELD info (derived from EDID data) of the audio sink. However, according to CEA-861-D no SAD is needed for basic audio (32/44.1/48kHz stereo 16-bit audio), which is instead indicated with a basic audio flag in the CEA EDID Extension. The flag is not present in ELD. However, as all audio capable sinks are required to support basic audio, we can assume it to be always available. Fix allowed audio formats with sinks that have SADs (Short Audio Descriptors) which do not completely overlap with the basic audio formats (there are no reports of affected devices so far) by always assuming that basic audio is supported. Reported-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Cc: stable@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - Do not wrongly restrict min_channels based on ELDAnssi Hannula2010-12-071-4/+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>
* ALSA: hda - Merge all HDMI modules into the unified moduleTakashi Iwai2010-09-201-7/+0
| | | | | | | | | | | | | | | 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>
* ALSA: hda - Fix build error with CONFIG_PROC_FS=nTakashi Iwai2010-08-191-2/+2
| | | | | | hdmi_eld_update_pcm_info() must be always compiled in. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - Restrict PCM parameters per ELD information over HDMITakashi Iwai2010-08-131-0/+49
| | | | | | | | | | | | | | | 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>
* include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* ALSA: hda - Build hda_eld into snd-hda-codec moduleTakashi Iwai2010-03-041-0/+6
| | | | | | | Now two modules require hda_eld.o, so we need to put it to the common place instead of building into two individual modules. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - introduce snd_hda_jack_detect() and snd_hda_pin_sense()Wu Fengguang2009-11-181-6/+1
| | | | | | | | | This helps merge duplicate code. v2: add snd_hda_jack_detect() and comments recommended by Takashi. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: intelhdmi - export monitor-presence and ELD-valid statusWu Fengguang2009-11-181-1/+7
| | | | | Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - vectorize intelhdmiWu Fengguang2009-10-301-2/+3
| | | | | | | | | | | | | | | | | The Intel IbexPeak HDMI codec supports 2 converters and 3 pins, which requires converting the cvt_nid/pin_nid to arrays. The active pin number (the one connected with a live HDMI monitor/sink) will be dynamically identified on hotplug events. It exports two HDMI devices, so that user space can choose the A/V pipe for sending the audio samples. It's still undefined behavior when there are two active monitors connected and routed to the same audio converter. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: fix out-of-bound hdmi_eld.sad[] writeRoel Kluin2009-07-291-2/+2
| | | | | | | | | e->sad[] is declared with size ELD_MAX_SAD=16, but the guard allows range 0-31. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - fix build warning when CONFIG_PROC_FS=nWu Fengguang2008-11-221-16/+14
| | | | | | | | Fix "defined but not used" build warning by moving eld_versoin_names[] and cea_edid_version_names[] into hdmi_print_eld_info(). Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - fix DisplayPort namingWu Fengguang2008-11-221-1/+1
| | | | | | | | | | | | | DisplayPort is a digital display interface standard put forth by the Video Electronics Standards Association (VESA). It defines a new license-free, royalty-free, digital audio/video interconnect, intended to be used primarily between a computer and its display monitor, or a computer and a home-theater system. - From Wikipedia, the free encyclopedia Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - ELD proc interface write updatesWu Fengguang2008-11-221-2/+9
| | | | | | | | | | | | - rename ELD proc write routine to hdmi_write_eld_info() - support modifying WMAPro's profile Write to some ELD fields (monitor_name, manufacture_id, product_id, eld_version, edid_version) are deliberately not supported, since that won't correct wrong behaviors and only leads to confusions. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - make HDMI messages more user friendlyWu Fengguang2008-11-221-14/+16
| | | | | | | | | - make some messages more user friendly - add message prefix "HDMI:" to indicate the problem's domain (also easier to do `dmesg | grep HDMI` ;-) Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - Release ELD proc fileTakashi Iwai2008-11-211-1/+10
| | | | | | Release ELD proc file when reconfigured so that no leak occurs. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - support writing to the ELD proc fileWu Fengguang2008-11-211-0/+56
| | | | | | | | | | Allow users to fix quicks of ELD ROMs by writing new values to the ELD proc interface. The format is one or more lines of "name hex_value". Users can add/remove/modify up to 32 SAD(Short Audio Descriptor) entries. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: modify monitor name to be consistent with other ELD proc itemsWu Fengguang2008-11-211-1/+1
| | | | | | | Rename "monitor name" to "monitor_name" to conform with the keyword style. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda - properly print ELD sample bitsWu Fengguang2008-11-211-1/+1
| | | | | | | Fix bugs on printing the ELD sample bits. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: compact ELD output messagesWu Fengguang2008-11-191-32/+24
| | | | | | | | Strip out some ELD printk messages that end user won't care, and make the output compact. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: make global snd_print_pcm_bits()Wu Fengguang2008-11-191-4/+6
| | | | | | | Introduce a global function snd_print_pcm_bits() and use it in the ELD code. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: minor output message cleanupsWu Fengguang2008-11-191-9/+6
| | | | | | | Some minor user visible message cleanups. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: rename sink_eld to hdmi_eldWu Fengguang2008-11-191-7/+7
| | | | | | | Rename struct sink_eld to hdmi_eld. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: minor code cleanupsWu Fengguang2008-11-191-1/+1
| | | | | | | Some minor code cleanups. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: hda: make global snd_print_channel_allocation()Wu Fengguang2008-11-191-6/+5
| | | | | | | code refactor: make a global function snd_print_channel_allocation(). Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: ELD proc interface for HDMI sinksWu Fengguang2008-11-181-0/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create /proc/asound/card<card_no>/eld#<codec_no> to reflect the audio configurations and capabilities of the attached HDMI sink. Some notes: - Shall we show an empty file if the ELD content is not valid? Well it's not that simple. There could be partially populated ELD, and there may be malformed ELD provided by buggy drivers/monitors. So expose ELD as it is. - The ELD retrieval routines rely on the Intel HDA interface, others are/could be universal and independent ones. - How do we name the proc file? If there are going to be two HDMI pins per codec, then the current naming scheme (eld#<codec no>) will fail. Luckily the user space dependencies should be minimal, so it would be trivial to do the rename if that happens. - The ELD proc file content is designed to be easy for scripts and human reading. Its lines all have the pattern: <item_name>\t[\t]*<item_value> where <item_name> is a keyword in c language, while <item_value> could be any contents, including white spaces. <item_value> could also be a null value. Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
OpenPOWER on IntegriCloud