Replace the lengthy #if defined(XXX) || defined(XXX_MODULE) with the
new IS_ENABLED() macro.

The patch still doesn't cover all ifdefs.  For example, the dependency
on CONFIG_GAMEPORT is still open-coded because this also has an extra
dependency on MODULE.  Similarly, an open-coded ifdef in pcm_oss.c and
some sequencer-related stuff are left untouched.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Since the commit [595fe1b7: ALSA: hda - Make
CONFIG_SND_HDA_CODEC_* tristate], the kconfig variables for the
generic parser and codec drivers can be "m" instead of boolean, but
some codes are left unchanged to check only #ifdef
CONFIG_SND_HDA_CODEC_XXX, which is no longer true for modules.
This patch fixes them by replacing with IS_ENABLED() macros.

Fixes: 595fe1b7 ('ALSA: hda - Make CONFIG_SND_HDA_CODEC_* tristate')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70161Signed-off-by: NTakashi Iwai <tiwai@suse.de>

While looking into some spurious responses, I found that the addr value was
treated a bit inconsistent: values 8..0xf will be treated as codec 0 and
values 0..7 will be treated as no error regardless of whether there is a codec
there, or not.

With this patch, all non-existing codecs will be treated equally.
In addition, printing rp and wp could help figuring out if the wp value is
reported wrongly from the controller or if something else is wrong.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the device ID for Intel Broadwell display HD-Audio controller,
and applies Haswell properties to this device.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It turned out that some AMD HDMI controllers still don't provide
proper values in GCAP register (all zero), and the driver assigns only
one stream in that case, although the connected codec chip supports
more than one stream.

In this patch, the default max number of streams for AMD HDMI
controllers is increased to 8, which  should suffice for most use
cases.  The overhead by this increase is more azx_dev struct and BDL
allocations, so it's negligible.  Of course, if the controller
provides a proper GCAP register, the register value would be used.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

While enabling these machines, we found we would sometimes lose an
interrupt if we change hardware volume during playback, and that
disabling msi fixed this issue. (Losing the interrupt caused underruns
and crackling audio, as the one second timeout is usually bigger than
the period size.)

The machines were all machines from HP, running AMD Hudson controller,
and Realtek ALC282 codec.

Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1260225Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Sometimes the hardware reports LPIB being advanced than POSBUF.
When this happens, the driver adjusts to a positive value by adding
the buffer size.  Then the driver detects it as an error (greater than
the period size), and stops the LPIB delay account from this point
on.

When I took a close look at these conditions, the values shown are all
very small numbers, and it'd be better to just ignore these values
instead of discontinuing the LPIB delay correction.

In this patch, the driver checks a negative delay value and ignores if
it's a significantly small error.  Currently the threshold is set to
64 frames, but could be smaller.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

HD-audio devices tend to take long time for finishing the whole
probing procedure.  In this patch, the time-consuming part of the
probing procedure, the codec probe and the rest initializations, are
moved in the work, so that they can be done asynchronously in parallel
with probes of other devices.

Since we already have this mechanism in the driver code for the
firmware and i915 request_symbol() stuff, we just need to enable it
always; the resultant patch even reduces more lines, which is an
additional bonus.

Credit goes to David Henningsson, who suggested this workaround.
Reported-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the probe of snd-hda-intel driver is deferred due to f/w loading
or the nested module loading, complete_all() should be also delayed
until the initialization really finished.  Otherwise, vga-switcheroo
client would start switching before the actual init is done.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now we fixed the long-standing bugs of runtime PM, let's enable
Panther Point again.  The runtime PM was disabled in the HDMI codec
driver due to the S3 issue, and this should have been fixed now.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use bus->power_keep_link_on instead.  The controller shouldn't go to
D3 when the link isn't reset, so essentially avoiding the link reset
means avoiding the runtime PM.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

dmesg here has a 100+ consecutive lines of:

[ 1464.219446] hda-intel 0000:00:14.2: spurious response 0x0:0x0, last cmd=0x170500
[ 1464.219451] hda-intel 0000:00:14.2: spurious response 0x0:0x0, last cmd=0x170500
[ 1464.219454] hda-intel 0000:00:14.2: spurious response 0x0:0x0, last cmd=0x170500
...

Ratelimit the message to reduce the dmesg log noise.

Coalesce the format while at it.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

"HDA Intel MID" is no correct name for Haswell HDMI controllers.
Give them a better name, "HDA Intel HDMI".
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Haswell HDMI audio controllers seem to get stuck when unaligned buffer
size is used.  Let's enable the buffer alignment for the corresponding
entries.

Since AZX_DCAPS_INTEL_PCH contains AZX_DCAPS_BUFSIZE that disables the
buffer alignment forcibly, define AZX_DCAPS_INTEL_HASWELL and put the
necessary AZX_DCAPS bits there.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60769Reported-by: NAlexander E. Patrakov <patrakov@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The device IDs of the AMD Cypress/Juniper/Redwood/Cedar/Cayman/Antilles/
Barts/Turks/Caicos HDMI HDA controllers weren't added explicitly
because the generic entry works, but it made the device appearing as
"Generic", and people are confused as if it's no proper HDMI
controller.  Add them so that the name shows up properly as "ATI HDMI"
instead of "Generic".

According to Takashi's tests and the lack of complaints, these devices
work fine without disabling snooping.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the HD Audio Device IDs for the Intel Wildcat Point-LP PCH.
Signed-off-by: NJames Ralston <james.d.ralston@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When HP laptops with mute and mic-record LEDs go to runtime suspend,
these LEDs are turned on forcibly no matter whether GPIO pis are on or
off.  This strange behavior seems triggered by resetting the HD-audio
bus link at azx_rutime_suspend().  So, just add a new hda_bus flag to
avoid the link reset at runtime suspend and set it for these HP
machines.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Toshiba Satellite C870 shows interrupt problems occasionally when
certain mixer controls like "Mic Switch" is toggled.  This seems
worked around by not using MSI.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=833585
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add support for HDMI audio device on VGA cards that powerdown
to D3cold using non-standard ACPI/PCI infrastructure (optimus).

This does a couple of things to make it work:

a) add a set of power ops for the hdmi domain, and enables them
via vga_switcheroo when we are a switcheroo controlled card. This
just replaces the runtime resume operation so that when the card
is in D3cold the userspace pci config space access via sysfs,
the vga switcheroon runtime resume gets called first and it calls
the GPU resume callback before calling the sound card runtime
resume.

b) standard ACPI/PCI stacks won't put a device into D3cold without
an ACPI handle, but since the hdmi audio devices on gpus don't have
an ACPI handle, we need to manually force the device into D3cold
after suspend from the switcheroo path only.

c) don't try and do runtime s/r when the GPU is off.

d) call runtime suspend/resume during switcheroo suspend/resume
this is to make sure the runtime stack knows to try and resume
the hdmi audio device for pci config space access.

v2: fix incorrect runtime call suspend->resume.

v3: rework irq handler to avoid false irq when we are resuming
but haven't runtime resumed yet, don't bother trying D3cold,
it won't work, just set it manually ourselves, move runtime s/r
calls outside the main s/r hook. enable dnyamic pm properly by
dropping reference.

v4: put back irq handler check just wrap it with cap check
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If compiled without CONFIG_SND_HDA_I915, the audio driver cannot
request power well. However, if the power well is on for other
reasons, maybe audio can still work. Therefore, do not skip the
card completely if compiled without CONFIG_SND_HDA_I915.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With runtime power save feature enabled, Headphone hotplug
event will not be detected while controller/codec in D3. HDA has
feature WAKEEN to let codec wake up system if controller is in D3 or
system in S3.(HDA Spec 4.5.9.2/3). Codec can send out INT or wake up
controller depending on whether CIE or GIE enabled.(Figure 4, Interupt
structure).

The controller must be in RESET mode after enter runtime-suspend, otherwise
it will not be waken up even if codec send out wake-up event. And STATESTS
will be cleared after controller brought out of RESET mode.

This patch only enable WAKEEN for runtime-suspend(Controller D3) mode,
not for system S3 mode. with tool "evtest", Headphone hotplug events
could be cought and reported successfully.

[fixed an unused variable warning by tiwai]
Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Register STATESTS is 16-bit length, use correct API for read/write.
Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch is a cleanup to the previous patch "reset hda link during system/
runtime suspend".

In this patch
- azx_enter_link_reset() and azx_exit_link_reset() are defined for entering and
  exiting the link reset respectively. azx_link_reset() is no longer used and
  replaced by azx_enter_link_reset().
- azx_reset() reuses the above two new functions for a link reset cycle
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

If all the codecs report ClkStopOK (OK to stop bus clock) after being put to
D3, this patch will reset the HDA link before the controller is put to D3.

So the link will be in reset during system or runtime suspend, the bus clock
stops and the codecs are in D3(ClkStop) state.

This may help to reduce power consumption by dozens of mW on some peripheral
hda codecs.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For Intel Haswell chip, HDA controller and codec have
power well dependency from GPU side. This patch added support
to request/release power well in audio driver. Power save
feature should be enabled to get runtime power saving.

There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) -> azx_probe -> module_request
(or symbol_request) -> modprobe (userspace) -> i915 init ->
drm_pci_init -> pci_register_driver -> bus_add_driver -> driver_attach ->
which in turn tries all locks on pci bus, and when it tries the one on the
audio device, it will deadlock.

This patch introduce a work to store remaining probe stuff, and let
request_module run in safe work context.
Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NLiam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a preliminary work for the upcoming Haswell HDMI audio fixes.

azx_first_init() function can be safely called after the f/w loader,
since the f/w loader doesn't require the sound hardware initialization
beforehand.  Moving it into azx_probe_continue() cleans up the code
flow a bit.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The device can support runtime PM no matter whether it support
signal wakeup or not. For some chips like Haswell which doesnot
support PME by default, this patch let haswell Display HD-A controller
enter runtime suspend, and bring more power saving whith power-well
feature enabled.
Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When a codec is powered off, some systems don't respond properly after
D3 FG transition, while the driver still expects the response and
tries to fall back to different modes (polling and single-cmd).  When
the fallback happens, the driver stays in that mode, and falling back
to the single-cmd mode means it'll loose the unsol event handling,
too.

The unresponsiveness at D3 isn't too serious, thus this fallback is
mostly superfluous.  We can gracefully ignore the error there so that
the driver keeps the normal operation mode.

This patch adds a new bit flag for codec read/write, set in the power
transition stage, which is notified to the controller driver via a new
bus->no_response_fallback flag.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As drvdata is cleared to NULL at probe failure or at removal by the
driver core, we don't have to call pci_set_drvdata(pci, NULL) any
longer in each driver.

The only remaining pci_set_drvdata(NULL) is in azx_firmware_cb() in
hda_intel.c.  Since this function itself releases the card instance,
we need to clear drvdata here as well, so that it won't be released
doubly in the remove callback.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add HD Audio Device PCI ID for the Intel BayTrail platform.
Signed-off-by: NChew, Chiau Ee <chiau.ee.chew@intel.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The audio driver mistakenly allows 64 bit addresses to be created for
the audio driver on Nvidia GPUs.  Unfortunately, the hardware normally
only supports up to 40 bits of DMA.  This can cause system panics as
well as misdirected data when the address is > 40 bits as the upper
part the address is truncated.
Signed-off-by: NMike Travis <travis@sgi.com>
Reviewed-by: NMike Habeck <habeck@sgi.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For capture, the delay through the codec contributes to the time stamp
of the sample recorded at the A to D.  Rename the codec time stamp
function appropriately.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For playback add the codec-side delay to the timestamp, for capture
subtract it.  This brings the timestamps in line with the time that
was recently added to the delay reporting.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a new codec PCM ops, get_delay(), to obtain the codec/stream-
specific PCM delay count.  When it's NULL, nothing changes.

This new feature was requested for CA0132, which has significant
delays in the path depending on the running DSP code.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This reverts commit 6ab31741.

The commit [6ab31741: ALSA: hda - Allow power_save_controller option
override DCAPS] changed the behavior of power_save_controller so that
it can override the driver capability.  This assumed that this option
is rarely changed dynamically unlike power_save option.  Too naive.

It turned out that the user-space power-management tool tries to set
power_save_controller option to 1 together with power_save option
without knowing what's actually doing.  This enabled forcibly the
runtime PM of the controller,  which is known to be broken om many
chips thus disabled as default.

So, the only sane fix is to revert this commit again.  It was intended
to ease debugging/testing for runtime PM enablement, but obviously we
need another way for it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=56171Reported-and-tested-by: NNikita Tsukanov <keks9n@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current DSP loader code abuses snd_hda_lock_devices() for ensuring
the DSP loader not conflicting with the other normal operations.  But
this trick obviously doesn't work for the PM resume since the streams
are kept opened there where snd_hda_lock_devices() returns -EBUSY.
That means we need another lock mechanism instead of abuse.

This patch provides the new lock state to azx_dev.  Theoretically it's
possible that the DSP loader conflicts with the stream that has been
already assigned for another PCM.  If it's running, the DSP loader
should simply fail.  If not -- it's the case for PM resume --, we
should assign this stream temporarily to the DSP loader, and take it
back to the PCM after finishing DSP loading.  If the PCM is operated
during the DSP loading, it should get an error, too.
Reported-and-tested-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We've got a regression report wrt the IRQ issue related with the
power-save on a Dell machine, and disabling runtime PM works around.

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

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

This patch fixes a few obvious bugs in DSP loader stuff:
- Fix possible memory leaks in the error path
- Avoid double-free calls in dma_reset()
- Properly set/unset WC bits for DMA buffers
- Add missing error status checks
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds the HD Audio Device IDs for the Intel Wellsburg PCH
Signed-off-by: NJames Ralston <james.d.ralston@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... looks like we need this for stable operations.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>