Merge remote-tracking branch 'efi/chainsaw' into x86/efi
Resolved Conflicts: drivers/firmware/efivars.c fs/efivarsfs/file.c Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>hifive-unleashed-5.1
H. Peter Anvin
commit
f53f292eea
22
CREDITS
22
CREDITS
|
|
@ -953,11 +953,11 @@ S: Blacksburg, Virginia 24061
|
|||
S: USA
|
||||
|
||||
N: Randy Dunlap
|
||||
E: rdunlap@xenotime.net
|
||||
W: http://www.xenotime.net/linux/linux.html
|
||||
W: http://www.linux-usb.org
|
||||
E: rdunlap@infradead.org
|
||||
W: http://www.infradead.org/~rdunlap/
|
||||
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
|
||||
D: x86 SMP, ACPI, bootflag hacking
|
||||
D: documentation, builds
|
||||
S: (ask for current address)
|
||||
S: USA
|
||||
|
||||
|
|
@ -1510,6 +1510,14 @@ D: Natsemi ethernet
|
|||
D: Cobalt Networks (x86) support
|
||||
D: This-and-That
|
||||
|
||||
N: Mark M. Hoffman
|
||||
E: mhoffman@lightlink.com
|
||||
D: asb100, lm93 and smsc47b397 hardware monitoring drivers
|
||||
D: hwmon subsystem core
|
||||
D: hwmon subsystem maintainer
|
||||
D: i2c-sis96x and i2c-stub SMBus drivers
|
||||
S: USA
|
||||
|
||||
N: Dirk Hohndel
|
||||
E: hohndel@suse.de
|
||||
D: The XFree86[tm] Project
|
||||
|
|
@ -1572,12 +1580,12 @@ S: Wantage, New Jersey 07461
|
|||
S: USA
|
||||
|
||||
N: Harald Hoyer
|
||||
E: harald.hoyer@parzelle.de
|
||||
W: http://parzelle.de/
|
||||
E: harald@redhat.com
|
||||
W: http://www.harald-hoyer.de
|
||||
D: ip_masq_quake
|
||||
D: md boot support
|
||||
S: Hohe Strasse 30
|
||||
S: D-70176 Stuttgart
|
||||
S: Am Strand 5
|
||||
S: D-19063 Schwerin
|
||||
S: Germany
|
||||
|
||||
N: Jan Hubicka
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
This is a brief list of all the files in ./linux/Documentation and what
|
||||
they contain. If you add a documentation file, please list it here in
|
||||
alphabetical order as well, or risk being hunted down like a rabid dog.
|
||||
Please try and keep the descriptions small enough to fit on one line.
|
||||
Please keep the descriptions small enough to fit on one line.
|
||||
Thanks -- Paul G.
|
||||
|
||||
Following translations are available on the WWW:
|
||||
|
|
@ -20,24 +20,33 @@ BUG-HUNTING
|
|||
Changes
|
||||
- list of changes that break older software packages.
|
||||
CodingStyle
|
||||
- how the boss likes the C code in the kernel to look.
|
||||
development-process/
|
||||
- An extended tutorial on how to work with the kernel development
|
||||
process.
|
||||
- how the maintainers expect the C code in the kernel to look.
|
||||
DMA-API.txt
|
||||
- DMA API, pci_ API & extensions for non-consistent memory machines.
|
||||
DMA-API-HOWTO.txt
|
||||
- Dynamic DMA mapping Guide
|
||||
DMA-ISA-LPC.txt
|
||||
- How to do DMA with ISA (and LPC) devices.
|
||||
DMA-attributes.txt
|
||||
- listing of the various possible attributes a DMA region can have
|
||||
DocBook/
|
||||
- directory with DocBook templates etc. for kernel documentation.
|
||||
EDID/
|
||||
- directory with info on customizing EDID for broken gfx/displays.
|
||||
HOWTO
|
||||
- the process and procedures of how to do Linux kernel development.
|
||||
IPMI.txt
|
||||
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
|
||||
IRQ-affinity.txt
|
||||
- how to select which CPU(s) handle which interrupt events on SMP.
|
||||
IRQ-domain.txt
|
||||
- info on inerrupt numbering and setting up IRQ domains.
|
||||
IRQ.txt
|
||||
- description of what an IRQ is.
|
||||
Intel-IOMMU.txt
|
||||
- basic info on the Intel IOMMU virtualization support.
|
||||
Makefile
|
||||
- some files in Documentation dir are actually sample code to build
|
||||
ManagementStyle
|
||||
- how to (attempt to) manage kernel hackers.
|
||||
RCU/
|
||||
|
|
@ -66,10 +75,16 @@ applying-patches.txt
|
|||
- description of various trees and how to apply their patches.
|
||||
arm/
|
||||
- directory with info about Linux on the ARM architecture.
|
||||
arm64/
|
||||
- directory with info about Linux on the 64 bit ARM architecture.
|
||||
atomic_ops.txt
|
||||
- semantics and behavior of atomic and bitmask operations.
|
||||
auxdisplay/
|
||||
- misc. LCD driver documentation (cfag12864b, ks0108).
|
||||
backlight/
|
||||
- directory with info on controlling backlights in flat panel displays
|
||||
bad_memory.txt
|
||||
- how to use kernel parameters to exclude bad RAM regions.
|
||||
basic_profiling.txt
|
||||
- basic instructions for those who wants to profile Linux kernel.
|
||||
binfmt_misc.txt
|
||||
|
|
@ -80,8 +95,14 @@ block/
|
|||
- info on the Block I/O (BIO) layer.
|
||||
blockdev/
|
||||
- info on block devices & drivers
|
||||
braille-console.txt
|
||||
- info on how to use serial devices for Braille support.
|
||||
bt8xxgpio.txt
|
||||
- info on how to modify a bt8xx video card for GPIO usage.
|
||||
btmrvl.txt
|
||||
- info on Marvell Bluetooth driver usage.
|
||||
bus-devices/
|
||||
- directory with info on TI GPMC (General Purpose Memory Controller)
|
||||
bus-virt-phys-mapping.txt
|
||||
- how to access I/O mapped memory from within device drivers.
|
||||
cachetlb.txt
|
||||
|
|
@ -90,6 +111,12 @@ cdrom/
|
|||
- directory with information on the CD-ROM drivers that Linux has.
|
||||
cgroups/
|
||||
- cgroups features, including cpusets and memory controller.
|
||||
circular-buffers.txt
|
||||
- how to make use of the existing circular buffer infrastructure
|
||||
clk.txt
|
||||
- info on the common clock framework
|
||||
coccinelle.txt
|
||||
- info on how to get and use the Coccinelle code checking tool.
|
||||
connector/
|
||||
- docs on the netlink based userspace<->kernel space communication mod.
|
||||
console/
|
||||
|
|
@ -114,24 +141,42 @@ dcdbas.txt
|
|||
- information on the Dell Systems Management Base Driver.
|
||||
debugging-modules.txt
|
||||
- some notes on debugging modules after Linux 2.6.3.
|
||||
debugging-via-ohci1394.txt
|
||||
- how to use firewire like a hardware debugger memory reader.
|
||||
dell_rbu.txt
|
||||
- document demonstrating the use of the Dell Remote BIOS Update driver.
|
||||
development-process/
|
||||
- how to work with the mainline kernel development process.
|
||||
device-mapper/
|
||||
- directory with info on Device Mapper.
|
||||
devices.txt
|
||||
- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
|
||||
devicetree/
|
||||
- directory with info on device tree files used by OF/PowerPC/ARM
|
||||
digsig.txt
|
||||
-info on the Digital Signature Verification API
|
||||
dma-buf-sharing.txt
|
||||
- the DMA Buffer Sharing API Guide
|
||||
dmaengine.txt
|
||||
-the DMA Engine API Guide
|
||||
dontdiff
|
||||
- file containing a list of files that should never be diff'ed.
|
||||
driver-model/
|
||||
- directory with info about Linux driver model.
|
||||
dvb/
|
||||
- info on Linux Digital Video Broadcast (DVB) subsystem.
|
||||
dynamic-debug-howto.txt
|
||||
- how to use the dynamic debug (dyndbg) feature.
|
||||
early-userspace/
|
||||
- info about initramfs, klibc, and userspace early during boot.
|
||||
edac.txt
|
||||
- information on EDAC - Error Detection And Correction
|
||||
eisa.txt
|
||||
- info on EISA bus support.
|
||||
email-clients.txt
|
||||
- info on how to use e-mail to send un-mangled (git) patches.
|
||||
extcon/
|
||||
- directory with porting guide for Android kernel switch driver.
|
||||
fault-injection/
|
||||
- dir with docs about the fault injection capabilities infrastructure.
|
||||
fb/
|
||||
|
|
@ -140,12 +185,22 @@ filesystems/
|
|||
- info on the vfs and the various filesystems that Linux supports.
|
||||
firmware_class/
|
||||
- request_firmware() hotplug interface info.
|
||||
flexible-arrays.txt
|
||||
- how to make use of flexible sized arrays in linux
|
||||
frv/
|
||||
- Fujitsu FR-V Linux documentation.
|
||||
futex-requeue-pi.txt
|
||||
- info on requeueing of tasks from a non-PI futex to a PI futex
|
||||
gcov.txt
|
||||
- use of GCC's coverage testing tool "gcov" with the Linux kernel
|
||||
gpio.txt
|
||||
- overview of GPIO (General Purpose Input/Output) access conventions.
|
||||
hid/
|
||||
- directory with information on human interface devices
|
||||
highuid.txt
|
||||
- notes on the change from 16 bit to 32 bit user/group IDs.
|
||||
hwspinlock.txt
|
||||
- hardware spinlock provides hardware assistance for synchronization
|
||||
timers/
|
||||
- info on the timer related topics
|
||||
hw_random.txt
|
||||
|
|
@ -162,10 +217,14 @@ ia64/
|
|||
- directory with info about Linux on Intel 64 bit architecture.
|
||||
infiniband/
|
||||
- directory with documents concerning Linux InfiniBand support.
|
||||
init.txt
|
||||
- what to do when the kernel can't find the 1st process to run.
|
||||
initrd.txt
|
||||
- how to use the RAM disk as an initial/temporary root filesystem.
|
||||
input/
|
||||
- info on Linux input device support.
|
||||
intel_txt.txt
|
||||
- info on intel Trusted Execution Technology (intel TXT).
|
||||
io-mapping.txt
|
||||
- description of io_mapping functions in linux/io-mapping.h
|
||||
io_ordering.txt
|
||||
|
|
@ -182,6 +241,8 @@ isdn/
|
|||
- directory with info on the Linux ISDN support, and supported cards.
|
||||
java.txt
|
||||
- info on the in-kernel binary support for Java(tm).
|
||||
ja_JP/
|
||||
- directory with Japanese translations of various documents
|
||||
kbuild/
|
||||
- directory with info about the kernel build process.
|
||||
kdump/
|
||||
|
|
@ -192,6 +253,12 @@ kernel-docs.txt
|
|||
- listing of various WWW + books that document kernel internals.
|
||||
kernel-parameters.txt
|
||||
- summary listing of command line / boot prompt args for the kernel.
|
||||
kmemcheck.txt
|
||||
- info on dynamic checker that detects uses of uninitialized memory.
|
||||
kmemleak.txt
|
||||
- info on how to make use of the kernel memory leak detection system
|
||||
ko_KR/
|
||||
- directory with Korean translations of various documents
|
||||
kobject.txt
|
||||
- info of the kobject infrastructure of the Linux kernel.
|
||||
kprobes.txt
|
||||
|
|
@ -208,6 +275,8 @@ local_ops.txt
|
|||
- semantics and behavior of local atomic operations.
|
||||
lockdep-design.txt
|
||||
- documentation on the runtime locking correctness validator.
|
||||
lockstat.txt
|
||||
- info on collecting statistics on locks (and contention).
|
||||
lockup-watchdogs.txt
|
||||
- info on soft and hard lockup detectors (aka nmi_watchdog).
|
||||
logo.gif
|
||||
|
|
@ -220,16 +289,28 @@ magic-number.txt
|
|||
- list of magic numbers used to mark/protect kernel data structures.
|
||||
md.txt
|
||||
- info on boot arguments for the multiple devices driver.
|
||||
media-framework.txt
|
||||
- info on media framework, its data structures, functions and usage.
|
||||
memory-barriers.txt
|
||||
- info on Linux kernel memory barriers.
|
||||
memory-devices/
|
||||
- directory with info on parts like the Texas Instruments EMIF driver
|
||||
memory-hotplug.txt
|
||||
- Hotpluggable memory support, how to use and current status.
|
||||
memory.txt
|
||||
- info on typical Linux memory problems.
|
||||
metag/
|
||||
- directory with info about Linux on Meta architecture.
|
||||
mips/
|
||||
- directory with info about Linux on MIPS architecture.
|
||||
misc-devices/
|
||||
- directory with info about devices using the misc dev subsystem
|
||||
mmc/
|
||||
- directory with info about the MMC subsystem
|
||||
mn10300/
|
||||
- directory with info about the mn10300 architecture port
|
||||
mtd/
|
||||
- directory with info about memory technology devices (flash)
|
||||
mono.txt
|
||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||
mutex-design.txt
|
||||
|
|
@ -240,6 +321,8 @@ netlabel/
|
|||
- directory with information on the NetLabel subsystem.
|
||||
networking/
|
||||
- directory with info on various aspects of networking with Linux.
|
||||
nfc/
|
||||
- directory relating info about Near Field Communications support.
|
||||
nommu-mmap.txt
|
||||
- documentation about no-mmu memory mapping support.
|
||||
numastat.txt
|
||||
|
|
@ -256,26 +339,46 @@ parport-lowlevel.txt
|
|||
- description and usage of the low level parallel port functions.
|
||||
pcmcia/
|
||||
- info on the Linux PCMCIA driver.
|
||||
percpu-rw-semaphore.txt
|
||||
- RCU based read-write semaphore optimized for locking for reading
|
||||
pi-futex.txt
|
||||
- documentation on lightweight PI-futexes.
|
||||
- documentation on lightweight priority inheritance futexes.
|
||||
pinctrl.txt
|
||||
- info on pinctrl subsystem and the PINMUX/PINCONF and drivers
|
||||
pnp.txt
|
||||
- Linux Plug and Play documentation.
|
||||
power/
|
||||
- directory with info on Linux PCI power management.
|
||||
powerpc/
|
||||
- directory with info on using Linux with the PowerPC.
|
||||
prctl/
|
||||
- directory with info on the priveledge control subsystem
|
||||
preempt-locking.txt
|
||||
- info on locking under a preemptive kernel.
|
||||
printk-formats.txt
|
||||
- how to get printk format specifiers right
|
||||
pps/
|
||||
- directory with information on the pulse-per-second support
|
||||
ptp/
|
||||
- directory with info on support for IEEE 1588 PTP clocks in Linux.
|
||||
pwm.txt
|
||||
- info on the pulse width modulation driver subsystem
|
||||
ramoops.txt
|
||||
- documentation of the ramoops oops/panic logging module.
|
||||
rapidio/
|
||||
- directory with info on RapidIO packet-based fabric interconnect
|
||||
rbtree.txt
|
||||
- info on what red-black trees are and what they are for.
|
||||
remoteproc.txt
|
||||
- info on how to handle remote processor (e.g. AMP) offloads/usage.
|
||||
rfkill.txt
|
||||
- info on the radio frequency kill switch subsystem/support.
|
||||
robust-futex-ABI.txt
|
||||
- documentation of the robust futex ABI.
|
||||
robust-futexes.txt
|
||||
- a description of what robust futexes are.
|
||||
rpmsg.txt
|
||||
- info on the Remote Processor Messaging (rpmsg) Framework
|
||||
rt-mutex-design.txt
|
||||
- description of the RealTime mutex implementation design.
|
||||
rt-mutex.txt
|
||||
|
|
@ -300,10 +403,10 @@ sgi-visws.txt
|
|||
- short blurb on the SGI Visual Workstations.
|
||||
sh/
|
||||
- directory with info on porting Linux to a new architecture.
|
||||
smsc_ece1099.txt
|
||||
-info on the smsc Keyboard Scan Expansion/GPIO Expansion device.
|
||||
sound/
|
||||
- directory with info on sound card support.
|
||||
sparc/
|
||||
- directory with info on using Linux on Sparc architecture.
|
||||
sparse.txt
|
||||
- info on how to obtain and use the sparse tool for typechecking.
|
||||
spi/
|
||||
|
|
@ -314,6 +417,8 @@ stable_api_nonsense.txt
|
|||
- info on why the kernel does not have a stable in-kernel api or abi.
|
||||
stable_kernel_rules.txt
|
||||
- rules and procedures for the -stable kernel releases.
|
||||
static-keys.txt
|
||||
- info on how static keys allow debug code in hotpaths via patching
|
||||
svga.txt
|
||||
- short guide on selecting video modes at boot via VGA BIOS.
|
||||
sysfs-rules.txt
|
||||
|
|
@ -322,27 +427,53 @@ sysctl/
|
|||
- directory with info on the /proc/sys/* files.
|
||||
sysrq.txt
|
||||
- info on the magic SysRq key.
|
||||
telephony/
|
||||
- directory with info on telephony (e.g. voice over IP) support.
|
||||
target/
|
||||
- directory with info on generating TCM v4 fabric .ko modules
|
||||
thermal/
|
||||
- directory with information on managing thermal issues (CPU/temp)
|
||||
trace/
|
||||
- directory with info on tracing technologies within linux
|
||||
unaligned-memory-access.txt
|
||||
- info on how to avoid arch breaking unaligned memory access in code.
|
||||
unicode.txt
|
||||
- info on the Unicode character/font mapping used in Linux.
|
||||
unshare.txt
|
||||
- description of the Linux unshare system call.
|
||||
usb/
|
||||
- directory with info regarding the Universal Serial Bus.
|
||||
vDSO/
|
||||
- directory with info regarding virtual dynamic shared objects
|
||||
vfio.txt
|
||||
- info on Virtual Function I/O used in guest/hypervisor instances.
|
||||
vgaarbiter.txt
|
||||
- info on enable/disable the legacy decoding on different VGA devices
|
||||
video-output.txt
|
||||
- sysfs class driver interface to enable/disable a video output device.
|
||||
video4linux/
|
||||
- directory with info regarding video/TV/radio cards and linux.
|
||||
virtual/
|
||||
- directory with information on the various linux virtualizations.
|
||||
vm/
|
||||
- directory with info on the Linux vm code.
|
||||
vme_api.txt
|
||||
- file relating info on the VME bus API in linux
|
||||
volatile-considered-harmful.txt
|
||||
- Why the "volatile" type class should not be used
|
||||
w1/
|
||||
- directory with documents regarding the 1-wire (w1) subsystem.
|
||||
watchdog/
|
||||
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
|
||||
wimax/
|
||||
- directory with info about Intel Wireless Wimax Connections
|
||||
workqueue.txt
|
||||
- information on the Concurrency Managed Workqueue implementation
|
||||
x86/x86_64/
|
||||
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
|
||||
xtensa/
|
||||
- directory with documents relating to arch/xtensa port/implementation
|
||||
xz.txt
|
||||
- how to make use of the XZ data compression within linux kernel
|
||||
zh_CN/
|
||||
- directory with Chinese translations of various documents
|
||||
zorro.txt
|
||||
- info on writing drivers for Zorro bus devices found on Amigas.
|
||||
|
|
|
|||
|
|
@ -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 ...]
|
||||
|
||||
action: measure | dont_measure | appraise | dont_appraise | audit
|
||||
condition:= base | lsm
|
||||
base: [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
|
||||
condition:= base | lsm [option]
|
||||
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
|
||||
[fowner]]
|
||||
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
||||
[obj_user=] [obj_role=] [obj_type=]]
|
||||
option: [[appraise_type=]]
|
||||
|
||||
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK][MODULE_CHECK]
|
||||
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
|
||||
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
|
||||
fsmagic:= hex value
|
||||
fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
|
||||
uid:= decimal value
|
||||
fowner:=decimal value
|
||||
lsm: are LSM specific
|
||||
option: appraise_type:= [imasig]
|
||||
|
||||
default policy:
|
||||
# PROC_SUPER_MAGIC
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Where: /dev/pstore/...
|
||||
Where: /sys/fs/pstore/... (or /dev/pstore/...)
|
||||
Date: March 2011
|
||||
Kernel Version: 2.6.39
|
||||
Contact: tony.luck@intel.com
|
||||
|
|
@ -11,9 +11,9 @@ Description: Generic interface to platform dependent persistent storage.
|
|||
of the console log is captured, but other interesting
|
||||
data can also be saved.
|
||||
|
||||
# mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
|
||||
# mount -t pstore -o kmsg_bytes=8000 - /sys/fs/pstore
|
||||
|
||||
$ ls -l /dev/pstore
|
||||
$ ls -l /sys/fs/pstore/
|
||||
total 0
|
||||
-r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1
|
||||
|
||||
|
|
@ -27,9 +27,9 @@ Description: Generic interface to platform dependent persistent storage.
|
|||
the file will signal to the underlying persistent storage
|
||||
device that it can reclaim the space for later re-use.
|
||||
|
||||
$ rm /dev/pstore/dmesg-erst-1
|
||||
$ rm /sys/fs/pstore/dmesg-erst-1
|
||||
|
||||
The expectation is that all files in /dev/pstore
|
||||
The expectation is that all files in /sys/fs/pstore/
|
||||
will be saved elsewhere and erased from persistent store
|
||||
soon after boot to free up space ready for the next
|
||||
catastrophe.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
KernelVersion: TBD
|
||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
||||
Description: 'FCoE Controller' instances on the fcoe bus
|
||||
Description: 'FCoE Controller' instances on the fcoe bus.
|
||||
The FCoE Controller now has a three stage creation process.
|
||||
1) Write interface name to ctlr_create 2) Configure the FCoE
|
||||
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
|
||||
discovery and login. The FCoE Controller is destroyed by
|
||||
writing it's name, i.e. ctlr_X to the ctlr_delete file.
|
||||
|
||||
Attributes:
|
||||
|
||||
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
|
||||
this value will change the dev_loss_tmo for all
|
||||
FCFs discovered by this controller.
|
||||
|
||||
mode: Display or change the FCoE Controller's mode. Possible
|
||||
modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
|
||||
is started in 'Fabric' mode then FIP FCF discovery is
|
||||
initiated and ultimately a fabric login is attempted.
|
||||
If a FCoE Controller is started in 'VN2VN' mode then
|
||||
FIP VN2VN discovery and login is performed. A FCoE
|
||||
Controller only supports one mode at a time.
|
||||
|
||||
enabled: Whether an FCoE controller is enabled or disabled.
|
||||
0 if disabled, 1 if enabled. Writing either 0 or 1
|
||||
to this file will enable or disable the FCoE controller.
|
||||
|
||||
lesb/link_fail: Link Error Status Block (LESB) link failure count.
|
||||
|
||||
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
|
||||
|
|
@ -26,7 +65,7 @@ Attributes:
|
|||
|
||||
Notes: ctlr_X (global increment starting at 0)
|
||||
|
||||
What: /sys/bus/fcoe/fcf_X
|
||||
What: /sys/bus/fcoe/devices/fcf_X
|
||||
Date: March 2012
|
||||
KernelVersion: TBD
|
||||
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
The /sys/bus/usb/devices/.../(hub interface)/portX
|
||||
is usb port device's sysfs directory.
|
||||
|
||||
What: /sys/bus/usb/devices/.../(hub interface)/portX/connect_type
|
||||
Date: January 2013
|
||||
Contact: Lan Tianyu <tianyu.lan@intel.com>
|
||||
Description:
|
||||
Some platforms provide usb port connect types through ACPI.
|
||||
This attribute is to expose these information to user space.
|
||||
The file will read "hotplug", "wired" and "not used" if the
|
||||
information is available, and "unknown" otherwise.
|
||||
|
|
|
|||
|
|
@ -48,3 +48,8 @@ max_ratio (read-write)
|
|||
most of the write-back cache. For example in case of an NFS
|
||||
mount that is prone to get stuck, or a FUSE mount which cannot
|
||||
be trusted to play fair.
|
||||
|
||||
stable_pages_required (read-only)
|
||||
|
||||
If set, the backing device requires that all pages comprising a write
|
||||
request must not be changed until writeout is complete.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu#/node
|
||||
Date: October 2009
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Discover NUMA node a CPU belongs to
|
||||
|
||||
When CONFIG_NUMA is enabled, a symbolic link that points
|
||||
to the corresponding NUMA node directory.
|
||||
|
||||
For example, the following symlink is created for cpu42
|
||||
in NUMA node 2:
|
||||
|
||||
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu#/topology/core_id
|
||||
/sys/devices/system/cpu/cpu#/topology/core_siblings
|
||||
/sys/devices/system/cpu/cpu#/topology/core_siblings_list
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
|
@ -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).
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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
|
||||
auditing without CONFIG_AUDITSYSCALL.
|
||||
|
||||
Features that might still be considered unstable should be defined as
|
||||
dependent on "EXPERIMENTAL":
|
||||
|
||||
config SLUB
|
||||
depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
|
||||
bool "SLUB (Unqueued Allocator)"
|
||||
...
|
||||
|
||||
while seriously dangerous features (such as write support for certain
|
||||
Seriously dangerous features (such as write support for certain
|
||||
filesystems) should advertise this prominently in their prompt string:
|
||||
|
||||
config ADFS_FS_RW
|
||||
|
|
|
|||
|
|
@ -488,9 +488,10 @@ will invoke the generic mapping error check interface. Doing so will ensure
|
|||
that the mapping code will work correctly on all dma implementations without
|
||||
any dependency on the specifics of the underlying implementation. Using the
|
||||
returned address without checking for errors could result in failures ranging
|
||||
from panics to silent data corruption. Couple of example of incorrect ways to
|
||||
check for errors that make assumptions about the underlying dma implementation
|
||||
are as follows and these are applicable to dma_map_page() as well.
|
||||
from panics to silent data corruption. A couple of examples of incorrect ways
|
||||
to check for errors that make assumptions about the underlying dma
|
||||
implementation are as follows and these are applicable to dma_map_page() as
|
||||
well.
|
||||
|
||||
Incorrect example 1:
|
||||
dma_addr_t dma_handle;
|
||||
|
|
@ -751,7 +752,7 @@ Example 1:
|
|||
dma_unmap_single(dma_handle1);
|
||||
map_error_handling1:
|
||||
|
||||
Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
|
||||
Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
|
||||
mapping error is detected in the middle)
|
||||
|
||||
dma_addr_t dma_addr;
|
||||
|
|
|
|||
|
|
@ -107,8 +107,8 @@
|
|||
!Finclude/net/cfg80211.h key_params
|
||||
!Finclude/net/cfg80211.h survey_info_flags
|
||||
!Finclude/net/cfg80211.h survey_info
|
||||
!Finclude/net/cfg80211.h beacon_parameters
|
||||
!Finclude/net/cfg80211.h plink_actions
|
||||
!Finclude/net/cfg80211.h cfg80211_beacon_data
|
||||
!Finclude/net/cfg80211.h cfg80211_ap_settings
|
||||
!Finclude/net/cfg80211.h station_parameters
|
||||
!Finclude/net/cfg80211.h station_info_flags
|
||||
!Finclude/net/cfg80211.h rate_info_flags
|
||||
|
|
|
|||
|
|
@ -743,6 +743,10 @@ char *date;</synopsis>
|
|||
These two operations are mandatory for GEM drivers that support DRM
|
||||
PRIME.
|
||||
</para>
|
||||
<sect4>
|
||||
<title>DRM PRIME Helper Functions Reference</title>
|
||||
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
|
||||
</sect4>
|
||||
</sect3>
|
||||
<sect3 id="drm-gem-objects-mapping">
|
||||
<title>GEM Objects Mapping</title>
|
||||
|
|
@ -978,10 +982,25 @@ int max_width, max_height;</synopsis>
|
|||
If the parameters are deemed valid, drivers then create, initialize and
|
||||
return an instance of struct <structname>drm_framebuffer</structname>.
|
||||
If desired the instance can be embedded in a larger driver-specific
|
||||
structure. The new instance is initialized with a call to
|
||||
<function>drm_framebuffer_init</function> which takes a pointer to DRM
|
||||
frame buffer operations (struct
|
||||
<structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
|
||||
structure. Drivers must fill its <structfield>width</structfield>,
|
||||
<structfield>height</structfield>, <structfield>pitches</structfield>,
|
||||
<structfield>offsets</structfield>, <structfield>depth</structfield>,
|
||||
<structfield>bits_per_pixel</structfield> and
|
||||
<structfield>pixel_format</structfield> fields from the values passed
|
||||
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
|
||||
should call the <function>drm_helper_mode_fill_fb_struct</function>
|
||||
helper function to do so.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The initailization of the new framebuffer instance is finalized with a
|
||||
call to <function>drm_framebuffer_init</function> which takes a pointer
|
||||
to DRM frame buffer operations (struct
|
||||
<structname>drm_framebuffer_funcs</structname>). Note that this function
|
||||
publishes the framebuffer and so from this point on it can be accessed
|
||||
concurrently from other threads. Hence it must be the last step in the
|
||||
driver's framebuffer initialization sequence. Frame buffer operations
|
||||
are
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
|
||||
|
|
@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis>
|
|||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
After initializing the <structname>drm_framebuffer</structname>
|
||||
instance drivers must fill its <structfield>width</structfield>,
|
||||
<structfield>height</structfield>, <structfield>pitches</structfield>,
|
||||
<structfield>offsets</structfield>, <structfield>depth</structfield>,
|
||||
<structfield>bits_per_pixel</structfield> and
|
||||
<structfield>pixel_format</structfield> fields from the values passed
|
||||
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
|
||||
should call the <function>drm_helper_mode_fill_fb_struct</function>
|
||||
helper function to do so.
|
||||
</para>
|
||||
The lifetime of a drm framebuffer is controlled with a reference count,
|
||||
drivers can grab additional references with
|
||||
<function>drm_framebuffer_reference</function> </para> and drop them
|
||||
again with <function>drm_framebuffer_unreference</function>. For
|
||||
driver-private framebuffers for which the last reference is never
|
||||
dropped (e.g. for the fbdev framebuffer when the struct
|
||||
<structname>drm_framebuffer</structname> is embedded into the fbdev
|
||||
helper struct) drivers can manually clean up a framebuffer at module
|
||||
unload time with
|
||||
<function>drm_framebuffer_unregister_private</function>.
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Output Polling</title>
|
||||
|
|
@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis>
|
|||
operation.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Locking</title>
|
||||
<para>
|
||||
Beside some lookup structures with their own locking (which is hidden
|
||||
behind the interface functions) most of the modeset state is protected
|
||||
by the <code>dev-<mode_config.lock</code> mutex and additionally
|
||||
per-crtc locks to allow cursor updates, pageflips and similar operations
|
||||
to occur concurrently with background tasks like output detection.
|
||||
Operations which cross domains like a full modeset always grab all
|
||||
locks. Drivers there need to protect resources shared between crtcs with
|
||||
additional locking. They also need to be careful to always grab the
|
||||
relevant crtc locks if a modset functions touches crtc state, e.g. for
|
||||
load detection (which does only grab the <code>mode_config.lock</code>
|
||||
to allow concurrent screen updates on live crtcs).
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Internals: kms initialization and cleanup -->
|
||||
|
|
@ -1125,6 +1160,12 @@ int max_width, max_height;</synopsis>
|
|||
without waiting for rendering or page flip to complete and must block
|
||||
any new rendering to the frame buffer until the page flip completes.
|
||||
</para>
|
||||
<para>
|
||||
If a page flip can be successfully scheduled the driver must set the
|
||||
<code>drm_crtc-<fb</code> field to the new framebuffer pointed to
|
||||
by <code>fb</code>. This is important so that the reference counting
|
||||
on framebuffers stays balanced.
|
||||
</para>
|
||||
<para>
|
||||
If a page flip is already pending, the
|
||||
<methodname>page_flip</methodname> operation must return
|
||||
|
|
@ -1609,6 +1650,10 @@ void intel_crt_init(struct drm_device *dev)
|
|||
make its properties available to applications.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>KMS API Functions</title>
|
||||
!Edrivers/gpu/drm/drm_crtc.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Internals: kms helper functions -->
|
||||
|
|
@ -2104,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<title>fbdev Helper Functions Reference</title>
|
||||
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
|
||||
!Edrivers/gpu/drm/drm_fb_helper.c
|
||||
!Iinclude/drm/drm_fb_helper.h
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Display Port Helper Functions Reference</title>
|
||||
|
|
@ -2111,6 +2157,10 @@ void intel_crt_init(struct drm_device *dev)
|
|||
!Iinclude/drm/drm_dp_helper.h
|
||||
!Edrivers/gpu/drm/drm_dp_helper.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>EDID Helper Functions Reference</title>
|
||||
!Edrivers/gpu/drm/drm_edid.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Internals: vertical blanking -->
|
||||
|
|
|
|||
|
|
@ -945,7 +945,7 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress);
|
|||
|
||||
<sect1 id="sym-exportsymbols">
|
||||
<title><function>EXPORT_SYMBOL()</function>
|
||||
<filename class="headerfile">include/linux/module.h</filename></title>
|
||||
<filename class="headerfile">include/linux/export.h</filename></title>
|
||||
|
||||
<para>
|
||||
This is the classic method of exporting a symbol: dynamically
|
||||
|
|
@ -955,7 +955,7 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress);
|
|||
|
||||
<sect1 id="sym-exportsymbols-gpl">
|
||||
<title><function>EXPORT_SYMBOL_GPL()</function>
|
||||
<filename class="headerfile">include/linux/module.h</filename></title>
|
||||
<filename class="headerfile">include/linux/export.h</filename></title>
|
||||
|
||||
<para>
|
||||
Similar to <function>EXPORT_SYMBOL()</function> except that the
|
||||
|
|
@ -1184,13 +1184,6 @@ static struct block_device_operations opt_fops = {
|
|||
<filename>Documentation/kbuild/kconfig-language.txt</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You may well want to make your CONFIG option only visible if
|
||||
<symbol>CONFIG_EXPERIMENTAL</symbol> is enabled: this serves as a
|
||||
warning to users. There many other fancy things you can do: see
|
||||
the various <filename>Kconfig</filename> files for ideas.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In your description of the option, make sure you address both the
|
||||
expert user and the user who knows nothing about your feature. Mention
|
||||
|
|
|
|||
|
|
@ -94,10 +94,8 @@
|
|||
<sect1 id="CompileKGDB">
|
||||
<title>Kernel config options for kgdb</title>
|
||||
<para>
|
||||
To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
|
||||
"Prompt for development and/or incomplete code/drivers"
|
||||
(CONFIG_EXPERIMENTAL) in "General setup", then under the
|
||||
"Kernel debugging" select "KGDB: kernel debugger".
|
||||
To enable <symbol>CONFIG_KGDB</symbol> you should look under
|
||||
"Kernel debugging" and select "KGDB: kernel debugger".
|
||||
</para>
|
||||
<para>
|
||||
While it is not a hard requirement that you have symbols in your
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
|
|||
|
||||
|
||||
<title>LINUX DVB API</title>
|
||||
<subtitle>Version 5.8</subtitle>
|
||||
<subtitle>Version 5.10</subtitle>
|
||||
<!-- ADD THE CHAPTERS HERE -->
|
||||
<chapter id="dvb_introdution">
|
||||
&sub-intro;
|
||||
|
|
|
|||
|
|
@ -7,14 +7,41 @@ the capability ioctls weren't implemented yet via the new way.</para>
|
|||
<para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant>
|
||||
API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
|
||||
struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
|
||||
<section id="dtv-stats">
|
||||
<title>DTV stats type</title>
|
||||
<programlisting>
|
||||
struct dtv_stats {
|
||||
__u8 scale; /* enum fecap_scale_params type */
|
||||
union {
|
||||
__u64 uvalue; /* for counters and relative scales */
|
||||
__s64 svalue; /* for 1/1000 dB measures */
|
||||
};
|
||||
} __packed;
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="dtv-fe-stats">
|
||||
<title>DTV stats type</title>
|
||||
<programlisting>
|
||||
#define MAX_DTV_STATS 4
|
||||
|
||||
struct dtv_fe_stats {
|
||||
__u8 len;
|
||||
struct dtv_stats stat[MAX_DTV_STATS];
|
||||
} __packed;
|
||||
</programlisting>
|
||||
</section>
|
||||
|
||||
<section id="dtv-property">
|
||||
<title>DTV property type</title>
|
||||
<programlisting>
|
||||
/* Reserved fields should be set to 0 */
|
||||
|
||||
struct dtv_property {
|
||||
__u32 cmd;
|
||||
__u32 reserved[3];
|
||||
union {
|
||||
__u32 data;
|
||||
struct dtv_fe_stats st;
|
||||
struct {
|
||||
__u8 data[32];
|
||||
__u32 len;
|
||||
|
|
@ -440,7 +467,7 @@ typedef enum fe_delivery_system {
|
|||
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
|
||||
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
|
||||
ISDB-T hierarchical layers can be decoded simultaneously. For that
|
||||
reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
|
||||
reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para>
|
||||
<para>ISDB-T has 3 hierarchical layers which each can use a part of the
|
||||
available segments. The total number of segments over all layers has
|
||||
to 13 in ISDB-T.</para>
|
||||
|
|
@ -850,6 +877,147 @@ enum fe_interleaving {
|
|||
<para>use the special macro LNA_AUTO to set LNA auto</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="frontend-stat-properties">
|
||||
<title>Frontend statistics indicators</title>
|
||||
<para>The values are returned via <constant>dtv_property.stat</constant>.
|
||||
If the property is supported, <constant>dtv_property.stat.len</constant> is bigger than zero.</para>
|
||||
<para>For most delivery systems, <constant>dtv_property.stat.len</constant>
|
||||
will be 1 if the stats is supported, and the properties will
|
||||
return a single value for each parameter.</para>
|
||||
<para>It should be noticed, however, that new OFDM delivery systems
|
||||
like ISDB can use different modulation types for each group of
|
||||
carriers. On such standards, up to 3 groups of statistics can be
|
||||
provided, and <constant>dtv_property.stat.len</constant> is updated
|
||||
to reflect the "global" metrics, plus one metric per each carrier
|
||||
group (called "layer" on ISDB).</para>
|
||||
<para>So, in order to be consistent with other delivery systems, the first
|
||||
value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link>
|
||||
array refers to the global metric. The other elements of the array
|
||||
represent each layer, starting from layer A(index 1),
|
||||
layer B (index 2) and so on.</para>
|
||||
<para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para>
|
||||
<para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem><para><constant>svalue</constant> or <constant>uvalue</constant>, where
|
||||
<constant>svalue</constant> is for signed values of the measure (dB measures)
|
||||
and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
|
||||
<listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
|
||||
<section id = "fecap-scale-params">
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
|
||||
<listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
|
||||
<listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
|
||||
<listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<section id="DTV-STAT-SIGNAL-STRENGTH">
|
||||
<title><constant>DTV_STAT_SIGNAL_STRENGTH</constant></title>
|
||||
<para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem>
|
||||
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-CNR">
|
||||
<title><constant>DTV_STAT_CNR</constant></title>
|
||||
<para>Indicates the Signal to Noise ratio for the main carrier.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem>
|
||||
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
|
||||
<title><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></title>
|
||||
<para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
|
||||
<para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
|
||||
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
|
||||
<link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
|
||||
<title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
|
||||
<para>Measures the amount of bits received before the inner code block, during the same period as
|
||||
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
|
||||
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
|
||||
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
|
||||
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-POST-ERROR-BIT-COUNT">
|
||||
<title><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></title>
|
||||
<para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
|
||||
<para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
|
||||
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
|
||||
<link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
|
||||
<title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
|
||||
<para>Measures the amount of bits received after the inner coding, during the same period as
|
||||
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
|
||||
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
|
||||
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
|
||||
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-ERROR-BLOCK-COUNT">
|
||||
<title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
|
||||
<para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
|
||||
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
|
||||
The frontend may reset it when a channel/transponder is tuned.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="DTV-STAT-TOTAL-BLOCK-COUNT">
|
||||
<title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
|
||||
<para>Measures the total number of blocks received during the same period as
|
||||
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
|
||||
<para>It can be used to calculate the PER indicator, by dividing
|
||||
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
|
||||
by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
|
||||
<para>Possible scales for this metric are:</para>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
|
||||
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
|
||||
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="frontend-property-terrestrial-systems">
|
||||
<title>Properties used on terrestrial delivery systems</title>
|
||||
<section id="dvbt-params">
|
||||
|
|
@ -871,6 +1039,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="dvbt2-params">
|
||||
<title>DVB-T2 delivery system</title>
|
||||
|
|
@ -895,6 +1064,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="isdbt">
|
||||
<title>ISDB-T delivery system</title>
|
||||
|
|
@ -948,6 +1118,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="atsc-params">
|
||||
<title>ATSC delivery system</title>
|
||||
|
|
@ -961,6 +1132,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="atscmh-params">
|
||||
<title>ATSC-MH delivery system</title>
|
||||
|
|
@ -988,6 +1160,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="dtmb-params">
|
||||
<title>DTMB delivery system</title>
|
||||
|
|
@ -1007,6 +1180,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section id="frontend-property-cable-systems">
|
||||
|
|
@ -1028,6 +1202,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="dvbc-annex-b-params">
|
||||
<title>DVB-C Annex B delivery system</title>
|
||||
|
|
@ -1043,6 +1218,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section id="frontend-property-satellital-systems">
|
||||
|
|
@ -1062,6 +1238,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
<para>Future implementations might add those two missing parameters:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
|
||||
|
|
@ -1077,6 +1254,7 @@ enum fe_interleaving {
|
|||
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
|
||||
</section>
|
||||
<section id="turbo-params">
|
||||
<title>Turbo code delivery system</title>
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ typedef enum fe_status {
|
|||
<entry align="char">The frontend has found a DVB signal</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_VITERBI</entry>
|
||||
<entry align="char">The frontend FEC code is stable</entry>
|
||||
<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_SYNC</entry>
|
||||
<entry align="char">Syncronization bytes was found</entry>
|
||||
|
|
|
|||
|
|
@ -609,7 +609,7 @@ to zero and the <constant>VIDIOC_G_STD</constant>,
|
|||
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
|
||||
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
|
||||
are available for the device.</para>
|
||||
&ENOTTY;.
|
||||
|
||||
<para>See <xref linkend="buffer" /> for a rationale. Probably
|
||||
even USB cameras follow some well known video standard. It might have
|
||||
been better to explicitly indicate elsewhere if a device cannot live
|
||||
|
|
|
|||
|
|
@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.9</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added timestamp types to
|
||||
<structfield>flags</structfield> field in
|
||||
<structname>v4l2_buffer</structname>. See <xref
|
||||
linkend="buffer-flags" />.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
|
||||
changes flag. See <xref linkend="changes-flags"/>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
||||
|
|
|
|||
|
|
@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry>
|
|||
<entry>boolean</entry>
|
||||
<entry>Mirror the picture vertically.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry>
|
||||
<entry>integer</entry>
|
||||
<entry>Horizontal image centering. This control is
|
||||
deprecated. New drivers and applications should use the <link
|
||||
linkend="camera-controls">Camera class controls</link>
|
||||
<constant>V4L2_CID_PAN_ABSOLUTE</constant>,
|
||||
<constant>V4L2_CID_PAN_RELATIVE</constant> and
|
||||
<constant>V4L2_CID_PAN_RESET</constant> instead.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant>
|
||||
(formerly <constant>V4L2_CID_VCENTER</constant>)</entry>
|
||||
<entry>integer</entry>
|
||||
<entry>Vertical image centering. Centering is intended to
|
||||
<emphasis>physically</emphasis> adjust cameras. For image cropping see
|
||||
<xref linkend="crop" />, for clipping <xref linkend="overlay" />. This
|
||||
control is deprecated. New drivers and applications should use the
|
||||
<link linkend="camera-controls">Camera class controls</link>
|
||||
<constant>V4L2_CID_TILT_ABSOLUTE</constant>,
|
||||
<constant>V4L2_CID_TILT_RELATIVE</constant> and
|
||||
<constant>V4L2_CID_TILT_RESET</constant> instead.</entry>
|
||||
</row>
|
||||
<row id="v4l2-power-line-frequency">
|
||||
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
|
||||
<entry>enum</entry>
|
||||
|
|
|
|||
|
|
@ -477,7 +477,7 @@ rest should be evident.</para>
|
|||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental"> experimental </link>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
|
|
@ -488,7 +488,7 @@ DMA buffer from userspace using a file descriptor previously exported for a
|
|||
different or the same device (known as the importer role), or both. This
|
||||
section describes the DMABUF importer role API in V4L2.</para>
|
||||
|
||||
<para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for
|
||||
<para>Refer to <link linkend="vidioc-expbuf">DMABUF exporting</link> for
|
||||
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
|
||||
|
||||
<para>Input and output devices support the streaming I/O method when the
|
||||
|
|
@ -741,17 +741,19 @@ applications when an output stream.</entry>
|
|||
<entry>struct timeval</entry>
|
||||
<entry><structfield>timestamp</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry><para>For input streams this is the
|
||||
system time (as returned by the <function>gettimeofday()</function>
|
||||
function) when the first data byte was captured. For output streams
|
||||
the data will not be displayed before this time, secondary to the
|
||||
nominal frame rate determined by the current video standard in
|
||||
enqueued order. Applications can for example zero this field to
|
||||
display frames as soon as possible. The driver stores the time at
|
||||
which the first data byte was actually sent out in the
|
||||
<structfield>timestamp</structfield> field. This permits
|
||||
applications to monitor the drift between the video and system
|
||||
clock.</para></entry>
|
||||
<entry><para>For input streams this is time when the first data
|
||||
byte was captured, as returned by the
|
||||
<function>clock_gettime()</function> function for the relevant
|
||||
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
|
||||
<xref linkend="buffer-flags" />. For output streams the data
|
||||
will not be displayed before this time, secondary to the nominal
|
||||
frame rate determined by the current video standard in enqueued
|
||||
order. Applications can for example zero this field to display
|
||||
frames as soon as possible. The driver stores the time at which
|
||||
the first data byte was actually sent out in the
|
||||
<structfield>timestamp</structfield> field. This permits
|
||||
applications to monitor the drift between the video and system
|
||||
clock.</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-timecode;</entry>
|
||||
|
|
@ -903,7 +905,7 @@ should set this to 0.</entry>
|
|||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__unsigned long</entry>
|
||||
<entry>unsigned long</entry>
|
||||
<entry><structfield>userptr</structfield></entry>
|
||||
<entry>When the memory type in the containing &v4l2-buffer; is
|
||||
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
|
||||
|
|
@ -1114,6 +1116,35 @@ Typically applications shall use this flag for output buffers if the data
|
|||
in this buffer has not been created by the CPU but by some DMA-capable unit,
|
||||
in which case caches have not been used.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
|
||||
<entry>0xe000</entry>
|
||||
<entry>Mask for timestamp types below. To test the
|
||||
timestamp type, mask out bits not belonging to timestamp
|
||||
type by performing a logical and operation with buffer
|
||||
flags and timestamp mask.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
|
||||
<entry>0x0000</entry>
|
||||
<entry>Unknown timestamp type. This type is used by
|
||||
drivers before Linux 3.9 and may be either monotonic (see
|
||||
below) or realtime (wall clock). Monotonic clock has been
|
||||
favoured in embedded systems whereas most of the drivers
|
||||
use the realtime clock. Either kinds of timestamps are
|
||||
available in user space via
|
||||
<function>clock_gettime(2)</function> using clock IDs
|
||||
<constant>CLOCK_MONOTONIC</constant> and
|
||||
<constant>CLOCK_REALTIME</constant>, respectively.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
|
||||
<entry>0x2000</entry>
|
||||
<entry>The buffer timestamp has been taken from the
|
||||
<constant>CLOCK_MONOTONIC</constant> clock. To access the
|
||||
same clock outside V4L2, use
|
||||
<function>clock_gettime(2)</function> .</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
<refnamediv>
|
||||
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-NV12MT-16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
|
||||
non contiguous in memory. </refpurpose>
|
||||
</refnamediv>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
@ -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-sbggr16;
|
||||
&sub-srggb10;
|
||||
&sub-srggb10alaw8;
|
||||
&sub-srggb10dpcm8;
|
||||
&sub-srggb12;
|
||||
</section>
|
||||
|
|
@ -701,6 +702,7 @@ information.</para>
|
|||
&sub-y12;
|
||||
&sub-y10b;
|
||||
&sub-y16;
|
||||
&sub-uv8;
|
||||
&sub-yuyv;
|
||||
&sub-uyvy;
|
||||
&sub-yvyu;
|
||||
|
|
|
|||
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
|
||||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.9</revnumber>
|
||||
<date>2012-12-03</date>
|
||||
<authorinitials>sa, sn</authorinitials>
|
||||
<revremark>Added timestamp types to v4l2_buffer.
|
||||
Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control
|
||||
event changes flag, see <xref linkend="changes-flags"/>.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.6</revnumber>
|
||||
<date>2012-07-02</date>
|
||||
|
|
@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.6</subtitle>
|
||||
<subtitle>Revision 3.9</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
|
|||
|
|
@ -261,6 +261,12 @@
|
|||
<entry>This control event was triggered because the control flags
|
||||
changed.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_RANGE</constant></entry>
|
||||
<entry>0x0004</entry>
|
||||
<entry>This control event was triggered because the minimum,
|
||||
maximum, step or the default value of the control changed.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -83,15 +83,14 @@ descriptor. The application may pass it to other DMABUF-aware devices. Refer to
|
|||
<link linkend="dmabuf">DMABUF importing</link> for details about importing
|
||||
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
|
||||
is no longer used to allow the associated memory to be reclaimed. </para>
|
||||
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
<section>
|
||||
<title>Examples</title>
|
||||
|
||||
<example>
|
||||
<title>Exporting a buffer.</title>
|
||||
<programlisting>
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
|
||||
<example>
|
||||
<title>Exporting a buffer.</title>
|
||||
<programlisting>
|
||||
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
|
||||
{
|
||||
&v4l2-exportbuffer; expbuf;
|
||||
|
|
@ -108,12 +107,12 @@ int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
|
|||
|
||||
return 0;
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Exporting a buffer using the multi-planar API.</title>
|
||||
<programlisting>
|
||||
<example>
|
||||
<title>Exporting a buffer using the multi-planar API.</title>
|
||||
<programlisting>
|
||||
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
|
||||
int dmafd[], int n_planes)
|
||||
{
|
||||
|
|
@ -137,12 +136,9 @@ int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
|
|||
|
||||
return 0;
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
</section>
|
||||
</refsect1>
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<refsect1>
|
||||
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
|
||||
<title>struct <structname>v4l2_exportbuffer</structname></title>
|
||||
<tgroup cols="3">
|
||||
|
|
|
|||
|
|
@ -64,7 +64,9 @@ return an &EINVAL;. When the <structfield>value</structfield> is out
|
|||
of bounds drivers can choose to take the closest valid value or return
|
||||
an &ERANGE;, whatever seems more appropriate. However,
|
||||
<constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not
|
||||
return the actual new value.</para>
|
||||
return the actual new value. If the <structfield>value</structfield>
|
||||
is inappropriate for the control (e.g. if it refers to an unsupported
|
||||
menu index of a menu control), then &EINVAL; is returned as well.</para>
|
||||
|
||||
<para>These ioctls work only with user controls. For other
|
||||
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
|
||||
|
|
@ -99,7 +101,9 @@ application.</entry>
|
|||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-control; <structfield>id</structfield> is
|
||||
invalid.</para>
|
||||
invalid or the <structfield>value</structfield> is inappropriate for
|
||||
the given control (i.e. if a menu item is selected that is not supported
|
||||
by the driver according to &VIDIOC-QUERYMENU;).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -106,7 +106,9 @@ value or if an error is returned.</para>
|
|||
&EINVAL;. When the value is out of bounds drivers can choose to take
|
||||
the closest valid value or return an &ERANGE;, whatever seems more
|
||||
appropriate. In the first case the new value is set in
|
||||
&v4l2-ext-control;.</para>
|
||||
&v4l2-ext-control;. If the new control value is inappropriate (e.g. the
|
||||
given menu index is not supported by the menu control), then this will
|
||||
also result in an &EINVAL; error.</para>
|
||||
|
||||
<para>The driver will only set/get these controls if all control
|
||||
values are correct. This prevents the situation where only some of the
|
||||
|
|
@ -199,13 +201,46 @@ also be zero.</entry>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>error_idx</structfield></entry>
|
||||
<entry>Set by the driver in case of an error. If it is equal
|
||||
to <structfield>count</structfield>, then no actual changes were made to
|
||||
controls. In other words, the error was not associated with setting a particular
|
||||
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
|
||||
were modified and control <structfield>error_idx</structfield> is the one that
|
||||
caused the error. The <structfield>error_idx</structfield> value is undefined
|
||||
if the ioctl returned 0 (success).</entry>
|
||||
<entry><para>Set by the driver in case of an error. If the error is
|
||||
associated with a particular control, then <structfield>error_idx</structfield>
|
||||
is set to the index of that control. If the error is not related to a specific
|
||||
control, or the validation step failed (see below), then
|
||||
<structfield>error_idx</structfield> is set to <structfield>count</structfield>.
|
||||
The value is undefined if the ioctl returned 0 (success).</para>
|
||||
|
||||
<para>Before controls are read from/written to hardware a validation step
|
||||
takes place: this checks if all controls in the list are valid controls,
|
||||
if no attempt is made to write to a read-only control or read from a write-only
|
||||
control, and any other up-front checks that can be done without accessing the
|
||||
hardware. The exact validations done during this step are driver dependent
|
||||
since some checks might require hardware access for some devices, thus making
|
||||
it impossible to do those checks up-front. However, drivers should make a
|
||||
best-effort to do as many up-front checks as possible.</para>
|
||||
|
||||
<para>This check is done to avoid leaving the hardware in an inconsistent state due
|
||||
to easy-to-avoid problems. But it leads to another problem: the application needs to
|
||||
know whether an error came from the validation step (meaning that the hardware
|
||||
was not touched) or from an error during the actual reading from/writing to hardware.</para>
|
||||
|
||||
<para>The, in hindsight quite poor, solution for that is to set <structfield>error_idx</structfield>
|
||||
to <structfield>count</structfield> if the validation failed. This has the
|
||||
unfortunate side-effect that it is not possible to see which control failed the
|
||||
validation. If the validation was successful and the error happened while
|
||||
accessing the hardware, then <structfield>error_idx</structfield> is less than
|
||||
<structfield>count</structfield> and only the controls up to
|
||||
<structfield>error_idx-1</structfield> were read or written correctly, and the
|
||||
state of the remaining controls is undefined.</para>
|
||||
|
||||
<para>Since <constant>VIDIOC_TRY_EXT_CTRLS</constant> does not access hardware
|
||||
there is also no need to handle the validation step in this special way,
|
||||
so <structfield>error_idx</structfield> will just be set to the control that
|
||||
failed the validation step instead of to <structfield>count</structfield>.
|
||||
This means that if <constant>VIDIOC_S_EXT_CTRLS</constant> fails with
|
||||
<structfield>error_idx</structfield> set to <structfield>count</structfield>,
|
||||
then you can call <constant>VIDIOC_TRY_EXT_CTRLS</constant> to try to discover
|
||||
the actual control that failed the validation step. Unfortunately, there
|
||||
is no <constant>TRY</constant> equivalent for <constant>VIDIOC_G_EXT_CTRLS</constant>.
|
||||
</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -298,8 +333,10 @@ These controls are described in <xref
|
|||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-ext-control; <structfield>id</structfield>
|
||||
is invalid or the &v4l2-ext-controls;
|
||||
<structfield>ctrl_class</structfield> is invalid. This error code is
|
||||
is invalid, the &v4l2-ext-controls;
|
||||
<structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control;
|
||||
<structfield>value</structfield> was inappropriate (e.g. the given menu
|
||||
index is not supported by the driver). This error code is
|
||||
also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and
|
||||
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
|
||||
control values are in conflict.</para>
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry>
|
|||
<row>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>card</structfield>[32]</entry>
|
||||
<entry>Name of the device, a NUL-terminated ASCII string.
|
||||
<entry>Name of the device, a NUL-terminated UTF-8 string.
|
||||
For example: "Yoyodyne TV/FM". One driver may support different brands
|
||||
or models of video hardware. This information is intended for users,
|
||||
for example in a menu of available devices. Since multiple TV cards of
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@
|
|||
|
||||
<!-- LinuxTV v4l-dvb repository. -->
|
||||
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
|
||||
<!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
|
||||
]>
|
||||
|
||||
<book id="media_api">
|
||||
|
|
|
|||
|
|
@ -984,7 +984,7 @@ int main()
|
|||
return errno;
|
||||
}
|
||||
configfd = open("/sys/class/uio/uio0/device/config", O_RDWR);
|
||||
if (uiofd < 0) {
|
||||
if (configfd < 0) {
|
||||
perror("config open:");
|
||||
return errno;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -871,9 +871,8 @@
|
|||
<para>
|
||||
This function itself doesn't allocate the data space. The data
|
||||
must be allocated manually beforehand, and its pointer is passed
|
||||
as the argument. This pointer is used as the
|
||||
(<parameter>chip</parameter> identifier in the above example)
|
||||
for the instance.
|
||||
as the argument. This pointer (<parameter>chip</parameter> in the
|
||||
above example) is used as the identifier for the instance.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -2304,7 +2303,7 @@ struct _snd_pcm_runtime {
|
|||
<constant>SNDRV_PCM_INFO_XXX</constant>. Here, at least, you
|
||||
have to specify whether the mmap is supported and which
|
||||
interleaved format is supported.
|
||||
When the is supported, add the
|
||||
When the hardware supports mmap, add the
|
||||
<constant>SNDRV_PCM_INFO_MMAP</constant> flag here. When the
|
||||
hardware supports the interleaved or the non-interleaved
|
||||
formats, <constant>SNDRV_PCM_INFO_INTERLEAVED</constant> or
|
||||
|
|
@ -2898,7 +2897,7 @@ struct _snd_pcm_runtime {
|
|||
|
||||
<para>
|
||||
When the pcm supports the pause operation (given in the info
|
||||
field of the hardware table), the <constant>PAUSE_PUSE</constant>
|
||||
field of the hardware table), the <constant>PAUSE_PUSH</constant>
|
||||
and <constant>PAUSE_RELEASE</constant> commands must be
|
||||
handled here, too. The former is the command to pause the pcm,
|
||||
and the latter to restart the pcm again.
|
||||
|
|
@ -3085,7 +3084,7 @@ struct _snd_pcm_runtime {
|
|||
<section id="pcm-interface-interrupt-handler-timer">
|
||||
<title>High frequency timer interrupts</title>
|
||||
<para>
|
||||
This happense when the hardware doesn't generate interrupts
|
||||
This happens when the hardware doesn't generate interrupts
|
||||
at the period boundary but issues timer interrupts at a fixed
|
||||
timer rate (e.g. es1968 or ymfpci drivers).
|
||||
In this case, you need to check the current hardware
|
||||
|
|
@ -3250,49 +3249,6 @@ struct _snd_pcm_runtime {
|
|||
<example>
|
||||
<title>Example of Hardware Constraints for Channels</title>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
|
||||
struct snd_pcm_hw_rule *rule)
|
||||
{
|
||||
struct snd_interval *c = hw_param_interval(params,
|
||||
SNDRV_PCM_HW_PARAM_CHANNELS);
|
||||
struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
|
||||
struct snd_mask fmt;
|
||||
|
||||
snd_mask_any(&fmt); /* Init the struct */
|
||||
if (c->min < 2) {
|
||||
fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
|
||||
return snd_mask_refine(f, &fmt);
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
]]>
|
||||
</programlisting>
|
||||
</example>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Then you need to call this function to add your rule:
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
|
||||
hw_rule_channels_by_format, 0, SNDRV_PCM_HW_PARAM_FORMAT,
|
||||
-1);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The rule function is called when an application sets the number of
|
||||
channels. But an application can set the format before the number of
|
||||
channels. Thus you also need to define the inverse rule:
|
||||
|
||||
<example>
|
||||
<title>Example of Hardware Constraints for Channels</title>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
|
||||
struct snd_pcm_hw_rule *rule)
|
||||
|
|
@ -3314,6 +3270,50 @@ struct _snd_pcm_runtime {
|
|||
</programlisting>
|
||||
</example>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Then you need to call this function to add your rule:
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
|
||||
hw_rule_channels_by_format, NULL,
|
||||
SNDRV_PCM_HW_PARAM_FORMAT, -1);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The rule function is called when an application sets the PCM
|
||||
format, and it refines the number of channels accordingly.
|
||||
But an application may set the number of channels before
|
||||
setting the format. Thus you also need to define the inverse rule:
|
||||
|
||||
<example>
|
||||
<title>Example of Hardware Constraints for Formats</title>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
|
||||
struct snd_pcm_hw_rule *rule)
|
||||
{
|
||||
struct snd_interval *c = hw_param_interval(params,
|
||||
SNDRV_PCM_HW_PARAM_CHANNELS);
|
||||
struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
|
||||
struct snd_mask fmt;
|
||||
|
||||
snd_mask_any(&fmt); /* Init the struct */
|
||||
if (c->min < 2) {
|
||||
fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
|
||||
return snd_mask_refine(f, &fmt);
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
]]>
|
||||
</programlisting>
|
||||
</example>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
...and in the open callback:
|
||||
|
|
@ -3321,8 +3321,8 @@ struct _snd_pcm_runtime {
|
|||
<programlisting>
|
||||
<![CDATA[
|
||||
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT,
|
||||
hw_rule_format_by_channels, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
|
||||
-1);
|
||||
hw_rule_format_by_channels, NULL,
|
||||
SNDRV_PCM_HW_PARAM_CHANNELS, -1);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
|
|
|||
|
|
@ -28,11 +28,30 @@ Makefile environment are given here.
|
|||
To create binary EDID and C source code files from the existing data
|
||||
material, simply type "make".
|
||||
|
||||
If you want to create your own EDID file, copy the file 1024x768.S and
|
||||
replace the settings with your own data. The CRC value in the last line
|
||||
If you want to create your own EDID file, copy the file 1024x768.S,
|
||||
replace the settings with your own data and add a new target to the
|
||||
Makefile. Please note that the EDID data structure expects the timing
|
||||
values in a different way as compared to the standard X11 format.
|
||||
|
||||
X11:
|
||||
HTimings: hdisp hsyncstart hsyncend htotal
|
||||
VTimings: vdisp vsyncstart vsyncend vtotal
|
||||
|
||||
EDID:
|
||||
#define XPIX hdisp
|
||||
#define XBLANK htotal-hdisp
|
||||
#define XOFFSET hsyncstart-hdisp
|
||||
#define XPULSE hsyncend-hsyncstart
|
||||
|
||||
#define YPIX vdisp
|
||||
#define YBLANK vtotal-vdisp
|
||||
#define YOFFSET (63+(vsyncstart-vdisp))
|
||||
#define YPULSE (63+(vsyncend-vsyncstart))
|
||||
|
||||
The CRC value in the last line
|
||||
#define CRC 0x55
|
||||
is a bit tricky. After a first version of the binary data set is
|
||||
created, it must be be checked with the "edid-decode" utility which will
|
||||
also is a bit tricky. After a first version of the binary data set is
|
||||
created, it must be checked with the "edid-decode" utility which will
|
||||
most probably complain about a wrong CRC. Fortunately, the utility also
|
||||
displays the correct CRC which must then be inserted into the source
|
||||
file. After the make procedure is repeated, the EDID data set is ready
|
||||
|
|
|
|||
|
|
@ -348,34 +348,40 @@ You can change this at module load time (for a module) with:
|
|||
|
||||
modprobe ipmi_si.o type=<type1>,<type2>....
|
||||
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
|
||||
irqs=<irq1>,<irq2>... trydefaults=[0|1]
|
||||
irqs=<irq1>,<irq2>...
|
||||
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
|
||||
regshifts=<shift1>,<shift2>,...
|
||||
slave_addrs=<addr1>,<addr2>,...
|
||||
force_kipmid=<enable1>,<enable2>,...
|
||||
kipmid_max_busy_us=<ustime1>,<ustime2>,...
|
||||
unload_when_empty=[0|1]
|
||||
trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1]
|
||||
tryplatform=[0|1] trypci=[0|1]
|
||||
|
||||
Each of these except si_trydefaults is a list, the first item for the
|
||||
Each of these except try... items is a list, the first item for the
|
||||
first interface, second item for the second interface, etc.
|
||||
|
||||
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
|
||||
defaults to "kcs".
|
||||
|
||||
If you specify si_addrs as non-zero for an interface, the driver will
|
||||
If you specify addrs as non-zero for an interface, the driver will
|
||||
use the memory address given as the address of the device. This
|
||||
overrides si_ports.
|
||||
|
||||
If you specify si_ports as non-zero for an interface, the driver will
|
||||
If you specify ports as non-zero for an interface, the driver will
|
||||
use the I/O port given as the device address.
|
||||
|
||||
If you specify si_irqs as non-zero for an interface, the driver will
|
||||
If you specify irqs as non-zero for an interface, the driver will
|
||||
attempt to use the given interrupt for the device.
|
||||
|
||||
si_trydefaults sets whether the standard IPMI interface at 0xca2 and
|
||||
trydefaults sets whether the standard IPMI interface at 0xca2 and
|
||||
any interfaces specified by ACPE are tried. By default, the driver
|
||||
tries it, set this value to zero to turn this off.
|
||||
|
||||
The other try... items disable discovery by their corresponding
|
||||
names. These are all enabled by default, set them to zero to disable
|
||||
them. The tryplatform disables openfirmware.
|
||||
|
||||
The next three parameters have to do with register layout. The
|
||||
registers used by the interfaces may not appear at successive
|
||||
locations and they may not be in 8-bit registers. These parameters
|
||||
|
|
|
|||
|
|
@ -127,15 +127,42 @@ on the number of vectors that can be allocated; pci_enable_msi_block()
|
|||
returns as soon as it finds any constraint that doesn't allow the
|
||||
call to succeed.
|
||||
|
||||
4.2.3 pci_disable_msi
|
||||
4.2.3 pci_enable_msi_block_auto
|
||||
|
||||
int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
|
||||
|
||||
This variation on pci_enable_msi() call allows a device driver to request
|
||||
the maximum possible number of MSIs. The MSI specification only allows
|
||||
interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
|
||||
|
||||
If this function returns a positive number, it indicates that it has
|
||||
succeeded and the returned value is the number of allocated interrupts. In
|
||||
this case, the function enables MSI on this device and updates dev->irq to
|
||||
be the lowest of the new interrupts assigned to it. The other interrupts
|
||||
assigned to the device are in the range dev->irq to dev->irq + returned
|
||||
value - 1.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to request any more MSI interrupts for
|
||||
this device.
|
||||
|
||||
If the device driver needs to know the number of interrupts the device
|
||||
supports it can pass the pointer count where that number is stored. The
|
||||
device driver must decide what action to take if pci_enable_msi_block_auto()
|
||||
succeeds, but returns a value less than the number of interrupts supported.
|
||||
If the device driver does not need to know the number of interrupts
|
||||
supported, it can set the pointer count to NULL.
|
||||
|
||||
4.2.4 pci_disable_msi
|
||||
|
||||
void pci_disable_msi(struct pci_dev *dev)
|
||||
|
||||
This function should be used to undo the effect of pci_enable_msi() or
|
||||
pci_enable_msi_block(). Calling it restores dev->irq to the pin-based
|
||||
interrupt number and frees the previously allocated message signaled
|
||||
interrupt(s). The interrupt may subsequently be assigned to another
|
||||
device, so drivers should not cache the value of dev->irq.
|
||||
pci_enable_msi_block() or pci_enable_msi_block_auto(). Calling it restores
|
||||
dev->irq to the pin-based interrupt number and frees the previously
|
||||
allocated message signaled interrupt(s). The interrupt may subsequently be
|
||||
assigned to another device, so drivers should not cache the value of
|
||||
dev->irq.
|
||||
|
||||
Before calling this function, a device driver must always call free_irq()
|
||||
on any interrupt for which it previously called request_irq().
|
||||
|
|
|
|||
|
|
@ -60,8 +60,7 @@ own source tree. For example:
|
|||
"dontdiff" is a list of files which are generated by the kernel during
|
||||
the build process, and should be ignored in any diff(1)-generated
|
||||
patch. The "dontdiff" file is included in the kernel tree in
|
||||
2.6.12 and later. For earlier kernel versions, you can get it
|
||||
from <http://www.xenotime.net/linux/doc/dontdiff>.
|
||||
2.6.12 and later.
|
||||
|
||||
Make sure your patch does not include any extra files which do not
|
||||
belong in a patch submission. Make sure to review your patch -after-
|
||||
|
|
|
|||
|
|
@ -63,8 +63,8 @@ from ACPI tables.
|
|||
Currently the kernel is not able to automatically determine from which ACPI
|
||||
device it should make the corresponding platform device so we need to add
|
||||
the ACPI device explicitly to acpi_platform_device_ids list defined in
|
||||
drivers/acpi/scan.c. This limitation is only for the platform devices, SPI
|
||||
and I2C devices are created automatically as described below.
|
||||
drivers/acpi/acpi_platform.c. This limitation is only for the platform
|
||||
devices, SPI and I2C devices are created automatically as described below.
|
||||
|
||||
SPI serial bus support
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
||||
ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
|
||||
|
||||
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
|
||||
|
||||
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
|
||||
just before the operation.
|
||||
|
||||
atomic_xchg requires explicit memory barriers around the operation.
|
||||
|
||||
int atomic_cmpxchg(atomic_t *v, int old, int new);
|
||||
|
||||
This performs an atomic compare exchange operation on the atomic value v,
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Kernel driver lp855x
|
|||
Backlight driver for LP855x ICs
|
||||
|
||||
Supported chips:
|
||||
Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556
|
||||
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
|
||||
|
||||
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Value : pwm based or register based
|
|||
|
||||
2) chip_id
|
||||
The lp855x chip id.
|
||||
Value : lp8550/lp8551/lp8552/lp8553/lp8556
|
||||
Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
|
||||
|
||||
Platform data for lp855x
|
||||
------------------------
|
||||
|
|
|
|||
|
|
@ -102,6 +102,64 @@ processing of request. Therefore, increasing the value can imporve the
|
|||
performace although this can cause the latency of some I/O to increase due
|
||||
to more number of requests.
|
||||
|
||||
CFQ Group scheduling
|
||||
====================
|
||||
|
||||
CFQ supports blkio cgroup and has "blkio." prefixed files in each
|
||||
blkio cgroup directory. It is weight-based and there are four knobs
|
||||
for configuration - weight[_device] and leaf_weight[_device].
|
||||
Internal cgroup nodes (the ones with children) can also have tasks in
|
||||
them, so the former two configure how much proportion the cgroup as a
|
||||
whole is entitled to at its parent's level while the latter two
|
||||
configure how much proportion the tasks in the cgroup have compared to
|
||||
its direct children.
|
||||
|
||||
Another way to think about it is assuming that each internal node has
|
||||
an implicit leaf child node which hosts all the tasks whose weight is
|
||||
configured by leaf_weight[_device]. Let's assume a blkio hierarchy
|
||||
composed of five cgroups - root, A, B, AA and AB - with the following
|
||||
weights where the names represent the hierarchy.
|
||||
|
||||
weight leaf_weight
|
||||
root : 125 125
|
||||
A : 500 750
|
||||
B : 250 500
|
||||
AA : 500 500
|
||||
AB : 1000 500
|
||||
|
||||
root never has a parent making its weight is meaningless. For backward
|
||||
compatibility, weight is always kept in sync with leaf_weight. B, AA
|
||||
and AB have no child and thus its tasks have no children cgroup to
|
||||
compete with. They always get 100% of what the cgroup won at the
|
||||
parent level. Considering only the weights which matter, the hierarchy
|
||||
looks like the following.
|
||||
|
||||
root
|
||||
/ | \
|
||||
A B leaf
|
||||
500 250 125
|
||||
/ | \
|
||||
AA AB leaf
|
||||
500 1000 750
|
||||
|
||||
If all cgroups have active IOs and competing with each other, disk
|
||||
time will be distributed like the following.
|
||||
|
||||
Distribution below root. The total active weight at this level is
|
||||
A:500 + B:250 + C:125 = 875.
|
||||
|
||||
root-leaf : 125 / 875 =~ 14%
|
||||
A : 500 / 875 =~ 57%
|
||||
B(-leaf) : 250 / 875 =~ 28%
|
||||
|
||||
A has children and further distributes its 57% among the children and
|
||||
the implicit leaf node. The total active weight at this level is
|
||||
AA:500 + AB:1000 + A-leaf:750 = 2250.
|
||||
|
||||
A-leaf : ( 750 / 2250) * A =~ 19%
|
||||
AA(-leaf) : ( 500 / 2250) * A =~ 12%
|
||||
AB(-leaf) : (1000 / 2250) * A =~ 25%
|
||||
|
||||
CFQ IOPS Mode for group scheduling
|
||||
===================================
|
||||
Basic CFQ design is to provide priority based time slices. Higher priority
|
||||
|
|
|
|||
|
|
@ -4,43 +4,13 @@
|
|||
can use a remote server as one of its block devices. So every time
|
||||
the client computer wants to read, e.g., /dev/nb0, it sends a
|
||||
request over TCP to the server, which will reply with the data read.
|
||||
This can be used for stations with low disk space (or even diskless -
|
||||
if you boot from floppy) to borrow disk space from another computer.
|
||||
Unlike NFS, it is possible to put any filesystem on it, etc. It should
|
||||
even be possible to use NBD as a root filesystem (I've never tried),
|
||||
but it requires a user-level program to be in the initrd to start.
|
||||
It also allows you to run block-device in user land (making server
|
||||
and client physically the same computer, communicating using loopback).
|
||||
|
||||
Current state: It currently works. Network block device is stable.
|
||||
I originally thought that it was impossible to swap over TCP. It
|
||||
turned out not to be true - swapping over TCP now works and seems
|
||||
to be deadlock-free, but it requires heavy patches into Linux's
|
||||
network layer.
|
||||
|
||||
This can be used for stations with low disk space (or even diskless)
|
||||
to borrow disk space from another computer.
|
||||
Unlike NFS, it is possible to put any filesystem on it, etc.
|
||||
|
||||
For more information, or to download the nbd-client and nbd-server
|
||||
tools, go to http://nbd.sf.net/.
|
||||
|
||||
Howto: To setup nbd, you can simply do the following:
|
||||
|
||||
First, serve a device or file from a remote server:
|
||||
|
||||
nbd-server <port-number> <device-or-file-to-serve-to-client>
|
||||
|
||||
e.g.,
|
||||
root@server1 # nbd-server 1234 /dev/sdb1
|
||||
|
||||
(serves sdb1 partition on TCP port 1234)
|
||||
|
||||
Then, on the local (client) system:
|
||||
|
||||
nbd-client <server-name-or-IP> <server-port-number> /dev/nb[0-n]
|
||||
|
||||
e.g.,
|
||||
root@client1 # nbd-client server1 1234 /dev/nb0
|
||||
|
||||
(creates the nb0 device on client1)
|
||||
|
||||
The nbd kernel module need only be installed on the client
|
||||
system, as the nbd-server is completely in userspace. In fact,
|
||||
the nbd-server has been successfully ported to other operating
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ blkio-controller.txt
|
|||
- Description for Block IO Controller, implementation and usage details.
|
||||
cgroups.txt
|
||||
- Control Groups definition, implementation details, examples and API.
|
||||
cgroup_event_listener.c
|
||||
- A user program for cgroup listener.
|
||||
cpuacct.txt
|
||||
- CPU Accounting Controller; account CPU usage for groups of tasks.
|
||||
cpusets.txt
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ Throttling/Upper Limit policy
|
|||
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
|
||||
|
||||
- Specify a bandwidth rate on particular device for root group. The format
|
||||
for policy is "<major>:<minor> <byes_per_second>".
|
||||
for policy is "<major>:<minor> <bytes_per_second>".
|
||||
|
||||
echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
|
||||
|
||||
|
|
@ -94,13 +94,11 @@ Throttling/Upper Limit policy
|
|||
|
||||
Hierarchical Cgroups
|
||||
====================
|
||||
- Currently none of the IO control policy supports hierarchical groups. But
|
||||
cgroup interface does allow creation of hierarchical cgroups and internally
|
||||
IO policies treat them as flat hierarchy.
|
||||
- Currently only CFQ supports hierarchical groups. For throttling,
|
||||
cgroup interface does allow creation of hierarchical cgroups and
|
||||
internally it treats them as flat hierarchy.
|
||||
|
||||
So this patch will allow creation of cgroup hierarchcy but at the backend
|
||||
everything will be treated as flat. So if somebody created a hierarchy like
|
||||
as follows.
|
||||
If somebody created a hierarchy like as follows.
|
||||
|
||||
root
|
||||
/ \
|
||||
|
|
@ -108,16 +106,20 @@ Hierarchical Cgroups
|
|||
|
|
||||
test3
|
||||
|
||||
CFQ and throttling will practically treat all groups at same level.
|
||||
CFQ will handle the hierarchy correctly but and throttling will
|
||||
practically treat all groups at same level. For details on CFQ
|
||||
hierarchy support, refer to Documentation/block/cfq-iosched.txt.
|
||||
Throttling will treat the hierarchy as if it looks like the
|
||||
following.
|
||||
|
||||
pivot
|
||||
/ / \ \
|
||||
root test1 test2 test3
|
||||
|
||||
Down the line we can implement hierarchical accounting/control support
|
||||
and also introduce a new cgroup file "use_hierarchy" which will control
|
||||
whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
|
||||
This is how memory controller also has implemented the things.
|
||||
Nesting cgroups, while allowed, isn't officially supported and blkio
|
||||
genereates warning when cgroups nest. Once throttling implements
|
||||
hierarchy support, hierarchy will be supported and the warning will
|
||||
be removed.
|
||||
|
||||
Various user visible config options
|
||||
===================================
|
||||
|
|
@ -172,6 +174,12 @@ Proportional weight policy files
|
|||
dev weight
|
||||
8:16 300
|
||||
|
||||
- blkio.leaf_weight[_device]
|
||||
- Equivalents of blkio.weight[_device] for the purpose of
|
||||
deciding how much weight tasks in the given cgroup has while
|
||||
competing with the cgroup's child cgroups. For details,
|
||||
please refer to Documentation/block/cfq-iosched.txt.
|
||||
|
||||
- blkio.time
|
||||
- disk time allocated to cgroup per device in milliseconds. First
|
||||
two fields specify the major and minor number of the device and
|
||||
|
|
@ -279,6 +287,11 @@ Proportional weight policy files
|
|||
and minor number of the device and third field specifies the number
|
||||
of times a group was dequeued from a particular device.
|
||||
|
||||
- blkio.*_recursive
|
||||
- Recursive version of various stats. These files show the
|
||||
same information as their non-recursive counterparts but
|
||||
include stats from all the descendant cgroups.
|
||||
|
||||
Throttling/Upper limit policy files
|
||||
-----------------------------------
|
||||
- blkio.throttle.read_bps_device
|
||||
|
|
|
|||
|
|
@ -399,8 +399,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||
|
||||
9.10 Memory thresholds
|
||||
Memory controller implements memory thresholds using cgroups notification
|
||||
API. You can use Documentation/cgroups/cgroup_event_listener.c to test
|
||||
it.
|
||||
API. You can use tools/cgroup/cgroup_event_listener.c to test it.
|
||||
|
||||
(Shell-A) Create cgroup and run event listener
|
||||
# mkdir /cgroup/A
|
||||
|
|
|
|||
|
|
@ -87,6 +87,10 @@ As any static code analyzer, Coccinelle produces false
|
|||
positives. Thus, reports must be carefully checked, and patches
|
||||
reviewed.
|
||||
|
||||
To enable verbose messages set the V= variable, for example:
|
||||
|
||||
make coccicheck MODE=report V=1
|
||||
|
||||
|
||||
Using Coccinelle with a single semantic patch
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -111,6 +111,12 @@ policy->governor must contain the "default policy" for
|
|||
For setting some of these values, the frequency table helpers might be
|
||||
helpful. See the section 2 for more information on them.
|
||||
|
||||
SMP systems normally have same clock source for a group of cpus. For these the
|
||||
.init() would be called only once for the first online cpu. Here the .init()
|
||||
routine must initialize policy->cpus with mask of all possible cpus (Online +
|
||||
Offline) that share the clock. Then the core would copy this mask onto
|
||||
policy->related_cpus and will reset policy->cpus to carry only online cpus.
|
||||
|
||||
|
||||
1.3 verify
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -190,11 +190,11 @@ scaling_max_freq show the current "policy limits" (in
|
|||
first set scaling_max_freq, then
|
||||
scaling_min_freq.
|
||||
|
||||
affected_cpus : List of CPUs that require software coordination
|
||||
of frequency.
|
||||
affected_cpus : List of Online CPUs that require software
|
||||
coordination of frequency.
|
||||
|
||||
related_cpus : List of CPUs that need some sort of frequency
|
||||
coordination, whether software or hardware.
|
||||
related_cpus : List of Online + Offline CPUs that need software
|
||||
coordination of frequency.
|
||||
|
||||
scaling_driver : Hardware driver for cpufreq.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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: Striped Mirrors (aka 'Striping on top of mirrors')
|
||||
- RAID1E: Integrated Adjacent Stripe Mirroring
|
||||
- RAID1E: Integrated Offset Stripe Mirroring
|
||||
- and other similar RAID10 variants
|
||||
|
||||
Reference: Chapter 4 of
|
||||
|
|
@ -64,15 +65,15 @@ The target is named "raid" and it accepts the following parameters:
|
|||
synchronisation state for each region.
|
||||
|
||||
[raid10_copies <# copies>]
|
||||
[raid10_format near]
|
||||
[raid10_format <near|far|offset>]
|
||||
These two options are used to alter the default layout of
|
||||
a RAID10 configuration. The number of copies is can be
|
||||
specified, but the default is 2. There are other variations
|
||||
to how the copies are laid down - the default and only current
|
||||
option is "near". Near copies are what most people think of
|
||||
with respect to mirroring. If these options are left
|
||||
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
|
||||
are given, then the layouts for 2, 3 and 4 devices are:
|
||||
specified, but the default is 2. There are also three
|
||||
variations to how the copies are laid down - the default
|
||||
is "near". Near copies are what most people think of with
|
||||
respect to mirroring. If these options are left unspecified,
|
||||
or 'raid10_copies 2' and/or 'raid10_format near' are given,
|
||||
then the layouts for 2, 3 and 4 devices are:
|
||||
2 drives 3 drives 4 drives
|
||||
-------- ---------- --------------
|
||||
A1 A1 A1 A1 A2 A1 A1 A2 A2
|
||||
|
|
@ -85,6 +86,33 @@ The target is named "raid" and it accepts the following parameters:
|
|||
3-device layout is what might be called a 'RAID1E - Integrated
|
||||
Adjacent Stripe Mirroring'.
|
||||
|
||||
If 'raid10_copies 2' and 'raid10_format far', then the layouts
|
||||
for 2, 3 and 4 devices are:
|
||||
2 drives 3 drives 4 drives
|
||||
-------- -------------- --------------------
|
||||
A1 A2 A1 A2 A3 A1 A2 A3 A4
|
||||
A3 A4 A4 A5 A6 A5 A6 A7 A8
|
||||
A5 A6 A7 A8 A9 A9 A10 A11 A12
|
||||
.. .. .. .. .. .. .. .. ..
|
||||
A2 A1 A3 A1 A2 A2 A1 A4 A3
|
||||
A4 A3 A6 A4 A5 A6 A5 A8 A7
|
||||
A6 A5 A9 A7 A8 A10 A9 A12 A11
|
||||
.. .. .. .. .. .. .. .. ..
|
||||
|
||||
If 'raid10_copies 2' and 'raid10_format offset', then the
|
||||
layouts for 2, 3 and 4 devices are:
|
||||
2 drives 3 drives 4 drives
|
||||
-------- ------------ -----------------
|
||||
A1 A2 A1 A2 A3 A1 A2 A3 A4
|
||||
A2 A1 A3 A1 A2 A2 A1 A4 A3
|
||||
A3 A4 A4 A5 A6 A5 A6 A7 A8
|
||||
A4 A3 A6 A4 A5 A6 A5 A8 A7
|
||||
A5 A6 A7 A8 A9 A9 A10 A11 A12
|
||||
A6 A5 A9 A7 A8 A10 A9 A12 A11
|
||||
.. .. .. .. .. .. .. .. ..
|
||||
Here we see layouts closely akin to 'RAID1E - Integrated
|
||||
Offset Stripe Mirroring'.
|
||||
|
||||
<#raid_devs>: The number of devices composing the array.
|
||||
Each device consists of two entries. The first is the device
|
||||
containing the metadata (if any); the second is the one containing the
|
||||
|
|
@ -142,3 +170,5 @@ Version History
|
|||
1.3.0 Added support for RAID 10
|
||||
1.3.1 Allow device replacement/rebuild for RAID 10
|
||||
1.3.2 Fix/improve redundancy checking for RAID10
|
||||
1.4.0 Non-functional change. Removes arg from mapping function.
|
||||
1.4.1 Add RAID10 "far" and "offset" algorithm support.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
- compatible : "altr,sys-mgr"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- cpu1-start-addr : CPU1 start address in hex.
|
||||
|
||||
Example:
|
||||
sysmgr@ffd08000 {
|
||||
compatible = "altr,sys-mgr";
|
||||
reg = <0xffd08000 0x1000>;
|
||||
cpu1-start-addr = <0xffd080c4>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,13 +1,14 @@
|
|||
* ARM architected timer
|
||||
|
||||
ARM Cortex-A7 and Cortex-A15 have a per-core architected timer, which
|
||||
provides per-cpu timers.
|
||||
ARM cores may have a per-core architected timer, which provides per-cpu timers.
|
||||
|
||||
The timer is attached to a GIC to deliver its per-processor interrupts.
|
||||
|
||||
** Timer node properties:
|
||||
|
||||
- compatible : Should at least contain "arm,armv7-timer".
|
||||
- compatible : Should at least contain one of
|
||||
"arm,armv7-timer"
|
||||
"arm,armv8-timer"
|
||||
|
||||
- interrupts : Interrupt list for secure, non-secure, virtual and
|
||||
hypervisor timers, in that order.
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- interrupt-parent: For single AIC system, it is an empty property.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. It sould be 3.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
|
||||
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
|
||||
The second cell is used to specify flags:
|
||||
bits[3:0] trigger type and level flags:
|
||||
|
|
|
|||
|
|
@ -5,6 +5,14 @@ i.MX23 Evaluation Kit
|
|||
Required root node properties:
|
||||
- compatible = "fsl,imx23-evk", "fsl,imx23";
|
||||
|
||||
i.MX25 Product Development Kit
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx25-pdk", "fsl,imx25";
|
||||
|
||||
i.MX27 Product Development Kit
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx27-pdk", "fsl,imx27";
|
||||
|
||||
i.MX28 Evaluation Kit
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx28-evk", "fsl,imx28";
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ Main node required properties:
|
|||
|
||||
Optional
|
||||
- interrupts : Interrupt source of the parent interrupt controller on
|
||||
secondary GICs, or VGIC maintainance interrupt on primary GIC (see
|
||||
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
|
||||
below).
|
||||
|
||||
- cpu-offset : per-cpu offset within the distributor and cpu interface
|
||||
|
|
@ -74,7 +74,7 @@ Required properties:
|
|||
virtual interface control register base and size. The 2nd additional
|
||||
region is the GIC virtual cpu interface register base and size.
|
||||
|
||||
- interrupts : VGIC maintainance interrupt.
|
||||
- interrupts : VGIC maintenance interrupt.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
|
||||
|
||||
- OMAP4 SDP : Software Developement Board
|
||||
- OMAP4 SDP : Software Development Board
|
||||
compatible = "ti,omap4-sdp", "ti,omap4430"
|
||||
|
||||
- OMAP4 PandaBoard : Low cost community board
|
||||
compatible = "ti,omap4-panda", "ti,omap4430"
|
||||
|
||||
- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x
|
||||
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
|
||||
compatible = "ti,omap3-evm", "ti,omap3"
|
||||
|
||||
- AM335X EVM : Software Developement Board for AM335x
|
||||
- AM335X EVM : Software Development Board for AM335x
|
||||
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
|
||||
|
||||
- AM335X Bone : Low cost community board
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
- 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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-------------------------------------------
|
||||
|
||||
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:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8650";
|
||||
|
||||
Boards with the Wondermedia WM8750 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8750";
|
||||
|
||||
Boards with the Wondermedia WM8850 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8850";
|
||||
|
|
|
|||
|
|
@ -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 */
|
||||
};
|
||||
|
|
@ -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
|
||||
can1_serial_gate 157
|
||||
can1_ipg_gate 158
|
||||
owire_gate 159
|
||||
|
||||
Examples (for mx53):
|
||||
|
||||
|
|
|
|||
|
|
@ -203,6 +203,8 @@ clocks and IDs.
|
|||
pcie_ref 188
|
||||
pcie_ref_125m 189
|
||||
enet_ref 190
|
||||
usbphy1_gate 191
|
||||
usbphy2_gate 192
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ ID Clock Peripheral
|
|||
16 xor1 XOR DMA 1
|
||||
17 crypto CESA engine
|
||||
18 pex1 PCIe Cntrl 1
|
||||
19 ge1 Gigabit Ethernet 0
|
||||
19 ge1 Gigabit Ethernet 1
|
||||
20 tdm Time Division Mplx
|
||||
|
||||
Required properties:
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -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
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0". Also includes SEC
|
||||
ERA versions (optional) with which the device is compatible.
|
||||
Definition: Must include "fsl,sec-v4.0"
|
||||
|
||||
- fsl,sec-era
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Define the 'ERA' of the SEC
|
||||
device.
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
|
|
@ -107,7 +112,8 @@ PROPERTIES
|
|||
|
||||
EXAMPLE
|
||||
crypto@300000 {
|
||||
compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
|
||||
compatible = "fsl,sec-v4.0";
|
||||
fsl,sec-era = <2>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x300000 0x10000>;
|
||||
|
|
|
|||
|
|
@ -10,7 +10,11 @@ Required properties:
|
|||
- interrupts: interrupt number to the cpu.
|
||||
|
||||
Optional properties:
|
||||
- dma-coherent : Present if dma operations are coherent
|
||||
- dma-coherent : Present if dma operations are coherent
|
||||
- #dma-cells: must be <1>. used to represent the number of integer
|
||||
cells in the dmas property of client device.
|
||||
- dma-channels: contains the total number of DMA channels supported by the DMAC
|
||||
- dma-requests: contains the total number of DMA requests supported by the DMAC
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -18,16 +22,23 @@ Example:
|
|||
compatible = "arm,pl330", "arm,primecell";
|
||||
reg = <0x12680000 0x1000>;
|
||||
interrupts = <99>;
|
||||
#dma-cells = <1>;
|
||||
#dma-channels = <8>;
|
||||
#dma-requests = <32>;
|
||||
};
|
||||
|
||||
Client drivers (device nodes requiring dma transfers from dev-to-mem or
|
||||
mem-to-dev) should specify the DMA channel numbers using a two-value pair
|
||||
mem-to-dev) should specify the DMA channel numbers and dma channel names
|
||||
as shown below.
|
||||
|
||||
[property name] = <[phandle of the dma controller] [dma request id]>;
|
||||
[property name] = <[dma channel name]>
|
||||
|
||||
where 'dma request id' is the dma request number which is connected
|
||||
to the client controller. The 'property name' is recommended to be
|
||||
of the form <name>-dma-channel.
|
||||
to the client controller. The 'property name' 'dmas' and 'dma-names'
|
||||
as required by the generic dma device tree binding helpers. The dma
|
||||
names correspond 1:1 with the dma request ids in the dmas property.
|
||||
|
||||
Example: tx-dma-channel = <&pdma0 12>;
|
||||
Example: dmas = <&pdma0 12
|
||||
&pdma1 11>;
|
||||
dma-names = "tx", "rx";
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
- compatible: "snps,dma-spear1340"
|
||||
- reg: Address range of the DMAC registers
|
||||
- interrupt: Should contain the DMAC interrupt number
|
||||
- dma-channels: Number of channels supported by hardware
|
||||
- dma-requests: Number of DMA request lines supported, up to 16
|
||||
- dma-masters: Number of AHB masters supported by the controller
|
||||
- #dma-cells: must be <3>
|
||||
- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
|
||||
1: descending
|
||||
- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
|
||||
increase from chan n->0
|
||||
- block_size: Maximum block size supported by the controller
|
||||
- data_width: Maximum data width supported by hardware per AHB master
|
||||
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
|
||||
|
||||
|
||||
Optional properties:
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupt: Should contain the DMAC interrupt number
|
||||
- is_private: The device channels should be marked as private and not for by the
|
||||
general purpose DMA channel allocator. False if not passed.
|
||||
|
||||
Example:
|
||||
|
||||
dma@fc000000 {
|
||||
dmahost: dma@fc000000 {
|
||||
compatible = "snps,dma-spear1340";
|
||||
reg = <0xfc000000 0x1000>;
|
||||
interrupt-parent = <&vic1>;
|
||||
interrupts = <12>;
|
||||
|
||||
dma-channels = <8>;
|
||||
dma-requests = <16>;
|
||||
dma-masters = <2>;
|
||||
#dma-cells = <3>;
|
||||
chan_allocation_order = <1>;
|
||||
chan_priority = <1>;
|
||||
block_size = <0xfff>;
|
||||
data_width = <3 3 0 0>;
|
||||
};
|
||||
|
||||
DMA clients connected to the Designware DMA controller must use the format
|
||||
described in the dma.txt file, using a four-cell specifier for each channel.
|
||||
The four cells in order are:
|
||||
|
||||
1. A phandle pointing to the DMA controller
|
||||
2. The DMA request line number
|
||||
3. Source master for transfers on allocated channel
|
||||
4. Destination master for transfers on allocated channel
|
||||
|
||||
Example:
|
||||
|
||||
serial@e0000000 {
|
||||
compatible = "arm,pl011", "arm,primecell";
|
||||
reg = <0xe0000000 0x1000>;
|
||||
interrupts = <0 35 0x4>;
|
||||
status = "disabled";
|
||||
dmas = <&dmahost 12 0 1>,
|
||||
<&dmahost 13 0 1 0>;
|
||||
dma-names = "rx", "rx";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue