This interface is designed for mixer/control application. By using this
interface, an application can get information about firewire node, can
lock/unlock kernel streaming and can get notification at starting/stopping
kernel streaming.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds MIDI functionality with an assumption of 'if the device
has MIDI comformant data channels in its stream formation, the device has
one MIDI port'.

When no streams have already started, MIDI functionality starts stream
with current sampling rate.

When MIDI functionality has already starts some streams and PCM
functionality is going to start streams at different sampling rate,
this driver stops streams once and changes sampling rate, then restarts
streams for both PCM/MIDI substreams.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In previous commit, a support for transmitted packets is added. This commit
add a support for capturing PCM samples.

When any streams are already started, this driver should not change sampling
rate of the device, thus this commit also adds a restriction of sampling rate
in this situation.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Previous commit adds support for some devices which can capture PCM samples.
These devices transmit AMDTP stream in non-blocking mode. This commit adds
functionality to handle AMDTP incoming stream.

OXFW seems to have two quirks:
 - Transmits packets with non-zero dbc in its beginning
 - Transmits packets with wrong values in syt field

For the first quirk, this commit adds CIP_SKIP_INIT_DBC_CHECK flag for
incoming stream to skip first check of dbc.

For the second quirk, this commit doesn't add duplex stream which
Fireworks/BeBoB drivers use. So OXFW driver generates syt value for outgoing
stream.

Here are examples of a sequence of packets transmitted by Behringer F-Control
Audio 202. There are differences between sequences of syt value when OXFW
driver transfers outgoing stream or not.

When driver gives no outgoing stream:
Index   Payload CIP_Header_0    CIP_Header_1
38      14      00020092        900103D1
39      12      00020098        900102FF
40      12      0002009D        9001027F
41      14      000200A2        90010396
42      14      000200A8        900102E8
43      12      000200AE        90010219
44      14      000200B3        90010331
45      12      000200B9        9001025F
46      14      000200BE        90010376
47      12      000200C4        900102A1
00      12      000200C9        9001023E
01      14      000200CE        90010358
02      12      000200D4        90010289
03      16      000200D9        900103A3
04      12      000200E0        900102DD
05      14      000200E5        900103F1
06      12      000200EB        90010335
07      12      000200F0        90010263
08      14      000200F5        9001037C
09      12      000200FB        900102AE

When driver gives outgoing stream:
Index   Payload CIP_Header_0    CIP_Header_1
38      12      000200BD        900104A8
39      14      000200C2        900104A8
40      12      000200C8        900104AC
41      14      000200CD        900104A9
42      12      000200D3        900104B1
43      14      000200D8        900104A8
44      12      000200DE        900104AA
45      14      000200E3        900104A9
46      14      000200E9        900104AE
47      12      000200EF        900104A8
00      14      000200F4        900104AD
01      12      000200FA        900104A7
02      14      000200FF        900104A9
03      12      00020005        900104A9
04      14      0002000A        900104B1
05      12      00020010        900104AA
06      14      00020015        900104AD
07      12      0002001B        900104A7
08      14      00020020        900104AC
09      12      00020026        900104A7
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some devices produced by Behringer/Mackie are based on OXFW970/971. This
commit adds support for them. Additionally, this commit changes the way to
name card with some information in config rom.

Ids of some Mackie(Loud) models are not identified, therefore this commit
applies name detection for these models.

The devices support capture/playback of PCM-samples and some of them
supports capture/playback of MIDI messages. These functionalities are
implemented by followed commits.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In past commit, this driver can keep stream formations for each sampling
rate. So its stream functionality can decide stream formations with given
some parameters.

This commit moves related codes from PCM functionality to stream
functionality. Furthermore, to set stream format correctly, this commit
uses AV/C Stream Format Information command instead of AV/C Input/Output
Plug Signal Format command.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds proc interface to get information about stream
formation. This commit also adds snd_oxfw_stream_get_current_formation()
to get current stream formation.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In previous commit, this driver can get to know stream formations at
each supported sampling rates. This commit uses it to make PCM
rules/constraints and obsoletes hard-coded rules/constraints.

For this purpose, this commit adds 'struct snd_oxfw_stream_formation' and
snd_oxfw_stream_parse_format() to parse data channel formation of data
block.

According to datasheet of OXFW970/971, they support 32.0kHz to 196.0kHz.

As long as developers investigate, some devices are confirmed to have
several formats for the same sampling rate.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

OXFW970/971 may supports AV/C Stream Format Information Specification 1.1
Working Draft (Apr 2005, 1394TA). By using this command, drivers can get to know
stream formations which device supports.

This commit adds 'EXTENDED STREAM FORMAT INFORMATION' command. This command
has two subfunctions, 'SINGLE' and 'LIST'. Drivers can use 'SINGLE' subfunction
to know/set current formation of AMDTP stream, Drivers can use 'LIST'
subfunction to know an available formation of AMDTP stream in a certain sampling
rate.

But some devices don't implement the 'LIST' subfunction. So this commit uses
an assumption that 'if they don't implement it, they don't change stream
formation depending on current each sampling rate'. With this assumption, this
driver generates formations for such devices by:
 1.getting current formation by SINGLE subfunction
 2.getting supported sampling rates
 3.applying current formation for all of supported sampling rates

Followed commit implements a parser of this format information.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This is a preparation for more models. In following commit, members
of 'struct snd_card' related to name becomes to consists of vendor and
model strings in device's config-rom.

Current supported devices also has strings in their config rom, but the
strings are too long to name sound card, thus this driver still keep
hard-coded vendor and model names for them.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds a support for MIDI capture/playback

When MIDI substrams already start streaming and PCM substreams are going to
join at different sampling rate, streams are stopped once. Then sampling rate
is changed and streams are restarted.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds a support for capturing PCM samples.

When opposite PCM substream is already running, available sampling rate is
limited at current one.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit allows this driver to handle devices with non SYT-Match
sampling clock source.

When sampling clock source is SYT-Match mode, devices handle
'presentation timestamp' in received packets and generates sampling clock
according to the information. In this case, driver is synchronization master
and must transfer correct value in SYT field of each packets in outgoing
stream, then the outgoing stream is a master stream.

On the other hand, non SYT-Match mode, devices do this. So drivers must pick
up the value in SYT field of incoming packets and use the value for outgoing
stream. Currently firewire-lib module achieve this work.

Furthermore, without SYT-Match and internal clock source, the sampling rate
should be fixed for the other devices connected to the handled device. This
commit add a restriction of sampling rate at this situation.

With these implementations, this driver has no need to set clock source.
This commit remove set function.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This commit adds support for AMDTP in-stream. As a result, Dice driver
supports full duplex streams with synchronization.

AMDTP can transfer timestamps in its packets. By handling the timestamp,
devices can synchronize to the other devices or drivers on the same bus.

When Dice chipset is 'enabled', it starts streams with correct settings.
This 'enable' register is global, thus, when a stream is started to run,
an opposite stream can't start unless turning off 'enable'. Therefore
a pair of streams must be running. This causes a loss of CPU usage when
single stream is needed for neither playbacking or capturing.

This commit assumes that playback-only models also have a functionality
to transmit stream for delivering timestamps.

Currently, sampling clock source is restricted to SYT-Match mode. This is
improved in followed commit. I note that at SYT-Match mode, Dice can select
from 4 streams for synchronization but this driver uses the 1st stream only
for simplicity.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Streaming functionality can start streams when rate is given but currently
some codes are in PCM functionality.

This commit changes the way to start stream and add some arrangement
to make it easy to understand the way.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For fixing a build error with CONFIG_SND_JACK=n
  sound/soc/codecs/ts3a227e.c:223:2: error: implicit declaration of function ‘snd_jack_set_key’ [-Werror=implicit-function-declaration]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Merge tag 'asoc-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Updates for v3.19

Lots and lots of changes this time around, the usual set of driver
updates and a huge bulk of cleanups from Lars-Peter.  Probably the most
interesting thing for most users is the Intel driver updates which will
(with some more machine integration work) enable support for newer x86
laptops.

 - Conversion of AC'97 drivers to use regmap, bringing us closer to the
   removal of the ASoC level I/O code.
 - Clean up a lot of old drivers that were open coding things that have
   subsequently been implemented in the core.
 - Some DAPM performance improvements.
 - Removal of the now seldom used CODEC mutex.
 - Lots of updates for the newer Intel SoC support, including support
   for the DSP and some Cherrytrail and Braswell machine drivers.
 - Support for Samsung boards using rt5631 as the CODEC.
 - Removal of the obsolete AFEB9260 machine driver.
 - Driver support for the TI TS3A227E headset driver used in some
   Chrombeooks.

Merge remote-tracking branches 'asoc/topic/wm9090', 'asoc/topic/wm9712' and 'asoc/topic/wm9713' into asoc-next

Merge remote-tracking branches 'asoc/topic/wm8991', 'asoc/topic/wm8993', 'asoc/topic/wm8994', 'asoc/topic/wm8995' and 'asoc/topic/wm9081' into asoc-next

Merge remote-tracking branches 'asoc/topic/wm8978', 'asoc/topic/wm8983', 'asoc/topic/wm8985', 'asoc/topic/wm8988' and 'asoc/topic/wm8990' into asoc-next

Merge remote-tracking branches 'asoc/topic/wm8955', 'asoc/topic/wm8960', 'asoc/topic/wm8961', 'asoc/topic/wm8962' and 'asoc/topic/wm8974' into asoc-next

Merge remote-tracking branches 'asoc/topic/wm8776', 'asoc/topic/wm8804', 'asoc/topic/wm8900', 'asoc/topic/wm8903' and 'asoc/topic/wm8940' into asoc-next

Merge remote-tracking branches 'asoc/topic/wm8711', 'asoc/topic/wm8728', 'asoc/topic/wm8731', 'asoc/topic/wm8737' and 'asoc/topic/wm8750' into asoc-next

Merge remote-tracking branches 'asoc/topic/wm8350', 'asoc/topic/wm8400', 'asoc/topic/wm8510', 'asoc/topic/wm8523' and 'asoc/topic/wm8580' into asoc-next

Merge remote-tracking branches 'asoc/topic/twl6040', 'asoc/topic/uda134x', 'asoc/topic/uda1380' and 'asoc/topic/wl1273' into asoc-next

Merge remote-tracking branches 'asoc/topic/tlv320aic32x4', 'asoc/topic/tlv320aic3x', 'asoc/topic/tlv320dac33', 'asoc/topic/ts3a227e' and 'asoc/topic/twl4030' into asoc-next

Merge remote-tracking branches 'asoc/topic/tas2552', 'asoc/topic/tegra', 'asoc/topic/tfa9879', 'asoc/topic/tlv320aic23' and 'asoc/topic/tlv320aic31xx' into asoc-next

Merge remote-tracking branches 'asoc/topic/ssm4567', 'asoc/topic/sta32x', 'asoc/topic/sta350', 'asoc/topic/sta529' and 'asoc/topic/stac9766' into asoc-next

Merge remote-tracking branches 'asoc/topic/sh', 'asoc/topic/sigmadsp', 'asoc/topic/simple', 'asoc/topic/sirf' and 'asoc/topic/sn95031' into asoc-next

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

Merge remote-tracking branches 'asoc/topic/rcar', 'asoc/topic/rockchip', 'asoc/topic/rt286' and 'asoc/topic/rt5631' into asoc-next

Merge remote-tracking branches 'asoc/topic/multi-codec', 'asoc/topic/mxs-saif', 'asoc/topic/mxs-sgtl5000', 'asoc/topic/omap' and 'asoc/topic/pxa' into asoc-next

Merge remote-tracking branches 'asoc/topic/max98088', 'asoc/topic/max98090', 'asoc/topic/max98095', 'asoc/topic/max9850' and 'asoc/topic/mop500' into asoc-next

Merge remote-tracking branches 'asoc/topic/hdmi', 'asoc/topic/intel', 'asoc/topic/jack', 'asoc/topic/jz4740' and 'asoc/topic/lm49453' into asoc-next

Merge remote-tracking branches 'asoc/topic/fsl', 'asoc/topic/fsl-card', 'asoc/topic/fsl-dt' and 'asoc/topic/fsl-ssi' into asoc-next

Merge remote-tracking branches 'asoc/topic/davinci', 'asoc/topic/doc', 'asoc/topic/dpcm', 'asoc/topic/dwc' and 'asoc/topic/fsi' into asoc-next

Merge remote-tracking branches 'asoc/topic/cs4265', 'asoc/topic/cs4271', 'asoc/topic/cs42l51' and 'asoc/topic/cs42l73' into asoc-next

Merge remote-tracking branches 'asoc/topic/codec-mutex', 'asoc/topic/compress' and 'asoc/topic/cq93vc' into asoc-next

Merge remote-tracking branches 'asoc/topic/ak4671', 'asoc/topic/alc5623', 'asoc/topic/alc5632', 'asoc/topic/arizona' and 'asoc/topic/atmel' into asoc-next

Merge remote-tracking branches 'asoc/topic/adav80x', 'asoc/topic/adsp', 'asoc/topic/ak4535', 'asoc/topic/ak4641' and 'asoc/topic/ak4642' into asoc-next