18 Mar, 2019
1 commit
-
This commit adds support for MOTU 8pre FireWire, which was shipped 2007
and nowadays already discontinued. Userspace applications can transmit
and receive PCM frames and MIDI messages for this model via ALSA PCM
interface and RawMidi/Sequencer interfaces.Like the other models of MOTU FireWire series, this model has many
quirks in its CIP.At first, data channels for two pairs of optical interfaces. At lower
sampling transmission frequency, i.e. 44.1 and 48.0 kHz, one pair is
available for ADAT data, thus 8 data chunks are transferred by CIP.
At middle sampling transmission frequency, i.e. 88.2 and 96.0 kHz,
two pairs are available to keep 8 chunks for ADAT data, thus CIP
still includes 8 data chunks.Apart from data chunks for optical interface, CIP includes fixed number
of data chunks. In tx stream, two chunks for status message, eight
chunks for samples from analog 1-8 input, two chunks for mix-return.
In rx stream, two chunks for control message, two chunks for main 1-2
output, two chunks for phone 1-2 output, two chunks for dummy 1-2.CIP header in tx stream includes quirks for its dbs and dbc fields.
The value of dbs field is fixed to 0x13, against its actual size.
The value of dbc field is firstly updated to 0x07 from zero, then
it's incremented continuously according to actual number of data h
blocks.Finally, the model has own bits to disable frame fetch.
This commit uses several options to absorb the above quirks.
$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0410b57d bus_info_length 4, crc_length 16, crc 46461
404 31333934 bus_name "1394"
408 20001000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4)
40c 0001f200 company_id 0001f2 |
410 00083dfb device_id 0000083dfb | EUI-64 0001f20000083dfbroot directory
-----------------------------------------------------------------
414 0004c65c directory_length 4, crc 50780
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 8d000006 --> eui-64 leaf at 438
424 d1000001 --> unit directory at 428unit directory at 428
-----------------------------------------------------------------
428 0003991c directory_length 3, crc 39196
42c 120001f2 specifier id
430 1300000f version
434 17103800 modeleui-64 leaf at 438
-----------------------------------------------------------------
438 00022681 leaf_length 2, crc 9857
43c 0001f200 company_id 0001f2 |
440 00083dfb device_id 0000083dfb | EUI-64 0001f20000083dfbSigned-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
17 Mar, 2019
1 commit
-
Current ALSA firewire-motu driver uses the value of 'model' field
of unit directory in configuration ROM for modalias for MOTU
FireWire models. However, as long as I checked, Pre8 and
828mk3(Hybrid) have the same value for the field (=0x100800).unit | version | model
--------------- | --------- | ----------
828mkII | 0x000003 | 0x101800
Traveler | 0x000009 | 0x107800
Pre8 | 0x00000f | 0x100800
Cc: # v4.19+
Signed-off-by: Takashi Iwai
26 Feb, 2019
1 commit
-
In data blocks of common isochronous packet for MOTU devices, PCM
frames are multiplexed in a shape of '24 bit * 4 Audio Pack', described
in IEC 61883-6. The frames are not aligned to quadlet.For capture PCM substream, ALSA firewire-motu driver constructs PCM
frames by reading data blocks byte-by-byte. However this operation
includes bug for lower byte of the PCM sample. This brings invalid
content of the PCM samples.This commit fixes the bug.
Reported-by: Peter Sjöberg
Cc: # v4.12+
Fixes: 4641c9394010 ("ALSA: firewire-motu: add MOTU specific protocol layer")
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
07 Feb, 2019
1 commit
-
The calls of snd_info_register() are superfluous and should be avoided
at the procfs creation time. They are called at the end of the whole
initialization via snd_card_register(). This patch drops such
superfluous calls.Reviewed-by: Takashi Sakamoto
Tested-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
10 Oct, 2018
3 commits
-
In former commits, .private_free callback releases resources just for
data transmission. This release function can be called without the
resources are actually allocated in error paths.This commit applies a small refactoring to clean up codes in error
paths.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
In a previous commit, drivers in ALSA firewire stack blocks .remove
callback of bus driver. This enables to release members of private
data in the callback after releasing device of sound card.This commit simplifies codes to release the members.
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
At present, in .remove callback of bus driver just decrease reference
count of device for ALSA card instance. This delegates release of the
device to a process in which the last of ALSA character device is
released.On the other hand, the other drivers such as for devices on PCIe are
programmed to block .remove callback of bus driver till all of ALSA
character devices are released.For consistency of behaviour for whole drivers, this probably confuses
users. This commit takes drivers in ALSA firewire stack to imitate the
above behaviour.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
04 Oct, 2018
1 commit
-
At present, private data of each driver in ALSA firewire stack is
allocated/freed by kernel slab allocator for corresponding unit on
IEEE 1394 bus. In this case, resource-managed slab allocator is
available to release memory object automatically just before releasing
device structure for the unit. This idea can prevent runtime from
memory leak due to programming mistakes.This commit uses the allocator for the private data. These drivers
already use reference counter to maintain lifetime of device structure
for the unit by a pair of fw_unit_get()/fw_unit_put(). The private data
is safely released in a callback of 'struct snd_card.private_free().Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
18 Jul, 2018
1 commit
-
snd_pcm_lib_mmap_vmalloc() was supposed to be implemented with
somewhat special for vmalloc handling, but in the end, this turned to
just the default handler, i.e. NULL. As the situation has never
changed over decades, let's rip it off.Reviewed-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
20 Jun, 2018
5 commits
-
This commit adds support for MOTU Traveler, launched in 2005, discontinued
quite before. As a result, transmission of PCM frame and MIDI messages is
available via ALSA PCM and RawMIDI/Sequencer interfaces.This model supports sampling transmission frequency up to 192.0 kHz, and
AES/EBU on XLR interface and ADAT on optical interface. Unlike
Motu 828MkII, Windows driver can switch fetching mode for DSP, like
mute/unmute feature.Although this commit enables high sampling transmission frequency, actual
sound from this model is not good. As long as I tested, it's silence at
176.4 kHz, and it includes hissing noise at 192.0 kHz. In my opinion, as I
reported at 3526ce7f9ba7 ('ALSA: firewire-motu: add MOTU specific protocol
layer'), timestamping on source packet header (SPH) may not still be good
for this model as well.$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 04106505 bus_info_length 4, crc_length 16, crc 25861
404 31333934 bus_name "1394"
408 20001000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 1 (4)
40c 0001f200 company_id 0001f2 |
410 0001f32f device_id 000001f32f | EUI-64 0001f2000001f32froot directory
-----------------------------------------------------------------
414 0004c65c directory_length 4, crc 50780
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 8d000006 --> eui-64 leaf at 438
424 d1000001 --> unit directory at 428unit directory at 428
-----------------------------------------------------------------
428 00035955 directory_length 3, crc 22869
42c 120001f2 specifier id
430 13000009 version
434 17107800 modeleui-64 leaf at 438
-----------------------------------------------------------------
438 000206b2 leaf_length 2, crc 1714
43c 0001f200 company_id 0001f2 |
440 0001f32f device_id 000001f32f | EUI-64 0001f2000001f32fSigned-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
For MOTU protocol version 2, this driver arranges the number of data
chunks to align chunks to quadlet data channel. However, MOTU Traveler
has padding bytes in the end of data block at high clock mode.This commit removes the arrangement. Fortunately, at low and middle clock
mode, supported model for v2 protocol (828mkII) gets no influence from this
change because all of combination for data chunks are just aligned to
quadlet data channel.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
MOTU Traveler supports AES/EBU on XLR interface and data block of rx/tx
packet includes two chunk for the interface. This commit adds a flag
for this purpose.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
This driver explicitly assumes that all of supported models have main data
chunk separated from chunk for analog ports. However, MOTU Traveler doesn't
support the separated main data chunk.This commit adds a flag for the separated main data chunk.
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
In MOTU firewire protocol, data block consists of 24 bit data chunks except
for one quadlet for source packet header (SPH). The number of data chunk in
a data block is different between three clock modes; low, middle and high.
When unit supports ADAT on optical interface, the data block includes some
chunks for ADAT channels. These ADAT chunks are unavailable at high mode.This driver has local functions to calculate the number of ADAT chunks. But
They uses stack for three clock modes. This is useless for higher mode.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
28 May, 2018
1 commit
-
Convert the S_ symbolic permissions to their octal equivalents as
using octal and not symbolic permissions is preferred by many as more
readable.see: https://lkml.org/lkml/2016/8/2/1945
Done with automated conversion via:
$ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplaceMiscellanea:
o Wrapped one multi-line call to a single line
Signed-off-by: Joe Perches
Acked-by: Vinod Koul
Signed-off-by: Takashi Iwai
12 Feb, 2018
1 commit
-
This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
for f in $L; do sed -i "-es/^\([^\"]*\)\(\\)/\\1E\\2/" $f; done
donewith de-mangling cleanups yet to come.
NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do. But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.The next patch from Al will sort out the final differences, and we
should be all done.Scripted-by: Al Viro
Signed-off-by: Linus Torvalds
28 Nov, 2017
1 commit
-
Signed-off-by: Al Viro
07 Nov, 2017
1 commit
-
Conflicts:
include/linux/compiler-clang.h
include/linux/compiler-gcc.h
include/linux/compiler-intel.h
include/uapi/linux/stddef.hSigned-off-by: Ingo Molnar
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
25 Oct, 2017
1 commit
-
…READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)@ depends on patch @
expression E;
@@- ACCESS_ONCE(E)
+ READ_ONCE(E)
----Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
12 Sep, 2017
1 commit
-
Add a jump target so that a bit of exception handling can be better reused
at the end of this function.This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
Signed-off-by: Takashi Iwai
22 Aug, 2017
2 commits
-
Drivers in ALSA firewire stack still includes some symbols which can be
moved to a section for read-only symbols.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
Conflicts:
sound/core/control.c
21 Aug, 2017
2 commits
-
MOTU Audio Express is one of third generation in MOTU FireWire
series, produced in 2011. This model consists of three chips:
* TI TSB41AB2 (Physical layer for IEEE 1394 bus)
* Microchip USB3300 (Hi-Speed USB Device with ULPI interface)
* Xilinx Spartan-3A FPGA, XC3S400A (Link layer for IEEE 1394 bus, packet
processing and data block processing layer)This commit adds support for this model. As I expected, it works with
current implementaion of protocol version 3. On the other hand, the unit
has a quirk to request subaction originated by any driver.11:45:51.287643 firewire_ohci 0000:03:00.0: AT spd 2 tl 1f, ffc1 -> ffc0, -reserved-, QW req, fffff0000b14 = 02000200
11:45:51.289193 firewire_ohci 0000:03:00.0: AR spd 2 tl 1f, ffc0 -> ffc1, ack_complete, W resp
11:45:51.289381 fireire_core 0000:03:00.0: unsolicited response (source ffc0, tlabel 1f)
11:45:51.313071 firewire_ohci 0000:03:00.0: AT spd 2 tl 20, ffc1 -> ffc0, ack_pending , QW req, fffff0000b14 = 02000200
11:45:51.314539 firewire_ohci 0000:03:00.0: AR spd 2 tl 20, ffc0 -> ffc1, ack_complete, W respIn 1394 OHCI (rev.1.1), after OUTPUT_LAST* descriptors is processed,
'xferStaus' field is filled with 'ContextControl[0:15]' (see clause 7.1.3).
5 bits in LSB side of the field has ack code in acknowledge from the unit
(see clause 7.2.2). A list of the code is shown in Table 3-2.As long as I investigated, in a case of the '-reserved-' acknowledge
message from the unit, the field has 0x10. On the table, this value is
'Reserved for definition by future 1394 standards'. As long as I know,
any specifications of IEEE 1394 has no such extensions, thus the unit is
out of specification. Besides, I note that the unit does not always
acknowledge with the invalid code. I guess this is a bug of firmware. I
confirmed the bug in firmware version 1.04 and this is the latest one.$ cd linux-firewire-utils
$ python2 ./src/crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0410a756 bus_info_length 4, crc_length 16, crc 42838
404 31333934 bus_name "1394"
408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256)
40c 0001f200 company_id 0001f2 |
410 000a8a7b device_id 00000a8a7b | EUI-64 0001f200000a8a7broot directory
-----------------------------------------------------------------
414 0004ef04 directory_length 4, crc 61188
418 030001f2 vendor
41c 0c0083c0 node capabilities per IEEE 1394
420 d1000002 --> unit directory at 428
424 8d000005 --> eui-64 leaf at 438unit directory at 428
-----------------------------------------------------------------
428 00031680 directory_length 3, crc 5760
42c 120001f2 specifier id
430 13000033 version
434 17104800 modeleui-64 leaf at 438
-----------------------------------------------------------------
438 00025ef3 leaf_length 2, crc 24307
43c 0001f200 company_id 0001f2 |
440 000a8a7b device_id 00000a8a7b | EUI-64 0001f200000a8a7bSigned-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
In protocols of MOTU FireWire series, when transferring MIDI messages,
transmitter set existence flag to one byte on first several quadlets. The
position differs depending on protocols and models, however two cases are
confirmed; in 5th byte and 8th byte from MSB side.This commit adds a series of specification flag to describe them. When
the existence flag is in the 5th byte, SND_MOTU_SPEC_[R|T]X_MIDI_2ND_Q is
used. Else, another set of the flag is used. Here, '_Q' means quadlet.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
20 Aug, 2017
1 commit
-
When failing sound card registration after initializing stream data, this
module leaves allocated data in stream data. This commit fixes the bug.Fixes: 9b2bb4f2f4a2 ('ALSA: firewire-motu: add stream management functionality')
Cc: # v4.12+
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
19 Aug, 2017
1 commit
-
snd_pcm_ops are not supposed to change at runtime. All functions
working with snd_pcm_ops provided by work with
const snd_pcm_ops. So mark the non-const structs as const.Signed-off-by: Arvind Yadav
Signed-off-by: Takashi Iwai
15 Aug, 2017
1 commit
-
These snd_rawmidi_ops structures are only passed as the third
argument of snd_rawmidi_set_ops. This argument is const, so the
snd_rawmidi_ops structures can be const too.Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
Reviewed-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
08 Jun, 2017
1 commit
-
In ALSA firewire stack, 8 drivers uses IEC 61883-1/6 engine for data
transmission. They have common PCM info/constraints and duplicated codes.This commit unifies the codes into fireiwre-lib.
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
07 Jun, 2017
1 commit
-
In recent commit for ALSA PCM core, some arrangement is done for
'struct snd_pcm_ops.ack' callback. This is called when appl_ptr is
explicitly moved in intermediate buffer for PCM frames, except for
some cases described later.For drivers in ALSA firewire stack, usage of this callback has a merit to
reduce latency between time of PCM frame queueing and handling actual
packets in recent isochronous cycle, because no need to wait for software
IRQ context from isochronous context of OHCI 1394.If this works well in a case that mapped page frame is used for the
intermediate buffer, user process should execute some commands for ioctl(2)
to tell the number of handled PCM frames in the intermediate buffer just
after handling them. Therefore, at present, with a combination of below
conditions, this doesn't work as expected and user process should wait for
the software IRQ context as usual:
- when ALSA PCM core judges page frame mapping is available for status
data (struct snd_pcm_mmap_status) and control data
(struct snd_pcm_mmap_control).
- user process handles PCM frames by loop just with 'snd_pcm_mmap_begin()'
and 'snd_pcm_mmap_commit()'.
- user process uses PCM hw plugin in alsa-lib to operate I/O without
'sync_ptr_ioctl' option.Unfortunately, major use case include these three conditions.
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
20 Apr, 2017
1 commit
-
Two functions were introduced for the purpose of tracing but cause warnings
when tracing is disabled:sound/firewire/motu/amdtp-motu.c:284:13: error: 'copy_message' defined but not used [-Werror=unused-function]
static void copy_message(u64 *frames, __be32 *buffer, unsigned int data_blocks,
sound/firewire/motu/amdtp-motu.c:271:13: error: 'copy_sph' defined but not used [-Werror=unused-function]
static void copy_sph(u32 *frames, __be32 *buffer, unsigned int data_blocks,Marking them as __maybe_unused will do the right thing here.
Fixes: 17909c1b3058 ("ALSA: firewire-motu: add tracepoints for SPH in IEC 61883-1 fashion")
Fixes: c6b0b9e65f09 ("ALSA: firewire-motu: add tracepoints for messages for unique protocol")
Signed-off-by: Arnd Bergmann
Signed-off-by: Takashi Iwai
11 Apr, 2017
2 commits
-
MOTU units transfer/receive messages in each data block of their
isochronous packet payload. A part of content in the message is cleard for
MIDI message transmission, while the rest is unknown yet. Additional
features are required to assist users and developers to reveal the
details.This commit adds tracepoints for the purpose. The tracepoints are designed
for MOTU's protocol version 2 and 3 (Protocol version 1 is not upstreamed
yet). In the tracepoints, events are probed to gather first two 24 bit
data chunks of each data block. The chunks are formatted into elements
of 64 bit array with padding in MSB.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
Unique protocol is used for MOTU FireWire series. In this protocol,
data block format is not compliant to AM824 in IEC 61883-1/6. Each of
the data block consists of 24 bit data chunks, except for a first
quadlet. The quadlet is used for source packet header (SPH) described
in IEC 61883-1.The sequence of SPH seems to represent presentation timestamp
corresponding to included data. Developers have experienced that invalid
sequence brings disorder of units in the series.Unfortunately, current implementation of ALSA IEC 61883-1/6 engine and
firewire-motu driver brings periodical noises to the units at sampling
transmission frequency based on 44.1 kHz. The engine generates the SPH with
even interval and this mechanism seems not to be suitable to the units.
Further work is required for this issue and infrastructure is preferable
to assist the work.This commit adds tracepoints for the purpose. In the tracepoints, events
are probed to gather the SPHs from each data blocks.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
06 Apr, 2017
1 commit
-
In protocol version 3, drivers can read current sampling clock status from
register 0x'ffff'f000'0b14. 8 bits of LSB of this register represents type
of signal as source of clock.Current driver code includes invalid bitshift to handle the parameter. This
commit fixes the bug.Reported-by: Dan Carpenter
Fixes: 5992e30034c4 ("ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3")
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai
28 Mar, 2017
6 commits
-
…th protocol version 3
MOTU 828mk3 (FireWire/Hybrid) is one of third generation in MOTU FireWire
series, produced in 2008/2014. This model consists of three chips for
functionality on IEEE 1394 bus:* TI TSB41AB2 (Physical layer for IEEE 1394 bus)
* Xilinx Spartan-3E FPGA Family (Link layer for IEEE 1394 bus, packet
processing and data block processing layer)
* TI TMS320C6722 (Digital signal processing)This commit adds a support for this model, with its unique protocol as
version 3. This protocol has some additional features to protocol
version 2.* Support several optical interfaces.
* Support a data chunk for return of reverb effect.
* Have a quirk of tx packets.
* Support heartbeat asynchronous transaction.In this protocol, series of transferred packets has some quirks. Below
fields in CIP headers of the packets are out of IEC 61883-1:
- SID (source node id): always 0x0d
- DBS (data block size): always 0x04
- DBC (data block counter): always 0x00
- EOH (End of header): always 0x00Below is an actual sample of transferred packets.
quads CIP1 CIP2
520 0x0D040400 0x22FFFFFF
8 0x0D040400 0x22FFFFFF
520 0x0D040400 0x22FFFFFF
520 0x0D040400 0x22FFFFFF
8 0x0D040400 0x22FFFFFFStatus of clock is configured by write transactions to 0x'ffff'f000'0b14,
as well as version 2, while meanings of fields are different from the
former protocols. Modes of optical interfaces are configured by write
transactions to 0x'ffff'f000'0c94.Drivers can register its address to receive heatbeat transactions from the
unit. 0x'ffff'f000'0b0c is for the higher part and 0x'ffff'f000'0b10 is
for the lower part. Nevertheless, this feature is not useless for this
driver and this commit omits it.Each data block consists of two parts in a point of the number of included
data chunks. In both of 'fixed' and 'differed' parts, the number of
included data blocks are a multiple of 4, thus depending on models there's
some empty data chunks. For example, 828mk3 includes one pair of empty
data chunks in its fixed part. When optical interface is configured to
S/PDIF, 828mk3 includes one pair of empty data chunks in its differed part.
To reduce consumption of CPU cycles with additional conditions/loops, this
commit just exposes these empty chunks to user space as PCM channels.Additionally, 828mk3 has a non-negligible overhead to change its sampling
transfer frequency. When softwares send asynchronous transaction to
perform it, LED on the unit starts to blink. In a worst case, it continues
blink during several seconds; e.g. 10 seconds. When stopping blinking,
the unit seems to be prepared for the requested sampling transfer
frequency. To wait for the preparation, this commit forces the driver
to call task scheduler and applications sleeps for 4 seconds.Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de> -
MOTU 828mk2 is one of second generation in MOTU FireWire series, produced in
2003. This model consists of four chips:
* TI TSB41AB2 (Physical layer for IEEE 1394 bus)
* PDI 1394L40BE (Link layer for IEEE 1394 bus and packet processing layer)
* ALTERA ACEX 1K EP1K30 Series FPGA (Data block processing layer)
* TI TMS320VC5402 (Digital signal processing)This commit adds a support for this model, with its unique protocol as
version 2. The features of this protocol are:* Support data chunks for status and control messages for both
directions.
* Support a pair of MIDI input/output.
* Support a data chunk for mic/instrument independent of analog line in.
* Support a data chunk for playback return.
* Support independent data chunks for S/PDIF of both optical/coaxial
interfaces.
* Support independent data chunks for each of main out and phone out.Status of clock is configured by write transactions to 0x'ffff'f000'0b14.
Modes of optical interfaces are configured by write transactions to
0x'ffff'f000'0c04.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
MOTU FireWire series can transfer messages to registered address. These
messages are transferred for the status of internal clock synchronization
just after starting streams.When the synchronization is stable, it's 0x01ffffff. Else, it's 0x05ffffff.
This commit adds a functionality for user space applications to receive
content of the message.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
This commit adds hwdep interface so as the other sound drivers for units
on IEEE 1394 bus have.This interface is designed for mixer/control applications. 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: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
In MOTU FireWire series, MIDI messages are multiplexed to isochronous
packets as well as PCM frames, while the way is different from the one
in IEC 61883-6.MIDI messages are put into a certain position in message chunks. One data
block can includes one byte of the MIDI messages. When data block includes
a MIDI byte, the block has a flag in a certain position of the message
chunk. These positions are unique depending on protocols.Once a data block includes a MIDI byte, some following data blocks includes
no MIDI bytes. Next MIDI byte appears on a data block corresponding to
next cycle of physical MIDI bus. This seems to avoid buffer overflow caused
by bandwidth differences between IEEE 1394 bus and physical MIDI bus.This commit adds MIDI functionality to transfer/receive MIDI messages.
Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai -
This commit adds PCM functionality to transmit/receive PCM samples.
When one of PCM substreams are running or external clock source is
selected, current sampling rate is used. Else, the sampling rate is
changed according to requests from a userspace application.Available number of samples in a frame of PCM substream is determined at
open(2) to corresponding PCM character device. Later, packet streaming
starts by ioctl(2) with SNDRV_PCM_IOCTL_PREPARE. In theory, between them,
applications can change state of the unit by any write transaction to
change the number. In this case, this driver may fail packet streaming due
to wrong data format.Signed-off-by: Takashi Sakamoto
Signed-off-by: Takashi Iwai