Example 1 is for "Sampling Rate Conversion",
sample has only 1 CPU, 1 Codec.
Thus, "codec Playback", "DAI1 Playback" route is unnecessary.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Both cases have 1 Capture path.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

ADG inputs clock from CLK{A,B,C,I} and outputs clock from
CLKOUT{0,1,2,3} which is selected by BRG{A,B}.
Now, ADG is assuming BRGA is for 44100Hz related clocks,
BRGB is for 48000Hz related clocks.

Clock related debug is very difficult/confusable.
This patch cleanups clock related debug info.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Current CTU/MIX/DVC are directly using rsnd_kctrl_cfg_m/s to control
val etc, but it is difficult to read/understand.
And there was no uniformity in access method.
This patch adds new rsnd_kctrl_xxx() and implements uniformed access
method.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Both DVC/MIX have Volume Ramp Control. This patch supprts MIX
Volume Ramp. One note is that main purpose of MIX Volume Ramp
is to reduce noise, thus, MIX Ramp range is very few if you
compare to DVC Volume Ramp (DVC = 5bit, MIX = 4bit).

You can use MIX Volume Ranp like below
	amixer set "MIX Ramp Up Rate"   "0.125 dB/1 step"
	amixer set "MIX Ramp Down Rate" "0.125 dB/1 step"
	amixer set "MIX Ramp" on
	aplay xxx.wav &
	amixer set "MIX",0  80%  // DAI0 Volume Down
	amixer set "MIX",1 100%  // DAI1 Volume Up
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

DVC is supporting Volume Ramp Rate, and MIX has Volume Ramp
but not yet supported. To support MIX Volume Ramp, we want to
share Rate List since DVC/MIX are using almost same list.
This patch move DVC specific Volume Ramp Rate List to core.c.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Same CTU might be used few times if system/platform is using MIX.
For example below case.

	DAI0 playback = <&src0 &ctu02 &mix0 &dvc0 &ssi0>;
	DAI1 playback = <&src2 &ctu03 &mix0 &dvc0 &ssi0>;

This case, ALSA will have CTU,0 and CTU,1 kcontrol interfaces,
but these are same CTU. This is confusing.
This patch adds new flags and avoid such case.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Same DVC might be used few times if system/platform is using MIX.
For example below case.

	DAI0 playback = <&src0 &ctu02 &mix0 &dvc0 &ssi0>;
	DAI1 playback = <&src2 &ctu03 &mix0 &dvc0 &ssi0>;

This case, ALSA will have DVC,0 and DVC,1 kcontrol interfaces,
but these are same DVC. This is confusing.
This patch adds new flags and avoid such case.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

SSI is using rsnd_ssi_flags_xxx() macro to control flags.
But it is useful macro not only for SSI. This patch replace it
to more generic rsnd_flags_xxx().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

R-Car sound DMA will be used from SSI/SRC.
dma.c doesn't alloc DMA handler in .probe timing, because we don't
know what kind of DMA transfer will be used then.
Thus, SSI/SRC have *rsnd_mod for DMA. rsnd_dma_attach() will allocate
it and attach it to system.
It will be PIO mode if it can't alloc DMA handler.

In case of MIX is used, rsnd_dma_attach() will be called twice from SSI.
To avoid duplicate allocation, current rsnd_dma_attach() is checking
allocated DMA handler. This DMA related operation is a little bit
difficult to understand.
This patch adds new rsnd_dma_alloc() and separates allocation and attach
for readable code.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Current ADG driver is over-writing flags. This patch fixes it.
Reported-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Merge remote-tracking branches 'asoc/topic/wm8524', 'asoc/topic/wm8804' and 'asoc/topic/zte' into asoc-next

Merge remote-tracking branches 'asoc/topic/twl6040', 'asoc/topic/txx9', 'asoc/topic/utils', 'asoc/topic/ux500' and 'asoc/topic/wm8523' into asoc-next

Merge remote-tracking branches 'asoc/topic/tas2552', 'asoc/topic/tas5720', 'asoc/topic/tegra', 'asoc/topic/tlv320aic32x4' and 'asoc/topic/tlv320aic3x' into asoc-next

Merge remote-tracking branches 'asoc/topic/simple', 'asoc/topic/spear', 'asoc/topic/sta32x', 'asoc/topic/stm32' and 'asoc/topic/sunxi' into asoc-next

Merge remote-tracking branches 'asoc/topic/rt5665', 'asoc/topic/rt5670', 'asoc/topic/rt5677' and 'asoc/topic/samsung' into asoc-next

Merge remote-tracking branches 'asoc/topic/rt5563', 'asoc/topic/rt5616', 'asoc/topic/rt5645', 'asoc/topic/rt5659' and 'asoc/topic/rt5663' into asoc-next

Merge remote-tracking branches 'asoc/topic/rk3036', 'asoc/topic/rockchip', 'asoc/topic/rt274' and 'asoc/topic/rt5514' into asoc-next

Merge remote-tracking branches 'asoc/topic/omap', 'asoc/topic/psc-ac97' and 'asoc/topic/pxa' into asoc-next

Merge remote-tracking branches 'asoc/topic/mtk', 'asoc/topic/mxs', 'asoc/topic/nau8825', 'asoc/topic/nuc900' and 'asoc/topic/of-graph' into asoc-next

Merge remote-tracking branches 'asoc/topic/kirkwood', 'asoc/topic/max9867', 'asoc/topic/max98926' and 'asoc/topic/max98927' into asoc-next

Merge remote-tracking branches 'asoc/topic/hisi', 'asoc/topic/img', 'asoc/topic/jack' and 'asoc/topic/jz4740' into asoc-next

Merge remote-tracking branches 'asoc/topic/dwc', 'asoc/topic/es8316', 'asoc/topic/fsi', 'asoc/topic/fsl' and 'asoc/topic/hdmi' into asoc-next

Merge remote-tracking branches 'asoc/topic/cs43130', 'asoc/topic/cs53l30', 'asoc/topic/cygnus' and 'asoc/topic/davinci' into asoc-next

Merge remote-tracking branches 'asoc/topic/cs35l33', 'asoc/topic/cs35l34' and 'asoc/topic/cs42l42' into asoc-next

Merge remote-tracking branches 'asoc/topic/blackfin', 'asoc/topic/build', 'asoc/topic/cirrus' and 'asoc/topic/compress' into asoc-next

Merge remote-tracking branches 'asoc/topic/adau1977', 'asoc/topic/arizona', 'asoc/topic/atmel', 'asoc/topic/au1x' and 'asoc/topic/bcm' into asoc-next

ASoC: Fixes for v4.13

A couple of fixes, one for a regression in simple-card introduced during
the merge window that was only reported this week and another for a
regression in registration of ACPI GPIOs.

# gpg: Signature made Thu 31 Aug 2017 12:50:29 BST
# gpg:                using RSA key ADE668AA675718B59FE29FEA24D68B725D5487D0
# gpg:                issuer "broonie@kernel.org"
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>" [unknown]
# gpg:                 aka "Mark Brown <broonie@debian.org>" [unknown]
# gpg:                 aka "Mark Brown <broonie@kernel.org>" [unknown]
# gpg:                 aka "Mark Brown <broonie@tardis.ed.ac.uk>" [unknown]
# gpg:                 aka "Mark Brown <broonie@linaro.org>" [unknown]
# gpg:                 aka "Mark Brown <Mark.Brown@linaro.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 3F25 68AA C269 98F9 E813  A1C5 C3F4 36CA 30F5 D8EB
#      Subkey fingerprint: ADE6 68AA 6757 18B5 9FE2  9FEA 24D6 8B72 5D54 87D0

Copier can support upto 4 output pins. However, only pin 0 is configured
as a part of copier initialization. Configuring rest of pins require the
separate IPC to be sent to fw.
Signed-off-by: Pradeep Tewani <pradeep.d.tewani@intel.com>
Acked-By: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

It is still using old driver style, this patch also
fixup it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>