request_module() handles the printf style arguments, so we don't have
to render strings in the caller side.  Not only it reduces the
unnecessary temporary string buffer, it's even safer from the security
POV.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... and reduce the open codes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The next patch will use it, so make it visible across modules.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The helper functions snd_hda_check_board_config() and
snd_hda_check_board_codec_sid_config() are no longer used since the
transition to the generic parser and all quirks have been replaced
with fixups.  Let's kill these dead codes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Previously, calling one quirk function first and another later
would make the latter one take priority, this is now changed
to make the former take priority.

By adding two special values for fixup_id we can also get rid of the
fixup_forced flag.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent commit [6194b99d: ALSA: hda - Kill the rest of snd_print*()
usages] changed the callback map_slaves(), but one call was forgotten
to be replaced due to the cast, which leads to kernel Oops due to
invalid function.  This patch replaces it with a proper function.

Fixes: 6194b99d ('ALSA: hda - Kill the rest of snd_print*() usages')
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Pass the codec object so that we can replace all the rest of
snd_print*() usages with the proper device-specific print helpers.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The beep input device is registered via input_register_device(), but
this is called in snd_hda_attach_beep_device() where the sound devices
aren't registered yet.  This leads to the binding to non-existing
object, thus results in failure.  And, even if the binding worked
(against the PCI object), it's still racy; the input device appears
before the sound objects.

For fixing this, register the input device properly at dev_register
ops of the codec object it's bound with.  Also, call
snd_hda_detach_beep_device() at dev_disconnection so that it's
detached at the right timing.  As a bonus, since it's called in the
codec's ops, we can get rid of the further call from the other codec
drivers.
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>

We have currently sysfs attributes for each hwdep, but basically these
should belong to the codec itself, per se.  Let's add them to the
codec object while keeping them for hwdep as is for compatibility.

While we are at it, split the sysfs-related stuff into a separate
source file, hda_sysfs.c, and keep only the stuff necessary for hwdep
in hda_hwdep.c.
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>

Now each snd_hda_codec instance is managed via the device chain, the
registration and release are done by its callback instead of calling
from bus.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of calling each time device_create_file(), create the groups
of sysfs attribute files at once in a normal way.  Add a new helper
function, snd_get_device(), to return the associated device object,
so that we can handle the sysfs addition locally.

Since the sysfs file addition is done differently now,
snd_add_device_sysfs_file() helper function is removed.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

Some codec drivers still have it since using PCI_VENDOR_ID_*.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Even after the fix for leftover kconfig handling (commit f8f1becf),
the current code still doesn't handle properly the builtin/module
mixup case between the core snd-hda-codec and other codec drivers.
For example, when CONFIG_SND_HDA_INTEL=y and
CONFIG_SND_HDA_CODEC_HDMI=m, it'll end up with an unresolved symbol
snd_hda_parse_hdmi_codec.  This patch fixes the issue.

Now codec->parser points to the parser object *only* when a module
(either generic or HDMI parser) is loaded and bound.  When a builtin
symbol is used, codec->parser still points to NULL.  This is the
difference from the previous versions.

Fixes: f8f1becf ('ALSA: hda - Fix leftover ifdef checks after modularization')
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
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>

Apply the codec->power_filter to the FG nodes in general for reducing
hackish set_power_state ops override in patch_sigmatel.c.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Replace all with the standard EXPORT_SYMBOL_GPL().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This simplifies lots of codes indeed.
Tested-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds 'depop_delay' to struct hda_codec, to indicate a depop delay
time in ms when power-down, in function set_power_state() to D3.

Default value is -1, for a default delay time.
Machine fixup can set a suitable value according to the codec chip and HW audio
design.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

To reduce driver resume time, this patch resumes the codecs in parallel
if there are multiple codecs on the bus.

- The PM workqueue of bus is also used to parallel resuming multiple codecs.
- The work item 'pm_work' is renamed to 'suspend_work' to parallel suspending
  codecs.
- Add a work item 'resume_work' to parallel resuming codecs.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The time to suspend a single codec may be several hundreds of ms. When runtime
power saving is disabled, driver suspend time can be long especially when there
are more than one codec on the bus.

To reduce driver suspend time, this patch creates a work queue for the bus, and
suspends the codecs in parallel if there are multiple codecs on the bus.

[fixed cosmetic issues by tiwai]
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

According to Mengdong, we shouldn't enable runtime PM when a codec
doesn't support EPSS, based on the experiences on Windows.
We have already this check in HDMI codec drivers, but now apply it in
general in hda_codec.c.

Credit goes to Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

No functional change.

- codec->pm_down_notified flag is renamed to codec->pm_up_notified
  flag (and takes the reversed meaning), which is managed solely in
  hda_call_pm_notify() now.

- The explicit call of hda_call_pm_notify() is moved into
  hda_keep_power_on().

- Removed a redundant call of hda_call_pm_notify() in
  snd_hda_power_up(), as it's called in hda_call_codec_resume()
  anyway.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

If a codec contains only the digital outputs, it's very likely a
HDMI/DP codec, which isn't supported by the generic parser but via
HDMI codec parser code.  Detect such a case and bind with the proper
parser object if available.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Drop the hard dependency on the generic parser code and load / unload
the generic parser code dynamically if built as a module.  This allows
us to avoid the generic parser if only HDMI/DP codecs are found.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When a codec is resumed, it keeps the power on while the resuming
phase via hda_keep_power_on(), then turns down via
snd_hda_power_down().  At that point, snd_hda_power_down() notifies
the power down to the controller, and this may confuse the refcount if
the codec was already powered up before the resume.

In the end result, the controller goes to runtime suspend even before
the codec is kicked off to the power save, and the communication
stalls happens.

The fix is to add the power-up notification together with
hda_keep_power_on(), and clears the flag appropriately.

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

snd_hda_codec_reset() is called either in resetting the whole setup at
error paths or hwdep clear/reconfig sysfs triggers.  But all of these
don't assume that the power has to be off, rather they want to keep
the power state unchanged (e.g. reconfig_codec() calls the power
up/down by itself).  Thus, unconditionally clearing the power state in
snd_hda_codec_reset() leads to the inconsistency, confuses the further
operation.   This patch gets rid of the lines doing that bad thing.

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

Check whether all vmaster slaves have the same dB steps.  Otherwise
the behavior would become inconsistent.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Check the TLV db scale result before actually dividing in vmaster
slave init code.  Also mask TLV_DB_SCALE_MUTE bit so that the right
value is obtained even if this bit is set by the codec driver.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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

When a machine goes to S3/S4 after power-save is enabled, the runtime
PM refcount might be incorrectly decreased because the power-down
triggered soon after resume assumes that the controller was already
powered up, and issues the pm_notify down.

This patch fixes the incorrect pm_notify call simply by checking the
current value properly.

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

The zero-length connection list happens so often on Haswell HDMI, and
it results in warning messages like
    ALSA: hda_codec: invalid CONNECT_LIST verb 5[1]:0
at each time the codec resumes from the power-save, which is fairly
annoying.

Since this is no real error, make it shown only in the verbose debug
mode.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In the case where we have both line out and more than stereo speakers,
the speaker DACs will end up in extra_out_nid.
In fact, AFAIU, speakers are the only ones that can end up in extra_out_nid,
and if we have several of those, they should be surround outputs
rather than copy front.

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

This patch adds flags and routines to get device list & selection info on
a pin.

To support Display Port 1.2 multi-stream transport (MST) over single DP port,
a pin can support multiple devices. Please refer to HD-A spec Document Change
Notificaton HDA040-A.

A display audio codec can set flag "dp_mst" in its patch, indicating its pins
can support MST. But at runtime, a pin may not be multi-streaming capable and
report the device list is empty, depending on Gfx driver configuration.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With jackpoll_interval != 0, it's used to poll jack event periodically
in a delayed work. if it's 0, give the caller chance to probe jack status
but will not restart the delayed work.

In the next patch which enable WAKEEN feature, HDA controller was able to wake
up system when it's in D3, it's useful to detect Jack hotplug event and notify
userspace. By default the jackpoll_interval=0, this patch let jack poll once
without starting the delayed work.
Signed-off-by: NWang Xingchao <xingchao.wang@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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>

snd_hda_codec_read(), snd_hda_codec_write() & co take the argument
"direct" that indicates whether the given NID is a direct reference or
an indirect reference.  However, the indirect reference is practically
unimplemented and never exists.  And moreover, we don't need the
indication of indirect reference at this high level, as NID can be
represented in 16bit values at this point.

Meanwhile, there are some cases where it'd be nice to give some
operational options to these functions.  So, we can reuse this
argument as a new bit flag!  Pretty frugal, eh?

All callers so far pass zero to this argument, thus there is no
behavior change by this replacement.

The real usage of this new bit option will be added in the following
patches.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>