FEX-Emu/linux
1
0
Fork 0
mirror of https://github.com/FEX-Emu/linux.git synced 2025-02-15 00:58:25 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Linux 3.9-rc1

Browse Source 
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iQEcBAABAgAGBQJRM9iWAAoJEHm+PkMAQRiGb4AH/0a99dPoENe40AnRdthsPgKN
 47n8L+Apra16PoOs3zAv+oWd1NskfIhaO2UVllKMkWBgiH6/FttJAprVQXJBVpiq
 WWv7BKtI2lyHmiPbQohY6K2nvpami/WwblISxvaU13NhlCJ2ubSFPfGtNQAkx6vn
 DH/GKfPDFayVmFiOQ8TFvVqFmWvn4m3ttIQYEEJHtjY2h3+2Z43xdIRXo7byqSTl
 9cf3FQjIihLLuQ1Hua2HkFh7dQT5/hNSrbf6afaSjCgW2cGj7mRTuvxWZgm7eVpg
 rksFN92EnFs/RJQBK6ZxfYhCMqV5ImUletKfsnQoxl+3NbPQjO0wl7R9VXbC7SE=
 =pBPB
 -----END PGP SIGNATURE-----

Merge tag 'v3.9-rc1' into staging/for_v3.9

Linux 3.9-rc1

* tag 'v3.9-rc1': (10698 commits)
  Linux 3.9-rc1
  btrfs/raid56: Add missing #include <linux/vmalloc.h>
  fix compat_sys_rt_sigprocmask()
  SUNRPC: One line comment fix
  ext4: enable quotas before orphan cleanup
  ext4: don't allow quota mount options when quota feature enabled
  ext4: fix a warning from sparse check for ext4_dir_llseek
  ext4: convert number of blocks to clusters properly
  ext4: fix possible memory leak in ext4_remount()
  jbd2: fix ERR_PTR dereference in jbd2__journal_start
  metag: Provide dma_get_sgtable()
  metag: prom.h: remove declaration of metag_dt_memblock_reserve()
  metag: copy devicetree to non-init memory
  metag: cleanup metag_ksyms.c includes
  metag: move mm/init.c exports out of metag_ksyms.c
  metag: move usercopy.c exports out of metag_ksyms.c
  metag: move setup.c exports out of metag_ksyms.c
  metag: move kick.c exports out of metag_ksyms.c
  metag: move traps.c exports out of metag_ksyms.c
  metag: move irq enable out of irqflags.h on SMP
  ...
This commit is contained in:
Mauro Carvalho Chehab 2013-03-04 11:07:08 -03:00
commit d34c353cd4
10278 changed files with 520590 additions and 271395 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
CREDITS
View File

@ -1572,12 +1572,12 @@ S: Wantage, New Jersey 07461
S: USA
N: Harald Hoyer
E: harald.hoyer@parzelle.de
W: http://parzelle.de/
E: harald@redhat.com
W: http://www.harald-hoyer.de
D: ip_masq_quake
D: md boot support
S: Hohe Strasse 30
S: D-70176 Stuttgart
S: Am Strand 5
S: D-19063 Schwerin
S: Germany
N: Jan Hubicka

151
Documentation/00-INDEX
View File

@ -2,7 +2,7 @@
This is a brief list of all the files in ./linux/Documentation and what
they contain. If you add a documentation file, please list it here in
alphabetical order as well, or risk being hunted down like a rabid dog.
Please try and keep the descriptions small enough to fit on one line.
Please keep the descriptions small enough to fit on one line.
Thanks -- Paul G.
Following translations are available on the WWW:
@ -20,24 +20,33 @@ BUG-HUNTING
Changes
- list of changes that break older software packages.
CodingStyle
- how the boss likes the C code in the kernel to look.
development-process/
- An extended tutorial on how to work with the kernel development
process.
- how the maintainers expect the C code in the kernel to look.
DMA-API.txt
- DMA API, pci_ API & extensions for non-consistent memory machines.
DMA-API-HOWTO.txt
- Dynamic DMA mapping Guide
DMA-ISA-LPC.txt
- How to do DMA with ISA (and LPC) devices.
DMA-attributes.txt
- listing of the various possible attributes a DMA region can have
DocBook/
- directory with DocBook templates etc. for kernel documentation.
EDID/
- directory with info on customizing EDID for broken gfx/displays.
HOWTO
- the process and procedures of how to do Linux kernel development.
IPMI.txt
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
IRQ-affinity.txt
- how to select which CPU(s) handle which interrupt events on SMP.
IRQ-domain.txt
- info on inerrupt numbering and setting up IRQ domains.
IRQ.txt
- description of what an IRQ is.
Intel-IOMMU.txt
- basic info on the Intel IOMMU virtualization support.
Makefile
- some files in Documentation dir are actually sample code to build
ManagementStyle
- how to (attempt to) manage kernel hackers.
RCU/
@ -66,10 +75,16 @@ applying-patches.txt
- description of various trees and how to apply their patches.
arm/
- directory with info about Linux on the ARM architecture.
arm64/
- directory with info about Linux on the 64 bit ARM architecture.
atomic_ops.txt
- semantics and behavior of atomic and bitmask operations.
auxdisplay/
- misc. LCD driver documentation (cfag12864b, ks0108).
backlight/
- directory with info on controlling backlights in flat panel displays
bad_memory.txt
- how to use kernel parameters to exclude bad RAM regions.
basic_profiling.txt
- basic instructions for those who wants to profile Linux kernel.
binfmt_misc.txt
@ -80,8 +95,14 @@ block/
- info on the Block I/O (BIO) layer.
blockdev/
- info on block devices & drivers
braille-console.txt
- info on how to use serial devices for Braille support.
bt8xxgpio.txt
- info on how to modify a bt8xx video card for GPIO usage.
btmrvl.txt
- info on Marvell Bluetooth driver usage.
bus-devices/
- directory with info on TI GPMC (General Purpose Memory Controller)
bus-virt-phys-mapping.txt
- how to access I/O mapped memory from within device drivers.
cachetlb.txt
@ -90,6 +111,12 @@ cdrom/
- directory with information on the CD-ROM drivers that Linux has.
cgroups/
- cgroups features, including cpusets and memory controller.
circular-buffers.txt
- how to make use of the existing circular buffer infrastructure
clk.txt
- info on the common clock framework
coccinelle.txt
- info on how to get and use the Coccinelle code checking tool.
connector/
- docs on the netlink based userspace<->kernel space communication mod.
console/
@ -114,24 +141,42 @@ dcdbas.txt
- information on the Dell Systems Management Base Driver.
debugging-modules.txt
- some notes on debugging modules after Linux 2.6.3.
debugging-via-ohci1394.txt
- how to use firewire like a hardware debugger memory reader.
dell_rbu.txt
- document demonstrating the use of the Dell Remote BIOS Update driver.
development-process/
- how to work with the mainline kernel development process.
device-mapper/
- directory with info on Device Mapper.
devices.txt
- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
devicetree/
- directory with info on device tree files used by OF/PowerPC/ARM
digsig.txt
-info on the Digital Signature Verification API
dma-buf-sharing.txt
- the DMA Buffer Sharing API Guide
dmaengine.txt
-the DMA Engine API Guide
dontdiff
- file containing a list of files that should never be diff'ed.
driver-model/
- directory with info about Linux driver model.
dvb/
- info on Linux Digital Video Broadcast (DVB) subsystem.
dynamic-debug-howto.txt
- how to use the dynamic debug (dyndbg) feature.
early-userspace/
- info about initramfs, klibc, and userspace early during boot.
edac.txt
- information on EDAC - Error Detection And Correction
eisa.txt
- info on EISA bus support.
email-clients.txt
- info on how to use e-mail to send un-mangled (git) patches.
extcon/
- directory with porting guide for Android kernel switch driver.
fault-injection/
- dir with docs about the fault injection capabilities infrastructure.
fb/
@ -140,12 +185,22 @@ filesystems/
- info on the vfs and the various filesystems that Linux supports.
firmware_class/
- request_firmware() hotplug interface info.
flexible-arrays.txt
- how to make use of flexible sized arrays in linux
frv/
- Fujitsu FR-V Linux documentation.
futex-requeue-pi.txt
- info on requeueing of tasks from a non-PI futex to a PI futex
gcov.txt
- use of GCC's coverage testing tool "gcov" with the Linux kernel
gpio.txt
- overview of GPIO (General Purpose Input/Output) access conventions.
hid/
- directory with information on human interface devices
highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
hwspinlock.txt
- hardware spinlock provides hardware assistance for synchronization
timers/
- info on the timer related topics
hw_random.txt
@ -162,10 +217,14 @@ ia64/
- directory with info about Linux on Intel 64 bit architecture.
infiniband/
- directory with documents concerning Linux InfiniBand support.
init.txt
- what to do when the kernel can't find the 1st process to run.
initrd.txt
- how to use the RAM disk as an initial/temporary root filesystem.
input/
- info on Linux input device support.
intel_txt.txt
- info on intel Trusted Execution Technology (intel TXT).
io-mapping.txt
- description of io_mapping functions in linux/io-mapping.h
io_ordering.txt
@ -182,6 +241,8 @@ isdn/
- directory with info on the Linux ISDN support, and supported cards.
java.txt
- info on the in-kernel binary support for Java(tm).
ja_JP/
- directory with Japanese translations of various documents
kbuild/
- directory with info about the kernel build process.
kdump/
@ -192,6 +253,12 @@ kernel-docs.txt
- listing of various WWW + books that document kernel internals.
kernel-parameters.txt
- summary listing of command line / boot prompt args for the kernel.
kmemcheck.txt
- info on dynamic checker that detects uses of uninitialized memory.
kmemleak.txt
- info on how to make use of the kernel memory leak detection system
ko_KR/
- directory with Korean translations of various documents
kobject.txt
- info of the kobject infrastructure of the Linux kernel.
kprobes.txt
@ -208,6 +275,8 @@ local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.txt
- documentation on the runtime locking correctness validator.
lockstat.txt
- info on collecting statistics on locks (and contention).
lockup-watchdogs.txt
- info on soft and hard lockup detectors (aka nmi_watchdog).
logo.gif
@ -220,16 +289,28 @@ magic-number.txt
- list of magic numbers used to mark/protect kernel data structures.
md.txt
- info on boot arguments for the multiple devices driver.
media-framework.txt
- info on media framework, its data structures, functions and usage.
memory-barriers.txt
- info on Linux kernel memory barriers.
memory-devices/
- directory with info on parts like the Texas Instruments EMIF driver
memory-hotplug.txt
- Hotpluggable memory support, how to use and current status.
memory.txt
- info on typical Linux memory problems.
metag/
- directory with info about Linux on Meta architecture.
mips/
- directory with info about Linux on MIPS architecture.
misc-devices/
- directory with info about devices using the misc dev subsystem
mmc/
- directory with info about the MMC subsystem
mn10300/
- directory with info about the mn10300 architecture port
mtd/
- directory with info about memory technology devices (flash)
mono.txt
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
mutex-design.txt
@ -240,6 +321,8 @@ netlabel/
- directory with information on the NetLabel subsystem.
networking/
- directory with info on various aspects of networking with Linux.
nfc/
- directory relating info about Near Field Communications support.
nommu-mmap.txt
- documentation about no-mmu memory mapping support.
numastat.txt
@ -256,26 +339,46 @@ parport-lowlevel.txt
- description and usage of the low level parallel port functions.
pcmcia/
- info on the Linux PCMCIA driver.
percpu-rw-semaphore.txt
- RCU based read-write semaphore optimized for locking for reading
pi-futex.txt
- documentation on lightweight PI-futexes.
- documentation on lightweight priority inheritance futexes.
pinctrl.txt
- info on pinctrl subsystem and the PINMUX/PINCONF and drivers
pnp.txt
- Linux Plug and Play documentation.
power/
- directory with info on Linux PCI power management.
powerpc/
- directory with info on using Linux with the PowerPC.
prctl/
- directory with info on the priveledge control subsystem
preempt-locking.txt
- info on locking under a preemptive kernel.
printk-formats.txt
- how to get printk format specifiers right
pps/
- directory with information on the pulse-per-second support
ptp/
- directory with info on support for IEEE 1588 PTP clocks in Linux.
pwm.txt
- info on the pulse width modulation driver subsystem
ramoops.txt
- documentation of the ramoops oops/panic logging module.
rapidio/
- directory with info on RapidIO packet-based fabric interconnect
rbtree.txt
- info on what red-black trees are and what they are for.
remoteproc.txt
- info on how to handle remote processor (e.g. AMP) offloads/usage.
rfkill.txt
- info on the radio frequency kill switch subsystem/support.
robust-futex-ABI.txt
- documentation of the robust futex ABI.
robust-futexes.txt
- a description of what robust futexes are.
rpmsg.txt
- info on the Remote Processor Messaging (rpmsg) Framework
rt-mutex-design.txt
- description of the RealTime mutex implementation design.
rt-mutex.txt
@ -300,10 +403,10 @@ sgi-visws.txt
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
smsc_ece1099.txt
-info on the smsc Keyboard Scan Expansion/GPIO Expansion device.
sound/
- directory with info on sound card support.
sparc/
- directory with info on using Linux on Sparc architecture.
sparse.txt
- info on how to obtain and use the sparse tool for typechecking.
spi/
@ -314,6 +417,8 @@ stable_api_nonsense.txt
- info on why the kernel does not have a stable in-kernel api or abi.
stable_kernel_rules.txt
- rules and procedures for the -stable kernel releases.
static-keys.txt
- info on how static keys allow debug code in hotpaths via patching
svga.txt
- short guide on selecting video modes at boot via VGA BIOS.
sysfs-rules.txt
@ -322,27 +427,53 @@ sysctl/
- directory with info on the /proc/sys/* files.
sysrq.txt
- info on the magic SysRq key.
telephony/
- directory with info on telephony (e.g. voice over IP) support.
target/
- directory with info on generating TCM v4 fabric .ko modules
thermal/
- directory with information on managing thermal issues (CPU/temp)
trace/
- directory with info on tracing technologies within linux
unaligned-memory-access.txt
- info on how to avoid arch breaking unaligned memory access in code.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
unshare.txt
- description of the Linux unshare system call.
usb/
- directory with info regarding the Universal Serial Bus.
vDSO/
- directory with info regarding virtual dynamic shared objects
vfio.txt
- info on Virtual Function I/O used in guest/hypervisor instances.
vgaarbiter.txt
- info on enable/disable the legacy decoding on different VGA devices
video-output.txt
- sysfs class driver interface to enable/disable a video output device.
video4linux/
- directory with info regarding video/TV/radio cards and linux.
virtual/
- directory with information on the various linux virtualizations.
vm/
- directory with info on the Linux vm code.
vme_api.txt
- file relating info on the VME bus API in linux
volatile-considered-harmful.txt
- Why the "volatile" type class should not be used
w1/
- directory with documents regarding the 1-wire (w1) subsystem.
watchdog/
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
wimax/
- directory with info about Intel Wireless Wimax Connections
workqueue.txt
- information on the Concurrency Managed Workqueue implementation
x86/x86_64/
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
xtensa/
- directory with documents relating to arch/xtensa port/implementation
xz.txt
- how to make use of the XZ data compression within linux kernel
zh_CN/
- directory with Chinese translations of various documents
zorro.txt
- info on writing drivers for Zorro bus devices found on Amigas.

185
Documentation/ABI/stable/sysfs-class-tpm Normal file
View File

@ -0,0 +1,185 @@
What: /sys/class/misc/tpmX/device/
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
Description: The device/ directory under a specific TPM instance exposes
the properties of that TPM chip
What: /sys/class/misc/tpmX/device/active
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "active" property prints a '1' if the TPM chip is accepting
commands. An inactive TPM chip still contains all the state of
an active chip (Storage Root Key, NVRAM, etc), and can be
visible to the OS, but will only accept a restricted set of
commands. See the TPM Main Specification part 2, Structures,
section 17 for more information on which commands are
available.
What: /sys/class/misc/tpmX/device/cancel
Date: June 2005
KernelVersion: 2.6.13
Contact: tpmdd-devel@lists.sf.net
Description: The "cancel" property allows you to cancel the currently
pending TPM command. Writing any value to cancel will call the
TPM vendor specific cancel operation.
What: /sys/class/misc/tpmX/device/caps
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
Description: The "caps" property contains TPM manufacturer and version info.
Example output:
Manufacturer: 0x53544d20
TCG version: 1.2
Firmware version: 8.16
Manufacturer is a hex dump of the 4 byte manufacturer info
space in a TPM. TCG version shows the TCG TPM spec level that
the chip supports. Firmware version is that of the chip and
is manufacturer specific.
What: /sys/class/misc/tpmX/device/durations
Date: March 2011
KernelVersion: 3.1
Contact: tpmdd-devel@lists.sf.net
Description: The "durations" property shows the 3 vendor-specific values
used to wait for a short, medium and long TPM command. All
TPM commands are categorized as short, medium or long in
execution time, so that the driver doesn't have to wait
any longer than necessary before starting to poll for a
result.
Example output:
3015000 4508000 180995000 [original]
Here the short, medium and long durations are displayed in
usecs. "[original]" indicates that the values are displayed
unmodified from when they were queried from the chip.
Durations can be modified in the case where a buggy chip
reports them in msec instead of usec and they need to be
scaled to be displayed in usecs. In this case "[adjusted]"
will be displayed in place of "[original]".
What: /sys/class/misc/tpmX/device/enabled
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "enabled" property prints a '1' if the TPM chip is enabled,
meaning that it should be visible to the OS. This property
may be visible but produce a '0' after some operation that
disables the TPM.
What: /sys/class/misc/tpmX/device/owned
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "owned" property produces a '1' if the TPM_TakeOwnership
ordinal has been executed successfully in the chip. A '0'
indicates that ownership hasn't been taken.
What: /sys/class/misc/tpmX/device/pcrs
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
Description: The "pcrs" property will dump the current value of all Platform
Configuration Registers in the TPM. Note that since these
values may be constantly changing, the output is only valid
for a snapshot in time.
Example output:
PCR-00: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-01: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-02: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-04: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
...
The number of PCRs and hex bytes needed to represent a PCR
value will vary depending on TPM chip version. For TPM 1.1 and
1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
long. Use the "caps" property to determine TPM version.
What: /sys/class/misc/tpmX/device/pubek
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
Description: The "pubek" property will return the TPM's public endorsement
key if possible. If the TPM has had ownership established and
is version 1.2, the pubek will not be available without the
owner's authorization. Since the TPM driver doesn't store any
secrets, it can't authorize its own request for the pubek,
making it unaccessible. The public endorsement key is gener-
ated at TPM menufacture time and exists for the life of the
chip.
Example output:
Algorithm: 00 00 00 01
Encscheme: 00 03
Sigscheme: 00 01
Parameters: 00 00 08 00 00 00 00 02 00 00 00 00
Modulus length: 256
Modulus:
B4 76 41 82 C9 20 2C 10 18 40 BC 8B E5 44 4C 6C
3A B2 92 0C A4 9B 2A 83 EB 5C 12 85 04 48 A0 B6
1E E4 81 84 CE B2 F2 45 1C F0 85 99 61 02 4D EB
86 C4 F7 F3 29 60 52 93 6B B2 E5 AB 8B A9 09 E3
D7 0E 7D CA 41 BF 43 07 65 86 3C 8C 13 7A D0 8B
82 5E 96 0B F8 1F 5F 34 06 DA A2 52 C1 A9 D5 26
0F F4 04 4B D9 3F 2D F2 AC 2F 74 64 1F 8B CD 3E
1E 30 38 6C 70 63 69 AB E2 50 DF 49 05 2E E1 8D
6F 78 44 DA 57 43 69 EE 76 6C 38 8A E9 8E A3 F0
A7 1F 3C A8 D0 12 15 3E CA 0E BD FA 24 CD 33 C6
47 AE A4 18 83 8E 22 39 75 93 86 E6 FD 66 48 B6
10 AD 94 14 65 F9 6A 17 78 BD 16 53 84 30 BF 70
E0 DC 65 FD 3C C6 B0 1E BF B9 C1 B5 6C EF B1 3A
F8 28 05 83 62 26 11 DC B4 6B 5A 97 FF 32 26 B6
F7 02 71 CF 15 AE 16 DD D1 C1 8E A8 CF 9B 50 7B
C3 91 FF 44 1E CF 7C 39 FE 17 77 21 20 BD CE 9B
Possible values:
Algorithm: TPM_ALG_RSA (1)
Encscheme: TPM_ES_RSAESPKCSv15 (2)
TPM_ES_RSAESOAEP_SHA1_MGF1 (3)
Sigscheme: TPM_SS_NONE (1)
Parameters, a byte string of 3 u32 values:
Key Length (bits): 00 00 08 00 (2048)
Num primes: 00 00 00 02 (2)
Exponent Size: 00 00 00 00 (0 means the
default exp)
Modulus Length: 256 (bytes)
Modulus: The 256 byte Endorsement Key modulus
What: /sys/class/misc/tpmX/device/temp_deactivated
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "temp_deactivated" property returns a '1' if the chip has
been temporarily dectivated, usually until the next power
cycle. Whether a warm boot (reboot) will clear a TPM chip
from a temp_deactivated state is platform specific.
What: /sys/class/misc/tpmX/device/timeouts
Date: March 2011
KernelVersion: 3.1
Contact: tpmdd-devel@lists.sf.net
Description: The "timeouts" property shows the 4 vendor-specific values
for the TPM's interface spec timeouts. The use of these
timeouts is defined by the TPM interface spec that the chip
conforms to.
Example output:
750000 750000 750000 750000 [original]
The four timeout values are shown in usecs, with a trailing
"[original]" or "[adjusted]" depending on whether the values
were scaled by the driver to be reported in usec from msecs.

10
Documentation/ABI/testing/ima_policy
View File

@ -18,17 +18,21 @@ Description:
rule format: action [condition ...]
action: measure | dont_measure | appraise | dont_appraise | audit
condition:= base | lsm
base: [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
condition:= base | lsm [option]
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
[fowner]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
option: [[appraise_type=]]
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK][MODULE_CHECK]
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
fsmagic:= hex value
fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
uid:= decimal value
fowner:=decimal value
lsm: are LSM specific
option: appraise_type:= [imasig]
default policy:
# PROC_SUPER_MAGIC

10
Documentation/ABI/testing/pstore
View File

@ -1,4 +1,4 @@
Where: /dev/pstore/...
Where: /sys/fs/pstore/... (or /dev/pstore/...)
Date: March 2011
Kernel Version: 2.6.39
Contact: tony.luck@intel.com
@ -11,9 +11,9 @@ Description: Generic interface to platform dependent persistent storage.
of the console log is captured, but other interesting
data can also be saved.
# mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
# mount -t pstore -o kmsg_bytes=8000 - /sys/fs/pstore
$ ls -l /dev/pstore
$ ls -l /sys/fs/pstore/
total 0
-r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1
@ -27,9 +27,9 @@ Description: Generic interface to platform dependent persistent storage.
the file will signal to the underlying persistent storage
device that it can reclaim the space for later re-use.
$ rm /dev/pstore/dmesg-erst-1
$ rm /sys/fs/pstore/dmesg-erst-1
The expectation is that all files in /dev/pstore
The expectation is that all files in /sys/fs/pstore/
will be saved elsewhere and erased from persistent store
soon after boot to free up space ready for the next
catastrophe.

62
Documentation/ABI/testing/sysfs-bus-event_source-devices-events Normal file
View File

@ -0,0 +1,62 @@
What: /sys/devices/cpu/events/
/sys/devices/cpu/events/branch-misses
/sys/devices/cpu/events/cache-references
/sys/devices/cpu/events/cache-misses
/sys/devices/cpu/events/stalled-cycles-frontend
/sys/devices/cpu/events/branch-instructions
/sys/devices/cpu/events/stalled-cycles-backend
/sys/devices/cpu/events/instructions
/sys/devices/cpu/events/cpu-cycles
Date: 2013/01/08
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Generic performance monitoring events
A collection of performance monitoring events that may be
supported by many/most CPUs. These events can be monitored
using the 'perf(1)' tool.
The contents of each file would look like:
event=0xNNNN
where 'N' is a hex digit and the number '0xNNNN' shows the
"raw code" for the perf event identified by the file's
"basename".
What: /sys/devices/cpu/events/PM_LD_MISS_L1
/sys/devices/cpu/events/PM_LD_REF_L1
/sys/devices/cpu/events/PM_CYC
/sys/devices/cpu/events/PM_BRU_FIN
/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
/sys/devices/cpu/events/PM_BRU_MPRED
/sys/devices/cpu/events/PM_INST_CMPL
/sys/devices/cpu/events/PM_CMPLU_STALL
Date: 2013/01/08
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
Description: POWER-systems specific performance monitoring events
A collection of performance monitoring events that may be
supported by the POWER CPU. These events can be monitored
using the 'perf(1)' tool.
These events may not be supported by other CPUs.
The contents of each file would look like:
event=0xNNNN
where 'N' is a hex digit and the number '0xNNNN' shows the
"raw code" for the perf event identified by the file's
"basename".
Further, multiple terms like 'event=0xNNNN' can be specified
and separated with comma. All available terms are defined in
the /sys/bus/event_source/devices/<dev>/format file.

45
Documentation/ABI/testing/sysfs-bus-fcoe
View File

@ -1,14 +1,53 @@
What: /sys/bus/fcoe/ctlr_X
What: /sys/bus/fcoe/
Date: August 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: The FCoE bus. Attributes in this directory are control interfaces.
Attributes:
ctlr_create: 'FCoE Controller' instance creation interface. Writing an
<ifname> to this file will allocate and populate sysfs with a
fcoe_ctlr_device (ctlr_X). The user can then configure any
per-port settings and finally write to the fcoe_ctlr_device's
'start' attribute to begin the kernel's discovery and login
process.
ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
fcoe_ctlr_device's sysfs name to this file will log the
fcoe_ctlr_device out of the fabric or otherwise connected
FCoE devices. It will also free all kernel memory allocated
for this fcoe_ctlr_device and any structures associated
with it, this includes the scsi_host.
What: /sys/bus/fcoe/devices/ctlr_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: 'FCoE Controller' instances on the fcoe bus
Description: 'FCoE Controller' instances on the fcoe bus.
The FCoE Controller now has a three stage creation process.
1) Write interface name to ctlr_create 2) Configure the FCoE
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
discovery and login. The FCoE Controller is destroyed by
writing it's name, i.e. ctlr_X to the ctlr_delete file.
Attributes:
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.
mode: Display or change the FCoE Controller's mode. Possible
modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
is started in 'Fabric' mode then FIP FCF discovery is
initiated and ultimately a fabric login is attempted.
If a FCoE Controller is started in 'VN2VN' mode then
FIP VN2VN discovery and login is performed. A FCoE
Controller only supports one mode at a time.
enabled: Whether an FCoE controller is enabled or disabled.
0 if disabled, 1 if enabled. Writing either 0 or 1
to this file will enable or disable the FCoE controller.
lesb/link_fail: Link Error Status Block (LESB) link failure count.
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
@ -26,7 +65,7 @@ Attributes:
Notes: ctlr_X (global increment starting at 0)
What: /sys/bus/fcoe/fcf_X
What: /sys/bus/fcoe/devices/fcf_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org

13
Documentation/ABI/testing/sysfs-bus-iio-mpu6050 Normal file
View File

@ -0,0 +1,13 @@
What: /sys/bus/iio/devices/iio:deviceX/in_gyro_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_accel_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_magn_matrix
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
This is mounting matrix for motion sensors. Mounting matrix
is a 3x3 unitary matrix. A typical mounting matrix would look like
[0, 1, 0; 1, 0, 0; 0, 0, -1]. Using this information, it would be
easy to tell the relative positions among sensors as well as their
positions relative to the board that holds these sensors. Identity matrix
[1, 0, 0; 0, 1, 0; 0, 0, 1] means sensor chip and device are perfectly
aligned with each other. All axes are exactly the same.

9
Documentation/ABI/testing/sysfs-bus-usb
View File

@ -227,3 +227,12 @@ Contact: Lan Tianyu <tianyu.lan@intel.com>
Description:
The /sys/bus/usb/devices/.../(hub interface)/portX
is usb port device's sysfs directory.
What: /sys/bus/usb/devices/.../(hub interface)/portX/connect_type
Date: January 2013
Contact: Lan Tianyu <tianyu.lan@intel.com>
Description:
Some platforms provide usb port connect types through ACPI.
This attribute is to expose these information to user space.
The file will read "hotplug", "wired" and "not used" if the
information is available, and "unknown" otherwise.

5
Documentation/ABI/testing/sysfs-class-bdi
View File

@ -48,3 +48,8 @@ max_ratio (read-write)
most of the write-back cache. For example in case of an NFS
mount that is prone to get stuck, or a FUSE mount which cannot
be trusted to play fair.
stable_pages_required (read-only)
If set, the backing device requires that all pages comprising a write
request must not be changed until writeout is complete.

13
Documentation/ABI/testing/sysfs-devices-power_resources_D0 Normal file
View File

@ -0,0 +1,13 @@
What: /sys/devices/.../power_resources_D0/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D0/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D0. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D1 Normal file
View File

@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D1/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D1/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D1.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D1. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D2 Normal file
View File

@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D2/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D2/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D2.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D2. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D3hot Normal file
View File

@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D3hot/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D3hot/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D3hot.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D3hot. The
names of the links are the same as the names of the directories
they point to.

20
Documentation/ABI/testing/sysfs-devices-power_state Normal file
View File

@ -0,0 +1,20 @@
What: /sys/devices/.../power_state
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_state attribute is only present for
device objects representing ACPI device nodes that provide power
management methods.
If present, it contains a string representing the current ACPI
power state of the given device node. Its possible values,
"D0", "D1", "D2", "D3hot", and "D3cold", reflect the power state
names defined by the ACPI specification (ACPI 4 and above).
If the device node uses shared ACPI power resources, this state
determines a list of power resources required not to be turned
off. However, some power resources needed by the device node in
higher-power (lower-number) states may also be ON because of
some other devices using them at the moment.
This attribute is read-only.

23
Documentation/ABI/testing/sysfs-devices-real_power_state Normal file
View File

@ -0,0 +1,23 @@
What: /sys/devices/.../real_power_state
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../real_power_state attribute is only present
for device objects representing ACPI device nodes that provide
power management methods and use ACPI power resources for power
management.
If present, it contains a string representing the real ACPI
power state of the given device node as returned by the _PSC
control method or inferred from the configuration of power
resources. Its possible values, "D0", "D1", "D2", "D3hot", and
"D3cold", reflect the power state names defined by the ACPI
specification (ACPI 4 and above).
In some situations the value of this attribute may be different
from the value of the /sys/devices/.../power_state attribute for
the same device object. If that happens, some shared power
resources used by the device node are only ON because of some
other devices using them at the moment.
This attribute is read-only.

12
Documentation/ABI/testing/sysfs-devices-resource_in_use Normal file
View File

@ -0,0 +1,12 @@
What: /sys/devices/.../resource_in_use
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../resource_in_use attribute is only present
for device objects representing ACPI power resources.
If present, it contains a number (0 or 1) representing the
current status of the given power resource (0 means that the
resource is not in use and therefore it has been turned off).
This attribute is read-only.

14
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -67,20 +67,6 @@ Description: Discover NUMA node a CPU belongs to
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
What: /sys/devices/system/cpu/cpu#/node
Date: October 2009
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Discover NUMA node a CPU belongs to
When CONFIG_NUMA is enabled, a symbolic link that points
to the corresponding NUMA node directory.
For example, the following symlink is created for cpu42
in NUMA node 2:
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
What: /sys/devices/system/cpu/cpu#/topology/core_id
/sys/devices/system/cpu/cpu#/topology/core_siblings
/sys/devices/system/cpu/cpu#/topology/core_siblings_list

21
Documentation/ABI/testing/sysfs-driver-hid-srws1 Normal file
View File

@ -0,0 +1,21 @@
What: /sys/class/leds/SRWS1::<serial>::RPM1
What: /sys/class/leds/SRWS1::<serial>::RPM2
What: /sys/class/leds/SRWS1::<serial>::RPM3
What: /sys/class/leds/SRWS1::<serial>::RPM4
What: /sys/class/leds/SRWS1::<serial>::RPM5
What: /sys/class/leds/SRWS1::<serial>::RPM6
What: /sys/class/leds/SRWS1::<serial>::RPM7
What: /sys/class/leds/SRWS1::<serial>::RPM8
What: /sys/class/leds/SRWS1::<serial>::RPM9
What: /sys/class/leds/SRWS1::<serial>::RPM10
What: /sys/class/leds/SRWS1::<serial>::RPM11
What: /sys/class/leds/SRWS1::<serial>::RPM12
What: /sys/class/leds/SRWS1::<serial>::RPM13
What: /sys/class/leds/SRWS1::<serial>::RPM14
What: /sys/class/leds/SRWS1::<serial>::RPM15
What: /sys/class/leds/SRWS1::<serial>::RPMALL
Date: Jan 2013
KernelVersion: 3.9
Contact: Simon Wood <simon@mungewell.org>
Description: Provides a control for turning on/off the LEDs which form
an RPM meter on the front of the controller

23
Documentation/ABI/testing/sysfs-driver-hid-thingm Normal file
View File

@ -0,0 +1,23 @@
What: /sys/class/leds/blink1::<serial>/rgb
Date: January 2013
Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Description: The ThingM blink1 is an USB RGB LED. The color notation is
3-byte hexadecimal. Read this attribute to get the last set
color. Write the 24-bit hexadecimal color to change the current
LED color. The default color is full white (0xFFFFFF).
For instance, set the color to green with: echo 00FF00 > rgb
What: /sys/class/leds/blink1::<serial>/fade
Date: January 2013
Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Description: This attribute allows to set a fade time in milliseconds for
the next color change. Read the attribute to know the current
fade time. The default value is set to 0 (no fade time). For
instance, set a fade time of 2 seconds with: echo 2000 > fade
What: /sys/class/leds/blink1::<serial>/play
Date: January 2013
Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Description: This attribute is used to play/pause the light patterns. Write 1
to start playing, 0 to stop. Reading this attribute returns the
current playing status.

52
Documentation/ABI/testing/sysfs-kernel-mm-ksm Normal file
View File

@ -0,0 +1,52 @@
What: /sys/kernel/mm/ksm
Date: September 2009
KernelVersion: 2.6.32
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Interface for Kernel Samepage Merging (KSM)
What: /sys/kernel/mm/ksm/full_scans
What: /sys/kernel/mm/ksm/pages_shared
What: /sys/kernel/mm/ksm/pages_sharing
What: /sys/kernel/mm/ksm/pages_to_scan
What: /sys/kernel/mm/ksm/pages_unshared
What: /sys/kernel/mm/ksm/pages_volatile
What: /sys/kernel/mm/ksm/run
What: /sys/kernel/mm/ksm/sleep_millisecs
Date: September 2009
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Kernel Samepage Merging daemon sysfs interface
full_scans: how many times all mergeable areas have been
scanned.
pages_shared: how many shared pages are being used.
pages_sharing: how many more sites are sharing them i.e. how
much saved.
pages_to_scan: how many present pages to scan before ksmd goes
to sleep.
pages_unshared: how many pages unique but repeatedly checked
for merging.
pages_volatile: how many pages changing too fast to be placed
in a tree.
run: write 0 to disable ksm, read 0 while ksm is disabled.
write 1 to run ksm, read 1 while ksm is running.
write 2 to disable ksm and unmerge all its pages.
sleep_millisecs: how many milliseconds ksm should sleep between
scans.
See Documentation/vm/ksm.txt for more information.
What: /sys/kernel/mm/ksm/merge_across_nodes
Date: January 2013
KernelVersion: 3.9
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Control merging pages across different NUMA nodes.
When it is set to 0 only pages from the same node are merged,
otherwise pages from all nodes can be merged together (default).

83
Documentation/ABI/testing/sysfs-platform-msi-laptop Normal file
View File

@ -0,0 +1,83 @@
What: /sys/devices/platform/msi-laptop-pf/lcd_level
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Screen brightness: contains a single integer in the range 0..8.
What: /sys/devices/platform/msi-laptop-pf/auto_brightness
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Enable automatic brightness control: contains either 0 or 1. If
set to 1 the hardware adjusts the screen brightness
automatically when the power cord is plugged/unplugged.
What: /sys/devices/platform/msi-laptop-pf/wlan
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
WLAN subsystem enabled: contains either 0 or 1.
What: /sys/devices/platform/msi-laptop-pf/bluetooth
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Bluetooth subsystem enabled: contains either 0 or 1. Please
note that this file is constantly 0 if no Bluetooth hardware is
available.
What: /sys/devices/platform/msi-laptop-pf/touchpad
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if touchpad is turned on.
Touchpad state can only be toggled by pressing Fn+F3.
What: /sys/devices/platform/msi-laptop-pf/turbo_mode
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if turbo mode is turned
on. In turbo mode power LED is orange and processor is
overclocked. Turbo mode is available only if charging. It is
only possible to toggle turbo mode state by pressing Fn+F10,
and there is a few seconds cooldown between subsequent toggles.
If user presses Fn+F10 too frequent, turbo mode state is not
changed.
What: /sys/devices/platform/msi-laptop-pf/eco_mode
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if ECO mode is turned on.
In ECO mode power LED is green and userspace should do some
powersaving actions. ECO mode is available only on battery
power. ECO mode can only be toggled by pressing Fn+F10.
What: /sys/devices/platform/msi-laptop-pf/turbo_cooldown
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains value in range 0..3:
* 0 -> Turbo mode is off
* 1 -> Turbo mode is on, cannot be turned off yet
* 2 -> Turbo mode is off, cannot be turned on yet
* 3 -> Turbo mode is on
What: /sys/devices/platform/msi-laptop-pf/auto_fan
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if fan speed is controlled
automatically (1) or fan runs at maximal speed (0). Can be
toggled in software.

47
Documentation/ABI/testing/sysfs-platform-ts5500 Normal file
View File

@ -0,0 +1,47 @@
What: /sys/devices/platform/ts5500/adc
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of an A/D Converter. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/ereset
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of an external reset. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/id
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Product ID of the TS board. TS-5500 ID is 0x60.
What: /sys/devices/platform/ts5500/jumpers
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Bitfield showing the jumpers' state. If a jumper is present,
the corresponding bit is set. For instance, 0x0e means jumpers
2, 3 and 4 are set.
What: /sys/devices/platform/ts5500/rs485
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of the RS485 option. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/sram
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of the SRAM option. If it is present,
it will display "1", otherwise "0".

10
Documentation/CodingStyle
View File

@ -546,15 +546,7 @@ config AUDIT
logging of avc messages output). Does not do system-call
auditing without CONFIG_AUDITSYSCALL.
Features that might still be considered unstable should be defined as
dependent on "EXPERIMENTAL":
config SLUB
depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
bool "SLUB (Unqueued Allocator)"
...
while seriously dangerous features (such as write support for certain
Seriously dangerous features (such as write support for certain
filesystems) should advertise this prominently in their prompt string:
config ADFS_FS_RW

9
Documentation/DMA-API-HOWTO.txt
View File

@ -488,9 +488,10 @@ will invoke the generic mapping error check interface. Doing so will ensure
that the mapping code will work correctly on all dma implementations without
any dependency on the specifics of the underlying implementation. Using the
returned address without checking for errors could result in failures ranging
from panics to silent data corruption. Couple of example of incorrect ways to
check for errors that make assumptions about the underlying dma implementation
are as follows and these are applicable to dma_map_page() as well.
from panics to silent data corruption. A couple of examples of incorrect ways
to check for errors that make assumptions about the underlying dma
implementation are as follows and these are applicable to dma_map_page() as
well.
Incorrect example 1:
dma_addr_t dma_handle;
@ -751,7 +752,7 @@ Example 1:
dma_unmap_single(dma_handle1);
map_error_handling1:
Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
mapping error is detected in the middle)
dma_addr_t dma_addr;

4
Documentation/DocBook/80211.tmpl
View File

@ -107,8 +107,8 @@
!Finclude/net/cfg80211.h key_params
!Finclude/net/cfg80211.h survey_info_flags
!Finclude/net/cfg80211.h survey_info
!Finclude/net/cfg80211.h beacon_parameters
!Finclude/net/cfg80211.h plink_actions
!Finclude/net/cfg80211.h cfg80211_beacon_data
!Finclude/net/cfg80211.h cfg80211_ap_settings
!Finclude/net/cfg80211.h station_parameters
!Finclude/net/cfg80211.h station_info_flags
!Finclude/net/cfg80211.h rate_info_flags

78
Documentation/DocBook/drm.tmpl
View File

@ -743,6 +743,10 @@ char *date;</synopsis>
These two operations are mandatory for GEM drivers that support DRM
PRIME.
</para>
<sect4>
<title>DRM PRIME Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
</sect4>
</sect3>
<sect3 id="drm-gem-objects-mapping">
<title>GEM Objects Mapping</title>
@ -978,10 +982,25 @@ int max_width, max_height;</synopsis>
If the parameters are deemed valid, drivers then create, initialize and
return an instance of struct <structname>drm_framebuffer</structname>.
If desired the instance can be embedded in a larger driver-specific
structure. The new instance is initialized with a call to
<function>drm_framebuffer_init</function> which takes a pointer to DRM
frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
structure. Drivers must fill its <structfield>width</structfield>,
<structfield>height</structfield>, <structfield>pitches</structfield>,
<structfield>offsets</structfield>, <structfield>depth</structfield>,
<structfield>bits_per_pixel</structfield> and
<structfield>pixel_format</structfield> fields from the values passed
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
should call the <function>drm_helper_mode_fill_fb_struct</function>
helper function to do so.
</para>
<para>
The initailization of the new framebuffer instance is finalized with a
call to <function>drm_framebuffer_init</function> which takes a pointer
to DRM frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Note that this function
publishes the framebuffer and so from this point on it can be accessed
concurrently from other threads. Hence it must be the last step in the
driver's framebuffer initialization sequence. Frame buffer operations
are
<itemizedlist>
<listitem>
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis>
</itemizedlist>
</para>
<para>
After initializing the <structname>drm_framebuffer</structname>
instance drivers must fill its <structfield>width</structfield>,
<structfield>height</structfield>, <structfield>pitches</structfield>,
<structfield>offsets</structfield>, <structfield>depth</structfield>,
<structfield>bits_per_pixel</structfield> and
<structfield>pixel_format</structfield> fields from the values passed
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
should call the <function>drm_helper_mode_fill_fb_struct</function>
helper function to do so.
</para>
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with
<function>drm_framebuffer_reference</function> </para> and drop them
again with <function>drm_framebuffer_unreference</function>. For
driver-private framebuffers for which the last reference is never
dropped (e.g. for the fbdev framebuffer when the struct
<structname>drm_framebuffer</structname> is embedded into the fbdev
helper struct) drivers can manually clean up a framebuffer at module
unload time with
<function>drm_framebuffer_unregister_private</function>.
</sect2>
<sect2>
<title>Output Polling</title>
@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis>
operation.
</para>
</sect2>
<sect2>
<title>Locking</title>
<para>
Beside some lookup structures with their own locking (which is hidden
behind the interface functions) most of the modeset state is protected
by the <code>dev-&lt;mode_config.lock</code> mutex and additionally
per-crtc locks to allow cursor updates, pageflips and similar operations
to occur concurrently with background tasks like output detection.
Operations which cross domains like a full modeset always grab all
locks. Drivers there need to protect resources shared between crtcs with
additional locking. They also need to be careful to always grab the
relevant crtc locks if a modset functions touches crtc state, e.g. for
load detection (which does only grab the <code>mode_config.lock</code>
to allow concurrent screen updates on live crtcs).
</para>
</sect2>
</sect1>
<!-- Internals: kms initialization and cleanup -->
@ -1125,6 +1160,12 @@ int max_width, max_height;</synopsis>
without waiting for rendering or page flip to complete and must block
any new rendering to the frame buffer until the page flip completes.
</para>
<para>
If a page flip can be successfully scheduled the driver must set the
<code>drm_crtc-&lt;fb</code> field to the new framebuffer pointed to
by <code>fb</code>. This is important so that the reference counting
on framebuffers stays balanced.
</para>
<para>
If a page flip is already pending, the
<methodname>page_flip</methodname> operation must return
@ -1609,6 +1650,10 @@ void intel_crt_init(struct drm_device *dev)
make its properties available to applications.
</para>
</sect2>
<sect2>
<title>KMS API Functions</title>
!Edrivers/gpu/drm/drm_crtc.c
</sect2>
</sect1>
<!-- Internals: kms helper functions -->
@ -2104,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev)
<title>fbdev Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
!Iinclude/drm/drm_fb_helper.h
</sect2>
<sect2>
<title>Display Port Helper Functions Reference</title>
@ -2111,6 +2157,10 @@ void intel_crt_init(struct drm_device *dev)
!Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
<sect2>
<title>EDID Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_edid.c
</sect2>
</sect1>
<!-- Internals: vertical blanking -->

11
Documentation/DocBook/kernel-hacking.tmpl
View File

@ -945,7 +945,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<sect1 id="sym-exportsymbols">
<title><function>EXPORT_SYMBOL()</function>
<filename class="headerfile">include/linux/module.h</filename></title>
<filename class="headerfile">include/linux/export.h</filename></title>
<para>
This is the classic method of exporting a symbol: dynamically
@ -955,7 +955,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<sect1 id="sym-exportsymbols-gpl">
<title><function>EXPORT_SYMBOL_GPL()</function>
<filename class="headerfile">include/linux/module.h</filename></title>
<filename class="headerfile">include/linux/export.h</filename></title>
<para>
Similar to <function>EXPORT_SYMBOL()</function> except that the
@ -1184,13 +1184,6 @@ static struct block_device_operations opt_fops = {
<filename>Documentation/kbuild/kconfig-language.txt</filename>.
</para>
<para>
You may well want to make your CONFIG option only visible if
<symbol>CONFIG_EXPERIMENTAL</symbol> is enabled: this serves as a
warning to users. There many other fancy things you can do: see
the various <filename>Kconfig</filename> files for ideas.
</para>
<para>
In your description of the option, make sure you address both the
expert user and the user who knows nothing about your feature. Mention

6
Documentation/DocBook/kgdb.tmpl
View File

@ -94,10 +94,8 @@
<sect1 id="CompileKGDB">
<title>Kernel config options for kgdb</title>
<para>
To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
"Prompt for development and/or incomplete code/drivers"
(CONFIG_EXPERIMENTAL) in "General setup", then under the
"Kernel debugging" select "KGDB: kernel debugger".
To enable <symbol>CONFIG_KGDB</symbol> you should look under
"Kernel debugging" and select "KGDB: kernel debugger".
</para>
<para>
While it is not a hard requirement that you have symbols in your

2
Documentation/DocBook/uio-howto.tmpl
View File

@ -984,7 +984,7 @@ int main()
return errno;
}
configfd = open(&quot;/sys/class/uio/uio0/device/config&quot;, O_RDWR);
if (uiofd &lt; 0) {
if (configfd &lt; 0) {
perror(&quot;config open:&quot;);
return errno;
}

102
Documentation/DocBook/writing-an-alsa-driver.tmpl
View File

@ -871,9 +871,8 @@
<para>
This function itself doesn't allocate the data space. The data
must be allocated manually beforehand, and its pointer is passed
as the argument. This pointer is used as the
(<parameter>chip</parameter> identifier in the above example)
for the instance.
as the argument. This pointer (<parameter>chip</parameter> in the
above example) is used as the identifier for the instance.
</para>
<para>
@ -2304,7 +2303,7 @@ struct _snd_pcm_runtime {
<constant>SNDRV_PCM_INFO_XXX</constant>. Here, at least, you
have to specify whether the mmap is supported and which
interleaved format is supported.
When the is supported, add the
When the hardware supports mmap, add the
<constant>SNDRV_PCM_INFO_MMAP</constant> flag here. When the
hardware supports the interleaved or the non-interleaved
formats, <constant>SNDRV_PCM_INFO_INTERLEAVED</constant> or
@ -2898,7 +2897,7 @@ struct _snd_pcm_runtime {
<para>
When the pcm supports the pause operation (given in the info
field of the hardware table), the <constant>PAUSE_PUSE</constant>
field of the hardware table), the <constant>PAUSE_PUSH</constant>
and <constant>PAUSE_RELEASE</constant> commands must be
handled here, too. The former is the command to pause the pcm,
and the latter to restart the pcm again.
@ -3085,7 +3084,7 @@ struct _snd_pcm_runtime {
<section id="pcm-interface-interrupt-handler-timer">
<title>High frequency timer interrupts</title>
<para>
This happense when the hardware doesn't generate interrupts
This happens when the hardware doesn't generate interrupts
at the period boundary but issues timer interrupts at a fixed
timer rate (e.g. es1968 or ymfpci drivers).
In this case, you need to check the current hardware
@ -3250,49 +3249,6 @@ struct _snd_pcm_runtime {
<example>
<title>Example of Hardware Constraints for Channels</title>
<programlisting>
<![CDATA[
static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
struct snd_interval *c = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_CHANNELS);
struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
struct snd_mask fmt;
snd_mask_any(&fmt); /* Init the struct */
if (c->min < 2) {
fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
return snd_mask_refine(f, &fmt);
}
return 0;
}
]]>
</programlisting>
</example>
</para>
<para>
Then you need to call this function to add your rule:
<informalexample>
<programlisting>
<![CDATA[
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
hw_rule_channels_by_format, 0, SNDRV_PCM_HW_PARAM_FORMAT,
-1);
]]>
</programlisting>
</informalexample>
</para>
<para>
The rule function is called when an application sets the number of
channels. But an application can set the format before the number of
channels. Thus you also need to define the inverse rule:
<example>
<title>Example of Hardware Constraints for Channels</title>
<programlisting>
<![CDATA[
static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
@ -3314,6 +3270,50 @@ struct _snd_pcm_runtime {
</programlisting>
</example>
</para>
<para>
Then you need to call this function to add your rule:
<informalexample>
<programlisting>
<![CDATA[
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
hw_rule_channels_by_format, NULL,
SNDRV_PCM_HW_PARAM_FORMAT, -1);
]]>
</programlisting>
</informalexample>
</para>
<para>
The rule function is called when an application sets the PCM
format, and it refines the number of channels accordingly.
But an application may set the number of channels before
setting the format. Thus you also need to define the inverse rule:
<example>
<title>Example of Hardware Constraints for Formats</title>
<programlisting>
<![CDATA[
static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
struct snd_interval *c = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_CHANNELS);
struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
struct snd_mask fmt;
snd_mask_any(&fmt); /* Init the struct */
if (c->min < 2) {
fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
return snd_mask_refine(f, &fmt);
}
return 0;
}
]]>
</programlisting>
</example>
</para>
<para>
...and in the open callback:
@ -3321,8 +3321,8 @@ struct _snd_pcm_runtime {
<programlisting>
<![CDATA[
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT,
hw_rule_format_by_channels, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
-1);
hw_rule_format_by_channels, NULL,
SNDRV_PCM_HW_PARAM_CHANNELS, -1);
]]>
</programlisting>
</informalexample>

27
Documentation/EDID/HOWTO.txt
View File

@ -28,11 +28,30 @@ Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".
If you want to create your own EDID file, copy the file 1024x768.S and
replace the settings with your own data. The CRC value in the last line
If you want to create your own EDID file, copy the file 1024x768.S,
replace the settings with your own data and add a new target to the
Makefile. Please note that the EDID data structure expects the timing
values in a different way as compared to the standard X11 format.
X11:
HTimings: hdisp hsyncstart hsyncend htotal
VTimings: vdisp vsyncstart vsyncend vtotal
EDID:
#define XPIX hdisp
#define XBLANK htotal-hdisp
#define XOFFSET hsyncstart-hdisp
#define XPULSE hsyncend-hsyncstart
#define YPIX vdisp
#define YBLANK vtotal-vdisp
#define YOFFSET (63+(vsyncstart-vdisp))
#define YPULSE (63+(vsyncend-vsyncstart))
The CRC value in the last line
#define CRC 0x55
is a bit tricky. After a first version of the binary data set is
created, it must be be checked with the "edid-decode" utility which will
also is a bit tricky. After a first version of the binary data set is
created, it must be checked with the "edid-decode" utility which will
most probably complain about a wrong CRC. Fortunately, the utility also
displays the correct CRC which must then be inserted into the source
file. After the make procedure is repeated, the EDID data set is ready

18
Documentation/IPMI.txt
View File

@ -348,34 +348,40 @@ You can change this at module load time (for a module) with:
modprobe ipmi_si.o type=<type1>,<type2>....
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
irqs=<irq1>,<irq2>... trydefaults=[0|1]
irqs=<irq1>,<irq2>...
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...
kipmid_max_busy_us=<ustime1>,<ustime2>,...
unload_when_empty=[0|1]
trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1]
tryplatform=[0|1] trypci=[0|1]
Each of these except si_trydefaults is a list, the first item for the
Each of these except try... items is a list, the first item for the
first interface, second item for the second interface, etc.
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
defaults to "kcs".
If you specify si_addrs as non-zero for an interface, the driver will
If you specify addrs as non-zero for an interface, the driver will
use the memory address given as the address of the device. This
overrides si_ports.
If you specify si_ports as non-zero for an interface, the driver will
If you specify ports as non-zero for an interface, the driver will
use the I/O port given as the device address.
If you specify si_irqs as non-zero for an interface, the driver will
If you specify irqs as non-zero for an interface, the driver will
attempt to use the given interrupt for the device.
si_trydefaults sets whether the standard IPMI interface at 0xca2 and
trydefaults sets whether the standard IPMI interface at 0xca2 and
any interfaces specified by ACPE are tried. By default, the driver
tries it, set this value to zero to turn this off.
The other try... items disable discovery by their corresponding
names. These are all enabled by default, set them to zero to disable
them. The tryplatform disables openfirmware.
The next three parameters have to do with register layout. The
registers used by the interfaces may not appear at successive
locations and they may not be in 8-bit registers. These parameters

37
Documentation/PCI/MSI-HOWTO.txt
View File

@ -127,15 +127,42 @@ on the number of vectors that can be allocated; pci_enable_msi_block()
returns as soon as it finds any constraint that doesn't allow the
call to succeed.
4.2.3 pci_disable_msi
4.2.3 pci_enable_msi_block_auto
int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
This variation on pci_enable_msi() call allows a device driver to request
the maximum possible number of MSIs. The MSI specification only allows
interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
If this function returns a positive number, it indicates that it has
succeeded and the returned value is the number of allocated interrupts. In
this case, the function enables MSI on this device and updates dev->irq to
be the lowest of the new interrupts assigned to it. The other interrupts
assigned to the device are in the range dev->irq to dev->irq + returned
value - 1.
If this function returns a negative number, it indicates an error and
the driver should not attempt to request any more MSI interrupts for
this device.
If the device driver needs to know the number of interrupts the device
supports it can pass the pointer count where that number is stored. The
device driver must decide what action to take if pci_enable_msi_block_auto()
succeeds, but returns a value less than the number of interrupts supported.
If the device driver does not need to know the number of interrupts
supported, it can set the pointer count to NULL.
4.2.4 pci_disable_msi
void pci_disable_msi(struct pci_dev *dev)
This function should be used to undo the effect of pci_enable_msi() or
pci_enable_msi_block(). Calling it restores dev->irq to the pin-based
interrupt number and frees the previously allocated message signaled
interrupt(s). The interrupt may subsequently be assigned to another
device, so drivers should not cache the value of dev->irq.
pci_enable_msi_block() or pci_enable_msi_block_auto(). Calling it restores
dev->irq to the pin-based interrupt number and frees the previously
allocated message signaled interrupt(s). The interrupt may subsequently be
assigned to another device, so drivers should not cache the value of
dev->irq.
Before calling this function, a device driver must always call free_irq()
on any interrupt for which it previously called request_irq().

4
Documentation/acpi/enumeration.txt
View File

@ -63,8 +63,8 @@ from ACPI tables.
Currently the kernel is not able to automatically determine from which ACPI
device it should make the corresponding platform device so we need to add
the ACPI device explicitly to acpi_platform_device_ids list defined in
drivers/acpi/scan.c. This limitation is only for the platform devices, SPI
and I2C devices are created automatically as described below.
drivers/acpi/acpi_platform.c. This limitation is only for the platform
devices, SPI and I2C devices are created automatically as described below.
SPI serial bus support
~~~~~~~~~~~~~~~~~~~~~~

77
Documentation/acpi/scan_handlers.txt Normal file
View File

@ -0,0 +1,77 @@
ACPI Scan Handlers
Copyright (C) 2012, Intel Corporation
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
During system initialization and ACPI-based device hot-add, the ACPI namespace
is scanned in search of device objects that generally represent various pieces
of hardware. This causes a struct acpi_device object to be created and
registered with the driver core for every device object in the ACPI namespace
and the hierarchy of those struct acpi_device objects reflects the namespace
layout (i.e. parent device objects in the namespace are represented by parent
struct acpi_device objects and analogously for their children). Those struct
acpi_device objects are referred to as "device nodes" in what follows, but they
should not be confused with struct device_node objects used by the Device Trees
parsing code (although their role is analogous to the role of those objects).
During ACPI-based device hot-remove device nodes representing pieces of hardware
being removed are unregistered and deleted.
The core ACPI namespace scanning code in drivers/acpi/scan.c carries out basic
initialization of device nodes, such as retrieving common configuration
information from the device objects represented by them and populating them with
appropriate data, but some of them require additional handling after they have
been registered. For example, if the given device node represents a PCI host
bridge, its registration should cause the PCI bus under that bridge to be
enumerated and PCI devices on that bus to be registered with the driver core.
Similarly, if the device node represents a PCI interrupt link, it is necessary
to configure that link so that the kernel can use it.
Those additional configuration tasks usually depend on the type of the hardware
component represented by the given device node which can be determined on the
basis of the device node's hardware ID (HID). They are performed by objects
called ACPI scan handlers represented by the following structure:
struct acpi_scan_handler {
const struct acpi_device_id *ids;
struct list_head list_node;
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
};
where ids is the list of IDs of device nodes the given handler is supposed to
take care of, list_node is the hook to the global list of ACPI scan handlers
maintained by the ACPI core and the .attach() and .detach() callbacks are
executed, respectively, after registration of new device nodes and before
unregistration of device nodes the handler attached to previously.
The namespace scanning function, acpi_bus_scan(), first registers all of the
device nodes in the given namespace scope with the driver core. Then, it tries
to match a scan handler against each of them using the ids arrays of the
available scan handlers. If a matching scan handler is found, its .attach()
callback is executed for the given device node. If that callback returns 1,
that means that the handler has claimed the device node and is now responsible
for carrying out any additional configuration tasks related to it. It also will
be responsible for preparing the device node for unregistration in that case.
The device node's handler field is then populated with the address of the scan
handler that has claimed it.
If the .attach() callback returns 0, it means that the device node is not
interesting to the given scan handler and may be matched against the next scan
handler in the list. If it returns a (negative) error code, that means that
the namespace scan should be terminated due to a serious error. The error code
returned should then reflect the type of the error.
The namespace trimming function, acpi_bus_trim(), first executes .detach()
callbacks from the scan handlers of all device nodes in the given namespace
scope (if they have scan handlers). Next, it unregisters all of the device
nodes in that scope.
ACPI scan handlers can be added to the list maintained by the ACPI core with the
help of the acpi_scan_add_handler() function taking a pointer to the new scan
handler as an argument. The order in which scan handlers are added to the list
is the order in which they are matched against device nodes during namespace
scans.
All scan handles must be added to the list before acpi_bus_scan() is run for the
first time and they cannot be removed from it.

2
Documentation/arm64/memory.txt
View File

@ -35,6 +35,8 @@ ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap]
ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]

2
Documentation/atomic_ops.txt
View File

@ -253,6 +253,8 @@ This performs an atomic exchange operation on the atomic variable v, setting
the given new value. It returns the old value that the atomic variable v had
just before the operation.
atomic_xchg requires explicit memory barriers around the operation.
int atomic_cmpxchg(atomic_t *v, int old, int new);
This performs an atomic compare exchange operation on the atomic value v,

4
Documentation/backlight/lp855x-driver.txt
View File

@ -4,7 +4,7 @@ Kernel driver lp855x
Backlight driver for LP855x ICs
Supported chips:
Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
@ -24,7 +24,7 @@ Value : pwm based or register based
2) chip_id
The lp855x chip id.
Value : lp8550/lp8551/lp8552/lp8553/lp8556
Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
Platform data for lp855x
------------------------

58
Documentation/block/cfq-iosched.txt
View File

@ -102,6 +102,64 @@ processing of request. Therefore, increasing the value can imporve the
performace although this can cause the latency of some I/O to increase due
to more number of requests.
CFQ Group scheduling
====================
CFQ supports blkio cgroup and has "blkio." prefixed files in each
blkio cgroup directory. It is weight-based and there are four knobs
for configuration - weight[_device] and leaf_weight[_device].
Internal cgroup nodes (the ones with children) can also have tasks in
them, so the former two configure how much proportion the cgroup as a
whole is entitled to at its parent's level while the latter two
configure how much proportion the tasks in the cgroup have compared to
its direct children.
Another way to think about it is assuming that each internal node has
an implicit leaf child node which hosts all the tasks whose weight is
configured by leaf_weight[_device]. Let's assume a blkio hierarchy
composed of five cgroups - root, A, B, AA and AB - with the following
weights where the names represent the hierarchy.
weight leaf_weight
root : 125 125
A : 500 750
B : 250 500
AA : 500 500
AB : 1000 500
root never has a parent making its weight is meaningless. For backward
compatibility, weight is always kept in sync with leaf_weight. B, AA
and AB have no child and thus its tasks have no children cgroup to
compete with. They always get 100% of what the cgroup won at the
parent level. Considering only the weights which matter, the hierarchy
looks like the following.
root
/ | \
A B leaf
500 250 125
/ | \
AA AB leaf
500 1000 750
If all cgroups have active IOs and competing with each other, disk
time will be distributed like the following.
Distribution below root. The total active weight at this level is
A:500 + B:250 + C:125 = 875.
root-leaf : 125 / 875 =~ 14%
A : 500 / 875 =~ 57%
B(-leaf) : 250 / 875 =~ 28%
A has children and further distributes its 57% among the children and
the implicit leaf node. The total active weight at this level is
AA:500 + AB:1000 + A-leaf:750 = 2250.
A-leaf : ( 750 / 2250) * A =~ 19%
AA(-leaf) : ( 500 / 2250) * A =~ 12%
AB(-leaf) : (1000 / 2250) * A =~ 25%
CFQ IOPS Mode for group scheduling
===================================
Basic CFQ design is to provide priority based time slices. Higher priority

38
Documentation/blockdev/nbd.txt
View File

@ -4,43 +4,13 @@
can use a remote server as one of its block devices. So every time
the client computer wants to read, e.g., /dev/nb0, it sends a
request over TCP to the server, which will reply with the data read.
This can be used for stations with low disk space (or even diskless -
if you boot from floppy) to borrow disk space from another computer.
Unlike NFS, it is possible to put any filesystem on it, etc. It should
even be possible to use NBD as a root filesystem (I've never tried),
but it requires a user-level program to be in the initrd to start.
It also allows you to run block-device in user land (making server
and client physically the same computer, communicating using loopback).
Current state: It currently works. Network block device is stable.
I originally thought that it was impossible to swap over TCP. It
turned out not to be true - swapping over TCP now works and seems
to be deadlock-free, but it requires heavy patches into Linux's
network layer.
This can be used for stations with low disk space (or even diskless)
to borrow disk space from another computer.
Unlike NFS, it is possible to put any filesystem on it, etc.
For more information, or to download the nbd-client and nbd-server
tools, go to http://nbd.sf.net/.
Howto: To setup nbd, you can simply do the following:
First, serve a device or file from a remote server:
nbd-server <port-number> <device-or-file-to-serve-to-client>
e.g.,
root@server1 # nbd-server 1234 /dev/sdb1
(serves sdb1 partition on TCP port 1234)
Then, on the local (client) system:
nbd-client <server-name-or-IP> <server-port-number> /dev/nb[0-n]
e.g.,
root@client1 # nbd-client server1 1234 /dev/nb0
(creates the nb0 device on client1)
The nbd kernel module need only be installed on the client
system, as the nbd-server is completely in userspace. In fact,
the nbd-server has been successfully ported to other operating

2
Documentation/cgroups/00-INDEX
View File

@ -4,8 +4,6 @@ blkio-controller.txt
- Description for Block IO Controller, implementation and usage details.
cgroups.txt
- Control Groups definition, implementation details, examples and API.
cgroup_event_listener.c
- A user program for cgroup listener.
cpuacct.txt
- CPU Accounting Controller; account CPU usage for groups of tasks.
cpusets.txt

37
Documentation/cgroups/blkio-controller.txt
View File

@ -75,7 +75,7 @@ Throttling/Upper Limit policy
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
- Specify a bandwidth rate on particular device for root group. The format
for policy is "<major>:<minor> <byes_per_second>".
for policy is "<major>:<minor> <bytes_per_second>".
echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
@ -94,13 +94,11 @@ Throttling/Upper Limit policy
Hierarchical Cgroups
====================
- Currently none of the IO control policy supports hierarchical groups. But
cgroup interface does allow creation of hierarchical cgroups and internally
IO policies treat them as flat hierarchy.
- Currently only CFQ supports hierarchical groups. For throttling,
cgroup interface does allow creation of hierarchical cgroups and
internally it treats them as flat hierarchy.
So this patch will allow creation of cgroup hierarchcy but at the backend
everything will be treated as flat. So if somebody created a hierarchy like
as follows.
If somebody created a hierarchy like as follows.
root
/ \
@ -108,16 +106,20 @@ Hierarchical Cgroups
|
test3
CFQ and throttling will practically treat all groups at same level.
CFQ will handle the hierarchy correctly but and throttling will
practically treat all groups at same level. For details on CFQ
hierarchy support, refer to Documentation/block/cfq-iosched.txt.
Throttling will treat the hierarchy as if it looks like the
following.
pivot
/ / \ \
root test1 test2 test3
Down the line we can implement hierarchical accounting/control support
and also introduce a new cgroup file "use_hierarchy" which will control
whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
This is how memory controller also has implemented the things.
Nesting cgroups, while allowed, isn't officially supported and blkio
genereates warning when cgroups nest. Once throttling implements
hierarchy support, hierarchy will be supported and the warning will
be removed.
Various user visible config options
===================================
@ -172,6 +174,12 @@ Proportional weight policy files
dev weight
8:16 300
- blkio.leaf_weight[_device]
- Equivalents of blkio.weight[_device] for the purpose of
deciding how much weight tasks in the given cgroup has while
competing with the cgroup's child cgroups. For details,
please refer to Documentation/block/cfq-iosched.txt.
- blkio.time
- disk time allocated to cgroup per device in milliseconds. First
two fields specify the major and minor number of the device and
@ -279,6 +287,11 @@ Proportional weight policy files
and minor number of the device and third field specifies the number
of times a group was dequeued from a particular device.
- blkio.*_recursive
- Recursive version of various stats. These files show the
same information as their non-recursive counterparts but
include stats from all the descendant cgroups.
Throttling/Upper limit policy files
-----------------------------------
- blkio.throttle.read_bps_device

3
Documentation/cgroups/memcg_test.txt
View File

@ -399,8 +399,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
9.10 Memory thresholds
Memory controller implements memory thresholds using cgroups notification
API. You can use Documentation/cgroups/cgroup_event_listener.c to test
it.
API. You can use tools/cgroup/cgroup_event_listener.c to test it.
(Shell-A) Create cgroup and run event listener
# mkdir /cgroup/A

4
Documentation/coccinelle.txt
View File

@ -87,6 +87,10 @@ As any static code analyzer, Coccinelle produces false
positives. Thus, reports must be carefully checked, and patches
reviewed.
To enable verbose messages set the V= variable, for example:
make coccicheck MODE=report V=1
Using Coccinelle with a single semantic patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6
Documentation/cpu-freq/cpu-drivers.txt
View File

@ -111,6 +111,12 @@ policy->governor must contain the "default policy" for
For setting some of these values, the frequency table helpers might be
helpful. See the section 2 for more information on them.
SMP systems normally have same clock source for a group of cpus. For these the
.init() would be called only once for the first online cpu. Here the .init()
routine must initialize policy->cpus with mask of all possible cpus (Online +
Offline) that share the clock. Then the core would copy this mask onto
policy->related_cpus and will reset policy->cpus to carry only online cpus.
1.3 verify
------------

8
Documentation/cpu-freq/user-guide.txt
View File

@ -190,11 +190,11 @@ scaling_max_freq show the current "policy limits" (in
first set scaling_max_freq, then
scaling_min_freq.
affected_cpus : List of CPUs that require software coordination
of frequency.
affected_cpus : List of Online CPUs that require software
coordination of frequency.
related_cpus : List of CPUs that need some sort of frequency
coordination, whether software or hardware.
related_cpus : List of Online + Offline CPUs that need software
coordination of frequency.
scaling_driver : Hardware driver for cpufreq.

77
Documentation/device-mapper/cache-policies.txt Normal file
View File

@ -0,0 +1,77 @@
Guidance for writing policies
=============================
Try to keep transactionality out of it. The core is careful to
avoid asking about anything that is migrating. This is a pain, but
makes it easier to write the policies.
Mappings are loaded into the policy at construction time.
Every bio that is mapped by the target is referred to the policy.
The policy can return a simple HIT or MISS or issue a migration.
Currently there's no way for the policy to issue background work,
e.g. to start writing back dirty blocks that are going to be evicte
soon.
Because we map bios, rather than requests it's easy for the policy
to get fooled by many small bios. For this reason the core target
issues periodic ticks to the policy. It's suggested that the policy
doesn't update states (eg, hit counts) for a block more than once
for each tick. The core ticks by watching bios complete, and so
trying to see when the io scheduler has let the ios run.
Overview of supplied cache replacement policies
===============================================
multiqueue
----------
This policy is the default.
The multiqueue policy has two sets of 16 queues: one set for entries
waiting for the cache and another one for those in the cache.
Cache entries in the queues are aged based on logical time. Entry into
the cache is based on variable thresholds and queue selection is based
on hit count on entry. The policy aims to take different cache miss
costs into account and to adjust to varying load patterns automatically.
Message and constructor argument pairs are:
'sequential_threshold <#nr_sequential_ios>' and
'random_threshold <#nr_random_ios>'.
The sequential threshold indicates the number of contiguous I/Os
required before a stream is treated as sequential. The random threshold
is the number of intervening non-contiguous I/Os that must be seen
before the stream is treated as random again.
The sequential and random thresholds default to 512 and 4 respectively.
Large, sequential ios are probably better left on the origin device
since spindles tend to have good bandwidth. The io_tracker counts
contiguous I/Os to try to spot when the io is in one of these sequential
modes.
cleaner
-------
The cleaner writes back all dirty blocks in a cache to decommission it.
Examples
========
The syntax for a table is:
cache <metadata dev> <cache dev> <origin dev> <block size>
<#feature_args> [<feature arg>]*
<policy> <#policy_args> [<policy arg>]*
The syntax to send a message using the dmsetup command is:
dmsetup message <mapped device> 0 sequential_threshold 1024
dmsetup message <mapped device> 0 random_threshold 8
Using dmsetup:
dmsetup create blah --table "0 268435456 cache /dev/sdb /dev/sdc \
/dev/sdd 512 0 mq 4 sequential_threshold 1024 random_threshold 8"
creates a 128GB large mapped device named 'blah' with the
sequential threshold set to 1024 and the random_threshold set to 8.

243
Documentation/device-mapper/cache.txt Normal file
View File

@ -0,0 +1,243 @@
Introduction
============
dm-cache is a device mapper target written by Joe Thornber, Heinz
Mauelshagen, and Mike Snitzer.
It aims to improve performance of a block device (eg, a spindle) by
dynamically migrating some of its data to a faster, smaller device
(eg, an SSD).
This device-mapper solution allows us to insert this caching at
different levels of the dm stack, for instance above the data device for
a thin-provisioning pool. Caching solutions that are integrated more
closely with the virtual memory system should give better performance.
The target reuses the metadata library used in the thin-provisioning
library.
The decision as to what data to migrate and when is left to a plug-in
policy module. Several of these have been written as we experiment,
and we hope other people will contribute others for specific io
scenarios (eg. a vm image server).
Glossary
========
Migration - Movement of the primary copy of a logical block from one
device to the other.
Promotion - Migration from slow device to fast device.
Demotion - Migration from fast device to slow device.
The origin device always contains a copy of the logical block, which
may be out of date or kept in sync with the copy on the cache device
(depending on policy).
Design
======
Sub-devices
-----------
The target is constructed by passing three devices to it (along with
other parameters detailed later):
1. An origin device - the big, slow one.
2. A cache device - the small, fast one.
3. A small metadata device - records which blocks are in the cache,
which are dirty, and extra hints for use by the policy object.
This information could be put on the cache device, but having it
separate allows the volume manager to configure it differently,
e.g. as a mirror for extra robustness.
Fixed block size
----------------
The origin is divided up into blocks of a fixed size. This block size
is configurable when you first create the cache. Typically we've been
using block sizes of 256k - 1024k.
Having a fixed block size simplifies the target a lot. But it is
something of a compromise. For instance, a small part of a block may be
getting hit a lot, yet the whole block will be promoted to the cache.
So large block sizes are bad because they waste cache space. And small
block sizes are bad because they increase the amount of metadata (both
in core and on disk).
Writeback/writethrough
----------------------
The cache has two modes, writeback and writethrough.
If writeback, the default, is selected then a write to a block that is
cached will go only to the cache and the block will be marked dirty in
the metadata.
If writethrough is selected then a write to a cached block will not
complete until it has hit both the origin and cache devices. Clean
blocks should remain clean.
A simple cleaner policy is provided, which will clean (write back) all
dirty blocks in a cache. Useful for decommissioning a cache.
Migration throttling
--------------------
Migrating data between the origin and cache device uses bandwidth.
The user can set a throttle to prevent more than a certain amount of
migration occuring at any one time. Currently we're not taking any
account of normal io traffic going to the devices. More work needs
doing here to avoid migrating during those peak io moments.
For the time being, a message "migration_threshold <#sectors>"
can be used to set the maximum number of sectors being migrated,
the default being 204800 sectors (or 100MB).
Updating on-disk metadata
-------------------------
On-disk metadata is committed every time a REQ_SYNC or REQ_FUA bio is
written. If no such requests are made then commits will occur every
second. This means the cache behaves like a physical disk that has a
write cache (the same is true of the thin-provisioning target). If
power is lost you may lose some recent writes. The metadata should
always be consistent in spite of any crash.
The 'dirty' state for a cache block changes far too frequently for us
to keep updating it on the fly. So we treat it as a hint. In normal
operation it will be written when the dm device is suspended. If the
system crashes all cache blocks will be assumed dirty when restarted.
Per-block policy hints
----------------------
Policy plug-ins can store a chunk of data per cache block. It's up to
the policy how big this chunk is, but it should be kept small. Like the
dirty flags this data is lost if there's a crash so a safe fallback
value should always be possible.
For instance, the 'mq' policy, which is currently the default policy,
uses this facility to store the hit count of the cache blocks. If
there's a crash this information will be lost, which means the cache
may be less efficient until those hit counts are regenerated.
Policy hints affect performance, not correctness.
Policy messaging
----------------
Policies will have different tunables, specific to each one, so we
need a generic way of getting and setting these. Device-mapper
messages are used. Refer to cache-policies.txt.
Discard bitset resolution
-------------------------
We can avoid copying data during migration if we know the block has
been discarded. A prime example of this is when mkfs discards the
whole block device. We store a bitset tracking the discard state of
blocks. However, we allow this bitset to have a different block size
from the cache blocks. This is because we need to track the discard
state for all of the origin device (compare with the dirty bitset
which is just for the smaller cache device).
Target interface
================
Constructor
-----------
cache <metadata dev> <cache dev> <origin dev> <block size>
<#feature args> [<feature arg>]*
<policy> <#policy args> [policy args]*
metadata dev : fast device holding the persistent metadata
cache dev : fast device holding cached data blocks
origin dev : slow device holding original data blocks
block size : cache unit size in sectors
#feature args : number of feature arguments passed
feature args : writethrough. (The default is writeback.)
policy : the replacement policy to use
#policy args : an even number of arguments corresponding to
key/value pairs passed to the policy
policy args : key/value pairs passed to the policy
E.g. 'sequential_threshold 1024'
See cache-policies.txt for details.
Optional feature arguments are:
writethrough : write through caching that prohibits cache block
content from being different from origin block content.
Without this argument, the default behaviour is to write
back cache block contents later for performance reasons,
so they may differ from the corresponding origin blocks.
A policy called 'default' is always registered. This is an alias for
the policy we currently think is giving best all round performance.
As the default policy could vary between kernels, if you are relying on
the characteristics of a specific policy, always request it by name.
Status
------
<#used metadata blocks>/<#total metadata blocks> <#read hits> <#read misses>
<#write hits> <#write misses> <#demotions> <#promotions> <#blocks in cache>
<#dirty> <#features> <features>* <#core args> <core args>* <#policy args>
<policy args>*
#used metadata blocks : Number of metadata blocks used
#total metadata blocks : Total number of metadata blocks
#read hits : Number of times a READ bio has been mapped
to the cache
#read misses : Number of times a READ bio has been mapped
to the origin
#write hits : Number of times a WRITE bio has been mapped
to the cache
#write misses : Number of times a WRITE bio has been
mapped to the origin
#demotions : Number of times a block has been removed
from the cache
#promotions : Number of times a block has been moved to
the cache
#blocks in cache : Number of blocks resident in the cache
#dirty : Number of blocks in the cache that differ
from the origin
#feature args : Number of feature args to follow
feature args : 'writethrough' (optional)
#core args : Number of core arguments (must be even)
core args : Key/value pairs for tuning the core
e.g. migration_threshold
#policy args : Number of policy arguments to follow (must be even)
policy args : Key/value pairs
e.g. 'sequential_threshold 1024
Messages
--------
Policies will have different tunables, specific to each one, so we
need a generic way of getting and setting these. Device-mapper
messages are used. (A sysfs interface would also be possible.)
The message format is:
<key> <value>
E.g.
dmsetup message my_cache 0 sequential_threshold 1024
Examples
========
The test suite can be found here:
https://github.com/jthornber/thinp-test-suite
dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
/dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0'
dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
/dev/mapper/ssd /dev/mapper/origin 1024 1 writeback \
mq 4 sequential_threshold 1024 random_threshold 8'

1
Documentation/device-mapper/dm-raid.txt
View File

@ -141,3 +141,4 @@ Version History
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.2 Fix/improve redundancy checking for RAID10

24
Documentation/devicetree/bindings/arc/interrupts.txt Normal file
View File

@ -0,0 +1,24 @@
* ARC700 incore Interrupt Controller
The core interrupt controller provides 32 prioritised interrupts (2 levels)
to ARC700 core.
Properties:
- compatible: "snps,arc700-intc"
- interrupt-controller: This is an interrupt controller.
- #interrupt-cells: Must be <1>.
Single Cell "interrupts" property of a device specifies the IRQ number
between 0 to 31
intc accessed via the special ARC AUX register interface, hence "reg" property
is not specified.
Example:
intc: interrupt-controller {
compatible = "snps,arc700-intc";
interrupt-controller;
#interrupt-cells = <1>;
};

2
Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
View File

@ -3,9 +3,11 @@ Altera SOCFPGA System Manager
Required properties:
- compatible : "altr,sys-mgr"
- reg : Should contain 1 register ranges(address and length)
- cpu1-start-addr : CPU1 start address in hex.
Example:
sysmgr@ffd08000 {
compatible = "altr,sys-mgr";
reg = <0xffd08000 0x1000>;
cpu1-start-addr = <0xffd080c4>;
};

7
Documentation/devicetree/bindings/arm/arch_timer.txt
View File

@ -1,13 +1,14 @@
* ARM architected timer
ARM Cortex-A7 and Cortex-A15 have a per-core architected timer, which
provides per-cpu timers.
ARM cores may have a per-core architected timer, which provides per-cpu timers.
The timer is attached to a GIC to deliver its per-processor interrupts.
** Timer node properties:
- compatible : Should at least contain "arm,armv7-timer".
- compatible : Should at least contain one of
"arm,armv7-timer"
"arm,armv8-timer"
- interrupts : Interrupt list for secure, non-secure, virtual and
hypervisor timers, in that order.

6
Documentation/devicetree/bindings/arm/armadeus.txt Normal file
View File

@ -0,0 +1,6 @@
Armadeus i.MX Platforms Device Tree Bindings
-----------------------------------------------
APF51: i.MX51 based module.
Required root node properties:
- compatible = "armadeus,imx51-apf51", "fsl,imx51";

2
Documentation/devicetree/bindings/arm/atmel-aic.txt
View File

@ -4,7 +4,7 @@ Required properties:
- compatible: Should be "atmel,<chip>-aic"
- interrupt-controller: Identifies the node as an interrupt controller.
- interrupt-parent: For single AIC system, it is an empty property.
- #interrupt-cells: The number of cells to define the interrupts. It sould be 3.
- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:

8
Documentation/devicetree/bindings/arm/fsl.txt
View File

@ -5,6 +5,14 @@ i.MX23 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx23-evk", "fsl,imx23";
i.MX25 Product Development Kit
Required root node properties:
- compatible = "fsl,imx25-pdk", "fsl,imx25";
i.MX27 Product Development Kit
Required root node properties:
- compatible = "fsl,imx27-pdk", "fsl,imx27";
i.MX28 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx28-evk", "fsl,imx28";

4
Documentation/devicetree/bindings/arm/gic.txt
View File

@ -42,7 +42,7 @@ Main node required properties:
Optional
- interrupts : Interrupt source of the parent interrupt controller on
secondary GICs, or VGIC maintainance interrupt on primary GIC (see
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
below).
- cpu-offset : per-cpu offset within the distributor and cpu interface
@ -74,7 +74,7 @@ Required properties:
virtual interface control register base and size. The 2nd additional
region is the GIC virtual cpu interface register base and size.
- interrupts : VGIC maintainance interrupt.
- interrupts : VGIC maintenance interrupt.
Example:

27
Documentation/devicetree/bindings/arm/kirkwood.txt Normal file
View File

@ -0,0 +1,27 @@
Marvell Kirkwood Platforms Device Tree Bindings
-----------------------------------------------
Boards with a SoC of the Marvell Kirkwood
shall have the following property:
Required root node property:
compatible: must contain "marvell,kirkwood";
In order to support the kirkwood cpufreq driver, there must be a node
cpus/cpu@0 with three clocks, "cpu_clk", "ddrclk" and "powersave",
where the "powersave" clock is a gating clock used to switch the CPU
between the "cpu_clk" and the "ddrclk".
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "marvell,sheeva-88SV131";
clocks = <&core_clk 1>, <&core_clk 3>, <&gate_clk 11>;
clock-names = "cpu_clk", "ddrclk", "powersave";
};

6
Documentation/devicetree/bindings/arm/omap/omap.txt
View File

@ -39,16 +39,16 @@ Boards:
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
- OMAP4 SDP : Software Developement Board
- OMAP4 SDP : Software Development Board
compatible = "ti,omap4-sdp", "ti,omap4430"
- OMAP4 PandaBoard : Low cost community board
compatible = "ti,omap4-panda", "ti,omap4430"
- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
compatible = "ti,omap3-evm", "ti,omap3"
- AM335X EVM : Software Developement Board for AM335x
- AM335X EVM : Software Development Board for AM335x
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
- AM335X Bone : Low cost community board

55
Documentation/devicetree/bindings/arm/psci.txt Normal file
View File

@ -0,0 +1,55 @@
* Power State Coordination Interface (PSCI)
Firmware implementing the PSCI functions described in ARM document number
ARM DEN 0022A ("Power State Coordination Interface System Software on ARM
processors") can be used by Linux to initiate various CPU-centric power
operations.
Issue A of the specification describes functions for CPU suspend, hotplug
and migration of secure software.
Functions are invoked by trapping to the privilege level of the PSCI
firmware (specified as part of the binding below) and passing arguments
in a manner similar to that specified by AAPCS:
r0 => 32-bit Function ID / return value
{r1 - r3} => Parameters
Note that the immediate field of the trapping instruction must be set
to #0.
Main node required properties:
- compatible : Must be "arm,psci"
- method : The method of calling the PSCI firmware. Permitted
values are:
"smc" : SMC #0, with the register assignments specified
in this binding.
"hvc" : HVC #0, with the register assignments specified
in this binding.
Main node optional properties:
- cpu_suspend : Function ID for CPU_SUSPEND operation
- cpu_off : Function ID for CPU_OFF operation
- cpu_on : Function ID for CPU_ON operation
- migrate : Function ID for MIGRATE operation
Example:
psci {
compatible = "arm,psci";
method = "smc";
cpu_suspend = <0x95c10000>;
cpu_off = <0x95c10001>;
cpu_on = <0x95c10002>;
migrate = <0x95c10003>;
};

10
Documentation/devicetree/bindings/arm/sirf.txt
View File

@ -1,3 +1,9 @@
prima2 "cb" evaluation board
CSR SiRFprimaII and SiRFmarco device tree bindings.
========================================
Required root node properties:
- compatible = "sirf,prima2-cb", "sirf,prima2";
- compatible:
- "sirf,prima2-cb" : prima2 "cb" evaluation board
- "sirf,marco-cb" : marco "cb" evaluation board
- "sirf,prima2" : prima2 device based board
- "sirf,marco" : marco device based board

27
Documentation/devicetree/bindings/arm/ste-nomadik.txt Normal file
View File

@ -0,0 +1,27 @@
ST-Ericsson Nomadik Device Tree Bindings
For various board the "board" node may contain specific properties
that pertain to this particular board, such as board-specific GPIOs.
Boards with the Nomadik SoC include:
S8815 "MiniKit" manufactured by Calao Systems:
Required root node property:
compatible="calaosystems,usb-s8815";
Required node: usb-s8815
Example:
usb-s8815 {
ethernet-gpio {
gpios = <&gpio3 19 0x1>;
interrupts = <19 0x1>;
interrupt-parent = <&gpio3>;
};
mmcsd-gpio {
gpios = <&gpio3 16 0x1>;
};
};

32
Documentation/devicetree/bindings/arm/tegra.txt
View File

@ -1,14 +1,34 @@
NVIDIA Tegra device tree bindings
-------------------------------------------
Boards with the tegra20 SoC shall have the following properties:
SoCs
-------------------------------------------
Required root node property:
Each device tree must specify which Tegra SoC it uses, using one of the
following compatible values:
compatible = "nvidia,tegra20";
nvidia,tegra20
nvidia,tegra30
Boards with the tegra30 SoC shall have the following properties:
Boards
-------------------------------------------
Required root node property:
Each device tree must specify which one or more of the following
board-specific compatible values:
compatible = "nvidia,tegra30";
ad,medcom-wide
ad,plutux
ad,tamonten
ad,tec
compal,paz00
compulab,trimslice
nvidia,beaver
nvidia,cardhu
nvidia,cardhu-a02
nvidia,cardhu-a04
nvidia,harmony
nvidia,seaboard
nvidia,ventana
nvidia,whistler
toradex,colibri_t20-512
toradex,iris

8
Documentation/devicetree/bindings/arm/vt8500.txt
View File

@ -12,3 +12,11 @@ compatible = "wm,wm8505";
Boards with the Wondermedia WM8650 SoC shall have the following properties:
Required root node property:
compatible = "wm,wm8650";
Boards with the Wondermedia WM8750 SoC shall have the following properties:
Required root node property:
compatible = "wm,wm8750";
Boards with the Wondermedia WM8850 SoC shall have the following properties:
Required root node property:
compatible = "wm,wm8850";

84
Documentation/devicetree/bindings/bus/ti-gpmc.txt Normal file
View File

@ -0,0 +1,84 @@
Device tree bindings for OMAP general purpose memory controllers (GPMC)
The actual devices are instantiated from the child nodes of a GPMC node.
Required properties:
- compatible: Should be set to one of the following:
ti,omap2420-gpmc (omap2420)
ti,omap2430-gpmc (omap2430)
ti,omap3430-gpmc (omap3430 & omap3630)
ti,omap4430-gpmc (omap4430 & omap4460 & omap543x)
ti,am3352-gpmc (am335x devices)
- reg: A resource specifier for the register space
(see the example below)
- ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
completed.
- #address-cells: Must be set to 2 to allow memory address translation
- #size-cells: Must be set to 1 to allow CS address passing
- gpmc,num-cs: The maximum number of chip-select lines that controller
can support.
- gpmc,num-waitpins: The maximum number of wait pins that controller can
support.
- ranges: Must be set up to reflect the memory layout with four
integer values for each chip-select line in use:
<cs-number> 0 <physical address of mapping> <size>
Currently, calculated values derived from the contents
of the per-CS register GPMC_CONFIG7 (as set up by the
bootloader) are used for the physical address decoding.
As this will change in the future, filling correct
values here is a requirement.
Timing properties for child nodes. All are optional and default to 0.
- gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
Chip-select signal timings corresponding to GPMC_CONFIG2:
- gpmc,cs-on: Assertion time
- gpmc,cs-rd-off: Read deassertion time
- gpmc,cs-wr-off: Write deassertion time
ADV signal timings corresponding to GPMC_CONFIG3:
- gpmc,adv-on: Assertion time
- gpmc,adv-rd-off: Read deassertion time
- gpmc,adv-wr-off: Write deassertion time
WE signals timings corresponding to GPMC_CONFIG4:
- gpmc,we-on: Assertion time
- gpmc,we-off: Deassertion time
OE signals timings corresponding to GPMC_CONFIG4:
- gpmc,oe-on: Assertion time
- gpmc,oe-off: Deassertion time
Access time and cycle time timings corresponding to GPMC_CONFIG5:
- gpmc,page-burst-access: Multiple access word delay
- gpmc,access: Start-cycle to first data valid delay
- gpmc,rd-cycle: Total read cycle time
- gpmc,wr-cycle: Total write cycle time
The following are only applicable to OMAP3+ and AM335x:
- gpmc,wr-access
- gpmc,wr-data-mux-bus
Example for an AM33xx board:
gpmc: gpmc@50000000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
reg = <0x50000000 0x2000>;
interrupts = <100>;
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
/* child nodes go here */
};

91
Documentation/devicetree/bindings/clock/imx31-clock.txt Normal file
View File

@ -0,0 +1,91 @@
* Clock bindings for Freescale i.MX31
Required properties:
- compatible: Should be "fsl,imx31-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.MX31
clocks and IDs.
Clock ID
-----------------------
dummy 0
ckih 1
ckil 2
mpll 3
spll 4
upll 5
mcu_main 6
hsp 7
ahb 8
nfc 9
ipg 10
per_div 11
per 12
csi_sel 13
fir_sel 14
csi_div 15
usb_div_pre 16
usb_div_post 17
fir_div_pre 18
fir_div_post 19
sdhc1_gate 20
sdhc2_gate 21
gpt_gate 22
epit1_gate 23
epit2_gate 24
iim_gate 25
ata_gate 26
sdma_gate 27
cspi3_gate 28
rng_gate 29
uart1_gate 30
uart2_gate 31
ssi1_gate 32
i2c1_gate 33
i2c2_gate 34
i2c3_gate 35
hantro_gate 36
mstick1_gate 37
mstick2_gate 38
csi_gate 39
rtc_gate 40
wdog_gate 41
pwm_gate 42
sim_gate 43
ect_gate 44
usb_gate 45
kpp_gate 46
ipu_gate 47
uart3_gate 48
uart4_gate 49
uart5_gate 50
owire_gate 51
ssi2_gate 52
cspi1_gate 53
cspi2_gate 54
gacc_gate 55
emi_gate 56
rtic_gate 57
firi_gate 58
Examples:
clks: ccm@53f80000{
compatible = "fsl,imx31-ccm";
reg = <0x53f80000 0x4000>;
interrupts = <0 31 0x04 0 53 0x04>;
#clock-cells = <1>;
};
uart1: serial@43f90000 {
compatible = "fsl,imx31-uart", "fsl,imx21-uart";
reg = <0x43f90000 0x4000>;
interrupts = <45>;
clocks = <&clks 10>, <&clks 30>;
clock-names = "ipg", "per";
status = "disabled";
};

1
Documentation/devicetree/bindings/clock/imx5-clock.txt
View File

@ -171,6 +171,7 @@ clocks and IDs.
can_sel 156
can1_serial_gate 157
can1_ipg_gate 158
owire_gate 159
Examples (for mx53):

2
Documentation/devicetree/bindings/clock/imx6q-clock.txt
View File

@ -203,6 +203,8 @@ clocks and IDs.
pcie_ref 188
pcie_ref_125m 189
enet_ref 190
usbphy1_gate 191
usbphy2_gate 192
Examples:

2
Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
View File

@ -89,7 +89,7 @@ ID Clock Peripheral
16 xor1 XOR DMA 1
17 crypto CESA engine
18 pex1 PCIe Cntrl 1
19 ge1 Gigabit Ethernet 0
19 ge1 Gigabit Ethernet 1
20 tdm Time Division Mplx
Required properties:

205
Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt Normal file
View File

@ -0,0 +1,205 @@
NVIDIA Tegra20 Clock And Reset Controller
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
for muxing and gating Tegra's clocks, and setting their rates.
Required properties :
- compatible : Should be "nvidia,tegra20-car"
- reg : Should contain CAR registers location and length
- clocks : Should contain phandle and clock specifiers for two clocks:
the 32 KHz "32k_in", and the board-specific oscillator "osc".
- #clock-cells : Should be 1.
In clock consumers, this cell represents the clock ID exposed by the CAR.
The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
registers. These IDs often match those in the CAR's RST_DEVICES registers,
but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
this case, those clocks are assigned IDs above 95 in order to highlight
this issue. Implementations that interpret these clock IDs as bit values
within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
explicitly handle these special cases.
The balance of the clocks controlled by the CAR are assigned IDs of 96 and
above.
0 cpu
1 unassigned
2 unassigned
3 ac97
4 rtc
5 tmr
6 uart1
7 unassigned (register bit affects uart2 and vfir)
8 gpio
9 sdmmc2
10 unassigned (register bit affects spdif_in and spdif_out)
11 i2s1
12 i2c1
13 ndflash
14 sdmmc1
15 sdmmc4
16 twc
17 pwm
18 i2s2
19 epp
20 unassigned (register bit affects vi and vi_sensor)
21 2d
22 usbd
23 isp
24 3d
25 ide
26 disp2
27 disp1
28 host1x
29 vcp
30 unassigned
31 cache2
32 mem
33 ahbdma
34 apbdma
35 unassigned
36 kbc
37 stat_mon
38 pmc
39 fuse
40 kfuse
41 sbc1
42 snor
43 spi1
44 sbc2
45 xio
46 sbc3
47 dvc
48 dsi
49 unassigned (register bit affects tvo and cve)
50 mipi
51 hdmi
52 csi
53 tvdac
54 i2c2
55 uart3
56 unassigned
57 emc
58 usb2
59 usb3
60 mpe
61 vde
62 bsea
63 bsev
64 speedo
65 uart4
66 uart5
67 i2c3
68 sbc4
69 sdmmc3
70 pcie
71 owr
72 afi
73 csite
74 unassigned
75 avpucq
76 la
77 unassigned
78 unassigned
79 unassigned
80 unassigned
81 unassigned
82 unassigned
83 unassigned
84 irama
85 iramb
86 iramc
87 iramd
88 cram2
89 audio_2x a/k/a audio_2x_sync_clk
90 clk_d
91 unassigned
92 sus
93 cdev1
94 cdev2
95 unassigned
96 uart2
97 vfir
98 spdif_in
99 spdif_out
100 vi
101 vi_sensor
102 tvo
103 cve
104 osc
105 clk_32k a/k/a clk_s
106 clk_m
107 sclk
108 cclk
109 hclk
110 pclk
111 blink
112 pll_a
113 pll_a_out0
114 pll_c
115 pll_c_out1
116 pll_d
117 pll_d_out0
118 pll_e
119 pll_m
120 pll_m_out1
121 pll_p
122 pll_p_out1
123 pll_p_out2
124 pll_p_out3
125 pll_p_out4
126 pll_s
127 pll_u
128 pll_x
129 cop a/k/a avp
130 audio a/k/a audio_sync_clk
131 pll_ref
132 twd
Example SoC include file:
/ {
tegra_car: clock {
compatible = "nvidia,tegra20-car";
reg = <0x60006000 0x1000>;
#clock-cells = <1>;
};
usb@c5004000 {
clocks = <&tegra_car 58>; /* usb2 */
};
};
Example board file:
/ {
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
osc: clock@0 {
compatible = "fixed-clock";
reg = <0>;
#clock-cells = <0>;
clock-frequency = <12000000>;
};
clk_32k: clock@1 {
compatible = "fixed-clock";
reg = <1>;
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
&tegra_car {
clocks = <&clk_32k> <&osc>;
};
};

262
Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt Normal file
View File

@ -0,0 +1,262 @@
NVIDIA Tegra30 Clock And Reset Controller
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
for muxing and gating Tegra's clocks, and setting their rates.
Required properties :
- compatible : Should be "nvidia,tegra30-car"
- reg : Should contain CAR registers location and length
- clocks : Should contain phandle and clock specifiers for two clocks:
the 32 KHz "32k_in", and the board-specific oscillator "osc".
- #clock-cells : Should be 1.
In clock consumers, this cell represents the clock ID exposed by the CAR.
The first 130 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
registers. These IDs often match those in the CAR's RST_DEVICES registers,
but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
this case, those clocks are assigned IDs above 160 in order to highlight
this issue. Implementations that interpret these clock IDs as bit values
within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
explicitly handle these special cases.
The balance of the clocks controlled by the CAR are assigned IDs of 160 and
above.
0 cpu
1 unassigned
2 unassigned
3 unassigned
4 rtc
5 timer
6 uarta
7 unassigned (register bit affects uartb and vfir)
8 gpio
9 sdmmc2
10 unassigned (register bit affects spdif_in and spdif_out)
11 i2s1
12 i2c1
13 ndflash
14 sdmmc1
15 sdmmc4
16 unassigned
17 pwm
18 i2s2
19 epp
20 unassigned (register bit affects vi and vi_sensor)
21 2d
22 usbd
23 isp
24 3d
25 unassigned
26 disp2
27 disp1
28 host1x
29 vcp
30 i2s0
31 cop_cache
32 mc
33 ahbdma
34 apbdma
35 unassigned
36 kbc
37 statmon
38 pmc
39 unassigned (register bit affects fuse and fuse_burn)
40 kfuse
41 sbc1
42 nor
43 unassigned
44 sbc2
45 unassigned
46 sbc3
47 i2c5
48 dsia
49 unassigned (register bit affects cve and tvo)
50 mipi
51 hdmi
52 csi
53 tvdac
54 i2c2
55 uartc
56 unassigned
57 emc
58 usb2
59 usb3
60 mpe
61 vde
62 bsea
63 bsev
64 speedo
65 uartd
66 uarte
67 i2c3
68 sbc4
69 sdmmc3
70 pcie
71 owr
72 afi
73 csite
74 pciex
75 avpucq
76 la
77 unassigned
78 unassigned
79 dtv
80 ndspeed
81 i2cslow
82 dsib
83 unassigned
84 irama
85 iramb
86 iramc
87 iramd
88 cram2
89 unassigned
90 audio_2x a/k/a audio_2x_sync_clk
91 unassigned
92 csus
93 cdev2
94 cdev1
95 unassigned
96 cpu_g
97 cpu_lp
98 3d2
99 mselect
100 tsensor
101 i2s3
102 i2s4
103 i2c4
104 sbc5
105 sbc6
106 d_audio
107 apbif
108 dam0
109 dam1
110 dam2
111 hda2codec_2x
112 atomics
113 audio0_2x
114 audio1_2x
115 audio2_2x
116 audio3_2x
117 audio4_2x
118 audio5_2x
119 actmon
120 extern1
121 extern2
122 extern3
123 sata_oob
124 sata
125 hda
127 se
128 hda2hdmi
129 sata_cold
160 uartb
161 vfir
162 spdif_in
163 spdif_out
164 vi
165 vi_sensor
166 fuse
167 fuse_burn
168 cve
169 tvo
170 clk_32k
171 clk_m
172 clk_m_div2
173 clk_m_div4
174 pll_ref
175 pll_c
176 pll_c_out1
177 pll_m
178 pll_m_out1
179 pll_p
180 pll_p_out1
181 pll_p_out2
182 pll_p_out3
183 pll_p_out4
184 pll_a
185 pll_a_out0
186 pll_d
187 pll_d_out0
188 pll_d2
189 pll_d2_out0
190 pll_u
191 pll_x
192 pll_x_out0
193 pll_e
194 spdif_in_sync
195 i2s0_sync
196 i2s1_sync
197 i2s2_sync
198 i2s3_sync
199 i2s4_sync
200 vimclk
201 audio0
202 audio1
203 audio2
204 audio3
205 audio4
206 audio5
207 clk_out_1 (extern1)
208 clk_out_2 (extern2)
209 clk_out_3 (extern3)
210 sclk
211 blink
212 cclk_g
213 cclk_lp
214 twd
215 cml0
216 cml1
217 hclk
218 pclk
Example SoC include file:
/ {
tegra_car: clock {
compatible = "nvidia,tegra30-car";
reg = <0x60006000 0x1000>;
#clock-cells = <1>;
};
usb@c5004000 {
clocks = <&tegra_car 58>; /* usb2 */
};
};
Example board file:
/ {
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
osc: clock@0 {
compatible = "fixed-clock";
reg = <0>;
#clock-cells = <0>;
clock-frequency = <12000000>;
};
clk_32k: clock@1 {
compatible = "fixed-clock";
reg = <1>;
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
&tegra_car {
clocks = <&clk_32k> <&osc>;
};
};

73
Documentation/devicetree/bindings/clock/prima2-clock.txt Normal file
View File

@ -0,0 +1,73 @@
* Clock bindings for CSR SiRFprimaII
Required properties:
- compatible: Should be "sirf,prima2-clkc"
- reg: Address and length of the register set
- interrupts: Should contain clock controller 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 prima2
clocks and IDs.
Clock ID
---------------------------
rtc 0
osc 1
pll1 2
pll2 3
pll3 4
mem 5
sys 6
security 7
dsp 8
gps 9
mf 10
io 11
cpu 12
uart0 13
uart1 14
uart2 15
tsc 16
i2c0 17
i2c1 18
spi0 19
spi1 20
pwmc 21
efuse 22
pulse 23
dmac0 24
dmac1 25
nand 26
audio 27
usp0 28
usp1 29
usp2 30
vip 31
gfx 32
mm 33
lcd 34
vpp 35
mmc01 36
mmc23 37
mmc45 38
usbpll 39
usb0 40
usb1 41
Examples:
clks: clock-controller@88000000 {
compatible = "sirf,prima2-clkc";
reg = <0x88000000 0x1000>;
interrupts = <3>;
#clock-cells = <1>;
};
i2c0: i2c@b00e0000 {
cell-index = <0>;
compatible = "sirf,prima2-i2c";
reg = <0xb00e0000 0x10000>;
interrupts = <24>;
clocks = <&clks 17>;
};

12
Documentation/devicetree/bindings/crypto/fsl-sec4.txt
View File

@ -54,8 +54,13 @@ PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0". Also includes SEC
ERA versions (optional) with which the device is compatible.
Definition: Must include "fsl,sec-v4.0"
- fsl,sec-era
Usage: optional
Value type: <u32>
Definition: A standard property. Define the 'ERA' of the SEC
device.
- #address-cells
Usage: required
@ -107,7 +112,8 @@ PROPERTIES
EXAMPLE
crypto@300000 {
compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
compatible = "fsl,sec-v4.0";
fsl,sec-era = <2>;
#address-cells = <1>;
#size-cells = <1>;
reg = <0x300000 0x10000>;

21
Documentation/devicetree/bindings/dma/arm-pl330.txt
View File

@ -10,7 +10,11 @@ Required properties:
- interrupts: interrupt number to the cpu.
Optional properties:
- dma-coherent : Present if dma operations are coherent
- dma-coherent : Present if dma operations are coherent
- #dma-cells: must be <1>. used to represent the number of integer
cells in the dmas property of client device.
- dma-channels: contains the total number of DMA channels supported by the DMAC
- dma-requests: contains the total number of DMA requests supported by the DMAC
Example:
@ -18,16 +22,23 @@ Example:
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <99>;
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
mem-to-dev) should specify the DMA channel numbers using a two-value pair
mem-to-dev) should specify the DMA channel numbers and dma channel names
as shown below.
[property name] = <[phandle of the dma controller] [dma request id]>;
[property name] = <[dma channel name]>
where 'dma request id' is the dma request number which is connected
to the client controller. The 'property name' is recommended to be
of the form <name>-dma-channel.
to the client controller. The 'property name' 'dmas' and 'dma-names'
as required by the generic dma device tree binding helpers. The dma
names correspond 1:1 with the dma request ids in the dmas property.
Example: tx-dma-channel = <&pdma0 12>;
Example: dmas = <&pdma0 12
&pdma1 11>;
dma-names = "tx", "rx";

81
Documentation/devicetree/bindings/dma/dma.txt Normal file
View File

@ -0,0 +1,81 @@
* Generic DMA Controller and DMA request bindings
Generic binding to provide a way for a driver using DMA Engine to retrieve the
DMA request or channel information that goes from a hardware device to a DMA
controller.
* DMA controller
Required property:
- #dma-cells: Must be at least 1. Used to provide DMA controller
specific information. See DMA client binding below for
more details.
Optional properties:
- dma-channels: Number of DMA channels supported by the controller.
- dma-requests: Number of DMA requests signals supported by the
controller.
Example:
dma: dma@48000000 {
compatible = "ti,omap-sdma";
reg = <0x48000000 0x1000>;
interrupts = <0 12 0x4
0 13 0x4
0 14 0x4
0 15 0x4>;
#dma-cells = <1>;
dma-channels = <32>;
dma-requests = <127>;
};
* DMA client
Client drivers should specify the DMA property using a phandle to the controller
followed by DMA controller specific data.
Required property:
- dmas: List of one or more DMA specifiers, each consisting of
- A phandle pointing to DMA controller node
- A number of integer cells, as determined by the
#dma-cells property in the node referenced by phandle
containing DMA controller specific information. This
typically contains a DMA request line number or a
channel number, but can contain any data that is used
required for configuring a channel.
- dma-names: Contains one identifier string for each DMA specifier in
the dmas property. The specific strings that can be used
are defined in the binding of the DMA client device.
Multiple DMA specifiers can be used to represent
alternatives and in this case the dma-names for those
DMA specifiers must be identical (see examples).
Examples:
1. A device with one DMA read channel, one DMA write channel:
i2c1: i2c@1 {
...
dmas = <&dma 2 /* read channel */
&dma 3>; /* write channel */
dma-names = "rx", "tx";
...
};
2. A single read-write channel with three alternative DMA controllers:
dmas = <&dma1 5
&dma2 7
&dma3 2>;
dma-names = "rx-tx", "rx-tx", "rx-tx";
3. A device with three channels, one of which has two alternatives:
dmas = <&dma1 2 /* read channel */
&dma1 3 /* write channel */
&dma2 0 /* error read */
&dma3 0>; /* alternative error read */
dma-names = "rx", "tx", "error", "error";

50
Documentation/devicetree/bindings/dma/snps-dma.txt
View File

@ -3,15 +3,61 @@
Required properties:
- compatible: "snps,dma-spear1340"
- reg: Address range of the DMAC registers
- interrupt: Should contain the DMAC interrupt number
- dma-channels: Number of channels supported by hardware
- dma-requests: Number of DMA request lines supported, up to 16
- dma-masters: Number of AHB masters supported by the controller
- #dma-cells: must be <3>
- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
increase from chan n->0
- block_size: Maximum block size supported by the controller
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
Optional properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
Example:
dma@fc000000 {
dmahost: dma@fc000000 {
compatible = "snps,dma-spear1340";
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
dma-channels = <8>;
dma-requests = <16>;
dma-masters = <2>;
#dma-cells = <3>;
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
data_width = <3 3 0 0>;
};
DMA clients connected to the Designware DMA controller must use the format
described in the dma.txt file, using a four-cell specifier for each channel.
The four cells in order are:
1. A phandle pointing to the DMA controller
2. The DMA request line number
3. Source master for transfers on allocated channel
4. Destination master for transfers on allocated channel
Example:
serial@e0000000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xe0000000 0x1000>;
interrupts = <0 35 0x4>;
status = "disabled";
dmas = <&dmahost 12 0 1>,
<&dmahost 13 0 1 0>;
dma-names = "rx", "rx";
};

22
Documentation/devicetree/bindings/drm/exynos/g2d.txt Normal file
View File

@ -0,0 +1,22 @@
Samsung 2D Graphic Accelerator using DRM frame work
Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
We set the drawing-context registers for configuring rendering parameters and
then start rendering.
This driver is for SOCs which contain G2D IPs with version 4.1.
Required properties:
-compatible:
should be "samsung,exynos-g2d-41".
-reg:
physical base address of the controller and length
of memory mapped region.
-interrupts:
interrupt combiner values.
Example:
g2d {
compatible = "samsung,exynos-g2d-41";
reg = <0x10850000 0x1000>;
interrupts = <0 91 0>;
};

59
Documentation/devicetree/bindings/drm/tilcdc/panel.txt Normal file
View File

@ -0,0 +1,59 @@
Device-Tree bindings for tilcdc DRM generic panel output driver
Required properties:
- compatible: value should be "ti,tilcdc,panel".
- panel-info: configuration info to configure LCDC correctly for the panel
- ac-bias: AC Bias Pin Frequency
- ac-bias-intrpt: AC Bias Pin Transitions per Interrupt
- dma-burst-sz: DMA burst size
- bpp: Bits per pixel
- fdd: FIFO DMA Request Delay
- sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling
- sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore
- raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most
- fifo-th: DMA FIFO threshold
- display-timings: typical videomode of lcd panel. Multiple video modes
can be listed if the panel supports multiple timings, but the 'native-mode'
should be the preferred/default resolution. Refer to
Documentation/devicetree/bindings/video/display-timing.txt for display
timing binding details.
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
Example:
/* Settings for CDTech_S035Q01 / LCD3 cape: */
lcd3 {
compatible = "ti,tilcdc,panel";
pinctrl-names = "default";
pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;
dma-burst-sz = <16>;
bpp = <16>;
fdd = <0x80>;
sync-edge = <0>;
sync-ctrl = <1>;
raster-order = <0>;
fifo-th = <0>;
};
display-timings {
native-mode = <&timing0>;
timing0: 320x240 {
hactive = <320>;
vactive = <240>;
hback-porch = <21>;
hfront-porch = <58>;
hsync-len = <47>;
vback-porch = <11>;
vfront-porch = <23>;
vsync-len = <2>;
clock-frequency = <8000000>;
hsync-active = <0>;
vsync-active = <0>;
};
};
};

18
Documentation/devicetree/bindings/drm/tilcdc/slave.txt Normal file
View File

@ -0,0 +1,18 @@
Device-Tree bindings for tilcdc DRM encoder slave output driver
Required properties:
- compatible: value should be "ti,tilcdc,slave".
- i2c: the phandle for the i2c device the encoder slave is connected to
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
Example:
hdmi {
compatible = "ti,tilcdc,slave";
i2c = <&i2c0>;
pinctrl-names = "default";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
};

21
Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt Normal file
View File

@ -0,0 +1,21 @@
Device-Tree bindings for tilcdc DRM TFP410 output driver
Required properties:
- compatible: value should be "ti,tilcdc,tfp410".
- i2c: the phandle for the i2c device to use for DDC
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
- powerdn-gpio: the powerdown GPIO, pulled low to power down the
TFP410 device (for DPMS_OFF)
Example:
dvicape {
compatible = "ti,tilcdc,tfp410";
i2c = <&i2c2>;
pinctrl-names = "default";
pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>;
powerdn-gpio = <&gpio2 31 0>;
};

21
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt Normal file
View File

@ -0,0 +1,21 @@
Device-Tree bindings for tilcdc DRM driver
Required properties:
- compatible: value should be "ti,am33xx-tilcdc".
- interrupts: the interrupt number
- reg: base address and size of the LCDC device
Recommended properties:
- interrupt-parent: the phandle for the interrupt controller that
services interrupts for this device.
- ti,hwmods: Name of the hwmod associated to the LCDC
Example:
fb: fb@4830e000 {
compatible = "ti,am33xx-tilcdc";
reg = <0x4830e000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <36>;
ti,hwmods = "lcdc";
};

20
Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt Normal file
View File

@ -0,0 +1,20 @@
Broadcom BCM2835 I2C controller
Required properties:
- compatible : Should be "brcm,bcm2835-i2c".
- reg: Should contain register location and length.
- interrupts: Should contain interrupt.
- clocks : The clock feeding the I2C controller.
Recommended properties:
- clock-frequency : desired I2C bus clock frequency in Hz.
Example:
i2c@20205000 {
compatible = "brcm,bcm2835-i2c";
reg = <0x7e205000 0x1000>;
interrupts = <2 21>;
clocks = <&clk_i2c>;
clock-frequency = <100000>;
};

2
Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
View File

@ -8,6 +8,8 @@ Required properties:
(b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
(c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
inside HDMIPHY block found on several samsung SoCs
(d) "samsung, exynos5440-i2c", for s3c2440-like i2c used
on EXYNOS5440 which does not need GPIO configuration.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.

18
Documentation/devicetree/bindings/i2c/ina209.txt Normal file
View File

@ -0,0 +1,18 @@
ina209 properties
Required properties:
- compatible: Must be "ti,ina209"
- reg: I2C address
Optional properties:
- shunt-resistor
Shunt resistor value in micro-Ohm
Example:
temp-sensor@4c {
compatible = "ti,ina209";
reg = <0x4c>;
shunt-resistor = <5000>;
};

64
Documentation/devicetree/bindings/i2c/max6697.txt Normal file
View File

@ -0,0 +1,64 @@
max6697 properties
Required properties:
- compatible:
Should be one of
maxim,max6581
maxim,max6602
maxim,max6622
maxim,max6636
maxim,max6689
maxim,max6693
maxim,max6694
maxim,max6697
maxim,max6698
maxim,max6699
- reg: I2C address
Optional properties:
- smbus-timeout-disable
Set to disable SMBus timeout. If not specified, SMBus timeout will be
enabled.
- extended-range-enable
Only valid for MAX6581. Set to enable extended temperature range.
Extended temperature will be disabled if not specified.
- beta-compensation-enable
Only valid for MAX6693 and MX6694. Set to enable beta compensation on
remote temperature channel 1.
Beta compensation will be disabled if not specified.
- alert-mask
Alert bit mask. Alert disabled for bits set.
Select bit 0 for local temperature, bit 1..7 for remote temperatures.
If not specified, alert will be enabled for all channels.
- over-temperature-mask
Over-temperature bit mask. Over-temperature reporting disabled for
bits set.
Select bit 0 for local temperature, bit 1..7 for remote temperatures.
If not specified, over-temperature reporting will be enabled for all
channels.
- resistance-cancellation
Boolean for all chips other than MAX6581. Set to enable resistance
cancellation on remote temperature channel 1.
For MAX6581, resistance cancellation enabled for all channels if
specified as boolean, otherwise as per bit mask specified.
Only supported for remote temperatures (bit 1..7).
If not specified, resistance cancellation will be disabled for all
channels.
- transistor-ideality
For MAX6581 only. Two values; first is bit mask, second is ideality
select value as per MAX6581 data sheet. Select bit 1..7 for remote
channels.
Transistor ideality will be initialized to default (1.008) if not
specified.
Example:
temp-sensor@1a {
compatible = "maxim,max6697";
reg = <0x1a>;
smbus-timeout-disable;
resistance-cancellation;
alert-mask = <0x72>;
over-temperature-mask = <0x7f>;
};

53
Documentation/devicetree/bindings/input/imx-keypad.txt Normal file
View File

@ -0,0 +1,53 @@
* Freescale i.MX Keypad Port(KPP) device tree bindings
The KPP is designed to interface with a keypad matrix with 2-point contact
or 3-point contact keys. The KPP is designed to simplify the software task
of scanning a keypad matrix. The KPP is capable of detecting, debouncing,
and decoding one or multiple keys pressed simultaneously on a keypad.
Required SoC Specific Properties:
- compatible: Should be "fsl,<soc>-kpp".
- reg: Physical base address of the KPP and length of memory mapped
region.
- interrupts: The KPP interrupt number to the CPU(s).
- clocks: The clock provided by the SoC to the KPP. Some SoCs use dummy
clock(The clock for the KPP is provided by the SoCs automatically).
Required Board Specific Properties:
- pinctrl-names: The definition can be found at
pinctrl/pinctrl-bindings.txt.
- pinctrl-0: The definition can be found at
pinctrl/pinctrl-bindings.txt.
- linux,keymap: The definition can be found at
bindings/input/matrix-keymap.txt.
Example:
kpp: kpp@73f94000 {
compatible = "fsl,imx51-kpp", "fsl,imx21-kpp";
reg = <0x73f94000 0x4000>;
interrupts = <60>;
clocks = <&clks 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_kpp_1>;
linux,keymap = <0x00000067 /* KEY_UP */
0x0001006c /* KEY_DOWN */
0x00020072 /* KEY_VOLUMEDOWN */
0x00030066 /* KEY_HOME */
0x0100006a /* KEY_RIGHT */
0x01010069 /* KEY_LEFT */
0x0102001c /* KEY_ENTER */
0x01030073 /* KEY_VOLUMEUP */
0x02000040 /* KEY_F6 */
0x02010042 /* KEY_F8 */
0x02020043 /* KEY_F9 */
0x02030044 /* KEY_F10 */
0x0300003b /* KEY_F1 */
0x0301003c /* KEY_F2 */
0x0302003d /* KEY_F3 */
0x03030074>; /* KEY_POWER */
};

9
Documentation/devicetree/bindings/input/lpc32xx-key.txt
View File

@ -1,19 +1,22 @@
NXP LPC32xx Key Scan Interface
This binding is based on the matrix-keymap binding with the following
changes:
Required Properties:
- compatible: Should be "nxp,lpc3220-key"
- reg: Physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
supports square matrices
- nxp,debounce-delay-ms: Debounce delay in ms
- nxp,scan-delay-ms: Repeated scan period in ms
- linux,keymap: the key-code to be reported when the key is pressed
and released, see also
Documentation/devicetree/bindings/input/matrix-keymap.txt
Note: keypad,num-rows and keypad,num-columns are required, and must be equal
since LPC32xx only supports square matrices
Example:
key@40050000 {

8
Documentation/devicetree/bindings/input/matrix-keymap.txt
View File

@ -9,6 +9,12 @@ Required properties:
row << 24 | column << 16 | key-code
Optional properties:
Properties for the number of rows and columns are optional because some
drivers will use fixed values for these.
- keypad,num-rows: Number of row lines connected to the keypad controller.
- keypad,num-columns: Number of column lines connected to the keypad
controller.
Some users of this binding might choose to specify secondary keymaps for
cases where there is a modifier key such as a Fn key. Proposed names
for said properties are "linux,fn-keymap" or with another descriptive
@ -17,3 +23,5 @@ word for the modifier other from "Fn".
Example:
linux,keymap = < 0x00030012
0x0102003a >;
keypad,num-rows = <2>;
keypad,num-columns = <8>;

22
Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
View File

@ -1,7 +1,18 @@
* Tegra keyboard controller
The key controller has maximum 24 pins to make matrix keypad. Any pin
can be configured as row or column. The maximum column pin can be 8
and maximum row pins can be 16 for Tegra20/Tegra30.
Required properties:
- compatible: "nvidia,tegra20-kbc"
- reg: Register base address of KBC.
- interrupts: Interrupt number for the KBC.
- nvidia,kbc-row-pins: The KBC pins which are configured as row. This is an
array of pin numbers which is used as rows.
- nvidia,kbc-col-pins: The KBC pins which are configured as column. This is an
array of pin numbers which is used as column.
- linux,keymap: The keymap for keys as described in the binding document
devicetree/bindings/input/matrix-keymap.txt.
Optional properties, in addition to those specified by the shared
matrix-keyboard bindings:
@ -19,5 +30,16 @@ Example:
keyboard: keyboard {
compatible = "nvidia,tegra20-kbc";
reg = <0x7000e200 0x100>;
interrupts = <0 85 0x04>;
nvidia,ghost-filter;
nvidia,debounce-delay-ms = <640>;
nvidia,kbc-row-pins = <0 1 2>; /* pin 0, 1, 2 as rows */
nvidia,kbc-col-pins = <11 12 13>; /* pin 11, 12, 13 as columns */
linux,keymap = <0x00000074
0x00010067
0x00020066
0x01010068
0x02000069
0x02010070
0x02020071>;
};

13
Documentation/devicetree/bindings/input/omap-keypad.txt
View File

@ -6,19 +6,16 @@ A key can be placed at each intersection of a unique row and a unique column.
The keypad controller can sense a key-press and key-release and report the
event using a interrupt to the cpu.
This binding is based on the matrix-keymap binding with the following
changes:
keypad,num-rows and keypad,num-columns are required.
Required SoC Specific Properties:
- compatible: should be one of the following
- "ti,omap4-keypad": For controllers compatible with omap4 keypad
controller.
Required Board Specific Properties, in addition to those specified by
the shared matrix-keyboard bindings:
- keypad,num-rows: Number of row lines connected to the keypad
controller.
- keypad,num-columns: Number of column lines connected to the
keypad controller.
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.

6
Documentation/devicetree/bindings/input/tca8418_keypad.txt
View File

@ -1,8 +1,10 @@
This binding is based on the matrix-keymap binding with the following
changes:
keypad,num-rows and keypad,num-columns are required.
Required properties:
- compatible: "ti,tca8418"
- reg: the I2C address
- interrupts: IRQ line number, should trigger on falling edge
- keypad,num-rows: The number of rows
- keypad,num-columns: The number of columns
- linux,keymap: Keys definitions, see keypad-matrix.

0
Documentation/devicetree/bindings/gpio/leds-ns2.txt → Documentation/devicetree/bindings/leds/leds-ns2.txt
View File

48
Documentation/devicetree/bindings/leds/leds-pwm.txt Normal file
View File

@ -0,0 +1,48 @@
LED connected to PWM
Required properties:
- compatible : should be "pwm-leds".
Each LED is represented as a sub-node of the pwm-leds device. Each
node's name represents the name of the corresponding LED.
LED sub-node properties:
- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
specify the period time to be used: <&phandle id period_ns>;
- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM device
For the pwms and pwm-names property please refer to:
Documentation/devicetree/bindings/pwm/pwm.txt
- max-brightness : Maximum brightness possible for the LED
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
Example:
twl_pwm: pwm {
/* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
compatible = "ti,twl6030-pwm";
#pwm-cells = <2>;
};
twl_pwmled: pwmled {
/* provides one PWM (id 0 for Charing indicator LED) */
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
pwmleds {
compatible = "pwm-leds";
kpad {
label = "omap4::keypad";
pwms = <&twl_pwm 0 7812500>;
max-brightness = <127>;
};
charging {
label = "omap4:green:chrg";
pwms = <&twl_pwmled 0 7812500>;
max-brightness = <255>;
};
};

33
Documentation/devicetree/bindings/leds/tca6507.txt Normal file
View File

@ -0,0 +1,33 @@
LEDs conected to tca6507
Required properties:
- compatible : should be : "ti,tca6507".
Each led is represented as a sub-node of the ti,tca6507 device.
LED sub-node properties:
- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
- reg : number of LED line (could be from 0 to 6)
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
Examples:
tca6507@45 {
compatible = "ti,tca6507";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x45>;
led0: red-aux@0 {
label = "red:aux";
reg = <0x0>;
};
led1: green-aux@1 {
label = "green:aux";
reg = <0x5>;
linux,default-trigger = "default-on";
};
};

82
Documentation/devicetree/bindings/metag/meta-intc.txt Normal file
View File

@ -0,0 +1,82 @@
* Meta External Trigger Controller Binding
This binding specifies what properties must be available in the device tree
representation of a Meta external trigger controller.
Required properties:
- compatible: Specifies the compatibility list for the interrupt controller.
The type shall be <string> and the value shall include "img,meta-intc".
- num-banks: Specifies the number of interrupt banks (each of which can
handle 32 interrupt sources).
- interrupt-controller: The presence of this property identifies the node
as an interupt controller. No property value shall be defined.
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 2.
- #address-cells: Specifies the number of cells needed to encode an
address. The type shall be <u32> and the value shall be 0. As such,
'interrupt-map' nodes do not have to specify a parent unit address.
Optional properties:
- no-mask: The controller doesn't have any mask registers.
* Interrupt Specifier Definition
Interrupt specifiers consists of 2 cells encoded as follows:
- <1st-cell>: The interrupt-number that identifies the interrupt source.
- <2nd-cell>: The Linux interrupt flags containing level-sense information,
encoded as follows:
1 = edge triggered
4 = level-sensitive
* Examples
Example 1:
/*
* Meta external trigger block
*/
intc: intc {
// This is an interrupt controller node.
interrupt-controller;
// No address cells so that 'interrupt-map' nodes which
// reference this interrupt controller node do not need a parent
// address specifier.
#address-cells = <0>;
// Two cells to encode interrupt sources.
#interrupt-cells = <2>;
// Number of interrupt banks
num-banks = <2>;
// No HWMASKEXT is available (specify on Chorus2 and Comet ES1)
no-mask;
// Compatible with Meta hardware trigger block.
compatible = "img,meta-intc";
};
Example 2:
/*
* An interrupt generating device that is wired to a Meta external
* trigger block.
*/
uart1: uart@0x02004c00 {
// Interrupt source '5' that is level-sensitive.
// Note that there are only two cells as specified in the
// interrupt parent's '#interrupt-cells' property.
interrupts = <5 4 /* level */>;
// The interrupt controller that this device is wired to.
interrupt-parent = <&intc>;
};

64
Documentation/devicetree/bindings/mfd/max8925.txt Normal file
View File

@ -0,0 +1,64 @@
* Maxim max8925 Power Management IC
Required parent device properties:
- compatible : "maxim,max8925"
- reg : the I2C slave address for the max8925 chip
- interrupts : IRQ line for the max8925 chip
- interrupt-controller: describes the max8925 as an interrupt
controller (has its own domain)
- #interrupt-cells : should be 1.
- The cell is the max8925 local IRQ number
Optional parent device properties:
- maxim,tsc-irq: there are 2 IRQ lines for max8925, one is indicated in
interrupts property, the other is indicated here.
max8925 consists of a large and varied group of sub-devices:
Device Supply Names Description
------ ------------ -----------
max8925-onkey : : On key
max8925-rtc : : RTC
max8925-regulator : : Regulators
max8925-backlight : : Backlight
max8925-touch : : Touchscreen
max8925-power : : Charger
Example:
pmic: max8925@3c {
compatible = "maxim,max8925";
reg = <0x3c>;
interrupts = <1>;
interrupt-parent = <&intcmux4>;
interrupt-controller;
#interrupt-cells = <1>;
maxim,tsc-irq = <0>;
regulators {
SDV1 {
regulator-min-microvolt = <637500>;
regulator-max-microvolt = <1425000>;
regulator-boot-on;
regulator-always-on;
};
LDO1 {
regulator-min-microvolt = <750000>;
regulator-max-microvolt = <3900000>;
regulator-boot-on;
regulator-always-on;
};
};
backlight {
maxim,max8925-dual-string = <0>;
};
charger {
batt-detect = <0>;
topoff-threshold = <1>;
fast-charge = <7>;
no-temp-support = <0>;
no-insert-detect = <0>;
};
};

91
Documentation/devicetree/bindings/mfd/tps6507x.txt Executable file
View File

@ -0,0 +1,91 @@
TPS6507x Power Management Integrated Circuit
Required properties:
- compatible: "ti,tps6507x"
- reg: I2C slave address
- regulators: This is the list of child nodes that specify the regulator
initialization data for defined regulators. Not all regulators for the
given device need to be present. The definition for each of these nodes
is defined using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
The regulator is matched with the regulator-compatible.
The valid regulator-compatible values are:
tps6507x: vdcdc1, vdcdc2, vdcdc3, vldo1, vldo2
- xxx-supply: Input voltage supply regulator.
These entries are required if regulators are enabled for a device.
Missing of these properties can cause the regulator registration
fails.
If some of input supply is powered through battery or always-on
supply then also it is require to have these parameters with proper
node handle of always on power supply.
tps6507x:
vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
vindcdc3-supply : VDCDC3 input.
vldo1_2-supply : VLDO1 and VLDO2 input.
Regulator Optional properties:
- defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
0: If defdcdc pin of DCDC2/DCDC3 is pulled to GND.
1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
If this property is not defined, it defaults to 0 (not enabled).
Example:
pmu: tps6507x@48 {
compatible = "ti,tps6507x";
reg = <0x48>;
vindcdc1_2-supply = <&vbat>;
vindcdc3-supply = <...>;
vinldo1_2-supply = <...>;
regulators {
#address-cells = <1>;
#size-cells = <0>;
vdcdc1_reg: regulator@0 {
regulator-compatible = "VDCDC1";
reg = <0>;
regulator-min-microvolt = <3150000>;
regulator-max-microvolt = <3450000>;
regulator-always-on;
regulator-boot-on;
};
vdcdc2_reg: regulator@1 {
regulator-compatible = "VDCDC2";
reg = <1>;
regulator-min-microvolt = <1710000>;
regulator-max-microvolt = <3450000>;
regulator-always-on;
regulator-boot-on;
defdcdc_default = <1>;
};
vdcdc3_reg: regulator@2 {
regulator-compatible = "VDCDC3";
reg = <2>;
regulator-min-microvolt = <950000>
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
defdcdc_default = <1>;
};
ldo1_reg: regulator@3 {
regulator-compatible = "LDO1";
reg = <3>;
regulator-min-microvolt = <1710000>;
regulator-max-microvolt = <1890000>;
regulator-always-on;
regulator-boot-on;
};
ldo2_reg: regulator@4 {
regulator-compatible = "LDO2";
reg = <4>;
regulator-min-microvolt = <1140000>;
regulator-max-microvolt = <1320000>;
regulator-always-on;
regulator-boot-on;
};
};
};

2
Documentation/devicetree/bindings/mips/cavium/dma-engine.txt
View File

@ -1,7 +1,7 @@
* DMA Engine.
The Octeon DMA Engine transfers between the Boot Bus and main memory.
The DMA Engine will be refered to by phandle by any device that is
The DMA Engine will be referred to by phandle by any device that is
connected to it.
Properties:

47
Documentation/devicetree/bindings/mips/cpu_irq.txt Normal file
View File

@ -0,0 +1,47 @@
MIPS CPU interrupt controller
On MIPS the mips_cpu_intc_init() helper can be used to initialize the 8 CPU
IRQs from a devicetree file and create a irq_domain for IRQ controller.
With the irq_domain in place we can describe how the 8 IRQs are wired to the
platforms internal interrupt controller cascade.
Below is an example of a platform describing the cascade inside the devicetree
and the code used to load it inside arch_init_irq().
Required properties:
- compatible : Should be "mti,cpu-interrupt-controller"
Example devicetree:
cpu-irq: cpu-irq@0 {
#address-cells = <0>;
interrupt-controller;
#interrupt-cells = <1>;
compatible = "mti,cpu-interrupt-controller";
};
intc: intc@200 {
compatible = "ralink,rt2880-intc";
reg = <0x200 0x100>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&cpu-irq>;
interrupts = <2>;
};
Example platform irq.c:
static struct of_device_id __initdata of_irq_ids[] = {
{ .compatible = "mti,cpu-interrupt-controller", .data = mips_cpu_intc_init },
{ .compatible = "ralink,rt2880-intc", .data = intc_of_init },
{},
};
void __init arch_init_irq(void)
{
of_irq_init(of_irq_ids);
}

18
Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt Normal file
View File

@ -0,0 +1,18 @@
Broadcom BCM2835 SDHCI controller
This file documents differences between the core properties described
by mmc.txt and the properties that represent the BCM2835 controller.
Required properties:
- compatible : Should be "brcm,bcm2835-sdhci".
- clocks : The clock feeding the SDHCI controller.
Example:
sdhci: sdhci {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e300000 0x100>;
interrupts = <2 30>;
clocks = <&clk_mmc>;
bus-width = <4>;
};

Some files were not shown because too many files have changed in this diff Show More