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>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, AM824 is described as format of data block. In this
format, one data block consists of several data channels, which is aligned
to 32 bit. One data channel has 8 bit label field and 24 bit data field.
PCM frames are transferred in Multi Bit Linear Audio (MBLA) data channel.
This channel can include 16/20/24 bit PCM sample.
As long as I know, models which support IEC 61883-1/6 doesn't allow to
switch bit length of PCM sample in MBLA data channel. They always
transmit/receive PCM frames of 24 bit length. This can be seen for the
other models which support protocols similar to IEC 61883-1/6.
On the other hand, current drivers for these protocols supports 16 bit
length PCM sample in playback substream. In this case, PCM sample is put
into the MBLA data channel with 8 bit padding in LSB side. Although 16
bit PCM sample is major because it's in CD format, this doesn't represent
device capability as is.
This commit removes support for 16 bit PCM samples in playback substream.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For digi00x series, asynchronous transaction is not used to transfer MIDI
messages to/from control surface. One of transction handlers in my previous
work loses its practical meaning.
This commit removes the handler. I note that unit of console type
transfers 0x00001000 to registered address of host space when switching
to 'standalone' mode. Then the unit generates bus reset.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At a commit c5fcee0373 ("ALSA: firewire-digi00x: add MIDI operations for
MIDI control port"), I described that MIDI messages for control surface is
transferred by a different way from the messages for physical ports.
However, this is wrong. MIDI messages to/from all of MIDI ports are
transferred by isochronous packets.
This commit removes codes to transfer MIDI messages via asynchronous
transaction, from MIDI handling layer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At a commit 9dc5d31cdc ("ALSA: firewire-digi00x: handle MIDI messages in
isochronous packets"), a functionality to handle MIDI messages on
isochronous packet was supported. But this includes some of my
misunderstanding. This commit is to fix them.
For digi00x series, first data channel of data blocks in rx/tx packet
includes MIDI messages. The data channel has 0x80 in 8 bit of its MSB,
however it's against IEC 61883-6. Unique data format is applied:
- Upper 4 bits of LSB represent port number.
- 0x0: port 1.
- 0x2: port 2.
- 0xe: console port.
- Lower 4 bits of LSB represent the number of included MIDI message bytes;
0x0/0x1/0x2.
- Two bytes of middle of this data channel have MIDI bytes.
Especially, MIDI messages from/to console surface are also transferred by
isochronous packets, as well as physical MIDI ports.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Digi00x series includes two types of unit; rack and console. As long as
reading information on config rom of Digi 002 console, 'MODEL_ID' field
has a different value from the one on Digi 002 rack.
We've already got a test report from users with Digi 003 rack. We can
assume that console type and rack type has different value in the field.
This commit adds a device entry for console type. For following commits,
this commit also adds a member to 'struct snd_digi00x' to identify console
type.
$ cd linux-firewire-utils/src
$ python2 ./crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400 0404f9d0 bus_info_length 4, crc_length 4, crc 63952
404 31333934 bus_name "1394"
408 60647002 irmc 0, cmc 1, isc 1, bmc 0, cyc_clk_acc 100, max_rec 7 (256)
40c 00a07e00 company_id 00a07e |
410 00a30000 device_id 0000a30000 | EUI-64 00a07e0000a30000
root directory
-----------------------------------------------------------------
414 00058a39 directory_length 5, crc 35385
418 0c0043a0 node capabilities
41c 04000001 hardware version
420 0300a07e vendor
424 81000007 --> descriptor leaf at 440
428 d1000001 --> unit directory at 42c
unit directory at 42c
-----------------------------------------------------------------
42c 00046674 directory_length 4, crc 26228
430 120000a3 specifier id
434 13000001 version
438 17000001 model
43c 81000007 --> descriptor leaf at 458
descriptor leaf at 440
-----------------------------------------------------------------
440 00055913 leaf_length 5, crc 22803
444 000050f2 descriptor_type 00, specifier_ID 50f2
448 80000000
44c 44696769
450 64657369
454 676e0000
descriptor leaf at 458
-----------------------------------------------------------------
458 0004a6fd leaf_length 4, crc 42749
45c 00000000 textual descriptor
460 00000000 minimal ASCII
464 44696769 "Digi"
468 20303032 " 002"
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix up affected files that include this signal functionality via sched.h.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Now snd_rawmidi_ops is maintained as a const pointer in snd_rawmidi,
we can constify the definitions.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some identifiers are referred just by one functions. In this case, they
can be put into the function definition. This brings two merits; readers
can easily follow codes related to the identifiers, developers are free
from name conflict.
This commit moves such identifiers to each function definition.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Check for snd_pcm_ops structures that are only stored in the ops field of a
snd_soc_platform_driver structure or passed as the third argument to
snd_pcm_set_ops. The corresponding field or parameter is declared const,
so snd_pcm_ops structures that have this property can be declared as const
also.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_pcm_ops i@p = { ... };
@ok1@
identifier r.i;
struct snd_soc_platform_driver e;
position p;
@@
e.ops = &i@p;
@ok2@
identifier r.i;
expression e1, e2;
position p;
@@
snd_pcm_set_ops(e1, e2, &i@p)
@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_pcm_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct snd_pcm_ops i = { ... };
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commit, drivers in ALSA firewire stack always starts IT context
before IR context. If IR context starts after packets are transmitted by
peer unit, packet discontinuity may be detected because the context starts
in the middle of packet streaming. This situation is rare because IT
context usually starts immediately. However, it's better to solve this
issue. This is suppressed with CIP_SKIP_INIT_DBC_CHECK flag.
This commit enables the same feature as CIP_SKIP_INIT_DBC_CHECK.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When some digi00x units are connected sequentially, userspace
applications are involved at bus-reset state on IEEE 1394 bus. In the
state, any communications can be canceled. Therefore, sound card
registration should be delayed till the bus gets calm.
This commit achieves it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/firewire/digi00x/amdtp-dot.c:67: warning: type qualifiers ignored on function return type
Drop the bogus "const" type qualifier on the return type of dot_scrt()
to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Digi 002/003 family uses two ways to transfer MIDI messages. They're
different mechanisms, while it's better to handle the ways in different
ALSA rawmidi character devices because one character device has just a
set of operations.
This commit adds another rawmidi character device for control MIDI port. As
a result, first rawmidi character device is just for MIDI messages
transferred by isochronous packets.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Digi 002/003 family has two types of MIDI port; one is for physical MIDI
port and another is for MIDI control message. The former is transferred in
isochronous packet, and the latter is transferred by asynchronous
transaction. These transmission mechanisms are completely different, while
current ALSA digi00x driver defines a set of operations for them with
several condition statements. As a result, codes for the operation are
messy.
This commit adds a set of MIDI operation for control MIDI ports. In later
commit, it's applied as an operation for ALSA rawmidi character device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In following commit, new functions and variables are added for operations
of MIDI control port.
This commit is a preparation. Current identifiers are renamed so that they
mean physical MIDI ports.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The contents of Config ROM in firewire device structure are already
aligned to CPU-endianness. Thus, no need to convert it again.
This commit removes needless conversions
Fixes: 9edf723fd858('ALSA: firewire-digi00x: add skeleton for Digi 002/003 family')
Fixes: c0949b278515('ALSA: firewire-tascam: add skeleton for TASCAM FireWire series')
Reported-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commits, asynchronous transactions are supported for physical
controls. This commit adds a pair of MIDI ports for them.
This driver already adds diferrent number of ALSA MIDI ports for physical
MIDI ports, and the number of in/out ports are different. As seeing as
'amidi' program in alsa-utils package, a pair of in/out MIDI ports is
expected with the same name. Therefore, this commit adds a pair of new
ports to the first.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, asynchronous transaction for incoming MIDI messages
from physical controls is supported. The physical controls may be
controlled by receiving MIDI messages at a certain address.
This commit supports asynchronous transaction for this purpose.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Digi 00x series has two types of model; rack and console. The console
models have physical controls. The model can transmit control messages.
These control messages are transferred by asynchronous transactions to
registered address.
This commit supports the asynchronous transaction.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds MIDI functionality to capture/playback MIDI messages
from/to physical MIDI ports. These messages are transferred in isochronous
packets.
When no substreams request AMDTP streams to run, this driver starts the
streams at current sampling rate. When other substreams start at different
sampling rate, the streams are stopped temporarily, then start again at
requested sampling rate. This operation can generate missing MIDI bytes,
thus it's preferable to start PCM substreams at favorite sampling rate in
advance.
Digi 002/003 console also has a set of MIDI port for physical controls.
These ports are added in later commits.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In Digi 002/003 protocol, MIDI messages are transferred in the last data
channel of data blocks. Although this data channel has a label of 0x80,
it's not fully MIDI conformant data channel especially because the Counter
field always zero independently of included MIDI bytes. The 4th byte of
the data channel in LSB tells the number of included MIDI bytes. This byte
also includes the number of MIDI port. Therefore, the data format in this
data channel is:
* 1st: 0x80 as label
* 2nd: MIDI bytes
* 3rd: 0 or MIDI bytes
* 4th: the number of MIDI byte and the number of MIDI port
This commit adds support of MIDI messages in data block processing layer.
Like AM824 data format, this data channel has a capability to transfer
more MIDI messages than the capability of phisical MIDI bus. Therefore, a
throttle for data rate is required to prevent devices' internal buffer to
overflow.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Original code for 'DoubleOhThree' encoding was written with '__u8' type,
while the type is usually used to export something to userspace.
This commit replaces the type with 'u8'.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Digi 002/003 family uses asynchronous transaction for messaging.
The address to transmit this message is stored on a certain register.
This commit allocates a range of address on OHCI 1394 host controller
to handle the messaging. As long as I know, the purpose of this message
seems to notify lost of synchronization. While, the meaning of content
of the message is not clear.
Actual examples of this messaging:
* When clock source is set as internal:
- 0x00007051
- 0x00007052
- 0x00007054
- 0x00007057
- 0x00007058
* When clock source is set as somewhat external:
- 0x00009000
- 0x00009010
- 0x00009020
- 0x00009021
- 0x00009022
The lost often occurs when using internal clock source. In this case,
users hear sounds with quite short gap every several minutes. In fact,
the lost is recovered temporarily.
When using with external clock source, the lost seems not to occur. The
mechanism is not clear yet.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds PCM functionality to transmit/receive PCM samples.
Any PCM substreams are jointed because incoming/outgoing AMDTP streams
are bound. When one of PCM substream is running or external clock source
is selected, current sampling rate is used. Else, the sampling rate is
changed as an userspace application requests.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds proc node to show current clock status for debugging.
As long as testing Digi 002 rack, registers can show local clock rate,
local clock source. When external clock input such as S/PDIF is
connected, the registers show the detection and external clock rate.
Additionally, the registers show the mode of optical digital input
interface. Although, a tester with Digi 003 rack reports this makes no
sense. Further investigation is required for Digi 003 series.
Besides, in Digi 002 rack, the S/PDIF format must be IEC 60958-4,
so-called professional.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds a functionality to manage streaming.
The streaming is not controlled by CMP in IEC 61883-6. It's controlled by
IEEE 1394 write transaction to certain addresses.
Several clock sources are available, while there're no differences about
packet transmission. The value of SYT field in transmitted packets is
always zero. Thus, streams in both direction don't build synchronization.
And the device always requires received packets to transmit packets. This
driver keeps to transfer outgoing stream even if they're not required.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Digi 002/003 family uses its own format for data blocks. The format is
quite similar to AM824 in IEC 61883-6, while there're some differences:
* The Valid Bit Length (VBL) code is always 0x40 in Multi-bit Linear Audio
(MBLA) data channel.
* The first data channel includes MIDI messages, against IEC 61883-6
recommendation.
* The Counter field is always zero in MIDI conformant data channel.
* Sequence multiplexing in IEC 61883-6 is not applied to the MIDI
conformant data channel.
* PCM samples are scrambled in received AMDTP packets. We call the way
as Double-Oh-Three (DOT). The algorithm was discovered by
Robin Gareus and Damien Zammit in 2012.
This commit adds data processing layer to satisfy these differences.
There's a quirk about transmission mode for received packets. When this
driver applies non-blocking mode to outgoing packets with isochronous
channel 2 or more, after 15 to 20 seconds since playbacking, any PCM
samples causes noisy sound on the device. With isochronous channel 0 or 1,
this doesn't occur. As long as I investigated, this quirk is not observed
when applying blocking mode to the received packets.
This driver applies blocking mode to outgoing packets, while non-blocking
mode to incoming packgets.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds a new driver for Digidesign 002/003 family. This commit
just creates/removes card instance according to bus event. More functions
will be added in following commits.
Digidesign 002/003 family consists of:
* Agere FW802B for IEEE 1394 PHY layer
* PDI 1394L40 for IEEE 1394 LINK layer and IEC 61883 interface
* ALTERA ACEX EP1K50 for IEC 61883 layer and DSP controller
* ADSP-21065L for signal processing
[minor cleanup using skip_spaces() by tiwai]
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
