Merge branch 'next' into for-linus

Prepare first round of input updates for 3.20.
This commit is contained in:
Dmitry Torokhov 2015-02-10 11:35:36 -08:00
commit 4ba24fef3e
15535 changed files with 885934 additions and 622720 deletions

3
.gitignore vendored
View File

@ -96,3 +96,6 @@ x509.genkey
# Kconfig presets
all.config
# Kdevelop4
*.kdev4

View File

@ -17,7 +17,7 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com>
Al Viro <viro@ftp.linux.org.uk>
Al Viro <viro@zenIV.linux.org.uk>
Andreas Herrmann <aherrman@de.ibm.com>
Andrew Morton <akpm@osdl.org>
Andrew Morton <akpm@linux-foundation.org>
Andrew Vasquez <andrew.vasquez@qlogic.com>
Andy Adamson <andros@citi.umich.edu>
Archit Taneja <archit@ti.com>
@ -51,6 +51,7 @@ Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman <greg@kroah.com>
Henk Vergonet <Henk.Vergonet@gmail.com>
Henrik Kretzschmar <henne@nachtwindheim.de>
Henrik Rydberg <rydberg@bitmath.org>
Herbert Xu <herbert@gondor.apana.org.au>
Jacob Shin <Jacob.Shin@amd.com>
James Bottomley <jejb@mulgrave.(none)>
@ -102,6 +103,8 @@ Rudolf Marek <R.Marek@sh.cvut.cz>
Rui Saraiva <rmps@joel.ist.utl.pt>
Sachin P Sant <ssant@in.ibm.com>
Sam Ravnborg <sam@mars.ravnborg.org>
Santosh Shilimkar <ssantosh@kernel.org>
Santosh Shilimkar <santosh.shilimkar@oracle.org>
Sascha Hauer <s.hauer@pengutronix.de>
S.Çağlar Onur <caglar@pardus.org.tr>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>

13
CREDITS
View File

@ -1197,6 +1197,13 @@ S: R. Tocantins, 89 - Cristo Rei
S: 80050-430 - Curitiba - Paraná
S: Brazil
N: Oded Gabbay
E: oded.gabbay@gmail.com
D: AMD KFD maintainer
S: 12 Shraga Raphaeli
S: Petah-Tikva, 4906418
S: Israel
N: Kumar Gala
E: galak@kernel.crashing.org
D: Embedded PowerPC 6xx/7xx/74xx/82xx/83xx/85xx support
@ -1727,14 +1734,14 @@ S: Chapel Hill, North Carolina 27514-4818
S: USA
N: Dave Jones
E: davej@redhat.com
E: davej@codemonkey.org.uk
W: http://www.codemonkey.org.uk
D: Assorted VIA x86 support.
D: 2.5 AGPGART overhaul.
D: CPUFREQ maintenance.
D: Fedora kernel maintenance.
D: Fedora kernel maintenance (2003-2014).
D: 'Trinity' and similar fuzz testing work.
D: Misc/Other.
S: 314 Littleton Rd, Westford, MA 01886, USA
N: Martin Josfsson
E: gandalf@wlug.westbo.se

View File

@ -1,7 +0,0 @@
filesystems/dnotify_test
laptops/dslm
timers/hpet_example
vm/hugepage-mmap
vm/hugepage-shm
vm/map_hugetlb

View File

@ -287,6 +287,8 @@ local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.txt
- documentation on the runtime locking correctness validator.
locking/
- directory with info about kernel locking primitives
lockstat.txt
- info on collecting statistics on locks (and contention).
lockup-watchdogs.txt

View File

@ -0,0 +1,8 @@
What: tcp_dma_copybreak sysctl
Date: Removed in kernel v3.13
Contact: Dan Williams <dan.j.williams@intel.com>
Description:
Formerly the lower limit, in bytes, of the size of socket reads
that will be offloaded to a DMA copy engine. Removed due to
coherency issues of the cpu potentially touching the buffers
while dma is in flight.

View File

@ -32,10 +32,9 @@ Date: January 2008
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
If CONFIG_PM_RUNTIME is enabled then this file
is present. When read, it returns the total time (in msec)
that the USB device has been connected to the machine. This
file is read-only.
If CONFIG_PM is enabled, then this file is present. When read,
it returns the total time (in msec) that the USB device has been
connected to the machine. This file is read-only.
Users:
PowerTOP <powertop@lists.01.org>
https://01.org/powertop/
@ -45,10 +44,9 @@ Date: January 2008
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
If CONFIG_PM_RUNTIME is enabled then this file
is present. When read, it returns the total time (in msec)
that the USB device has been active, i.e. not in a suspended
state. This file is read-only.
If CONFIG_PM is enabled, then this file is present. When read,
it returns the total time (in msec) that the USB device has been
active, i.e. not in a suspended state. This file is read-only.
Tools can use this file and the connected_duration file to
compute the percentage of time that a device has been active.

View File

@ -0,0 +1,93 @@
What: /sys/class/udc/<udc>/a_alt_hnp_support
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates if an OTG A-Host supports HNP at an alternate port.
Users:
What: /sys/class/udc/<udc>/a_hnp_support
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates if an OTG A-Host supports HNP at this port.
Users:
What: /sys/class/udc/<udc>/b_hnp_enable
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates if an OTG A-Host enabled HNP support.
Users:
What: /sys/class/udc/<udc>/current_speed
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates the current negotiated speed at this port.
Users:
What: /sys/class/udc/<udc>/is_a_peripheral
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates that this port is the default Host on an OTG session
but HNP was used to switch roles.
Users:
What: /sys/class/udc/<udc>/is_otg
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates that this port support OTG.
Users:
What: /sys/class/udc/<udc>/maximum_speed
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates the maximum USB speed supported by this port.
Users:
What: /sys/class/udc/<udc>/maximum_speed
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates the maximum USB speed supported by this port.
Users:
What: /sys/class/udc/<udc>/soft_connect
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Allows users to disconnect data pullup resistors thus causing a
logical disconnection from the USB Host.
Users:
What: /sys/class/udc/<udc>/srp
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Allows users to manually start Session Request Protocol.
Users:
What: /sys/class/udc/<udc>/state
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates current state of the USB Device Controller. Valid
states are: 'not-attached', 'attached', 'powered',
'reconnecting', 'unauthenticated', 'default', 'addressed',
'configured', and 'suspended'; however not all USB Device
Controllers support reporting all states.
Users:

View File

@ -85,14 +85,6 @@ Description:
will be compacted. When it completes, memory will be freed
into blocks which have as many contiguous pages as possible
What: /sys/devices/system/node/nodeX/scan_unevictable_pages
Date: October 2008
Contact: Lee Schermerhorn <lee.schermerhorn@hp.com>
Description:
When set, it triggers scanning the node's unevictable lists
and move any pages that have become evictable onto the respective
zone's inactive list. See mm/vmscan.c
What: /sys/devices/system/node/nodeX/hugepages/hugepages-<size>/
Date: December 2009
Contact: Lee Schermerhorn <lee.schermerhorn@hp.com>

View File

@ -55,12 +55,12 @@ Description: Interface for making ib_srp connect to a new target.
only safe with partial memory descriptor list support enabled
(allow_ext_sg=1).
* comp_vector, a number in the range 0..n-1 specifying the
MSI-X completion vector. Some HCA's allocate multiple (n)
MSI-X vectors per HCA port. If the IRQ affinity masks of
these interrupts have been configured such that each MSI-X
interrupt is handled by a different CPU then the comp_vector
parameter can be used to spread the SRP completion workload
over multiple CPU's.
MSI-X completion vector of the first RDMA channel. Some
HCA's allocate multiple (n) MSI-X vectors per HCA port. If
the IRQ affinity masks of these interrupts have been
configured such that each MSI-X interrupt is handled by a
different CPU then the comp_vector parameter can be used to
spread the SRP completion workload over multiple CPU's.
* tl_retry_count, a number in the range 2..7 specifying the
IB RC retry count.
* queue_size, the maximum number of commands that the
@ -88,6 +88,13 @@ Description: Whether ib_srp is allowed to include a partial memory
descriptor list in an SRP_CMD when communicating with an SRP
target.
What: /sys/class/scsi_host/host<n>/ch_count
Date: April 1, 2015
KernelVersion: 3.19
Contact: linux-rdma@vger.kernel.org
Description: Number of RDMA channels used for communication with the SRP
target.
What: /sys/class/scsi_host/host<n>/cmd_sg_entries
Date: May 19, 2011
KernelVersion: 2.6.39
@ -95,6 +102,12 @@ Contact: linux-rdma@vger.kernel.org
Description: Maximum number of data buffer descriptors that may be sent to
the target in a single SRP_CMD request.
What: /sys/class/scsi_host/host<n>/comp_vector
Date: September 2, 2013
KernelVersion: 3.11
Contact: linux-rdma@vger.kernel.org
Description: Completion vector used for the first RDMA channel.
What: /sys/class/scsi_host/host<n>/dgid
Date: June 17, 2006
KernelVersion: 2.6.17

View File

@ -0,0 +1,11 @@
What: /config/usb-gadget/gadget/functions/hid.name
Date: Nov 2014
KernelVersion: 3.19
Description:
The attributes:
protocol - HID protocol to use
report_desc - blob corresponding to HID report descriptors
except the data passed through /dev/hidg<N>
report_length - HID report length
subclass - HID device subclass to use

View File

@ -0,0 +1,12 @@
What: /config/usb-gadget/gadget/functions/midi.name
Date: Nov 2014
KernelVersion: 3.19
Description:
The attributes:
index - index value for the USB MIDI adapter
id - ID string for the USB MIDI adapter
buflen - MIDI buffer length
qlen - USB read request queue length
in_ports - number of MIDI input ports
out_ports - number of MIDI output ports

View File

@ -0,0 +1,12 @@
What: /config/usb-gadget/gadget/functions/uac1.name
Date: Sep 2014
KernelVersion: 3.18
Description:
The attributes:
audio_buf_size - audio buffer size
fn_cap - capture pcm device file name
fn_cntl - control device file name
fn_play - playback pcm device file name
req_buf_size - ISO OUT endpoint request buffer size
req_count - ISO OUT endpoint request count

View File

@ -0,0 +1,12 @@
What: /config/usb-gadget/gadget/functions/uac2.name
Date: Sep 2014
KernelVersion: 3.18
Description:
The attributes:
c_chmask - capture channel mask
c_srate - capture sampling rate
c_ssize - capture sample size (bytes)
p_chmask - playback channel mask
p_srate - playback sampling rate
p_ssize - playback sample size (bytes)

View File

@ -53,6 +53,14 @@ Description:
512 bytes of data.
What: /sys/block/<disk>/integrity/device_is_integrity_capable
Date: July 2014
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether a storage device is capable of storing
integrity metadata. Set if the device is T10 PI-capable.
What: /sys/block/<disk>/integrity/write_generate
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>

View File

@ -77,11 +77,14 @@ What: /sys/block/zram<id>/notify_free
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The notify_free file is read-only and specifies the number of
swap slot free notifications received by this device. These
notifications are sent to a swap block device when a swap slot
is freed. This statistic is applicable only when this disk is
being used as a swap disk.
The notify_free file is read-only. Depending on device usage
scenario it may account a) the number of pages freed because
of swap slot free notifications or b) the number of pages freed
because of REQ_DISCARD requests sent by bio. The former ones
are sent to a swap block device when a swap slot is freed, which
implies that this disk is being used as a swap disk. The latter
ones are sent by filesystem mounted with discard option,
whenever some data blocks are getting discarded.
What: /sys/block/zram<id>/zero_pages
Date: August 2010
@ -119,3 +122,22 @@ Description:
efficiency can be calculated using compr_data_size and this
statistic.
Unit: bytes
What: /sys/block/zram<id>/mem_used_max
Date: August 2014
Contact: Minchan Kim <minchan@kernel.org>
Description:
The mem_used_max file is read/write and specifies the amount
of maximum memory zram have consumed to store compressed data.
For resetting the value, you should write "0". Otherwise,
you could see -EINVAL.
Unit: bytes
What: /sys/block/zram<id>/mem_limit
Date: August 2014
Contact: Minchan Kim <minchan@kernel.org>
Description:
The mem_limit file is read/write and specifies the maximum
amount of memory ZRAM can use to store the compressed data. The
limit could be changed in run time and "0" means disable the
limit. No limit is the initial state. Unit: bytes

View File

@ -0,0 +1,24 @@
What: /sys/bus/coresight/devices/<memory_map>.etb/enable_sink
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Add/remove a sink from a trace path. There can be multiple
source for a single sink.
ex: echo 1 > /sys/bus/coresight/devices/20010000.etb/enable_sink
What: /sys/bus/coresight/devices/<memory_map>.etb/status
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) List various control and status registers. The specific
layout and content is driver specific.
What: /sys/bus/coresight/devices/<memory_map>.etb/trigger_cntr
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Disables write access to the Trace RAM by stopping the
formatter after a defined number of words have been stored
following the trigger event. The number of 32-bit words written
into the Trace RAM following the trigger event is equal to the
value stored in this register+1 (from ARM ETB-TRM).

View File

@ -0,0 +1,253 @@
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/enable_source
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Enable/disable tracing on this specific trace entiry.
Enabling a source implies the source has been configured
properly and a sink has been identidifed for it. The path
of coresight components linking the source to the sink is
configured and managed automatically by the coresight framework.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/status
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) List various control and status registers. The specific
layout and content is driver specific.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_idx
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: Select which address comparator or pair (of comparators) to
work with.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_acctype
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies
characteristics about the address comparator being configure,
for example the access type, the kind of instruction to trace,
processor contect ID to trigger on, etc. Individual fields in
the access type register may vary on the version of the trace
entity.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_range
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the range of
addresses to trigger on. Inclusion or exclusion is specificed
in the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_single
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the single
address to trigger on, highly influenced by the configuration
options of the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_start
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the single
address to start tracing on, highly influenced by the
configuration options of the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_stop
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the single
address to stop tracing on, highly influenced by the
configuration options of the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_idx
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Specifies the counter to work on.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with cntr_idx, give access to the
counter event register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_val
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with cntr_idx, give access to the
counter value register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_rld_val
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with cntr_idx, give access to the
counter reload value register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_rld_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with cntr_idx, give access to the
counter reload event register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_idx
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Specifies the index of the context ID register to be
selected.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_mask
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask to apply to all the context ID comparator.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_val
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used with the ctxid_idx, specify with context ID to trigger
on.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/enable_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines which event triggers a trace.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/etmsr
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Gives access to the ETM status register, which holds
programming information and status on certains events.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/fifofull_level
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Number of byte left in the fifo before considering it full.
Depending on the tracer's version, can also hold threshold for
data suppression.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mode
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Interface with the driver's 'mode' field, controlling
various aspect of the trace entity such as time stamping,
context ID size and cycle accurate tracing. Driver specific
and bound to change depending on the driver.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_addr_cmp
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Provides the number of address comparators pairs accessible
on a trace unit, as specified by bit 3:0 of register ETMCCR.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_cntr
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Provides the number of counters accessible on a trace unit,
as specified by bit 15:13 of register ETMCCR.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_ctxid_cmp
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Provides the number of context ID comparator available on a
trace unit, as specified by bit 25:24 of register ETMCCR.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/reset
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (W) Cancels all configuration on a trace unit and set it back
to its boot configuration.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_12_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 1 to state 2.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_13_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 1 to state 3.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_21_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 2 to state 1.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_23_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 2 to state 3.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_31_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 3 to state 1.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_32_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 3 to state 2.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/curr_seq_state
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Holds the current state of the sequencer.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/sync_freq
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Holds the trace synchronization frequency value - must be
programmed with the various implementation behavior in mind.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/timestamp_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines an event that requests the insertion of a timestamp
into the trace stream.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/traceid
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Holds the trace ID that will appear in the trace stream
coming from this trace entity.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/trigger_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Define the event that controls the trigger.

View File

@ -0,0 +1,12 @@
What: /sys/bus/coresight/devices/<memory_map>.funnel/funnel_ctrl
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Enables the slave ports and defines the hold time of the
slave ports.
What: /sys/bus/coresight/devices/<memory_map>.funnel/priority
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines input port priority order.

View File

@ -0,0 +1,8 @@
What: /sys/bus/coresight/devices/<memory_map>.tmc/trigger_cntr
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Disables write access to the Trace RAM by stopping the
formatter after a defined number of words have been stored
following the trigger event. Additional interface for this
driver are expected to be added as it matures.

View File

@ -27,575 +27,62 @@ Description: Generic performance monitoring events
"basename".
What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
/sys/devices/cpu/events/PM_BRU_FIN
/sys/devices/cpu/events/PM_BR_MPRED
/sys/devices/cpu/events/PM_CMPLU_STALL
/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
/sys/devices/cpu/events/PM_CMPLU_STALL_DFU
/sys/devices/cpu/events/PM_CMPLU_STALL_DIV
/sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS
/sys/devices/cpu/events/PM_CMPLU_STALL_FXU
/sys/devices/cpu/events/PM_CMPLU_STALL_IFU
/sys/devices/cpu/events/PM_CMPLU_STALL_LSU
/sys/devices/cpu/events/PM_CMPLU_STALL_REJECT
/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR
/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG
/sys/devices/cpu/events/PM_CMPLU_STALL_STORE
/sys/devices/cpu/events/PM_CMPLU_STALL_THRD
/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR
/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG
/sys/devices/cpu/events/PM_CYC
/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED
/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS
/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
/sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS
/sys/devices/cpu/events/PM_GRP_CMPL
/sys/devices/cpu/events/PM_INST_CMPL
/sys/devices/cpu/events/PM_LD_MISS_L1
/sys/devices/cpu/events/PM_LD_REF_L1
/sys/devices/cpu/events/PM_RUN_CYC
/sys/devices/cpu/events/PM_RUN_INST_CMPL
/sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_ALL
/sys/devices/cpu/events/PM_GCT_UTIL_7_TO_10_SLOTS
/sys/devices/cpu/events/PM_PMC2_SAVED
/sys/devices/cpu/events/PM_VSU0_16FLOP
/sys/devices/cpu/events/PM_MRK_LSU_DERAT_MISS
/sys/devices/cpu/events/PM_MRK_ST_CMPL
/sys/devices/cpu/events/PM_NEST_PAIR3_ADD
/sys/devices/cpu/events/PM_L2_ST_DISP
/sys/devices/cpu/events/PM_L2_CASTOUT_MOD
/sys/devices/cpu/events/PM_ISEG
/sys/devices/cpu/events/PM_MRK_INST_TIMEO
/sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_ADDR
/sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM
/sys/devices/cpu/events/PM_IERAT_WR_64K
/sys/devices/cpu/events/PM_MRK_DTLB_MISS_16M
/sys/devices/cpu/events/PM_IERAT_MISS
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_LMEM
/sys/devices/cpu/events/PM_FLOP
/sys/devices/cpu/events/PM_THRD_PRIO_4_5_CYC
/sys/devices/cpu/events/PM_BR_PRED_TA
/sys/devices/cpu/events/PM_EXT_INT
/sys/devices/cpu/events/PM_VSU_FSQRT_FDIV
/sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC
/sys/devices/cpu/events/PM_LSU1_LDF
/sys/devices/cpu/events/PM_IC_WRITE_ALL
/sys/devices/cpu/events/PM_LSU0_SRQ_STFWD
/sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_MOD
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR
/sys/devices/cpu/events/PM_DATA_FROM_L21_MOD
/sys/devices/cpu/events/PM_VSU1_SCAL_DOUBLE_ISSUED
/sys/devices/cpu/events/PM_VSU0_8FLOP
/sys/devices/cpu/events/PM_POWER_EVENT1
/sys/devices/cpu/events/PM_DISP_CLB_HELD_BAL
/sys/devices/cpu/events/PM_VSU1_2FLOP
/sys/devices/cpu/events/PM_LWSYNC_HELD
/sys/devices/cpu/events/PM_PTEG_FROM_DL2L3_SHR
/sys/devices/cpu/events/PM_INST_FROM_L21_MOD
/sys/devices/cpu/events/PM_IERAT_XLATE_WR_16MPLUS
/sys/devices/cpu/events/PM_IC_REQ_ALL
/sys/devices/cpu/events/PM_DSLB_MISS
/sys/devices/cpu/events/PM_L3_MISS
/sys/devices/cpu/events/PM_LSU0_L1_PREF
/sys/devices/cpu/events/PM_VSU_SCALAR_SINGLE_ISSUED
/sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM_STRIDE
/sys/devices/cpu/events/PM_L2_INST
/sys/devices/cpu/events/PM_VSU0_FRSP
/sys/devices/cpu/events/PM_FLUSH_DISP
/sys/devices/cpu/events/PM_PTEG_FROM_L2MISS
/sys/devices/cpu/events/PM_VSU1_DQ_ISSUED
/sys/devices/cpu/events/PM_MRK_DATA_FROM_DMEM
/sys/devices/cpu/events/PM_LSU_FLUSH_ULD
/sys/devices/cpu/events/PM_PTEG_FROM_LMEM
/sys/devices/cpu/events/PM_MRK_DERAT_MISS_16M
/sys/devices/cpu/events/PM_THRD_ALL_RUN_CYC
/sys/devices/cpu/events/PM_MEM0_PREFETCH_DISP
/sys/devices/cpu/events/PM_MRK_STALL_CMPLU_CYC_COUNT
/sys/devices/cpu/events/PM_DATA_FROM_DL2L3_MOD
/sys/devices/cpu/events/PM_VSU_FRSP
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_MOD
/sys/devices/cpu/events/PM_PMC1_OVERFLOW
/sys/devices/cpu/events/PM_VSU0_SINGLE
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L3MISS
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L31_SHR
/sys/devices/cpu/events/PM_VSU0_VECTOR_SP_ISSUED
/sys/devices/cpu/events/PM_VSU1_FEST
/sys/devices/cpu/events/PM_MRK_INST_DISP
/sys/devices/cpu/events/PM_VSU0_COMPLEX_ISSUED
/sys/devices/cpu/events/PM_LSU1_FLUSH_UST
/sys/devices/cpu/events/PM_FXU_IDLE
/sys/devices/cpu/events/PM_LSU0_FLUSH_ULD
/sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_MOD
/sys/devices/cpu/events/PM_LSU_LMQ_SRQ_EMPTY_ALL_CYC
/sys/devices/cpu/events/PM_LSU1_REJECT_LMQ_FULL
/sys/devices/cpu/events/PM_INST_PTEG_FROM_L21_MOD
/sys/devices/cpu/events/PM_INST_FROM_RL2L3_MOD
/sys/devices/cpu/events/PM_SHL_CREATED
/sys/devices/cpu/events/PM_L2_ST_HIT
/sys/devices/cpu/events/PM_DATA_FROM_DMEM
/sys/devices/cpu/events/PM_L3_LD_MISS
/sys/devices/cpu/events/PM_FXU1_BUSY_FXU0_IDLE
/sys/devices/cpu/events/PM_DISP_CLB_HELD_RES
/sys/devices/cpu/events/PM_L2_SN_SX_I_DONE
/sys/devices/cpu/events/PM_STCX_CMPL
/sys/devices/cpu/events/PM_VSU0_2FLOP
/sys/devices/cpu/events/PM_L3_PREF_MISS
/sys/devices/cpu/events/PM_LSU_SRQ_SYNC_CYC
/sys/devices/cpu/events/PM_LSU_REJECT_ERAT_MISS
/sys/devices/cpu/events/PM_L1_ICACHE_MISS
/sys/devices/cpu/events/PM_LSU1_FLUSH_SRQ
/sys/devices/cpu/events/PM_LD_REF_L1_LSU0
/sys/devices/cpu/events/PM_VSU0_FEST
/sys/devices/cpu/events/PM_VSU_VECTOR_SINGLE_ISSUED
/sys/devices/cpu/events/PM_FREQ_UP
/sys/devices/cpu/events/PM_DATA_FROM_LMEM
/sys/devices/cpu/events/PM_LSU1_LDX
/sys/devices/cpu/events/PM_PMC3_OVERFLOW
/sys/devices/cpu/events/PM_MRK_BR_MPRED
/sys/devices/cpu/events/PM_SHL_MATCH
/sys/devices/cpu/events/PM_MRK_BR_TAKEN
/sys/devices/cpu/events/PM_ISLB_MISS
/sys/devices/cpu/events/PM_DISP_HELD_THERMAL
/sys/devices/cpu/events/PM_INST_PTEG_FROM_RL2L3_SHR
/sys/devices/cpu/events/PM_LSU1_SRQ_STFWD
/sys/devices/cpu/events/PM_PTEG_FROM_DMEM
/sys/devices/cpu/events/PM_VSU_2FLOP
/sys/devices/cpu/events/PM_GCT_FULL_CYC
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L3_CYC
/sys/devices/cpu/events/PM_LSU_SRQ_S0_ALLOC
/sys/devices/cpu/events/PM_MRK_DERAT_MISS_4K
/sys/devices/cpu/events/PM_BR_MPRED_TA
/sys/devices/cpu/events/PM_INST_PTEG_FROM_L2MISS
/sys/devices/cpu/events/PM_DPU_HELD_POWER
/sys/devices/cpu/events/PM_MRK_VSU_FIN
/sys/devices/cpu/events/PM_LSU_SRQ_S0_VALID
/sys/devices/cpu/events/PM_GCT_EMPTY_CYC
/sys/devices/cpu/events/PM_IOPS_DISP
/sys/devices/cpu/events/PM_RUN_SPURR
/sys/devices/cpu/events/PM_PTEG_FROM_L21_MOD
/sys/devices/cpu/events/PM_VSU0_1FLOP
/sys/devices/cpu/events/PM_SNOOP_TLBIE
/sys/devices/cpu/events/PM_DATA_FROM_L3MISS
/sys/devices/cpu/events/PM_VSU_SINGLE
/sys/devices/cpu/events/PM_DTLB_MISS_16G
/sys/devices/cpu/events/PM_FLUSH
/sys/devices/cpu/events/PM_L2_LD_HIT
/sys/devices/cpu/events/PM_NEST_PAIR2_AND
/sys/devices/cpu/events/PM_VSU1_1FLOP
/sys/devices/cpu/events/PM_IC_PREF_REQ
/sys/devices/cpu/events/PM_L3_LD_HIT
/sys/devices/cpu/events/PM_DISP_HELD
/sys/devices/cpu/events/PM_L2_LD
/sys/devices/cpu/events/PM_LSU_FLUSH_SRQ
/sys/devices/cpu/events/PM_BC_PLUS_8_CONV
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_MOD_CYC
/sys/devices/cpu/events/PM_L2_RCST_BUSY_RC_FULL
/sys/devices/cpu/events/PM_TB_BIT_TRANS
/sys/devices/cpu/events/PM_THERMAL_MAX
/sys/devices/cpu/events/PM_LSU1_FLUSH_ULD
/sys/devices/cpu/events/PM_LSU1_REJECT_LHS
/sys/devices/cpu/events/PM_LSU_LRQ_S0_ALLOC
/sys/devices/cpu/events/PM_L3_CO_L31
/sys/devices/cpu/events/PM_POWER_EVENT4
/sys/devices/cpu/events/PM_DATA_FROM_L31_SHR
/sys/devices/cpu/events/PM_BR_UNCOND
/sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_ALLOC
/sys/devices/cpu/events/PM_PMC4_REWIND
/sys/devices/cpu/events/PM_L2_RCLD_DISP
/sys/devices/cpu/events/PM_THRD_PRIO_2_3_CYC
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L2MISS
/sys/devices/cpu/events/PM_IC_DEMAND_L2_BHT_REDIRECT
/sys/devices/cpu/events/PM_DATA_FROM_L31_SHR
/sys/devices/cpu/events/PM_IC_PREF_CANCEL_L2
/sys/devices/cpu/events/PM_MRK_FIN_STALL_CYC_COUNT
/sys/devices/cpu/events/PM_BR_PRED_CCACHE
/sys/devices/cpu/events/PM_GCT_UTIL_1_TO_2_SLOTS
/sys/devices/cpu/events/PM_MRK_ST_CMPL_INT
/sys/devices/cpu/events/PM_LSU_TWO_TABLEWALK_CYC
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L3MISS
/sys/devices/cpu/events/PM_LSU_SET_MPRED
/sys/devices/cpu/events/PM_FLUSH_DISP_TLBIE
/sys/devices/cpu/events/PM_VSU1_FCONV
/sys/devices/cpu/events/PM_DERAT_MISS_16G
/sys/devices/cpu/events/PM_INST_FROM_LMEM
/sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_REDIRECT
/sys/devices/cpu/events/PM_INST_PTEG_FROM_L2
/sys/devices/cpu/events/PM_PTEG_FROM_L2
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_SHR_CYC
/sys/devices/cpu/events/PM_MRK_DTLB_MISS_4K
/sys/devices/cpu/events/PM_VSU0_FPSCR
/sys/devices/cpu/events/PM_VSU1_VECT_DOUBLE_ISSUED
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_RL2L3_MOD
/sys/devices/cpu/events/PM_MEM0_RQ_DISP
/sys/devices/cpu/events/PM_L2_LD_MISS
/sys/devices/cpu/events/PM_VMX_RESULT_SAT_1
/sys/devices/cpu/events/PM_L1_PREF
/sys/devices/cpu/events/PM_MRK_DATA_FROM_LMEM_CYC
/sys/devices/cpu/events/PM_GRP_IC_MISS_NONSPEC
/sys/devices/cpu/events/PM_PB_NODE_PUMP
/sys/devices/cpu/events/PM_SHL_MERGED
/sys/devices/cpu/events/PM_NEST_PAIR1_ADD
/sys/devices/cpu/events/PM_DATA_FROM_L3
/sys/devices/cpu/events/PM_LSU_FLUSH
/sys/devices/cpu/events/PM_LSU_SRQ_SYNC_COUNT
/sys/devices/cpu/events/PM_PMC2_OVERFLOW
/sys/devices/cpu/events/PM_LSU_LDF
/sys/devices/cpu/events/PM_POWER_EVENT3
/sys/devices/cpu/events/PM_DISP_WT
/sys/devices/cpu/events/PM_IC_BANK_CONFLICT
/sys/devices/cpu/events/PM_BR_MPRED_CR_TA
/sys/devices/cpu/events/PM_L2_INST_MISS
/sys/devices/cpu/events/PM_NEST_PAIR2_ADD
/sys/devices/cpu/events/PM_MRK_LSU_FLUSH
/sys/devices/cpu/events/PM_L2_LDST
/sys/devices/cpu/events/PM_INST_FROM_L31_SHR
/sys/devices/cpu/events/PM_VSU0_FIN
/sys/devices/cpu/events/PM_VSU1_FCONV
/sys/devices/cpu/events/PM_INST_FROM_RMEM
/sys/devices/cpu/events/PM_DISP_CLB_HELD_TLBIE
/sys/devices/cpu/events/PM_MRK_DATA_FROM_DMEM_CYC
/sys/devices/cpu/events/PM_BR_PRED_CR
/sys/devices/cpu/events/PM_LSU_REJECT
/sys/devices/cpu/events/PM_GCT_UTIL_3_TO_6_SLOTS
/sys/devices/cpu/events/PM_CMPLU_STALL_END_GCT_NOSLOT
/sys/devices/cpu/events/PM_LSU0_REJECT_LMQ_FULL
/sys/devices/cpu/events/PM_VSU_FEST
/sys/devices/cpu/events/PM_NEST_PAIR0_AND
/sys/devices/cpu/events/PM_PTEG_FROM_L3
/sys/devices/cpu/events/PM_POWER_EVENT2
/sys/devices/cpu/events/PM_IC_PREF_CANCEL_PAGE
/sys/devices/cpu/events/PM_VSU0_FSQRT_FDIV
/sys/devices/cpu/events/PM_MRK_GRP_CMPL
/sys/devices/cpu/events/PM_VSU0_SCAL_DOUBLE_ISSUED
/sys/devices/cpu/events/PM_GRP_DISP
/sys/devices/cpu/events/PM_LSU0_LDX
/sys/devices/cpu/events/PM_DATA_FROM_L2
/sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_MOD
/sys/devices/cpu/events/PM_VSU0_VECT_DOUBLE_ISSUED
/sys/devices/cpu/events/PM_VSU1_2FLOP_DOUBLE
/sys/devices/cpu/events/PM_THRD_PRIO_6_7_CYC
/sys/devices/cpu/events/PM_BC_PLUS_8_RSLV_TAKEN
/sys/devices/cpu/events/PM_BR_MPRED_CR
/sys/devices/cpu/events/PM_L3_CO_MEM
/sys/devices/cpu/events/PM_DATA_FROM_RL2L3_MOD
/sys/devices/cpu/events/PM_LSU_SRQ_FULL_CYC
/sys/devices/cpu/events/PM_TABLEWALK_CYC
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_RMEM
/sys/devices/cpu/events/PM_LSU_SRQ_STFWD
/sys/devices/cpu/events/PM_INST_PTEG_FROM_RMEM
/sys/devices/cpu/events/PM_FXU0_FIN
/sys/devices/cpu/events/PM_LSU1_L1_SW_PREF
/sys/devices/cpu/events/PM_PTEG_FROM_L31_MOD
/sys/devices/cpu/events/PM_PMC5_OVERFLOW
/sys/devices/cpu/events/PM_LD_REF_L1_LSU1
/sys/devices/cpu/events/PM_INST_PTEG_FROM_L21_SHR
/sys/devices/cpu/events/PM_DATA_FROM_RMEM
/sys/devices/cpu/events/PM_VSU0_SCAL_SINGLE_ISSUED
/sys/devices/cpu/events/PM_BR_MPRED_LSTACK
/sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_MOD_CYC
/sys/devices/cpu/events/PM_LSU0_FLUSH_UST
/sys/devices/cpu/events/PM_LSU_NCST
/sys/devices/cpu/events/PM_BR_TAKEN
/sys/devices/cpu/events/PM_INST_PTEG_FROM_LMEM
/sys/devices/cpu/events/PM_DTLB_MISS_4K
/sys/devices/cpu/events/PM_PMC4_SAVED
/sys/devices/cpu/events/PM_VSU1_PERMUTE_ISSUED
/sys/devices/cpu/events/PM_SLB_MISS
/sys/devices/cpu/events/PM_LSU1_FLUSH_LRQ
/sys/devices/cpu/events/PM_DTLB_MISS
/sys/devices/cpu/events/PM_VSU1_FRSP
/sys/devices/cpu/events/PM_VSU_VECTOR_DOUBLE_ISSUED
/sys/devices/cpu/events/PM_L2_CASTOUT_SHR
/sys/devices/cpu/events/PM_DATA_FROM_DL2L3_SHR
/sys/devices/cpu/events/PM_VSU1_STF
/sys/devices/cpu/events/PM_ST_FIN
/sys/devices/cpu/events/PM_PTEG_FROM_L21_SHR
/sys/devices/cpu/events/PM_L2_LOC_GUESS_WRONG
/sys/devices/cpu/events/PM_MRK_STCX_FAIL
/sys/devices/cpu/events/PM_LSU0_REJECT_LHS
/sys/devices/cpu/events/PM_IC_PREF_CANCEL_HIT
/sys/devices/cpu/events/PM_L3_PREF_BUSY
/sys/devices/cpu/events/PM_MRK_BRU_FIN
/sys/devices/cpu/events/PM_LSU1_NCLD
/sys/devices/cpu/events/PM_INST_PTEG_FROM_L31_MOD
/sys/devices/cpu/events/PM_LSU_NCLD
/sys/devices/cpu/events/PM_LSU_LDX
/sys/devices/cpu/events/PM_L2_LOC_GUESS_CORRECT
/sys/devices/cpu/events/PM_THRESH_TIMEO
/sys/devices/cpu/events/PM_L3_PREF_ST
/sys/devices/cpu/events/PM_DISP_CLB_HELD_SYNC
/sys/devices/cpu/events/PM_VSU_SIMPLE_ISSUED
/sys/devices/cpu/events/PM_VSU1_SINGLE
/sys/devices/cpu/events/PM_DATA_TABLEWALK_CYC
/sys/devices/cpu/events/PM_L2_RC_ST_DONE
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L21_MOD
/sys/devices/cpu/events/PM_LARX_LSU1
/sys/devices/cpu/events/PM_MRK_DATA_FROM_RMEM
/sys/devices/cpu/events/PM_DISP_CLB_HELD
/sys/devices/cpu/events/PM_DERAT_MISS_4K
/sys/devices/cpu/events/PM_L2_RCLD_DISP_FAIL_ADDR
/sys/devices/cpu/events/PM_SEG_EXCEPTION
/sys/devices/cpu/events/PM_FLUSH_DISP_SB
/sys/devices/cpu/events/PM_L2_DC_INV
/sys/devices/cpu/events/PM_PTEG_FROM_DL2L3_MOD
/sys/devices/cpu/events/PM_DSEG
/sys/devices/cpu/events/PM_BR_PRED_LSTACK
/sys/devices/cpu/events/PM_VSU0_STF
/sys/devices/cpu/events/PM_LSU_FX_FIN
/sys/devices/cpu/events/PM_DERAT_MISS_16M
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_DL2L3_MOD
/sys/devices/cpu/events/PM_GCT_UTIL_11_PLUS_SLOTS
/sys/devices/cpu/events/PM_INST_FROM_L3
/sys/devices/cpu/events/PM_MRK_IFU_FIN
/sys/devices/cpu/events/PM_ITLB_MISS
/sys/devices/cpu/events/PM_VSU_STF
/sys/devices/cpu/events/PM_LSU_FLUSH_UST
/sys/devices/cpu/events/PM_L2_LDST_MISS
/sys/devices/cpu/events/PM_FXU1_FIN
/sys/devices/cpu/events/PM_SHL_DEALLOCATED
/sys/devices/cpu/events/PM_L2_SN_M_WR_DONE
/sys/devices/cpu/events/PM_LSU_REJECT_SET_MPRED
/sys/devices/cpu/events/PM_L3_PREF_LD
/sys/devices/cpu/events/PM_L2_SN_M_RD_DONE
/sys/devices/cpu/events/PM_MRK_DERAT_MISS_16G
/sys/devices/cpu/events/PM_VSU_FCONV
/sys/devices/cpu/events/PM_ANY_THRD_RUN_CYC
/sys/devices/cpu/events/PM_LSU_LMQ_FULL_CYC
/sys/devices/cpu/events/PM_MRK_LSU_REJECT_LHS
/sys/devices/cpu/events/PM_MRK_LD_MISS_L1_CYC
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L2_CYC
/sys/devices/cpu/events/PM_INST_IMC_MATCH_DISP
/sys/devices/cpu/events/PM_MRK_DATA_FROM_RMEM_CYC
/sys/devices/cpu/events/PM_VSU0_SIMPLE_ISSUED
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_RL2L3_SHR
/sys/devices/cpu/events/PM_VSU_FMA_DOUBLE
/sys/devices/cpu/events/PM_VSU_4FLOP
/sys/devices/cpu/events/PM_VSU1_FIN
/sys/devices/cpu/events/PM_NEST_PAIR1_AND
/sys/devices/cpu/events/PM_INST_PTEG_FROM_RL2L3_MOD
/sys/devices/cpu/events/PM_PTEG_FROM_RMEM
/sys/devices/cpu/events/PM_LSU_LRQ_S0_VALID
/sys/devices/cpu/events/PM_LSU0_LDF
/sys/devices/cpu/events/PM_FLUSH_COMPLETION
/sys/devices/cpu/events/PM_ST_MISS_L1
/sys/devices/cpu/events/PM_L2_NODE_PUMP
/sys/devices/cpu/events/PM_INST_FROM_DL2L3_SHR
/sys/devices/cpu/events/PM_MRK_STALL_CMPLU_CYC
/sys/devices/cpu/events/PM_VSU1_DENORM
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR_CYC
/sys/devices/cpu/events/PM_NEST_PAIR0_ADD
/sys/devices/cpu/events/PM_INST_FROM_L3MISS
/sys/devices/cpu/events/PM_EE_OFF_EXT_INT
/sys/devices/cpu/events/PM_INST_PTEG_FROM_DMEM
/sys/devices/cpu/events/PM_INST_FROM_DL2L3_MOD
/sys/devices/cpu/events/PM_PMC6_OVERFLOW
/sys/devices/cpu/events/PM_VSU_2FLOP_DOUBLE
/sys/devices/cpu/events/PM_TLB_MISS
/sys/devices/cpu/events/PM_FXU_BUSY
/sys/devices/cpu/events/PM_L2_RCLD_DISP_FAIL_OTHER
/sys/devices/cpu/events/PM_LSU_REJECT_LMQ_FULL
/sys/devices/cpu/events/PM_IC_RELOAD_SHR
/sys/devices/cpu/events/PM_GRP_MRK
/sys/devices/cpu/events/PM_MRK_ST_NEST
/sys/devices/cpu/events/PM_VSU1_FSQRT_FDIV
/sys/devices/cpu/events/PM_LSU0_FLUSH_LRQ
/sys/devices/cpu/events/PM_LARX_LSU0
/sys/devices/cpu/events/PM_IBUF_FULL_CYC
/sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_SHR_CYC
/sys/devices/cpu/events/PM_LSU_DC_PREF_STREAM_ALLOC
/sys/devices/cpu/events/PM_GRP_MRK_CYC
/sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_SHR_CYC
/sys/devices/cpu/events/PM_L2_GLOB_GUESS_CORRECT
/sys/devices/cpu/events/PM_LSU_REJECT_LHS
/sys/devices/cpu/events/PM_MRK_DATA_FROM_LMEM
/sys/devices/cpu/events/PM_INST_PTEG_FROM_L3
/sys/devices/cpu/events/PM_FREQ_DOWN
/sys/devices/cpu/events/PM_PB_RETRY_NODE_PUMP
/sys/devices/cpu/events/PM_INST_FROM_RL2L3_SHR
/sys/devices/cpu/events/PM_MRK_INST_ISSUED
/sys/devices/cpu/events/PM_PTEG_FROM_L3MISS
/sys/devices/cpu/events/PM_RUN_PURR
/sys/devices/cpu/events/PM_MRK_GRP_IC_MISS
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L3
/sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_SHR
/sys/devices/cpu/events/PM_LSU_FLUSH_LRQ
/sys/devices/cpu/events/PM_MRK_DERAT_MISS_64K
/sys/devices/cpu/events/PM_INST_PTEG_FROM_DL2L3_MOD
/sys/devices/cpu/events/PM_L2_ST_MISS
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L21_SHR
/sys/devices/cpu/events/PM_LWSYNC
/sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_CONFIRM_STRIDE
/sys/devices/cpu/events/PM_MRK_LSU_FLUSH_LRQ
/sys/devices/cpu/events/PM_INST_IMC_MATCH_CMPL
/sys/devices/cpu/events/PM_NEST_PAIR3_AND
/sys/devices/cpu/events/PM_PB_RETRY_SYS_PUMP
/sys/devices/cpu/events/PM_MRK_INST_FIN
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_DL2L3_SHR
/sys/devices/cpu/events/PM_INST_FROM_L31_MOD
/sys/devices/cpu/events/PM_MRK_DTLB_MISS_64K
/sys/devices/cpu/events/PM_LSU_FIN
/sys/devices/cpu/events/PM_MRK_LSU_REJECT
/sys/devices/cpu/events/PM_L2_CO_FAIL_BUSY
/sys/devices/cpu/events/PM_MEM0_WQ_DISP
/sys/devices/cpu/events/PM_DATA_FROM_L31_MOD
/sys/devices/cpu/events/PM_THERMAL_WARN
/sys/devices/cpu/events/PM_VSU0_4FLOP
/sys/devices/cpu/events/PM_BR_MPRED_CCACHE
/sys/devices/cpu/events/PM_L1_DEMAND_WRITE
/sys/devices/cpu/events/PM_FLUSH_BR_MPRED
/sys/devices/cpu/events/PM_MRK_DTLB_MISS_16G
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_DMEM
/sys/devices/cpu/events/PM_L2_RCST_DISP
/sys/devices/cpu/events/PM_LSU_PARTIAL_CDF
/sys/devices/cpu/events/PM_DISP_CLB_HELD_SB
/sys/devices/cpu/events/PM_VSU0_FMA_DOUBLE
/sys/devices/cpu/events/PM_FXU0_BUSY_FXU1_IDLE
/sys/devices/cpu/events/PM_IC_DEMAND_CYC
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_SHR
/sys/devices/cpu/events/PM_MRK_LSU_FLUSH_UST
/sys/devices/cpu/events/PM_INST_PTEG_FROM_L3MISS
/sys/devices/cpu/events/PM_VSU_DENORM
/sys/devices/cpu/events/PM_MRK_LSU_PARTIAL_CDF
/sys/devices/cpu/events/PM_INST_FROM_L21_SHR
/sys/devices/cpu/events/PM_IC_PREF_WRITE
/sys/devices/cpu/events/PM_BR_PRED
/sys/devices/cpu/events/PM_INST_FROM_DMEM
/sys/devices/cpu/events/PM_IC_PREF_CANCEL_ALL
/sys/devices/cpu/events/PM_LSU_DC_PREF_STREAM_CONFIRM
/sys/devices/cpu/events/PM_MRK_LSU_FLUSH_SRQ
/sys/devices/cpu/events/PM_MRK_FIN_STALL_CYC
/sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_OTHER
/sys/devices/cpu/events/PM_VSU1_DD_ISSUED
/sys/devices/cpu/events/PM_PTEG_FROM_L31_SHR
/sys/devices/cpu/events/PM_DATA_FROM_L21_SHR
/sys/devices/cpu/events/PM_LSU0_NCLD
/sys/devices/cpu/events/PM_VSU1_4FLOP
/sys/devices/cpu/events/PM_VSU1_8FLOP
/sys/devices/cpu/events/PM_VSU_8FLOP
/sys/devices/cpu/events/PM_LSU_LMQ_SRQ_EMPTY_CYC
/sys/devices/cpu/events/PM_DTLB_MISS_64K
/sys/devices/cpu/events/PM_THRD_CONC_RUN_INST
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L2
/sys/devices/cpu/events/PM_PB_SYS_PUMP
/sys/devices/cpu/events/PM_VSU_FIN
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_MOD
/sys/devices/cpu/events/PM_THRD_PRIO_0_1_CYC
/sys/devices/cpu/events/PM_DERAT_MISS_64K
/sys/devices/cpu/events/PM_PMC2_REWIND
/sys/devices/cpu/events/PM_INST_FROM_L2
/sys/devices/cpu/events/PM_GRP_BR_MPRED_NONSPEC
/sys/devices/cpu/events/PM_INST_DISP
/sys/devices/cpu/events/PM_MEM0_RD_CANCEL_TOTAL
/sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_CONFIRM
/sys/devices/cpu/events/PM_L1_DCACHE_RELOAD_VALID
/sys/devices/cpu/events/PM_VSU_SCALAR_DOUBLE_ISSUED
/sys/devices/cpu/events/PM_L3_PREF_HIT
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L31_MOD
/sys/devices/cpu/events/PM_MRK_FXU_FIN
/sys/devices/cpu/events/PM_PMC4_OVERFLOW
/sys/devices/cpu/events/PM_MRK_PTEG_FROM_L3
/sys/devices/cpu/events/PM_LSU0_LMQ_LHR_MERGE
/sys/devices/cpu/events/PM_BTAC_HIT
/sys/devices/cpu/events/PM_L3_RD_BUSY
/sys/devices/cpu/events/PM_LSU0_L1_SW_PREF
/sys/devices/cpu/events/PM_INST_FROM_L2MISS
/sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_ALLOC
/sys/devices/cpu/events/PM_L2_ST
/sys/devices/cpu/events/PM_VSU0_DENORM
/sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_SHR
/sys/devices/cpu/events/PM_BR_PRED_CR_TA
/sys/devices/cpu/events/PM_VSU0_FCONV
/sys/devices/cpu/events/PM_MRK_LSU_FLUSH_ULD
/sys/devices/cpu/events/PM_BTAC_MISS
/sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC_COUNT
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L2
/sys/devices/cpu/events/PM_LSU_DCACHE_RELOAD_VALID
/sys/devices/cpu/events/PM_VSU_FMA
/sys/devices/cpu/events/PM_LSU0_FLUSH_SRQ
/sys/devices/cpu/events/PM_LSU1_L1_PREF
/sys/devices/cpu/events/PM_IOPS_CMPL
/sys/devices/cpu/events/PM_L2_SYS_PUMP
/sys/devices/cpu/events/PM_L2_RCLD_BUSY_RC_FULL
/sys/devices/cpu/events/PM_LSU_LMQ_S0_ALLOC
/sys/devices/cpu/events/PM_FLUSH_DISP_SYNC
/sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_MOD_CYC
/sys/devices/cpu/events/PM_L2_IC_INV
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_MOD_CYC
/sys/devices/cpu/events/PM_L3_PREF_LDST
/sys/devices/cpu/events/PM_LSU_SRQ_EMPTY_CYC
/sys/devices/cpu/events/PM_LSU_LMQ_S0_VALID
/sys/devices/cpu/events/PM_FLUSH_PARTIAL
/sys/devices/cpu/events/PM_VSU1_FMA_DOUBLE
/sys/devices/cpu/events/PM_1PLUS_PPC_DISP
/sys/devices/cpu/events/PM_DATA_FROM_L2MISS
/sys/devices/cpu/events/PM_SUSPENDED
/sys/devices/cpu/events/PM_VSU0_FMA
/sys/devices/cpu/events/PM_STCX_FAIL
/sys/devices/cpu/events/PM_VSU0_FSQRT_FDIV_DOUBLE
/sys/devices/cpu/events/PM_DC_PREF_DST
/sys/devices/cpu/events/PM_VSU1_SCAL_SINGLE_ISSUED
/sys/devices/cpu/events/PM_L3_HIT
/sys/devices/cpu/events/PM_L2_GLOB_GUESS_WRONG
/sys/devices/cpu/events/PM_MRK_DFU_FIN
/sys/devices/cpu/events/PM_INST_FROM_L1
/sys/devices/cpu/events/PM_IC_DEMAND_REQ
/sys/devices/cpu/events/PM_VSU1_FSQRT_FDIV_DOUBLE
/sys/devices/cpu/events/PM_VSU1_FMA
/sys/devices/cpu/events/PM_MRK_LD_MISS_L1
/sys/devices/cpu/events/PM_VSU0_2FLOP_DOUBLE
/sys/devices/cpu/events/PM_LSU_DC_PREF_STRIDED_STREAM_CONFIRM
/sys/devices/cpu/events/PM_INST_PTEG_FROM_L31_SHR
/sys/devices/cpu/events/PM_MRK_LSU_REJECT_ERAT_MISS
/sys/devices/cpu/events/PM_MRK_DATA_FROM_L2MISS
/sys/devices/cpu/events/PM_DATA_FROM_RL2L3_SHR
/sys/devices/cpu/events/PM_INST_FROM_PREF
/sys/devices/cpu/events/PM_VSU1_SQ
/sys/devices/cpu/events/PM_L2_LD_DISP
/sys/devices/cpu/events/PM_L2_DISP_ALL
/sys/devices/cpu/events/PM_THRD_GRP_CMPL_BOTH_CYC
/sys/devices/cpu/events/PM_VSU_FSQRT_FDIV_DOUBLE
/sys/devices/cpu/events/PM_INST_PTEG_FROM_DL2L3_SHR
/sys/devices/cpu/events/PM_VSU_1FLOP
/sys/devices/cpu/events/PM_HV_CYC
/sys/devices/cpu/events/PM_MRK_LSU_FIN
/sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_SHR
/sys/devices/cpu/events/PM_DTLB_MISS_16M
/sys/devices/cpu/events/PM_LSU1_LMQ_LHR_MERGE
/sys/devices/cpu/events/PM_IFU_FIN
/sys/devices/cpu/events/PM_1THRD_CON_RUN_INSTR
/sys/devices/cpu/events/PM_CMPLU_STALL_COUNT
/sys/devices/cpu/events/PM_MEM0_PB_RD_CL
/sys/devices/cpu/events/PM_THRD_1_RUN_CYC
/sys/devices/cpu/events/PM_THRD_2_CONC_RUN_INSTR
/sys/devices/cpu/events/PM_THRD_2_RUN_CYC
/sys/devices/cpu/events/PM_THRD_3_CONC_RUN_INST
/sys/devices/cpu/events/PM_THRD_3_RUN_CYC
/sys/devices/cpu/events/PM_THRD_4_CONC_RUN_INST
/sys/devices/cpu/events/PM_THRD_4_RUN_CYC
Date: 2013/01/08
What: /sys/bus/event_source/devices/<pmu>/events/<event>
Date: 2014/02/24
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
Description: Per-pmu performance monitoring events specific to the running system
Description: POWER-systems specific performance monitoring events
Each file (except for some of those with a '.' in them, '.unit'
and '.scale') in the 'events' directory describes a single
performance monitoring event supported by the <pmu>. The name
of the file is the name of the event.
A collection of performance monitoring events that may be
supported by the POWER CPU. These events can be monitored
using the 'perf(1)' tool.
File contents:
These events may not be supported by other CPUs.
<term>[=<value>][,<term>[=<value>]]...
The contents of each file would look like:
Where <term> is one of the terms listed under
/sys/bus/event_source/devices/<pmu>/format/ and <value> is
a number is base-16 format with a '0x' prefix (lowercase only).
If a <term> is specified alone (without an assigned value), it
is implied that 0x1 is assigned to that <term>.
event=0xNNNN
Examples (each of these lines would be in a seperate file):
where 'N' is a hex digit and the number '0xNNNN' shows the
"raw code" for the perf event identified by the file's
"basename".
event=0x2abc
event=0x423,inv,cmask=0x3
domain=0x1,offset=0x8,starting_index=0xffff
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.
Each of the assignments indicates a value to be assigned to a
particular set of bits (as defined by the format file
corresponding to the <term>) in the perf_event structure passed
to the perf_open syscall.
What: /sys/bus/event_source/devices/<pmu>/events/<event>.unit
Date: 2014/02/24
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Perf event units
A string specifying the English plural numerical unit that <event>
(once multiplied by <event>.scale) represents.
Example:
Joules
What: /sys/bus/event_source/devices/<pmu>/events/<event>.scale
Date: 2014/02/24
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Perf event scaling factors
A string representing a floating point value expressed in
scientific notation to be multiplied by the event count
recieved from the kernel to match the unit specified in the
<event>.unit file.
Example:
2.3283064365386962890625e-10
This is provided to avoid performing floating point arithmetic
in the kernel.

View File

@ -1,6 +1,6 @@
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Provides access to the binary "24x7 catalog" provided by the
hypervisor on POWER7 and 8 systems. This catalog lists events
@ -10,14 +10,14 @@ Description:
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_length
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
A number equal to the length in bytes of the catalog. This is
also extractable from the provided binary "catalog" sysfs entry.
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_version
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Exposes the "version" field of the 24x7 catalog. This is also
extractable from the provided binary "catalog" sysfs entry.

View File

@ -1,6 +1,6 @@
What: /sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
'0' if the hypervisor is configured to forbid access to event
counters being accumulated by other guests and to physical
@ -9,35 +9,35 @@ Description:
What: /sys/bus/event_source/devices/hv_gpci/interface/ga
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
0 or 1. Indicates whether we have access to "GA" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/expanded
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
0 or 1. Indicates whether we have access to "EXPANDED" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/lab
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
0 or 1. Indicates whether we have access to "LAB" events (listed
in arch/powerpc/perf/hv-gpci.h).
What: /sys/bus/event_source/devices/hv_gpci/interface/version
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
A number indicating the version of the gpci interface that the
hypervisor reports supporting.
What: /sys/bus/event_source/devices/hv_gpci/interface/kernel_version
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
A number indicating the latest version of the gpci interface
that the kernel is aware of.

View File

@ -200,6 +200,13 @@ Description:
Raw pressure measurement from channel Y. Units after
application of scale and offset are kilopascal.
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_input
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_input
KernelVersion: 3.8
Contact: linux-iio@vger.kernel.org
Description:
Scaled pressure measurement from channel Y, in kilopascal.
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_raw
KernelVersion: 3.14
Contact: linux-iio@vger.kernel.org
@ -231,6 +238,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_offset
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@ -251,6 +259,7 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale
@ -266,6 +275,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_sca
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@ -328,6 +338,10 @@ Description:
are listed in this attribute.
What /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_clear_hardwaregain
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@ -1028,3 +1042,12 @@ Contact: linux-iio@vger.kernel.org
Description:
Raw value of rotation from true/magnetic north measured with
or without compensation from tilt sensors.
What: /sys/bus/iio/devices/iio:deviceX/in_currentX_raw
KernelVersion: 3.18
Contact: linux-iio@vger.kernel.org
Description:
Raw current measurement from channel X. Units are in milliamps
after application of scale and offset. If no offset or scale is
present, output should be considered as processed with the
unit in milliamps.

View File

@ -0,0 +1,7 @@
What: /sys/bus/iio/devices/triggerX/name = "bmc150_accel-any-motion-devX"
KernelVersion: 3.17
Contact: linux-iio@vger.kernel.org
Description:
The BMC150 accelerometer kernel module provides an additional trigger,
which sets driver in a mode, where data is pushed to the buffer
only when there is any motion.

View File

@ -0,0 +1,7 @@
What: /sys/bus/iio/devices/triggerX/name = "bmg160-any-motion-devX"
KernelVersion: 3.17
Contact: linux-iio@vger.kernel.org
Description:
The BMG160 gyro kernel module provides an additional trigger,
which sets driver in a mode, where data is pushed to the buffer
only when there is any motion.

View File

@ -65,6 +65,16 @@ Description:
force a rescan of all PCI buses in the system, and
re-discover previously removed devices.
What: /sys/bus/pci/devices/.../msi_bus
Date: September 2014
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
Writing a zero value to this attribute disallows MSI and
MSI-X for any future drivers of the device. If the device
is a bridge, MSI and MSI-X will be disallowed for future
drivers of all child devices under the bridge. Drivers
must be reloaded for the new setting to take effect.
What: /sys/bus/pci/devices/.../msi_irqs/
Date: September, 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
@ -271,3 +281,16 @@ Description:
opt-out of driver binding using a driver_override name such as
"none". Only a single driver may be specified in the override,
there is no support for parsing delimiters.
What: /sys/bus/pci/devices/.../numa_node
Date: Oct 2014
Contact: Prarit Bhargava <prarit@redhat.com>
Description:
This file contains the NUMA node to which the PCI device is
attached, or -1 if the node is unknown. The initial value
comes from an ACPI _PXM method or a similar firmware
source. If that is missing or incorrect, this file can be
written to override the node. In that case, please report
a firmware bug to the system vendor. Writing to this file
taints the kernel with TAINT_FIRMWARE_WORKAROUND, which
reduces the supportability of your system.

View File

@ -104,16 +104,15 @@ What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
Date: September 2011
Contact: Andiry Xu <andiry.xu@amd.com>
Description:
If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
is plugged in to a xHCI host which support link PM, it will
perform a LPM test; if the test is passed and host supports
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
be enabled for the device and the USB device directory will
contain a file named power/usb2_hardware_lpm. The file holds
a string value (enable or disable) indicating whether or not
USB2 hardware LPM is enabled for the device. Developer can
write y/Y/1 or n/N/0 to the file to enable/disable the
feature.
If CONFIG_PM is set and a USB 2.0 lpm-capable device is plugged
in to a xHCI host which support link PM, it will perform a LPM
test; if the test is passed and host supports USB2 hardware LPM
(xHCI 1.0 feature), USB2 hardware LPM will be enabled for the
device and the USB device directory will contain a file named
power/usb2_hardware_lpm. The file holds a string value (enable
or disable) indicating whether or not USB2 hardware LPM is
enabled for the device. Developer can write y/Y/1 or n/N/0 to
the file to enable/disable the feature.
What: /sys/bus/usb/devices/.../removable
Date: February 2012

View File

@ -0,0 +1,129 @@
Slave contexts (eg. /sys/class/cxl/afu0.0s):
What: /sys/class/cxl/<afu>/irqs_max
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Decimal value of maximum number of interrupts that can be
requested by userspace. The default on probe is the maximum
that hardware can support (eg. 2037). Write values will limit
userspace applications to that many userspace interrupts. Must
be >= irqs_min.
What: /sys/class/cxl/<afu>/irqs_min
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the minimum number of interrupts that
userspace must request on a CXL_START_WORK ioctl. Userspace may
omit the num_interrupts field in the START_WORK IOCTL to get
this minimum automatically.
What: /sys/class/cxl/<afu>/mmio_size
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the size of the MMIO space that may be mmaped
by userspace.
What: /sys/class/cxl/<afu>/modes_supported
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
List of the modes this AFU supports. One per line.
Valid entries are: "dedicated_process" and "afu_directed"
What: /sys/class/cxl/<afu>/mode
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
The current mode the AFU is using. Will be one of the modes
given in modes_supported. Writing will change the mode
provided that no user contexts are attached.
What: /sys/class/cxl/<afu>/prefault_mode
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Set the mode for prefaulting in segments into the segment table
when performing the START_WORK ioctl. Possible values:
none: No prefaulting (default)
work_element_descriptor: Treat the work element
descriptor as an effective address and
prefault what it points to.
all: all segments process calling START_WORK maps.
What: /sys/class/cxl/<afu>/reset
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
Writing 1 here will reset the AFU provided there are not
contexts active on the AFU.
What: /sys/class/cxl/<afu>/api_version
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the current version of the kernel/user API.
What: /sys/class/cxl/<afu>/api_version_com
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the the lowest version of the userspace API
this this kernel supports.
Master contexts (eg. /sys/class/cxl/afu0.0m)
What: /sys/class/cxl/<afu>m/mmio_size
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the size of the MMIO space that may be mmaped
by userspace. This includes all slave contexts space also.
What: /sys/class/cxl/<afu>m/pp_mmio_len
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the Per Process MMIO space length.
What: /sys/class/cxl/<afu>m/pp_mmio_off
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the Per Process MMIO space offset.
Card info (eg. /sys/class/cxl/card0)
What: /sys/class/cxl/<card>/caia_version
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the CAIA Version the card implements.
What: /sys/class/cxl/<card>/psl_version
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the revision level of the PSL.
What: /sys/class/cxl/<card>/base_image
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the revision level of the base image for devices
that support loadable PSLs. For FPGAs this field identifies
the image contained in the on-adapter flash which is loaded
during the initial program load.
What: /sys/class/cxl/<card>/image_loaded
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Will return "user" or "factory" depending on the image loaded
onto the card.

View File

@ -159,7 +159,7 @@ Description:
lower-level interface protocol used. Ethernet devices will show
a 'mtu' attribute value of 1500 unless changed.
What: /sys/calss/net/<iface>/netdev_group
What: /sys/class/net/<iface>/netdev_group
Date: January 2011
KernelVersion: 2.6.39
Contact: netdev@vger.kernel.org
@ -216,3 +216,11 @@ Contact: netdev@vger.kernel.org
Description:
Indicates the interface protocol type as a decimal value. See
include/uapi/linux/if_arp.h for all possible values.
What: /sys/class/net/<iface>/phys_switch_id
Date: November 2014
KernelVersion: 3.19
Contact: netdev@vger.kernel.org
Description:
Indicates the unique physical switch identifier of a switch this
port belongs to, as a string.

View File

@ -18,3 +18,17 @@ Description:
This file is writeable and can be used to set the assumed
battery 'full level'. As batteries age, this value has to be
amended over time.
What: /sys/class/power_supply/max14577-charger/device/fast_charge_timer
Date: October 2014
KernelVersion: 3.18.0
Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Description:
This entry shows and sets the maximum time the max14577
charger operates in fast-charge mode. When the timer expires
the device will terminate fast-charge mode (charging current
will drop to 0 A) and will trigger interrupt.
Valid values:
- 5, 6 or 7 (hours),
- 0: disabled.

View File

@ -43,6 +43,19 @@ Description:
Reading returns the currently active channel, or -1 if
the radio controller is not beaconing.
What: /sys/class/uwb_rc/uwbN/ASIE
Date: August 2014
KernelVersion: 3.18
Contact: linux-usb@vger.kernel.org
Description:
The application-specific information element (ASIE)
included in this device's beacon, in space separated
hex octets.
Reading returns the current ASIE. Writing replaces
the current ASIE with the one written.
What: /sys/class/uwb_rc/uwbN/scan
Date: July 2008
KernelVersion: 2.6.27

View File

@ -61,6 +61,14 @@ Users: hotplug memory remove tools
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
What: /sys/devices/system/memory/memoryX/valid_zones
Date: July 2014
Contact: Zhang Zhen <zhenzhang.zhang@huawei.com>
Description:
The file /sys/devices/system/memory/memoryX/valid_zones is
read-only and is designed to show which zone this memory
block can be onlined to.
What: /sys/devices/system/memoryX/nodeY
Date: October 2009
Contact: Linux Memory Management list <linux-mm@kvack.org>

View File

@ -224,3 +224,50 @@ Description: Parameters for the Intel P-state driver
frequency range.
More details can be found in Documentation/cpu-freq/intel-pstate.txt
What: /sys/devices/system/cpu/cpu*/cache/index*/<set_of_attributes_mentioned_below>
Date: July 2014(documented, existed before August 2008)
Contact: Sudeep Holla <sudeep.holla@arm.com>
Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Parameters for the CPU cache attributes
allocation_policy:
- WriteAllocate: allocate a memory location to a cache line
on a cache miss because of a write
- ReadAllocate: allocate a memory location to a cache line
on a cache miss because of a read
- ReadWriteAllocate: both writeallocate and readallocate
attributes: LEGACY used only on IA64 and is same as write_policy
coherency_line_size: the minimum amount of data in bytes that gets
transferred from memory to cache
level: the cache hierarcy in the multi-level cache configuration
number_of_sets: total number of sets in the cache, a set is a
collection of cache lines with the same cache index
physical_line_partition: number of physical cache line per cache tag
shared_cpu_list: the list of logical cpus sharing the cache
shared_cpu_map: logical cpu mask containing the list of cpus sharing
the cache
size: the total cache size in kB
type:
- Instruction: cache that only holds instructions
- Data: cache that only caches data
- Unified: cache that holds both data and instructions
ways_of_associativity: degree of freedom in placing a particular block
of memory in the cache
write_policy:
- WriteThrough: data is written to both the cache line
and to the block in the lower-level memory
- WriteBack: data is written only to the cache line and
the modified cache line is written to main
memory only when it is replaced

View File

@ -0,0 +1,11 @@
What: /sys/class/input/input(x)/device/startup
Date: March 2014
Contact: Carlo Caione <carlo@caione.org>
Description: Startup time in us. Board is powered on if the button is pressed
for more than <startup_time>
What: /sys/class/input/input(x)/device/shutdown
Date: March 2014
Contact: Carlo Caione <carlo@caione.org>
Description: Shutdown time in us. Board is powered off if the button is pressed
for more than <shutdown_time>

View File

@ -44,6 +44,13 @@ Description:
Controls the FS utilization condition for the in-place-update
policies.
What: /sys/fs/f2fs/<disk>/min_fsync_blocks
Date: September 2014
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Controls the dirty page count condition for the in-place-update
policies.
What: /sys/fs/f2fs/<disk>/max_small_discards
Date: November 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>

View File

@ -20,4 +20,4 @@ Date: November 2007
Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
Description: The /sys/firmware/ibft/ethernetX directory will contain
files that expose the iSCSI Boot Firmware Table NIC data.
This can this can the IP address, MAC, and gateway of the NIC.
Usually this contains the IP address, MAC, and gateway of the NIC.

View File

@ -0,0 +1,60 @@
What: /sys/class/leds/dell::kbd_backlight/als_setting
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to control the automatic keyboard
illumination mode on some systems that have an ambient
light sensor. Write 1 to this file to enable the auto
mode, 0 to disable it.
What: /sys/class/leds/dell::kbd_backlight/start_triggers
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to control the input triggers that
turn on the keyboard backlight illumination that is
disabled because of inactivity.
Read the file to see the triggers available. The ones
enabled are preceded by '+', those disabled by '-'.
To enable a trigger, write its name preceded by '+' to
this file. To disable a trigger, write its name preceded
by '-' instead.
For example, to enable the keyboard as trigger run:
echo +keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
To disable it:
echo -keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
Note that not all the available triggers can be configured.
What: /sys/class/leds/dell::kbd_backlight/stop_timeout
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to specify the interval after which the
keyboard illumination is disabled because of inactivity.
The timeouts are expressed in seconds, minutes, hours and
days, for which the symbols are 's', 'm', 'h' and 'd'
respectively.
To configure the timeout, write to this file a value along
with any the above units. If no unit is specified, the value
is assumed to be expressed in seconds.
For example, to set the timeout to 10 minutes run:
echo 10m > /sys/class/leds/dell::kbd_backlight/stop_timeout
Note that when this file is read, the returned value might be
expressed in a different unit than the one used when the timeout
was set.
Also note that only some timeouts are supported and that
some systems might fall back to a specific timeout in case
an invalid timeout is written to this file.

View File

@ -167,18 +167,11 @@ later is recommended, due to some significant improvements).
PCMCIAutils
-----------
PCMCIAutils replaces pcmcia-cs (see below). It properly sets up
PCMCIAutils replaces pcmcia-cs. It properly sets up
PCMCIA sockets at system startup and loads the appropriate modules
for 16-bit PCMCIA devices if the kernel is modularized and the hotplug
subsystem is used.
Pcmcia-cs
---------
PCMCIA (PC Card) support is now partially implemented in the main
kernel source. The "pcmciautils" package (see above) replaces pcmcia-cs
for newest kernels.
Quota-tools
-----------
@ -341,17 +334,13 @@ Pcmciautils
-----------
o <ftp://ftp.kernel.org/pub/linux/utils/kernel/pcmcia/>
Pcmcia-cs
---------
o <http://pcmcia-cs.sourceforge.net/>
Quota-tools
----------
o <http://sourceforge.net/projects/linuxquota/>
DocBook Stylesheets
-------------------
o <http://nwalsh.com/docbook/dsssl/>
o <http://sourceforge.net/projects/docbook/files/docbook-dsssl/>
XMLTO XSLT Frontend
-------------------
@ -359,11 +348,11 @@ o <http://cyberelk.net/tim/xmlto/>
Intel P6 microcode
------------------
o <http://www.urbanmyth.org/microcode/>
o <https://downloadcenter.intel.com/>
udev
----
o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html>
o <http://www.freedesktop.org/software/systemd/man/udev.html>
FUSE
----
@ -371,7 +360,7 @@ o <http://sourceforge.net/projects/fuse>
mcelog
------
o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/>
o <http://www.mcelog.org/>
Networking
**********
@ -394,7 +383,7 @@ o <http://www.iptables.org/downloads.html>
Ip-route2
---------
o <ftp://ftp.tux.org/pub/net/ip-routing/iproute2-2.2.4-now-ss991023.tar.gz>
o <https://www.kernel.org/pub/linux/utils/net/iproute2/>
OProfile
--------

View File

@ -392,7 +392,12 @@ The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done. If there is no
cleanup needed then just return directly.
The rationale is:
Choose label names which say what the goto does or why the goto exists. An
example of a good name could be "out_buffer:" if the goto frees "buffer". Avoid
using GW-BASIC names like "err1:" and "err2:". Also don't name them after the
goto location like "err_kmalloc_failed:"
The rationale for using gotos is:
- unconditional statements are easier to understand and follow
- nesting is reduced
@ -403,9 +408,10 @@ The rationale is:
int fun(int a)
{
int result = 0;
char *buffer = kmalloc(SIZE);
char *buffer;
if (buffer == NULL)
buffer = kmalloc(SIZE, GFP_KERNEL);
if (!buffer)
return -ENOMEM;
if (condition1) {
@ -413,14 +419,25 @@ int fun(int a)
...
}
result = 1;
goto out;
goto out_buffer;
}
...
out:
out_buffer:
kfree(buffer);
return result;
}
A common type of bug to be aware of it "one err bugs" which look like this:
err:
kfree(foo->bar);
kfree(foo);
return ret;
The bug in this code is that on some exit paths "foo" is NULL. Normally the
fix for this is to split it up into two error labels "err_bar:" and "err_foo:".
Chapter 8: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
@ -675,7 +692,7 @@ the ones already enabled by DEBUG.
Many subsystems have Kconfig debug options to turn on -DDEBUG in the
corresponding Makefile; in other cases specific files #define DEBUG. And
when a debug message should be unconditionally printed, such as if it is
already inside a debug-related #ifdef secton, printk(KERN_DEBUG ...) can be
already inside a debug-related #ifdef section, printk(KERN_DEBUG ...) can be
used.
@ -845,6 +862,49 @@ next instruction in the assembly output:
: /* outputs */ : /* inputs */ : /* clobbers */);
Chapter 20: Conditional Compilation
Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c
files; doing so makes code harder to read and logic harder to follow. Instead,
use such conditionals in a header file defining functions for use in those .c
files, providing no-op stub versions in the #else case, and then call those
functions unconditionally from .c files. The compiler will avoid generating
any code for the stub calls, producing identical results, but the logic will
remain easy to follow.
Prefer to compile out entire functions, rather than portions of functions or
portions of expressions. Rather than putting an ifdef in an expression, factor
out part or all of the expression into a separate helper function and apply the
conditional to that function.
If you have a function or variable which may potentially go unused in a
particular configuration, and the compiler would warn about its definition
going unused, mark the definition as __maybe_unused rather than wrapping it in
a preprocessor conditional. (However, if a function or variable *always* goes
unused, delete it.)
Within code, where possible, use the IS_ENABLED macro to convert a Kconfig
symbol into a C boolean expression, and use it in a normal C conditional:
if (IS_ENABLED(CONFIG_SOMETHING)) {
...
}
The compiler will constant-fold the conditional away, and include or exclude
the block of code just as with an #ifdef, so this will not add any runtime
overhead. However, this approach still allows the C compiler to see the code
inside the block, and check it for correctness (syntax, types, symbol
references, etc). Thus, you still have to use an #ifdef if the code inside the
block references symbols that will not exist if the condition is not met.
At the end of any non-trivial #if or #ifdef block (more than a few lines),
place a comment after the #endif on the same line, noting the conditional
expression used. For instance:
#ifdef CONFIG_SOMETHING
...
#endif /* CONFIG_SOMETHING */
Appendix I: References

View File

@ -531,7 +531,7 @@ To map a single region, you do:
size_t size = buffer->len;
dma_handle = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dma_handle)) {
if (dma_mapping_error(dev, dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
@ -588,7 +588,7 @@ Specifically:
size_t size = buffer->len;
dma_handle = dma_map_page(dev, page, offset, size, direction);
if (dma_mapping_error(dma_handle)) {
if (dma_mapping_error(dev, dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
@ -689,7 +689,7 @@ to use the dma_sync_*() interfaces.
dma_addr_t mapping;
mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
if (dma_mapping_error(dma_handle)) {
if (dma_mapping_error(cp->dev, dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or

View File

@ -15,7 +15,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml
writing_musb_glue_layer.xml crypto-API.xml
include Documentation/DocBook/media/Makefile

View File

@ -57,6 +57,7 @@
!Esound/core/pcm.c
!Esound/core/pcm_lib.c
!Esound/core/pcm_native.c
!Iinclude/sound/pcm.h
</sect1>
<sect1><title>PCM Format Helpers</title>
!Esound/core/pcm_misc.c
@ -64,6 +65,10 @@
<sect1><title>PCM Memory Management</title>
!Esound/core/pcm_memory.c
</sect1>
<sect1><title>PCM DMA Engine API</title>
!Esound/core/pcm_dmaengine.c
!Iinclude/sound/dmaengine_pcm.h
</sect1>
</chapter>
<chapter><title>Control/Mixer API</title>
<sect1><title>General Control Interface</title>
@ -91,12 +96,38 @@
!Esound/core/info.c
</sect1>
</chapter>
<chapter><title>Compress Offload</title>
<sect1><title>Compress Offload API</title>
!Esound/core/compress_offload.c
!Iinclude/uapi/sound/compress_offload.h
!Iinclude/uapi/sound/compress_params.h
!Iinclude/sound/compress_driver.h
</sect1>
</chapter>
<chapter><title>ASoC</title>
<sect1><title>ASoC Core API</title>
!Iinclude/sound/soc.h
!Esound/soc/soc-core.c
!Esound/soc/soc-cache.c
!Esound/soc/soc-devres.c
!Esound/soc/soc-io.c
!Esound/soc/soc-pcm.c
</sect1>
<sect1><title>ASoC DAPM API</title>
!Esound/soc/soc-dapm.c
</sect1>
<sect1><title>ASoC DMA Engine API</title>
!Esound/soc/soc-generic-dmaengine-pcm.c
</sect1>
</chapter>
<chapter><title>Miscellaneous Functions</title>
<sect1><title>Hardware-Dependent Devices API</title>
!Esound/core/hwdep.c
</sect1>
<sect1><title>Jack Abstraction Layer API</title>
!Iinclude/sound/jack.h
!Esound/core/jack.c
!Esound/soc/soc-jack.c
</sect1>
<sect1><title>ISA DMA Helpers</title>
!Esound/core/isadma.c

File diff suppressed because it is too large Load Diff

View File

@ -291,10 +291,9 @@ char *date;</synopsis>
<title>Device Registration</title>
<para>
A number of functions are provided to help with device registration.
The functions deal with PCI, USB and platform devices, respectively.
The functions deal with PCI and platform devices, respectively.
</para>
!Edrivers/gpu/drm/drm_pci.c
!Edrivers/gpu/drm/drm_usb.c
!Edrivers/gpu/drm/drm_platform.c
<para>
New drivers that no longer rely on the services provided by the
@ -493,10 +492,10 @@ char *date;</synopsis>
<sect2>
<title>The Translation Table Manager (TTM)</title>
<para>
TTM design background and information belongs here.
TTM design background and information belongs here.
</para>
<sect3>
<title>TTM initialization</title>
<title>TTM initialization</title>
<warning><para>This section is outdated.</para></warning>
<para>
Drivers wishing to support TTM must fill out a drm_bo_driver
@ -504,42 +503,42 @@ char *date;</synopsis>
pointers for initializing the TTM, allocating and freeing memory,
waiting for command completion and fence synchronization, and memory
migration. See the radeon_ttm.c file for an example of usage.
</para>
<para>
The ttm_global_reference structure is made up of several fields:
</para>
<programlisting>
struct ttm_global_reference {
enum ttm_global_types global_type;
size_t size;
void *object;
int (*init) (struct ttm_global_reference *);
void (*release) (struct ttm_global_reference *);
};
</programlisting>
<para>
There should be one global reference structure for your memory
manager as a whole, and there will be others for each object
created by the memory manager at runtime. Your global TTM should
have a type of TTM_GLOBAL_TTM_MEM. The size field for the global
object should be sizeof(struct ttm_mem_global), and the init and
release hooks should point at your driver-specific init and
release routines, which probably eventually call
ttm_mem_global_init and ttm_mem_global_release, respectively.
</para>
<para>
Once your global TTM accounting structure is set up and initialized
by calling ttm_global_item_ref() on it,
you need to create a buffer object TTM to
provide a pool for buffer object allocation by clients and the
kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO,
and its size should be sizeof(struct ttm_bo_global). Again,
driver-specific init and release functions may be provided,
likely eventually calling ttm_bo_global_init() and
ttm_bo_global_release(), respectively. Also, like the previous
object, ttm_global_item_ref() is used to create an initial reference
count for the TTM, which will call your initialization function.
</para>
</para>
<para>
The ttm_global_reference structure is made up of several fields:
</para>
<programlisting>
struct ttm_global_reference {
enum ttm_global_types global_type;
size_t size;
void *object;
int (*init) (struct ttm_global_reference *);
void (*release) (struct ttm_global_reference *);
};
</programlisting>
<para>
There should be one global reference structure for your memory
manager as a whole, and there will be others for each object
created by the memory manager at runtime. Your global TTM should
have a type of TTM_GLOBAL_TTM_MEM. The size field for the global
object should be sizeof(struct ttm_mem_global), and the init and
release hooks should point at your driver-specific init and
release routines, which probably eventually call
ttm_mem_global_init and ttm_mem_global_release, respectively.
</para>
<para>
Once your global TTM accounting structure is set up and initialized
by calling ttm_global_item_ref() on it,
you need to create a buffer object TTM to
provide a pool for buffer object allocation by clients and the
kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO,
and its size should be sizeof(struct ttm_bo_global). Again,
driver-specific init and release functions may be provided,
likely eventually calling ttm_bo_global_init() and
ttm_bo_global_release(), respectively. Also, like the previous
object, ttm_global_item_ref() is used to create an initial reference
count for the TTM, which will call your initialization function.
</para>
</sect3>
</sect2>
<sect2 id="drm-gem">
@ -567,19 +566,19 @@ char *date;</synopsis>
using driver-specific ioctls.
</para>
<para>
On a fundamental level, GEM involves several operations:
<itemizedlist>
<listitem>Memory allocation and freeing</listitem>
<listitem>Command execution</listitem>
<listitem>Aperture management at command execution time</listitem>
</itemizedlist>
Buffer object allocation is relatively straightforward and largely
On a fundamental level, GEM involves several operations:
<itemizedlist>
<listitem>Memory allocation and freeing</listitem>
<listitem>Command execution</listitem>
<listitem>Aperture management at command execution time</listitem>
</itemizedlist>
Buffer object allocation is relatively straightforward and largely
provided by Linux's shmem layer, which provides memory to back each
object.
</para>
<para>
Device-specific operations, such as command execution, pinning, buffer
read &amp; write, mapping, and domain ownership transfers are left to
read &amp; write, mapping, and domain ownership transfers are left to
driver-specific ioctls.
</para>
<sect3>
@ -739,16 +738,16 @@ char *date;</synopsis>
respectively. The conversion is handled by the DRM core without any
driver-specific support.
</para>
<para>
GEM also supports buffer sharing with dma-buf file descriptors through
PRIME. GEM-based drivers must use the provided helpers functions to
implement the exporting and importing correctly. See <xref linkend="drm-prime-support" />.
Since sharing file descriptors is inherently more secure than the
easily guessable and global GEM names it is the preferred buffer
sharing mechanism. Sharing buffers through GEM names is only supported
for legacy userspace. Furthermore PRIME also allows cross-device
buffer sharing since it is based on dma-bufs.
</para>
<para>
GEM also supports buffer sharing with dma-buf file descriptors through
PRIME. GEM-based drivers must use the provided helpers functions to
implement the exporting and importing correctly. See <xref linkend="drm-prime-support" />.
Since sharing file descriptors is inherently more secure than the
easily guessable and global GEM names it is the preferred buffer
sharing mechanism. Sharing buffers through GEM names is only supported
for legacy userspace. Furthermore PRIME also allows cross-device
buffer sharing since it is based on dma-bufs.
</para>
</sect3>
<sect3 id="drm-gem-objects-mapping">
<title>GEM Objects Mapping</title>
@ -853,7 +852,7 @@ char *date;</synopsis>
<sect3>
<title>Command Execution</title>
<para>
Perhaps the most important GEM function for GPU devices is providing a
Perhaps the most important GEM function for GPU devices is providing a
command execution interface to clients. Client programs construct
command buffers containing references to previously allocated memory
objects, and then submit them to GEM. At that point, GEM takes care to
@ -875,95 +874,101 @@ char *date;</synopsis>
<title>GEM Function Reference</title>
!Edrivers/gpu/drm/drm_gem.c
</sect3>
</sect2>
<sect2>
<title>VMA Offset Manager</title>
</sect2>
<sect2>
<title>VMA Offset Manager</title>
!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager
!Edrivers/gpu/drm/drm_vma_manager.c
!Iinclude/drm/drm_vma_manager.h
</sect2>
<sect2 id="drm-prime-support">
<title>PRIME Buffer Sharing</title>
<para>
PRIME is the cross device buffer sharing framework in drm, originally
created for the OPTIMUS range of multi-gpu platforms. To userspace
PRIME buffers are dma-buf based file descriptors.
</para>
<sect3>
<title>Overview and Driver Interface</title>
<para>
Similar to GEM global names, PRIME file descriptors are
also used to share buffer objects across processes. They offer
additional security: as file descriptors must be explicitly sent over
UNIX domain sockets to be shared between applications, they can't be
guessed like the globally unique GEM names.
</para>
<para>
Drivers that support the PRIME
API must set the DRIVER_PRIME bit in the struct
<structname>drm_driver</structname>
<structfield>driver_features</structfield> field, and implement the
<methodname>prime_handle_to_fd</methodname> and
<methodname>prime_fd_to_handle</methodname> operations.
</para>
<para>
<synopsis>int (*prime_handle_to_fd)(struct drm_device *dev,
struct drm_file *file_priv, uint32_t handle,
uint32_t flags, int *prime_fd);
</sect2>
<sect2 id="drm-prime-support">
<title>PRIME Buffer Sharing</title>
<para>
PRIME is the cross device buffer sharing framework in drm, originally
created for the OPTIMUS range of multi-gpu platforms. To userspace
PRIME buffers are dma-buf based file descriptors.
</para>
<sect3>
<title>Overview and Driver Interface</title>
<para>
Similar to GEM global names, PRIME file descriptors are
also used to share buffer objects across processes. They offer
additional security: as file descriptors must be explicitly sent over
UNIX domain sockets to be shared between applications, they can't be
guessed like the globally unique GEM names.
</para>
<para>
Drivers that support the PRIME
API must set the DRIVER_PRIME bit in the struct
<structname>drm_driver</structname>
<structfield>driver_features</structfield> field, and implement the
<methodname>prime_handle_to_fd</methodname> and
<methodname>prime_fd_to_handle</methodname> operations.
</para>
<para>
<synopsis>int (*prime_handle_to_fd)(struct drm_device *dev,
struct drm_file *file_priv, uint32_t handle,
uint32_t flags, int *prime_fd);
int (*prime_fd_to_handle)(struct drm_device *dev,
struct drm_file *file_priv, int prime_fd,
uint32_t *handle);</synopsis>
Those two operations convert a handle to a PRIME file descriptor and
vice versa. Drivers must use the kernel dma-buf buffer sharing framework
to manage the PRIME file descriptors. Similar to the mode setting
API PRIME is agnostic to the underlying buffer object manager, as
long as handles are 32bit unsigned integers.
</para>
<para>
While non-GEM drivers must implement the operations themselves, GEM
drivers must use the <function>drm_gem_prime_handle_to_fd</function>
and <function>drm_gem_prime_fd_to_handle</function> helper functions.
Those helpers rely on the driver
<methodname>gem_prime_export</methodname> and
<methodname>gem_prime_import</methodname> operations to create a dma-buf
instance from a GEM object (dma-buf exporter role) and to create a GEM
object from a dma-buf instance (dma-buf importer role).
</para>
<para>
<synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
struct drm_gem_object *obj,
int flags);
struct drm_file *file_priv, int prime_fd,
uint32_t *handle);</synopsis>
Those two operations convert a handle to a PRIME file descriptor and
vice versa. Drivers must use the kernel dma-buf buffer sharing framework
to manage the PRIME file descriptors. Similar to the mode setting
API PRIME is agnostic to the underlying buffer object manager, as
long as handles are 32bit unsigned integers.
</para>
<para>
While non-GEM drivers must implement the operations themselves, GEM
drivers must use the <function>drm_gem_prime_handle_to_fd</function>
and <function>drm_gem_prime_fd_to_handle</function> helper functions.
Those helpers rely on the driver
<methodname>gem_prime_export</methodname> and
<methodname>gem_prime_import</methodname> operations to create a dma-buf
instance from a GEM object (dma-buf exporter role) and to create a GEM
object from a dma-buf instance (dma-buf importer role).
</para>
<para>
<synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
struct drm_gem_object *obj,
int flags);
struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
struct dma_buf *dma_buf);</synopsis>
These two operations are mandatory for GEM drivers that support
PRIME.
</para>
</sect3>
<sect3>
<title>PRIME Helper Functions</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
struct dma_buf *dma_buf);</synopsis>
These two operations are mandatory for GEM drivers that support
PRIME.
</para>
</sect3>
</sect2>
<sect2>
<title>PRIME Function References</title>
<sect3>
<title>PRIME Helper Functions</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
</sect3>
</sect2>
<sect2>
<title>PRIME Function References</title>
!Edrivers/gpu/drm/drm_prime.c
</sect2>
<sect2>
<title>DRM MM Range Allocator</title>
<sect3>
<title>Overview</title>
</sect2>
<sect2>
<title>DRM MM Range Allocator</title>
<sect3>
<title>Overview</title>
!Pdrivers/gpu/drm/drm_mm.c Overview
</sect3>
<sect3>
<title>LRU Scan/Eviction Support</title>
</sect3>
<sect3>
<title>LRU Scan/Eviction Support</title>
!Pdrivers/gpu/drm/drm_mm.c lru scan roaster
</sect3>
</sect3>
</sect2>
<sect2>
<title>DRM MM Range Allocator Function References</title>
<sect2>
<title>DRM MM Range Allocator Function References</title>
!Edrivers/gpu/drm/drm_mm.c
!Iinclude/drm/drm_mm.h
</sect2>
</sect2>
<sect2>
<title>CMA Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_gem_cma_helper.c cma helpers
!Edrivers/gpu/drm/drm_gem_cma_helper.c
!Iinclude/drm/drm_gem_cma_helper.h
</sect2>
</sect1>
<!-- Internals: mode setting -->
@ -995,6 +1000,10 @@ int max_width, max_height;</synopsis>
<title>Display Modes Function Reference</title>
!Iinclude/drm/drm_modes.h
!Edrivers/gpu/drm/drm_modes.c
</sect2>
<sect2>
<title>Atomic Mode Setting Function Reference</title>
!Edrivers/gpu/drm/drm_atomic.c
</sect2>
<sect2>
<title>Frame Buffer Creation</title>
@ -1826,6 +1835,10 @@ void intel_crt_init(struct drm_device *dev)
<sect2>
<title>KMS API Functions</title>
!Edrivers/gpu/drm/drm_crtc.c
</sect2>
<sect2>
<title>KMS Data Structures</title>
!Iinclude/drm/drm_crtc.h
</sect2>
<sect2>
<title>KMS Locking</title>
@ -1934,10 +1947,16 @@ void intel_crt_init(struct drm_device *dev)
and then retrieves a list of modes by calling the connector
<methodname>get_modes</methodname> helper operation.
</para>
<para>
If the helper operation returns no mode, and if the connector status
is connector_status_connected, standard VESA DMT modes up to
1024x768 are automatically added to the modes list by a call to
<function>drm_add_modes_noedid</function>.
</para>
<para>
The function filters out modes larger than
The function then filters out modes larger than
<parameter>max_width</parameter> and <parameter>max_height</parameter>
if specified. It then calls the optional connector
if specified. It finally calls the optional connector
<methodname>mode_valid</methodname> helper operation for each mode in
the probed list to check whether the mode is valid for the connector.
</para>
@ -2077,11 +2096,19 @@ void intel_crt_init(struct drm_device *dev)
<synopsis>int (*get_modes)(struct drm_connector *connector);</synopsis>
<para>
Fill the connector's <structfield>probed_modes</structfield> list
by parsing EDID data with <function>drm_add_edid_modes</function> or
calling <function>drm_mode_probed_add</function> directly for every
by parsing EDID data with <function>drm_add_edid_modes</function>,
adding standard VESA DMT modes with <function>drm_add_modes_noedid</function>,
or calling <function>drm_mode_probed_add</function> directly for every
supported mode and return the number of modes it has detected. This
operation is mandatory.
</para>
<para>
Note that the caller function will automatically add standard VESA
DMT modes up to 1024x768 if the <methodname>get_modes</methodname>
helper operation returns no mode and if the connector status is
connector_status_connected. There is no need to call
<function>drm_add_edid_modes</function> manually in that case.
</para>
<para>
When adding modes manually the driver creates each mode with a call to
<function>drm_mode_create</function> and must fill the following fields.
@ -2279,7 +2306,7 @@ void intel_crt_init(struct drm_device *dev)
<function>drm_helper_probe_single_connector_modes</function>.
</para>
<para>
When parsing EDID data, <function>drm_add_edid_modes</function> fill the
When parsing EDID data, <function>drm_add_edid_modes</function> fills the
connector <structfield>display_info</structfield>
<structfield>width_mm</structfield> and
<structfield>height_mm</structfield> fields. When creating modes
@ -2316,9 +2343,27 @@ void intel_crt_init(struct drm_device *dev)
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Atomic Modeset Helper Functions Reference</title>
<sect3>
<title>Overview</title>
!Pdrivers/gpu/drm/drm_atomic_helper.c overview
</sect3>
<sect3>
<title>Implementing Asynchronous Atomic Commit</title>
!Pdrivers/gpu/drm/drm_atomic_helper.c implementing async commit
</sect3>
<sect3>
<title>Atomic State Reset and Initialization</title>
!Pdrivers/gpu/drm/drm_atomic_helper.c atomic state reset and initialization
</sect3>
!Iinclude/drm/drm_atomic_helper.h
!Edrivers/gpu/drm/drm_atomic_helper.c
</sect2>
<sect2>
<title>Modeset Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_crtc_helper.c
!Pdrivers/gpu/drm/drm_crtc_helper.c overview
</sect2>
<sect2>
<title>Output Probing Helper Functions Reference</title>
@ -2342,6 +2387,12 @@ void intel_crt_init(struct drm_device *dev)
!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
!Iinclude/drm/drm_dp_mst_helper.h
!Edrivers/gpu/drm/drm_dp_mst_topology.c
</sect2>
<sect2>
<title>MIPI DSI Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_mipi_dsi.c dsi helpers
!Iinclude/drm/drm_mipi_dsi.h
!Edrivers/gpu/drm/drm_mipi_dsi.c
</sect2>
<sect2>
<title>EDID Helper Functions Reference</title>
@ -2372,7 +2423,12 @@ void intel_crt_init(struct drm_device *dev)
</sect2>
<sect2>
<title id="drm-kms-planehelpers">Plane Helper Reference</title>
!Edrivers/gpu/drm/drm_plane_helper.c Plane Helpers
!Edrivers/gpu/drm/drm_plane_helper.c
!Pdrivers/gpu/drm/drm_plane_helper.c overview
</sect2>
<sect2>
<title>Tile group</title>
!Pdrivers/gpu/drm/drm_crtc.c Tile group
</sect2>
</sect1>
@ -2508,8 +2564,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Description/Restrictions</td>
</tr>
<tr>
<td rowspan="21" valign="top" >DRM</td>
<td rowspan="2" valign="top" >Generic</td>
<td rowspan="25" valign="top" >DRM</td>
<td rowspan="4" valign="top" >Generic</td>
<td valign="top" >“EDID”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
<td valign="top" >0</td>
@ -2524,6 +2580,20 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Contains DPMS operation mode value.</td>
</tr>
<tr>
<td valign="top" >“PATH”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
<td valign="top" >0</td>
<td valign="top" >Connector</td>
<td valign="top" >Contains topology path to a connector.</td>
</tr>
<tr>
<td valign="top" >“TILE”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
<td valign="top" >0</td>
<td valign="top" >Connector</td>
<td valign="top" >Contains tiling information for a connector.</td>
</tr>
<tr>
<td rowspan="1" valign="top" >Plane</td>
<td valign="top" >“type”</td>
<td valign="top" >ENUM | IMMUTABLE</td>
@ -2639,6 +2709,21 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >Virtual GPU</td>
<td valign="top" >“suggested X”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=0xffffffff</td>
<td valign="top" >Connector</td>
<td valign="top" >property to suggest an X offset for a connector</td>
</tr>
<tr>
<td valign="top" >“suggested Y”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=0xffffffff</td>
<td valign="top" >Connector</td>
<td valign="top" >property to suggest an Y offset for a connector</td>
</tr>
<tr>
<td rowspan="3" valign="top" >Optional</td>
<td valign="top" >“scaling mode”</td>
<td valign="top" >ENUM</td>
@ -3386,6 +3471,13 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
by scheduling a timer. The delay is accessible through the vblankoffdelay
module parameter or the <varname>drm_vblank_offdelay</varname> global
variable and expressed in milliseconds. Its default value is 5000 ms.
Zero means never disable, and a negative value means disable immediately.
Drivers may override the behaviour by setting the
<structname>drm_device</structname>
<structfield>vblank_disable_immediate</structfield> flag, which when set
causes vblank interrupts to be disabled immediately regardless of the
drm_vblank_offdelay value. The flag should only be set if there's a
properly working hardware vblank counter present.
</para>
<para>
When a vertical blanking interrupt occurs drivers only need to call the
@ -3400,6 +3492,7 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
<sect2>
<title>Vertical Blanking and Interrupt Handling Functions Reference</title>
!Edrivers/gpu/drm/drm_irq.c
!Finclude/drm/drmP.h drm_crtc_vblank_waitqueue
</sect2>
</sect1>
@ -3780,6 +3873,26 @@ int num_ioctls;</synopsis>
blocks. This excludes a set of SoC platforms with an SGX rendering unit,
those have basic support through the gma500 drm driver.
</para>
<sect1>
<title>Core Driver Infrastructure</title>
<para>
This section covers core driver infrastructure used by both the display
and the GEM parts of the driver.
</para>
<sect2>
<title>Runtime Power Management</title>
!Pdrivers/gpu/drm/i915/intel_runtime_pm.c runtime pm
!Idrivers/gpu/drm/i915/intel_runtime_pm.c
</sect2>
<sect2>
<title>Interrupt Handling</title>
!Pdrivers/gpu/drm/i915/i915_irq.c interrupt handling
!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_init intel_irq_init_hw intel_hpd_init
!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_fini
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
</sect2>
</sect1>
<sect1>
<title>Display Hardware Handling</title>
<para>
@ -3796,6 +3909,18 @@ int num_ioctls;</synopsis>
configuration change.
</para>
</sect2>
<sect2>
<title>Frontbuffer Tracking</title>
!Pdrivers/gpu/drm/i915/intel_frontbuffer.c frontbuffer tracking
!Idrivers/gpu/drm/i915/intel_frontbuffer.c
!Fdrivers/gpu/drm/i915/intel_drv.h intel_frontbuffer_flip
!Fdrivers/gpu/drm/i915/i915_gem.c i915_gem_track_fb
</sect2>
<sect2>
<title>Display FIFO Underrun Reporting</title>
!Pdrivers/gpu/drm/i915/intel_fifo_underrun.c fifo underrun handling
!Idrivers/gpu/drm/i915/intel_fifo_underrun.c
</sect2>
<sect2>
<title>Plane Configuration</title>
<para>
@ -3815,6 +3940,16 @@ int num_ioctls;</synopsis>
probing, so those sections fully apply.
</para>
</sect2>
<sect2>
<title>High Definition Audio</title>
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port
!Idrivers/gpu/drm/i915/intel_audio.c
</sect2>
<sect2>
<title>Panel Self Refresh PSR (PSR/SRD)</title>
!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD)
!Idrivers/gpu/drm/i915/intel_psr.c
</sect2>
<sect2>
<title>DPIO</title>
!Pdrivers/gpu/drm/i915/i915_reg.h DPIO
@ -3918,7 +4053,34 @@ int num_ioctls;</synopsis>
!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
!Idrivers/gpu/drm/i915/i915_cmd_parser.c
</sect2>
<sect2>
<title>Logical Rings, Logical Ring Contexts and Execlists</title>
!Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists
!Idrivers/gpu/drm/i915/intel_lrc.c
</sect2>
</sect1>
<sect1>
<title> Tracing </title>
<para>
This sections covers all things related to the tracepoints implemented in
the i915 driver.
</para>
<sect2>
<title> i915_ppgtt_create and i915_ppgtt_release </title>
!Pdrivers/gpu/drm/i915/i915_trace.h i915_ppgtt_create and i915_ppgtt_release tracepoints
</sect2>
<sect2>
<title> i915_context_create and i915_context_free </title>
!Pdrivers/gpu/drm/i915/i915_trace.h i915_context_create and i915_context_free tracepoints
</sect2>
<sect2>
<title> switch_mm </title>
!Pdrivers/gpu/drm/i915/i915_trace.h switch_mm tracepoint
</sect2>
</sect1>
</chapter>
!Cdrivers/gpu/drm/i915/i915_irq.c
</part>
</book>

View File

@ -1972,7 +1972,7 @@ machines due to caching.
<itemizedlist>
<listitem>
<para>
<filename>Documentation/spinlocks.txt</filename>:
<filename>Documentation/locking/spinlocks.txt</filename>:
Linus Torvalds' spinlocking tutorial in the kernel sources.
</para>
</listitem>

View File

@ -25,7 +25,7 @@ GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP))
PHONY += cleanmediadocs
cleanmediadocs:
-@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2>/dev/null
-@rm -f `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2>/dev/null
$(obj)/media_api.xml: $(GENFILES) FORCE

View File

@ -120,8 +120,8 @@ struct dtv_properties {
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call sets one or more frontend properties. This call only
requires read-only access to the device.</para>
<para>This ioctl call sets one or more frontend properties. This call
requires read/write access to the device.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS

View File

@ -178,6 +178,75 @@ Signal - NTSC for Studio Applications"</title>
1125-Line High-Definition Production"</title>
</biblioentry>
<biblioentry id="srgb">
<abbrev>sRGB</abbrev>
<authorgroup>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>IEC 61966-2-1 ed1.0 "Multimedia systems and equipment - Colour measurement
and management - Part 2-1: Colour management - Default RGB colour space - sRGB"</title>
</biblioentry>
<biblioentry id="sycc">
<abbrev>sYCC</abbrev>
<authorgroup>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>IEC 61966-2-1-am1 ed1.0 "Amendment 1 - Multimedia systems and equipment - Colour measurement
and management - Part 2-1: Colour management - Default RGB colour space - sRGB"</title>
</biblioentry>
<biblioentry id="xvycc">
<abbrev>xvYCC</abbrev>
<authorgroup>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>IEC 61966-2-4 ed1.0 "Multimedia systems and equipment - Colour measurement
and management - Part 2-4: Colour management - Extended-gamut YCC colour space for video
applications - xvYCC"</title>
</biblioentry>
<biblioentry id="adobergb">
<abbrev>AdobeRGB</abbrev>
<authorgroup>
<corpauthor>Adobe Systems Incorporated (<ulink url="http://www.adobe.com">http://www.adobe.com</ulink>)</corpauthor>
</authorgroup>
<title>Adobe&copy; RGB (1998) Color Image Encoding Version 2005-05</title>
</biblioentry>
<biblioentry id="oprgb">
<abbrev>opRGB</abbrev>
<authorgroup>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>IEC 61966-2-5 "Multimedia systems and equipment - Colour measurement
and management - Part 2-5: Colour management - Optional RGB colour space - opRGB"</title>
</biblioentry>
<biblioentry id="itu2020">
<abbrev>ITU&nbsp;BT.2020</abbrev>
<authorgroup>
<corpauthor>International Telecommunication Union (<ulink
url="http://www.itu.ch">http://www.itu.ch</ulink>)</corpauthor>
</authorgroup>
<title>ITU-R Recommendation BT.2020 (08/2012) "Parameter values for ultra-high
definition television systems for production and international programme exchange"
</title>
</biblioentry>
<biblioentry id="tech3213">
<abbrev>EBU&nbsp;Tech&nbsp;3213</abbrev>
<authorgroup>
<corpauthor>European Broadcast Union (<ulink
url="http://www.ebu.ch">http://www.ebu.ch</ulink>)</corpauthor>
</authorgroup>
<title>E.B.U. Standard for Chromaticity Tolerances for Studio Monitors"</title>
</biblioentry>
<biblioentry id="iec62106">
<abbrev>IEC&nbsp;62106</abbrev>
<authorgroup>
@ -266,4 +335,20 @@ in the frequency range from 87,5 to 108,0 MHz</title>
<subtitle>Version 1, Revision 2</subtitle>
</biblioentry>
<biblioentry id="poynton">
<abbrev>poynton</abbrev>
<authorgroup>
<corpauthor>Charles Poynton</corpauthor>
</authorgroup>
<title>Digital Video and HDTV, Algorithms and Interfaces</title>
</biblioentry>
<biblioentry id="colimg">
<abbrev>colimg</abbrev>
<authorgroup>
<corpauthor>Erik Reinhard et al.</corpauthor>
</authorgroup>
<title>Color Imaging: Fundamentals and Applications</title>
</biblioentry>
</bibliography>

View File

@ -110,7 +110,7 @@ makes no provisions to find these related devices. Some really
complex devices use the Media Controller (see <xref linkend="media_controller" />)
which can be used for this purpose. But most drivers do not use it,
and while some code exists that uses sysfs to discover related devices
(see libmedia_dev in the <ulink url="http://git.linuxtv.org/v4l-utils/">v4l-utils</ulink>
(see libmedia_dev in the <ulink url="http://git.linuxtv.org/cgit.cgi/v4l-utils.git/">v4l-utils</ulink>
git repository), there is no library yet that can provide a single API towards
both Media Controller-based devices and devices that do not use the Media Controller.
If you want to work on this please write to the linux-media mailing list: &v4l-ml;.</para>

View File

@ -2569,6 +2569,28 @@ fields changed from _s32 to _u32.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.18</title>
<orderedlist>
<listitem>
<para>Added <constant>V4L2_CID_PAN_SPEED</constant> and
<constant>V4L2_CID_TILT_SPEED</constant> camera controls.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.19</title>
<orderedlist>
<listitem>
<para>Rewrote Colorspace chapter, added new &v4l2-ycbcr-encoding;
and &v4l2-quantization; fields to &v4l2-pix-format;, &v4l2-pix-format-mplane;
and &v4l2-mbus-framefmt;.
</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>

View File

@ -3965,6 +3965,27 @@ by exposure, white balance or focus controls.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_PAN_SPEED</constant>&nbsp;</entry>
<entry>integer</entry>
</row><row><entry spanname="descr">This control turns the
camera horizontally at the specific speed. The unit is undefined. A
positive value moves the camera to the right (clockwise when viewed
from above), a negative value to the left. A value of zero stops the motion
if one is in progress and has no effect otherwise.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_TILT_SPEED</constant>&nbsp;</entry>
<entry>integer</entry>
</row><row><entry spanname="descr">This control turns the
camera vertically at the specified speed. The unit is undefined. A
positive value moves the camera up, a negative value down. A value of zero
stops the motion if one is in progress and has no effect otherwise.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>
</table>
@ -4790,6 +4811,40 @@ interface and may change in the future.</para>
conversion.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_TEST_PATTERN_RED</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Test pattern red colour component.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_TEST_PATTERN_GREENR</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Test pattern green (next to red)
colour component.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_TEST_PATTERN_BLUE</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Test pattern blue colour component.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_TEST_PATTERN_GREENB</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Test pattern green (next to blue)
colour component.
</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>

View File

@ -195,53 +195,59 @@
<title>Sample Pipeline Configuration</title>
<tgroup cols="3">
<colspec colname="what"/>
<colspec colname="sensor-0" />
<colspec colname="frontend-0" />
<colspec colname="frontend-1" />
<colspec colname="scaler-0" />
<colspec colname="scaler-1" />
<colspec colname="sensor-0 format" />
<colspec colname="frontend-0 format" />
<colspec colname="frontend-1 format" />
<colspec colname="scaler-0 format" />
<colspec colname="scaler-0 compose" />
<colspec colname="scaler-1 format" />
<thead>
<row>
<entry></entry>
<entry>Sensor/0</entry>
<entry>Frontend/0</entry>
<entry>Frontend/1</entry>
<entry>Scaler/0</entry>
<entry>Scaler/1</entry>
<entry>Sensor/0 format</entry>
<entry>Frontend/0 format</entry>
<entry>Frontend/1 format</entry>
<entry>Scaler/0 format</entry>
<entry>Scaler/0 compose selection rectangle</entry>
<entry>Scaler/1 format</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry>Initial state</entry>
<entry>2048x1536</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>(default)</entry>
<entry>(default)</entry>
<entry>(default)</entry>
<entry>(default)</entry>
<entry>(default)</entry>
</row>
<row>
<entry>Configure frontend input</entry>
<entry>2048x1536</entry>
<entry><emphasis>2048x1536</emphasis></entry>
<entry><emphasis>2046x1534</emphasis></entry>
<entry>-</entry>
<entry>-</entry>
<entry>Configure frontend sink format</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry><emphasis>2048x1536/SGRBG8_1X8</emphasis></entry>
<entry><emphasis>2046x1534/SGRBG8_1X8</emphasis></entry>
<entry>(default)</entry>
<entry>(default)</entry>
<entry>(default)</entry>
</row>
<row>
<entry>Configure scaler input</entry>
<entry>2048x1536</entry>
<entry>2048x1536</entry>
<entry>2046x1534</entry>
<entry><emphasis>2046x1534</emphasis></entry>
<entry><emphasis>2046x1534</emphasis></entry>
<entry>Configure scaler sink format</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>2046x1534/SGRBG8_1X8</entry>
<entry><emphasis>2046x1534/SGRBG8_1X8</emphasis></entry>
<entry><emphasis>0,0/2046x1534</emphasis></entry>
<entry><emphasis>2046x1534/SGRBG8_1X8</emphasis></entry>
</row>
<row>
<entry>Configure scaler output</entry>
<entry>2048x1536</entry>
<entry>2048x1536</entry>
<entry>2046x1534</entry>
<entry>2046x1534</entry>
<entry><emphasis>1280x960</emphasis></entry>
<entry>Configure scaler sink compose selection</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>2046x1534/SGRBG8_1X8</entry>
<entry>2046x1534/SGRBG8_1X8</entry>
<entry><emphasis>0,0/1280x960</emphasis></entry>
<entry><emphasis>1280x960/SGRBG8_1X8</emphasis></entry>
</row>
</tbody>
</tgroup>
@ -249,19 +255,30 @@
<para>
<orderedlist>
<listitem><para>Initial state. The sensor output is set to its native 3MP
resolution. Resolutions on the host frontend and scaler input and output
pads are undefined.</para></listitem>
<listitem><para>The application configures the frontend input pad resolution to
2048x1536. The driver propagates the format to the frontend output pad.
Note that the propagated output format can be different, as in this case,
than the input format, as the hardware might need to crop pixels (for
instance when converting a Bayer filter pattern to RGB or YUV).</para></listitem>
<listitem><para>The application configures the scaler input pad resolution to
2046x1534 to match the frontend output resolution. The driver propagates
the format to the scaler output pad.</para></listitem>
<listitem><para>The application configures the scaler output pad resolution to
1280x960.</para></listitem>
<listitem><para>Initial state. The sensor source pad format is
set to its native 3MP size and V4L2_MBUS_FMT_SGRBG8_1X8
media bus code. Formats on the host frontend and scaler sink
and source pads have the default values, as well as the
compose rectangle on the scaler's sink pad.</para></listitem>
<listitem><para>The application configures the frontend sink
pad format's size to 2048x1536 and its media bus code to
V4L2_MBUS_FMT_SGRBG_1X8. The driver propagates the format to
the frontend source pad.</para></listitem>
<listitem><para>The application configures the scaler sink pad
format's size to 2046x1534 and the media bus code to
V4L2_MBUS_FMT_SGRBG_1X8 to match the frontend source size and
media bus code. The media bus code on the sink pad is set to
V4L2_MBUS_FMT_SGRBG_1X8. The driver propagates the size to the
compose selection rectangle on the scaler's sink pad, and the
format to the scaler source pad.</para></listitem>
<listitem><para>The application configures the size of the compose
selection rectangle of the scaler's sink pad 1280x960. The driver
propagates the size to the scaler's source pad
format.</para></listitem>
</orderedlist>
</para>

View File

@ -1422,7 +1422,10 @@ one of the <constant>V4L2_FIELD_NONE</constant>,
<constant>V4L2_FIELD_BOTTOM</constant>, or
<constant>V4L2_FIELD_INTERLACED</constant> formats is acceptable.
Drivers choose depending on hardware capabilities or e.&nbsp;g. the
requested image size, and return the actual field order. &v4l2-buffer;
requested image size, and return the actual field order. Drivers must
never return <constant>V4L2_FIELD_ANY</constant>. If multiple
field orders are possible the driver must choose one of the possible
field orders during &VIDIOC-S-FMT; or &VIDIOC-TRY-FMT;. &v4l2-buffer;
<structfield>field</structfield> can never be
<constant>V4L2_FIELD_ANY</constant>.</entry>
</row>

View File

@ -237,9 +237,9 @@ for a pixel lie next to each other in memory.</para>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-RGB555X">
<entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry>
<entry>'RGBQ'</entry>
<row id="V4L2-PIX-FMT-ARGB555X">
<entry><constant>V4L2_PIX_FMT_ARGB555X</constant></entry>
<entry>'AR15' | (1 &lt;&lt; 31)</entry>
<entry></entry>
<entry>a</entry>
<entry>r<subscript>4</subscript></entry>
@ -259,6 +259,28 @@ for a pixel lie next to each other in memory.</para>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-XRGB555X">
<entry><constant>V4L2_PIX_FMT_XRGB555X</constant></entry>
<entry>'XR15' | (1 &lt;&lt; 31)</entry>
<entry></entry>
<entry>-</entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-RGB565X">
<entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry>
<entry>'RGBR'</entry>
@ -464,7 +486,7 @@ for a pixel lie next to each other in memory.</para>
</row>
<row id="V4L2-PIX-FMT-ARGB32">
<entry><constant>V4L2_PIX_FMT_ARGB32</constant></entry>
<entry>'AX24'</entry>
<entry>'BA24'</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry>
@ -800,6 +822,28 @@ image</title>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-RGB555X">
<entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry>
<entry>'RGBQ'</entry>
<entry></entry>
<entry>a</entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-BGR32">
<entry><constant>V4L2_PIX_FMT_BGR32</constant></entry>
<entry>'BGR4'</entry>

File diff suppressed because it is too large Load Diff

View File

@ -62,6 +62,22 @@
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_NATIVE_SIZE</constant></entry>
<entry>0x0003</entry>
<entry>The native size of the device, e.g. a sensor's
pixel array. <structfield>left</structfield> and
<structfield>top</structfield> fields are zero for this
target. Setting the native size will generally only make
sense for memory to memory devices where the software can
create a canvas of a given size in which for example a
video frame can be composed. In that case
V4L2_SEL_TGT_NATIVE_SIZE can be used to configure the size
of that canvas.
</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE</constant></entry>
<entry>0x0100</entry>

View File

@ -33,9 +33,25 @@
<entry>Image colorspace, from &v4l2-colorspace;. See
<xref linkend="colorspaces" /> for details.</entry>
</row>
<row>
<entry>&v4l2-ycbcr-encoding;</entry>
<entry><structfield>ycbcr_enc</structfield></entry>
<entry>This information supplements the
<structfield>colorspace</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
<row>
<entry>&v4l2-quantization;</entry>
<entry><structfield>quantization</structfield></entry>
<entry>This information supplements the
<structfield>colorspace</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[7]</entry>
<entry><structfield>reserved</structfield>[6]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
@ -86,7 +102,7 @@
green and 5-bit blue values padded on the high bit, transferred as 2 8-bit
samples per pixel with the most significant bits (padding, red and half of
the green value) transferred first will be named
<constant>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</constant>.
<constant>MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE</constant>.
</para>
<para>The following tables list existing packed RGB formats.</para>
@ -176,8 +192,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-RGB444-2X8-PADHI-BE">
<entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry>
<row id="MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE">
<entry>MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE</entry>
<entry>0x1001</entry>
<entry></entry>
&dash-ent-24;
@ -204,8 +220,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB444-2X8-PADHI-LE">
<entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry>
<row id="MEDIA-BUS-FMT-RGB444-2X8-PADHI-LE">
<entry>MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE</entry>
<entry>0x1002</entry>
<entry></entry>
&dash-ent-24;
@ -232,8 +248,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB555-2X8-PADHI-BE">
<entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry>
<row id="MEDIA-BUS-FMT-RGB555-2X8-PADHI-BE">
<entry>MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE</entry>
<entry>0x1003</entry>
<entry></entry>
&dash-ent-24;
@ -260,8 +276,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB555-2X8-PADHI-LE">
<entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry>
<row id="MEDIA-BUS-FMT-RGB555-2X8-PADHI-LE">
<entry>MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE</entry>
<entry>0x1004</entry>
<entry></entry>
&dash-ent-24;
@ -288,8 +304,8 @@
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-BGR565-2X8-BE">
<entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry>
<row id="MEDIA-BUS-FMT-BGR565-2X8-BE">
<entry>MEDIA_BUS_FMT_BGR565_2X8_BE</entry>
<entry>0x1005</entry>
<entry></entry>
&dash-ent-24;
@ -316,8 +332,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-BGR565-2X8-LE">
<entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry>
<row id="MEDIA-BUS-FMT-BGR565-2X8-LE">
<entry>MEDIA_BUS_FMT_BGR565_2X8_LE</entry>
<entry>0x1006</entry>
<entry></entry>
&dash-ent-24;
@ -344,8 +360,8 @@
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB565-2X8-BE">
<entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry>
<row id="MEDIA-BUS-FMT-RGB565-2X8-BE">
<entry>MEDIA_BUS_FMT_RGB565_2X8_BE</entry>
<entry>0x1007</entry>
<entry></entry>
&dash-ent-24;
@ -372,8 +388,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB565-2X8-LE">
<entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry>
<row id="MEDIA-BUS-FMT-RGB565-2X8-LE">
<entry>MEDIA_BUS_FMT_RGB565_2X8_LE</entry>
<entry>0x1008</entry>
<entry></entry>
&dash-ent-24;
@ -400,8 +416,8 @@
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB666-1X18">
<entry>V4L2_MBUS_FMT_RGB666_1X18</entry>
<row id="MEDIA-BUS-FMT-RGB666-1X18">
<entry>MEDIA_BUS_FMT_RGB666_1X18</entry>
<entry>0x1009</entry>
<entry></entry>
&dash-ent-14;
@ -424,8 +440,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB888-1X24">
<entry>V4L2_MBUS_FMT_RGB888_1X24</entry>
<row id="MEDIA-BUS-FMT-RGB888-1X24">
<entry>MEDIA_BUS_FMT_RGB888_1X24</entry>
<entry>0x100a</entry>
<entry></entry>
&dash-ent-8;
@ -454,8 +470,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB888-2X12-BE">
<entry>V4L2_MBUS_FMT_RGB888_2X12_BE</entry>
<row id="MEDIA-BUS-FMT-RGB888-2X12-BE">
<entry>MEDIA_BUS_FMT_RGB888_2X12_BE</entry>
<entry>0x100b</entry>
<entry></entry>
&dash-ent-20;
@ -490,8 +506,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB888-2X12-LE">
<entry>V4L2_MBUS_FMT_RGB888_2X12_LE</entry>
<row id="MEDIA-BUS-FMT-RGB888-2X12-LE">
<entry>MEDIA_BUS_FMT_RGB888_2X12_LE</entry>
<entry>0x100c</entry>
<entry></entry>
&dash-ent-20;
@ -526,8 +542,8 @@
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-ARGB888-1X32">
<entry>V4L2_MBUS_FMT_ARGB888_1X32</entry>
<row id="MEDIA-BUS-FMT-ARGB888-1X32">
<entry>MEDIA_BUS_FMT_ARGB888_1X32</entry>
<entry>0x100d</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
@ -600,7 +616,7 @@
<para>For instance, a format with uncompressed 10-bit Bayer components
arranged in a red, green, green, blue pattern transferred as 2 8-bit
samples per pixel with the least significant bits transferred first will
be named <constant>V4L2_MBUS_FMT_SRGGB10_2X8_PADHI_LE</constant>.
be named <constant>MEDIA_BUS_FMT_SRGGB10_2X8_PADHI_LE</constant>.
</para>
<figure id="bayer-patterns">
@ -663,8 +679,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-SBGGR8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR8_1X8</entry>
<row id="MEDIA-BUS-FMT-SBGGR8-1X8">
<entry>MEDIA_BUS_FMT_SBGGR8_1X8</entry>
<entry>0x3001</entry>
<entry></entry>
<entry>-</entry>
@ -680,8 +696,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGBRG8-1X8">
<entry>MEDIA_BUS_FMT_SGBRG8_1X8</entry>
<entry>0x3013</entry>
<entry></entry>
<entry>-</entry>
@ -697,8 +713,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGRBG8-1X8">
<entry>MEDIA_BUS_FMT_SGRBG8_1X8</entry>
<entry>0x3002</entry>
<entry></entry>
<entry>-</entry>
@ -714,8 +730,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB8_1X8</entry>
<row id="MEDIA-BUS-FMT-SRGGB8-1X8">
<entry>MEDIA_BUS_FMT_SRGGB8_1X8</entry>
<entry>0x3014</entry>
<entry></entry>
<entry>-</entry>
@ -731,8 +747,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-ALAW8-1X8">
<entry>MEDIA_BUS_FMT_SBGGR10_ALAW8_1X8</entry>
<entry>0x3015</entry>
<entry></entry>
<entry>-</entry>
@ -748,8 +764,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGBRG10-ALAW8-1X8">
<entry>MEDIA_BUS_FMT_SGBRG10_ALAW8_1X8</entry>
<entry>0x3016</entry>
<entry></entry>
<entry>-</entry>
@ -765,8 +781,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGRBG10-ALAW8-1X8">
<entry>MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8</entry>
<entry>0x3017</entry>
<entry></entry>
<entry>-</entry>
@ -782,8 +798,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry>
<row id="MEDIA-BUS-FMT-SRGGB10-ALAW8-1X8">
<entry>MEDIA_BUS_FMT_SRGGB10_ALAW8_1X8</entry>
<entry>0x3018</entry>
<entry></entry>
<entry>-</entry>
@ -799,8 +815,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-DPCM8-1X8">
<entry>MEDIA_BUS_FMT_SBGGR10_DPCM8_1X8</entry>
<entry>0x300b</entry>
<entry></entry>
<entry>-</entry>
@ -816,8 +832,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGBRG10-DPCM8-1X8">
<entry>MEDIA_BUS_FMT_SGBRG10_DPCM8_1X8</entry>
<entry>0x300c</entry>
<entry></entry>
<entry>-</entry>
@ -833,8 +849,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGRBG10-DPCM8-1X8">
<entry>MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8</entry>
<entry>0x3009</entry>
<entry></entry>
<entry>-</entry>
@ -850,8 +866,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8</entry>
<row id="MEDIA-BUS-FMT-SRGGB10-DPCM8-1X8">
<entry>MEDIA_BUS_FMT_SRGGB10_DPCM8_1X8</entry>
<entry>0x300d</entry>
<entry></entry>
<entry>-</entry>
@ -867,8 +883,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADHI-BE">
<entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-2X8-PADHI-BE">
<entry>MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE</entry>
<entry>0x3003</entry>
<entry></entry>
<entry>-</entry>
@ -901,8 +917,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADHI-LE">
<entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-2X8-PADHI-LE">
<entry>MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE</entry>
<entry>0x3004</entry>
<entry></entry>
<entry>-</entry>
@ -935,8 +951,8 @@
<entry>b<subscript>9</subscript></entry>
<entry>b<subscript>8</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADLO-BE">
<entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-2X8-PADLO-BE">
<entry>MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_BE</entry>
<entry>0x3005</entry>
<entry></entry>
<entry>-</entry>
@ -969,8 +985,8 @@
<entry>0</entry>
<entry>0</entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADLO-LE">
<entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-2X8-PADLO-LE">
<entry>MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_LE</entry>
<entry>0x3006</entry>
<entry></entry>
<entry>-</entry>
@ -1003,8 +1019,8 @@
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-1X10">
<entry>V4L2_MBUS_FMT_SBGGR10_1X10</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-1X10">
<entry>MEDIA_BUS_FMT_SBGGR10_1X10</entry>
<entry>0x3007</entry>
<entry></entry>
<entry>-</entry>
@ -1020,8 +1036,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG10-1X10">
<entry>V4L2_MBUS_FMT_SGBRG10_1X10</entry>
<row id="MEDIA-BUS-FMT-SGBRG10-1X10">
<entry>MEDIA_BUS_FMT_SGBRG10_1X10</entry>
<entry>0x300e</entry>
<entry></entry>
<entry>-</entry>
@ -1037,8 +1053,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG10-1X10">
<entry>V4L2_MBUS_FMT_SGRBG10_1X10</entry>
<row id="MEDIA-BUS-FMT-SGRBG10-1X10">
<entry>MEDIA_BUS_FMT_SGRBG10_1X10</entry>
<entry>0x300a</entry>
<entry></entry>
<entry>-</entry>
@ -1054,8 +1070,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB10-1X10">
<entry>V4L2_MBUS_FMT_SRGGB10_1X10</entry>
<row id="MEDIA-BUS-FMT-SRGGB10-1X10">
<entry>MEDIA_BUS_FMT_SRGGB10_1X10</entry>
<entry>0x300f</entry>
<entry></entry>
<entry>-</entry>
@ -1071,8 +1087,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR12-1X12">
<entry>V4L2_MBUS_FMT_SBGGR12_1X12</entry>
<row id="MEDIA-BUS-FMT-SBGGR12-1X12">
<entry>MEDIA_BUS_FMT_SBGGR12_1X12</entry>
<entry>0x3008</entry>
<entry></entry>
<entry>b<subscript>11</subscript></entry>
@ -1088,8 +1104,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG12-1X12">
<entry>V4L2_MBUS_FMT_SGBRG12_1X12</entry>
<row id="MEDIA-BUS-FMT-SGBRG12-1X12">
<entry>MEDIA_BUS_FMT_SGBRG12_1X12</entry>
<entry>0x3010</entry>
<entry></entry>
<entry>g<subscript>11</subscript></entry>
@ -1105,8 +1121,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG12-1X12">
<entry>V4L2_MBUS_FMT_SGRBG12_1X12</entry>
<row id="MEDIA-BUS-FMT-SGRBG12-1X12">
<entry>MEDIA_BUS_FMT_SGRBG12_1X12</entry>
<entry>0x3011</entry>
<entry></entry>
<entry>g<subscript>11</subscript></entry>
@ -1122,8 +1138,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB12-1X12">
<entry>V4L2_MBUS_FMT_SRGGB12_1X12</entry>
<row id="MEDIA-BUS-FMT-SRGGB12-1X12">
<entry>MEDIA_BUS_FMT_SRGGB12_1X12</entry>
<entry>0x3012</entry>
<entry></entry>
<entry>r<subscript>11</subscript></entry>
@ -1175,7 +1191,7 @@
<para>For instance, a format where pixels are encoded as 8-bit YUV values
downsampled to 4:2:2 and transferred as 2 8-bit bus samples per pixel in the
U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>.
U, Y, V, Y order will be named <constant>MEDIA_BUS_FMT_UYVY8_2X8</constant>.
</para>
<para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> lists existing packed YUV
@ -1280,8 +1296,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-Y8-1X8">
<entry>V4L2_MBUS_FMT_Y8_1X8</entry>
<row id="MEDIA-BUS-FMT-Y8-1X8">
<entry>MEDIA_BUS_FMT_Y8_1X8</entry>
<entry>0x2001</entry>
<entry></entry>
&dash-ent-24;
@ -1294,8 +1310,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UV8-1X8">
<entry>V4L2_MBUS_FMT_UV8_1X8</entry>
<row id="MEDIA-BUS-FMT-UV8-1X8">
<entry>MEDIA_BUS_FMT_UV8_1X8</entry>
<entry>0x2015</entry>
<entry></entry>
&dash-ent-24;
@ -1322,8 +1338,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-1_5X8">
<entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry>
<row id="MEDIA-BUS-FMT-UYVY8-1_5X8">
<entry>MEDIA_BUS_FMT_UYVY8_1_5X8</entry>
<entry>0x2002</entry>
<entry></entry>
&dash-ent-24;
@ -1406,8 +1422,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY8-1_5X8">
<entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry>
<row id="MEDIA-BUS-FMT-VYUY8-1_5X8">
<entry>MEDIA_BUS_FMT_VYUY8_1_5X8</entry>
<entry>0x2003</entry>
<entry></entry>
&dash-ent-24;
@ -1490,8 +1506,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV8-1_5X8">
<entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry>
<row id="MEDIA-BUS-FMT-YUYV8-1_5X8">
<entry>MEDIA_BUS_FMT_YUYV8_1_5X8</entry>
<entry>0x2004</entry>
<entry></entry>
&dash-ent-24;
@ -1574,8 +1590,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU8-1_5X8">
<entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry>
<row id="MEDIA-BUS-FMT-YVYU8-1_5X8">
<entry>MEDIA_BUS_FMT_YVYU8_1_5X8</entry>
<entry>0x2005</entry>
<entry></entry>
&dash-ent-24;
@ -1658,8 +1674,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-2X8">
<entry>V4L2_MBUS_FMT_UYVY8_2X8</entry>
<row id="MEDIA-BUS-FMT-UYVY8-2X8">
<entry>MEDIA_BUS_FMT_UYVY8_2X8</entry>
<entry>0x2006</entry>
<entry></entry>
&dash-ent-24;
@ -1714,8 +1730,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY8-2X8">
<entry>V4L2_MBUS_FMT_VYUY8_2X8</entry>
<row id="MEDIA-BUS-FMT-VYUY8-2X8">
<entry>MEDIA_BUS_FMT_VYUY8_2X8</entry>
<entry>0x2007</entry>
<entry></entry>
&dash-ent-24;
@ -1770,8 +1786,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV8-2X8">
<entry>V4L2_MBUS_FMT_YUYV8_2X8</entry>
<row id="MEDIA-BUS-FMT-YUYV8-2X8">
<entry>MEDIA_BUS_FMT_YUYV8_2X8</entry>
<entry>0x2008</entry>
<entry></entry>
&dash-ent-24;
@ -1826,8 +1842,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU8-2X8">
<entry>V4L2_MBUS_FMT_YVYU8_2X8</entry>
<row id="MEDIA-BUS-FMT-YVYU8-2X8">
<entry>MEDIA_BUS_FMT_YVYU8_2X8</entry>
<entry>0x2009</entry>
<entry></entry>
&dash-ent-24;
@ -1882,8 +1898,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-Y10-1X10">
<entry>V4L2_MBUS_FMT_Y10_1X10</entry>
<row id="MEDIA-BUS-FMT-Y10-1X10">
<entry>MEDIA_BUS_FMT_Y10_1X10</entry>
<entry>0x200a</entry>
<entry></entry>
&dash-ent-22;
@ -1898,8 +1914,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY10-2X10">
<entry>V4L2_MBUS_FMT_UYVY10_2X10</entry>
<row id="MEDIA-BUS-FMT-UYVY10-2X10">
<entry>MEDIA_BUS_FMT_UYVY10_2X10</entry>
<entry>0x2018</entry>
<entry></entry>
&dash-ent-22;
@ -1962,8 +1978,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY10-2X10">
<entry>V4L2_MBUS_FMT_VYUY10_2X10</entry>
<row id="MEDIA-BUS-FMT-VYUY10-2X10">
<entry>MEDIA_BUS_FMT_VYUY10_2X10</entry>
<entry>0x2019</entry>
<entry></entry>
&dash-ent-22;
@ -2026,8 +2042,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV10-2X10">
<entry>V4L2_MBUS_FMT_YUYV10_2X10</entry>
<row id="MEDIA-BUS-FMT-YUYV10-2X10">
<entry>MEDIA_BUS_FMT_YUYV10_2X10</entry>
<entry>0x200b</entry>
<entry></entry>
&dash-ent-22;
@ -2090,8 +2106,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU10-2X10">
<entry>V4L2_MBUS_FMT_YVYU10_2X10</entry>
<row id="MEDIA-BUS-FMT-YVYU10-2X10">
<entry>MEDIA_BUS_FMT_YVYU10_2X10</entry>
<entry>0x200c</entry>
<entry></entry>
&dash-ent-22;
@ -2154,8 +2170,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-Y12-1X12">
<entry>V4L2_MBUS_FMT_Y12_1X12</entry>
<row id="MEDIA-BUS-FMT-Y12-1X12">
<entry>MEDIA_BUS_FMT_Y12_1X12</entry>
<entry>0x2013</entry>
<entry></entry>
&dash-ent-20;
@ -2172,8 +2188,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-1X16">
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
<row id="MEDIA-BUS-FMT-UYVY8-1X16">
<entry>MEDIA_BUS_FMT_UYVY8_1X16</entry>
<entry>0x200f</entry>
<entry></entry>
&dash-ent-16;
@ -2216,8 +2232,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY8-1X16">
<entry>V4L2_MBUS_FMT_VYUY8_1X16</entry>
<row id="MEDIA-BUS-FMT-VYUY8-1X16">
<entry>MEDIA_BUS_FMT_VYUY8_1X16</entry>
<entry>0x2010</entry>
<entry></entry>
&dash-ent-16;
@ -2260,8 +2276,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV8-1X16">
<entry>V4L2_MBUS_FMT_YUYV8_1X16</entry>
<row id="MEDIA-BUS-FMT-YUYV8-1X16">
<entry>MEDIA_BUS_FMT_YUYV8_1X16</entry>
<entry>0x2011</entry>
<entry></entry>
&dash-ent-16;
@ -2304,8 +2320,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU8-1X16">
<entry>V4L2_MBUS_FMT_YVYU8_1X16</entry>
<row id="MEDIA-BUS-FMT-YVYU8-1X16">
<entry>MEDIA_BUS_FMT_YVYU8_1X16</entry>
<entry>0x2012</entry>
<entry></entry>
&dash-ent-16;
@ -2348,8 +2364,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YDYUYDYV8-1X16">
<entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry>
<row id="MEDIA-BUS-FMT-YDYUYDYV8-1X16">
<entry>MEDIA_BUS_FMT_YDYUYDYV8_1X16</entry>
<entry>0x2014</entry>
<entry></entry>
&dash-ent-16;
@ -2436,8 +2452,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY10-1X20">
<entry>V4L2_MBUS_FMT_UYVY10_1X20</entry>
<row id="MEDIA-BUS-FMT-UYVY10-1X20">
<entry>MEDIA_BUS_FMT_UYVY10_1X20</entry>
<entry>0x201a</entry>
<entry></entry>
&dash-ent-12;
@ -2488,8 +2504,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY10-1X20">
<entry>V4L2_MBUS_FMT_VYUY10_1X20</entry>
<row id="MEDIA-BUS-FMT-VYUY10-1X20">
<entry>MEDIA_BUS_FMT_VYUY10_1X20</entry>
<entry>0x201b</entry>
<entry></entry>
&dash-ent-12;
@ -2540,8 +2556,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV10-1X20">
<entry>V4L2_MBUS_FMT_YUYV10_1X20</entry>
<row id="MEDIA-BUS-FMT-YUYV10-1X20">
<entry>MEDIA_BUS_FMT_YUYV10_1X20</entry>
<entry>0x200d</entry>
<entry></entry>
&dash-ent-12;
@ -2592,8 +2608,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU10-1X20">
<entry>V4L2_MBUS_FMT_YVYU10_1X20</entry>
<row id="MEDIA-BUS-FMT-YVYU10-1X20">
<entry>MEDIA_BUS_FMT_YVYU10_1X20</entry>
<entry>0x200e</entry>
<entry></entry>
&dash-ent-12;
@ -2644,8 +2660,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUV10-1X30">
<entry>V4L2_MBUS_FMT_YUV10_1X30</entry>
<row id="MEDIA-BUS-FMT-YUV10-1X30">
<entry>MEDIA_BUS_FMT_YUV10_1X30</entry>
<entry>0x2016</entry>
<entry></entry>
<entry>-</entry>
@ -2681,8 +2697,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-AYUV8-1X32">
<entry>V4L2_MBUS_FMT_AYUV8_1X32</entry>
<row id="MEDIA-BUS-FMT-AYUV8-1X32">
<entry>MEDIA_BUS_FMT_AYUV8_1X32</entry>
<entry>0x2017</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
@ -2718,8 +2734,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY12-2X12">
<entry>V4L2_MBUS_FMT_UYVY12_2X12</entry>
<row id="MEDIA-BUS-FMT-UYVY12-2X12">
<entry>MEDIA_BUS_FMT_UYVY12_2X12</entry>
<entry>0x201c</entry>
<entry></entry>
&dash-ent-20;
@ -2790,8 +2806,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY12-2X12">
<entry>V4L2_MBUS_FMT_VYUY12_2X12</entry>
<row id="MEDIA-BUS-FMT-VYUY12-2X12">
<entry>MEDIA_BUS_FMT_VYUY12_2X12</entry>
<entry>0x201d</entry>
<entry></entry>
&dash-ent-20;
@ -2862,8 +2878,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV12-2X12">
<entry>V4L2_MBUS_FMT_YUYV12_2X12</entry>
<row id="MEDIA-BUS-FMT-YUYV12-2X12">
<entry>MEDIA_BUS_FMT_YUYV12_2X12</entry>
<entry>0x201e</entry>
<entry></entry>
&dash-ent-20;
@ -2934,8 +2950,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU12-2X12">
<entry>V4L2_MBUS_FMT_YVYU12_2X12</entry>
<row id="MEDIA-BUS-FMT-YVYU12-2X12">
<entry>MEDIA_BUS_FMT_YVYU12_2X12</entry>
<entry>0x201f</entry>
<entry></entry>
&dash-ent-20;
@ -3006,8 +3022,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY12-1X24">
<entry>V4L2_MBUS_FMT_UYVY12_1X24</entry>
<row id="MEDIA-BUS-FMT-UYVY12-1X24">
<entry>MEDIA_BUS_FMT_UYVY12_1X24</entry>
<entry>0x2020</entry>
<entry></entry>
&dash-ent-8;
@ -3066,8 +3082,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY12-1X24">
<entry>V4L2_MBUS_FMT_VYUY12_1X24</entry>
<row id="MEDIA-BUS-FMT-VYUY12-1X24">
<entry>MEDIA_BUS_FMT_VYUY12_1X24</entry>
<entry>0x2021</entry>
<entry></entry>
&dash-ent-8;
@ -3126,8 +3142,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV12-1X24">
<entry>V4L2_MBUS_FMT_YUYV12_1X24</entry>
<row id="MEDIA-BUS-FMT-YUYV12-1X24">
<entry>MEDIA_BUS_FMT_YUYV12_1X24</entry>
<entry>0x2022</entry>
<entry></entry>
&dash-ent-8;
@ -3186,8 +3202,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU12-1X24">
<entry>V4L2_MBUS_FMT_YVYU12_1X24</entry>
<row id="MEDIA-BUS-FMT-YVYU12-1X24">
<entry>MEDIA_BUS_FMT_YVYU12_1X24</entry>
<entry>0x2023</entry>
<entry></entry>
&dash-ent-8;
@ -3366,8 +3382,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-AHSV8888-1X32">
<entry>V4L2_MBUS_FMT_AHSV8888_1X32</entry>
<row id="MEDIA-BUS-FMT-AHSV8888-1X32">
<entry>MEDIA_BUS_FMT_AHSV8888_1X32</entry>
<entry>0x6001</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
@ -3422,7 +3438,7 @@
</para>
<para>For instance, for a JPEG baseline process and an 8-bit bus width
the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>.
the format will be named <constant>MEDIA_BUS_FMT_JPEG_1X8</constant>.
</para>
<para>The following table lists existing JPEG compressed formats.</para>
@ -3441,8 +3457,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-JPEG-1X8">
<entry>V4L2_MBUS_FMT_JPEG_1X8</entry>
<row id="MEDIA-BUS-FMT-JPEG-1X8">
<entry>MEDIA_BUS_FMT_JPEG_1X8</entry>
<entry>0x4001</entry>
<entry>Besides of its usage for the parallel bus this format is
recommended for transmission of JPEG data over MIPI CSI bus
@ -3484,8 +3500,8 @@ interface and may change in the future.</para>
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-S5C-UYVY-JPEG-1X8">
<entry>V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8</entry>
<row id="MEDIA-BUS-FMT-S5C-UYVY-JPEG-1X8">
<entry>MEDIA_BUS_FMT_S5C_UYVY_JPEG_1X8</entry>
<entry>0x5001</entry>
<entry>
Interleaved raw UYVY and JPEG image format with embedded

View File

@ -151,6 +151,15 @@ 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.19</revnumber>
<date>2014-12-05</date>
<authorinitials>hv</authorinitials>
<revremark>Rewrote Colorspace chapter, added new &v4l2-ycbcr-encoding; and &v4l2-quantization; fields
to &v4l2-pix-format;, &v4l2-pix-format-mplane; and &v4l2-mbus-framefmt;.
</revremark>
</revision>
<revision>
<revnumber>3.17</revnumber>
<date>2014-08-04</date>
@ -539,7 +548,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.17</subtitle>
<subtitle>Revision 3.19</subtitle>
<chapter id="common">
&sub-common;

View File

@ -76,21 +76,22 @@
<entry></entry>
<entry>&v4l2-event-vsync;</entry>
<entry><structfield>vsync</structfield></entry>
<entry>Event data for event V4L2_EVENT_VSYNC.
<entry>Event data for event <constant>V4L2_EVENT_VSYNC</constant>.
</entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-event-ctrl;</entry>
<entry><structfield>ctrl</structfield></entry>
<entry>Event data for event V4L2_EVENT_CTRL.
<entry>Event data for event <constant>V4L2_EVENT_CTRL</constant>.
</entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-event-frame-sync;</entry>
<entry><structfield>frame_sync</structfield></entry>
<entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
<entry>Event data for event
<constant>V4L2_EVENT_FRAME_SYNC</constant>.</entry>
</row>
<row>
<entry></entry>

View File

@ -287,6 +287,14 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
<entry>0x00000004</entry>
<entry>This input supports setting the TV standard by using VIDIOC_S_STD.</entry>
</row>
<row>
<entry><constant>V4L2_IN_CAP_NATIVE_SIZE</constant></entry>
<entry>0x00000008</entry>
<entry>This input supports setting the native size using
the <constant>V4L2_SEL_TGT_NATIVE_SIZE</constant>
selection target, see <xref
linkend="v4l2-selections-common"/>.</entry>
</row>
</tbody>
</tgroup>
</table>

View File

@ -172,6 +172,14 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
<entry>0x00000004</entry>
<entry>This output supports setting the TV standard by using VIDIOC_S_STD.</entry>
</row>
<row>
<entry><constant>V4L2_OUT_CAP_NATIVE_SIZE</constant></entry>
<entry>0x00000008</entry>
<entry>This output supports setting the native size using
the <constant>V4L2_SEL_TGT_NATIVE_SIZE</constant>
selection target, see <xref
linkend="v4l2-selections-common"/>.</entry>
</row>
</tbody>
</tgroup>
</table>

View File

@ -24,7 +24,7 @@
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>const struct v4l2_edid *<parameter>argp</parameter></paramdef>
<paramdef>struct v4l2_edid *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
@ -124,18 +124,18 @@
maximum number of blocks as defined by the standard). When you set the EDID and
<structfield>blocks</structfield> is 0, then the EDID is disabled or erased.</entry>
</row>
<row>
<entry>__u8&nbsp;*</entry>
<entry><structfield>edid</structfield></entry>
<entry>Pointer to memory that contains the EDID. The minimum size is
<structfield>blocks</structfield>&nbsp;*&nbsp;128.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[5]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
<row>
<entry>__u8&nbsp;*</entry>
<entry><structfield>edid</structfield></entry>
<entry>Pointer to memory that contains the EDID. The minimum size is
<structfield>blocks</structfield>&nbsp;*&nbsp;128.</entry>
</row>
</tbody>
</tgroup>
</table>

View File

@ -176,7 +176,7 @@
</row>
<row>
<entry><constant>V4L2_EVENT_MOTION_DET</constant></entry>
<entry>5</entry>
<entry>6</entry>
<entry>
<para>Triggered whenever the motion detection state for one or more of the regions
changes. This event has a &v4l2-event-motion-det; associated with it.</para>

View File

@ -540,7 +540,7 @@ appears in sysfs.
</para></listitem>
<listitem><para>
<varname>unsigned long size</varname>: Fill in the size of the
<varname>resource_size_t size</varname>: Fill in the size of the
memory block that <varname>addr</varname> points to. If <varname>size</varname>
is zero, the mapping is considered unused. Note that you
<emphasis>must</emphasis> initialize <varname>size</varname> with zero for

View File

@ -593,7 +593,7 @@ for (;;) {
Each device has one control endpoint (endpoint zero)
which supports a limited RPC style RPC access.
Devices are configured
by khubd (in the kernel) setting a device-wide
by hub_wq (in the kernel) setting a device-wide
<emphasis>configuration</emphasis> that affects things
like power consumption and basic functionality.
The endpoints are part of USB <emphasis>interfaces</emphasis>,

View File

@ -2742,7 +2742,9 @@ struct _snd_pcm_runtime {
<para>
Another note is that this callback is non-atomic
(schedulable). This is important, because the
(schedulable) as default, i.e. when no
<structfield>nonatomic</structfield> flag set.
This is important, because the
<structfield>trigger</structfield> callback
is atomic (non-schedulable). That is, mutexes or any
schedule-related functions are not available in
@ -2900,8 +2902,9 @@ struct _snd_pcm_runtime {
</para>
<para>
As mentioned, this callback is atomic. You cannot call
functions which may sleep.
As mentioned, this callback is atomic as default unless
<structfield>nonatomic</structfield> flag set, and
you cannot call functions which may sleep.
The trigger callback should be as minimal as possible,
just really triggering the DMA. The other stuff should be
initialized hw_params and prepare callbacks properly
@ -2936,7 +2939,7 @@ struct _snd_pcm_runtime {
</para>
<para>
This callback is also atomic.
This callback is also atomic as default.
</para>
</section>
@ -2972,7 +2975,7 @@ struct _snd_pcm_runtime {
is useful only for such a purpose.
</para>
<para>
This callback is atomic.
This callback is atomic as default.
</para>
</section>
@ -3175,6 +3178,21 @@ struct _snd_pcm_runtime {
called with local interrupts disabled.
</para>
<para>
The recent changes in PCM core code, however, allow all PCM
operations to be non-atomic. This assumes that the all caller
sides are in non-atomic contexts. For example, the function
<function>snd_pcm_period_elapsed()</function> is called
typically from the interrupt handler. But, if you set up the
driver to use a threaded interrupt handler, this call can be in
non-atomic context, too. In such a case, you can set
<structfield>nonatomic</structfield> filed of
<structname>snd_pcm</structname> object after creating it.
When this flag is set, mutex and rwsem are used internally in
the PCM core instead of spin and rwlocks, so that you can call
all PCM functions safely in a non-atomic context.
</para>
</section>
<section id="pcm-interface-constraints">
<title>Constraints</title>
@ -3639,6 +3657,29 @@ struct _snd_pcm_runtime {
</informalexample>
</para>
<para>
The above callback can be simplified with a helper function,
<function>snd_ctl_enum_info</function>. The final code
looks like below.
(You can pass ARRAY_SIZE(texts) instead of 4 in the third
argument; it's a matter of taste.)
<informalexample>
<programlisting>
<![CDATA[
static int snd_myctl_enum_info(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
static char *texts[4] = {
"First", "Second", "Third", "Fourth"
};
return snd_ctl_enum_info(uinfo, 1, 4, texts);
}
]]>
</programlisting>
</informalexample>
</para>
<para>
Some common info callbacks are available for your convenience:
<function>snd_ctl_boolean_mono_info()</function> and

View File

@ -324,7 +324,6 @@ tree, they need to be integration-tested. For this purpose, a special
testing repository exists into which virtually all subsystem trees are
pulled on an almost daily basis:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
http://linux.f-seidel.de/linux-next/pmwiki/
This way, the -next kernel gives a summary outlook onto what will be
expected to go into the mainline kernel at the next merge period.

View File

@ -42,7 +42,13 @@ The driver interface depends on your hardware. If your system
properly provides the SMBIOS info for IPMI, the driver will detect it
and just work. If you have a board with a standard interface (These
will generally be either "KCS", "SMIC", or "BT", consult your hardware
manual), choose the 'IPMI SI handler' option.
manual), choose the 'IPMI SI handler' option. A driver also exists
for direct I2C access to the IPMI management controller. Some boards
support this, but it is unknown if it will work on every board. For
this, choose 'IPMI SMBus handler', but be ready to try to do some
figuring to see if it will work on your system if the SMBIOS/APCI
information is wrong or not present. It is fairly safe to have both
these enabled and let the drivers auto-detect what is present.
You should generally enable ACPI on your system, as systems with IPMI
can have ACPI tables describing them.
@ -52,7 +58,8 @@ their job correctly, the IPMI controller should be automatically
detected (via ACPI or SMBIOS tables) and should just work. Sadly,
many boards do not have this information. The driver attempts
standard defaults, but they may not work. If you fall into this
situation, you need to read the section below named 'The SI Driver'.
situation, you need to read the section below named 'The SI Driver' or
"The SMBus Driver" on how to hand-configure your system.
IPMI defines a standard watchdog timer. You can enable this with the
'IPMI Watchdog Timer' config option. If you compile the driver into
@ -97,7 +104,12 @@ driver, each open file for this device ties in to the message handler
as an IPMI user.
ipmi_si - A driver for various system interfaces. This supports KCS,
SMIC, and BT interfaces.
SMIC, and BT interfaces. Unless you have an SMBus interface or your
own custom interface, you probably need to use this.
ipmi_ssif - A driver for accessing BMCs on the SMBus. It uses the
I2C kernel driver's SMBus interfaces to send and receive IPMI messages
over the SMBus.
ipmi_watchdog - IPMI requires systems to have a very capable watchdog
timer. This driver implements the standard Linux watchdog timer
@ -476,6 +488,62 @@ for specifying an interface. Note that when removing an interface,
only the first three parameters (si type, address type, and address)
are used for the comparison. Any options are ignored for removing.
The SMBus Driver (SSIF)
-----------------------
The SMBus driver allows up to 4 SMBus devices to be configured in the
system. By default, the driver will only register with something it
finds in DMI or ACPI tables. You can change this
at module load time (for a module) with:
modprobe ipmi_ssif.o
addr=<i2caddr1>[,<i2caddr2>[,...]]
adapter=<adapter1>[,<adapter2>[...]]
dbg=<flags1>,<flags2>...
slave_addrs=<addr1>,<addr2>,...
[dbg_probe=1]
The addresses are normal I2C addresses. The adapter is the string
name of the adapter, as shown in /sys/class/i2c-adapter/i2c-<n>/name.
It is *NOT* i2c-<n> itself.
The debug flags are bit flags for each BMC found, they are:
IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8
Setting dbg_probe to 1 will enable debugging of the probing and
detection process for BMCs on the SMBusses.
The slave_addrs specifies the IPMI address of the local BMC. This is
usually 0x20 and the driver defaults to that, but in case it's not, it
can be specified when the driver starts up.
Discovering the IPMI compliant BMC on the SMBus can cause devices on
the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI
message as a block write to the I2C bus and waits for a response.
This action can be detrimental to some I2C devices. It is highly
recommended that the known I2C address be given to the SMBus driver in
the smb_addr parameter unless you have DMI or ACPI data to tell the
driver what to use.
When compiled into the kernel, the addresses can be specified on the
kernel command line as:
ipmb_ssif.addr=<i2caddr1>[,<i2caddr2>[...]]
ipmi_ssif.adapter=<adapter1>[,<adapter2>[...]]
ipmi_ssif.dbg=<flags1>[,<flags2>[...]]
ipmi_ssif.dbg_probe=1
ipmi_ssif.slave_addrs=<addr1>[,<addr2>[...]]
These are the same options as on the module command line.
The I2C driver does not support non-blocking access or polling, so
this driver cannod to IPMI panic events, extend the watchdog at panic
time, or other panic-related IPMI functions without special kernel
patches and driver modifications. You can get those at the openipmi
web page.
The driver supports a hot add and remove of interfaces through the I2C
sysfs interface.
Other Pieces
------------

View File

@ -151,3 +151,74 @@ used and no descriptor gets allocated it is very important to make sure
that the driver using the simple domain call irq_create_mapping()
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.
==== Hierarchy IRQ domain ====
On some architectures, there may be multiple interrupt controllers
involved in delivering an interrupt from the device to the target CPU.
Let's look at a typical interrupt delivering path on x86 platforms:
Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU
There are three interrupt controllers involved:
1) IOAPIC controller
2) Interrupt remapping controller
3) Local APIC controller
To support such a hardware topology and make software architecture match
hardware architecture, an irq_domain data structure is built for each
interrupt controller and those irq_domains are organized into hierarchy.
When building irq_domain hierarchy, the irq_domain near to the device is
child and the irq_domain near to CPU is parent. So a hierarchy structure
as below will be built for the example above.
CPU Vector irq_domain (root irq_domain to manage CPU vectors)
^
|
Interrupt Remapping irq_domain (manage irq_remapping entries)
^
|
IOAPIC irq_domain (manage IOAPIC delivery entries/pins)
There are four major interfaces to use hierarchy irq_domain:
1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt
controller related resources to deliver these interrupts.
2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller
related resources associated with these interrupts.
3) irq_domain_activate_irq(): activate interrupt controller hardware to
deliver the interrupt.
3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
to stop delivering the interrupt.
Following changes are needed to support hierarchy irq_domain.
1) a new field 'parent' is added to struct irq_domain; it's used to
maintain irq_domain hierarchy information.
2) a new field 'parent_data' is added to struct irq_data; it's used to
build hierarchy irq_data to match hierarchy irq_domains. The irq_data
is used to store irq_domain pointer and hardware irq number.
3) new callbacks are added to struct irq_domain_ops to support hierarchy
irq_domain operations.
With support of hierarchy irq_domain and hierarchy irq_data ready, an
irq_domain structure is built for each interrupt controller, and an
irq_data structure is allocated for each irq_domain associated with an
IRQ. Now we could go one step further to support stacked(hierarchy)
irq_chip. That is, an irq_chip is associated with each irq_data along
the hierarchy. A child irq_chip may implement a required action by
itself or by cooperating with its parent irq_chip.
With stacked irq_chip, interrupt controller driver only needs to deal
with the hardware managed by itself and may ask for services from its
parent irq_chip when needed. So we could achieve a much cleaner
software architecture.
For an interrupt controller driver to support hierarchy irq_domain, it
needs to:
1) Implement irq_domain_ops.alloc and irq_domain_ops.free
2) Optionally implement irq_domain_ops.activate and
irq_domain_ops.deactivate.
3) Optionally implement an irq_chip to manage the interrupt controller
hardware.
4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,
they are unused with hierarchy irq_domain.
Hierarchy irq_domain may also be used to support other architectures,
such as ARM, ARM64 etc.

View File

@ -1,3 +1,4 @@
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \
pcmcia/ spi/ timers/ watchdog/src/ misc-devices/mei/
subdir-y := accounting arm auxdisplay blackfin connector \
filesystems filesystems ia64 laptops mic misc-devices \
networking pcmcia prctl ptp spi timers vDSO video4linux \
watchdog

View File

@ -36,7 +36,7 @@ o How can the updater tell when a grace period has completed
executed in user mode, or executed in the idle loop, we can
safely free up that item.
Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the
Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the
same effect, but require that the readers manipulate CPU-local
counters. These counters allow limited types of blocking within
RCU read-side critical sections. SRCU also uses CPU-local
@ -81,7 +81,7 @@ o I hear that RCU is patented? What is with that?
o I hear that RCU needs work in order to support realtime kernels?
This work is largely completed. Realtime-friendly RCU can be
enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration
enabled via the CONFIG_PREEMPT_RCU kernel configuration
parameter. However, work is in progress for enabling priority
boosting of preempted RCU read-side critical sections. This is
needed if you have CPU-bound realtime threads.

View File

@ -26,12 +26,6 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
Stall-warning messages may be enabled and disabled completely via
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
CONFIG_RCU_CPU_STALL_VERBOSE
This kernel configuration parameter causes the stall warning to
also dump the stacks of any tasks that are blocking the current
RCU-preempt grace period.
CONFIG_RCU_CPU_STALL_INFO
This kernel configuration parameter causes the stall warning to
@ -56,8 +50,20 @@ RCU_STALL_RAT_DELAY
two jiffies. (This is a cpp macro, not a kernel configuration
parameter.)
When a CPU detects that it is stalling, it will print a message similar
to the following:
rcupdate.rcu_task_stall_timeout
This boot/sysfs parameter controls the RCU-tasks stall warning
interval. A value of zero or less suppresses RCU-tasks stall
warnings. A positive value sets the stall-warning interval
in jiffies. An RCU-tasks stall warning starts wtih the line:
INFO: rcu_tasks detected stalls on tasks:
And continues with the output of sched_show_task() for each
task stalling the current RCU-tasks grace period.
For non-RCU-tasks flavors of RCU, when a CPU detects that it is stalling,
it will print a message similar to the following:
INFO: rcu_sched_state detected stall on CPU 5 (t=2500 jiffies)
@ -65,7 +71,7 @@ This message indicates that CPU 5 detected that it was causing a stall,
and that the stall was affecting RCU-sched. This message will normally be
followed by a stack dump of the offending CPU. On TREE_RCU kernel builds,
RCU and RCU-sched are implemented by the same underlying mechanism,
while on TREE_PREEMPT_RCU kernel builds, RCU is instead implemented
while on PREEMPT_RCU kernel builds, RCU is instead implemented
by rcu_preempt_state.
On the other hand, if the offending CPU fails to print out a stall-warning
@ -77,7 +83,7 @@ INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 j
This message indicates that CPU 2 detected that CPUs 3 and 5 were both
causing stalls, and that the stall was affecting RCU-bh. This message
will normally be followed by stack dumps for each CPU. Please note that
TREE_PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,
PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,
and that the tasks will be indicated by PID, for example, "P3421".
It is even possible for a rcu_preempt_state stall to be caused by both
CPUs -and- tasks, in which case the offending CPUs and tasks will all
@ -174,8 +180,12 @@ o A CPU looping with preemption disabled. This condition can
o A CPU looping with bottom halves disabled. This condition can
result in RCU-sched and RCU-bh stalls.
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel
without invoking schedule().
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the
kernel without invoking schedule(). Note that cond_resched()
does not necessarily prevent RCU CPU stall warnings. Therefore,
if the looping in the kernel is really expected and desirable
behavior, you might need to replace some of the cond_resched()
calls with calls to cond_resched_rcu_qs().
o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
happen to preempt a low-priority task in the middle of an RCU
@ -189,10 +199,10 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
is running at a higher priority than the RCU softirq threads.
This will prevent RCU callbacks from ever being invoked,
and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent
and in a CONFIG_PREEMPT_RCU kernel will further prevent
RCU grace periods from ever completing. Either way, the
system will eventually run out of memory and hang. In the
CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning
CONFIG_PREEMPT_RCU case, you might see stall-warning
messages.
o A hardware or software issue shuts off the scheduler-clock
@ -208,11 +218,10 @@ o A hardware failure. This is quite unlikely, but has occurred
This resulted in a series of RCU CPU stall warnings, eventually
leading the realization that the CPU had failed.
The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.
SRCU does not have its own CPU stall warnings, but its calls to
synchronize_sched() will result in RCU-sched detecting RCU-sched-related
CPU stalls. Please note that RCU only detects CPU stalls when there is
a grace period in progress. No grace period, no CPU stall warnings.
The RCU, RCU-sched, RCU-bh, and RCU-tasks implementations have CPU stall
warning. Note that SRCU does -not- have CPU stall warnings. Please note
that RCU only detects CPU stalls when there is a grace period in progress.
No grace period, no CPU stall warnings.
To diagnose the cause of the stall, inspect the stack traces.
The offending function will usually be near the top of the stack.

View File

@ -8,7 +8,7 @@ The following sections describe the debugfs files and formats, first
for rcutree and next for rcutiny.
CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
CONFIG_TREE_RCU and CONFIG_PREEMPT_RCU debugfs Files and Formats
These implementations of RCU provide several debugfs directories under the
top-level directory "rcu":
@ -18,7 +18,7 @@ rcu/rcu_preempt
rcu/rcu_sched
Each directory contains files for the corresponding flavor of RCU.
Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.
Note that rcu/rcu_preempt is only present for CONFIG_PREEMPT_RCU.
For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,
so that activity for both appears in rcu/rcu_sched.

View File

@ -137,7 +137,7 @@ rcu_read_lock()
Used by a reader to inform the reclaimer that the reader is
entering an RCU read-side critical section. It is illegal
to block while in an RCU read-side critical section, though
kernels built with CONFIG_TREE_PREEMPT_RCU can preempt RCU
kernels built with CONFIG_PREEMPT_RCU can preempt RCU
read-side critical sections. Any RCU-protected data structure
accessed during an RCU read-side critical section is guaranteed to
remain unreclaimed for the full duration of that critical section.

View File

@ -483,12 +483,10 @@ have been included in the discussion
14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
If this patch fixes a problem reported by somebody else, consider adding a
Reported-by: tag to credit the reporter for their contribution. Please
note that this tag should not be added without the reporter's permission,
especially if the problem was not reported in a public forum. That said,
if we diligently credit our bug reporters, they will, hopefully, be
inspired to help us again in the future.
The Reported-by tag gives credit to people who find bugs and report them and it
hopefully inspires them to help us again in the future. Please note that if
the bug was reported in private, then ask for permission first before using the
Reported-by tag.
A Tested-by: tag indicates that the patch has been successfully tested (in
some environment) by the person named. This tag informs maintainers that

View File

@ -1,6 +1,3 @@
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := getdelays

View File

@ -312,3 +312,30 @@ a code like this:
There are also devm_* versions of these functions which release the
descriptors once the device is released.
MFD devices
~~~~~~~~~~~
The MFD devices register their children as platform devices. For the child
devices there needs to be an ACPI handle that they can use to reference
parts of the ACPI namespace that relate to them. In the Linux MFD subsystem
we provide two ways:
o The children share the parent ACPI handle.
o The MFD cell can specify the ACPI id of the device.
For the first case, the MFD drivers do not need to do anything. The
resulting child platform device will have its ACPI_COMPANION() set to point
to the parent device.
If the ACPI namespace has a device that we can match using an ACPI id,
the id should be set like:
static struct mfd_cell my_subdevice_cell = {
.name = "my_subdevice",
/* set the resources relative to the parent */
.acpi_pnpid = "XYZ0001",
};
The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
the MFD device and if found, that ACPI companion device is bound to the
resulting child platform device.

View File

@ -0,0 +1,96 @@
_DSD Device Properties Related to GPIO
--------------------------------------
With the release of ACPI 5.1 and the _DSD configuration objecte names
can finally be given to GPIOs (and other things as well) returned by
_CRS. Previously, we were only able to use an integer index to find
the corresponding GPIO, which is pretty error prone (it depends on
the _CRS output ordering, for example).
With _DSD we can now query GPIOs using a name instead of an integer
index, like the ASL example below shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have a field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
it to 1 marks the GPIO as active low.
In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.
ACPI GPIO Mappings Provided by Drivers
--------------------------------------
There are systems in which the ACPI tables do not contain _DSD but provide _CRS
with GpioIo()/GpioInt() resources and device drivers still need to work with
them.
In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB, _HRV,
available to the driver can be used to identify the device and that is supposed
to be sufficient to determine the meaning and purpose of all of the GPIO lines
listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words,
the driver is supposed to know what to use the GpioIo()/GpioInt() resources for
once it has identified the device. Having done that, it can simply assign names
to the GPIO lines it is going to use and provide the GPIO subsystem with a
mapping between those names and the ACPI GPIO resources corresponding to them.
To do that, the driver needs to define a mapping table as a NULL-terminated
array of struct acpi_gpio_mapping objects that each contain a name, a pointer
to an array of line data (struct acpi_gpio_params) objects and the size of that
array. Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, line_index, active_low, representing the index of the target
GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target
line in that resource starting from zero, and the active-low flag for that line,
respectively, in analogy with the _DSD GPIO property format specified above.
For the example Bluetooth device discussed previously the data structures in
question would look like this:
static const struct acpi_gpio_params reset_gpio = { 1, 1, false };
static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false };
static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
{ "reset-gpio", &reset_gpio, 1 },
{ "shutdown-gpio", &shutdown_gpio, 1 },
{ },
};
Next, the mapping table needs to be passed as the second argument to
acpi_dev_add_driver_gpios() that will register it with the ACPI device object
pointed to by its first argument. That should be done in the driver's .probe()
routine. On removal, the driver should unregister its GPIO mapping table by
calling acpi_dev_remove_driver_gpios() on the ACPI device object where that
table was previously registered.

View File

@ -94,7 +94,7 @@ Common errors when patching
---
When patch applies a patch file it attempts to verify the sanity of the
file in different ways.
Checking that the file looks like a valid patch file & checking the code
Checking that the file looks like a valid patch file and checking the code
around the bits being modified matches the context provided in the patch are
just two of the basic sanity checks patch does.

View File

@ -0,0 +1 @@
subdir-y := SH-Mobile

View File

@ -103,6 +103,10 @@ EBU Armada family
NOTE: not to be confused with the non-SMP 78xx0 SoCs
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
Functional Spec: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
Hardware Specs:
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core: Sheeva ARMv7 compatible

View File

@ -0,0 +1 @@
vrl4

View File

@ -1,8 +1,7 @@
BIN := vrl4
# List of programs to build
hostprogs-y := vrl4
.PHONY: all
all: $(BIN)
# Tell kbuild to always build the programs
always := $(hostprogs-y)
.PHONY: clean
clean:
rm -f *.o $(BIN)
HOSTCFLAGS_vrl4.o += -I$(objtree)/usr/include -I$(srctree)/tools/include

View File

@ -34,6 +34,7 @@
#include <stdint.h>
#include <stdio.h>
#include <errno.h>
#include <tools/endian.h>
struct hdr {
uint32_t magic1;
@ -77,7 +78,7 @@ struct hdr {
#define ROUND_UP(x) ((x + ALIGN - 1) & ~(ALIGN - 1))
ssize_t do_read(int fd, void *buf, size_t count)
static ssize_t do_read(int fd, void *buf, size_t count)
{
size_t offset = 0;
ssize_t l;
@ -98,7 +99,7 @@ ssize_t do_read(int fd, void *buf, size_t count)
return offset;
}
ssize_t do_write(int fd, const void *buf, size_t count)
static ssize_t do_write(int fd, const void *buf, size_t count)
{
size_t offset = 0;
ssize_t l;
@ -117,7 +118,7 @@ ssize_t do_write(int fd, const void *buf, size_t count)
return offset;
}
ssize_t write_zero(int fd, size_t len)
static ssize_t write_zero(int fd, size_t len)
{
size_t i = len;

View File

@ -7,32 +7,14 @@ world, which changes the way some things have to be initialized. This makes
a need to provide an interface for such platforms to specify available firmware
operations and call them when needed.
Firmware operations can be specified using struct firmware_ops
struct firmware_ops {
/*
* Enters CPU idle mode
*/
int (*do_idle)(void);
/*
* Sets boot address of specified physical CPU
*/
int (*set_cpu_boot_addr)(int cpu, unsigned long boot_addr);
/*
* Boots specified physical CPU
*/
int (*cpu_boot)(int cpu);
/*
* Initializes L2 cache
*/
int (*l2x0_init)(void);
};
and then registered with register_firmware_ops function
Firmware operations can be specified by filling in a struct firmware_ops
with appropriate callbacks and then registering it with register_firmware_ops()
function.
void register_firmware_ops(const struct firmware_ops *ops)
the ops pointer must be non-NULL.
The ops pointer must be non-NULL. More information about struct firmware_ops
and its members can be found in arch/arm/include/asm/firmware.h header.
There is a default, empty set of operations provided, so there is no need to
set anything if platform does not require firmware operations.

View File

@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with
fffe0000 fffe7fff ITCM mapping area for platforms with
ITCM mounted inside the CPU.
ffc00000 ffdfffff Fixmap mapping region. Addresses provided
ffc00000 ffefffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.
fee00000 feffffff Mapping of PCI I/O space. This is a static

View File

@ -37,16 +37,26 @@ SunXi family
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
- Allwinner A23
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A23/A23%20Datasheet%20V1.0%2020130830.pdf
+ User Manual
http://dl.linux-sunxi.org/A23/A23%20User%20Manual%20V1.0%2020130830.pdf
* Quad ARM Cortex-A7 based SoCs
- Allwinner A31 (sun6i)
+ Datasheet
http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20(2012-12-24).pdf
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20datasheet%20V1.3%2020131106.pdf
+ User Manual
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf
- Allwinner A31s (sun6i)
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
+ User Manual
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20User%20Manual%20%20V1.0%2020130322.pdf
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A80/A80_Datasheet_Revision_1.0_0404.pdf

View File

@ -0,0 +1,45 @@
The arm64 port of the Linux kernel provides infrastructure to support
emulation of instructions which have been deprecated, or obsoleted in
the architecture. The infrastructure code uses undefined instruction
hooks to support emulation. Where available it also allows turning on
the instruction execution in hardware.
The emulation mode can be controlled by writing to sysctl nodes
(/proc/sys/abi). The following explains the different execution
behaviours and the corresponding values of the sysctl nodes -
* Undef
Value: 0
Generates undefined instruction abort. Default for instructions that
have been obsoleted in the architecture, e.g., SWP
* Emulate
Value: 1
Uses software emulation. To aid migration of software, in this mode
usage of emulated instruction is traced as well as rate limited
warnings are issued. This is the default for deprecated
instructions, .e.g., CP15 barriers
* Hardware Execution
Value: 2
Although marked as deprecated, some implementations may support the
enabling/disabling of hardware support for the execution of these
instructions. Using hardware execution generally provides better
performance, but at the loss of ability to gather runtime statistics
about the use of the deprecated instructions.
The default mode depends on the status of the instruction in the
architecture. Deprecated instructions should default to emulation
while obsolete instructions must be undefined by default.
Supported legacy instructions
-----------------------------
* SWP{B}
Node: /proc/sys/abi/swp
Status: Obsolete
Default: Undef (0)
* CP15 Barriers
Node: /proc/sys/abi/cp15_barrier
Status: Deprecated
Default: Emulate (1)

View File

@ -17,7 +17,7 @@ User addresses have bits 63:48 set to 0 while the kernel addresses have
the same bits set to 1. TTBRx selection is given by bit 63 of the
virtual address. The swapper_pg_dir contains only kernel (global)
mappings while the user pgd contains only user (non-global) mappings.
The swapper_pgd_dir address is written to TTBR1 and never written to
The swapper_pg_dir address is written to TTBR1 and never written to
TTBR0.

View File

@ -7,12 +7,13 @@
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
The atomic_t type should be defined as a signed integer.
Also, it should be made opaque such that any kind of cast to a normal
C integer type will fail. Something like the following should
suffice:
The atomic_t type should be defined as a signed integer and
the atomic_long_t type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
will fail. Something like the following should suffice:
typedef struct { int counter; } atomic_t;
typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
See Documentation/volatile-considered-harmful.txt for the complete rationale.
@ -37,6 +38,9 @@ initializer is used before runtime. If the initializer is used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
value with atomic_read from another thread.
As with all of the atomic_ interfaces, replace the leading "atomic_"
with "atomic_long_" to operate on atomic_long_t.
The second interface can be used at runtime, as in:
struct foo { atomic_t counter; };

View File

@ -1,6 +1,3 @@
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
# List of programs to build
hostprogs-y := cfag12864b-example

View File

@ -15,39 +15,50 @@ First you must mount binfmt_misc:
mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc
To actually register a new binary type, you have to set up a string looking like
:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':' upon
your needs) and echo it to /proc/sys/fs/binfmt_misc/register.
:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':'
upon your needs) and echo it to /proc/sys/fs/binfmt_misc/register.
Here is what the fields mean:
- 'name' is an identifier string. A new /proc file will be created with this
name below /proc/sys/fs/binfmt_misc
name below /proc/sys/fs/binfmt_misc; cannot contain slashes '/' for obvious
reasons.
- 'type' is the type of recognition. Give 'M' for magic and 'E' for extension.
- 'offset' is the offset of the magic/mask in the file, counted in bytes. This
defaults to 0 if you omit it (i.e. you write ':name:type::magic...')
defaults to 0 if you omit it (i.e. you write ':name:type::magic...'). Ignored
when using filename extension matching.
- 'magic' is the byte sequence binfmt_misc is matching for. The magic string
may contain hex-encoded characters like \x0a or \xA4. In a shell environment
you will have to write \\x0a to prevent the shell from eating your \.
may contain hex-encoded characters like \x0a or \xA4. Note that you must
escape any NUL bytes; parsing halts at the first one. In a shell environment
you might have to write \\x0a to prevent the shell from eating your \.
If you chose filename extension matching, this is the extension to be
recognised (without the '.', the \x0a specials are not allowed). Extension
matching is case sensitive!
matching is case sensitive, and slashes '/' are not allowed!
- 'mask' is an (optional, defaults to all 0xff) mask. You can mask out some
bits from matching by supplying a string like magic and as long as magic.
The mask is anded with the byte sequence of the file.
The mask is anded with the byte sequence of the file. Note that you must
escape any NUL bytes; parsing halts at the first one. Ignored when using
filename extension matching.
- 'interpreter' is the program that should be invoked with the binary as first
argument (specify the full path)
- 'flags' is an optional field that controls several aspects of the invocation
of the interpreter. It is a string of capital letters, each controls a certain
aspect. The following flags are supported -
'P' - preserve-argv[0]. Legacy behavior of binfmt_misc is to overwrite the
original argv[0] with the full path to the binary. When this flag is
included, binfmt_misc will add an argument to the argument vector for
this purpose, thus preserving the original argv[0].
of the interpreter. It is a string of capital letters, each controls a
certain aspect. The following flags are supported -
'P' - preserve-argv[0]. Legacy behavior of binfmt_misc is to overwrite
the original argv[0] with the full path to the binary. When this
flag is included, binfmt_misc will add an argument to the argument
vector for this purpose, thus preserving the original argv[0].
e.g. If your interp is set to /bin/foo and you run `blah` (which is
in /usr/local/bin), then the kernel will execute /bin/foo with
argv[] set to ["/bin/foo", "/usr/local/bin/blah", "blah"]. The
interp has to be aware of this so it can execute /usr/local/bin/blah
with argv[] set to ["blah"].
'O' - open-binary. Legacy behavior of binfmt_misc is to pass the full path
of the binary to the interpreter as an argument. When this flag is
included, binfmt_misc will open the file for reading and pass its
descriptor as an argument, instead of the full path, thus allowing
the interpreter to execute non-readable binaries. This feature should
be used with care - the interpreter has to be trusted not to emit
the contents of the non-readable binary.
the interpreter to execute non-readable binaries. This feature
should be used with care - the interpreter has to be trusted not to
emit the contents of the non-readable binary.
'C' - credentials. Currently, the behavior of binfmt_misc is to calculate
the credentials and security token of the new process according to
the interpreter. When this flag is included, these attributes are
@ -58,7 +69,7 @@ Here is what the fields mean:
There are some restrictions:
- the whole register string may not exceed 255 characters
- the whole register string may not exceed 1920 characters
- the magic must reside in the first 128 bytes of the file, i.e.
offset+size(magic) has to be less than 128
- the interpreter string may not exceed 127 characters
@ -110,7 +121,4 @@ passes it the full filename (or the file descriptor) to use. Using $PATH can
cause unexpected behaviour and can be a security hazard.
There is a web page about binfmt_misc at
http://www.tat.physik.uni-tuebingen.de
Richard Günther <rguenth@tat.physik.uni-tuebingen.de>

View File

@ -1,6 +1,3 @@
ifneq ($(CONFIG_BLACKFIN),)
obj-m := gptimers-example.o
all: modules
modules clean:
$(MAKE) -C ../.. SUBDIRS=$(PWD) $@
endif

View File

@ -827,10 +827,6 @@ but in the event of any barrier requests in the tag queue we need to ensure
that requests are restarted in the order they were queue. This may happen
if the driver needs to use blk_queue_invalidate_tags().
Tagging also defines a new request flag, REQ_QUEUED. This is set whenever
a request is currently tagged. You should not use this flag directly,
blk_rq_tagged(rq) is the portable way to do so.
3.3 I/O Submission
The routine submit_bio() is used to submit a single io. Higher level i/o
@ -946,7 +942,11 @@ elevator_allow_merge_fn called whenever the block layer determines
request safely. The io scheduler may still
want to stop a merge at this point if it
results in some sort of conflict internally,
this hook allows it to do that.
this hook allows it to do that. Note however
that two *requests* can still be merged at later
time. Currently the io scheduler has no way to
prevent that. It can only learn about the fact
from elevator_merge_req_fn callback.
elevator_dispatch_fn* fills the dispatch queue with ready requests.
I/O schedulers are free to postpone requests by

View File

@ -129,11 +129,11 @@ interface for this is being worked on.
4.1 BIO
The data integrity patches add a new field to struct bio when
CONFIG_BLK_DEV_INTEGRITY is enabled. bio->bi_integrity is a pointer
to a struct bip which contains the bio integrity payload. Essentially
a bip is a trimmed down struct bio which holds a bio_vec containing
the integrity metadata and the required housekeeping information (bvec
pool, vector count, etc.)
CONFIG_BLK_DEV_INTEGRITY is enabled. bio_integrity(bio) returns a
pointer to a struct bip which contains the bio integrity payload.
Essentially a bip is a trimmed down struct bio which holds a bio_vec
containing the integrity metadata and the required housekeeping
information (bvec pool, vector count, etc.)
A kernel subsystem can enable data integrity protection on a bio by
calling bio_integrity_alloc(bio). This will allocate and attach the
@ -192,16 +192,6 @@ will require extra work due to the application tag.
supported by the block device.
int bdev_integrity_enabled(block_device, int rw);
bdev_integrity_enabled() will return 1 if the block device
supports integrity metadata transfer for the data direction
specified in 'rw'.
bdev_integrity_enabled() honors the write_generate and
read_verify flags in sysfs and will respond accordingly.
int bio_integrity_prep(bio);
To generate IMD for WRITE and to set up buffers for READ, the
@ -216,36 +206,6 @@ will require extra work due to the application tag.
bio_integrity_enabled() returned 1.
int bio_integrity_tag_size(bio);
If the filesystem wants to use the application tag space it will
first have to find out how much storage space is available.
Because tag space is generally limited (usually 2 bytes per
sector regardless of sector size), the integrity framework
supports interleaving the information between the sectors in an
I/O.
Filesystems can call bio_integrity_tag_size(bio) to find out how
many bytes of storage are available for that particular bio.
Another option is bdev_get_tag_size(block_device) which will
return the number of available bytes per hardware sector.
int bio_integrity_set_tag(bio, void *tag_buf, len);
After a successful return from bio_integrity_prep(),
bio_integrity_set_tag() can be used to attach an opaque tag
buffer to a bio. Obviously this only makes sense if the I/O is
a WRITE.
int bio_integrity_get_tag(bio, void *tag_buf, len);
Similarly, at READ I/O completion time the filesystem can
retrieve the tag buffer using bio_integrity_get_tag().
5.3 PASSING EXISTING INTEGRITY METADATA
Filesystems that either generate their own integrity metadata or
@ -298,8 +258,6 @@ will require extra work due to the application tag.
.name = "STANDARDSBODY-TYPE-VARIANT-CSUM",
.generate_fn = my_generate_fn,
.verify_fn = my_verify_fn,
.get_tag_fn = my_get_tag_fn,
.set_tag_fn = my_set_tag_fn,
.tuple_size = sizeof(struct my_tuple_size),
.tag_size = <tag bytes per hw sector>,
};
@ -321,7 +279,5 @@ will require extra work due to the application tag.
are available per hardware sector. For DIF this is either 2 or
0 depending on the value of the Control Mode Page ATO bit.
See 6.2 for a description of get_tag_fn and set_tag_fn.
----------------------------------------------------------------------
2007-12-24 Martin K. Petersen <martin.petersen@oracle.com>

View File

@ -42,7 +42,7 @@ nr_devices=[Number of devices]: Default: 2
Number of block devices instantiated. They are instantiated as /dev/nullb0,
etc.
irq_mode=[0-2]: Default: 1-Soft-irq
irqmode=[0-2]: Default: 1-Soft-irq
The completion mode used for completing IOs to the block-layer.
0: None.
@ -53,7 +53,7 @@ irq_mode=[0-2]: Default: 1-Soft-irq
completion.
completion_nsec=[ns]: Default: 10.000ns
Combined with irq_mode=2 (timer). The time each completion event must wait.
Combined with irqmode=2 (timer). The time each completion event must wait.
submit_queues=[0..nr_cpus]:
The number of submission queues attached to the device driver. If unset, it

View File

@ -11,7 +11,7 @@ read-write.
add_random (RW)
----------------
This file allows to trun off the disk entropy contribution. Default
This file allows to turn off the disk entropy contribution. Default
value of this file is '1'(on).
discard_granularity (RO)
@ -72,7 +72,7 @@ Maximum segment size of the device.
minimum_io_size (RO)
--------------------
This is the smallest preferred io size reported by the device.
This is the smallest preferred IO size reported by the device.
nomerges (RW)
-------------
@ -98,7 +98,7 @@ regulated by nr_requests.
optimal_io_size (RO)
--------------------
This is the optimal io size reported by the device.
This is the optimal IO size reported by the device.
physical_block_size (RO)
------------------------

View File

@ -74,14 +74,30 @@ There is little point creating a zram of greater than twice the size of memory
since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the
size of the disk when not in use so a huge zram is wasteful.
5) Activate:
5) Set memory limit: Optional
Set memory limit by writing the value to sysfs node 'mem_limit'.
The value can be either in bytes or you can use mem suffixes.
In addition, you could change the value in runtime.
Examples:
# limit /dev/zram0 with 50MB memory
echo $((50*1024*1024)) > /sys/block/zram0/mem_limit
# Using mem suffixes
echo 256K > /sys/block/zram0/mem_limit
echo 512M > /sys/block/zram0/mem_limit
echo 1G > /sys/block/zram0/mem_limit
# To disable memory limit
echo 0 > /sys/block/zram0/mem_limit
6) Activate:
mkswap /dev/zram0
swapon /dev/zram0
mkfs.ext4 /dev/zram1
mount /dev/zram1 /tmp
6) Stats:
7) Stats:
Per-device statistics are exported as various nodes under
/sys/block/zram<id>/
disksize
@ -95,12 +111,13 @@ size of the disk when not in use so a huge zram is wasteful.
orig_data_size
compr_data_size
mem_used_total
mem_used_max
7) Deactivate:
8) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
8) Reset:
9) Reset:
Write any positive value to 'reset' sysfs node
echo 1 > /sys/block/zram0/reset
echo 1 > /sys/block/zram1/reset

View File

@ -312,10 +312,10 @@ the "cpuset" cgroup subsystem, the steps are something like:
2) mkdir /sys/fs/cgroup/cpuset
3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
4) Create the new cgroup by doing mkdir's and write's (or echo's) in
the /sys/fs/cgroup virtual file system.
the /sys/fs/cgroup/cpuset virtual file system.
5) Start a task that will be the "founding father" of the new job.
6) Attach that task to the new cgroup by writing its PID to the
/sys/fs/cgroup/cpuset/tasks file for that cgroup.
/sys/fs/cgroup/cpuset tasks file for that cgroup.
7) fork, exec or clone the job tasks from this founding father task.
For example, the following sequence of commands will setup a cgroup

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