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>
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>
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>
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>
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>
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>
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>
Commit bbbe33900d 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>
Commit bbbe33900d 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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
- 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>
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>
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>
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>
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>
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>
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>
ELD handling routines can be shared by all HDMI codecs,
and they are large enough to make a standalone source file.
Signed-off-by: Wu Fengguang <wfg@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pierre-Louis Bossart
Takashi Iwai
Wu Fengguang
Stephen Warren
David Henningsson
Anssi Hannula
Tejun Heo
Roel Kluin
Wu Fengguang