Merge tag 'v3.9-rc3' into drm-intel-next-queued
Backmerge so that I can merge Imre Deak's coalesced sg entries fixes,
which depend upon the new for_each_sg_page introduce in
commit a321e91b6d
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Feb 27 17:02:56 2013 -0800
lib/scatterlist: add simple page iterator
The merge itself is just two trivial conflicts:
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is contained in:
14
CREDITS
14
CREDITS
@@ -953,11 +953,11 @@ S: Blacksburg, Virginia 24061
|
|||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
N: Randy Dunlap
|
N: Randy Dunlap
|
||||||
E: rdunlap@xenotime.net
|
E: rdunlap@infradead.org
|
||||||
W: http://www.xenotime.net/linux/linux.html
|
W: http://www.infradead.org/~rdunlap/
|
||||||
W: http://www.linux-usb.org
|
|
||||||
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
|
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
|
||||||
D: x86 SMP, ACPI, bootflag hacking
|
D: x86 SMP, ACPI, bootflag hacking
|
||||||
|
D: documentation, builds
|
||||||
S: (ask for current address)
|
S: (ask for current address)
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
@@ -1572,12 +1572,12 @@ S: Wantage, New Jersey 07461
|
|||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
N: Harald Hoyer
|
N: Harald Hoyer
|
||||||
E: harald.hoyer@parzelle.de
|
E: harald@redhat.com
|
||||||
W: http://parzelle.de/
|
W: http://www.harald-hoyer.de
|
||||||
D: ip_masq_quake
|
D: ip_masq_quake
|
||||||
D: md boot support
|
D: md boot support
|
||||||
S: Hohe Strasse 30
|
S: Am Strand 5
|
||||||
S: D-70176 Stuttgart
|
S: D-19063 Schwerin
|
||||||
S: Germany
|
S: Germany
|
||||||
|
|
||||||
N: Jan Hubicka
|
N: Jan Hubicka
|
||||||
|
@@ -2,7 +2,7 @@
|
|||||||
This is a brief list of all the files in ./linux/Documentation and what
|
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
|
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.
|
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.
|
Thanks -- Paul G.
|
||||||
|
|
||||||
Following translations are available on the WWW:
|
Following translations are available on the WWW:
|
||||||
@@ -20,24 +20,33 @@ BUG-HUNTING
|
|||||||
Changes
|
Changes
|
||||||
- list of changes that break older software packages.
|
- list of changes that break older software packages.
|
||||||
CodingStyle
|
CodingStyle
|
||||||
- how the boss likes the C code in the kernel to look.
|
- how the maintainers expect the C code in the kernel to look.
|
||||||
development-process/
|
|
||||||
- An extended tutorial on how to work with the kernel development
|
|
||||||
process.
|
|
||||||
DMA-API.txt
|
DMA-API.txt
|
||||||
- DMA API, pci_ API & extensions for non-consistent memory machines.
|
- DMA API, pci_ API & extensions for non-consistent memory machines.
|
||||||
|
DMA-API-HOWTO.txt
|
||||||
|
- Dynamic DMA mapping Guide
|
||||||
DMA-ISA-LPC.txt
|
DMA-ISA-LPC.txt
|
||||||
- How to do DMA with ISA (and LPC) devices.
|
- How to do DMA with ISA (and LPC) devices.
|
||||||
|
DMA-attributes.txt
|
||||||
|
- listing of the various possible attributes a DMA region can have
|
||||||
DocBook/
|
DocBook/
|
||||||
- directory with DocBook templates etc. for kernel documentation.
|
- directory with DocBook templates etc. for kernel documentation.
|
||||||
|
EDID/
|
||||||
|
- directory with info on customizing EDID for broken gfx/displays.
|
||||||
HOWTO
|
HOWTO
|
||||||
- the process and procedures of how to do Linux kernel development.
|
- the process and procedures of how to do Linux kernel development.
|
||||||
IPMI.txt
|
IPMI.txt
|
||||||
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
|
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
|
||||||
IRQ-affinity.txt
|
IRQ-affinity.txt
|
||||||
- how to select which CPU(s) handle which interrupt events on SMP.
|
- 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
|
IRQ.txt
|
||||||
- description of what an IRQ is.
|
- 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
|
ManagementStyle
|
||||||
- how to (attempt to) manage kernel hackers.
|
- how to (attempt to) manage kernel hackers.
|
||||||
RCU/
|
RCU/
|
||||||
@@ -66,10 +75,16 @@ applying-patches.txt
|
|||||||
- description of various trees and how to apply their patches.
|
- description of various trees and how to apply their patches.
|
||||||
arm/
|
arm/
|
||||||
- directory with info about Linux on the ARM architecture.
|
- directory with info about Linux on the ARM architecture.
|
||||||
|
arm64/
|
||||||
|
- directory with info about Linux on the 64 bit ARM architecture.
|
||||||
atomic_ops.txt
|
atomic_ops.txt
|
||||||
- semantics and behavior of atomic and bitmask operations.
|
- semantics and behavior of atomic and bitmask operations.
|
||||||
auxdisplay/
|
auxdisplay/
|
||||||
- misc. LCD driver documentation (cfag12864b, ks0108).
|
- 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_profiling.txt
|
||||||
- basic instructions for those who wants to profile Linux kernel.
|
- basic instructions for those who wants to profile Linux kernel.
|
||||||
binfmt_misc.txt
|
binfmt_misc.txt
|
||||||
@@ -80,8 +95,14 @@ block/
|
|||||||
- info on the Block I/O (BIO) layer.
|
- info on the Block I/O (BIO) layer.
|
||||||
blockdev/
|
blockdev/
|
||||||
- info on block devices & drivers
|
- 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
|
btmrvl.txt
|
||||||
- info on Marvell Bluetooth driver usage.
|
- info on Marvell Bluetooth driver usage.
|
||||||
|
bus-devices/
|
||||||
|
- directory with info on TI GPMC (General Purpose Memory Controller)
|
||||||
bus-virt-phys-mapping.txt
|
bus-virt-phys-mapping.txt
|
||||||
- how to access I/O mapped memory from within device drivers.
|
- how to access I/O mapped memory from within device drivers.
|
||||||
cachetlb.txt
|
cachetlb.txt
|
||||||
@@ -90,6 +111,12 @@ cdrom/
|
|||||||
- directory with information on the CD-ROM drivers that Linux has.
|
- directory with information on the CD-ROM drivers that Linux has.
|
||||||
cgroups/
|
cgroups/
|
||||||
- cgroups features, including cpusets and memory controller.
|
- 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/
|
connector/
|
||||||
- docs on the netlink based userspace<->kernel space communication mod.
|
- docs on the netlink based userspace<->kernel space communication mod.
|
||||||
console/
|
console/
|
||||||
@@ -114,24 +141,42 @@ dcdbas.txt
|
|||||||
- information on the Dell Systems Management Base Driver.
|
- information on the Dell Systems Management Base Driver.
|
||||||
debugging-modules.txt
|
debugging-modules.txt
|
||||||
- some notes on debugging modules after Linux 2.6.3.
|
- 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
|
dell_rbu.txt
|
||||||
- document demonstrating the use of the Dell Remote BIOS Update driver.
|
- document demonstrating the use of the Dell Remote BIOS Update driver.
|
||||||
|
development-process/
|
||||||
|
- how to work with the mainline kernel development process.
|
||||||
device-mapper/
|
device-mapper/
|
||||||
- directory with info on Device Mapper.
|
- directory with info on Device Mapper.
|
||||||
devices.txt
|
devices.txt
|
||||||
- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
|
- 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
|
dontdiff
|
||||||
- file containing a list of files that should never be diff'ed.
|
- file containing a list of files that should never be diff'ed.
|
||||||
driver-model/
|
driver-model/
|
||||||
- directory with info about Linux driver model.
|
- directory with info about Linux driver model.
|
||||||
dvb/
|
dvb/
|
||||||
- info on Linux Digital Video Broadcast (DVB) subsystem.
|
- info on Linux Digital Video Broadcast (DVB) subsystem.
|
||||||
|
dynamic-debug-howto.txt
|
||||||
|
- how to use the dynamic debug (dyndbg) feature.
|
||||||
early-userspace/
|
early-userspace/
|
||||||
- info about initramfs, klibc, and userspace early during boot.
|
- info about initramfs, klibc, and userspace early during boot.
|
||||||
edac.txt
|
edac.txt
|
||||||
- information on EDAC - Error Detection And Correction
|
- information on EDAC - Error Detection And Correction
|
||||||
eisa.txt
|
eisa.txt
|
||||||
- info on EISA bus support.
|
- 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/
|
fault-injection/
|
||||||
- dir with docs about the fault injection capabilities infrastructure.
|
- dir with docs about the fault injection capabilities infrastructure.
|
||||||
fb/
|
fb/
|
||||||
@@ -140,12 +185,22 @@ filesystems/
|
|||||||
- info on the vfs and the various filesystems that Linux supports.
|
- info on the vfs and the various filesystems that Linux supports.
|
||||||
firmware_class/
|
firmware_class/
|
||||||
- request_firmware() hotplug interface info.
|
- request_firmware() hotplug interface info.
|
||||||
|
flexible-arrays.txt
|
||||||
|
- how to make use of flexible sized arrays in linux
|
||||||
frv/
|
frv/
|
||||||
- Fujitsu FR-V Linux documentation.
|
- 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
|
gpio.txt
|
||||||
- overview of GPIO (General Purpose Input/Output) access conventions.
|
- overview of GPIO (General Purpose Input/Output) access conventions.
|
||||||
|
hid/
|
||||||
|
- directory with information on human interface devices
|
||||||
highuid.txt
|
highuid.txt
|
||||||
- notes on the change from 16 bit to 32 bit user/group IDs.
|
- notes on the change from 16 bit to 32 bit user/group IDs.
|
||||||
|
hwspinlock.txt
|
||||||
|
- hardware spinlock provides hardware assistance for synchronization
|
||||||
timers/
|
timers/
|
||||||
- info on the timer related topics
|
- info on the timer related topics
|
||||||
hw_random.txt
|
hw_random.txt
|
||||||
@@ -162,10 +217,14 @@ ia64/
|
|||||||
- directory with info about Linux on Intel 64 bit architecture.
|
- directory with info about Linux on Intel 64 bit architecture.
|
||||||
infiniband/
|
infiniband/
|
||||||
- directory with documents concerning Linux InfiniBand support.
|
- 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
|
initrd.txt
|
||||||
- how to use the RAM disk as an initial/temporary root filesystem.
|
- how to use the RAM disk as an initial/temporary root filesystem.
|
||||||
input/
|
input/
|
||||||
- info on Linux input device support.
|
- info on Linux input device support.
|
||||||
|
intel_txt.txt
|
||||||
|
- info on intel Trusted Execution Technology (intel TXT).
|
||||||
io-mapping.txt
|
io-mapping.txt
|
||||||
- description of io_mapping functions in linux/io-mapping.h
|
- description of io_mapping functions in linux/io-mapping.h
|
||||||
io_ordering.txt
|
io_ordering.txt
|
||||||
@@ -182,6 +241,8 @@ isdn/
|
|||||||
- directory with info on the Linux ISDN support, and supported cards.
|
- directory with info on the Linux ISDN support, and supported cards.
|
||||||
java.txt
|
java.txt
|
||||||
- info on the in-kernel binary support for Java(tm).
|
- info on the in-kernel binary support for Java(tm).
|
||||||
|
ja_JP/
|
||||||
|
- directory with Japanese translations of various documents
|
||||||
kbuild/
|
kbuild/
|
||||||
- directory with info about the kernel build process.
|
- directory with info about the kernel build process.
|
||||||
kdump/
|
kdump/
|
||||||
@@ -192,6 +253,12 @@ kernel-docs.txt
|
|||||||
- listing of various WWW + books that document kernel internals.
|
- listing of various WWW + books that document kernel internals.
|
||||||
kernel-parameters.txt
|
kernel-parameters.txt
|
||||||
- summary listing of command line / boot prompt args for the kernel.
|
- 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
|
kobject.txt
|
||||||
- info of the kobject infrastructure of the Linux kernel.
|
- info of the kobject infrastructure of the Linux kernel.
|
||||||
kprobes.txt
|
kprobes.txt
|
||||||
@@ -208,6 +275,8 @@ local_ops.txt
|
|||||||
- semantics and behavior of local atomic operations.
|
- semantics and behavior of local atomic operations.
|
||||||
lockdep-design.txt
|
lockdep-design.txt
|
||||||
- documentation on the runtime locking correctness validator.
|
- documentation on the runtime locking correctness validator.
|
||||||
|
lockstat.txt
|
||||||
|
- info on collecting statistics on locks (and contention).
|
||||||
lockup-watchdogs.txt
|
lockup-watchdogs.txt
|
||||||
- info on soft and hard lockup detectors (aka nmi_watchdog).
|
- info on soft and hard lockup detectors (aka nmi_watchdog).
|
||||||
logo.gif
|
logo.gif
|
||||||
@@ -220,16 +289,28 @@ magic-number.txt
|
|||||||
- list of magic numbers used to mark/protect kernel data structures.
|
- list of magic numbers used to mark/protect kernel data structures.
|
||||||
md.txt
|
md.txt
|
||||||
- info on boot arguments for the multiple devices driver.
|
- 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
|
memory-barriers.txt
|
||||||
- info on Linux kernel memory barriers.
|
- info on Linux kernel memory barriers.
|
||||||
|
memory-devices/
|
||||||
|
- directory with info on parts like the Texas Instruments EMIF driver
|
||||||
memory-hotplug.txt
|
memory-hotplug.txt
|
||||||
- Hotpluggable memory support, how to use and current status.
|
- Hotpluggable memory support, how to use and current status.
|
||||||
memory.txt
|
memory.txt
|
||||||
- info on typical Linux memory problems.
|
- info on typical Linux memory problems.
|
||||||
|
metag/
|
||||||
|
- directory with info about Linux on Meta architecture.
|
||||||
mips/
|
mips/
|
||||||
- directory with info about Linux on MIPS architecture.
|
- directory with info about Linux on MIPS architecture.
|
||||||
|
misc-devices/
|
||||||
|
- directory with info about devices using the misc dev subsystem
|
||||||
mmc/
|
mmc/
|
||||||
- directory with info about the MMC subsystem
|
- 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
|
mono.txt
|
||||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||||
mutex-design.txt
|
mutex-design.txt
|
||||||
@@ -240,6 +321,8 @@ netlabel/
|
|||||||
- directory with information on the NetLabel subsystem.
|
- directory with information on the NetLabel subsystem.
|
||||||
networking/
|
networking/
|
||||||
- directory with info on various aspects of networking with Linux.
|
- directory with info on various aspects of networking with Linux.
|
||||||
|
nfc/
|
||||||
|
- directory relating info about Near Field Communications support.
|
||||||
nommu-mmap.txt
|
nommu-mmap.txt
|
||||||
- documentation about no-mmu memory mapping support.
|
- documentation about no-mmu memory mapping support.
|
||||||
numastat.txt
|
numastat.txt
|
||||||
@@ -256,26 +339,46 @@ parport-lowlevel.txt
|
|||||||
- description and usage of the low level parallel port functions.
|
- description and usage of the low level parallel port functions.
|
||||||
pcmcia/
|
pcmcia/
|
||||||
- info on the Linux PCMCIA driver.
|
- info on the Linux PCMCIA driver.
|
||||||
|
percpu-rw-semaphore.txt
|
||||||
|
- RCU based read-write semaphore optimized for locking for reading
|
||||||
pi-futex.txt
|
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
|
pnp.txt
|
||||||
- Linux Plug and Play documentation.
|
- Linux Plug and Play documentation.
|
||||||
power/
|
power/
|
||||||
- directory with info on Linux PCI power management.
|
- directory with info on Linux PCI power management.
|
||||||
powerpc/
|
powerpc/
|
||||||
- directory with info on using Linux with the PowerPC.
|
- directory with info on using Linux with the PowerPC.
|
||||||
|
prctl/
|
||||||
|
- directory with info on the priveledge control subsystem
|
||||||
preempt-locking.txt
|
preempt-locking.txt
|
||||||
- info on locking under a preemptive kernel.
|
- info on locking under a preemptive kernel.
|
||||||
printk-formats.txt
|
printk-formats.txt
|
||||||
- how to get printk format specifiers right
|
- 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
|
ramoops.txt
|
||||||
- documentation of the ramoops oops/panic logging module.
|
- documentation of the ramoops oops/panic logging module.
|
||||||
|
rapidio/
|
||||||
|
- directory with info on RapidIO packet-based fabric interconnect
|
||||||
rbtree.txt
|
rbtree.txt
|
||||||
- info on what red-black trees are and what they are for.
|
- 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
|
robust-futex-ABI.txt
|
||||||
- documentation of the robust futex ABI.
|
- documentation of the robust futex ABI.
|
||||||
robust-futexes.txt
|
robust-futexes.txt
|
||||||
- a description of what robust futexes are.
|
- a description of what robust futexes are.
|
||||||
|
rpmsg.txt
|
||||||
|
- info on the Remote Processor Messaging (rpmsg) Framework
|
||||||
rt-mutex-design.txt
|
rt-mutex-design.txt
|
||||||
- description of the RealTime mutex implementation design.
|
- description of the RealTime mutex implementation design.
|
||||||
rt-mutex.txt
|
rt-mutex.txt
|
||||||
@@ -300,10 +403,10 @@ sgi-visws.txt
|
|||||||
- short blurb on the SGI Visual Workstations.
|
- short blurb on the SGI Visual Workstations.
|
||||||
sh/
|
sh/
|
||||||
- directory with info on porting Linux to a new architecture.
|
- directory with info on porting Linux to a new architecture.
|
||||||
|
smsc_ece1099.txt
|
||||||
|
-info on the smsc Keyboard Scan Expansion/GPIO Expansion device.
|
||||||
sound/
|
sound/
|
||||||
- directory with info on sound card support.
|
- directory with info on sound card support.
|
||||||
sparc/
|
|
||||||
- directory with info on using Linux on Sparc architecture.
|
|
||||||
sparse.txt
|
sparse.txt
|
||||||
- info on how to obtain and use the sparse tool for typechecking.
|
- info on how to obtain and use the sparse tool for typechecking.
|
||||||
spi/
|
spi/
|
||||||
@@ -314,6 +417,8 @@ stable_api_nonsense.txt
|
|||||||
- info on why the kernel does not have a stable in-kernel api or abi.
|
- info on why the kernel does not have a stable in-kernel api or abi.
|
||||||
stable_kernel_rules.txt
|
stable_kernel_rules.txt
|
||||||
- rules and procedures for the -stable kernel releases.
|
- 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
|
svga.txt
|
||||||
- short guide on selecting video modes at boot via VGA BIOS.
|
- short guide on selecting video modes at boot via VGA BIOS.
|
||||||
sysfs-rules.txt
|
sysfs-rules.txt
|
||||||
@@ -322,27 +427,53 @@ sysctl/
|
|||||||
- directory with info on the /proc/sys/* files.
|
- directory with info on the /proc/sys/* files.
|
||||||
sysrq.txt
|
sysrq.txt
|
||||||
- info on the magic SysRq key.
|
- info on the magic SysRq key.
|
||||||
telephony/
|
target/
|
||||||
- directory with info on telephony (e.g. voice over IP) support.
|
- 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
|
unicode.txt
|
||||||
- info on the Unicode character/font mapping used in Linux.
|
- info on the Unicode character/font mapping used in Linux.
|
||||||
unshare.txt
|
unshare.txt
|
||||||
- description of the Linux unshare system call.
|
- description of the Linux unshare system call.
|
||||||
usb/
|
usb/
|
||||||
- directory with info regarding the Universal Serial Bus.
|
- 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
|
video-output.txt
|
||||||
- sysfs class driver interface to enable/disable a video output device.
|
- sysfs class driver interface to enable/disable a video output device.
|
||||||
video4linux/
|
video4linux/
|
||||||
- directory with info regarding video/TV/radio cards and linux.
|
- directory with info regarding video/TV/radio cards and linux.
|
||||||
|
virtual/
|
||||||
|
- directory with information on the various linux virtualizations.
|
||||||
vm/
|
vm/
|
||||||
- directory with info on the Linux vm code.
|
- 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
|
volatile-considered-harmful.txt
|
||||||
- Why the "volatile" type class should not be used
|
- Why the "volatile" type class should not be used
|
||||||
w1/
|
w1/
|
||||||
- directory with documents regarding the 1-wire (w1) subsystem.
|
- directory with documents regarding the 1-wire (w1) subsystem.
|
||||||
watchdog/
|
watchdog/
|
||||||
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
|
- 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/
|
x86/x86_64/
|
||||||
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
|
- 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
|
zorro.txt
|
||||||
- info on writing drivers for Zorro bus devices found on Amigas.
|
- info on writing drivers for Zorro bus devices found on Amigas.
|
||||||
|
185
Documentation/ABI/stable/sysfs-class-tpm
Normal file
185
Documentation/ABI/stable/sysfs-class-tpm
Normal file
@@ -0,0 +1,185 @@
|
|||||||
|
What: /sys/class/misc/tpmX/device/
|
||||||
|
Date: April 2005
|
||||||
|
KernelVersion: 2.6.12
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The device/ directory under a specific TPM instance exposes
|
||||||
|
the properties of that TPM chip
|
||||||
|
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/active
|
||||||
|
Date: April 2006
|
||||||
|
KernelVersion: 2.6.17
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "active" property prints a '1' if the TPM chip is accepting
|
||||||
|
commands. An inactive TPM chip still contains all the state of
|
||||||
|
an active chip (Storage Root Key, NVRAM, etc), and can be
|
||||||
|
visible to the OS, but will only accept a restricted set of
|
||||||
|
commands. See the TPM Main Specification part 2, Structures,
|
||||||
|
section 17 for more information on which commands are
|
||||||
|
available.
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/cancel
|
||||||
|
Date: June 2005
|
||||||
|
KernelVersion: 2.6.13
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "cancel" property allows you to cancel the currently
|
||||||
|
pending TPM command. Writing any value to cancel will call the
|
||||||
|
TPM vendor specific cancel operation.
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/caps
|
||||||
|
Date: April 2005
|
||||||
|
KernelVersion: 2.6.12
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "caps" property contains TPM manufacturer and version info.
|
||||||
|
|
||||||
|
Example output:
|
||||||
|
|
||||||
|
Manufacturer: 0x53544d20
|
||||||
|
TCG version: 1.2
|
||||||
|
Firmware version: 8.16
|
||||||
|
|
||||||
|
Manufacturer is a hex dump of the 4 byte manufacturer info
|
||||||
|
space in a TPM. TCG version shows the TCG TPM spec level that
|
||||||
|
the chip supports. Firmware version is that of the chip and
|
||||||
|
is manufacturer specific.
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/durations
|
||||||
|
Date: March 2011
|
||||||
|
KernelVersion: 3.1
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "durations" property shows the 3 vendor-specific values
|
||||||
|
used to wait for a short, medium and long TPM command. All
|
||||||
|
TPM commands are categorized as short, medium or long in
|
||||||
|
execution time, so that the driver doesn't have to wait
|
||||||
|
any longer than necessary before starting to poll for a
|
||||||
|
result.
|
||||||
|
|
||||||
|
Example output:
|
||||||
|
|
||||||
|
3015000 4508000 180995000 [original]
|
||||||
|
|
||||||
|
Here the short, medium and long durations are displayed in
|
||||||
|
usecs. "[original]" indicates that the values are displayed
|
||||||
|
unmodified from when they were queried from the chip.
|
||||||
|
Durations can be modified in the case where a buggy chip
|
||||||
|
reports them in msec instead of usec and they need to be
|
||||||
|
scaled to be displayed in usecs. In this case "[adjusted]"
|
||||||
|
will be displayed in place of "[original]".
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/enabled
|
||||||
|
Date: April 2006
|
||||||
|
KernelVersion: 2.6.17
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "enabled" property prints a '1' if the TPM chip is enabled,
|
||||||
|
meaning that it should be visible to the OS. This property
|
||||||
|
may be visible but produce a '0' after some operation that
|
||||||
|
disables the TPM.
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/owned
|
||||||
|
Date: April 2006
|
||||||
|
KernelVersion: 2.6.17
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "owned" property produces a '1' if the TPM_TakeOwnership
|
||||||
|
ordinal has been executed successfully in the chip. A '0'
|
||||||
|
indicates that ownership hasn't been taken.
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/pcrs
|
||||||
|
Date: April 2005
|
||||||
|
KernelVersion: 2.6.12
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "pcrs" property will dump the current value of all Platform
|
||||||
|
Configuration Registers in the TPM. Note that since these
|
||||||
|
values may be constantly changing, the output is only valid
|
||||||
|
for a snapshot in time.
|
||||||
|
|
||||||
|
Example output:
|
||||||
|
|
||||||
|
PCR-00: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||||
|
PCR-01: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||||
|
PCR-02: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||||
|
PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||||
|
PCR-04: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||||
|
...
|
||||||
|
|
||||||
|
The number of PCRs and hex bytes needed to represent a PCR
|
||||||
|
value will vary depending on TPM chip version. For TPM 1.1 and
|
||||||
|
1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
|
||||||
|
long. Use the "caps" property to determine TPM version.
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/pubek
|
||||||
|
Date: April 2005
|
||||||
|
KernelVersion: 2.6.12
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "pubek" property will return the TPM's public endorsement
|
||||||
|
key if possible. If the TPM has had ownership established and
|
||||||
|
is version 1.2, the pubek will not be available without the
|
||||||
|
owner's authorization. Since the TPM driver doesn't store any
|
||||||
|
secrets, it can't authorize its own request for the pubek,
|
||||||
|
making it unaccessible. The public endorsement key is gener-
|
||||||
|
ated at TPM menufacture time and exists for the life of the
|
||||||
|
chip.
|
||||||
|
|
||||||
|
Example output:
|
||||||
|
|
||||||
|
Algorithm: 00 00 00 01
|
||||||
|
Encscheme: 00 03
|
||||||
|
Sigscheme: 00 01
|
||||||
|
Parameters: 00 00 08 00 00 00 00 02 00 00 00 00
|
||||||
|
Modulus length: 256
|
||||||
|
Modulus:
|
||||||
|
B4 76 41 82 C9 20 2C 10 18 40 BC 8B E5 44 4C 6C
|
||||||
|
3A B2 92 0C A4 9B 2A 83 EB 5C 12 85 04 48 A0 B6
|
||||||
|
1E E4 81 84 CE B2 F2 45 1C F0 85 99 61 02 4D EB
|
||||||
|
86 C4 F7 F3 29 60 52 93 6B B2 E5 AB 8B A9 09 E3
|
||||||
|
D7 0E 7D CA 41 BF 43 07 65 86 3C 8C 13 7A D0 8B
|
||||||
|
82 5E 96 0B F8 1F 5F 34 06 DA A2 52 C1 A9 D5 26
|
||||||
|
0F F4 04 4B D9 3F 2D F2 AC 2F 74 64 1F 8B CD 3E
|
||||||
|
1E 30 38 6C 70 63 69 AB E2 50 DF 49 05 2E E1 8D
|
||||||
|
6F 78 44 DA 57 43 69 EE 76 6C 38 8A E9 8E A3 F0
|
||||||
|
A7 1F 3C A8 D0 12 15 3E CA 0E BD FA 24 CD 33 C6
|
||||||
|
47 AE A4 18 83 8E 22 39 75 93 86 E6 FD 66 48 B6
|
||||||
|
10 AD 94 14 65 F9 6A 17 78 BD 16 53 84 30 BF 70
|
||||||
|
E0 DC 65 FD 3C C6 B0 1E BF B9 C1 B5 6C EF B1 3A
|
||||||
|
F8 28 05 83 62 26 11 DC B4 6B 5A 97 FF 32 26 B6
|
||||||
|
F7 02 71 CF 15 AE 16 DD D1 C1 8E A8 CF 9B 50 7B
|
||||||
|
C3 91 FF 44 1E CF 7C 39 FE 17 77 21 20 BD CE 9B
|
||||||
|
|
||||||
|
Possible values:
|
||||||
|
|
||||||
|
Algorithm: TPM_ALG_RSA (1)
|
||||||
|
Encscheme: TPM_ES_RSAESPKCSv15 (2)
|
||||||
|
TPM_ES_RSAESOAEP_SHA1_MGF1 (3)
|
||||||
|
Sigscheme: TPM_SS_NONE (1)
|
||||||
|
Parameters, a byte string of 3 u32 values:
|
||||||
|
Key Length (bits): 00 00 08 00 (2048)
|
||||||
|
Num primes: 00 00 00 02 (2)
|
||||||
|
Exponent Size: 00 00 00 00 (0 means the
|
||||||
|
default exp)
|
||||||
|
Modulus Length: 256 (bytes)
|
||||||
|
Modulus: The 256 byte Endorsement Key modulus
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/temp_deactivated
|
||||||
|
Date: April 2006
|
||||||
|
KernelVersion: 2.6.17
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "temp_deactivated" property returns a '1' if the chip has
|
||||||
|
been temporarily dectivated, usually until the next power
|
||||||
|
cycle. Whether a warm boot (reboot) will clear a TPM chip
|
||||||
|
from a temp_deactivated state is platform specific.
|
||||||
|
|
||||||
|
What: /sys/class/misc/tpmX/device/timeouts
|
||||||
|
Date: March 2011
|
||||||
|
KernelVersion: 3.1
|
||||||
|
Contact: tpmdd-devel@lists.sf.net
|
||||||
|
Description: The "timeouts" property shows the 4 vendor-specific values
|
||||||
|
for the TPM's interface spec timeouts. The use of these
|
||||||
|
timeouts is defined by the TPM interface spec that the chip
|
||||||
|
conforms to.
|
||||||
|
|
||||||
|
Example output:
|
||||||
|
|
||||||
|
750000 750000 750000 750000 [original]
|
||||||
|
|
||||||
|
The four timeout values are shown in usecs, with a trailing
|
||||||
|
"[original]" or "[adjusted]" depending on whether the values
|
||||||
|
were scaled by the driver to be reported in usec from msecs.
|
@@ -18,17 +18,21 @@ Description:
|
|||||||
rule format: action [condition ...]
|
rule format: action [condition ...]
|
||||||
|
|
||||||
action: measure | dont_measure | appraise | dont_appraise | audit
|
action: measure | dont_measure | appraise | dont_appraise | audit
|
||||||
condition:= base | lsm
|
condition:= base | lsm [option]
|
||||||
base: [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
|
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
|
||||||
|
[fowner]]
|
||||||
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
||||||
[obj_user=] [obj_role=] [obj_type=]]
|
[obj_user=] [obj_role=] [obj_type=]]
|
||||||
|
option: [[appraise_type=]]
|
||||||
|
|
||||||
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK][MODULE_CHECK]
|
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
|
||||||
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
|
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
|
||||||
fsmagic:= hex value
|
fsmagic:= hex value
|
||||||
|
fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
|
||||||
uid:= decimal value
|
uid:= decimal value
|
||||||
fowner:=decimal value
|
fowner:=decimal value
|
||||||
lsm: are LSM specific
|
lsm: are LSM specific
|
||||||
|
option: appraise_type:= [imasig]
|
||||||
|
|
||||||
default policy:
|
default policy:
|
||||||
# PROC_SUPER_MAGIC
|
# PROC_SUPER_MAGIC
|
||||||
|
@@ -1,4 +1,4 @@
|
|||||||
Where: /dev/pstore/...
|
Where: /sys/fs/pstore/... (or /dev/pstore/...)
|
||||||
Date: March 2011
|
Date: March 2011
|
||||||
Kernel Version: 2.6.39
|
Kernel Version: 2.6.39
|
||||||
Contact: tony.luck@intel.com
|
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
|
of the console log is captured, but other interesting
|
||||||
data can also be saved.
|
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
|
total 0
|
||||||
-r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1
|
-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
|
the file will signal to the underlying persistent storage
|
||||||
device that it can reclaim the space for later re-use.
|
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
|
will be saved elsewhere and erased from persistent store
|
||||||
soon after boot to free up space ready for the next
|
soon after boot to free up space ready for the next
|
||||||
catastrophe.
|
catastrophe.
|
||||||
|
@@ -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.
|
@@ -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
|
Date: March 2012
|
||||||
KernelVersion: TBD
|
KernelVersion: TBD
|
||||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
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:
|
Attributes:
|
||||||
|
|
||||||
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
|
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
|
||||||
this value will change the dev_loss_tmo for all
|
this value will change the dev_loss_tmo for all
|
||||||
FCFs discovered by this controller.
|
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/link_fail: Link Error Status Block (LESB) link failure count.
|
||||||
|
|
||||||
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
|
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
|
||||||
@@ -26,7 +65,7 @@ Attributes:
|
|||||||
|
|
||||||
Notes: ctlr_X (global increment starting at 0)
|
Notes: ctlr_X (global increment starting at 0)
|
||||||
|
|
||||||
What: /sys/bus/fcoe/fcf_X
|
What: /sys/bus/fcoe/devices/fcf_X
|
||||||
Date: March 2012
|
Date: March 2012
|
||||||
KernelVersion: TBD
|
KernelVersion: TBD
|
||||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
||||||
|
13
Documentation/ABI/testing/sysfs-bus-iio-mpu6050
Normal file
13
Documentation/ABI/testing/sysfs-bus-iio-mpu6050
Normal 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.
|
@@ -227,3 +227,12 @@ Contact: Lan Tianyu <tianyu.lan@intel.com>
|
|||||||
Description:
|
Description:
|
||||||
The /sys/bus/usb/devices/.../(hub interface)/portX
|
The /sys/bus/usb/devices/.../(hub interface)/portX
|
||||||
is usb port device's sysfs directory.
|
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.
|
||||||
|
@@ -48,3 +48,8 @@ max_ratio (read-write)
|
|||||||
most of the write-back cache. For example in case of an NFS
|
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
|
mount that is prone to get stuck, or a FUSE mount which cannot
|
||||||
be trusted to play fair.
|
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
13
Documentation/ABI/testing/sysfs-devices-power_resources_D0
Normal 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
14
Documentation/ABI/testing/sysfs-devices-power_resources_D1
Normal 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
14
Documentation/ABI/testing/sysfs-devices-power_resources_D2
Normal 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.
|
@@ -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
20
Documentation/ABI/testing/sysfs-devices-power_state
Normal 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
23
Documentation/ABI/testing/sysfs-devices-real_power_state
Normal 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
12
Documentation/ABI/testing/sysfs-devices-resource_in_use
Normal 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.
|
@@ -67,20 +67,6 @@ Description: Discover NUMA node a CPU belongs to
|
|||||||
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
|
/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
|
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
|
||||||
/sys/devices/system/cpu/cpu#/topology/core_siblings_list
|
/sys/devices/system/cpu/cpu#/topology/core_siblings_list
|
||||||
|
21
Documentation/ABI/testing/sysfs-driver-hid-srws1
Normal file
21
Documentation/ABI/testing/sysfs-driver-hid-srws1
Normal 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
23
Documentation/ABI/testing/sysfs-driver-hid-thingm
Normal 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
52
Documentation/ABI/testing/sysfs-kernel-mm-ksm
Normal 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
83
Documentation/ABI/testing/sysfs-platform-msi-laptop
Normal 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
47
Documentation/ABI/testing/sysfs-platform-ts5500
Normal 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".
|
@@ -546,15 +546,7 @@ config AUDIT
|
|||||||
logging of avc messages output). Does not do system-call
|
logging of avc messages output). Does not do system-call
|
||||||
auditing without CONFIG_AUDITSYSCALL.
|
auditing without CONFIG_AUDITSYSCALL.
|
||||||
|
|
||||||
Features that might still be considered unstable should be defined as
|
Seriously dangerous features (such as write support for certain
|
||||||
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
|
|
||||||
filesystems) should advertise this prominently in their prompt string:
|
filesystems) should advertise this prominently in their prompt string:
|
||||||
|
|
||||||
config ADFS_FS_RW
|
config ADFS_FS_RW
|
||||||
|
@@ -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
|
that the mapping code will work correctly on all dma implementations without
|
||||||
any dependency on the specifics of the underlying implementation. Using the
|
any dependency on the specifics of the underlying implementation. Using the
|
||||||
returned address without checking for errors could result in failures ranging
|
returned address without checking for errors could result in failures ranging
|
||||||
from panics to silent data corruption. Couple of example of incorrect ways to
|
from panics to silent data corruption. A couple of examples of incorrect ways
|
||||||
check for errors that make assumptions about the underlying dma implementation
|
to check for errors that make assumptions about the underlying dma
|
||||||
are as follows and these are applicable to dma_map_page() as well.
|
implementation are as follows and these are applicable to dma_map_page() as
|
||||||
|
well.
|
||||||
|
|
||||||
Incorrect example 1:
|
Incorrect example 1:
|
||||||
dma_addr_t dma_handle;
|
dma_addr_t dma_handle;
|
||||||
@@ -751,7 +752,7 @@ Example 1:
|
|||||||
dma_unmap_single(dma_handle1);
|
dma_unmap_single(dma_handle1);
|
||||||
map_error_handling1:
|
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)
|
mapping error is detected in the middle)
|
||||||
|
|
||||||
dma_addr_t dma_addr;
|
dma_addr_t dma_addr;
|
||||||
|
@@ -107,8 +107,8 @@
|
|||||||
!Finclude/net/cfg80211.h key_params
|
!Finclude/net/cfg80211.h key_params
|
||||||
!Finclude/net/cfg80211.h survey_info_flags
|
!Finclude/net/cfg80211.h survey_info_flags
|
||||||
!Finclude/net/cfg80211.h survey_info
|
!Finclude/net/cfg80211.h survey_info
|
||||||
!Finclude/net/cfg80211.h beacon_parameters
|
!Finclude/net/cfg80211.h cfg80211_beacon_data
|
||||||
!Finclude/net/cfg80211.h plink_actions
|
!Finclude/net/cfg80211.h cfg80211_ap_settings
|
||||||
!Finclude/net/cfg80211.h station_parameters
|
!Finclude/net/cfg80211.h station_parameters
|
||||||
!Finclude/net/cfg80211.h station_info_flags
|
!Finclude/net/cfg80211.h station_info_flags
|
||||||
!Finclude/net/cfg80211.h rate_info_flags
|
!Finclude/net/cfg80211.h rate_info_flags
|
||||||
|
@@ -1160,6 +1160,12 @@ int max_width, max_height;</synopsis>
|
|||||||
without waiting for rendering or page flip to complete and must block
|
without waiting for rendering or page flip to complete and must block
|
||||||
any new rendering to the frame buffer until the page flip completes.
|
any new rendering to the frame buffer until the page flip completes.
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
|
If a page flip can be successfully scheduled the driver must set the
|
||||||
|
<code>drm_crtc-<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>
|
<para>
|
||||||
If a page flip is already pending, the
|
If a page flip is already pending, the
|
||||||
<methodname>page_flip</methodname> operation must return
|
<methodname>page_flip</methodname> operation must return
|
||||||
@@ -2143,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||||||
<title>fbdev Helper Functions Reference</title>
|
<title>fbdev Helper Functions Reference</title>
|
||||||
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
|
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
|
||||||
!Edrivers/gpu/drm/drm_fb_helper.c
|
!Edrivers/gpu/drm/drm_fb_helper.c
|
||||||
|
!Iinclude/drm/drm_fb_helper.h
|
||||||
</sect2>
|
</sect2>
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Display Port Helper Functions Reference</title>
|
<title>Display Port Helper Functions Reference</title>
|
||||||
@@ -2150,6 +2157,10 @@ void intel_crt_init(struct drm_device *dev)
|
|||||||
!Iinclude/drm/drm_dp_helper.h
|
!Iinclude/drm/drm_dp_helper.h
|
||||||
!Edrivers/gpu/drm/drm_dp_helper.c
|
!Edrivers/gpu/drm/drm_dp_helper.c
|
||||||
</sect2>
|
</sect2>
|
||||||
|
<sect2>
|
||||||
|
<title>EDID Helper Functions Reference</title>
|
||||||
|
!Edrivers/gpu/drm/drm_edid.c
|
||||||
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<!-- Internals: vertical blanking -->
|
<!-- Internals: vertical blanking -->
|
||||||
|
@@ -945,7 +945,7 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress);
|
|||||||
|
|
||||||
<sect1 id="sym-exportsymbols">
|
<sect1 id="sym-exportsymbols">
|
||||||
<title><function>EXPORT_SYMBOL()</function>
|
<title><function>EXPORT_SYMBOL()</function>
|
||||||
<filename class="headerfile">include/linux/module.h</filename></title>
|
<filename class="headerfile">include/linux/export.h</filename></title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This is the classic method of exporting a symbol: dynamically
|
This is the classic method of exporting a symbol: dynamically
|
||||||
@@ -955,7 +955,7 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress);
|
|||||||
|
|
||||||
<sect1 id="sym-exportsymbols-gpl">
|
<sect1 id="sym-exportsymbols-gpl">
|
||||||
<title><function>EXPORT_SYMBOL_GPL()</function>
|
<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>
|
<para>
|
||||||
Similar to <function>EXPORT_SYMBOL()</function> except that the
|
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>.
|
<filename>Documentation/kbuild/kconfig-language.txt</filename>.
|
||||||
</para>
|
</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>
|
<para>
|
||||||
In your description of the option, make sure you address both the
|
In your description of the option, make sure you address both the
|
||||||
expert user and the user who knows nothing about your feature. Mention
|
expert user and the user who knows nothing about your feature. Mention
|
||||||
|
@@ -94,10 +94,8 @@
|
|||||||
<sect1 id="CompileKGDB">
|
<sect1 id="CompileKGDB">
|
||||||
<title>Kernel config options for kgdb</title>
|
<title>Kernel config options for kgdb</title>
|
||||||
<para>
|
<para>
|
||||||
To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
|
To enable <symbol>CONFIG_KGDB</symbol> you should look under
|
||||||
"Prompt for development and/or incomplete code/drivers"
|
"Kernel debugging" and select "KGDB: kernel debugger".
|
||||||
(CONFIG_EXPERIMENTAL) in "General setup", then under the
|
|
||||||
"Kernel debugging" select "KGDB: kernel debugger".
|
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
While it is not a hard requirement that you have symbols in your
|
While it is not a hard requirement that you have symbols in your
|
||||||
|
@@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
|
|||||||
|
|
||||||
|
|
||||||
<title>LINUX DVB API</title>
|
<title>LINUX DVB API</title>
|
||||||
<subtitle>Version 5.8</subtitle>
|
<subtitle>Version 5.10</subtitle>
|
||||||
<!-- ADD THE CHAPTERS HERE -->
|
<!-- ADD THE CHAPTERS HERE -->
|
||||||
<chapter id="dvb_introdution">
|
<chapter id="dvb_introdution">
|
||||||
&sub-intro;
|
&sub-intro;
|
||||||
|
@@ -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>
|
<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">
|
API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
|
||||||
struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
|
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">
|
<section id="dtv-property">
|
||||||
<title>DTV property type</title>
|
<title>DTV property type</title>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
/* Reserved fields should be set to 0 */
|
/* Reserved fields should be set to 0 */
|
||||||
|
|
||||||
struct dtv_property {
|
struct dtv_property {
|
||||||
__u32 cmd;
|
__u32 cmd;
|
||||||
|
__u32 reserved[3];
|
||||||
union {
|
union {
|
||||||
__u32 data;
|
__u32 data;
|
||||||
|
struct dtv_fe_stats st;
|
||||||
struct {
|
struct {
|
||||||
__u8 data[32];
|
__u8 data[32];
|
||||||
__u32 len;
|
__u32 len;
|
||||||
@@ -440,7 +467,7 @@ typedef enum fe_delivery_system {
|
|||||||
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
|
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
|
||||||
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
|
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
|
||||||
ISDB-T hierarchical layers can be decoded simultaneously. For that
|
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
|
<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
|
available segments. The total number of segments over all layers has
|
||||||
to 13 in ISDB-T.</para>
|
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>
|
<para>use the special macro LNA_AUTO to set LNA auto</para>
|
||||||
</section>
|
</section>
|
||||||
</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">
|
<section id="frontend-property-terrestrial-systems">
|
||||||
<title>Properties used on terrestrial delivery systems</title>
|
<title>Properties used on terrestrial delivery systems</title>
|
||||||
<section id="dvbt-params">
|
<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-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="dvbt2-params">
|
<section id="dvbt2-params">
|
||||||
<title>DVB-T2 delivery system</title>
|
<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-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="isdbt">
|
<section id="isdbt">
|
||||||
<title>ISDB-T delivery system</title>
|
<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-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>
|
<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="atsc-params">
|
<section id="atsc-params">
|
||||||
<title>ATSC delivery system</title>
|
<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-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="atscmh-params">
|
<section id="atscmh-params">
|
||||||
<title>ATSC-MH delivery system</title>
|
<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-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>
|
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="dtmb-params">
|
<section id="dtmb-params">
|
||||||
<title>DTMB delivery system</title>
|
<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-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="frontend-property-cable-systems">
|
<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-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="dvbc-annex-b-params">
|
<section id="dvbc-annex-b-params">
|
||||||
<title>DVB-C Annex B delivery system</title>
|
<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-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="frontend-property-satellital-systems">
|
<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-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</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>
|
<para>Future implementations might add those two missing parameters:</para>
|
||||||
<itemizedlist mark='opencircle'>
|
<itemizedlist mark='opencircle'>
|
||||||
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
|
<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-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
|
||||||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="turbo-params">
|
<section id="turbo-params">
|
||||||
<title>Turbo code delivery system</title>
|
<title>Turbo code delivery system</title>
|
||||||
|
@@ -230,7 +230,7 @@ typedef enum fe_status {
|
|||||||
<entry align="char">The frontend has found a DVB signal</entry>
|
<entry align="char">The frontend has found a DVB signal</entry>
|
||||||
</row><row>
|
</row><row>
|
||||||
<entry align="char">FE_HAS_VITERBI</entry>
|
<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>
|
</row><row>
|
||||||
<entry align="char">FE_HAS_SYNC</entry>
|
<entry align="char">FE_HAS_SYNC</entry>
|
||||||
<entry align="char">Syncronization bytes was found</entry>
|
<entry align="char">Syncronization bytes was found</entry>
|
||||||
|
@@ -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
|
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
|
||||||
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
|
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
|
||||||
are available for the device.</para>
|
are available for the device.</para>
|
||||||
&ENOTTY;.
|
|
||||||
<para>See <xref linkend="buffer" /> for a rationale. Probably
|
<para>See <xref linkend="buffer" /> for a rationale. Probably
|
||||||
even USB cameras follow some well known video standard. It might have
|
even USB cameras follow some well known video standard. It might have
|
||||||
been better to explicitly indicate elsewhere if a device cannot live
|
been better to explicitly indicate elsewhere if a device cannot live
|
||||||
|
@@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||||||
</orderedlist>
|
</orderedlist>
|
||||||
</section>
|
</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">
|
<section id="other">
|
||||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||||
|
|
||||||
|
@@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry>
|
|||||||
<entry>boolean</entry>
|
<entry>boolean</entry>
|
||||||
<entry>Mirror the picture vertically.</entry>
|
<entry>Mirror the picture vertically.</entry>
|
||||||
</row>
|
</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">
|
<row id="v4l2-power-line-frequency">
|
||||||
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
|
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
|
||||||
<entry>enum</entry>
|
<entry>enum</entry>
|
||||||
|
@@ -477,7 +477,7 @@ rest should be evident.</para>
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<title>Experimental</title>
|
<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>
|
interface and may change in the future.</para>
|
||||||
</note>
|
</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
|
different or the same device (known as the importer role), or both. This
|
||||||
section describes the DMABUF importer role API in V4L2.</para>
|
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>
|
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
|
||||||
|
|
||||||
<para>Input and output devices support the streaming I/O method when the
|
<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>struct timeval</entry>
|
||||||
<entry><structfield>timestamp</structfield></entry>
|
<entry><structfield>timestamp</structfield></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry><para>For input streams this is the
|
<entry><para>For input streams this is time when the first data
|
||||||
system time (as returned by the <function>gettimeofday()</function>
|
byte was captured, as returned by the
|
||||||
function) when the first data byte was captured. For output streams
|
<function>clock_gettime()</function> function for the relevant
|
||||||
the data will not be displayed before this time, secondary to the
|
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
|
||||||
nominal frame rate determined by the current video standard in
|
<xref linkend="buffer-flags" />. For output streams the data
|
||||||
enqueued order. Applications can for example zero this field to
|
will not be displayed before this time, secondary to the nominal
|
||||||
display frames as soon as possible. The driver stores the time at
|
frame rate determined by the current video standard in enqueued
|
||||||
which the first data byte was actually sent out in the
|
order. Applications can for example zero this field to display
|
||||||
<structfield>timestamp</structfield> field. This permits
|
frames as soon as possible. The driver stores the time at which
|
||||||
applications to monitor the drift between the video and system
|
the first data byte was actually sent out in the
|
||||||
clock.</para></entry>
|
<structfield>timestamp</structfield> field. This permits
|
||||||
|
applications to monitor the drift between the video and system
|
||||||
|
clock.</para></entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>&v4l2-timecode;</entry>
|
<entry>&v4l2-timecode;</entry>
|
||||||
@@ -903,7 +905,7 @@ should set this to 0.</entry>
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>__unsigned long</entry>
|
<entry>unsigned long</entry>
|
||||||
<entry><structfield>userptr</structfield></entry>
|
<entry><structfield>userptr</structfield></entry>
|
||||||
<entry>When the memory type in the containing &v4l2-buffer; is
|
<entry>When the memory type in the containing &v4l2-buffer; is
|
||||||
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
|
<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 this buffer has not been created by the CPU but by some DMA-capable unit,
|
||||||
in which case caches have not been used.</entry>
|
in which case caches have not been used.</entry>
|
||||||
</row>
|
</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>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
|
@@ -6,7 +6,7 @@
|
|||||||
<refnamediv>
|
<refnamediv>
|
||||||
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
|
<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-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
|
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
|
||||||
non contiguous in memory. </refpurpose>
|
non contiguous in memory. </refpurpose>
|
||||||
</refnamediv>
|
</refnamediv>
|
||||||
|
34
Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
Normal file
34
Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
Normal 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
62
Documentation/DocBook/media/v4l/pixfmt-uv8.xml
Normal 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 + 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 + 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 + 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 + 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>
|
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
|
|||||||
&sub-srggb8;
|
&sub-srggb8;
|
||||||
&sub-sbggr16;
|
&sub-sbggr16;
|
||||||
&sub-srggb10;
|
&sub-srggb10;
|
||||||
|
&sub-srggb10alaw8;
|
||||||
&sub-srggb10dpcm8;
|
&sub-srggb10dpcm8;
|
||||||
&sub-srggb12;
|
&sub-srggb12;
|
||||||
</section>
|
</section>
|
||||||
@@ -701,6 +702,7 @@ information.</para>
|
|||||||
&sub-y12;
|
&sub-y12;
|
||||||
&sub-y10b;
|
&sub-y10b;
|
||||||
&sub-y16;
|
&sub-y16;
|
||||||
|
&sub-uv8;
|
||||||
&sub-yuyv;
|
&sub-yuyv;
|
||||||
&sub-uyvy;
|
&sub-uyvy;
|
||||||
&sub-yvyu;
|
&sub-yvyu;
|
||||||
|
File diff suppressed because it is too large
Load Diff
@@ -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
|
(compat.xml), along with the possible impact on existing drivers and
|
||||||
applications. -->
|
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>
|
<revision>
|
||||||
<revnumber>3.6</revnumber>
|
<revnumber>3.6</revnumber>
|
||||||
<date>2012-07-02</date>
|
<date>2012-07-02</date>
|
||||||
@@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||||||
</partinfo>
|
</partinfo>
|
||||||
|
|
||||||
<title>Video for Linux Two API Specification</title>
|
<title>Video for Linux Two API Specification</title>
|
||||||
<subtitle>Revision 3.6</subtitle>
|
<subtitle>Revision 3.9</subtitle>
|
||||||
|
|
||||||
<chapter id="common">
|
<chapter id="common">
|
||||||
&sub-common;
|
&sub-common;
|
||||||
|
@@ -261,6 +261,12 @@
|
|||||||
<entry>This control event was triggered because the control flags
|
<entry>This control event was triggered because the control flags
|
||||||
changed.</entry>
|
changed.</entry>
|
||||||
</row>
|
</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>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
|
@@ -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
|
<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
|
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>
|
is no longer used to allow the associated memory to be reclaimed. </para>
|
||||||
|
|
||||||
</refsect1>
|
</refsect1>
|
||||||
<refsect1>
|
|
||||||
<section>
|
|
||||||
<title>Examples</title>
|
|
||||||
|
|
||||||
<example>
|
<refsect1>
|
||||||
<title>Exporting a buffer.</title>
|
<title>Examples</title>
|
||||||
<programlisting>
|
|
||||||
|
<example>
|
||||||
|
<title>Exporting a buffer.</title>
|
||||||
|
<programlisting>
|
||||||
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
|
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
|
||||||
{
|
{
|
||||||
&v4l2-exportbuffer; expbuf;
|
&v4l2-exportbuffer; expbuf;
|
||||||
@@ -108,12 +107,12 @@ int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
|
|||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</example>
|
</example>
|
||||||
|
|
||||||
<example>
|
<example>
|
||||||
<title>Exporting a buffer using the multi-planar API.</title>
|
<title>Exporting a buffer using the multi-planar API.</title>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
|
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
|
||||||
int dmafd[], int n_planes)
|
int dmafd[], int n_planes)
|
||||||
{
|
{
|
||||||
@@ -137,12 +136,9 @@ int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
|
|||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</example>
|
</example>
|
||||||
</section>
|
|
||||||
</refsect1>
|
|
||||||
|
|
||||||
<refsect1>
|
|
||||||
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
|
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
|
||||||
<title>struct <structname>v4l2_exportbuffer</structname></title>
|
<title>struct <structname>v4l2_exportbuffer</structname></title>
|
||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
|
@@ -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
|
of bounds drivers can choose to take the closest valid value or return
|
||||||
an &ERANGE;, whatever seems more appropriate. However,
|
an &ERANGE;, whatever seems more appropriate. However,
|
||||||
<constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not
|
<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
|
<para>These ioctls work only with user controls. For other
|
||||||
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
|
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
|
||||||
@@ -99,7 +101,9 @@ application.</entry>
|
|||||||
<term><errorcode>EINVAL</errorcode></term>
|
<term><errorcode>EINVAL</errorcode></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The &v4l2-control; <structfield>id</structfield> is
|
<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>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
|
@@ -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
|
&EINVAL;. When the value is out of bounds drivers can choose to take
|
||||||
the closest valid value or return an &ERANGE;, whatever seems more
|
the closest valid value or return an &ERANGE;, whatever seems more
|
||||||
appropriate. In the first case the new value is set in
|
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
|
<para>The driver will only set/get these controls if all control
|
||||||
values are correct. This prevents the situation where only some of the
|
values are correct. This prevents the situation where only some of the
|
||||||
@@ -199,13 +201,46 @@ also be zero.</entry>
|
|||||||
<row>
|
<row>
|
||||||
<entry>__u32</entry>
|
<entry>__u32</entry>
|
||||||
<entry><structfield>error_idx</structfield></entry>
|
<entry><structfield>error_idx</structfield></entry>
|
||||||
<entry>Set by the driver in case of an error. If it is equal
|
<entry><para>Set by the driver in case of an error. If the error is
|
||||||
to <structfield>count</structfield>, then no actual changes were made to
|
associated with a particular control, then <structfield>error_idx</structfield>
|
||||||
controls. In other words, the error was not associated with setting a particular
|
is set to the index of that control. If the error is not related to a specific
|
||||||
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
|
control, or the validation step failed (see below), then
|
||||||
were modified and control <structfield>error_idx</structfield> is the one that
|
<structfield>error_idx</structfield> is set to <structfield>count</structfield>.
|
||||||
caused the error. The <structfield>error_idx</structfield> value is undefined
|
The value is undefined if the ioctl returned 0 (success).</para>
|
||||||
if the ioctl returned 0 (success).</entry>
|
|
||||||
|
<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>
|
||||||
<row>
|
<row>
|
||||||
<entry>__u32</entry>
|
<entry>__u32</entry>
|
||||||
@@ -298,8 +333,10 @@ These controls are described in <xref
|
|||||||
<term><errorcode>EINVAL</errorcode></term>
|
<term><errorcode>EINVAL</errorcode></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>The &v4l2-ext-control; <structfield>id</structfield>
|
<para>The &v4l2-ext-control; <structfield>id</structfield>
|
||||||
is invalid or the &v4l2-ext-controls;
|
is invalid, the &v4l2-ext-controls;
|
||||||
<structfield>ctrl_class</structfield> is invalid. This error code is
|
<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
|
also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and
|
||||||
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
|
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
|
||||||
control values are in conflict.</para>
|
control values are in conflict.</para>
|
||||||
|
@@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry>
|
|||||||
<row>
|
<row>
|
||||||
<entry>__u8</entry>
|
<entry>__u8</entry>
|
||||||
<entry><structfield>card</structfield>[32]</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
|
For example: "Yoyodyne TV/FM". One driver may support different brands
|
||||||
or models of video hardware. This information is intended for users,
|
or models of video hardware. This information is intended for users,
|
||||||
for example in a menu of available devices. Since multiple TV cards of
|
for example in a menu of available devices. Since multiple TV cards of
|
||||||
|
@@ -22,6 +22,7 @@
|
|||||||
|
|
||||||
<!-- LinuxTV v4l-dvb repository. -->
|
<!-- LinuxTV v4l-dvb repository. -->
|
||||||
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
|
<!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">
|
<book id="media_api">
|
||||||
|
@@ -984,7 +984,7 @@ int main()
|
|||||||
return errno;
|
return errno;
|
||||||
}
|
}
|
||||||
configfd = open("/sys/class/uio/uio0/device/config", O_RDWR);
|
configfd = open("/sys/class/uio/uio0/device/config", O_RDWR);
|
||||||
if (uiofd < 0) {
|
if (configfd < 0) {
|
||||||
perror("config open:");
|
perror("config open:");
|
||||||
return errno;
|
return errno;
|
||||||
}
|
}
|
||||||
|
@@ -871,9 +871,8 @@
|
|||||||
<para>
|
<para>
|
||||||
This function itself doesn't allocate the data space. The data
|
This function itself doesn't allocate the data space. The data
|
||||||
must be allocated manually beforehand, and its pointer is passed
|
must be allocated manually beforehand, and its pointer is passed
|
||||||
as the argument. This pointer is used as the
|
as the argument. This pointer (<parameter>chip</parameter> in the
|
||||||
(<parameter>chip</parameter> identifier in the above example)
|
above example) is used as the identifier for the instance.
|
||||||
for the instance.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@@ -2304,7 +2303,7 @@ struct _snd_pcm_runtime {
|
|||||||
<constant>SNDRV_PCM_INFO_XXX</constant>. Here, at least, you
|
<constant>SNDRV_PCM_INFO_XXX</constant>. Here, at least, you
|
||||||
have to specify whether the mmap is supported and which
|
have to specify whether the mmap is supported and which
|
||||||
interleaved format is supported.
|
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
|
<constant>SNDRV_PCM_INFO_MMAP</constant> flag here. When the
|
||||||
hardware supports the interleaved or the non-interleaved
|
hardware supports the interleaved or the non-interleaved
|
||||||
formats, <constant>SNDRV_PCM_INFO_INTERLEAVED</constant> or
|
formats, <constant>SNDRV_PCM_INFO_INTERLEAVED</constant> or
|
||||||
@@ -2898,7 +2897,7 @@ struct _snd_pcm_runtime {
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
When the pcm supports the pause operation (given in the info
|
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
|
and <constant>PAUSE_RELEASE</constant> commands must be
|
||||||
handled here, too. The former is the command to pause the pcm,
|
handled here, too. The former is the command to pause the pcm,
|
||||||
and the latter to restart the pcm again.
|
and the latter to restart the pcm again.
|
||||||
@@ -3085,7 +3084,7 @@ struct _snd_pcm_runtime {
|
|||||||
<section id="pcm-interface-interrupt-handler-timer">
|
<section id="pcm-interface-interrupt-handler-timer">
|
||||||
<title>High frequency timer interrupts</title>
|
<title>High frequency timer interrupts</title>
|
||||||
<para>
|
<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
|
at the period boundary but issues timer interrupts at a fixed
|
||||||
timer rate (e.g. es1968 or ymfpci drivers).
|
timer rate (e.g. es1968 or ymfpci drivers).
|
||||||
In this case, you need to check the current hardware
|
In this case, you need to check the current hardware
|
||||||
@@ -3250,49 +3249,6 @@ struct _snd_pcm_runtime {
|
|||||||
<example>
|
<example>
|
||||||
<title>Example of Hardware Constraints for Channels</title>
|
<title>Example of Hardware Constraints for Channels</title>
|
||||||
<programlisting>
|
<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[
|
<![CDATA[
|
||||||
static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
|
static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
|
||||||
struct snd_pcm_hw_rule *rule)
|
struct snd_pcm_hw_rule *rule)
|
||||||
@@ -3314,6 +3270,50 @@ struct _snd_pcm_runtime {
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
</example>
|
</example>
|
||||||
</para>
|
</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>
|
<para>
|
||||||
...and in the open callback:
|
...and in the open callback:
|
||||||
@@ -3321,8 +3321,8 @@ struct _snd_pcm_runtime {
|
|||||||
<programlisting>
|
<programlisting>
|
||||||
<![CDATA[
|
<![CDATA[
|
||||||
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT,
|
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT,
|
||||||
hw_rule_format_by_channels, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
|
hw_rule_format_by_channels, NULL,
|
||||||
-1);
|
SNDRV_PCM_HW_PARAM_CHANNELS, -1);
|
||||||
]]>
|
]]>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
</informalexample>
|
||||||
|
@@ -348,34 +348,40 @@ You can change this at module load time (for a module) with:
|
|||||||
|
|
||||||
modprobe ipmi_si.o type=<type1>,<type2>....
|
modprobe ipmi_si.o type=<type1>,<type2>....
|
||||||
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
|
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
|
||||||
irqs=<irq1>,<irq2>... trydefaults=[0|1]
|
irqs=<irq1>,<irq2>...
|
||||||
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
|
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
|
||||||
regshifts=<shift1>,<shift2>,...
|
regshifts=<shift1>,<shift2>,...
|
||||||
slave_addrs=<addr1>,<addr2>,...
|
slave_addrs=<addr1>,<addr2>,...
|
||||||
force_kipmid=<enable1>,<enable2>,...
|
force_kipmid=<enable1>,<enable2>,...
|
||||||
kipmid_max_busy_us=<ustime1>,<ustime2>,...
|
kipmid_max_busy_us=<ustime1>,<ustime2>,...
|
||||||
unload_when_empty=[0|1]
|
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.
|
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
|
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
|
||||||
defaults to "kcs".
|
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
|
use the memory address given as the address of the device. This
|
||||||
overrides si_ports.
|
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.
|
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.
|
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
|
any interfaces specified by ACPE are tried. By default, the driver
|
||||||
tries it, set this value to zero to turn this off.
|
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
|
The next three parameters have to do with register layout. The
|
||||||
registers used by the interfaces may not appear at successive
|
registers used by the interfaces may not appear at successive
|
||||||
locations and they may not be in 8-bit registers. These parameters
|
locations and they may not be in 8-bit registers. These parameters
|
||||||
|
@@ -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
|
returns as soon as it finds any constraint that doesn't allow the
|
||||||
call to succeed.
|
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)
|
void pci_disable_msi(struct pci_dev *dev)
|
||||||
|
|
||||||
This function should be used to undo the effect of pci_enable_msi() or
|
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
|
pci_enable_msi_block() or pci_enable_msi_block_auto(). Calling it restores
|
||||||
interrupt number and frees the previously allocated message signaled
|
dev->irq to the pin-based interrupt number and frees the previously
|
||||||
interrupt(s). The interrupt may subsequently be assigned to another
|
allocated message signaled interrupt(s). The interrupt may subsequently be
|
||||||
device, so drivers should not cache the value of dev->irq.
|
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()
|
Before calling this function, a device driver must always call free_irq()
|
||||||
on any interrupt for which it previously called request_irq().
|
on any interrupt for which it previously called request_irq().
|
||||||
|
@@ -60,8 +60,7 @@ own source tree. For example:
|
|||||||
"dontdiff" is a list of files which are generated by the kernel during
|
"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
|
the build process, and should be ignored in any diff(1)-generated
|
||||||
patch. The "dontdiff" file is included in the kernel tree in
|
patch. The "dontdiff" file is included in the kernel tree in
|
||||||
2.6.12 and later. For earlier kernel versions, you can get it
|
2.6.12 and later.
|
||||||
from <http://www.xenotime.net/linux/doc/dontdiff>.
|
|
||||||
|
|
||||||
Make sure your patch does not include any extra files which do not
|
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-
|
belong in a patch submission. Make sure to review your patch -after-
|
||||||
|
@@ -63,8 +63,8 @@ from ACPI tables.
|
|||||||
Currently the kernel is not able to automatically determine from which ACPI
|
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
|
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
|
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
|
drivers/acpi/acpi_platform.c. This limitation is only for the platform
|
||||||
and I2C devices are created automatically as described below.
|
devices, SPI and I2C devices are created automatically as described below.
|
||||||
|
|
||||||
SPI serial bus support
|
SPI serial bus support
|
||||||
~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
77
Documentation/acpi/scan_handlers.txt
Normal file
77
Documentation/acpi/scan_handlers.txt
Normal 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.
|
@@ -35,6 +35,8 @@ ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
|
|||||||
|
|
||||||
ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap]
|
ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap]
|
||||||
|
|
||||||
|
ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
|
||||||
|
|
||||||
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
|
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
|
||||||
|
|
||||||
ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]
|
ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]
|
||||||
|
@@ -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
|
the given new value. It returns the old value that the atomic variable v had
|
||||||
just before the operation.
|
just before the operation.
|
||||||
|
|
||||||
|
atomic_xchg requires explicit memory barriers around the operation.
|
||||||
|
|
||||||
int atomic_cmpxchg(atomic_t *v, int old, int new);
|
int atomic_cmpxchg(atomic_t *v, int old, int new);
|
||||||
|
|
||||||
This performs an atomic compare exchange operation on the atomic value v,
|
This performs an atomic compare exchange operation on the atomic value v,
|
||||||
|
@@ -4,7 +4,7 @@ Kernel driver lp855x
|
|||||||
Backlight driver for LP855x ICs
|
Backlight driver for LP855x ICs
|
||||||
|
|
||||||
Supported chips:
|
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>
|
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
|
||||||
|
|
||||||
@@ -24,7 +24,7 @@ Value : pwm based or register based
|
|||||||
|
|
||||||
2) chip_id
|
2) chip_id
|
||||||
The lp855x chip id.
|
The lp855x chip id.
|
||||||
Value : lp8550/lp8551/lp8552/lp8553/lp8556
|
Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
|
||||||
|
|
||||||
Platform data for lp855x
|
Platform data for lp855x
|
||||||
------------------------
|
------------------------
|
||||||
|
@@ -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
|
performace although this can cause the latency of some I/O to increase due
|
||||||
to more number of requests.
|
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
|
CFQ IOPS Mode for group scheduling
|
||||||
===================================
|
===================================
|
||||||
Basic CFQ design is to provide priority based time slices. Higher priority
|
Basic CFQ design is to provide priority based time slices. Higher priority
|
||||||
|
@@ -4,43 +4,13 @@
|
|||||||
can use a remote server as one of its block devices. So every time
|
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
|
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.
|
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 -
|
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.
|
to borrow disk space from another computer.
|
||||||
Unlike NFS, it is possible to put any filesystem on it, etc. It should
|
Unlike NFS, it is possible to put any filesystem on it, etc.
|
||||||
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.
|
|
||||||
|
|
||||||
For more information, or to download the nbd-client and nbd-server
|
For more information, or to download the nbd-client and nbd-server
|
||||||
tools, go to http://nbd.sf.net/.
|
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
|
The nbd kernel module need only be installed on the client
|
||||||
system, as the nbd-server is completely in userspace. In fact,
|
system, as the nbd-server is completely in userspace. In fact,
|
||||||
the nbd-server has been successfully ported to other operating
|
the nbd-server has been successfully ported to other operating
|
||||||
|
@@ -4,8 +4,6 @@ blkio-controller.txt
|
|||||||
- Description for Block IO Controller, implementation and usage details.
|
- Description for Block IO Controller, implementation and usage details.
|
||||||
cgroups.txt
|
cgroups.txt
|
||||||
- Control Groups definition, implementation details, examples and API.
|
- Control Groups definition, implementation details, examples and API.
|
||||||
cgroup_event_listener.c
|
|
||||||
- A user program for cgroup listener.
|
|
||||||
cpuacct.txt
|
cpuacct.txt
|
||||||
- CPU Accounting Controller; account CPU usage for groups of tasks.
|
- CPU Accounting Controller; account CPU usage for groups of tasks.
|
||||||
cpusets.txt
|
cpusets.txt
|
||||||
|
@@ -75,7 +75,7 @@ Throttling/Upper Limit policy
|
|||||||
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
|
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
|
||||||
|
|
||||||
- Specify a bandwidth rate on particular device for root group. The format
|
- 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
|
echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
|
||||||
|
|
||||||
@@ -94,13 +94,11 @@ Throttling/Upper Limit policy
|
|||||||
|
|
||||||
Hierarchical Cgroups
|
Hierarchical Cgroups
|
||||||
====================
|
====================
|
||||||
- Currently none of the IO control policy supports hierarchical groups. But
|
- Currently only CFQ supports hierarchical groups. For throttling,
|
||||||
cgroup interface does allow creation of hierarchical cgroups and internally
|
cgroup interface does allow creation of hierarchical cgroups and
|
||||||
IO policies treat them as flat hierarchy.
|
internally it treats them as flat hierarchy.
|
||||||
|
|
||||||
So this patch will allow creation of cgroup hierarchcy but at the backend
|
If somebody created a hierarchy like as follows.
|
||||||
everything will be treated as flat. So if somebody created a hierarchy like
|
|
||||||
as follows.
|
|
||||||
|
|
||||||
root
|
root
|
||||||
/ \
|
/ \
|
||||||
@@ -108,16 +106,20 @@ Hierarchical Cgroups
|
|||||||
|
|
|
|
||||||
test3
|
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
|
pivot
|
||||||
/ / \ \
|
/ / \ \
|
||||||
root test1 test2 test3
|
root test1 test2 test3
|
||||||
|
|
||||||
Down the line we can implement hierarchical accounting/control support
|
Nesting cgroups, while allowed, isn't officially supported and blkio
|
||||||
and also introduce a new cgroup file "use_hierarchy" which will control
|
genereates warning when cgroups nest. Once throttling implements
|
||||||
whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
|
hierarchy support, hierarchy will be supported and the warning will
|
||||||
This is how memory controller also has implemented the things.
|
be removed.
|
||||||
|
|
||||||
Various user visible config options
|
Various user visible config options
|
||||||
===================================
|
===================================
|
||||||
@@ -172,6 +174,12 @@ Proportional weight policy files
|
|||||||
dev weight
|
dev weight
|
||||||
8:16 300
|
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
|
- blkio.time
|
||||||
- disk time allocated to cgroup per device in milliseconds. First
|
- disk time allocated to cgroup per device in milliseconds. First
|
||||||
two fields specify the major and minor number of the device and
|
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
|
and minor number of the device and third field specifies the number
|
||||||
of times a group was dequeued from a particular device.
|
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
|
Throttling/Upper limit policy files
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
- blkio.throttle.read_bps_device
|
- blkio.throttle.read_bps_device
|
||||||
|
@@ -399,8 +399,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||||||
|
|
||||||
9.10 Memory thresholds
|
9.10 Memory thresholds
|
||||||
Memory controller implements memory thresholds using cgroups notification
|
Memory controller implements memory thresholds using cgroups notification
|
||||||
API. You can use Documentation/cgroups/cgroup_event_listener.c to test
|
API. You can use tools/cgroup/cgroup_event_listener.c to test it.
|
||||||
it.
|
|
||||||
|
|
||||||
(Shell-A) Create cgroup and run event listener
|
(Shell-A) Create cgroup and run event listener
|
||||||
# mkdir /cgroup/A
|
# mkdir /cgroup/A
|
||||||
|
@@ -87,6 +87,10 @@ As any static code analyzer, Coccinelle produces false
|
|||||||
positives. Thus, reports must be carefully checked, and patches
|
positives. Thus, reports must be carefully checked, and patches
|
||||||
reviewed.
|
reviewed.
|
||||||
|
|
||||||
|
To enable verbose messages set the V= variable, for example:
|
||||||
|
|
||||||
|
make coccicheck MODE=report V=1
|
||||||
|
|
||||||
|
|
||||||
Using Coccinelle with a single semantic patch
|
Using Coccinelle with a single semantic patch
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
@@ -111,6 +111,12 @@ policy->governor must contain the "default policy" for
|
|||||||
For setting some of these values, the frequency table helpers might be
|
For setting some of these values, the frequency table helpers might be
|
||||||
helpful. See the section 2 for more information on them.
|
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
|
1.3 verify
|
||||||
------------
|
------------
|
||||||
|
@@ -190,11 +190,11 @@ scaling_max_freq show the current "policy limits" (in
|
|||||||
first set scaling_max_freq, then
|
first set scaling_max_freq, then
|
||||||
scaling_min_freq.
|
scaling_min_freq.
|
||||||
|
|
||||||
affected_cpus : List of CPUs that require software coordination
|
affected_cpus : List of Online CPUs that require software
|
||||||
of frequency.
|
coordination of frequency.
|
||||||
|
|
||||||
related_cpus : List of CPUs that need some sort of frequency
|
related_cpus : List of Online + Offline CPUs that need software
|
||||||
coordination, whether software or hardware.
|
coordination of frequency.
|
||||||
|
|
||||||
scaling_driver : Hardware driver for cpufreq.
|
scaling_driver : Hardware driver for cpufreq.
|
||||||
|
|
||||||
|
77
Documentation/device-mapper/cache-policies.txt
Normal file
77
Documentation/device-mapper/cache-policies.txt
Normal 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
243
Documentation/device-mapper/cache.txt
Normal 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'
|
@@ -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 Various RAID10 inspired algorithms chosen by additional params
|
||||||
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
|
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
|
||||||
- RAID1E: Integrated Adjacent Stripe Mirroring
|
- RAID1E: Integrated Adjacent Stripe Mirroring
|
||||||
|
- RAID1E: Integrated Offset Stripe Mirroring
|
||||||
- and other similar RAID10 variants
|
- and other similar RAID10 variants
|
||||||
|
|
||||||
Reference: Chapter 4 of
|
Reference: Chapter 4 of
|
||||||
@@ -64,15 +65,15 @@ The target is named "raid" and it accepts the following parameters:
|
|||||||
synchronisation state for each region.
|
synchronisation state for each region.
|
||||||
|
|
||||||
[raid10_copies <# copies>]
|
[raid10_copies <# copies>]
|
||||||
[raid10_format near]
|
[raid10_format <near|far|offset>]
|
||||||
These two options are used to alter the default layout of
|
These two options are used to alter the default layout of
|
||||||
a RAID10 configuration. The number of copies is can be
|
a RAID10 configuration. The number of copies is can be
|
||||||
specified, but the default is 2. There are other variations
|
specified, but the default is 2. There are also three
|
||||||
to how the copies are laid down - the default and only current
|
variations to how the copies are laid down - the default
|
||||||
option is "near". Near copies are what most people think of
|
is "near". Near copies are what most people think of with
|
||||||
with respect to mirroring. If these options are left
|
respect to mirroring. If these options are left unspecified,
|
||||||
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
|
or 'raid10_copies 2' and/or 'raid10_format near' are given,
|
||||||
are given, then the layouts for 2, 3 and 4 devices are:
|
then the layouts for 2, 3 and 4 devices are:
|
||||||
2 drives 3 drives 4 drives
|
2 drives 3 drives 4 drives
|
||||||
-------- ---------- --------------
|
-------- ---------- --------------
|
||||||
A1 A1 A1 A1 A2 A1 A1 A2 A2
|
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
|
3-device layout is what might be called a 'RAID1E - Integrated
|
||||||
Adjacent Stripe Mirroring'.
|
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.
|
<#raid_devs>: The number of devices composing the array.
|
||||||
Each device consists of two entries. The first is the device
|
Each device consists of two entries. The first is the device
|
||||||
containing the metadata (if any); the second is the one containing the
|
containing the metadata (if any); the second is the one containing the
|
||||||
@@ -142,3 +170,5 @@ Version History
|
|||||||
1.3.0 Added support for RAID 10
|
1.3.0 Added support for RAID 10
|
||||||
1.3.1 Allow device replacement/rebuild for RAID 10
|
1.3.1 Allow device replacement/rebuild for RAID 10
|
||||||
1.3.2 Fix/improve redundancy checking for RAID10
|
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
24
Documentation/devicetree/bindings/arc/interrupts.txt
Normal 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>;
|
||||||
|
};
|
@@ -3,9 +3,11 @@ Altera SOCFPGA System Manager
|
|||||||
Required properties:
|
Required properties:
|
||||||
- compatible : "altr,sys-mgr"
|
- compatible : "altr,sys-mgr"
|
||||||
- reg : Should contain 1 register ranges(address and length)
|
- reg : Should contain 1 register ranges(address and length)
|
||||||
|
- cpu1-start-addr : CPU1 start address in hex.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
sysmgr@ffd08000 {
|
sysmgr@ffd08000 {
|
||||||
compatible = "altr,sys-mgr";
|
compatible = "altr,sys-mgr";
|
||||||
reg = <0xffd08000 0x1000>;
|
reg = <0xffd08000 0x1000>;
|
||||||
|
cpu1-start-addr = <0xffd080c4>;
|
||||||
};
|
};
|
||||||
|
@@ -1,13 +1,14 @@
|
|||||||
* ARM architected timer
|
* ARM architected timer
|
||||||
|
|
||||||
ARM Cortex-A7 and Cortex-A15 have a per-core architected timer, which
|
ARM cores may have a per-core architected timer, which provides per-cpu timers.
|
||||||
provides per-cpu timers.
|
|
||||||
|
|
||||||
The timer is attached to a GIC to deliver its per-processor interrupts.
|
The timer is attached to a GIC to deliver its per-processor interrupts.
|
||||||
|
|
||||||
** Timer node properties:
|
** 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
|
- interrupts : Interrupt list for secure, non-secure, virtual and
|
||||||
hypervisor timers, in that order.
|
hypervisor timers, in that order.
|
||||||
|
6
Documentation/devicetree/bindings/arm/armadeus.txt
Normal file
6
Documentation/devicetree/bindings/arm/armadeus.txt
Normal 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";
|
@@ -4,7 +4,7 @@ Required properties:
|
|||||||
- compatible: Should be "atmel,<chip>-aic"
|
- compatible: Should be "atmel,<chip>-aic"
|
||||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||||
- interrupt-parent: For single AIC system, it is an empty property.
|
- 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 first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
|
||||||
The second cell is used to specify flags:
|
The second cell is used to specify flags:
|
||||||
bits[3:0] trigger type and level flags:
|
bits[3:0] trigger type and level flags:
|
||||||
|
@@ -5,6 +5,14 @@ i.MX23 Evaluation Kit
|
|||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "fsl,imx23-evk", "fsl,imx23";
|
- 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
|
i.MX28 Evaluation Kit
|
||||||
Required root node properties:
|
Required root node properties:
|
||||||
- compatible = "fsl,imx28-evk", "fsl,imx28";
|
- compatible = "fsl,imx28-evk", "fsl,imx28";
|
||||||
|
@@ -42,7 +42,7 @@ Main node required properties:
|
|||||||
|
|
||||||
Optional
|
Optional
|
||||||
- interrupts : Interrupt source of the parent interrupt controller on
|
- 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).
|
below).
|
||||||
|
|
||||||
- cpu-offset : per-cpu offset within the distributor and cpu interface
|
- 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
|
virtual interface control register base and size. The 2nd additional
|
||||||
region is the GIC virtual cpu interface register base and size.
|
region is the GIC virtual cpu interface register base and size.
|
||||||
|
|
||||||
- interrupts : VGIC maintainance interrupt.
|
- interrupts : VGIC maintenance interrupt.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
|
27
Documentation/devicetree/bindings/arm/kirkwood.txt
Normal file
27
Documentation/devicetree/bindings/arm/kirkwood.txt
Normal 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";
|
||||||
|
};
|
@@ -39,16 +39,16 @@ Boards:
|
|||||||
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
|
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
|
||||||
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
|
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"
|
compatible = "ti,omap4-sdp", "ti,omap4430"
|
||||||
|
|
||||||
- OMAP4 PandaBoard : Low cost community board
|
- OMAP4 PandaBoard : Low cost community board
|
||||||
compatible = "ti,omap4-panda", "ti,omap4430"
|
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"
|
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"
|
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
|
||||||
|
|
||||||
- AM335X Bone : Low cost community board
|
- AM335X Bone : Low cost community board
|
||||||
|
55
Documentation/devicetree/bindings/arm/psci.txt
Normal file
55
Documentation/devicetree/bindings/arm/psci.txt
Normal 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>;
|
||||||
|
};
|
@@ -1,3 +1,9 @@
|
|||||||
prima2 "cb" evaluation board
|
CSR SiRFprimaII and SiRFmarco device tree bindings.
|
||||||
|
========================================
|
||||||
|
|
||||||
Required root node properties:
|
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
27
Documentation/devicetree/bindings/arm/ste-nomadik.txt
Normal 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>;
|
||||||
|
};
|
||||||
|
};
|
@@ -1,14 +1,34 @@
|
|||||||
NVIDIA Tegra device tree bindings
|
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
|
||||||
|
@@ -12,3 +12,11 @@ compatible = "wm,wm8505";
|
|||||||
Boards with the Wondermedia WM8650 SoC shall have the following properties:
|
Boards with the Wondermedia WM8650 SoC shall have the following properties:
|
||||||
Required root node property:
|
Required root node property:
|
||||||
compatible = "wm,wm8650";
|
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
84
Documentation/devicetree/bindings/bus/ti-gpmc.txt
Normal file
@@ -0,0 +1,84 @@
|
|||||||
|
Device tree bindings for OMAP general purpose memory controllers (GPMC)
|
||||||
|
|
||||||
|
The actual devices are instantiated from the child nodes of a GPMC node.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
|
||||||
|
- compatible: Should be set to one of the following:
|
||||||
|
|
||||||
|
ti,omap2420-gpmc (omap2420)
|
||||||
|
ti,omap2430-gpmc (omap2430)
|
||||||
|
ti,omap3430-gpmc (omap3430 & omap3630)
|
||||||
|
ti,omap4430-gpmc (omap4430 & omap4460 & omap543x)
|
||||||
|
ti,am3352-gpmc (am335x devices)
|
||||||
|
|
||||||
|
- reg: A resource specifier for the register space
|
||||||
|
(see the example below)
|
||||||
|
- ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
|
||||||
|
completed.
|
||||||
|
- #address-cells: Must be set to 2 to allow memory address translation
|
||||||
|
- #size-cells: Must be set to 1 to allow CS address passing
|
||||||
|
- gpmc,num-cs: The maximum number of chip-select lines that controller
|
||||||
|
can support.
|
||||||
|
- gpmc,num-waitpins: The maximum number of wait pins that controller can
|
||||||
|
support.
|
||||||
|
- ranges: Must be set up to reflect the memory layout with four
|
||||||
|
integer values for each chip-select line in use:
|
||||||
|
|
||||||
|
<cs-number> 0 <physical address of mapping> <size>
|
||||||
|
|
||||||
|
Currently, calculated values derived from the contents
|
||||||
|
of the per-CS register GPMC_CONFIG7 (as set up by the
|
||||||
|
bootloader) are used for the physical address decoding.
|
||||||
|
As this will change in the future, filling correct
|
||||||
|
values here is a requirement.
|
||||||
|
|
||||||
|
Timing properties for child nodes. All are optional and default to 0.
|
||||||
|
|
||||||
|
- gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
|
||||||
|
|
||||||
|
Chip-select signal timings corresponding to GPMC_CONFIG2:
|
||||||
|
- gpmc,cs-on: Assertion time
|
||||||
|
- gpmc,cs-rd-off: Read deassertion time
|
||||||
|
- gpmc,cs-wr-off: Write deassertion time
|
||||||
|
|
||||||
|
ADV signal timings corresponding to GPMC_CONFIG3:
|
||||||
|
- gpmc,adv-on: Assertion time
|
||||||
|
- gpmc,adv-rd-off: Read deassertion time
|
||||||
|
- gpmc,adv-wr-off: Write deassertion time
|
||||||
|
|
||||||
|
WE signals timings corresponding to GPMC_CONFIG4:
|
||||||
|
- gpmc,we-on: Assertion time
|
||||||
|
- gpmc,we-off: Deassertion time
|
||||||
|
|
||||||
|
OE signals timings corresponding to GPMC_CONFIG4:
|
||||||
|
- gpmc,oe-on: Assertion time
|
||||||
|
- gpmc,oe-off: Deassertion time
|
||||||
|
|
||||||
|
Access time and cycle time timings corresponding to GPMC_CONFIG5:
|
||||||
|
- gpmc,page-burst-access: Multiple access word delay
|
||||||
|
- gpmc,access: Start-cycle to first data valid delay
|
||||||
|
- gpmc,rd-cycle: Total read cycle time
|
||||||
|
- gpmc,wr-cycle: Total write cycle time
|
||||||
|
|
||||||
|
The following are only applicable to OMAP3+ and AM335x:
|
||||||
|
- gpmc,wr-access
|
||||||
|
- gpmc,wr-data-mux-bus
|
||||||
|
|
||||||
|
|
||||||
|
Example for an AM33xx board:
|
||||||
|
|
||||||
|
gpmc: gpmc@50000000 {
|
||||||
|
compatible = "ti,am3352-gpmc";
|
||||||
|
ti,hwmods = "gpmc";
|
||||||
|
reg = <0x50000000 0x2000>;
|
||||||
|
interrupts = <100>;
|
||||||
|
|
||||||
|
gpmc,num-cs = <8>;
|
||||||
|
gpmc,num-waitpins = <2>;
|
||||||
|
#address-cells = <2>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
|
||||||
|
|
||||||
|
/* child nodes go here */
|
||||||
|
};
|
91
Documentation/devicetree/bindings/clock/imx31-clock.txt
Normal file
91
Documentation/devicetree/bindings/clock/imx31-clock.txt
Normal 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";
|
||||||
|
};
|
@@ -171,6 +171,7 @@ clocks and IDs.
|
|||||||
can_sel 156
|
can_sel 156
|
||||||
can1_serial_gate 157
|
can1_serial_gate 157
|
||||||
can1_ipg_gate 158
|
can1_ipg_gate 158
|
||||||
|
owire_gate 159
|
||||||
|
|
||||||
Examples (for mx53):
|
Examples (for mx53):
|
||||||
|
|
||||||
|
@@ -203,6 +203,8 @@ clocks and IDs.
|
|||||||
pcie_ref 188
|
pcie_ref 188
|
||||||
pcie_ref_125m 189
|
pcie_ref_125m 189
|
||||||
enet_ref 190
|
enet_ref 190
|
||||||
|
usbphy1_gate 191
|
||||||
|
usbphy2_gate 192
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
|
||||||
|
@@ -89,7 +89,7 @@ ID Clock Peripheral
|
|||||||
16 xor1 XOR DMA 1
|
16 xor1 XOR DMA 1
|
||||||
17 crypto CESA engine
|
17 crypto CESA engine
|
||||||
18 pex1 PCIe Cntrl 1
|
18 pex1 PCIe Cntrl 1
|
||||||
19 ge1 Gigabit Ethernet 0
|
19 ge1 Gigabit Ethernet 1
|
||||||
20 tdm Time Division Mplx
|
20 tdm Time Division Mplx
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
|
205
Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
Normal file
205
Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
Normal 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
262
Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
Normal 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
73
Documentation/devicetree/bindings/clock/prima2-clock.txt
Normal 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>;
|
||||||
|
};
|
@@ -54,8 +54,13 @@ PROPERTIES
|
|||||||
- compatible
|
- compatible
|
||||||
Usage: required
|
Usage: required
|
||||||
Value type: <string>
|
Value type: <string>
|
||||||
Definition: Must include "fsl,sec-v4.0". Also includes SEC
|
Definition: Must include "fsl,sec-v4.0"
|
||||||
ERA versions (optional) with which the device is compatible.
|
|
||||||
|
- fsl,sec-era
|
||||||
|
Usage: optional
|
||||||
|
Value type: <u32>
|
||||||
|
Definition: A standard property. Define the 'ERA' of the SEC
|
||||||
|
device.
|
||||||
|
|
||||||
- #address-cells
|
- #address-cells
|
||||||
Usage: required
|
Usage: required
|
||||||
@@ -107,7 +112,8 @@ PROPERTIES
|
|||||||
|
|
||||||
EXAMPLE
|
EXAMPLE
|
||||||
crypto@300000 {
|
crypto@300000 {
|
||||||
compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
|
compatible = "fsl,sec-v4.0";
|
||||||
|
fsl,sec-era = <2>;
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <1>;
|
#size-cells = <1>;
|
||||||
reg = <0x300000 0x10000>;
|
reg = <0x300000 0x10000>;
|
||||||
|
@@ -10,7 +10,11 @@ Required properties:
|
|||||||
- interrupts: interrupt number to the cpu.
|
- interrupts: interrupt number to the cpu.
|
||||||
|
|
||||||
Optional properties:
|
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:
|
Example:
|
||||||
|
|
||||||
@@ -18,16 +22,23 @@ Example:
|
|||||||
compatible = "arm,pl330", "arm,primecell";
|
compatible = "arm,pl330", "arm,primecell";
|
||||||
reg = <0x12680000 0x1000>;
|
reg = <0x12680000 0x1000>;
|
||||||
interrupts = <99>;
|
interrupts = <99>;
|
||||||
|
#dma-cells = <1>;
|
||||||
|
#dma-channels = <8>;
|
||||||
|
#dma-requests = <32>;
|
||||||
};
|
};
|
||||||
|
|
||||||
Client drivers (device nodes requiring dma transfers from dev-to-mem or
|
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.
|
as shown below.
|
||||||
|
|
||||||
[property name] = <[phandle of the dma controller] [dma request id]>;
|
[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
|
where 'dma request id' is the dma request number which is connected
|
||||||
to the client controller. The 'property name' is recommended to be
|
to the client controller. The 'property name' 'dmas' and 'dma-names'
|
||||||
of the form <name>-dma-channel.
|
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
81
Documentation/devicetree/bindings/dma/dma.txt
Normal 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";
|
@@ -3,15 +3,61 @@
|
|||||||
Required properties:
|
Required properties:
|
||||||
- compatible: "snps,dma-spear1340"
|
- compatible: "snps,dma-spear1340"
|
||||||
- reg: Address range of the DMAC registers
|
- 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
|
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||||
that services interrupts for this device
|
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:
|
Example:
|
||||||
|
|
||||||
dma@fc000000 {
|
dmahost: dma@fc000000 {
|
||||||
compatible = "snps,dma-spear1340";
|
compatible = "snps,dma-spear1340";
|
||||||
reg = <0xfc000000 0x1000>;
|
reg = <0xfc000000 0x1000>;
|
||||||
interrupt-parent = <&vic1>;
|
interrupt-parent = <&vic1>;
|
||||||
interrupts = <12>;
|
interrupts = <12>;
|
||||||
|
|
||||||
|
dma-channels = <8>;
|
||||||
|
dma-requests = <16>;
|
||||||
|
dma-masters = <2>;
|
||||||
|
#dma-cells = <3>;
|
||||||
|
chan_allocation_order = <1>;
|
||||||
|
chan_priority = <1>;
|
||||||
|
block_size = <0xfff>;
|
||||||
|
data_width = <3 3 0 0>;
|
||||||
|
};
|
||||||
|
|
||||||
|
DMA clients connected to the Designware DMA controller must use the format
|
||||||
|
described in the dma.txt file, using a four-cell specifier for each channel.
|
||||||
|
The four cells in order are:
|
||||||
|
|
||||||
|
1. A phandle pointing to the DMA controller
|
||||||
|
2. The DMA request line number
|
||||||
|
3. Source master for transfers on allocated channel
|
||||||
|
4. Destination master for transfers on allocated channel
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
serial@e0000000 {
|
||||||
|
compatible = "arm,pl011", "arm,primecell";
|
||||||
|
reg = <0xe0000000 0x1000>;
|
||||||
|
interrupts = <0 35 0x4>;
|
||||||
|
status = "disabled";
|
||||||
|
dmas = <&dmahost 12 0 1>,
|
||||||
|
<&dmahost 13 0 1 0>;
|
||||||
|
dma-names = "rx", "rx";
|
||||||
};
|
};
|
||||||
|
22
Documentation/devicetree/bindings/drm/exynos/g2d.txt
Normal file
22
Documentation/devicetree/bindings/drm/exynos/g2d.txt
Normal file
@@ -0,0 +1,22 @@
|
|||||||
|
Samsung 2D Graphic Accelerator using DRM frame work
|
||||||
|
|
||||||
|
Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
|
||||||
|
We set the drawing-context registers for configuring rendering parameters and
|
||||||
|
then start rendering.
|
||||||
|
This driver is for SOCs which contain G2D IPs with version 4.1.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
-compatible:
|
||||||
|
should be "samsung,exynos-g2d-41".
|
||||||
|
-reg:
|
||||||
|
physical base address of the controller and length
|
||||||
|
of memory mapped region.
|
||||||
|
-interrupts:
|
||||||
|
interrupt combiner values.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
g2d {
|
||||||
|
compatible = "samsung,exynos-g2d-41";
|
||||||
|
reg = <0x10850000 0x1000>;
|
||||||
|
interrupts = <0 91 0>;
|
||||||
|
};
|
59
Documentation/devicetree/bindings/drm/tilcdc/panel.txt
Normal file
59
Documentation/devicetree/bindings/drm/tilcdc/panel.txt
Normal file
@@ -0,0 +1,59 @@
|
|||||||
|
Device-Tree bindings for tilcdc DRM generic panel output driver
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: value should be "ti,tilcdc,panel".
|
||||||
|
- panel-info: configuration info to configure LCDC correctly for the panel
|
||||||
|
- ac-bias: AC Bias Pin Frequency
|
||||||
|
- ac-bias-intrpt: AC Bias Pin Transitions per Interrupt
|
||||||
|
- dma-burst-sz: DMA burst size
|
||||||
|
- bpp: Bits per pixel
|
||||||
|
- fdd: FIFO DMA Request Delay
|
||||||
|
- sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling
|
||||||
|
- sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore
|
||||||
|
- raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most
|
||||||
|
- fifo-th: DMA FIFO threshold
|
||||||
|
- display-timings: typical videomode of lcd panel. Multiple video modes
|
||||||
|
can be listed if the panel supports multiple timings, but the 'native-mode'
|
||||||
|
should be the preferred/default resolution. Refer to
|
||||||
|
Documentation/devicetree/bindings/video/display-timing.txt for display
|
||||||
|
timing binding details.
|
||||||
|
|
||||||
|
Recommended properties:
|
||||||
|
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
|
||||||
|
muxing properly for pins that connect to TFP410 device
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
/* Settings for CDTech_S035Q01 / LCD3 cape: */
|
||||||
|
lcd3 {
|
||||||
|
compatible = "ti,tilcdc,panel";
|
||||||
|
pinctrl-names = "default";
|
||||||
|
pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
|
||||||
|
panel-info {
|
||||||
|
ac-bias = <255>;
|
||||||
|
ac-bias-intrpt = <0>;
|
||||||
|
dma-burst-sz = <16>;
|
||||||
|
bpp = <16>;
|
||||||
|
fdd = <0x80>;
|
||||||
|
sync-edge = <0>;
|
||||||
|
sync-ctrl = <1>;
|
||||||
|
raster-order = <0>;
|
||||||
|
fifo-th = <0>;
|
||||||
|
};
|
||||||
|
display-timings {
|
||||||
|
native-mode = <&timing0>;
|
||||||
|
timing0: 320x240 {
|
||||||
|
hactive = <320>;
|
||||||
|
vactive = <240>;
|
||||||
|
hback-porch = <21>;
|
||||||
|
hfront-porch = <58>;
|
||||||
|
hsync-len = <47>;
|
||||||
|
vback-porch = <11>;
|
||||||
|
vfront-porch = <23>;
|
||||||
|
vsync-len = <2>;
|
||||||
|
clock-frequency = <8000000>;
|
||||||
|
hsync-active = <0>;
|
||||||
|
vsync-active = <0>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
18
Documentation/devicetree/bindings/drm/tilcdc/slave.txt
Normal file
18
Documentation/devicetree/bindings/drm/tilcdc/slave.txt
Normal file
@@ -0,0 +1,18 @@
|
|||||||
|
Device-Tree bindings for tilcdc DRM encoder slave output driver
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: value should be "ti,tilcdc,slave".
|
||||||
|
- i2c: the phandle for the i2c device the encoder slave is connected to
|
||||||
|
|
||||||
|
Recommended properties:
|
||||||
|
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
|
||||||
|
muxing properly for pins that connect to TFP410 device
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
hdmi {
|
||||||
|
compatible = "ti,tilcdc,slave";
|
||||||
|
i2c = <&i2c0>;
|
||||||
|
pinctrl-names = "default";
|
||||||
|
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
|
||||||
|
};
|
21
Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
Normal file
21
Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
Normal file
@@ -0,0 +1,21 @@
|
|||||||
|
Device-Tree bindings for tilcdc DRM TFP410 output driver
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: value should be "ti,tilcdc,tfp410".
|
||||||
|
- i2c: the phandle for the i2c device to use for DDC
|
||||||
|
|
||||||
|
Recommended properties:
|
||||||
|
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
|
||||||
|
muxing properly for pins that connect to TFP410 device
|
||||||
|
- powerdn-gpio: the powerdown GPIO, pulled low to power down the
|
||||||
|
TFP410 device (for DPMS_OFF)
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
dvicape {
|
||||||
|
compatible = "ti,tilcdc,tfp410";
|
||||||
|
i2c = <&i2c2>;
|
||||||
|
pinctrl-names = "default";
|
||||||
|
pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>;
|
||||||
|
powerdn-gpio = <&gpio2 31 0>;
|
||||||
|
};
|
21
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
Normal file
21
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
Normal file
@@ -0,0 +1,21 @@
|
|||||||
|
Device-Tree bindings for tilcdc DRM driver
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: value should be "ti,am33xx-tilcdc".
|
||||||
|
- interrupts: the interrupt number
|
||||||
|
- reg: base address and size of the LCDC device
|
||||||
|
|
||||||
|
Recommended properties:
|
||||||
|
- interrupt-parent: the phandle for the interrupt controller that
|
||||||
|
services interrupts for this device.
|
||||||
|
- ti,hwmods: Name of the hwmod associated to the LCDC
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
fb: fb@4830e000 {
|
||||||
|
compatible = "ti,am33xx-tilcdc";
|
||||||
|
reg = <0x4830e000 0x1000>;
|
||||||
|
interrupt-parent = <&intc>;
|
||||||
|
interrupts = <36>;
|
||||||
|
ti,hwmods = "lcdc";
|
||||||
|
};
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user