This patch does two things:
- code refactoring with a local helper function,
- allow codec drivers to provide the specific PCM stream info pointers
  only for overriding the non-NULL entries, instead of copying the
  whole.

This simplifies the codec driver side (currently the only user is
alc269's 44kHz fixed rate).
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit [ef403edb: ALSA: hda - Don't access stereo amps for
mono channel widgets] fixed the handling of mono widgets in general,
but it still misses an exceptional case: namely, a mono mixer widget
taking a single stereo input.  In this case, it has stereo volumes
although it's a mono widget, and thus we have to take care of both
left and right input channels, as stated in HD-audio spec ("7.1.3
Widget Interconnection Rules").

This patch covers this missing piece by adding proper checks of stereo
amps in both the generic parser and the proc output codes.
Reported-by: NRaymond Yau <superquad.vortex2@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The driver shutdown ops is simpler than registering reboot notifier
manually.  There should be no functional change by this -- the codec
driver calls its own callback while the bus driver just calls
azx_stop() like before.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current HDA generic parser initializes / modifies the amp values
always in stereo, but this seems causing the problem on ALC3229 codec
that has a few mono channel widgets: namely, these mono widgets react
to actions for both channels equally.

In the driver code, we do care the mono channel and create a control
only for the left channel (as defined in HD-audio spec) for such a
node.  When the control is updated, only the left channel value is
changed.  However, in the resume, the right channel value is also
restored from the initial value we took as stereo, and this overwrites
the left channel value.  This ends up being the silent output as the
right channel has been never touched and remains muted.

This patch covers the places where unconditional stereo amp accesses
are done and converts to the conditional accesses.

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

MacBook Air 5,2 has the same problem as MacBook Pro 8,1 where the
built-in mic records only the right channel.  Apply the same
workaround as MBP8,1 to spread the mono channel via a Cirrus codec
vendor-specific COEF setup.
Reported-and-tested-by: NVasil Zlatanov <vasil.zlatanov@gmail.com>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

CS420x codecs seem to deal only the single amps of ADC nodes even
though the nodes receive multiple inputs.  This leads to the
inconsistent amp value after S3/S4 resume, for example.

The fix is just to set codec->single_adc_amp flag.  Then the driver
handles these ADC amps as if single connections.
Reported-and-tested-by: NVasil Zlatanov <vasil.zlatanov@gmail.com>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Compaq Presario CQ60 laptop with CX20561 gives a wrong pin for the
built-in mic NID 0x17 instead of NID 0x1d, and it results in the
non-working mic.  This patch just remaps the pin correctly via fixup.

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

The commit [63e51fd7: ALSA: hda - Don't take unresponsive D3
transition too serious] introduced a conditional fallback behavior to
the HD-audio controller depending on the flag set.  However, it
introduced a silly bug, too, that the flag was evaluated in a reverse
way.  This resulted in a regression of HD-audio controller driver
where it can't go to the fallback mode at communication errors.

Unfortunately (or fortunately?) this didn't come up until recently
because the affected code path is an error handling that happens only
on an unstable hardware chip.  Most of recent chips work stably, thus
they didn't hit this problem.  Now, we've got a regression report with
a VIA chip, and this seems indeed requiring the fallback to the
polling mode, and finally the bug was revealed.

The fix is a oneliner to remove the wrong logical NOT in the check.
(Lesson learned - be careful about double negation.)

The bug should be backported to stable, but the patch won't be
applicable to 3.13 or earlier because of the code splits.  The stable
fix patches for earlier kernels will be posted later manually.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021
Fixes: 63e51fd7 ('ALSA: hda - Don't take unresponsive D3 transition too serious')
Cc: <stable@vger.kernel.org> # v3.14+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Cc: <stable@vger.kernel.org>
BugLink: https://bugs.launchpad.net/bugs/1428947Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Move the destructor code to device release callback for the codec
object instead.  This is a safer place to release the resources than
dev_free callback in general.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The events that are handled by HD-audio drivers are no frequent and
urgent ones, so we can use the standard workqueue without any problem
nowadays.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This makes the code flow easier -- instead of the controller driver
calling snd_hda_build_pcms() and snd_hda_build_controls() explicitly,
the codec driver itself builds PCMs and controls at probe time.  Then
the controller driver only needs to call snd_card_register().

Also, this allows us the full bind/unbind control, too.  Even when a
codec driver is bound later, it automatically registers the new PCM
and controls by itself.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now we have all pieces ready, and put them into places:
- add the hda_pcm refcount to azx_pcm_open() and azx_pcm_close(),
- call the most of cleanup code in hda_codec_reset() from the codec
  driver remove,
- call the same code also from the hda_codec object free.

Then the codec driver can be unbound more safely now.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The PCM ops might be set NULL, or cleared to NULL when the driver is
unbound.  Give a proper NULL check at each place to be more robust.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

So far, the hda_codec object kept the hda_pcm list in an array, and
the codec driver was expected to assign the array.  However, this
makes the object life cycle management harder, because the assigned
array is freed at the codec driver detach while it might be still
accessed by the opened streams.

In this patch, we allocate each hda_pcm object dynamically and manage
it as a linked list.  Each object has a kref refcount, and both the
codec driver binder and the PCM open/close touches it, so that the
object won't be freed while in use.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The memory allocators should have already given the kernel warning
messages, thus we don't have to annoy again.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Allow the codec object to have an individual card pointer.  Not only
this simplifies the redirections in many places, also this will allow
us to make each codec assigned to a different card object.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_hda_build_pcms() does actually three things: let the codec driver
build up hda_pcm list, set the PCM default values, and call the
attach_pcm bus ops for each hda_pcm instance.  The former two are
basically independent from the bus implementation, so it'd make the
code a bit more readable.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We leave the pcm field of struct hda_pcm at removal of each device, so
far.  This hasn't been a problem since unbinding the codec driver
isn't supposed to happen and another route via snd_hda_codec_reset()
clears all the once.  However, for a proper unbind implementation, we
need to care about it.

This patch does the thing above properly:

- Include struct hda_pcm pointer instead of struct hda_pcm_stream
  pointers in struct azx_dev.  This allows us to point the hda_pcm
  object at dev_free callback.

- Introduce to_hda_pcm_stream() macro for better readability.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

They are no longer used, let's kill them.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Set the card device as the parent like other sound devices instead of
leaving it empty.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

So far, we let the controller driver power down the all codecs at the
end of probe.  But this can be done better in the codec's dev_register
callback.  This results in the reduction of duplicated codes in each
control driver.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now the final bit of runtime PM cleanup: instead of manual
notification of the power up/down of the codec via hda_bus pm_notify
ops, use the standard runtime PM feature.

The child codec device will kick off the runtime PM of the parent
(PCI) device upon suspend/resume automatically.  For managing whether
the link can be really turned off, we use the bit flags
bus->codec_powered instead of the earlier bus->power_keep_link_on.
flag.  Each codec driver is responsible to set/clear the bit flag, and
the controller device can be turned off only when all these bits are
cleared.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We used to pass the power_save option value to hda_bus via a given
pointer.  This was needed to refer to the value from the HD-audio core
side.  However, after the transition to the runtime PM, this is no
longer needed.

This patch drops the power_save value indirection in hda_bus above,
and let the controller driver reprograms the autosuspend value
explicitly by a new helper, snd_hda_set_power_save().  Without this
call, the HD-audio core doesn't set up the autosuspend and flip the
runtime PM.  (User may still be able to set up via sysfs, though.)

Along with this change, the pointer argument of azx_bus_create() is
dropped as well.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is essentially a partial revert of the commit [b1920c21:
'ALSA: hda - Enable runtime PM on Panther Point'].  There was a bug
report showing the HD-audio bus hang during runtime PM on HP Spectre
XT.
Reported-by: NDang Sananikone <dang.sananikone@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It is a bad idea to export static functions. GCC for some platforms
shows errors like:

  error: __ksymtab_azx_get_response causes a section type conflict
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Like the previous transition of suspend/resume, now move the
power-save code to the standard runtime PM.  As usual for runtime PM,
it's a bit tricky, but this simplified codes a lot in the end.

For keeping the usage compatibility, power_save module option still
controls the whole power-saving behavior on all codecs.  The value is
translated to pm_runtime_*_autosuspend() and pm_runtime_allow() /
pm_runtime_forbid() calls.

snd_hda_power_up() and snd_hda_power_down() are translated to
pm_runtime_get_sync() and pm_runtime_put_autosuspend(), respectively.
Since we can do call pm_runtime_get_sync() more reliably, the sync
version is used always and snd_hda_power_up_d3wait() is dropped.
Another slight difference is that snd_hda_power_up()/down() don't call
runtime_pm code during the suspend/resume transition phase.  Calling
them there isn't safe unlike our own code, resulted in unexpected
behavior (endless wakeups).

The hda_power_count tracepoint was removed, as it doesn't match well
with the new code.

Last but not least, we need to set ignore_children flag in the parent
dev.power field so that the runtime PM of the controller chip won't
get confused.  The notification is still done in the bus pm_notify
callback.  We'll get rid of this hack in the later patch.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch moves the suspend/resume mechanisms down to each codec
driver level, as we have a proper codec driver bound on the bus now.
Then we get the asynchronous PM gratis without fiddling much in the
driver level.

As a soft-landing transition, implement the common suspend/resume pm
ops for hda_codec_driver and keep the each codec driver intact.  Only
the callers of suspend/resume in the controller side (azx_suspend()
and azx_resume()) are removed.

Another involved place is azx_bus_reset() calling the temporary
suspend and resume as a hackish method of bus reset.  The HD-audio
core provide a helper function snd_hda_bus_reset() instead.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now we create the standard HD-audio bus (/sys/bus/hdaudio), and bind
the codec driver with the codec device over there.  This is the first
step of the whole transition so that the changes to each codec driver
are kept as minimal as possible.

Each codec driver needs to register hda_codec_driver struct containing
the currently existing preset via the new helper macro
module_hda_codec_driver().  The old hda_codec_preset_list is replaced
with this infrastructure.  The generic parsers (for HDMI and other)
are also included in the preset with the special IDs to bind
uniquely.

In HD-audio core side, the device binding code is split to
hda_bind.c.  It provides the snd_hda_bus_type implementation to match
the codec driver with the given codec vendor ID.  It also manages the
module auto-loading by itself like before: when the matching isn't
found, it tries to probe the corresponding codec modules, and finally
falls back to the generic drivers.  (The special ID mentioned above is
set at this stage.)

The only visible change to outside is that the hdaudio sysfs entry now
appears in /sys/bus/devices, not as a sound class device.

More works to move the suspend/resume and remove ops will be
(hopefully) done in later patches.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is a preliminary patch for the hda_bus implementation, removing
the parent device setup to codec device.  Since the bus and the class
devices can't be crossed over, leave the sound devices to the default
parent device as is.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

BIOS doesn't seem to set up pins for 5.1 and the SPDIF out, so we need
to give explicitly here.
Reported-and-tested-by: NMisan Thropos <misanthropos@gmx.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

No real functional change, only take wall clock and system time
in same routine and add accuracy report.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the mixer amp is touched by control elements, we don't have to
power up always; if the codec was suspended at the time, we can just
update the amp cache and it's reflected to the hardware upon resume.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

azx_create_codec() function does actually two things: create a bus and
probe codecs.  For the future work, split this to two logical
functions, azx_bus_create() and azx_probe_codecs().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

It's just an indirection, so let the caller directly calling
snd_hda_build_controls().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There is no big reason to keep them separately.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For making the debugging of runtime PM easier, introduce
azx_has_pm_runtime() and use it in all places checking the runtime pm
driver capability.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There is no big merit to handle hda_bus_unsolicited object
individually, as it's tightly coupled with the hda_bus object itself.
Embedding it makes the code simpler in the end.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of copying from the given template, let the caller fills the
fields after creation.  This simplifies the code after all.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NEliot Blennerhassett <eliot@blennerhassett.gen.nz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>