Merge branch 'linus' into x86/urgent, to pick up dependent commits
We are going to fix a bug introduced by a more recent commit, so refresh the tree. Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
commit
415812f2d6
8
CREDITS
8
CREDITS
|
|
@ -1034,6 +1034,10 @@ S: 2037 Walnut #6
|
|||
S: Boulder, Colorado 80302
|
||||
S: USA
|
||||
|
||||
N: Hans-Christian Noren Egtvedt
|
||||
E: egtvedt@samfundet.no
|
||||
D: AVR32 architecture maintainer.
|
||||
|
||||
N: Heiko Eißfeldt
|
||||
E: heiko@colossus.escape.de heiko@unifix.de
|
||||
D: verify_area stuff, generic SCSI fixes
|
||||
|
|
@ -3398,6 +3402,10 @@ S: Suite 101
|
|||
S: Markham, Ontario L3R 2Z6
|
||||
S: Canada
|
||||
|
||||
N: Haavard Skinnemoen
|
||||
M: Haavard Skinnemoen <hskinnemoen@gmail.com>
|
||||
D: AVR32 architecture port to Linux and maintainer.
|
||||
|
||||
N: Rick Sladkey
|
||||
E: jrs@world.std.com
|
||||
D: utility hacker: Emacs, NFS server, mount, kmem-ps, UPS debugger, strace, GDB
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
What: /sys/firmware/acpi/hotplug/force_remove
|
||||
Date: Mar 2017
|
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
||||
Description:
|
||||
Since the force_remove is inherently broken and dangerous to
|
||||
use for some hotplugable resources like memory (because ignoring
|
||||
the offline failure might lead to memory corruption and crashes)
|
||||
enabling this knob is not safe and thus unsupported.
|
||||
|
|
@ -213,14 +213,8 @@ What: /sys/block/<disk>/queue/discard_zeroes_data
|
|||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Devices that support discard functionality may return
|
||||
stale or random data when a previously discarded block
|
||||
is read back. This can cause problems if the filesystem
|
||||
expects discarded blocks to be explicitly cleared. If a
|
||||
device reports that it deterministically returns zeroes
|
||||
when a discarded area is read the discard_zeroes_data
|
||||
parameter will be set to one. Otherwise it will be 0 and
|
||||
the result of reading a discarded area is undefined.
|
||||
Will always return 0. Don't rely on any specific behavior
|
||||
for discards, and don't read this file.
|
||||
|
||||
What: /sys/block/<disk>/queue/write_same_max_bytes
|
||||
Date: January 2012
|
||||
|
|
|
|||
|
|
@ -44,16 +44,6 @@ Description:
|
|||
or 0 (unset). Attempts to write any other values to it will
|
||||
cause -EINVAL to be returned.
|
||||
|
||||
What: /sys/firmware/acpi/hotplug/force_remove
|
||||
Date: May 2013
|
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
||||
Description:
|
||||
The number in this file (0 or 1) determines whether (1) or not
|
||||
(0) the ACPI subsystem will allow devices to be hot-removed even
|
||||
if they cannot be put offline gracefully (from the kernel's
|
||||
viewpoint). That number can be changed by writing a boolean
|
||||
value to this file.
|
||||
|
||||
What: /sys/firmware/acpi/interrupts/
|
||||
Date: February 2008
|
||||
Contact: Len Brown <lenb@kernel.org>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,162 @@
|
|||
Graphs
|
||||
|
||||
|
||||
_DSD
|
||||
----
|
||||
|
||||
_DSD (Device Specific Data) [7] is a predefined ACPI device
|
||||
configuration object that can be used to convey information on
|
||||
hardware features which are not specifically covered by the ACPI
|
||||
specification [1][6]. There are two _DSD extensions that are relevant
|
||||
for graphs: property [4] and hierarchical data extensions [5]. The
|
||||
property extension provides generic key-value pairs whereas the
|
||||
hierarchical data extension supports nodes with references to other
|
||||
nodes, forming a tree. The nodes in the tree may contain properties as
|
||||
defined by the property extension. The two extensions together provide
|
||||
a tree-like structure with zero or more properties (key-value pairs)
|
||||
in each node of the tree.
|
||||
|
||||
The data structure may be accessed at runtime by using the device_*
|
||||
and fwnode_* functions defined in include/linux/fwnode.h .
|
||||
|
||||
Fwnode represents a generic firmware node object. It is independent on
|
||||
the firmware type. In ACPI, fwnodes are _DSD hierarchical data
|
||||
extensions objects. A device's _DSD object is represented by an
|
||||
fwnode.
|
||||
|
||||
The data structure may be referenced to elsewhere in the ACPI tables
|
||||
by using a hard reference to the device itself and an index to the
|
||||
hierarchical data extension array on each depth.
|
||||
|
||||
|
||||
Ports and endpoints
|
||||
-------------------
|
||||
|
||||
The port and endpoint concepts are very similar to those in Devicetree
|
||||
[3]. A port represents an interface in a device, and an endpoint
|
||||
represents a connection to that interface.
|
||||
|
||||
All port nodes are located under the device's "_DSD" node in the
|
||||
hierarchical data extension tree. The property extension related to
|
||||
each port node must contain the key "port" and an integer value which
|
||||
is the number of the port. The object it refers to should be called "PRTX",
|
||||
where "X" is the number of the port.
|
||||
|
||||
Further on, endpoints are located under the individual port nodes. The
|
||||
first hierarchical data extension package list entry of the endpoint
|
||||
nodes must begin with "endpoint" and must be followed by the number
|
||||
of the endpoint. The object it refers to should be called "EPXY", where
|
||||
"X" is the number of the port and "Y" is the number of the endpoint.
|
||||
|
||||
Each port node contains a property extension key "port", the value of
|
||||
which is the number of the port node. The each endpoint is similarly numbered
|
||||
with a property extension key "endpoint". Port numbers must be unique within a
|
||||
device and endpoint numbers must be unique within a port.
|
||||
|
||||
The endpoint reference uses property extension with "remote-endpoint" property
|
||||
name followed by a reference in the same package. Such references consist of the
|
||||
the remote device reference, number of the port in the device and finally the
|
||||
number of the endpoint in that port. Individual references thus appear as:
|
||||
|
||||
Package() { device, port_number, endpoint_number }
|
||||
|
||||
The references to endpoints must be always done both ways, to the
|
||||
remote endpoint and back from the referred remote endpoint node.
|
||||
|
||||
A simple example of this is show below:
|
||||
|
||||
Scope (\_SB.PCI0.I2C2)
|
||||
{
|
||||
Device (CAM0)
|
||||
{
|
||||
Name (_DSD, Package () {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "compatible", Package () { "nokia,smia" } },
|
||||
},
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "port0", "PRT0" },
|
||||
}
|
||||
})
|
||||
Name (PRT0, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "port", 0 },
|
||||
},
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "endpoint0", "EP00" },
|
||||
}
|
||||
})
|
||||
Name (EP00, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "endpoint", 0 },
|
||||
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, 4, 0 } },
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
Scope (\_SB.PCI0)
|
||||
{
|
||||
Device (ISP)
|
||||
{
|
||||
Name (_DSD, Package () {
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "port4", "PRT4" },
|
||||
}
|
||||
})
|
||||
|
||||
Name (PRT4, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "port", 4 }, /* CSI-2 port number */
|
||||
},
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "endpoint0", "EP40" },
|
||||
}
|
||||
})
|
||||
|
||||
Name (EP40, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "endpoint", 0 },
|
||||
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, 0, 0 } },
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
Here, the port 0 of the "CAM0" device is connected to the port 4 of
|
||||
the "ISP" device and vice versa.
|
||||
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
[1] _DSD (Device Specific Data) Implementation Guide.
|
||||
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm>,
|
||||
referenced 2016-10-03.
|
||||
|
||||
[2] Devicetree. <URL:http://www.devicetree.org>, referenced 2016-10-03.
|
||||
|
||||
[3] Documentation/devicetree/bindings/graph.txt
|
||||
|
||||
[4] Device Properties UUID For _DSD.
|
||||
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
|
||||
referenced 2016-10-04.
|
||||
|
||||
[5] Hierarchical Data Extension UUID For _DSD.
|
||||
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf>,
|
||||
referenced 2016-10-04.
|
||||
|
||||
[6] Advanced Configuration and Power Interface Specification.
|
||||
<URL:http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf>,
|
||||
referenced 2016-10-04.
|
||||
|
||||
[7] _DSD Device Properties Usage Rules.
|
||||
Documentation/acpi/DSD-properties-rules.txt
|
||||
|
|
@ -24,7 +24,7 @@ upstream.
|
|||
The homepage of ACPICA project is: www.acpica.org, it is maintained and
|
||||
supported by Intel Corporation.
|
||||
|
||||
The following figure depicts the Linux ACPI subystem where the ACPICA
|
||||
The following figure depicts the Linux ACPI subsystem where the ACPICA
|
||||
adaptation is included:
|
||||
|
||||
+---------------------------------------------------------+
|
||||
|
|
@ -110,7 +110,7 @@ upstream.
|
|||
Linux patches. The patches generated by this process are referred to as
|
||||
"linuxized ACPICA patches". The release process is carried out on a local
|
||||
copy the ACPICA git repository. Each commit in the monthly release is
|
||||
converted into a linuxized ACPICA patch. Together, they form the montly
|
||||
converted into a linuxized ACPICA patch. Together, they form the monthly
|
||||
ACPICA release patchset for the Linux ACPI community. This process is
|
||||
illustrated in the following figure:
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ upstream.
|
|||
<http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git>.
|
||||
|
||||
Before the linuxized ACPICA patches are sent to the Linux ACPI community
|
||||
for review, there is a quality ensurance build test process to reduce
|
||||
for review, there is a quality assurance build test process to reduce
|
||||
porting issues. Currently this build process only takes care of the
|
||||
following kernel configuration options:
|
||||
CONFIG_ACPI/CONFIG_ACPI_DEBUG/CONFIG_ACPI_DEBUGGER
|
||||
|
|
@ -195,12 +195,12 @@ upstream.
|
|||
release utilities (please refer to Section 4 below for the details).
|
||||
3. Linux specific features - Sometimes it's impossible to use the
|
||||
current ACPICA APIs to implement features required by the Linux kernel,
|
||||
so Linux developers occasionaly have to change ACPICA code directly.
|
||||
so Linux developers occasionally have to change ACPICA code directly.
|
||||
Those changes may not be acceptable by ACPICA upstream and in such cases
|
||||
they are left as committed ACPICA divergences unless the ACPICA side can
|
||||
implement new mechanisms as replacements for them.
|
||||
4. ACPICA release fixups - ACPICA only tests commits using a set of the
|
||||
user space simulation utilies, thus the linuxized ACPICA patches may
|
||||
user space simulation utilities, thus the linuxized ACPICA patches may
|
||||
break the Linux kernel, leaving us build/boot failures. In order to
|
||||
avoid breaking Linux bisection, fixes are applied directly to the
|
||||
linuxized ACPICA patches during the release process. When the release
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ On what hardware does it run?
|
|||
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
|
||||
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
|
||||
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
|
||||
Xtensa, Tilera TILE, AVR32, ARC and Renesas M32R architectures.
|
||||
Xtensa, Tilera TILE, ARC and Renesas M32R architectures.
|
||||
|
||||
Linux is easily portable to most general-purpose 32- or 64-bit architectures
|
||||
as long as they have a paged memory management unit (PMMU) and a port of the
|
||||
|
|
|
|||
|
|
@ -86,7 +86,6 @@ parameter is applicable::
|
|||
APIC APIC support is enabled.
|
||||
APM Advanced Power Management support is enabled.
|
||||
ARM ARM architecture is enabled.
|
||||
AVR32 AVR32 architecture is enabled.
|
||||
AX25 Appropriate AX.25 support is enabled.
|
||||
BLACKFIN Blackfin architecture is enabled.
|
||||
CLK Common clock infrastructure is enabled.
|
||||
|
|
|
|||
|
|
@ -531,7 +531,6 @@
|
|||
[ACPI] acpi_pm
|
||||
[ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
|
||||
pxa_timer,timer3,32k_counter,timer0_1
|
||||
[AVR32] avr32
|
||||
[X86-32] pit,hpet,tsc;
|
||||
scx200_hrt on Geode; cyclone on IBM x440
|
||||
[MIPS] MIPS
|
||||
|
|
@ -989,6 +988,7 @@
|
|||
earlyprintk=ttySn[,baudrate]
|
||||
earlyprintk=dbgp[debugController#]
|
||||
earlyprintk=pciserial,bus:device.function[,baudrate]
|
||||
earlyprintk=xdbc[xhciController#]
|
||||
|
||||
earlyprintk is useful when the kernel crashes before
|
||||
the normal console is initialized. It is not enabled by
|
||||
|
|
@ -2425,7 +2425,7 @@
|
|||
osd-targets. Please see:
|
||||
Documentation/filesystems/pnfs.txt for more explanations
|
||||
|
||||
nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take
|
||||
nmi_debug= [KNL,SH] Specify one or more actions to take
|
||||
when a NMI is triggered.
|
||||
Format: [state][,regs][,debounce][,die]
|
||||
|
||||
|
|
@ -3178,6 +3178,12 @@
|
|||
ramdisk_size= [RAM] Sizes of RAM disks in kilobytes
|
||||
See Documentation/blockdev/ramdisk.txt.
|
||||
|
||||
ras=option[,option,...] [KNL] RAS-specific options
|
||||
|
||||
cec_disable [X86]
|
||||
Disable the Correctable Errors Collector,
|
||||
see CONFIG_RAS_CEC help text.
|
||||
|
||||
rcu_nocbs= [KNL]
|
||||
The argument is a cpu list, as described above.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,6 +54,7 @@ stable kernels.
|
|||
| ARM | Cortex-A57 | #852523 | N/A |
|
||||
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
|
||||
| ARM | Cortex-A72 | #853709 | N/A |
|
||||
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
|
||||
| ARM | MMU-500 | #841119,#826419 | N/A |
|
||||
| | | | |
|
||||
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
00-INDEX
|
||||
- This file
|
||||
bfq-iosched.txt
|
||||
- BFQ IO scheduler and its tunables
|
||||
biodoc.txt
|
||||
- Notes on the Generic Block Layer Rewrite in Linux 2.5
|
||||
biovecs.txt
|
||||
|
|
|
|||
|
|
@ -0,0 +1,531 @@
|
|||
BFQ (Budget Fair Queueing)
|
||||
==========================
|
||||
|
||||
BFQ is a proportional-share I/O scheduler, with some extra
|
||||
low-latency capabilities. In addition to cgroups support (blkio or io
|
||||
controllers), BFQ's main features are:
|
||||
- BFQ guarantees a high system and application responsiveness, and a
|
||||
low latency for time-sensitive applications, such as audio or video
|
||||
players;
|
||||
- BFQ distributes bandwidth, and not just time, among processes or
|
||||
groups (switching back to time distribution when needed to keep
|
||||
throughput high).
|
||||
|
||||
On average CPUs, the current version of BFQ can handle devices
|
||||
performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a
|
||||
reference, 30-50 KIOPS correspond to very high bandwidths with
|
||||
sequential I/O (e.g., 8-12 GB/s if I/O requests are 256 KB large), and
|
||||
to 120-200 MB/s with 4KB random I/O. BFQ has not yet been tested on
|
||||
multi-queue devices.
|
||||
|
||||
The table of contents follow. Impatients can just jump to Section 3.
|
||||
|
||||
CONTENTS
|
||||
|
||||
1. When may BFQ be useful?
|
||||
1-1 Personal systems
|
||||
1-2 Server systems
|
||||
2. How does BFQ work?
|
||||
3. What are BFQ's tunable?
|
||||
4. BFQ group scheduling
|
||||
4-1 Service guarantees provided
|
||||
4-2 Interface
|
||||
|
||||
1. When may BFQ be useful?
|
||||
==========================
|
||||
|
||||
BFQ provides the following benefits on personal and server systems.
|
||||
|
||||
1-1 Personal systems
|
||||
--------------------
|
||||
|
||||
Low latency for interactive applications
|
||||
|
||||
Regardless of the actual background workload, BFQ guarantees that, for
|
||||
interactive tasks, the storage device is virtually as responsive as if
|
||||
it was idle. For example, even if one or more of the following
|
||||
background workloads are being executed:
|
||||
- one or more large files are being read, written or copied,
|
||||
- a tree of source files is being compiled,
|
||||
- one or more virtual machines are performing I/O,
|
||||
- a software update is in progress,
|
||||
- indexing daemons are scanning filesystems and updating their
|
||||
databases,
|
||||
starting an application or loading a file from within an application
|
||||
takes about the same time as if the storage device was idle. As a
|
||||
comparison, with CFQ, NOOP or DEADLINE, and in the same conditions,
|
||||
applications experience high latencies, or even become unresponsive
|
||||
until the background workload terminates (also on SSDs).
|
||||
|
||||
Low latency for soft real-time applications
|
||||
|
||||
Also soft real-time applications, such as audio and video
|
||||
players/streamers, enjoy a low latency and a low drop rate, regardless
|
||||
of the background I/O workload. As a consequence, these applications
|
||||
do not suffer from almost any glitch due to the background workload.
|
||||
|
||||
Higher speed for code-development tasks
|
||||
|
||||
If some additional workload happens to be executed in parallel, then
|
||||
BFQ executes the I/O-related components of typical code-development
|
||||
tasks (compilation, checkout, merge, ...) much more quickly than CFQ,
|
||||
NOOP or DEADLINE.
|
||||
|
||||
High throughput
|
||||
|
||||
On hard disks, BFQ achieves up to 30% higher throughput than CFQ, and
|
||||
up to 150% higher throughput than DEADLINE and NOOP, with all the
|
||||
sequential workloads considered in our tests. With random workloads,
|
||||
and with all the workloads on flash-based devices, BFQ achieves,
|
||||
instead, about the same throughput as the other schedulers.
|
||||
|
||||
Strong fairness, bandwidth and delay guarantees
|
||||
|
||||
BFQ distributes the device throughput, and not just the device time,
|
||||
among I/O-bound applications in proportion their weights, with any
|
||||
workload and regardless of the device parameters. From these bandwidth
|
||||
guarantees, it is possible to compute tight per-I/O-request delay
|
||||
guarantees by a simple formula. If not configured for strict service
|
||||
guarantees, BFQ switches to time-based resource sharing (only) for
|
||||
applications that would otherwise cause a throughput loss.
|
||||
|
||||
1-2 Server systems
|
||||
------------------
|
||||
|
||||
Most benefits for server systems follow from the same service
|
||||
properties as above. In particular, regardless of whether additional,
|
||||
possibly heavy workloads are being served, BFQ guarantees:
|
||||
|
||||
. audio and video-streaming with zero or very low jitter and drop
|
||||
rate;
|
||||
|
||||
. fast retrieval of WEB pages and embedded objects;
|
||||
|
||||
. real-time recording of data in live-dumping applications (e.g.,
|
||||
packet logging);
|
||||
|
||||
. responsiveness in local and remote access to a server.
|
||||
|
||||
|
||||
2. How does BFQ work?
|
||||
=====================
|
||||
|
||||
BFQ is a proportional-share I/O scheduler, whose general structure,
|
||||
plus a lot of code, are borrowed from CFQ.
|
||||
|
||||
- Each process doing I/O on a device is associated with a weight and a
|
||||
(bfq_)queue.
|
||||
|
||||
- BFQ grants exclusive access to the device, for a while, to one queue
|
||||
(process) at a time, and implements this service model by
|
||||
associating every queue with a budget, measured in number of
|
||||
sectors.
|
||||
|
||||
- After a queue is granted access to the device, the budget of the
|
||||
queue is decremented, on each request dispatch, by the size of the
|
||||
request.
|
||||
|
||||
- The in-service queue is expired, i.e., its service is suspended,
|
||||
only if one of the following events occurs: 1) the queue finishes
|
||||
its budget, 2) the queue empties, 3) a "budget timeout" fires.
|
||||
|
||||
- The budget timeout prevents processes doing random I/O from
|
||||
holding the device for too long and dramatically reducing
|
||||
throughput.
|
||||
|
||||
- Actually, as in CFQ, a queue associated with a process issuing
|
||||
sync requests may not be expired immediately when it empties. In
|
||||
contrast, BFQ may idle the device for a short time interval,
|
||||
giving the process the chance to go on being served if it issues
|
||||
a new request in time. Device idling typically boosts the
|
||||
throughput on rotational devices, if processes do synchronous
|
||||
and sequential I/O. In addition, under BFQ, device idling is
|
||||
also instrumental in guaranteeing the desired throughput
|
||||
fraction to processes issuing sync requests (see the description
|
||||
of the slice_idle tunable in this document, or [1, 2], for more
|
||||
details).
|
||||
|
||||
- With respect to idling for service guarantees, if several
|
||||
processes are competing for the device at the same time, but
|
||||
all processes (and groups, after the following commit) have
|
||||
the same weight, then BFQ guarantees the expected throughput
|
||||
distribution without ever idling the device. Throughput is
|
||||
thus as high as possible in this common scenario.
|
||||
|
||||
- If low-latency mode is enabled (default configuration), BFQ
|
||||
executes some special heuristics to detect interactive and soft
|
||||
real-time applications (e.g., video or audio players/streamers),
|
||||
and to reduce their latency. The most important action taken to
|
||||
achieve this goal is to give to the queues associated with these
|
||||
applications more than their fair share of the device
|
||||
throughput. For brevity, we call just "weight-raising" the whole
|
||||
sets of actions taken by BFQ to privilege these queues. In
|
||||
particular, BFQ provides a milder form of weight-raising for
|
||||
interactive applications, and a stronger form for soft real-time
|
||||
applications.
|
||||
|
||||
- BFQ automatically deactivates idling for queues born in a burst of
|
||||
queue creations. In fact, these queues are usually associated with
|
||||
the processes of applications and services that benefit mostly
|
||||
from a high throughput. Examples are systemd during boot, or git
|
||||
grep.
|
||||
|
||||
- As CFQ, BFQ merges queues performing interleaved I/O, i.e.,
|
||||
performing random I/O that becomes mostly sequential if
|
||||
merged. Differently from CFQ, BFQ achieves this goal with a more
|
||||
reactive mechanism, called Early Queue Merge (EQM). EQM is so
|
||||
responsive in detecting interleaved I/O (cooperating processes),
|
||||
that it enables BFQ to achieve a high throughput, by queue
|
||||
merging, even for queues for which CFQ needs a different
|
||||
mechanism, preemption, to get a high throughput. As such EQM is a
|
||||
unified mechanism to achieve a high throughput with interleaved
|
||||
I/O.
|
||||
|
||||
- Queues are scheduled according to a variant of WF2Q+, named
|
||||
B-WF2Q+, and implemented using an augmented rb-tree to preserve an
|
||||
O(log N) overall complexity. See [2] for more details. B-WF2Q+ is
|
||||
also ready for hierarchical scheduling. However, for a cleaner
|
||||
logical breakdown, the code that enables and completes
|
||||
hierarchical support is provided in the next commit, which focuses
|
||||
exactly on this feature.
|
||||
|
||||
- B-WF2Q+ guarantees a tight deviation with respect to an ideal,
|
||||
perfectly fair, and smooth service. In particular, B-WF2Q+
|
||||
guarantees that each queue receives a fraction of the device
|
||||
throughput proportional to its weight, even if the throughput
|
||||
fluctuates, and regardless of: the device parameters, the current
|
||||
workload and the budgets assigned to the queue.
|
||||
|
||||
- The last, budget-independence, property (although probably
|
||||
counterintuitive in the first place) is definitely beneficial, for
|
||||
the following reasons:
|
||||
|
||||
- First, with any proportional-share scheduler, the maximum
|
||||
deviation with respect to an ideal service is proportional to
|
||||
the maximum budget (slice) assigned to queues. As a consequence,
|
||||
BFQ can keep this deviation tight not only because of the
|
||||
accurate service of B-WF2Q+, but also because BFQ *does not*
|
||||
need to assign a larger budget to a queue to let the queue
|
||||
receive a higher fraction of the device throughput.
|
||||
|
||||
- Second, BFQ is free to choose, for every process (queue), the
|
||||
budget that best fits the needs of the process, or best
|
||||
leverages the I/O pattern of the process. In particular, BFQ
|
||||
updates queue budgets with a simple feedback-loop algorithm that
|
||||
allows a high throughput to be achieved, while still providing
|
||||
tight latency guarantees to time-sensitive applications. When
|
||||
the in-service queue expires, this algorithm computes the next
|
||||
budget of the queue so as to:
|
||||
|
||||
- Let large budgets be eventually assigned to the queues
|
||||
associated with I/O-bound applications performing sequential
|
||||
I/O: in fact, the longer these applications are served once
|
||||
got access to the device, the higher the throughput is.
|
||||
|
||||
- Let small budgets be eventually assigned to the queues
|
||||
associated with time-sensitive applications (which typically
|
||||
perform sporadic and short I/O), because, the smaller the
|
||||
budget assigned to a queue waiting for service is, the sooner
|
||||
B-WF2Q+ will serve that queue (Subsec 3.3 in [2]).
|
||||
|
||||
- If several processes are competing for the device at the same time,
|
||||
but all processes and groups have the same weight, then BFQ
|
||||
guarantees the expected throughput distribution without ever idling
|
||||
the device. It uses preemption instead. Throughput is then much
|
||||
higher in this common scenario.
|
||||
|
||||
- ioprio classes are served in strict priority order, i.e.,
|
||||
lower-priority queues are not served as long as there are
|
||||
higher-priority queues. Among queues in the same class, the
|
||||
bandwidth is distributed in proportion to the weight of each
|
||||
queue. A very thin extra bandwidth is however guaranteed to
|
||||
the Idle class, to prevent it from starving.
|
||||
|
||||
|
||||
3. What are BFQ's tunable?
|
||||
==========================
|
||||
|
||||
The tunables back_seek-max, back_seek_penalty, fifo_expire_async and
|
||||
fifo_expire_sync below are the same as in CFQ. Their description is
|
||||
just copied from that for CFQ. Some considerations in the description
|
||||
of slice_idle are copied from CFQ too.
|
||||
|
||||
per-process ioprio and weight
|
||||
-----------------------------
|
||||
|
||||
Unless the cgroups interface is used (see "4. BFQ group scheduling"),
|
||||
weights can be assigned to processes only indirectly, through I/O
|
||||
priorities, and according to the relation:
|
||||
weight = (IOPRIO_BE_NR - ioprio) * 10.
|
||||
|
||||
Beware that, if low-latency is set, then BFQ automatically raises the
|
||||
weight of the queues associated with interactive and soft real-time
|
||||
applications. Unset this tunable if you need/want to control weights.
|
||||
|
||||
slice_idle
|
||||
----------
|
||||
|
||||
This parameter specifies how long BFQ should idle for next I/O
|
||||
request, when certain sync BFQ queues become empty. By default
|
||||
slice_idle is a non-zero value. Idling has a double purpose: boosting
|
||||
throughput and making sure that the desired throughput distribution is
|
||||
respected (see the description of how BFQ works, and, if needed, the
|
||||
papers referred there).
|
||||
|
||||
As for throughput, idling can be very helpful on highly seeky media
|
||||
like single spindle SATA/SAS disks where we can cut down on overall
|
||||
number of seeks and see improved throughput.
|
||||
|
||||
Setting slice_idle to 0 will remove all the idling on queues and one
|
||||
should see an overall improved throughput on faster storage devices
|
||||
like multiple SATA/SAS disks in hardware RAID configuration.
|
||||
|
||||
So depending on storage and workload, it might be useful to set
|
||||
slice_idle=0. In general for SATA/SAS disks and software RAID of
|
||||
SATA/SAS disks keeping slice_idle enabled should be useful. For any
|
||||
configurations where there are multiple spindles behind single LUN
|
||||
(Host based hardware RAID controller or for storage arrays), setting
|
||||
slice_idle=0 might end up in better throughput and acceptable
|
||||
latencies.
|
||||
|
||||
Idling is however necessary to have service guarantees enforced in
|
||||
case of differentiated weights or differentiated I/O-request lengths.
|
||||
To see why, suppose that a given BFQ queue A must get several I/O
|
||||
requests served for each request served for another queue B. Idling
|
||||
ensures that, if A makes a new I/O request slightly after becoming
|
||||
empty, then no request of B is dispatched in the middle, and thus A
|
||||
does not lose the possibility to get more than one request dispatched
|
||||
before the next request of B is dispatched. Note that idling
|
||||
guarantees the desired differentiated treatment of queues only in
|
||||
terms of I/O-request dispatches. To guarantee that the actual service
|
||||
order then corresponds to the dispatch order, the strict_guarantees
|
||||
tunable must be set too.
|
||||
|
||||
There is an important flipside for idling: apart from the above cases
|
||||
where it is beneficial also for throughput, idling can severely impact
|
||||
throughput. One important case is random workload. Because of this
|
||||
issue, BFQ tends to avoid idling as much as possible, when it is not
|
||||
beneficial also for throughput. As a consequence of this behavior, and
|
||||
of further issues described for the strict_guarantees tunable,
|
||||
short-term service guarantees may be occasionally violated. And, in
|
||||
some cases, these guarantees may be more important than guaranteeing
|
||||
maximum throughput. For example, in video playing/streaming, a very
|
||||
low drop rate may be more important than maximum throughput. In these
|
||||
cases, consider setting the strict_guarantees parameter.
|
||||
|
||||
strict_guarantees
|
||||
-----------------
|
||||
|
||||
If this parameter is set (default: unset), then BFQ
|
||||
|
||||
- always performs idling when the in-service queue becomes empty;
|
||||
|
||||
- forces the device to serve one I/O request at a time, by dispatching a
|
||||
new request only if there is no outstanding request.
|
||||
|
||||
In the presence of differentiated weights or I/O-request sizes, both
|
||||
the above conditions are needed to guarantee that every BFQ queue
|
||||
receives its allotted share of the bandwidth. The first condition is
|
||||
needed for the reasons explained in the description of the slice_idle
|
||||
tunable. The second condition is needed because all modern storage
|
||||
devices reorder internally-queued requests, which may trivially break
|
||||
the service guarantees enforced by the I/O scheduler.
|
||||
|
||||
Setting strict_guarantees may evidently affect throughput.
|
||||
|
||||
back_seek_max
|
||||
-------------
|
||||
|
||||
This specifies, given in Kbytes, the maximum "distance" for backward seeking.
|
||||
The distance is the amount of space from the current head location to the
|
||||
sectors that are backward in terms of distance.
|
||||
|
||||
This parameter allows the scheduler to anticipate requests in the "backward"
|
||||
direction and consider them as being the "next" if they are within this
|
||||
distance from the current head location.
|
||||
|
||||
back_seek_penalty
|
||||
-----------------
|
||||
|
||||
This parameter is used to compute the cost of backward seeking. If the
|
||||
backward distance of request is just 1/back_seek_penalty from a "front"
|
||||
request, then the seeking cost of two requests is considered equivalent.
|
||||
|
||||
So scheduler will not bias toward one or the other request (otherwise scheduler
|
||||
will bias toward front request). Default value of back_seek_penalty is 2.
|
||||
|
||||
fifo_expire_async
|
||||
-----------------
|
||||
|
||||
This parameter is used to set the timeout of asynchronous requests. Default
|
||||
value of this is 248ms.
|
||||
|
||||
fifo_expire_sync
|
||||
----------------
|
||||
|
||||
This parameter is used to set the timeout of synchronous requests. Default
|
||||
value of this is 124ms. In case to favor synchronous requests over asynchronous
|
||||
one, this value should be decreased relative to fifo_expire_async.
|
||||
|
||||
low_latency
|
||||
-----------
|
||||
|
||||
This parameter is used to enable/disable BFQ's low latency mode. By
|
||||
default, low latency mode is enabled. If enabled, interactive and soft
|
||||
real-time applications are privileged and experience a lower latency,
|
||||
as explained in more detail in the description of how BFQ works.
|
||||
|
||||
DO NOT enable this mode if you need full control on bandwidth
|
||||
distribution. In fact, if it is enabled, then BFQ automatically
|
||||
increases the bandwidth share of privileged applications, as the main
|
||||
means to guarantee a lower latency to them.
|
||||
|
||||
timeout_sync
|
||||
------------
|
||||
|
||||
Maximum amount of device time that can be given to a task (queue) once
|
||||
it has been selected for service. On devices with costly seeks,
|
||||
increasing this time usually increases maximum throughput. On the
|
||||
opposite end, increasing this time coarsens the granularity of the
|
||||
short-term bandwidth and latency guarantees, especially if the
|
||||
following parameter is set to zero.
|
||||
|
||||
max_budget
|
||||
----------
|
||||
|
||||
Maximum amount of service, measured in sectors, that can be provided
|
||||
to a BFQ queue once it is set in service (of course within the limits
|
||||
of the above timeout). According to what said in the description of
|
||||
the algorithm, larger values increase the throughput in proportion to
|
||||
the percentage of sequential I/O requests issued. The price of larger
|
||||
values is that they coarsen the granularity of short-term bandwidth
|
||||
and latency guarantees.
|
||||
|
||||
The default value is 0, which enables auto-tuning: BFQ sets max_budget
|
||||
to the maximum number of sectors that can be served during
|
||||
timeout_sync, according to the estimated peak rate.
|
||||
|
||||
weights
|
||||
-------
|
||||
|
||||
Read-only parameter, used to show the weights of the currently active
|
||||
BFQ queues.
|
||||
|
||||
|
||||
wr_ tunables
|
||||
------------
|
||||
|
||||
BFQ exports a few parameters to control/tune the behavior of
|
||||
low-latency heuristics.
|
||||
|
||||
wr_coeff
|
||||
|
||||
Factor by which the weight of a weight-raised queue is multiplied. If
|
||||
the queue is deemed soft real-time, then the weight is further
|
||||
multiplied by an additional, constant factor.
|
||||
|
||||
wr_max_time
|
||||
|
||||
Maximum duration of a weight-raising period for an interactive task
|
||||
(ms). If set to zero (default value), then this value is computed
|
||||
automatically, as a function of the peak rate of the device. In any
|
||||
case, when the value of this parameter is read, it always reports the
|
||||
current duration, regardless of whether it has been set manually or
|
||||
computed automatically.
|
||||
|
||||
wr_max_softrt_rate
|
||||
|
||||
Maximum service rate below which a queue is deemed to be associated
|
||||
with a soft real-time application, and is then weight-raised
|
||||
accordingly (sectors/sec).
|
||||
|
||||
wr_min_idle_time
|
||||
|
||||
Minimum idle period after which interactive weight-raising may be
|
||||
reactivated for a queue (in ms).
|
||||
|
||||
wr_rt_max_time
|
||||
|
||||
Maximum weight-raising duration for soft real-time queues (in ms). The
|
||||
start time from which this duration is considered is automatically
|
||||
moved forward if the queue is detected to be still soft real-time
|
||||
before the current soft real-time weight-raising period finishes.
|
||||
|
||||
wr_min_inter_arr_async
|
||||
|
||||
Minimum period between I/O request arrivals after which weight-raising
|
||||
may be reactivated for an already busy async queue (in ms).
|
||||
|
||||
|
||||
4. Group scheduling with BFQ
|
||||
============================
|
||||
|
||||
BFQ supports both cgroups-v1 and cgroups-v2 io controllers, namely
|
||||
blkio and io. In particular, BFQ supports weight-based proportional
|
||||
share. To activate cgroups support, set BFQ_GROUP_IOSCHED.
|
||||
|
||||
4-1 Service guarantees provided
|
||||
-------------------------------
|
||||
|
||||
With BFQ, proportional share means true proportional share of the
|
||||
device bandwidth, according to group weights. For example, a group
|
||||
with weight 200 gets twice the bandwidth, and not just twice the time,
|
||||
of a group with weight 100.
|
||||
|
||||
BFQ supports hierarchies (group trees) of any depth. Bandwidth is
|
||||
distributed among groups and processes in the expected way: for each
|
||||
group, the children of the group share the whole bandwidth of the
|
||||
group in proportion to their weights. In particular, this implies
|
||||
that, for each leaf group, every process of the group receives the
|
||||
same share of the whole group bandwidth, unless the ioprio of the
|
||||
process is modified.
|
||||
|
||||
The resource-sharing guarantee for a group may partially or totally
|
||||
switch from bandwidth to time, if providing bandwidth guarantees to
|
||||
the group lowers the throughput too much. This switch occurs on a
|
||||
per-process basis: if a process of a leaf group causes throughput loss
|
||||
if served in such a way to receive its share of the bandwidth, then
|
||||
BFQ switches back to just time-based proportional share for that
|
||||
process.
|
||||
|
||||
4-2 Interface
|
||||
-------------
|
||||
|
||||
To get proportional sharing of bandwidth with BFQ for a given device,
|
||||
BFQ must of course be the active scheduler for that device.
|
||||
|
||||
Within each group directory, the names of the files associated with
|
||||
BFQ-specific cgroup parameters and stats begin with the "bfq."
|
||||
prefix. So, with cgroups-v1 or cgroups-v2, the full prefix for
|
||||
BFQ-specific files is "blkio.bfq." or "io.bfq." For example, the group
|
||||
parameter to set the weight of a group with BFQ is blkio.bfq.weight
|
||||
or io.bfq.weight.
|
||||
|
||||
Parameters to set
|
||||
-----------------
|
||||
|
||||
For each group, there is only the following parameter to set.
|
||||
|
||||
weight (namely blkio.bfq.weight or io.bfq-weight): the weight of the
|
||||
group inside its parent. Available values: 1..10000 (default 100). The
|
||||
linear mapping between ioprio and weights, described at the beginning
|
||||
of the tunable section, is still valid, but all weights higher than
|
||||
IOPRIO_BE_NR*10 are mapped to ioprio 0.
|
||||
|
||||
Recall that, if low-latency is set, then BFQ automatically raises the
|
||||
weight of the queues associated with interactive and soft real-time
|
||||
applications. Unset this tunable if you need/want to control weights.
|
||||
|
||||
|
||||
[1] P. Valente, A. Avanzini, "Evolution of the BFQ Storage I/O
|
||||
Scheduler", Proceedings of the First Workshop on Mobile System
|
||||
Technologies (MST-2015), May 2015.
|
||||
http://algogroup.unimore.it/people/paolo/disk_sched/mst-2015.pdf
|
||||
|
||||
[2] P. Valente and M. Andreolini, "Improving Application
|
||||
Responsiveness with the BFQ Disk I/O Scheduler", Proceedings of
|
||||
the 5th Annual International Systems and Storage Conference
|
||||
(SYSTOR '12), June 2012.
|
||||
Slightly extended version:
|
||||
http://algogroup.unimore.it/people/paolo/disk_sched/bfq-v1-suite-
|
||||
results.pdf
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Kyber I/O scheduler tunables
|
||||
===========================
|
||||
|
||||
The only two tunables for the Kyber scheduler are the target latencies for
|
||||
reads and synchronous writes. Kyber will throttle requests in order to meet
|
||||
these target latencies.
|
||||
|
||||
read_lat_nsec
|
||||
-------------
|
||||
Target latency for reads (in nanoseconds).
|
||||
|
||||
write_lat_nsec
|
||||
--------------
|
||||
Target latency for synchronous writes (in nanoseconds).
|
||||
|
|
@ -43,11 +43,6 @@ large discards are issued, setting this value lower will make Linux issue
|
|||
smaller discards and potentially help reduce latencies induced by large
|
||||
discard operations.
|
||||
|
||||
discard_zeroes_data (RO)
|
||||
------------------------
|
||||
When read, this file will show if the discarded block are zeroed by the
|
||||
device or not. If its value is '1' the blocks are zeroed otherwise not.
|
||||
|
||||
hw_sector_size (RO)
|
||||
-------------------
|
||||
This is the hardware sector size of the device, in bytes.
|
||||
|
|
@ -192,5 +187,11 @@ scaling back writes. Writing a value of '0' to this file disables the
|
|||
feature. Writing a value of '-1' to this file resets the value to the
|
||||
default setting.
|
||||
|
||||
throttle_sample_time (RW)
|
||||
-------------------------
|
||||
This is the time window that blk-throttle samples data, in millisecond.
|
||||
blk-throttle makes decision based on the samplings. Lower time means cgroups
|
||||
have more smooth throughput, but higher CPU overhead. This exists only when
|
||||
CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
|
||||
|
||||
Jens Axboe <jens.axboe@oracle.com>, February 2009
|
||||
|
|
|
|||
|
|
@ -1,84 +0,0 @@
|
|||
This document describes m[g]flash support in linux.
|
||||
|
||||
Contents
|
||||
1. Overview
|
||||
2. Reserved area configuration
|
||||
3. Example of mflash platform driver registration
|
||||
|
||||
1. Overview
|
||||
|
||||
Mflash and gflash are embedded flash drive. The only difference is mflash is
|
||||
MCP(Multi Chip Package) device. These two device operate exactly same way.
|
||||
So the rest mflash repersents mflash and gflash altogether.
|
||||
|
||||
Internally, mflash has nand flash and other hardware logics and supports
|
||||
2 different operation (ATA, IO) modes. ATA mode doesn't need any new
|
||||
driver and currently works well under standard IDE subsystem. Actually it's
|
||||
one chip SSD. IO mode is ATA-like custom mode for the host that doesn't have
|
||||
IDE interface.
|
||||
|
||||
Following are brief descriptions about IO mode.
|
||||
A. IO mode based on ATA protocol and uses some custom command. (read confirm,
|
||||
write confirm)
|
||||
B. IO mode uses SRAM bus interface.
|
||||
C. IO mode supports 4kB boot area, so host can boot from mflash.
|
||||
|
||||
2. Reserved area configuration
|
||||
If host boot from mflash, usually needs raw area for boot loader image. All of
|
||||
the mflash's block device operation will be taken this value as start offset.
|
||||
Note that boot loader's size of reserved area and kernel configuration value
|
||||
must be same.
|
||||
|
||||
3. Example of mflash platform driver registration
|
||||
Working mflash is very straight forward. Adding platform device stuff to board
|
||||
configuration file is all. Here is some pseudo example.
|
||||
|
||||
static struct mg_drv_data mflash_drv_data = {
|
||||
/* If you want to polling driver set to 1 */
|
||||
.use_polling = 0,
|
||||
/* device attribution */
|
||||
.dev_attr = MG_BOOT_DEV
|
||||
};
|
||||
|
||||
static struct resource mg_mflash_rsc[] = {
|
||||
/* Base address of mflash */
|
||||
[0] = {
|
||||
.start = 0x08000000,
|
||||
.end = 0x08000000 + SZ_64K - 1,
|
||||
.flags = IORESOURCE_MEM
|
||||
},
|
||||
/* mflash interrupt pin */
|
||||
[1] = {
|
||||
.start = IRQ_GPIO(84),
|
||||
.end = IRQ_GPIO(84),
|
||||
.flags = IORESOURCE_IRQ
|
||||
},
|
||||
/* mflash reset pin */
|
||||
[2] = {
|
||||
.start = 43,
|
||||
.end = 43,
|
||||
.name = MG_RST_PIN,
|
||||
.flags = IORESOURCE_IO
|
||||
},
|
||||
/* mflash reset-out pin
|
||||
* If you use mflash as storage device (i.e. other than MG_BOOT_DEV),
|
||||
* should assign this */
|
||||
[3] = {
|
||||
.start = 51,
|
||||
.end = 51,
|
||||
.name = MG_RSTOUT_PIN,
|
||||
.flags = IORESOURCE_IO
|
||||
}
|
||||
};
|
||||
|
||||
static struct platform_device mflash_dev = {
|
||||
.name = MG_DEV_NAME,
|
||||
.id = -1,
|
||||
.dev = {
|
||||
.platform_data = &mflash_drv_data,
|
||||
},
|
||||
.num_resources = ARRAY_SIZE(mg_mflash_rsc),
|
||||
.resource = mg_mflash_rsc
|
||||
};
|
||||
|
||||
platform_device_register(&mflash_dev);
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
Device tree binding for the TI DM816 AHCI SATA Controller
|
||||
---------------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "ti,dm816-ahci"
|
||||
- reg: physical base address and size of the register region used by
|
||||
the controller (as defined by the AHCI 1.1 standard)
|
||||
- interrupts: interrupt specifier (refer to the interrupt binding)
|
||||
- clocks: list of phandle and clock specifier pairs (or only
|
||||
phandles for clock providers with '0' defined for
|
||||
#clock-cells); two clocks must be specified: the functional
|
||||
clock and an external reference clock
|
||||
|
||||
Example:
|
||||
|
||||
sata: sata@4a140000 {
|
||||
compatible = "ti,dm816-ahci";
|
||||
reg = <0x4a140000 0x10000>;
|
||||
interrupts = <16>;
|
||||
clocks = <&sysclk5_ck>, <&sata_refclk>;
|
||||
};
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
ads7828 properties
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be one of
|
||||
ti,ads7828
|
||||
ti,ads7830
|
||||
- reg: I2C address
|
||||
|
||||
Optional properties:
|
||||
|
||||
- ti,differential-input
|
||||
Set to use the device in differential mode.
|
||||
- vref-supply
|
||||
The external reference on the device is set to this regulators output. If it
|
||||
does not exists the internal reference will be used and output by the ads78xx
|
||||
on the "external vref" pin.
|
||||
|
||||
Example ADS7828 node:
|
||||
|
||||
ads7828: ads@48 {
|
||||
comatible = "ti,ads7828";
|
||||
reg = <0x48>;
|
||||
vref-supply = <&vref>;
|
||||
ti,differential-input;
|
||||
};
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
|
||||
|
||||
The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
|
||||
controller can support upto 16 Fan tachometer inputs.
|
||||
|
||||
There can be upto 8 fans supported. Each fan can have one PWM output and
|
||||
one/two Fan tach inputs.
|
||||
|
||||
Required properties for pwm-tacho node:
|
||||
- #address-cells : should be 1.
|
||||
|
||||
- #size-cells : should be 1.
|
||||
|
||||
- reg : address and length of the register set for the device.
|
||||
|
||||
- pinctrl-names : a pinctrl state named "default" must be defined.
|
||||
|
||||
- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
|
||||
|
||||
- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
|
||||
"aspeed,ast2500-pwm-tacho" for AST2500.
|
||||
|
||||
- clocks : a fixed clock providing input clock frequency(PWM
|
||||
and Fan Tach clock)
|
||||
|
||||
fan subnode format:
|
||||
===================
|
||||
Under fan subnode there can upto 8 child nodes, with each child node
|
||||
representing a fan. If there are 8 fans each fan can have one PWM port and
|
||||
one/two Fan tach inputs.
|
||||
|
||||
Required properties for each child node:
|
||||
- reg : should specify PWM source port.
|
||||
integer value in the range 0 to 7 with 0 indicating PWM port A and
|
||||
7 indicating PWM port H.
|
||||
|
||||
- aspeed,fan-tach-ch : should specify the Fan tach input channel.
|
||||
integer value in the range 0 through 15, with 0 indicating
|
||||
Fan tach channel 0 and 15 indicating Fan tach channel 15.
|
||||
Atleast one Fan tach input channel is required.
|
||||
|
||||
Examples:
|
||||
|
||||
pwm_tacho_fixed_clk: fixedclk {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <24000000>;
|
||||
};
|
||||
|
||||
pwm_tacho: pwmtachocontroller@1e786000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x1E786000 0x1000>;
|
||||
compatible = "aspeed,ast2500-pwm-tacho";
|
||||
clocks = <&pwm_tacho_fixed_clk>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
|
||||
|
||||
fan@0 {
|
||||
reg = <0x00>;
|
||||
aspeed,fan-tach-ch = /bits/ 8 <0x00>;
|
||||
};
|
||||
|
||||
fan@1 {
|
||||
reg = <0x01>;
|
||||
aspeed,fan-tach-ch = /bits/ 8 <0x01 0x02>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
*LM87 hwmon sensor.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be
|
||||
"ti,lm87"
|
||||
|
||||
- reg: I2C address
|
||||
|
||||
optional properties:
|
||||
- has-temp3: This configures pins 18 and 19 to be used as a second
|
||||
remote temperature sensing channel. By default the pins
|
||||
are configured as voltage input pins in0 and in5.
|
||||
|
||||
- has-in6: When set, pin 5 is configured to be used as voltage input
|
||||
in6. Otherwise the pin is set as FAN1 input.
|
||||
|
||||
- has-in7: When set, pin 6 is configured to be used as voltage input
|
||||
in7. Otherwise the pin is set as FAN2 input.
|
||||
|
||||
- vcc-supply: a Phandle for the regulator supplying power, can be
|
||||
cofigured to measure 5.0V power supply. Default is 3.3V.
|
||||
|
||||
Example:
|
||||
|
||||
lm87@2e {
|
||||
compatible = "ti,lm87";
|
||||
reg = <0x2e>;
|
||||
has-temp3;
|
||||
vcc-supply = <®_5v0>;
|
||||
};
|
||||
|
|
@ -1,9 +1,12 @@
|
|||
* Cortina Systems Gemini interrupt controller
|
||||
* Faraday Technologt FTINTC010 interrupt controller
|
||||
|
||||
This interrupt controller is found on the Gemini SoCs.
|
||||
This interrupt controller is a stock IP block from Faraday Technology found
|
||||
in the Gemini SoCs and other designs.
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "cortina,gemini-interrupt-controller"
|
||||
- compatible: must be one of
|
||||
"faraday,ftintc010"
|
||||
"cortina,gemini-interrupt-controller" (deprecated)
|
||||
- reg: The register bank for the interrupt controller.
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- #interrupt-cells: The number of cells to define the interrupts.
|
||||
|
|
@ -15,7 +18,7 @@ Required properties:
|
|||
Example:
|
||||
|
||||
interrupt-controller@48000000 {
|
||||
compatible = "cortina,gemini-interrupt-controller";
|
||||
compatible = "faraday,ftintc010"
|
||||
reg = <0x48000000 0x1000>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
* Mediatek 27xx cirq
|
||||
|
||||
In Mediatek SOCs, the CIRQ is a low power interrupt controller designed to
|
||||
work outside MCUSYS which comprises with Cortex-Ax cores,CCI and GIC.
|
||||
The external interrupts (outside MCUSYS) will feed through CIRQ and connect
|
||||
to GIC in MCUSYS. When CIRQ is enabled, it will record the edge-sensitive
|
||||
interrupts and generate a pulse signal to parent interrupt controller when
|
||||
flush command is executed. With CIRQ, MCUSYS can be completely turned off
|
||||
to improve the system power consumption without losing interrupts.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be one of
|
||||
- "mediatek,mt2701-cirq" for mt2701 CIRQ
|
||||
- "mediatek,mt8135-cirq" for mt8135 CIRQ
|
||||
- "mediatek,mt8173-cirq" for mt8173 CIRQ
|
||||
and "mediatek,cirq" as a fallback.
|
||||
- interrupt-controller : Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt.
|
||||
- interrupt-parent: phandle of irq parent for cirq. The parent must
|
||||
use the same interrupt-cells format as GIC.
|
||||
- reg: Physical base address of the cirq registers and length of memory
|
||||
mapped region.
|
||||
- mediatek,ext-irq-range: Identifies external irq number range in different
|
||||
SOCs.
|
||||
|
||||
Example:
|
||||
cirq: interrupt-controller@10204000 {
|
||||
compatible = "mediatek,mt2701-cirq",
|
||||
"mediatek,mtk-cirq";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <3>;
|
||||
interrupt-parent = <&sysirq>;
|
||||
reg = <0 0x10204000 0 0x400>;
|
||||
mediatek,ext-irq-start = <32 200>;
|
||||
};
|
||||
|
|
@ -21,13 +21,16 @@ Required properties:
|
|||
- interrupt-parent: phandle of irq parent for sysirq. The parent must
|
||||
use the same interrupt-cells format as GIC.
|
||||
- reg: Physical base address of the intpol registers and length of memory
|
||||
mapped region.
|
||||
mapped region. Could be multiple bases here. Ex: mt6797 needs 2 reg, others
|
||||
need 1.
|
||||
|
||||
Example:
|
||||
sysirq: interrupt-controller@10200100 {
|
||||
compatible = "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq";
|
||||
sysirq: intpol-controller@10200620 {
|
||||
compatible = "mediatek,mt6797-sysirq",
|
||||
"mediatek,mt6577-sysirq";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <3>;
|
||||
interrupt-parent = <&gic>;
|
||||
reg = <0 0x10200100 0 0x1c>;
|
||||
reg = <0 0x10220620 0 0x20>,
|
||||
<0 0x10220690 0 0x10>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -6,7 +6,9 @@ perform in-band IPMI communication with their host.
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "aspeed,ast2400-ibt-bmc"
|
||||
- compatible : should be one of
|
||||
"aspeed,ast2400-ibt-bmc"
|
||||
"aspeed,ast2500-ibt-bmc"
|
||||
- reg: physical address and size of the registers
|
||||
|
||||
Optional properties:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,29 @@
|
|||
Motorola CPCAP PMIC LEDs
|
||||
------------------------
|
||||
|
||||
This module is part of the CPCAP. For more details about the whole
|
||||
chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
|
||||
|
||||
Requires node properties:
|
||||
- compatible: should be one of
|
||||
* "motorola,cpcap-led-mdl" (Main Display Lighting)
|
||||
* "motorola,cpcap-led-kl" (Keyboard Lighting)
|
||||
* "motorola,cpcap-led-adl" (Aux Display Lighting)
|
||||
* "motorola,cpcap-led-red" (Red Triode)
|
||||
* "motorola,cpcap-led-green" (Green Triode)
|
||||
* "motorola,cpcap-led-blue" (Blue Triode)
|
||||
* "motorola,cpcap-led-cf" (Camera Flash)
|
||||
* "motorola,cpcap-led-bt" (Bluetooth)
|
||||
* "motorola,cpcap-led-cp" (Camera Privacy LED)
|
||||
- label: see Documentation/devicetree/bindings/leds/common.txt
|
||||
- vdd-supply: A phandle to the regulator powering the LED
|
||||
|
||||
Example:
|
||||
|
||||
&cpcap {
|
||||
cpcap_led_red: red-led {
|
||||
compatible = "motorola,cpcap-led-red";
|
||||
label = "cpcap:red";
|
||||
vdd-supply = <&sw5>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
Device Tree Bindings for LED support on MT6323 PMIC
|
||||
|
||||
MT6323 LED controller is subfunction provided by MT6323 PMIC, so the LED
|
||||
controllers are defined as the subnode of the function node provided by MT6323
|
||||
PMIC controller that is being defined as one kind of Muti-Function Device (MFD)
|
||||
using shared bus called PMIC wrapper for each subfunction to access remote
|
||||
MT6323 PMIC hardware.
|
||||
|
||||
For MT6323 MFD bindings see:
|
||||
Documentation/devicetree/bindings/mfd/mt6397.txt
|
||||
For MediaTek PMIC wrapper bindings see:
|
||||
Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be "mediatek,mt6323-led"
|
||||
- address-cells : Must be 1
|
||||
- size-cells : Must be 0
|
||||
|
||||
Each led is represented as a child node of the mediatek,mt6323-led that
|
||||
describes the initial behavior for each LED physically and currently only four
|
||||
LED child nodes can be supported.
|
||||
|
||||
Required properties for the LED child node:
|
||||
- reg : LED channel number (0..3)
|
||||
|
||||
Optional properties for the LED child node:
|
||||
- label : See Documentation/devicetree/bindings/leds/common.txt
|
||||
- linux,default-trigger : See Documentation/devicetree/bindings/leds/common.txt
|
||||
- default-state: See Documentation/devicetree/bindings/leds/common.txt
|
||||
|
||||
Example:
|
||||
|
||||
mt6323: pmic {
|
||||
compatible = "mediatek,mt6323";
|
||||
|
||||
...
|
||||
|
||||
mt6323led: leds {
|
||||
compatible = "mediatek,mt6323-led";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
led@0 {
|
||||
reg = <0>;
|
||||
label = "LED0";
|
||||
linux,default-trigger = "timer";
|
||||
default-state = "on";
|
||||
};
|
||||
led@1 {
|
||||
reg = <1>;
|
||||
label = "LED1";
|
||||
default-state = "off";
|
||||
};
|
||||
led@2 {
|
||||
reg = <2>;
|
||||
label = "LED2";
|
||||
default-state = "on";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -17,6 +17,8 @@ Optional sub-node properties:
|
|||
- label: see Documentation/devicetree/bindings/leds/common.txt
|
||||
- type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE)
|
||||
- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
|
||||
- default-state: see Documentation/devicetree/bindings/leds/common.txt
|
||||
This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>.
|
||||
|
||||
Example:
|
||||
#include <dt-bindings/leds/leds-pca9532.h>
|
||||
|
|
@ -33,6 +35,14 @@ Example:
|
|||
label = "pca:green:power";
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
};
|
||||
kernel-booting {
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
default-state = "on";
|
||||
};
|
||||
sys-stat {
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
default-state = "keep"; // don't touch, was set by U-Boot
|
||||
};
|
||||
};
|
||||
|
||||
For more product information please see the link below:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,59 @@
|
|||
Broadcom FlexRM Ring Manager
|
||||
============================
|
||||
The Broadcom FlexRM ring manager provides a set of rings which can be
|
||||
used to submit work to offload engines. An SoC may have multiple FlexRM
|
||||
hardware blocks. There is one device tree entry per FlexRM block. The
|
||||
FlexRM driver will create a mailbox-controller instance for given FlexRM
|
||||
hardware block where each mailbox channel is a separate FlexRM ring.
|
||||
|
||||
Required properties:
|
||||
--------------------
|
||||
- compatible: Should be "brcm,iproc-flexrm-mbox"
|
||||
- reg: Specifies base physical address and size of the FlexRM
|
||||
ring registers
|
||||
- msi-parent: Phandles (and potential Device IDs) to MSI controllers
|
||||
The FlexRM engine will send MSIs (instead of wired
|
||||
interrupts) to CPU. There is one MSI for each FlexRM ring.
|
||||
Refer devicetree/bindings/interrupt-controller/msi.txt
|
||||
- #mbox-cells: Specifies the number of cells needed to encode a mailbox
|
||||
channel. This should be 3.
|
||||
|
||||
The 1st cell is the mailbox channel number.
|
||||
|
||||
The 2nd cell contains MSI completion threshold. This is the
|
||||
number of completion messages for which FlexRM will inject
|
||||
one MSI interrupt to CPU.
|
||||
|
||||
The 3nd cell contains MSI timer value representing time for
|
||||
which FlexRM will wait to accumulate N completion messages
|
||||
where N is the value specified by 2nd cell above. If FlexRM
|
||||
does not get required number of completion messages in time
|
||||
specified by this cell then it will inject one MSI interrupt
|
||||
to CPU provided atleast one completion message is available.
|
||||
|
||||
Optional properties:
|
||||
--------------------
|
||||
- dma-coherent: Present if DMA operations made by the FlexRM engine (such
|
||||
as DMA descriptor access, access to buffers pointed by DMA
|
||||
descriptors and read/write pointer updates to DDR) are
|
||||
cache coherent with the CPU.
|
||||
|
||||
Example:
|
||||
--------
|
||||
crypto_mbox: mbox@67000000 {
|
||||
compatible = "brcm,iproc-flexrm-mbox";
|
||||
reg = <0x67000000 0x200000>;
|
||||
msi-parent = <&gic_its 0x7f00>;
|
||||
#mbox-cells = <3>;
|
||||
};
|
||||
|
||||
crypto@672c0000 {
|
||||
compatible = "brcm,spu2-v2-crypto";
|
||||
reg = <0x672c0000 0x1000>;
|
||||
mboxes = <&crypto_mbox 0 0x1 0xffff>,
|
||||
<&crypto_mbox 1 0x1 0xffff>,
|
||||
<&crypto_mbox 16 0x1 0xffff>,
|
||||
<&crypto_mbox 17 0x1 0xffff>,
|
||||
<&crypto_mbox 30 0x1 0xffff>,
|
||||
<&crypto_mbox 31 0x1 0xffff>;
|
||||
};
|
||||
|
|
@ -1,9 +1,11 @@
|
|||
The PDC driver manages data transfer to and from various offload engines
|
||||
on some Broadcom SoCs. An SoC may have multiple PDC hardware blocks. There is
|
||||
one device tree entry per block.
|
||||
one device tree entry per block. On some chips, the PDC functionality is
|
||||
handled by the FA2 (Northstar Plus).
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "brcm,iproc-pdc-mbox".
|
||||
- compatible : Should be "brcm,iproc-pdc-mbox" or "brcm,iproc-fa2-mbox" for
|
||||
FA2/Northstar Plus.
|
||||
- reg: Should contain PDC registers location and length.
|
||||
- interrupts: Should contain the IRQ line for the PDC.
|
||||
- #mbox-cells: 1
|
||||
|
|
|
|||
|
|
@ -31,7 +31,9 @@ Optional properties:
|
|||
|
||||
- domain-idle-states : A phandle of an idle-state that shall be soaked into a
|
||||
generic domain power state. The idle state definitions are
|
||||
compatible with domain-idle-state specified in [1].
|
||||
compatible with domain-idle-state specified in [1]. phandles
|
||||
that are not compatible with domain-idle-state will be
|
||||
ignored.
|
||||
The domain-idle-state property reflects the idle state of this PM domain and
|
||||
not the idle states of the devices or sub-domains in the PM domain. Devices
|
||||
and sub-domains have their own idle-states independent of the parent
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
* Device-Tree bindings for Cortina Systems Gemini Poweroff
|
||||
|
||||
This is a special IP block in the Cortina Gemini SoC that only
|
||||
deals with different ways to power the system down.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "cortina,gemini-power-controller"
|
||||
- reg: should contain the physical memory base and size
|
||||
- interrupts: should contain the power management interrupt
|
||||
|
||||
Example:
|
||||
|
||||
power-controller@4b000000 {
|
||||
compatible = "cortina,gemini-power-controller";
|
||||
reg = <0x4b000000 0x100>;
|
||||
interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
|
||||
};
|
||||
|
|
@ -3,13 +3,20 @@ Generic SYSCON mapped register poweroff driver
|
|||
This is a generic poweroff driver using syscon to map the poweroff register.
|
||||
The poweroff is generally performed with a write to the poweroff register
|
||||
defined by the register map pointed by syscon reference plus the offset
|
||||
with the mask defined in the poweroff node.
|
||||
with the value and mask defined in the poweroff node.
|
||||
|
||||
Required properties:
|
||||
- compatible: should contain "syscon-poweroff"
|
||||
- regmap: this is phandle to the register map node
|
||||
- offset: offset in the register map for the poweroff register (in bytes)
|
||||
- mask: the poweroff value written to the poweroff register (32 bit access)
|
||||
- value: the poweroff value written to the poweroff register (32 bit access)
|
||||
|
||||
Optional properties:
|
||||
- mask: update only the register bits defined by the mask (32 bit)
|
||||
|
||||
Legacy usage:
|
||||
If a node doesn't contain a value property but contains a mask property, the
|
||||
mask property is used as the value.
|
||||
|
||||
Default will be little endian mode, 32 bit access only.
|
||||
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@ Required properties:
|
|||
- compatible: should be one of:
|
||||
- "rockchip,rk3188-io-voltage-domain" for rk3188
|
||||
- "rockchip,rk3288-io-voltage-domain" for rk3288
|
||||
- "rockchip,rk3328-io-voltage-domain" for rk3328
|
||||
- "rockchip,rk3368-io-voltage-domain" for rk3368
|
||||
- "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains
|
||||
- "rockchip,rk3399-io-voltage-domain" for rk3399
|
||||
|
|
|
|||
|
|
@ -0,0 +1,37 @@
|
|||
Motorola CPCAP PMIC battery charger binding
|
||||
|
||||
Required properties:
|
||||
- compatible: Shall be "motorola,mapphone-cpcap-charger"
|
||||
- interrupts: Interrupt specifier for each name in interrupt-names
|
||||
- interrupt-names: Should contain the following entries:
|
||||
"chrg_det", "rvrs_chrg", "chrg_se1b", "se0conn",
|
||||
"rvrs_mode", "chrgcurr1", "vbusvld", "battdetb"
|
||||
- io-channels: IIO ADC channel specifier for each name in io-channel-names
|
||||
- io-channel-names: Should contain the following entries:
|
||||
"battdetb", "battp", "vbus", "chg_isense", "batti"
|
||||
|
||||
Optional properties:
|
||||
- mode-gpios: Optionally CPCAP charger can have a companion wireless
|
||||
charge controller that is controlled with two GPIOs
|
||||
that are active low.
|
||||
|
||||
Example:
|
||||
|
||||
cpcap_charger: charger {
|
||||
compatible = "motorola,mapphone-cpcap-charger";
|
||||
interrupts-extended = <
|
||||
&cpcap 13 0 &cpcap 12 0 &cpcap 29 0 &cpcap 28 0
|
||||
&cpcap 22 0 &cpcap 20 0 &cpcap 19 0 &cpcap 54 0
|
||||
>;
|
||||
interrupt-names =
|
||||
"chrg_det", "rvrs_chrg", "chrg_se1b", "se0conn",
|
||||
"rvrs_mode", "chrgcurr1", "vbusvld", "battdetb";
|
||||
mode-gpios = <&gpio3 29 GPIO_ACTIVE_LOW
|
||||
&gpio3 23 GPIO_ACTIVE_LOW>;
|
||||
io-channels = <&cpcap_adc 0 &cpcap_adc 1
|
||||
&cpcap_adc 2 &cpcap_adc 5
|
||||
&cpcap_adc 6>;
|
||||
io-channel-names = "battdetb", "battp",
|
||||
"vbus", "chg_isense",
|
||||
"batti";
|
||||
};
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
LEGO MINDSTORMS EV3 Battery
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
LEGO MINDSTORMS EV3 has some built-in capability for monitoring the battery.
|
||||
It uses 6 AA batteries or a special Li-ion rechargeable battery pack that is
|
||||
detected by a key switch in the battery compartment.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "lego,ev3-battery"
|
||||
- io-channels: phandles to analog inputs for reading voltage and current
|
||||
- io-channel-names: Must be "voltage", "current"
|
||||
- rechargeable-gpios: phandle to the rechargeable battery indication gpio
|
||||
|
||||
Example:
|
||||
|
||||
battery {
|
||||
compatible = "lego,ev3-battery";
|
||||
io-channels = <&adc 4>, <&adc 3>;
|
||||
io-channel-names = "voltage", "current";
|
||||
rechargeable-gpios = <&gpio 136 GPIO_ACTIVE_LOW>;
|
||||
};
|
||||
|
|
@ -6,8 +6,8 @@ temperature monitoring, and uses a slightly different conversion
|
|||
formula for the charge counter.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain "ltc2941" or "ltc2943" which also indicates the
|
||||
type of I2C chip attached.
|
||||
- compatible: Should contain "lltc,ltc2941" or "lltc,ltc2943" which also
|
||||
indicates the type of I2C chip attached.
|
||||
- reg: The 7-bit I2C address.
|
||||
- lltc,resistor-sense: The sense resistor value in milli-ohms. Can be a 32-bit
|
||||
negative value when the battery has been connected to the wrong end of the
|
||||
|
|
@ -20,7 +20,7 @@ Required properties:
|
|||
Example from the Topic Miami Florida board:
|
||||
|
||||
fuelgauge: ltc2943@64 {
|
||||
compatible = "ltc2943";
|
||||
compatible = "lltc,ltc2943";
|
||||
reg = <0x64>;
|
||||
lltc,resistor-sense = <15>;
|
||||
lltc,prescaler-exponent = <5>; /* 2^(2*5) = 1024 */
|
||||
|
|
|
|||
|
|
@ -1,22 +0,0 @@
|
|||
Cortina Systems Gemini timer
|
||||
|
||||
This timer is embedded in the Cortina Systems Gemini SoCs.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Must be "cortina,gemini-timer"
|
||||
- reg : Should contain registers location and length
|
||||
- interrupts : Should contain the three timer interrupts with
|
||||
flags for rising edge
|
||||
- syscon : a phandle to the global Gemini system controller
|
||||
|
||||
Example:
|
||||
|
||||
timer@43000000 {
|
||||
compatible = "cortina,gemini-timer";
|
||||
reg = <0x43000000 0x1000>;
|
||||
interrupts = <14 IRQ_TYPE_EDGE_RISING>, /* Timer 1 */
|
||||
<15 IRQ_TYPE_EDGE_RISING>, /* Timer 2 */
|
||||
<16 IRQ_TYPE_EDGE_RISING>; /* Timer 3 */
|
||||
syscon = <&syscon>;
|
||||
};
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
Faraday Technology timer
|
||||
|
||||
This timer is a generic IP block from Faraday Technology, embedded in the
|
||||
Cortina Systems Gemini SoCs and other designs.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Must be one of
|
||||
"faraday,fttmr010"
|
||||
"cortina,gemini-timer"
|
||||
- reg : Should contain registers location and length
|
||||
- interrupts : Should contain the three timer interrupts usually with
|
||||
flags for falling edge
|
||||
|
||||
Optionally required properties:
|
||||
|
||||
- clocks : a clock to provide the tick rate for "faraday,fttmr010"
|
||||
- clock-names : should be "EXTCLK" and "PCLK" for the external tick timer
|
||||
and peripheral clock respectively, for "faraday,fttmr010"
|
||||
- syscon : a phandle to the global Gemini system controller if the compatible
|
||||
type is "cortina,gemini-timer"
|
||||
|
||||
Example:
|
||||
|
||||
timer@43000000 {
|
||||
compatible = "faraday,fttmr010";
|
||||
reg = <0x43000000 0x1000>;
|
||||
interrupts = <14 IRQ_TYPE_EDGE_FALLING>, /* Timer 1 */
|
||||
<15 IRQ_TYPE_EDGE_FALLING>, /* Timer 2 */
|
||||
<16 IRQ_TYPE_EDGE_FALLING>; /* Timer 3 */
|
||||
clocks = <&extclk>, <&pclk>;
|
||||
clock-names = "EXTCLK", "PCLK";
|
||||
};
|
||||
|
|
@ -1,9 +1,15 @@
|
|||
Rockchip rk timer
|
||||
|
||||
Required properties:
|
||||
- compatible: shall be one of:
|
||||
"rockchip,rk3288-timer" - for rk3066, rk3036, rk3188, rk322x, rk3288, rk3368
|
||||
"rockchip,rk3399-timer" - for rk3399
|
||||
- compatible: should be:
|
||||
"rockchip,rk3036-timer", "rockchip,rk3288-timer": for Rockchip RK3036
|
||||
"rockchip,rk3066-timer", "rockchip,rk3288-timer": for Rockchip RK3066
|
||||
"rockchip,rk3188-timer", "rockchip,rk3288-timer": for Rockchip RK3188
|
||||
"rockchip,rk3228-timer", "rockchip,rk3288-timer": for Rockchip RK3228
|
||||
"rockchip,rk3229-timer", "rockchip,rk3288-timer": for Rockchip RK3229
|
||||
"rockchip,rk3288-timer": for Rockchip RK3288
|
||||
"rockchip,rk3368-timer", "rockchip,rk3288-timer": for Rockchip RK3368
|
||||
"rockchip,rk3399-timer": for Rockchip RK3399
|
||||
- reg: base address of the timer register starting with TIMERS CONTROL register
|
||||
- interrupts: should contain the interrupts for Timer0
|
||||
- clocks : must contain an entry for each entry in clock-names
|
||||
|
|
|
|||
|
|
@ -265,6 +265,7 @@ sbs Smart Battery System
|
|||
schindler Schindler
|
||||
seagate Seagate Technology PLC
|
||||
semtech Semtech Corporation
|
||||
sensirion Sensirion AG
|
||||
sgx SGX Sensortech
|
||||
sharp Sharp Corporation
|
||||
si-en Si-En Technology Ltd.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | ok |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | ok |
|
||||
| c6x: | ok |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | ok |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | TODO |
|
||||
| avr32: | ok |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | ok |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | ok |
|
||||
| blackfin: | ok |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | .. |
|
||||
| arm: | .. |
|
||||
| arm64: | .. |
|
||||
| avr32: | .. |
|
||||
| blackfin: | .. |
|
||||
| c6x: | .. |
|
||||
| cris: | .. |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | ok |
|
||||
| blackfin: | ok |
|
||||
| c6x: | ok |
|
||||
| cris: | ok |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| avr32: | ok |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | ok |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | .. |
|
||||
| blackfin: | .. |
|
||||
| c6x: | .. |
|
||||
| cris: | .. |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | .. |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | .. |
|
||||
| cris: | .. |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | .. |
|
||||
| arm: | .. |
|
||||
| arm64: | .. |
|
||||
| avr32: | .. |
|
||||
| blackfin: | .. |
|
||||
| c6x: | .. |
|
||||
| cris: | .. |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@
|
|||
| arc: | ok |
|
||||
| arm: | ok |
|
||||
| arm64: | ok |
|
||||
| avr32: | TODO |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
Kernel driver aspeed-pwm-tacho
|
||||
==============================
|
||||
|
||||
Supported chips:
|
||||
ASPEED AST2400/2500
|
||||
|
||||
Authors:
|
||||
<jaghu@google.com>
|
||||
|
||||
Description:
|
||||
------------
|
||||
This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
|
||||
controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
|
||||
controller supports up to 16 tachometer inputs.
|
||||
|
||||
The driver provides the following sensor accesses in sysfs:
|
||||
|
||||
fanX_input ro provide current fan rotation value in RPM as reported
|
||||
by the fan to the device.
|
||||
|
||||
pwmX rw get or set PWM fan control value. This is an integer
|
||||
value between 0(off) and 255(full speed).
|
||||
|
|
@ -2,7 +2,7 @@ Kernel driver tc654
|
|||
===================
|
||||
|
||||
Supported chips:
|
||||
* Microship TC654 and TC655
|
||||
* Microchip TC654 and TC655
|
||||
Prefix: 'tc654'
|
||||
Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
pblk: Physical Block Device Target
|
||||
==================================
|
||||
|
||||
pblk implements a fully associative, host-based FTL that exposes a traditional
|
||||
block I/O interface. Its primary responsibilities are:
|
||||
|
||||
- Map logical addresses onto physical addresses (4KB granularity) in a
|
||||
logical-to-physical (L2P) table.
|
||||
- Maintain the integrity and consistency of the L2P table as well as its
|
||||
recovery from normal tear down and power outage.
|
||||
- Deal with controller- and media-specific constrains.
|
||||
- Handle I/O errors.
|
||||
- Implement garbage collection.
|
||||
- Maintain consistency across the I/O stack during synchronization points.
|
||||
|
||||
For more information please refer to:
|
||||
|
||||
http://lightnvm.io
|
||||
|
||||
which maintains updated FAQs, manual pages, technical documentation, tools,
|
||||
contacts, etc.
|
||||
|
|
@ -12,7 +12,7 @@ The following terms are used in this document:
|
|||
control and configuration, and a parallel or a serial bus for data.
|
||||
- camera host - an interface, to which a camera is connected. Typically a
|
||||
specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH,
|
||||
AVR32, i.MX27, i.MX31.
|
||||
i.MX27, i.MX31.
|
||||
- camera host bus - a connection between a camera host and a camera. Can be
|
||||
parallel or serial, consists of data and control lines, e.g. clock, vertical
|
||||
and horizontal synchronization signals.
|
||||
|
|
|
|||
|
|
@ -478,15 +478,23 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
|
|||
- set the power.last_busy field to the current time
|
||||
|
||||
void pm_runtime_use_autosuspend(struct device *dev);
|
||||
- set the power.use_autosuspend flag, enabling autosuspend delays
|
||||
- set the power.use_autosuspend flag, enabling autosuspend delays; call
|
||||
pm_runtime_get_sync if the flag was previously cleared and
|
||||
power.autosuspend_delay is negative
|
||||
|
||||
void pm_runtime_dont_use_autosuspend(struct device *dev);
|
||||
- clear the power.use_autosuspend flag, disabling autosuspend delays
|
||||
- clear the power.use_autosuspend flag, disabling autosuspend delays;
|
||||
decrement the device's usage counter if the flag was previously set and
|
||||
power.autosuspend_delay is negative; call pm_runtime_idle
|
||||
|
||||
void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
|
||||
- set the power.autosuspend_delay value to 'delay' (expressed in
|
||||
milliseconds); if 'delay' is negative then runtime suspends are
|
||||
prevented
|
||||
prevented; if power.use_autosuspend is set, pm_runtime_get_sync may be
|
||||
called or the device's usage counter may be decremented and
|
||||
pm_runtime_idle called depending on if power.autosuspend_delay is
|
||||
changed to or from a negative value; if power.use_autosuspend is clear,
|
||||
pm_runtime_idle is called
|
||||
|
||||
unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
|
||||
- calculate the time when the current autosuspend delay period will expire,
|
||||
|
|
@ -836,9 +844,8 @@ of the non-autosuspend counterparts:
|
|||
Instead of: pm_runtime_put_sync use: pm_runtime_put_sync_autosuspend.
|
||||
|
||||
Drivers may also continue to use the non-autosuspend helper functions; they
|
||||
will behave normally, not taking the autosuspend delay into account.
|
||||
Similarly, if the power.use_autosuspend field isn't set then the autosuspend
|
||||
helper functions will behave just like the non-autosuspend counterparts.
|
||||
will behave normally, which means sometimes taking the autosuspend delay into
|
||||
account (see pm_runtime_idle).
|
||||
|
||||
Under some circumstances a driver or subsystem may want to prevent a device
|
||||
from autosuspending immediately, even though the usage counter is zero and the
|
||||
|
|
|
|||
|
|
@ -0,0 +1,108 @@
|
|||
/*
|
||||
* The following program is used to generate the constants for
|
||||
* computing sched averages.
|
||||
*
|
||||
* ==============================================================
|
||||
* C program (compile with -lm)
|
||||
* ==============================================================
|
||||
*/
|
||||
|
||||
#include <math.h>
|
||||
#include <stdio.h>
|
||||
|
||||
#define HALFLIFE 32
|
||||
#define SHIFT 32
|
||||
|
||||
double y;
|
||||
|
||||
void calc_runnable_avg_yN_inv(void)
|
||||
{
|
||||
int i;
|
||||
unsigned int x;
|
||||
|
||||
printf("static const u32 runnable_avg_yN_inv[] = {");
|
||||
for (i = 0; i < HALFLIFE; i++) {
|
||||
x = ((1UL<<32)-1)*pow(y, i);
|
||||
|
||||
if (i % 6 == 0) printf("\n\t");
|
||||
printf("0x%8x, ", x);
|
||||
}
|
||||
printf("\n};\n\n");
|
||||
}
|
||||
|
||||
int sum = 1024;
|
||||
|
||||
void calc_runnable_avg_yN_sum(void)
|
||||
{
|
||||
int i;
|
||||
|
||||
printf("static const u32 runnable_avg_yN_sum[] = {\n\t 0,");
|
||||
for (i = 1; i <= HALFLIFE; i++) {
|
||||
if (i == 1)
|
||||
sum *= y;
|
||||
else
|
||||
sum = sum*y + 1024*y;
|
||||
|
||||
if (i % 11 == 0)
|
||||
printf("\n\t");
|
||||
|
||||
printf("%5d,", sum);
|
||||
}
|
||||
printf("\n};\n\n");
|
||||
}
|
||||
|
||||
int n = -1;
|
||||
/* first period */
|
||||
long max = 1024;
|
||||
|
||||
void calc_converged_max(void)
|
||||
{
|
||||
long last = 0, y_inv = ((1UL<<32)-1)*y;
|
||||
|
||||
for (; ; n++) {
|
||||
if (n > -1)
|
||||
max = ((max*y_inv)>>SHIFT) + 1024;
|
||||
/*
|
||||
* This is the same as:
|
||||
* max = max*y + 1024;
|
||||
*/
|
||||
|
||||
if (last == max)
|
||||
break;
|
||||
|
||||
last = max;
|
||||
}
|
||||
n--;
|
||||
printf("#define LOAD_AVG_PERIOD %d\n", HALFLIFE);
|
||||
printf("#define LOAD_AVG_MAX %ld\n", max);
|
||||
// printf("#define LOAD_AVG_MAX_N %d\n\n", n);
|
||||
}
|
||||
|
||||
void calc_accumulated_sum_32(void)
|
||||
{
|
||||
int i, x = sum;
|
||||
|
||||
printf("static const u32 __accumulated_sum_N32[] = {\n\t 0,");
|
||||
for (i = 1; i <= n/HALFLIFE+1; i++) {
|
||||
if (i > 1)
|
||||
x = x/2 + sum;
|
||||
|
||||
if (i % 6 == 0)
|
||||
printf("\n\t");
|
||||
|
||||
printf("%6d,", x);
|
||||
}
|
||||
printf("\n};\n\n");
|
||||
}
|
||||
|
||||
void main(void)
|
||||
{
|
||||
printf("/* Generated by Documentation/scheduler/sched-pelt; do not modify. */\n\n");
|
||||
|
||||
y = pow(0.5, 1/(double)HALFLIFE);
|
||||
|
||||
calc_runnable_avg_yN_inv();
|
||||
// calc_runnable_avg_yN_sum();
|
||||
calc_converged_max();
|
||||
// calc_accumulated_sum_32();
|
||||
}
|
||||
|
|
@ -8,8 +8,9 @@ Overview
|
|||
--------
|
||||
These events are similar to tracepoint based events. Instead of Tracepoint,
|
||||
this is based on kprobes (kprobe and kretprobe). So it can probe wherever
|
||||
kprobes can probe (this means, all functions body except for __kprobes
|
||||
functions). Unlike the Tracepoint based event, this can be added and removed
|
||||
kprobes can probe (this means, all functions except those with
|
||||
__kprobes/nokprobe_inline annotation and those marked NOKPROBE_SYMBOL).
|
||||
Unlike the Tracepoint based event, this can be added and removed
|
||||
dynamically, on the fly.
|
||||
|
||||
To enable this feature, build your kernel with CONFIG_KPROBE_EVENTS=y.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,100 @@
|
|||
===============
|
||||
USB3 debug port
|
||||
===============
|
||||
|
||||
:Author: Lu Baolu <baolu.lu@linux.intel.com>
|
||||
:Date: March 2017
|
||||
|
||||
GENERAL
|
||||
=======
|
||||
|
||||
This is a HOWTO for using the USB3 debug port on x86 systems.
|
||||
|
||||
Before using any kernel debugging functionality based on USB3
|
||||
debug port, you need to::
|
||||
|
||||
1) check whether any USB3 debug port is available in
|
||||
your system;
|
||||
2) check which port is used for debugging purposes;
|
||||
3) have a USB 3.0 super-speed A-to-A debugging cable.
|
||||
|
||||
INTRODUCTION
|
||||
============
|
||||
|
||||
The xHCI debug capability (DbC) is an optional but standalone
|
||||
functionality provided by the xHCI host controller. The xHCI
|
||||
specification describes DbC in the section 7.6.
|
||||
|
||||
When DbC is initialized and enabled, it will present a debug
|
||||
device through the debug port (normally the first USB3
|
||||
super-speed port). The debug device is fully compliant with
|
||||
the USB framework and provides the equivalent of a very high
|
||||
performance full-duplex serial link between the debug target
|
||||
(the system under debugging) and a debug host.
|
||||
|
||||
EARLY PRINTK
|
||||
============
|
||||
|
||||
DbC has been designed to log early printk messages. One use for
|
||||
this feature is kernel debugging. For example, when your machine
|
||||
crashes very early before the regular console code is initialized.
|
||||
Other uses include simpler, lockless logging instead of a full-
|
||||
blown printk console driver and klogd.
|
||||
|
||||
On the debug target system, you need to customize a debugging
|
||||
kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add below
|
||||
kernel boot parameter::
|
||||
|
||||
"earlyprintk=xdbc"
|
||||
|
||||
If there are multiple xHCI controllers in your system, you can
|
||||
append a host contoller index to this kernel parameter. This
|
||||
index starts from 0.
|
||||
|
||||
Current design doesn't support DbC runtime suspend/resume. As
|
||||
the result, you'd better disable runtime power management for
|
||||
USB subsystem by adding below kernel boot parameter::
|
||||
|
||||
"usbcore.autosuspend=-1"
|
||||
|
||||
Before starting the debug target, you should connect the debug
|
||||
port to a USB port (root port or port of any external hub) on
|
||||
the debug host. The cable used to connect these two ports
|
||||
should be a USB 3.0 super-speed A-to-A debugging cable.
|
||||
|
||||
During early boot of the debug target, DbC will be detected and
|
||||
initialized. After initialization, the debug host should be able
|
||||
to enumerate the debug device in debug target. The debug host
|
||||
will then bind the debug device with the usb_debug driver module
|
||||
and create the /dev/ttyUSB device.
|
||||
|
||||
If the debug device enumeration goes smoothly, you should be able
|
||||
to see below kernel messages on the debug host::
|
||||
|
||||
# tail -f /var/log/kern.log
|
||||
[ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd
|
||||
[ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM.
|
||||
[ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, idProduct=0004
|
||||
[ 1815.999902] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
|
||||
[ 1815.999903] usb 4-3: Product: Remote GDB
|
||||
[ 1815.999904] usb 4-3: Manufacturer: Linux
|
||||
[ 1815.999905] usb 4-3: SerialNumber: 0001
|
||||
[ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected
|
||||
[ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0
|
||||
|
||||
You can use any communication program, for example minicom, to
|
||||
read and view the messages. Below simple bash scripts can help
|
||||
you to check the sanity of the setup.
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
===== start of bash scripts =============
|
||||
#!/bin/bash
|
||||
|
||||
while true ; do
|
||||
while [ ! -d /sys/class/tty/ttyUSB0 ] ; do
|
||||
:
|
||||
done
|
||||
cat /dev/ttyUSB0
|
||||
done
|
||||
===== end of bash scripts ===============
|
||||
|
|
@ -4,6 +4,7 @@ Copyright (C) 2016 Intel Corporation
|
|||
|
||||
Fenghua Yu <fenghua.yu@intel.com>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
Vikas Shivappa <vikas.shivappa@intel.com>
|
||||
|
||||
This feature is enabled by the CONFIG_INTEL_RDT_A Kconfig and the
|
||||
X86 /proc/cpuinfo flag bits "rdt", "cat_l3" and "cdp_l3".
|
||||
|
|
@ -22,19 +23,34 @@ Info directory
|
|||
|
||||
The 'info' directory contains information about the enabled
|
||||
resources. Each resource has its own subdirectory. The subdirectory
|
||||
names reflect the resource names. Each subdirectory contains the
|
||||
following files:
|
||||
names reflect the resource names.
|
||||
Cache resource(L3/L2) subdirectory contains the following files:
|
||||
|
||||
"num_closids": The number of CLOSIDs which are valid for this
|
||||
resource. The kernel uses the smallest number of
|
||||
CLOSIDs of all enabled resources as limit.
|
||||
"num_closids": The number of CLOSIDs which are valid for this
|
||||
resource. The kernel uses the smallest number of
|
||||
CLOSIDs of all enabled resources as limit.
|
||||
|
||||
"cbm_mask": The bitmask which is valid for this resource. This
|
||||
mask is equivalent to 100%.
|
||||
"cbm_mask": The bitmask which is valid for this resource.
|
||||
This mask is equivalent to 100%.
|
||||
|
||||
"min_cbm_bits": The minimum number of consecutive bits which must be
|
||||
set when writing a mask.
|
||||
"min_cbm_bits": The minimum number of consecutive bits which
|
||||
must be set when writing a mask.
|
||||
|
||||
Memory bandwitdh(MB) subdirectory contains the following files:
|
||||
|
||||
"min_bandwidth": The minimum memory bandwidth percentage which
|
||||
user can request.
|
||||
|
||||
"bandwidth_gran": The granularity in which the memory bandwidth
|
||||
percentage is allocated. The allocated
|
||||
b/w percentage is rounded off to the next
|
||||
control step available on the hardware. The
|
||||
available bandwidth control steps are:
|
||||
min_bandwidth + N * bandwidth_gran.
|
||||
|
||||
"delay_linear": Indicates if the delay scale is linear or
|
||||
non-linear. This field is purely informational
|
||||
only.
|
||||
|
||||
Resource groups
|
||||
---------------
|
||||
|
|
@ -59,6 +75,9 @@ There are three files associated with each group:
|
|||
given to the default (root) group. You cannot remove CPUs
|
||||
from the default group.
|
||||
|
||||
"cpus_list": One or more CPU ranges of logical CPUs assigned to this
|
||||
group. Same rules apply like for the "cpus" file.
|
||||
|
||||
"schemata": A list of all the resources available to this group.
|
||||
Each resource has its own line and format - see below for
|
||||
details.
|
||||
|
|
@ -107,6 +126,22 @@ and 0xA are not. On a system with a 20-bit mask each bit represents 5%
|
|||
of the capacity of the cache. You could partition the cache into four
|
||||
equal parts with masks: 0x1f, 0x3e0, 0x7c00, 0xf8000.
|
||||
|
||||
Memory bandwidth(b/w) percentage
|
||||
--------------------------------
|
||||
For Memory b/w resource, user controls the resource by indicating the
|
||||
percentage of total memory b/w.
|
||||
|
||||
The minimum bandwidth percentage value for each cpu model is predefined
|
||||
and can be looked up through "info/MB/min_bandwidth". The bandwidth
|
||||
granularity that is allocated is also dependent on the cpu model and can
|
||||
be looked up at "info/MB/bandwidth_gran". The available bandwidth
|
||||
control steps are: min_bw + N * bw_gran. Intermediate values are rounded
|
||||
to the next control step available on the hardware.
|
||||
|
||||
The bandwidth throttling is a core specific mechanism on some of Intel
|
||||
SKUs. Using a high bandwidth and a low bandwidth setting on two threads
|
||||
sharing a core will result in both threads being throttled to use the
|
||||
low bandwidth.
|
||||
|
||||
L3 details (code and data prioritization disabled)
|
||||
--------------------------------------------------
|
||||
|
|
@ -129,16 +164,38 @@ schemata format is always:
|
|||
|
||||
L2:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
|
||||
|
||||
Memory b/w Allocation details
|
||||
-----------------------------
|
||||
|
||||
Memory b/w domain is L3 cache.
|
||||
|
||||
MB:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;...
|
||||
|
||||
Reading/writing the schemata file
|
||||
---------------------------------
|
||||
Reading the schemata file will show the state of all resources
|
||||
on all domains. When writing you only need to specify those values
|
||||
which you wish to change. E.g.
|
||||
|
||||
# cat schemata
|
||||
L3DATA:0=fffff;1=fffff;2=fffff;3=fffff
|
||||
L3CODE:0=fffff;1=fffff;2=fffff;3=fffff
|
||||
# echo "L3DATA:2=3c0;" > schemata
|
||||
# cat schemata
|
||||
L3DATA:0=fffff;1=fffff;2=3c0;3=fffff
|
||||
L3CODE:0=fffff;1=fffff;2=fffff;3=fffff
|
||||
|
||||
Example 1
|
||||
---------
|
||||
On a two socket machine (one L3 cache per socket) with just four bits
|
||||
for cache bit masks
|
||||
for cache bit masks, minimum b/w of 10% with a memory bandwidth
|
||||
granularity of 10%
|
||||
|
||||
# mount -t resctrl resctrl /sys/fs/resctrl
|
||||
# cd /sys/fs/resctrl
|
||||
# mkdir p0 p1
|
||||
# echo "L3:0=3;1=c" > /sys/fs/resctrl/p0/schemata
|
||||
# echo "L3:0=3;1=3" > /sys/fs/resctrl/p1/schemata
|
||||
# echo "L3:0=3;1=c\nMB:0=50;1=50" > /sys/fs/resctrl/p0/schemata
|
||||
# echo "L3:0=3;1=3\nMB:0=50;1=50" > /sys/fs/resctrl/p1/schemata
|
||||
|
||||
The default resource group is unmodified, so we have access to all parts
|
||||
of all caches (its schemata file reads "L3:0=f;1=f").
|
||||
|
|
@ -147,6 +204,14 @@ Tasks that are under the control of group "p0" may only allocate from the
|
|||
"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1.
|
||||
Tasks in group "p1" use the "lower" 50% of cache on both sockets.
|
||||
|
||||
Similarly, tasks that are under the control of group "p0" may use a
|
||||
maximum memory b/w of 50% on socket0 and 50% on socket 1.
|
||||
Tasks in group "p1" may also use 50% memory b/w on both sockets.
|
||||
Note that unlike cache masks, memory b/w cannot specify whether these
|
||||
allocations can overlap or not. The allocations specifies the maximum
|
||||
b/w that the group may be able to use and the system admin can configure
|
||||
the b/w accordingly.
|
||||
|
||||
Example 2
|
||||
---------
|
||||
Again two sockets, but this time with a more realistic 20-bit mask.
|
||||
|
|
@ -160,9 +225,10 @@ of L3 cache on socket 0.
|
|||
# cd /sys/fs/resctrl
|
||||
|
||||
First we reset the schemata for the default group so that the "upper"
|
||||
50% of the L3 cache on socket 0 cannot be used by ordinary tasks:
|
||||
50% of the L3 cache on socket 0 and 50% of memory b/w cannot be used by
|
||||
ordinary tasks:
|
||||
|
||||
# echo "L3:0=3ff;1=fffff" > schemata
|
||||
# echo "L3:0=3ff;1=fffff\nMB:0=50;1=100" > schemata
|
||||
|
||||
Next we make a resource group for our first real time task and give
|
||||
it access to the "top" 25% of the cache on socket 0.
|
||||
|
|
@ -185,6 +251,20 @@ Ditto for the second real time task (with the remaining 25% of cache):
|
|||
# echo 5678 > p1/tasks
|
||||
# taskset -cp 2 5678
|
||||
|
||||
For the same 2 socket system with memory b/w resource and CAT L3 the
|
||||
schemata would look like(Assume min_bandwidth 10 and bandwidth_gran is
|
||||
10):
|
||||
|
||||
For our first real time task this would request 20% memory b/w on socket
|
||||
0.
|
||||
|
||||
# echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata
|
||||
|
||||
For our second real time task this would request an other 20% memory b/w
|
||||
on socket 0.
|
||||
|
||||
# echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata
|
||||
|
||||
Example 3
|
||||
---------
|
||||
|
||||
|
|
@ -198,18 +278,22 @@ the tasks.
|
|||
# cd /sys/fs/resctrl
|
||||
|
||||
First we reset the schemata for the default group so that the "upper"
|
||||
50% of the L3 cache on socket 0 cannot be used by ordinary tasks:
|
||||
50% of the L3 cache on socket 0, and 50% of memory bandwidth on socket 0
|
||||
cannot be used by ordinary tasks:
|
||||
|
||||
# echo "L3:0=3ff" > schemata
|
||||
# echo "L3:0=3ff\nMB:0=50" > schemata
|
||||
|
||||
Next we make a resource group for our real time cores and give
|
||||
it access to the "top" 50% of the cache on socket 0.
|
||||
Next we make a resource group for our real time cores and give it access
|
||||
to the "top" 50% of the cache on socket 0 and 50% of memory bandwidth on
|
||||
socket 0.
|
||||
|
||||
# mkdir p0
|
||||
# echo "L3:0=ffc00;" > p0/schemata
|
||||
# echo "L3:0=ffc00\nMB:0=50" > p0/schemata
|
||||
|
||||
Finally we move core 4-7 over to the new group and make sure that the
|
||||
kernel and the tasks running there get 50% of the cache.
|
||||
kernel and the tasks running there get 50% of the cache. They should
|
||||
also get 50% of memory bandwidth assuming that the cores 4-7 are SMT
|
||||
siblings and only the real time threads are scheduled on the cores 4-7.
|
||||
|
||||
# echo C0 > p0/cpus
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
Virtual memory map with 4 level page tables:
|
||||
|
||||
0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
|
||||
hole caused by [48:63] sign extension
|
||||
hole caused by [47:63] sign extension
|
||||
ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
|
||||
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
|
||||
ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
|
||||
|
|
@ -19,16 +19,43 @@ ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
|
|||
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
|
||||
... unused hole ...
|
||||
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0
|
||||
ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space (variable)
|
||||
ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
|
||||
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
|
||||
|
||||
Virtual memory map with 5 level page tables:
|
||||
|
||||
0000000000000000 - 00ffffffffffffff (=56 bits) user space, different per mm
|
||||
hole caused by [56:63] sign extension
|
||||
ff00000000000000 - ff0fffffffffffff (=52 bits) guard hole, reserved for hypervisor
|
||||
ff10000000000000 - ff8fffffffffffff (=55 bits) direct mapping of all phys. memory
|
||||
ff90000000000000 - ff91ffffffffffff (=49 bits) hole
|
||||
ff92000000000000 - ffd1ffffffffffff (=54 bits) vmalloc/ioremap space
|
||||
ffd2000000000000 - ffd3ffffffffffff (=49 bits) hole
|
||||
ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB)
|
||||
... unused hole ...
|
||||
ffd8000000000000 - fff7ffffffffffff (=53 bits) kasan shadow memory (8PB)
|
||||
... unused hole ...
|
||||
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
|
||||
... unused hole ...
|
||||
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
|
||||
... unused hole ...
|
||||
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0
|
||||
ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space
|
||||
ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
|
||||
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
|
||||
|
||||
Architecture defines a 64-bit virtual address. Implementations can support
|
||||
less. Currently supported are 48- and 57-bit virtual addresses. Bits 63
|
||||
through to the most-significant implemented bit are set to either all ones
|
||||
or all zero. This causes hole between user space and kernel addresses.
|
||||
|
||||
The direct mapping covers all memory in the system up to the highest
|
||||
memory address (this means in some cases it can also include PCI memory
|
||||
holes).
|
||||
|
||||
vmalloc space is lazily synchronized into the different PML4 pages of
|
||||
the processes using the page fault handler, with init_level4_pgt as
|
||||
vmalloc space is lazily synchronized into the different PML4/PML5 pages of
|
||||
the processes using the page fault handler, with init_top_pgt as
|
||||
reference.
|
||||
|
||||
Current X86-64 implementations support up to 46 bits of address space (64 TB),
|
||||
|
|
@ -39,6 +66,9 @@ memory window (this size is arbitrary, it can be raised later if needed).
|
|||
The mappings are not part of any other kernel PGD and are only available
|
||||
during EFI runtime calls.
|
||||
|
||||
The module mapping space size changes based on the CONFIG requirements for the
|
||||
following fixmap section.
|
||||
|
||||
Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
|
||||
physical memory, vmalloc/ioremap space and virtual memory map are randomized.
|
||||
Their order is preserved but their base will be offset early at boot time.
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Offset Proto Name Meaning
|
|||
1C0/020 ALL efi_info EFI 32 information (struct efi_info)
|
||||
1E0/004 ALL alk_mem_k Alternative mem check, in KB
|
||||
1E4/004 ALL scratch Scratch field for the kernel setup code
|
||||
1E8/001 ALL e820_entries Number of entries in e820_map (below)
|
||||
1E8/001 ALL e820_entries Number of entries in e820_table (below)
|
||||
1E9/001 ALL eddbuf_entries Number of entries in eddbuf (below)
|
||||
1EA/001 ALL edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
|
||||
(below)
|
||||
|
|
@ -35,6 +35,6 @@ Offset Proto Name Meaning
|
|||
1EC/001 ALL secure_boot Secure boot is enabled in the firmware
|
||||
1EF/001 ALL sentinel Used to detect broken bootloaders
|
||||
290/040 ALL edd_mbr_sig_buffer EDD MBR signatures
|
||||
2D0/A00 ALL e820_map E820 memory map table
|
||||
(array of struct e820entry)
|
||||
2D0/A00 ALL e820_table E820 memory map table
|
||||
(array of struct e820_entry)
|
||||
D00/1EC ALL eddbuf EDD data (array of struct edd_info)
|
||||
|
|
|
|||
43
MAINTAINERS
43
MAINTAINERS
|
|
@ -2327,21 +2327,6 @@ S: Maintained
|
|||
F: drivers/auxdisplay/
|
||||
F: include/linux/cfag12864b.h
|
||||
|
||||
AVR32 ARCHITECTURE
|
||||
M: Haavard Skinnemoen <hskinnemoen@gmail.com>
|
||||
M: Hans-Christian Egtvedt <egtvedt@samfundet.no>
|
||||
W: http://www.atmel.com/products/AVR32/
|
||||
W: http://mirror.egtvedt.no/avr32linux.org/
|
||||
W: http://avrfreaks.net/
|
||||
S: Maintained
|
||||
F: arch/avr32/
|
||||
|
||||
AVR32/AT32AP MACHINE SUPPORT
|
||||
M: Haavard Skinnemoen <hskinnemoen@gmail.com>
|
||||
M: Hans-Christian Egtvedt <egtvedt@samfundet.no>
|
||||
S: Maintained
|
||||
F: arch/avr32/mach-at32ap/
|
||||
|
||||
AX.25 NETWORK LAYER
|
||||
M: Ralf Baechle <ralf@linux-mips.org>
|
||||
L: linux-hams@vger.kernel.org
|
||||
|
|
@ -2544,6 +2529,14 @@ F: block/
|
|||
F: kernel/trace/blktrace.c
|
||||
F: lib/sbitmap.c
|
||||
|
||||
BFQ I/O SCHEDULER
|
||||
M: Paolo Valente <paolo.valente@linaro.org>
|
||||
M: Jens Axboe <axboe@kernel.dk>
|
||||
L: linux-block@vger.kernel.org
|
||||
S: Maintained
|
||||
F: block/bfq-*
|
||||
F: Documentation/block/bfq-iosched.txt
|
||||
|
||||
BLOCK2MTD DRIVER
|
||||
M: Joern Engel <joern@lazybastard.org>
|
||||
L: linux-mtd@lists.infradead.org
|
||||
|
|
@ -3463,6 +3456,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
|
|||
T: git git://git.linaro.org/people/vireshk/linux.git (For ARM Updates)
|
||||
B: https://bugzilla.kernel.org
|
||||
F: Documentation/cpu-freq/
|
||||
F: Documentation/devicetree/bindings/cpufreq/
|
||||
F: drivers/cpufreq/
|
||||
F: include/linux/cpufreq.h
|
||||
F: tools/testing/selftests/cpufreq/
|
||||
|
|
@ -4707,6 +4701,7 @@ L: linux-edac@vger.kernel.org
|
|||
L: linux-mips@linux-mips.org
|
||||
S: Supported
|
||||
F: drivers/edac/octeon_edac*
|
||||
F: drivers/edac/thunderx_edac*
|
||||
|
||||
EDAC-E752X
|
||||
M: Mark Gross <mark.gross@intel.com>
|
||||
|
|
@ -5420,6 +5415,23 @@ F: fs/fuse/
|
|||
F: include/uapi/linux/fuse.h
|
||||
F: Documentation/filesystems/fuse.txt
|
||||
|
||||
FUTEX SUBSYSTEM
|
||||
M: Thomas Gleixner <tglx@linutronix.de>
|
||||
M: Ingo Molnar <mingo@redhat.com>
|
||||
R: Peter Zijlstra <peterz@infradead.org>
|
||||
R: Darren Hart <dvhart@infradead.org>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core
|
||||
S: Maintained
|
||||
F: kernel/futex.c
|
||||
F: kernel/futex_compat.c
|
||||
F: include/asm-generic/futex.h
|
||||
F: include/linux/futex.h
|
||||
F: include/uapi/linux/futex.h
|
||||
F: tools/testing/selftests/futex/
|
||||
F: tools/perf/bench/futex*
|
||||
F: Documentation/*futex*
|
||||
|
||||
FUTURE DOMAIN TMC-16x0 SCSI DRIVER (16-bit)
|
||||
M: Rik Faith <faith@cs.unc.edu>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
|
|
@ -11124,6 +11136,7 @@ F: drivers/power/supply/bq27xxx_battery_i2c.c
|
|||
TIMEKEEPING, CLOCKSOURCE CORE, NTP, ALARMTIMER
|
||||
M: John Stultz <john.stultz@linaro.org>
|
||||
M: Thomas Gleixner <tglx@linutronix.de>
|
||||
R: Stephen Boyd <sboyd@codeaurora.org>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
|
||||
S: Supported
|
||||
|
|
|
|||
|
|
@ -700,6 +700,13 @@ config ARCH_MMAP_RND_COMPAT_BITS
|
|||
This value can be changed after boot using the
|
||||
/proc/sys/vm/mmap_rnd_compat_bits tunable
|
||||
|
||||
config HAVE_ARCH_COMPAT_MMAP_BASES
|
||||
bool
|
||||
help
|
||||
This allows 64bit applications to invoke 32-bit mmap() syscall
|
||||
and vice-versa 32-bit applications to call 64-bit mmap().
|
||||
Required for applications doing different bitness syscalls.
|
||||
|
||||
config HAVE_COPY_THREAD_TLS
|
||||
bool
|
||||
help
|
||||
|
|
|
|||
|
|
@ -0,0 +1,55 @@
|
|||
#ifndef _ASM_EXTABLE_H
|
||||
#define _ASM_EXTABLE_H
|
||||
|
||||
/*
|
||||
* About the exception table:
|
||||
*
|
||||
* - insn is a 32-bit pc-relative offset from the faulting insn.
|
||||
* - nextinsn is a 16-bit offset off of the faulting instruction
|
||||
* (not off of the *next* instruction as branches are).
|
||||
* - errreg is the register in which to place -EFAULT.
|
||||
* - valreg is the final target register for the load sequence
|
||||
* and will be zeroed.
|
||||
*
|
||||
* Either errreg or valreg may be $31, in which case nothing happens.
|
||||
*
|
||||
* The exception fixup information "just so happens" to be arranged
|
||||
* as in a MEM format instruction. This lets us emit our three
|
||||
* values like so:
|
||||
*
|
||||
* lda valreg, nextinsn(errreg)
|
||||
*
|
||||
*/
|
||||
|
||||
struct exception_table_entry
|
||||
{
|
||||
signed int insn;
|
||||
union exception_fixup {
|
||||
unsigned unit;
|
||||
struct {
|
||||
signed int nextinsn : 16;
|
||||
unsigned int errreg : 5;
|
||||
unsigned int valreg : 5;
|
||||
} bits;
|
||||
} fixup;
|
||||
};
|
||||
|
||||
/* Returns the new pc */
|
||||
#define fixup_exception(map_reg, _fixup, pc) \
|
||||
({ \
|
||||
if ((_fixup)->fixup.bits.valreg != 31) \
|
||||
map_reg((_fixup)->fixup.bits.valreg) = 0; \
|
||||
if ((_fixup)->fixup.bits.errreg != 31) \
|
||||
map_reg((_fixup)->fixup.bits.errreg) = -EFAULT; \
|
||||
(pc) + (_fixup)->fixup.bits.nextinsn; \
|
||||
})
|
||||
|
||||
#define ARCH_HAS_RELATIVE_EXTABLE
|
||||
|
||||
#define swap_ex_entry_fixup(a, b, tmp, delta) \
|
||||
do { \
|
||||
(a)->fixup.unit = (b)->fixup.unit; \
|
||||
(b)->fixup.unit = (tmp).fixup.unit; \
|
||||
} while (0)
|
||||
|
||||
#endif
|
||||
|
|
@ -19,12 +19,8 @@
|
|||
"3: .subsection 2\n" \
|
||||
"4: br 1b\n" \
|
||||
" .previous\n" \
|
||||
" .section __ex_table,\"a\"\n" \
|
||||
" .long 1b-.\n" \
|
||||
" lda $31,3b-1b(%1)\n" \
|
||||
" .long 2b-.\n" \
|
||||
" lda $31,3b-2b(%1)\n" \
|
||||
" .previous\n" \
|
||||
EXC(1b,3b,%1,$31) \
|
||||
EXC(2b,3b,%1,$31) \
|
||||
: "=&r" (oldval), "=&r"(ret) \
|
||||
: "r" (uaddr), "r"(oparg) \
|
||||
: "memory")
|
||||
|
|
@ -101,12 +97,8 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
|
|||
"3: .subsection 2\n"
|
||||
"4: br 1b\n"
|
||||
" .previous\n"
|
||||
" .section __ex_table,\"a\"\n"
|
||||
" .long 1b-.\n"
|
||||
" lda $31,3b-1b(%0)\n"
|
||||
" .long 2b-.\n"
|
||||
" lda $31,3b-2b(%0)\n"
|
||||
" .previous\n"
|
||||
EXC(1b,3b,%0,$31)
|
||||
EXC(2b,3b,%0,$31)
|
||||
: "+r"(ret), "=&r"(prev), "=&r"(cmp)
|
||||
: "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
|
||||
: "memory");
|
||||
|
|
|
|||
|
|
@ -1,10 +1,6 @@
|
|||
#ifndef __ALPHA_UACCESS_H
|
||||
#define __ALPHA_UACCESS_H
|
||||
|
||||
#include <linux/errno.h>
|
||||
#include <linux/sched.h>
|
||||
|
||||
|
||||
/*
|
||||
* The fs value determines whether argument validity checking should be
|
||||
* performed or not. If get_fs() == USER_DS, checking is performed, with
|
||||
|
|
@ -20,9 +16,6 @@
|
|||
#define KERNEL_DS ((mm_segment_t) { 0UL })
|
||||
#define USER_DS ((mm_segment_t) { -0x40000000000UL })
|
||||
|
||||
#define VERIFY_READ 0
|
||||
#define VERIFY_WRITE 1
|
||||
|
||||
#define get_fs() (current_thread_info()->addr_limit)
|
||||
#define get_ds() (KERNEL_DS)
|
||||
#define set_fs(x) (current_thread_info()->addr_limit = (x))
|
||||
|
|
@ -39,13 +32,13 @@
|
|||
* - AND "addr+size" doesn't have any high-bits set
|
||||
* - OR we are in kernel mode.
|
||||
*/
|
||||
#define __access_ok(addr, size, segment) \
|
||||
(((segment).seg & (addr | size | (addr+size))) == 0)
|
||||
#define __access_ok(addr, size) \
|
||||
((get_fs().seg & (addr | size | (addr+size))) == 0)
|
||||
|
||||
#define access_ok(type, addr, size) \
|
||||
({ \
|
||||
__chk_user_ptr(addr); \
|
||||
__access_ok(((unsigned long)(addr)), (size), get_fs()); \
|
||||
#define access_ok(type, addr, size) \
|
||||
({ \
|
||||
__chk_user_ptr(addr); \
|
||||
__access_ok(((unsigned long)(addr)), (size)); \
|
||||
})
|
||||
|
||||
/*
|
||||
|
|
@ -61,9 +54,9 @@
|
|||
* (b) require any knowledge of processes at this stage
|
||||
*/
|
||||
#define put_user(x, ptr) \
|
||||
__put_user_check((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)), get_fs())
|
||||
__put_user_check((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
|
||||
#define get_user(x, ptr) \
|
||||
__get_user_check((x), (ptr), sizeof(*(ptr)), get_fs())
|
||||
__get_user_check((x), (ptr), sizeof(*(ptr)))
|
||||
|
||||
/*
|
||||
* The "__xxx" versions do not do address space checking, useful when
|
||||
|
|
@ -81,6 +74,11 @@
|
|||
* more extensive comments with fixup_inline_exception below for
|
||||
* more information.
|
||||
*/
|
||||
#define EXC(label,cont,res,err) \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long "#label"-.\n" \
|
||||
" lda "#res","#cont"-"#label"("#err")\n" \
|
||||
".previous\n"
|
||||
|
||||
extern void __get_user_unknown(void);
|
||||
|
||||
|
|
@ -100,23 +98,23 @@ extern void __get_user_unknown(void);
|
|||
__gu_err; \
|
||||
})
|
||||
|
||||
#define __get_user_check(x, ptr, size, segment) \
|
||||
({ \
|
||||
long __gu_err = -EFAULT; \
|
||||
unsigned long __gu_val = 0; \
|
||||
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
|
||||
if (__access_ok((unsigned long)__gu_addr, size, segment)) { \
|
||||
__gu_err = 0; \
|
||||
switch (size) { \
|
||||
case 1: __get_user_8(__gu_addr); break; \
|
||||
case 2: __get_user_16(__gu_addr); break; \
|
||||
case 4: __get_user_32(__gu_addr); break; \
|
||||
case 8: __get_user_64(__gu_addr); break; \
|
||||
default: __get_user_unknown(); break; \
|
||||
} \
|
||||
} \
|
||||
(x) = (__force __typeof__(*(ptr))) __gu_val; \
|
||||
__gu_err; \
|
||||
#define __get_user_check(x, ptr, size) \
|
||||
({ \
|
||||
long __gu_err = -EFAULT; \
|
||||
unsigned long __gu_val = 0; \
|
||||
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
|
||||
if (__access_ok((unsigned long)__gu_addr, size)) { \
|
||||
__gu_err = 0; \
|
||||
switch (size) { \
|
||||
case 1: __get_user_8(__gu_addr); break; \
|
||||
case 2: __get_user_16(__gu_addr); break; \
|
||||
case 4: __get_user_32(__gu_addr); break; \
|
||||
case 8: __get_user_64(__gu_addr); break; \
|
||||
default: __get_user_unknown(); break; \
|
||||
} \
|
||||
} \
|
||||
(x) = (__force __typeof__(*(ptr))) __gu_val; \
|
||||
__gu_err; \
|
||||
})
|
||||
|
||||
struct __large_struct { unsigned long buf[100]; };
|
||||
|
|
@ -125,20 +123,14 @@ struct __large_struct { unsigned long buf[100]; };
|
|||
#define __get_user_64(addr) \
|
||||
__asm__("1: ldq %0,%2\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda %0, 2b-1b(%1)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,%0,%1) \
|
||||
: "=r"(__gu_val), "=r"(__gu_err) \
|
||||
: "m"(__m(addr)), "1"(__gu_err))
|
||||
|
||||
#define __get_user_32(addr) \
|
||||
__asm__("1: ldl %0,%2\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda %0, 2b-1b(%1)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,%0,%1) \
|
||||
: "=r"(__gu_val), "=r"(__gu_err) \
|
||||
: "m"(__m(addr)), "1"(__gu_err))
|
||||
|
||||
|
|
@ -148,20 +140,14 @@ struct __large_struct { unsigned long buf[100]; };
|
|||
#define __get_user_16(addr) \
|
||||
__asm__("1: ldwu %0,%2\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda %0, 2b-1b(%1)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,%0,%1) \
|
||||
: "=r"(__gu_val), "=r"(__gu_err) \
|
||||
: "m"(__m(addr)), "1"(__gu_err))
|
||||
|
||||
#define __get_user_8(addr) \
|
||||
__asm__("1: ldbu %0,%2\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda %0, 2b-1b(%1)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,%0,%1) \
|
||||
: "=r"(__gu_val), "=r"(__gu_err) \
|
||||
: "m"(__m(addr)), "1"(__gu_err))
|
||||
#else
|
||||
|
|
@ -177,12 +163,8 @@ struct __large_struct { unsigned long buf[100]; };
|
|||
" extwh %1,%3,%1\n" \
|
||||
" or %0,%1,%0\n" \
|
||||
"3:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda %0, 3b-1b(%2)\n" \
|
||||
" .long 2b - .\n" \
|
||||
" lda %0, 3b-2b(%2)\n" \
|
||||
".previous" \
|
||||
EXC(1b,3b,%0,%2) \
|
||||
EXC(2b,3b,%0,%2) \
|
||||
: "=&r"(__gu_val), "=&r"(__gu_tmp), "=r"(__gu_err) \
|
||||
: "r"(addr), "2"(__gu_err)); \
|
||||
}
|
||||
|
|
@ -191,10 +173,7 @@ struct __large_struct { unsigned long buf[100]; };
|
|||
__asm__("1: ldq_u %0,0(%2)\n" \
|
||||
" extbl %0,%2,%0\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda %0, 2b-1b(%1)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,%0,%1) \
|
||||
: "=&r"(__gu_val), "=r"(__gu_err) \
|
||||
: "r"(addr), "1"(__gu_err))
|
||||
#endif
|
||||
|
|
@ -215,21 +194,21 @@ extern void __put_user_unknown(void);
|
|||
__pu_err; \
|
||||
})
|
||||
|
||||
#define __put_user_check(x, ptr, size, segment) \
|
||||
({ \
|
||||
long __pu_err = -EFAULT; \
|
||||
__typeof__(*(ptr)) __user *__pu_addr = (ptr); \
|
||||
if (__access_ok((unsigned long)__pu_addr, size, segment)) { \
|
||||
__pu_err = 0; \
|
||||
switch (size) { \
|
||||
case 1: __put_user_8(x, __pu_addr); break; \
|
||||
case 2: __put_user_16(x, __pu_addr); break; \
|
||||
case 4: __put_user_32(x, __pu_addr); break; \
|
||||
case 8: __put_user_64(x, __pu_addr); break; \
|
||||
default: __put_user_unknown(); break; \
|
||||
} \
|
||||
} \
|
||||
__pu_err; \
|
||||
#define __put_user_check(x, ptr, size) \
|
||||
({ \
|
||||
long __pu_err = -EFAULT; \
|
||||
__typeof__(*(ptr)) __user *__pu_addr = (ptr); \
|
||||
if (__access_ok((unsigned long)__pu_addr, size)) { \
|
||||
__pu_err = 0; \
|
||||
switch (size) { \
|
||||
case 1: __put_user_8(x, __pu_addr); break; \
|
||||
case 2: __put_user_16(x, __pu_addr); break; \
|
||||
case 4: __put_user_32(x, __pu_addr); break; \
|
||||
case 8: __put_user_64(x, __pu_addr); break; \
|
||||
default: __put_user_unknown(); break; \
|
||||
} \
|
||||
} \
|
||||
__pu_err; \
|
||||
})
|
||||
|
||||
/*
|
||||
|
|
@ -240,20 +219,14 @@ extern void __put_user_unknown(void);
|
|||
#define __put_user_64(x, addr) \
|
||||
__asm__ __volatile__("1: stq %r2,%1\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda $31,2b-1b(%0)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,$31,%0) \
|
||||
: "=r"(__pu_err) \
|
||||
: "m" (__m(addr)), "rJ" (x), "0"(__pu_err))
|
||||
|
||||
#define __put_user_32(x, addr) \
|
||||
__asm__ __volatile__("1: stl %r2,%1\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda $31,2b-1b(%0)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,$31,%0) \
|
||||
: "=r"(__pu_err) \
|
||||
: "m"(__m(addr)), "rJ"(x), "0"(__pu_err))
|
||||
|
||||
|
|
@ -263,20 +236,14 @@ __asm__ __volatile__("1: stl %r2,%1\n" \
|
|||
#define __put_user_16(x, addr) \
|
||||
__asm__ __volatile__("1: stw %r2,%1\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda $31,2b-1b(%0)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,$31,%0) \
|
||||
: "=r"(__pu_err) \
|
||||
: "m"(__m(addr)), "rJ"(x), "0"(__pu_err))
|
||||
|
||||
#define __put_user_8(x, addr) \
|
||||
__asm__ __volatile__("1: stb %r2,%1\n" \
|
||||
"2:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda $31,2b-1b(%0)\n" \
|
||||
".previous" \
|
||||
EXC(1b,2b,$31,%0) \
|
||||
: "=r"(__pu_err) \
|
||||
: "m"(__m(addr)), "rJ"(x), "0"(__pu_err))
|
||||
#else
|
||||
|
|
@ -298,16 +265,10 @@ __asm__ __volatile__("1: stb %r2,%1\n" \
|
|||
"3: stq_u %2,1(%5)\n" \
|
||||
"4: stq_u %1,0(%5)\n" \
|
||||
"5:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda $31, 5b-1b(%0)\n" \
|
||||
" .long 2b - .\n" \
|
||||
" lda $31, 5b-2b(%0)\n" \
|
||||
" .long 3b - .\n" \
|
||||
" lda $31, 5b-3b(%0)\n" \
|
||||
" .long 4b - .\n" \
|
||||
" lda $31, 5b-4b(%0)\n" \
|
||||
".previous" \
|
||||
EXC(1b,5b,$31,%0) \
|
||||
EXC(2b,5b,$31,%0) \
|
||||
EXC(3b,5b,$31,%0) \
|
||||
EXC(4b,5b,$31,%0) \
|
||||
: "=r"(__pu_err), "=&r"(__pu_tmp1), \
|
||||
"=&r"(__pu_tmp2), "=&r"(__pu_tmp3), \
|
||||
"=&r"(__pu_tmp4) \
|
||||
|
|
@ -324,12 +285,8 @@ __asm__ __volatile__("1: stb %r2,%1\n" \
|
|||
" or %1,%2,%1\n" \
|
||||
"2: stq_u %1,0(%4)\n" \
|
||||
"3:\n" \
|
||||
".section __ex_table,\"a\"\n" \
|
||||
" .long 1b - .\n" \
|
||||
" lda $31, 3b-1b(%0)\n" \
|
||||
" .long 2b - .\n" \
|
||||
" lda $31, 3b-2b(%0)\n" \
|
||||
".previous" \
|
||||
EXC(1b,3b,$31,%0) \
|
||||
EXC(2b,3b,$31,%0) \
|
||||
: "=r"(__pu_err), \
|
||||
"=&r"(__pu_tmp1), "=&r"(__pu_tmp2) \
|
||||
: "r"((unsigned long)(x)), "r"(addr), "0"(__pu_err)); \
|
||||
|
|
@ -341,153 +298,37 @@ __asm__ __volatile__("1: stb %r2,%1\n" \
|
|||
* Complex access routines
|
||||
*/
|
||||
|
||||
/* This little bit of silliness is to get the GP loaded for a function
|
||||
that ordinarily wouldn't. Otherwise we could have it done by the macro
|
||||
directly, which can be optimized the linker. */
|
||||
#ifdef MODULE
|
||||
#define __module_address(sym) "r"(sym),
|
||||
#define __module_call(ra, arg, sym) "jsr $" #ra ",(%" #arg ")," #sym
|
||||
#else
|
||||
#define __module_address(sym)
|
||||
#define __module_call(ra, arg, sym) "bsr $" #ra "," #sym " !samegp"
|
||||
#endif
|
||||
extern long __copy_user(void *to, const void *from, long len);
|
||||
|
||||
extern void __copy_user(void);
|
||||
|
||||
extern inline long
|
||||
__copy_tofrom_user_nocheck(void *to, const void *from, long len)
|
||||
static inline unsigned long
|
||||
raw_copy_from_user(void *to, const void __user *from, unsigned long len)
|
||||
{
|
||||
register void * __cu_to __asm__("$6") = to;
|
||||
register const void * __cu_from __asm__("$7") = from;
|
||||
register long __cu_len __asm__("$0") = len;
|
||||
|
||||
__asm__ __volatile__(
|
||||
__module_call(28, 3, __copy_user)
|
||||
: "=r" (__cu_len), "=r" (__cu_from), "=r" (__cu_to)
|
||||
: __module_address(__copy_user)
|
||||
"0" (__cu_len), "1" (__cu_from), "2" (__cu_to)
|
||||
: "$1", "$2", "$3", "$4", "$5", "$28", "memory");
|
||||
|
||||
return __cu_len;
|
||||
return __copy_user(to, (__force const void *)from, len);
|
||||
}
|
||||
|
||||
#define __copy_to_user(to, from, n) \
|
||||
({ \
|
||||
__chk_user_ptr(to); \
|
||||
__copy_tofrom_user_nocheck((__force void *)(to), (from), (n)); \
|
||||
})
|
||||
#define __copy_from_user(to, from, n) \
|
||||
({ \
|
||||
__chk_user_ptr(from); \
|
||||
__copy_tofrom_user_nocheck((to), (__force void *)(from), (n)); \
|
||||
})
|
||||
|
||||
#define __copy_to_user_inatomic __copy_to_user
|
||||
#define __copy_from_user_inatomic __copy_from_user
|
||||
|
||||
extern inline long
|
||||
copy_to_user(void __user *to, const void *from, long n)
|
||||
static inline unsigned long
|
||||
raw_copy_to_user(void __user *to, const void *from, unsigned long len)
|
||||
{
|
||||
if (likely(__access_ok((unsigned long)to, n, get_fs())))
|
||||
n = __copy_tofrom_user_nocheck((__force void *)to, from, n);
|
||||
return n;
|
||||
return __copy_user((__force void *)to, from, len);
|
||||
}
|
||||
|
||||
extern inline long
|
||||
copy_from_user(void *to, const void __user *from, long n)
|
||||
{
|
||||
long res = n;
|
||||
if (likely(__access_ok((unsigned long)from, n, get_fs())))
|
||||
res = __copy_from_user_inatomic(to, from, n);
|
||||
if (unlikely(res))
|
||||
memset(to + (n - res), 0, res);
|
||||
return res;
|
||||
}
|
||||
|
||||
extern void __do_clear_user(void);
|
||||
|
||||
extern inline long
|
||||
__clear_user(void __user *to, long len)
|
||||
{
|
||||
register void __user * __cl_to __asm__("$6") = to;
|
||||
register long __cl_len __asm__("$0") = len;
|
||||
__asm__ __volatile__(
|
||||
__module_call(28, 2, __do_clear_user)
|
||||
: "=r"(__cl_len), "=r"(__cl_to)
|
||||
: __module_address(__do_clear_user)
|
||||
"0"(__cl_len), "1"(__cl_to)
|
||||
: "$1", "$2", "$3", "$4", "$5", "$28", "memory");
|
||||
return __cl_len;
|
||||
}
|
||||
extern long __clear_user(void __user *to, long len);
|
||||
|
||||
extern inline long
|
||||
clear_user(void __user *to, long len)
|
||||
{
|
||||
if (__access_ok((unsigned long)to, len, get_fs()))
|
||||
if (__access_ok((unsigned long)to, len))
|
||||
len = __clear_user(to, len);
|
||||
return len;
|
||||
}
|
||||
|
||||
#undef __module_address
|
||||
#undef __module_call
|
||||
|
||||
#define user_addr_max() \
|
||||
(segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL)
|
||||
(uaccess_kernel() ? ~0UL : TASK_SIZE)
|
||||
|
||||
extern long strncpy_from_user(char *dest, const char __user *src, long count);
|
||||
extern __must_check long strlen_user(const char __user *str);
|
||||
extern __must_check long strnlen_user(const char __user *str, long n);
|
||||
|
||||
/*
|
||||
* About the exception table:
|
||||
*
|
||||
* - insn is a 32-bit pc-relative offset from the faulting insn.
|
||||
* - nextinsn is a 16-bit offset off of the faulting instruction
|
||||
* (not off of the *next* instruction as branches are).
|
||||
* - errreg is the register in which to place -EFAULT.
|
||||
* - valreg is the final target register for the load sequence
|
||||
* and will be zeroed.
|
||||
*
|
||||
* Either errreg or valreg may be $31, in which case nothing happens.
|
||||
*
|
||||
* The exception fixup information "just so happens" to be arranged
|
||||
* as in a MEM format instruction. This lets us emit our three
|
||||
* values like so:
|
||||
*
|
||||
* lda valreg, nextinsn(errreg)
|
||||
*
|
||||
*/
|
||||
|
||||
struct exception_table_entry
|
||||
{
|
||||
signed int insn;
|
||||
union exception_fixup {
|
||||
unsigned unit;
|
||||
struct {
|
||||
signed int nextinsn : 16;
|
||||
unsigned int errreg : 5;
|
||||
unsigned int valreg : 5;
|
||||
} bits;
|
||||
} fixup;
|
||||
};
|
||||
|
||||
/* Returns the new pc */
|
||||
#define fixup_exception(map_reg, _fixup, pc) \
|
||||
({ \
|
||||
if ((_fixup)->fixup.bits.valreg != 31) \
|
||||
map_reg((_fixup)->fixup.bits.valreg) = 0; \
|
||||
if ((_fixup)->fixup.bits.errreg != 31) \
|
||||
map_reg((_fixup)->fixup.bits.errreg) = -EFAULT; \
|
||||
(pc) + (_fixup)->fixup.bits.nextinsn; \
|
||||
})
|
||||
|
||||
#define ARCH_HAS_RELATIVE_EXTABLE
|
||||
|
||||
#define swap_ex_entry_fixup(a, b, tmp, delta) \
|
||||
do { \
|
||||
(a)->fixup.unit = (b)->fixup.unit; \
|
||||
(b)->fixup.unit = (tmp).fixup.unit; \
|
||||
} while (0)
|
||||
|
||||
#include <asm/extable.h>
|
||||
|
||||
#endif /* __ALPHA_UACCESS_H */
|
||||
|
|
|
|||
|
|
@ -1016,6 +1016,7 @@ SYSCALL_DEFINE2(osf_gettimeofday, struct timeval32 __user *, tv,
|
|||
SYSCALL_DEFINE2(osf_settimeofday, struct timeval32 __user *, tv,
|
||||
struct timezone __user *, tz)
|
||||
{
|
||||
struct timespec64 kts64;
|
||||
struct timespec kts;
|
||||
struct timezone ktz;
|
||||
|
||||
|
|
@ -1023,13 +1024,14 @@ SYSCALL_DEFINE2(osf_settimeofday, struct timeval32 __user *, tv,
|
|||
if (get_tv32((struct timeval *)&kts, tv))
|
||||
return -EFAULT;
|
||||
kts.tv_nsec *= 1000;
|
||||
kts64 = timespec_to_timespec64(kts);
|
||||
}
|
||||
if (tz) {
|
||||
if (copy_from_user(&ktz, tz, sizeof(*tz)))
|
||||
return -EFAULT;
|
||||
}
|
||||
|
||||
return do_sys_settimeofday(tv ? &kts : NULL, tz ? &ktz : NULL);
|
||||
return do_sys_settimeofday64(tv ? &kts64 : NULL, tz ? &ktz : NULL);
|
||||
}
|
||||
|
||||
asmlinkage long sys_ni_posix_timers(void);
|
||||
|
|
|
|||
|
|
@ -482,12 +482,8 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
|
|||
" extwl %1,%3,%1\n"
|
||||
" extwh %2,%3,%2\n"
|
||||
"3:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %1,3b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %2,3b-2b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,3b,%1,%0)
|
||||
EXC(2b,3b,%2,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2)
|
||||
: "r"(va), "0"(0));
|
||||
if (error)
|
||||
|
|
@ -502,12 +498,8 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
|
|||
" extll %1,%3,%1\n"
|
||||
" extlh %2,%3,%2\n"
|
||||
"3:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %1,3b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %2,3b-2b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,3b,%1,%0)
|
||||
EXC(2b,3b,%2,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2)
|
||||
: "r"(va), "0"(0));
|
||||
if (error)
|
||||
|
|
@ -522,12 +514,8 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
|
|||
" extql %1,%3,%1\n"
|
||||
" extqh %2,%3,%2\n"
|
||||
"3:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %1,3b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %2,3b-2b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,3b,%1,%0)
|
||||
EXC(2b,3b,%2,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2)
|
||||
: "r"(va), "0"(0));
|
||||
if (error)
|
||||
|
|
@ -551,16 +539,10 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
|
|||
"3: stq_u %2,1(%5)\n"
|
||||
"4: stq_u %1,0(%5)\n"
|
||||
"5:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %2,5b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %1,5b-2b(%0)\n"
|
||||
" .long 3b - .\n"
|
||||
" lda $31,5b-3b(%0)\n"
|
||||
" .long 4b - .\n"
|
||||
" lda $31,5b-4b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,5b,%2,%0)
|
||||
EXC(2b,5b,%1,%0)
|
||||
EXC(3b,5b,$31,%0)
|
||||
EXC(4b,5b,$31,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2),
|
||||
"=&r"(tmp3), "=&r"(tmp4)
|
||||
: "r"(va), "r"(una_reg(reg)), "0"(0));
|
||||
|
|
@ -581,16 +563,10 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
|
|||
"3: stq_u %2,3(%5)\n"
|
||||
"4: stq_u %1,0(%5)\n"
|
||||
"5:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %2,5b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %1,5b-2b(%0)\n"
|
||||
" .long 3b - .\n"
|
||||
" lda $31,5b-3b(%0)\n"
|
||||
" .long 4b - .\n"
|
||||
" lda $31,5b-4b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,5b,%2,%0)
|
||||
EXC(2b,5b,%1,%0)
|
||||
EXC(3b,5b,$31,%0)
|
||||
EXC(4b,5b,$31,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2),
|
||||
"=&r"(tmp3), "=&r"(tmp4)
|
||||
: "r"(va), "r"(una_reg(reg)), "0"(0));
|
||||
|
|
@ -611,16 +587,10 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
|
|||
"3: stq_u %2,7(%5)\n"
|
||||
"4: stq_u %1,0(%5)\n"
|
||||
"5:\n"
|
||||
".section __ex_table,\"a\"\n\t"
|
||||
" .long 1b - .\n"
|
||||
" lda %2,5b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %1,5b-2b(%0)\n"
|
||||
" .long 3b - .\n"
|
||||
" lda $31,5b-3b(%0)\n"
|
||||
" .long 4b - .\n"
|
||||
" lda $31,5b-4b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,5b,%2,%0)
|
||||
EXC(2b,5b,%1,%0)
|
||||
EXC(3b,5b,$31,%0)
|
||||
EXC(4b,5b,$31,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2),
|
||||
"=&r"(tmp3), "=&r"(tmp4)
|
||||
: "r"(va), "r"(una_reg(reg)), "0"(0));
|
||||
|
|
@ -802,7 +772,7 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
/* Don't bother reading ds in the access check since we already
|
||||
know that this came from the user. Also rely on the fact that
|
||||
the page at TASK_SIZE is unmapped and so can't be touched anyway. */
|
||||
if (!__access_ok((unsigned long)va, 0, USER_DS))
|
||||
if ((unsigned long)va >= TASK_SIZE)
|
||||
goto give_sigsegv;
|
||||
|
||||
++unaligned[1].count;
|
||||
|
|
@ -835,12 +805,8 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
" extwl %1,%3,%1\n"
|
||||
" extwh %2,%3,%2\n"
|
||||
"3:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %1,3b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %2,3b-2b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,3b,%1,%0)
|
||||
EXC(2b,3b,%2,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2)
|
||||
: "r"(va), "0"(0));
|
||||
if (error)
|
||||
|
|
@ -855,12 +821,8 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
" extll %1,%3,%1\n"
|
||||
" extlh %2,%3,%2\n"
|
||||
"3:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %1,3b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %2,3b-2b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,3b,%1,%0)
|
||||
EXC(2b,3b,%2,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2)
|
||||
: "r"(va), "0"(0));
|
||||
if (error)
|
||||
|
|
@ -875,12 +837,8 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
" extql %1,%3,%1\n"
|
||||
" extqh %2,%3,%2\n"
|
||||
"3:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %1,3b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %2,3b-2b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,3b,%1,%0)
|
||||
EXC(2b,3b,%2,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2)
|
||||
: "r"(va), "0"(0));
|
||||
if (error)
|
||||
|
|
@ -895,12 +853,8 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
" extll %1,%3,%1\n"
|
||||
" extlh %2,%3,%2\n"
|
||||
"3:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %1,3b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %2,3b-2b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,3b,%1,%0)
|
||||
EXC(2b,3b,%2,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2)
|
||||
: "r"(va), "0"(0));
|
||||
if (error)
|
||||
|
|
@ -915,12 +869,8 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
" extql %1,%3,%1\n"
|
||||
" extqh %2,%3,%2\n"
|
||||
"3:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %1,3b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %2,3b-2b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,3b,%1,%0)
|
||||
EXC(2b,3b,%2,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2)
|
||||
: "r"(va), "0"(0));
|
||||
if (error)
|
||||
|
|
@ -944,16 +894,10 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
"3: stq_u %2,1(%5)\n"
|
||||
"4: stq_u %1,0(%5)\n"
|
||||
"5:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %2,5b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %1,5b-2b(%0)\n"
|
||||
" .long 3b - .\n"
|
||||
" lda $31,5b-3b(%0)\n"
|
||||
" .long 4b - .\n"
|
||||
" lda $31,5b-4b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,5b,%2,%0)
|
||||
EXC(2b,5b,%1,%0)
|
||||
EXC(3b,5b,$31,%0)
|
||||
EXC(4b,5b,$31,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2),
|
||||
"=&r"(tmp3), "=&r"(tmp4)
|
||||
: "r"(va), "r"(*reg_addr), "0"(0));
|
||||
|
|
@ -978,16 +922,10 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
"3: stq_u %2,3(%5)\n"
|
||||
"4: stq_u %1,0(%5)\n"
|
||||
"5:\n"
|
||||
".section __ex_table,\"a\"\n"
|
||||
" .long 1b - .\n"
|
||||
" lda %2,5b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %1,5b-2b(%0)\n"
|
||||
" .long 3b - .\n"
|
||||
" lda $31,5b-3b(%0)\n"
|
||||
" .long 4b - .\n"
|
||||
" lda $31,5b-4b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,5b,%2,%0)
|
||||
EXC(2b,5b,%1,%0)
|
||||
EXC(3b,5b,$31,%0)
|
||||
EXC(4b,5b,$31,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2),
|
||||
"=&r"(tmp3), "=&r"(tmp4)
|
||||
: "r"(va), "r"(*reg_addr), "0"(0));
|
||||
|
|
@ -1012,16 +950,10 @@ do_entUnaUser(void __user * va, unsigned long opcode,
|
|||
"3: stq_u %2,7(%5)\n"
|
||||
"4: stq_u %1,0(%5)\n"
|
||||
"5:\n"
|
||||
".section __ex_table,\"a\"\n\t"
|
||||
" .long 1b - .\n"
|
||||
" lda %2,5b-1b(%0)\n"
|
||||
" .long 2b - .\n"
|
||||
" lda %1,5b-2b(%0)\n"
|
||||
" .long 3b - .\n"
|
||||
" lda $31,5b-3b(%0)\n"
|
||||
" .long 4b - .\n"
|
||||
" lda $31,5b-4b(%0)\n"
|
||||
".previous"
|
||||
EXC(1b,5b,%2,%0)
|
||||
EXC(2b,5b,%1,%0)
|
||||
EXC(3b,5b,$31,%0)
|
||||
EXC(4b,5b,$31,%0)
|
||||
: "=r"(error), "=&r"(tmp1), "=&r"(tmp2),
|
||||
"=&r"(tmp3), "=&r"(tmp4)
|
||||
: "r"(va), "r"(*reg_addr), "0"(0));
|
||||
|
|
@ -1047,7 +979,7 @@ give_sigsegv:
|
|||
/* We need to replicate some of the logic in mm/fault.c,
|
||||
since we don't have access to the fault code in the
|
||||
exception handling return path. */
|
||||
if (!__access_ok((unsigned long)va, 0, USER_DS))
|
||||
if ((unsigned long)va >= TASK_SIZE)
|
||||
info.si_code = SEGV_ACCERR;
|
||||
else {
|
||||
struct mm_struct *mm = current->mm;
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue