Merge branches 'for-5.1/upstream-fixes', 'for-5.2/core', 'for-5.2/ish', 'for-5.2/logitech', 'for-5.2/macally', 'for-5.2/picolcd', 'for-5.2/sensor' and 'for-5.2/u2fzero' into for-linus
This commit is contained in:
commit
63b6f0b827
|
@ -240,6 +240,7 @@ ForEachMacros:
|
|||
- 'for_each_set_bit'
|
||||
- 'for_each_set_bit_from'
|
||||
- 'for_each_sg'
|
||||
- 'for_each_sg_dma_page'
|
||||
- 'for_each_sg_page'
|
||||
- 'for_each_sibling_event'
|
||||
- '__for_each_thread'
|
||||
|
@ -289,7 +290,6 @@ ForEachMacros:
|
|||
- 'idr_for_each_entry_ul'
|
||||
- 'inet_bind_bucket_for_each'
|
||||
- 'inet_lhash2_for_each_icsk_rcu'
|
||||
- 'iov_for_each'
|
||||
- 'key_for_each'
|
||||
- 'key_for_each_safe'
|
||||
- 'klp_for_each_func'
|
||||
|
@ -360,6 +360,7 @@ ForEachMacros:
|
|||
- 'radix_tree_for_each_slot'
|
||||
- 'radix_tree_for_each_tagged'
|
||||
- 'rbtree_postorder_for_each_entry_safe'
|
||||
- 'rdma_for_each_port'
|
||||
- 'resource_list_for_each_entry'
|
||||
- 'resource_list_for_each_entry_safe'
|
||||
- 'rhl_for_each_entry_rcu'
|
||||
|
|
4
.mailmap
4
.mailmap
|
@ -156,6 +156,8 @@ Morten Welinder <welinder@darter.rentec.com>
|
|||
Morten Welinder <welinder@troll.com>
|
||||
Mythri P K <mythripk@ti.com>
|
||||
Nguyen Anh Quynh <aquynh@gmail.com>
|
||||
Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
|
||||
Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
|
||||
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
|
||||
Patrick Mochel <mochel@digitalimplant.org>
|
||||
Paul Burton <paul.burton@mips.com> <paul.burton@imgtec.com>
|
||||
|
@ -224,3 +226,5 @@ Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
|
|||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
Gustavo Padovan <gustavo@las.ic.unicamp.br>
|
||||
Gustavo Padovan <padovan@profusion.mobi>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
|
|
22
Documentation/ABI/obsolete/sysfs-class-dax
Normal file
22
Documentation/ABI/obsolete/sysfs-class-dax
Normal file
|
@ -0,0 +1,22 @@
|
|||
What: /sys/class/dax/
|
||||
Date: May, 2016
|
||||
KernelVersion: v4.7
|
||||
Contact: linux-nvdimm@lists.01.org
|
||||
Description: Device DAX is the device-centric analogue of Filesystem
|
||||
DAX (CONFIG_FS_DAX). It allows memory ranges to be
|
||||
allocated and mapped without need of an intervening file
|
||||
system. Device DAX is strict, precise and predictable.
|
||||
Specifically this interface:
|
||||
|
||||
1/ Guarantees fault granularity with respect to a given
|
||||
page size (pte, pmd, or pud) set at configuration time.
|
||||
|
||||
2/ Enforces deterministic behavior by being strict about
|
||||
what fault scenarios are supported.
|
||||
|
||||
The /sys/class/dax/ interface enumerates all the
|
||||
device-dax instances in the system. The ABI is
|
||||
deprecated and will be removed after 2020. It is
|
||||
replaced with the DAX bus interface /sys/bus/dax/ where
|
||||
device-dax instances can be found under
|
||||
/sys/bus/dax/devices/
|
|
@ -21,7 +21,19 @@ Description: These files show with which CPLD versions have been burned
|
|||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
|
||||
cpld3_version
|
||||
fan_dir
|
||||
|
||||
Date: December 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file shows the system fans direction:
|
||||
forward direction - relevant bit is set 0;
|
||||
reversed direction - relevant bit is set 1.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
|
||||
jtag_enable
|
||||
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
|
|
23
Documentation/ABI/testing/debugfs-wilco-ec
Normal file
23
Documentation/ABI/testing/debugfs-wilco-ec
Normal file
|
@ -0,0 +1,23 @@
|
|||
What: /sys/kernel/debug/wilco_ec/raw
|
||||
Date: January 2019
|
||||
KernelVersion: 5.1
|
||||
Description:
|
||||
Write and read raw mailbox commands to the EC.
|
||||
|
||||
For writing:
|
||||
Bytes 0-1 indicate the message type:
|
||||
00 F0 = Execute Legacy Command
|
||||
00 F2 = Read/Write NVRAM Property
|
||||
Byte 2 provides the command code
|
||||
Bytes 3+ consist of the data passed in the request
|
||||
|
||||
At least three bytes are required, for the msg type and command,
|
||||
with additional bytes optional for additional data.
|
||||
|
||||
Example:
|
||||
// Request EC info type 3 (EC firmware build date)
|
||||
$ echo 00 f0 38 00 03 00 > raw
|
||||
// View the result. The decoded ASCII result "12/21/18" is
|
||||
// included after the raw hex.
|
||||
$ cat raw
|
||||
00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00 .12/21/18.8...
|
32
Documentation/ABI/testing/sysfs-class-chromeos
Normal file
32
Documentation/ABI/testing/sysfs-class-chromeos
Normal file
|
@ -0,0 +1,32 @@
|
|||
What: /sys/class/chromeos/<ec-device-name>/flashinfo
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
Show the EC flash information.
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/kb_wake_angle
|
||||
Date: March 2018
|
||||
KernelVersion: 4.17
|
||||
Description:
|
||||
Control the keyboard wake lid angle. Values are between
|
||||
0 and 360. This file will also show the keyboard wake lid
|
||||
angle by querying the hardware.
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/reboot
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
Tell the EC to reboot in various ways. Options are:
|
||||
"cancel": Cancel a pending reboot.
|
||||
"ro": Jump to RO without rebooting.
|
||||
"rw": Jump to RW without rebooting.
|
||||
"cold": Cold reboot.
|
||||
"disable-jump": Disable jump until next reboot.
|
||||
"hibernate": Hibernate the EC.
|
||||
"at-shutdown": Reboot after an AP shutdown.
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/version
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
Show the information about the EC software and hardware.
|
|
@ -0,0 +1,74 @@
|
|||
What: /sys/class/chromeos/<ec-device-name>/lightbar/brightness
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
Writing to this file adjusts the overall brightness of
|
||||
the lightbar, separate from any color intensity. The
|
||||
valid range is 0 (off) to 255 (maximum brightness).
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/lightbar/interval_msec
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
The lightbar is controlled by an embedded controller (EC),
|
||||
which also manages the keyboard, battery charging, fans,
|
||||
and other system hardware. To prevent unprivileged users
|
||||
from interfering with the other EC functions, the rate at
|
||||
which the lightbar control files can be read or written is
|
||||
limited.
|
||||
|
||||
Reading this file will return the number of milliseconds
|
||||
that must elapse between accessing any of the lightbar
|
||||
functions through this interface. Going faster will simply
|
||||
block until the necessary interval has lapsed. The interval
|
||||
applies uniformly to all accesses of any kind by any user.
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/lightbar/led_rgb
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
This allows you to control each LED segment. If the
|
||||
lightbar is already running one of the automatic
|
||||
sequences, you probably won’t see anything change because
|
||||
your color setting will be almost immediately replaced.
|
||||
To get useful results, you should stop the lightbar
|
||||
sequence first.
|
||||
|
||||
The values written to this file are sets of four integers,
|
||||
indicating LED, RED, GREEN, BLUE. The LED number is 0 to 3
|
||||
to select a single segment, or 4 to set all four segments
|
||||
to the same value at once. The RED, GREEN, and BLUE
|
||||
numbers should be in the range 0 (off) to 255 (maximum).
|
||||
You can update more than one segment at a time by writing
|
||||
more than one set of four integers.
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/lightbar/program
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
This allows you to upload and run custom lightbar sequences.
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/lightbar/sequence
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
The Pixel lightbar has a number of built-in sequences
|
||||
that it displays under various conditions, such as at
|
||||
power on, shut down, or while running. Reading from this
|
||||
file displays the current sequence that the lightbar is
|
||||
displaying. Writing to this file allows you to change the
|
||||
sequence.
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/lightbar/userspace_control
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
This allows you to take the control of the lightbar. This
|
||||
prevents the kernel from going through its normal
|
||||
sequences.
|
||||
|
||||
What: /sys/class/chromeos/<ec-device-name>/lightbar/version
|
||||
Date: August 2015
|
||||
KernelVersion: 4.2
|
||||
Description:
|
||||
Show the information about the lightbar version.
|
|
@ -0,0 +1,6 @@
|
|||
What: /sys/class/chromeos/<ec-device-name>/vbc/vboot_context
|
||||
Date: October 2015
|
||||
KernelVersion: 4.4
|
||||
Description:
|
||||
Read/write the verified boot context data included on a
|
||||
small nvram space on some EC implementations.
|
|
@ -49,3 +49,26 @@ Contact: Wim Van Sebroeck <wim@iguana.be>
|
|||
Description:
|
||||
It is a read only file. It is read to know about current
|
||||
value of timeout programmed.
|
||||
|
||||
What: /sys/class/watchdog/watchdogn/pretimeout
|
||||
Date: December 2016
|
||||
Contact: Wim Van Sebroeck <wim@iguana.be>
|
||||
Description:
|
||||
It is a read only file. It specifies the time in seconds before
|
||||
timeout when the pretimeout interrupt is delivered. Pretimeout
|
||||
is an optional feature.
|
||||
|
||||
What: /sys/class/watchdog/watchdogn/pretimeout_avaialable_governors
|
||||
Date: February 2017
|
||||
Contact: Wim Van Sebroeck <wim@iguana.be>
|
||||
Description:
|
||||
It is a read only file. It shows the pretimeout governors
|
||||
available for this watchdog.
|
||||
|
||||
What: /sys/class/watchdog/watchdogn/pretimeout_governor
|
||||
Date: February 2017
|
||||
Contact: Wim Van Sebroeck <wim@iguana.be>
|
||||
Description:
|
||||
It is a read/write file. When read, the currently assigned
|
||||
pretimeout governor is returned. When written, it sets
|
||||
the pretimeout governor.
|
||||
|
|
|
@ -109,3 +109,10 @@ Description:
|
|||
write operation (since a 4k random write might turn
|
||||
into a much larger write due to the zeroout
|
||||
operation).
|
||||
|
||||
What: /sys/fs/ext4/<disk>/journal_task
|
||||
Date: February 2019
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
This file is read-only and shows the pid of journal thread in
|
||||
current pid-namespace or 0 if task is unreachable.
|
||||
|
|
|
@ -86,6 +86,13 @@ Description:
|
|||
The unit size is one block, now only support configuring in range
|
||||
of [1, 512].
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/umount_discard_timeout
|
||||
Date: January 2019
|
||||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
Description:
|
||||
Set timeout to issue discard commands during umount.
|
||||
Default: 5 secs
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/max_victim_search
|
||||
Date: January 2014
|
||||
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
||||
|
|
|
@ -146,114 +146,75 @@ What about block I/O and networking buffers? The block I/O and
|
|||
networking subsystems make sure that the buffers they use are valid
|
||||
for you to DMA from/to.
|
||||
|
||||
DMA addressing limitations
|
||||
DMA addressing capabilities
|
||||
==========================
|
||||
|
||||
Does your device have any DMA addressing limitations? For example, is
|
||||
your device only capable of driving the low order 24-bits of address?
|
||||
If so, you need to inform the kernel of this fact.
|
||||
By default, the kernel assumes that your device can address 32-bits of DMA
|
||||
addressing. For a 64-bit capable device, this needs to be increased, and for
|
||||
a device with limitations, it needs to be decreased.
|
||||
|
||||
By default, the kernel assumes that your device can address the full
|
||||
32-bits. For a 64-bit capable device, this needs to be increased.
|
||||
And for a device with limitations, as discussed in the previous
|
||||
paragraph, it needs to be decreased.
|
||||
Special note about PCI: PCI-X specification requires PCI-X devices to support
|
||||
64-bit addressing (DAC) for all transactions. And at least one platform (SGI
|
||||
SN2) requires 64-bit consistent allocations to operate correctly when the IO
|
||||
bus is in PCI-X mode.
|
||||
|
||||
Special note about PCI: PCI-X specification requires PCI-X devices to
|
||||
support 64-bit addressing (DAC) for all transactions. And at least
|
||||
one platform (SGI SN2) requires 64-bit consistent allocations to
|
||||
operate correctly when the IO bus is in PCI-X mode.
|
||||
For correct operation, you must set the DMA mask to inform the kernel about
|
||||
your devices DMA addressing capabilities.
|
||||
|
||||
For correct operation, you must interrogate the kernel in your device
|
||||
probe routine to see if the DMA controller on the machine can properly
|
||||
support the DMA addressing limitation your device has. It is good
|
||||
style to do this even if your device holds the default setting,
|
||||
because this shows that you did think about these issues wrt. your
|
||||
device.
|
||||
|
||||
The query is performed via a call to dma_set_mask_and_coherent()::
|
||||
This is performed via a call to dma_set_mask_and_coherent()::
|
||||
|
||||
int dma_set_mask_and_coherent(struct device *dev, u64 mask);
|
||||
|
||||
which will query the mask for both streaming and coherent APIs together.
|
||||
If you have some special requirements, then the following two separate
|
||||
queries can be used instead:
|
||||
which will set the mask for both streaming and coherent APIs together. If you
|
||||
have some special requirements, then the following two separate calls can be
|
||||
used instead:
|
||||
|
||||
The query for streaming mappings is performed via a call to
|
||||
The setup for streaming mappings is performed via a call to
|
||||
dma_set_mask()::
|
||||
|
||||
int dma_set_mask(struct device *dev, u64 mask);
|
||||
|
||||
The query for consistent allocations is performed via a call
|
||||
The setup for consistent allocations is performed via a call
|
||||
to dma_set_coherent_mask()::
|
||||
|
||||
int dma_set_coherent_mask(struct device *dev, u64 mask);
|
||||
|
||||
Here, dev is a pointer to the device struct of your device, and mask
|
||||
is a bit mask describing which bits of an address your device
|
||||
supports. It returns zero if your card can perform DMA properly on
|
||||
the machine given the address mask you provided. In general, the
|
||||
device struct of your device is embedded in the bus-specific device
|
||||
struct of your device. For example, &pdev->dev is a pointer to the
|
||||
device struct of a PCI device (pdev is a pointer to the PCI device
|
||||
struct of your device).
|
||||
Here, dev is a pointer to the device struct of your device, and mask is a bit
|
||||
mask describing which bits of an address your device supports. Often the
|
||||
device struct of your device is embedded in the bus-specific device struct of
|
||||
your device. For example, &pdev->dev is a pointer to the device struct of a
|
||||
PCI device (pdev is a pointer to the PCI device struct of your device).
|
||||
|
||||
If it returns non-zero, your device cannot perform DMA properly on
|
||||
this platform, and attempting to do so will result in undefined
|
||||
behavior. You must either use a different mask, or not use DMA.
|
||||
These calls usually return zero to indicated your device can perform DMA
|
||||
properly on the machine given the address mask you provided, but they might
|
||||
return an error if the mask is too small to be supportable on the given
|
||||
system. If it returns non-zero, your device cannot perform DMA properly on
|
||||
this platform, and attempting to do so will result in undefined behavior.
|
||||
You must not use DMA on this device unless the dma_set_mask family of
|
||||
functions has returned success.
|
||||
|
||||
This means that in the failure case, you have three options:
|
||||
This means that in the failure case, you have two options:
|
||||
|
||||
1) Use another DMA mask, if possible (see below).
|
||||
2) Use some non-DMA mode for data transfer, if possible.
|
||||
3) Ignore this device and do not initialize it.
|
||||
1) Use some non-DMA mode for data transfer, if possible.
|
||||
2) Ignore this device and do not initialize it.
|
||||
|
||||
It is recommended that your driver print a kernel KERN_WARNING message
|
||||
when you end up performing either #2 or #3. In this manner, if a user
|
||||
of your driver reports that performance is bad or that the device is not
|
||||
even detected, you can ask them for the kernel messages to find out
|
||||
exactly why.
|
||||
It is recommended that your driver print a kernel KERN_WARNING message when
|
||||
setting the DMA mask fails. In this manner, if a user of your driver reports
|
||||
that performance is bad or that the device is not even detected, you can ask
|
||||
them for the kernel messages to find out exactly why.
|
||||
|
||||
The standard 32-bit addressing device would do something like this::
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
dev_warn(dev, "mydev: No suitable DMA available\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
Another common scenario is a 64-bit capable device. The approach here
|
||||
is to try for 64-bit addressing, but back down to a 32-bit mask that
|
||||
should not fail. The kernel may fail the 64-bit mask not because the
|
||||
platform is not capable of 64-bit addressing. Rather, it may fail in
|
||||
this case simply because 32-bit addressing is done more efficiently
|
||||
than 64-bit addressing. For example, Sparc64 PCI SAC addressing is
|
||||
more efficient than DAC addressing.
|
||||
If the device only supports 32-bit addressing for descriptors in the
|
||||
coherent allocations, but supports full 64-bits for streaming mappings
|
||||
it would look like this:
|
||||
|
||||
Here is how you would handle a 64-bit capable device which can drive
|
||||
all 64-bits when accessing streaming DMA::
|
||||
|
||||
int using_dac;
|
||||
|
||||
if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
} else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
} else {
|
||||
dev_warn(dev, "mydev: No suitable DMA available\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
If a card is capable of using 64-bit consistent allocations as well,
|
||||
the case would look like this::
|
||||
|
||||
int using_dac, consistent_using_dac;
|
||||
|
||||
if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
consistent_using_dac = 1;
|
||||
} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
consistent_using_dac = 0;
|
||||
} else {
|
||||
if (dma_set_mask(dev, DMA_BIT_MASK(64))) {
|
||||
dev_warn(dev, "mydev: No suitable DMA available\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
|
|
@ -195,6 +195,14 @@ Requesting the required mask does not alter the current mask. If you
|
|||
wish to take advantage of it, you should issue a dma_set_mask()
|
||||
call to set the mask to the value returned.
|
||||
|
||||
::
|
||||
|
||||
size_t
|
||||
dma_direct_max_mapping_size(struct device *dev);
|
||||
|
||||
Returns the maximum size of a mapping for the device. The size parameter
|
||||
of the mapping functions like dma_map_single(), dma_map_page() and
|
||||
others should not be larger than the returned value.
|
||||
|
||||
Part Id - Streaming DMA mappings
|
||||
--------------------------------
|
||||
|
@ -530,8 +538,8 @@ that simply cannot make consistent memory.
|
|||
dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
|
||||
dma_addr_t dma_handle, unsigned long attrs)
|
||||
|
||||
Free memory allocated by the dma_alloc_attrs(). All parameters common
|
||||
parameters must identical to those otherwise passed to dma_fre_coherent,
|
||||
Free memory allocated by the dma_alloc_attrs(). All common
|
||||
parameters must be identical to those otherwise passed to dma_free_coherent,
|
||||
and the attrs argument must be identical to the attrs passed to
|
||||
dma_alloc_attrs().
|
||||
|
||||
|
@ -566,8 +574,7 @@ boundaries when doing this.
|
|||
|
||||
int
|
||||
dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr,
|
||||
dma_addr_t device_addr, size_t size, int
|
||||
flags)
|
||||
dma_addr_t device_addr, size_t size);
|
||||
|
||||
Declare region of memory to be handed out by dma_alloc_coherent() when
|
||||
it's asked for coherent memory for this device.
|
||||
|
@ -581,12 +588,6 @@ dma_addr_t in dma_alloc_coherent()).
|
|||
|
||||
size is the size of the area (must be multiples of PAGE_SIZE).
|
||||
|
||||
flags can be ORed together and are:
|
||||
|
||||
- DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions.
|
||||
Do not allow dma_alloc_coherent() to fall back to system memory when
|
||||
it's out of memory in the declared region.
|
||||
|
||||
As a simplification for the platforms, only *one* such region of
|
||||
memory may be declared per device.
|
||||
|
||||
|
@ -605,23 +606,6 @@ unconditionally having removed all the required structures. It is the
|
|||
driver's job to ensure that no parts of this memory region are
|
||||
currently in use.
|
||||
|
||||
::
|
||||
|
||||
void *
|
||||
dma_mark_declared_memory_occupied(struct device *dev,
|
||||
dma_addr_t device_addr, size_t size)
|
||||
|
||||
This is used to occupy specific regions of the declared space
|
||||
(dma_alloc_coherent() will hand out the first free region it finds).
|
||||
|
||||
device_addr is the *device* address of the region requested.
|
||||
|
||||
size is the size (and should be a page-sized multiple).
|
||||
|
||||
The return value will be either a pointer to the processor virtual
|
||||
address of the memory, or an error (via PTR_ERR()) if any part of the
|
||||
region is occupied.
|
||||
|
||||
Part III - Debug drivers use of the DMA-API
|
||||
-------------------------------------------
|
||||
|
||||
|
@ -696,6 +680,9 @@ dma-api/disabled This read-only file contains the character 'Y'
|
|||
happen when it runs out of memory or if it was
|
||||
disabled at boot time
|
||||
|
||||
dma-api/dump This read-only file contains current DMA
|
||||
mappings.
|
||||
|
||||
dma-api/error_count This file is read-only and shows the total
|
||||
numbers of errors found.
|
||||
|
||||
|
@ -717,7 +704,7 @@ dma-api/num_free_entries The current number of free dma_debug_entries
|
|||
dma-api/nr_total_entries The total number of dma_debug_entries in the
|
||||
allocator, both free and used.
|
||||
|
||||
dma-api/driver-filter You can write a name of a driver into this file
|
||||
dma-api/driver_filter You can write a name of a driver into this file
|
||||
to limit the debug output to requests from that
|
||||
particular driver. Write an empty string to
|
||||
that file to disable the filter and see
|
||||
|
|
|
@ -52,8 +52,8 @@ Address translation
|
|||
-------------------
|
||||
|
||||
To translate the virtual address to a bus address, use the normal DMA
|
||||
API. Do _not_ use isa_virt_to_phys() even though it does the same
|
||||
thing. The reason for this is that the function isa_virt_to_phys()
|
||||
API. Do _not_ use isa_virt_to_bus() even though it does the same
|
||||
thing. The reason for this is that the function isa_virt_to_bus()
|
||||
will require a Kconfig dependency to ISA, not just ISA_DMA_API which
|
||||
is really all you need. Remember that even though the DMA controller
|
||||
has its origins in ISA it is used elsewhere.
|
||||
|
|
|
@ -14,9 +14,9 @@ being the real world and all that.
|
|||
So let's look at an example RCU lockdep splat from 3.0-rc5, one that
|
||||
has long since been fixed:
|
||||
|
||||
===============================
|
||||
[ INFO: suspicious RCU usage. ]
|
||||
-------------------------------
|
||||
=============================
|
||||
WARNING: suspicious RCU usage
|
||||
-----------------------------
|
||||
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
|
||||
|
||||
other info that might help us debug this:
|
||||
|
@ -24,11 +24,11 @@ other info that might help us debug this:
|
|||
|
||||
rcu_scheduler_active = 1, debug_locks = 0
|
||||
3 locks held by scsi_scan_6/1552:
|
||||
#0: (&shost->scan_mutex){+.+.+.}, at: [<ffffffff8145efca>]
|
||||
#0: (&shost->scan_mutex){+.+.}, at: [<ffffffff8145efca>]
|
||||
scsi_scan_host_selected+0x5a/0x150
|
||||
#1: (&eq->sysfs_lock){+.+...}, at: [<ffffffff812a5032>]
|
||||
#1: (&eq->sysfs_lock){+.+.}, at: [<ffffffff812a5032>]
|
||||
elevator_exit+0x22/0x60
|
||||
#2: (&(&q->__queue_lock)->rlock){-.-...}, at: [<ffffffff812b6233>]
|
||||
#2: (&(&q->__queue_lock)->rlock){-.-.}, at: [<ffffffff812b6233>]
|
||||
cfq_exit_queue+0x43/0x190
|
||||
|
||||
stack backtrace:
|
||||
|
|
|
@ -23,7 +23,7 @@ kernel.
|
|||
|
||||
The resultant userspace tool binary is then located at:
|
||||
|
||||
tools/acpi/power/acpi/acpidbg/acpidbg
|
||||
tools/power/acpi/acpidbg
|
||||
|
||||
It can be installed to system directories by running "make install" (as a
|
||||
sufficiently privileged user).
|
||||
|
@ -35,7 +35,7 @@ kernel.
|
|||
|
||||
# mount -t debugfs none /sys/kernel/debug
|
||||
# modprobe acpi_dbg
|
||||
# tools/acpi/power/acpi/acpidbg/acpidbg
|
||||
# tools/power/acpi/acpidbg
|
||||
|
||||
That spawns the interactive AML debugger environment where you can execute
|
||||
debugger commands.
|
||||
|
|
|
@ -251,7 +251,7 @@ Configuring the kernel
|
|||
Compiling the kernel
|
||||
--------------------
|
||||
|
||||
- Make sure you have at least gcc 3.2 available.
|
||||
- Make sure you have at least gcc 4.6 available.
|
||||
For more information, refer to :ref:`Documentation/process/changes.rst <changes>`.
|
||||
|
||||
Please note that you can still run a.out user programs with this kernel.
|
||||
|
|
|
@ -1197,9 +1197,10 @@
|
|||
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
|
||||
|
||||
elevator= [IOSCHED]
|
||||
Format: {"cfq" | "deadline" | "noop"}
|
||||
See Documentation/block/cfq-iosched.txt and
|
||||
Documentation/block/deadline-iosched.txt for details.
|
||||
Format: { "mq-deadline" | "kyber" | "bfq" }
|
||||
See Documentation/block/deadline-iosched.txt,
|
||||
Documentation/block/kyber-iosched.txt and
|
||||
Documentation/block/bfq-iosched.txt for details.
|
||||
|
||||
elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390]
|
||||
Specifies physical address of start of kernel core
|
||||
|
@ -1845,6 +1846,11 @@
|
|||
to let secondary kernels in charge of setting up
|
||||
LPIs.
|
||||
|
||||
irqchip.gicv3_pseudo_nmi= [ARM64]
|
||||
Enables support for pseudo-NMIs in the kernel. This
|
||||
requires the kernel to be built with
|
||||
CONFIG_ARM64_PSEUDO_NMI.
|
||||
|
||||
irqfixup [HW]
|
||||
When an interrupt is not handled search all handlers
|
||||
for it. Intended to get systems with badly broken
|
||||
|
@ -1996,6 +2002,12 @@
|
|||
Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y,
|
||||
the default is off.
|
||||
|
||||
kpti= [ARM64] Control page table isolation of user
|
||||
and kernel address spaces.
|
||||
Default: enabled on cores which need mitigation.
|
||||
0: force disabled
|
||||
1: force enabled
|
||||
|
||||
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
|
||||
Default is 0 (don't ignore, but inject #GP)
|
||||
|
||||
|
@ -5066,6 +5078,14 @@
|
|||
or other driver-specific files in the
|
||||
Documentation/watchdog/ directory.
|
||||
|
||||
watchdog_thresh=
|
||||
[KNL]
|
||||
Set the hard lockup detector stall duration
|
||||
threshold in seconds. The soft lockup detector
|
||||
threshold is set to twice the value. A value of 0
|
||||
disables both lockup detectors. Default is 10
|
||||
seconds.
|
||||
|
||||
workqueue.watchdog_thresh=
|
||||
If CONFIG_WQ_WATCHDOG is configured, workqueue can
|
||||
warn stall conditions and dump internal state to
|
||||
|
|
|
@ -756,3 +756,6 @@ These currently include:
|
|||
The cache mode for raid5. raid5 could include an extra disk for
|
||||
caching. The mode can be "write-throuth" and "write-back". The
|
||||
default is "write-through".
|
||||
|
||||
ppl_write_hint
|
||||
NVMe stream ID to be set for each PPL write request.
|
||||
|
|
|
@ -6,83 +6,211 @@ Perf Events and tool security
|
|||
Overview
|
||||
--------
|
||||
|
||||
Usage of Performance Counters for Linux (perf_events) [1]_ , [2]_ , [3]_ can
|
||||
impose a considerable risk of leaking sensitive data accessed by monitored
|
||||
processes. The data leakage is possible both in scenarios of direct usage of
|
||||
perf_events system call API [2]_ and over data files generated by Perf tool user
|
||||
mode utility (Perf) [3]_ , [4]_ . The risk depends on the nature of data that
|
||||
perf_events performance monitoring units (PMU) [2]_ collect and expose for
|
||||
performance analysis. Having that said perf_events/Perf performance monitoring
|
||||
is the subject for security access control management [5]_ .
|
||||
Usage of Performance Counters for Linux (perf_events) [1]_ , [2]_ , [3]_
|
||||
can impose a considerable risk of leaking sensitive data accessed by
|
||||
monitored processes. The data leakage is possible both in scenarios of
|
||||
direct usage of perf_events system call API [2]_ and over data files
|
||||
generated by Perf tool user mode utility (Perf) [3]_ , [4]_ . The risk
|
||||
depends on the nature of data that perf_events performance monitoring
|
||||
units (PMU) [2]_ and Perf collect and expose for performance analysis.
|
||||
Collected system and performance data may be split into several
|
||||
categories:
|
||||
|
||||
1. System hardware and software configuration data, for example: a CPU
|
||||
model and its cache configuration, an amount of available memory and
|
||||
its topology, used kernel and Perf versions, performance monitoring
|
||||
setup including experiment time, events configuration, Perf command
|
||||
line parameters, etc.
|
||||
|
||||
2. User and kernel module paths and their load addresses with sizes,
|
||||
process and thread names with their PIDs and TIDs, timestamps for
|
||||
captured hardware and software events.
|
||||
|
||||
3. Content of kernel software counters (e.g., for context switches, page
|
||||
faults, CPU migrations), architectural hardware performance counters
|
||||
(PMC) [8]_ and machine specific registers (MSR) [9]_ that provide
|
||||
execution metrics for various monitored parts of the system (e.g.,
|
||||
memory controller (IMC), interconnect (QPI/UPI) or peripheral (PCIe)
|
||||
uncore counters) without direct attribution to any execution context
|
||||
state.
|
||||
|
||||
4. Content of architectural execution context registers (e.g., RIP, RSP,
|
||||
RBP on x86_64), process user and kernel space memory addresses and
|
||||
data, content of various architectural MSRs that capture data from
|
||||
this category.
|
||||
|
||||
Data that belong to the fourth category can potentially contain
|
||||
sensitive process data. If PMUs in some monitoring modes capture values
|
||||
of execution context registers or data from process memory then access
|
||||
to such monitoring capabilities requires to be ordered and secured
|
||||
properly. So, perf_events/Perf performance monitoring is the subject for
|
||||
security access control management [5]_ .
|
||||
|
||||
perf_events/Perf access control
|
||||
-------------------------------
|
||||
|
||||
To perform security checks, the Linux implementation splits processes into two
|
||||
categories [6]_ : a) privileged processes (whose effective user ID is 0, referred
|
||||
to as superuser or root), and b) unprivileged processes (whose effective UID is
|
||||
nonzero). Privileged processes bypass all kernel security permission checks so
|
||||
perf_events performance monitoring is fully available to privileged processes
|
||||
without access, scope and resource restrictions.
|
||||
To perform security checks, the Linux implementation splits processes
|
||||
into two categories [6]_ : a) privileged processes (whose effective user
|
||||
ID is 0, referred to as superuser or root), and b) unprivileged
|
||||
processes (whose effective UID is nonzero). Privileged processes bypass
|
||||
all kernel security permission checks so perf_events performance
|
||||
monitoring is fully available to privileged processes without access,
|
||||
scope and resource restrictions.
|
||||
|
||||
Unprivileged processes are subject to a full security permission check based on
|
||||
the process's credentials [5]_ (usually: effective UID, effective GID, and
|
||||
supplementary group list).
|
||||
Unprivileged processes are subject to a full security permission check
|
||||
based on the process's credentials [5]_ (usually: effective UID,
|
||||
effective GID, and supplementary group list).
|
||||
|
||||
Linux divides the privileges traditionally associated with superuser into
|
||||
distinct units, known as capabilities [6]_ , which can be independently enabled
|
||||
and disabled on per-thread basis for processes and files of unprivileged users.
|
||||
Linux divides the privileges traditionally associated with superuser
|
||||
into distinct units, known as capabilities [6]_ , which can be
|
||||
independently enabled and disabled on per-thread basis for processes and
|
||||
files of unprivileged users.
|
||||
|
||||
Unprivileged processes with enabled CAP_SYS_ADMIN capability are treated as
|
||||
privileged processes with respect to perf_events performance monitoring and
|
||||
bypass *scope* permissions checks in the kernel.
|
||||
Unprivileged processes with enabled CAP_SYS_ADMIN capability are treated
|
||||
as privileged processes with respect to perf_events performance
|
||||
monitoring and bypass *scope* permissions checks in the kernel.
|
||||
|
||||
Unprivileged processes using perf_events system call API is also subject for
|
||||
PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose outcome
|
||||
determines whether monitoring is permitted. So unprivileged processes provided
|
||||
with CAP_SYS_PTRACE capability are effectively permitted to pass the check.
|
||||
Unprivileged processes using perf_events system call API is also subject
|
||||
for PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose
|
||||
outcome determines whether monitoring is permitted. So unprivileged
|
||||
processes provided with CAP_SYS_PTRACE capability are effectively
|
||||
permitted to pass the check.
|
||||
|
||||
Other capabilities being granted to unprivileged processes can effectively
|
||||
enable capturing of additional data required for later performance analysis of
|
||||
monitored processes or a system. For example, CAP_SYSLOG capability permits
|
||||
reading kernel space memory addresses from /proc/kallsyms file.
|
||||
Other capabilities being granted to unprivileged processes can
|
||||
effectively enable capturing of additional data required for later
|
||||
performance analysis of monitored processes or a system. For example,
|
||||
CAP_SYSLOG capability permits reading kernel space memory addresses from
|
||||
/proc/kallsyms file.
|
||||
|
||||
perf_events/Perf privileged users
|
||||
---------------------------------
|
||||
|
||||
Mechanisms of capabilities, privileged capability-dumb files [6]_ and
|
||||
file system ACLs [10]_ can be used to create a dedicated group of
|
||||
perf_events/Perf privileged users who are permitted to execute
|
||||
performance monitoring without scope limits. The following steps can be
|
||||
taken to create such a group of privileged Perf users.
|
||||
|
||||
1. Create perf_users group of privileged Perf users, assign perf_users
|
||||
group to Perf tool executable and limit access to the executable for
|
||||
other users in the system who are not in the perf_users group:
|
||||
|
||||
::
|
||||
|
||||
# groupadd perf_users
|
||||
# ls -alhF
|
||||
-rwxr-xr-x 2 root root 11M Oct 19 15:12 perf
|
||||
# chgrp perf_users perf
|
||||
# ls -alhF
|
||||
-rwxr-xr-x 2 root perf_users 11M Oct 19 15:12 perf
|
||||
# chmod o-rwx perf
|
||||
# ls -alhF
|
||||
-rwxr-x--- 2 root perf_users 11M Oct 19 15:12 perf
|
||||
|
||||
2. Assign the required capabilities to the Perf tool executable file and
|
||||
enable members of perf_users group with performance monitoring
|
||||
privileges [6]_ :
|
||||
|
||||
::
|
||||
|
||||
# setcap "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
|
||||
# setcap -v "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
|
||||
perf: OK
|
||||
# getcap perf
|
||||
perf = cap_sys_ptrace,cap_sys_admin,cap_syslog+ep
|
||||
|
||||
As a result, members of perf_users group are capable of conducting
|
||||
performance monitoring by using functionality of the configured Perf
|
||||
tool executable that, when executes, passes perf_events subsystem scope
|
||||
checks.
|
||||
|
||||
This specific access control management is only available to superuser
|
||||
or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_
|
||||
capabilities.
|
||||
|
||||
perf_events/Perf unprivileged users
|
||||
-----------------------------------
|
||||
|
||||
perf_events/Perf *scope* and *access* control for unprivileged processes is
|
||||
governed by perf_event_paranoid [2]_ setting:
|
||||
perf_events/Perf *scope* and *access* control for unprivileged processes
|
||||
is governed by perf_event_paranoid [2]_ setting:
|
||||
|
||||
-1:
|
||||
Impose no *scope* and *access* restrictions on using perf_events performance
|
||||
monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
|
||||
ignored when allocating memory buffers for storing performance data.
|
||||
This is the least secure mode since allowed monitored *scope* is
|
||||
maximized and no perf_events specific limits are imposed on *resources*
|
||||
allocated for performance monitoring.
|
||||
Impose no *scope* and *access* restrictions on using perf_events
|
||||
performance monitoring. Per-user per-cpu perf_event_mlock_kb [2]_
|
||||
locking limit is ignored when allocating memory buffers for storing
|
||||
performance data. This is the least secure mode since allowed
|
||||
monitored *scope* is maximized and no perf_events specific limits
|
||||
are imposed on *resources* allocated for performance monitoring.
|
||||
|
||||
>=0:
|
||||
*scope* includes per-process and system wide performance monitoring
|
||||
but excludes raw tracepoints and ftrace function tracepoints monitoring.
|
||||
CPU and system events happened when executing either in user or
|
||||
in kernel space can be monitored and captured for later analysis.
|
||||
Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
|
||||
ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
|
||||
but excludes raw tracepoints and ftrace function tracepoints
|
||||
monitoring. CPU and system events happened when executing either in
|
||||
user or in kernel space can be monitored and captured for later
|
||||
analysis. Per-user per-cpu perf_event_mlock_kb locking limit is
|
||||
imposed but ignored for unprivileged processes with CAP_IPC_LOCK
|
||||
[6]_ capability.
|
||||
|
||||
>=1:
|
||||
*scope* includes per-process performance monitoring only and excludes
|
||||
system wide performance monitoring. CPU and system events happened when
|
||||
executing either in user or in kernel space can be monitored and
|
||||
captured for later analysis. Per-user per-cpu perf_event_mlock_kb
|
||||
locking limit is imposed but ignored for unprivileged processes with
|
||||
CAP_IPC_LOCK capability.
|
||||
*scope* includes per-process performance monitoring only and
|
||||
excludes system wide performance monitoring. CPU and system events
|
||||
happened when executing either in user or in kernel space can be
|
||||
monitored and captured for later analysis. Per-user per-cpu
|
||||
perf_event_mlock_kb locking limit is imposed but ignored for
|
||||
unprivileged processes with CAP_IPC_LOCK capability.
|
||||
|
||||
>=2:
|
||||
*scope* includes per-process performance monitoring only. CPU and system
|
||||
events happened when executing in user space only can be monitored and
|
||||
captured for later analysis. Per-user per-cpu perf_event_mlock_kb
|
||||
locking limit is imposed but ignored for unprivileged processes with
|
||||
CAP_IPC_LOCK capability.
|
||||
*scope* includes per-process performance monitoring only. CPU and
|
||||
system events happened when executing in user space only can be
|
||||
monitored and captured for later analysis. Per-user per-cpu
|
||||
perf_event_mlock_kb locking limit is imposed but ignored for
|
||||
unprivileged processes with CAP_IPC_LOCK capability.
|
||||
|
||||
perf_events/Perf resource control
|
||||
---------------------------------
|
||||
|
||||
Open file descriptors
|
||||
+++++++++++++++++++++
|
||||
|
||||
The perf_events system call API [2]_ allocates file descriptors for
|
||||
every configured PMU event. Open file descriptors are a per-process
|
||||
accountable resource governed by the RLIMIT_NOFILE [11]_ limit
|
||||
(ulimit -n), which is usually derived from the login shell process. When
|
||||
configuring Perf collection for a long list of events on a large server
|
||||
system, this limit can be easily hit preventing required monitoring
|
||||
configuration. RLIMIT_NOFILE limit can be increased on per-user basis
|
||||
modifying content of the limits.conf file [12]_ . Ordinarily, a Perf
|
||||
sampling session (perf record) requires an amount of open perf_event
|
||||
file descriptors that is not less than the number of monitored events
|
||||
multiplied by the number of monitored CPUs.
|
||||
|
||||
Memory allocation
|
||||
+++++++++++++++++
|
||||
|
||||
The amount of memory available to user processes for capturing
|
||||
performance monitoring data is governed by the perf_event_mlock_kb [2]_
|
||||
setting. This perf_event specific resource setting defines overall
|
||||
per-cpu limits of memory allowed for mapping by the user processes to
|
||||
execute performance monitoring. The setting essentially extends the
|
||||
RLIMIT_MEMLOCK [11]_ limit, but only for memory regions mapped
|
||||
specifically for capturing monitored performance events and related data.
|
||||
|
||||
For example, if a machine has eight cores and perf_event_mlock_kb limit
|
||||
is set to 516 KiB, then a user process is provided with 516 KiB * 8 =
|
||||
4128 KiB of memory above the RLIMIT_MEMLOCK limit (ulimit -l) for
|
||||
perf_event mmap buffers. In particular, this means that, if the user
|
||||
wants to start two or more performance monitoring processes, the user is
|
||||
required to manually distribute the available 4128 KiB between the
|
||||
monitoring processes, for example, using the --mmap-pages Perf record
|
||||
mode option. Otherwise, the first started performance monitoring process
|
||||
allocates all available 4128 KiB and the other processes will fail to
|
||||
proceed due to the lack of memory.
|
||||
|
||||
RLIMIT_MEMLOCK and perf_event_mlock_kb resource constraints are ignored
|
||||
for processes with the CAP_IPC_LOCK capability. Thus, perf_events/Perf
|
||||
privileged users can be provided with memory above the constraints for
|
||||
perf_events/Perf performance monitoring purpose by providing the Perf
|
||||
executable with CAP_IPC_LOCK capability.
|
||||
|
||||
Bibliography
|
||||
------------
|
||||
|
@ -94,4 +222,9 @@ Bibliography
|
|||
.. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
|
||||
.. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
|
||||
.. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
|
||||
.. [8] `<https://en.wikipedia.org/wiki/Hardware_performance_counter>`_
|
||||
.. [9] `<https://en.wikipedia.org/wiki/Model-specific_register>`_
|
||||
.. [10] `<http://man7.org/linux/man-pages/man5/acl.5.html>`_
|
||||
.. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_
|
||||
.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_
|
||||
|
||||
|
|
|
@ -1,59 +1,164 @@
|
|||
Tainted kernels
|
||||
---------------
|
||||
|
||||
Some oops reports contain the string **'Tainted: '** after the program
|
||||
counter. This indicates that the kernel has been tainted by some
|
||||
mechanism. The string is followed by a series of position-sensitive
|
||||
characters, each representing a particular tainted value.
|
||||
The kernel will mark itself as 'tainted' when something occurs that might be
|
||||
relevant later when investigating problems. Don't worry too much about this,
|
||||
most of the time it's not a problem to run a tainted kernel; the information is
|
||||
mainly of interest once someone wants to investigate some problem, as its real
|
||||
cause might be the event that got the kernel tainted. That's why bug reports
|
||||
from tainted kernels will often be ignored by developers, hence try to reproduce
|
||||
problems with an untainted kernel.
|
||||
|
||||
1) ``G`` if all modules loaded have a GPL or compatible license, ``P`` if
|
||||
Note the kernel will remain tainted even after you undo what caused the taint
|
||||
(i.e. unload a proprietary kernel module), to indicate the kernel remains not
|
||||
trustworthy. That's also why the kernel will print the tainted state when it
|
||||
notices an internal problem (a 'kernel bug'), a recoverable error
|
||||
('kernel oops') or a non-recoverable error ('kernel panic') and writes debug
|
||||
information about this to the logs ``dmesg`` outputs. It's also possible to
|
||||
check the tainted state at runtime through a file in ``/proc/``.
|
||||
|
||||
|
||||
Tainted flag in bugs, oops or panics messages
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You find the tainted state near the top in a line starting with 'CPU:'; if or
|
||||
why the kernel was tainted is shown after the Process ID ('PID:') and a shortened
|
||||
name of the command ('Comm:') that triggered the event::
|
||||
|
||||
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
|
||||
Oops: 0002 [#1] SMP PTI
|
||||
CPU: 0 PID: 4424 Comm: insmod Tainted: P W O 4.20.0-0.rc6.fc30 #1
|
||||
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
|
||||
RIP: 0010:my_oops_init+0x13/0x1000 [kpanic]
|
||||
[...]
|
||||
|
||||
You'll find a 'Not tainted: ' there if the kernel was not tainted at the
|
||||
time of the event; if it was, then it will print 'Tainted: ' and characters
|
||||
either letters or blanks. In above example it looks like this::
|
||||
|
||||
Tainted: P W O
|
||||
|
||||
The meaning of those characters is explained in the table below. In tis case
|
||||
the kernel got tainted earlier because a proprietary Module (``P``) was loaded,
|
||||
a warning occurred (``W``), and an externally-built module was loaded (``O``).
|
||||
To decode other letters use the table below.
|
||||
|
||||
|
||||
Decoding tainted state at runtime
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
At runtime, you can query the tainted state by reading
|
||||
``cat /proc/sys/kernel/tainted``. If that returns ``0``, the kernel is not
|
||||
tainted; any other number indicates the reasons why it is. The easiest way to
|
||||
decode that number is the script ``tools/debugging/kernel-chktaint``, which your
|
||||
distribution might ship as part of a package called ``linux-tools`` or
|
||||
``kernel-tools``; if it doesn't you can download the script from
|
||||
`git.kernel.org <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/tools/debugging/kernel-chktaint>`_
|
||||
and execute it with ``sh kernel-chktaint``, which would print something like
|
||||
this on the machine that had the statements in the logs that were quoted earlier::
|
||||
|
||||
Kernel is Tainted for following reasons:
|
||||
* Proprietary module was loaded (#0)
|
||||
* Kernel issued warning (#9)
|
||||
* Externally-built ('out-of-tree') module was loaded (#12)
|
||||
See Documentation/admin-guide/tainted-kernels.rst in the the Linux kernel or
|
||||
https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html for
|
||||
a more details explanation of the various taint flags.
|
||||
Raw taint value as int/string: 4609/'P W O '
|
||||
|
||||
You can try to decode the number yourself. That's easy if there was only one
|
||||
reason that got your kernel tainted, as in this case you can find the number
|
||||
with the table below. If there were multiple reasons you need to decode the
|
||||
number, as it is a bitfield, where each bit indicates the absence or presence of
|
||||
a particular type of taint. It's best to leave that to the aforementioned
|
||||
script, but if you need something quick you can use this shell command to check
|
||||
which bits are set::
|
||||
|
||||
$ for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
|
||||
|
||||
Table for decoding tainted state
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
=== === ====== ========================================================
|
||||
Bit Log Number Reason that got the kernel tainted
|
||||
=== === ====== ========================================================
|
||||
0 G/P 1 proprietary module was loaded
|
||||
1 _/F 2 module was force loaded
|
||||
2 _/S 4 SMP kernel oops on an officially SMP incapable processor
|
||||
3 _/R 8 module was force unloaded
|
||||
4 _/M 16 processor reported a Machine Check Exception (MCE)
|
||||
5 _/B 32 bad page referenced or some unexpected page flags
|
||||
6 _/U 64 taint requested by userspace application
|
||||
7 _/D 128 kernel died recently, i.e. there was an OOPS or BUG
|
||||
8 _/A 256 ACPI table overridden by user
|
||||
9 _/W 512 kernel issued warning
|
||||
10 _/C 1024 staging driver was loaded
|
||||
11 _/I 2048 workaround for bug in platform firmware applied
|
||||
12 _/O 4096 externally-built ("out-of-tree") module was loaded
|
||||
13 _/E 8192 unsigned module was loaded
|
||||
14 _/L 16384 soft lockup occurred
|
||||
15 _/K 32768 kernel has been live patched
|
||||
16 _/X 65536 auxiliary taint, defined for and used by distros
|
||||
17 _/T 131072 kernel was built with the struct randomization plugin
|
||||
=== === ====== ========================================================
|
||||
|
||||
Note: The character ``_`` is representing a blank in this table to make reading
|
||||
easier.
|
||||
|
||||
More detailed explanation for tainting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
0) ``G`` if all modules loaded have a GPL or compatible license, ``P`` if
|
||||
any proprietary module has been loaded. Modules without a
|
||||
MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by
|
||||
insmod as GPL compatible are assumed to be proprietary.
|
||||
|
||||
2) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
|
||||
1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
|
||||
modules were loaded normally.
|
||||
|
||||
3) ``S`` if the oops occurred on an SMP kernel running on hardware that
|
||||
2) ``S`` if the oops occurred on an SMP kernel running on hardware that
|
||||
hasn't been certified as safe to run multiprocessor.
|
||||
Currently this occurs only on various Athlons that are not
|
||||
SMP capable.
|
||||
|
||||
4) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
|
||||
3) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
|
||||
modules were unloaded normally.
|
||||
|
||||
5) ``M`` if any processor has reported a Machine Check Exception,
|
||||
4) ``M`` if any processor has reported a Machine Check Exception,
|
||||
``' '`` if no Machine Check Exceptions have occurred.
|
||||
|
||||
6) ``B`` if a page-release function has found a bad page reference or
|
||||
some unexpected page flags.
|
||||
5) ``B`` If a page-release function has found a bad page reference or some
|
||||
unexpected page flags. This indicates a hardware problem or a kernel bug;
|
||||
there should be other information in the log indicating why this tainting
|
||||
occured.
|
||||
|
||||
7) ``U`` if a user or user application specifically requested that the
|
||||
6) ``U`` if a user or user application specifically requested that the
|
||||
Tainted flag be set, ``' '`` otherwise.
|
||||
|
||||
8) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG.
|
||||
7) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG.
|
||||
|
||||
9) ``A`` if the ACPI table has been overridden.
|
||||
8) ``A`` if an ACPI table has been overridden.
|
||||
|
||||
10) ``W`` if a warning has previously been issued by the kernel.
|
||||
9) ``W`` if a warning has previously been issued by the kernel.
|
||||
(Though some warnings may set more specific taint flags.)
|
||||
|
||||
11) ``C`` if a staging driver has been loaded.
|
||||
10) ``C`` if a staging driver has been loaded.
|
||||
|
||||
12) ``I`` if the kernel is working around a severe bug in the platform
|
||||
11) ``I`` if the kernel is working around a severe bug in the platform
|
||||
firmware (BIOS or similar).
|
||||
|
||||
13) ``O`` if an externally-built ("out-of-tree") module has been loaded.
|
||||
12) ``O`` if an externally-built ("out-of-tree") module has been loaded.
|
||||
|
||||
14) ``E`` if an unsigned module has been loaded in a kernel supporting
|
||||
13) ``E`` if an unsigned module has been loaded in a kernel supporting
|
||||
module signature.
|
||||
|
||||
15) ``L`` if a soft lockup has previously occurred on the system.
|
||||
14) ``L`` if a soft lockup has previously occurred on the system.
|
||||
|
||||
16) ``K`` if the kernel has been live patched.
|
||||
15) ``K`` if the kernel has been live patched.
|
||||
|
||||
The primary reason for the **'Tainted: '** string is to tell kernel
|
||||
debuggers if this is a clean kernel or if anything unusual has
|
||||
occurred. Tainting is permanent: even if an offending module is
|
||||
unloaded, the tainted value remains to indicate that the kernel is not
|
||||
trustworthy.
|
||||
16) ``X`` Auxiliary taint, defined for and used by Linux distributors.
|
||||
|
||||
17) ``T`` Kernel was build with the randstruct plugin, which can intentionally
|
||||
produce extremely unusual kernel structure layouts (even performance
|
||||
pathological ones), which is important to know when debugging. Set at
|
||||
build time.
|
||||
|
|
|
@ -6,7 +6,7 @@ TL;DR summary
|
|||
* Use only NEON instructions, or VFP instructions that don't rely on support
|
||||
code
|
||||
* Isolate your NEON code in a separate compilation unit, and compile it with
|
||||
'-mfpu=neon -mfloat-abi=softfp'
|
||||
'-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
|
||||
* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
|
||||
NEON code
|
||||
* Don't sleep in your NEON code, and be aware that it will be executed with
|
||||
|
@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken.
|
|||
Therefore, the recommended and only supported way of using NEON/VFP in the
|
||||
kernel is by adhering to the following rules:
|
||||
* isolate the NEON code in a separate compilation unit and compile it with
|
||||
'-mfpu=neon -mfloat-abi=softfp';
|
||||
'-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
|
||||
* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
|
||||
into the unit containing the NEON code from a compilation unit which is *not*
|
||||
built with the GCC flag '-mfpu=neon' set.
|
||||
|
|
|
@ -188,6 +188,11 @@ Before jumping into the kernel, the following conditions must be met:
|
|||
the kernel image will be entered must be initialised by software at a
|
||||
higher exception level to prevent execution in an UNKNOWN state.
|
||||
|
||||
- SCR_EL3.FIQ must have the same value across all CPUs the kernel is
|
||||
executing on.
|
||||
- The value of SCR_EL3.FIQ must be the same as the one present at boot
|
||||
time whenever the kernel is executing.
|
||||
|
||||
For systems with a GICv3 interrupt controller to be used in v3 mode:
|
||||
- If EL3 is present:
|
||||
ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
|
||||
|
|
|
@ -78,6 +78,11 @@ bits can vary between the two. Note that the masks apply to TTBR0
|
|||
addresses, and are not valid to apply to TTBR1 addresses (e.g. kernel
|
||||
pointers).
|
||||
|
||||
Additionally, when CONFIG_CHECKPOINT_RESTORE is also set, the kernel
|
||||
will expose the NT_ARM_PACA_KEYS and NT_ARM_PACG_KEYS regsets (struct
|
||||
user_pac_address_keys and struct user_pac_generic_keys). These can be
|
||||
used to get and set the keys for a thread.
|
||||
|
||||
|
||||
Virtualization
|
||||
--------------
|
||||
|
|
|
@ -82,3 +82,4 @@ stable kernels.
|
|||
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
|
||||
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
|
||||
| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
|
||||
| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
|
||||
|
|
|
@ -117,3 +117,28 @@ Other implications:
|
|||
size limitations and the limitations of the underlying devices. Thus
|
||||
there's no need to define ->merge_bvec_fn() callbacks for individual block
|
||||
drivers.
|
||||
|
||||
Usage of helpers:
|
||||
=================
|
||||
|
||||
* The following helpers whose names have the suffix of "_all" can only be used
|
||||
on non-BIO_CLONED bio. They are usually used by filesystem code. Drivers
|
||||
shouldn't use them because the bio may have been split before it reached the
|
||||
driver.
|
||||
|
||||
bio_for_each_segment_all()
|
||||
bio_first_bvec_all()
|
||||
bio_first_page_all()
|
||||
bio_last_bvec_all()
|
||||
|
||||
* The following helpers iterate over single-page segment. The passed 'struct
|
||||
bio_vec' will contain a single-page IO vector during the iteration
|
||||
|
||||
bio_for_each_segment()
|
||||
bio_for_each_segment_all()
|
||||
|
||||
* The following helpers iterate over multi-page bvec. The passed 'struct
|
||||
bio_vec' will contain a multi-page IO vector during the iteration
|
||||
|
||||
bio_for_each_bvec()
|
||||
rq_for_each_bvec()
|
||||
|
|
|
@ -70,7 +70,7 @@ Brief summary of control files.
|
|||
memory.soft_limit_in_bytes # set/show soft limit of memory usage
|
||||
memory.stat # show various statistics
|
||||
memory.use_hierarchy # set/show hierarchical account enabled
|
||||
memory.force_empty # trigger forced move charge to parent
|
||||
memory.force_empty # trigger forced page reclaim
|
||||
memory.pressure_level # set memory pressure notifications
|
||||
memory.swappiness # set/show swappiness parameter of vmscan
|
||||
(See sysctl's vm.swappiness)
|
||||
|
@ -459,8 +459,9 @@ About use_hierarchy, see Section 6.
|
|||
the cgroup will be reclaimed and as many pages reclaimed as possible.
|
||||
|
||||
The typical use case for this interface is before calling rmdir().
|
||||
Because rmdir() moves all pages to parent, some out-of-use page caches can be
|
||||
moved to the parent. If you want to avoid that, force_empty will be useful.
|
||||
Though rmdir() offlines memcg, but the memcg may still stay there due to
|
||||
charged file caches. Some out-of-use page caches may keep charged until
|
||||
memory pressure happens. If you want to avoid that, force_empty will be useful.
|
||||
|
||||
Also, note that when memory.kmem.limit_in_bytes is set the charges due to
|
||||
kernel pages will still be seen. This is not considered a failure and the
|
||||
|
|
|
@ -1,130 +0,0 @@
|
|||
|
||||
===================================
|
||||
Using flexible arrays in the kernel
|
||||
===================================
|
||||
|
||||
Large contiguous memory allocations can be unreliable in the Linux kernel.
|
||||
Kernel programmers will sometimes respond to this problem by allocating
|
||||
pages with :c:func:`vmalloc()`. This solution not ideal, though. On 32-bit
|
||||
systems, memory from vmalloc() must be mapped into a relatively small address
|
||||
space; it's easy to run out. On SMP systems, the page table changes required
|
||||
by vmalloc() allocations can require expensive cross-processor interrupts on
|
||||
all CPUs. And, on all systems, use of space in the vmalloc() range increases
|
||||
pressure on the translation lookaside buffer (TLB), reducing the performance
|
||||
of the system.
|
||||
|
||||
In many cases, the need for memory from vmalloc() can be eliminated by piecing
|
||||
together an array from smaller parts; the flexible array library exists to make
|
||||
this task easier.
|
||||
|
||||
A flexible array holds an arbitrary (within limits) number of fixed-sized
|
||||
objects, accessed via an integer index. Sparse arrays are handled
|
||||
reasonably well. Only single-page allocations are made, so memory
|
||||
allocation failures should be relatively rare. The down sides are that the
|
||||
arrays cannot be indexed directly, individual object size cannot exceed the
|
||||
system page size, and putting data into a flexible array requires a copy
|
||||
operation. It's also worth noting that flexible arrays do no internal
|
||||
locking at all; if concurrent access to an array is possible, then the
|
||||
caller must arrange for appropriate mutual exclusion.
|
||||
|
||||
The creation of a flexible array is done with :c:func:`flex_array_alloc()`::
|
||||
|
||||
#include <linux/flex_array.h>
|
||||
|
||||
struct flex_array *flex_array_alloc(int element_size,
|
||||
unsigned int total,
|
||||
gfp_t flags);
|
||||
|
||||
The individual object size is provided by ``element_size``, while total is the
|
||||
maximum number of objects which can be stored in the array. The flags
|
||||
argument is passed directly to the internal memory allocation calls. With
|
||||
the current code, using flags to ask for high memory is likely to lead to
|
||||
notably unpleasant side effects.
|
||||
|
||||
It is also possible to define flexible arrays at compile time with::
|
||||
|
||||
DEFINE_FLEX_ARRAY(name, element_size, total);
|
||||
|
||||
This macro will result in a definition of an array with the given name; the
|
||||
element size and total will be checked for validity at compile time.
|
||||
|
||||
Storing data into a flexible array is accomplished with a call to
|
||||
:c:func:`flex_array_put()`::
|
||||
|
||||
int flex_array_put(struct flex_array *array, unsigned int element_nr,
|
||||
void *src, gfp_t flags);
|
||||
|
||||
This call will copy the data from src into the array, in the position
|
||||
indicated by ``element_nr`` (which must be less than the maximum specified when
|
||||
the array was created). If any memory allocations must be performed, flags
|
||||
will be used. The return value is zero on success, a negative error code
|
||||
otherwise.
|
||||
|
||||
There might possibly be a need to store data into a flexible array while
|
||||
running in some sort of atomic context; in this situation, sleeping in the
|
||||
memory allocator would be a bad thing. That can be avoided by using
|
||||
``GFP_ATOMIC`` for the flags value, but, often, there is a better way. The
|
||||
trick is to ensure that any needed memory allocations are done before
|
||||
entering atomic context, using :c:func:`flex_array_prealloc()`::
|
||||
|
||||
int flex_array_prealloc(struct flex_array *array, unsigned int start,
|
||||
unsigned int nr_elements, gfp_t flags);
|
||||
|
||||
This function will ensure that memory for the elements indexed in the range
|
||||
defined by ``start`` and ``nr_elements`` has been allocated. Thereafter, a
|
||||
``flex_array_put()`` call on an element in that range is guaranteed not to
|
||||
block.
|
||||
|
||||
Getting data back out of the array is done with :c:func:`flex_array_get()`::
|
||||
|
||||
void *flex_array_get(struct flex_array *fa, unsigned int element_nr);
|
||||
|
||||
The return value is a pointer to the data element, or NULL if that
|
||||
particular element has never been allocated.
|
||||
|
||||
Note that it is possible to get back a valid pointer for an element which
|
||||
has never been stored in the array. Memory for array elements is allocated
|
||||
one page at a time; a single allocation could provide memory for several
|
||||
adjacent elements. Flexible array elements are normally initialized to the
|
||||
value ``FLEX_ARRAY_FREE`` (defined as 0x6c in <linux/poison.h>), so errors
|
||||
involving that number probably result from use of unstored array entries.
|
||||
Note that, if array elements are allocated with ``__GFP_ZERO``, they will be
|
||||
initialized to zero and this poisoning will not happen.
|
||||
|
||||
Individual elements in the array can be cleared with
|
||||
:c:func:`flex_array_clear()`::
|
||||
|
||||
int flex_array_clear(struct flex_array *array, unsigned int element_nr);
|
||||
|
||||
This function will set the given element to ``FLEX_ARRAY_FREE`` and return
|
||||
zero. If storage for the indicated element is not allocated for the array,
|
||||
``flex_array_clear()`` will return ``-EINVAL`` instead. Note that clearing an
|
||||
element does not release the storage associated with it; to reduce the
|
||||
allocated size of an array, call :c:func:`flex_array_shrink()`::
|
||||
|
||||
int flex_array_shrink(struct flex_array *array);
|
||||
|
||||
The return value will be the number of pages of memory actually freed.
|
||||
This function works by scanning the array for pages containing nothing but
|
||||
``FLEX_ARRAY_FREE`` bytes, so (1) it can be expensive, and (2) it will not work
|
||||
if the array's pages are allocated with ``__GFP_ZERO``.
|
||||
|
||||
It is possible to remove all elements of an array with a call to
|
||||
:c:func:`flex_array_free_parts()`::
|
||||
|
||||
void flex_array_free_parts(struct flex_array *array);
|
||||
|
||||
This call frees all elements, but leaves the array itself in place.
|
||||
Freeing the entire array is done with :c:func:`flex_array_free()`::
|
||||
|
||||
void flex_array_free(struct flex_array *array);
|
||||
|
||||
As of this writing, there are no users of flexible arrays in the mainline
|
||||
kernel. The functions described here are also not exported to modules;
|
||||
that will probably be fixed when somebody comes up with a need for it.
|
||||
|
||||
|
||||
Flexible array functions
|
||||
------------------------
|
||||
|
||||
.. kernel-doc:: include/linux/flex_array.h
|
12
Documentation/core-api/generic-radix-tree.rst
Normal file
12
Documentation/core-api/generic-radix-tree.rst
Normal file
|
@ -0,0 +1,12 @@
|
|||
=================================
|
||||
Generic radix trees/sparse arrays
|
||||
=================================
|
||||
|
||||
.. kernel-doc:: include/linux/generic-radix-tree.h
|
||||
:doc: Generic radix trees/sparse arrays
|
||||
|
||||
generic radix tree functions
|
||||
----------------------------
|
||||
|
||||
.. kernel-doc:: include/linux/generic-radix-tree.h
|
||||
:functions:
|
|
@ -28,6 +28,7 @@ Core utilities
|
|||
errseq
|
||||
printk-formats
|
||||
circular-buffers
|
||||
generic-radix-tree
|
||||
memory-allocation
|
||||
mm-api
|
||||
gfp_mask-from-fs-io
|
||||
|
|
|
@ -356,10 +356,6 @@ Read-Copy Update (RCU)
|
|||
|
||||
.. kernel-doc:: include/linux/rcupdate.h
|
||||
|
||||
.. kernel-doc:: include/linux/rcupdate_wait.h
|
||||
|
||||
.. kernel-doc:: include/linux/rcutree.h
|
||||
|
||||
.. kernel-doc:: kernel/rcu/tree.c
|
||||
|
||||
.. kernel-doc:: kernel/rcu/tree_plugin.h
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
.. _memory-allocation:
|
||||
.. _memory_allocation:
|
||||
|
||||
=======================
|
||||
Memory Allocation Guide
|
||||
|
@ -113,9 +113,11 @@ see :c:func:`kvmalloc_node` reference documentation. Note that
|
|||
|
||||
If you need to allocate many identical objects you can use the slab
|
||||
cache allocator. The cache should be set up with
|
||||
:c:func:`kmem_cache_create` before it can be used. Afterwards
|
||||
:c:func:`kmem_cache_alloc` and its convenience wrappers can allocate
|
||||
memory from that cache.
|
||||
:c:func:`kmem_cache_create` or :c:func:`kmem_cache_create_usercopy`
|
||||
before it can be used. The second function should be used if a part of
|
||||
the cache might be copied to the userspace. After the cache is
|
||||
created :c:func:`kmem_cache_alloc` and its convenience wrappers can
|
||||
allocate memory from that cache.
|
||||
|
||||
When the allocated memory is no longer needed it must be freed. You
|
||||
can use :c:func:`kvfree` for the memory allocated with `kmalloc`,
|
||||
|
|
|
@ -35,7 +35,7 @@ users will want to use a plain ``GFP_KERNEL``.
|
|||
:doc: Reclaim modifiers
|
||||
|
||||
.. kernel-doc:: include/linux/gfp.h
|
||||
:doc: Common combinations
|
||||
:doc: Useful GFP flag combinations
|
||||
|
||||
The Slab Cache
|
||||
==============
|
||||
|
|
|
@ -13,6 +13,10 @@ Integer types
|
|||
|
||||
If variable is of Type, use printk format specifier:
|
||||
------------------------------------------------------------
|
||||
char %hhd or %hhx
|
||||
unsigned char %hhu or %hhx
|
||||
short int %hd or %hx
|
||||
unsigned short int %hu or %hx
|
||||
int %d or %x
|
||||
unsigned int %u or %x
|
||||
long %ld or %lx
|
||||
|
@ -21,6 +25,10 @@ Integer types
|
|||
unsigned long long %llu or %llx
|
||||
size_t %zu or %zx
|
||||
ssize_t %zd or %zx
|
||||
s8 %hhd or %hhx
|
||||
u8 %hhu or %hhx
|
||||
s16 %hd or %hx
|
||||
u16 %hu or %hx
|
||||
s32 %d or %x
|
||||
u32 %u or %x
|
||||
s64 %lld or %llx
|
||||
|
|
|
@ -85,7 +85,7 @@ which was at that index; if it returns the same entry which was passed as
|
|||
|
||||
If you want to only store a new entry to an index if the current entry
|
||||
at that index is ``NULL``, you can use :c:func:`xa_insert` which
|
||||
returns ``-EEXIST`` if the entry is not empty.
|
||||
returns ``-EBUSY`` if the entry is not empty.
|
||||
|
||||
You can enquire whether a mark is set on an entry by using
|
||||
:c:func:`xa_get_mark`. If the entry is not ``NULL``, you can set a mark
|
||||
|
@ -131,17 +131,23 @@ If you use :c:func:`DEFINE_XARRAY_ALLOC` to define the XArray, or
|
|||
initialise it by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,
|
||||
the XArray changes to track whether entries are in use or not.
|
||||
|
||||
You can call :c:func:`xa_alloc` to store the entry at any unused index
|
||||
You can call :c:func:`xa_alloc` to store the entry at an unused index
|
||||
in the XArray. If you need to modify the array from interrupt context,
|
||||
you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable
|
||||
interrupts while allocating the ID.
|
||||
|
||||
Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert`
|
||||
will mark the entry as being allocated. Unlike a normal XArray, storing
|
||||
Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert` will
|
||||
also mark the entry as being allocated. Unlike a normal XArray, storing
|
||||
``NULL`` will mark the entry as being in use, like :c:func:`xa_reserve`.
|
||||
To free an entry, use :c:func:`xa_erase` (or :c:func:`xa_release` if
|
||||
you only want to free the entry if it's ``NULL``).
|
||||
|
||||
By default, the lowest free entry is allocated starting from 0. If you
|
||||
want to allocate entries starting at 1, it is more efficient to use
|
||||
:c:func:`DEFINE_XARRAY_ALLOC1` or ``XA_FLAGS_ALLOC1``. If you want to
|
||||
allocate IDs up to a maximum, then wrap back around to the lowest free
|
||||
ID, you can use :c:func:`xa_alloc_cyclic`.
|
||||
|
||||
You cannot use ``XA_MARK_0`` with an allocating XArray as this mark
|
||||
is used to track whether an entry is free or not. The other marks are
|
||||
available for your use.
|
||||
|
@ -209,7 +215,6 @@ Assumes xa_lock held on entry:
|
|||
* :c:func:`__xa_erase`
|
||||
* :c:func:`__xa_cmpxchg`
|
||||
* :c:func:`__xa_alloc`
|
||||
* :c:func:`__xa_reserve`
|
||||
* :c:func:`__xa_set_mark`
|
||||
* :c:func:`__xa_clear_mark`
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ Configure the kernel with::
|
|||
|
||||
CONFIG_KCOV=y
|
||||
|
||||
CONFIG_KCOV requires gcc built on revision 231296 or later.
|
||||
CONFIG_KCOV requires gcc 6.1.0 or later.
|
||||
|
||||
If the comparison operands need to be collected, set::
|
||||
|
||||
|
|
|
@ -206,6 +206,9 @@ Optional feature arguments are:
|
|||
in a separate btree, which improves speed of shutting
|
||||
down the cache.
|
||||
|
||||
no_discard_passdown : disable passing down discards from the cache
|
||||
to the origin's data device.
|
||||
|
||||
A policy called 'default' is always registered. This is an alias for
|
||||
the policy we currently think is giving best all round performance.
|
||||
|
||||
|
|
114
Documentation/device-mapper/dm-init.txt
Normal file
114
Documentation/device-mapper/dm-init.txt
Normal file
|
@ -0,0 +1,114 @@
|
|||
Early creation of mapped devices
|
||||
====================================
|
||||
|
||||
It is possible to configure a device-mapper device to act as the root device for
|
||||
your system in two ways.
|
||||
|
||||
The first is to build an initial ramdisk which boots to a minimal userspace
|
||||
which configures the device, then pivot_root(8) in to it.
|
||||
|
||||
The second is to create one or more device-mappers using the module parameter
|
||||
"dm-mod.create=" through the kernel boot command line argument.
|
||||
|
||||
The format is specified as a string of data separated by commas and optionally
|
||||
semi-colons, where:
|
||||
- a comma is used to separate fields like name, uuid, flags and table
|
||||
(specifies one device)
|
||||
- a semi-colon is used to separate devices.
|
||||
|
||||
So the format will look like this:
|
||||
|
||||
dm-mod.create=<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]+]
|
||||
|
||||
Where,
|
||||
<name> ::= The device name.
|
||||
<uuid> ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | ""
|
||||
<minor> ::= The device minor number | ""
|
||||
<flags> ::= "ro" | "rw"
|
||||
<table> ::= <start_sector> <num_sectors> <target_type> <target_args>
|
||||
<target_type> ::= "verity" | "linear" | ... (see list below)
|
||||
|
||||
The dm line should be equivalent to the one used by the dmsetup tool with the
|
||||
--concise argument.
|
||||
|
||||
Target types
|
||||
============
|
||||
|
||||
Not all target types are available as there are serious risks in allowing
|
||||
activation of certain DM targets without first using userspace tools to check
|
||||
the validity of associated metadata.
|
||||
|
||||
"cache": constrained, userspace should verify cache device
|
||||
"crypt": allowed
|
||||
"delay": allowed
|
||||
"era": constrained, userspace should verify metadata device
|
||||
"flakey": constrained, meant for test
|
||||
"linear": allowed
|
||||
"log-writes": constrained, userspace should verify metadata device
|
||||
"mirror": constrained, userspace should verify main/mirror device
|
||||
"raid": constrained, userspace should verify metadata device
|
||||
"snapshot": constrained, userspace should verify src/dst device
|
||||
"snapshot-origin": allowed
|
||||
"snapshot-merge": constrained, userspace should verify src/dst device
|
||||
"striped": allowed
|
||||
"switch": constrained, userspace should verify dev path
|
||||
"thin": constrained, requires dm target message from userspace
|
||||
"thin-pool": constrained, requires dm target message from userspace
|
||||
"verity": allowed
|
||||
"writecache": constrained, userspace should verify cache device
|
||||
"zero": constrained, not meant for rootfs
|
||||
|
||||
If the target is not listed above, it is constrained by default (not tested).
|
||||
|
||||
Examples
|
||||
========
|
||||
An example of booting to a linear array made up of user-mode linux block
|
||||
devices:
|
||||
|
||||
dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0
|
||||
|
||||
This will boot to a rw dm-linear target of 8192 sectors split across two block
|
||||
devices identified by their major:minor numbers. After boot, udev will rename
|
||||
this target to /dev/mapper/lroot (depending on the rules). No uuid was assigned.
|
||||
|
||||
An example of multiple device-mappers, with the dm-mod.create="..." contents is shown here
|
||||
split on multiple lines for readability:
|
||||
|
||||
vroot,,,ro,
|
||||
0 1740800 verity 254:0 254:0 1740800 sha1
|
||||
76e9be054b15884a9fa85973e9cb274c93afadb6
|
||||
5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe;
|
||||
vram,,,rw,
|
||||
0 32768 linear 1:0 0,
|
||||
32768 32768 linear 1:1 0
|
||||
|
||||
Other examples (per target):
|
||||
|
||||
"crypt":
|
||||
dm-crypt,,8,ro,
|
||||
0 1048576 crypt aes-xts-plain64
|
||||
babebabebabebabebabebabebabebabebabebabebabebabebabebabebabebabe 0
|
||||
/dev/sda 0 1 allow_discards
|
||||
|
||||
"delay":
|
||||
dm-delay,,4,ro,0 409600 delay /dev/sda1 0 500
|
||||
|
||||
"linear":
|
||||
dm-linear,,,rw,
|
||||
0 32768 linear /dev/sda1 0,
|
||||
32768 1024000 linear /dev/sda2 0,
|
||||
1056768 204800 linear /dev/sda3 0,
|
||||
1261568 512000 linear /dev/sda4 0
|
||||
|
||||
"snapshot-origin":
|
||||
dm-snap-orig,,4,ro,0 409600 snapshot-origin 8:2
|
||||
|
||||
"striped":
|
||||
dm-striped,,4,ro,0 1638400 striped 4 4096
|
||||
/dev/sda1 0 /dev/sda2 0 /dev/sda3 0 /dev/sda4 0
|
||||
|
||||
"verity":
|
||||
dm-verity,,4,ro,
|
||||
0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256
|
||||
fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd
|
||||
51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584
|
|
@ -15,7 +15,7 @@ DT_TMP_SCHEMA := processed-schema.yaml
|
|||
extra-y += $(DT_TMP_SCHEMA)
|
||||
|
||||
quiet_cmd_mk_schema = SCHEMA $@
|
||||
cmd_mk_schema = $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(filter-out FORCE, $^)
|
||||
cmd_mk_schema = $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(real-prereqs)
|
||||
|
||||
DT_DOCS = $(shell \
|
||||
cd $(srctree)/$(src) && \
|
||||
|
|
|
@ -21,7 +21,8 @@ Its subnodes can be:
|
|||
|
||||
RSTC Reset Controller required properties:
|
||||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
|
||||
<chip> can be "at91sam9260", "at91sam9g45", "sama5d3" or "samx7"
|
||||
it also can be "microchip,sam9x60-rstc"
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
|
|
|
@ -1,114 +0,0 @@
|
|||
* ARM L2 Cache Controller
|
||||
|
||||
ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/
|
||||
PL310 and variants) based level 2 cache controller. All these various implementations
|
||||
of the L2 cache controller have compatible programming models (Note 1).
|
||||
Some of the properties that are just prefixed "cache-*" are taken from section
|
||||
3.7.3 of the Devicetree Specification which can be found at:
|
||||
https://www.devicetree.org/specifications/
|
||||
|
||||
The ARM L2 cache representation in the device tree should be done as follows:
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be one of:
|
||||
"arm,pl310-cache"
|
||||
"arm,l220-cache"
|
||||
"arm,l210-cache"
|
||||
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
|
||||
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
|
||||
offset needs to be added to the address before passing down to the L2
|
||||
cache controller
|
||||
"marvell,aurora-system-cache": Marvell Controller designed to be
|
||||
compatible with the ARM one, with system cache mode (meaning
|
||||
maintenance operations on L1 are broadcasted to the L2 and L2
|
||||
performs the same operation).
|
||||
"marvell,aurora-outer-cache": Marvell Controller designed to be
|
||||
compatible with the ARM one with outer cache mode.
|
||||
"marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
|
||||
with arm,pl310-cache controller.
|
||||
- cache-unified : Specifies the cache is a unified cache.
|
||||
- cache-level : Should be set to 2 for a level 2 cache.
|
||||
- reg : Physical base address and size of cache controller's memory mapped
|
||||
registers.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
|
||||
read, write and setup latencies. Minimum valid values are 1. Controllers
|
||||
without setup latency control should use a value of 0.
|
||||
- arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
|
||||
read, write and setup latencies. Controllers without setup latency control
|
||||
should use 0. Controllers without separate read and write Tag RAM latency
|
||||
values should only use the first cell.
|
||||
- arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
|
||||
- arm,filter-ranges : <start length> Starting address and length of window to
|
||||
filter. Addresses in the filter window are directed to the M1 port. Other
|
||||
addresses will go to the M0 port.
|
||||
- arm,io-coherent : indicates that the system is operating in an hardware
|
||||
I/O coherent mode. Valid only when the arm,pl310-cache compatible
|
||||
string is used.
|
||||
- interrupts : 1 combined interrupt.
|
||||
- cache-size : specifies the size in bytes of the cache
|
||||
- cache-sets : specifies the number of associativity sets of the cache
|
||||
- cache-block-size : specifies the size in bytes of a cache block
|
||||
- cache-line-size : specifies the size in bytes of a line in the cache,
|
||||
if this is not specified, the line size is assumed to be equal to the
|
||||
cache block size
|
||||
- cache-id-part: cache id part number to be used if it is not present
|
||||
on hardware
|
||||
- wt-override: If present then L2 is forced to Write through mode
|
||||
- arm,double-linefill : Override double linefill enable setting. Enable if
|
||||
non-zero, disable if zero.
|
||||
- arm,double-linefill-incr : Override double linefill on INCR read. Enable
|
||||
if non-zero, disable if zero.
|
||||
- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
|
||||
if non-zero, disable if zero.
|
||||
- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
|
||||
disable if zero.
|
||||
- arm,prefetch-offset : Override prefetch offset value. Valid values are
|
||||
0-7, 15, 23, and 31.
|
||||
- arm,shared-override : The default behavior of the L220 or PL310 cache
|
||||
controllers with respect to the shareable attribute is to transform "normal
|
||||
memory non-cacheable transactions" into "cacheable no allocate" (for reads)
|
||||
or "write through no write allocate" (for writes).
|
||||
On systems where this may cause DMA buffer corruption, this property must be
|
||||
specified to indicate that such transforms are precluded.
|
||||
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
|
||||
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
|
||||
- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
|
||||
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
|
||||
will randomly hang unless outer sync operations are disabled.
|
||||
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
|
||||
(forcibly enable), property absent (retain settings set by firmware)
|
||||
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
|
||||
<1> (forcibly enable), property absent (retain settings set by
|
||||
firmware)
|
||||
- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
|
||||
disable), <1> (forcibly enable), property absent (OS specific behavior,
|
||||
preferably retain firmware settings)
|
||||
- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
|
||||
<1> (forcibly enable), property absent (OS specific behavior,
|
||||
preferably retain firmware settings)
|
||||
- arm,early-bresp-disable : Disable the CA9 optimization Early BRESP (PL310)
|
||||
- arm,full-line-zero-disable : Disable the CA9 optimization Full line of zero
|
||||
write (PL310)
|
||||
|
||||
Example:
|
||||
|
||||
L2: cache-controller {
|
||||
compatible = "arm,pl310-cache";
|
||||
reg = <0xfff12000 0x1000>;
|
||||
arm,data-latency = <1 1 1>;
|
||||
arm,tag-latency = <2 2 2>;
|
||||
arm,filter-ranges = <0x80000000 0x8000000>;
|
||||
cache-unified;
|
||||
cache-level = <2>;
|
||||
interrupts = <45>;
|
||||
};
|
||||
|
||||
Note 1: The description in this document doesn't apply to integrated L2
|
||||
cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
|
||||
integrated L2 controllers are assumed to be all preconfigured by
|
||||
early secure boot code. Thus no need to deal with their configuration
|
||||
in the kernel at all.
|
248
Documentation/devicetree/bindings/arm/l2c2x0.yaml
Normal file
248
Documentation/devicetree/bindings/arm/l2c2x0.yaml
Normal file
|
@ -0,0 +1,248 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/l2c2x0.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM L2 Cache Controller
|
||||
|
||||
maintainers:
|
||||
- Rob Herring <robh@kernel.org>
|
||||
|
||||
description: |+
|
||||
ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/
|
||||
PL220/PL310 and variants) based level 2 cache controller. All these various
|
||||
implementations of the L2 cache controller have compatible programming
|
||||
models (Note 1). Some of the properties that are just prefixed "cache-*" are
|
||||
taken from section 3.7.3 of the Devicetree Specification which can be found
|
||||
at:
|
||||
https://www.devicetree.org/specifications/
|
||||
|
||||
Note 1: The description in this document doesn't apply to integrated L2
|
||||
cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
|
||||
integrated L2 controllers are assumed to be all preconfigured by
|
||||
early secure boot code. Thus no need to deal with their configuration
|
||||
in the kernel at all.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/cache-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- arm,pl310-cache
|
||||
- arm,l220-cache
|
||||
- arm,l210-cache
|
||||
# DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
|
||||
- bcm,bcm11351-a2-pl310-cache
|
||||
# For Broadcom bcm11351 chipset where an
|
||||
# offset needs to be added to the address before passing down to the L2
|
||||
# cache controller
|
||||
- brcm,bcm11351-a2-pl310-cache
|
||||
# Marvell Controller designed to be
|
||||
# compatible with the ARM one, with system cache mode (meaning
|
||||
# maintenance operations on L1 are broadcasted to the L2 and L2
|
||||
# performs the same operation).
|
||||
- marvell,aurora-system-cache
|
||||
# Marvell Controller designed to be
|
||||
# compatible with the ARM one with outer cache mode.
|
||||
- marvell,aurora-outer-cache
|
||||
# Marvell Tauros3 cache controller, compatible
|
||||
# with arm,pl310-cache controller.
|
||||
- marvell,tauros3-cache
|
||||
|
||||
cache-level:
|
||||
const: 2
|
||||
|
||||
cache-unified: true
|
||||
cache-size: true
|
||||
cache-sets: true
|
||||
cache-block-size: true
|
||||
cache-line-size: true
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
arm,data-latency:
|
||||
description: Cycles of latency for Data RAM accesses. Specifies 3 cells of
|
||||
read, write and setup latencies. Minimum valid values are 1. Controllers
|
||||
without setup latency control should use a value of 0.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
- minItems: 2
|
||||
maxItems: 3
|
||||
items:
|
||||
minimum: 0
|
||||
maximum: 8
|
||||
|
||||
arm,tag-latency:
|
||||
description: Cycles of latency for Tag RAM accesses. Specifies 3 cells of
|
||||
read, write and setup latencies. Controllers without setup latency control
|
||||
should use 0. Controllers without separate read and write Tag RAM latency
|
||||
values should only use the first cell.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
- minItems: 1
|
||||
maxItems: 3
|
||||
items:
|
||||
minimum: 0
|
||||
maximum: 8
|
||||
|
||||
arm,dirty-latency:
|
||||
description: Cycles of latency for Dirty RAMs. This is a single cell.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- minimum: 1
|
||||
maximum: 8
|
||||
|
||||
arm,filter-ranges:
|
||||
description: <start length> Starting address and length of window to
|
||||
filter. Addresses in the filter window are directed to the M1 port. Other
|
||||
addresses will go to the M0 port.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
- items:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
arm,io-coherent:
|
||||
description: indicates that the system is operating in an hardware
|
||||
I/O coherent mode. Valid only when the arm,pl310-cache compatible
|
||||
string is used.
|
||||
type: boolean
|
||||
|
||||
interrupts:
|
||||
# Either a single combined interrupt or up to 9 individual interrupts
|
||||
minItems: 1
|
||||
maxItems: 9
|
||||
|
||||
cache-id-part:
|
||||
description: cache id part number to be used if it is not present
|
||||
on hardware
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
wt-override:
|
||||
description: If present then L2 is forced to Write through mode
|
||||
type: boolean
|
||||
|
||||
arm,double-linefill:
|
||||
description: Override double linefill enable setting. Enable if
|
||||
non-zero, disable if zero.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1 ]
|
||||
|
||||
arm,double-linefill-incr:
|
||||
description: Override double linefill on INCR read. Enable
|
||||
if non-zero, disable if zero.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1 ]
|
||||
|
||||
arm,double-linefill-wrap:
|
||||
description: Override double linefill on WRAP read. Enable
|
||||
if non-zero, disable if zero.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1 ]
|
||||
|
||||
arm,prefetch-drop:
|
||||
description: Override prefetch drop enable setting. Enable if non-zero,
|
||||
disable if zero.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1 ]
|
||||
|
||||
arm,prefetch-offset:
|
||||
description: Override prefetch offset value.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1, 2, 3, 4, 5, 6, 7, 15, 23, 31 ]
|
||||
|
||||
arm,shared-override:
|
||||
description: The default behavior of the L220 or PL310 cache
|
||||
controllers with respect to the shareable attribute is to transform "normal
|
||||
memory non-cacheable transactions" into "cacheable no allocate" (for reads)
|
||||
or "write through no write allocate" (for writes).
|
||||
On systems where this may cause DMA buffer corruption, this property must
|
||||
be specified to indicate that such transforms are precluded.
|
||||
type: boolean
|
||||
|
||||
arm,parity-enable:
|
||||
description: enable parity checking on the L2 cache (L220 or PL310).
|
||||
type: boolean
|
||||
|
||||
arm,parity-disable:
|
||||
description: disable parity checking on the L2 cache (L220 or PL310).
|
||||
type: boolean
|
||||
|
||||
arm,outer-sync-disable:
|
||||
description: disable the outer sync operation on the L2 cache.
|
||||
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
|
||||
will randomly hang unless outer sync operations are disabled.
|
||||
type: boolean
|
||||
|
||||
prefetch-data:
|
||||
description: |
|
||||
Data prefetch. Value: <0> (forcibly disable), <1>
|
||||
(forcibly enable), property absent (retain settings set by firmware)
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1 ]
|
||||
|
||||
prefetch-instr:
|
||||
description: |
|
||||
Instruction prefetch. Value: <0> (forcibly disable),
|
||||
<1> (forcibly enable), property absent (retain settings set by
|
||||
firmware)
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1 ]
|
||||
|
||||
arm,dynamic-clock-gating:
|
||||
description: |
|
||||
L2 dynamic clock gating. Value: <0> (forcibly
|
||||
disable), <1> (forcibly enable), property absent (OS specific behavior,
|
||||
preferably retain firmware settings)
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1 ]
|
||||
|
||||
arm,standby-mode:
|
||||
description: L2 standby mode enable. Value <0> (forcibly disable),
|
||||
<1> (forcibly enable), property absent (OS specific behavior,
|
||||
preferably retain firmware settings)
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- enum: [ 0, 1 ]
|
||||
|
||||
arm,early-bresp-disable:
|
||||
description: Disable the CA9 optimization Early BRESP (PL310)
|
||||
type: boolean
|
||||
|
||||
arm,full-line-zero-disable:
|
||||
description: Disable the CA9 optimization Full line of zero
|
||||
write (PL310)
|
||||
type: boolean
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- cache-unified
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
cache-controller@fff12000 {
|
||||
compatible = "arm,pl310-cache";
|
||||
reg = <0xfff12000 0x1000>;
|
||||
arm,data-latency = <1 1 1>;
|
||||
arm,tag-latency = <2 2 2>;
|
||||
arm,filter-ranges = <0x80000000 0x8000000>;
|
||||
cache-unified;
|
||||
cache-level = <2>;
|
||||
interrupts = <45>;
|
||||
};
|
||||
|
||||
...
|
|
@ -1,70 +0,0 @@
|
|||
* ARM Performance Monitor Units
|
||||
|
||||
ARM cores often have a PMU for counting cpu and cache events like cache misses
|
||||
and hits. The interface to the PMU is part of the ARM ARM. The ARM PMU
|
||||
representation in the device tree should be done as under:-
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be one of
|
||||
"apm,potenza-pmu"
|
||||
"arm,armv8-pmuv3"
|
||||
"arm,cortex-a73-pmu"
|
||||
"arm,cortex-a72-pmu"
|
||||
"arm,cortex-a57-pmu"
|
||||
"arm,cortex-a53-pmu"
|
||||
"arm,cortex-a35-pmu"
|
||||
"arm,cortex-a17-pmu"
|
||||
"arm,cortex-a15-pmu"
|
||||
"arm,cortex-a12-pmu"
|
||||
"arm,cortex-a9-pmu"
|
||||
"arm,cortex-a8-pmu"
|
||||
"arm,cortex-a7-pmu"
|
||||
"arm,cortex-a5-pmu"
|
||||
"arm,arm11mpcore-pmu"
|
||||
"arm,arm1176-pmu"
|
||||
"arm,arm1136-pmu"
|
||||
"brcm,vulcan-pmu"
|
||||
"cavium,thunder-pmu"
|
||||
"qcom,scorpion-pmu"
|
||||
"qcom,scorpion-mp-pmu"
|
||||
"qcom,krait-pmu"
|
||||
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
|
||||
interrupt (PPI) then 1 interrupt should be specified.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- interrupt-affinity : When using SPIs, specifies a list of phandles to CPU
|
||||
nodes corresponding directly to the affinity of
|
||||
the SPIs listed in the interrupts property.
|
||||
|
||||
When using a PPI, specifies a list of phandles to CPU
|
||||
nodes corresponding to the set of CPUs which have
|
||||
a PMU of this type signalling the PPI listed in the
|
||||
interrupts property, unless this is already specified
|
||||
by the PPI interrupt specifier itself (in which case
|
||||
the interrupt-affinity property shouldn't be present).
|
||||
|
||||
This property should be present when there is more than
|
||||
a single SPI.
|
||||
|
||||
|
||||
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
|
||||
events.
|
||||
|
||||
- secure-reg-access : Indicates that the ARMv7 Secure Debug Enable Register
|
||||
(SDER) is accessible. This will cause the driver to do
|
||||
any setup required that is only possible in ARMv7 secure
|
||||
state. If not present the ARMv7 SDER will not be touched,
|
||||
which means the PMU may fail to operate unless external
|
||||
code (bootloader or security monitor) has performed the
|
||||
appropriate initialisation. Note that this property is
|
||||
not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
|
||||
in Non-secure state.
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "arm,cortex-a9-pmu";
|
||||
interrupts = <100 101>;
|
||||
};
|
87
Documentation/devicetree/bindings/arm/pmu.yaml
Normal file
87
Documentation/devicetree/bindings/arm/pmu.yaml
Normal file
|
@ -0,0 +1,87 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/pmu.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM Performance Monitor Units
|
||||
|
||||
maintainers:
|
||||
- Mark Rutland <mark.rutland@arm.com>
|
||||
- Will Deacon <will.deacon@arm.com>
|
||||
|
||||
description: |+
|
||||
ARM cores often have a PMU for counting cpu and cache events like cache misses
|
||||
and hits. The interface to the PMU is part of the ARM ARM. The ARM PMU
|
||||
representation in the device tree should be done as under:-
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- apm,potenza-pmu
|
||||
- arm,armv8-pmuv3
|
||||
- arm,cortex-a73-pmu
|
||||
- arm,cortex-a72-pmu
|
||||
- arm,cortex-a57-pmu
|
||||
- arm,cortex-a53-pmu
|
||||
- arm,cortex-a35-pmu
|
||||
- arm,cortex-a17-pmu
|
||||
- arm,cortex-a15-pmu
|
||||
- arm,cortex-a12-pmu
|
||||
- arm,cortex-a9-pmu
|
||||
- arm,cortex-a8-pmu
|
||||
- arm,cortex-a7-pmu
|
||||
- arm,cortex-a5-pmu
|
||||
- arm,arm11mpcore-pmu
|
||||
- arm,arm1176-pmu
|
||||
- arm,arm1136-pmu
|
||||
- brcm,vulcan-pmu
|
||||
- cavium,thunder-pmu
|
||||
- qcom,scorpion-pmu
|
||||
- qcom,scorpion-mp-pmu
|
||||
- qcom,krait-pmu
|
||||
|
||||
interrupts:
|
||||
# Don't know how many CPUs, so no constraints to specify
|
||||
description: 1 per-cpu interrupt (PPI) or 1 interrupt per core.
|
||||
|
||||
interrupt-affinity:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
When using SPIs, specifies a list of phandles to CPU
|
||||
nodes corresponding directly to the affinity of
|
||||
the SPIs listed in the interrupts property.
|
||||
|
||||
When using a PPI, specifies a list of phandles to CPU
|
||||
nodes corresponding to the set of CPUs which have
|
||||
a PMU of this type signalling the PPI listed in the
|
||||
interrupts property, unless this is already specified
|
||||
by the PPI interrupt specifier itself (in which case
|
||||
the interrupt-affinity property shouldn't be present).
|
||||
|
||||
This property should be present when there is more than
|
||||
a single SPI.
|
||||
|
||||
qcom,no-pc-write:
|
||||
type: boolean
|
||||
description:
|
||||
Indicates that this PMU doesn't support the 0xc and 0xd events.
|
||||
|
||||
secure-reg-access:
|
||||
type: boolean
|
||||
description:
|
||||
Indicates that the ARMv7 Secure Debug Enable Register
|
||||
(SDER) is accessible. This will cause the driver to do
|
||||
any setup required that is only possible in ARMv7 secure
|
||||
state. If not present the ARMv7 SDER will not be touched,
|
||||
which means the PMU may fail to operate unless external
|
||||
code (bootloader or security monitor) has performed the
|
||||
appropriate initialisation. Note that this property is
|
||||
not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
|
||||
in Non-secure state.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
...
|
|
@ -2,13 +2,14 @@
|
|||
|
||||
The Actions Semi Owl Clock Management Unit generates and supplies clock
|
||||
to various controllers within the SoC. The clock binding described here is
|
||||
applicable to S900 and S700 SoC's.
|
||||
applicable to S900, S700 and S500 SoC's.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following,
|
||||
"actions,s900-cmu"
|
||||
"actions,s700-cmu"
|
||||
"actions,s500-cmu"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- clocks: Reference to the parent clocks ("hosc", "losc")
|
||||
|
@ -19,8 +20,8 @@ Each clock is assigned an identifier, and client nodes can use this identifier
|
|||
to specify the clock which they consume.
|
||||
|
||||
All available clocks are defined as preprocessor macros in corresponding
|
||||
dt-bindings/clock/actions,s900-cmu.h or actions,s700-cmu.h header and can be
|
||||
used in device tree sources.
|
||||
dt-bindings/clock/actions,s900-cmu.h or actions,s700-cmu.h or
|
||||
actions,s500-cmu.h header and can be used in device tree sources.
|
||||
|
||||
External clocks:
|
||||
|
||||
|
|
|
@ -10,6 +10,7 @@ Required Properties:
|
|||
- GXL (S905X, S905D) : "amlogic,meson-gxl-aoclkc"
|
||||
- GXM (S912) : "amlogic,meson-gxm-aoclkc"
|
||||
- AXG (A113D, A113X) : "amlogic,meson-axg-aoclkc"
|
||||
- G12A (S905X2, S905D2, S905Y2) : "amlogic,meson-g12a-aoclkc"
|
||||
followed by the common "amlogic,meson-gx-aoclkc"
|
||||
- clocks: list of clock phandle, one for each entry clock-names.
|
||||
- clock-names: should contain the following:
|
||||
|
|
|
@ -9,6 +9,7 @@ Required Properties:
|
|||
"amlogic,gxbb-clkc" for GXBB SoC,
|
||||
"amlogic,gxl-clkc" for GXL and GXM SoC,
|
||||
"amlogic,axg-clkc" for AXG SoC.
|
||||
"amlogic,g12a-clkc" for G12A SoC.
|
||||
- clocks : list of clock phandle, one for each entry clock-names.
|
||||
- clock-names : should contain the following:
|
||||
* "xtal": the platform xtal
|
||||
|
|
|
@ -50,6 +50,8 @@ Required Properties:
|
|||
IPs.
|
||||
- "samsung,exynos5433-cmu-cam1" - clock controller compatible for CMU_CAM1
|
||||
which generates clocks for Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs.
|
||||
- "samsung,exynos5433-cmu-imem" - clock controller compatible for CMU_IMEM
|
||||
which generates clocks for SSS (Security SubSystem) and SlimSSS IPs.
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
@ -168,6 +170,12 @@ Required Properties:
|
|||
- aclk_cam1_400
|
||||
- aclk_cam1_552
|
||||
|
||||
Input clocks for imem clock controller:
|
||||
- oscclk
|
||||
- aclk_imem_sssx_266
|
||||
- aclk_imem_266
|
||||
- aclk_imem_200
|
||||
|
||||
Optional properties:
|
||||
- power-domains: a phandle to respective power domain node as described by
|
||||
generic PM domain bindings (see power/power_domain.txt for more
|
||||
|
@ -469,6 +477,21 @@ Example 2: Examples of clock controller nodes are listed below.
|
|||
power-domains = <&pd_cam1>;
|
||||
};
|
||||
|
||||
cmu_imem: clock-controller@11060000 {
|
||||
compatible = "samsung,exynos5433-cmu-imem";
|
||||
reg = <0x11060000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"aclk_imem_sssx_266",
|
||||
"aclk_imem_266",
|
||||
"aclk_imem_200";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_top CLK_DIV_ACLK_IMEM_SSSX_266>,
|
||||
<&cmu_top CLK_DIV_ACLK_IMEM_266>,
|
||||
<&cmu_top CLK_DIV_ACLK_IMEM_200>;
|
||||
};
|
||||
|
||||
Example 3: UART controller node that consumes the clock generated by the clock
|
||||
controller.
|
||||
|
||||
|
|
|
@ -1,23 +0,0 @@
|
|||
Binding for simple fixed-rate clock sources.
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be "fixed-clock".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clock-frequency : frequency of clock in Hz. Should be a single cell.
|
||||
|
||||
Optional properties:
|
||||
- clock-accuracy : accuracy of clock in ppb (parts per billion).
|
||||
Should be a single cell.
|
||||
- clock-output-names : From common clock binding.
|
||||
|
||||
Example:
|
||||
clock {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <1000000000>;
|
||||
clock-accuracy = <100>;
|
||||
};
|
44
Documentation/devicetree/bindings/clock/fixed-clock.yaml
Normal file
44
Documentation/devicetree/bindings/clock/fixed-clock.yaml
Normal file
|
@ -0,0 +1,44 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Binding for simple fixed-rate clock sources
|
||||
|
||||
maintainers:
|
||||
- Michael Turquette <mturquette@baylibre.com>
|
||||
- Stephen Boyd <sboyd@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: fixed-clock
|
||||
|
||||
"#clock-cells":
|
||||
const: 0
|
||||
|
||||
clock-frequency: true
|
||||
|
||||
clock-accuracy:
|
||||
description: accuracy of clock in ppb (parts per billion).
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
clock-output-names:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
- clock-frequency
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <1000000000>;
|
||||
clock-accuracy = <100>;
|
||||
};
|
||||
...
|
|
@ -1,28 +0,0 @@
|
|||
Binding for simple fixed factor rate clock sources.
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be "fixed-factor-clock".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clock-div: fixed divider.
|
||||
- clock-mult: fixed multiplier.
|
||||
- clocks: parent clock.
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names : From common clock binding.
|
||||
|
||||
Some clocks that require special treatments are also handled by that
|
||||
driver, with the compatibles:
|
||||
- allwinner,sun4i-a10-pll3-2x-clk
|
||||
|
||||
Example:
|
||||
clock {
|
||||
compatible = "fixed-factor-clock";
|
||||
clocks = <&parentclk>;
|
||||
#clock-cells = <0>;
|
||||
clock-div = <2>;
|
||||
clock-mult = <1>;
|
||||
};
|
|
@ -0,0 +1,56 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/fixed-factor-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Binding for simple fixed factor rate clock sources
|
||||
|
||||
maintainers:
|
||||
- Michael Turquette <mturquette@baylibre.com>
|
||||
- Stephen Boyd <sboyd@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- allwinner,sun4i-a10-pll3-2x-clk
|
||||
- fixed-factor-clock
|
||||
|
||||
"#clock-cells":
|
||||
const: 0
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-div:
|
||||
description: Fixed divider
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- minimum: 1
|
||||
|
||||
clock-mult:
|
||||
description: Fixed multiplier
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
clock-output-names:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- "#clock-cells"
|
||||
- clock-div
|
||||
- clock-mult
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock {
|
||||
compatible = "fixed-factor-clock";
|
||||
clocks = <&parentclk>;
|
||||
#clock-cells = <0>;
|
||||
clock-div = <2>;
|
||||
clock-mult = <1>;
|
||||
};
|
||||
...
|
24
Documentation/devicetree/bindings/clock/fixed-mmio-clock.txt
Normal file
24
Documentation/devicetree/bindings/clock/fixed-mmio-clock.txt
Normal file
|
@ -0,0 +1,24 @@
|
|||
Binding for simple memory mapped io fixed-rate clock sources.
|
||||
The driver reads a clock frequency value from a single 32-bit memory mapped
|
||||
I/O register and registers it as a fixed rate clock.
|
||||
|
||||
It was designed for test systems, like FPGA, not for complete, finished SoCs.
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be "fixed-mmio-clock".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- reg : Address and length of the clock value register set.
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names : From common clock binding.
|
||||
|
||||
Example:
|
||||
sysclock: sysclock@fd020004 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "fixed-mmio-clock";
|
||||
reg = <0xfd020004 0x4>;
|
||||
};
|
29
Documentation/devicetree/bindings/clock/imx8mm-clock.txt
Normal file
29
Documentation/devicetree/bindings/clock/imx8mm-clock.txt
Normal file
|
@ -0,0 +1,29 @@
|
|||
* Clock bindings for NXP i.MX8M Mini
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx8mm-ccm"
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
- clocks: list of clock specifiers, must contain an entry for each required
|
||||
entry in clock-names
|
||||
- clock-names: should include the following entries:
|
||||
- "osc_32k"
|
||||
- "osc_24m"
|
||||
- "clk_ext1"
|
||||
- "clk_ext2"
|
||||
- "clk_ext3"
|
||||
- "clk_ext4"
|
||||
|
||||
clk: clock-controller@30380000 {
|
||||
compatible = "fsl,imx8mm-ccm";
|
||||
reg = <0x0 0x30380000 0x0 0x10000>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
|
||||
<&clk_ext3>, <&clk_ext4>;
|
||||
clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
|
||||
"clk_ext3", "clk_ext4";
|
||||
};
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mm-clock.h
|
||||
for the full list of i.MX8M Mini clock IDs.
|
|
@ -16,6 +16,7 @@ Required properties :
|
|||
"qcom,rpmcc-msm8974", "qcom,rpmcc"
|
||||
"qcom,rpmcc-apq8064", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8996", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8998", "qcom,rpmcc"
|
||||
"qcom,rpmcc-qcs404", "qcom,rpmcc"
|
||||
|
||||
- #clock-cells : shall contain 1
|
||||
|
|
|
@ -20,7 +20,7 @@ Example:
|
|||
backlight: backlight {
|
||||
compatible = "gpio-backlight";
|
||||
gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
|
||||
}
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
|
|
|
@ -36,7 +36,6 @@ ssd1307: oled@3c {
|
|||
reg = <0x3c>;
|
||||
pwms = <&pwm 4 3000>;
|
||||
reset-gpios = <&gpio2 7>;
|
||||
reset-active-low;
|
||||
};
|
||||
|
||||
ssd1306: oled@3c {
|
||||
|
@ -44,7 +43,6 @@ ssd1306: oled@3c {
|
|||
reg = <0x3c>;
|
||||
pwms = <&pwm 4 3000>;
|
||||
reset-gpios = <&gpio2 7>;
|
||||
reset-active-low;
|
||||
solomon,com-lrremap;
|
||||
solomon,com-invdir;
|
||||
solomon,com-offset = <32>;
|
||||
|
|
|
@ -16,6 +16,9 @@ Optional properties:
|
|||
- dma-channels: Number of DMA channels supported by the controller.
|
||||
- dma-requests: Number of DMA request signals supported by the
|
||||
controller.
|
||||
- dma-channel-mask: Bitmask of available DMA channels in ascending order
|
||||
that are not reserved by firmware and are available to
|
||||
the kernel. i.e. first channel corresponds to LSB.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -29,6 +32,7 @@ Example:
|
|||
#dma-cells = <1>;
|
||||
dma-channels = <32>;
|
||||
dma-requests = <127>;
|
||||
dma-channel-mask = <0xfffe>
|
||||
};
|
||||
|
||||
* DMA router
|
||||
|
|
57
Documentation/devicetree/bindings/dma/fsl-qdma.txt
Normal file
57
Documentation/devicetree/bindings/dma/fsl-qdma.txt
Normal file
|
@ -0,0 +1,57 @@
|
|||
NXP Layerscape SoC qDMA Controller
|
||||
==================================
|
||||
|
||||
This device follows the generic DMA bindings defined in dma/dma.txt.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be one of
|
||||
"fsl,ls1021a-qdma": for LS1021A Board
|
||||
"fsl,ls1043a-qdma": for ls1043A Board
|
||||
"fsl,ls1046a-qdma": for ls1046A Board
|
||||
- reg: Should contain the register's base address and length.
|
||||
- interrupts: Should contain a reference to the interrupt used by this
|
||||
device.
|
||||
- interrupt-names: Should contain interrupt names:
|
||||
"qdma-queue0": the block0 interrupt
|
||||
"qdma-queue1": the block1 interrupt
|
||||
"qdma-queue2": the block2 interrupt
|
||||
"qdma-queue3": the block3 interrupt
|
||||
"qdma-error": the error interrupt
|
||||
- fsl,dma-queues: Should contain number of queues supported.
|
||||
- dma-channels: Number of DMA channels supported
|
||||
- block-number: the virtual block number
|
||||
- block-offset: the offset of different virtual block
|
||||
- status-sizes: status queue size of per virtual block
|
||||
- queue-sizes: command queue size of per virtual block, the size number
|
||||
based on queues
|
||||
|
||||
Optional properties:
|
||||
|
||||
- dma-channels: Number of DMA channels supported by the controller.
|
||||
- big-endian: If present registers and hardware scatter/gather descriptors
|
||||
of the qDMA are implemented in big endian mode, otherwise in little
|
||||
mode.
|
||||
|
||||
Examples:
|
||||
|
||||
qdma: dma-controller@8390000 {
|
||||
compatible = "fsl,ls1021a-qdma";
|
||||
reg = <0x0 0x8388000 0x0 0x1000>, /* Controller regs */
|
||||
<0x0 0x8389000 0x0 0x1000>, /* Status regs */
|
||||
<0x0 0x838a000 0x0 0x2000>; /* Block regs */
|
||||
interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "qdma-error",
|
||||
"qdma-queue0", "qdma-queue1";
|
||||
dma-channels = <8>;
|
||||
block-number = <2>;
|
||||
block-offset = <0x1000>;
|
||||
fsl,dma-queues = <2>;
|
||||
status-sizes = <64>;
|
||||
queue-sizes = <64 64>;
|
||||
big-endian;
|
||||
};
|
||||
|
||||
DMA clients must use the format described in dma/dma.txt file.
|
|
@ -3,7 +3,9 @@
|
|||
See dma.txt first
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "hisilicon,k3-dma-1.0"
|
||||
- compatible: Must be one of
|
||||
- "hisilicon,k3-dma-1.0"
|
||||
- "hisilicon,hisi-pcm-asp-dma-1.0"
|
||||
- reg: Should contain DMA registers location and length.
|
||||
- interrupts: Should contain one interrupt shared by all channel
|
||||
- #dma-cells: see dma.txt, should be 1, para number
|
||||
|
|
|
@ -23,8 +23,6 @@ Deprecated properties:
|
|||
|
||||
|
||||
Optional properties:
|
||||
- is_private: The device channels should be marked as private and not for by the
|
||||
general purpose DMA channel allocator. False if not passed.
|
||||
- multi-block: Multi block transfers supported by hardware. Array property with
|
||||
one cell per channel. 0: not supported, 1 (default): supported.
|
||||
- snps,dma-protection-control: AHB HPROT[3:1] protection setting.
|
||||
|
|
|
@ -31,7 +31,7 @@ DMA clients connected to the Spreadtrum DMA controller must use the format
|
|||
described in the dma.txt file, using a two-cell specifier for each channel.
|
||||
The two cells in order are:
|
||||
1. A phandle pointing to the DMA controller.
|
||||
2. The channel id.
|
||||
2. The slave id.
|
||||
|
||||
spi0: spi@70a00000{
|
||||
...
|
||||
|
|
|
@ -37,10 +37,11 @@ Required properties:
|
|||
Required properties for VDMA:
|
||||
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
|
||||
|
||||
Optional properties:
|
||||
- xlnx,include-sg: Tells configured for Scatter-mode in
|
||||
the hardware.
|
||||
Optional properties for AXI DMA:
|
||||
- xlnx,sg-length-width: Should be set to the width in bits of the length
|
||||
register as configured in h/w. Takes values {8...26}. If the property
|
||||
is missing or invalid then the default value 23 is used. This is the
|
||||
maximum value that is supported by all IP versions.
|
||||
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
|
||||
Optional properties for VDMA:
|
||||
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
|
||||
|
|
25
Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
Normal file
25
Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
Normal file
|
@ -0,0 +1,25 @@
|
|||
Aspeed AST2500 SoC EDAC node
|
||||
|
||||
The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error
|
||||
correction check).
|
||||
|
||||
The memory controller supports SECDED (single bit error correction, double bit
|
||||
error detection) and single bit error auto scrubbing by reserving 8 bits for
|
||||
every 64 bit word (effectively reducing available memory to 8/9).
|
||||
|
||||
Note, the bootloader must configure ECC mode in the memory controller.
|
||||
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "aspeed,ast2500-sdram-edac"
|
||||
- reg: sdram controller register set should be <0x1e6e0000 0x174>
|
||||
- interrupts: should be AVIC interrupt #0
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
edac: sdram@1e6e0000 {
|
||||
compatible = "aspeed,ast2500-sdram-edac";
|
||||
reg = <0x1e6e0000 0x174>;
|
||||
interrupts = <0>;
|
||||
};
|
|
@ -75,6 +75,8 @@ Optional properties:
|
|||
|
||||
- address-width: number of address bits (one of 8, 16).
|
||||
|
||||
- num-addresses: total number of i2c slave addresses this device takes
|
||||
|
||||
Example:
|
||||
|
||||
eeprom@52 {
|
||||
|
@ -82,4 +84,5 @@ eeprom@52 {
|
|||
reg = <0x52>;
|
||||
pagesize = <32>;
|
||||
wp-gpios = <&gpio1 3 0>;
|
||||
num-addresses = <8>;
|
||||
};
|
||||
|
|
|
@ -0,0 +1,20 @@
|
|||
Gateworks PLD GPIO controller bindings
|
||||
|
||||
The GPIO controller should be a child node on an I2C bus,
|
||||
see: i2c/i2c.txt for details.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "gateworks,pld-gpio"
|
||||
- reg: I2C slave address
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
- #gpio-cells: Should be <2>. The first cell is the gpio number and
|
||||
the second cell is used to specify optional parameters.
|
||||
|
||||
Example:
|
||||
|
||||
pld@56 {
|
||||
compatible = "gateworks,pld-gpio";
|
||||
reg = <0x56>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
|
@ -33,7 +33,7 @@ Required properties:
|
|||
"sprd,sc9860-eic-latch",
|
||||
"sprd,sc9860-eic-async",
|
||||
"sprd,sc9860-eic-sync",
|
||||
"sprd,sc27xx-eic".
|
||||
"sprd,sc2731-eic".
|
||||
- reg: Define the base and range of the I/O address space containing
|
||||
the GPIO controller registers.
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
|
@ -86,7 +86,7 @@ Example:
|
|||
};
|
||||
|
||||
pmic_eic: gpio@300 {
|
||||
compatible = "sprd,sc27xx-eic";
|
||||
compatible = "sprd,sc2731-eic";
|
||||
reg = <0x300>;
|
||||
interrupt-parent = <&sc2731_pmic>;
|
||||
interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
|
|
@ -16,6 +16,7 @@ Required properties:
|
|||
nxp,pca9574
|
||||
nxp,pca9575
|
||||
nxp,pca9698
|
||||
nxp,pcal6416
|
||||
nxp,pcal6524
|
||||
nxp,pcal9555a
|
||||
maxim,max7310
|
||||
|
|
|
@ -67,6 +67,18 @@ Optional standard bitfield specifiers for the last cell:
|
|||
https://en.wikipedia.org/wiki/Open_collector
|
||||
- Bit 3: 0 means the output should be maintained during sleep/low-power mode
|
||||
1 means the output state can be lost during sleep/low-power mode
|
||||
- Bit 4: 0 means no pull-up resistor should be enabled
|
||||
1 means a pull-up resistor should be enabled
|
||||
This setting only applies to hardware with a simple on/off
|
||||
control for pull-up configuration. If the hardware has more
|
||||
elaborate pull-up configuration, it should be represented
|
||||
using a pin control binding.
|
||||
- Bit 5: 0 means no pull-down resistor should be enabled
|
||||
1 means a pull-down resistor should be enabled
|
||||
This setting only applies to hardware with a simple on/off
|
||||
control for pull-down configuration. If the hardware has more
|
||||
elaborate pull-down configuration, it should be represented
|
||||
using a pin control binding.
|
||||
|
||||
1.1) GPIO specifier best practices
|
||||
----------------------------------
|
||||
|
|
38
Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.txt
Normal file
38
Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.txt
Normal file
|
@ -0,0 +1,38 @@
|
|||
Intel IXP4xx XScale Networking Processors GPIO
|
||||
|
||||
This GPIO controller is found in the Intel IXP4xx processors.
|
||||
It supports 16 GPIO lines.
|
||||
|
||||
The interrupt portions of the GPIO controller is hierarchical:
|
||||
the synchronous edge detector is part of the GPIO block, but the
|
||||
actual enabling/disabling of the interrupt line is done in the
|
||||
main IXP4xx interrupt controller which has a 1:1 mapping for
|
||||
the first 12 GPIO lines to 12 system interrupts.
|
||||
|
||||
The remaining 4 GPIO lines can not be used for receiving
|
||||
interrupts.
|
||||
|
||||
The interrupt parent of this GPIO controller must be the
|
||||
IXP4xx interrupt controller.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be
|
||||
"intel,ixp4xx-gpio"
|
||||
- reg : Should contain registers location and length
|
||||
- gpio-controller : marks this as a GPIO controller
|
||||
- #gpio-cells : Should be 2, see gpio/gpio.txt
|
||||
- interrupt-controller : marks this as an interrupt controller
|
||||
- #interrupt-cells : a standard two-cell interrupt, see
|
||||
interrupt-controller/interrupts.txt
|
||||
|
||||
Example:
|
||||
|
||||
gpio0: gpio@c8004000 {
|
||||
compatible = "intel,ixp4xx-gpio";
|
||||
reg = <0xc8004000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
|
@ -26,7 +26,7 @@ Required node properties:
|
|||
|
||||
Optional node properties:
|
||||
|
||||
- ti,mode: Operation mode (see above).
|
||||
- ti,mode: Operation mode (u8) (see above).
|
||||
|
||||
|
||||
Example (operation mode 2):
|
||||
|
@ -34,5 +34,5 @@ Example (operation mode 2):
|
|||
adc128d818@1d {
|
||||
compatible = "ti,adc128d818";
|
||||
reg = <0x1d>;
|
||||
ti,mode = <2>;
|
||||
ti,mode = /bits/ 8 <2>;
|
||||
};
|
||||
|
|
20
Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt
Normal file
20
Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt
Normal file
|
@ -0,0 +1,20 @@
|
|||
i2c Controller on XScale platforms such as IOP3xx and IXP4xx
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be one of
|
||||
"intel,iop3xx-i2c"
|
||||
"intel,ixp4xx-i2c";
|
||||
- reg
|
||||
- #address-cells = <1>;
|
||||
- #size-cells = <0>;
|
||||
|
||||
Optional properties:
|
||||
- Child nodes conforming to i2c bus binding
|
||||
|
||||
Example:
|
||||
|
||||
i2c@c8011000 {
|
||||
compatible = "intel,ixp4xx-i2c";
|
||||
reg = <0xc8011000 0x18>;
|
||||
interrupts = <33 IRQ_TYPE_LEVEL_LOW>;
|
||||
};
|
|
@ -10,6 +10,7 @@ Required properties:
|
|||
"mediatek,mt6589-i2c": for MediaTek MT6589
|
||||
"mediatek,mt7622-i2c": for MediaTek MT7622
|
||||
"mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623
|
||||
"mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629
|
||||
"mediatek,mt8173-i2c": for MediaTek MT8173
|
||||
- reg: physical base address of the controller and dma base, length of memory
|
||||
mapped region.
|
21
Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
Normal file
21
Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
Normal file
|
@ -0,0 +1,21 @@
|
|||
STMPE ADC driver
|
||||
----------------
|
||||
|
||||
Required properties:
|
||||
- compatible: "st,stmpe-adc"
|
||||
|
||||
Optional properties:
|
||||
Note that the ADC is shared with the STMPE touchscreen. ADC related settings
|
||||
have to be done in the mfd.
|
||||
- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
|
||||
requestable due to different usage (e.g. touch)
|
||||
|
||||
Node name must be stmpe_adc and should be child node of stmpe node to
|
||||
which it belongs.
|
||||
|
||||
Example:
|
||||
|
||||
stmpe_adc {
|
||||
compatible = "st,stmpe-adc";
|
||||
st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
|
||||
};
|
|
@ -1,13 +1,19 @@
|
|||
Samsung tm2-touchkey
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "cypress,tm2-touchkey"
|
||||
- compatible:
|
||||
* "cypress,tm2-touchkey" - for the touchkey found on the tm2 board
|
||||
* "cypress,midas-touchkey" - for the touchkey found on midas boards
|
||||
* "cypress,aries-touchkey" - for the touchkey found on aries boards
|
||||
- reg: I2C address of the chip.
|
||||
- interrupts: interrupt to which the chip is connected (see interrupt
|
||||
binding[0]).
|
||||
- vcc-supply : internal regulator output. 1.8V
|
||||
- vdd-supply : power supply for IC 3.3V
|
||||
|
||||
Optional properties:
|
||||
- linux,keycodes: array of keycodes (max 4), default KEY_PHONE and KEY_BACK
|
||||
|
||||
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
|
||||
|
||||
Example:
|
||||
|
@ -21,5 +27,6 @@ Example:
|
|||
interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
|
||||
vcc-supply=<&ldo32_reg>;
|
||||
vdd-supply=<&ldo33_reg>;
|
||||
linux,keycodes = <KEY_PHONE KEY_BACK>;
|
||||
};
|
||||
};
|
||||
|
|
25
Documentation/devicetree/bindings/input/ilitek,ili2xxx.txt
Normal file
25
Documentation/devicetree/bindings/input/ilitek,ili2xxx.txt
Normal file
|
@ -0,0 +1,25 @@
|
|||
Ilitek ILI210x/ILI251x touchscreen controller
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
ilitek,ili210x for ILI210x
|
||||
ilitek,ili251x for ILI251x
|
||||
|
||||
- reg: The I2C address of the device
|
||||
|
||||
- interrupts: The sink for the touchscreen's IRQ output
|
||||
See ../interrupt-controller/interrupts.txt
|
||||
|
||||
Optional properties for main touchpad device:
|
||||
|
||||
- reset-gpios: GPIO specifier for the touchscreen's reset pin (active low)
|
||||
|
||||
Example:
|
||||
|
||||
touchscreen@41 {
|
||||
compatible = "ilitek,ili251x";
|
||||
reg = <0x41>;
|
||||
interrupt-parent = <&gpio4>;
|
||||
interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
|
||||
reset-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
|
||||
};
|
36
Documentation/devicetree/bindings/input/msm-vibrator.txt
Normal file
36
Documentation/devicetree/bindings/input/msm-vibrator.txt
Normal file
|
@ -0,0 +1,36 @@
|
|||
* Device tree bindings for the Qualcomm MSM vibrator
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be one of
|
||||
"qcom,msm8226-vibrator"
|
||||
"qcom,msm8974-vibrator"
|
||||
- reg: the base address and length of the IO memory for the registers.
|
||||
- pinctrl-names: set to default.
|
||||
- pinctrl-0: phandles pointing to pin configuration nodes. See
|
||||
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
|
||||
- clock-names: set to pwm
|
||||
- clocks: phandle of the clock. See
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
- enable-gpios: GPIO that enables the vibrator.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- vcc-supply: phandle to the regulator that provides power to the sensor.
|
||||
|
||||
Example from a LG Nexus 5 (hammerhead) phone:
|
||||
|
||||
vibrator@fd8c3450 {
|
||||
reg = <0xfd8c3450 0x400>;
|
||||
compatible = "qcom,msm8974-vibrator";
|
||||
|
||||
vcc-supply = <&pm8941_l19>;
|
||||
|
||||
clocks = <&mmcc CAMSS_GP1_CLK>;
|
||||
clock-names = "pwm";
|
||||
|
||||
enable-gpios = <&msmgpio 60 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&vibrator_pin>;
|
||||
};
|
28
Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
Normal file
28
Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
Normal file
|
@ -0,0 +1,28 @@
|
|||
STMicroelectronics STPMIC1 Onkey
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible = "st,stpmic1-onkey";
|
||||
- interrupts: interrupt line to use
|
||||
- interrupt-names = "onkey-falling", "onkey-rising"
|
||||
onkey-falling: happens when onkey is pressed; IT_PONKEY_F of pmic
|
||||
onkey-rising: happens when onkey is released; IT_PONKEY_R of pmic
|
||||
|
||||
Optional properties:
|
||||
|
||||
- st,onkey-clear-cc-flag: onkey is able power on after an
|
||||
over-current shutdown event.
|
||||
- st,onkey-pu-inactive: onkey pull up is not active
|
||||
- power-off-time-sec: Duration in seconds which the key should be kept
|
||||
pressed for device to power off automatically (from 1 to 16 seconds).
|
||||
see See Documentation/devicetree/bindings/input/keys.txt
|
||||
|
||||
Example:
|
||||
|
||||
onkey {
|
||||
compatible = "st,stpmic1-onkey";
|
||||
interrupt-parent = <&pmic>;
|
||||
interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>;
|
||||
interrupt-names = "onkey-falling", "onkey-rising";
|
||||
power-off-time-sec = <10>;
|
||||
};
|
|
@ -1,11 +1,12 @@
|
|||
FocalTech EDT-FT5x06 Polytouch driver
|
||||
=====================================
|
||||
|
||||
There are 3 variants of the chip for various touch panel sizes
|
||||
There are 5 variants of the chip for various touch panel sizes
|
||||
FT5206GE1 2.8" .. 3.8"
|
||||
FT5306DE4 4.3" .. 7"
|
||||
FT5406EE8 7" .. 8.9"
|
||||
FT5506EEG 7" .. 8.9"
|
||||
FT5726NEI 5.7” .. 11.6"
|
||||
|
||||
The software interface is identical for all those chips, so that
|
||||
currently there is no need for the driver to distinguish between the
|
||||
|
@ -19,6 +20,7 @@ Required properties:
|
|||
or: "edt,edt-ft5306"
|
||||
or: "edt,edt-ft5406"
|
||||
or: "edt,edt-ft5506"
|
||||
or: "evervision,ev-ft5726"
|
||||
or: "focaltech,ft6236"
|
||||
|
||||
- reg: I2C slave address of the chip (0x38)
|
||||
|
@ -42,6 +44,15 @@ Optional properties:
|
|||
|
||||
- offset: allows setting the edge compensation in the range from
|
||||
0 to 31.
|
||||
|
||||
- offset-x: Same as offset, but applies only to the horizontal position.
|
||||
Range from 0 to 80, only supported by evervision,ev-ft5726
|
||||
devices.
|
||||
|
||||
- offset-y: Same as offset, but applies only to the vertical position.
|
||||
Range from 0 to 80, only supported by evervision,ev-ft5726
|
||||
devices.
|
||||
|
||||
- touchscreen-size-x : See touchscreen.txt
|
||||
- touchscreen-size-y : See touchscreen.txt
|
||||
- touchscreen-fuzz-x : See touchscreen.txt
|
||||
|
|
|
@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen controller
|
|||
Required properties:
|
||||
|
||||
- compatible : Should be "goodix,gt1151"
|
||||
or "goodix,gt5688"
|
||||
or "goodix,gt911"
|
||||
or "goodix,gt9110"
|
||||
or "goodix,gt912"
|
||||
|
@ -18,11 +19,14 @@ Optional properties:
|
|||
- irq-gpios : GPIO pin used for IRQ. The driver uses the
|
||||
interrupt gpio pin as output to reset the device.
|
||||
- reset-gpios : GPIO pin used for reset
|
||||
- touchscreen-inverted-x
|
||||
- touchscreen-inverted-y
|
||||
- touchscreen-size-x
|
||||
- touchscreen-size-y
|
||||
- touchscreen-swapped-x-y
|
||||
|
||||
- touchscreen-inverted-x : X axis is inverted (boolean)
|
||||
- touchscreen-inverted-y : Y axis is inverted (boolean)
|
||||
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
|
||||
(swapping is done after inverting the axis)
|
||||
The touchscreen-* properties are documented in touchscreen.txt in this
|
||||
directory.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
@ -1,13 +1,17 @@
|
|||
* Sitronix st1232 touchscreen controller
|
||||
* Sitronix st1232 or st1633 touchscreen controller
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "sitronix,st1232"
|
||||
- compatible: must contain one of
|
||||
* "sitronix,st1232"
|
||||
* "sitronix,st1633"
|
||||
- reg: I2C address of the chip
|
||||
- interrupts: interrupt to which the chip is connected
|
||||
|
||||
Optional properties:
|
||||
- gpios: a phandle to the reset GPIO
|
||||
|
||||
For additional optional properties see: touchscreen.txt
|
||||
|
||||
Example:
|
||||
|
||||
i2c@00000000 {
|
||||
|
|
|
@ -5,39 +5,105 @@ Required properties:
|
|||
- compatible: "st,stmpe-ts"
|
||||
|
||||
Optional properties:
|
||||
- st,sample-time: ADC converstion time in number of clock. (0 -> 36 clocks, 1 ->
|
||||
44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96 clocks, 6
|
||||
-> 144 clocks), recommended is 4.
|
||||
- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
|
||||
- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
|
||||
reference)
|
||||
- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 MHz)
|
||||
- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 -> 4
|
||||
samples, 3 -> 8 samples)
|
||||
- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us, 2 ->
|
||||
100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms) recommended
|
||||
is 3
|
||||
- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 -> 500 us, 3
|
||||
-> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is 2
|
||||
- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) = Count of
|
||||
the fractional part) recommended is 7
|
||||
- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA typical 35
|
||||
mA max, 1 -> 50 mA typical 80 mA max)
|
||||
- st,ave-ctrl : Sample average control
|
||||
0 -> 1 sample
|
||||
1 -> 2 samples
|
||||
2 -> 4 samples
|
||||
3 -> 8 samples
|
||||
- st,touch-det-delay : Touch detect interrupt delay (recommended is 3)
|
||||
0 -> 10 us
|
||||
1 -> 50 us
|
||||
2 -> 100 us
|
||||
3 -> 500 us
|
||||
4 -> 1 ms
|
||||
5 -> 5 ms
|
||||
6 -> 10 ms
|
||||
7 -> 50 ms
|
||||
- st,settling : Panel driver settling time (recommended is 2)
|
||||
0 -> 10 us
|
||||
1 -> 100 us
|
||||
2 -> 500 us
|
||||
3 -> 1 ms
|
||||
4 -> 5 ms
|
||||
5 -> 10 ms
|
||||
6 -> 50 ms
|
||||
7 -> 100 ms
|
||||
- st,fraction-z : Length of the fractional part in z (recommended is 7)
|
||||
(fraction-z ([0..7]) = Count of the fractional part)
|
||||
- st,i-drive : current limit value of the touchscreen drivers
|
||||
0 -> 20 mA (typical 35mA max)
|
||||
1 -> 50 mA (typical 80 mA max)
|
||||
|
||||
Optional properties common with MFD (deprecated):
|
||||
- st,sample-time : ADC conversion time in number of clock.
|
||||
0 -> 36 clocks
|
||||
1 -> 44 clocks
|
||||
2 -> 56 clocks
|
||||
3 -> 64 clocks
|
||||
4 -> 80 clocks (recommended)
|
||||
5 -> 96 clocks
|
||||
6 -> 124 clocks
|
||||
- st,mod-12b : ADC Bit mode
|
||||
0 -> 10bit ADC
|
||||
1 -> 12bit ADC
|
||||
- st,ref-sel : ADC reference source
|
||||
0 -> internal
|
||||
1 -> external
|
||||
- st,adc-freq : ADC Clock speed
|
||||
0 -> 1.625 MHz
|
||||
1 -> 3.25 MHz
|
||||
2 || 3 -> 6.5 MHz
|
||||
|
||||
Node name must be stmpe_touchscreen and should be child node of stmpe node to
|
||||
which it belongs.
|
||||
|
||||
Note that common ADC settings of stmpe_touchscreen (child) will take precedence
|
||||
over the settings done in MFD.
|
||||
|
||||
Example:
|
||||
|
||||
stmpe811@41 {
|
||||
compatible = "st,stmpe811";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_touch_int>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x41>;
|
||||
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-parent = <&gpio4>;
|
||||
interrupt-controller;
|
||||
id = <0>;
|
||||
blocks = <0x5>;
|
||||
irq-trigger = <0x1>;
|
||||
/* Common ADC settings */
|
||||
/* 3.25 MHz ADC clock speed */
|
||||
st,adc-freq = <1>;
|
||||
/* 12-bit ADC */
|
||||
st,mod-12b = <1>;
|
||||
/* internal ADC reference */
|
||||
st,ref-sel = <0>;
|
||||
/* ADC converstion time: 80 clocks */
|
||||
st,sample-time = <4>;
|
||||
|
||||
stmpe_touchscreen {
|
||||
compatible = "st,stmpe-ts";
|
||||
st,sample-time = <4>;
|
||||
st,mod-12b = <1>;
|
||||
st,ref-sel = <0>;
|
||||
st,adc-freq = <1>;
|
||||
st,ave-ctrl = <1>;
|
||||
st,touch-det-delay = <2>;
|
||||
st,settling = <2>;
|
||||
reg = <0>;
|
||||
/* 8 sample average control */
|
||||
st,ave-ctrl = <3>;
|
||||
/* 5 ms touch detect interrupt delay */
|
||||
st,touch-det-delay = <5>;
|
||||
/* 1 ms panel driver settling time */
|
||||
st,settling = <3>;
|
||||
/* 7 length fractional part in z */
|
||||
st,fraction-z = <7>;
|
||||
/*
|
||||
* 50 mA typical 80 mA max touchscreen drivers
|
||||
* current limit value
|
||||
*/
|
||||
st,i-drive = <1>;
|
||||
};
|
||||
stmpe_adc {
|
||||
compatible = "st,stmpe-adc";
|
||||
st,norequest-mask = <0x0F>;
|
||||
};
|
||||
};
|
||||
|
|
|
@ -1,10 +1,17 @@
|
|||
* Semtech SX8654 I2C Touchscreen Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "semtech,sx8654"
|
||||
- compatible: must be one of the following, depending on the model:
|
||||
"semtech,sx8650"
|
||||
"semtech,sx8654"
|
||||
"semtech,sx8655"
|
||||
"semtech,sx8656"
|
||||
- reg: i2c slave address
|
||||
- interrupts: touch controller interrupt
|
||||
|
||||
Optional properties:
|
||||
- reset-gpios: GPIO specification for the NRST input
|
||||
|
||||
Example:
|
||||
|
||||
sx8654@48 {
|
||||
|
@ -12,4 +19,5 @@ Example:
|
|||
reg = <0x48>;
|
||||
interrupt-parent = <&gpio6>;
|
||||
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
|
||||
reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
|
||||
};
|
||||
|
|
|
@ -1,175 +0,0 @@
|
|||
* ARM Generic Interrupt Controller, version 3
|
||||
|
||||
AArch64 SMP cores are often associated with a GICv3, providing Private
|
||||
Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
|
||||
Software Generated Interrupts (SGI), and Locality-specific Peripheral
|
||||
Interrupts (LPI).
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should at least contain "arm,gic-v3" or either
|
||||
"qcom,msm8996-gic-v3", "arm,gic-v3" for msm8996 SoCs
|
||||
to address SoC specific bugs/quirks
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. Must be a single cell with a value of at least 3.
|
||||
If the system requires describing PPI affinity, then the value must
|
||||
be at least 4.
|
||||
|
||||
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
|
||||
interrupts. Other values are reserved for future use.
|
||||
|
||||
The 2nd cell contains the interrupt number for the interrupt type.
|
||||
SPI interrupts are in the range [0-987]. PPI interrupts are in the
|
||||
range [0-15].
|
||||
|
||||
The 3rd cell is the flags, encoded as follows:
|
||||
bits[3:0] trigger type and level flags.
|
||||
1 = edge triggered
|
||||
4 = level triggered
|
||||
|
||||
The 4th cell is a phandle to a node describing a set of CPUs this
|
||||
interrupt is affine to. The interrupt must be a PPI, and the node
|
||||
pointed must be a subnode of the "ppi-partitions" subnode. For
|
||||
interrupt types other than PPI or PPIs that are not partitionned,
|
||||
this cell must be zero. See the "ppi-partitions" node description
|
||||
below.
|
||||
|
||||
Cells 5 and beyond are reserved for future use and must have a value
|
||||
of 0 if present.
|
||||
|
||||
- reg : Specifies base physical address(s) and size of the GIC
|
||||
registers, in the following order:
|
||||
- GIC Distributor interface (GICD)
|
||||
- GIC Redistributors (GICR), one range per redistributor region
|
||||
- GIC CPU interface (GICC)
|
||||
- GIC Hypervisor interface (GICH)
|
||||
- GIC Virtual CPU interface (GICV)
|
||||
|
||||
GICC, GICH and GICV are optional.
|
||||
|
||||
- interrupts : Interrupt source of the VGIC maintenance interrupt.
|
||||
|
||||
Optional
|
||||
|
||||
- redistributor-stride : If using padding pages, specifies the stride
|
||||
of consecutive redistributors. Must be a multiple of 64kB.
|
||||
|
||||
- #redistributor-regions: The number of independent contiguous regions
|
||||
occupied by the redistributors. Required if more than one such
|
||||
region is present.
|
||||
|
||||
- msi-controller: Boolean property. Identifies the node as an MSI
|
||||
controller. Only present if the Message Based Interrupt
|
||||
functionnality is being exposed by the HW, and the mbi-ranges
|
||||
property present.
|
||||
|
||||
- mbi-ranges: A list of pairs <intid span>, where "intid" is the first
|
||||
SPI of a range that can be used an MBI, and "span" the size of that
|
||||
range. Multiple ranges can be provided. Requires "msi-controller" to
|
||||
be set.
|
||||
|
||||
- mbi-alias: Address property. Base address of an alias of the GICD
|
||||
region containing only the {SET,CLR}SPI registers to be used if
|
||||
isolation is required, and if supported by the HW.
|
||||
|
||||
Sub-nodes:
|
||||
|
||||
PPI affinity can be expressed as a single "ppi-partitions" node,
|
||||
containing a set of sub-nodes, each with the following property:
|
||||
- affinity: Should be a list of phandles to CPU nodes (as described in
|
||||
Documentation/devicetree/bindings/arm/cpus.yaml).
|
||||
|
||||
GICv3 has one or more Interrupt Translation Services (ITS) that are
|
||||
used to route Message Signalled Interrupts (MSI) to the CPUs.
|
||||
|
||||
These nodes must have the following properties:
|
||||
- compatible : Should at least contain "arm,gic-v3-its".
|
||||
- msi-controller : Boolean property. Identifies the node as an MSI controller
|
||||
- #msi-cells: Must be <1>. The single msi-cell is the DeviceID of the device
|
||||
which will generate the MSI.
|
||||
- reg: Specifies the base physical address and size of the ITS
|
||||
registers.
|
||||
|
||||
Optional:
|
||||
- socionext,synquacer-pre-its: (u32, u32) tuple describing the untranslated
|
||||
address and size of the pre-ITS window.
|
||||
|
||||
The main GIC node must contain the appropriate #address-cells,
|
||||
#size-cells and ranges properties for the reg property of all ITS
|
||||
nodes.
|
||||
|
||||
Examples:
|
||||
|
||||
gic: interrupt-controller@2cf00000 {
|
||||
compatible = "arm,gic-v3";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
ranges;
|
||||
interrupt-controller;
|
||||
reg = <0x0 0x2f000000 0 0x10000>, // GICD
|
||||
<0x0 0x2f100000 0 0x200000>, // GICR
|
||||
<0x0 0x2c000000 0 0x2000>, // GICC
|
||||
<0x0 0x2c010000 0 0x2000>, // GICH
|
||||
<0x0 0x2c020000 0 0x2000>; // GICV
|
||||
interrupts = <1 9 4>;
|
||||
|
||||
msi-controller;
|
||||
mbi-ranges = <256 128>;
|
||||
|
||||
gic-its@2c200000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c200000 0 0x20000>;
|
||||
};
|
||||
};
|
||||
|
||||
gic: interrupt-controller@2c010000 {
|
||||
compatible = "arm,gic-v3";
|
||||
#interrupt-cells = <4>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
ranges;
|
||||
interrupt-controller;
|
||||
redistributor-stride = <0x0 0x40000>; // 256kB stride
|
||||
#redistributor-regions = <2>;
|
||||
reg = <0x0 0x2c010000 0 0x10000>, // GICD
|
||||
<0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31
|
||||
<0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63
|
||||
<0x0 0x2c040000 0 0x2000>, // GICC
|
||||
<0x0 0x2c060000 0 0x2000>, // GICH
|
||||
<0x0 0x2c080000 0 0x2000>; // GICV
|
||||
interrupts = <1 9 4>;
|
||||
|
||||
gic-its@2c200000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c200000 0 0x20000>;
|
||||
};
|
||||
|
||||
gic-its@2c400000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c400000 0 0x20000>;
|
||||
};
|
||||
|
||||
ppi-partitions {
|
||||
part0: interrupt-partition-0 {
|
||||
affinity = <&cpu0 &cpu2>;
|
||||
};
|
||||
|
||||
part1: interrupt-partition-1 {
|
||||
affinity = <&cpu1 &cpu3>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
device@0 {
|
||||
reg = <0 0 0 4>;
|
||||
interrupts = <1 1 4 &part0>;
|
||||
};
|
|
@ -0,0 +1,279 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interrupt-controller/arm,gic-v3.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM Generic Interrupt Controller, version 3
|
||||
|
||||
maintainers:
|
||||
- Marc Zyngier <marc.zyngier@arm.com>
|
||||
|
||||
description: |
|
||||
AArch64 SMP cores are often associated with a GICv3, providing Private
|
||||
Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
|
||||
Software Generated Interrupts (SGI), and Locality-specific Peripheral
|
||||
Interrupts (LPI).
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/interrupt-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,msm8996-gic-v3
|
||||
- const: arm,gic-v3
|
||||
- const: arm,gic-v3
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
"#address-cells":
|
||||
enum: [ 0, 1, 2 ]
|
||||
"#size-cells":
|
||||
enum: [ 1, 2 ]
|
||||
|
||||
ranges: true
|
||||
|
||||
"#interrupt-cells":
|
||||
description: |
|
||||
Specifies the number of cells needed to encode an interrupt source.
|
||||
Must be a single cell with a value of at least 3.
|
||||
If the system requires describing PPI affinity, then the value must
|
||||
be at least 4.
|
||||
|
||||
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
|
||||
interrupts. Other values are reserved for future use.
|
||||
|
||||
The 2nd cell contains the interrupt number for the interrupt type.
|
||||
SPI interrupts are in the range [0-987]. PPI interrupts are in the
|
||||
range [0-15].
|
||||
|
||||
The 3rd cell is the flags, encoded as follows:
|
||||
bits[3:0] trigger type and level flags.
|
||||
1 = edge triggered
|
||||
4 = level triggered
|
||||
|
||||
The 4th cell is a phandle to a node describing a set of CPUs this
|
||||
interrupt is affine to. The interrupt must be a PPI, and the node
|
||||
pointed must be a subnode of the "ppi-partitions" subnode. For
|
||||
interrupt types other than PPI or PPIs that are not partitionned,
|
||||
this cell must be zero. See the "ppi-partitions" node description
|
||||
below.
|
||||
|
||||
Cells 5 and beyond are reserved for future use and must have a value
|
||||
of 0 if present.
|
||||
enum: [ 3, 4 ]
|
||||
|
||||
reg:
|
||||
description: |
|
||||
Specifies base physical address(s) and size of the GIC
|
||||
registers, in the following order:
|
||||
- GIC Distributor interface (GICD)
|
||||
- GIC Redistributors (GICR), one range per redistributor region
|
||||
- GIC CPU interface (GICC)
|
||||
- GIC Hypervisor interface (GICH)
|
||||
- GIC Virtual CPU interface (GICV)
|
||||
|
||||
GICC, GICH and GICV are optional.
|
||||
minItems: 2
|
||||
maxItems: 4096 # Should be enough?
|
||||
|
||||
interrupts:
|
||||
description:
|
||||
Interrupt source of the VGIC maintenance interrupt.
|
||||
maxItems: 1
|
||||
|
||||
redistributor-stride:
|
||||
description:
|
||||
If using padding pages, specifies the stride of consecutive
|
||||
redistributors. Must be a multiple of 64kB.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint64
|
||||
- multipleOf: 0x10000
|
||||
exclusiveMinimum: 0
|
||||
|
||||
"#redistributor-regions":
|
||||
description:
|
||||
The number of independent contiguous regions occupied by the
|
||||
redistributors. Required if more than one such region is present.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- maximum: 4096 # Should be enough?
|
||||
|
||||
msi-controller:
|
||||
description:
|
||||
Only present if the Message Based Interrupt functionnality is
|
||||
being exposed by the HW, and the mbi-ranges property present.
|
||||
|
||||
mbi-ranges:
|
||||
description:
|
||||
A list of pairs <intid span>, where "intid" is the first SPI of a range
|
||||
that can be used an MBI, and "span" the size of that range. Multiple
|
||||
ranges can be provided.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
- items:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
mbi-alias:
|
||||
description:
|
||||
Address property. Base address of an alias of the GICD region containing
|
||||
only the {SET,CLR}SPI registers to be used if isolation is required,
|
||||
and if supported by the HW.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
- items:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
ppi-partitions:
|
||||
type: object
|
||||
description:
|
||||
PPI affinity can be expressed as a single "ppi-partitions" node,
|
||||
containing a set of sub-nodes.
|
||||
patternProperties:
|
||||
"^interrupt-partition-[0-9]+$":
|
||||
properties:
|
||||
affinity:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
Should be a list of phandles to CPU nodes (as described in
|
||||
Documentation/devicetree/bindings/arm/cpus.yaml).
|
||||
|
||||
required:
|
||||
- affinity
|
||||
|
||||
dependencies:
|
||||
mbi-ranges: [ msi-controller ]
|
||||
msi-controller: [ mbi-ranges ]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- interrupts
|
||||
- reg
|
||||
|
||||
patternProperties:
|
||||
"^gic-its@": false
|
||||
"^interrupt-controller@[0-9a-f]+$": false
|
||||
# msi-controller is preferred, but allow other names
|
||||
"^(msi-controller|gic-its|interrupt-controller)@[0-9a-f]+$":
|
||||
type: object
|
||||
description:
|
||||
GICv3 has one or more Interrupt Translation Services (ITS) that are
|
||||
used to route Message Signalled Interrupts (MSI) to the CPUs.
|
||||
properties:
|
||||
compatible:
|
||||
const: arm,gic-v3-its
|
||||
|
||||
msi-controller: true
|
||||
|
||||
"#msi-cells":
|
||||
description:
|
||||
The single msi-cell is the DeviceID of the device which will generate
|
||||
the MSI.
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
description:
|
||||
Specifies the base physical address and size of the ITS registers.
|
||||
maxItems: 1
|
||||
|
||||
socionext,synquacer-pre-its:
|
||||
description:
|
||||
(u32, u32) tuple describing the untranslated
|
||||
address and size of the pre-ITS window.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
- items:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- msi-controller
|
||||
- "#msi-cells"
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
gic: interrupt-controller@2cf00000 {
|
||||
compatible = "arm,gic-v3";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
interrupt-controller;
|
||||
reg = <0x2f000000 0x10000>, // GICD
|
||||
<0x2f100000 0x200000>, // GICR
|
||||
<0x2c000000 0x2000>, // GICC
|
||||
<0x2c010000 0x2000>, // GICH
|
||||
<0x2c020000 0x2000>; // GICV
|
||||
interrupts = <1 9 4>;
|
||||
|
||||
msi-controller;
|
||||
mbi-ranges = <256 128>;
|
||||
|
||||
msi-controller@2c200000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x2c200000 0x20000>;
|
||||
};
|
||||
};
|
||||
|
||||
interrupt-controller@2c010000 {
|
||||
compatible = "arm,gic-v3";
|
||||
#interrupt-cells = <4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
interrupt-controller;
|
||||
redistributor-stride = <0x0 0x40000>; // 256kB stride
|
||||
#redistributor-regions = <2>;
|
||||
reg = <0x2c010000 0x10000>, // GICD
|
||||
<0x2d000000 0x800000>, // GICR 1: CPUs 0-31
|
||||
<0x2e000000 0x800000>, // GICR 2: CPUs 32-63
|
||||
<0x2c040000 0x2000>, // GICC
|
||||
<0x2c060000 0x2000>, // GICH
|
||||
<0x2c080000 0x2000>; // GICV
|
||||
interrupts = <1 9 4>;
|
||||
|
||||
msi-controller@2c200000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x2c200000 0x20000>;
|
||||
};
|
||||
|
||||
msi-controller@2c400000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x2c400000 0x20000>;
|
||||
};
|
||||
|
||||
ppi-partitions {
|
||||
part0: interrupt-partition-0 {
|
||||
affinity = <&cpu0 &cpu2>;
|
||||
};
|
||||
|
||||
part1: interrupt-partition-1 {
|
||||
affinity = <&cpu1 &cpu3>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
device@0 {
|
||||
reg = <0 4>;
|
||||
interrupts = <1 1 4 &part0>;
|
||||
};
|
||||
|
||||
...
|
|
@ -1,171 +0,0 @@
|
|||
* ARM Generic Interrupt Controller
|
||||
|
||||
ARM SMP cores are often associated with a GIC, providing per processor
|
||||
interrupts (PPI), shared processor interrupts (SPI) and software
|
||||
generated interrupts (SGI).
|
||||
|
||||
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
|
||||
Secondary GICs are cascaded into the upward interrupt controller and do not
|
||||
have PPIs or SGIs.
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should be one of:
|
||||
"arm,arm1176jzf-devchip-gic"
|
||||
"arm,arm11mp-gic"
|
||||
"arm,cortex-a15-gic"
|
||||
"arm,cortex-a7-gic"
|
||||
"arm,cortex-a9-gic"
|
||||
"arm,eb11mp-gic"
|
||||
"arm,gic-400"
|
||||
"arm,pl390"
|
||||
"arm,tc11mp-gic"
|
||||
"brcm,brahma-b15-gic"
|
||||
"nvidia,tegra210-agic"
|
||||
"qcom,msm-8660-qgic"
|
||||
"qcom,msm-qgic2"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 3.
|
||||
|
||||
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
|
||||
interrupts.
|
||||
|
||||
The 2nd cell contains the interrupt number for the interrupt type.
|
||||
SPI interrupts are in the range [0-987]. PPI interrupts are in the
|
||||
range [0-15].
|
||||
|
||||
The 3rd cell is the flags, encoded as follows:
|
||||
bits[3:0] trigger type and level flags.
|
||||
1 = low-to-high edge triggered
|
||||
2 = high-to-low edge triggered (invalid for SPIs)
|
||||
4 = active high level-sensitive
|
||||
8 = active low level-sensitive (invalid for SPIs).
|
||||
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
|
||||
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
|
||||
the interrupt is wired to that CPU. Only valid for PPI interrupts.
|
||||
Also note that the configurability of PPI interrupts is IMPLEMENTATION
|
||||
DEFINED and as such not guaranteed to be present (most SoC available
|
||||
in 2014 seem to ignore the setting of this flag and use the hardware
|
||||
default value).
|
||||
|
||||
- reg : Specifies base physical address(s) and size of the GIC registers. The
|
||||
first region is the GIC distributor register base and size. The 2nd region is
|
||||
the GIC cpu interface register base and size.
|
||||
|
||||
Optional
|
||||
- interrupts : Interrupt source of the parent interrupt controller on
|
||||
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
|
||||
below).
|
||||
|
||||
- cpu-offset : per-cpu offset within the distributor and cpu interface
|
||||
regions, used when the GIC doesn't have banked registers. The offset is
|
||||
cpu-offset * cpu-nr.
|
||||
|
||||
- clocks : List of phandle and clock-specific pairs, one for each entry
|
||||
in clock-names.
|
||||
- clock-names : List of names for the GIC clock input(s). Valid clock names
|
||||
depend on the GIC variant:
|
||||
"ic_clk" (for "arm,arm11mp-gic")
|
||||
"PERIPHCLKEN" (for "arm,cortex-a15-gic")
|
||||
"PERIPHCLK", "PERIPHCLKEN" (for "arm,cortex-a9-gic")
|
||||
"clk" (for "arm,gic-400" and "nvidia,tegra210")
|
||||
"gclk" (for "arm,pl390")
|
||||
|
||||
- power-domains : A phandle and PM domain specifier as defined by bindings of
|
||||
the power controller specified by phandle, used when the GIC
|
||||
is part of a Power or Clock Domain.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@fff11000 {
|
||||
compatible = "arm,cortex-a9-gic";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <1>;
|
||||
interrupt-controller;
|
||||
reg = <0xfff11000 0x1000>,
|
||||
<0xfff10100 0x100>;
|
||||
};
|
||||
|
||||
|
||||
* GIC virtualization extensions (VGIC)
|
||||
|
||||
For ARM cores that support the virtualization extensions, additional
|
||||
properties must be described (they only exist if the GIC is the
|
||||
primary interrupt controller).
|
||||
|
||||
Required properties:
|
||||
|
||||
- reg : Additional regions specifying the base physical address and
|
||||
size of the VGIC registers. The first additional region is the GIC
|
||||
virtual interface control register base and size. The 2nd additional
|
||||
region is the GIC virtual cpu interface register base and size.
|
||||
|
||||
- interrupts : VGIC maintenance interrupt.
|
||||
|
||||
Example:
|
||||
|
||||
interrupt-controller@2c001000 {
|
||||
compatible = "arm,cortex-a15-gic";
|
||||
#interrupt-cells = <3>;
|
||||
interrupt-controller;
|
||||
reg = <0x2c001000 0x1000>,
|
||||
<0x2c002000 0x2000>,
|
||||
<0x2c004000 0x2000>,
|
||||
<0x2c006000 0x2000>;
|
||||
interrupts = <1 9 0xf04>;
|
||||
};
|
||||
|
||||
|
||||
* GICv2m extension for MSI/MSI-x support (Optional)
|
||||
|
||||
Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s).
|
||||
This is enabled by specifying v2m sub-node(s).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : The value here should contain "arm,gic-v2m-frame".
|
||||
|
||||
- msi-controller : Identifies the node as an MSI controller.
|
||||
|
||||
- reg : GICv2m MSI interface register base and size
|
||||
|
||||
Optional properties:
|
||||
|
||||
- arm,msi-base-spi : When the MSI_TYPER register contains an incorrect
|
||||
value, this property should contain the SPI base of
|
||||
the MSI frame, overriding the HW value.
|
||||
|
||||
- arm,msi-num-spis : When the MSI_TYPER register contains an incorrect
|
||||
value, this property should contain the number of
|
||||
SPIs assigned to the frame, overriding the HW value.
|
||||
|
||||
Example:
|
||||
|
||||
interrupt-controller@e1101000 {
|
||||
compatible = "arm,gic-400";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
interrupt-controller;
|
||||
interrupts = <1 8 0xf04>;
|
||||
ranges = <0 0 0 0xe1100000 0 0x100000>;
|
||||
reg = <0x0 0xe1110000 0 0x01000>,
|
||||
<0x0 0xe112f000 0 0x02000>,
|
||||
<0x0 0xe1140000 0 0x10000>,
|
||||
<0x0 0xe1160000 0 0x10000>;
|
||||
v2m0: v2m@8000 {
|
||||
compatible = "arm,gic-v2m-frame";
|
||||
msi-controller;
|
||||
reg = <0x0 0x80000 0 0x1000>;
|
||||
};
|
||||
|
||||
....
|
||||
|
||||
v2mN: v2m@9000 {
|
||||
compatible = "arm,gic-v2m-frame";
|
||||
msi-controller;
|
||||
reg = <0x0 0x90000 0 0x1000>;
|
||||
};
|
||||
};
|
|
@ -0,0 +1,223 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interrupt-controller/arm,gic.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM Generic Interrupt Controller v1 and v2
|
||||
|
||||
maintainers:
|
||||
- Marc Zyngier <marc.zyngier@arm.com>
|
||||
|
||||
description: |+
|
||||
ARM SMP cores are often associated with a GIC, providing per processor
|
||||
interrupts (PPI), shared processor interrupts (SPI) and software
|
||||
generated interrupts (SGI).
|
||||
|
||||
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
|
||||
Secondary GICs are cascaded into the upward interrupt controller and do not
|
||||
have PPIs or SGIs.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/interrupt-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- arm,arm11mp-gic
|
||||
- arm,cortex-a15-gic
|
||||
- arm,cortex-a7-gic
|
||||
- arm,cortex-a5-gic
|
||||
- arm,cortex-a9-gic
|
||||
- arm,eb11mp-gic
|
||||
- arm,gic-400
|
||||
- arm,pl390
|
||||
- arm,tc11mp-gic
|
||||
- nvidia,tegra210-agic
|
||||
- qcom,msm-8660-qgic
|
||||
- qcom,msm-qgic2
|
||||
|
||||
- items:
|
||||
- const: arm,arm1176jzf-devchip-gic
|
||||
- const: arm,arm11mp-gic
|
||||
|
||||
- items:
|
||||
- const: brcm,brahma-b15-gic
|
||||
- const: arm,cortex-a15-gic
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
"#address-cells":
|
||||
enum: [ 0, 1 ]
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
"#interrupt-cells":
|
||||
const: 3
|
||||
description: |
|
||||
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
|
||||
interrupts.
|
||||
|
||||
The 2nd cell contains the interrupt number for the interrupt type.
|
||||
SPI interrupts are in the range [0-987]. PPI interrupts are in the
|
||||
range [0-15].
|
||||
|
||||
The 3rd cell is the flags, encoded as follows:
|
||||
bits[3:0] trigger type and level flags.
|
||||
1 = low-to-high edge triggered
|
||||
2 = high-to-low edge triggered (invalid for SPIs)
|
||||
4 = active high level-sensitive
|
||||
8 = active low level-sensitive (invalid for SPIs).
|
||||
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
|
||||
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
|
||||
the interrupt is wired to that CPU. Only valid for PPI interrupts.
|
||||
Also note that the configurability of PPI interrupts is IMPLEMENTATION
|
||||
DEFINED and as such not guaranteed to be present (most SoC available
|
||||
in 2014 seem to ignore the setting of this flag and use the hardware
|
||||
default value).
|
||||
|
||||
reg:
|
||||
description: |
|
||||
Specifies base physical address(s) and size of the GIC registers. The
|
||||
first region is the GIC distributor register base and size. The 2nd region
|
||||
is the GIC cpu interface register base and size.
|
||||
|
||||
For GICv2 with virtualization extensions, additional regions are
|
||||
required for specifying the base physical address and size of the VGIC
|
||||
registers. The first additional region is the GIC virtual interface
|
||||
control register base and size. The 2nd additional region is the GIC
|
||||
virtual cpu interface register base and size.
|
||||
minItems: 2
|
||||
maxItems: 4
|
||||
|
||||
interrupts:
|
||||
description: Interrupt source of the parent interrupt controller on
|
||||
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
|
||||
below).
|
||||
maxItems: 1
|
||||
|
||||
cpu-offset:
|
||||
description: per-cpu offset within the distributor and cpu interface
|
||||
regions, used when the GIC doesn't have banked registers. The offset
|
||||
is cpu-offset * cpu-nr.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
description: List of names for the GIC clock input(s). Valid clock names
|
||||
depend on the GIC variant.
|
||||
oneOf:
|
||||
- const: ic_clk # for "arm,arm11mp-gic"
|
||||
- const: PERIPHCLKEN # for "arm,cortex-a15-gic"
|
||||
- items: # for "arm,cortex-a9-gic"
|
||||
- const: PERIPHCLK
|
||||
- const: PERIPHCLKEN
|
||||
- const: clk # for "arm,gic-400" and "nvidia,tegra210"
|
||||
- const: gclk #for "arm,pl390"
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
patternProperties:
|
||||
"^v2m@[0-9a-f]+$":
|
||||
description: |
|
||||
* GICv2m extension for MSI/MSI-x support (Optional)
|
||||
|
||||
Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s).
|
||||
This is enabled by specifying v2m sub-node(s).
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: arm,gic-v2m-frame
|
||||
|
||||
msi-controller: true
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
description: GICv2m MSI interface register base and size
|
||||
|
||||
arm,msi-base-spi:
|
||||
description: When the MSI_TYPER register contains an incorrect value,
|
||||
this property should contain the SPI base of the MSI frame, overriding
|
||||
the HW value.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
arm,msi-num-spis:
|
||||
description: When the MSI_TYPER register contains an incorrect value,
|
||||
this property should contain the number of SPIs assigned to the
|
||||
frame, overriding the HW value.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- msi-controller
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// GICv1
|
||||
intc: interrupt-controller@fff11000 {
|
||||
compatible = "arm,cortex-a9-gic";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <1>;
|
||||
interrupt-controller;
|
||||
reg = <0xfff11000 0x1000>,
|
||||
<0xfff10100 0x100>;
|
||||
};
|
||||
|
||||
- |
|
||||
// GICv2
|
||||
interrupt-controller@2c001000 {
|
||||
compatible = "arm,cortex-a15-gic";
|
||||
#interrupt-cells = <3>;
|
||||
interrupt-controller;
|
||||
reg = <0x2c001000 0x1000>,
|
||||
<0x2c002000 0x2000>,
|
||||
<0x2c004000 0x2000>,
|
||||
<0x2c006000 0x2000>;
|
||||
interrupts = <1 9 0xf04>;
|
||||
};
|
||||
|
||||
- |
|
||||
// GICv2m extension for MSI/MSI-x support
|
||||
interrupt-controller@e1101000 {
|
||||
compatible = "arm,gic-400";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
interrupt-controller;
|
||||
interrupts = <1 8 0xf04>;
|
||||
ranges = <0 0 0 0xe1100000 0 0x100000>;
|
||||
reg = <0x0 0xe1110000 0 0x01000>,
|
||||
<0x0 0xe112f000 0 0x02000>,
|
||||
<0x0 0xe1140000 0 0x10000>,
|
||||
<0x0 0xe1160000 0 0x10000>;
|
||||
|
||||
v2m0: v2m@8000 {
|
||||
compatible = "arm,gic-v2m-frame";
|
||||
msi-controller;
|
||||
reg = <0x0 0x80000 0 0x1000>;
|
||||
};
|
||||
|
||||
//...
|
||||
|
||||
v2mN: v2m@9000 {
|
||||
compatible = "arm,gic-v2m-frame";
|
||||
msi-controller;
|
||||
reg = <0x0 0x90000 0 0x1000>;
|
||||
};
|
||||
};
|
||||
...
|
|
@ -16,6 +16,7 @@ Required properties:
|
|||
- "renesas,irqc-r8a7793" (R-Car M2-N)
|
||||
- "renesas,irqc-r8a7794" (R-Car E2)
|
||||
- "renesas,intc-ex-r8a774a1" (RZ/G2M)
|
||||
- "renesas,intc-ex-r8a774c0" (RZ/G2E)
|
||||
- "renesas,intc-ex-r8a7795" (R-Car H3)
|
||||
- "renesas,intc-ex-r8a7796" (R-Car M3-W)
|
||||
- "renesas,intc-ex-r8a77965" (R-Car M3-N)
|
||||
|
|
|
@ -1,14 +0,0 @@
|
|||
NVIDIA Tegra 20 GART
|
||||
|
||||
Required properties:
|
||||
- compatible: "nvidia,tegra20-gart"
|
||||
- reg: Two pairs of cells specifying the physical address and size of
|
||||
the memory controller registers and the GART aperture respectively.
|
||||
|
||||
Example:
|
||||
|
||||
gart {
|
||||
compatible = "nvidia,tegra20-gart";
|
||||
reg = <0x7000f024 0x00000018 /* controller registers */
|
||||
0x58000000 0x02000000>; /* GART aperture */
|
||||
};
|
|
@ -0,0 +1,127 @@
|
|||
Xilinx IPI Mailbox Controller
|
||||
========================================
|
||||
|
||||
The Xilinx IPI(Inter Processor Interrupt) mailbox controller is to manage
|
||||
messaging between two Xilinx Zynq UltraScale+ MPSoC IPI agents. Each IPI
|
||||
agent owns registers used for notification and buffers for message.
|
||||
|
||||
+-------------------------------------+
|
||||
| Xilinx ZynqMP IPI Controller |
|
||||
+-------------------------------------+
|
||||
+--------------------------------------------------+
|
||||
ATF | |
|
||||
| |
|
||||
| |
|
||||
+--------------------------+ |
|
||||
| |
|
||||
| |
|
||||
+--------------------------------------------------+
|
||||
+------------------------------------------+
|
||||
| +----------------+ +----------------+ |
|
||||
Hardware | | IPI Agent | | IPI Buffers | |
|
||||
| | Registers | | | |
|
||||
| | | | | |
|
||||
| +----------------+ +----------------+ |
|
||||
| |
|
||||
| Xilinx IPI Agent Block |
|
||||
+------------------------------------------+
|
||||
|
||||
|
||||
Controller Device Node:
|
||||
===========================
|
||||
Required properties:
|
||||
--------------------
|
||||
IPI agent node:
|
||||
- compatible: Shall be: "xlnx,zynqmp-ipi-mailbox"
|
||||
- interrupt-parent: Phandle for the interrupt controller
|
||||
- interrupts: Interrupt information corresponding to the
|
||||
interrupt-names property.
|
||||
- xlnx,ipi-id: local Xilinx IPI agent ID
|
||||
- #address-cells: number of address cells of internal IPI mailbox nodes
|
||||
- #size-cells: number of size cells of internal IPI mailbox nodes
|
||||
|
||||
Internal IPI mailbox node:
|
||||
- reg: IPI buffers address ranges
|
||||
- reg-names: Names of the reg resources. It should have:
|
||||
* local_request_region
|
||||
- IPI request msg buffer written by local and read
|
||||
by remote
|
||||
* local_response_region
|
||||
- IPI response msg buffer written by local and read
|
||||
by remote
|
||||
* remote_request_region
|
||||
- IPI request msg buffer written by remote and read
|
||||
by local
|
||||
* remote_response_region
|
||||
- IPI response msg buffer written by remote and read
|
||||
by local
|
||||
- #mbox-cells: Shall be 1. It contains:
|
||||
* tx(0) or rx(1) channel
|
||||
- xlnx,ipi-id: remote Xilinx IPI agent ID of which the mailbox is
|
||||
connected to.
|
||||
|
||||
Optional properties:
|
||||
--------------------
|
||||
- method: The method of accessing the IPI agent registers.
|
||||
Permitted values are: "smc" and "hvc". Default is
|
||||
"smc".
|
||||
|
||||
Client Device Node:
|
||||
===========================
|
||||
Required properties:
|
||||
--------------------
|
||||
- mboxes: Standard property to specify a mailbox
|
||||
(See ./mailbox.txt)
|
||||
- mbox-names: List of identifier strings for each mailbox
|
||||
channel.
|
||||
|
||||
Example:
|
||||
===========================
|
||||
zynqmp_ipi {
|
||||
compatible = "xlnx,zynqmp-ipi-mailbox";
|
||||
interrupt-parent = <&gic>;
|
||||
interrupts = <0 29 4>;
|
||||
xlnx,ipi-id = <0>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
/* APU<->RPU0 IPI mailbox controller */
|
||||
ipi_mailbox_rpu0: mailbox@ff90400 {
|
||||
reg = <0xff990400 0x20>,
|
||||
<0xff990420 0x20>,
|
||||
<0xff990080 0x20>,
|
||||
<0xff9900a0 0x20>;
|
||||
reg-names = "local_request_region",
|
||||
"local_response_region",
|
||||
"remote_request_region",
|
||||
"remote_response_region";
|
||||
#mbox-cells = <1>;
|
||||
xlnx,ipi-id = <1>;
|
||||
};
|
||||
/* APU<->RPU1 IPI mailbox controller */
|
||||
ipi_mailbox_rpu1: mailbox@ff990440 {
|
||||
reg = <0xff990440 0x20>,
|
||||
<0xff990460 0x20>,
|
||||
<0xff990280 0x20>,
|
||||
<0xff9902a0 0x20>;
|
||||
reg-names = "local_request_region",
|
||||
"local_response_region",
|
||||
"remote_request_region",
|
||||
"remote_response_region";
|
||||
#mbox-cells = <1>;
|
||||
xlnx,ipi-id = <2>;
|
||||
};
|
||||
};
|
||||
rpu0 {
|
||||
...
|
||||
mboxes = <&ipi_mailbox_rpu0 0>,
|
||||
<&ipi_mailbox_rpu0 1>;
|
||||
mbox-names = "tx", "rx";
|
||||
};
|
||||
rpu1 {
|
||||
...
|
||||
mboxes = <&ipi_mailbox_rpu1 0>,
|
||||
<&ipi_mailbox_rpu1 1>;
|
||||
mbox-names = "tx", "rx";
|
||||
};
|
|
@ -48,7 +48,16 @@ are numbered as follows.
|
|||
TXA source 10
|
||||
TXB source 11
|
||||
|
||||
The digital output port nodes must contain at least one endpoint.
|
||||
The digital output port nodes, when present, shall contain at least one
|
||||
endpoint. Each of those endpoints shall contain the data-lanes property as
|
||||
described in video-interfaces.txt.
|
||||
|
||||
Required source endpoint properties:
|
||||
- data-lanes: an array of physical data lane indexes
|
||||
The accepted value(s) for this property depends on which of the two
|
||||
sources are described. For TXA 1, 2 or 4 data lanes can be described
|
||||
while for TXB only 1 data lane is valid. See video-interfaces.txt
|
||||
for detailed description.
|
||||
|
||||
Ports are optional if they are not connected to anything at the hardware level.
|
||||
|
||||
|
|
|
@ -0,0 +1,20 @@
|
|||
* Melexis MLX90640 FIR Sensor
|
||||
|
||||
Melexis MLX90640 FIR sensor support which allows recording of thermal data
|
||||
with 32x24 resolution excluding 2 lines of coefficient data that is used by
|
||||
userspace to render processed frames.
|
||||
|
||||
Required Properties:
|
||||
- compatible : Must be "melexis,mlx90640"
|
||||
- reg : i2c address of the device
|
||||
|
||||
Example:
|
||||
|
||||
i2c0@1c22000 {
|
||||
...
|
||||
mlx90640@33 {
|
||||
compatible = "melexis,mlx90640";
|
||||
reg = <0x33>;
|
||||
};
|
||||
...
|
||||
};
|
38
Documentation/devicetree/bindings/media/i2c/mt9m001.txt
Normal file
38
Documentation/devicetree/bindings/media/i2c/mt9m001.txt
Normal file
|
@ -0,0 +1,38 @@
|
|||
MT9M001: 1/2-Inch Megapixel Digital Image Sensor
|
||||
|
||||
The MT9M001 is an SXGA-format with a 1/2-inch CMOS active-pixel digital
|
||||
image sensor. It is programmable through I2C interface.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: shall be "onnn,mt9m001".
|
||||
- clocks: reference to the master clock into sensor
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- reset-gpios: GPIO handle which is connected to the reset pin of the chip.
|
||||
Active low.
|
||||
- standby-gpios: GPIO handle which is connected to the standby pin of the chip.
|
||||
Active high.
|
||||
|
||||
The device node must contain one 'port' child node with one 'endpoint' child
|
||||
sub-node for its digital output video port, in accordance with the video
|
||||
interface bindings defined in:
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
|
||||
Example:
|
||||
|
||||
&i2c1 {
|
||||
camera-sensor@5d {
|
||||
compatible = "onnn,mt9m001";
|
||||
reg = <0x5d>;
|
||||
reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
|
||||
standby-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
|
||||
clocks = <&camera_clk>;
|
||||
port {
|
||||
mt9m001_out: endpoint {
|
||||
remote-endpoint = <&vcap_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
|
@ -26,9 +26,9 @@ Example:
|
|||
&i2c1 {
|
||||
...
|
||||
|
||||
ov5645: ov5645@78 {
|
||||
ov5645: ov5645@3c {
|
||||
compatible = "ovti,ov5645";
|
||||
reg = <0x78>;
|
||||
reg = <0x3c>;
|
||||
|
||||
enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
|
||||
|
@ -37,7 +37,7 @@ Example:
|
|||
|
||||
clocks = <&clks 200>;
|
||||
clock-names = "xclk";
|
||||
clock-frequency = <23880000>;
|
||||
clock-frequency = <24000000>;
|
||||
|
||||
vdddo-supply = <&camera_dovdd_1v8>;
|
||||
vdda-supply = <&camera_avdd_2v8>;
|
||||
|
|
45
Documentation/devicetree/bindings/media/imx7-csi.txt
Normal file
45
Documentation/devicetree/bindings/media/imx7-csi.txt
Normal file
|
@ -0,0 +1,45 @@
|
|||
Freescale i.MX7 CMOS Sensor Interface
|
||||
=====================================
|
||||
|
||||
csi node
|
||||
--------
|
||||
|
||||
This is device node for the CMOS Sensor Interface (CSI) which enables the chip
|
||||
to connect directly to external CMOS image sensors.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "fsl,imx7-csi";
|
||||
- reg : base address and length of the register set for the device;
|
||||
- interrupts : should contain CSI interrupt;
|
||||
- clocks : list of clock specifiers, see
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
|
||||
- clock-names : must contain "axi", "mclk" and "dcic" entries, matching
|
||||
entries in the clock property;
|
||||
|
||||
The device node shall contain one 'port' child node with one child 'endpoint'
|
||||
node, according to the bindings defined in:
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
In the following example a remote endpoint is a video multiplexer.
|
||||
|
||||
example:
|
||||
|
||||
csi: csi@30710000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
compatible = "fsl,imx7-csi";
|
||||
reg = <0x30710000 0x10000>;
|
||||
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clks IMX7D_CLK_DUMMY>,
|
||||
<&clks IMX7D_CSI_MCLK_ROOT_CLK>,
|
||||
<&clks IMX7D_CLK_DUMMY>;
|
||||
clock-names = "axi", "mclk", "dcic";
|
||||
|
||||
port {
|
||||
csi_from_csi_mux: endpoint {
|
||||
remote-endpoint = <&csi_mux_to_csi>;
|
||||
};
|
||||
};
|
||||
};
|
90
Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
Normal file
90
Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
Normal file
|
@ -0,0 +1,90 @@
|
|||
Freescale i.MX7 Mipi CSI2
|
||||
=========================
|
||||
|
||||
mipi_csi2 node
|
||||
--------------
|
||||
|
||||
This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
|
||||
compatible with previous version of Samsung D-phy.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "fsl,imx7-mipi-csi2";
|
||||
- reg : base address and length of the register set for the device;
|
||||
- interrupts : should contain MIPI CSIS interrupt;
|
||||
- clocks : list of clock specifiers, see
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
|
||||
- clock-names : must contain "pclk", "wrap" and "phy" entries, matching
|
||||
entries in the clock property;
|
||||
- power-domains : a phandle to the power domain, see
|
||||
Documentation/devicetree/bindings/power/power_domain.txt for details.
|
||||
- reset-names : should include following entry "mrst";
|
||||
- resets : a list of phandle, should contain reset entry of
|
||||
reset-names;
|
||||
- phy-supply : from the generic phy bindings, a phandle to a regulator that
|
||||
provides power to MIPI CSIS core;
|
||||
|
||||
Optional properties:
|
||||
|
||||
- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
|
||||
value when this property is not specified is 166 MHz;
|
||||
- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
|
||||
|
||||
The device node should contain two 'port' child nodes with one child 'endpoint'
|
||||
node, according to the bindings defined in:
|
||||
Documentation/devicetree/bindings/ media/video-interfaces.txt.
|
||||
The following are properties specific to those nodes.
|
||||
|
||||
port node
|
||||
---------
|
||||
|
||||
- reg : (required) can take the values 0 or 1, where 0 shall be
|
||||
related to the sink port and port 1 shall be the source
|
||||
one;
|
||||
|
||||
endpoint node
|
||||
-------------
|
||||
|
||||
- data-lanes : (required) an array specifying active physical MIPI-CSI2
|
||||
data input lanes and their mapping to logical lanes; this
|
||||
shall only be applied to port 0 (sink port), the array's
|
||||
content is unused only its length is meaningful,
|
||||
in this case the maximum length supported is 2;
|
||||
|
||||
example:
|
||||
|
||||
mipi_csi: mipi-csi@30750000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
compatible = "fsl,imx7-mipi-csi2";
|
||||
reg = <0x30750000 0x10000>;
|
||||
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clks IMX7D_IPG_ROOT_CLK>,
|
||||
<&clks IMX7D_MIPI_CSI_ROOT_CLK>,
|
||||
<&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
|
||||
clock-names = "pclk", "wrap", "phy";
|
||||
clock-frequency = <166000000>;
|
||||
power-domains = <&pgc_mipi_phy>;
|
||||
phy-supply = <®_1p0d>;
|
||||
resets = <&src IMX7_RESET_MIPI_PHY_MRST>;
|
||||
reset-names = "mrst";
|
||||
fsl,csis-hs-settle = <3>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
mipi_from_sensor: endpoint {
|
||||
remote-endpoint = <&ov2680_to_mipi>;
|
||||
data-lanes = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
mipi_vc0_to_csi_mux: endpoint {
|
||||
remote-endpoint = <&csi_mux_from_mipi_vc0>;
|
||||
};
|
||||
};
|
||||
};
|
|
@ -66,6 +66,15 @@ vcodec_dec: vcodec@16000000 {
|
|||
"vencpll",
|
||||
"venc_lt_sel",
|
||||
"vdec_bus_clk_src";
|
||||
assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>,
|
||||
<&topckgen CLK_TOP_CCI400_SEL>,
|
||||
<&topckgen CLK_TOP_VDEC_SEL>,
|
||||
<&apmixedsys CLK_APMIXED_VCODECPLL>,
|
||||
<&apmixedsys CLK_APMIXED_VENCPLL>;
|
||||
assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>,
|
||||
<&topckgen CLK_TOP_UNIVPLL_D2>,
|
||||
<&topckgen CLK_TOP_VCODECPLL>;
|
||||
assigned-clock-rates = <0>, <0>, <0>, <1482000000>, <800000000>;
|
||||
};
|
||||
|
||||
vcodec_enc: vcodec@18002000 {
|
||||
|
@ -105,4 +114,8 @@ vcodec_dec: vcodec@16000000 {
|
|||
"venc_sel",
|
||||
"venc_lt_sel_src",
|
||||
"venc_lt_sel";
|
||||
assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>,
|
||||
<&topckgen CLK_TOP_VENC_LT_SEL>;
|
||||
assigned-clock-parents = <&topckgen CLK_TOP_VENCPLL_D2>,
|
||||
<&topckgen CLK_TOP_UNIVPLL1_D2>;
|
||||
};
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue