Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Linux 3.9-rc2

Browse source 
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iQEcBAABAgAGBQJRPR09AAoJEHm+PkMAQRiGQLoIAJpgaFDY2bRKuApUOu61sU2b
 Cwiza9m0TZrGMUguXE7suudfC4i8PRkaOZOJWk6TUg/nTT1cl4kNscasgFamKGt4
 zcpiooVnox1e7gpWS1P9NWpuVY7pFC87FrN4dbXgFs45slYNy+sGlTp9/LMviZ13
 mR3aTG2R7o4GBapD+gpqX8hroV53o8X12kjln6aLghoNLfEdtlAawoiWO5PTHHl8
 4Pu4DANoyA7Z9pIMT3++uTWl/BR4bbpBVFIqkUomUFRYFjtwhHBXr+ak11pK7jTt
 EJ5HYYIiOcm0v2nVvIovNwUKnWTNopK4P+bx/vgFjANpwV132v5nPuf/Ucoj0U0=
 =eQ4p
 -----END PGP SIGNATURE-----

Merge tag 'v3.9-rc2' into next

Sync with Linus.

Linux 3.9-rc2
This commit is contained in:
James Morris 2013-03-11 12:54:48 +11:00
commit 2c4cdf5950
11745 changed files with 563132 additions and 290808 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
CREDITS
View file

@ -953,11 +953,11 @@ S: Blacksburg, Virginia 24061
S: USA
N: Randy Dunlap
E: rdunlap@xenotime.net
W: http://www.xenotime.net/linux/linux.html
W: http://www.linux-usb.org
E: rdunlap@infradead.org
W: http://www.infradead.org/~rdunlap/
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
D: x86 SMP, ACPI, bootflag hacking
D: documentation, builds
S: (ask for current address)
S: USA
@ -1572,12 +1572,12 @@ S: Wantage, New Jersey 07461
S: USA
N: Harald Hoyer
E: harald.hoyer@parzelle.de
W: http://parzelle.de/
E: harald@redhat.com
W: http://www.harald-hoyer.de
D: ip_masq_quake
D: md boot support
S: Hohe Strasse 30
S: D-70176 Stuttgart
S: Am Strand 5
S: D-19063 Schwerin
S: Germany
N: Jan Hubicka

151
Documentation/00-INDEX
View file

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

10
Documentation/ABI/testing/pstore
View file

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10
Documentation/CodingStyle
View file

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

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

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

4
Documentation/DocBook/80211.tmpl
View file

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

78
Documentation/DocBook/drm.tmpl
View file

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

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

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

6
Documentation/DocBook/kgdb.tmpl
View file

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

2
Documentation/DocBook/media/dvb/dvbapi.xml
View file

@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
<title>LINUX DVB API</title>
<subtitle>Version 5.8</subtitle>
<subtitle>Version 5.10</subtitle>
<!-- ADD THE CHAPTERS HERE -->
<chapter id="dvb_introdution">
&sub-intro;

180
Documentation/DocBook/media/dvb/dvbproperty.xml
View file

@ -7,14 +7,41 @@ the capability ioctls weren't implemented yet via the new way.</para>
<para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant>
API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
<section id="dtv-stats">
<title>DTV stats type</title>
<programlisting>
struct dtv_stats {
__u8 scale; /* enum fecap_scale_params type */
union {
__u64 uvalue; /* for counters and relative scales */
__s64 svalue; /* for 1/1000 dB measures */
};
} __packed;
</programlisting>
</section>
<section id="dtv-fe-stats">
<title>DTV stats type</title>
<programlisting>
#define MAX_DTV_STATS 4
struct dtv_fe_stats {
__u8 len;
struct dtv_stats stat[MAX_DTV_STATS];
} __packed;
</programlisting>
</section>
<section id="dtv-property">
<title>DTV property type</title>
<programlisting>
/* Reserved fields should be set to 0 */
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct dtv_fe_stats st;
struct {
__u8 data[32];
__u32 len;
@ -440,7 +467,7 @@ typedef enum fe_delivery_system {
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
ISDB-T hierarchical layers can be decoded simultaneously. For that
reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para>
<para>ISDB-T has 3 hierarchical layers which each can use a part of the
available segments. The total number of segments over all layers has
to 13 in ISDB-T.</para>
@ -850,6 +877,147 @@ enum fe_interleaving {
<para>use the special macro LNA_AUTO to set LNA auto</para>
</section>
</section>
<section id="frontend-stat-properties">
<title>Frontend statistics indicators</title>
<para>The values are returned via <constant>dtv_property.stat</constant>.
If the property is supported, <constant>dtv_property.stat.len</constant> is bigger than zero.</para>
<para>For most delivery systems, <constant>dtv_property.stat.len</constant>
will be 1 if the stats is supported, and the properties will
return a single value for each parameter.</para>
<para>It should be noticed, however, that new OFDM delivery systems
like ISDB can use different modulation types for each group of
carriers. On such standards, up to 3 groups of statistics can be
provided, and <constant>dtv_property.stat.len</constant> is updated
to reflect the "global" metrics, plus one metric per each carrier
group (called "layer" on ISDB).</para>
<para>So, in order to be consistent with other delivery systems, the first
value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link>
array refers to the global metric. The other elements of the array
represent each layer, starting from layer A(index 1),
layer B (index 2) and so on.</para>
<para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para>
<para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para>
<itemizedlist mark='opencircle'>
<listitem><para><constant>svalue</constant> or <constant>uvalue</constant>, where
<constant>svalue</constant> is for signed values of the measure (dB measures)
and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
<listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
<section id = "fecap-scale-params">
<itemizedlist mark='bullet'>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
<listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
<listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
</itemizedlist>
</section>
</listitem>
</itemizedlist>
<section id="DTV-STAT-SIGNAL-STRENGTH">
<title><constant>DTV_STAT_SIGNAL_STRENGTH</constant></title>
<para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem>
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-CNR">
<title><constant>DTV_STAT_CNR</constant></title>
<para>Indicates the Signal to Noise ratio for the main carrier.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem>
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
<title><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></title>
<para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
<para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
<link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
<title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
<para>Measures the amount of bits received before the inner code block, during the same period as
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-POST-ERROR-BIT-COUNT">
<title><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></title>
<para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
<para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
<link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
<title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
<para>Measures the amount of bits received after the inner coding, during the same period as
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-ERROR-BLOCK-COUNT">
<title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
<para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-TOTAL-BLOCK-COUNT">
<title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
<para>Measures the total number of blocks received during the same period as
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
<para>It can be used to calculate the PER indicator, by dividing
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
</section>
<section id="frontend-property-terrestrial-systems">
<title>Properties used on terrestrial delivery systems</title>
<section id="dvbt-params">
@ -871,6 +1039,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dvbt2-params">
<title>DVB-T2 delivery system</title>
@ -895,6 +1064,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="isdbt">
<title>ISDB-T delivery system</title>
@ -948,6 +1118,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="atsc-params">
<title>ATSC delivery system</title>
@ -961,6 +1132,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="atscmh-params">
<title>ATSC-MH delivery system</title>
@ -988,6 +1160,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dtmb-params">
<title>DTMB delivery system</title>
@ -1007,6 +1180,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
</section>
<section id="frontend-property-cable-systems">
@ -1028,6 +1202,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dvbc-annex-b-params">
<title>DVB-C Annex B delivery system</title>
@ -1043,6 +1218,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
</section>
<section id="frontend-property-satellital-systems">
@ -1062,6 +1238,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
<para>Future implementations might add those two missing parameters:</para>
<itemizedlist mark='opencircle'>
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
@ -1077,6 +1254,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="turbo-params">
<title>Turbo code delivery system</title>

2
Documentation/DocBook/media/dvb/frontend.xml
View file

@ -230,7 +230,7 @@ typedef enum fe_status {
<entry align="char">The frontend has found a DVB signal</entry>
</row><row>
<entry align="char">FE_HAS_VITERBI</entry>
<entry align="char">The frontend FEC code is stable</entry>
<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
</row><row>
<entry align="char">FE_HAS_SYNC</entry>
<entry align="char">Syncronization bytes was found</entry>

2
Documentation/DocBook/media/v4l/common.xml
View file

@ -609,7 +609,7 @@ to zero and the <constant>VIDIOC_G_STD</constant>,
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
are available for the device.</para>
&ENOTTY;.
<para>See <xref linkend="buffer" /> for a rationale. Probably
even USB cameras follow some well known video standard. It might have
been better to explicitly indicate elsewhere if a device cannot live

16
Documentation/DocBook/media/v4l/compat.xml
View file

@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.9</title>
<orderedlist>
<listitem>
<para>Added timestamp types to
<structfield>flags</structfield> field in
<structname>v4l2_buffer</structname>. See <xref
linkend="buffer-flags" />.</para>
</listitem>
<listitem>
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
changes flag. See <xref linkend="changes-flags"/>.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>

23
Documentation/DocBook/media/v4l/controls.xml
View file

@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry>
<entry>boolean</entry>
<entry>Mirror the picture vertically.</entry>
</row>
<row>
<entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry>
<entry>integer</entry>
<entry>Horizontal image centering. This control is
deprecated. New drivers and applications should use the <link
linkend="camera-controls">Camera class controls</link>
<constant>V4L2_CID_PAN_ABSOLUTE</constant>,
<constant>V4L2_CID_PAN_RELATIVE</constant> and
<constant>V4L2_CID_PAN_RESET</constant> instead.</entry>
</row>
<row>
<entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant>
(formerly <constant>V4L2_CID_VCENTER</constant>)</entry>
<entry>integer</entry>
<entry>Vertical image centering. Centering is intended to
<emphasis>physically</emphasis> adjust cameras. For image cropping see
<xref linkend="crop" />, for clipping <xref linkend="overlay" />. This
control is deprecated. New drivers and applications should use the
<link linkend="camera-controls">Camera class controls</link>
<constant>V4L2_CID_TILT_ABSOLUTE</constant>,
<constant>V4L2_CID_TILT_RELATIVE</constant> and
<constant>V4L2_CID_TILT_RESET</constant> instead.</entry>
</row>
<row id="v4l2-power-line-frequency">
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
<entry>enum</entry>

6
Documentation/DocBook/media/v4l/driver.xml
View file

@ -116,7 +116,7 @@ my_suspend (struct pci_dev * pci_dev,
return 0; /* a negative value on error, 0 on success. */
}
static void __devexit
static void
my_remove (struct pci_dev * pci_dev)
{
my_device *my = pci_get_drvdata (pci_dev);
@ -124,7 +124,7 @@ my_remove (struct pci_dev * pci_dev)
/* Describe me. */
}
static int __devinit
static int
my_probe (struct pci_dev * pci_dev,
const struct pci_device_id * pci_id)
{
@ -157,7 +157,7 @@ my_pci_driver = {
.id_table = my_pci_device_ids,
.probe = my_probe,
.remove = __devexit_p (my_remove),
.remove = my_remove,
/* Power management functions. */
.suspend = my_suspend,

59
Documentation/DocBook/media/v4l/io.xml
View file

@ -477,7 +477,7 @@ rest should be evident.</para>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
@ -488,7 +488,7 @@ DMA buffer from userspace using a file descriptor previously exported for a
different or the same device (known as the importer role), or both. This
section describes the DMABUF importer role API in V4L2.</para>
<para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for
<para>Refer to <link linkend="vidioc-expbuf">DMABUF exporting</link> for
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
<para>Input and output devices support the streaming I/O method when the
@ -741,17 +741,19 @@ applications when an output stream.</entry>
<entry>struct timeval</entry>
<entry><structfield>timestamp</structfield></entry>
<entry></entry>
<entry><para>For input streams this is the
system time (as returned by the <function>gettimeofday()</function>
function) when the first data byte was captured. For output streams
the data will not be displayed before this time, secondary to the
nominal frame rate determined by the current video standard in
enqueued order. Applications can for example zero this field to
display frames as soon as possible. The driver stores the time at
which the first data byte was actually sent out in the
<structfield>timestamp</structfield> field. This permits
applications to monitor the drift between the video and system
clock.</para></entry>
<entry><para>For input streams this is time when the first data
byte was captured, as returned by the
<function>clock_gettime()</function> function for the relevant
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
<xref linkend="buffer-flags" />. For output streams the data
will not be displayed before this time, secondary to the nominal
frame rate determined by the current video standard in enqueued
order. Applications can for example zero this field to display
frames as soon as possible. The driver stores the time at which
the first data byte was actually sent out in the
<structfield>timestamp</structfield> field. This permits
applications to monitor the drift between the video and system
clock.</para></entry>
</row>
<row>
<entry>&v4l2-timecode;</entry>
@ -903,7 +905,7 @@ should set this to 0.</entry>
</row>
<row>
<entry></entry>
<entry>__unsigned long</entry>
<entry>unsigned long</entry>
<entry><structfield>userptr</structfield></entry>
<entry>When the memory type in the containing &v4l2-buffer; is
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
@ -1114,6 +1116,35 @@ Typically applications shall use this flag for output buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
<entry>0xe000</entry>
<entry>Mask for timestamp types below. To test the
timestamp type, mask out bits not belonging to timestamp
type by performing a logical and operation with buffer
flags and timestamp mask.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
<entry>0x0000</entry>
<entry>Unknown timestamp type. This type is used by
drivers before Linux 3.9 and may be either monotonic (see
below) or realtime (wall clock). Monotonic clock has been
favoured in embedded systems whereas most of the drivers
use the realtime clock. Either kinds of timestamps are
available in user space via
<function>clock_gettime(2)</function> using clock IDs
<constant>CLOCK_MONOTONIC</constant> and
<constant>CLOCK_REALTIME</constant>, respectively.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
<entry>0x2000</entry>
<entry>The buffer timestamp has been taken from the
<constant>CLOCK_MONOTONIC</constant> clock. To access the
same clock outside V4L2, use
<function>clock_gettime(2)</function> .</entry>
</row>
</tbody>
</tgroup>
</table>

2
Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
View file

@ -6,7 +6,7 @@
<refnamediv>
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
<refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
<refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
<refname id="V4L2-PIX-FMT-NV12MT-16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
non contiguous in memory. </refpurpose>
</refnamediv>

34
Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml Normal file
View file

@ -0,0 +1,34 @@
<refentry>
<refmeta>
<refentrytitle>
V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-SBGGR10ALAW8">
<constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SGBRG10ALAW8">
<constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SGRBG10ALAW8">
<constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SRGGB10ALAW8">
<constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant>
</refname>
<refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer
formats with 10 bits per color compressed to 8 bits each,
using the A-LAW algorithm. Each color component consumes 8
bits of memory. In other respects this format is similar to
<xref linkend="V4L2-PIX-FMT-SRGGB8"></xref>.</para>
</refsect1>
</refentry>

62
Documentation/DocBook/media/v4l/pixfmt-uv8.xml Normal file
View file

@ -0,0 +1,62 @@
<refentry id="V4L2-PIX-FMT-UV8">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_UV8</constant></refname>
<refpurpose>UV plane interleaved</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>In this format there is no Y plane, Only CbCr plane. ie
(UV interleaved)</para>
<example>
<title>
<constant>V4L2_PIX_FMT_UV8</constant>
pixel image
</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;12:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

2
Documentation/DocBook/media/v4l/pixfmt.xml
View file

@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
&sub-srggb8;
&sub-sbggr16;
&sub-srggb10;
&sub-srggb10alaw8;
&sub-srggb10dpcm8;
&sub-srggb12;
</section>
@ -701,6 +702,7 @@ information.</para>
&sub-y12;
&sub-y10b;
&sub-y16;
&sub-uv8;
&sub-yuyv;
&sub-uyvy;
&sub-yvyu;

938
Documentation/DocBook/media/v4l/subdev-formats.xml
View file

File diff suppressed because it is too large Load diff

12
Documentation/DocBook/media/v4l/v4l2.xml
View file

@ -139,6 +139,16 @@ 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.9</revnumber>
<date>2012-12-03</date>
<authorinitials>sa, sn</authorinitials>
<revremark>Added timestamp types to v4l2_buffer.
Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control
event changes flag, see <xref linkend="changes-flags"/>.
</revremark>
</revision>
<revision>
<revnumber>3.6</revnumber>
<date>2012-07-02</date>
@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.6</subtitle>
<subtitle>Revision 3.9</subtitle>
<chapter id="common">
&sub-common;

6
Documentation/DocBook/media/v4l/vidioc-dqevent.xml
View file

@ -261,6 +261,12 @@
<entry>This control event was triggered because the control flags
changed.</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_CTRL_CH_RANGE</constant></entry>
<entry>0x0004</entry>
<entry>This control event was triggered because the minimum,
maximum, step or the default value of the control changed.</entry>
</row>
</tbody>
</tgroup>
</table>

30
Documentation/DocBook/media/v4l/vidioc-expbuf.xml
View file

@ -83,15 +83,14 @@ descriptor. The application may pass it to other DMABUF-aware devices. Refer to
<link linkend="dmabuf">DMABUF importing</link> for details about importing
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
is no longer used to allow the associated memory to be reclaimed. </para>
</refsect1>
<refsect1>
<section>
<title>Examples</title>
<example>
<title>Exporting a buffer.</title>
<programlisting>
<refsect1>
<title>Examples</title>
<example>
<title>Exporting a buffer.</title>
<programlisting>
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
{
&v4l2-exportbuffer; expbuf;
@ -108,12 +107,12 @@ int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
return 0;
}
</programlisting>
</example>
</programlisting>
</example>
<example>
<title>Exporting a buffer using the multi-planar API.</title>
<programlisting>
<example>
<title>Exporting a buffer using the multi-planar API.</title>
<programlisting>
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
int dmafd[], int n_planes)
{
@ -137,12 +136,9 @@ int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
return 0;
}
</programlisting>
</example>
</section>
</refsect1>
</programlisting>
</example>
<refsect1>
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
<title>struct <structname>v4l2_exportbuffer</structname></title>
<tgroup cols="3">

8
Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
View file

@ -64,7 +64,9 @@ return an &EINVAL;. When the <structfield>value</structfield> is out
of bounds drivers can choose to take the closest valid value or return
an &ERANGE;, whatever seems more appropriate. However,
<constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not
return the actual new value.</para>
return the actual new value. If the <structfield>value</structfield>
is inappropriate for the control (e.g. if it refers to an unsupported
menu index of a menu control), then &EINVAL; is returned as well.</para>
<para>These ioctls work only with user controls. For other
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
@ -99,7 +101,9 @@ application.</entry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-control; <structfield>id</structfield> is
invalid.</para>
invalid or the <structfield>value</structfield> is inappropriate for
the given control (i.e. if a menu item is selected that is not supported
by the driver according to &VIDIOC-QUERYMENU;).</para>
</listitem>
</varlistentry>
<varlistentry>

57
Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
View file

@ -106,7 +106,9 @@ value or if an error is returned.</para>
&EINVAL;. When the value is out of bounds drivers can choose to take
the closest valid value or return an &ERANGE;, whatever seems more
appropriate. In the first case the new value is set in
&v4l2-ext-control;.</para>
&v4l2-ext-control;. If the new control value is inappropriate (e.g. the
given menu index is not supported by the menu control), then this will
also result in an &EINVAL; error.</para>
<para>The driver will only set/get these controls if all control
values are correct. This prevents the situation where only some of the
@ -199,13 +201,46 @@ also be zero.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>error_idx</structfield></entry>
<entry>Set by the driver in case of an error. If it is equal
to <structfield>count</structfield>, then no actual changes were made to
controls. In other words, the error was not associated with setting a particular
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
were modified and control <structfield>error_idx</structfield> is the one that
caused the error. The <structfield>error_idx</structfield> value is undefined
if the ioctl returned 0 (success).</entry>
<entry><para>Set by the driver in case of an error. If the error is
associated with a particular control, then <structfield>error_idx</structfield>
is set to the index of that control. If the error is not related to a specific
control, or the validation step failed (see below), then
<structfield>error_idx</structfield> is set to <structfield>count</structfield>.
The value is undefined if the ioctl returned 0 (success).</para>
<para>Before controls are read from/written to hardware a validation step
takes place: this checks if all controls in the list are valid controls,
if no attempt is made to write to a read-only control or read from a write-only
control, and any other up-front checks that can be done without accessing the
hardware. The exact validations done during this step are driver dependent
since some checks might require hardware access for some devices, thus making
it impossible to do those checks up-front. However, drivers should make a
best-effort to do as many up-front checks as possible.</para>
<para>This check is done to avoid leaving the hardware in an inconsistent state due
to easy-to-avoid problems. But it leads to another problem: the application needs to
know whether an error came from the validation step (meaning that the hardware
was not touched) or from an error during the actual reading from/writing to hardware.</para>
<para>The, in hindsight quite poor, solution for that is to set <structfield>error_idx</structfield>
to <structfield>count</structfield> if the validation failed. This has the
unfortunate side-effect that it is not possible to see which control failed the
validation. If the validation was successful and the error happened while
accessing the hardware, then <structfield>error_idx</structfield> is less than
<structfield>count</structfield> and only the controls up to
<structfield>error_idx-1</structfield> were read or written correctly, and the
state of the remaining controls is undefined.</para>
<para>Since <constant>VIDIOC_TRY_EXT_CTRLS</constant> does not access hardware
there is also no need to handle the validation step in this special way,
so <structfield>error_idx</structfield> will just be set to the control that
failed the validation step instead of to <structfield>count</structfield>.
This means that if <constant>VIDIOC_S_EXT_CTRLS</constant> fails with
<structfield>error_idx</structfield> set to <structfield>count</structfield>,
then you can call <constant>VIDIOC_TRY_EXT_CTRLS</constant> to try to discover
the actual control that failed the validation step. Unfortunately, there
is no <constant>TRY</constant> equivalent for <constant>VIDIOC_G_EXT_CTRLS</constant>.
</para></entry>
</row>
<row>
<entry>__u32</entry>
@ -298,8 +333,10 @@ These controls are described in <xref
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-ext-control; <structfield>id</structfield>
is invalid or the &v4l2-ext-controls;
<structfield>ctrl_class</structfield> is invalid. This error code is
is invalid, the &v4l2-ext-controls;
<structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control;
<structfield>value</structfield> was inappropriate (e.g. the given menu
index is not supported by the driver). This error code is
also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
control values are in conflict.</para>

2
Documentation/DocBook/media/v4l/vidioc-querycap.xml
View file

@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry>
<row>
<entry>__u8</entry>
<entry><structfield>card</structfield>[32]</entry>
<entry>Name of the device, a NUL-terminated ASCII string.
<entry>Name of the device, a NUL-terminated UTF-8 string.
For example: "Yoyodyne TV/FM". One driver may support different brands
or models of video hardware. This information is intended for users,
for example in a menu of available devices. Since multiple TV cards of

1
Documentation/DocBook/media_api.tmpl
View file

@ -22,6 +22,7 @@
<!-- LinuxTV v4l-dvb repository. -->
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
<!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
]>
<book id="media_api">

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

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

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

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

27
Documentation/EDID/HOWTO.txt
View file

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

18
Documentation/IPMI.txt
View file

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

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

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

6
Documentation/PCI/pci-iov-howto.txt
View file

@ -76,7 +76,7 @@ To notify SR-IOV core of Virtual Function Migration:
Following piece of code illustrates the usage of the SR-IOV API.
static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
pci_enable_sriov(dev, NR_VIRTFN);
@ -85,7 +85,7 @@ static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *
return 0;
}
static void __devexit dev_remove(struct pci_dev *dev)
static void dev_remove(struct pci_dev *dev)
{
pci_disable_sriov(dev);
@ -131,7 +131,7 @@ static struct pci_driver dev_driver = {
.name = "SR-IOV Physical Function driver",
.id_table = dev_id_table,
.probe = dev_probe,
.remove = __devexit_p(dev_remove),
.remove = dev_remove,
.suspend = dev_suspend,
.resume = dev_resume,
.shutdown = dev_shutdown,

20
Documentation/PCI/pci.txt
View file

@ -183,12 +183,6 @@ Please mark the initialization and cleanup functions where appropriate
initializes.
__exit Exit code. Ignored for non-modular drivers.
__devinit Device initialization code.
Identical to __init if the kernel is not compiled
with CONFIG_HOTPLUG, normal function otherwise.
__devexit The same for __exit.
Tips on when/where to use the above attributes:
o The module_init()/module_exit() functions (and all
initialization functions called _only_ from these)
@ -196,20 +190,6 @@ Tips on when/where to use the above attributes:
o Do not mark the struct pci_driver.
o The ID table array should be marked __devinitconst; this is done
automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE().
o The probe() and remove() functions should be marked __devinit
and __devexit respectively. All initialization functions
exclusively called by the probe() routine, can be marked __devinit.
Ditto for remove() and __devexit.
o If mydriver_remove() is marked with __devexit(), then all address
references to mydriver_remove must use __devexit_p(mydriver_remove)
(in the struct pci_driver declaration for example).
__devexit_p() will generate the function name _or_ NULL if the
function will be discarded. For an example, see drivers/net/tg3.c.
o Do NOT mark a function if you are not sure which mark to use.
Better to not mark the function than mark the function wrong.

3
Documentation/SubmittingPatches
View file

@ -60,8 +60,7 @@ own source tree. For example:
"dontdiff" is a list of files which are generated by the kernel during
the build process, and should be ignored in any diff(1)-generated
patch. The "dontdiff" file is included in the kernel tree in
2.6.12 and later. For earlier kernel versions, you can get it
from <http://www.xenotime.net/linux/doc/dontdiff>.
2.6.12 and later.
Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-

6
Documentation/acpi/enumeration.txt
View file

@ -63,8 +63,8 @@ from ACPI tables.
Currently the kernel is not able to automatically determine from which ACPI
device it should make the corresponding platform device so we need to add
the ACPI device explicitly to acpi_platform_device_ids list defined in
drivers/acpi/scan.c. This limitation is only for the platform devices, SPI
and I2C devices are created automatically as described below.
drivers/acpi/acpi_platform.c. This limitation is only for the platform
devices, SPI and I2C devices are created automatically as described below.
SPI serial bus support
~~~~~~~~~~~~~~~~~~~~~~
@ -185,7 +185,7 @@ input driver:
.acpi_match_table ACPI_PTR(mpu3050_acpi_match),
},
.probe = mpu3050_probe,
.remove = __devexit_p(mpu3050_remove),
.remove = mpu3050_remove,
.id_table = mpu3050_ids,
};

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

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

2
Documentation/arm64/memory.txt
View file

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

2
Documentation/atomic_ops.txt
View file

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

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

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

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

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

38
Documentation/blockdev/nbd.txt
View file

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

2
Documentation/cgroups/00-INDEX
View file

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

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

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

3
Documentation/cgroups/memcg_test.txt
View file

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

4
Documentation/coccinelle.txt
View file

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

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

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

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

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

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

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

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

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

45
Documentation/device-mapper/dm-raid.txt
View file

@ -30,6 +30,7 @@ The target is named "raid" and it accepts the following parameters:
raid10 Various RAID10 inspired algorithms chosen by additional params
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
- RAID1E: Integrated Adjacent Stripe Mirroring
- RAID1E: Integrated Offset Stripe Mirroring
- and other similar RAID10 variants
Reference: Chapter 4 of
@ -64,15 +65,15 @@ The target is named "raid" and it accepts the following parameters:
synchronisation state for each region.
[raid10_copies <# copies>]
[raid10_format near]
[raid10_format <near|far|offset>]
These two options are used to alter the default layout of
a RAID10 configuration. The number of copies is can be
specified, but the default is 2. There are other variations
to how the copies are laid down - the default and only current
option is "near". Near copies are what most people think of
with respect to mirroring. If these options are left
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
are given, then the layouts for 2, 3 and 4 devices are:
specified, but the default is 2. There are also three
variations to how the copies are laid down - the default
is "near". Near copies are what most people think of with
respect to mirroring. If these options are left unspecified,
or 'raid10_copies 2' and/or 'raid10_format near' are given,
then the layouts for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- ---------- --------------
A1 A1 A1 A1 A2 A1 A1 A2 A2
@ -85,6 +86,33 @@ The target is named "raid" and it accepts the following parameters:
3-device layout is what might be called a 'RAID1E - Integrated
Adjacent Stripe Mirroring'.
If 'raid10_copies 2' and 'raid10_format far', then the layouts
for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- -------------- --------------------
A1 A2 A1 A2 A3 A1 A2 A3 A4
A3 A4 A4 A5 A6 A5 A6 A7 A8
A5 A6 A7 A8 A9 A9 A10 A11 A12
.. .. .. .. .. .. .. .. ..
A2 A1 A3 A1 A2 A2 A1 A4 A3
A4 A3 A6 A4 A5 A6 A5 A8 A7
A6 A5 A9 A7 A8 A10 A9 A12 A11
.. .. .. .. .. .. .. .. ..
If 'raid10_copies 2' and 'raid10_format offset', then the
layouts for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- ------------ -----------------
A1 A2 A1 A2 A3 A1 A2 A3 A4
A2 A1 A3 A1 A2 A2 A1 A4 A3
A3 A4 A4 A5 A6 A5 A6 A7 A8
A4 A3 A6 A4 A5 A6 A5 A8 A7
A5 A6 A7 A8 A9 A9 A10 A11 A12
A6 A5 A9 A7 A8 A10 A9 A12 A11
.. .. .. .. .. .. .. .. ..
Here we see layouts closely akin to 'RAID1E - Integrated
Offset Stripe Mirroring'.
<#raid_devs>: The number of devices composing the array.
Each device consists of two entries. The first is the device
containing the metadata (if any); the second is the one containing the
@ -141,3 +169,6 @@ Version History
1.2.0 Handle creation of arrays that contain failed devices.
1.3.0 Added support for RAID 10
1.3.1 Allow device replacement/rebuild for RAID 10
1.3.2 Fix/improve redundancy checking for RAID10
1.4.0 Non-functional change. Removes arg from mapping function.
1.4.1 Add RAID10 "far" and "offset" algorithm support.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5
Documentation/devicetree/bindings/clock/imx23-clock.txt
View file

@ -60,11 +60,6 @@ clks: clkctrl@80040000 {
compatible = "fsl,imx23-clkctrl";
reg = <0x80040000 0x2000>;
#clock-cells = <1>;
clock-output-names =
...
"uart", /* 32 */
...
"end_of_list";
};
auart0: serial@8006c000 {

4
Documentation/devicetree/bindings/clock/imx25-clock.txt
View file

@ -146,10 +146,6 @@ clks: ccm@53f80000 {
compatible = "fsl,imx25-ccm";
reg = <0x53f80000 0x4000>;
interrupts = <31>;
clock-output-names = ...
"uart_ipg",
"uart_serial",
...;
};
uart1: serial@43f90000 {

5
Documentation/devicetree/bindings/clock/imx28-clock.txt
View file

@ -83,11 +83,6 @@ clks: clkctrl@80040000 {
compatible = "fsl,imx28-clkctrl";
reg = <0x80040000 0x2000>;
#clock-cells = <1>;
clock-output-names =
...
"uart", /* 45 */
...
"end_of_list";
};
auart0: serial@8006a000 {

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

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

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

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

6
Documentation/devicetree/bindings/clock/imx6q-clock.txt
View file

@ -203,6 +203,8 @@ clocks and IDs.
pcie_ref 188
pcie_ref_125m 189
enet_ref 190
usbphy1_gate 191
usbphy2_gate 192
Examples:
@ -211,10 +213,6 @@ clks: ccm@020c4000 {
reg = <0x020c4000 0x4000>;
interrupts = <0 87 0x04 0 88 0x04>;
#clock-cells = <1>;
clock-output-names = ...
"uart_ipg",
"uart_serial",
...;
};
uart1: serial@02020000 {

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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