Linux 3.7-rc1
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQEcBAABAgAGBQJQezF+AAoJEHm+PkMAQRiG2wkIAIpxXCCZo8SsxOimo0jkb50r Ouufv/92lz7LNqPEsaQDYXNni+1ObEnADU2XbXdfJ6pdQkfw3Phu/IIzZAufIS21 ZTDgK04D1HA0inx8ywHr96bSEfHu0RCuj5jMu2/N5F5jZbvvaHpeIaCfKWXtQ2Tg yAuFY6mp6MVXCJPnJbvb5inVpDlfAXCHQ4BLFHQL0MhfPW0eNHhgyWJQsn8UywxK rYdIet1RAL+iY+C7gr5SIRXRg0CF8zAyBRJMIyB8kfY26YvwEy75zHf1TavxtT1X o4B/WSqO4JbAM4yuRFFpb/ehNtfalxLX7JFexSHzBRev95yllQ6a3UTgtM1Ch8E= =Vg7R -----END PGP SIGNATURE----- Merge tag 'v3.7-rc1' into staging/for_v3.8 Linux 3.7-rc1 * tag 'v3.7-rc1': (9579 commits) Linux 3.7-rc1 x86, boot: Explicitly include autoconf.h for hostprogs perf: Fix UAPI fallout ARM: config: make sure that platforms are ordered by option string ARM: config: sort select statements alphanumerically UAPI: (Scripted) Disintegrate include/linux/byteorder UAPI: (Scripted) Disintegrate include/linux UAPI: Unexport linux/blk_types.h UAPI: Unexport part of linux/ppp-comp.h perf: Handle new rbtree implementation procfs: don't need a PATH_MAX allocation to hold a string representation of an int vfs: embed struct filename inside of names_cache allocation if possible audit: make audit_inode take struct filename vfs: make path_openat take a struct filename pointer vfs: turn do_path_lookup into wrapper around struct filename variant audit: allow audit code to satisfy getname requests from its names_list vfs: define struct filename and have getname() return it btrfs: Fix compilation with user namespace support enabled userns: Fix posix_acl_file_xattr_userns gid conversion userns: Properly print bluetooth socket uids ...
This commit is contained in:
commit
214e2ca2b8
14
.gitignore
vendored
14
.gitignore
vendored
|
@ -14,6 +14,10 @@
|
|||
*.o.*
|
||||
*.a
|
||||
*.s
|
||||
*.ko.unsigned
|
||||
*.ko.stripped
|
||||
*.ko.stripped.dig
|
||||
*.ko.stripped.sig
|
||||
*.ko
|
||||
*.so
|
||||
*.so.dbg
|
||||
|
@ -84,3 +88,13 @@ GTAGS
|
|||
*.orig
|
||||
*~
|
||||
\#*#
|
||||
|
||||
#
|
||||
# Leavings from module signing
|
||||
#
|
||||
extra_certificates
|
||||
signing_key.priv
|
||||
signing_key.x509
|
||||
signing_key.x509.keyid
|
||||
signing_key.x509.signer
|
||||
x509.genkey
|
||||
|
|
|
@ -270,8 +270,6 @@ preempt-locking.txt
|
|||
- info on locking under a preemptive kernel.
|
||||
printk-formats.txt
|
||||
- how to get printk format specifiers right
|
||||
prio_tree.txt
|
||||
- info on radix-priority-search-tree use for indexing vmas.
|
||||
ramoops.txt
|
||||
- documentation of the ramoops oops/panic logging module.
|
||||
rbtree.txt
|
||||
|
|
|
@ -1,22 +0,0 @@
|
|||
What: /proc/<pid>/oom_adj
|
||||
When: August 2012
|
||||
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||
badness heuristic used to determine which task to kill when the kernel
|
||||
is out of memory.
|
||||
|
||||
The badness heuristic has since been rewritten since the introduction of
|
||||
this tunable such that its meaning is deprecated. The value was
|
||||
implemented as a bitshift on a score generated by the badness()
|
||||
function that did not have any precise units of measure. With the
|
||||
rewrite, the score is given as a proportion of available memory to the
|
||||
task allocating pages, so using a bitshift which grows the score
|
||||
exponentially is, thus, impossible to tune with fine granularity.
|
||||
|
||||
A much more powerful interface, /proc/<pid>/oom_score_adj, was
|
||||
introduced with the oom killer rewrite that allows users to increase or
|
||||
decrease the badness score linearly. This interface will replace
|
||||
/proc/<pid>/oom_adj.
|
||||
|
||||
A warning will be emitted to the kernel log if an application uses this
|
||||
deprecated interface. After it is printed once, future warnings will be
|
||||
suppressed until the kernel is rebooted.
|
|
@ -12,11 +12,14 @@ Description:
|
|||
then closing the file. The new policy takes effect after
|
||||
the file ima/policy is closed.
|
||||
|
||||
IMA appraisal, if configured, uses these file measurements
|
||||
for local measurement appraisal.
|
||||
|
||||
rule format: action [condition ...]
|
||||
|
||||
action: measure | dont_measure
|
||||
action: measure | dont_measure | appraise | dont_appraise | audit
|
||||
condition:= base | lsm
|
||||
base: [[func=] [mask=] [fsmagic=] [uid=]]
|
||||
base: [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
|
||||
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
||||
[obj_user=] [obj_role=] [obj_type=]]
|
||||
|
||||
|
@ -24,36 +27,50 @@ Description:
|
|||
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
|
||||
fsmagic:= hex value
|
||||
uid:= decimal value
|
||||
fowner:=decimal value
|
||||
lsm: are LSM specific
|
||||
|
||||
default policy:
|
||||
# PROC_SUPER_MAGIC
|
||||
dont_measure fsmagic=0x9fa0
|
||||
dont_appraise fsmagic=0x9fa0
|
||||
# SYSFS_MAGIC
|
||||
dont_measure fsmagic=0x62656572
|
||||
dont_appraise fsmagic=0x62656572
|
||||
# DEBUGFS_MAGIC
|
||||
dont_measure fsmagic=0x64626720
|
||||
dont_appraise fsmagic=0x64626720
|
||||
# TMPFS_MAGIC
|
||||
dont_measure fsmagic=0x01021994
|
||||
dont_appraise fsmagic=0x01021994
|
||||
# RAMFS_MAGIC
|
||||
dont_measure fsmagic=0x858458f6
|
||||
dont_appraise fsmagic=0x858458f6
|
||||
# SECURITYFS_MAGIC
|
||||
dont_measure fsmagic=0x73636673
|
||||
dont_appraise fsmagic=0x73636673
|
||||
|
||||
measure func=BPRM_CHECK
|
||||
measure func=FILE_MMAP mask=MAY_EXEC
|
||||
measure func=FILE_CHECK mask=MAY_READ uid=0
|
||||
appraise fowner=0
|
||||
|
||||
The default policy measures all executables in bprm_check,
|
||||
all files mmapped executable in file_mmap, and all files
|
||||
open for read by root in do_filp_open.
|
||||
open for read by root in do_filp_open. The default appraisal
|
||||
policy appraises all files owned by root.
|
||||
|
||||
Examples of LSM specific definitions:
|
||||
|
||||
SELinux:
|
||||
# SELINUX_MAGIC
|
||||
dont_measure fsmagic=0xF97CFF8C
|
||||
dont_measure fsmagic=0xf97cff8c
|
||||
dont_appraise fsmagic=0xf97cff8c
|
||||
|
||||
dont_measure obj_type=var_log_t
|
||||
dont_appraise obj_type=var_log_t
|
||||
dont_measure obj_type=auditd_log_t
|
||||
dont_appraise obj_type=auditd_log_t
|
||||
measure subj_user=system_u func=FILE_CHECK mask=MAY_READ
|
||||
measure subj_role=system_r func=FILE_CHECK mask=MAY_READ
|
||||
|
||||
|
|
|
@ -206,3 +206,17 @@ Description:
|
|||
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.
|
||||
|
||||
What: /sys/block/<disk>/queue/write_same_max_bytes
|
||||
Date: January 2012
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Some devices support a write same operation in which a
|
||||
single data block can be written to a range of several
|
||||
contiguous blocks on storage. This can be used to wipe
|
||||
areas on disk or to initialize drives in a RAID
|
||||
configuration. write_same_max_bytes indicates how many
|
||||
bytes can be written in a single write same command. If
|
||||
write_same_max_bytes is 0, write same is not supported
|
||||
by the device.
|
||||
|
||||
|
|
|
@ -9,19 +9,19 @@ Attributes:
|
|||
this value will change the dev_loss_tmo for all
|
||||
FCFs discovered by this controller.
|
||||
|
||||
lesb_link_fail: Link Error Status Block (LESB) link failure count.
|
||||
lesb/link_fail: Link Error Status Block (LESB) link failure count.
|
||||
|
||||
lesb_vlink_fail: Link Error Status Block (LESB) virtual link
|
||||
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
|
||||
failure count.
|
||||
|
||||
lesb_miss_fka: Link Error Status Block (LESB) missed FCoE
|
||||
lesb/miss_fka: Link Error Status Block (LESB) missed FCoE
|
||||
Initialization Protocol (FIP) Keep-Alives (FKA).
|
||||
|
||||
lesb_symb_err: Link Error Status Block (LESB) symbolic error count.
|
||||
lesb/symb_err: Link Error Status Block (LESB) symbolic error count.
|
||||
|
||||
lesb_err_block: Link Error Status Block (LESB) block error count.
|
||||
lesb/err_block: Link Error Status Block (LESB) block error count.
|
||||
|
||||
lesb_fcs_error: Link Error Status Block (LESB) Fibre Channel
|
||||
lesb/fcs_error: Link Error Status Block (LESB) Fibre Channel
|
||||
Serivces error count.
|
||||
|
||||
Notes: ctlr_X (global increment starting at 0)
|
||||
|
|
|
@ -25,6 +25,10 @@ client_id
|
|||
|
||||
The ceph unique client id that was assigned for this specific session.
|
||||
|
||||
features
|
||||
|
||||
A hexadecimal encoding of the feature bits for this image.
|
||||
|
||||
major
|
||||
|
||||
The block device major number.
|
||||
|
@ -33,6 +37,11 @@ name
|
|||
|
||||
The name of the rbd image.
|
||||
|
||||
image_id
|
||||
|
||||
The unique id for the rbd image. (For rbd image format 1
|
||||
this is empty.)
|
||||
|
||||
pool
|
||||
|
||||
The name of the storage pool where this rbd image resides.
|
||||
|
@ -57,12 +66,6 @@ current_snap
|
|||
|
||||
The current snapshot for which the device is mapped.
|
||||
|
||||
create_snap
|
||||
|
||||
Create a snapshot:
|
||||
|
||||
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create
|
||||
|
||||
snap_*
|
||||
|
||||
A directory per each snapshot
|
||||
|
@ -79,4 +82,7 @@ snap_size
|
|||
|
||||
The size of the image when this snapshot was taken.
|
||||
|
||||
snap_features
|
||||
|
||||
A hexadecimal encoding of the feature bits for this snapshot.
|
||||
|
||||
|
|
|
@ -220,3 +220,10 @@ Description:
|
|||
If the device doesn't support LTM, the file will read "no".
|
||||
The file will be present for all speeds of USB devices, and will
|
||||
always read "no" for USB 1.1 and USB 2.0 devices.
|
||||
|
||||
What: /sys/bus/usb/devices/.../(hub interface)/portX
|
||||
Date: August 2012
|
||||
Contact: Lan Tianyu <tianyu.lan@intel.com>
|
||||
Description:
|
||||
The /sys/bus/usb/devices/.../(hub interface)/portX
|
||||
is usb port device's sysfs directory.
|
||||
|
|
|
@ -13,7 +13,7 @@ Description:
|
|||
accessory cables have such capability. For example,
|
||||
the 30-pin port of Nuri board (/arch/arm/mach-exynos)
|
||||
may have both HDMI and Charger attached, or analog audio,
|
||||
video, and USB cables attached simulteneously.
|
||||
video, and USB cables attached simultaneously.
|
||||
|
||||
If there are cables mutually exclusive with each other,
|
||||
such binary relations may be expressed with extcon_dev's
|
||||
|
@ -35,7 +35,7 @@ Description:
|
|||
The /sys/class/extcon/.../state shows and stores the cable
|
||||
attach/detach information of the corresponding extcon object.
|
||||
If the extcon object has an optional callback "show_state"
|
||||
defined, the showing function is overriden with the optional
|
||||
defined, the showing function is overridden with the optional
|
||||
callback.
|
||||
|
||||
If the default callback for showing function is used, the
|
||||
|
@ -46,19 +46,19 @@ Description:
|
|||
TA=1
|
||||
EAR_JACK=0
|
||||
#
|
||||
In this example, the extcon device have USB_OTG and TA
|
||||
In this example, the extcon device has USB_OTG and TA
|
||||
cables attached and HDMI and EAR_JACK cables detached.
|
||||
|
||||
In order to update the state of an extcon device, enter a hex
|
||||
state number starting with 0x.
|
||||
echo 0xHEX > state
|
||||
state number starting with 0x:
|
||||
# echo 0xHEX > state
|
||||
|
||||
This updates the whole state of the extcon dev.
|
||||
This updates the whole state of the extcon device.
|
||||
Inputs of all the methods are required to meet the
|
||||
mutually_exclusive contidions if they exist.
|
||||
mutually_exclusive conditions if they exist.
|
||||
|
||||
It is recommended to use this "global" state interface if
|
||||
you need to enter the value atomically. The later state
|
||||
you need to set the value atomically. The later state
|
||||
interface associated with each cable cannot update
|
||||
multiple cable states of an extcon device simultaneously.
|
||||
|
||||
|
@ -73,7 +73,7 @@ What: /sys/class/extcon/.../cable.x/state
|
|||
Date: February 2012
|
||||
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
Description:
|
||||
The /sys/class/extcon/.../cable.x/name shows and stores the
|
||||
The /sys/class/extcon/.../cable.x/state shows and stores the
|
||||
state of cable "x" (integer between 0 and 31) of an extcon
|
||||
device. The state value is either 0 (detached) or 1
|
||||
(attached).
|
||||
|
@ -83,8 +83,8 @@ Date: December 2011
|
|||
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
Description:
|
||||
Shows the relations of mutually exclusiveness. For example,
|
||||
if the mutually_exclusive array of extcon_dev is
|
||||
{0x3, 0x5, 0xC, 0x0}, the, the output is:
|
||||
if the mutually_exclusive array of extcon device is
|
||||
{0x3, 0x5, 0xC, 0x0}, then the output is:
|
||||
# ls mutually_exclusive/
|
||||
0x3
|
||||
0x5
|
||||
|
|
|
@ -349,3 +349,24 @@ Description:
|
|||
|
||||
This will be one of the same strings reported by
|
||||
the "state" attribute.
|
||||
|
||||
What: /sys/class/regulator/.../bypass
|
||||
Date: September 2012
|
||||
KernelVersion: 3.7
|
||||
Contact: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
bypass. This indicates if the device is in bypass mode.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
'enabled'
|
||||
'disabled'
|
||||
'unknown'
|
||||
|
||||
'enabled' means the regulator is in bypass mode.
|
||||
|
||||
'disabled' means that the regulator is regulating.
|
||||
|
||||
'unknown' means software cannot determine the state, or
|
||||
the reported state is invalid.
|
||||
|
|
17
Documentation/ABI/testing/sysfs-devices-firmware_node
Normal file
17
Documentation/ABI/testing/sysfs-devices-firmware_node
Normal file
|
@ -0,0 +1,17 @@
|
|||
What: /sys/devices/.../firmware_node/
|
||||
Date: September 2012
|
||||
Contact: <>
|
||||
Description:
|
||||
The /sys/devices/.../firmware_node directory contains attributes
|
||||
allowing the user space to check and modify some firmware
|
||||
related properties of given device.
|
||||
|
||||
What: /sys/devices/.../firmware_node/description
|
||||
Date: September 2012
|
||||
Contact: Lance Ortiz <lance.ortiz@hp.com>
|
||||
Description:
|
||||
The /sys/devices/.../firmware/description attribute contains a string
|
||||
that describes the device as provided by the _STR method in the ACPI
|
||||
namespace. This attribute is read-only. If the device does not have
|
||||
an _STR method associated with it in the ACPI namespace, this
|
||||
attribute is not present.
|
|
@ -176,3 +176,14 @@ Description: Disable L3 cache indices
|
|||
All AMD processors with L3 caches provide this functionality.
|
||||
For details, see BKDGs at
|
||||
http://developer.amd.com/documentation/guides/Pages/default.aspx
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpufreq/boost
|
||||
Date: August 2012
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Processor frequency boosting control
|
||||
|
||||
This switch controls the boost setting for the whole system.
|
||||
Boosting allows the CPU and the firmware to run at a frequency
|
||||
beyound it's nominal limit.
|
||||
More details can be found in Documentation/cpu-freq/boost.txt
|
||||
|
|
70
Documentation/ABI/testing/sysfs-driver-ppi
Normal file
70
Documentation/ABI/testing/sysfs-driver-ppi
Normal file
|
@ -0,0 +1,70 @@
|
|||
What: /sys/devices/pnp0/<bus-num>/ppi/
|
||||
Date: August 2012
|
||||
Kernel Version: 3.6
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This folder includes the attributes related with PPI (Physical
|
||||
Presence Interface). Only if TPM is supported by BIOS, this
|
||||
folder makes sence. The folder path can be got by command
|
||||
'find /sys/ -name 'pcrs''. For the detail information of PPI,
|
||||
please refer to the PPI specification from
|
||||
http://www.trustedcomputinggroup.org/
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/version
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows the version of the PPI supported by the
|
||||
platform.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/request
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows the request for an operation to be
|
||||
executed in the pre-OS environment. It is the only input from
|
||||
the OS to the pre-OS environment. The request should be an
|
||||
integer value range from 1 to 160, and 0 means no request.
|
||||
This file can be read and written.
|
||||
|
||||
What: /sys/devices/pnp0/00:<bus-num>/ppi/response
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows the response to the most recent operation
|
||||
request it acted upon. The format is "<request> <response num>
|
||||
: <response description>".
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/transition_action
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows the platform-specific action that should
|
||||
take place in order to transition to the BIOS for execution of
|
||||
a requested operation. The format is "<action num>: <action
|
||||
description>".
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/tcg_operations
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows whether it is allowed to request an
|
||||
operation to be executed in the pre-OS environment by the BIOS
|
||||
for the requests defined by TCG, i.e. requests from 1 to 22.
|
||||
The format is "<request> <status num>: <status description>".
|
||||
This attribute is only supported by PPI version 1.2+.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/devices/pnp0/<bus-num>/ppi/vs_operations
|
||||
Date: August 2012
|
||||
Contact: xiaoyan.zhang@intel.com
|
||||
Description:
|
||||
This attribute shows whether it is allowed to request an
|
||||
operation to be executed in the pre-OS environment by the BIOS
|
||||
for the verdor specific requests, i.e. requests from 128 to
|
||||
255. The format is same with tcg_operations. This attribute
|
||||
is also only supported by PPI version 1.2+.
|
||||
This file is readonly.
|
|
@ -1,3 +1,16 @@
|
|||
WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
|
||||
Date: June 2012
|
||||
Contact: linux-bluetooth@vger.kernel.org
|
||||
Description:
|
||||
The /sys/class/hidraw/hidraw*/device/oled*_img files control
|
||||
OLED mocro displays on Intuos4 Wireless tablet. Accepted image
|
||||
has to contain 256 bytes (64x32 px 1 bit colour). The format
|
||||
is the same as PBM image 62x32px without header (64 bits per
|
||||
horizontal line, 32 lines). An example of setting OLED No. 0:
|
||||
dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
|
||||
The attribute is read only and no local copy of the image is
|
||||
stored.
|
||||
|
||||
What: /sys/class/hidraw/hidraw*/device/speed
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.35
|
||||
|
|
|
@ -96,3 +96,16 @@ Contact: "Theodore Ts'o" <tytso@mit.edu>
|
|||
Description:
|
||||
The maximum number of megabytes the writeback code will
|
||||
try to write out before move on to another inode.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/extent_max_zeroout_kb
|
||||
Date: August 2012
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The maximum number of kilobytes which will be zeroed
|
||||
out in preference to creating a new uninitialized
|
||||
extent when manipulating an inode's extent tree. Note
|
||||
that using a larger value will increase the
|
||||
variability of time necessary to complete a random
|
||||
write operation (since a 4k random write might turn
|
||||
into a much larger write due to the zeroout
|
||||
operation).
|
||||
|
|
|
@ -19,7 +19,11 @@ Date: September 2010
|
|||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
This file contains the name of the PTP hardware clock
|
||||
as a human readable string.
|
||||
as a human readable string. The purpose of this
|
||||
attribute is to provide the user with a "friendly
|
||||
name" and to help distinguish PHY based devices from
|
||||
MAC based ones. The string does not necessarily have
|
||||
to be any kind of unique id.
|
||||
|
||||
What: /sys/class/ptp/ptpN/max_adjustment
|
||||
Date: September 2010
|
||||
|
|
|
@ -17,3 +17,12 @@ Description:
|
|||
device, like 'tty1'.
|
||||
The file supports poll() to detect virtual
|
||||
console switches.
|
||||
|
||||
What: /sys/class/tty/ttyS0/uartclk
|
||||
Date: Sep 2012
|
||||
Contact: Tomas Hlavacek <tmshlvck@gmail.com>
|
||||
Description:
|
||||
Shows the current uartclk value associated with the
|
||||
UART port in serial_core, that is bound to TTY like ttyS0.
|
||||
uartclk = 16 * baud_base
|
||||
|
||||
|
|
|
@ -454,6 +454,16 @@ The preferred style for long (multi-line) comments is:
|
|||
* with beginning and ending almost-blank lines.
|
||||
*/
|
||||
|
||||
For files in net/ and drivers/net/ the preferred style for long (multi-line)
|
||||
comments is a little different.
|
||||
|
||||
/* The preferred comment style for files in net/ and drivers/net
|
||||
* looks like this.
|
||||
*
|
||||
* It is nearly the same as the generally preferred comment style,
|
||||
* but there is no initial almost-blank line.
|
||||
*/
|
||||
|
||||
It's also important to comment data, whether they are basic types or derived
|
||||
types. To this end, use just one data declaration per line (no commas for
|
||||
multiple data declarations). This leaves you room for a small comment on each
|
||||
|
|
File diff suppressed because it is too large
Load diff
|
@ -1216,8 +1216,6 @@ in this page</entry>
|
|||
#define NAND_BBT_LASTBLOCK 0x00000010
|
||||
/* The bbt is at the given page, else we must scan for the bbt */
|
||||
#define NAND_BBT_ABSPAGE 0x00000020
|
||||
/* The bbt is at the given page, else we must scan for the bbt */
|
||||
#define NAND_BBT_SEARCH 0x00000040
|
||||
/* bbt is stored per chip on multichip devices */
|
||||
#define NAND_BBT_PERCHIP 0x00000080
|
||||
/* bbt has a version counter at offset veroffs */
|
||||
|
|
|
@ -310,6 +310,12 @@ over a rather long period of time, but improvements are always welcome!
|
|||
code under the influence of preempt_disable(), you instead
|
||||
need to use synchronize_irq() or synchronize_sched().
|
||||
|
||||
This same limitation also applies to synchronize_rcu_bh()
|
||||
and synchronize_srcu(), as well as to the asynchronous and
|
||||
expedited forms of the three primitives, namely call_rcu(),
|
||||
call_rcu_bh(), call_srcu(), synchronize_rcu_expedited(),
|
||||
synchronize_rcu_bh_expedited(), and synchronize_srcu_expedited().
|
||||
|
||||
12. Any lock acquired by an RCU callback must be acquired elsewhere
|
||||
with softirq disabled, e.g., via spin_lock_irqsave(),
|
||||
spin_lock_bh(), etc. Failing to disable irq on a given
|
||||
|
|
|
@ -99,7 +99,7 @@ In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
|||
printed:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer=-1
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
|
||||
(t=65000 jiffies)
|
||||
|
||||
The "(64628 ticks this GP)" indicates that this CPU has taken more
|
||||
|
@ -116,13 +116,13 @@ number between the two "/"s is the value of the nesting, which will
|
|||
be a small positive number if in the idle loop and a very large positive
|
||||
number (as shown above) otherwise.
|
||||
|
||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the
|
||||
CPU is not in the process of trying to force itself into dyntick-idle
|
||||
state, the "." indicates that the CPU has not given up forcing RCU
|
||||
into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"
|
||||
indicates that the CPU has not recented forced RCU into dyntick-idle
|
||||
mode (it would otherwise indicate the number of microseconds remaining
|
||||
in this forced state).
|
||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
|
||||
not in the process of trying to force itself into dyntick-idle state, the
|
||||
"." indicates that the CPU has not given up forcing RCU into dyntick-idle
|
||||
mode (it would be "H" otherwise), and the "timer not pending" indicates
|
||||
that the CPU has not recently forced RCU into dyntick-idle mode (it
|
||||
would otherwise indicate the number of microseconds remaining in this
|
||||
forced state).
|
||||
|
||||
|
||||
Multiple Warnings From One Stall
|
||||
|
|
|
@ -333,23 +333,23 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
|
|||
The output of "cat rcu/rcu_pending" looks as follows:
|
||||
|
||||
rcu_sched:
|
||||
0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nf=6445 nn=146741
|
||||
1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nf=5912 nn=155792
|
||||
2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nf=1201 nn=136629
|
||||
3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nf=207 nn=137723
|
||||
4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nf=3529 nn=123110
|
||||
5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nf=201 nn=137456
|
||||
6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nf=4202 nn=120834
|
||||
7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nf=41 nn=144888
|
||||
0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nn=146741
|
||||
1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nn=155792
|
||||
2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nn=136629
|
||||
3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nn=137723
|
||||
4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nn=123110
|
||||
5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nn=137456
|
||||
6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nn=120834
|
||||
7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nn=144888
|
||||
rcu_bh:
|
||||
0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nf=2 nn=145314
|
||||
1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nf=3 nn=143180
|
||||
2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nf=0 nn=117936
|
||||
3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nf=0 nn=134863
|
||||
4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nf=0 nn=110671
|
||||
5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nf=0 nn=133235
|
||||
6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921
|
||||
7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542
|
||||
0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nn=145314
|
||||
1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nn=143180
|
||||
2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nn=117936
|
||||
3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nn=134863
|
||||
4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nn=110671
|
||||
5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nn=133235
|
||||
6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nn=110921
|
||||
7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nn=118542
|
||||
|
||||
As always, this is once again split into "rcu_sched" and "rcu_bh"
|
||||
portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional
|
||||
|
@ -377,17 +377,6 @@ o "gpc" is the number of times that an old grace period had
|
|||
o "gps" is the number of times that a new grace period had started,
|
||||
but this CPU was not yet aware of it.
|
||||
|
||||
o "nf" is the number of times that this CPU suspected that the
|
||||
current grace period had run for too long, and thus needed to
|
||||
be forced.
|
||||
|
||||
Please note that "forcing" consists of sending resched IPIs
|
||||
to holdout CPUs. If that CPU really still is in an old RCU
|
||||
read-side critical section, then we really do have to wait for it.
|
||||
The assumption behing "forcing" is that the CPU is not still in
|
||||
an old RCU read-side critical section, but has not yet responded
|
||||
for some other reason.
|
||||
|
||||
o "nn" is the number of times that this CPU needed nothing. Alert
|
||||
readers will note that the rcu "nn" number for a given CPU very
|
||||
closely matches the rcu_bh "np" number for that same CPU. This
|
||||
|
|
|
@ -873,7 +873,7 @@ d. Do you need to treat NMI handlers, hardirq handlers,
|
|||
and code segments with preemption disabled (whether
|
||||
via preempt_disable(), local_irq_save(), local_bh_disable(),
|
||||
or some other mechanism) as if they were explicit RCU readers?
|
||||
If so, you need RCU-sched.
|
||||
If so, RCU-sched is the only choice that will work for you.
|
||||
|
||||
e. Do you need RCU grace periods to complete even in the face
|
||||
of softirq monopolization of one or more of the CPUs? For
|
||||
|
@ -884,7 +884,12 @@ f. Is your workload too update-intensive for normal use of
|
|||
RCU, but inappropriate for other synchronization mechanisms?
|
||||
If so, consider SLAB_DESTROY_BY_RCU. But please be careful!
|
||||
|
||||
g. Otherwise, use RCU.
|
||||
g. Do you need read-side critical sections that are respected
|
||||
even though they are in the middle of the idle loop, during
|
||||
user-mode execution, or on an offlined CPU? If so, SRCU is the
|
||||
only choice that will work for you.
|
||||
|
||||
h. Otherwise, use RCU.
|
||||
|
||||
Of course, this all assumes that you have determined that RCU is in fact
|
||||
the right tool for your job.
|
||||
|
|
|
@ -98,10 +98,9 @@ static int create_nl_socket(int protocol)
|
|||
if (rcvbufsz)
|
||||
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
|
||||
&rcvbufsz, sizeof(rcvbufsz)) < 0) {
|
||||
fprintf(stderr, "Unable to set socket rcv buf size "
|
||||
"to %d\n",
|
||||
fprintf(stderr, "Unable to set socket rcv buf size to %d\n",
|
||||
rcvbufsz);
|
||||
return -1;
|
||||
goto error;
|
||||
}
|
||||
|
||||
memset(&local, 0, sizeof(local));
|
||||
|
|
|
@ -1,8 +1,16 @@
|
|||
The EtherDrive (R) HOWTO for users of 2.6 kernels is found at ...
|
||||
ATA over Ethernet is a network protocol that provides simple access to
|
||||
block storage on the LAN.
|
||||
|
||||
http://www.coraid.com/SUPPORT/EtherDrive-HBA
|
||||
http://support.coraid.com/documents/AoEr11.txt
|
||||
|
||||
It has many tips and hints!
|
||||
The EtherDrive (R) HOWTO for 2.6 and 3.x kernels is found at ...
|
||||
|
||||
http://support.coraid.com/support/linux/EtherDrive-2.6-HOWTO.html
|
||||
|
||||
It has many tips and hints! Please see, especially, recommended
|
||||
tunings for virtual memory:
|
||||
|
||||
http://support.coraid.com/support/linux/EtherDrive-2.6-HOWTO-5.html#ss5.19
|
||||
|
||||
The aoetools are userland programs that are designed to work with this
|
||||
driver. The aoetools are on sourceforge.
|
||||
|
@ -23,20 +31,12 @@ CREATING DEVICE NODES
|
|||
There is a udev-install.sh script that shows how to install these
|
||||
rules on your system.
|
||||
|
||||
If you are not using udev, two scripts are provided in
|
||||
Documentation/aoe as examples of static device node creation for
|
||||
using the aoe driver.
|
||||
|
||||
rm -rf /dev/etherd
|
||||
sh Documentation/aoe/mkdevs.sh /dev/etherd
|
||||
|
||||
... or to make just one shelf's worth of block device nodes ...
|
||||
|
||||
sh Documentation/aoe/mkshelf.sh /dev/etherd 0
|
||||
|
||||
There is also an autoload script that shows how to edit
|
||||
/etc/modprobe.d/aoe.conf to ensure that the aoe module is loaded when
|
||||
necessary.
|
||||
necessary. Preloading the aoe module is preferable to autoloading,
|
||||
however, because AoE discovery takes a few seconds. It can be
|
||||
confusing when an AoE device is not present the first time the a
|
||||
command is run but appears a second later.
|
||||
|
||||
USING DEVICE NODES
|
||||
|
||||
|
@ -51,9 +51,9 @@ USING DEVICE NODES
|
|||
"echo > /dev/etherd/discover" tells the driver to find out what AoE
|
||||
devices are available.
|
||||
|
||||
These character devices may disappear and be replaced by sysfs
|
||||
counterparts. Using the commands in aoetools insulates users from
|
||||
these implementation details.
|
||||
In the future these character devices may disappear and be replaced
|
||||
by sysfs counterparts. Using the commands in aoetools insulates
|
||||
users from these implementation details.
|
||||
|
||||
The block devices are named like this:
|
||||
|
||||
|
@ -76,8 +76,8 @@ USING SYSFS
|
|||
The netif attribute is the network interface on the localhost
|
||||
through which we are communicating with the remote AoE device.
|
||||
|
||||
There is a script in this directory that formats this information
|
||||
in a convenient way. Users with aoetools can use the aoe-stat
|
||||
There is a script in this directory that formats this information in
|
||||
a convenient way. Users with aoetools should use the aoe-stat
|
||||
command.
|
||||
|
||||
root@makki root# sh Documentation/aoe/status.sh
|
||||
|
@ -121,3 +121,21 @@ DRIVER OPTIONS
|
|||
usage example for the module parameter.
|
||||
|
||||
modprobe aoe_iflist="eth1 eth3"
|
||||
|
||||
The aoe_deadsecs module parameter determines the maximum number of
|
||||
seconds that the driver will wait for an AoE device to provide a
|
||||
response to an AoE command. After aoe_deadsecs seconds have
|
||||
elapsed, the AoE device will be marked as "down".
|
||||
|
||||
The aoe_maxout module parameter has a default of 128. This is the
|
||||
maximum number of unresponded packets that will be sent to an AoE
|
||||
target at one time.
|
||||
|
||||
The aoe_dyndevs module parameter defaults to 1, meaning that the
|
||||
driver will assign a block device minor number to a discovered AoE
|
||||
target based on the order of its discovery. With dynamic minor
|
||||
device numbers in use, a greater range of AoE shelf and slot
|
||||
addresses can be supported. Users with udev will never have to
|
||||
think about minor numbers. Using aoe_dyndevs=0 allows device nodes
|
||||
to be pre-created using a static minor-number scheme with the
|
||||
aoe-mkshelf script in the aoetools.
|
||||
|
|
|
@ -1,41 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
n_shelves=${n_shelves:-10}
|
||||
n_partitions=${n_partitions:-16}
|
||||
|
||||
if test "$#" != "1"; then
|
||||
echo "Usage: sh `basename $0` {dir}" 1>&2
|
||||
echo " n_partitions=16 sh `basename $0` {dir}" 1>&2
|
||||
exit 1
|
||||
fi
|
||||
dir=$1
|
||||
|
||||
MAJOR=152
|
||||
|
||||
echo "Creating AoE devnode files in $dir ..."
|
||||
|
||||
set -e
|
||||
|
||||
mkdir -p $dir
|
||||
|
||||
# (Status info is in sysfs. See status.sh.)
|
||||
# rm -f $dir/stat
|
||||
# mknod -m 0400 $dir/stat c $MAJOR 1
|
||||
rm -f $dir/err
|
||||
mknod -m 0400 $dir/err c $MAJOR 2
|
||||
rm -f $dir/discover
|
||||
mknod -m 0200 $dir/discover c $MAJOR 3
|
||||
rm -f $dir/interfaces
|
||||
mknod -m 0200 $dir/interfaces c $MAJOR 4
|
||||
rm -f $dir/revalidate
|
||||
mknod -m 0200 $dir/revalidate c $MAJOR 5
|
||||
rm -f $dir/flush
|
||||
mknod -m 0200 $dir/flush c $MAJOR 6
|
||||
|
||||
export n_partitions
|
||||
mkshelf=`echo $0 | sed 's!mkdevs!mkshelf!'`
|
||||
i=0
|
||||
while test $i -lt $n_shelves; do
|
||||
sh -xc "sh $mkshelf $dir $i"
|
||||
i=`expr $i + 1`
|
||||
done
|
|
@ -1,28 +0,0 @@
|
|||
#! /bin/sh
|
||||
|
||||
if test "$#" != "2"; then
|
||||
echo "Usage: sh `basename $0` {dir} {shelfaddress}" 1>&2
|
||||
echo " n_partitions=16 sh `basename $0` {dir} {shelfaddress}" 1>&2
|
||||
exit 1
|
||||
fi
|
||||
n_partitions=${n_partitions:-16}
|
||||
dir=$1
|
||||
shelf=$2
|
||||
nslots=16
|
||||
maxslot=`echo $nslots 1 - p | dc`
|
||||
MAJOR=152
|
||||
|
||||
set -e
|
||||
|
||||
minor=`echo $nslots \* $shelf \* $n_partitions | bc`
|
||||
endp=`echo $n_partitions - 1 | bc`
|
||||
for slot in `seq 0 $maxslot`; do
|
||||
for part in `seq 0 $endp`; do
|
||||
name=e$shelf.$slot
|
||||
test "$part" != "0" && name=${name}p$part
|
||||
rm -f $dir/$name
|
||||
mknod -m 0660 $dir/$name b $MAJOR $minor
|
||||
|
||||
minor=`expr $minor + 1`
|
||||
done
|
||||
done
|
|
@ -1,5 +1,8 @@
|
|||
#! /bin/sh
|
||||
# collate and present sysfs information about AoE storage
|
||||
#
|
||||
# A more complete version of this script is aoe-stat, in the
|
||||
# aoetools.
|
||||
|
||||
set -e
|
||||
format="%8s\t%8s\t%8s\n"
|
||||
|
|
|
@ -154,13 +154,33 @@ In either case, the following conditions must be met:
|
|||
|
||||
- CPU mode
|
||||
All forms of interrupts must be disabled (IRQs and FIQs)
|
||||
The CPU must be in SVC mode. (A special exception exists for Angel)
|
||||
|
||||
For CPUs which do not include the ARM virtualization extensions, the
|
||||
CPU must be in SVC mode. (A special exception exists for Angel)
|
||||
|
||||
CPUs which include support for the virtualization extensions can be
|
||||
entered in HYP mode in order to enable the kernel to make full use of
|
||||
these extensions. This is the recommended boot method for such CPUs,
|
||||
unless the virtualisations are already in use by a pre-installed
|
||||
hypervisor.
|
||||
|
||||
If the kernel is not entered in HYP mode for any reason, it must be
|
||||
entered in SVC mode.
|
||||
|
||||
- Caches, MMUs
|
||||
The MMU must be off.
|
||||
Instruction cache may be on or off.
|
||||
Data cache must be off.
|
||||
|
||||
If the kernel is entered in HYP mode, the above requirements apply to
|
||||
the HYP mode configuration in addition to the ordinary PL1 (privileged
|
||||
kernel modes) configuration. In addition, all traps into the
|
||||
hypervisor must be disabled, and PL1 access must be granted for all
|
||||
peripherals and CPU resources for which this is architecturally
|
||||
possible. Except for entering in HYP mode, the system configuration
|
||||
should be such that a kernel which does not include support for the
|
||||
virtualization extensions can boot correctly without extra help.
|
||||
|
||||
- The boot loader is expected to call the kernel image by jumping
|
||||
directly to the first instruction of the kernel image.
|
||||
|
||||
|
|
232
Documentation/arm/Marvell/README
Normal file
232
Documentation/arm/Marvell/README
Normal file
|
@ -0,0 +1,232 @@
|
|||
ARM Marvell SoCs
|
||||
================
|
||||
|
||||
This document lists all the ARM Marvell SoCs that are currently
|
||||
supported in mainline by the Linux kernel. As the Marvell families of
|
||||
SoCs are large and complex, it is hard to understand where the support
|
||||
for a particular SoC is available in the Linux kernel. This document
|
||||
tries to help in understanding where those SoCs are supported, and to
|
||||
match them with their corresponding public datasheet, when available.
|
||||
|
||||
Orion family
|
||||
------------
|
||||
|
||||
Flavors:
|
||||
88F5082
|
||||
88F5181
|
||||
88F5181L
|
||||
88F5182
|
||||
Datasheet : http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf
|
||||
Programmer's User Guide : http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf
|
||||
User Manual : http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf
|
||||
88F5281
|
||||
Datasheet : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
|
||||
88F6183
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-orion5x
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
||||
Kirkwood family
|
||||
---------------
|
||||
|
||||
Flavors:
|
||||
88F6282 a.k.a Armada 300
|
||||
Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
|
||||
88F6283 a.k.a Armada 310
|
||||
Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
|
||||
88F6190
|
||||
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
88F6192
|
||||
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
88F6182
|
||||
88F6180
|
||||
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
88F6281
|
||||
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-kirkwood
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
||||
Discovery family
|
||||
----------------
|
||||
|
||||
Flavors:
|
||||
MV78100
|
||||
Product Brief : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78100_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
|
||||
MV78200
|
||||
Product Brief : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78200-002_WEB.pdf
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78200_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
|
||||
MV76100
|
||||
Not supported by the Linux kernel.
|
||||
|
||||
Core: Feroceon ARMv5 compatible
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mv78xx0
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
||||
EBU Armada family
|
||||
-----------------
|
||||
|
||||
Armada 370 Flavors:
|
||||
88F6710
|
||||
88F6707
|
||||
88F6W11
|
||||
|
||||
Armada XP Flavors:
|
||||
MV78230
|
||||
MV78260
|
||||
MV78460
|
||||
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
|
||||
No public datasheet available.
|
||||
|
||||
Core: Sheeva ARMv7 compatible
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mvebu
|
||||
Linux kernel plat directory: none
|
||||
|
||||
Avanta family
|
||||
-------------
|
||||
|
||||
Flavors:
|
||||
88F6510
|
||||
88F6530P
|
||||
88F6550
|
||||
88F6560
|
||||
Homepage : http://www.marvell.com/broadband/
|
||||
Product Brief: http://www.marvell.com/broadband/assets/Marvell_Avanta_88F6510_305_060-001_product_brief.pdf
|
||||
No public datasheet available.
|
||||
|
||||
Core: ARMv5 compatible
|
||||
|
||||
Linux kernel mach directory: no code in mainline yet, planned for the future
|
||||
Linux kernel plat directory: no code in mainline yet, planned for the future
|
||||
|
||||
Dove family (application processor)
|
||||
-----------------------------------
|
||||
|
||||
Flavors:
|
||||
88AP510 a.k.a Armada 510
|
||||
Product Brief : http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf
|
||||
Hardware Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf
|
||||
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
|
||||
Homepage: http://www.marvell.com/application-processors/armada-500/
|
||||
Core: ARMv7 compatible
|
||||
Directory: arch/arm/mach-dove
|
||||
|
||||
PXA 2xx/3xx/93x/95x family
|
||||
--------------------------
|
||||
|
||||
Flavors:
|
||||
PXA21x, PXA25x, PXA26x
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
PXA270, PXA271, PXA272
|
||||
Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
|
||||
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
|
||||
Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_man.pdf
|
||||
Specification : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
|
||||
Specification update : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
PXA300, PXA310, PXA320
|
||||
PXA 300 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
|
||||
PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
|
||||
PXA 320 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA320_PB_R4.pdf
|
||||
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Design_Guide.pdf
|
||||
Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
|
||||
Specifications : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_EMTS.pdf
|
||||
Specification Update : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
|
||||
Reference Manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 XScale core
|
||||
PXA930, PXA935
|
||||
Application processor with Communication processor
|
||||
Core: ARMv5 XScale core
|
||||
PXA955
|
||||
Application processor with Communication processor
|
||||
Core: ARMv7 compatible Sheeva PJ4 core
|
||||
|
||||
Comments:
|
||||
|
||||
* This line of SoCs originates from the XScale family developed by
|
||||
Intel and acquired by Marvell in ~2006. The PXA21x, PXA25x,
|
||||
PXA26x, PXA27x, PXA3xx and PXA93x were developed by Intel, while
|
||||
the later PXA95x were developed by Marvell.
|
||||
|
||||
* Due to their XScale origin, these SoCs have virtually nothing in
|
||||
common with the other (Kirkwood, Dove, etc.) families of Marvell
|
||||
SoCs, except with the MMP/MMP2 family of SoCs.
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-pxa
|
||||
Linux kernel plat directory: arch/arm/plat-pxa
|
||||
|
||||
MMP/MMP2 family (communication processor)
|
||||
-----------------------------------------
|
||||
|
||||
Flavors:
|
||||
PXA168, a.k.a Armada 168
|
||||
Homepage : http://www.marvell.com/application-processors/armada-100/armada-168.jsp
|
||||
Product brief : http://www.marvell.com/application-processors/armada-100/assets/pxa_168_pb.pdf
|
||||
Hardware manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_datasheet.pdf
|
||||
Software manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
|
||||
Specification update : http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf
|
||||
Boot ROM manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
|
||||
App node package : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
|
||||
Application processor only
|
||||
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
|
||||
PXA910
|
||||
Homepage : http://www.marvell.com/communication-processors/pxa910/
|
||||
Product Brief : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
|
||||
Application processor with Communication processor
|
||||
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
|
||||
MMP2, a.k.a Armada 610
|
||||
Product Brief : http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
|
||||
Application processor only
|
||||
Core: ARMv7 compatible Sheeva PJ4 core
|
||||
|
||||
Comments:
|
||||
|
||||
* This line of SoCs originates from the XScale family developed by
|
||||
Intel and acquired by Marvell in ~2006. All the processors of
|
||||
this MMP/MMP2 family were developed by Marvell.
|
||||
|
||||
* Due to their XScale origin, these SoCs have virtually nothing in
|
||||
common with the other (Kirkwood, Dove, etc.) families of Marvell
|
||||
SoCs, except with the PXA family of SoCs listed above.
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mmp
|
||||
Linux kernel plat directory: arch/arm/plat-pxa
|
||||
|
||||
Long-term plans
|
||||
---------------
|
||||
|
||||
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and
|
||||
mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the
|
||||
Marvell EBU (Engineering Business Unit) in a single mach-<foo>
|
||||
directory. The plat-orion/ would therefore disappear.
|
||||
|
||||
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
|
||||
directory. The plat-pxa/ would therefore disappear.
|
||||
|
||||
Credits
|
||||
-------
|
||||
|
||||
Maen Suleiman <maen@marvell.com>
|
||||
Lior Amsalem <alior@marvell.com>
|
||||
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
||||
Andrew Lunn <andrew@lunn.ch>
|
||||
Nicolas Pitre <nico@fluxnic.net>
|
||||
Eric Miao <eric.y.miao@gmail.com>
|
|
@ -1,4 +1,4 @@
|
|||
S3C2410 GPIO Control
|
||||
S3C24XX GPIO Control
|
||||
====================
|
||||
|
||||
Introduction
|
||||
|
@ -12,7 +12,7 @@ Introduction
|
|||
of the s3c2410 GPIO system, please read the Samsung provided
|
||||
data-sheet/users manual to find out the complete list.
|
||||
|
||||
See Documentation/arm/Samsung/GPIO.txt for the core implemetation.
|
||||
See Documentation/arm/Samsung/GPIO.txt for the core implementation.
|
||||
|
||||
|
||||
GPIOLIB
|
||||
|
@ -41,8 +41,8 @@ GPIOLIB
|
|||
GPIOLIB conversion
|
||||
------------------
|
||||
|
||||
If you need to convert your board or driver to use gpiolib from the exiting
|
||||
s3c2410 api, then here are some notes on the process.
|
||||
If you need to convert your board or driver to use gpiolib from the phased
|
||||
out s3c2410 API, then here are some notes on the process.
|
||||
|
||||
1) If your board is exclusively using an GPIO, say to control peripheral
|
||||
power, then it will require to claim the gpio with gpio_request() before
|
||||
|
@ -55,7 +55,7 @@ s3c2410 api, then here are some notes on the process.
|
|||
as they have the same arguments, and can either take the pin specific
|
||||
values, or the more generic special-function-number arguments.
|
||||
|
||||
3) s3c2410_gpio_pullup() changs have the problem that whilst the
|
||||
3) s3c2410_gpio_pullup() changes have the problem that whilst the
|
||||
s3c2410_gpio_pullup(x, 1) can be easily translated to the
|
||||
s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
|
||||
are not so easy.
|
||||
|
@ -74,7 +74,7 @@ s3c2410 api, then here are some notes on the process.
|
|||
when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
|
||||
would return the value the pin is supposed to be outputting).
|
||||
|
||||
6) s3c2410_gpio_getirq() should be directly replacable with the
|
||||
6) s3c2410_gpio_getirq() should be directly replaceable with the
|
||||
gpio_to_irq() call.
|
||||
|
||||
The s3c2410_gpio and gpio_ calls have always operated on the same gpio
|
||||
|
@ -105,7 +105,7 @@ PIN Numbers
|
|||
-----------
|
||||
|
||||
Each pin has an unique number associated with it in regs-gpio.h,
|
||||
eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
|
||||
e.g. S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
|
||||
the GPIO functions which pin is to be used.
|
||||
|
||||
With the conversion to gpiolib, there is no longer a direct conversion
|
||||
|
@ -120,31 +120,27 @@ Configuring a pin
|
|||
The following function allows the configuration of a given pin to
|
||||
be changed.
|
||||
|
||||
void s3c2410_gpio_cfgpin(unsigned int pin, unsigned int function);
|
||||
void s3c_gpio_cfgpin(unsigned int pin, unsigned int function);
|
||||
|
||||
Eg:
|
||||
e.g.:
|
||||
|
||||
s3c2410_gpio_cfgpin(S3C2410_GPA(0), S3C2410_GPA0_ADDR0);
|
||||
s3c2410_gpio_cfgpin(S3C2410_GPE(8), S3C2410_GPE8_SDDAT1);
|
||||
s3c_gpio_cfgpin(S3C2410_GPA(0), S3C_GPIO_SFN(1));
|
||||
s3c_gpio_cfgpin(S3C2410_GPE(8), S3C_GPIO_SFN(2));
|
||||
|
||||
which would turn GPA(0) into the lowest Address line A0, and set
|
||||
GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
|
||||
|
||||
The s3c_gpio_cfgpin() call is a functional replacement for this call.
|
||||
|
||||
|
||||
Reading the current configuration
|
||||
---------------------------------
|
||||
|
||||
The current configuration of a pin can be read by using:
|
||||
The current configuration of a pin can be read by using standard
|
||||
gpiolib function:
|
||||
|
||||
s3c2410_gpio_getcfg(unsigned int pin);
|
||||
s3c_gpio_getcfg(unsigned int pin);
|
||||
|
||||
The return value will be from the same set of values which can be
|
||||
passed to s3c2410_gpio_cfgpin().
|
||||
|
||||
The s3c_gpio_getcfg() call should be a functional replacement for
|
||||
this call.
|
||||
passed to s3c_gpio_cfgpin().
|
||||
|
||||
|
||||
Configuring a pull-up resistor
|
||||
|
@ -154,61 +150,33 @@ Configuring a pull-up resistor
|
|||
pull-up resistors enabled. This can be configured by the following
|
||||
function:
|
||||
|
||||
void s3c2410_gpio_pullup(unsigned int pin, unsigned int to);
|
||||
void s3c_gpio_setpull(unsigned int pin, unsigned int to);
|
||||
|
||||
Where the to value is zero to set the pull-up off, and 1 to enable
|
||||
the specified pull-up. Any other values are currently undefined.
|
||||
|
||||
The s3c_gpio_setpull() offers similar functionality, but with the
|
||||
ability to encode whether the pull is up or down. Currently there
|
||||
is no 'just on' state, so up or down must be selected.
|
||||
Where the to value is S3C_GPIO_PULL_NONE to set the pull-up off,
|
||||
and S3C_GPIO_PULL_UP to enable the specified pull-up. Any other
|
||||
values are currently undefined.
|
||||
|
||||
|
||||
Getting the state of a PIN
|
||||
--------------------------
|
||||
Getting and setting the state of a PIN
|
||||
--------------------------------------
|
||||
|
||||
The state of a pin can be read by using the function:
|
||||
|
||||
unsigned int s3c2410_gpio_getpin(unsigned int pin);
|
||||
|
||||
This will return either zero or non-zero. Do not count on this
|
||||
function returning 1 if the pin is set.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Setting the state of a PIN
|
||||
--------------------------
|
||||
|
||||
The value an pin is outputing can be modified by using the following:
|
||||
|
||||
void s3c2410_gpio_setpin(unsigned int pin, unsigned int to);
|
||||
|
||||
Which sets the given pin to the value. Use 0 to write 0, and 1 to
|
||||
set the output to 1.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
These calls are now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Getting the IRQ number associated with a PIN
|
||||
--------------------------------------------
|
||||
|
||||
The following function can map the given pin number to an IRQ
|
||||
A standard gpiolib function can map the given pin number to an IRQ
|
||||
number to pass to the IRQ system.
|
||||
|
||||
int s3c2410_gpio_getirq(unsigned int pin);
|
||||
int gpio_to_irq(unsigned int pin);
|
||||
|
||||
Note, not all pins have an IRQ.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Authour
|
||||
Author
|
||||
-------
|
||||
|
||||
|
||||
Ben Dooks, 03 October 2004
|
||||
Copyright 2004 Ben Dooks, Simtec Electronics
|
||||
|
|
|
@ -5,14 +5,14 @@ Introduction
|
|||
------------
|
||||
|
||||
This outlines the Samsung GPIO implementation and the architecture
|
||||
specific calls provided alongisde the drivers/gpio core.
|
||||
specific calls provided alongside the drivers/gpio core.
|
||||
|
||||
|
||||
S3C24XX (Legacy)
|
||||
----------------
|
||||
|
||||
See Documentation/arm/Samsung-S3C24XX/GPIO.txt for more information
|
||||
about these devices. Their implementation is being brought into line
|
||||
about these devices. Their implementation has been brought into line
|
||||
with the core samsung implementation described in this document.
|
||||
|
||||
|
||||
|
@ -29,7 +29,7 @@ GPIO numbering is synchronised between the Samsung and gpiolib system.
|
|||
PIN configuration
|
||||
-----------------
|
||||
|
||||
Pin configuration is specific to the Samsung architecutre, with each SoC
|
||||
Pin configuration is specific to the Samsung architecture, with each SoC
|
||||
registering the necessary information for the core gpio configuration
|
||||
implementation to configure pins as necessary.
|
||||
|
||||
|
@ -38,5 +38,3 @@ driver or machine to change gpio configuration.
|
|||
|
||||
See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
|
||||
on these functions.
|
||||
|
||||
|
||||
|
|
|
@ -51,6 +51,9 @@ ffc00000 ffefffff DMA memory mapping region. Memory returned
|
|||
ff000000 ffbfffff Reserved for future expansion of DMA
|
||||
mapping region.
|
||||
|
||||
fee00000 feffffff Mapping of PCI I/O space. This is a static
|
||||
mapping within the vmalloc space.
|
||||
|
||||
VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
|
||||
Memory returned by vmalloc/ioremap will
|
||||
be dynamically placed in this region.
|
||||
|
|
152
Documentation/arm64/booting.txt
Normal file
152
Documentation/arm64/booting.txt
Normal file
|
@ -0,0 +1,152 @@
|
|||
Booting AArch64 Linux
|
||||
=====================
|
||||
|
||||
Author: Will Deacon <will.deacon@arm.com>
|
||||
Date : 07 September 2012
|
||||
|
||||
This document is based on the ARM booting document by Russell King and
|
||||
is relevant to all public releases of the AArch64 Linux kernel.
|
||||
|
||||
The AArch64 exception model is made up of a number of exception levels
|
||||
(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure
|
||||
counterpart. EL2 is the hypervisor level and exists only in non-secure
|
||||
mode. EL3 is the highest priority level and exists only in secure mode.
|
||||
|
||||
For the purposes of this document, we will use the term `boot loader'
|
||||
simply to define all software that executes on the CPU(s) before control
|
||||
is passed to the Linux kernel. This may include secure monitor and
|
||||
hypervisor code, or it may just be a handful of instructions for
|
||||
preparing a minimal boot environment.
|
||||
|
||||
Essentially, the boot loader should provide (as a minimum) the
|
||||
following:
|
||||
|
||||
1. Setup and initialise the RAM
|
||||
2. Setup the device tree
|
||||
3. Decompress the kernel image
|
||||
4. Call the kernel image
|
||||
|
||||
|
||||
1. Setup and initialise RAM
|
||||
---------------------------
|
||||
|
||||
Requirement: MANDATORY
|
||||
|
||||
The boot loader is expected to find and initialise all RAM that the
|
||||
kernel will use for volatile data storage in the system. It performs
|
||||
this in a machine dependent manner. (It may use internal algorithms
|
||||
to automatically locate and size all RAM, or it may use knowledge of
|
||||
the RAM in the machine, or any other method the boot loader designer
|
||||
sees fit.)
|
||||
|
||||
|
||||
2. Setup the device tree
|
||||
-------------------------
|
||||
|
||||
Requirement: MANDATORY
|
||||
|
||||
The device tree blob (dtb) must be no bigger than 2 megabytes in size
|
||||
and placed at a 2-megabyte boundary within the first 512 megabytes from
|
||||
the start of the kernel image. This is to allow the kernel to map the
|
||||
blob using a single section mapping in the initial page tables.
|
||||
|
||||
|
||||
3. Decompress the kernel image
|
||||
------------------------------
|
||||
|
||||
Requirement: OPTIONAL
|
||||
|
||||
The AArch64 kernel does not currently provide a decompressor and
|
||||
therefore requires decompression (gzip etc.) to be performed by the boot
|
||||
loader if a compressed Image target (e.g. Image.gz) is used. For
|
||||
bootloaders that do not implement this requirement, the uncompressed
|
||||
Image target is available instead.
|
||||
|
||||
|
||||
4. Call the kernel image
|
||||
------------------------
|
||||
|
||||
Requirement: MANDATORY
|
||||
|
||||
The decompressed kernel image contains a 32-byte header as follows:
|
||||
|
||||
u32 magic = 0x14000008; /* branch to stext, little-endian */
|
||||
u32 res0 = 0; /* reserved */
|
||||
u64 text_offset; /* Image load offset */
|
||||
u64 res1 = 0; /* reserved */
|
||||
u64 res2 = 0; /* reserved */
|
||||
|
||||
The image must be placed at the specified offset (currently 0x80000)
|
||||
from the start of the system RAM and called there. The start of the
|
||||
system RAM must be aligned to 2MB.
|
||||
|
||||
Before jumping into the kernel, the following conditions must be met:
|
||||
|
||||
- Quiesce all DMA capable devices so that memory does not get
|
||||
corrupted by bogus network packets or disk data. This will save
|
||||
you many hours of debug.
|
||||
|
||||
- Primary CPU general-purpose register settings
|
||||
x0 = physical address of device tree blob (dtb) in system RAM.
|
||||
x1 = 0 (reserved for future use)
|
||||
x2 = 0 (reserved for future use)
|
||||
x3 = 0 (reserved for future use)
|
||||
|
||||
- CPU mode
|
||||
All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
|
||||
IRQ and FIQ).
|
||||
The CPU must be in either EL2 (RECOMMENDED in order to have access to
|
||||
the virtualisation extensions) or non-secure EL1.
|
||||
|
||||
- Caches, MMUs
|
||||
The MMU must be off.
|
||||
Instruction cache may be on or off.
|
||||
Data cache must be off and invalidated.
|
||||
External caches (if present) must be configured and disabled.
|
||||
|
||||
- Architected timers
|
||||
CNTFRQ must be programmed with the timer frequency.
|
||||
If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
|
||||
set where available.
|
||||
|
||||
- Coherency
|
||||
All CPUs to be booted by the kernel must be part of the same coherency
|
||||
domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
|
||||
initialisation to enable the receiving of maintenance operations on
|
||||
each CPU.
|
||||
|
||||
- System registers
|
||||
All writable architected system registers at the exception level where
|
||||
the kernel image will be entered must be initialised by software at a
|
||||
higher exception level to prevent execution in an UNKNOWN state.
|
||||
|
||||
The boot loader is expected to enter the kernel on each CPU in the
|
||||
following manner:
|
||||
|
||||
- The primary CPU must jump directly to the first instruction of the
|
||||
kernel image. The device tree blob passed by this CPU must contain
|
||||
for each CPU node:
|
||||
|
||||
1. An 'enable-method' property. Currently, the only supported value
|
||||
for this field is the string "spin-table".
|
||||
|
||||
2. A 'cpu-release-addr' property identifying a 64-bit,
|
||||
zero-initialised memory location.
|
||||
|
||||
It is expected that the bootloader will generate these device tree
|
||||
properties and insert them into the blob prior to kernel entry.
|
||||
|
||||
- Any secondary CPUs must spin outside of the kernel in a reserved area
|
||||
of memory (communicated to the kernel by a /memreserve/ region in the
|
||||
device tree) polling their cpu-release-addr location, which must be
|
||||
contained in the reserved region. A wfe instruction may be inserted
|
||||
to reduce the overhead of the busy-loop and a sev will be issued by
|
||||
the primary CPU. When a read of the location pointed to by the
|
||||
cpu-release-addr returns a non-zero value, the CPU must jump directly
|
||||
to this value.
|
||||
|
||||
- Secondary CPU general-purpose register settings
|
||||
x0 = 0 (reserved for future use)
|
||||
x1 = 0 (reserved for future use)
|
||||
x2 = 0 (reserved for future use)
|
||||
x3 = 0 (reserved for future use)
|
73
Documentation/arm64/memory.txt
Normal file
73
Documentation/arm64/memory.txt
Normal file
|
@ -0,0 +1,73 @@
|
|||
Memory Layout on AArch64 Linux
|
||||
==============================
|
||||
|
||||
Author: Catalin Marinas <catalin.marinas@arm.com>
|
||||
Date : 20 February 2012
|
||||
|
||||
This document describes the virtual memory layout used by the AArch64
|
||||
Linux kernel. The architecture allows up to 4 levels of translation
|
||||
tables with a 4KB page size and up to 3 levels with a 64KB page size.
|
||||
|
||||
AArch64 Linux uses 3 levels of translation tables with the 4KB page
|
||||
configuration, allowing 39-bit (512GB) virtual addresses for both user
|
||||
and kernel. With 64KB pages, only 2 levels of translation tables are
|
||||
used but the memory layout is the same.
|
||||
|
||||
User addresses have bits 63:39 set to 0 while the kernel addresses have
|
||||
the same bits set to 1. TTBRx selection is given by bit 63 of the
|
||||
virtual address. The swapper_pg_dir contains only kernel (global)
|
||||
mappings while the user pgd contains only user (non-global) mappings.
|
||||
The swapper_pgd_dir address is written to TTBR1 and never written to
|
||||
TTBR0.
|
||||
|
||||
|
||||
AArch64 Linux memory layout:
|
||||
|
||||
Start End Size Use
|
||||
-----------------------------------------------------------------------
|
||||
0000000000000000 0000007fffffffff 512GB user
|
||||
|
||||
ffffff8000000000 ffffffbbfffcffff ~240GB vmalloc
|
||||
|
||||
ffffffbbfffd0000 ffffffbcfffdffff 64KB [guard page]
|
||||
|
||||
ffffffbbfffe0000 ffffffbcfffeffff 64KB PCI I/O space
|
||||
|
||||
ffffffbbffff0000 ffffffbcffffffff 64KB [guard page]
|
||||
|
||||
ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
|
||||
|
||||
ffffffbe00000000 ffffffbffbffffff ~8GB [guard, future vmmemap]
|
||||
|
||||
ffffffbffc000000 ffffffbfffffffff 64MB modules
|
||||
|
||||
ffffffc000000000 ffffffffffffffff 256GB memory
|
||||
|
||||
|
||||
Translation table lookup with 4KB pages:
|
||||
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | | |
|
||||
| | | | | v
|
||||
| | | | | [11:0] in-page offset
|
||||
| | | | +-> [20:12] L3 index
|
||||
| | | +-----------> [29:21] L2 index
|
||||
| | +---------------------> [38:30] L1 index
|
||||
| +-------------------------------> [47:39] L0 index (not used)
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
||||
|
||||
|
||||
Translation table lookup with 64KB pages:
|
||||
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | |
|
||||
| | | | v
|
||||
| | | | [15:0] in-page offset
|
||||
| | | +----------> [28:16] L3 index
|
||||
| | +--------------------------> [41:29] L2 index (only 38:29 used)
|
||||
| +-------------------------------> [47:42] L1 index (not used)
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
|
@ -465,7 +465,6 @@ struct bio {
|
|||
bio_end_io_t *bi_end_io; /* bi_end_io (bio) */
|
||||
atomic_t bi_cnt; /* pin count: free when it hits zero */
|
||||
void *bi_private;
|
||||
bio_destructor_t *bi_destructor; /* bi_destructor (bio) */
|
||||
};
|
||||
|
||||
With this multipage bio design:
|
||||
|
@ -647,10 +646,6 @@ for a non-clone bio. There are the 6 pools setup for different size biovecs,
|
|||
so bio_alloc(gfp_mask, nr_iovecs) will allocate a vec_list of the
|
||||
given size from these slabs.
|
||||
|
||||
The bi_destructor() routine takes into account the possibility of the bio
|
||||
having originated from a different source (see later discussions on
|
||||
n/w to block transfers and kvec_cb)
|
||||
|
||||
The bio_get() routine may be used to hold an extra reference on a bio prior
|
||||
to i/o submission, if the bio fields are likely to be accessed after the
|
||||
i/o is issued (since the bio may otherwise get freed in case i/o completion
|
||||
|
|
|
@ -29,7 +29,8 @@ CONTENTS:
|
|||
3.1 Overview
|
||||
3.2 Synchronization
|
||||
3.3 Subsystem API
|
||||
4. Questions
|
||||
4. Extended attributes usage
|
||||
5. Questions
|
||||
|
||||
1. Control Groups
|
||||
=================
|
||||
|
@ -62,9 +63,9 @@ an instance of the cgroup virtual filesystem associated with it.
|
|||
At any one time there may be multiple active hierarchies of task
|
||||
cgroups. Each hierarchy is a partition of all tasks in the system.
|
||||
|
||||
User level code may create and destroy cgroups by name in an
|
||||
User-level code may create and destroy cgroups by name in an
|
||||
instance of the cgroup virtual file system, specify and query to
|
||||
which cgroup a task is assigned, and list the task pids assigned to
|
||||
which cgroup a task is assigned, and list the task PIDs assigned to
|
||||
a cgroup. Those creations and assignments only affect the hierarchy
|
||||
associated with that instance of the cgroup file system.
|
||||
|
||||
|
@ -72,7 +73,7 @@ On their own, the only use for cgroups is for simple job
|
|||
tracking. The intention is that other subsystems hook into the generic
|
||||
cgroup support to provide new attributes for cgroups, such as
|
||||
accounting/limiting the resources which processes in a cgroup can
|
||||
access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allows
|
||||
access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allow
|
||||
you to associate a set of CPUs and a set of memory nodes with the
|
||||
tasks in each cgroup.
|
||||
|
||||
|
@ -80,11 +81,11 @@ tasks in each cgroup.
|
|||
----------------------------
|
||||
|
||||
There are multiple efforts to provide process aggregations in the
|
||||
Linux kernel, mainly for resource tracking purposes. Such efforts
|
||||
Linux kernel, mainly for resource-tracking purposes. Such efforts
|
||||
include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server
|
||||
namespaces. These all require the basic notion of a
|
||||
grouping/partitioning of processes, with newly forked processes ending
|
||||
in the same group (cgroup) as their parent process.
|
||||
up in the same group (cgroup) as their parent process.
|
||||
|
||||
The kernel cgroup patch provides the minimum essential kernel
|
||||
mechanisms required to efficiently implement such groups. It has
|
||||
|
@ -127,14 +128,14 @@ following lines:
|
|||
/ \
|
||||
Professors (15%) students (5%)
|
||||
|
||||
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
|
||||
into NFS network class.
|
||||
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd goes
|
||||
into the NFS network class.
|
||||
|
||||
At the same time Firefox/Lynx will share an appropriate CPU/Memory class
|
||||
depending on who launched it (prof/student).
|
||||
|
||||
With the ability to classify tasks differently for different resources
|
||||
(by putting those resource subsystems in different hierarchies) then
|
||||
(by putting those resource subsystems in different hierarchies),
|
||||
the admin can easily set up a script which receives exec notifications
|
||||
and depending on who is launching the browser he can
|
||||
|
||||
|
@ -145,19 +146,19 @@ a separate cgroup for every browser launched and associate it with
|
|||
appropriate network and other resource class. This may lead to
|
||||
proliferation of such cgroups.
|
||||
|
||||
Also lets say that the administrator would like to give enhanced network
|
||||
Also let's say that the administrator would like to give enhanced network
|
||||
access temporarily to a student's browser (since it is night and the user
|
||||
wants to do online gaming :)) OR give one of the students simulation
|
||||
apps enhanced CPU power,
|
||||
wants to do online gaming :)) OR give one of the student's simulation
|
||||
apps enhanced CPU power.
|
||||
|
||||
With ability to write pids directly to resource classes, it's just a
|
||||
matter of :
|
||||
With ability to write PIDs directly to resource classes, it's just a
|
||||
matter of:
|
||||
|
||||
# echo pid > /sys/fs/cgroup/network/<new_class>/tasks
|
||||
(after some time)
|
||||
# echo pid > /sys/fs/cgroup/network/<orig_class>/tasks
|
||||
|
||||
Without this ability, he would have to split the cgroup into
|
||||
Without this ability, the administrator would have to split the cgroup into
|
||||
multiple separate ones and then associate the new cgroups with the
|
||||
new resource classes.
|
||||
|
||||
|
@ -184,20 +185,20 @@ Control Groups extends the kernel as follows:
|
|||
field of each task_struct using the css_set, anchored at
|
||||
css_set->tasks.
|
||||
|
||||
- A cgroup hierarchy filesystem can be mounted for browsing and
|
||||
- A cgroup hierarchy filesystem can be mounted for browsing and
|
||||
manipulation from user space.
|
||||
|
||||
- You can list all the tasks (by pid) attached to any cgroup.
|
||||
- You can list all the tasks (by PID) attached to any cgroup.
|
||||
|
||||
The implementation of cgroups requires a few, simple hooks
|
||||
into the rest of the kernel, none in performance critical paths:
|
||||
into the rest of the kernel, none in performance-critical paths:
|
||||
|
||||
- in init/main.c, to initialize the root cgroups and initial
|
||||
css_set at system boot.
|
||||
|
||||
- in fork and exit, to attach and detach a task from its css_set.
|
||||
|
||||
In addition a new file system, of type "cgroup" may be mounted, to
|
||||
In addition, a new file system of type "cgroup" may be mounted, to
|
||||
enable browsing and modifying the cgroups presently known to the
|
||||
kernel. When mounting a cgroup hierarchy, you may specify a
|
||||
comma-separated list of subsystems to mount as the filesystem mount
|
||||
|
@ -230,13 +231,13 @@ as the path relative to the root of the cgroup file system.
|
|||
Each cgroup is represented by a directory in the cgroup file system
|
||||
containing the following files describing that cgroup:
|
||||
|
||||
- tasks: list of tasks (by pid) attached to that cgroup. This list
|
||||
is not guaranteed to be sorted. Writing a thread id into this file
|
||||
- tasks: list of tasks (by PID) attached to that cgroup. This list
|
||||
is not guaranteed to be sorted. Writing a thread ID into this file
|
||||
moves the thread into this cgroup.
|
||||
- cgroup.procs: list of tgids in the cgroup. This list is not
|
||||
guaranteed to be sorted or free of duplicate tgids, and userspace
|
||||
- cgroup.procs: list of thread group IDs in the cgroup. This list is
|
||||
not guaranteed to be sorted or free of duplicate TGIDs, and userspace
|
||||
should sort/uniquify the list if this property is required.
|
||||
Writing a thread group id into this file moves all threads in that
|
||||
Writing a thread group ID into this file moves all threads in that
|
||||
group into this cgroup.
|
||||
- notify_on_release flag: run the release agent on exit?
|
||||
- release_agent: the path to use for release notifications (this file
|
||||
|
@ -261,7 +262,7 @@ cgroup file system directories.
|
|||
|
||||
When a task is moved from one cgroup to another, it gets a new
|
||||
css_set pointer - if there's an already existing css_set with the
|
||||
desired collection of cgroups then that group is reused, else a new
|
||||
desired collection of cgroups then that group is reused, otherwise a new
|
||||
css_set is allocated. The appropriate existing css_set is located by
|
||||
looking into a hash table.
|
||||
|
||||
|
@ -292,7 +293,7 @@ file system) of the abandoned cgroup. This enables automatic
|
|||
removal of abandoned cgroups. The default value of
|
||||
notify_on_release in the root cgroup at system boot is disabled
|
||||
(0). The default value of other cgroups at creation is the current
|
||||
value of their parents notify_on_release setting. The default value of
|
||||
value of their parents' notify_on_release settings. The default value of
|
||||
a cgroup hierarchy's release_agent path is empty.
|
||||
|
||||
1.5 What does clone_children do ?
|
||||
|
@ -316,7 +317,7 @@ the "cpuset" cgroup subsystem, the steps are something like:
|
|||
4) Create the new cgroup by doing mkdir's and write's (or echo's) in
|
||||
the /sys/fs/cgroup virtual file system.
|
||||
5) Start a task that will be the "founding father" of the new job.
|
||||
6) Attach that task to the new cgroup by writing its pid to the
|
||||
6) Attach that task to the new cgroup by writing its PID to the
|
||||
/sys/fs/cgroup/cpuset/tasks file for that cgroup.
|
||||
7) fork, exec or clone the job tasks from this founding father task.
|
||||
|
||||
|
@ -344,7 +345,7 @@ and then start a subshell 'sh' in that cgroup:
|
|||
2.1 Basic Usage
|
||||
---------------
|
||||
|
||||
Creating, modifying, using the cgroups can be done through the cgroup
|
||||
Creating, modifying, using cgroups can be done through the cgroup
|
||||
virtual filesystem.
|
||||
|
||||
To mount a cgroup hierarchy with all available subsystems, type:
|
||||
|
@ -441,7 +442,7 @@ You can attach the current shell task by echoing 0:
|
|||
# echo 0 > tasks
|
||||
|
||||
You can use the cgroup.procs file instead of the tasks file to move all
|
||||
threads in a threadgroup at once. Echoing the pid of any task in a
|
||||
threads in a threadgroup at once. Echoing the PID of any task in a
|
||||
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
|
||||
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
|
||||
in the writing task's threadgroup.
|
||||
|
@ -479,7 +480,7 @@ in /proc/mounts and /proc/<pid>/cgroups.
|
|||
There is mechanism which allows to get notifications about changing
|
||||
status of a cgroup.
|
||||
|
||||
To register new notification handler you need:
|
||||
To register a new notification handler you need to:
|
||||
- create a file descriptor for event notification using eventfd(2);
|
||||
- open a control file to be monitored (e.g. memory.usage_in_bytes);
|
||||
- write "<event_fd> <control_fd> <args>" to cgroup.event_control.
|
||||
|
@ -488,7 +489,7 @@ To register new notification handler you need:
|
|||
eventfd will be woken up by control file implementation or when the
|
||||
cgroup is removed.
|
||||
|
||||
To unregister notification handler just close eventfd.
|
||||
To unregister a notification handler just close eventfd.
|
||||
|
||||
NOTE: Support of notifications should be implemented for the control
|
||||
file. See documentation for the subsystem.
|
||||
|
@ -502,7 +503,7 @@ file. See documentation for the subsystem.
|
|||
Each kernel subsystem that wants to hook into the generic cgroup
|
||||
system needs to create a cgroup_subsys object. This contains
|
||||
various methods, which are callbacks from the cgroup system, along
|
||||
with a subsystem id which will be assigned by the cgroup system.
|
||||
with a subsystem ID which will be assigned by the cgroup system.
|
||||
|
||||
Other fields in the cgroup_subsys object include:
|
||||
|
||||
|
@ -516,7 +517,7 @@ Other fields in the cgroup_subsys object include:
|
|||
at system boot.
|
||||
|
||||
Each cgroup object created by the system has an array of pointers,
|
||||
indexed by subsystem id; this pointer is entirely managed by the
|
||||
indexed by subsystem ID; this pointer is entirely managed by the
|
||||
subsystem; the generic cgroup code will never touch this pointer.
|
||||
|
||||
3.2 Synchronization
|
||||
|
@ -639,7 +640,7 @@ void post_clone(struct cgroup *cgrp)
|
|||
|
||||
Called during cgroup_create() to do any parameter
|
||||
initialization which might be required before a task could attach. For
|
||||
example in cpusets, no task may attach before 'cpus' and 'mems' are set
|
||||
example, in cpusets, no task may attach before 'cpus' and 'mems' are set
|
||||
up.
|
||||
|
||||
void bind(struct cgroup *root)
|
||||
|
@ -650,7 +651,26 @@ and root cgroup. Currently this will only involve movement between
|
|||
the default hierarchy (which never has sub-cgroups) and a hierarchy
|
||||
that is being created/destroyed (and hence has no sub-cgroups).
|
||||
|
||||
4. Questions
|
||||
4. Extended attribute usage
|
||||
===========================
|
||||
|
||||
cgroup filesystem supports certain types of extended attributes in its
|
||||
directories and files. The current supported types are:
|
||||
- Trusted (XATTR_TRUSTED)
|
||||
- Security (XATTR_SECURITY)
|
||||
|
||||
Both require CAP_SYS_ADMIN capability to set.
|
||||
|
||||
Like in tmpfs, the extended attributes in cgroup filesystem are stored
|
||||
using kernel memory and it's advised to keep the usage at minimum. This
|
||||
is the reason why user defined extended attributes are not supported, since
|
||||
any user can do it and there's no limit in the value size.
|
||||
|
||||
The current known users for this feature are SELinux to limit cgroup usage
|
||||
in containers and systemd for assorted meta data like main PID in a cgroup
|
||||
(systemd creates a cgroup per service).
|
||||
|
||||
5. Questions
|
||||
============
|
||||
|
||||
Q: what's up with this '/bin/echo' ?
|
||||
|
@ -660,5 +680,5 @@ A: bash's builtin 'echo' command does not check calls to write() against
|
|||
|
||||
Q: When I attach processes, only the first of the line gets really attached !
|
||||
A: We can only return one error code per call to write(). So you should also
|
||||
put only ONE pid.
|
||||
put only ONE PID.
|
||||
|
||||
|
|
|
@ -18,16 +18,16 @@ from the rest of the system. The article on LWN [12] mentions some probable
|
|||
uses of the memory controller. The memory controller can be used to
|
||||
|
||||
a. Isolate an application or a group of applications
|
||||
Memory hungry applications can be isolated and limited to a smaller
|
||||
Memory-hungry applications can be isolated and limited to a smaller
|
||||
amount of memory.
|
||||
b. Create a cgroup with limited amount of memory, this can be used
|
||||
b. Create a cgroup with a limited amount of memory; this can be used
|
||||
as a good alternative to booting with mem=XXXX.
|
||||
c. Virtualization solutions can control the amount of memory they want
|
||||
to assign to a virtual machine instance.
|
||||
d. A CD/DVD burner could control the amount of memory used by the
|
||||
rest of the system to ensure that burning does not fail due to lack
|
||||
of available memory.
|
||||
e. There are several other use cases, find one or use the controller just
|
||||
e. There are several other use cases; find one or use the controller just
|
||||
for fun (to learn and hack on the VM subsystem).
|
||||
|
||||
Current Status: linux-2.6.34-mmotm(development version of 2010/April)
|
||||
|
@ -38,12 +38,12 @@ Features:
|
|||
- optionally, memory+swap usage can be accounted and limited.
|
||||
- hierarchical accounting
|
||||
- soft limit
|
||||
- moving(recharging) account at moving a task is selectable.
|
||||
- moving (recharging) account at moving a task is selectable.
|
||||
- usage threshold notifier
|
||||
- oom-killer disable knob and oom-notifier
|
||||
- Root cgroup has no limit controls.
|
||||
|
||||
Kernel memory support is work in progress, and the current version provides
|
||||
Kernel memory support is a work in progress, and the current version provides
|
||||
basically functionality. (See Section 2.7)
|
||||
|
||||
Brief summary of control files.
|
||||
|
@ -144,9 +144,9 @@ Figure 1 shows the important aspects of the controller
|
|||
3. Each page has a pointer to the page_cgroup, which in turn knows the
|
||||
cgroup it belongs to
|
||||
|
||||
The accounting is done as follows: mem_cgroup_charge() is invoked to setup
|
||||
The accounting is done as follows: mem_cgroup_charge() is invoked to set up
|
||||
the necessary data structures and check if the cgroup that is being charged
|
||||
is over its limit. If it is then reclaim is invoked on the cgroup.
|
||||
is over its limit. If it is, then reclaim is invoked on the cgroup.
|
||||
More details can be found in the reclaim section of this document.
|
||||
If everything goes well, a page meta-data-structure called page_cgroup is
|
||||
updated. page_cgroup has its own LRU on cgroup.
|
||||
|
@ -163,13 +163,13 @@ for earlier. A file page will be accounted for as Page Cache when it's
|
|||
inserted into inode (radix-tree). While it's mapped into the page tables of
|
||||
processes, duplicate accounting is carefully avoided.
|
||||
|
||||
A RSS page is unaccounted when it's fully unmapped. A PageCache page is
|
||||
An RSS page is unaccounted when it's fully unmapped. A PageCache page is
|
||||
unaccounted when it's removed from radix-tree. Even if RSS pages are fully
|
||||
unmapped (by kswapd), they may exist as SwapCache in the system until they
|
||||
are really freed. Such SwapCaches also also accounted.
|
||||
are really freed. Such SwapCaches are also accounted.
|
||||
A swapped-in page is not accounted until it's mapped.
|
||||
|
||||
Note: The kernel does swapin-readahead and read multiple swaps at once.
|
||||
Note: The kernel does swapin-readahead and reads multiple swaps at once.
|
||||
This means swapped-in pages may contain pages for other tasks than a task
|
||||
causing page fault. So, we avoid accounting at swap-in I/O.
|
||||
|
||||
|
@ -209,7 +209,7 @@ memsw.limit_in_bytes.
|
|||
Example: Assume a system with 4G of swap. A task which allocates 6G of memory
|
||||
(by mistake) under 2G memory limitation will use all swap.
|
||||
In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap.
|
||||
By using memsw limit, you can avoid system OOM which can be caused by swap
|
||||
By using the memsw limit, you can avoid system OOM which can be caused by swap
|
||||
shortage.
|
||||
|
||||
* why 'memory+swap' rather than swap.
|
||||
|
@ -217,7 +217,7 @@ The global LRU(kswapd) can swap out arbitrary pages. Swap-out means
|
|||
to move account from memory to swap...there is no change in usage of
|
||||
memory+swap. In other words, when we want to limit the usage of swap without
|
||||
affecting global LRU, memory+swap limit is better than just limiting swap from
|
||||
OS point of view.
|
||||
an OS point of view.
|
||||
|
||||
* What happens when a cgroup hits memory.memsw.limit_in_bytes
|
||||
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
|
||||
|
@ -236,7 +236,7 @@ an OOM routine is invoked to select and kill the bulkiest task in the
|
|||
cgroup. (See 10. OOM Control below.)
|
||||
|
||||
The reclaim algorithm has not been modified for cgroups, except that
|
||||
pages that are selected for reclaiming come from the per cgroup LRU
|
||||
pages that are selected for reclaiming come from the per-cgroup LRU
|
||||
list.
|
||||
|
||||
NOTE: Reclaim does not work for the root cgroup, since we cannot set any
|
||||
|
@ -316,7 +316,7 @@ We can check the usage:
|
|||
# cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes
|
||||
1216512
|
||||
|
||||
A successful write to this file does not guarantee a successful set of
|
||||
A successful write to this file does not guarantee a successful setting of
|
||||
this limit to the value written into the file. This can be due to a
|
||||
number of factors, such as rounding up to page boundaries or the total
|
||||
availability of memory on the system. The user is required to re-read
|
||||
|
@ -350,7 +350,7 @@ Trying usual test under memory controller is always helpful.
|
|||
4.1 Troubleshooting
|
||||
|
||||
Sometimes a user might find that the application under a cgroup is
|
||||
terminated by OOM killer. There are several causes for this:
|
||||
terminated by the OOM killer. There are several causes for this:
|
||||
|
||||
1. The cgroup limit is too low (just too low to do anything useful)
|
||||
2. The user is using anonymous memory and swap is turned off or too low
|
||||
|
@ -358,7 +358,7 @@ terminated by OOM killer. There are several causes for this:
|
|||
A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
|
||||
some of the pages cached in the cgroup (page cache pages).
|
||||
|
||||
To know what happens, disable OOM_Kill by 10. OOM Control(see below) and
|
||||
To know what happens, disabling OOM_Kill as per "10. OOM Control" (below) and
|
||||
seeing what happens will be helpful.
|
||||
|
||||
4.2 Task migration
|
||||
|
@ -399,10 +399,10 @@ About use_hierarchy, see Section 6.
|
|||
|
||||
Almost all pages tracked by this memory cgroup will be unmapped and freed.
|
||||
Some pages cannot be freed because they are locked or in-use. Such pages are
|
||||
moved to parent(if use_hierarchy==1) or root (if use_hierarchy==0) and this
|
||||
moved to parent (if use_hierarchy==1) or root (if use_hierarchy==0) and this
|
||||
cgroup will be empty.
|
||||
|
||||
Typical use case of this interface is that calling this before rmdir().
|
||||
The typical use case for this interface is before calling rmdir().
|
||||
Because rmdir() moves all pages to parent, some out-of-use page caches can be
|
||||
moved to the parent. If you want to avoid that, force_empty will be useful.
|
||||
|
||||
|
@ -486,7 +486,7 @@ You can reset failcnt by writing 0 to failcnt file.
|
|||
|
||||
For efficiency, as other kernel components, memory cgroup uses some optimization
|
||||
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
|
||||
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
|
||||
method and doesn't show 'exact' value of memory (and swap) usage, it's a fuzz
|
||||
value for efficient access. (Of course, when necessary, it's synchronized.)
|
||||
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
|
||||
value in memory.stat(see 5.2).
|
||||
|
@ -496,8 +496,8 @@ value in memory.stat(see 5.2).
|
|||
This is similar to numa_maps but operates on a per-memcg basis. This is
|
||||
useful for providing visibility into the numa locality information within
|
||||
an memcg since the pages are allowed to be allocated from any physical
|
||||
node. One of the usecases is evaluating application performance by
|
||||
combining this information with the application's cpu allocation.
|
||||
node. One of the use cases is evaluating application performance by
|
||||
combining this information with the application's CPU allocation.
|
||||
|
||||
We export "total", "file", "anon" and "unevictable" pages per-node for
|
||||
each memcg. The ouput format of memory.numa_stat is:
|
||||
|
@ -561,10 +561,10 @@ are pushed back to their soft limits. If the soft limit of each control
|
|||
group is very high, they are pushed back as much as possible to make
|
||||
sure that one control group does not starve the others of memory.
|
||||
|
||||
Please note that soft limits is a best effort feature, it comes with
|
||||
Please note that soft limits is a best-effort feature; it comes with
|
||||
no guarantees, but it does its best to make sure that when memory is
|
||||
heavily contended for, memory is allocated based on the soft limit
|
||||
hints/setup. Currently soft limit based reclaim is setup such that
|
||||
hints/setup. Currently soft limit based reclaim is set up such that
|
||||
it gets invoked from balance_pgdat (kswapd).
|
||||
|
||||
7.1 Interface
|
||||
|
@ -592,7 +592,7 @@ page tables.
|
|||
|
||||
8.1 Interface
|
||||
|
||||
This feature is disabled by default. It can be enabled(and disabled again) by
|
||||
This feature is disabled by default. It can be enabledi (and disabled again) by
|
||||
writing to memory.move_charge_at_immigrate of the destination cgroup.
|
||||
|
||||
If you want to enable it:
|
||||
|
@ -601,8 +601,8 @@ If you want to enable it:
|
|||
|
||||
Note: Each bits of move_charge_at_immigrate has its own meaning about what type
|
||||
of charges should be moved. See 8.2 for details.
|
||||
Note: Charges are moved only when you move mm->owner, IOW, a leader of a thread
|
||||
group.
|
||||
Note: Charges are moved only when you move mm->owner, in other words,
|
||||
a leader of a thread group.
|
||||
Note: If we cannot find enough space for the task in the destination cgroup, we
|
||||
try to make space by reclaiming memory. Task migration may fail if we
|
||||
cannot make enough space.
|
||||
|
@ -612,25 +612,25 @@ And if you want disable it again:
|
|||
|
||||
# echo 0 > memory.move_charge_at_immigrate
|
||||
|
||||
8.2 Type of charges which can be move
|
||||
8.2 Type of charges which can be moved
|
||||
|
||||
Each bits of move_charge_at_immigrate has its own meaning about what type of
|
||||
charges should be moved. But in any cases, it must be noted that an account of
|
||||
a page or a swap can be moved only when it is charged to the task's current(old)
|
||||
memory cgroup.
|
||||
Each bit in move_charge_at_immigrate has its own meaning about what type of
|
||||
charges should be moved. But in any case, it must be noted that an account of
|
||||
a page or a swap can be moved only when it is charged to the task's current
|
||||
(old) memory cgroup.
|
||||
|
||||
bit | what type of charges would be moved ?
|
||||
-----+------------------------------------------------------------------------
|
||||
0 | A charge of an anonymous page(or swap of it) used by the target task.
|
||||
| You must enable Swap Extension(see 2.4) to enable move of swap charges.
|
||||
0 | A charge of an anonymous page (or swap of it) used by the target task.
|
||||
| You must enable Swap Extension (see 2.4) to enable move of swap charges.
|
||||
-----+------------------------------------------------------------------------
|
||||
1 | A charge of file pages(normal file, tmpfs file(e.g. ipc shared memory)
|
||||
1 | A charge of file pages (normal file, tmpfs file (e.g. ipc shared memory)
|
||||
| and swaps of tmpfs file) mmapped by the target task. Unlike the case of
|
||||
| anonymous pages, file pages(and swaps) in the range mmapped by the task
|
||||
| anonymous pages, file pages (and swaps) in the range mmapped by the task
|
||||
| will be moved even if the task hasn't done page fault, i.e. they might
|
||||
| not be the task's "RSS", but other task's "RSS" that maps the same file.
|
||||
| And mapcount of the page is ignored(the page can be moved even if
|
||||
| page_mapcount(page) > 1). You must enable Swap Extension(see 2.4) to
|
||||
| And mapcount of the page is ignored (the page can be moved even if
|
||||
| page_mapcount(page) > 1). You must enable Swap Extension (see 2.4) to
|
||||
| enable move of swap charges.
|
||||
|
||||
8.3 TODO
|
||||
|
@ -640,11 +640,11 @@ memory cgroup.
|
|||
|
||||
9. Memory thresholds
|
||||
|
||||
Memory cgroup implements memory thresholds using cgroups notification
|
||||
Memory cgroup implements memory thresholds using the cgroups notification
|
||||
API (see cgroups.txt). It allows to register multiple memory and memsw
|
||||
thresholds and gets notifications when it crosses.
|
||||
|
||||
To register a threshold application need:
|
||||
To register a threshold, an application must:
|
||||
- create an eventfd using eventfd(2);
|
||||
- open memory.usage_in_bytes or memory.memsw.usage_in_bytes;
|
||||
- write string like "<event_fd> <fd of memory.usage_in_bytes> <threshold>" to
|
||||
|
@ -659,24 +659,24 @@ It's applicable for root and non-root cgroup.
|
|||
|
||||
memory.oom_control file is for OOM notification and other controls.
|
||||
|
||||
Memory cgroup implements OOM notifier using cgroup notification
|
||||
Memory cgroup implements OOM notifier using the cgroup notification
|
||||
API (See cgroups.txt). It allows to register multiple OOM notification
|
||||
delivery and gets notification when OOM happens.
|
||||
|
||||
To register a notifier, application need:
|
||||
To register a notifier, an application must:
|
||||
- create an eventfd using eventfd(2)
|
||||
- open memory.oom_control file
|
||||
- write string like "<event_fd> <fd of memory.oom_control>" to
|
||||
cgroup.event_control
|
||||
|
||||
Application will be notified through eventfd when OOM happens.
|
||||
OOM notification doesn't work for root cgroup.
|
||||
The application will be notified through eventfd when OOM happens.
|
||||
OOM notification doesn't work for the root cgroup.
|
||||
|
||||
You can disable OOM-killer by writing "1" to memory.oom_control file, as:
|
||||
You can disable the OOM-killer by writing "1" to memory.oom_control file, as:
|
||||
|
||||
#echo 1 > memory.oom_control
|
||||
|
||||
This operation is only allowed to the top cgroup of sub-hierarchy.
|
||||
This operation is only allowed to the top cgroup of a sub-hierarchy.
|
||||
If OOM-killer is disabled, tasks under cgroup will hang/sleep
|
||||
in memory cgroup's OOM-waitqueue when they request accountable memory.
|
||||
|
||||
|
|
93
Documentation/cpu-freq/boost.txt
Normal file
93
Documentation/cpu-freq/boost.txt
Normal file
|
@ -0,0 +1,93 @@
|
|||
Processor boosting control
|
||||
|
||||
- information for users -
|
||||
|
||||
Quick guide for the impatient:
|
||||
--------------------
|
||||
/sys/devices/system/cpu/cpufreq/boost
|
||||
controls the boost setting for the whole system. You can read and write
|
||||
that file with either "0" (boosting disabled) or "1" (boosting allowed).
|
||||
Reading or writing 1 does not mean that the system is boosting at this
|
||||
very moment, but only that the CPU _may_ raise the frequency at it's
|
||||
discretion.
|
||||
--------------------
|
||||
|
||||
Introduction
|
||||
-------------
|
||||
Some CPUs support a functionality to raise the operating frequency of
|
||||
some cores in a multi-core package if certain conditions apply, mostly
|
||||
if the whole chip is not fully utilized and below it's intended thermal
|
||||
budget. This is done without operating system control by a combination
|
||||
of hardware and firmware.
|
||||
On Intel CPUs this is called "Turbo Boost", AMD calls it "Turbo-Core",
|
||||
in technical documentation "Core performance boost". In Linux we use
|
||||
the term "boost" for convenience.
|
||||
|
||||
Rationale for disable switch
|
||||
----------------------------
|
||||
|
||||
Though the idea is to just give better performance without any user
|
||||
intervention, sometimes the need arises to disable this functionality.
|
||||
Most systems offer a switch in the (BIOS) firmware to disable the
|
||||
functionality at all, but a more fine-grained and dynamic control would
|
||||
be desirable:
|
||||
1. While running benchmarks, reproducible results are important. Since
|
||||
the boosting functionality depends on the load of the whole package,
|
||||
single thread performance can vary. By explicitly disabling the boost
|
||||
functionality at least for the benchmark's run-time the system will run
|
||||
at a fixed frequency and results are reproducible again.
|
||||
2. To examine the impact of the boosting functionality it is helpful
|
||||
to do tests with and without boosting.
|
||||
3. Boosting means overclocking the processor, though under controlled
|
||||
conditions. By raising the frequency and the voltage the processor
|
||||
will consume more power than without the boosting, which may be
|
||||
undesirable for instance for mobile users. Disabling boosting may
|
||||
save power here, though this depends on the workload.
|
||||
|
||||
|
||||
User controlled switch
|
||||
----------------------
|
||||
|
||||
To allow the user to toggle the boosting functionality, the acpi-cpufreq
|
||||
driver exports a sysfs knob to disable it. There is a file:
|
||||
/sys/devices/system/cpu/cpufreq/boost
|
||||
which can either read "0" (boosting disabled) or "1" (boosting enabled).
|
||||
Reading the file is always supported, even if the processor does not
|
||||
support boosting. In this case the file will be read-only and always
|
||||
reads as "0". Explicitly changing the permissions and writing to that
|
||||
file anyway will return EINVAL.
|
||||
|
||||
On supported CPUs one can write either a "0" or a "1" into this file.
|
||||
This will either disable the boost functionality on all cores in the
|
||||
whole system (0) or will allow the hardware to boost at will (1).
|
||||
|
||||
Writing a "1" does not explicitly boost the system, but just allows the
|
||||
CPU (and the firmware) to boost at their discretion. Some implementations
|
||||
take external factors like the chip's temperature into account, so
|
||||
boosting once does not necessarily mean that it will occur every time
|
||||
even using the exact same software setup.
|
||||
|
||||
|
||||
AMD legacy cpb switch
|
||||
---------------------
|
||||
The AMD powernow-k8 driver used to support a very similar switch to
|
||||
disable or enable the "Core Performance Boost" feature of some AMD CPUs.
|
||||
This switch was instantiated in each CPU's cpufreq directory
|
||||
(/sys/devices/system/cpu[0-9]*/cpufreq) and was called "cpb".
|
||||
Though the per CPU existence hints at a more fine grained control, the
|
||||
actual implementation only supported a system-global switch semantics,
|
||||
which was simply reflected into each CPU's file. Writing a 0 or 1 into it
|
||||
would pull the other CPUs to the same state.
|
||||
For compatibility reasons this file and its behavior is still supported
|
||||
on AMD CPUs, though it is now protected by a config switch
|
||||
(X86_ACPI_CPUFREQ_CPB). On Intel CPUs this file will never be created,
|
||||
even with the config option set.
|
||||
This functionality is considered legacy and will be removed in some future
|
||||
kernel version.
|
||||
|
||||
More fine grained boosting control
|
||||
----------------------------------
|
||||
|
||||
Technically it is possible to switch the boosting functionality at least
|
||||
on a per package basis, for some CPUs even per core. Currently the driver
|
||||
does not support it, but this may be implemented in the future.
|
|
@ -76,9 +76,17 @@ total 0
|
|||
|
||||
|
||||
* desc : Small description about the idle state (string)
|
||||
* disable : Option to disable this idle state (bool)
|
||||
* disable : Option to disable this idle state (bool) -> see note below
|
||||
* latency : Latency to exit out of this idle state (in microseconds)
|
||||
* name : Name of the idle state (string)
|
||||
* power : Power consumed while in this idle state (in milliwatts)
|
||||
* time : Total time spent in this idle state (in microseconds)
|
||||
* usage : Number of times this state was entered (count)
|
||||
|
||||
Note:
|
||||
The behavior and the effect of the disable variable depends on the
|
||||
implementation of a particular governor. In the ladder governor, for
|
||||
example, it is not coherent, i.e. if one is disabling a light state,
|
||||
then all deeper states are disabled as well, but the disable variable
|
||||
does not reflect it. Likewise, if one enables a deep state but a lighter
|
||||
state still is disabled, then this has no effect.
|
||||
|
|
312
Documentation/crypto/asymmetric-keys.txt
Normal file
312
Documentation/crypto/asymmetric-keys.txt
Normal file
|
@ -0,0 +1,312 @@
|
|||
=============================================
|
||||
ASYMMETRIC / PUBLIC-KEY CRYPTOGRAPHY KEY TYPE
|
||||
=============================================
|
||||
|
||||
Contents:
|
||||
|
||||
- Overview.
|
||||
- Key identification.
|
||||
- Accessing asymmetric keys.
|
||||
- Signature verification.
|
||||
- Asymmetric key subtypes.
|
||||
- Instantiation data parsers.
|
||||
|
||||
|
||||
========
|
||||
OVERVIEW
|
||||
========
|
||||
|
||||
The "asymmetric" key type is designed to be a container for the keys used in
|
||||
public-key cryptography, without imposing any particular restrictions on the
|
||||
form or mechanism of the cryptography or form of the key.
|
||||
|
||||
The asymmetric key is given a subtype that defines what sort of data is
|
||||
associated with the key and provides operations to describe and destroy it.
|
||||
However, no requirement is made that the key data actually be stored in the
|
||||
key.
|
||||
|
||||
A completely in-kernel key retention and operation subtype can be defined, but
|
||||
it would also be possible to provide access to cryptographic hardware (such as
|
||||
a TPM) that might be used to both retain the relevant key and perform
|
||||
operations using that key. In such a case, the asymmetric key would then
|
||||
merely be an interface to the TPM driver.
|
||||
|
||||
Also provided is the concept of a data parser. Data parsers are responsible
|
||||
for extracting information from the blobs of data passed to the instantiation
|
||||
function. The first data parser that recognises the blob gets to set the
|
||||
subtype of the key and define the operations that can be done on that key.
|
||||
|
||||
A data parser may interpret the data blob as containing the bits representing a
|
||||
key, or it may interpret it as a reference to a key held somewhere else in the
|
||||
system (for example, a TPM).
|
||||
|
||||
|
||||
==================
|
||||
KEY IDENTIFICATION
|
||||
==================
|
||||
|
||||
If a key is added with an empty name, the instantiation data parsers are given
|
||||
the opportunity to pre-parse a key and to determine the description the key
|
||||
should be given from the content of the key.
|
||||
|
||||
This can then be used to refer to the key, either by complete match or by
|
||||
partial match. The key type may also use other criteria to refer to a key.
|
||||
|
||||
The asymmetric key type's match function can then perform a wider range of
|
||||
comparisons than just the straightforward comparison of the description with
|
||||
the criterion string:
|
||||
|
||||
(1) If the criterion string is of the form "id:<hexdigits>" then the match
|
||||
function will examine a key's fingerprint to see if the hex digits given
|
||||
after the "id:" match the tail. For instance:
|
||||
|
||||
keyctl search @s asymmetric id:5acc2142
|
||||
|
||||
will match a key with fingerprint:
|
||||
|
||||
1A00 2040 7601 7889 DE11 882C 3823 04AD 5ACC 2142
|
||||
|
||||
(2) If the criterion string is of the form "<subtype>:<hexdigits>" then the
|
||||
match will match the ID as in (1), but with the added restriction that
|
||||
only keys of the specified subtype (e.g. tpm) will be matched. For
|
||||
instance:
|
||||
|
||||
keyctl search @s asymmetric tpm:5acc2142
|
||||
|
||||
Looking in /proc/keys, the last 8 hex digits of the key fingerprint are
|
||||
displayed, along with the subtype:
|
||||
|
||||
1a39e171 I----- 1 perm 3f010000 0 0 asymmetri modsign.0: DSA 5acc2142 []
|
||||
|
||||
|
||||
=========================
|
||||
ACCESSING ASYMMETRIC KEYS
|
||||
=========================
|
||||
|
||||
For general access to asymmetric keys from within the kernel, the following
|
||||
inclusion is required:
|
||||
|
||||
#include <crypto/public_key.h>
|
||||
|
||||
This gives access to functions for dealing with asymmetric / public keys.
|
||||
Three enums are defined there for representing public-key cryptography
|
||||
algorithms:
|
||||
|
||||
enum pkey_algo
|
||||
|
||||
digest algorithms used by those:
|
||||
|
||||
enum pkey_hash_algo
|
||||
|
||||
and key identifier representations:
|
||||
|
||||
enum pkey_id_type
|
||||
|
||||
Note that the key type representation types are required because key
|
||||
identifiers from different standards aren't necessarily compatible. For
|
||||
instance, PGP generates key identifiers by hashing the key data plus some
|
||||
PGP-specific metadata, whereas X.509 has arbitrary certificate identifiers.
|
||||
|
||||
The operations defined upon a key are:
|
||||
|
||||
(1) Signature verification.
|
||||
|
||||
Other operations are possible (such as encryption) with the same key data
|
||||
required for verification, but not currently supported, and others
|
||||
(eg. decryption and signature generation) require extra key data.
|
||||
|
||||
|
||||
SIGNATURE VERIFICATION
|
||||
----------------------
|
||||
|
||||
An operation is provided to perform cryptographic signature verification, using
|
||||
an asymmetric key to provide or to provide access to the public key.
|
||||
|
||||
int verify_signature(const struct key *key,
|
||||
const struct public_key_signature *sig);
|
||||
|
||||
The caller must have already obtained the key from some source and can then use
|
||||
it to check the signature. The caller must have parsed the signature and
|
||||
transferred the relevant bits to the structure pointed to by sig.
|
||||
|
||||
struct public_key_signature {
|
||||
u8 *digest;
|
||||
u8 digest_size;
|
||||
enum pkey_hash_algo pkey_hash_algo : 8;
|
||||
u8 nr_mpi;
|
||||
union {
|
||||
MPI mpi[2];
|
||||
...
|
||||
};
|
||||
};
|
||||
|
||||
The algorithm used must be noted in sig->pkey_hash_algo, and all the MPIs that
|
||||
make up the actual signature must be stored in sig->mpi[] and the count of MPIs
|
||||
placed in sig->nr_mpi.
|
||||
|
||||
In addition, the data must have been digested by the caller and the resulting
|
||||
hash must be pointed to by sig->digest and the size of the hash be placed in
|
||||
sig->digest_size.
|
||||
|
||||
The function will return 0 upon success or -EKEYREJECTED if the signature
|
||||
doesn't match.
|
||||
|
||||
The function may also return -ENOTSUPP if an unsupported public-key algorithm
|
||||
or public-key/hash algorithm combination is specified or the key doesn't
|
||||
support the operation; -EBADMSG or -ERANGE if some of the parameters have weird
|
||||
data; or -ENOMEM if an allocation can't be performed. -EINVAL can be returned
|
||||
if the key argument is the wrong type or is incompletely set up.
|
||||
|
||||
|
||||
=======================
|
||||
ASYMMETRIC KEY SUBTYPES
|
||||
=======================
|
||||
|
||||
Asymmetric keys have a subtype that defines the set of operations that can be
|
||||
performed on that key and that determines what data is attached as the key
|
||||
payload. The payload format is entirely at the whim of the subtype.
|
||||
|
||||
The subtype is selected by the key data parser and the parser must initialise
|
||||
the data required for it. The asymmetric key retains a reference on the
|
||||
subtype module.
|
||||
|
||||
The subtype definition structure can be found in:
|
||||
|
||||
#include <keys/asymmetric-subtype.h>
|
||||
|
||||
and looks like the following:
|
||||
|
||||
struct asymmetric_key_subtype {
|
||||
struct module *owner;
|
||||
const char *name;
|
||||
|
||||
void (*describe)(const struct key *key, struct seq_file *m);
|
||||
void (*destroy)(void *payload);
|
||||
int (*verify_signature)(const struct key *key,
|
||||
const struct public_key_signature *sig);
|
||||
};
|
||||
|
||||
Asymmetric keys point to this with their type_data[0] member.
|
||||
|
||||
The owner and name fields should be set to the owning module and the name of
|
||||
the subtype. Currently, the name is only used for print statements.
|
||||
|
||||
There are a number of operations defined by the subtype:
|
||||
|
||||
(1) describe().
|
||||
|
||||
Mandatory. This allows the subtype to display something in /proc/keys
|
||||
against the key. For instance the name of the public key algorithm type
|
||||
could be displayed. The key type will display the tail of the key
|
||||
identity string after this.
|
||||
|
||||
(2) destroy().
|
||||
|
||||
Mandatory. This should free the memory associated with the key. The
|
||||
asymmetric key will look after freeing the fingerprint and releasing the
|
||||
reference on the subtype module.
|
||||
|
||||
(3) verify_signature().
|
||||
|
||||
Optional. These are the entry points for the key usage operations.
|
||||
Currently there is only the one defined. If not set, the caller will be
|
||||
given -ENOTSUPP. The subtype may do anything it likes to implement an
|
||||
operation, including offloading to hardware.
|
||||
|
||||
|
||||
==========================
|
||||
INSTANTIATION DATA PARSERS
|
||||
==========================
|
||||
|
||||
The asymmetric key type doesn't generally want to store or to deal with a raw
|
||||
blob of data that holds the key data. It would have to parse it and error
|
||||
check it each time it wanted to use it. Further, the contents of the blob may
|
||||
have various checks that can be performed on it (eg. self-signatures, validity
|
||||
dates) and may contain useful data about the key (identifiers, capabilities).
|
||||
|
||||
Also, the blob may represent a pointer to some hardware containing the key
|
||||
rather than the key itself.
|
||||
|
||||
Examples of blob formats for which parsers could be implemented include:
|
||||
|
||||
- OpenPGP packet stream [RFC 4880].
|
||||
- X.509 ASN.1 stream.
|
||||
- Pointer to TPM key.
|
||||
- Pointer to UEFI key.
|
||||
|
||||
During key instantiation each parser in the list is tried until one doesn't
|
||||
return -EBADMSG.
|
||||
|
||||
The parser definition structure can be found in:
|
||||
|
||||
#include <keys/asymmetric-parser.h>
|
||||
|
||||
and looks like the following:
|
||||
|
||||
struct asymmetric_key_parser {
|
||||
struct module *owner;
|
||||
const char *name;
|
||||
|
||||
int (*parse)(struct key_preparsed_payload *prep);
|
||||
};
|
||||
|
||||
The owner and name fields should be set to the owning module and the name of
|
||||
the parser.
|
||||
|
||||
There is currently only a single operation defined by the parser, and it is
|
||||
mandatory:
|
||||
|
||||
(1) parse().
|
||||
|
||||
This is called to preparse the key from the key creation and update paths.
|
||||
In particular, it is called during the key creation _before_ a key is
|
||||
allocated, and as such, is permitted to provide the key's description in
|
||||
the case that the caller declines to do so.
|
||||
|
||||
The caller passes a pointer to the following struct with all of the fields
|
||||
cleared, except for data, datalen and quotalen [see
|
||||
Documentation/security/keys.txt].
|
||||
|
||||
struct key_preparsed_payload {
|
||||
char *description;
|
||||
void *type_data[2];
|
||||
void *payload;
|
||||
const void *data;
|
||||
size_t datalen;
|
||||
size_t quotalen;
|
||||
};
|
||||
|
||||
The instantiation data is in a blob pointed to by data and is datalen in
|
||||
size. The parse() function is not permitted to change these two values at
|
||||
all, and shouldn't change any of the other values _unless_ they are
|
||||
recognise the blob format and will not return -EBADMSG to indicate it is
|
||||
not theirs.
|
||||
|
||||
If the parser is happy with the blob, it should propose a description for
|
||||
the key and attach it to ->description, ->type_data[0] should be set to
|
||||
point to the subtype to be used, ->payload should be set to point to the
|
||||
initialised data for that subtype, ->type_data[1] should point to a hex
|
||||
fingerprint and quotalen should be updated to indicate how much quota this
|
||||
key should account for.
|
||||
|
||||
When clearing up, the data attached to ->type_data[1] and ->description
|
||||
will be kfree()'d and the data attached to ->payload will be passed to the
|
||||
subtype's ->destroy() method to be disposed of. A module reference for
|
||||
the subtype pointed to by ->type_data[0] will be put.
|
||||
|
||||
|
||||
If the data format is not recognised, -EBADMSG should be returned. If it
|
||||
is recognised, but the key cannot for some reason be set up, some other
|
||||
negative error code should be returned. On success, 0 should be returned.
|
||||
|
||||
The key's fingerprint string may be partially matched upon. For a
|
||||
public-key algorithm such as RSA and DSA this will likely be a printable
|
||||
hex version of the key's fingerprint.
|
||||
|
||||
Functions are provided to register and unregister parsers:
|
||||
|
||||
int register_asymmetric_key_parser(struct asymmetric_key_parser *parser);
|
||||
void unregister_asymmetric_key_parser(struct asymmetric_key_parser *subtype);
|
||||
|
||||
Parsers may not have the same name. The names are otherwise only used for
|
||||
displaying in debugging messages.
|
|
@ -132,3 +132,12 @@ Here we can see the RAID type is raid4, there are 5 devices - all of
|
|||
which are 'A'live, and the array is 2/490221568 complete with recovery.
|
||||
Faulty or missing devices are marked 'D'. Devices that are out-of-sync
|
||||
are marked 'a'.
|
||||
|
||||
|
||||
Version History
|
||||
---------------
|
||||
1.0.0 Initial version. Support for RAID 4/5/6
|
||||
1.1.0 Added support for RAID 1
|
||||
1.2.0 Handle creation of arrays that contain failed devices.
|
||||
1.3.0 Added support for RAID 10
|
||||
1.3.1 Allow device replacement/rebuild for RAID 10
|
||||
|
|
|
@ -1,3 +1,15 @@
|
|||
ARM Integrator/AP (Application Platform) and Integrator/CP (Compact Platform)
|
||||
-----------------------------------------------------------------------------
|
||||
ARM's oldest Linux-supported platform with connectors for different core
|
||||
tiles of ARMv4, ARMv5 and ARMv6 type.
|
||||
|
||||
Required properties (in root node):
|
||||
compatible = "arm,integrator-ap"; /* Application Platform */
|
||||
compatible = "arm,integrator-cp"; /* Compact Platform */
|
||||
|
||||
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
|
||||
|
||||
|
||||
ARM Versatile Application and Platform Baseboards
|
||||
-------------------------------------------------
|
||||
ARM's development hardware platform with connectors for customizable
|
||||
|
|
8
Documentation/devicetree/bindings/arm/bcm2835.txt
Normal file
8
Documentation/devicetree/bindings/arm/bcm2835.txt
Normal file
|
@ -0,0 +1,8 @@
|
|||
Broadcom BCM2835 device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
Boards with the BCM2835 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "brcm,bcm2835";
|
17
Documentation/devicetree/bindings/arm/calxeda/combophy.txt
Normal file
17
Documentation/devicetree/bindings/arm/calxeda/combophy.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
Calxeda Highbank Combination Phys for SATA
|
||||
|
||||
Properties:
|
||||
- compatible : Should be "calxeda,hb-combophy"
|
||||
- #phy-cells: Should be 1.
|
||||
- reg : Address and size for Combination Phy registers.
|
||||
- phydev: device ID for programming the combophy.
|
||||
|
||||
Example:
|
||||
|
||||
combophy5: combo-phy@fff5d000 {
|
||||
compatible = "calxeda,hb-combophy";
|
||||
#phy-cells = <1>;
|
||||
reg = <0xfff5d000 0x1000>;
|
||||
phydev = <31>;
|
||||
};
|
||||
|
51
Documentation/devicetree/bindings/arm/davinci/nand.txt
Normal file
51
Documentation/devicetree/bindings/arm/davinci/nand.txt
Normal file
|
@ -0,0 +1,51 @@
|
|||
* Texas Instruments Davinci NAND
|
||||
|
||||
This file provides information, what the device node for the
|
||||
davinci nand interface contain.
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,davinci-nand";
|
||||
- reg : contain 2 offset/length values:
|
||||
- offset and length for the access window
|
||||
- offset and length for accessing the aemif control registers
|
||||
- ti,davinci-chipselect: Indicates on the davinci_nand driver which
|
||||
chipselect is used for accessing the nand.
|
||||
|
||||
Recommended properties :
|
||||
- ti,davinci-mask-ale: mask for ale
|
||||
- ti,davinci-mask-cle: mask for cle
|
||||
- ti,davinci-mask-chipsel: mask for chipselect
|
||||
- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
|
||||
- "none"
|
||||
- "soft"
|
||||
- "hw"
|
||||
- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
|
||||
- ti,davinci-nand-buswidth: buswidth 8 or 16
|
||||
- ti,davinci-nand-use-bbt: use flash based bad block table support.
|
||||
|
||||
Example (enbw_cmc board):
|
||||
aemif@60000000 {
|
||||
compatible = "ti,davinci-aemif";
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x68000000 0x80000>;
|
||||
ranges = <2 0 0x60000000 0x02000000
|
||||
3 0 0x62000000 0x02000000
|
||||
4 0 0x64000000 0x02000000
|
||||
5 0 0x66000000 0x02000000
|
||||
6 0 0x68000000 0x02000000>;
|
||||
nand@3,0 {
|
||||
compatible = "ti,davinci-nand";
|
||||
reg = <3 0x0 0x807ff
|
||||
6 0x0 0x8000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ti,davinci-chipselect = <1>;
|
||||
ti,davinci-mask-ale = <0>;
|
||||
ti,davinci-mask-cle = <0>;
|
||||
ti,davinci-mask-chipsel = <0>;
|
||||
ti,davinci-ecc-mode = "hw";
|
||||
ti,davinci-ecc-bits = <4>;
|
||||
ti,davinci-nand-use-bbt;
|
||||
};
|
||||
};
|
17
Documentation/devicetree/bindings/arm/mrvl/tauros2.txt
Normal file
17
Documentation/devicetree/bindings/arm/mrvl/tauros2.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
* Marvell Tauros2 Cache
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "marvell,tauros2-cache".
|
||||
- marvell,tauros2-cache-features : Specify the features supported for the
|
||||
tauros2 cache.
|
||||
The features including
|
||||
CACHE_TAUROS2_PREFETCH_ON (1 << 0)
|
||||
CACHE_TAUROS2_LINEFILL_BURST8 (1 << 1)
|
||||
The definition can be found at
|
||||
arch/arm/include/asm/hardware/cache-tauros2.h
|
||||
|
||||
Example:
|
||||
L2: l2-cache {
|
||||
compatible = "marvell,tauros2-cache";
|
||||
marvell,tauros2-cache-features = <0x3>;
|
||||
};
|
38
Documentation/devicetree/bindings/arm/msm/timer.txt
Normal file
38
Documentation/devicetree/bindings/arm/msm/timer.txt
Normal file
|
@ -0,0 +1,38 @@
|
|||
* MSM Timer
|
||||
|
||||
Properties:
|
||||
|
||||
- compatible : Should at least contain "qcom,msm-timer". More specific
|
||||
properties such as "qcom,msm-gpt" and "qcom,msm-dgt" specify a general
|
||||
purpose timer and a debug timer respectively.
|
||||
|
||||
- interrupts : Interrupt indicating a match event.
|
||||
|
||||
- reg : Specifies the base address of the timer registers. The second region
|
||||
specifies an optional register used to configure the clock divider.
|
||||
|
||||
- clock-frequency : The frequency of the timer in Hz.
|
||||
|
||||
Optional:
|
||||
|
||||
- cpu-offset : per-cpu offset used when the timer is accessed without the
|
||||
CPU remapping facilities. The offset is cpu-offset * cpu-nr.
|
||||
|
||||
Example:
|
||||
|
||||
timer@200a004 {
|
||||
compatible = "qcom,msm-gpt", "qcom,msm-timer";
|
||||
interrupts = <1 2 0x301>;
|
||||
reg = <0x0200a004 0x10>;
|
||||
clock-frequency = <32768>;
|
||||
cpu-offset = <0x40000>;
|
||||
};
|
||||
|
||||
timer@200a024 {
|
||||
compatible = "qcom,msm-dgt", "qcom,msm-timer";
|
||||
interrupts = <1 3 0x301>;
|
||||
reg = <0x0200a024 0x10>,
|
||||
<0x0200a034 0x4>;
|
||||
clock-frequency = <6750000>;
|
||||
cpu-offset = <0x40000>;
|
||||
};
|
|
@ -36,6 +36,9 @@ Boards:
|
|||
- OMAP3 BeagleBoard : Low cost community board
|
||||
compatible = "ti,omap3-beagle", "ti,omap3"
|
||||
|
||||
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
|
||||
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
|
||||
|
||||
- OMAP4 SDP : Software Developement Board
|
||||
compatible = "ti,omap4-sdp", "ti,omap4430"
|
||||
|
||||
|
|
|
@ -7,8 +7,12 @@ representation in the device tree should be done as under:-
|
|||
Required properties:
|
||||
|
||||
- compatible : should be one of
|
||||
"arm,cortex-a15-pmu"
|
||||
"arm,cortex-a9-pmu"
|
||||
"arm,cortex-a8-pmu"
|
||||
"arm,cortex-a7-pmu"
|
||||
"arm,cortex-a5-pmu"
|
||||
"arm,arm11mpcore-pmu"
|
||||
"arm,arm1176-pmu"
|
||||
"arm,arm1136-pmu"
|
||||
- interrupts : 1 combined interrupt or 1 per core.
|
||||
|
|
31
Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
Normal file
31
Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
Normal file
|
@ -0,0 +1,31 @@
|
|||
* ARM Versatile FPGA interrupt controller
|
||||
|
||||
One or more FPGA IRQ controllers can be synthesized in an ARM reference board
|
||||
such as the Integrator or Versatile family. The output of these different
|
||||
controllers are OR:ed together and fed to the CPU tile's IRQ input. Each
|
||||
instance can handle up to 32 interrupts.
|
||||
|
||||
Required properties:
|
||||
- compatible: "arm,versatile-fpga-irq"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- #interrupt-cells: The number of cells to define the interrupts. Must be 1
|
||||
as the FPGA IRQ controller has no configuration options for interrupt
|
||||
sources. The cell is a u32 and defines the interrupt number.
|
||||
- reg: The register bank for the FPGA interrupt controller.
|
||||
- clear-mask: a u32 number representing the mask written to clear all IRQs
|
||||
on the controller at boot for example.
|
||||
- valid-mask: a u32 number representing a bit mask determining which of
|
||||
the interrupts are valid. Unconnected/unused lines are set to 0, and
|
||||
the system till not make it possible for devices to request these
|
||||
interrupts.
|
||||
|
||||
Example:
|
||||
|
||||
pic: pic@14000000 {
|
||||
compatible = "arm,versatile-fpga-irq";
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-controller;
|
||||
reg = <0x14000000 0x100>;
|
||||
clear-mask = <0xffffffff>;
|
||||
valid-mask = <0x003fffff>;
|
||||
};
|
14
Documentation/devicetree/bindings/arm/vt8500.txt
Normal file
14
Documentation/devicetree/bindings/arm/vt8500.txt
Normal file
|
@ -0,0 +1,14 @@
|
|||
VIA/Wondermedia VT8500 Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Boards with the VIA VT8500 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "via,vt8500";
|
||||
|
||||
Boards with the Wondermedia WM8505 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8505";
|
||||
|
||||
Boards with the Wondermedia WM8650 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8650";
|
|
@ -0,0 +1,16 @@
|
|||
VIA/Wondermedia VT8500 Interrupt Controller
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-intc"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- #interrupt-cells : should be <1>
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@d8140000 {
|
||||
compatible = "via,vt8500-intc";
|
||||
interrupt-controller;
|
||||
reg = <0xd8140000 0x10000>;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
|
@ -0,0 +1,13 @@
|
|||
VIA/Wondermedia VT8500 Power Management Controller
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-pmc"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
|
||||
Example:
|
||||
|
||||
pmc@d8130000 {
|
||||
compatible = "via,vt8500-pmc";
|
||||
reg = <0xd8130000 0x1000>;
|
||||
};
|
|
@ -0,0 +1,15 @@
|
|||
VIA/Wondermedia VT8500 Timer
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-timer"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- interrupts : interrupt for the timer
|
||||
|
||||
Example:
|
||||
|
||||
timer@d8130100 {
|
||||
compatible = "via,vt8500-timer";
|
||||
reg = <0xd8130100 0x28>;
|
||||
interrupts = <36>;
|
||||
};
|
25
Documentation/devicetree/bindings/arm/xen.txt
Normal file
25
Documentation/devicetree/bindings/arm/xen.txt
Normal file
|
@ -0,0 +1,25 @@
|
|||
* Xen hypervisor device tree bindings
|
||||
|
||||
Xen ARM virtual platforms shall have a top-level "hypervisor" node with
|
||||
the following properties:
|
||||
|
||||
- compatible:
|
||||
compatible = "xen,xen-<version>", "xen,xen";
|
||||
where <version> is the version of the Xen ABI of the platform.
|
||||
|
||||
- reg: specifies the base physical address and size of a region in
|
||||
memory where the grant table should be mapped to, using an
|
||||
HYPERVISOR_memory_op hypercall. The memory region is large enough to map
|
||||
the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
|
||||
|
||||
- interrupts: the interrupt used by Xen to inject event notifications.
|
||||
A GIC node is also required.
|
||||
|
||||
|
||||
Example (assuming #address-cells = <2> and #size-cells = <2>):
|
||||
|
||||
hypervisor {
|
||||
compatible = "xen,xen-4.3", "xen,xen";
|
||||
reg = <0 0xb0000000 0 0x20000>;
|
||||
interrupts = <1 15 0xf08>;
|
||||
};
|
|
@ -8,9 +8,18 @@ Required properties:
|
|||
- interrupts : <interrupt mapping for SATA IRQ>
|
||||
- reg : <registers mapping>
|
||||
|
||||
Optional properties:
|
||||
- calxeda,port-phys: phandle-combophy and lane assignment, which maps each
|
||||
SATA port to a combophy and a lane within that
|
||||
combophy
|
||||
- dma-coherent : Present if dma operations are coherent
|
||||
|
||||
Example:
|
||||
sata@ffe08000 {
|
||||
compatible = "calxeda,hb-ahci";
|
||||
reg = <0xffe08000 0x1000>;
|
||||
interrupts = <115>;
|
||||
calxeda,port-phys = <&combophy5 0 &combophy0 0 &combophy0 1
|
||||
&combophy0 2 &combophy0 3>;
|
||||
|
||||
};
|
||||
|
|
17
Documentation/devicetree/bindings/ata/pata-arasan.txt
Normal file
17
Documentation/devicetree/bindings/ata/pata-arasan.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
* ARASAN PATA COMPACT FLASH CONTROLLER
|
||||
|
||||
Required properties:
|
||||
- compatible: "arasan,cf-spear1340"
|
||||
- reg: Address range of the CF registers
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupt: Should contain the CF interrupt number
|
||||
|
||||
Example:
|
||||
|
||||
cf@fc000000 {
|
||||
compatible = "arasan,cf-spear1340";
|
||||
reg = <0xfc000000 0x1000>;
|
||||
interrupt-parent = <&vic1>;
|
||||
interrupts = <12>;
|
||||
};
|
10
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
Normal file
10
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
Normal file
|
@ -0,0 +1,10 @@
|
|||
* OMAP OCP2SCP - ocp interface to scp interface
|
||||
|
||||
properties:
|
||||
- compatible : Should be "ti,omap-ocp2scp"
|
||||
- #address-cells, #size-cells : Must be present if the device has sub-nodes
|
||||
- ranges : the child address space are mapped 1:1 onto the parent address space
|
||||
- ti,hwmods : must be "ocp2scp_usb_phy"
|
||||
|
||||
Sub-nodes:
|
||||
All the devices connected to ocp2scp are described using sub-node to ocp2scp
|
76
Documentation/devicetree/bindings/clock/imx23-clock.txt
Normal file
76
Documentation/devicetree/bindings/clock/imx23-clock.txt
Normal file
|
@ -0,0 +1,76 @@
|
|||
* Clock bindings for Freescale i.MX23
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx23-clkctrl"
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. The following is a full list of i.MX23
|
||||
clocks and IDs.
|
||||
|
||||
Clock ID
|
||||
------------------
|
||||
ref_xtal 0
|
||||
pll 1
|
||||
ref_cpu 2
|
||||
ref_emi 3
|
||||
ref_pix 4
|
||||
ref_io 5
|
||||
saif_sel 6
|
||||
lcdif_sel 7
|
||||
gpmi_sel 8
|
||||
ssp_sel 9
|
||||
emi_sel 10
|
||||
cpu 11
|
||||
etm_sel 12
|
||||
cpu_pll 13
|
||||
cpu_xtal 14
|
||||
hbus 15
|
||||
xbus 16
|
||||
lcdif_div 17
|
||||
ssp_div 18
|
||||
gpmi_div 19
|
||||
emi_pll 20
|
||||
emi_xtal 21
|
||||
etm_div 22
|
||||
saif_div 23
|
||||
clk32k_div 24
|
||||
rtc 25
|
||||
adc 26
|
||||
spdif_div 27
|
||||
clk32k 28
|
||||
dri 29
|
||||
pwm 30
|
||||
filt 31
|
||||
uart 32
|
||||
ssp 33
|
||||
gpmi 34
|
||||
spdif 35
|
||||
emi 36
|
||||
saif 37
|
||||
lcdif 38
|
||||
etm 39
|
||||
usb 40
|
||||
usb_pwr 41
|
||||
|
||||
Examples:
|
||||
|
||||
clks: clkctrl@80040000 {
|
||||
compatible = "fsl,imx23-clkctrl";
|
||||
reg = <0x80040000 0x2000>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names =
|
||||
...
|
||||
"uart", /* 32 */
|
||||
...
|
||||
"end_of_list";
|
||||
};
|
||||
|
||||
auart0: serial@8006c000 {
|
||||
compatible = "fsl,imx23-auart";
|
||||
reg = <0x8006c000 0x2000>;
|
||||
interrupts = <24 25 23>;
|
||||
clocks = <&clks 32>;
|
||||
status = "disabled";
|
||||
};
|
99
Documentation/devicetree/bindings/clock/imx28-clock.txt
Normal file
99
Documentation/devicetree/bindings/clock/imx28-clock.txt
Normal file
|
@ -0,0 +1,99 @@
|
|||
* Clock bindings for Freescale i.MX28
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx28-clkctrl"
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. The following is a full list of i.MX28
|
||||
clocks and IDs.
|
||||
|
||||
Clock ID
|
||||
------------------
|
||||
ref_xtal 0
|
||||
pll0 1
|
||||
pll1 2
|
||||
pll2 3
|
||||
ref_cpu 4
|
||||
ref_emi 5
|
||||
ref_io0 6
|
||||
ref_io1 7
|
||||
ref_pix 8
|
||||
ref_hsadc 9
|
||||
ref_gpmi 10
|
||||
saif0_sel 11
|
||||
saif1_sel 12
|
||||
gpmi_sel 13
|
||||
ssp0_sel 14
|
||||
ssp1_sel 15
|
||||
ssp2_sel 16
|
||||
ssp3_sel 17
|
||||
emi_sel 18
|
||||
etm_sel 19
|
||||
lcdif_sel 20
|
||||
cpu 21
|
||||
ptp_sel 22
|
||||
cpu_pll 23
|
||||
cpu_xtal 24
|
||||
hbus 25
|
||||
xbus 26
|
||||
ssp0_div 27
|
||||
ssp1_div 28
|
||||
ssp2_div 29
|
||||
ssp3_div 30
|
||||
gpmi_div 31
|
||||
emi_pll 32
|
||||
emi_xtal 33
|
||||
lcdif_div 34
|
||||
etm_div 35
|
||||
ptp 36
|
||||
saif0_div 37
|
||||
saif1_div 38
|
||||
clk32k_div 39
|
||||
rtc 40
|
||||
lradc 41
|
||||
spdif_div 42
|
||||
clk32k 43
|
||||
pwm 44
|
||||
uart 45
|
||||
ssp0 46
|
||||
ssp1 47
|
||||
ssp2 48
|
||||
ssp3 49
|
||||
gpmi 50
|
||||
spdif 51
|
||||
emi 52
|
||||
saif0 53
|
||||
saif1 54
|
||||
lcdif 55
|
||||
etm 56
|
||||
fec 57
|
||||
can0 58
|
||||
can1 59
|
||||
usb0 60
|
||||
usb1 61
|
||||
usb0_pwr 62
|
||||
usb1_pwr 63
|
||||
enet_out 64
|
||||
|
||||
Examples:
|
||||
|
||||
clks: clkctrl@80040000 {
|
||||
compatible = "fsl,imx28-clkctrl";
|
||||
reg = <0x80040000 0x2000>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names =
|
||||
...
|
||||
"uart", /* 45 */
|
||||
...
|
||||
"end_of_list";
|
||||
};
|
||||
|
||||
auart0: serial@8006a000 {
|
||||
compatible = "fsl,imx28-auart", "fsl,imx23-auart";
|
||||
reg = <0x8006a000 0x2000>;
|
||||
interrupts = <112 70 71>;
|
||||
clocks = <&clks 45>;
|
||||
status = "disabled";
|
||||
};
|
222
Documentation/devicetree/bindings/clock/imx6q-clock.txt
Normal file
222
Documentation/devicetree/bindings/clock/imx6q-clock.txt
Normal file
|
@ -0,0 +1,222 @@
|
|||
* Clock bindings for Freescale i.MX6 Quad
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx6q-ccm"
|
||||
- reg: Address and length of the register set
|
||||
- interrupts: Should contain CCM interrupt
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. The following is a full list of i.MX6Q
|
||||
clocks and IDs.
|
||||
|
||||
Clock ID
|
||||
---------------------------
|
||||
dummy 0
|
||||
ckil 1
|
||||
ckih 2
|
||||
osc 3
|
||||
pll2_pfd0_352m 4
|
||||
pll2_pfd1_594m 5
|
||||
pll2_pfd2_396m 6
|
||||
pll3_pfd0_720m 7
|
||||
pll3_pfd1_540m 8
|
||||
pll3_pfd2_508m 9
|
||||
pll3_pfd3_454m 10
|
||||
pll2_198m 11
|
||||
pll3_120m 12
|
||||
pll3_80m 13
|
||||
pll3_60m 14
|
||||
twd 15
|
||||
step 16
|
||||
pll1_sw 17
|
||||
periph_pre 18
|
||||
periph2_pre 19
|
||||
periph_clk2_sel 20
|
||||
periph2_clk2_sel 21
|
||||
axi_sel 22
|
||||
esai_sel 23
|
||||
asrc_sel 24
|
||||
spdif_sel 25
|
||||
gpu2d_axi 26
|
||||
gpu3d_axi 27
|
||||
gpu2d_core_sel 28
|
||||
gpu3d_core_sel 29
|
||||
gpu3d_shader_sel 30
|
||||
ipu1_sel 31
|
||||
ipu2_sel 32
|
||||
ldb_di0_sel 33
|
||||
ldb_di1_sel 34
|
||||
ipu1_di0_pre_sel 35
|
||||
ipu1_di1_pre_sel 36
|
||||
ipu2_di0_pre_sel 37
|
||||
ipu2_di1_pre_sel 38
|
||||
ipu1_di0_sel 39
|
||||
ipu1_di1_sel 40
|
||||
ipu2_di0_sel 41
|
||||
ipu2_di1_sel 42
|
||||
hsi_tx_sel 43
|
||||
pcie_axi_sel 44
|
||||
ssi1_sel 45
|
||||
ssi2_sel 46
|
||||
ssi3_sel 47
|
||||
usdhc1_sel 48
|
||||
usdhc2_sel 49
|
||||
usdhc3_sel 50
|
||||
usdhc4_sel 51
|
||||
enfc_sel 52
|
||||
emi_sel 53
|
||||
emi_slow_sel 54
|
||||
vdo_axi_sel 55
|
||||
vpu_axi_sel 56
|
||||
cko1_sel 57
|
||||
periph 58
|
||||
periph2 59
|
||||
periph_clk2 60
|
||||
periph2_clk2 61
|
||||
ipg 62
|
||||
ipg_per 63
|
||||
esai_pred 64
|
||||
esai_podf 65
|
||||
asrc_pred 66
|
||||
asrc_podf 67
|
||||
spdif_pred 68
|
||||
spdif_podf 69
|
||||
can_root 70
|
||||
ecspi_root 71
|
||||
gpu2d_core_podf 72
|
||||
gpu3d_core_podf 73
|
||||
gpu3d_shader 74
|
||||
ipu1_podf 75
|
||||
ipu2_podf 76
|
||||
ldb_di0_podf 77
|
||||
ldb_di1_podf 78
|
||||
ipu1_di0_pre 79
|
||||
ipu1_di1_pre 80
|
||||
ipu2_di0_pre 81
|
||||
ipu2_di1_pre 82
|
||||
hsi_tx_podf 83
|
||||
ssi1_pred 84
|
||||
ssi1_podf 85
|
||||
ssi2_pred 86
|
||||
ssi2_podf 87
|
||||
ssi3_pred 88
|
||||
ssi3_podf 89
|
||||
uart_serial_podf 90
|
||||
usdhc1_podf 91
|
||||
usdhc2_podf 92
|
||||
usdhc3_podf 93
|
||||
usdhc4_podf 94
|
||||
enfc_pred 95
|
||||
enfc_podf 96
|
||||
emi_podf 97
|
||||
emi_slow_podf 98
|
||||
vpu_axi_podf 99
|
||||
cko1_podf 100
|
||||
axi 101
|
||||
mmdc_ch0_axi_podf 102
|
||||
mmdc_ch1_axi_podf 103
|
||||
arm 104
|
||||
ahb 105
|
||||
apbh_dma 106
|
||||
asrc 107
|
||||
can1_ipg 108
|
||||
can1_serial 109
|
||||
can2_ipg 110
|
||||
can2_serial 111
|
||||
ecspi1 112
|
||||
ecspi2 113
|
||||
ecspi3 114
|
||||
ecspi4 115
|
||||
ecspi5 116
|
||||
enet 117
|
||||
esai 118
|
||||
gpt_ipg 119
|
||||
gpt_ipg_per 120
|
||||
gpu2d_core 121
|
||||
gpu3d_core 122
|
||||
hdmi_iahb 123
|
||||
hdmi_isfr 124
|
||||
i2c1 125
|
||||
i2c2 126
|
||||
i2c3 127
|
||||
iim 128
|
||||
enfc 129
|
||||
ipu1 130
|
||||
ipu1_di0 131
|
||||
ipu1_di1 132
|
||||
ipu2 133
|
||||
ipu2_di0 134
|
||||
ldb_di0 135
|
||||
ldb_di1 136
|
||||
ipu2_di1 137
|
||||
hsi_tx 138
|
||||
mlb 139
|
||||
mmdc_ch0_axi 140
|
||||
mmdc_ch1_axi 141
|
||||
ocram 142
|
||||
openvg_axi 143
|
||||
pcie_axi 144
|
||||
pwm1 145
|
||||
pwm2 146
|
||||
pwm3 147
|
||||
pwm4 148
|
||||
per1_bch 149
|
||||
gpmi_bch_apb 150
|
||||
gpmi_bch 151
|
||||
gpmi_io 152
|
||||
gpmi_apb 153
|
||||
sata 154
|
||||
sdma 155
|
||||
spba 156
|
||||
ssi1 157
|
||||
ssi2 158
|
||||
ssi3 159
|
||||
uart_ipg 160
|
||||
uart_serial 161
|
||||
usboh3 162
|
||||
usdhc1 163
|
||||
usdhc2 164
|
||||
usdhc3 165
|
||||
usdhc4 166
|
||||
vdo_axi 167
|
||||
vpu_axi 168
|
||||
cko1 169
|
||||
pll1_sys 170
|
||||
pll2_bus 171
|
||||
pll3_usb_otg 172
|
||||
pll4_audio 173
|
||||
pll5_video 174
|
||||
pll6_mlb 175
|
||||
pll7_usb_host 176
|
||||
pll8_enet 177
|
||||
ssi1_ipg 178
|
||||
ssi2_ipg 179
|
||||
ssi3_ipg 180
|
||||
rom 181
|
||||
usbphy1 182
|
||||
usbphy2 183
|
||||
ldb_di0_div_3_5 184
|
||||
ldb_di1_div_3_5 185
|
||||
|
||||
Examples:
|
||||
|
||||
clks: ccm@020c4000 {
|
||||
compatible = "fsl,imx6q-ccm";
|
||||
reg = <0x020c4000 0x4000>;
|
||||
interrupts = <0 87 0x04 0 88 0x04>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = ...
|
||||
"uart_ipg",
|
||||
"uart_serial",
|
||||
...;
|
||||
};
|
||||
|
||||
uart1: serial@02020000 {
|
||||
compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
|
||||
reg = <0x02020000 0x4000>;
|
||||
interrupts = <0 26 0x04>;
|
||||
clocks = <&clks 160>, <&clks 161>;
|
||||
clock-names = "ipg", "per";
|
||||
status = "disabled";
|
||||
};
|
72
Documentation/devicetree/bindings/clock/vt8500.txt
Normal file
72
Documentation/devicetree/bindings/clock/vt8500.txt
Normal file
|
@ -0,0 +1,72 @@
|
|||
Device Tree Clock bindings for arch-vt8500
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be one of the following:
|
||||
"via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock
|
||||
"wm,wm8650-pll-clock" - for a WM8650 PLL clock
|
||||
"via,vt8500-device-clock" - for a VT/WM device clock
|
||||
|
||||
Required properties for PLL clocks:
|
||||
- reg : shall be the control register offset from PMC base for the pll clock.
|
||||
- clocks : shall be the input parent clock phandle for the clock. This should
|
||||
be the reference clock.
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
|
||||
Required properties for device clocks:
|
||||
- clocks : shall be the input parent clock phandle for the clock. This should
|
||||
be a pll output.
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
|
||||
|
||||
Device Clocks
|
||||
|
||||
Device clocks are required to have one or both of the following sets of
|
||||
properties:
|
||||
|
||||
|
||||
Gated device clocks:
|
||||
|
||||
Required properties:
|
||||
- enable-reg : shall be the register offset from PMC base for the enable
|
||||
register.
|
||||
- enable-bit : shall be the bit within enable-reg to enable/disable the clock.
|
||||
|
||||
|
||||
Divisor device clocks:
|
||||
|
||||
Required property:
|
||||
- divisor-reg : shall be the register offset from PMC base for the divisor
|
||||
register.
|
||||
Optional property:
|
||||
- divisor-mask : shall be the mask for the divisor register. Defaults to 0x1f
|
||||
if not specified.
|
||||
|
||||
|
||||
For example:
|
||||
|
||||
ref25: ref25M {
|
||||
#clock-cells = <0>;
|
||||
compatible = "fixed-clock";
|
||||
clock-frequency = <25000000>;
|
||||
};
|
||||
|
||||
plla: plla {
|
||||
#clock-cells = <0>;
|
||||
compatible = "wm,wm8650-pll-clock";
|
||||
clocks = <&ref25>;
|
||||
reg = <0x200>;
|
||||
};
|
||||
|
||||
sdhc: sdhc {
|
||||
#clock-cells = <0>;
|
||||
compatible = "via,vt8500-device-clock";
|
||||
clocks = <&pllb>;
|
||||
divisor-reg = <0x328>;
|
||||
divisor-mask = <0x3f>;
|
||||
enable-reg = <0x254>;
|
||||
enable-bit = <18>;
|
||||
};
|
55
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
Normal file
55
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
Normal file
|
@ -0,0 +1,55 @@
|
|||
Generic CPU0 cpufreq driver
|
||||
|
||||
It is a generic cpufreq driver for CPU0 frequency management. It
|
||||
supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
|
||||
systems which share clock and voltage across all CPUs.
|
||||
|
||||
Both required and optional properties listed below must be defined
|
||||
under node /cpus/cpu@0.
|
||||
|
||||
Required properties:
|
||||
- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
|
||||
for details
|
||||
|
||||
Optional properties:
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
in unit of nanoseconds.
|
||||
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
|
||||
|
||||
Examples:
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
operating-points = <
|
||||
/* kHz uV */
|
||||
792000 1100000
|
||||
396000 950000
|
||||
198000 850000
|
||||
>;
|
||||
transition-latency = <61036>; /* two CLK32 periods */
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <1>;
|
||||
next-level-cache = <&L2>;
|
||||
};
|
||||
|
||||
cpu@2 {
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <2>;
|
||||
next-level-cache = <&L2>;
|
||||
};
|
||||
|
||||
cpu@3 {
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <3>;
|
||||
next-level-cache = <&L2>;
|
||||
};
|
||||
};
|
|
@ -9,6 +9,7 @@ Copyright (C) 2008-2011 Freescale Semiconductor Inc.
|
|||
-Run Time Integrity Check (RTIC) Node
|
||||
-Run Time Integrity Check (RTIC) Memory Node
|
||||
-Secure Non-Volatile Storage (SNVS) Node
|
||||
-Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
||||
-Full Example
|
||||
|
||||
NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
|
||||
|
@ -294,6 +295,27 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
address and length of the SEC4 configuration
|
||||
registers.
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing physical addresses in child nodes. Must
|
||||
have a value of 1.
|
||||
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing the size of physical addresses in
|
||||
child nodes. Must have a value of 1.
|
||||
|
||||
- ranges
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
range of the SNVS register space. A triplet that includes
|
||||
the child address, parent address, & length.
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
|
@ -314,10 +336,33 @@ EXAMPLE
|
|||
sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
||||
|
||||
A SNVS child node that defines SNVS LP RTC.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical
|
||||
address and length of the SNVS LP configuration registers.
|
||||
|
||||
EXAMPLE
|
||||
sec_mon_rtc_lp@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
FULL EXAMPLE
|
||||
|
||||
|
@ -390,8 +435,14 @@ FULL EXAMPLE
|
|||
sec_mon: sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
|
||||
sec_mon_rtc_lp@34 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
};
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
|
20
Documentation/devicetree/bindings/crypto/mv_cesa.txt
Normal file
20
Documentation/devicetree/bindings/crypto/mv_cesa.txt
Normal file
|
@ -0,0 +1,20 @@
|
|||
Marvell Cryptographic Engines And Security Accelerator
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "marvell,orion-crypto"
|
||||
- reg : base physical address of the engine and length of memory mapped
|
||||
region, followed by base physical address of sram and its memory
|
||||
length
|
||||
- reg-names : "regs" , "sram";
|
||||
- interrupts : interrupt number
|
||||
|
||||
Examples:
|
||||
|
||||
crypto@30000 {
|
||||
compatible = "marvell,orion-crypto";
|
||||
reg = <0x30000 0x10000>,
|
||||
<0x4000000 0x800>;
|
||||
reg-names = "regs" , "sram";
|
||||
interrupts = <22>;
|
||||
status = "okay";
|
||||
};
|
|
@ -9,6 +9,9 @@ Required properties:
|
|||
region.
|
||||
- interrupts: interrupt number to the cpu.
|
||||
|
||||
Optional properties:
|
||||
- dma-coherent : Present if dma operations are coherent
|
||||
|
||||
Example:
|
||||
|
||||
pdma0: pdma@12680000 {
|
||||
|
|
74
Documentation/devicetree/bindings/dma/mmp-dma.txt
Normal file
74
Documentation/devicetree/bindings/dma/mmp-dma.txt
Normal file
|
@ -0,0 +1,74 @@
|
|||
* MARVELL MMP DMA controller
|
||||
|
||||
Marvell Peripheral DMA Controller
|
||||
Used platfroms: pxa688, pxa910, pxa3xx, etc
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "marvell,pdma-1.0"
|
||||
- reg: Should contain DMA registers location and length.
|
||||
- interrupts: Either contain all of the per-channel DMA interrupts
|
||||
or one irq for pdma device
|
||||
- #dma-channels: Number of DMA channels supported by the controller.
|
||||
|
||||
"marvell,pdma-1.0"
|
||||
Used platfroms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
|
||||
|
||||
Examples:
|
||||
|
||||
/*
|
||||
* Each channel has specific irq
|
||||
* ICU parse out irq channel from ICU register,
|
||||
* while DMA controller may not able to distinguish the irq channel
|
||||
* Using this method, interrupt-parent is required as demuxer
|
||||
* For example, pxa688 icu register 0x128, bit 0~15 is PDMA channel irq,
|
||||
* 18~21 is ADMA irq
|
||||
*/
|
||||
pdma: dma-controller@d4000000 {
|
||||
compatible = "marvell,pdma-1.0";
|
||||
reg = <0xd4000000 0x10000>;
|
||||
interrupts = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>;
|
||||
interrupt-parent = <&intcmux32>;
|
||||
#dma-channels = <16>;
|
||||
};
|
||||
|
||||
/*
|
||||
* One irq for all channels
|
||||
* Dmaengine driver (DMA controller) distinguish irq channel via
|
||||
* parsing internal register
|
||||
*/
|
||||
pdma: dma-controller@d4000000 {
|
||||
compatible = "marvell,pdma-1.0";
|
||||
reg = <0xd4000000 0x10000>;
|
||||
interrupts = <47>;
|
||||
#dma-channels = <16>;
|
||||
};
|
||||
|
||||
|
||||
Marvell Two Channel DMA Controller used specifically for audio
|
||||
Used platfroms: pxa688, pxa910
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "marvell,adma-1.0" or "marvell,pxa910-squ"
|
||||
- reg: Should contain DMA registers location and length.
|
||||
- interrupts: Either contain all of the per-channel DMA interrupts
|
||||
or one irq for dma device
|
||||
|
||||
"marvell,adma-1.0" used on pxa688
|
||||
"marvell,pxa910-squ" used on pxa910
|
||||
|
||||
Examples:
|
||||
|
||||
/* each channel has specific irq */
|
||||
adma0: dma-controller@d42a0800 {
|
||||
compatible = "marvell,adma-1.0";
|
||||
reg = <0xd42a0800 0x100>;
|
||||
interrupts = <18 19>;
|
||||
interrupt-parent = <&intcmux32>;
|
||||
};
|
||||
|
||||
/* One irq for all channels */
|
||||
squ: dma-controller@d42a0800 {
|
||||
compatible = "marvell,pxa910-squ";
|
||||
reg = <0xd42a0800 0x100>;
|
||||
interrupts = <46>;
|
||||
};
|
22
Documentation/devicetree/bindings/gpio/gpio-74x164.txt
Normal file
22
Documentation/devicetree/bindings/gpio/gpio-74x164.txt
Normal file
|
@ -0,0 +1,22 @@
|
|||
* Generic 8-bits shift register GPIO driver
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "fairchild,74hc595"
|
||||
- reg : chip select number
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify the gpio polarity:
|
||||
0 = active high
|
||||
1 = active low
|
||||
- registers-number: Number of daisy-chained shift registers
|
||||
|
||||
Example:
|
||||
|
||||
gpio5: gpio5@0 {
|
||||
compatible = "fairchild,74hc595";
|
||||
reg = <0>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
registers-number = <4>;
|
||||
spi-max-frequency = <100000>;
|
||||
};
|
34
Documentation/devicetree/bindings/gpio/gpio-adnp.txt
Normal file
34
Documentation/devicetree/bindings/gpio/gpio-adnp.txt
Normal file
|
@ -0,0 +1,34 @@
|
|||
Avionic Design N-bit GPIO expander bindings
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "ad,gpio-adnp"
|
||||
- reg: The I2C slave address for this device.
|
||||
- interrupt-parent: phandle of the parent interrupt controller.
|
||||
- interrupts: Interrupt specifier for the controllers interrupt.
|
||||
- #gpio-cells: Should be 2. The first cell is the GPIO number and the
|
||||
second cell is used to specify optional parameters:
|
||||
- bit 0: polarity (0: normal, 1: inverted)
|
||||
- gpio-controller: Marks the device as a GPIO controller
|
||||
- nr-gpios: The number of pins supported by the controller.
|
||||
|
||||
The GPIO expander can optionally be used as an interrupt controller, in
|
||||
which case it uses the default two cell specifier as described in
|
||||
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
|
||||
|
||||
Example:
|
||||
|
||||
gpioext: gpio-controller@41 {
|
||||
compatible = "ad,gpio-adnp";
|
||||
reg = <0x41>;
|
||||
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <160 1>;
|
||||
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
nr-gpios = <64>;
|
||||
};
|
25
Documentation/devicetree/bindings/gpio/gpio-fan.txt
Normal file
25
Documentation/devicetree/bindings/gpio/gpio-fan.txt
Normal file
|
@ -0,0 +1,25 @@
|
|||
Bindings for fan connected to GPIO lines
|
||||
|
||||
Required properties:
|
||||
- compatible : "gpio-fan"
|
||||
- gpios: Specifies the pins that map to bits in the control value,
|
||||
ordered MSB-->LSB.
|
||||
- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
|
||||
control value that should be set to achieve them. This array
|
||||
must have the RPM values in ascending order.
|
||||
|
||||
Optional properties:
|
||||
- alarm-gpios: This pin going active indicates something is wrong with
|
||||
the fan, and a udev event will be fired.
|
||||
|
||||
Examples:
|
||||
|
||||
gpio_fan {
|
||||
compatible = "gpio-fan";
|
||||
gpios = <&gpio1 14 1
|
||||
&gpio1 13 1>;
|
||||
gpio-fan,speed-map = <0 0
|
||||
3000 1
|
||||
6000 2>;
|
||||
alarm-gpios = <&gpio1 15 1>;
|
||||
};
|
53
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
Normal file
53
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
Normal file
|
@ -0,0 +1,53 @@
|
|||
* Marvell EBU GPIO controller
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio"
|
||||
or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for
|
||||
Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada
|
||||
370. "marvell,mv78200-gpio" should be used for the Discovery
|
||||
MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP
|
||||
SoCs (MV78230, MV78260, MV78460).
|
||||
|
||||
- reg: Address and length of the register set for the device. Only one
|
||||
entry is expected, except for the "marvell,armadaxp-gpio" variant
|
||||
for which two entries are expected: one for the general registers,
|
||||
one for the per-cpu registers.
|
||||
|
||||
- interrupts: The list of interrupts that are used for all the pins
|
||||
managed by this GPIO bank. There can be more than one interrupt
|
||||
(example: 1 interrupt per 8 pins on Armada XP, which means 4
|
||||
interrupts per bank of 32 GPIOs).
|
||||
|
||||
- interrupt-controller: identifies the node as an interrupt controller
|
||||
|
||||
- #interrupt-cells: specifies the number of cells needed to encode an
|
||||
interrupt source. Should be two.
|
||||
The first cell is the GPIO number.
|
||||
The second cell is used to specify flags:
|
||||
bits[3:0] trigger type and level flags:
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
4 = active high level-sensitive.
|
||||
8 = active low level-sensitive.
|
||||
|
||||
- gpio-controller: marks the device node as a gpio controller
|
||||
|
||||
- ngpios: number of GPIOs this controller has
|
||||
|
||||
- #gpio-cells: Should be two. The first cell is the pin number. The
|
||||
second cell is reserved for flags, unused at the moment.
|
||||
|
||||
Example:
|
||||
|
||||
gpio0: gpio@d0018100 {
|
||||
compatible = "marvell,armadaxp-gpio";
|
||||
reg = <0xd0018100 0x40>,
|
||||
<0xd0018800 0x30>;
|
||||
ngpios = <32>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <16>, <17>, <18>, <19>;
|
||||
};
|
|
@ -39,3 +39,46 @@ Example:
|
|||
#gpio-cells = <4>;
|
||||
gpio-controller;
|
||||
};
|
||||
|
||||
|
||||
Samsung S3C24XX GPIO Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Compatible property value should be "samsung,s3c24xx-gpio".
|
||||
|
||||
- reg: Physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #gpio-cells: Should be 3. The syntax of the gpio specifier used by client nodes
|
||||
should be the following with values derived from the SoC user manual.
|
||||
<[phandle of the gpio controller node]
|
||||
[pin number within the gpio controller]
|
||||
[mux function]
|
||||
[flags and pull up/down]
|
||||
|
||||
Values for gpio specifier:
|
||||
- Pin number: depending on the controller a number from 0 up to 15.
|
||||
- Mux function: Depending on the SoC and the gpio bank the gpio can be set
|
||||
as input, output or a special function
|
||||
- Flags and Pull Up/Down: the values to use differ for the individual SoCs
|
||||
example S3C2416/S3C2450:
|
||||
0 - Pull Up/Down Disabled.
|
||||
1 - Pull Down Enabled.
|
||||
2 - Pull Up Enabled.
|
||||
Bit 16 (0x00010000) - Input is active low.
|
||||
Consult the user manual for the correct values of Mux and Pull Up/Down.
|
||||
|
||||
- gpio-controller: Specifies that the node is a gpio controller.
|
||||
- #address-cells: should be 1.
|
||||
- #size-cells: should be 1.
|
||||
|
||||
Example:
|
||||
|
||||
gpa: gpio-controller@56000000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "samsung,s3c24xx-gpio";
|
||||
reg = <0x56000000 0x10>;
|
||||
#gpio-cells = <3>;
|
||||
gpio-controller;
|
||||
};
|
||||
|
|
|
@ -11,6 +11,11 @@ Required properties:
|
|||
- interrupt-controller: Mark the device node as an interrupt controller
|
||||
The first cell is the GPIO number.
|
||||
The second cell is not used.
|
||||
- ti,use-leds : Enables LEDA and LEDB outputs if set
|
||||
- ti,debounce : if n-th bit is set, debounces GPIO-n
|
||||
- ti,mmc-cd : if n-th bit is set, GPIO-n controls VMMC(n+1)
|
||||
- ti,pullups : if n-th bit is set, set a pullup on GPIO-n
|
||||
- ti,pulldowns : if n-th bit is set, set a pulldown on GPIO-n
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -20,4 +25,5 @@ twl_gpio: gpio {
|
|||
gpio-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
ti,use-leds;
|
||||
};
|
||||
|
|
24
Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
Normal file
24
Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
Normal file
|
@ -0,0 +1,24 @@
|
|||
VIA/Wondermedia VT8500 GPIO Controller
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
|
||||
or "wm,wm8650-gpio" depending on your SoC
|
||||
- reg : Should contain 1 register range (address and length)
|
||||
- #gpio-cells : should be <3>.
|
||||
1) bank
|
||||
2) pin number
|
||||
3) flags - should be 0
|
||||
|
||||
Example:
|
||||
|
||||
gpio: gpio-controller@d8110000 {
|
||||
compatible = "via,vt8500-gpio";
|
||||
gpio-controller;
|
||||
reg = <0xd8110000 0x10000>;
|
||||
#gpio-cells = <3>;
|
||||
};
|
||||
|
||||
vibrate {
|
||||
gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
|
||||
};
|
|
@ -8,7 +8,7 @@ node's name represents the name of the corresponding LED.
|
|||
|
||||
LED sub-node properties:
|
||||
- gpios : Should specify the LED's GPIO, see "gpios property" in
|
||||
Documentation/devicetree/gpio.txt. Active low LEDs should be
|
||||
Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be
|
||||
indicated using flags in the GPIO specifier.
|
||||
- label : (optional) The label for this LED. If omitted, the label is
|
||||
taken from the node name (excluding the unit address).
|
||||
|
|
30
Documentation/devicetree/bindings/i2c/atmel-i2c.txt
Normal file
30
Documentation/devicetree/bindings/i2c/atmel-i2c.txt
Normal file
|
@ -0,0 +1,30 @@
|
|||
I2C for Atmel platforms
|
||||
|
||||
Required properties :
|
||||
- compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c",
|
||||
"atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c"
|
||||
or "atmel,at91sam9x5-i2c"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: interrupt number to the cpu.
|
||||
- #address-cells = <1>;
|
||||
- #size-cells = <0>;
|
||||
|
||||
Optional properties:
|
||||
- Child nodes conforming to i2c bus binding
|
||||
|
||||
Examples :
|
||||
|
||||
i2c0: i2c@fff84000 {
|
||||
compatible = "atmel,at91sam9g20-i2c";
|
||||
reg = <0xfff84000 0x100>;
|
||||
interrupts = <12 4 6>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
24c512@50 {
|
||||
compatible = "24c512";
|
||||
reg = <0x50>;
|
||||
pagesize = <128>;
|
||||
}
|
||||
}
|
28
Documentation/devicetree/bindings/i2c/davinci.txt
Normal file
28
Documentation/devicetree/bindings/i2c/davinci.txt
Normal file
|
@ -0,0 +1,28 @@
|
|||
* Texas Instruments Davinci I2C
|
||||
|
||||
This file provides information, what the device node for the
|
||||
davinci i2c interface contain.
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,davinci-i2c";
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
Recommended properties :
|
||||
- interrupts : standard interrupt property.
|
||||
- clock-frequency : desired I2C bus clock frequency in Hz.
|
||||
|
||||
Example (enbw_cmc board):
|
||||
i2c@1c22000 {
|
||||
compatible = "ti,davinci-i2c";
|
||||
reg = <0x22000 0x1000>;
|
||||
clock-frequency = <100000>;
|
||||
interrupts = <15>;
|
||||
interrupt-parent = <&intc>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
dtt@48 {
|
||||
compatible = "national,lm75";
|
||||
reg = <0x48>;
|
||||
};
|
||||
};
|
|
@ -6,6 +6,7 @@ Required properties:
|
|||
- interrupts: Should contain ERROR and DMA interrupts
|
||||
- clock-frequency: Desired I2C bus clock frequency in Hz.
|
||||
Only 100000Hz and 400000Hz modes are supported.
|
||||
- fsl,i2c-dma-channel: APBX DMA channel for the I2C
|
||||
|
||||
Examples:
|
||||
|
||||
|
@ -16,4 +17,5 @@ i2c0: i2c@80058000 {
|
|||
reg = <0x80058000 2000>;
|
||||
interrupts = <111 68>;
|
||||
clock-frequency = <100000>;
|
||||
fsl,i2c-dma-channel = <6>;
|
||||
};
|
||||
|
|
23
Documentation/devicetree/bindings/i2c/nomadik.txt
Normal file
23
Documentation/devicetree/bindings/i2c/nomadik.txt
Normal file
|
@ -0,0 +1,23 @@
|
|||
I2C for Nomadik based systems
|
||||
|
||||
Required (non-standard) properties:
|
||||
- Nil
|
||||
|
||||
Recommended (non-standard) properties:
|
||||
- clock-frequency : Maximum bus clock frequency for the device
|
||||
|
||||
Optional (non-standard) properties:
|
||||
- Nil
|
||||
|
||||
Example :
|
||||
|
||||
i2c@80004000 {
|
||||
compatible = "stericsson,db8500-i2c", "st,nomadik-i2c";
|
||||
reg = <0x80004000 0x1000>;
|
||||
interrupts = <0 21 0x4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
v-i2c-supply = <&db8500_vape_reg>;
|
||||
|
||||
clock-frequency = <400000>;
|
||||
};
|
|
@ -56,3 +56,4 @@ stm,m41t00 Serial Access TIMEKEEPER
|
|||
stm,m41t62 Serial real-time clock (RTC) with alarm
|
||||
stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
|
||||
ti,tsc2003 I2C Touch-Screen Controller
|
||||
ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
|
||||
|
|
38
Documentation/devicetree/bindings/input/gpio-keys-polled.txt
Normal file
38
Documentation/devicetree/bindings/input/gpio-keys-polled.txt
Normal file
|
@ -0,0 +1,38 @@
|
|||
Device-Tree bindings for input/gpio_keys_polled.c keyboard driver
|
||||
|
||||
Required properties:
|
||||
- compatible = "gpio-keys-polled";
|
||||
- poll-interval: Poll interval time in milliseconds
|
||||
|
||||
Optional properties:
|
||||
- autorepeat: Boolean, Enable auto repeat feature of Linux input
|
||||
subsystem.
|
||||
|
||||
Each button (key) is represented as a sub-node of "gpio-keys-polled":
|
||||
Subnode properties:
|
||||
|
||||
- gpios: OF device-tree gpio specification.
|
||||
- label: Descriptive name of the key.
|
||||
- linux,code: Keycode to emit.
|
||||
|
||||
Optional subnode-properties:
|
||||
- linux,input-type: Specify event type this button/key generates.
|
||||
If not specified defaults to <1> == EV_KEY.
|
||||
- debounce-interval: Debouncing interval time in milliseconds.
|
||||
If not specified defaults to 5.
|
||||
- gpio-key,wakeup: Boolean, button can wake-up the system.
|
||||
|
||||
Example nodes:
|
||||
|
||||
gpio_keys_polled {
|
||||
compatible = "gpio-keys-polled";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
poll-interval = <100>;
|
||||
autorepeat;
|
||||
button@21 {
|
||||
label = "GPIO Key UP";
|
||||
linux,code = <103>;
|
||||
gpios = <&gpio1 0 1>;
|
||||
};
|
||||
...
|
36
Documentation/devicetree/bindings/input/rotary-encoder.txt
Normal file
36
Documentation/devicetree/bindings/input/rotary-encoder.txt
Normal file
|
@ -0,0 +1,36 @@
|
|||
Rotary encoder DT bindings
|
||||
|
||||
Required properties:
|
||||
- gpios: a spec for two GPIOs to be used
|
||||
|
||||
Optional properties:
|
||||
- linux,axis: the input subsystem axis to map to this rotary encoder.
|
||||
Defaults to 0 (ABS_X / REL_X)
|
||||
- rotary-encoder,steps: Number of steps in a full turnaround of the
|
||||
encoder. Only relevant for absolute axis. Defaults to 24 which is a
|
||||
typical value for such devices.
|
||||
- rotary-encoder,relative-axis: register a relative axis rather than an
|
||||
absolute one. Relative axis will only generate +1/-1 events on the input
|
||||
device, hence no steps need to be passed.
|
||||
- rotary-encoder,rollover: Automatic rollove when the rotary value becomes
|
||||
greater than the specified steps or smaller than 0. For absolute axis only.
|
||||
- rotary-encoder,half-period: Makes the driver work on half-period mode.
|
||||
|
||||
See Documentation/input/rotary-encoder.txt for more information.
|
||||
|
||||
Example:
|
||||
|
||||
rotary@0 {
|
||||
compatible = "rotary-encoder";
|
||||
gpios = <&gpio 19 1>, <&gpio 20 0>; /* GPIO19 is inverted */
|
||||
linux,axis = <0>; /* REL_X */
|
||||
rotary-encoder,relative-axis;
|
||||
};
|
||||
|
||||
rotary@1 {
|
||||
compatible = "rotary-encoder";
|
||||
gpios = <&gpio 21 0>, <&gpio 22 0>;
|
||||
linux,axis = <1>; /* ABS_Y */
|
||||
rotary-encoder,steps = <24>;
|
||||
rotary-encoder,rollover;
|
||||
};
|
|
@ -0,0 +1,110 @@
|
|||
BCM2835 Top-Level ("ARMCTRL") Interrupt Controller
|
||||
|
||||
The BCM2835 contains a custom top-level interrupt controller, which supports
|
||||
72 interrupt sources using a 2-level register scheme. The interrupt
|
||||
controller, or the HW block containing it, is referred to occasionally
|
||||
as "armctrl" in the SoC documentation, hence naming of this binding.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "brcm,bcm2835-armctrl-ic"
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The value shall be 2.
|
||||
|
||||
The 1st cell is the interrupt bank; 0 for interrupts in the "IRQ basic
|
||||
pending" register, or 1/2 respectively for interrupts in the "IRQ pending
|
||||
1/2" register.
|
||||
|
||||
The 2nd cell contains the interrupt number within the bank. Valid values
|
||||
are 0..7 for bank 0, and 0..31 for bank 1.
|
||||
|
||||
The interrupt sources are as follows:
|
||||
|
||||
Bank 0:
|
||||
0: ARM_TIMER
|
||||
1: ARM_MAILBOX
|
||||
2: ARM_DOORBELL_0
|
||||
3: ARM_DOORBELL_1
|
||||
4: VPU0_HALTED
|
||||
5: VPU1_HALTED
|
||||
6: ILLEGAL_TYPE0
|
||||
7: ILLEGAL_TYPE1
|
||||
|
||||
Bank 1:
|
||||
0: TIMER0
|
||||
1: TIMER1
|
||||
2: TIMER2
|
||||
3: TIMER3
|
||||
4: CODEC0
|
||||
5: CODEC1
|
||||
6: CODEC2
|
||||
7: VC_JPEG
|
||||
8: ISP
|
||||
9: VC_USB
|
||||
10: VC_3D
|
||||
11: TRANSPOSER
|
||||
12: MULTICORESYNC0
|
||||
13: MULTICORESYNC1
|
||||
14: MULTICORESYNC2
|
||||
15: MULTICORESYNC3
|
||||
16: DMA0
|
||||
17: DMA1
|
||||
18: VC_DMA2
|
||||
19: VC_DMA3
|
||||
20: DMA4
|
||||
21: DMA5
|
||||
22: DMA6
|
||||
23: DMA7
|
||||
24: DMA8
|
||||
25: DMA9
|
||||
26: DMA10
|
||||
27: DMA11
|
||||
28: DMA12
|
||||
29: AUX
|
||||
30: ARM
|
||||
31: VPUDMA
|
||||
|
||||
Bank 2:
|
||||
0: HOSTPORT
|
||||
1: VIDEOSCALER
|
||||
2: CCP2TX
|
||||
3: SDC
|
||||
4: DSI0
|
||||
5: AVE
|
||||
6: CAM0
|
||||
7: CAM1
|
||||
8: HDMI0
|
||||
9: HDMI1
|
||||
10: PIXELVALVE1
|
||||
11: I2CSPISLV
|
||||
12: DSI1
|
||||
13: PWA0
|
||||
14: PWA1
|
||||
15: CPR
|
||||
16: SMI
|
||||
17: GPIO0
|
||||
18: GPIO1
|
||||
19: GPIO2
|
||||
20: GPIO3
|
||||
21: VC_I2C
|
||||
22: VC_SPI
|
||||
23: VC_I2SPCM
|
||||
24: VC_SDIO
|
||||
25: VC_UART
|
||||
26: SLIMBUS
|
||||
27: VEC
|
||||
28: CPG
|
||||
29: RNG
|
||||
30: VC_ARASANSDIO
|
||||
31: AVSPMON
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller {
|
||||
compatible = "brcm,bcm2835-armctrl-ic";
|
||||
reg = <0x7e00b200 0x200>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
|
@ -0,0 +1,95 @@
|
|||
Specifying interrupt information for devices
|
||||
============================================
|
||||
|
||||
1) Interrupt client nodes
|
||||
-------------------------
|
||||
|
||||
Nodes that describe devices which generate interrupts must contain an
|
||||
"interrupts" property. This property must contain a list of interrupt
|
||||
specifiers, one per output interrupt. The format of the interrupt specifier is
|
||||
determined by the interrupt controller to which the interrupts are routed; see
|
||||
section 2 below for details.
|
||||
|
||||
The "interrupt-parent" property is used to specify the controller to which
|
||||
interrupts are routed and contains a single phandle referring to the interrupt
|
||||
controller node. This property is inherited, so it may be specified in an
|
||||
interrupt client node or in any of its parent nodes.
|
||||
|
||||
2) Interrupt controller nodes
|
||||
-----------------------------
|
||||
|
||||
A device is marked as an interrupt controller with the "interrupt-controller"
|
||||
property. This is a empty, boolean property. An additional "#interrupt-cells"
|
||||
property defines the number of cells needed to specify a single interrupt.
|
||||
|
||||
It is the responsibility of the interrupt controller's binding to define the
|
||||
length and format of the interrupt specifier. The following two variants are
|
||||
commonly used:
|
||||
|
||||
a) one cell
|
||||
-----------
|
||||
The #interrupt-cells property is set to 1 and the single cell defines the
|
||||
index of the interrupt within the controller.
|
||||
|
||||
Example:
|
||||
|
||||
vic: intc@10140000 {
|
||||
compatible = "arm,versatile-vic";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x10140000 0x1000>;
|
||||
};
|
||||
|
||||
sic: intc@10003000 {
|
||||
compatible = "arm,versatile-sic";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x10003000 0x1000>;
|
||||
interrupt-parent = <&vic>;
|
||||
interrupts = <31>; /* Cascaded to vic */
|
||||
};
|
||||
|
||||
b) two cells
|
||||
------------
|
||||
The #interrupt-cells property is set to 2 and the first cell defines the
|
||||
index of the interrupt within the controller, while the second cell is used
|
||||
to specify any of the following flags:
|
||||
- bits[3:0] trigger type and level flags
|
||||
1 = low-to-high edge triggered
|
||||
2 = high-to-low edge triggered
|
||||
4 = active high level-sensitive
|
||||
8 = active low level-sensitive
|
||||
|
||||
Example:
|
||||
|
||||
i2c@7000c000 {
|
||||
gpioext: gpio-adnp@41 {
|
||||
compatible = "ad,gpio-adnp";
|
||||
reg = <0x41>;
|
||||
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <160 1>;
|
||||
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
nr-gpios = <64>;
|
||||
};
|
||||
|
||||
sx8634@2b {
|
||||
compatible = "smtc,sx8634";
|
||||
reg = <0x2b>;
|
||||
|
||||
interrupt-parent = <&gpioext>;
|
||||
interrupts = <3 0x8>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
threshold = <0x40>;
|
||||
sensitivity = <7>;
|
||||
};
|
||||
};
|
52
Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
Normal file
52
Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
Normal file
|
@ -0,0 +1,52 @@
|
|||
* AC timing parameters of LPDDR2(JESD209-2) memories for a given speed-bin
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "jedec,lpddr2-timings"
|
||||
- min-freq : minimum DDR clock frequency for the speed-bin. Type is <u32>
|
||||
- max-freq : maximum DDR clock frequency for the speed-bin. Type is <u32>
|
||||
|
||||
Optional properties:
|
||||
|
||||
The following properties represent AC timing parameters from the memory
|
||||
data-sheet of the device for a given speed-bin. All these properties are
|
||||
of type <u32> and the default unit is ps (pico seconds). Parameters with
|
||||
a different unit have a suffix indicating the unit such as 'tRAS-max-ns'
|
||||
- tRCD
|
||||
- tWR
|
||||
- tRAS-min
|
||||
- tRRD
|
||||
- tWTR
|
||||
- tXP
|
||||
- tRTP
|
||||
- tDQSCK-max
|
||||
- tFAW
|
||||
- tZQCS
|
||||
- tZQinit
|
||||
- tRPab
|
||||
- tZQCL
|
||||
- tCKESR
|
||||
- tRAS-max-ns
|
||||
- tDQSCK-max-derated
|
||||
|
||||
Example:
|
||||
|
||||
timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
|
||||
compatible = "jedec,lpddr2-timings";
|
||||
min-freq = <10000000>;
|
||||
max-freq = <400000000>;
|
||||
tRPab = <21000>;
|
||||
tRCD = <18000>;
|
||||
tWR = <15000>;
|
||||
tRAS-min = <42000>;
|
||||
tRRD = <10000>;
|
||||
tWTR = <7500>;
|
||||
tXP = <7500>;
|
||||
tRTP = <7500>;
|
||||
tCKESR = <15000>;
|
||||
tDQSCK-max = <5500>;
|
||||
tFAW = <50000>;
|
||||
tZQCS = <90000>;
|
||||
tZQCL = <360000>;
|
||||
tZQinit = <1000000>;
|
||||
tRAS-max-ns = <70000>;
|
||||
};
|
102
Documentation/devicetree/bindings/lpddr2/lpddr2.txt
Normal file
102
Documentation/devicetree/bindings/lpddr2/lpddr2.txt
Normal file
|
@ -0,0 +1,102 @@
|
|||
* LPDDR2 SDRAM memories compliant to JEDEC JESD209-2
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be one of - "jedec,lpddr2-nvm", "jedec,lpddr2-s2",
|
||||
"jedec,lpddr2-s4"
|
||||
|
||||
"ti,jedec-lpddr2-s2" should be listed if the memory part is LPDDR2-S2 type
|
||||
|
||||
"ti,jedec-lpddr2-s4" should be listed if the memory part is LPDDR2-S4 type
|
||||
|
||||
"ti,jedec-lpddr2-nvm" should be listed if the memory part is LPDDR2-NVM type
|
||||
|
||||
- density : <u32> representing density in Mb (Mega bits)
|
||||
|
||||
- io-width : <u32> representing bus width. Possible values are 8, 16, and 32
|
||||
|
||||
Optional properties:
|
||||
|
||||
The following optional properties represent the minimum value of some AC
|
||||
timing parameters of the DDR device in terms of number of clock cycles.
|
||||
These values shall be obtained from the device data-sheet.
|
||||
- tRRD-min-tck
|
||||
- tWTR-min-tck
|
||||
- tXP-min-tck
|
||||
- tRTP-min-tck
|
||||
- tCKE-min-tck
|
||||
- tRPab-min-tck
|
||||
- tRCD-min-tck
|
||||
- tWR-min-tck
|
||||
- tRASmin-min-tck
|
||||
- tCKESR-min-tck
|
||||
- tFAW-min-tck
|
||||
|
||||
Child nodes:
|
||||
- The lpddr2 node may have one or more child nodes of type "lpddr2-timings".
|
||||
"lpddr2-timings" provides AC timing parameters of the device for
|
||||
a given speed-bin. The user may provide the timings for as many
|
||||
speed-bins as is required. Please see Documentation/devicetree/
|
||||
bindings/lpddr2/lpddr2-timings.txt for more information on "lpddr2-timings"
|
||||
|
||||
Example:
|
||||
|
||||
elpida_ECB240ABACN : lpddr2 {
|
||||
compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4";
|
||||
density = <2048>;
|
||||
io-width = <32>;
|
||||
|
||||
tRPab-min-tck = <3>;
|
||||
tRCD-min-tck = <3>;
|
||||
tWR-min-tck = <3>;
|
||||
tRASmin-min-tck = <3>;
|
||||
tRRD-min-tck = <2>;
|
||||
tWTR-min-tck = <2>;
|
||||
tXP-min-tck = <2>;
|
||||
tRTP-min-tck = <2>;
|
||||
tCKE-min-tck = <3>;
|
||||
tCKESR-min-tck = <3>;
|
||||
tFAW-min-tck = <8>;
|
||||
|
||||
timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
|
||||
compatible = "jedec,lpddr2-timings";
|
||||
min-freq = <10000000>;
|
||||
max-freq = <400000000>;
|
||||
tRPab = <21000>;
|
||||
tRCD = <18000>;
|
||||
tWR = <15000>;
|
||||
tRAS-min = <42000>;
|
||||
tRRD = <10000>;
|
||||
tWTR = <7500>;
|
||||
tXP = <7500>;
|
||||
tRTP = <7500>;
|
||||
tCKESR = <15000>;
|
||||
tDQSCK-max = <5500>;
|
||||
tFAW = <50000>;
|
||||
tZQCS = <90000>;
|
||||
tZQCL = <360000>;
|
||||
tZQinit = <1000000>;
|
||||
tRAS-max-ns = <70000>;
|
||||
};
|
||||
|
||||
timings_elpida_ECB240ABACN_200mhz: lpddr2-timings@1 {
|
||||
compatible = "jedec,lpddr2-timings";
|
||||
min-freq = <10000000>;
|
||||
max-freq = <200000000>;
|
||||
tRPab = <21000>;
|
||||
tRCD = <18000>;
|
||||
tWR = <15000>;
|
||||
tRAS-min = <42000>;
|
||||
tRRD = <10000>;
|
||||
tWTR = <10000>;
|
||||
tXP = <7500>;
|
||||
tRTP = <7500>;
|
||||
tCKESR = <15000>;
|
||||
tDQSCK-max = <5500>;
|
||||
tFAW = <50000>;
|
||||
tZQCS = <90000>;
|
||||
tZQCL = <360000>;
|
||||
tZQinit = <1000000>;
|
||||
tRAS-max-ns = <70000>;
|
||||
};
|
||||
|
||||
}
|
30
Documentation/devicetree/bindings/media/exynos5-gsc.txt
Normal file
30
Documentation/devicetree/bindings/media/exynos5-gsc.txt
Normal file
|
@ -0,0 +1,30 @@
|
|||
* Samsung Exynos5 G-Scaler device
|
||||
|
||||
G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "samsung,exynos5-gsc"
|
||||
- reg: should contain G-Scaler physical address location and length.
|
||||
- interrupts: should contain G-Scaler interrupt number
|
||||
|
||||
Example:
|
||||
|
||||
gsc_0: gsc@0x13e00000 {
|
||||
compatible = "samsung,exynos5-gsc";
|
||||
reg = <0x13e00000 0x1000>;
|
||||
interrupts = <0 85 0>;
|
||||
};
|
||||
|
||||
Aliases:
|
||||
Each G-Scaler node should have a numbered alias in the aliases node,
|
||||
in the form of gscN, N = 0...3. G-Scaler driver uses these aliases
|
||||
to retrieve the device IDs using "of_alias_get_id()" call.
|
||||
|
||||
Example:
|
||||
|
||||
aliases {
|
||||
gsc0 =&gsc_0;
|
||||
gsc1 =&gsc_1;
|
||||
gsc2 =&gsc_2;
|
||||
gsc3 =&gsc_3;
|
||||
};
|
|
@ -0,0 +1,55 @@
|
|||
* EMIF family of TI SDRAM controllers
|
||||
|
||||
EMIF - External Memory Interface - is an SDRAM controller used in
|
||||
TI SoCs. EMIF supports, based on the IP revision, one or more of
|
||||
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
|
||||
of the EMIF IP and memory parts attached to it.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be of the form "ti,emif-<ip-rev>" where <ip-rev>
|
||||
is the IP revision of the specific EMIF instance.
|
||||
|
||||
- phy-type : <u32> indicating the DDR phy type. Following are the
|
||||
allowed values
|
||||
<1> : Attila PHY
|
||||
<2> : Intelli PHY
|
||||
|
||||
- device-handle : phandle to a "lpddr2" node representing the memory part
|
||||
|
||||
- ti,hwmods : For TI hwmods processing and omap device creation
|
||||
the value shall be "emif<n>" where <n> is the number of the EMIF
|
||||
instance with base 1.
|
||||
|
||||
Optional properties:
|
||||
- cs1-used : Have this property if CS1 of this EMIF
|
||||
instance has a memory part attached to it. If there is a memory
|
||||
part attached to CS1, it should be the same type as the one on CS0,
|
||||
so there is no need to give the details of this memory part.
|
||||
|
||||
- cal-resistor-per-cs : Have this property if the board has one
|
||||
calibration resistor per chip-select.
|
||||
|
||||
- hw-caps-read-idle-ctrl: Have this property if the controller
|
||||
supports read idle window programming
|
||||
|
||||
- hw-caps-dll-calib-ctrl: Have this property if the controller
|
||||
supports dll calibration control
|
||||
|
||||
- hw-caps-ll-interface : Have this property if the controller
|
||||
has a low latency interface and corresponding interrupt events
|
||||
|
||||
- hw-caps-temp-alert : Have this property if the controller
|
||||
has capability for generating SDRAM temperature alerts
|
||||
|
||||
Example:
|
||||
|
||||
emif1: emif@0x4c000000 {
|
||||
compatible = "ti,emif-4d";
|
||||
ti,hwmods = "emif2";
|
||||
phy-type = <1>;
|
||||
device-handle = <&elpida_ECB240ABACN>;
|
||||
cs1-used;
|
||||
hw-caps-read-idle-ctrl;
|
||||
hw-caps-ll-interface;
|
||||
hw-caps-temp-alert;
|
||||
};
|
85
Documentation/devicetree/bindings/mfd/88pm860x.txt
Normal file
85
Documentation/devicetree/bindings/mfd/88pm860x.txt
Normal file
|
@ -0,0 +1,85 @@
|
|||
* Marvell 88PM860x Power Management IC
|
||||
|
||||
Required parent device properties:
|
||||
- compatible : "marvell,88pm860x"
|
||||
- reg : the I2C slave address for the 88pm860x chip
|
||||
- interrupts : IRQ line for the 88pm860x chip
|
||||
- interrupt-controller: describes the 88pm860x as an interrupt controller (has its own domain)
|
||||
- #interrupt-cells : should be 1.
|
||||
- The cell is the 88pm860x local IRQ number
|
||||
|
||||
Optional parent device properties:
|
||||
- marvell,88pm860x-irq-read-clr: inicates whether interrupt status is cleared by read
|
||||
- marvell,88pm860x-slave-addr: 88pm860x are two chips solution. <reg> stores the I2C address
|
||||
of one chip, and this property stores the I2C address of
|
||||
another chip.
|
||||
|
||||
88pm860x consists of a large and varied group of sub-devices:
|
||||
|
||||
Device Supply Names Description
|
||||
------ ------------ -----------
|
||||
88pm860x-onkey : : On key
|
||||
88pm860x-rtc : : RTC
|
||||
88pm8607 : : Regulators
|
||||
88pm860x-backlight : : Backlight
|
||||
88pm860x-led : : Led
|
||||
88pm860x-touch : : Touchscreen
|
||||
|
||||
Example:
|
||||
|
||||
pmic: 88pm860x@34 {
|
||||
compatible = "marvell,88pm860x";
|
||||
reg = <0x34>;
|
||||
interrupts = <4>;
|
||||
interrupt-parent = <&intc>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
marvell,88pm860x-irq-read-clr;
|
||||
marvell,88pm860x-slave-addr = <0x11>;
|
||||
|
||||
regulators {
|
||||
BUCK1 {
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <1500000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
LDO1 {
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <2800000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
};
|
||||
rtc {
|
||||
marvell,88pm860x-vrtc = <1>;
|
||||
};
|
||||
touch {
|
||||
marvell,88pm860x-gpadc-prebias = <1>;
|
||||
marvell,88pm860x-gpadc-slot-cycle = <1>;
|
||||
marvell,88pm860x-tsi-prebias = <6>;
|
||||
marvell,88pm860x-pen-prebias = <16>;
|
||||
marvell,88pm860x-pen-prechg = <2>;
|
||||
marvell,88pm860x-resistor-X = <300>;
|
||||
};
|
||||
backlights {
|
||||
backlight-0 {
|
||||
marvell,88pm860x-iset = <4>;
|
||||
marvell,88pm860x-pwm = <3>;
|
||||
};
|
||||
backlight-2 {
|
||||
};
|
||||
};
|
||||
leds {
|
||||
led0-red {
|
||||
marvell,88pm860x-iset = <12>;
|
||||
};
|
||||
led0-green {
|
||||
marvell,88pm860x-iset = <12>;
|
||||
};
|
||||
led0-blue {
|
||||
marvell,88pm860x-iset = <12>;
|
||||
};
|
||||
};
|
||||
};
|
|
@ -23,6 +23,7 @@ Device IRQ Names Supply Names Description
|
|||
ab8500-bm : : : Battery Manager
|
||||
ab8500-btemp : : : Battery Temperature
|
||||
ab8500-charger : : : Battery Charger
|
||||
ab8500-codec : : : Audio Codec
|
||||
ab8500-fg : : : Fuel Gauge
|
||||
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter
|
||||
SW_CONV_END : :
|
||||
|
@ -52,6 +53,14 @@ Optional child device properties:
|
|||
supplied in the interrupts property
|
||||
- <supply_name>-supply : contains a phandle to the regulator supply node in Device Tree
|
||||
|
||||
Non-standard child device properties:
|
||||
- Audio CODEC:
|
||||
- stericsson,amic[1|2]-type-single-ended : Single-ended Analoge Mic (default: differential)
|
||||
- stericsson,amic1a-bias-vamic2 : Analoge Mic wishes to use a non-standard Vamic
|
||||
- stericsson,amic1b-bias-vamic2 : Analoge Mic wishes to use a non-standard Vamic
|
||||
- stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic
|
||||
- stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)
|
||||
|
||||
ab8500@5 {
|
||||
compatible = "stericsson,ab8500";
|
||||
reg = <5>; /* mailbox 5 is i2c */
|
||||
|
@ -110,6 +119,12 @@ ab8500@5 {
|
|||
compatible = "stericsson,ab8500-pwm";
|
||||
};
|
||||
|
||||
codec: ab8500-codec {
|
||||
compatible = "stericsson,ab8500-codec";
|
||||
|
||||
stericsson,earpeice-cmv = <950>; /* Units in mV. */
|
||||
};
|
||||
|
||||
ab8500-regulators {
|
||||
compatible = "stericsson,ab8500-regulator";
|
||||
|
||||
|
|
20
Documentation/devicetree/bindings/mfd/syscon.txt
Normal file
20
Documentation/devicetree/bindings/mfd/syscon.txt
Normal file
|
@ -0,0 +1,20 @@
|
|||
* System Controller Registers R/W driver
|
||||
|
||||
System controller node represents a register region containing a set
|
||||
of miscellaneous registers. The registers are not cohesive enough to
|
||||
represent as any specific type of device. The typical use-case is for
|
||||
some other node's driver, or platform-specific code, to acquire a
|
||||
reference to the syscon node (e.g. by phandle, node path, or search
|
||||
using a specific compatible value), interrogate the node (or associated
|
||||
OS driver) to determine the location of the registers, and access the
|
||||
registers directly.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain "syscon".
|
||||
- reg: the register region can be accessed from syscon
|
||||
|
||||
Examples:
|
||||
gpr: iomuxc-gpr@020e0000 {
|
||||
compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
|
||||
reg = <0x020e0000 0x38>;
|
||||
};
|
|
@ -59,6 +59,8 @@ Optional properties:
|
|||
in TPS6591X datasheet)
|
||||
- ti,en-gpio-sleep: enable sleep control for gpios
|
||||
There should be 9 entries here, one for each gpio.
|
||||
- ti,system-power-controller: Telling whether or not this pmic is controlling
|
||||
the system power.
|
||||
|
||||
Regulator Optional properties:
|
||||
- ti,regulator-ext-sleep-control: enable external sleep
|
||||
|
@ -79,6 +81,8 @@ Example:
|
|||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
|
||||
ti,system-power-controller;
|
||||
|
||||
ti,vmbch-threshold = 0;
|
||||
ti,vmbch2-threshold = 0;
|
||||
ti,en-ck32k-xtal;
|
||||
|
|
46
Documentation/devicetree/bindings/mfd/twl4030-audio.txt
Normal file
46
Documentation/devicetree/bindings/mfd/twl4030-audio.txt
Normal file
|
@ -0,0 +1,46 @@
|
|||
Texas Instruments TWL family (twl4030) audio module
|
||||
|
||||
The audio module inside the TWL family consist of an audio codec and a vibra
|
||||
driver.
|
||||
|
||||
Required properties:
|
||||
- compatible : must be "ti,twl4030-audio"
|
||||
|
||||
Optional properties, nodes:
|
||||
|
||||
Audio functionality:
|
||||
- codec { }: Need to be present if the audio functionality is used. Within this
|
||||
section the following options can be used:
|
||||
- ti,digimic_delay: Delay need after enabling the digimic to reduce artifacts
|
||||
from the start of the recorded sample (in ms)
|
||||
-ti,ramp_delay_value: HS ramp delay configuration to reduce pop noise
|
||||
-ti,hs_extmute: Use external mute for HS pop reduction
|
||||
-ti,hs_extmute_gpio: Use external GPIO to control the external mute
|
||||
-ti,offset_cncl_path: Offset cancellation path selection, refer to TRM for the
|
||||
valid values.
|
||||
|
||||
Vibra functionality
|
||||
- ti,enable-vibra: Need to be set to <1> if the vibra functionality is used. if
|
||||
missing or it is 0, the vibra functionality is disabled.
|
||||
|
||||
Example:
|
||||
&i2c1 {
|
||||
clock-frequency = <2600000>;
|
||||
|
||||
twl: twl@48 {
|
||||
reg = <0x48>;
|
||||
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
|
||||
interrupt-parent = <&intc>;
|
||||
|
||||
twl_audio: audio {
|
||||
compatible = "ti,twl4030-audio";
|
||||
|
||||
ti,enable-vibra = <1>;
|
||||
|
||||
codec {
|
||||
ti,ramp_delay_value = <3>;
|
||||
};
|
||||
|
||||
};
|
||||
};
|
||||
};
|
|
@ -1,7 +1,7 @@
|
|||
Texas Instruments TWL6040 family
|
||||
|
||||
The TWL6040s are 8-channel high quality low-power audio codecs providing audio
|
||||
and vibra functionality on OMAP4+ platforms.
|
||||
The TWL6040s are 8-channel high quality low-power audio codecs providing audio,
|
||||
vibra and GPO functionality on OMAP4+ platforms.
|
||||
They are connected ot the host processor via i2c for commands, McPDM for audio
|
||||
data and commands.
|
||||
|
||||
|
@ -10,6 +10,8 @@ Required properties:
|
|||
- reg: must be 0x4b for i2c address
|
||||
- interrupts: twl6040 has one interrupt line connecteded to the main SoC
|
||||
- interrupt-parent: The parent interrupt controller
|
||||
- gpio-controller:
|
||||
- #gpio-cells = <1>: twl6040 provides GPO lines.
|
||||
- twl6040,audpwron-gpio: Power on GPIO line for the twl6040
|
||||
|
||||
- vio-supply: Regulator for the twl6040 VIO supply
|
||||
|
@ -37,7 +39,6 @@ Example:
|
|||
&i2c1 {
|
||||
twl6040: twl@4b {
|
||||
compatible = "ti,twl6040";
|
||||
reg = <0x4b>;
|
||||
|
||||
interrupts = <0 119 4>;
|
||||
interrupt-parent = <&gic>;
|
||||
|
@ -60,3 +61,5 @@ Example:
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
/include/ "twl6040.dtsi"
|
||||
|
|
|
@ -1,21 +1,35 @@
|
|||
Atmel AT25 eeprom
|
||||
EEPROMs (SPI) compatible with Atmel at25.
|
||||
|
||||
Required properties:
|
||||
- compatible : "atmel,at25".
|
||||
- reg : chip select number
|
||||
- spi-max-frequency : max spi frequency to use
|
||||
- pagesize : size of the eeprom page
|
||||
- size : total eeprom size in bytes
|
||||
- address-width : number of address bits (one of 8, 16, or 24)
|
||||
|
||||
Optional properties:
|
||||
- spi-cpha : SPI shifted clock phase, as per spi-bus bindings.
|
||||
- spi-cpol : SPI inverse clock polarity, as per spi-bus bindings.
|
||||
- read-only : this parameter-less property disables writes to the eeprom
|
||||
|
||||
Obsolete legacy properties are can be used in place of "size", "pagesize",
|
||||
"address-width", and "read-only":
|
||||
- at25,byte-len : total eeprom size in bytes
|
||||
- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h
|
||||
- at25,page-size : size of the eeprom page
|
||||
|
||||
Examples:
|
||||
at25@0 {
|
||||
compatible = "atmel,at25";
|
||||
reg = <0>
|
||||
spi-max-frequency = <5000000>;
|
||||
Additional compatible properties are also allowed.
|
||||
|
||||
at25,byte-len = <0x8000>;
|
||||
at25,addr-mode = <2>;
|
||||
at25,page-size = <64>;
|
||||
};
|
||||
Example:
|
||||
at25@0 {
|
||||
compatible = "atmel,at25", "st,m95256";
|
||||
reg = <0>
|
||||
spi-max-frequency = <5000000>;
|
||||
spi-cpha;
|
||||
spi-cpol;
|
||||
|
||||
pagesize = <64>;
|
||||
size = <32768>;
|
||||
address-width = <16>;
|
||||
};
|
||||
|
|
41
Documentation/devicetree/bindings/misc/ifm-csi.txt
Normal file
41
Documentation/devicetree/bindings/misc/ifm-csi.txt
Normal file
|
@ -0,0 +1,41 @@
|
|||
IFM camera sensor interface on mpc5200 LocalPlus bus
|
||||
|
||||
Required properties:
|
||||
- compatible: "ifm,o2d-csi"
|
||||
- reg: specifies sensor chip select number and associated address range
|
||||
- interrupts: external interrupt line number and interrupt sense mode
|
||||
of the interrupt line signaling frame valid events
|
||||
- gpios: three gpio-specifiers for "capture", "reset" and "master enable"
|
||||
GPIOs (strictly in this order).
|
||||
- ifm,csi-clk-handle: the phandle to a node in the DT describing the sensor
|
||||
clock generator. This node is usually a general purpose timer controller.
|
||||
- ifm,csi-addr-bus-width: address bus width (valid values are 16, 24, 25)
|
||||
- ifm,csi-data-bus-width: data bus width (valid values are 8 and 16)
|
||||
- ifm,csi-wait-cycles: sensor bus wait cycles
|
||||
|
||||
Optional properties:
|
||||
- ifm,csi-byte-swap: if this property is present, the byte swapping on
|
||||
the bus will be enabled.
|
||||
|
||||
Example:
|
||||
|
||||
csi@3,0 {
|
||||
compatible = "ifm,o2d-csi";
|
||||
reg = <3 0 0x00100000>; /* CS 3, 1 MiB range */
|
||||
interrupts = <1 1 2>; /* IRQ1, edge falling */
|
||||
|
||||
ifm,csi-clk-handle = <&timer7>;
|
||||
gpios = <&gpio_simple 23 0 /* image_capture */
|
||||
&gpio_simple 26 0 /* image_reset */
|
||||
&gpio_simple 29 0>; /* image_master_en */
|
||||
|
||||
ifm,csi-addr-bus-width = <24>;
|
||||
ifm,csi-data-bus-width = <8>;
|
||||
ifm,csi-wait-cycles = <0>;
|
||||
};
|
||||
|
||||
The base address of the used chip select is specified in the
|
||||
ranges property of the parent localbus node, for example:
|
||||
|
||||
ranges = <0 0 0xff000000 0x01000000
|
||||
3 0 0xe3000000 0x00100000>;
|
112
Documentation/devicetree/bindings/misc/lis302.txt
Normal file
112
Documentation/devicetree/bindings/misc/lis302.txt
Normal file
|
@ -0,0 +1,112 @@
|
|||
LIS302 accelerometer devicetree bindings
|
||||
|
||||
This device is matched via its bus drivers, and has a number of properties
|
||||
that apply in on the generic device (independent from the bus).
|
||||
|
||||
|
||||
Required properties for the SPI bindings:
|
||||
- compatible: should be set to "st,lis3lv02d_spi"
|
||||
- reg: the chipselect index
|
||||
- spi-max-frequency: maximal bus speed, should be set to 1000000 unless
|
||||
constrained by external circuitry
|
||||
- interrupts: the interrupt generated by the device
|
||||
|
||||
Required properties for the I2C bindings:
|
||||
- compatible: should be set to "st,lis3lv02d"
|
||||
- reg: i2c slave address
|
||||
- Vdd-supply: The input supply for Vdd
|
||||
- Vdd_IO-supply: The input supply for Vdd_IO
|
||||
|
||||
|
||||
Optional properties for all bus drivers:
|
||||
|
||||
- st,click-single-{x,y,z}: if present, tells the device to issue an
|
||||
interrupt on single click events on the
|
||||
x/y/z axis.
|
||||
- st,click-double-{x,y,z}: if present, tells the device to issue an
|
||||
interrupt on double click events on the
|
||||
x/y/z axis.
|
||||
- st,click-thresh-{x,y,z}: set the x/y/z axis threshold
|
||||
- st,click-click-time-limit: click time limit, from 0 to 127.5msec
|
||||
with step of 0.5 msec
|
||||
- st,click-latency: click latency, from 0 to 255 msec with
|
||||
step of 1 msec.
|
||||
- st,click-window: click window, from 0 to 255 msec with
|
||||
step of 1 msec.
|
||||
- st,irq{1,2}-disable: disable IRQ 1/2
|
||||
- st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
|
||||
- st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
|
||||
- st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
|
||||
- st,irq{1,2}-click: raise IRQ 1/2 on click condition
|
||||
- st,irq-open-drain: consider IRQ lines open-drain
|
||||
- st,irq-active-low: make IRQ lines active low
|
||||
- st,wu-duration-1: duration register for Free-Fall/Wake-Up
|
||||
interrupt 1
|
||||
- st,wu-duration-2: duration register for Free-Fall/Wake-Up
|
||||
interrupt 2
|
||||
- st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
|
||||
upper/lower limit
|
||||
- st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
|
||||
highpass cut-off frequency
|
||||
- st,hipass{1,2}-disable: disable highpass 1/2.
|
||||
- st,default-rate=: set the default rate
|
||||
- st,axis-{x,y,z}=: set the axis to map to the three coordinates
|
||||
- st,{min,max}-limit-{x,y,z} set the min/max limits for x/y/z axis
|
||||
(used by self-test)
|
||||
|
||||
|
||||
Example for a SPI device node:
|
||||
|
||||
lis302@0 {
|
||||
compatible = "st,lis302dl-spi";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <1000000>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <104 0>;
|
||||
|
||||
st,click-single-x;
|
||||
st,click-single-y;
|
||||
st,click-single-z;
|
||||
st,click-thresh-x = <10>;
|
||||
st,click-thresh-y = <10>;
|
||||
st,click-thresh-z = <10>;
|
||||
st,irq1-click;
|
||||
st,irq2-click;
|
||||
st,wakeup-x-lo;
|
||||
st,wakeup-x-hi;
|
||||
st,wakeup-y-lo;
|
||||
st,wakeup-y-hi;
|
||||
st,wakeup-z-lo;
|
||||
st,wakeup-z-hi;
|
||||
};
|
||||
|
||||
Example for a I2C device node:
|
||||
|
||||
lis331dlh: lis331dlh@18 {
|
||||
compatible = "st,lis331dlh", "st,lis3lv02d";
|
||||
reg = <0x18>;
|
||||
Vdd-supply = <&lis3_reg>;
|
||||
Vdd_IO-supply = <&lis3_reg>;
|
||||
|
||||
st,click-single-x;
|
||||
st,click-single-y;
|
||||
st,click-single-z;
|
||||
st,click-thresh-x = <10>;
|
||||
st,click-thresh-y = <10>;
|
||||
st,click-thresh-z = <10>;
|
||||
st,irq1-click;
|
||||
st,irq2-click;
|
||||
st,wakeup-x-lo;
|
||||
st,wakeup-x-hi;
|
||||
st,wakeup-y-lo;
|
||||
st,wakeup-y-hi;
|
||||
st,wakeup-z-lo;
|
||||
st,wakeup-z-hi;
|
||||
st,min-limit-x = <120>;
|
||||
st,min-limit-y = <120>;
|
||||
st,min-limit-z = <140>;
|
||||
st,max-limit-x = <550>;
|
||||
st,max-limit-y = <550>;
|
||||
st,max-limit-z = <750>;
|
||||
};
|
||||
|
68
Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
Normal file
68
Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
Normal file
|
@ -0,0 +1,68 @@
|
|||
* Atmel High Speed MultiMedia Card Interface
|
||||
|
||||
This controller on atmel products provides an interface for MMC, SD and SDIO
|
||||
types of memory cards.
|
||||
|
||||
This file documents differences between the core properties described
|
||||
by mmc.txt and the properties used by the atmel-mci driver.
|
||||
|
||||
1) MCI node
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "atmel,hsmci"
|
||||
- #address-cells: should be one. The cell is the slot id.
|
||||
- #size-cells: should be zero.
|
||||
- at least one slot node
|
||||
|
||||
The node contains child nodes for each slot that the platform uses
|
||||
|
||||
Example MCI node:
|
||||
|
||||
mmc0: mmc@f0008000 {
|
||||
compatible = "atmel,hsmci";
|
||||
reg = <0xf0008000 0x600>;
|
||||
interrupts = <12 4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
[ child node definitions...]
|
||||
};
|
||||
|
||||
2) slot nodes
|
||||
|
||||
Required properties:
|
||||
- reg: should contain the slot id.
|
||||
- bus-width: number of data lines connected to the controller
|
||||
|
||||
Optional properties:
|
||||
- cd-gpios: specify GPIOs for card detection
|
||||
- cd-inverted: invert the value of external card detect gpio line
|
||||
- wp-gpios: specify GPIOs for write protection
|
||||
|
||||
Example slot node:
|
||||
|
||||
slot@0 {
|
||||
reg = <0>;
|
||||
bus-width = <4>;
|
||||
cd-gpios = <&pioD 15 0>
|
||||
cd-inverted;
|
||||
};
|
||||
|
||||
Example full MCI node:
|
||||
mmc0: mmc@f0008000 {
|
||||
compatible = "atmel,hsmci";
|
||||
reg = <0xf0008000 0x600>;
|
||||
interrupts = <12 4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
slot@0 {
|
||||
reg = <0>;
|
||||
bus-width = <4>;
|
||||
cd-gpios = <&pioD 15 0>
|
||||
cd-inverted;
|
||||
};
|
||||
slot@1 {
|
||||
reg = <1>;
|
||||
bus-width = <4>;
|
||||
};
|
||||
};
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue