openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
857,575 Commits 18 Branches 27 Tags 3.4 GiB
Commit Graph

12 Commits

Author SHA1 Message Date
Greg Kroah-Hartman b24413180f License cleanup: add SPDX GPL-2.0 license identifier to files with no license 
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 <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 2017-11-02 11:10:55 +01:00
Takashi Sakamoto 17909c1b30 ALSA: firewire-motu: add tracepoints for SPH in IEC 61883-1 fashion 
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-04-11 08:30:45 +02:00
Takashi Sakamoto 5992e30034 ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with 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 0x00

Below is an actual sample of transferred packets.

quads CIP1       CIP2
520   0x0D040400 0x22FFFFFF
  8   0x0D040400 0x22FFFFFF
520   0x0D040400 0x22FFFFFF
520   0x0D040400 0x22FFFFFF
  8   0x0D040400 0x22FFFFFF

Status 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>
 2017-03-28 12:34:13 +02:00
Takashi Sakamoto 949613e366 ALSA: firewire-motu: add support for MOTU 828mk2 as a model with protocol version 2 
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-03-28 12:34:08 +02:00
Takashi Sakamoto 71c3797779 ALSA: firewire-motu: add hwdep interface 
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>
 2017-03-28 12:34:02 +02:00
Takashi Sakamoto 9e796e7d59 ALSA: firewire-motu: add MIDI functionality 
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-03-28 12:33:56 +02:00
Takashi Sakamoto dd49b2d1f0 ALSA: firewire-motu: add PCM functionality 
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-03-28 12:33:53 +02:00
Takashi Sakamoto 4638ec6ede ALSA: firewire-motu: add proc node to show current statuc of clock and packet formats 
This commit adds a proc node for debugging purpose.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-03-28 12:33:51 +02:00
Takashi Sakamoto 9b2bb4f2f4 ALSA: firewire-motu: add stream management functionality 
This commit adds a functionality to manage packet streaming for MOTU
FireWire series.

The streaming is not controlled by CMP, thus against IEC 61883-1. Write
transaction to certain addresses start/stop packet streaming.

Transactions to 0x'ffff'f000'0b00 results in isochronous channel number for
both directions and starting/stopping transmission of packets. The
isochronous channel number is represented in 6 bit field, thus units can
identify the channels up to 64, as IEEE 1394 bus specification described.

Transactions to 0x'ffff'f000'0b10 results in packet format for both
directions and transmission speed. When each of data block includes fixed
part of data chunks only, corresponding flags stand.

When bus reset occurs, the units continue to transmit packets with
non-contiguous data block counter. This causes discontinuity detection in
packet streaming engine and ALSA PCM applications receives EPIPE from any
I/O operation. In this case, typical applications manage to recover
corresponding PCM substream. This behaviour is kicked much earlier than
callback of bus reset handler by Linux FireWire subsystem, therefore
status of packet streaming is not changed in the handler.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-03-28 12:33:34 +02:00
Takashi Sakamoto 2e76701bbb ALSA: firewire-motu: handle transactions specific for MOTU FireWire models 
All models of MOTU FireWire series can be controlled by write transaction
to addresses in a range from 0x'ffff'f0000'0b00 to 0x'ffff'f000'0cff.

The models support asynchronous notification. This notification has 32 bit
field data, and is transferred when status of clock changes. Meaning of
the value is not enough clear yet.

Drivers can register its address to receive the notification. Write
transaction to 0x'ffff'f000'0b04 registers higher 16 bits of the address.
Write transaction to 0x'ffff'f0000'0b08 registers the rest of bits. The
address includes node ID, thus it should be registered every time of bus
reset.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-03-28 12:33:32 +02:00
Takashi Sakamoto 4641c93940 ALSA: firewire-motu: add MOTU specific protocol layer 
MOTU FireWire series uses blocking transmission for AMDTP packet streaming.
They transmit/receive 8,000 packets per second, to handle the same number
of data blocks as current sampling transmission frequency. Thus,
IEC 61883-1/6 packet streaming engine of ALSA firewire stack is available
for them.

However, the sequence of packet and data blocks includes some quirks.
Below sample is a sequence of CIP headers of packets received by 828mk2,
at 44.1kHz of sampling transmission frequency.

quads CIP1        CIP2
488   0x020F04E8  0x8222FFFF
  8   0x020F04F8  0x8222FFFF
488   0x020F0400  0x8222FFFF
488   0x020F0408  0x8222FFFF
  8   0x020F04E8  0x8222FFFF
488   0x020F04F0  0x8222FFFF
488   0x020F04F8  0x8222FFFF

The SID (source node ID), DBS (data block size), SPH (source packet header),
FMT (format ID), FDF (format dependent field) and SYT (time stamp) fields
are in IEC 61883-1. Especially, FMT is 0x02, FDF is 0x22 and SYT is 0xffff
to define MOTU specific protocol. In an aspect of dbc field, the value
represents accumulated number of data blocks included the packet. This
is against IEC 61883-1, because according to the specification this value
should be the number of data blocks already transferred.

In ALSA IEC 61883-1/6 engine, this quirk is already supported by
CIP_DBC_IS_END_EVENT flag, because Echo Audio Fireworks has.

Each data block includes SPH as its first quadlet field, to represent its
presentation time stamp. Actual value of SPH is compliant to IEC 61883-1;
lower 25 bits of 32 bits width consists of 13 bits cycle count and 12 bits
cycle offset.

The rest of each data block consists of 24 bit chunks. All of PCM samples,
MIDI messages, status and control messages are transferred by the chunks.
This is similar to '24-bit * 4 Audio Pack' in IEC 61883-6. The position of
each kind of data depends on generations of each model. The number of
whole chunks in a data block is a multiple of 4, to consists of
quadlet-aligned packets.

This commit adds data block processing layer specific for the MOTU
protocol. The remarkable point is the way to generate SPH header. Time
stamps for each data blocks are generated by below calculation:

 * Using pre-computed table for the number of ticks per event
  *  44,1kHz: (557 + 123/441)
  *  48.0kHz: (512 +   0/441)
  *  88.2kHz: (278 + 282/441)
  *  96.0kHz: (256 +   0/441)
  * 176.4kHz: (139 + 141/441)
  * 192.0kHz: (128 +   0/441)
 * Accumulate the ticks and set the value to SPH for every events.
 * This way makes sense only for blocking transmission because this mode
   transfers fixed number or none of events.

This calculation assumes that each data block has a PCM frame which is
sampled according to event timing clock. Current packet streaming layer
has the same assumption.

Although this sequence works fine for MOTU FireWire series at sampling
transmission frequency based on 48.0kHz, it is not enough at the frequency
based on 44.1kHz. The units generate choppy noise every few seconds.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-03-28 12:33:30 +02:00
Takashi Sakamoto 6c3cef4890 ALSA: firewire-motu: add skeleton for Mark of the unicorn (MOTU) FireWire series 
This commit adds an new driver for MOTU FireWire series. In this commit,
this driver just creates/removes card instance according to bus event.
More functionalities will be added in following commits.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
 2017-03-28 12:33:16 +02:00