redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity

Merge branch 'master' into for-next

wifi-calibration
Jiri Kosina 2014-02-20 14:54:28 +01:00
parent be873ac782 6d0abeca32
commit d4263348f7
10316 changed files with 557568 additions and 217526 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@ -92,3 +92,6 @@ extra_certificates
signing_key.priv
signing_key.x509
x509.genkey
# Kconfig presets
all.config

4
CREDITS
View File

@ -823,8 +823,8 @@ S: D-69231 Rauenberg
S: Germany
N: Jean Delvare
E: khali@linux-fr.org
W: http://khali.linux-fr.org/
E: jdelvare@suse.de
W: http://jdelvare.nerim.net/
D: Several hardware monitoring drivers
S: France

24
Documentation/00-INDEX
View File

@ -29,6 +29,8 @@ 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
dmatest.txt
- how to compile, configure and use the dmatest system.
DocBook/
- directory with DocBook templates etc. for kernel documentation.
EDID/
@ -77,6 +79,8 @@ arm/
- directory with info about Linux on the ARM architecture.
arm64/
- directory with info about Linux on the 64 bit ARM architecture.
assoc_array.txt
- generic associative array intro.
atomic_ops.txt
- semantics and behavior of atomic and bitmask operations.
auxdisplay/
@ -87,6 +91,8 @@ 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.
bcache.txt
- Block-layer cache on fast SSDs to improve slow (raid) I/O performance.
binfmt_misc.txt
- info on the kernel support for extra binary formats.
blackfin/
@ -171,6 +177,8 @@ early-userspace/
- info about initramfs, klibc, and userspace early during boot.
edac.txt
- information on EDAC - Error Detection And Correction
efi-stub.txt
- How to use the EFI boot stub to bypass GRUB or elilo on EFI systems.
eisa.txt
- info on EISA bus support.
email-clients.txt
@ -195,8 +203,8 @@ 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.
gpio/
- gpio related documentation
hid/
- directory with information on human interface devices
highuid.txt
@ -255,6 +263,8 @@ 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.
kernel-per-CPU-kthreads.txt
- List of all per-CPU kthreads and how they introduce jitter.
kmemcheck.txt
- info on dynamic checker that detects uses of uninitialized memory.
kmemleak.txt
@ -299,8 +309,6 @@ 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/
@ -311,6 +319,8 @@ mmc/
- directory with info about the MMC subsystem
mn10300/
- directory with info about the mn10300 architecture port
module-signing.txt
- Kernel module signing for increased security when loading modules.
mtd/
- directory with info about memory technology devices (flash)
mono.txt
@ -343,6 +353,8 @@ pcmcia/
- info on the Linux PCMCIA driver.
percpu-rw-semaphore.txt
- RCU based read-write semaphore optimized for locking for reading
phy.txt
- Description of the generic PHY framework.
pi-futex.txt
- documentation on lightweight priority inheritance futexes.
pinctrl.txt
@ -431,6 +443,8 @@ sysrq.txt
- info on the magic SysRq key.
target/
- directory with info on generating TCM v4 fabric .ko modules
this_cpu_ops.txt
- List rationale behind and the way to use this_cpu operations.
thermal/
- directory with information on managing thermal issues (CPU/temp)
trace/
@ -469,6 +483,8 @@ wimax/
- directory with info about Intel Wireless Wimax Connections
workqueue.txt
- information on the Concurrency Managed Workqueue implementation
ww-mutex-design.txt
- Intro to Mutex wait/would deadlock handling.s
x86/x86_64/
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
xtensa/

12
Documentation/ABI/testing/configfs-usb-gadget
View File

@ -1,13 +1,13 @@
What: /config/usb-gadget
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
This group contains sub-groups corresponding to created
USB gadgets.
What: /config/usb-gadget/gadget
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
The attributes of a gadget:
@ -27,7 +27,7 @@ Description:
What: /config/usb-gadget/gadget/configs
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
This group contains a USB gadget's configurations
@ -58,20 +58,20 @@ Description:
What: /config/usb-gadget/gadget/functions
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
This group contains functions available to this USB gadget.
What: /config/usb-gadget/gadget/strings
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
This group contains subdirectories for language-specific
strings for this gadget.
What: /config/usb-gadget/gadget/strings/language
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
The attributes:

2
Documentation/ABI/testing/configfs-usb-gadget-acm
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/acm.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
This item contains just one readonly attribute: port_num.

2
Documentation/ABI/testing/configfs-usb-gadget-ecm
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/ecm.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
The attributes:

2
Documentation/ABI/testing/configfs-usb-gadget-eem
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/eem.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
The attributes:

9
Documentation/ABI/testing/configfs-usb-gadget-ffs 100644
View File

@ -0,0 +1,9 @@
What: /config/usb-gadget/gadget/functions/ffs.name
Date: Nov 2013
KernelVersion: 3.13
Description: The purpose of this directory is to create and remove it.
A corresponding USB function instance is created/removed.
There are no attributes here.
All parameters are set through FunctionFS.

8
Documentation/ABI/testing/configfs-usb-gadget-loopback 100644
View File

@ -0,0 +1,8 @@
What: /config/usb-gadget/gadget/functions/Loopback.name
Date: Nov 2013
KernelVersion: 3.13
Description:
The attributes:
qlen - depth of loopback queue
bulk_buflen - buffer length

4
Documentation/ABI/testing/configfs-usb-gadget-mass-storage
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/mass_storage.name
Date: Oct 2013
KenelVersion: 3.13
KernelVersion: 3.13
Description:
The attributes:
@ -13,7 +13,7 @@ Description:
What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
Date: Oct 2013
KenelVersion: 3.13
KernelVersion: 3.13
Description:
The attributes:

2
Documentation/ABI/testing/configfs-usb-gadget-ncm
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/ncm.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
The attributes:

2
Documentation/ABI/testing/configfs-usb-gadget-obex
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/obex.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
This item contains just one readonly attribute: port_num.

2
Documentation/ABI/testing/configfs-usb-gadget-phonet
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/phonet.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
This item contains just one readonly attribute: ifname.

2
Documentation/ABI/testing/configfs-usb-gadget-rndis
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/rndis.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
The attributes:

2
Documentation/ABI/testing/configfs-usb-gadget-serial
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/gser.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
This item contains just one readonly attribute: port_num.

12
Documentation/ABI/testing/configfs-usb-gadget-sourcesink 100644
View File

@ -0,0 +1,12 @@
What: /config/usb-gadget/gadget/functions/SourceSink.name
Date: Nov 2013
KernelVersion: 3.13
Description:
The attributes:
pattern - 0 (all zeros), 1 (mod63), 2 (none)
isoc_interval - 1..16
isoc_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss)
isoc_mult - 0..2 (hs/ss only)
isoc_maxburst - 0..15 (ss only)
qlen - buffer length

2
Documentation/ABI/testing/configfs-usb-gadget-subset
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/geth.name
Date: Jun 2013
KenelVersion: 3.11
KernelVersion: 3.11
Description:
The attributes:

91
Documentation/ABI/testing/debugfs-driver-genwqe 100644
View File

@ -0,0 +1,91 @@
What: /sys/kernel/debug/genwqe/genwqe<n>_card/ddcb_info
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: DDCB queue dump used for debugging queueing problems.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_regs
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump of the current error registers.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid0
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID0 (unit id 0).
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid1
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID1.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid2
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID2.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_regs
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump of the error registers before the last reset of
the card occured.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid0
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID0 before card was reset.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid1
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID1 before card was reset.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid2
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Internal chip state of UID2 before card was reset.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/info
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Comprehensive summary of bitstream version and software
version. Used bitstream and bitstream clocking information.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/err_inject
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Possibility to inject error cases to ensure that the drivers
error handling code works well.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/vf<0..14>_jobtimeout_msec
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Default VF timeout 250ms. Testing might require 1000ms.
Using 0 will use the cards default value (whatever that is).
The timeout depends on the max number of available cards
in the system and the maximum allowed queue size.
The driver ensures that the settings are done just before
the VFs get enabled. Changing the timeouts in flight is not
possible.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/jobtimer
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump job timeout register values for PF and VFs.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/queue_working_time
Date: Dec 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump queue working time register values for PF and VFs.
Only available for PF.

13
Documentation/ABI/testing/sysfs-bus-iio
View File

@ -197,6 +197,19 @@ Description:
Raw pressure measurement from channel Y. Units after
application of scale and offset are kilopascal.
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_raw
KernelVersion: 3.14
Contact: linux-iio@vger.kernel.org
Description:
Raw humidity measurement of air. Units after application of
scale and offset are milli percent.
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_input
KernelVersion: 3.14
Contact: linux-iio@vger.kernel.org
Description:
Scaled humidity measurement in milli percent.
What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset

11
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -70,18 +70,15 @@ Date: September, 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
Description:
The /sys/devices/.../msi_irqs directory contains a variable set
of sub-directories, with each sub-directory being named after a
corresponding msi irq vector allocated to that device. Each
numbered sub-directory N contains attributes of that irq.
Note that this directory is not created for device drivers which
do not support msi irqs
of files, with each file being named after a corresponding msi
irq vector allocated to that device.
What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode
What: /sys/bus/pci/devices/.../msi_irqs/<N>
Date: September 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
Description:
This attribute indicates the mode that the irq vector named by
the parent directory is in (msi vs. msix)
the file is in (msi vs. msix)
What: /sys/bus/pci/devices/.../remove
Date: January 2009

26
Documentation/ABI/testing/sysfs-bus-rbd
View File

@ -18,6 +18,28 @@ Removal of a device:
$ echo <dev-id> > /sys/bus/rbd/remove
What: /sys/bus/rbd/add_single_major
Date: December 2013
KernelVersion: 3.14
Contact: Sage Weil <sage@inktank.com>
Description: Available only if rbd module is inserted with single_major
parameter set to true.
Usage is the same as for /sys/bus/rbd/add. If present,
should be used instead of the latter: any attempts to use
/sys/bus/rbd/add if /sys/bus/rbd/add_single_major is
available will fail for backwards compatibility reasons.
What: /sys/bus/rbd/remove_single_major
Date: December 2013
KernelVersion: 3.14
Contact: Sage Weil <sage@inktank.com>
Description: Available only if rbd module is inserted with single_major
parameter set to true.
Usage is the same as for /sys/bus/rbd/remove. If present,
should be used instead of the latter: any attempts to use
/sys/bus/rbd/remove if /sys/bus/rbd/remove_single_major is
available will fail for backwards compatibility reasons.
Entries under /sys/bus/rbd/devices/<dev-id>/
--------------------------------------------
@ -33,6 +55,10 @@ major
The block device major number.
minor
The block device minor number. (December 2013, since 3.14.)
name
The name of the rbd image.

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

@ -50,13 +50,19 @@ Description:
This may allow the driver to support more hardware than
was included in the driver's static device ID support
table at compile time. The format for the device ID is:
idVendor idProduct bInterfaceClass.
idVendor idProduct bInterfaceClass RefIdVendor RefIdProduct
The vendor ID and device ID fields are required, the
interface class is optional.
rest is optional. The Ref* tuple can be used to tell the
driver to use the same driver_data for the new device as
it is used for the reference device.
Upon successfully adding an ID, the driver will probe
for the device and attempt to bind to it. For example:
# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
Here add a new device (0458:7045) using driver_data from
an already supported device (0458:704c):
# echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id
Reading from this file will list all dynamically added
device IDs in the same format, with one entry per
line. For example:

8
Documentation/ABI/testing/sysfs-class-net-mesh
View File

@ -68,6 +68,14 @@ Description:
Defines the penalty which will be applied to an
originator message's tq-field on every hop.
What: /sys/class/net/<mesh_iface>/mesh/isolation_mark
Date: Nov 2013
Contact: Antonio Quartulli <antonio@meshcoding.com>
Description:
Defines the isolation mark (and its bitmask) which
is used to classify clients as "isolated" by the
Extended Isolation feature.
What: /sys/class/net/<mesh_iface>/mesh/network_coding
Date: Nov 2012
Contact: Martin Hundeboll <martin@hundeboll.net>

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

@ -200,3 +200,27 @@ Description: address and size of the percpu note.
note of cpu#.
crash_notes_size: size of the note of cpu#.
What: /sys/devices/system/cpu/intel_pstate/max_perf_pct
/sys/devices/system/cpu/intel_pstate/min_perf_pct
/sys/devices/system/cpu/intel_pstate/no_turbo
Date: February 2013
Contact: linux-pm@vger.kernel.org
Description: Parameters for the Intel P-state driver
Logic for selecting the current P-state in Intel
Sandybridge+ processors. The three knobs control
limits for the P-state that will be requested by the
driver.
max_perf_pct: limits the maximum P state that will be requested by
the driver stated as a percentage of the available performance.
min_perf_pct: limits the minimum P state that will be requested by
the driver stated as a percentage of the available performance.
no_turbo: limits the driver to selecting P states below the turbo
frequency range.
More details can be found in Documentation/cpu-freq/intel-pstate.txt

62
Documentation/ABI/testing/sysfs-driver-genwqe 100644
View File

@ -0,0 +1,62 @@
What: /sys/class/genwqe/genwqe<n>_card/version
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Unique bitstream identification e.g.
'0000000330336283.00000000475a4950'.
What: /sys/class/genwqe/genwqe<n>_card/appid
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Identifies the currently active card application e.g. 'GZIP'
for compression/decompression.
What: /sys/class/genwqe/genwqe<n>_card/type
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Type of the card e.g. 'GenWQE5-A7'.
What: /sys/class/genwqe/genwqe<n>_card/curr_bitstream
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Currently active bitstream. 1 is default, 0 is backup.
What: /sys/class/genwqe/genwqe<n>_card/next_bitstream
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Interface to set the next bitstream to be used.
What: /sys/class/genwqe/genwqe<n>_card/tempsens
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Interface to read the cards temperature sense register.
What: /sys/class/genwqe/genwqe<n>_card/freerunning_timer
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Interface to read the cards free running timer.
Used for performance and utilization measurements.
What: /sys/class/genwqe/genwqe<n>_card/queue_working_time
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Interface to read queue working time.
Used for performance and utilization measurements.
What: /sys/class/genwqe/genwqe<n>_card/state
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: State of the card: "unused", "used", "error".
What: /sys/class/genwqe/genwqe<n>_card/base_clock
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Base clock frequency of the card.
What: /sys/class/genwqe/genwqe<n>_card/device/sriov_numvfs
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Enable VFs (1..15):
sudo sh -c 'echo 15 > \
/sys/bus/pci/devices/0000\:1b\:00.0/sriov_numvfs'
Disable VFs:
Write a 0 into the same sysfs entry.

20
Documentation/ABI/testing/sysfs-firmware-efi 100644
View File

@ -0,0 +1,20 @@
What: /sys/firmware/efi/fw_vendor
Date: December 2013
Contact: Dave Young <dyoung@redhat.com>
Description: It shows the physical address of firmware vendor field in the
EFI system table.
Users: Kexec
What: /sys/firmware/efi/runtime
Date: December 2013
Contact: Dave Young <dyoung@redhat.com>
Description: It shows the physical address of runtime service table entry in
the EFI system table.
Users: Kexec
What: /sys/firmware/efi/config_table
Date: December 2013
Contact: Dave Young <dyoung@redhat.com>
Description: It shows the physical address of config table entry in the EFI
system table.
Users: Kexec

34
Documentation/ABI/testing/sysfs-firmware-efi-runtime-map 100644
View File

@ -0,0 +1,34 @@
What: /sys/firmware/efi/runtime-map/
Date: December 2013
Contact: Dave Young <dyoung@redhat.com>
Description: Switching efi runtime services to virtual mode requires
that all efi memory ranges which have the runtime attribute
bit set to be mapped to virtual addresses.
The efi runtime services can only be switched to virtual
mode once without rebooting. The kexec kernel must maintain
the same physical to virtual address mappings as the first
kernel. The mappings are exported to sysfs so userspace tools
can reassemble them and pass them into the kexec kernel.
/sys/firmware/efi/runtime-map/ is the directory the kernel
exports that information in.
subdirectories are named with the number of the memory range:
/sys/firmware/efi/runtime-map/0
/sys/firmware/efi/runtime-map/1
/sys/firmware/efi/runtime-map/2
/sys/firmware/efi/runtime-map/3
...
Each subdirectory contains five files:
attribute : The attributes of the memory range.
num_pages : The size of the memory range in pages.
phys_addr : The physical address of the memory range.
type : The type of the memory range.
virt_addr : The virtual address of the memory range.
Above values are all hexadecimal numbers with the '0x' prefix.
Users: Kexec

31
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -24,3 +24,34 @@ Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the victim selection policy for garbage collection.
What: /sys/fs/f2fs/<disk>/reclaim_segments
Date: October 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the issue rate of segment discard commands.
What: /sys/fs/f2fs/<disk>/ipu_policy
Date: November 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the in-place-update policy.
What: /sys/fs/f2fs/<disk>/min_ipu_util
Date: November 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the FS utilization condition for the in-place-update
policies.
What: /sys/fs/f2fs/<disk>/max_small_discards
Date: November 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the issue rate of small discard commands.
What: /sys/fs/f2fs/<disk>/max_victim_search
Date: January 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the number of trials to find a victim segment.

38
Documentation/ABI/testing/sysfs-kernel-boot_params 100644
View File

@ -0,0 +1,38 @@
What: /sys/kernel/boot_params
Date: December 2013
Contact: Dave Young <dyoung@redhat.com>
Description: The /sys/kernel/boot_params directory contains two
files: "data" and "version" and one subdirectory "setup_data".
It is used to export the kernel boot parameters of an x86
platform to userspace for kexec and debugging purpose.
If there's no setup_data in boot_params the subdirectory will
not be created.
"data" file is the binary representation of struct boot_params.
"version" file is the string representation of boot
protocol version.
"setup_data" subdirectory contains the setup_data data
structure in boot_params. setup_data is maintained in kernel
as a link list. In "setup_data" subdirectory there's one
subdirectory for each link list node named with the number
of the list nodes. The list node subdirectory contains two
files "type" and "data". "type" file is the string
representation of setup_data type. "data" file is the binary
representation of setup_data payload.
The whole boot_params directory structure is like below:
/sys/kernel/boot_params
|__ data
|__ setup_data
| |__ 0
| | |__ data
| | |__ type
| |__ 1
| |__ data
| |__ type
|__ version
Users: Kexec

14
Documentation/ABI/testing/sysfs-kernel-vmcoreinfo 100644
View File

@ -0,0 +1,14 @@
What: /sys/kernel/vmcoreinfo
Date: October 2007
KernelVersion: 2.6.24
Contact: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Kexec Mailing List <kexec@lists.infradead.org>
Vivek Goyal <vgoyal@redhat.com>
Description
Shows physical address and size of vmcoreinfo ELF note.
First value contains physical address of note in hex and
second value contains the size of note in hex. This ELF
note info is parsed by second kernel and exported to user
space as part of ELF note in /proc/vmcore file. This note
contains various information like struct size, symbol
values, page size etc.

16
Documentation/ABI/testing/sysfs-platform-tahvo-usb 100644
View File

@ -0,0 +1,16 @@
What: /sys/bus/platform/devices/tahvo-usb/otg_mode
Date: December 2013
Contact: Aaro Koskinen <aaro.koskinen@iki.fi>
Description:
Set or read the current OTG mode. Valid values are "host" and
"peripheral".
Reading: returns the current mode.
What: /sys/bus/platform/devices/tahvo-usb/vbus
Date: December 2013
Contact: Aaro Koskinen <aaro.koskinen@iki.fi>
Description:
Read the current VBUS state.
Reading: returns "on" or "off".

3
Documentation/ABI/testing/sysfs-tty
View File

@ -3,7 +3,8 @@ Date: Nov 2010
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description:
Shows the list of currently configured
console devices, like 'tty1 ttyS0'.
tty devices used for the console,
like 'tty1 ttyS0'.
The last entry in the file is the active
device connected to /dev/console.
The file supports poll() to detect virtual

12
Documentation/DocBook/media/v4l/compat.xml
View File

@ -2523,6 +2523,18 @@ that used it. It was originally scheduled for removal in 2.6.35.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.14</title>
<orderedlist>
<listitem>
<para> In struct <structname>v4l2_rect</structname>, the type
of <structfield>width</structfield> and <structfield>height</structfield>
fields changed from _s32 to _u32.
</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>

41
Documentation/DocBook/media/v4l/controls.xml
View File

@ -3161,6 +3161,47 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a golden frame.</entry>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_MIN_QP</constant></entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Minimum quantization parameter for VP8.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_MAX_QP</constant></entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Maximum quantization parameter for VP8.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Quantization parameter for an I frame for VP8.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Quantization parameter for a P frame for VP8.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_PROFILE</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Select the desired profile for VPx encoder.
Acceptable values are 0, 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>

9
Documentation/DocBook/media/v4l/dev-overlay.xml
View File

@ -346,17 +346,14 @@ rectangle, in pixels.</entry>
rectangle, in pixels. Offsets increase to the right and down.</entry>
</row>
<row>
<entry>__s32</entry>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Width of the rectangle, in pixels.</entry>
</row>
<row>
<entry>__s32</entry>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Height of the rectangle, in pixels. Width and
height cannot be negative, the fields are signed for hysterical
reasons. <!-- video4linux-list@redhat.com on 22 Oct 2002 subject
"Re:[V4L][patches!] Re:v4l2/kernel-2.5" --></entry>
<entry>Height of the rectangle, in pixels.</entry>
</row>
</tbody>
</tgroup>

9
Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
View File

@ -134,6 +134,15 @@
<entry>Output pad, relative to the entity. Output pads source data
and are origins of links.</entry>
</row>
<row>
<entry><constant>MEDIA_PAD_FL_MUST_CONNECT</constant></entry>
<entry>If this flag is set and the pad is linked to any other
pad, then at least one of those links must be enabled for the
entity to be able to stream. There could be temporary reasons
(e.g. device configuration dependent) for the pad to need
enabled links even when this flag isn't set; the absence of the
flag doesn't imply there is none.</entry>
</row>
</tbody>
</tgroup>
</table>

163
Documentation/DocBook/media/v4l/subdev-formats.xml
View File

@ -89,7 +89,7 @@
<constant>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</constant>.
</para>
<para>The following tables list existing packet RGB formats.</para>
<para>The following tables list existing packed RGB formats.</para>
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb">
<title>RGB formats</title>
@ -615,7 +615,7 @@
</mediaobject>
</figure>
<para>The following table lists existing packet Bayer formats. The data
<para>The following table lists existing packed Bayer formats. The data
organization is given as an example for the first pixel only.</para>
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-bayer">
@ -1178,7 +1178,7 @@
U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>.
</para>
<para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> list existing packet YUV
<para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> lists existing packed YUV
formats and describes the organization of each pixel data in each sample.
When a format pattern is split across multiple samples each of the samples
in the pattern is described.</para>
@ -2491,6 +2491,163 @@
</table>
</section>
<section>
<title>HSV/HSL Formats</title>
<para>Those formats transfer pixel data as RGB values in a cylindrical-coordinate
system using Hue-Saturation-Value or Hue-Saturation-Lightness components. The
format code is made of the following information.
<itemizedlist>
<listitem><para>The hue, saturation, value or lightness and optional alpha
components order code, as encoded in a pixel sample. The only currently
supported value is AHSV.
</para></listitem>
<listitem><para>The number of bits per component, for each component. The values
can be different for all components. The only currently supported value is 8888.
</para></listitem>
<listitem><para>The number of bus samples per pixel. Pixels that are wider than
the bus width must be transferred in multiple samples. The only currently
supported value is 1.</para></listitem>
<listitem><para>The bus width.</para></listitem>
<listitem><para>For formats where the total number of bits per pixel is smaller
than the number of bus samples per pixel times the bus width, a padding
value stating if the bytes are padded in their most high order bits
(PADHI) or low order bits (PADLO).</para></listitem>
<listitem><para>For formats where the number of bus samples per pixel is larger
than 1, an endianness value stating if the pixel is transferred MSB first
(BE) or LSB first (LE).</para></listitem>
</itemizedlist>
</para>
<para>The following table lists existing HSV/HSL formats.</para>
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-hsv">
<title>HSV/HSL formats</title>
<tgroup cols="27">
<colspec colname="id" align="left" />
<colspec colname="code" align="center"/>
<colspec colname="bit" />
<colspec colnum="4" colname="b31" align="center" />
<colspec colnum="5" colname="b20" align="center" />
<colspec colnum="6" colname="b29" align="center" />
<colspec colnum="7" colname="b28" align="center" />
<colspec colnum="8" colname="b27" align="center" />
<colspec colnum="9" colname="b26" align="center" />
<colspec colnum="10" colname="b25" align="center" />
<colspec colnum="11" colname="b24" align="center" />
<colspec colnum="12" colname="b23" align="center" />
<colspec colnum="13" colname="b22" align="center" />
<colspec colnum="14" colname="b21" align="center" />
<colspec colnum="15" colname="b20" align="center" />
<colspec colnum="16" colname="b19" align="center" />
<colspec colnum="17" colname="b18" align="center" />
<colspec colnum="18" colname="b17" align="center" />
<colspec colnum="19" colname="b16" align="center" />
<colspec colnum="20" colname="b15" align="center" />
<colspec colnum="21" colname="b14" align="center" />
<colspec colnum="22" colname="b13" align="center" />
<colspec colnum="23" colname="b12" align="center" />
<colspec colnum="24" colname="b11" align="center" />
<colspec colnum="25" colname="b10" align="center" />
<colspec colnum="26" colname="b09" align="center" />
<colspec colnum="27" colname="b08" align="center" />
<colspec colnum="28" colname="b07" align="center" />
<colspec colnum="29" colname="b06" align="center" />
<colspec colnum="30" colname="b05" align="center" />
<colspec colnum="31" colname="b04" align="center" />
<colspec colnum="32" colname="b03" align="center" />
<colspec colnum="33" colname="b02" align="center" />
<colspec colnum="34" colname="b01" align="center" />
<colspec colnum="35" colname="b00" align="center" />
<spanspec namest="b31" nameend="b00" spanname="b0" />
<thead>
<row>
<entry>Identifier</entry>
<entry>Code</entry>
<entry></entry>
<entry spanname="b0">Data organization</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>Bit</entry>
<entry>31</entry>
<entry>30</entry>
<entry>29</entry>
<entry>28</entry>
<entry>27</entry>
<entry>26</entry>
<entry>25</entry>
<entry>24</entry>
<entry>23</entry>
<entry>22</entry>
<entry>21</entry>
<entry>20</entry>
<entry>19</entry>
<entry>18</entry>
<entry>17</entry>
<entry>16</entry>
<entry>15</entry>
<entry>14</entry>
<entry>13</entry>
<entry>12</entry>
<entry>11</entry>
<entry>10</entry>
<entry>9</entry>
<entry>8</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-AHSV8888-1X32">
<entry>V4L2_MBUS_FMT_AHSV8888_1X32</entry>
<entry>0x6001</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry>
<entry>a<subscript>5</subscript></entry>
<entry>a<subscript>4</subscript></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
<entry>h<subscript>7</subscript></entry>
<entry>h<subscript>6</subscript></entry>
<entry>h<subscript>5</subscript></entry>
<entry>h<subscript>4</subscript></entry>
<entry>h<subscript>3</subscript></entry>
<entry>h<subscript>2</subscript></entry>
<entry>h<subscript>1</subscript></entry>
<entry>h<subscript>0</subscript></entry>
<entry>s<subscript>7</subscript></entry>
<entry>s<subscript>6</subscript></entry>
<entry>s<subscript>5</subscript></entry>
<entry>s<subscript>4</subscript></entry>
<entry>s<subscript>3</subscript></entry>
<entry>s<subscript>2</subscript></entry>
<entry>s<subscript>1</subscript></entry>
<entry>s<subscript>0</subscript></entry>
<entry>v<subscript>7</subscript></entry>
<entry>v<subscript>6</subscript></entry>
<entry>v<subscript>5</subscript></entry>
<entry>v<subscript>4</subscript></entry>
<entry>v<subscript>3</subscript></entry>
<entry>v<subscript>2</subscript></entry>
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section>
<title>JPEG Compressed Formats</title>

10
Documentation/DocBook/media/v4l/v4l2.xml
View File

@ -140,6 +140,14 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.14</revnumber>
<date>2013-11-25</date>
<authorinitials>rr</authorinitials>
<revremark>Set width and height as unsigned on v4l2_rect.
</revremark>
</revision>
<revision>
<revnumber>3.11</revnumber>
<date>2013-05-26</date>
@ -501,7 +509,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.11</subtitle>
<subtitle>Revision 3.14</subtitle>
<chapter id="common">
&sub-common;

10
Documentation/DocBook/media/v4l/vidioc-cropcap.xml
View File

@ -133,18 +133,14 @@ rectangle, in pixels.</entry>
rectangle, in pixels.</entry>
</row>
<row>
<entry>__s32</entry>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Width of the rectangle, in pixels.</entry>
</row>
<row>
<entry>__s32</entry>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Height of the rectangle, in pixels. Width
and height cannot be negative, the fields are signed for
hysterical reasons. <!-- video4linux-list@redhat.com
on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" -->
</entry>
<entry>Height of the rectangle, in pixels.</entry>
</row>
</tbody>
</tgroup>

2
Documentation/DocBook/media/v4l/vidioc-streamon.xml
View File

@ -59,7 +59,7 @@ buffers are filled (if there are any empty buffers in the incoming
queue) until <constant>VIDIOC_STREAMON</constant> has been called.
Accordingly the output hardware is disabled, no video signal is
produced until <constant>VIDIOC_STREAMON</constant> has been called.
The ioctl will succeed only when at least one output buffer is in the
The ioctl will succeed when at least one output buffer is in the
incoming queue.</para>
<para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of

4
Documentation/HOWTO
View File

@ -112,7 +112,7 @@ required reading:
Other excellent descriptions of how to create patches properly are:
"The Perfect Patch"
http://kerneltrap.org/node/3737
http://www.ozlabs.org/~akpm/stuff/tpp.txt
"Linux kernel patch submission format"
http://linux.yyz.us/patch-format.html
@ -579,7 +579,7 @@ all time. It should describe the patch completely, containing:
For more details on what this should all look like, please see the
ChangeLog section of the document:
"The Perfect Patch"
http://userweb.kernel.org/~akpm/stuff/tpp.txt
http://www.ozlabs.org/~akpm/stuff/tpp.txt

4
Documentation/PCI/00-INDEX
View File

@ -2,12 +2,12 @@
- this file
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCI-DMA-mapping.txt
- info for PCI drivers using DMA portably across all platforms
PCIEBUS-HOWTO.txt
- a guide describing the PCI Express Port Bus driver
pci-error-recovery.txt
- info on PCI error recovery
pci-iov-howto.txt
- the PCI Express I/O Virtualization HOWTO
pci.txt
- info on the PCI subsystem for device driver authors
pcieaer-howto.txt

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

@ -82,93 +82,111 @@ Most of the hard work is done for the driver in the PCI layer. It simply
has to request that the PCI layer set up the MSI capability for this
device.
4.2.1 pci_enable_msi
4.2.1 pci_enable_msi_range
int pci_enable_msi(struct pci_dev *dev)
int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
A successful call allocates ONE interrupt to the device, regardless
of how many MSIs the device supports. The device is switched from
pin-based interrupt mode to MSI mode. The dev->irq number is changed
to a new number which represents the message signaled interrupt;
consequently, this function should be called before the driver calls
request_irq(), because an MSI is delivered via a vector that is
different from the vector of a pin-based interrupt.
This function allows a device driver to request any number of MSI
interrupts within specified range from 'minvec' to 'maxvec'.
4.2.2 pci_enable_msi_block
int pci_enable_msi_block(struct pci_dev *dev, int count)
This variation on the above call allows a device driver to request multiple
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 0, it has succeeded in allocating at least as many
interrupts as the driver requested (it may have allocated more in order
to satisfy the power-of-two requirement). 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 + count - 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 this function returns a positive number, it is
less than 'count' and indicates the number of interrupts that could have
been allocated. In neither case is the irq value updated or the device
switched into MSI mode.
The device driver must decide what action to take if
pci_enable_msi_block() returns a value less than the number requested.
For instance, the driver could still make use of fewer interrupts;
in this case the driver should call pci_enable_msi_block()
again. Note that it is not guaranteed to succeed, even when the
'count' has been reduced to the value returned from a previous call to
pci_enable_msi_block(). This is because there are multiple constraints
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_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 positive number it indicates the number of
MSI interrupts that have been successfully allocated. In this case
the device is switched from pin-based interrupt mode to MSI mode 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. Device driver can use the returned
number of successfully allocated MSI interrupts to further allocate
and initialize device resources.
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.
This function should be called before the driver calls request_irq(),
because MSI interrupts are delivered via vectors that are different
from the vector of a pin-based interrupt.
4.2.4 pci_disable_msi
It is ideal if drivers can cope with a variable number of MSI interrupts;
there are many reasons why the platform may not be able to provide the
exact number that a driver asks for.
There could be devices that can not operate with just any number of MSI
interrupts within a range. See chapter 4.3.1.3 to get the idea how to
handle such devices for MSI-X - the same logic applies to MSI.
4.2.1.1 Maximum possible number of MSI interrupts
The typical usage of MSI interrupts is to allocate as many vectors as
possible, likely up to the limit returned by pci_msi_vec_count() function:
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
{
return pci_enable_msi_range(pdev, 1, nvec);
}
Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive,
the value of 0 would be meaningless and could result in error.
Some devices have a minimal limit on number of MSI interrupts.
In this case the function could look like this:
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
{
return pci_enable_msi_range(pdev, FOO_DRIVER_MINIMUM_NVEC, nvec);
}
4.2.1.2 Exact number of MSI interrupts
If a driver is unable or unwilling to deal with a variable number of MSI
interrupts it could request a particular number of interrupts by passing
that number to pci_enable_msi_range() function as both 'minvec' and 'maxvec'
parameters:
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
{
return pci_enable_msi_range(pdev, nvec, nvec);
}
4.2.1.3 Single MSI mode
The most notorious example of the request type described above is
enabling the single MSI mode for a device. It could be done by passing
two 1s as 'minvec' and 'maxvec':
static int foo_driver_enable_single_msi(struct pci_dev *pdev)
{
return pci_enable_msi_range(pdev, 1, 1);
}
4.2.2 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() 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.
This function should be used to undo the effect of pci_enable_msi_range().
Calling it restores dev->irq to the pin-based interrupt number and frees
the previously allocated MSIs. The interrupts 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().
Failure to do so results in a BUG_ON(), leaving the device with
MSI enabled and thus leaking its vector.
4.2.3 pci_msi_vec_count
int pci_msi_vec_count(struct pci_dev *dev)
This function could be used to retrieve the number of MSI vectors the
device requested (via the Multiple Message Capable register). The MSI
specification only allows the returned value to be a power of two,
up to a maximum of 2^5 (32).
If this function returns a negative number, it indicates the device is
not capable of sending MSIs.
If this function returns a positive number, it indicates the maximum
number of MSI interrupt vectors that could be allocated.
4.3 Using MSI-X
The MSI-X capability is much more flexible than the MSI capability.
@ -188,26 +206,31 @@ in each element of the array to indicate for which entries the kernel
should assign interrupts; it is invalid to fill in two entries with the
same number.
4.3.1 pci_enable_msix
4.3.1 pci_enable_msix_range
int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
int pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries,
int minvec, int maxvec)
Calling this function asks the PCI subsystem to allocate 'nvec' MSIs.
Calling this function asks the PCI subsystem to allocate any number of
MSI-X interrupts within specified range from 'minvec' to 'maxvec'.
The 'entries' argument is a pointer to an array of msix_entry structs
which should be at least 'nvec' entries in size. On success, the
device is switched into MSI-X mode and the function returns 0.
The 'vector' member in each entry is populated with the interrupt number;
which should be at least 'maxvec' entries in size.
On success, the device is switched into MSI-X mode and the function
returns the number of MSI-X interrupts that have been successfully
allocated. In this case the 'vector' member in entries numbered from
0 to the returned value - 1 is populated with the interrupt number;
the driver should then call request_irq() for each 'vector' that it
decides to use. The device driver is responsible for keeping track of the
interrupts assigned to the MSI-X vectors so it can free them again later.
Device driver can use the returned number of successfully allocated MSI-X
interrupts to further allocate and initialize device resources.
If this function returns a negative number, it indicates an error and
the driver should not attempt to allocate any more MSI-X interrupts for
this device. If it returns a positive number, it indicates the maximum
number of interrupt vectors that could have been allocated. See example
below.
this device.
This function, in contrast with pci_enable_msi(), does not adjust
This function, in contrast with pci_enable_msi_range(), does not adjust
dev->irq. The device will not generate interrupts for this interrupt
number once MSI-X is enabled.
@ -218,28 +241,103 @@ It is ideal if drivers can cope with a variable number of MSI-X interrupts;
there are many reasons why the platform may not be able to provide the
exact number that a driver asks for.
A request loop to achieve that might look like:
There could be devices that can not operate with just any number of MSI-X
interrupts within a range. E.g., an network adapter might need let's say
four vectors per each queue it provides. Therefore, a number of MSI-X
interrupts allocated should be a multiple of four. In this case interface
pci_enable_msix_range() can not be used alone to request MSI-X interrupts
(since it can allocate any number within the range, without any notion of
the multiple of four) and the device driver should master a custom logic
to request the required number of MSI-X interrupts.
4.3.1.1 Maximum possible number of MSI-X interrupts
The typical usage of MSI-X interrupts is to allocate as many vectors as
possible, likely up to the limit returned by pci_msix_vec_count() function:
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
{
while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
rc = pci_enable_msix(adapter->pdev,
adapter->msix_entries, nvec);
if (rc > 0)
nvec = rc;
else
return rc;
return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,
1, nvec);
}
Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive,
the value of 0 would be meaningless and could result in error.
Some devices have a minimal limit on number of MSI-X interrupts.
In this case the function could look like this:
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
{
return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,
FOO_DRIVER_MINIMUM_NVEC, nvec);
}
4.3.1.2 Exact number of MSI-X interrupts
If a driver is unable or unwilling to deal with a variable number of MSI-X
interrupts it could request a particular number of interrupts by passing
that number to pci_enable_msix_range() function as both 'minvec' and 'maxvec'
parameters:
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
{
return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,
nvec, nvec);
}
4.3.1.3 Specific requirements to the number of MSI-X interrupts
As noted above, there could be devices that can not operate with just any
number of MSI-X interrupts within a range. E.g., let's assume a device that
is only capable sending the number of MSI-X interrupts which is a power of
two. A routine that enables MSI-X mode for such device might look like this:
/*
* Assume 'minvec' and 'maxvec' are non-zero
*/
static int foo_driver_enable_msix(struct foo_adapter *adapter,
int minvec, int maxvec)
{
int rc;
minvec = roundup_pow_of_two(minvec);
maxvec = rounddown_pow_of_two(maxvec);
if (minvec > maxvec)
return -ERANGE;
retry:
rc = pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
maxvec, maxvec);
/*
* -ENOSPC is the only error code allowed to be analized
*/
if (rc == -ENOSPC) {
if (maxvec == 1)
return -ENOSPC;
maxvec /= 2;
if (minvec > maxvec)
return -ENOSPC;
goto retry;
}
return -ENOSPC;
return rc;
}
Note how pci_enable_msix_range() return value is analized for a fallback -
any error code other than -ENOSPC indicates a fatal error and should not
be retried.
4.3.2 pci_disable_msix
void pci_disable_msix(struct pci_dev *dev)
This function should be used to undo the effect of pci_enable_msix(). It frees
the previously allocated message signaled interrupts. The interrupts may
This function should be used to undo the effect of pci_enable_msix_range().
It frees the previously allocated MSI-X interrupts. The interrupts may
subsequently be assigned to another device, so drivers should not cache
the value of the 'vector' elements over a call to pci_disable_msix().
@ -255,18 +353,32 @@ MSI-X Table. This address is mapped by the PCI subsystem, and should not
be accessed directly by the device driver. If the driver wishes to
mask or unmask an interrupt, it should call disable_irq() / enable_irq().
4.3.4 pci_msix_vec_count
int pci_msix_vec_count(struct pci_dev *dev)
This function could be used to retrieve number of entries in the device
MSI-X table.
If this function returns a negative number, it indicates the device is
not capable of sending MSI-Xs.
If this function returns a positive number, it indicates the maximum
number of MSI-X interrupt vectors that could be allocated.
4.4 Handling devices implementing both MSI and MSI-X capabilities
If a device implements both MSI and MSI-X capabilities, it can
run in either MSI mode or MSI-X mode, but not both simultaneously.
This is a requirement of the PCI spec, and it is enforced by the
PCI layer. Calling pci_enable_msi() when MSI-X is already enabled or
pci_enable_msix() when MSI is already enabled results in an error.
If a device driver wishes to switch between MSI and MSI-X at runtime,
it must first quiesce the device, then switch it back to pin-interrupt
mode, before calling pci_enable_msi() or pci_enable_msix() and resuming
operation. This is not expected to be a common operation but may be
useful for debugging or testing during development.
PCI layer. Calling pci_enable_msi_range() when MSI-X is already
enabled or pci_enable_msix_range() when MSI is already enabled
results in an error. If a device driver wishes to switch between MSI
and MSI-X at runtime, it must first quiesce the device, then switch
it back to pin-interrupt mode, before calling pci_enable_msi_range()
or pci_enable_msix_range() and resuming operation. This is not expected
to be a common operation but may be useful for debugging or testing
during development.
4.5 Considerations when using MSIs
@ -381,5 +493,5 @@ or disabled (0). If 0 is found in any of the msi_bus files belonging
to bridges between the PCI root and the device, MSIs are disabled.
It is also worth checking the device driver to see whether it supports MSIs.
For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or
pci_enable_msi_block().
For example, it may contain calls to pci_enable_msi_range() or
pci_enable_msix_range().

6
Documentation/PCI/pci.txt
View File

@ -123,8 +123,10 @@ initialization with a pointer to a structure describing the driver
The ID table is an array of struct pci_device_id entries ending with an
all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred
method of declaring the table. Each entry consists of:
all-zero entry. Definitions with static const are generally preferred.
Use of the deprecated macro DEFINE_PCI_DEVICE_TABLE should be avoided.
Each entry consists of:
vendor,device Vendor and device ID to match (or PCI_ANY_ID)

2
Documentation/RCU/00-INDEX
View File

@ -8,6 +8,8 @@ listRCU.txt
- Using RCU to Protect Read-Mostly Linked Lists
lockdep.txt
- RCU and lockdep checking
lockdep-splat.txt
- RCU Lockdep splats explained.
NMI-RCU.txt
- Using RCU to Protect Dynamic NMI Handlers
rcubarrier.txt

22
Documentation/RCU/trace.txt
View File

@ -396,14 +396,14 @@ o Each element of the form "3/3 ..>. 0:7 ^0" represents one rcu_node
The output of "cat rcu/rcu_sched/rcu_pending" looks as follows:
0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903
1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113
2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889
3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469
4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042
5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422
6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699
7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147
0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903 ndw=0
1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113 ndw=0
2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889 ndw=0
3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469 ndw=0
4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042 ndw=0
5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422 ndw=0
6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699 ndw=0
7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147 ndw=0
The fields are as follows:
@ -432,6 +432,10 @@ o "gpc" is the number of times that an old grace period had
o "gps" is the number of times that a new grace period had started,
but this CPU was not yet aware of it.
o "ndw" is the number of times that a wakeup of an rcuo
callback-offload kthread had to be deferred in order to avoid
deadlock.
o "nn" is the number of times that this CPU needed nothing.
@ -443,7 +447,7 @@ The output of "cat rcu/rcuboost" looks as follows:
balk: nt=0 egt=6541 bt=0 nb=0 ny=126 nos=0
This information is output only for rcu_preempt. Each two-line entry
corresponds to a leaf rcu_node strcuture. The fields are as follows:
corresponds to a leaf rcu_node structure. The fields are as follows:
o "n:m" is the CPU-number range for the corresponding two-line
entry. In the sample output above, the first entry covers

19
Documentation/acpi/apei/einj.txt
View File

@ -45,11 +45,22 @@ directory apei/einj. The following files are provided.
injection. Before this, please specify all necessary error
parameters.
- flags
Present for kernel version 3.13 and above. Used to specify which
of param{1..4} are valid and should be used by BIOS during injection.
Value is a bitmask as specified in ACPI5.0 spec for the
SET_ERROR_TYPE_WITH_ADDRESS data structure:
Bit 0 - Processor APIC field valid (see param3 below)
Bit 1 - Memory address and mask valid (param1 and param2)
Bit 2 - PCIe (seg,bus,dev,fn) valid (param4 below)
If set to zero, legacy behaviour is used where the type of injection
specifies just one bit set, and param1 is multiplexed.
- param1
This file is used to set the first error parameter value. Effect of
parameter depends on error_type specified. For example, if error
type is memory related type, the param1 should be a valid physical
memory address.
memory address. [Unless "flag" is set - see above]
- param2
This file is used to set the second error parameter value. Effect of
@ -58,6 +69,12 @@ directory apei/einj. The following files are provided.
address mask. Linux requires page or narrower granularity, say,
0xfffffffffffff000.
- param3
Used when the 0x1 bit is set in "flag" to specify the APIC id
- param4
Used when the 0x4 bit is set in "flag" to specify target PCIe device
- notrigger
The EINJ mechanism is a two step process. First inject the error, then
perform some actions to trigger it. Setting "notrigger" to 1 skips the

36
Documentation/acpi/enumeration.txt
View File

@ -293,36 +293,13 @@ the device to the driver. For example:
These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
specifies the path to the controller. In order to use these GPIOs in Linux
we need to translate them to the Linux GPIO numbers.
we need to translate them to the corresponding Linux GPIO descriptors.
In a simple case of just getting the Linux GPIO number from device
resources one can use acpi_get_gpio_by_index() helper function. It takes
pointer to the device and index of the GpioIo/GpioInt descriptor in the
device resources list. For example:
There is a standard GPIO API for that and is documented in
Documentation/gpio.txt.
int gpio_irq, gpio_power;
int ret;
gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
if (gpio_irq < 0)
/* handle error */
gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
if (gpio_power < 0)
/* handle error */
/* Now we can use the GPIO numbers */
Other GpioIo parameters must be converted first by the driver to be
suitable to the gpiolib before passing them.
In case of GpioInt resource an additional call to gpio_to_irq() must be
done before calling request_irq().
Note that the above API is ACPI specific and not recommended for drivers
that need to support non-ACPI systems. The recommended way is to use
the descriptor based GPIO interfaces. The above example looks like this
when converted to the GPIO desc:
In the above example we can get the corresponding two GPIO descriptors with
a code like this:
#include <linux/gpio/consumer.h>
...
@ -339,4 +316,5 @@ when converted to the GPIO desc:
/* Now we can use the GPIO descriptors */
See also Documentation/gpio.txt.
There are also devm_* versions of these functions which release the
descriptors once the device is released.

9
Documentation/acpi/namespace.txt
View File

@ -235,10 +235,6 @@ Wysocki <rafael.j.wysocki@intel.com>.
named object's type in the second column). In that case the object's
directory in sysfs will contain the 'path' attribute whose value is
the full path to the node from the namespace root.
struct acpi_device objects are created for the ACPI namespace nodes
whose _STA control methods return PRESENT or FUNCTIONING. The power
resource nodes or nodes without _STA are assumed to be both PRESENT
and FUNCTIONING.
F:
The struct acpi_device object is created for a fixed hardware
feature (as indicated by the fixed feature flag's name in the second
@ -340,7 +336,7 @@ Wysocki <rafael.j.wysocki@intel.com>.
| +-------------+-------+----------------+
| |
| | +- - - - - - - +- - - - - - +- - - - - - - -+
| +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
| +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
| | +- - - - - - - +- - - - - - +- - - - - - - -+
| |
| | +------------+------------+-----------------------+
@ -390,6 +386,3 @@ Wysocki <rafael.j.wysocki@intel.com>.
attribute (as described earlier in this document).
NOTE: N/A indicates the device object does not have the 'path' or the
'modalias' attribute.
NOTE: The PNP0C0D device listed above is highlighted (marked by "*")
to indicate it will be created only when its _STA methods return
PRESENT or FUNCTIONING.

14
Documentation/arm/00-INDEX
View File

@ -4,6 +4,8 @@ Booting
- requirements for booting
Interrupts
- ARM Interrupt subsystem documentation
IXP4xx
- Intel IXP4xx Network processor.
msm
- MSM specific documentation
Netwinder
@ -24,8 +26,16 @@ SPEAr
- ST SPEAr platform Linux Overview
VFP/
- Release notes for Linux Kernel Vector Floating Point support code
cluster-pm-race-avoidance.txt
- Algorithm for CPU and Cluster setup/teardown
empeg/
- Ltd's Empeg MP3 Car Audio Player
firmware.txt
- Secure firmware registration and calling.
kernel_mode_neon.txt
- How to use NEON instructions in kernel mode
kernel_user_helpers.txt
- Helper functions in kernel space made available for userspace.
mem_alignment
- alignment abort handler documentation
memory.txt
@ -34,3 +44,7 @@ nwfpe/
- NWFPE floating point emulator documentation
swp_emulation
- SWP/SWPB emulation handler/logging description
tcm.txt
- ARM Tightly Coupled Memory
vlocks.txt
- Voting locks, low-level mechanism relying on memory system atomic writes.

24
Documentation/arm/Marvell/README
View File

@ -211,6 +211,30 @@ MMP/MMP2 family (communication processor)
Linux kernel mach directory: arch/arm/mach-mmp
Linux kernel plat directory: arch/arm/plat-pxa
Berlin family (Digital Entertainment)
-------------------------------------
Flavors:
88DE3005, Armada 1500-mini
Design name: BG2CD
Core: ARM Cortex-A9, PL310 L2CC
Homepage: http://www.marvell.com/digital-entertainment/armada-1500-mini/
88DE3100, Armada 1500
Design name: BG2
Core: Marvell PJ4B (ARMv7), Tauros3 L2CC
Homepage: http://www.marvell.com/digital-entertainment/armada-1500/
Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE????
Design name: BG3
Core: ARM Cortex-A15, CA15 integrated L2CC
Homepage: http://www.marvell.com/digital-entertainment/
Directory: arch/arm/mach-berlin
Comments:
* This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
Long-term plans
---------------

13
Documentation/arm/Samsung-S3C24XX/GPIO.txt
View File

@ -85,21 +85,10 @@ between the calls.
Headers
-------
See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list
of GPIO pins, and the configuration values for them. This
is included by using #include <mach/regs-gpio.h>
The GPIO management functions are defined in the hardware
header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
included by #include <mach/hardware.h>
A useful amount of documentation can be found in the hardware
header on how the GPIO functions (and others) work.
Whilst a number of these functions do make some checks on what
is passed to them, for speed of use, they may not always ensure
that the user supplied data to them is correct.
PIN Numbers
-----------

6
Documentation/blackfin/00-INDEX
View File

@ -1,8 +1,10 @@
00-INDEX
- This file
Makefile
- Makefile for gptimers example file.
bfin-gpio-notes.txt
- Notes in developing/using bfin-gpio driver.
bfin-spi-notes.txt
- Notes for using bfin spi bus driver.
gptimers-example.c
- gptimers example

2
Documentation/block/00-INDEX
View File

@ -14,6 +14,8 @@ deadline-iosched.txt
- Deadline IO scheduler tunables
ioprio.txt
- Block io priorities (in CFQ scheduler)
null_blk.txt
- Null block for block-layer benchmarking.
queue-sysfs.txt
- Queue's sysfs entries
request.txt

7
Documentation/block/biodoc.txt
View File

@ -447,14 +447,13 @@ struct bio_vec {
* main unit of I/O for the block layer and lower layers (ie drivers)
*/
struct bio {
sector_t bi_sector;
struct bio *bi_next; /* request queue link */
struct block_device *bi_bdev; /* target device */
unsigned long bi_flags; /* status, command, etc */
unsigned long bi_rw; /* low bits: r/w, high: priority */
unsigned int bi_vcnt; /* how may bio_vec's */
unsigned int bi_idx; /* current index into bio_vec array */
struct bvec_iter bi_iter; /* current index into bio_vec array */
unsigned int bi_size; /* total size in bytes */
unsigned short bi_phys_segments; /* segments after physaddr coalesce*/
@ -480,7 +479,7 @@ With this multipage bio design:
- Code that traverses the req list can find all the segments of a bio
by using rq_for_each_segment. This handles the fact that a request
has multiple bios, each of which can have multiple segments.
- Drivers which can't process a large bio in one shot can use the bi_idx
- Drivers which can't process a large bio in one shot can use the bi_iter
field to keep track of the next bio_vec entry to process.
(e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
[TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying
@ -589,7 +588,7 @@ driver should not modify these values. The block layer sets up the
nr_sectors and current_nr_sectors fields (based on the corresponding
hard_xxx values and the number of bytes transferred) and updates it on
every transfer that invokes end_that_request_first. It does the same for the
buffer, bio, bio->bi_idx fields too.
buffer, bio, bio->bi_iter fields too.
The buffer field is just a virtual address mapping of the current segment
of the i/o buffer in cases where the buffer resides in low-memory. For high

111
Documentation/block/biovecs.txt 100644
View File

@ -0,0 +1,111 @@
Immutable biovecs and biovec iterators:
=======================================
Kent Overstreet <kmo@daterainc.com>
As of 3.13, biovecs should never be modified after a bio has been submitted.
Instead, we have a new struct bvec_iter which represents a range of a biovec -
the iterator will be modified as the bio is completed, not the biovec.
More specifically, old code that needed to partially complete a bio would
update bi_sector and bi_size, and advance bi_idx to the next biovec. If it
ended up partway through a biovec, it would increment bv_offset and decrement
bv_len by the number of bytes completed in that biovec.
In the new scheme of things, everything that must be mutated in order to
partially complete a bio is segregated into struct bvec_iter: bi_sector,
bi_size and bi_idx have been moved there; and instead of modifying bv_offset
and bv_len, struct bvec_iter has bi_bvec_done, which represents the number of
bytes completed in the current bvec.
There are a bunch of new helper macros for hiding the gory details - in
particular, presenting the illusion of partially completed biovecs so that
normal code doesn't have to deal with bi_bvec_done.
* Driver code should no longer refer to biovecs directly; we now have
bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs,
constructed from the raw biovecs but taking into account bi_bvec_done and
bi_size.
bio_for_each_segment() has been updated to take a bvec_iter argument
instead of an integer (that corresponded to bi_idx); for a lot of code the
conversion just required changing the types of the arguments to
bio_for_each_segment().
* Advancing a bvec_iter is done with bio_advance_iter(); bio_advance() is a
wrapper around bio_advance_iter() that operates on bio->bi_iter, and also
advances the bio integrity's iter if present.
There is a lower level advance function - bvec_iter_advance() - which takes
a pointer to a biovec, not a bio; this is used by the bio integrity code.
What's all this get us?
=======================
Having a real iterator, and making biovecs immutable, has a number of
advantages:
* Before, iterating over bios was very awkward when you weren't processing
exactly one bvec at a time - for example, bio_copy_data() in fs/bio.c,
which copies the contents of one bio into another. Because the biovecs
wouldn't necessarily be the same size, the old code was tricky convoluted -
it had to walk two different bios at the same time, keeping both bi_idx and
and offset into the current biovec for each.
The new code is much more straightforward - have a look. This sort of
pattern comes up in a lot of places; a lot of drivers were essentially open
coding bvec iterators before, and having common implementation considerably
simplifies a lot of code.
* Before, any code that might need to use the biovec after the bio had been
completed (perhaps to copy the data somewhere else, or perhaps to resubmit
it somewhere else if there was an error) had to save the entire bvec array
- again, this was being done in a fair number of places.
* Biovecs can be shared between multiple bios - a bvec iter can represent an
arbitrary range of an existing biovec, both starting and ending midway
through biovecs. This is what enables efficient splitting of arbitrary
bios. Note that this means we _only_ use bi_size to determine when we've
reached the end of a bio, not bi_vcnt - and the bio_iovec() macro takes
bi_size into account when constructing biovecs.
* Splitting bios is now much simpler. The old bio_split() didn't even work on
bios with more than a single bvec! Now, we can efficiently split arbitrary
size bios - because the new bio can share the old bio's biovec.
Care must be taken to ensure the biovec isn't freed while the split bio is
still using it, in case the original bio completes first, though. Using
bio_chain() when splitting bios helps with this.
* Submitting partially completed bios is now perfectly fine - this comes up
occasionally in stacking block drivers and various code (e.g. md and
bcache) had some ugly workarounds for this.
It used to be the case that submitting a partially completed bio would work
fine to _most_ devices, but since accessing the raw bvec array was the
norm, not all drivers would respect bi_idx and those would break. Now,
since all drivers _must_ go through the bvec iterator - and have been
audited to make sure they are - submitting partially completed bios is
perfectly fine.
Other implications:
===================
* Almost all usage of bi_idx is now incorrect and has been removed; instead,
where previously you would have used bi_idx you'd now use a bvec_iter,
probably passing it to one of the helper macros.
I.e. instead of using bio_iovec_idx() (or bio->bi_iovec[bio->bi_idx]), you
now use bio_iter_iovec(), which takes a bvec_iter and returns a
literal struct bio_vec - constructed on the fly from the raw biovec but
taking into account bi_bvec_done (and bi_size).
* bi_vcnt can't be trusted or relied upon by driver code - i.e. anything that
doesn't actually own the bio. The reason is twofold: firstly, it's not
actually needed for iterating over the bio anymore - we only use bi_size.
Secondly, when cloning a bio and reusing (a portion of) the original bio's
biovec, in order to calculate bi_vcnt for the new bio we'd have to iterate
over all the biovecs in the new bio - which is silly as it's not needed.
So, don't use bi_vcnt anymore.

72
Documentation/block/null_blk.txt 100644
View File

@ -0,0 +1,72 @@
Null block device driver
================================================================================
I. Overview
The null block device (/dev/nullb*) is used for benchmarking the various
block-layer implementations. It emulates a block device of X gigabytes in size.
The following instances are possible:
Single-queue block-layer
- Request-based.
- Single submission queue per device.
- Implements IO scheduling algorithms (CFQ, Deadline, noop).
Multi-queue block-layer
- Request-based.
- Configurable submission queues per device.
No block-layer (Known as bio-based)
- Bio-based. IO requests are submitted directly to the device driver.
- Directly accepts bio data structure and returns them.
All of them have a completion queue for each core in the system.
II. Module parameters applicable for all instances:
queue_mode=[0-2]: Default: 2-Multi-queue
Selects which block-layer the module should instantiate with.
0: Bio-based.
1: Single-queue.
2: Multi-queue.
home_node=[0--nr_nodes]: Default: NUMA_NO_NODE
Selects what CPU node the data structures are allocated from.
gb=[Size in GB]: Default: 250GB
The size of the device reported to the system.
bs=[Block size (in bytes)]: Default: 512 bytes
The block size reported to the system.
nr_devices=[Number of devices]: Default: 2
Number of block devices instantiated. They are instantiated as /dev/nullb0,
etc.
irq_mode=[0-2]: Default: 1-Soft-irq
The completion mode used for completing IOs to the block-layer.
0: None.
1: Soft-irq. Uses IPI to complete IOs across CPU nodes. Simulates the overhead
when IOs are issued from another CPU node than the home the device is
connected to.
2: Timer: Waits a specific period (completion_nsec) for each IO before
completion.
completion_nsec=[ns]: Default: 10.000ns
Combined with irq_mode=2 (timer). The time each completion event must wait.
submit_queues=[0..nr_cpus]:
The number of submission queues attached to the device driver. If unset, it
defaults to 1 on single-queue and bio-based instances. For multi-queue,
it is ignored when use_per_node_hctx module parameter is 1.
hw_queue_depth=[0..qdepth]: Default: 64
The hardware queue depth of the device.
III: Multi-queue specific parameters
use_per_node_hctx=[0/1]: Default: 0
0: The number of submit queues are set to the value of the submit_queues
parameter.
1: The multi-queue block layer is instantiated with a hardware dispatch
queue for each CPU node in the system.

21
Documentation/blockdev/ramdisk.txt
View File

@ -36,21 +36,30 @@ allowing one to squeeze more programs onto an average installation or
rescue floppy disk.
2) Kernel Command Line Parameters
2) Parameters
---------------------------------
2a) Kernel Command Line Parameters
ramdisk_size=N
==============
This parameter tells the RAM disk driver to set up RAM disks of N k size. The
default is 4096 (4 MB) (8192 (8 MB) on S390).
default is 4096 (4 MB).
ramdisk_blocksize=N
===================
2b) Module parameters
This parameter tells the RAM disk driver how many bytes to use per block. The
default is 1024 (BLOCK_SIZE).
rd_nr
=====
/dev/ramX devices created.
max_part
========
Maximum partition number.
rd_size
=======
See ramdisk_size.
3) Using "rdev -r"
------------------

6
drivers/staging/zram/zram.txt → Documentation/blockdev/zram.txt
View File

@ -1,8 +1,6 @@
zram: Compressed RAM based block devices
----------------------------------------
Project home: http://compcache.googlecode.com/
* Introduction
The zram module creates RAM based block devices named /dev/zram<id>
@ -69,9 +67,5 @@ Following shows a typical sequence of steps for using zram.
resets the disksize to zero. You must set the disksize again
before reusing the device.
Please report any problems at:
- Mailing list: linux-mm-cc at laptop dot org
- Issue tracker: http://code.google.com/p/compcache/issues/list
Nitin Gupta
ngupta@vflare.org

20
Documentation/cgroups/cgroups.txt
View File

@ -24,7 +24,6 @@ CONTENTS:
2.1 Basic Usage
2.2 Attaching processes
2.3 Mounting hierarchies by name
2.4 Notification API
3. Kernel API
3.1 Overview
3.2 Synchronization
@ -472,25 +471,6 @@ you give a subsystem a name.
The name of the subsystem appears as part of the hierarchy description
in /proc/mounts and /proc/<pid>/cgroups.
2.4 Notification API
--------------------
There is mechanism which allows to get notifications about changing
status of a cgroup.
To register a new notification handler you need to:
- create a file descriptor for event notification using eventfd(2);
- open a control file to be monitored (e.g. memory.usage_in_bytes);
- write "<event_fd> <control_fd> <args>" to cgroup.event_control.
Interpretation of args is defined by control file implementation;
eventfd will be woken up by control file implementation or when the
cgroup is removed.
To unregister a notification handler just close eventfd.
NOTE: Support of notifications should be implemented for the control
file. See documentation for the subsystem.
3. Kernel API
=============

4
Documentation/cgroups/memory.txt
View File

@ -577,7 +577,7 @@ Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable"
per-node page counts including "hierarchical_<counter>" which sums up all
hierarchical children's values in addition to the memcg's own value.
The ouput format of memory.numa_stat is:
The output format of memory.numa_stat is:
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
@ -670,7 +670,7 @@ page tables.
8.1 Interface
This feature is disabled by default. It can be enabledi (and disabled again) by
This feature is disabled by default. It can be enabled (and disabled again) by
writing to memory.move_charge_at_immigrate of the destination cgroup.
If you want to enable it:

5
Documentation/cgroups/net_cls.txt
View File

@ -6,6 +6,8 @@ tag network packets with a class identifier (classid).
The Traffic Controller (tc) can be used to assign
different priorities to packets from different cgroups.
Also, Netfilter (iptables) can use this tag to perform
actions on such packets.
Creating a net_cls cgroups instance creates a net_cls.classid file.
This net_cls.classid value is initialized to 0.
@ -32,3 +34,6 @@ tc class add dev eth0 parent 10: classid 10:1 htb rate 40mbit
- creating traffic class 10:1
tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup
configuring iptables, basic example:
iptables -A OUTPUT -m cgroup ! --cgroup 0x100001 -j DROP

6
Documentation/cgroups/resource_counter.txt
View File

@ -95,10 +95,10 @@ to work with it.
f. u64 res_counter_uncharge_until
(struct res_counter *rc, struct res_counter *top,
unsinged long val)
unsigned long val)
Almost same as res_cunter_uncharge() but propagation of uncharge
stops when rc == top. This is useful when kill a res_coutner in
Almost same as res_counter_uncharge() but propagation of uncharge
stops when rc == top. This is useful when kill a res_counter in
child cgroup.
2.1 Other accounting routines

45
Documentation/circular-buffers.txt
View File

@ -160,6 +160,7 @@ The producer will look something like this:
spin_lock(&producer_lock);
unsigned long head = buffer->head;
/* The spin_unlock() and next spin_lock() provide needed ordering. */
unsigned long tail = ACCESS_ONCE(buffer->tail);
if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
@ -168,9 +169,8 @@ The producer will look something like this:
produce_item(item);
smp_wmb(); /* commit the item before incrementing the head */
buffer->head = (head + 1) & (buffer->size - 1);
smp_store_release(buffer->head,
(head + 1) & (buffer->size - 1));
/* wake_up() will make sure that the head is committed before
* waking anyone up */
@ -183,9 +183,14 @@ This will instruct the CPU that the contents of the new item must be written
before the head index makes it available to the consumer and then instructs the
CPU that the revised head index must be written before the consumer is woken.
Note that wake_up() doesn't have to be the exact mechanism used, but whatever
is used must guarantee a (write) memory barrier between the update of the head
index and the change of state of the consumer, if a change of state occurs.
Note that wake_up() does not guarantee any sort of barrier unless something
is actually awakened. We therefore cannot rely on it for ordering. However,
there is always one element of the array left empty. Therefore, the
producer must produce two elements before it could possibly corrupt the
element currently being read by the consumer. Therefore, the unlock-lock
pair between consecutive invocations of the consumer provides the necessary
ordering between the read of the index indicating that the consumer has
vacated a given element and the write by the producer to that same element.
THE CONSUMER
@ -195,21 +200,20 @@ The consumer will look something like this:
spin_lock(&consumer_lock);
unsigned long head = ACCESS_ONCE(buffer->head);
/* Read index before reading contents at that index. */
unsigned long head = smp_load_acquire(buffer->head);
unsigned long tail = buffer->tail;
if (CIRC_CNT(head, tail, buffer->size) >= 1) {
/* read index before reading contents at that index */
smp_read_barrier_depends();
/* extract one item from the buffer */
struct item *item = buffer[tail];
consume_item(item);
smp_mb(); /* finish reading descriptor before incrementing tail */
buffer->tail = (tail + 1) & (buffer->size - 1);
/* Finish reading descriptor before incrementing tail. */
smp_store_release(buffer->tail,
(tail + 1) & (buffer->size - 1));
}
spin_unlock(&consumer_lock);
@ -218,12 +222,17 @@ This will instruct the CPU to make sure the index is up to date before reading
the new item, and then it shall make sure the CPU has finished reading the item
before it writes the new tail pointer, which will erase the item.
Note the use of ACCESS_ONCE() in both algorithms to read the opposition index.
This prevents the compiler from discarding and reloading its cached value -
which some compilers will do across smp_read_barrier_depends(). This isn't
strictly needed if you can be sure that the opposition index will _only_ be
used the once.
Note the use of ACCESS_ONCE() and smp_load_acquire() to read the
opposition index. This prevents the compiler from discarding and
reloading its cached value - which some compilers will do across
smp_read_barrier_depends(). This isn't strictly needed if you can
be sure that the opposition index will _only_ be used the once.
The smp_load_acquire() additionally forces the CPU to order against
subsequent memory references. Similarly, smp_store_release() is used
in both algorithms to write the thread's index. This documents the
fact that we are writing to something that can be read concurrently,
prevents the compiler from tearing the store, and enforces ordering
against previous accesses.
===============

7
Documentation/clk.txt
View File

@ -77,6 +77,11 @@ the operations defined in clk.h:
int (*set_parent)(struct clk_hw *hw, u8 index);
u8 (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long);
int (*set_rate_and_parent)(struct clk_hw *hw,
unsigned long rate,
unsigned long parent_rate, u8 index);
unsigned long (*recalc_accuracy)(struct clk_hw *hw,
unsigned long parent_accuracy);
void (*init)(struct clk_hw *hw);
};
@ -202,6 +207,8 @@ optional or must be evaluated on a case-by-case basis.
.set_parent | | | n | y | n |
.get_parent | | | n | y | n |
| | | | | |
.recalc_accuracy| | | | | |
| | | | | |
.init | | | | | |
-----------------------------------------------------------
[1] either one of round_rate or determine_rate is required.

26
Documentation/cpu-freq/boost.txt
View File

@ -17,8 +17,8 @@ Introduction
Some CPUs support a functionality to raise the operating frequency of
some cores in a multi-core package if certain conditions apply, mostly
if the whole chip is not fully utilized and below it's intended thermal
budget. This is done without operating system control by a combination
of hardware and firmware.
budget. The decision about boost disable/enable is made either at hardware
(e.g. x86) or software (e.g ARM).
On Intel CPUs this is called "Turbo Boost", AMD calls it "Turbo-Core",
in technical documentation "Core performance boost". In Linux we use
the term "boost" for convenience.
@ -48,24 +48,24 @@ be desirable:
User controlled switch
----------------------
To allow the user to toggle the boosting functionality, the acpi-cpufreq
driver exports a sysfs knob to disable it. There is a file:
To allow the user to toggle the boosting functionality, the cpufreq core
driver exports a sysfs knob to enable or disable it. There is a file:
/sys/devices/system/cpu/cpufreq/boost
which can either read "0" (boosting disabled) or "1" (boosting enabled).
Reading the file is always supported, even if the processor does not
support boosting. In this case the file will be read-only and always
reads as "0". Explicitly changing the permissions and writing to that
file anyway will return EINVAL.
The file is exported only when cpufreq driver supports boosting.
Explicitly changing the permissions and writing to that file anyway will
return EINVAL.
On supported CPUs one can write either a "0" or a "1" into this file.
This will either disable the boost functionality on all cores in the
whole system (0) or will allow the hardware to boost at will (1).
whole system (0) or will allow the software or hardware to boost at will
(1).
Writing a "1" does not explicitly boost the system, but just allows the
CPU (and the firmware) to boost at their discretion. Some implementations
take external factors like the chip's temperature into account, so
boosting once does not necessarily mean that it will occur every time
even using the exact same software setup.
CPU to boost at their discretion. Some implementations take external
factors like the chip's temperature into account, so boosting once does
not necessarily mean that it will occur every time even using the exact
same software setup.
AMD legacy cpb switch

40
Documentation/cpu-freq/intel-pstate.txt 100644
View File

@ -0,0 +1,40 @@
Intel P-state driver
--------------------
This driver implements a scaling driver with an internal governor for
Intel Core processors. The driver follows the same model as the
Transmeta scaling driver (longrun.c) and implements the setpolicy()
instead of target(). Scaling drivers that implement setpolicy() are
assumed to implement internal governors by the cpufreq core. All the
logic for selecting the current P state is contained within the
driver; no external governor is used by the cpufreq core.
Intel SandyBridge+ processors are supported.
New sysfs files for controlling P state selection have been added to
/sys/devices/system/cpu/intel_pstate/
max_perf_pct: limits the maximum P state that will be requested by
the driver stated as a percentage of the available performance.
min_perf_pct: limits the minimum P state that will be requested by
the driver stated as a percentage of the available performance.
no_turbo: limits the driver to selecting P states below the turbo
frequency range.
For contemporary Intel processors, the frequency is controlled by the
processor itself and the P-states exposed to software are related to
performance levels. The idea that frequency can be set to a single
frequency is fiction for Intel Core processors. Even if the scaling
driver selects a single P state the actual frequency the processor
will run at is selected by the processor itself.
New debugfs files have also been added to /sys/kernel/debug/pstate_snb/
deadband
d_gain_pct
i_gain_pct
p_gain_pct
sample_rate_ms
setpoint

2
Documentation/cpu-hotplug.txt
View File

@ -285,7 +285,7 @@ A: This is what you would need in your kernel code to receive notifications.
return NOTIFY_OK;
}
static struct notifier_block foobar_cpu_notifer =
static struct notifier_block foobar_cpu_notifier =
{
.notifier_call = foobar_cpu_callback,
};

41
Documentation/debugging-via-ohci1394.txt
View File

@ -22,10 +22,12 @@ locations such as buffers like the printk buffer or the process table.
Retrieving a full system memory dump is also possible over the FireWire,
using data transfer rates in the order of 10MB/s or more.
Memory access is currently limited to the low 4G of physical address
space which can be a problem on IA64 machines where memory is located
mostly above that limit, but it is rarely a problem on more common
hardware such as hardware based on x86, x86-64 and PowerPC.
With most FireWire controllers, memory access is limited to the low 4 GB
of physical address space. This can be a problem on IA64 machines where
memory is located mostly above that limit, but it is rarely a problem on
more common hardware such as x86, x86-64 and PowerPC. However, at least
Agere/LSI FW643e and FW643e2 controllers are known to support access to
physical addresses above 4 GB.
Together with a early initialization of the OHCI-1394 controller for debugging,
this facility proved most useful for examining long debugs logs in the printk
@ -36,17 +38,11 @@ available (notebooks) or too slow for extensive debug information (like ACPI).
Drivers
-------
The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers
to a working state and enables physical DMA by default for all remote nodes.
This can be turned off by ohci1394's module parameter phys_dma=0.
The alternative firewire-ohci driver in drivers/firewire uses filtered physical
The firewire-ohci driver in drivers/firewire uses filtered physical
DMA by default, which is more secure but not suitable for remote debugging.
Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
DMA.
Pass the remote_dma=1 parameter to the driver to get unfiltered physical DMA.
Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
Because the firewire-ohci driver depends on the PCI enumeration to be
completed, an initialization routine which runs pretty early has been
implemented for x86. This routine runs long before console_init() can be
called, i.e. before the printk buffer appears on the console.
@ -64,7 +60,7 @@ be used to view the printk buffer of a remote machine, even with live update.
Bernhard Kaindl enhanced firescope to support accessing 64-bit machines
from 32-bit firescope and vice versa:
- http://halobates.de/firewire/firescope-0.2.2.tar.bz2
- http://v3.sk/~lkundrak/firescope/
and he implemented fast system dump (alpha version - read README.txt):
- http://halobates.de/firewire/firedump-0.1.tar.bz2
@ -92,11 +88,11 @@ Step-by-step instructions for using firescope with early OHCI initialization:
1) Verify that your hardware is supported:
Load the ohci1394 or the fw-ohci module and check your kernel logs.
Load the firewire-ohci module and check your kernel logs.
You should see a line similar to
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[fe9ff800-fe9fffff]
... Max Packet=[2048] IR/IT contexts=[4/8]
firewire_ohci 0000:15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT
... contexts, quirks 0x11
when loading the driver. If you have no supported controller, many PCI,
CardBus and even some Express cards which are fully compliant to OHCI-1394
@ -105,6 +101,9 @@ Step-by-step instructions for using firescope with early OHCI initialization:
compliant, they are based on TI PCILynx chips and require drivers for Win-
dows operating systems.
The mentioned kernel log message contains ">4 GB phys DMA" in case of
OHCI-1394 controllers which support accesses above this limit.
2) Establish a working FireWire cable connection:
Any FireWire cable, as long at it provides electrically and mechanically
@ -113,20 +112,18 @@ Step-by-step instructions for using firescope with early OHCI initialization:
If an driver is running on both machines you should see a line like
ieee1394: Node added: ID:BUS[0-01:1023] GUID[0090270001b84bba]
firewire_core 0000:15:00.1: created device fw1: GUID 00061b0020105917, S400
on both machines in the kernel log when the cable is plugged in
and connects the two machines.
3) Test physical DMA using firescope:
On the debug host,
- load the raw1394 module,
- make sure that /dev/raw1394 is accessible,
On the debug host, make sure that /dev/fw* is accessible,
then start firescope:
$ firescope
Port 0 (ohci1394) opened, 2 nodes detected
Port 0 (/dev/fw1) opened, 2 nodes detected
FireScope
---------

16
Documentation/device-mapper/cache-policies.txt
View File

@ -40,8 +40,11 @@ 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>'.
'sequential_threshold <#nr_sequential_ios>'
'random_threshold <#nr_random_ios>'
'read_promote_adjustment <value>'
'write_promote_adjustment <value>'
'discard_promote_adjustment <value>'
The sequential threshold indicates the number of contiguous I/Os
required before a stream is treated as sequential. The random threshold
@ -55,6 +58,15 @@ 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.
Internally the mq policy maintains a promotion threshold variable. If
the hit count of a block not in the cache goes above this threshold it
gets promoted to the cache. The read, write and discard promote adjustment
tunables allow you to tweak the promotion threshold by adding a small
value based on the io type. They default to 4, 8 and 1 respectively.
If you're trying to quickly warm a new cache device you may wish to
reduce these to encourage promotion. Remember to switch them back to
their defaults after the cache fills though.
cleaner
-------

49
Documentation/device-mapper/cache.txt
View File

@ -217,36 +217,43 @@ 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>*
<metadata block size> <#used metadata blocks>/<#total metadata blocks>
<cache block size> <#used cache blocks>/<#total cache blocks>
<#read hits> <#read misses> <#write hits> <#write misses>
<#demotions> <#promotions> <#dirty> <#features> <features>*
<#core args> <core args>* <policy name> <#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
metadata block size : Fixed block size for each metadata block in
sectors
#used metadata blocks : Number of metadata blocks used
#total metadata blocks : Total number of metadata blocks
cache block size : Configurable block size for the cache device
in sectors
#used cache blocks : Number of blocks resident in the cache
#total cache blocks : Total number of cache 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
#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
#write hits : Number of times a WRITE bio has been mapped
to the cache
#write misses : Number of times a WRITE bio has been
#write misses : Number of times a WRITE bio has been
mapped to the origin
#demotions : Number of times a block has been removed
#demotions : Number of times a block has been removed
from the cache
#promotions : Number of times a block has been moved to
#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
#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
#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
policy name : Name of the policy
#policy args : Number of policy arguments to follow (must be even)
policy args : Key/value pairs
e.g. sequential_threshold
Messages
--------

7
Documentation/device-mapper/thin-provisioning.txt
View File

@ -235,6 +235,8 @@ i) Constructor
read_only: Don't allow any changes to be made to the pool
metadata.
error_if_no_space: Error IOs, instead of queueing, if no space.
Data block size must be between 64KB (128 sectors) and 1GB
(2097152 sectors) inclusive.
@ -276,6 +278,11 @@ ii) Status
contain the string 'Fail'. The userspace recovery tools
should then be used.
error_if_no_space|queue_if_no_space
If the pool runs out of data or metadata space, the pool will
either queue or error the IO destined to the data device. The
default is to queue the IO until more space is added.
iii) Messages
create_thin <dev id>

1
Documentation/devices.txt
View File

@ -409,6 +409,7 @@ Your cooperation is appreciated.
193 = /dev/d7s SPARC 7-segment display
194 = /dev/zkshim Zero-Knowledge network shim control
195 = /dev/elographics/e2201 Elographics touchscreen E271-2201
196 = /dev/vfio/vfio VFIO userspace driver interface
198 = /dev/sexec Signed executable interface
199 = /dev/scanners/cuecat :CueCat barcode scanner
200 = /dev/net/tun TAP/TUN network device

2
Documentation/devicetree/00-INDEX
View File

@ -8,3 +8,5 @@ https://lists.ozlabs.org/listinfo/devicetree-discuss
- this file
booting-without-of.txt
- Booting Linux without Open Firmware, describes history and format of device trees.
usage-model.txt
- How Linux uses DT and what DT aims to solve.

39
Documentation/devicetree/bindings/ABI.txt 100644
View File

@ -0,0 +1,39 @@
Devicetree (DT) ABI
I. Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit
summary document:
"That still leaves the question of, what does a stable binding look
like? Certainly a stable binding means that a newer kernel will not
break on an older device tree, but that doesn't mean the binding is
frozen for all time. Grant said there are ways to change bindings that
don't result in breakage. For instance, if a new property is added,
then default to the previous behaviour if it is missing. If a binding
truly needs an incompatible change, then change the compatible string
at the same time. The driver can bind against both the old and the
new. These guidelines aren't new, but they desperately need to be
documented."
II. General binding rules
1) Maintainers, don't let perfect be the enemy of good. Don't hold up a
binding because it isn't perfect.
2) Use specific compatible strings so that if we need to add a feature (DMA)
in the future, we can create a new compatible string. See I.
3) Bindings can be augmented, but the driver shouldn't break when given
the old binding. ie. add additional properties, but don't change the
meaning of an existing property. For drivers, default to the original
behaviour when a newly added property is missing.
4) Don't submit bindings for staging or unstable. That will be decided by
the devicetree maintainers *after* discussion on the mailinglist.
III. Notes
1) This document is intended as a general familiarization with the process as
decided at the 2013 Kernel Summit. When in doubt, the current word of the
devicetree maintainers overrules this document. In that situation, a patch
updating this document would be appreciated.

8
Documentation/devicetree/bindings/arm/arm-boards
View File

@ -14,6 +14,9 @@ Required nodes:
- core-module: the root node to the Integrator platforms must have
a core-module with regs and the compatible string
"arm,core-module-integrator"
- external-bus-interface: the root node to the Integrator platforms
must have an external bus interface with regs and the
compatible-string "arm,external-bus-interface"
Required properties for the core module:
- regs: the location and size of the core module registers, one
@ -48,6 +51,11 @@ Required nodes:
reg = <0x10000000 0x200>;
};
ebi@12000000 {
compatible = "arm,external-bus-interface";
reg = <0x12000000 0x100>;
};
syscon {
compatible = "arm,integrator-ap-syscon";
reg = <0x11000000 0x100>;

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

@ -2,6 +2,7 @@
Required properties:
- compatible: Should be "atmel,<chip>-aic"
<chip> can be "at91rm9200" or "sama5d3"
- 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 should be 3.

11
Documentation/devicetree/bindings/arm/atmel-at91.txt
View File

@ -20,6 +20,10 @@ TC/TCLIB Timer required properties:
- interrupts: Should contain all interrupts for the TC block
Note that you can specify several interrupt cells if the TC
block has one interrupt per channel.
- clock-names: tuple listing input clock names.
Required elements: "t0_clk"
Optional elements: "t1_clk", "t2_clk"
- clocks: phandles to input clocks.
Examples:
@ -28,6 +32,8 @@ One interrupt per TC block:
compatible = "atmel,at91rm9200-tcb";
reg = <0xfff7c000 0x100>;
interrupts = <18 4>;
clocks = <&tcb0_clk>;
clock-names = "t0_clk";
};
One interrupt per TC channel in a TC block:
@ -35,6 +41,8 @@ One interrupt per TC channel in a TC block:
compatible = "atmel,at91rm9200-tcb";
reg = <0xfffdc000 0x100>;
interrupts = <26 4 27 4 28 4>;
clocks = <&tcb1_clk>;
clock-names = "t0_clk";
};
RSTC Reset Controller required properties:
@ -50,7 +58,8 @@ Example:
};
RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91sam9260-sdramc",
- compatible: Should be "atmel,at91rm9200-sdramc",
"atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
- reg: Should contain registers location and length
For at91sam9263 and at91sam9g45 you must specify 2 entries.

7
Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
View File

@ -8,13 +8,18 @@ Required properties:
- DEPRECATED: compatible : "bcm,kona-timer"
- reg : Register range for the timer
- interrupts : interrupt for the timer
- clocks: phandle + clock specifier pair of the external clock
- clock-frequency: frequency that the clock operates
Only one of clocks or clock-frequency should be specified.
Refer to clocks/clock-bindings.txt for generic clock consumer properties.
Example:
timer@35006000 {
compatible = "brcm,kona-timer";
reg = <0x35006000 0x1000>;
interrupts = <0x0 7 0x4>;
clock-frequency = <32768>;
clocks = <&hub_timer_clk>;
};

46
Documentation/devicetree/bindings/arm/davinci/nand.txt
View File

@ -1,46 +0,0 @@
* Texas Instruments Davinci NAND
This file provides information, what the device node for the
davinci nand interface contain.
Required properties:
- compatible: "ti,davinci-nand";
- reg : contain 2 offset/length values:
- offset and length for the access window
- offset and length for accessing the aemif control registers
- ti,davinci-chipselect: Indicates on the davinci_nand driver which
chipselect is used for accessing the nand.
Recommended properties :
- ti,davinci-mask-ale: mask for ale
- ti,davinci-mask-cle: mask for cle
- ti,davinci-mask-chipsel: mask for chipselect
- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
- "none"
- "soft"
- "hw"
- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
- ti,davinci-nand-buswidth: buswidth 8 or 16
- ti,davinci-nand-use-bbt: use flash based bad block table support.
nand device bindings may contain additional sub-nodes describing
partitions of the address space. See partition.txt for more detail.
Example(da850 EVM ):
nand_cs3@62000000 {
compatible = "ti,davinci-nand";
reg = <0x62000000 0x807ff
0x68000000 0x8000>;
ti,davinci-chipselect = <1>;
ti,davinci-mask-ale = <0>;
ti,davinci-mask-cle = <0>;
ti,davinci-mask-chipsel = <0>;
ti,davinci-ecc-mode = "hw";
ti,davinci-ecc-bits = <4>;
ti,davinci-nand-use-bbt;
partition@180000 {
label = "ubifs";
reg = <0x180000 0x7e80000>;
};
};

20
Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt 100644
View File

@ -0,0 +1,20 @@
Trusted Foundations
-------------------
Boards that use the Trusted Foundations secure monitor can signal its
presence by declaring a node compatible with "tlm,trusted-foundations"
under the /firmware/ node
Required properties:
- compatible: "tlm,trusted-foundations"
- tlm,version-major: major version number of Trusted Foundations firmware
- tlm,version-minor: minor version number of Trusted Foundations firmware
Example:
firmware {
trusted-foundations {
compatible = "tlm,trusted-foundations";
tlm,version-major = <2>;
tlm,version-minor = <8>;
};
};

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

@ -11,6 +11,7 @@ have PPIs or SGIs.
Main node required properties:
- compatible : should be one of:
"arm,gic-400"
"arm,cortex-a15-gic"
"arm,cortex-a9-gic"
"arm,cortex-a7-gic"

32
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 100644
View File

@ -0,0 +1,32 @@
Hisilicon Platforms Device Tree Bindings
----------------------------------------------------
Hi4511 Board
Required root node properties:
- compatible = "hisilicon,hi3620-hi4511";
Hisilicon system controller
Required properties:
- compatible : "hisilicon,sysctrl"
- reg : Register address and size
Optional properties:
- smp-offset : offset in sysctrl for notifying slave cpu booting
cpu 1, reg;
cpu 2, reg + 0x4;
cpu 3, reg + 0x8;
If reg value is not zero, cpun exit wfi and go
- resume-offset : offset in sysctrl for notifying cpu0 when resume
- reboot-offset : offset in sysctrl for system reboot
Example:
/* for Hi3620 */
sysctrl: system-controller@fc802000 {
compatible = "hisilicon,sysctrl";
reg = <0xfc802000 0x1000>;
smp-offset = <0x31c>;
resume-offset = <0x308>;
reboot-offset = <0x4>;
};

23
Documentation/devicetree/bindings/arm/l2cc.txt
View File

@ -7,20 +7,21 @@ The ARM L2 cache representation in the device tree should be done as follows:
Required properties:
- compatible : should be one of:
"arm,pl310-cache"
"arm,l220-cache"
"arm,l210-cache"
"marvell,aurora-system-cache": Marvell Controller designed to be
"arm,pl310-cache"
"arm,l220-cache"
"arm,l210-cache"
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
offset needs to be added to the address before passing down to the L2
cache controller
"marvell,aurora-system-cache": Marvell Controller designed to be
compatible with the ARM one, with system cache mode (meaning
maintenance operations on L1 are broadcasted to the L2 and L2
performs the same operation).
"marvell,"aurora-outer-cache: Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
offset needs to be added to the address before passing down to the L2
cache controller
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by
"brcm,bcm11351-a2-pl310-cache"
"marvell,aurora-outer-cache": Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
"marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
with arm,pl310-cache controller.
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped

24
Documentation/devicetree/bindings/arm/marvell,berlin.txt 100644
View File

@ -0,0 +1,24 @@
Marvell Berlin SoC Family Device Tree Bindings
---------------------------------------------------------------
Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
shall have the following properties:
* Required root node properties:
compatible: must contain "marvell,berlin"
In addition, the above compatible shall be extended with the specific
SoC and board used. Currently known SoC compatibles are:
"marvell,berlin2" for Marvell Armada 1500 (BG2, 88DE3100),
"marvell,berlin2cd" for Marvell Armada 1500-mini (BG2CD, 88DE3005)
"marvell,berlin2ct" for Marvell Armada ? (BG2CT, 88DE????)
"marvell,berlin3" for Marvell Armada ? (BG3, 88DE????)
* Example:
/ {
model = "Sony NSZ-GS7";
compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
...
}

12
Documentation/devicetree/bindings/arm/moxart.txt 100644
View File

@ -0,0 +1,12 @@
MOXA ART device tree bindings
Boards with the MOXA ART SoC shall have the following properties:
Required root node property:
compatible = "moxa,moxart";
Boards:
- UC-7112-LX: embedded computer
compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"

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

@ -31,6 +31,59 @@ spinlock@1 {
ti,hwmods = "spinlock";
};
SoC Type (optional):
- General Purpose devices
compatible = "ti,gp"
- High Security devices
compatible = "ti,hs"
SoC Families:
- OMAP2 generic - defaults to OMAP2420
compatible = "ti,omap2"
- OMAP3 generic - defaults to OMAP3430
compatible = "ti,omap3"
- OMAP4 generic - defaults to OMAP4430
compatible = "ti,omap4"
- OMAP5 generic - defaults to OMAP5430
compatible = "ti,omap5"
- DRA7 generic - defaults to DRA742
compatible = "ti,dra7"
- AM43x generic - defaults to AM4372
compatible = "ti,am43"
SoCs:
- OMAP2420
compatible = "ti,omap2420", "ti,omap2"
- OMAP2430
compatible = "ti,omap2430", "ti,omap2"
- OMAP3430
compatible = "ti,omap3430", "ti,omap3"
- AM3517
compatible = "ti,am3517", "ti,omap3"
- OMAP3630
compatible = "ti,omap36xx", "ti,omap3"
- AM33xx
compatible = "ti,am33xx", "ti,omap3"
- OMAP4430
compatible = "ti,omap4430", "ti,omap4"
- OMAP4460
compatible = "ti,omap4460", "ti,omap4"
- OMAP5430
compatible = "ti,omap5430", "ti,omap5"
- OMAP5432
compatible = "ti,omap5432", "ti,omap5"
- DRA742
compatible = "ti,dra7xx", "ti,dra7"
- AM4372
compatible = "ti,am4372", "ti,am43"
Boards:

7
Documentation/devicetree/bindings/arm/samsung/sysreg.txt
View File

@ -1,7 +1,12 @@
SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
Properties:
- name : should be 'sysreg';
- compatible : should contain "samsung,<chip name>-sysreg", "syscon";
For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
- reg : offset and length of the register set.
Example:
syscon@10010000 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x10010000 0x400>;
};

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

@ -32,3 +32,8 @@ board-specific compatible values:
nvidia,whistler
toradex,colibri_t20-512
toradex,iris
Trusted Foundations
-------------------------------------------
Tegra supports the Trusted Foundation secure monitor. See the
"tlm,trusted-foundations" binding's documentation for more details.

1
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
View File

@ -9,6 +9,7 @@ Required properties:
- compatible : Should contain "nvidia,tegra<chip>-pmc".
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entries:
"pclk" (The Tegra clock of that name),
"clk32k_in" (The 32KHz clock input to Tegra).

5
Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
View File

@ -29,3 +29,8 @@ pic: pic@14000000 {
clear-mask = <0xffffffff>;
valid-mask = <0x003fffff>;
};
Optional properties:
- interrupts: if the FPGA IRQ controller is cascaded, i.e. if its IRQ
output is simply connected to the input of another IRQ controller,
then the parent IRQ shall be specified in this property.

2
Documentation/devicetree/bindings/ata/marvell.txt
View File

@ -1,7 +1,7 @@
* Marvell Orion SATA
Required Properties:
- compatibility : "marvell,orion-sata"
- compatibility : "marvell,orion-sata" or "marvell,armada-370-sata"
- reg : Address range of controller
- interrupts : Interrupt controller is using
- nr-ports : Number of SATA ports in use.

18
Documentation/devicetree/bindings/ata/sata_rcar.txt 100644
View File

@ -0,0 +1,18 @@
* Renesas R-Car SATA
Required properties:
- compatible : should contain one of the following:
- "renesas,sata-r8a7779" for R-Car H1
- "renesas,sata-r8a7790" for R-Car H2
- "renesas,sata-r8a7791" for R-Car M2
- reg : address and length of the SATA registers;
- interrupts : must consist of one interrupt specifier.
Example:
sata: sata@fc600000 {
compatible = "renesas,sata-r8a7779";
reg = <0xfc600000 0x2000>;
interrupt-parent = <&gic>;
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
};

339
Documentation/devicetree/bindings/clock/at91-clock.txt 100644
View File

@ -0,0 +1,339 @@
Device Tree Clock bindings for arch-at91
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of the following:
"atmel,at91rm9200-pmc" or
"atmel,at91sam9g45-pmc" or
"atmel,at91sam9n12-pmc" or
"atmel,at91sam9x5-pmc" or
"atmel,sama5d3-pmc":
at91 PMC (Power Management Controller)
All at91 specific clocks (clocks defined below) must be child
node of the PMC node.
"atmel,at91rm9200-clk-main":
at91 main oscillator
"atmel,at91rm9200-clk-master" or
"atmel,at91sam9x5-clk-master":
at91 master clock
"atmel,at91sam9x5-clk-peripheral" or
"atmel,at91rm9200-clk-peripheral":
at91 peripheral clocks
"atmel,at91rm9200-clk-pll" or
"atmel,at91sam9g45-clk-pll" or
"atmel,at91sam9g20-clk-pllb" or
"atmel,sama5d3-clk-pll":
at91 pll clocks
"atmel,at91sam9x5-clk-plldiv":
at91 plla divisor
"atmel,at91rm9200-clk-programmable" or
"atmel,at91sam9g45-clk-programmable" or
"atmel,at91sam9x5-clk-programmable":
at91 programmable clocks
"atmel,at91sam9x5-clk-smd":
at91 SMD (Soft Modem) clock
"atmel,at91rm9200-clk-system":
at91 system clocks
"atmel,at91rm9200-clk-usb" or
"atmel,at91sam9x5-clk-usb" or
"atmel,at91sam9n12-clk-usb":
at91 usb clock
"atmel,at91sam9x5-clk-utmi":
at91 utmi clock
Required properties for PMC node:
- reg : defines the IO memory reserved for the PMC.
- #size-cells : shall be 0 (reg is used to encode clk id).
- #address-cells : shall be 1 (reg is used to encode clk id).
- interrupts : shall be set to PMC interrupt line.
- interrupt-controller : tell that the PMC is an interrupt controller.
- #interrupt-cells : must be set to 1. The first cell encodes the interrupt id,
and reflect the bit position in the PMC_ER/DR/SR registers.
You can use the dt macros defined in dt-bindings/clk/at91.h.
0 (AT91_PMC_MOSCS) -> main oscillator ready
1 (AT91_PMC_LOCKA) -> PLL A ready
2 (AT91_PMC_LOCKB) -> PLL B ready
3 (AT91_PMC_MCKRDY) -> master clock ready
6 (AT91_PMC_LOCKU) -> UTMI PLL clock ready
8 .. 15 (AT91_PMC_PCKRDY(id)) -> programmable clock ready
16 (AT91_PMC_MOSCSELS) -> main oscillator selected
17 (AT91_PMC_MOSCRCS) -> RC main oscillator stabilized
18 (AT91_PMC_CFDEV) -> clock failure detected
For example:
pmc: pmc@fffffc00 {
compatible = "atmel,sama5d3-pmc";
interrupts = <1 4 7>;
interrupt-controller;
#interrupt-cells = <2>;
#size-cells = <0>;
#address-cells = <1>;
/* put at91 clocks here */
};
Required properties for main clock:
- interrupt-parent : must reference the PMC node.
- interrupts : shall be set to "<0>".
- #clock-cells : from common clock binding; shall be set to 0.
- clocks (optional if clock-frequency is provided) : shall be the slow clock
phandle. This clock is used to calculate the main clock rate if
"clock-frequency" is not provided.
- clock-frequency : the main oscillator frequency.Prefer the use of
"clock-frequency" over automatic clock rate calculation.
For example:
main: mainck {
compatible = "atmel,at91rm9200-clk-main";
interrupt-parent = <&pmc>;
interrupts = <0>;
#clock-cells = <0>;
clocks = <&ck32k>;
clock-frequency = <18432000>;
};
Required properties for master clock:
- interrupt-parent : must reference the PMC node.
- interrupts : shall be set to "<3>".
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : shall be the master clock sources (see atmel datasheet) phandles.
e.g. "<&ck32k>, <&main>, <&plla>, <&pllb>".
- atmel,clk-output-range : minimum and maximum clock frequency (two u32
fields).
e.g. output = <0 133000000>; <=> 0 to 133MHz.
- atmel,clk-divisors : master clock divisors table (four u32 fields).
0 <=> reserved value.
e.g. divisors = <1 2 4 6>;
- atmel,master-clk-have-div3-pres : some SoC use the reserved value 7 in the
PRES field as CLOCK_DIV3 (e.g sam9x5).
For example:
mck: mck {
compatible = "atmel,at91rm9200-clk-master";
interrupt-parent = <&pmc>;
interrupts = <3>;
#clock-cells = <0>;
atmel,clk-output-range = <0 133000000>;
atmel,clk-divisors = <1 2 4 0>;
};
Required properties for peripheral clocks:
- #size-cells : shall be 0 (reg is used to encode clk id).
- #address-cells : shall be 1 (reg is used to encode clk id).
- clocks : shall be the master clock phandle.
e.g. clocks = <&mck>;
- name: device tree node describing a specific system clock.
* #clock-cells : from common clock binding; shall be set to 0.
* reg: peripheral id. See Atmel's datasheets to get a full
list of peripheral ids.
* atmel,clk-output-range : minimum and maximum clock frequency
(two u32 fields). Only valid on at91sam9x5-clk-peripheral
compatible IPs.
For example:
periph: periphck {
compatible = "atmel,at91sam9x5-clk-peripheral";
#size-cells = <0>;
#address-cells = <1>;
clocks = <&mck>;
ssc0_clk {
#clock-cells = <0>;
reg = <2>;
atmel,clk-output-range = <0 133000000>;
};
usart0_clk {
#clock-cells = <0>;
reg = <3>;
atmel,clk-output-range = <0 66000000>;
};
};
Required properties for pll clocks:
- interrupt-parent : must reference the PMC node.
- interrupts : shall be set to "<1>".
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : shall be the main clock phandle.
- reg : pll id.
0 -> PLL A
1 -> PLL B
- atmel,clk-input-range : minimum and maximum source clock frequency (two u32
fields).
e.g. input = <1 32000000>; <=> 1 to 32MHz.
- #atmel,pll-clk-output-range-cells : number of cells reserved for pll output
range description. Sould be set to 2, 3
or 4.
* 1st and 2nd cells represent the frequency range (min-max).
* 3rd cell is optional and represents the OUT field value for the given
range.
* 4th cell is optional and represents the ICPLL field (PLLICPR
register)
- atmel,pll-clk-output-ranges : pll output frequency ranges + optional parameter
depending on #atmel,pll-output-range-cells
property value.
For example:
plla: pllack {
compatible = "atmel,at91sam9g45-clk-pll";
interrupt-parent = <&pmc>;
interrupts = <1>;
#clock-cells = <0>;
clocks = <&main>;
reg = <0>;
atmel,clk-input-range = <2000000 32000000>;
#atmel,pll-clk-output-range-cells = <4>;
atmel,pll-clk-output-ranges = <74500000 800000000 0 0
69500000 750000000 1 0
64500000 700000000 2 0
59500000 650000000 3 0
54500000 600000000 0 1
49500000 550000000 1 1
44500000 500000000 2 1
40000000 450000000 3 1>;
};
Required properties for plldiv clocks (plldiv = pll / 2):
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : shall be the plla clock phandle.
The pll divisor is equal to 2 and cannot be changed.
For example:
plladiv: plladivck {
compatible = "atmel,at91sam9x5-clk-plldiv";
#clock-cells = <0>;
clocks = <&plla>;
};
Required properties for programmable clocks:
- interrupt-parent : must reference the PMC node.
- #size-cells : shall be 0 (reg is used to encode clk id).
- #address-cells : shall be 1 (reg is used to encode clk id).
- clocks : shall be the programmable clock source phandles.
e.g. clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
- name: device tree node describing a specific prog clock.
* #clock-cells : from common clock binding; shall be set to 0.
* reg : programmable clock id (register offset from PCKx
register).
* interrupts : shall be set to "<(8 + id)>".
For example:
prog: progck {
compatible = "atmel,at91sam9g45-clk-programmable";
#size-cells = <0>;
#address-cells = <1>;
interrupt-parent = <&pmc>;
clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
prog0 {
#clock-cells = <0>;
reg = <0>;
interrupts = <8>;
};
prog1 {
#clock-cells = <0>;
reg = <1>;
interrupts = <9>;
};
};
Required properties for smd clock:
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : shall be the smd clock source phandles.
e.g. clocks = <&plladiv>, <&utmi>;
For example:
smd: smdck {
compatible = "atmel,at91sam9x5-clk-smd";
#clock-cells = <0>;
clocks = <&plladiv>, <&utmi>;
};
Required properties for system clocks:
- #size-cells : shall be 0 (reg is used to encode clk id).
- #address-cells : shall be 1 (reg is used to encode clk id).
- name: device tree node describing a specific system clock.
* #clock-cells : from common clock binding; shall be set to 0.
* reg: system clock id (bit position in SCER/SCDR/SCSR registers).
See Atmel's datasheet to get a full list of system clock ids.
For example:
system: systemck {
compatible = "atmel,at91rm9200-clk-system";
#address-cells = <1>;
#size-cells = <0>;
ddrck {
#clock-cells = <0>;
reg = <2>;
clocks = <&mck>;
};
uhpck {
#clock-cells = <0>;
reg = <6>;
clocks = <&usb>;
};
udpck {
#clock-cells = <0>;
reg = <7>;
clocks = <&usb>;
};
};
Required properties for usb clock:
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : shall be the smd clock source phandles.
e.g. clocks = <&pllb>;
- atmel,clk-divisors (only available for "atmel,at91rm9200-clk-usb"):
usb clock divisor table.
e.g. divisors = <1 2 4 0>;
For example:
usb: usbck {
compatible = "atmel,at91sam9x5-clk-usb";
#clock-cells = <0>;
clocks = <&plladiv>, <&utmi>;
};
usb: usbck {
compatible = "atmel,at91rm9200-clk-usb";
#clock-cells = <0>;
clocks = <&pllb>;
atmel,clk-divisors = <1 2 4 0>;
};
Required properties for utmi clock:
- interrupt-parent : must reference the PMC node.
- interrupts : shall be set to "<AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>".
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : shall be the main clock source phandle.
For example:
utmi: utmick {
compatible = "atmel,at91sam9x5-clk-utmi";
interrupt-parent = <&pmc>;
interrupts = <AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>;
#clock-cells = <0>;
clocks = <&main>;
};

93
Documentation/devicetree/bindings/clock/bcm-kona-clock.txt 100644
View File

@ -0,0 +1,93 @@
Broadcom Kona Family Clocks
This binding is associated with Broadcom SoCs having "Kona" style
clock control units (CCUs). A CCU is a clock provider that manages
a set of clock signals. Each CCU is represented by a node in the
device tree.
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible
Shall have one of the following values:
- "brcm,bcm11351-root-ccu"
- "brcm,bcm11351-aon-ccu"
- "brcm,bcm11351-hub-ccu"
- "brcm,bcm11351-master-ccu"
- "brcm,bcm11351-slave-ccu"
- reg
Shall define the base and range of the address space
containing clock control registers
- #clock-cells
Shall have value <1>. The permitted clock-specifier values
are defined below.
- clock-output-names
Shall be an ordered list of strings defining the names of
the clocks provided by the CCU.
BCM281XX family SoCs use Kona CCUs. The following table defines
the set of CCUs and clock specifiers for BCM281XX clocks. When
a clock consumer references a clocks, its symbolic specifier
(rather than its numeric index value) should be used. These
specifiers are defined in "include/dt-bindings/clock/bcm281xx.h".
CCU Clock Type Index Specifier
--- ----- ---- ----- ---------
root frac_1m peri 0 BCM281XX_ROOT_CCU_FRAC_1M
aon hub_timer peri 0 BCM281XX_AON_CCU_HUB_TIMER
aon pmu_bsc peri 1 BCM281XX_AON_CCU_PMU_BSC
aon pmu_bsc_var peri 2 BCM281XX_AON_CCU_PMU_BSC_VAR
hub tmon_1m peri 0 BCM281XX_HUB_CCU_TMON_1M
master sdio1 peri 0 BCM281XX_MASTER_CCU_SDIO1
master sdio2 peri 1 BCM281XX_MASTER_CCU_SDIO2
master sdio3 peri 2 BCM281XX_MASTER_CCU_SDIO3
master sdio4 peri 3 BCM281XX_MASTER_CCU_SDIO4
master dmac peri 4 BCM281XX_MASTER_CCU_DMAC
master usb_ic peri 5 BCM281XX_MASTER_CCU_USB_IC
master hsic2_48m peri 6 BCM281XX_MASTER_CCU_HSIC_48M
master hsic2_12m peri 7 BCM281XX_MASTER_CCU_HSIC_12M
slave uartb peri 0 BCM281XX_SLAVE_CCU_UARTB
slave uartb2 peri 1 BCM281XX_SLAVE_CCU_UARTB2
slave uartb3 peri 2 BCM281XX_SLAVE_CCU_UARTB3
slave uartb4 peri 3 BCM281XX_SLAVE_CCU_UARTB4
slave ssp0 peri 4 BCM281XX_SLAVE_CCU_SSP0
slave ssp2 peri 5 BCM281XX_SLAVE_CCU_SSP2
slave bsc1 peri 6 BCM281XX_SLAVE_CCU_BSC1
slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2
slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3
slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM
Device tree example:
slave_ccu: slave_ccu {
compatible = "brcm,bcm11351-slave-ccu";
reg = <0x3e011000 0x0f00>;
#clock-cells = <1>;
clock-output-names = "uartb",
"uartb2",
"uartb3",
"uartb4";
};
ref_crystal_clk: ref_crystal {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <26000000>;
};
uart@3e002000 {
compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
status = "disabled";
reg = <0x3e002000 0x1000>;
clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>;
interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
};

39
Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
View File

@ -8,12 +8,29 @@ Required Properties:
- compatible: should be one of the following:
- "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs.
- "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5 SoCs.
- "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250
SoCs.
- "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420
SoCs.
- reg: physical base address and length of the controller's register set.
- #clock-cells: should be 1.
- clocks:
- pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll"
is used if not specified.
- pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll"
is used if not specified.
- cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not
specified.
- sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if
not specified.
- sclk_pcm_in: PCM clock, parent of sclk_pcm. "sclk_pcm0" is used if not
specified.
- clock-names: Aliases for the above clocks. They should be "pll_ref",
"pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume. Some of the clocks are available only on a particular
@ -34,8 +51,10 @@ i2s_bus 6
sclk_i2s 7
pcm_bus 8
sclk_pcm 9
adma 10 Exynos5420
Example 1: An example of a clock controller node is listed below.
Example 1: An example of a clock controller node using the default input
clock names is listed below.
clock_audss: audss-clock-controller@3810000 {
compatible = "samsung,exynos5250-audss-clock";
@ -43,7 +62,19 @@ clock_audss: audss-clock-controller@3810000 {
#clock-cells = <1>;
};
Example 2: I2S controller node that consumes the clock generated by the clock
Example 2: An example of a clock controller node with the input clocks
specified.
clock_audss: audss-clock-controller@3810000 {
compatible = "samsung,exynos5250-audss-clock";
reg = <0x03810000 0x0C>;
#clock-cells = <1>;
clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>,
<&ext_i2s_clk>;
clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk";
};
Example 3: I2S controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.

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

@ -5,7 +5,7 @@ Sources of clock signal can be represented by any node in the device
tree. Those nodes are designated as clock providers. Clock consumer
nodes use a phandle and clock specifier pair to connect clock provider
outputs to clock inputs. Similar to the gpio specifiers, a clock
specifier is an array of one more more cells identifying the clock
specifier is an array of zero, one or more cells identifying the clock
output on a device. The length of a clock specifier is defined by the
value of a #clock-cells property in the clock provider node.

134
Documentation/devicetree/bindings/clock/corenet-clock.txt 100644
View File

@ -0,0 +1,134 @@
* Clock Block on Freescale CoreNet Platforms
Freescale CoreNet chips take primary clocking input from the external
SYSCLK signal. The SYSCLK input (frequency) is multiplied using
multiple phase locked loops (PLL) to create a variety of frequencies
which can then be passed to a variety of internal logic, including
cores and peripheral IP blocks.
Please refer to the Reference Manual for details.
1. Clock Block Binding
Required properties:
- compatible: Should contain a specific clock block compatible string
and a single chassis clock compatible string.
Clock block strings include, but not limited to, one of the:
* "fsl,p2041-clockgen"
* "fsl,p3041-clockgen"
* "fsl,p4080-clockgen"
* "fsl,p5020-clockgen"
* "fsl,p5040-clockgen"
* "fsl,t4240-clockgen"
* "fsl,b4420-clockgen"
* "fsl,b4860-clockgen"
Chassis clock strings include:
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
- reg: Describes the address of the device's resources within the
address space defined by its parent bus, and resource zero
represents the clock register set
- clock-frequency: Input system clock frequency
Recommended properties:
- ranges: Allows valid translation between child's address space and
parent's. Must be present if the device has sub-nodes.
- #address-cells: Specifies the number of cells used to represent
physical base addresses. Must be present if the device has
sub-nodes and set to 1 if present
- #size-cells: Specifies the number of cells used to represent
the size of an address. Must be present if the device has
sub-nodes and set to 1 if present
2. Clock Provider/Consumer Binding
Most of the bindings are from the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : Should include one of the following:
* "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
* "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
* "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
* "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
* "fsl,qoriq-sysclk-1.0": for input system clock (v1.0).
It takes parent's clock-frequency as its clock.
* "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
It takes parent's clock-frequency as its clock.
- #clock-cells: From common clock binding. The number of cells in a
clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
For "fsl,qoriq-core-pll-[1,2].0" clocks, the single
clock-specifier cell may take the following values:
* 0 - equal to the PLL frequency
* 1 - equal to the PLL frequency divided by 2
* 2 - equal to the PLL frequency divided by 4
Recommended properties:
- clocks: Should be the phandle of input parent clock
- clock-names: From common clock binding, indicates the clock name
- clock-output-names: From common clock binding, indicates the names of
output clocks
- reg: Should be the offset and length of clock block base address.
The length should be 4.
Example for clock block and clock provider:
/ {
clockgen: global-utilities@e1000 {
compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
ranges = <0x0 0xe1000 0x1000>;
clock-frequency = <133333333>;
reg = <0xe1000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
sysclk: sysclk {
#clock-cells = <0>;
compatible = "fsl,qoriq-sysclk-1.0";
clock-output-names = "sysclk";
}
pll0: pll0@800 {
#clock-cells = <1>;
reg = <0x800 0x4>;
compatible = "fsl,qoriq-core-pll-1.0";
clocks = <&sysclk>;
clock-output-names = "pll0", "pll0-div2";
};
pll1: pll1@820 {
#clock-cells = <1>;
reg = <0x820 0x4>;
compatible = "fsl,qoriq-core-pll-1.0";
clocks = <&sysclk>;
clock-output-names = "pll1", "pll1-div2";
};
mux0: mux0@0 {
#clock-cells = <0>;
reg = <0x0 0x4>;
compatible = "fsl,qoriq-core-mux-1.0";
clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
clock-output-names = "cmux0";
};
mux1: mux1@20 {
#clock-cells = <0>;
reg = <0x20 0x4>;
compatible = "fsl,qoriq-core-mux-1.0";
clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
clock-output-names = "cmux1";
};
};
}
Example for clock consumer:
/ {
cpu0: PowerPC,e5500@0 {
...
clocks = <&mux0>;
...
};
}

98
Documentation/devicetree/bindings/clock/emev2-clock.txt 100644
View File

@ -0,0 +1,98 @@
Device tree Clock bindings for Renesas EMMA Mobile EV2
This binding uses the common clock binding.
* SMU
System Management Unit described in user's manual R19UH0037EJ1000_SMU.
This is not a clock provider, but clocks under SMU depend on it.
Required properties:
- compatible: Should be "renesas,emev2-smu"
- reg: Address and Size of SMU registers
* SMU_CLKDIV
Function block with an input mux and a divider, which corresponds to
"Serial clock generator" in fig."Clock System Overview" of the manual,
and "xxx frequency division setting register" (XXXCLKDIV) registers.
This makes internal (neither input nor output) clock that is provided
to input of xxxGCLK block.
Required properties:
- compatible: Should be "renesas,emev2-smu-clkdiv"
- reg: Byte offset from SMU base and Bit position in the register
- clocks: Parent clocks. Input clocks as described in clock-bindings.txt
- #clock-cells: Should be <0>
* SMU_GCLK
Clock gating node shown as "Clock stop processing block" in the
fig."Clock System Overview" of the manual.
Registers are "xxx clock gate control register" (XXXGCLKCTRL).
Required properties:
- compatible: Should be "renesas,emev2-smu-gclk"
- reg: Byte offset from SMU base and Bit position in the register
- clocks: Input clock as described in clock-bindings.txt
- #clock-cells: Should be <0>
Example of provider:
usia_u0_sclkdiv: usia_u0_sclkdiv {
compatible = "renesas,emev2-smu-clkdiv";
reg = <0x610 0>;
clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>;
#clock-cells = <0>;
};
usia_u0_sclk: usia_u0_sclk {
compatible = "renesas,emev2-smu-gclk";
reg = <0x4a0 1>;
clocks = <&usia_u0_sclkdiv>;
#clock-cells = <0>;
};
Example of consumer:
uart@e1020000 {
compatible = "renesas,em-uart";
reg = <0xe1020000 0x38>;
interrupts = <0 8 0>;
clocks = <&usia_u0_sclk>;
clock-names = "sclk";
};
Example of clock-tree description:
This describes a clock path in the clock tree
c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
smu@e0110000 {
compatible = "renesas,emev2-smu";
reg = <0xe0110000 0x10000>;
#address-cells = <2>;
#size-cells = <0>;
c32ki: c32ki {
compatible = "fixed-clock";
clock-frequency = <32768>;
#clock-cells = <0>;
};
pll3_fo: pll3_fo {
compatible = "fixed-factor-clock";
clocks = <&c32ki>;
clock-div = <1>;
clock-mult = <7000>;
#clock-cells = <0>;
};
usia_u0_sclkdiv: usia_u0_sclkdiv {
compatible = "renesas,emev2-smu-clkdiv";
reg = <0x610 0>;
clocks = <&pll3_fo>;
#clock-cells = <0>;
};
usia_u0_sclk: usia_u0_sclk {
compatible = "renesas,emev2-smu-gclk";
reg = <0x4a0 1>;
clocks = <&usia_u0_sclkdiv>;
#clock-cells = <0>;
};
};

3
Documentation/devicetree/bindings/clock/exynos5250-clock.txt
View File

@ -62,6 +62,7 @@ clock which they consume.
div_i2s1 157
div_i2s2 158
sclk_hdmiphy 159
div_pcm0 160
[Peripheral Clock Gates]
@ -159,6 +160,8 @@ clock which they consume.
mixer 343
hdmi 344
g2d 345
mdma0 346
smmu_mdma0 347
[Clock Muxes]

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