Pull the pcm_ops and the functions they use into a new hda_controller
file.  This is done to allow for other hda implementations besides PCI
to use the same ops.  The hda_controller file will house functionality
related to HDA but independent of the bus used to talk to the
controller.

This currently shares dsp locking across the two files.  This will be
remedied in a following commit.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Adding this op allows the X86 specific mmap operation to help in
hda_intel without needing a CONFIG_X86 in future non-PCI hda drivers.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Break out the allocation of pages for DMA and PCM buffers to ops in
the chip structure.  This is done to allow for architecture specific
work-arounds to be added.  Currently mark_pages_wc is used by
hda_intel.  This avoids needing to move that x86-specific code to a
common area shared with hda platform drivers.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Passing the max slots and power save arguments to codec_create will
allow for its reuse by an hda_platform driver. It makes the function
independent of the module params in hda_intel and ready to move to
hda_shared in a following commit.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Keeping a pointer to the jackpoll_ms array in the chip will allow
azx_codec_create to be shared between hda_intel and hda_platform
drivers.  Also modify get_jackpoll_ms to make the jackpoll_ms member
optional, this way a platform driver can leave it out if it's not
needed.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Although the code was updated last year the "#if 0" surrounding it
dates back to the original git commit.  The function will be moved to
a new file, no need to carry the dead code.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is a PCI-only feature, but adding a callback for it in the chip
structure breaks the PCI dependency in the RIRB code allowing the
logic there to be re-used by the platform HDA driver.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This removes calls to get the device via PCI from other parts of the
code that will be able to be re-used by the platform driver.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This will allow for a platform hda driver to use it as well.  It
removes the dependency on the module param from hda_intel, which will
allow for azx_setup_periods to be shared.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The forthcoming platform hda driver needs to override the way
registers are read and written.  In preparation for that, introduce a
reg_ops struct that can be implemented differently by the new driver.
Change the existing macros to use the new structure, and move them to
hda_priv.h where they will be accessible to both PCI and platform
drivers.

Start with register access, but later commits will add more ops that
differ between PCI and platform.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Later commits adding support for hda platform drivers will want to use
the same defines and structures. Put them in a place reachable by both
hda_intel and the new platform driver.

This is a mostly a direct copy with a few whitespace and comment
changes to make checkpatch happy.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

According to the HDA spec, we must write 1 to bit 15 on a CORBRP
reset, read back 1, then write 0, then read back 0. This must be
done while the DMA is not running.

We accidentaly ended up writing back the 0 by using a writel
instead of a writew to CORBWP.

This caused occasional controller failure on Bay Trail hardware.

[replaced error messages with dev_err() by tiwai]
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use dev_err() and co for messages from HD-audio controller and codec
drivers.  The codec drivers are mostly bound with codec objects, so
some helper macros, codec_err(), codec_info(), etc, are provided.
They merely wrap the corresponding dev_xxx().

There are a few places still calling snd_printk() and its variants
as they are called without the codec or device context.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As the HD-audio is treated individually in each codec driver, it's
more convenient to assign an own struct device to each codec object.
Then we'll be able to use dev_err() more easily for each codec, for
example.

For achieving it, this patch just creates an object "hdaudioCxDy".
It belongs to sound class instead of creating a new bus, just for
simplicity, at this stage.  No pm ops is implemented in the device
struct level but currently it's merely a container.  The PCM and hwdep
devices are now children of this codec device.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Also remove superfluous snd_card_set_dev() calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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>