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

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

Instead of managing input-jack stuff separately, call all stuff inside
the kctl-jack creation, deletion and report.  The caller no longer needs
to care about input-jack.

The better integration between input-jack and kctl-jack should be done
in the upper layer in near future, but for now, it's implemented locally
for more tests.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The new hardware tends to have more and more.  As a temporary fix, just
increase the number for now.

For a long-term solution, we should assign the cvts/pins dynamically.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

We can use the very same table in hda_jack.c for managing the list for
input-jack elements, too.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Manage the tags assigned for unsolicited events dynamically together
with the jack-detection routines.  Basically this is almost same as what
we've done in patch_sigmatel.c.  Assign the new tag number for each new
unsol event, associate with the given NID and the action type, etc.

With this change, now all pins looked over in snd_hda_jack_add_kctls()
are actually enabled for detection now even if the pins aren't used for
jack-retasking by the driver.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Create kcontrols for pin jack-detections, which work similarly like
jack-input layer.  Each control will notify when the jack is plugged or
unplugged, and also user can read the value at any time via the normal
control API.

The control elements are created with iface=CARD, so that they won't
appear in the mixer apps.

So far, only the pins that enabled the jack-detection are registered.
For covering all pins, the transition of the common unsol-tag handling
would be needed.  Stay tuned.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Introduce a table containing the pins and their jack-detection states
for avoiding the unnecessary verbs to check the pin status at each time.

When the unsol event is enabled via snd_hda_jack_detect_enable(), it
automatically adds the given NID to the table.  Then the driver supposes
that the codec driver will set the dirty flag appropariately when an
unsolicited event is invoked for that pin.

The behavior for reading other pins that aren't registered in the table
doesn't change.  Only the pins assigned to the table are cached, so far.

In near futre, this table can be extended to use the central place for
the unsolicited events of all pins, etc, and eventually include the
jack-detect kcontrols that replace the current input-jack stuff.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It looks more natural and saves two lines of code.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

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

Just clean-up what GCC caught.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NPaul Gortmaker <paul.gortmaker@windriver.com>

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: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

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

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

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

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

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

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

Just as for headphones and microphone jacks, this patch adds reporting
of HDMI jack status through the input layer.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

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: NAaron Plattner <aplattner@nvidia.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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: NRichard Samson <samson.richard@gmail.com>
Acked-by: NAcked-By: Stephen Warren <swarren@nvidia.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

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>