mirror of
https://github.com/t2linux/kernel.git
synced 2026-04-30 13:48:59 -07:00
Merge branch 'locking/rwsem'
This commit is contained in:
@@ -82,7 +82,10 @@ Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@gmail.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@imgtec.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@mips.com>
|
||||
<dev.kurt@vandijck-laurijssen.be> <kurt.van.dijck@eia.be>
|
||||
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <[dbaryshkov@gmail.com]>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_baryshkov@mentor.com>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_eremin@mentor.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <dima@arista.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
|
||||
@@ -287,6 +290,7 @@ Santosh Shilimkar <ssantosh@kernel.org>
|
||||
Sarangdhar Joshi <spjoshi@codeaurora.org>
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
S.Çağlar Onur <caglar@pardus.org.tr>
|
||||
Sean Christopherson <seanjc@google.com> <sean.j.christopherson@intel.com>
|
||||
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
|
||||
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
|
||||
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
|
||||
|
||||
@@ -98,7 +98,7 @@ N: Erik Andersen
|
||||
E: andersen@codepoet.org
|
||||
W: https://www.codepoet.org/
|
||||
P: 1024D/30D39057 1BC4 2742 E885 E4DE 9301 0C82 5F9B 643E 30D3 9057
|
||||
D: Maintainer of ide-cd and Uniform CD-ROM driver,
|
||||
D: Maintainer of ide-cd and Uniform CD-ROM driver,
|
||||
D: ATAPI CD-Changer support, Major 2.1.x CD-ROM update.
|
||||
S: 352 North 525 East
|
||||
S: Springville, Utah 84663
|
||||
@@ -263,7 +263,7 @@ N: Paul Barton-Davis
|
||||
E: pbd@op.net
|
||||
D: Driver for WaveFront soundcards (Turtle Beach Maui, Tropez, Tropez+)
|
||||
D: Various bugfixes and changes to sound drivers
|
||||
S: USA
|
||||
S: USA
|
||||
|
||||
N: Carlos Henrique Bauer
|
||||
E: chbauer@acm.org
|
||||
@@ -849,6 +849,12 @@ D: trivial hack to add variable address length routing to Rose.
|
||||
D: AX25-HOWTO, HAM-HOWTO, IPX-HOWTO, NET-2-HOWTO
|
||||
D: ax25-utils maintainer.
|
||||
|
||||
N: Kamil Debski
|
||||
E: kamil@wypas.org
|
||||
D: Samsung S5P 2D graphics acceleration and Multi Format Codec drivers
|
||||
D: Samsung USB2 phy drivers
|
||||
D: PWM fan driver
|
||||
|
||||
N: Helge Deller
|
||||
E: deller@gmx.de
|
||||
W: http://www.parisc-linux.org/
|
||||
@@ -1199,7 +1205,7 @@ N: Daniel J. Frasnelli
|
||||
E: dfrasnel@alphalinux.org
|
||||
W: http://www.alphalinux.org/
|
||||
P: 1024/3EF87611 B9 F1 44 50 D3 E8 C2 80 DA E5 55 AA 56 7C 42 DA
|
||||
D: DEC Alpha hacker
|
||||
D: DEC Alpha hacker
|
||||
D: Miscellaneous bug squisher
|
||||
|
||||
N: Jim Freeman
|
||||
@@ -1299,7 +1305,7 @@ S: P.O. Box 76, Epping
|
||||
S: New South Wales, 2121
|
||||
S: Australia
|
||||
|
||||
N: Carlos E. Gorges
|
||||
N: Carlos E. Gorges
|
||||
E: carlos@techlinux.com.br
|
||||
D: fix smp support on cmpci driver
|
||||
P: 2048G/EA3C4B19 FF31 33A6 0362 4915 B7EB E541 17D0 0379 EA3C 4B19
|
||||
@@ -1340,7 +1346,7 @@ E: wgreathouse@smva.com
|
||||
E: wgreathouse@myfavoritei.com
|
||||
D: Current Belkin USB Serial Adapter F5U103 hacker
|
||||
D: Kernel hacker, embedded systems
|
||||
S: 7802 Fitzwater Road
|
||||
S: 7802 Fitzwater Road
|
||||
S: Brecksville, OH 44141-1334
|
||||
S: USA
|
||||
|
||||
@@ -1381,7 +1387,7 @@ N: Grant Guenther
|
||||
E: grant@torque.net
|
||||
W: http://www.torque.net/linux-pp.html
|
||||
D: original author of ppa driver for parallel port ZIP drive
|
||||
D: original architect of the parallel-port sharing scheme
|
||||
D: original architect of the parallel-port sharing scheme
|
||||
D: PARIDE subsystem: drivers for parallel port IDE & ATAPI devices
|
||||
S: 44 St. Joseph Street, Suite 506
|
||||
S: Toronto, Ontario, M4Y 2W4
|
||||
@@ -1523,7 +1529,7 @@ N: Benjamin Herrenschmidt
|
||||
E: benh@kernel.crashing.org
|
||||
D: Various parts of PPC/PPC64 & PowerMac
|
||||
S: 312/107 Canberra Avenue
|
||||
S: Griffith, ACT 2603
|
||||
S: Griffith, ACT 2603
|
||||
S: Australia
|
||||
|
||||
N: Andreas Herrmann
|
||||
@@ -1825,7 +1831,7 @@ S: Hungary
|
||||
N: Bernhard Kaindl
|
||||
E: bkaindl@netway.at
|
||||
E: edv@bartelt.via.at
|
||||
D: Author of a menu based configuration tool, kmenu, which
|
||||
D: Author of a menu based configuration tool, kmenu, which
|
||||
D: is the predecessor of 'make menuconfig' and 'make xconfig'.
|
||||
D: digiboard driver update(modularisation work and 2.1.x upd)
|
||||
S: Tallak 95
|
||||
@@ -2016,7 +2022,7 @@ W: http://www.xos.nl/
|
||||
D: IP transparent proxy support
|
||||
S: X/OS Experts in Open Systems BV
|
||||
S: Kruislaan 419
|
||||
S: 1098 VA Amsterdam
|
||||
S: 1098 VA Amsterdam
|
||||
S: The Netherlands
|
||||
|
||||
N: Goran Koruga
|
||||
@@ -2088,7 +2094,7 @@ S: Germany
|
||||
|
||||
N: Andrzej M. Krzysztofowicz
|
||||
E: ankry@mif.pg.gda.pl
|
||||
D: Some 8-bit XT disk driver and devfs hacking
|
||||
D: Some 8-bit XT disk driver and devfs hacking
|
||||
D: Aladdin 1533/1543(C) chipset IDE
|
||||
D: PIIX chipset IDE
|
||||
S: ul. Matemblewska 1B/10
|
||||
@@ -2463,7 +2469,7 @@ E: mge@EZ-Darmstadt.Telekom.de
|
||||
D: Logical Volume Manager
|
||||
S: Bartningstr. 12
|
||||
S: 64289 Darmstadt
|
||||
S: Germany
|
||||
S: Germany
|
||||
|
||||
N: Mark W. McClelland
|
||||
E: mmcclell@bigfoot.com
|
||||
@@ -2547,7 +2553,7 @@ E: meskes@debian.org
|
||||
P: 1024/04B6E8F5 6C 77 33 CA CC D6 22 03 AB AB 15 A3 AE AD 39 7D
|
||||
D: Kernel hacker. PostgreSQL hacker. Software watchdog daemon.
|
||||
D: Maintainer of several Debian packages
|
||||
S: Th.-Heuss-Str. 61
|
||||
S: Th.-Heuss-Str. 61
|
||||
S: D-41812 Erkelenz
|
||||
S: Germany
|
||||
|
||||
@@ -2785,7 +2791,7 @@ E: neuffer@goofy.zdv.uni-mainz.de
|
||||
W: http://www.i-Connect.Net/~mike/
|
||||
D: Developer and maintainer of the EATA-DMA SCSI driver
|
||||
D: Co-developer EATA-PIO SCSI driver
|
||||
D: /proc/scsi and assorted other snippets
|
||||
D: /proc/scsi and assorted other snippets
|
||||
S: Zum Schiersteiner Grund 2
|
||||
S: 55127 Mainz
|
||||
S: Germany
|
||||
@@ -2852,6 +2858,10 @@ D: IPX development and support
|
||||
N: Venkatesh Pallipadi (Venki)
|
||||
D: x86/HPET
|
||||
|
||||
N: Kyungmin Park
|
||||
E: kyungmin.park@samsung.com
|
||||
D: Samsung S5Pv210 and Exynos4210 mobile platforms
|
||||
|
||||
N: David Parsons
|
||||
E: orc@pell.chi.il.us
|
||||
D: improved memory detection code.
|
||||
@@ -3019,7 +3029,7 @@ D: Embedded PowerPC 4xx/6xx/7xx/74xx support
|
||||
S: Chandler, Arizona 85249
|
||||
S: USA
|
||||
|
||||
N: Frederic Potter
|
||||
N: Frederic Potter
|
||||
E: fpotter@cirpack.com
|
||||
D: Some PCI kernel support
|
||||
|
||||
@@ -3452,21 +3462,21 @@ S: Klosterweg 28 / i309
|
||||
S: 76131 Karlsruhe
|
||||
S: Germany
|
||||
|
||||
N: James Simmons
|
||||
N: James Simmons
|
||||
E: jsimmons@infradead.org
|
||||
E: jsimmons@users.sf.net
|
||||
E: jsimmons@users.sf.net
|
||||
D: Frame buffer device maintainer
|
||||
D: input layer development
|
||||
D: tty/console layer
|
||||
D: various mipsel devices
|
||||
S: 115 Carmel Avenue
|
||||
D: various mipsel devices
|
||||
S: 115 Carmel Avenue
|
||||
S: El Cerrito CA 94530
|
||||
S: USA
|
||||
S: USA
|
||||
|
||||
N: Jaspreet Singh
|
||||
E: jaspreet@sangoma.com
|
||||
W: www.sangoma.com
|
||||
D: WANPIPE drivers & API Support for Sangoma S508/FT1 cards
|
||||
D: WANPIPE drivers & API Support for Sangoma S508/FT1 cards
|
||||
S: Sangoma Technologies Inc.,
|
||||
S: 1001 Denison Street
|
||||
S: Suite 101
|
||||
@@ -3490,7 +3500,7 @@ N: Craig Small
|
||||
E: csmall@triode.apana.org.au
|
||||
E: vk2xlz@gonzo.vk2xlz.ampr.org (packet radio)
|
||||
D: Gracilis PackeTwin device driver
|
||||
D: RSPF daemon
|
||||
D: RSPF daemon
|
||||
S: 10 Stockalls Place
|
||||
S: Minto, NSW, 2566
|
||||
S: Australia
|
||||
@@ -3700,7 +3710,7 @@ N: Tsu-Sheng Tsao
|
||||
E: tsusheng@scf.usc.edu
|
||||
D: IGMP(Internet Group Management Protocol) version 2
|
||||
S: 2F 14 ALY 31 LN 166 SEC 1 SHIH-PEI RD
|
||||
S: Taipei
|
||||
S: Taipei
|
||||
S: Taiwan 112
|
||||
S: Republic of China
|
||||
S: 24335 Delta Drive
|
||||
@@ -3861,7 +3871,7 @@ D: Produced the Slackware distribution, updated the SVGAlib
|
||||
D: patches for ghostscript, worked on color 'ls', etc.
|
||||
S: 301 15th Street S.
|
||||
S: Moorhead, Minnesota 56560
|
||||
S: USA
|
||||
S: USA
|
||||
|
||||
N: Jos Vos
|
||||
E: jos@xos.nl
|
||||
@@ -3869,7 +3879,7 @@ W: http://www.xos.nl/
|
||||
D: Various IP firewall updates, ipfwadm
|
||||
S: X/OS Experts in Open Systems BV
|
||||
S: Kruislaan 419
|
||||
S: 1098 VA Amsterdam
|
||||
S: 1098 VA Amsterdam
|
||||
S: The Netherlands
|
||||
|
||||
N: Jeroen Vreeken
|
||||
@@ -4107,7 +4117,7 @@ S: People's Repulic of China
|
||||
N: Victor Yodaiken
|
||||
E: yodaiken@fsmlabs.com
|
||||
D: RTLinux (RealTime Linux)
|
||||
S: POB 1822
|
||||
S: POB 1822
|
||||
S: Socorro NM, 87801
|
||||
S: USA
|
||||
|
||||
@@ -4205,7 +4215,7 @@ D: EISA/sysfs subsystem
|
||||
S: France
|
||||
|
||||
# Don't add your name here, unless you really _are_ after Marc
|
||||
# alphabetically. Leonard used to be very proud of being the
|
||||
# alphabetically. Leonard used to be very proud of being the
|
||||
# last entry, and he'll get positively pissed if he can't even
|
||||
# be second-to-last. (and this file really _is_ supposed to be
|
||||
# in alphabetic order)
|
||||
|
||||
@@ -109,30 +109,6 @@ Description:
|
||||
When counting down the counter start from preset value
|
||||
and fire event when reach 0.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
|
||||
KernelVersion: 4.12
|
||||
Contact: benjamin.gaignard@st.com
|
||||
Description:
|
||||
Reading returns the list possible quadrature modes.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
|
||||
KernelVersion: 4.12
|
||||
Contact: benjamin.gaignard@st.com
|
||||
Description:
|
||||
Configure the device counter quadrature modes:
|
||||
|
||||
channel_A:
|
||||
Encoder A input servers as the count input and B as
|
||||
the UP/DOWN direction control input.
|
||||
|
||||
channel_B:
|
||||
Encoder B input serves as the count input and A as
|
||||
the UP/DOWN direction control input.
|
||||
|
||||
quadrature:
|
||||
Encoder A and B inputs are mixed to get direction
|
||||
and count with a scale of 0.25.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_count_enable_mode_available
|
||||
KernelVersion: 4.12
|
||||
Contact: benjamin.gaignard@st.com
|
||||
|
||||
@@ -137,15 +137,24 @@ Boot Kernel With a Boot Config
|
||||
==============================
|
||||
|
||||
Since the boot configuration file is loaded with initrd, it will be added
|
||||
to the end of the initrd (initramfs) image file with size, checksum and
|
||||
12-byte magic word as below.
|
||||
to the end of the initrd (initramfs) image file with padding, size,
|
||||
checksum and 12-byte magic word as below.
|
||||
|
||||
[initrd][bootconfig][size(u32)][checksum(u32)][#BOOTCONFIG\n]
|
||||
[initrd][bootconfig][padding][size(le32)][checksum(le32)][#BOOTCONFIG\n]
|
||||
|
||||
The size and checksum fields are unsigned 32bit little endian value.
|
||||
|
||||
When the boot configuration is added to the initrd image, the total
|
||||
file size is aligned to 4 bytes. To fill the gap, null characters
|
||||
(``\0``) will be added. Thus the ``size`` is the length of the bootconfig
|
||||
file + padding bytes.
|
||||
|
||||
The Linux kernel decodes the last part of the initrd image in memory to
|
||||
get the boot configuration data.
|
||||
Because of this "piggyback" method, there is no need to change or
|
||||
update the boot loader and the kernel image itself.
|
||||
update the boot loader and the kernel image itself as long as the boot
|
||||
loader passes the correct initrd file size. If by any chance, the boot
|
||||
loader passes a longer size, the kernel feils to find the bootconfig data.
|
||||
|
||||
To do this operation, Linux kernel provides "bootconfig" command under
|
||||
tools/bootconfig, which allows admin to apply or delete the config file
|
||||
@@ -176,7 +185,8 @@ up to 512 key-value pairs. If keys contains 3 words in average, it can
|
||||
contain 256 key-value pairs. In most cases, the number of config items
|
||||
will be under 100 entries and smaller than 8KB, so it would be enough.
|
||||
If the node number exceeds 1024, parser returns an error even if the file
|
||||
size is smaller than 32KB.
|
||||
size is smaller than 32KB. (Note that this maximum size is not including
|
||||
the padding null characters.)
|
||||
Anyway, since bootconfig command verifies it when appending a boot config
|
||||
to initrd image, user can notice it before boot.
|
||||
|
||||
|
||||
@@ -2858,6 +2858,8 @@
|
||||
mds=off [X86]
|
||||
tsx_async_abort=off [X86]
|
||||
kvm.nx_huge_pages=off [X86]
|
||||
no_entry_flush [PPC]
|
||||
no_uaccess_flush [PPC]
|
||||
|
||||
Exceptions:
|
||||
This does not have any effect on
|
||||
@@ -3186,6 +3188,8 @@
|
||||
|
||||
noefi Disable EFI runtime services support.
|
||||
|
||||
no_entry_flush [PPC] Don't flush the L1-D cache when entering the kernel.
|
||||
|
||||
noexec [IA-64]
|
||||
|
||||
noexec [X86]
|
||||
@@ -3235,6 +3239,9 @@
|
||||
nospec_store_bypass_disable
|
||||
[HW] Disable all mitigations for the Speculative Store Bypass vulnerability
|
||||
|
||||
no_uaccess_flush
|
||||
[PPC] Don't flush the L1-D cache after accessing user data.
|
||||
|
||||
noxsave [BUGS=X86] Disables x86 extended register state save
|
||||
and restore using xsave. The kernel will fallback to
|
||||
enabling legacy floating-point and sse state.
|
||||
|
||||
@@ -90,7 +90,7 @@ things to try.
|
||||
re-run kunit_tool.
|
||||
5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This
|
||||
may help clean up any residual config items which could be causing problems.
|
||||
6. Finally, try running KUnit outside UML. KUnit and KUnit tests can run be
|
||||
6. Finally, try running KUnit outside UML. KUnit and KUnit tests can be
|
||||
built into any kernel, or can be built as a module and loaded at runtime.
|
||||
Doing so should allow you to determine if UML is causing the issue you're
|
||||
seeing. When tests are built-in, they will execute when the kernel boots, and
|
||||
|
||||
@@ -175,17 +175,17 @@ An example Kconfig entry:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
config FOO_KUNIT_TEST
|
||||
tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
|
||||
depends on KUNIT
|
||||
default KUNIT_ALL_TESTS
|
||||
help
|
||||
This builds unit tests for foo.
|
||||
config FOO_KUNIT_TEST
|
||||
tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
|
||||
depends on KUNIT
|
||||
default KUNIT_ALL_TESTS
|
||||
help
|
||||
This builds unit tests for foo.
|
||||
|
||||
For more information on KUnit and unit tests in general, please refer
|
||||
to the KUnit documentation in Documentation/dev-tools/kunit
|
||||
For more information on KUnit and unit tests in general, please refer
|
||||
to the KUnit documentation in Documentation/dev-tools/kunit/.
|
||||
|
||||
If unsure, say N
|
||||
If unsure, say N.
|
||||
|
||||
|
||||
Test File and Module Names
|
||||
|
||||
@@ -92,7 +92,7 @@ behavior of a function called ``add``; the first parameter is always of type
|
||||
the second parameter, in this case, is what the value is expected to be; the
|
||||
last value is what the value actually is. If ``add`` passes all of these
|
||||
expectations, the test case, ``add_test_basic`` will pass; if any one of these
|
||||
expectations fail, the test case will fail.
|
||||
expectations fails, the test case will fail.
|
||||
|
||||
It is important to understand that a test case *fails* when any expectation is
|
||||
violated; however, the test will continue running, potentially trying other
|
||||
@@ -202,7 +202,7 @@ Example:
|
||||
kunit_test_suite(example_test_suite);
|
||||
|
||||
In the above example the test suite, ``example_test_suite``, would run the test
|
||||
cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``,
|
||||
cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``;
|
||||
each would have ``example_test_init`` called immediately before it and would
|
||||
have ``example_test_exit`` called immediately after it.
|
||||
``kunit_test_suite(example_test_suite)`` registers the test suite with the
|
||||
@@ -229,7 +229,7 @@ through some sort of indirection where a function is exposed as part of an API
|
||||
such that the definition of that function can be changed without affecting the
|
||||
rest of the code base. In the kernel this primarily comes from two constructs,
|
||||
classes, structs that contain function pointers that are provided by the
|
||||
implementer, and architecture specific functions which have definitions selected
|
||||
implementer, and architecture-specific functions which have definitions selected
|
||||
at compile time.
|
||||
|
||||
Classes
|
||||
@@ -459,7 +459,7 @@ KUnit on non-UML architectures
|
||||
By default KUnit uses UML as a way to provide dependencies for code under test.
|
||||
Under most circumstances KUnit's usage of UML should be treated as an
|
||||
implementation detail of how KUnit works under the hood. Nevertheless, there
|
||||
are instances where being able to run architecture specific code or test
|
||||
are instances where being able to run architecture-specific code or test
|
||||
against real hardware is desirable. For these reasons KUnit supports running on
|
||||
other architectures.
|
||||
|
||||
@@ -599,7 +599,7 @@ writing normal KUnit tests. One special caveat is that you have to reset
|
||||
hardware state in between test cases; if this is not possible, you may only be
|
||||
able to run one test case per invocation.
|
||||
|
||||
.. TODO(brendanhiggins@google.com): Add an actual example of an architecture
|
||||
.. TODO(brendanhiggins@google.com): Add an actual example of an architecture-
|
||||
dependent KUnit test.
|
||||
|
||||
KUnit debugfs representation
|
||||
|
||||
@@ -57,7 +57,7 @@ examples:
|
||||
};
|
||||
|
||||
can@53fc8000 {
|
||||
compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
|
||||
compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
|
||||
reg = <0x53fc8000 0x4000>;
|
||||
interrupts = <82>;
|
||||
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
|
||||
|
||||
@@ -76,6 +76,12 @@ properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
wifi-2.4ghz-coexistence:
|
||||
type: boolean
|
||||
description: >
|
||||
Should the pixel frequencies in the WiFi frequencies range be
|
||||
avoided?
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -20,14 +20,17 @@ properties:
|
||||
- fsl,imx8qm-flexcan
|
||||
- fsl,imx8mp-flexcan
|
||||
- fsl,imx6q-flexcan
|
||||
- fsl,imx53-flexcan
|
||||
- fsl,imx35-flexcan
|
||||
- fsl,imx28-flexcan
|
||||
- fsl,imx25-flexcan
|
||||
- fsl,p1010-flexcan
|
||||
- fsl,vf610-flexcan
|
||||
- fsl,ls1021ar2-flexcan
|
||||
- fsl,lx2160ar1-flexcan
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx53-flexcan
|
||||
- fsl,imx35-flexcan
|
||||
- const: fsl,imx25-flexcan
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx7d-flexcan
|
||||
@@ -81,11 +84,12 @@ properties:
|
||||
req_bit is the bit offset of CAN stop request.
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
items:
|
||||
- description: The 'gpr' is the phandle to general purpose register node.
|
||||
- description: The 'req_gpr' is the gpr register offset of CAN stop request.
|
||||
maximum: 0xff
|
||||
- description: The 'req_bit' is the bit offset of CAN stop request.
|
||||
maximum: 0x1f
|
||||
items:
|
||||
- description: The 'gpr' is the phandle to general purpose register node.
|
||||
- description: The 'req_gpr' is the gpr register offset of CAN stop request.
|
||||
maximum: 0xff
|
||||
- description: The 'req_bit' is the bit offset of CAN stop request.
|
||||
maximum: 0x1f
|
||||
|
||||
fsl,clk-source:
|
||||
description: |
|
||||
|
||||
@@ -8,10 +8,16 @@ Required properties:
|
||||
|
||||
- reg : The I2C address of the device.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- realtek,power-up-delay-ms
|
||||
Set a delay time for flush work to be completed,
|
||||
this value is adjustable depending on platform.
|
||||
|
||||
Example:
|
||||
|
||||
rt1015: codec@28 {
|
||||
compatible = "realtek,rt1015";
|
||||
reg = <0x28>;
|
||||
realtek,power-up-delay-ms = <50>;
|
||||
};
|
||||
|
||||
@@ -149,11 +149,11 @@ vidtv_psi.[ch]
|
||||
Because the generator is implemented in a separate file, it can be
|
||||
reused elsewhere in the media subsystem.
|
||||
|
||||
Currently vidtv supports working with 3 PSI tables: PAT, PMT and
|
||||
SDT.
|
||||
Currently vidtv supports working with 5 PSI tables: PAT, PMT,
|
||||
SDT, NIT and EIT.
|
||||
|
||||
The specification for PAT and PMT can be found in *ISO 13818-1:
|
||||
Systems*, while the specification for the SDT can be found in *ETSI
|
||||
Systems*, while the specification for the SDT, NIT, EIT can be found in *ETSI
|
||||
EN 300 468: Specification for Service Information (SI) in DVB
|
||||
systems*.
|
||||
|
||||
@@ -197,6 +197,8 @@ vidtv_channel.[ch]
|
||||
|
||||
#. Their programs will be concatenated to populate the PAT
|
||||
|
||||
#. Their events will be concatenated to populate the EIT
|
||||
|
||||
#. For each program in the PAT, a PMT section will be created
|
||||
|
||||
#. The PMT section for a channel will be assigned its streams.
|
||||
@@ -256,6 +258,42 @@ Using dvb-fe-tool
|
||||
The first step to check whether the demod loaded successfully is to run::
|
||||
|
||||
$ dvb-fe-tool
|
||||
Device Dummy demod for DVB-T/T2/C/S/S2 (/dev/dvb/adapter0/frontend0) capabilities:
|
||||
CAN_FEC_1_2
|
||||
CAN_FEC_2_3
|
||||
CAN_FEC_3_4
|
||||
CAN_FEC_4_5
|
||||
CAN_FEC_5_6
|
||||
CAN_FEC_6_7
|
||||
CAN_FEC_7_8
|
||||
CAN_FEC_8_9
|
||||
CAN_FEC_AUTO
|
||||
CAN_GUARD_INTERVAL_AUTO
|
||||
CAN_HIERARCHY_AUTO
|
||||
CAN_INVERSION_AUTO
|
||||
CAN_QAM_16
|
||||
CAN_QAM_32
|
||||
CAN_QAM_64
|
||||
CAN_QAM_128
|
||||
CAN_QAM_256
|
||||
CAN_QAM_AUTO
|
||||
CAN_QPSK
|
||||
CAN_TRANSMISSION_MODE_AUTO
|
||||
DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
|
||||
Supported delivery systems:
|
||||
DVBT
|
||||
DVBT2
|
||||
[DVBC/ANNEX_A]
|
||||
DVBS
|
||||
DVBS2
|
||||
Frequency range for the current standard:
|
||||
From: 51.0 MHz
|
||||
To: 2.15 GHz
|
||||
Step: 62.5 kHz
|
||||
Tolerance: 29.5 MHz
|
||||
Symbol rate ranges for the current standard:
|
||||
From: 1.00 MBauds
|
||||
To: 45.0 MBauds
|
||||
|
||||
This should return what is currently set up at the demod struct, i.e.::
|
||||
|
||||
@@ -314,7 +352,7 @@ For this, one should provide a configuration file known as a 'scan file',
|
||||
here's an example::
|
||||
|
||||
[Channel]
|
||||
FREQUENCY = 330000000
|
||||
FREQUENCY = 474000000
|
||||
MODULATION = QAM/AUTO
|
||||
SYMBOL_RATE = 6940000
|
||||
INNER_FEC = AUTO
|
||||
@@ -335,6 +373,14 @@ You can browse scan tables online here: `dvb-scan-tables
|
||||
Assuming this channel is named 'channel.conf', you can then run::
|
||||
|
||||
$ dvbv5-scan channel.conf
|
||||
dvbv5-scan ~/vidtv.conf
|
||||
ERROR command BANDWIDTH_HZ (5) not found during retrieve
|
||||
Cannot calc frequency shift. Either bandwidth/symbol-rate is unavailable (yet).
|
||||
Scanning frequency #1 330000000
|
||||
(0x00) Signal= -68.00dBm
|
||||
Scanning frequency #2 474000000
|
||||
Lock (0x1f) Signal= -34.45dBm C/N= 33.74dB UCB= 0
|
||||
Service Beethoven, provider LinuxTV.org: digital television
|
||||
|
||||
For more information on dvb-scan, check its documentation online here:
|
||||
`dvb-scan Documentation <https://www.linuxtv.org/wiki/index.php/Dvbscan>`_.
|
||||
@@ -344,23 +390,38 @@ Using dvb-zap
|
||||
|
||||
dvbv5-zap is a command line tool that can be used to record MPEG-TS to disk. The
|
||||
typical use is to tune into a channel and put it into record mode. The example
|
||||
below - which is taken from the documentation - illustrates that::
|
||||
below - which is taken from the documentation - illustrates that\ [1]_::
|
||||
|
||||
$ dvbv5-zap -c dvb_channel.conf "trilhas sonoras" -r
|
||||
using demux '/dev/dvb/adapter0/demux0'
|
||||
$ dvbv5-zap -c dvb_channel.conf "beethoven" -o music.ts -P -t 10
|
||||
using demux 'dvb0.demux0'
|
||||
reading channels from file 'dvb_channel.conf'
|
||||
service has pid type 05: 204
|
||||
tuning to 573000000 Hz
|
||||
audio pid 104
|
||||
dvb_set_pesfilter 104
|
||||
Lock (0x1f) Quality= Good Signal= 100.00% C/N= -13.80dB UCB= 70 postBER= 3.14x10^-3 PER= 0
|
||||
DVR interface '/dev/dvb/adapter0/dvr0' can now be opened
|
||||
tuning to 474000000 Hz
|
||||
pass all PID's to TS
|
||||
dvb_set_pesfilter 8192
|
||||
dvb_dev_set_bufsize: buffer set to 6160384
|
||||
Lock (0x1f) Quality= Good Signal= -34.66dBm C/N= 33.41dB UCB= 0 postBER= 0 preBER= 1.05x10^-3 PER= 0
|
||||
Lock (0x1f) Quality= Good Signal= -34.57dBm C/N= 33.46dB UCB= 0 postBER= 0 preBER= 1.05x10^-3 PER= 0
|
||||
Record to file 'music.ts' started
|
||||
received 24587768 bytes (2401 Kbytes/sec)
|
||||
Lock (0x1f) Quality= Good Signal= -34.42dBm C/N= 33.89dB UCB= 0 postBER= 0 preBER= 2.44x10^-3 PER= 0
|
||||
|
||||
The channel can be watched by playing the contents of the DVR interface, with
|
||||
some player that recognizes the MPEG-TS format, such as *mplayer* or *vlc*.
|
||||
.. [1] In this example, it records 10 seconds with all program ID's stored
|
||||
at the music.ts file.
|
||||
|
||||
|
||||
The channel can be watched by playing the contents of the stream with some
|
||||
player that recognizes the MPEG-TS format, such as ``mplayer`` or ``vlc``.
|
||||
|
||||
By playing the contents of the stream one can visually inspect the workings of
|
||||
vidtv, e.g.::
|
||||
vidtv, e.g., to play a recorded TS file with::
|
||||
|
||||
$ mplayer music.ts
|
||||
|
||||
or, alternatively, running this command on one terminal::
|
||||
|
||||
$ dvbv5-zap -c dvb_channel.conf "beethoven" -P -r &
|
||||
|
||||
And, on a second terminal, playing the contents from DVR interface with::
|
||||
|
||||
$ mplayer /dev/dvb/adapter0/dvr0
|
||||
|
||||
@@ -423,3 +484,30 @@ A nice addition is to simulate some noise when the signal quality is bad by:
|
||||
- Updating the error statistics accordingly (e.g. BER, etc).
|
||||
|
||||
- Simulating some noise in the encoded data.
|
||||
|
||||
Functions and structs used within vidtv
|
||||
---------------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_bridge.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_channel.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_demod.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_encoder.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_mux.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_pes.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_psi.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_s302m.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_ts.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_tuner.h
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_common.c
|
||||
|
||||
.. kernel-doc:: drivers/media/test-drivers/vidtv/vidtv_tuner.c
|
||||
|
||||
@@ -256,6 +256,10 @@ which is 1024 bytes long:
|
||||
- s\_padding2
|
||||
-
|
||||
* - 0x54
|
||||
- \_\_be32
|
||||
- s\_num\_fc\_blocks
|
||||
- Number of fast commit blocks in the journal.
|
||||
* - 0x58
|
||||
- \_\_u32
|
||||
- s\_padding[42]
|
||||
-
|
||||
@@ -310,6 +314,8 @@ The journal incompat features are any combination of the following:
|
||||
- This journal uses v3 of the checksum on-disk format. This is the same as
|
||||
v2, but the journal block tag size is fixed regardless of the size of
|
||||
block numbers. (JBD2\_FEATURE\_INCOMPAT\_CSUM\_V3)
|
||||
* - 0x20
|
||||
- Journal has fast commit blocks. (JBD2\_FEATURE\_INCOMPAT\_FAST\_COMMIT)
|
||||
|
||||
.. _jbd2_checksum_type:
|
||||
|
||||
|
||||
@@ -596,6 +596,13 @@ following:
|
||||
- Sparse Super Block, v2. If this flag is set, the SB field s\_backup\_bgs
|
||||
points to the two block groups that contain backup superblocks
|
||||
(COMPAT\_SPARSE\_SUPER2).
|
||||
* - 0x400
|
||||
- Fast commits supported. Although fast commits blocks are
|
||||
backward incompatible, fast commit blocks are not always
|
||||
present in the journal. If fast commit blocks are present in
|
||||
the journal, JBD2 incompat feature
|
||||
(JBD2\_FEATURE\_INCOMPAT\_FAST\_COMMIT) gets
|
||||
set (COMPAT\_FAST\_COMMIT).
|
||||
|
||||
.. _super_incompat:
|
||||
|
||||
|
||||
@@ -136,10 +136,8 @@ Fast commits
|
||||
~~~~~~~~~~~~
|
||||
|
||||
JBD2 to also allows you to perform file-system specific delta commits known as
|
||||
fast commits. In order to use fast commits, you first need to call
|
||||
:c:func:`jbd2_fc_init` and tell how many blocks at the end of journal
|
||||
area should be reserved for fast commits. Along with that, you will also need
|
||||
to set following callbacks that perform correspodning work:
|
||||
fast commits. In order to use fast commits, you will need to set following
|
||||
callbacks that perform correspodning work:
|
||||
|
||||
`journal->j_fc_cleanup_cb`: Cleanup function called after every full commit and
|
||||
fast commit.
|
||||
|
||||
@@ -19,9 +19,9 @@ report the "current" state of the lid as either "opened" or "closed".
|
||||
|
||||
For most platforms, both the _LID method and the lid notifications are
|
||||
reliable. However, there are exceptions. In order to work with these
|
||||
exceptional buggy platforms, special restrictions and expections should be
|
||||
exceptional buggy platforms, special restrictions and exceptions should be
|
||||
taken into account. This document describes the restrictions and the
|
||||
expections of the Linux ACPI lid device driver.
|
||||
exceptions of the Linux ACPI lid device driver.
|
||||
|
||||
|
||||
Restrictions of the returning value of the _LID control method
|
||||
@@ -46,7 +46,7 @@ state is changed to "closed". The "closed" notification is normally used to
|
||||
trigger some system power saving operations on Windows. Since it is fully
|
||||
tested, it is reliable from all AML tables.
|
||||
|
||||
Expections for the userspace users of the ACPI lid device driver
|
||||
Exceptions for the userspace users of the ACPI lid device driver
|
||||
================================================================
|
||||
|
||||
The ACPI button driver exports the lid state to the userspace via the
|
||||
@@ -100,7 +100,7 @@ use the following kernel parameter:
|
||||
C. button.lid_init_state=ignore:
|
||||
When this option is specified, the ACPI button driver never reports the
|
||||
initial lid state and there is a compensation mechanism implemented to
|
||||
ensure that the reliable "closed" notifications can always be delievered
|
||||
ensure that the reliable "closed" notifications can always be delivered
|
||||
to the userspace by always pairing "closed" input events with complement
|
||||
"opened" input events. But there is still no guarantee that the "opened"
|
||||
notifications can be delivered to the userspace when the lid is actually
|
||||
|
||||
@@ -20,9 +20,9 @@ index, like the ASL example below shows::
|
||||
|
||||
Name (_CRS, ResourceTemplate ()
|
||||
{
|
||||
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
|
||||
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
|
||||
"\\_SB.GPO0", 0, ResourceConsumer) {15}
|
||||
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
|
||||
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
|
||||
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
|
||||
})
|
||||
|
||||
@@ -49,15 +49,41 @@ index
|
||||
pin
|
||||
Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
|
||||
active_low
|
||||
If 1 the GPIO is marked as active_low.
|
||||
If 1, the GPIO is marked as active_low.
|
||||
|
||||
Since ACPI GpioIo() resource does not have a field saying whether it is
|
||||
active low or high, the "active_low" argument can be used here. Setting
|
||||
it to 1 marks the GPIO as active low.
|
||||
|
||||
Note, active_low in _DSD does not make sense for GpioInt() resource and
|
||||
must be 0. GpioInt() resource has its own means of defining it.
|
||||
|
||||
In our Bluetooth example the "reset-gpios" refers to the second GpioIo()
|
||||
resource, second pin in that resource with the GPIO number of 31.
|
||||
|
||||
The GpioIo() resource unfortunately doesn't explicitly provide an initial
|
||||
state of the output pin which driver should use during its initialization.
|
||||
|
||||
Linux tries to use common sense here and derives the state from the bias
|
||||
and polarity settings. The table below shows the expectations:
|
||||
|
||||
========= ============= ==============
|
||||
Pull Bias Polarity Requested...
|
||||
========= ============= ==============
|
||||
Implicit x AS IS (assumed firmware configured for us)
|
||||
Explicit x (no _DSD) as Pull Bias (Up == High, Down == Low),
|
||||
assuming non-active (Polarity = !Pull Bias)
|
||||
Down Low as low, assuming active
|
||||
Down High as low, assuming non-active
|
||||
Up Low as high, assuming non-active
|
||||
Up High as high, assuming active
|
||||
========= ============= ==============
|
||||
|
||||
That said, for our above example the both GPIOs, since the bias setting
|
||||
is explicit and _DSD is present, will be treated as active with a high
|
||||
polarity and Linux will configure the pins in this state until a driver
|
||||
reprograms them differently.
|
||||
|
||||
It is possible to leave holes in the array of GPIOs. This is useful in
|
||||
cases like with SPI host controllers where some chip selects may be
|
||||
implemented as GPIOs and some as native signals. For example a SPI host
|
||||
@@ -112,8 +138,8 @@ Example::
|
||||
Package () {
|
||||
"gpio-line-names",
|
||||
Package () {
|
||||
"SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD", "MUX7_IO",
|
||||
"LVL_C_A1", "MUX0_IO", "SPI1_MISO"
|
||||
"SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD",
|
||||
"MUX7_IO", "LVL_C_A1", "MUX0_IO", "SPI1_MISO",
|
||||
}
|
||||
}
|
||||
|
||||
@@ -137,7 +163,7 @@ to the GPIO lines it is going to use and provide the GPIO subsystem with a
|
||||
mapping between those names and the ACPI GPIO resources corresponding to them.
|
||||
|
||||
To do that, the driver needs to define a mapping table as a NULL-terminated
|
||||
array of struct acpi_gpio_mapping objects that each contain a name, a pointer
|
||||
array of struct acpi_gpio_mapping objects that each contains a name, a pointer
|
||||
to an array of line data (struct acpi_gpio_params) objects and the size of that
|
||||
array. Each struct acpi_gpio_params object consists of three fields,
|
||||
crs_entry_index, line_index, active_low, representing the index of the target
|
||||
@@ -154,13 +180,14 @@ question would look like this::
|
||||
static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
|
||||
{ "reset-gpios", &reset_gpio, 1 },
|
||||
{ "shutdown-gpios", &shutdown_gpio, 1 },
|
||||
{ },
|
||||
{ }
|
||||
};
|
||||
|
||||
Next, the mapping table needs to be passed as the second argument to
|
||||
acpi_dev_add_driver_gpios() that will register it with the ACPI device object
|
||||
pointed to by its first argument. That should be done in the driver's .probe()
|
||||
routine. On removal, the driver should unregister its GPIO mapping table by
|
||||
acpi_dev_add_driver_gpios() or its managed analogue that will
|
||||
register it with the ACPI device object pointed to by its first
|
||||
argument. That should be done in the driver's .probe() routine.
|
||||
On removal, the driver should unregister its GPIO mapping table by
|
||||
calling acpi_dev_remove_driver_gpios() on the ACPI device object where that
|
||||
table was previously registered.
|
||||
|
||||
@@ -191,12 +218,12 @@ The driver might expect to get the right GPIO when it does::
|
||||
but since there is no way to know the mapping between "reset" and
|
||||
the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT).
|
||||
|
||||
The driver author can solve this by passing the mapping explictly
|
||||
(the recommended way and documented in the above chapter).
|
||||
The driver author can solve this by passing the mapping explicitly
|
||||
(this is the recommended way and it's documented in the above chapter).
|
||||
|
||||
The ACPI GPIO mapping tables should not contaminate drivers that are not
|
||||
knowing about which exact device they are servicing on. It implies that
|
||||
the ACPI GPIO mapping tables are hardly linked to ACPI ID and certain
|
||||
the ACPI GPIO mapping tables are hardly linked to an ACPI ID and certain
|
||||
objects, as listed in the above chapter, of the device in question.
|
||||
|
||||
Getting GPIO descriptor
|
||||
@@ -229,5 +256,5 @@ Case 2 explicitly tells GPIO core to look for resources in _CRS.
|
||||
Be aware that gpiod_get_index() in cases 1 and 2, assuming that there
|
||||
are two versions of ACPI device description provided and no mapping is
|
||||
present in the driver, will return different resources. That's why a
|
||||
certain driver has to handle them carefully as explained in previous
|
||||
certain driver has to handle them carefully as explained in the previous
|
||||
chapter.
|
||||
|
||||
@@ -98,7 +98,7 @@ subject to change::
|
||||
[ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution.
|
||||
|
||||
Developers can utilize these special log entries to track the AML
|
||||
interpretion, thus can aid issue debugging and performance tuning. Note
|
||||
interpretation, thus can aid issue debugging and performance tuning. Note
|
||||
that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT()
|
||||
macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling
|
||||
"AML tracer" logs.
|
||||
|
||||
@@ -57,9 +57,8 @@ to enable them. ::
|
||||
They can be enabled individually. The full list of the parameters: ::
|
||||
|
||||
make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
|
||||
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump OBJSIZE=llvm-size \
|
||||
READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar \
|
||||
HOSTLD=ld.lld
|
||||
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
|
||||
HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld
|
||||
|
||||
Currently, the integrated assembler is disabled by default. You can pass
|
||||
``LLVM_IAS=1`` to enable it.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user