hdmi_channel_allocation() tries to find a HDMI channel allocation that
matches the number channels in the playback stream and contains only
speakers that the HDMI sink has reported as available via EDID. If no
such allocation is found, 0 (stereo audio) is used.

Using CA 0 causes the audio causes the sink to discard everything except
the first two channels (front left and front right).

However, the sink may be capable of receiving more channels than it has
speakers (and then perform downmix or discard the extra channels), in
which case it is preferable to use a CA that contains extra channels
than to use CA 0 which discards all the non-stereo channels.

Additionally, it seems that HBR (HD) passthrough output does not work on
Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes
channels not present in CA). This happens with all receivers that report
a 5.1 speaker mask since a HBR stream is carried on 8 channels to the
codec.

Add a fallback in the CA selection so that the CA channel count at least
matches the stream channel count, even if the stream contains channels
not present in the sink speaker descriptor.

Thanks to GrimGriefer at OpenELEC forums for discovering that changing
the sink speaker mask allowed HBR output.

Reported-by: GrimGriefer
Reported-by: Ashecrow
Reported-by: NFrank Zafka <kafkaesque1978@gmail.com>
Reported-by: NPeter Frühberger <fritsch@xbmc.org>
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds two fields to unsolicited response, according to spec HDA040-A:
- Device Entry (bit 20:15)
- Inactive (bit 2)
and show the info in debug message.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch is only to allow codec proc file to expose devices list/select info
for Haswell codec pins.

Since Haswell Gfx driver cannot support DP1.2 MST now, so all pins' device list
is empty, meaning no pin is multi-streaming capaple.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Vendor ID 0x10de0060 is used by a yet-to-be-named GPU chip.
Reviewed-by: NAndy Ritger <aritger@nvidia.com>
Signed-off-by: NAaron Plattner <aplattner@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Hdmi driver may not receive intrinsic event from gfx side when
it's in runtime suspend mode. There's no ELD info when exit from
runtime suspend. This patch avoid missing ELD info.
Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... instead of open codes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin with
physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter 0, pin 1 has HDMI monitor connected.
when play audio on Pin 0 or pin 2, pin 1 could get audio data too.

This patch configure unused pins to choose different converter.
Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a selection to a converter MUX is changed in hdmi_pcm_open(), it
should be cached so that the given connection can be restored properly
at PM resume.  We need just to replace the corresponding
snd_hda_codec_write() call with snd_hda_codec_write_cache().

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Haswell converters maybe in wrong power state before usage.
i.e. only converter 0 is in D0, converter 1/2 are in D3.
When pin choose converter 1/2, there's no audio output, this
cause dependency when playing differnt stream on pins.

AUD_PWRST  ConvertorA_Widget_Power_State_Current        D0
AUD_PWRST  ConvertorA_Widget_Power_State_Requsted       D0
AUD_PWRST  ConvertorB_Widget_Power_State_Current        D3
AUD_PWRST  ConvertorB_Widget_Power_State_Requested      D3
AUD_PWRST  ConvC_Widget_PwrSt_Curr                      D3
AUD_PWRST  ConvC_Widget_PwrSt_Req                       D3

This patch check converter's power state and set D0 if it's in D3 mode.
Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is a revised patch based on Mengdong Lin's fix patch, which is a
supplement to a previous patch [1611a9c9: ALSA: hda - Add fixup for
Haswell to enable all pin and convertor widgets].

Some Haswell BIOS will disable the 2nd and 3rd pin/covertor widgets
when the HD-A controller changes state from D3 to D0.  So when the
controller resumes after a system or runtime suspend, these widgets
are disabled and programming these widgets to D0 will cause H/W error
and codec will not respond.

In addition, we found out that some BIOS disables the pins at S3
although it shows up at boot.  This confuses the driver utterly, and
the hardware falls into the fatal communication error like the above.

So in this patch, we apply intel_haswell_enable_all_pins() not only as
a fixup to a certain device (with 8086:2010) but to all Haswell
machines.  The codec driver basically assumes that all pins are
exposed, so it's anyway better to see them from the beginning.  Even
if all pins and converters are shown by this call, there should be no
regression in practice: the pin default configurations are still kept,
thus the disabled pins are handled as disabled by the driver
properly.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When graphics initializes the HDMI chip, sometimes this leads to
pins going into D3 and right channel being muted. If the audio driver
finishes initialization before the graphic driver does, this situation
becomes permanent.

This is a workaround that checks for this situation and corrects it on
playback prepare. It has been verified working on at least one machine.

BugLink: https://bugs.launchpad.net/bugs/1167270Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch let ELD debug message show 'pin_eld->monitor_present' which reflects
the real pin response to verb GET_PIN_SENSE.

'eld->monitor_present' should not be used here because 'eld' is a temp
structure now and so its "monitor_present" is not set.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Acked-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use the dynamic array allocations for pins, converters and PCM arrays
instead of the fixed size arrays.  The modern HDMI codecs get more and
more pins, and we don't know the sensitive limit.

Most of the patch are spent for the straight conversions from the
fixed array access to snd_array helpers.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Just as for analog codecs, a jack that isn't suitable for detection
(in this case, NO_PRESENCE was set) should be a phantom Jack
instead of a normal one.

Thanks to Raymond Yau for spotting.

Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/961286
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ELD validity can change during the lifetime of a presence detect,
so we need to be able to listen for changes on the ELD control.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

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

Previously, it was possible to read the eld data of the previous
monitor connected. This should not be allowed.

Also refactor the function slightly.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently, eld_valid is never set to false, except at kernel module
load time. This patch makes sure that eld is no longer valid when
the cable is (hot-)unplugged.

Cc: stable@kernel.org
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A Haswell test machine showed that the invalid connection list, but
this time it has only a single pin on the codec, thus the former fixup
code doesn't work as it assumes the three pins blindly.

This patch splits the former fixup code to two parts:
- Enable eDP 1.2 for Haswell codec
- Fix the connection list of pins on Haswell codec;
  the converter list is recorded dynamically in hdmi_add_cvt(), and
  applied in hdmi_add_pin()
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some Haswell machines support more than one display outputs (HDMI or DP),
but its BIOS may not enable the codec's 2nd and 3rd pin and output cvt widgets.

This patch implements a board-specific fixup for Intel Haswell Machines:
If the hidden pins are not enabled by BIOS, the driver will enable them
and call common code to update the codec tree.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently we set the max number of connections to be 32, but there
seems codec that gives longer connection lists like AD1988, and we see
errors in proc output and else.  (Though, in the case of AD1988, it's
a list of all codecs connected to a single vendor widget, so this must
be something fishy, but it's still valid from the h/w design POV.)

This patch tries to remove this restriction.  For efficiency, we still
use the fixed size array in the parser, but takes a dynamic array when
the size is reported to be greater than that.

Now the fixed array size is found only in patch_hdmi.c, but it should
be fine, as the codec itself can't support so many pins.
Reported-by: NRaymond Yau <superquad.vortex2@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit d45e6889 ("ALSA: hda - Provide
the proper channel mapping for generic HDMI driver") added support for
custom channel maps in the HDA HDMI driver. Due to a mistake in an
'if' condition the custom map is always used even when no such map has
been set. This causes incorrect channel mapping for multichannel audio
by default.

Pass per_pin->chmap_set to hdmi_setup_channel_mapping() as a parameter
so that it can use it for detecting if a custom map has been set instead
of checking if map is NULL (which is never the case).
Reported-by: NStaffan Lindberg <pike@xbmc.org>
Signed-off-by: NAnssi Hannula <anssi.hannula@iki.fi>
Cc: stable@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

If the driver detects and invalid ELD, it gives an open error.
But it forgot to release the assigned pin, converter and spdif ctls
before returning.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When "alsactl restore" is performed on HDMI codecs, it tries to
restore the channel map value since the channel map controls are
writable.  But hdmi_chmap_ctl_put() returns -EBADFD when no PCM stream
is assigned yet, and this results in an error message from alsactl.
Although the error is harmless, it's certainly ugly and can be
regarded as a regression.

As a workaround, this patch changes the return code in such a case to
be zero for making others happy.  (A slight excuse is: when the chmap
is changed through the proper alsa-lib API, the PCM status is checked
there anyway, so we don't have to be too strict in the kernel side.)

Cc: <stable@vger.kernel.org> [v3.7+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Haswell HDMI codec pins may report invalid connection list entries, which
will cause failure to play audio via HDMI or Display Port.

So this patch adds fixup for Haswell to workaround this hardware issue:
enable DP1.2 mode and override the pins' connection list entries with proper
value.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NXingchao Wang <xingchao.wang@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We've seen the broken HDMI *video* output on some machines with GM965,
and the debugging session pointed that the culprit is the disabled
audio output pins.  Toggling these pins dynamically on demand caused
flickering of HDMI TV.

This patch changes the behavior to keep the pin ON constantly.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51421

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NTakashi Iwai <tiwai@suse.de>

On some of the PantherPoint HDMI machines we currently enable, we're seeing
trouble with unsol events, i e detecting monitor presence, especially when
on battery and after suspend/resume.

BugLink: https://bugs.launchpad.net/bugs/1075882Tested-by: NCyrus Lien <cyrus.lien@canonical.com>
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When both an SPDIF and an HDMI device are created on the same card
instance, multiple IEC958 controls are created with indices=0, 1, ...
But the alsa-lib configuration can't know which index corresponds
actually to which PCM device, and both the SPDIF and the HDMI
configurations point to the first IEC958 control wrongly.

This patch introduces a (hackish and ugly) workaround: the IEC958
controls for the SPDIF device are re-labeled with device=1 when HDMI
coexists.  The device=1 corresponds to the actual PCM device for
SPDIF, so it's anyway a better representation.  In future, HDMI
controls should be moved with the corresponding PCM device number,
too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some old Nvidia HDMI codecs with 8ch support only 2/8 or
2/6/8 channels and with the fixed CLFE-first map.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... instead of the standard fixed channel maps.
The generic HDMI is based on the audio infoframe, and its configuration
can be selected via CA bits.  Thus we need a translation between the
CA index and the verbose channel map list.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Recently the check for non-PCM stream state was added to the generic
HDMI driver code.  But this check should be done rather to each pin
instead of each converter.  Otherwise when a different converter is
assigned at the next open, the audio infoframe can be inconsistent
with the setup using the previous converter.

For fixing this issue, this patch moves the state of the current
non-PCM status from per_cvt to per_pin.  (In addition an unused
argument cvt_nid is stripped from hdmi_setup_channel_mapping())
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For HBR stream test, use straight channel mapping way.
when switched back to "speaker-test -c8", even the audio
infoframe is up-to-date, there should be correct channel mapping setup.
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

HDMI channel remapping apparently effects HBR packets on Intel's chips.
For compressed non-PCM audio, use "straight-through" channel mapping.
For uncompressed multi-channel pcm audio, use normal channel mapping.
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The array channel_allocations[] is an ordered list, add function to get
correct order by ca_index.
Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

CONFIG_SND_HDA_POWER_SAVE is no longer an experimental feature and its
behavior can be well controlled via the default value and module
parameter.  Let's just replace it with the standard CONFIG_PM.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of calling the jack sync in the init callback of each codec,
call it generically at initialization and resume.  By calling it at
the last of resume sequence, a possible race between the jack sync and
the unsol event enablement in the current code will be closed, too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>