The commit 53d7d69d
    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=28592Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: <stable@kernel.org>

The commit ad09fc9d 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: NTakashi Iwai <tiwai@suse.de>

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: NTakashi Iwai <tiwai@suse.de>

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: NTakashi Iwai <tiwai@suse.de>

Added hardware constraint in patch_hdmi.c to disable
channels 4/6 which are not supported by some older
NVIDIA GPUs.
Signed-off-by: NNitin Daga <ndaga@nvidia.com>
Acked-By: NStephen Warren <swarren@nvidia.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NTakashi Iwai <tiwai@suse.de>
Cc: <stable@kernel.org>

When unplugged, we shouldn't refer to ELD information for PCM open
any more.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: <stable@kernel.org>

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: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit bbbe3390 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: NAnssi Hannula <anssi.hannula@iki.fi>
Reported-by: NJean-Yves Avenard <jyavenard@gmail.com>
Tested-by: NJean-Yves Avenard <jyavenard@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NAnssi Hannula <anssi.hannula@iki.fi>
Tested-by: NJohn Ettedgui <john.ettedgui@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NJerry Zhou <jerry.zhou@intel.com>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

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: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTakashi 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: NTakashi Iwai <tiwai@suse.de>

Define constants for the HD-audio stream format bits, and replace the
magic numbers in codes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NAnssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NWei Ni <wni@nvidia.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Also change printk level for the two others.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NWei Ni <wni@nvidia.com>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For codecs without EPSS support (G45/IbexPeak), the hotplug event will
be lost if the HDA is powered off during the time. After that the pin
presence detection verb returns inaccurate info.

So always power-on HDA link for !EPSS codecs.

KarL offers the fact and Takashi recommends to flag hda_bus. Thanks!
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

IbexPeak is the first Intel HDMI audio codec to support channel mapping.

Currently the outstanding problem is, the HDMI channel order do not
agree with that of ALSA.  This patch presents workaround for some
typical use cases. It gives priority to the typical ALSA surround
configurations, and defines channel mapping for them.

We may need better kernel+userspace interactive channel mapping scheme.
For example, in current scheme if user plays with the surround50 device,
the kernel is unaware of this and will still select the surround41
channel allocation and channel mapping..

Thanks to Marcin for offering good tips!
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

HDA036-A specifies that the Audio Sample Packet (ASP) Channel Mapping
verbs apply to Digital Display Pin Complex instead of Converter.

With this fix, channel mapping is working as expected for IbexPeak.

Thanks to Marcin for pointing this out!
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

HDA036 spec states:
  DP (Display Port) indicates whether the Pin Complex Widget supports
  connection to a Display Port sink.  Supported if set to 1. Note that
  it is possible for the pin widget to support more than one digital
  display connection type, e.g. HDMI and DP bit are both set to 1.

Also export the DP pin cap in procfs.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Don't change channel count if not necessary.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We tracked down the first-0.5s-hdmi-audio-samples-lost problem to the
AC_VERB_SET_CHANNEL_STREAMID command. It is suspected that many HDMI
sinks need some time to adapt to the new state.

The workaround is to avoid changing stream id/format whenever possible.
Proposed by David.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Remember the active infoframe, so as to avoid stop/restart infoframe
transmission when switching between audio clips of the same format.

Proposed by Shang and David.

CC: Shane W <shane-alsa@csy.ca>
CC: David Härdeman <david@hardeman.nu>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

And make it right when called for more than one times.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This avoids lost of presence info on module reloading.
The presence info used to be only updated at the (rare) hotplug events.

Proposed by David, thanks!

CC: David Härdeman <david@hardeman.nu>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Reported-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Added a proper ifdef CONFIG_SND_DEBUG_VERBOSE to avoid a compile warning:
  sound/pci/hda/patch_intelhdmi.c:406: warning: ‘hdmi_get_channel_count’ defined but not used
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi 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: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

No behavior change.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Remove pcm callbacks open/close in favor of the prepare/cleanup.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>