HDAC extended core should create streams for an extended bus and also free
up those on cleanup. So introduce snd_hdac_ext_stream_init_all and
snd_hdac_stream_free_all routines
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Since this is common option for HDA driver to specfiy pre-allocated
buffer, we should make this option availble to all HDA driver by
moving this to HDA core
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Yet another non-trivial conflicts for HDA legacy stuff.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When CONFIG_SND_HDA_I915=n, we get a compile warning:
  sound/pci/hda/hda_intel.c: In function ‘azx_probe_continue’:
  sound/pci/hda/hda_intel.c:1882:2: warning: label ‘skip_i915’ defined but not used [-Wunused-label]

Fix it by putting again ifdef to it.  Sigh.

Fixes: bf06848b ('ALSA: hda - Continue probing even if i915 binding fails')
Reported-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The new Dell XPS13 also requires the similar quirk for fixing the
noisy outputs.  (But, as the codec was changed, now the fixup for
Latitude is used instead.)

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

They're based on DM1500 (ArchWave produced), and BeBoB version 3 is
installed.

$ cat /proc/asound/FCA610/firewire/firmware
Manufacturer:	bridgeCo
Protocol Ver:	3
Build Ver:		0
GUID:		0x001564000002AD73
Model ID:		0x03
Model Rev:		0
Firmware Date:	20121102
Firmware Time:	153431
Firmware ID:	0x610
Firmware Ver:	8348
Base Addr:		0x400C0080
Max Size:		1422624
Loader Date:	20121015
Loader Time:	104710
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Behringer FCA610 transmits packets with periodic noisy PCM samples
when receiving no streams, and generates a bit noisy sound.

ALSA BeBoB driver is programmed to establish both in/out connections
when starting streaming, then transfers packets as userspace applications
requested. This means that there's a case that one of incoming/outgoing
streams is running, to save CPU and bandwidth usage. Although, it's natural
to start transferring packets in both direction.

This commit makes this driver to keeps duplex streams always.
Tested-by: NKim Tore Jensen <kim@incendio.no>
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

PrismSound Orpheus, Behringer UFX1604 and FCA610 work with BeBoB v3, and
they're confirmed to transmit discontinuous packets in the beginning of
streaming.

payload    CIP headers
  8        0x00070000 0x9002FFFF
  8        0x00070000 0x9002FFFF
  8        0x00070000 0x9002FFFF
  8        0x00070008 0x9002FFFF <-
  8        0x00070008 0x9002FFFF
  8        0x00070008 0x9002FFFF
  8        0x00070008 0x9002FFFF
  8        0x00070008 0x9002FFFF
  8        0x00070008 0x9002FFFF
232        0x00070000 0x9002E798 <-
232        0x00070008 0x9002FB99
232        0x00070010 0x90021398
  8        0x00070018 0x9002FFFF
(This sample was got with Behringer FCA610 and FFADO library.)

This commit sets CIP_EMPTY_HAS_WRONG_DBC and CIP_SKIP_DBC_ZERO_CHECK to
ignore these discontinuities.
Tested-by: NKim Tore Jensen <kim@incendio.no>
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Behringer FCA610 and UFX1604 is confirmed to require more time till
transmitting packets after establishing connections. This seems to
be a quirk of DM1500 ASIC which ArchWave produced.

For this quirk, this commit extends the time to wait up to 2 seconds.
As a result, in worst cases, below userspace functions require 2 seconds
to return.
 - snd_pcm_prepare()
 - snd_pcm_hw_params()
 - snd_pcm_recover()
Tested-by: NKim Tore Jensen <kim@incendio.no>
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

BeBoB installed devices have BeBoB register area. This area stores
basic information about its firmware. A register has its protocol
version.

This commit adds 'version' member and store the device's protocol
version to handle v3 quirks in following commits.
Tested-by: NKim Tore Jensen <kim@incendio.no>
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In previous commits, this driver can detect the source of clock as mush
as possible. SYT-Match mode is also available.

This commit purge the restriction.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The old string literals were completely replaced by new normalized
representation.

This commit obsoletes it.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit changes function prototype and its processing. As a result,
function caller can execute additional processing according to detected
clock source.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA: bebob: preparation for replacing string literals by normalized representation for model-dependent structures

Previous commit adds a enumerator as a normalized representation of
clock source, while model-dependent structures still use string literals
for this purpose.

This commit is a preparation for replacement.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Previous commit allows this driver to detect several types of clock
source, while there's no normalized expression for it.

This commit adds a new enumerator for this purpose.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With BeBoB version 3, current ALSA BeBoB driver detects the type of
current clock signal source wrongly. This is due to a lack of proper
implementation to parse the information.

This commit renews the parser. As a result, this driver detects
SYT-Match clock signal, thus it can start streams with two modes;
SYT-Match mode and the others. SYT-Match mode will be supported in future
commits.

There's a constrain about detected internal/external clock source.
When detecting external clock source, this driver allows userspace
applications to use current sampling rate only. This is due to consider
abour synchronization to external clock sources such as S/PDIF, ADAT or
word-clock.

According to several information from some devices, I guesss that the
internal clock of most devices synchronize to IEEE 1394 cycle start
packet. In this case, by a usual way, it's detect as 'Sync type
of output Music Sub-Unit' connected to 'Sync type of PCR output Unit
(oPCR)', and this driver judges it as internal clock. Therefore,
userspace applications is allowed to request arbitrary supported sampling
rates.

On the other hand, several devices based on BeBoB version 3 have
additional internal clock. In this case, by a usual way, it's detect as
'Sync/Additional type of External input Unit'. Unfortunately, there's no
way to distinguish this sync type from the other external clock sources
such as word-clock. In this case, this driver handles it as external and
userspace applications is forced to use current sampling rate.

I note that when the source of clock is detected as 'Isochronous stream
type of input PCR[0]', it's under 'SYT-Match' mode. In this mode, the
synchronization clock is generated according to SYT-series in received
packets. In this case, this driver generates the series by myself. I
experienced this mode often make the device silent suddenly during
playbacking. This means that the mode is easy to lost synchronization.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fix the missing dependency on PCM stuff.

[Add the same fix for HAL2, too -- tiwai]
Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Conflicts:
	sound/pci/hda/patch_realtek.c
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We still got a report that the audio crackles and noises occur with
the recent 4.1 kernels on Dell machines.  These machines seem to need
similar workarounds that have been applied to the recent Dell XPS 13
models.  Since the codec of these machines (Dell Latitute E7240 and
E7440) is different from XPS 13's one, we need a new fixup entry.

Also, it was confirmed that the previous workaround to disable the
widget power-save (commit [219f47e4: ALSA: hda - Disable widget
power-saving for ALC292 & co]) is no longer needed after this fix.
So, this patch includes the partial revert of the commit, too.
Reported-and-tested-by: NMihai Donțu <mihai.dontu@gmail.com>
Tested-by: NJonathan McDowell <noodles@earth.li>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

On a HP Envy TouchSmart laptop, there are 2 speakers (main speaker
and subwoofer speaker), 1 headphone and 2 DACs, without this fixup,
the headphone will be assigned to a DAC and the 2 speakers will be
assigned to another DAC, this assignment makes the surround-2.1
channels invalid.

To fix it, here using a DAC/pin preference map to bind the main
speaker to 1 DAC and the subwoofer speaker will be assigned to another
DAC.

Cc: <stable@vger.kernel.org>
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NMatt Ranostay <mranostay@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use kernel.h macro definition.

Thanks to Julia Lawall for Coccinelle scripting support.
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use kernel.h macro definition.

Thanks to Julia Lawall for Coccinelle scripting support.
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The dev_attrs field of struct bus_type is going away, use dev_groups instead.
This converts the soundbus code to use the correct field.

These modifications were made using Coccinelle.
Signed-off-by: NQuentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Yet another non-trivial conflicts resolution for the recent HD-audio fix.

Conflicts:
	sound/pci/hda/hda_intel.c
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The previous patch tried to continue the probe if i915 binding fails.
For for simplicity reason, we haven't implemented abort even for
controller chips that are dedicated for HDMI/DP on HSW and BDW.
However, Mengdong suggested that this can be dangerous; BIOS may
disable gfx power well although the PCI entry for HD-audio is left,
and this may result in the unexpected behavior, kernel errors, etc.

For avoiding this situation, abort the probe at i915 binding failure
only for HSW/BDW chips selectively.  For other chips, it still
continues.

Fixes: bf06848b ('ALSA: hda - Continue probing even if i915 binding fails')
Reported-by: NMengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit a1b3fda6ae ALSA: hdac_ext: add hdac extended controller,
erroneously added snd_hdac_ext_bus_map_codec_to_link() function
declaration, so remove it
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_hdac_link_power() has to be called after unregistering the codec
device.  Otherwise the device might be already runtime-suspended, thus
the refcount goes under zero, triggering a warning like:

  WARNING: CPU: 7 PID: 2014 at sound/hda/hdac_i915.c:63 snd_hdac_display_power+0x106/0x120 [snd_hda_core]()
  CPU: 7 PID: 2014 Comm: modprobe Not tainted 4.1.0-rc7-test+ #1
  Call Trace:
   [<ffffffff81697fe3>] dump_stack+0x4c/0x6e
   [<ffffffff810696da>] warn_slowpath_common+0x8a/0xc0
   [<ffffffff810697ca>] warn_slowpath_null+0x1a/0x20
   [<ffffffffa02dd526>] snd_hdac_display_power+0x106/0x120 [snd_hda_core]
   [<ffffffffa030b422>] azx_intel_link_power+0x12/0x20 [snd_hda_intel]
   [<ffffffffa037139f>] azx_link_power+0x1f/0x30 [snd_hda_codec]
   [<ffffffffa02d89fe>] snd_hdac_link_power+0x2e/0x40 [snd_hda_core]
   [<ffffffffa0368524>] snd_hda_codec_dev_free+0x34/0x50 [snd_hda_codec]
   [<ffffffffa0252061>] __snd_device_free+0x51/0xa0 [snd]
   .....
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now we have the bus and controller code added to find and initialize
the extended capabilities. Now we need to use them in stream code to
decouple stream, manage links etc

So this patch adds the stream handling code for extended capabilities
introduced in preceding patches
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The controller needs to support the new capabilities and allow
reading, parsing and initializing of these capabilities, so this patch
does it
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The new HDA controllers from Intel support new capabilities like
multilink, pipe processing, SPIB, GTS etc In order to use them we
create an extended HDA bus which embed the hdac bus and contains the
fields for extended configurations
Signed-off-by: NJeeja KP <jeeja.kp@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Changed ctl type for Input Gain Control and Input Gain Pad Control to
USB_MIXER_S16 as per section 5.2.5.7.11-12 in the USB Audio Class 2.0
definition.
Signed-off-by: NJohan Rastén <johan@oljud.se>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Yet another regression by the transition to regmap cache; for better
usability, we had the fake mute control using the zero amp value for
Conexant codecs, and this was forgotten in the new hda core code.

Since the bits 4-7 are unused for the amp registers (as we follow the
syntax of AMP_GET verb), the bit 4 is now used to indicate the fake
mute.  For setting this flag, snd_hda_codec_amp_update() becomes a
function from a simple macro.  The bonus is that it gained a proper
function description.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This merges and resolves the non-trivial conflicts with the recent fix
for hda-i915 binding fallback.

Conflicts:
	sound/pci/hda/hda_intel.c
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently snd-hda-intel driver aborts the probing of Intel HD-audio
controller with i915 power well management when binding with i915
driver via hda_i915_init() fails.  This is no big problem for Haswell
and Broadwell where the HD-audio controllers are dedicated to
HDMI/DP, thus i915 link is mandatory.  However, Skylake, Baytrail and
Braswell have only one controller and both HDMI/DP and analog codecs
share the same bus.  Thus, even if HDMI/DP isn't usable, we should
keep the controller working for other codecs.

For fixing this, this patch simply allows continuing the probing even
if hda_i915_init() call fails.  This may leave stale sound components
for HDMI/DP devices that are unbound with graphics.  We could abort
the probing selectively, but from the code simplicity POV, it's better
to continue in all cases.
Reported-by: NLibin Yang <libin.yang@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add the missing NULL checks so that snd_hdac_i915*() can be called
even after the binding with i915 failed.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Along with the transition to regmap for managing the cached parameter
reads, the caps overwrite was also moved to regmap cache.  The cache
change itself works, but it still tries to write the non-existing verb
(the HDA parameter is read-only) wrongly.  It's harmless in most
cases, but some chips are picky and may result in the codec
communication stall.

This patch avoids it just by adding the missing flag check in
reg_write ops.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch fix some spelling typo found in Documentations/sound/oss.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Enable runtime PM of the HDMI audio codec on the latest Intel platforms.
So the HD-A controller or HDMI codec can suspend when idle timeout by
default and release the GFX power well.
The patch influences HSW/BDW/BYT/BSW/SKL. Eariler platforms and third
party analog codecs will not be influenced.
Signed-off-by: NLu, Han <han.lu@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Resolve the non-trivial conflict due to the hdac regmap API changes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>