iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'sched/urgent' into sched/core, to avoid conflicts

Browse Source 
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2014-05-07 13:15:46 +02:00
commit 2fe5de9ce7
7124 changed files with 439469 additions and 145271 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.mailmap
View File

@ -99,6 +99,7 @@ Sachin P Sant <ssant@in.ibm.com>
Sam Ravnborg <sam@mars.ravnborg.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>
Simon Kelley <simon@thekelleys.org.uk>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <shemminger@osdl.org>

18
CREDITS
View File

@ -630,6 +630,13 @@ N: Michael Elizabeth Chastain
E: mec@shout.net
D: Configure, Menuconfig, xconfig
N: Mauro Carvalho Chehab
E: m.chehab@samsung.org
E: mchehab@infradead.org
D: Media subsystem (V4L/DVB) drivers and core
D: EDAC drivers and EDAC 3.0 core rework
S: Brazil
N: Raymond Chen
E: raymondc@microsoft.com
D: Author of Configure script
@ -1229,7 +1236,7 @@ E: philip@gladstonefamily.net
D: Kernel / timekeeping stuff
S: Carlisle, MA 01741
S: USA
N: Jan-Benedict Glaw
E: jbglaw@lug-owl.de
D: SRM environment driver (for Alpha systems)
@ -2560,10 +2567,14 @@ S: 22 Seaview St
S: Fullarton 5063
S: South Australia
N. Wolfgang Muees
N: Wolfgang Muees
E: wolfgang@iksw-muees.de
D: Auerswald USB driver
N: Paul Mundt
E: paul.mundt@gmail.com
D: SuperH maintainer
N: Ian A. Murdock
E: imurdock@gnu.ai.mit.edu
D: Creator of Debian distribution
@ -2707,6 +2718,9 @@ N: Greg Page
E: gpage@sovereign.org
D: IPX development and support
N: Venkatesh Pallipadi (Venki)
D: x86/HPET
N: David Parsons
E: orc@pell.chi.il.us
D: improved memory detection code.

41
Documentation/ABI/stable/sysfs-firmware-opal-dump Normal file
View File

@ -0,0 +1,41 @@
What: /sys/firmware/opal/dump
Date: Feb 2014
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
Description:
This directory exposes interfaces for interacting with
the FSP and platform dumps through OPAL firmware interface.
This is only for the powerpc/powernv platform.
initiate_dump: When '1' is written to it,
we will initiate a dump.
Read this file for supported commands.
0xXX-0xYYYY: A directory for dump of type 0xXX and
id 0xYYYY (in hex). The name of this
directory should not be relied upon to
be in this format, only that it's unique
among all dumps. For determining the type
and ID of the dump, use the id and type files.
Do not rely on any particular size of dump
type or dump id.
Each dump has the following files:
id: An ASCII representation of the dump ID
in hex (e.g. '0x01')
type: An ASCII representation of the type of
dump in the format "0x%x %s" with the ID
in hex and a description of the dump type
(or 'unknown').
Type '0xffffffff unknown' is used when
we could not get the type from firmware.
e.g. '0x02 System/Platform Dump'
dump: A binary file containing the dump.
The size of the dump is the size of this file.
acknowledge: When 'ack' is written to this, we will
acknowledge that we've retrieved the
dump to the service processor. It will
then remove it, making the dump
inaccessible.
Reading this file will get a list of
supported actions.

60
Documentation/ABI/stable/sysfs-firmware-opal-elog Normal file
View File

@ -0,0 +1,60 @@
What: /sys/firmware/opal/elog
Date: Feb 2014
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
Description:
This directory exposes error log entries retrieved
through the OPAL firmware interface.
Each error log is identified by a unique ID and will
exist until explicitly acknowledged to firmware.
Each log entry has a directory in /sys/firmware/opal/elog.
Log entries may be purged by the service processor
before retrieved by firmware or retrieved/acknowledged by
Linux if there is no room for more log entries.
In the event that Linux has retrieved the log entries
but not explicitly acknowledged them to firmware and
the service processor needs more room for log entries,
the only remaining copy of a log message may be in
Linux.
Typically, a user space daemon will monitor for new
entries, read them out and acknowledge them.
The service processor may be able to store more log
entries than firmware can, so after you acknowledge
an event from Linux you may instantly get another one
from the queue that was generated some time in the past.
The raw log format is a binary format. We currently
do not parse this at all in kernel, leaving it up to
user space to solve the problem. In future, we may
do more parsing in kernel and add more files to make
it easier for simple user space processes to extract
more information.
For each log entry (directory), there are the following
files:
id: An ASCII representation of the ID of the
error log, in hex - e.g. "0x01".
type: An ASCII representation of the type id and
description of the type of error log.
Currently just "0x00 PEL" - platform error log.
In the future there may be additional types.
raw: A read-only binary file that can be read
to get the raw log entry. These are
<16kb, often just hundreds of bytes and
"average" 2kb.
acknowledge: Writing 'ack' to this file will acknowledge
the error log to firmware (and in turn
the service processor, if applicable).
Shortly after acknowledging it, the log
entry will be removed from sysfs.
Reading this file will list the supported
operations (curently just acknowledge).

39
Documentation/ABI/testing/sysfs-block-zram
View File

@ -43,6 +43,36 @@ Description:
The invalid_io file is read-only and specifies the number of
non-page-size-aligned I/O requests issued to this device.
What: /sys/block/zram<id>/failed_reads
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_reads file is read-only and specifies the number of
failed reads happened on this device.
What: /sys/block/zram<id>/failed_writes
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_writes file is read-only and specifies the number of
failed writes happened on this device.
What: /sys/block/zram<id>/max_comp_streams
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The max_comp_streams file is read-write and specifies the
number of backend's zcomp_strm compression streams (number of
concurrent compress operations).
What: /sys/block/zram<id>/comp_algorithm
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The comp_algorithm file is read-write and lets to show
available and selected compression algorithms, change
compression algorithm selection.
What: /sys/block/zram<id>/notify_free
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
@ -53,15 +83,6 @@ Description:
is freed. This statistic is applicable only when this disk is
being used as a swap disk.
What: /sys/block/zram<id>/discard
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The discard file is read-only and specifies the number of
discard requests received by this device. These requests
provide information to block device regarding blocks which are
no longer used by filesystem.
What: /sys/block/zram<id>/zero_pages
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>

517
Documentation/ABI/testing/sysfs-bus-event_source-devices-events
View File

@ -57,6 +57,523 @@ What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
/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

23
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 Normal file
View File

@ -0,0 +1,23 @@
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
Provides access to the binary "24x7 catalog" provided by the
hypervisor on POWER7 and 8 systems. This catalog lists events
avaliable from the powerpc "hv_24x7" pmu. Its format is
documented here:
https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_length
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
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>
Description:
Exposes the "version" field of the 24x7 catalog. This is also
extractable from the provided binary "catalog" sysfs entry.

43
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci Normal file
View File

@ -0,0 +1,43 @@
What: /sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
Description:
'0' if the hypervisor is configured to forbid access to event
counters being accumulated by other guests and to physical
domain event counters.
'1' if that access is allowed.
What: /sys/bus/event_source/devices/hv_gpci/interface/ga
Date: February 2014
Contact: Cody P Schafer <cody@linux.vnet.ibm.com>
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>
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>
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>
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>
Description:
A number indicating the latest version of the gpci interface
that the kernel is aware of.

20
Documentation/ABI/testing/sysfs-bus-mdio
View File

@ -7,3 +7,23 @@ Description:
by the device during bus enumeration, encoded in hexadecimal.
This ID is used to match the device with the appropriate
driver.
What: /sys/bus/mdio_bus/devices/.../phy_interface
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
This attribute contains the PHY interface as configured by the
Ethernet driver during bus enumeration, encoded in string.
This interface mode is used to configure the Ethernet MAC with the
appropriate mode for its data lines to the PHY hardware.
What: /sys/bus/mdio_bus/devices/.../phy_has_fixups
Date: February 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
This attribute contains the boolean value whether a given PHY
device has had any "fixup" workaround running on it, encoded as
a boolean. This information is provided to help troubleshooting
PHY configurations.

199
Documentation/ABI/testing/sysfs-class-net Normal file
View File

@ -0,0 +1,199 @@
What: /sys/class/net/<iface>/addr_assign_type
Date: July 2010
KernelVersion: 3.2
Contact: netdev@vger.kernel.org
Description:
Indicates the address assignment type. Possible values are:
0: permanent address
1: randomly generated
2: stolen from another device
3: set using dev_set_mac_address
What: /sys/class/net/<iface>/addr_len
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the hardware address size in bytes.
Values vary based on the lower-level protocol used by the
interface (Ethernet, FDDI, ATM, IEEE 802.15.4...). See
include/uapi/linux/if_*.h for actual values.
What: /sys/class/net/<iface>/address
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Hardware address currently assigned to this interface.
Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC
address.
What: /sys/class/net/<iface>/broadcast
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Hardware broadcast address for this interface. Format is a
string, e.g: ff:ff:ff:ff:ff:ff for an Ethernet broadcast MAC
address.
What: /sys/class/net/<iface>/carrier
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the current physical link state of the interface.
Posssible values are:
0: physical link is down
1: physical link is up
Note: some special devices, e.g: bonding and team drivers will
allow this attribute to be written to force a link state for
operating correctly and designating another fallback interface.
What: /sys/class/net/<iface>/dev_id
Date: April 2008
KernelVersion: 2.6.26
Contact: netdev@vger.kernel.org
Description:
Indicates the device unique identifier. Format is an hexadecimal
value. This is used to disambiguate interfaces which might be
stacked (e.g: VLAN interfaces) but still have the same MAC
address as their parent device.
What: /sys/class/net/<iface>/dormant
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates whether the interface is in dormant state. Possible
values are:
0: interface is not dormant
1: interface is dormant
This attribute can be used by supplicant software to signal that
the device is not usable unless some supplicant-based
authentication is performed (e.g: 802.1x). 'link_mode' attribute
will also reflect the dormant state.
What: /sys/clas/net/<iface>/duplex
Date: October 2009
KernelVersion: 2.6.33
Contact: netdev@vger.kernel.org
Description:
Indicates the interface latest or current duplex value. Possible
values are:
half: half duplex
full: full duplex
Note: This attribute is only valid for interfaces that implement
the ethtool get_settings method (mostly Ethernet).
What: /sys/class/net/<iface>/flags
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface flags as a bitmask in hexadecimal. See
include/uapi/linux/if.h for a list of all possible values and
the flags semantics.
What: /sys/class/net/<iface>/ifalias
Date: September 2008
KernelVersion: 2.6.28
Contact: netdev@vger.kernel.org
Description:
Indicates/stores an interface alias name as a string. This can
be used for system management purposes.
What: /sys/class/net/<iface>/ifindex
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the system-wide interface unique index identifier as a
decimal number. This attribute is used for mapping an interface
identifier to an interface name. It is used throughout the
networking stack for specifying the interface specific
requests/events.
What: /sys/class/net/<iface>/iflink
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the system-wide interface unique index identifier a
the interface is linked to. Format is decimal. This attribute is
used to resolve interfaces chaining, linking and stacking.
Physical interfaces have the same 'ifindex' and 'iflink' values.
What: /sys/class/net/<iface>/link_mode
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates the interface link mode, as a decimal number. This
attribute should be used in conjunction with 'dormant' attribute
to determine the interface usability. Possible values:
0: default link mode
1: dormant link mode
What: /sys/class/net/<iface>/mtu
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface currently configured MTU value, in
bytes, and in decimal format. Specific values depends on the
lower-level interface protocol used. Ethernet devices will show
a 'mtu' attribute value of 1500 unless changed.
What: /sys/calss/net/<iface>/netdev_group
Date: January 2011
KernelVersion: 2.6.39
Contact: netdev@vger.kernel.org
Description:
Indicates the interface network device group, as a decimal
integer. Default value is 0 which corresponds to the initial
network devices group. The group can be changed to affect
routing decisions (see: net/ipv4/fib_rules and
net/ipv6/fib6_rules.c).
What: /sys/class/net/<iface>/operstate
Date: March 2006
KernelVersion: 2.6.17
Contact: netdev@vger.kernel.org
Description:
Indicates the interface RFC2863 operational state as a string.
Possible values are:
"unknown", "notpresent", "down", "lowerlayerdown", "testing",
"dormant", "up".
What: /sys/class/net/<iface>/speed
Date: October 2009
KernelVersion: 2.6.33
Contact: netdev@vger.kernel.org
Description:
Indicates the interface latest or current speed value. Value is
an integer representing the link speed in Mbits/sec.
Note: this attribute is only valid for interfaces that implement
the ethtool get_settings method (mostly Ethernet ).
What: /sys/class/net/<iface>/tx_queue_len
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface transmit queue len in number of packets,
as an integer value. Value depend on the type of interface,
Ethernet network adapters have a default value of 1000 unless
configured otherwise
What: /sys/class/net/<iface>/type
Date: April 2005
KernelVersion: 2.6.12
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.

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

@ -76,6 +76,15 @@ Description:
is used to classify clients as "isolated" by the
Extended Isolation feature.
What: /sys/class/net/<mesh_iface>/mesh/multicast_mode
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Indicates whether multicast optimizations are enabled
or disabled. If set to zero then all nodes in the
mesh are going to use classic flooding for any
multicast packet with no optimizations.
What: /sys/class/net/<mesh_iface>/mesh/network_coding
Date: Nov 2012
Contact: Martin Hundeboll <martin@hundeboll.net>

111
Documentation/ABI/testing/sysfs-class-rc Normal file
View File

@ -0,0 +1,111 @@
What: /sys/class/rc/
Date: Apr 2010
KernelVersion: 2.6.35
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
The rc/ class sub-directory belongs to the Remote Controller
core and provides a sysfs interface for configuring infrared
remote controller receivers.
What: /sys/class/rc/rcN/
Date: Apr 2010
KernelVersion: 2.6.35
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
A /sys/class/rc/rcN directory is created for each remote
control receiver device where N is the number of the receiver.
What: /sys/class/rc/rcN/protocols
Date: Jun 2010
KernelVersion: 2.6.36
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns a list of available protocols,
something like:
"rc5 [rc6] nec jvc [sony]"
Enabled protocols are shown in [] brackets.
Writing "+proto" will add a protocol to the list of enabled
protocols.
Writing "-proto" will remove a protocol from the list of enabled
protocols.
Writing "proto" will enable only "proto".
Writing "none" will disable all protocols.
Write fails with EINVAL if an invalid protocol combination or
unknown protocol name is used.
What: /sys/class/rc/rcN/filter
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Sets the scancode filter expected value.
Use in combination with /sys/class/rc/rcN/filter_mask to set the
expected value of the bits set in the filter mask.
If the hardware supports it then scancodes which do not match
the filter will be ignored. Otherwise the write will fail with
an error.
This value may be reset to 0 if the current protocol is altered.
What: /sys/class/rc/rcN/filter_mask
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Sets the scancode filter mask of bits to compare.
Use in combination with /sys/class/rc/rcN/filter to set the bits
of the scancode which should be compared against the expected
value. A value of 0 disables the filter to allow all valid
scancodes to be processed.
If the hardware supports it then scancodes which do not match
the filter will be ignored. Otherwise the write will fail with
an error.
This value may be reset to 0 if the current protocol is altered.
What: /sys/class/rc/rcN/wakeup_protocols
Date: Feb 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns a list of available protocols to use
for the wakeup filter, something like:
"rc5 rc6 nec jvc [sony]"
The enabled wakeup protocol is shown in [] brackets.
Writing "+proto" will add a protocol to the list of enabled
wakeup protocols.
Writing "-proto" will remove a protocol from the list of enabled
wakeup protocols.
Writing "proto" will use "proto" for wakeup events.
Writing "none" will disable wakeup.
Write fails with EINVAL if an invalid protocol combination or
unknown protocol name is used, or if wakeup is not supported by
the hardware.
What: /sys/class/rc/rcN/wakeup_filter
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Sets the scancode wakeup filter expected value.
Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to
set the expected value of the bits set in the wakeup filter mask
to trigger a system wake event.
If the hardware supports it and wakeup_filter_mask is not 0 then
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.
This value may be reset to 0 if the wakeup protocol is altered.
What: /sys/class/rc/rcN/wakeup_filter_mask
Date: Jan 2014
KernelVersion: 3.15
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Sets the scancode wakeup filter mask of bits to compare.
Use in combination with /sys/class/rc/rcN/wakeup_filter to set
the bits of the scancode which should be compared against the
expected value to trigger a system wake event.
If the hardware supports it and wakeup_filter_mask is not 0 then
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.
This value may be reset to 0 if the wakeup protocol is altered.

46
Documentation/ABI/testing/sysfs-devices-power
View File

@ -83,8 +83,10 @@ Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_count attribute contains the number
of signaled wakeup events associated with the device. This
attribute is read-only. If the device is not enabled to wake up
attribute is read-only. If the device is not capable to wake up
the system from sleep states, this attribute is not present.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
What: /sys/devices/.../power/wakeup_active_count
Date: September 2010
@ -93,8 +95,10 @@ Description:
The /sys/devices/.../wakeup_active_count attribute contains the
number of times the processing of wakeup events associated with
the device was completed (at the kernel level). This attribute
is read-only. If the device is not enabled to wake up the
system from sleep states, this attribute is not present.
is read-only. If the device is not capable to wake up the
system from sleep states, this attribute is not present. If
the device is not enabled to wake up the system from sleep
states, this attribute is empty.
What: /sys/devices/.../power/wakeup_abort_count
Date: February 2012
@ -104,8 +108,9 @@ Description:
number of times the processing of a wakeup event associated with
the device might have aborted system transition into a sleep
state in progress. This attribute is read-only. If the device
is not enabled to wake up the system from sleep states, this
attribute is not present.
is not capable to wake up the system from sleep states, this
attribute is not present. If the device is not enabled to wake
up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_expire_count
Date: February 2012
@ -114,8 +119,10 @@ Description:
The /sys/devices/.../wakeup_expire_count attribute contains the
number of times a wakeup event associated with the device has
been reported with a timeout that expired. This attribute is
read-only. If the device is not enabled to wake up the system
from sleep states, this attribute is not present.
read-only. If the device is not capable to wake up the system
from sleep states, this attribute is not present. If the
device is not enabled to wake up the system from sleep states,
this attribute is empty.
What: /sys/devices/.../power/wakeup_active
Date: September 2010
@ -124,8 +131,10 @@ Description:
The /sys/devices/.../wakeup_active attribute contains either 1,
or 0, depending on whether or not a wakeup event associated with
the device is being processed (1). This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is not present.
If the device is not capable to wake up the system from sleep
states, this attribute is not present. If the device is not
enabled to wake up the system from sleep states, this attribute
is empty.
What: /sys/devices/.../power/wakeup_total_time_ms
Date: September 2010
@ -134,8 +143,9 @@ Description:
The /sys/devices/.../wakeup_total_time_ms attribute contains
the total time of processing wakeup events associated with the
device, in milliseconds. This attribute is read-only. If the
device is not enabled to wake up the system from sleep states,
this attribute is not present.
device is not capable to wake up the system from sleep states,
this attribute is not present. If the device is not enabled to
wake up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_max_time_ms
Date: September 2010
@ -144,8 +154,10 @@ Description:
The /sys/devices/.../wakeup_max_time_ms attribute contains
the maximum time of processing a single wakeup event associated
with the device, in milliseconds. This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is not present.
If the device is not capable to wake up the system from sleep
states, this attribute is not present. If the device is not
enabled to wake up the system from sleep states, this attribute
is empty.
What: /sys/devices/.../power/wakeup_last_time_ms
Date: September 2010
@ -156,7 +168,8 @@ Description:
signaling the last wakeup event associated with the device, in
milliseconds. This attribute is read-only. If the device is
not enabled to wake up the system from sleep states, this
attribute is not present.
attribute is not present. If the device is not enabled to wake
up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms
Date: February 2012
@ -165,9 +178,10 @@ Description:
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
contains the total time the device has been preventing
opportunistic transitions to sleep states from occurring.
This attribute is read-only. If the device is not enabled to
This attribute is read-only. If the device is not capable to
wake up the system from sleep states, this attribute is not
present.
present. If the device is not enabled to wake up the system
from sleep states, this attribute is empty.
What: /sys/devices/.../power/autosuspend_delay_ms
Date: September 2010

28
Documentation/ABI/testing/sysfs-firmware-ofw Normal file
View File

@ -0,0 +1,28 @@
What: /sys/firmware/devicetree/*
Date: November 2013
Contact: Grant Likely <grant.likely@linaro.org>
Description:
When using OpenFirmware or a Flattened Device Tree to enumerate
hardware, the device tree structure will be exposed in this
directory.
It is possible for multiple device-tree directories to exist.
Some device drivers use a separate detached device tree which
have no attachment to the system tree and will appear in a
different subdirectory under /sys/firmware/devicetree.
Userspace must not use the /sys/firmware/devicetree/base
path directly, but instead should follow /proc/device-tree
symlink. It is possible that the absolute path will change
in the future, but the symlink is the stable ABI.
The /proc/device-tree symlink replaces the devicetree /proc
filesystem support, and has largely the same semantics and
should be compatible with existing userspace.
The contents of /sys/firmware/devicetree/ is a
hierarchy of directories, one per device tree node. The
directory name is the resolved path component name (node
name plus address). Properties are represented as files
in the directory. The contents of each file is the exact
binary data from the device tree.

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

@ -55,3 +55,15 @@ Date: January 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the number of trials to find a victim segment.
What: /sys/fs/f2fs/<disk>/dir_level
Date: March 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the directory level for large directory.
What: /sys/fs/f2fs/<disk>/ram_thresh
Date: March 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the memory footprint used by f2fs.

1
Documentation/ABI/testing/sysfs-module
View File

@ -49,3 +49,4 @@ Description: Module taint flags:
O - out-of-tree module
F - force-loaded module
C - staging driver module
E - unsigned module

20
Documentation/ABI/testing/sysfs-ptp
View File

@ -54,6 +54,26 @@ Description:
This file contains the number of programmable periodic
output channels offered by the PTP hardware clock.
What: /sys/class/ptp/ptpN/n_pins
Date: March 2014
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the number of programmable pins
offered by the PTP hardware clock.
What: /sys/class/ptp/ptpN/pins
Date: March 2014
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This directory contains one file for each programmable
pin offered by the PTP hardware clock. The file name
is the hardware dependent pin name. Reading from this
file produces two numbers, the assigned function (see
the PTP_PF_ enumeration values in linux/ptp_clock.h)
and the channel number. The function and channel
assignment may be changed by two writing numbers into
the file.
What: /sys/class/ptp/ptpN/pps_avaiable
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>

2
Documentation/DocBook/80211.tmpl
View File

@ -98,6 +98,8 @@
!Finclude/net/cfg80211.h priv_to_wiphy
!Finclude/net/cfg80211.h set_wiphy_dev
!Finclude/net/cfg80211.h wdev_priv
!Finclude/net/cfg80211.h ieee80211_iface_limit
!Finclude/net/cfg80211.h ieee80211_iface_combination
</chapter>
<chapter>
<title>Actions and configuration</title>

25
Documentation/DocBook/Makefile
View File

@ -16,7 +16,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.xml
include $(srctree)/Documentation/DocBook/media/Makefile
include Documentation/DocBook/media/Makefile
###
# The build process is as follows (targets):
@ -36,6 +36,7 @@ PS_METHOD = $(prefer-db2x)
# The targets that may be used.
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
targets += $(DOCBOOKS)
BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
xmldocs: $(BOOKS)
sgmldocs: xmldocs
@ -58,14 +59,14 @@ mandocs: $(MAN)
installmandocs: mandocs
mkdir -p /usr/local/man/man9/
install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/
install $(obj)/man/*.9.gz /usr/local/man/man9/
###
#External programs used
KERNELDOC = $(srctree)/scripts/kernel-doc
DOCPROC = $(objtree)/scripts/docproc
XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
XMLTOFLAGS += --skip-validation
###
@ -87,21 +88,9 @@ define rule_docproc
) > $(dir $@).$(notdir $@).cmd
endef
%.xml: %.tmpl FORCE
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
$(call if_changed_rule,docproc)
###
#Read in all saved dependency files
cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd))
ifneq ($(cmd_files),)
include $(cmd_files)
endif
###
# Changes in kernel-doc force a rebuild of all documentation
$(BOOKS): $(KERNELDOC)
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@ -139,7 +128,7 @@ quiet_cmd_db2pdf = PDF $@
index = index.html
main_idx = Documentation/DocBook/$(index)
main_idx = $(obj)/$(index)
build_main_index = rm -rf $(main_idx); \
echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
@ -148,7 +137,7 @@ build_main_index = rm -rf $(main_idx); \
quiet_cmd_db2html = HTML $@
cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
%.html: %.xml
@(which xmlto > /dev/null 2>&1) || \

10
Documentation/DocBook/device-drivers.tmpl
View File

@ -276,7 +276,7 @@ X!Isound/sound_firmware.c
</para>
<sect1><title>Frame Buffer Memory</title>
!Edrivers/video/fbmem.c
!Edrivers/video/fbdev/core/fbmem.c
</sect1>
<!--
<sect1><title>Frame Buffer Console</title>
@ -284,7 +284,7 @@ X!Edrivers/video/console/fbcon.c
</sect1>
-->
<sect1><title>Frame Buffer Colormap</title>
!Edrivers/video/fbcmap.c
!Edrivers/video/fbdev/core/fbcmap.c
</sect1>
<!-- FIXME:
drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment
@ -294,11 +294,11 @@ X!Idrivers/video/fbgen.c
</sect1>
KAO -->
<sect1><title>Frame Buffer Video Mode Database</title>
!Idrivers/video/modedb.c
!Edrivers/video/modedb.c
!Idrivers/video/fbdev/core/modedb.c
!Edrivers/video/fbdev/core/modedb.c
</sect1>
<sect1><title>Frame Buffer Macintosh Video Mode Database</title>
!Edrivers/video/macmodes.c
!Edrivers/video/fbdev/macmodes.c
</sect1>
<sect1><title>Frame Buffer Fonts</title>
<para>

557
Documentation/DocBook/drm.tmpl
View File

@ -29,12 +29,26 @@
</address>
</affiliation>
</author>
<author>
<firstname>Daniel</firstname>
<surname>Vetter</surname>
<contrib>Contributions all over the place</contrib>
<affiliation>
<orgname>Intel Corporation</orgname>
<address>
<email>daniel.vetter@ffwll.ch</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2008-2009</year>
<year>2012</year>
<year>2013-2014</year>
<holder>Intel Corporation</holder>
</copyright>
<copyright>
<year>2012</year>
<holder>Laurent Pinchart</holder>
</copyright>
@ -60,7 +74,15 @@
<toc></toc>
<!-- Introduction -->
<part id="drmCore">
<title>DRM Core</title>
<partintro>
<para>
This first part of the DRM Developer's Guide documents core DRM code,
helper libraries for writting drivers and generic userspace interfaces
exposed by DRM drivers.
</para>
</partintro>
<chapter id="drmIntroduction">
<title>Introduction</title>
@ -264,8 +286,8 @@ char *date;</synopsis>
<para>
The <methodname>load</methodname> method is the driver and device
initialization entry point. The method is responsible for allocating and
initializing driver private data, specifying supported performance
counters, performing resource allocation and mapping (e.g. acquiring
initializing driver private data, performing resource allocation and
mapping (e.g. acquiring
clocks, mapping registers or allocating command buffers), initializing
the memory manager (<xref linkend="drm-memory-management"/>), installing
the IRQ handler (<xref linkend="drm-irq-registration"/>), setting up
@ -295,7 +317,7 @@ char *date;</synopsis>
their <methodname>load</methodname> method called with flags to 0.
</para>
<sect3>
<title>Driver Private &amp; Performance Counters</title>
<title>Driver Private Data</title>
<para>
The driver private hangs off the main
<structname>drm_device</structname> structure and can be used for
@ -307,14 +329,6 @@ char *date;</synopsis>
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
set to NULL when the driver is unloaded.
</para>
<para>
DRM supports several counters which were used for rough performance
characterization. This stat counter system is deprecated and should not
be used. If performance monitoring is desired, the developer should
investigate and potentially enhance the kernel perf and tracing
infrastructure to export GPU related performance information for
consumption by performance monitoring tools and applications.
</para>
</sect3>
<sect3 id="drm-irq-registration">
<title>IRQ Registration</title>
@ -697,55 +711,16 @@ char *date;</synopsis>
respectively. The conversion is handled by the DRM core without any
driver-specific support.
</para>
<para>
Similar to global names, GEM file descriptors are also used to share GEM
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 GEM file descriptors, also known as the DRM 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.
</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 DRM
PRIME.
</para>
<sect4>
<title>DRM PRIME Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
</sect4>
<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>
@ -829,62 +804,6 @@ char *date;</synopsis>
faults can implement their own mmap file operation handler.
</para>
</sect3>
<sect3>
<title>Dumb GEM Objects</title>
<para>
The GEM API doesn't standardize GEM objects creation and leaves it to
driver-specific ioctls. While not an issue for full-fledged graphics
stacks that include device-specific userspace components (in libdrm for
instance), this limit makes DRM-based early boot graphics unnecessarily
complex.
</para>
<para>
Dumb GEM objects partly alleviate the problem by providing a standard
API to create dumb buffers suitable for scanout, which can then be used
to create KMS frame buffers.
</para>
<para>
To support dumb GEM objects drivers must implement the
<methodname>dumb_create</methodname>,
<methodname>dumb_destroy</methodname> and
<methodname>dumb_map_offset</methodname> operations.
</para>
<itemizedlist>
<listitem>
<synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev,
struct drm_mode_create_dumb *args);</synopsis>
<para>
The <methodname>dumb_create</methodname> operation creates a GEM
object suitable for scanout based on the width, height and depth
from the struct <structname>drm_mode_create_dumb</structname>
argument. It fills the argument's <structfield>handle</structfield>,
<structfield>pitch</structfield> and <structfield>size</structfield>
fields with a handle for the newly created GEM object and its line
pitch and size in bytes.
</para>
</listitem>
<listitem>
<synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev,
uint32_t handle);</synopsis>
<para>
The <methodname>dumb_destroy</methodname> operation destroys a dumb
GEM object created by <methodname>dumb_create</methodname>.
</para>
</listitem>
<listitem>
<synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev,
uint32_t handle, uint64_t *offset);</synopsis>
<para>
The <methodname>dumb_map_offset</methodname> operation associates an
mmap fake offset with the GEM object given by the handle and returns
it. Drivers must use the
<function>drm_gem_create_mmap_offset</function> function to
associate the fake offset as described in
<xref linkend="drm-gem-objects-mapping"/>.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Memory Coherency</title>
<para>
@ -924,7 +843,99 @@ char *date;</synopsis>
abstracted from the client in libdrm.
</para>
</sect3>
</sect2>
<sect3>
<title>GEM Function Reference</title>
!Edrivers/gpu/drm/drm_gem.c
</sect3>
</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);
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 unsinged 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
</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>
!Pdrivers/gpu/drm/drm_mm.c Overview
</sect3>
<sect3>
<title>LRU Scan/Eviction Support</title>
!Pdrivers/gpu/drm/drm_mm.c lru scan roaster
</sect3>
</sect2>
<sect2>
<title>DRM MM Range Allocator Function References</title>
!Edrivers/gpu/drm/drm_mm.c
!Iinclude/drm/drm_mm.h
</sect2>
</sect1>
<!-- Internals: mode setting -->
@ -952,6 +963,11 @@ int max_width, max_height;</synopsis>
<para>Mode setting functions.</para>
</listitem>
</itemizedlist>
<sect2>
<title>Display Modes Function Reference</title>
!Iinclude/drm/drm_modes.h
!Edrivers/gpu/drm/drm_modes.c
</sect2>
<sect2>
<title>Frame Buffer Creation</title>
<synopsis>struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
@ -968,9 +984,11 @@ int max_width, max_height;</synopsis>
Frame buffers rely on the underneath memory manager for low-level memory
operations. When creating a frame buffer applications pass a memory
handle (or a list of memory handles for multi-planar formats) through
the <parameter>drm_mode_fb_cmd2</parameter> argument. This document
assumes that the driver uses GEM, those handles thus reference GEM
objects.
the <parameter>drm_mode_fb_cmd2</parameter> argument. For drivers using
GEM as their userspace buffer management interface this would be a GEM
handle. Drivers are however free to use their own backing storage object
handles, e.g. vmwgfx directly exposes special TTM handles to userspace
and so expects TTM handles in the create ioctl and not GEM handles.
</para>
<para>
Drivers must first validate the requested frame buffer parameters passed
@ -992,7 +1010,7 @@ int max_width, max_height;</synopsis>
</para>
<para>
The initailization of the new framebuffer instance is finalized with a
The initialization of the new framebuffer instance is finalized with a
call to <function>drm_framebuffer_init</function> which takes a pointer
to DRM frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Note that this function
@ -1042,7 +1060,7 @@ int max_width, max_height;</synopsis>
<para>
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with
<function>drm_framebuffer_reference</function> </para> and drop them
<function>drm_framebuffer_reference</function>and drop them
again with <function>drm_framebuffer_unreference</function>. For
driver-private framebuffers for which the last reference is never
dropped (e.g. for the fbdev framebuffer when the struct
@ -1050,6 +1068,72 @@ int max_width, max_height;</synopsis>
helper struct) drivers can manually clean up a framebuffer at module
unload time with
<function>drm_framebuffer_unregister_private</function>.
</para>
</sect2>
<sect2>
<title>Dumb Buffer Objects</title>
<para>
The KMS API doesn't standardize backing storage object creation and
leaves it to driver-specific ioctls. Furthermore actually creating a
buffer object even for GEM-based drivers is done through a
driver-specific ioctl - GEM only has a common userspace interface for
sharing and destroying objects. While not an issue for full-fledged
graphics stacks that include device-specific userspace components (in
libdrm for instance), this limit makes DRM-based early boot graphics
unnecessarily complex.
</para>
<para>
Dumb objects partly alleviate the problem by providing a standard
API to create dumb buffers suitable for scanout, which can then be used
to create KMS frame buffers.
</para>
<para>
To support dumb objects drivers must implement the
<methodname>dumb_create</methodname>,
<methodname>dumb_destroy</methodname> and
<methodname>dumb_map_offset</methodname> operations.
</para>
<itemizedlist>
<listitem>
<synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev,
struct drm_mode_create_dumb *args);</synopsis>
<para>
The <methodname>dumb_create</methodname> operation creates a driver
object (GEM or TTM handle) suitable for scanout based on the
width, height and depth from the struct
<structname>drm_mode_create_dumb</structname> argument. It fills the
argument's <structfield>handle</structfield>,
<structfield>pitch</structfield> and <structfield>size</structfield>
fields with a handle for the newly created object and its line
pitch and size in bytes.
</para>
</listitem>
<listitem>
<synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev,
uint32_t handle);</synopsis>
<para>
The <methodname>dumb_destroy</methodname> operation destroys a dumb
object created by <methodname>dumb_create</methodname>.
</para>
</listitem>
<listitem>
<synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev,
uint32_t handle, uint64_t *offset);</synopsis>
<para>
The <methodname>dumb_map_offset</methodname> operation associates an
mmap fake offset with the object given by the handle and returns
it. Drivers must use the
<function>drm_gem_create_mmap_offset</function> function to
associate the fake offset as described in
<xref linkend="drm-gem-objects-mapping"/>.
</para>
</listitem>
</itemizedlist>
<para>
Note that dumb objects may not be used for gpu acceleration, as has been
attempted on some ARM embedded platforms. Such drivers really must have
a hardware-specific ioctl to allocate suitable buffer objects.
</para>
</sect2>
<sect2>
<title>Output Polling</title>
@ -1110,7 +1194,7 @@ int max_width, max_height;</synopsis>
pointer to CRTC functions.
</para>
</sect3>
<sect3>
<sect3 id="drm-kms-crtcops">
<title>CRTC Operations</title>
<sect4>
<title>Set Configuration</title>
@ -1130,8 +1214,11 @@ int max_width, max_height;</synopsis>
This operation is called with the mode config lock held.
</para>
<note><para>
FIXME: How should set_config interact with DPMS? If the CRTC is
suspended, should it be resumed?
Note that the drm core has no notion of restoring the mode setting
state after resume, since all resume handling is in the full
responsibility of the driver. The common mode setting helper library
though provides a helper which can be used for this:
<function>drm_helper_resume_force_mode</function>.
</para></note>
</sect4>
<sect4>
@ -1248,15 +1335,47 @@ int max_width, max_height;</synopsis>
optionally scale it to a destination size. The result is then blended
with or overlayed on top of a CRTC.
</para>
<para>
The DRM core recognizes three types of planes:
<itemizedlist>
<listitem>
DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary
planes are the planes operated upon by by CRTC modesetting and flipping
operations described in <xref linkend="drm-kms-crtcops"/>.
</listitem>
<listitem>
DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor
planes are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and
DRM_IOCTL_MODE_CURSOR2 ioctls.
</listitem>
<listitem>
DRM_PLANE_TYPE_OVERLAY represents all non-primary, non-cursor planes.
Some drivers refer to these types of planes as "sprites" internally.
</listitem>
</itemizedlist>
For compatibility with legacy userspace, only overlay planes are made
available to userspace by default. Userspace clients may set the
DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that
they wish to receive a universal plane list containing all plane types.
</para>
<sect3>
<title>Plane Initialization</title>
<para>
Planes are optional. To create a plane, a KMS drivers allocates and
To create a plane, a KMS drivers allocates and
zeroes an instances of struct <structname>drm_plane</structname>
(possibly as part of a larger structure) and registers it with a call
to <function>drm_plane_init</function>. The function takes a bitmask
to <function>drm_universal_plane_init</function>. The function takes a bitmask
of the CRTCs that can be associated with the plane, a pointer to the
plane functions and a list of format supported formats.
plane functions, a list of format supported formats, and the type of
plane (primary, cursor, or overlay) being initialized.
</para>
<para>
Cursor and overlay planes are optional. All drivers should provide
one primary plane per CRTC (although this requirement may change in
the future); drivers that do not wish to provide special handling for
primary planes may make use of the helper functions described in
<xref linkend="drm-kms-planehelpers"/> to create and register a
primary plane with standard capabilities.
</para>
</sect3>
<sect3>
@ -1687,7 +1806,7 @@ void intel_crt_init(struct drm_device *dev)
<sect1>
<title>Mode Setting Helper Functions</title>
<para>
The CRTC, encoder and connector functions provided by the drivers
The plane, CRTC, encoder and connector functions provided by the drivers
implement the DRM API. They're called by the DRM core and ioctl handlers
to handle device state changes and configuration request. As implementing
those functions often requires logic not specific to drivers, mid-layer
@ -1695,8 +1814,8 @@ void intel_crt_init(struct drm_device *dev)
</para>
<para>
The DRM core contains one mid-layer implementation. The mid-layer provides
implementations of several CRTC, encoder and connector functions (called
from the top of the mid-layer) that pre-process requests and call
implementations of several plane, CRTC, encoder and connector functions
(called from the top of the mid-layer) that pre-process requests and call
lower-level functions provided by the driver (at the bottom of the
mid-layer). For instance, the
<function>drm_crtc_helper_set_config</function> function can be used to
@ -2134,7 +2253,7 @@ void intel_crt_init(struct drm_device *dev)
set the <structfield>display_info</structfield>
<structfield>width_mm</structfield> and
<structfield>height_mm</structfield> fields if they haven't been set
already (for instance at initilization time when a fixed-size panel is
already (for instance at initialization time when a fixed-size panel is
attached to the connector). The mode <structfield>width_mm</structfield>
and <structfield>height_mm</structfield> fields are only used internally
during EDID parsing and should not be set when creating modes manually.
@ -2166,6 +2285,11 @@ void intel_crt_init(struct drm_device *dev)
<sect2>
<title>Modeset Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_crtc_helper.c
</sect2>
<sect2>
<title>Output Probing Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_probe_helper.c output probing helper overview
!Edrivers/gpu/drm/drm_probe_helper.c
</sect2>
<sect2>
<title>fbdev Helper Functions Reference</title>
@ -2196,10 +2320,19 @@ void intel_crt_init(struct drm_device *dev)
!Edrivers/gpu/drm/drm_flip_work.c
</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
<title>HDMI Infoframes Helper Reference</title>
<para>
Strictly speaking this is not a DRM helper library but generally useable
by any driver interfacing with HDMI outputs like v4l or alsa drivers.
But it nicely fits into the overall topic of mode setting helper
libraries and hence is also included here.
</para>
!Iinclude/linux/hdmi.h
!Edrivers/video/hdmi.c
</sect2>
<sect2>
<title id="drm-kms-planehelpers">Plane Helper Reference</title>
!Edrivers/gpu/drm/drm_plane_helper.c Plane Helpers
</sect2>
</sect1>
@ -2561,42 +2694,44 @@ int num_ioctls;</synopsis>
</para>
</sect2>
</sect1>
<sect1>
<title>Command submission &amp; fencing</title>
<title>Legacy Support Code</title>
<para>
This should cover a few device-specific command submission
implementations.
The section very brievely covers some of the old legacy support code which
is only used by old DRM drivers which have done a so-called shadow-attach
to the underlying device instead of registering as a real driver. This
also includes some of the old generic buffer mangement and command
submission code. Do not use any of this in new and modern drivers.
</para>
</sect1>
<!-- Internals: suspend/resume -->
<sect2>
<title>Legacy Suspend/Resume</title>
<para>
The DRM core provides some suspend/resume code, but drivers wanting full
suspend/resume support should provide save() and restore() functions.
These are called at suspend, hibernate, or resume time, and should perform
any state save or restore required by your device across suspend or
hibernate states.
</para>
<synopsis>int (*suspend) (struct drm_device *, pm_message_t state);
int (*resume) (struct drm_device *);</synopsis>
<para>
Those are legacy suspend and resume methods which
<emphasis>only</emphasis> work with the legacy shadow-attach driver
registration functions. New driver should use the power management
interface provided by their bus type (usually through
the struct <structname>device_driver</structname> dev_pm_ops) and set
these methods to NULL.
</para>
</sect2>
<sect1>
<title>Suspend/Resume</title>
<para>
The DRM core provides some suspend/resume code, but drivers wanting full
suspend/resume support should provide save() and restore() functions.
These are called at suspend, hibernate, or resume time, and should perform
any state save or restore required by your device across suspend or
hibernate states.
</para>
<synopsis>int (*suspend) (struct drm_device *, pm_message_t state);
int (*resume) (struct drm_device *);</synopsis>
<para>
Those are legacy suspend and resume methods. New driver should use the
power management interface provided by their bus type (usually through
the struct <structname>device_driver</structname> dev_pm_ops) and set
these methods to NULL.
</para>
</sect1>
<sect1>
<title>DMA services</title>
<para>
This should cover how DMA mapping etc. is supported by the core.
These functions are deprecated and should not be used.
</para>
<sect2>
<title>Legacy DMA Services</title>
<para>
This should cover how DMA mapping etc. is supported by the core.
These functions are deprecated and should not be used.
</para>
</sect2>
</sect1>
</chapter>
@ -2658,8 +2793,8 @@ int (*resume) (struct drm_device *);</synopsis>
DRM core provides multiple character-devices for user-space to use.
Depending on which device is opened, user-space can perform a different
set of operations (mainly ioctls). The primary node is always created
and called <term>card&lt;num&gt;</term>. Additionally, a currently
unused control node, called <term>controlD&lt;num&gt;</term> is also
and called card&lt;num&gt;. Additionally, a currently
unused control node, called controlD&lt;num&gt; is also
created. The primary node provides all legacy operations and
historically was the only interface used by userspace. With KMS, the
control node was introduced. However, the planned KMS control interface
@ -2674,21 +2809,21 @@ int (*resume) (struct drm_device *);</synopsis>
nodes were introduced. Render nodes solely serve render clients, that
is, no modesetting or privileged ioctls can be issued on render nodes.
Only non-global rendering commands are allowed. If a driver supports
render nodes, it must advertise it via the <term>DRIVER_RENDER</term>
render nodes, it must advertise it via the DRIVER_RENDER
DRM driver capability. If not supported, the primary node must be used
for render clients together with the legacy drmAuth authentication
procedure.
</para>
<para>
If a driver advertises render node support, DRM core will create a
separate render node called <term>renderD&lt;num&gt;</term>. There will
separate render node called renderD&lt;num&gt;. There will
be one render node per device. No ioctls except PRIME-related ioctls
will be allowed on this node. Especially <term>GEM_OPEN</term> will be
will be allowed on this node. Especially GEM_OPEN will be
explicitly prohibited. Render nodes are designed to avoid the
buffer-leaks, which occur if clients guess the flink names or mmap
offsets on the legacy interface. Additionally to this basic interface,
drivers must mark their driver-dependent render-only ioctls as
<term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver
DRM_RENDER_ALLOW so render clients can use them. Driver
authors must be careful not to allow any privileged ioctls on render
nodes.
</para>
@ -2749,15 +2884,73 @@ int (*resume) (struct drm_device *);</synopsis>
</sect1>
</chapter>
</part>
<part id="drmDrivers">
<title>DRM Drivers</title>
<!-- API reference -->
<appendix id="drmDriverApi">
<title>DRM Driver API</title>
<partintro>
<para>
Include auto-generated API reference here (need to reference it
from paragraphs above too).
This second part of the DRM Developer's Guide documents driver code,
implementation details and also all the driver-specific userspace
interfaces. Especially since all hardware-acceleration interfaces to
userspace are driver specific for efficiency and other reasons these
interfaces can be rather substantial. Hence every driver has its own
chapter.
</para>
</appendix>
</partintro>
<chapter id="drmI915">
<title>drm/i915 Intel GFX Driver</title>
<para>
The drm/i915 driver supports all (with the exception of some very early
models) integrated GFX chipsets with both Intel display and rendering
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>Display Hardware Handling</title>
<para>
This section covers everything related to the display hardware including
the mode setting infrastructure, plane, sprite and cursor handling and
display, output probing and related topics.
</para>
<sect2>
<title>Mode Setting Infrastructure</title>
<para>
The i915 driver is thus far the only DRM driver which doesn't use the
common DRM helper code to implement mode setting sequences. Thus it
has its own tailor-made infrastructure for executing a display
configuration change.
</para>
</sect2>
<sect2>
<title>Plane Configuration</title>
<para>
This section covers plane configuration and composition with the
primary plane, sprites, cursors and overlays. This includes the
infrastructure to do atomic vsync'ed updates of all this state and
also tightly coupled topics like watermark setup and computation,
framebuffer compression and panel self refresh.
</para>
</sect2>
<sect2>
<title>Output Probing</title>
<para>
This section covers output probing and related infrastructure like the
hotplug interrupt storm detection and mitigation code. Note that the
i915 driver still uses most of the common DRM helper code for output
probing, so those sections fully apply.
</para>
</sect2>
</sect1>
<sect1>
<title>Memory Management and Command Submission</title>
<para>
This sections covers all things related to the GEM implementation in the
i915 driver.
</para>
</sect1>
</chapter>
</part>
</book>

12
Documentation/DocBook/kernel-hacking.tmpl
View File

@ -671,7 +671,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<sect1 id="routines-local-irqs">
<title><function>local_irq_save()</function>/<function>local_irq_restore()</function>
<filename class="headerfile">include/asm/system.h</filename>
<filename class="headerfile">include/linux/irqflags.h</filename>
</title>
<para>
@ -850,16 +850,6 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<returnvalue>-ERESTARTSYS</returnvalue> if a signal is received.
The <function>wait_event()</function> version ignores signals.
</para>
<para>
Do not use the <function>sleep_on()</function> function family -
it is very easy to accidentally introduce races; almost certainly
one of the <function>wait_event()</function> family will do, or a
loop around <function>schedule_timeout()</function>. If you choose
to loop around <function>schedule_timeout()</function> remember
you must set the task state (with
<function>set_current_state()</function>) on each iteration to avoid
busy-looping.
</para>
</sect1>

23
Documentation/DocBook/media/dvb/demux.xml
View File

@ -1042,7 +1042,14 @@ role="subsection"><title>DMX_ADD_PID</title>
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
<para>This ioctl call allows to add multiple PIDs to a transport stream filter
previously set up with DMX_SET_PES_FILTER and output equal to DMX_OUT_TSDEMUX_TAP.
</para></entry></row><row><entry align="char"><para>
It is used by readers of /dev/dvb/adapterX/demuxY.
</para></entry></row><row><entry align="char"><para>
It may be called at any time, i.e. before or after the first filter on the
shared file descriptor was started. It makes it possible to record multiple
services without the need to de-multiplex or re-multiplex TS packets.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
@ -1075,7 +1082,7 @@ role="subsection"><title>DMX_ADD_PID</title>
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
<para>PID number to be filtered.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
@ -1087,7 +1094,15 @@ role="subsection"><title>DMX_REMOVE_PID</title>
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
<para>This ioctl call allows to remove a PID when multiple PIDs are set on a
transport stream filter, e. g. a filter previously set up with output equal to
DMX_OUT_TSDEMUX_TAP, created via either DMX_SET_PES_FILTER or DMX_ADD_PID.
</para></entry></row><row><entry align="char"><para>
It is used by readers of /dev/dvb/adapterX/demuxY.
</para></entry></row><row><entry align="char"><para>
It may be called at any time, i.e. before or after the first filter on the
shared file descriptor was started. It makes it possible to record multiple
services without the need to de-multiplex or re-multiplex TS packets.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
@ -1120,7 +1135,7 @@ role="subsection"><title>DMX_REMOVE_PID</title>
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
<para>PID of the PES filter to be removed.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;

4
Documentation/DocBook/media/dvb/dvbapi.xml
View File

@ -18,7 +18,7 @@
<firstname>Mauro</firstname>
<othername role="mi">Carvalho</othername>
<surname>Chehab</surname>
<affiliation><address><email>mchehab@redhat.com</email></address></affiliation>
<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation>
<contrib>Ported document to Docbook XML.</contrib>
</author>
</authorgroup>
@ -28,7 +28,7 @@
<holder>Convergence GmbH</holder>
</copyright>
<copyright>
<year>2009-2012</year>
<year>2009-2014</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>

2
Documentation/DocBook/media/dvb/dvbproperty.xml
View File

@ -196,7 +196,7 @@ get/set up to 64 properties. The actual meaning of each property is described on
<para>1)For satellital delivery systems, it is measured in kHz.
For the other ones, it is measured in Hz.</para>
<para>2)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
E.g. a valid frequency could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>
<para>3)As in ISDB-Tsb the channel consists of only one or three segments the

8
Documentation/DocBook/media/dvb/frontend.xml
View File

@ -744,7 +744,7 @@ typedef enum fe_hierarchy {
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t
<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, uint16_t
&#x22C6;snr);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -766,7 +766,7 @@ typedef enum fe_hierarchy {
</entry>
</row><row><entry
align="char">
<para>int16_t *snr</para>
<para>uint16_t *snr</para>
</entry><entry
align="char">
<para>The signal-to-noise ratio is stored into *snr.</para>
@ -791,7 +791,7 @@ typedef enum fe_hierarchy {
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl( int fd, int request =
<link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t &#x22C6;strength);</para>
<link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, uint16_t &#x22C6;strength);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -814,7 +814,7 @@ typedef enum fe_hierarchy {
</entry>
</row><row><entry
align="char">
<para>int16_t *strength</para>
<para>uint16_t *strength</para>
</entry><entry
align="char">
<para>The signal strength value is stored into *strength.</para>

402
Documentation/DocBook/media/v4l/common.xml
View File

@ -38,70 +38,41 @@ the basic concepts applicable to all devices.</para>
<para>V4L2 drivers are implemented as kernel modules, loaded
manually by the system administrator or automatically when a device is
first opened. The driver modules plug into the "videodev" kernel
first discovered. The driver modules plug into the "videodev" kernel
module. It provides helper functions and a common application
interface specified in this document.</para>
<para>Each driver thus loaded registers one or more device nodes
with major number 81 and a minor number between 0 and 255. Assigning
minor numbers to V4L2 devices is entirely up to the system administrator,
this is primarily intended to solve conflicts between devices.<footnote>
<para>Access permissions are associated with character
device special files, hence we must ensure device numbers cannot
change with the module load order. To this end minor numbers are no
longer automatically assigned by the "videodev" module as in V4L but
requested by the driver. The defaults will suffice for most people
unless two drivers compete for the same minor numbers.</para>
</footnote> The module options to select minor numbers are named
after the device special file with a "_nr" suffix. For example "video_nr"
for <filename>/dev/video</filename> video capture devices. The number is
an offset to the base minor number associated with the device type.
<footnote>
<para>In earlier versions of the V4L2 API the module options
where named after the device special file with a "unit_" prefix, expressing
the minor number itself, not an offset. Rationale for this change is unknown.
Lastly the naming and semantics are just a convention among driver writers,
the point to note is that minor numbers are not supposed to be hardcoded
into drivers.</para>
</footnote> When the driver supports multiple devices of the same
type more than one minor number can be assigned, separated by commas:
<informalexample>
with major number 81 and a minor number between 0 and 255. Minor numbers
are allocated dynamically unless the kernel is compiled with the kernel
option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are
allocated in ranges depending on the device node type (video, radio, etc.).</para>
<para>Many drivers support "video_nr", "radio_nr" or "vbi_nr"
module options to select specific video/radio/vbi node numbers. This allows
the user to request that the device node is named e.g. /dev/video5 instead
of leaving it to chance. When the driver supports multiple devices of the same
type more than one device node number can be assigned, separated by commas:
<informalexample>
<screen>
&gt; insmod mydriver.o video_nr=0,1 radio_nr=0,1</screen>
&gt; modprobe mydriver video_nr=0,1 radio_nr=0,1</screen>
</informalexample></para>
<para>In <filename>/etc/modules.conf</filename> this may be
written as: <informalexample>
<screen>
alias char-major-81-0 mydriver
alias char-major-81-1 mydriver
alias char-major-81-64 mydriver <co id="alias" />
options mydriver video_nr=0,1 radio_nr=0,1 <co id="options" />
options mydriver video_nr=0,1 radio_nr=0,1
</screen>
<calloutlist>
<callout arearefs="alias">
<para>When an application attempts to open a device
special file with major number 81 and minor number 0, 1, or 64, load
"mydriver" (and the "videodev" module it depends upon).</para>
</callout>
<callout arearefs="options">
<para>Register the first two video capture devices with
minor number 0 and 1 (base number is 0), the first two radio device
with minor number 64 and 65 (base 64).</para>
</callout>
</calloutlist>
</informalexample> When no minor number is given as module
option the driver supplies a default. <xref linkend="devices" />
recommends the base minor numbers to be used for the various device
types. Obviously minor numbers must be unique. When the number is
already in use the <emphasis>offending device</emphasis> will not be
registered. <!-- Blessed by Linus Torvalds on
linux-kernel@vger.kernel.org, 2002-11-20. --></para>
</informalexample> When no device node number is given as module
option the driver supplies a default.</para>
<para>By convention system administrators create various
character device special files with these major and minor numbers in
the <filename>/dev</filename> directory. The names recommended for the
different V4L2 device types are listed in <xref linkend="devices" />.
<para>Normally udev will create the device nodes in /dev automatically
for you. If udev is not installed, then you need to enable the
CONFIG_VIDEO_FIXED_MINOR_RANGES kernel option in order to be able to correctly
relate a minor number to a device node number. I.e., you need to be certain
that minor number 5 maps to device node name video5. With this kernel option
different device types have different minor number ranges. These ranges are
listed in <xref linkend="devices" />.
</para>
<para>The creation of character special files (with
@ -110,85 +81,66 @@ devices cannot be opened by major and minor number. That means
applications cannot <emphasis>reliable</emphasis> scan for loaded or
installed drivers. The user must enter a device name, or the
application can try the conventional device names.</para>
<para>Under the device filesystem (devfs) the minor number
options are ignored. V4L2 drivers (or by proxy the "videodev" module)
automatically create the required device files in the
<filename>/dev/v4l</filename> directory using the conventional device
names above.</para>
</section>
<section id="related">
<title>Related Devices</title>
<para>Devices can support several related functions. For example
video capturing, video overlay and VBI capturing are related because
these functions share, amongst other, the same video input and tuner
frequency. V4L and earlier versions of V4L2 used the same device name
and minor number for video capturing and overlay, but different ones
for VBI. Experience showed this approach has several problems<footnote>
<para>Given a device file name one cannot reliable find
related devices. For once names are arbitrary and in a system with
multiple devices, where only some support VBI capturing, a
<filename>/dev/video2</filename> is not necessarily related to
<filename>/dev/vbi2</filename>. The V4L
<constant>VIDIOCGUNIT</constant> ioctl would require a search for a
device file with a particular major and minor number.</para>
</footnote>, and to make things worse the V4L videodev module
used to prohibit multiple opens of a device.</para>
<para>Devices can support several functions. For example
video capturing, VBI capturing and radio support.</para>
<para>As a remedy the present version of the V4L2 API relaxed the
concept of device types with specific names and minor numbers. For
compatibility with old applications drivers must still register different
minor numbers to assign a default function to the device. But if related
functions are supported by the driver they must be available under all
registered minor numbers. The desired function can be selected after
opening the device as described in <xref linkend="devices" />.</para>
<para>The V4L2 API creates different nodes for each of these functions.</para>
<para>Imagine a driver supporting video capturing, video
overlay, raw VBI capturing, and FM radio reception. It registers three
devices with minor number 0, 64 and 224 (this numbering scheme is
inherited from the V4L API). Regardless if
<filename>/dev/video</filename> (81, 0) or
<filename>/dev/vbi</filename> (81, 224) is opened the application can
select any one of the video capturing, overlay or VBI capturing
functions. Without programming (e.&nbsp;g. reading from the device
with <application>dd</application> or <application>cat</application>)
<filename>/dev/video</filename> captures video images, while
<filename>/dev/vbi</filename> captures raw VBI data.
<filename>/dev/radio</filename> (81, 64) is invariable a radio device,
unrelated to the video functions. Being unrelated does not imply the
devices can be used at the same time, however. The &func-open;
function may very well return an &EBUSY;.</para>
<para>The V4L2 API was designed with the idea that one device node could support
all functions. However, in practice this never worked: this 'feature'
was never used by applications and many drivers did not support it and if
they did it was certainly never tested. In addition, switching a device
node between different functions only works when using the streaming I/O
API, not with the read()/write() API.</para>
<para>Today each device node supports just one function.</para>
<para>Besides video input or output the hardware may also
support audio sampling or playback. If so, these functions are
implemented as OSS or ALSA PCM devices and eventually OSS or ALSA
audio mixer. The V4L2 API makes no provisions yet to find these
related devices. If you have an idea please write to the linux-media
mailing list: &v4l-ml;.</para>
implemented as ALSA PCM devices with optional ALSA audio mixer
devices.</para>
<para>One problem with all these devices is that the V4L2 API
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>
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>
</section>
<section>
<title>Multiple Opens</title>
<para>In general, V4L2 devices can be opened more than once.
<para>V4L2 devices can be opened more than once.<footnote><para>
There are still some old and obscure drivers that have not been updated to
allow for multiple opens. This implies that for such drivers &func-open; can
return an &EBUSY; when the device is already in use.</para></footnote>
When this is supported by the driver, users can for example start a
"panel" application to change controls like brightness or audio
volume, while another application captures video and audio. In other words, panel
applications are comparable to an OSS or ALSA audio mixer application.
When a device supports multiple functions like capturing and overlay
<emphasis>simultaneously</emphasis>, multiple opens allow concurrent
use of the device by forked processes or specialized applications.</para>
applications are comparable to an ALSA audio mixer application.
Just opening a V4L2 device should not change the state of the device.<footnote>
<para>Unfortunately, opening a radio device often switches the state of the
device to radio mode in many drivers. This behavior should be fixed eventually
as it violates the V4L2 specification.</para></footnote></para>
<para>Multiple opens are optional, although drivers should
permit at least concurrent accesses without data exchange, &ie; panel
applications. This implies &func-open; can return an &EBUSY; when the
device is already in use, as well as &func-ioctl; functions initiating
data exchange (namely the &VIDIOC-S-FMT; ioctl), and the &func-read;
and &func-write; functions.</para>
<para>Once an application has allocated the memory buffers needed for
streaming data (by calling the &VIDIOC-REQBUFS; or &VIDIOC-CREATE-BUFS; ioctls,
or implicitly by calling the &func-read; or &func-write; functions) that
application (filehandle) becomes the owner of the device. It is no longer
allowed to make changes that would affect the buffer sizes (e.g. by calling
the &VIDIOC-S-FMT; ioctl) and other applications are no longer allowed to allocate
buffers or start or stop streaming. The &EBUSY; will be returned instead.</para>
<para>Mere opening a V4L2 device does not grant exclusive
<para>Merely opening a V4L2 device does not grant exclusive
access.<footnote>
<para>Drivers could recognize the
<constant>O_EXCL</constant> open flag. Presently this is not required,
@ -206,12 +158,7 @@ additional access privileges using the priority mechanism described in
<para>V4L2 drivers should not support multiple applications
reading or writing the same data stream on a device by copying
buffers, time multiplexing or similar means. This is better handled by
a proxy application in user space. When the driver supports stream
sharing anyway it must be implemented transparently. The V4L2 API does
not specify how conflicts are solved. <!-- For example O_EXCL when the
application does not want to be preempted, PROT_READ mmapped buffers
which can be mapped twice, what happens when image formats do not
match etc.--></para>
a proxy application in user space.</para>
</section>
<section>
@ -240,15 +187,15 @@ methods</link> supported by the device.</para>
<para>Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the
V4L2 API version used by the driver, with generally matches the Kernel version.
There's no need of using &VIDIOC-QUERYCAP; to check if an specific ioctl is
supported, the V4L2 core now returns ENOIOCTLCMD if a driver doesn't provide
There's no need of using &VIDIOC-QUERYCAP; to check if a specific ioctl is
supported, the V4L2 core now returns ENOTTY if a driver doesn't provide
support for an ioctl.</para>
<para>Other features can be queried
by calling the respective ioctl, for example &VIDIOC-ENUMINPUT;
to learn about the number, types and names of video connectors on the
device. Although abstraction is a major objective of this API, the
ioctl also allows driver specific applications to reliable identify
&VIDIOC-QUERYCAP; ioctl also allows driver specific applications to reliably identify
the driver.</para>
<para>All V4L2 drivers must support
@ -278,9 +225,7 @@ Applications requiring a different priority will usually call
the &VIDIOC-QUERYCAP; ioctl.</para>
<para>Ioctls changing driver properties, such as &VIDIOC-S-INPUT;,
return an &EBUSY; after another application obtained higher priority.
An event mechanism to notify applications about asynchronous property
changes has been proposed but not added yet.</para>
return an &EBUSY; after another application obtained higher priority.</para>
</section>
<section id="video">
@ -288,9 +233,9 @@ changes has been proposed but not added yet.</para>
<para>Video inputs and outputs are physical connectors of a
device. These can be for example RF connectors (antenna/cable), CVBS
a.k.a. Composite Video, S-Video or RGB connectors. Only video and VBI
capture devices have inputs, output devices have outputs, at least one
each. Radio devices have no video inputs or outputs.</para>
a.k.a. Composite Video, S-Video or RGB connectors. Video and VBI
capture devices have inputs. Video and VBI output devices have outputs,
at least one each. Radio devices have no video inputs or outputs.</para>
<para>To learn about the number and attributes of the
available inputs and outputs applications can enumerate them with the
@ -299,30 +244,13 @@ available inputs and outputs applications can enumerate them with the
ioctl also contains signal status information applicable when the
current video input is queried.</para>
<para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctl return the
<para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctls return the
index of the current video input or output. To select a different
input or output applications call the &VIDIOC-S-INPUT; and
&VIDIOC-S-OUTPUT; ioctl. Drivers must implement all the input ioctls
&VIDIOC-S-OUTPUT; ioctls. Drivers must implement all the input ioctls
when the device has one or more inputs, all the output ioctls when the
device has one or more outputs.</para>
<!--
<figure id=io-tree>
<title>Input and output enumeration is the root of most device properties.</title>
<mediaobject>
<imageobject>
<imagedata fileref="links.pdf" format="ps" />
</imageobject>
<imageobject>
<imagedata fileref="links.gif" format="gif" />
</imageobject>
<textobject>
<phrase>Links between various device property structures.</phrase>
</textobject>
</mediaobject>
</figure>
-->
<example>
<title>Information about the current video input</title>
@ -330,20 +258,20 @@ device has one or more outputs.</para>
&v4l2-input; input;
int index;
if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &amp;index)) {
perror ("VIDIOC_G_INPUT");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &amp;index)) {
perror("VIDIOC_G_INPUT");
exit(EXIT_FAILURE);
}
memset (&amp;input, 0, sizeof (input));
memset(&amp;input, 0, sizeof(input));
input.index = index;
if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
perror ("VIDIOC_ENUMINPUT");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
perror("VIDIOC_ENUMINPUT");
exit(EXIT_FAILURE);
}
printf ("Current input: %s\n", input.name);
printf("Current input: %s\n", input.name);
</programlisting>
</example>
@ -355,9 +283,9 @@ int index;
index = 0;
if (-1 == ioctl (fd, &VIDIOC-S-INPUT;, &amp;index)) {
perror ("VIDIOC_S_INPUT");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-S-INPUT;, &amp;index)) {
perror("VIDIOC_S_INPUT");
exit(EXIT_FAILURE);
}
</programlisting>
</example>
@ -397,7 +325,7 @@ available inputs and outputs applications can enumerate them with the
also contains signal status information applicable when the current
audio input is queried.</para>
<para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctl report
<para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctls report
the current audio input and output, respectively. Note that, unlike
&VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; these ioctls return a structure
as <constant>VIDIOC_ENUMAUDIO</constant> and
@ -408,11 +336,11 @@ applications call the &VIDIOC-S-AUDIO; ioctl. To select an audio
output (which presently has no changeable properties) applications
call the &VIDIOC-S-AUDOUT; ioctl.</para>
<para>Drivers must implement all input ioctls when the device
has one or more inputs, all output ioctls when the device has one
or more outputs. When the device has any audio inputs or outputs the
driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the
&v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para>
<para>Drivers must implement all audio input ioctls when the device
has multiple selectable audio inputs, all audio output ioctls when the
device has multiple selectable audio outputs. When the device has any
audio inputs or outputs the driver must set the <constant>V4L2_CAP_AUDIO</constant>
flag in the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para>
<example>
<title>Information about the current audio input</title>
@ -420,14 +348,14 @@ driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the
<programlisting>
&v4l2-audio; audio;
memset (&amp;audio, 0, sizeof (audio));
memset(&amp;audio, 0, sizeof(audio));
if (-1 == ioctl (fd, &VIDIOC-G-AUDIO;, &amp;audio)) {
perror ("VIDIOC_G_AUDIO");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-G-AUDIO;, &amp;audio)) {
perror("VIDIOC_G_AUDIO");
exit(EXIT_FAILURE);
}
printf ("Current input: %s\n", audio.name);
printf("Current input: %s\n", audio.name);
</programlisting>
</example>
@ -437,13 +365,13 @@ printf ("Current input: %s\n", audio.name);
<programlisting>
&v4l2-audio; audio;
memset (&amp;audio, 0, sizeof (audio)); /* clear audio.mode, audio.reserved */
memset(&amp;audio, 0, sizeof(audio)); /* clear audio.mode, audio.reserved */
audio.index = 0;
if (-1 == ioctl (fd, &VIDIOC-S-AUDIO;, &amp;audio)) {
perror ("VIDIOC_S_AUDIO");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-S-AUDIO;, &amp;audio)) {
perror("VIDIOC_S_AUDIO");
exit(EXIT_FAILURE);
}
</programlisting>
</example>
@ -468,7 +396,7 @@ the tuner.</para>
video inputs.</para>
<para>To query and change tuner properties applications use the
&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The
&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctls, respectively. The
&v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also
contains signal status information applicable when the tuner of the
current video or radio input is queried. Note that
@ -533,7 +461,7 @@ standards or variations of standards. Each video input and output may
support another set of standards. This set is reported by the
<structfield>std</structfield> field of &v4l2-input; and
&v4l2-output; returned by the &VIDIOC-ENUMINPUT; and
&VIDIOC-ENUMOUTPUT; ioctl, respectively.</para>
&VIDIOC-ENUMOUTPUT; ioctls, respectively.</para>
<para>V4L2 defines one bit for each analog video standard
currently in use worldwide, and sets aside bits for driver defined
@ -564,28 +492,10 @@ automatically.</para>
<para>To query and select the standard used by the current video
input or output applications call the &VIDIOC-G-STD; and
&VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis>
standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote>
<para>An alternative to the current scheme is to use pointers
to indices as arguments of <constant>VIDIOC_G_STD</constant> and
<constant>VIDIOC_S_STD</constant>, the &v4l2-input; and
&v4l2-output; <structfield>std</structfield> field would be a set of
indices like <structfield>audioset</structfield>.</para>
<para>Indices are consistent with the rest of the API
and identify the standard unambiguously. In the present scheme of
things an enumerated standard is looked up by &v4l2-std-id;. Now the
standards supported by the inputs of a device can overlap. Just
assume the tuner and composite input in the example above both
exist on a device. An enumeration of "PAL-B/G", "PAL-H/I" suggests
a choice which does not exist. We cannot merge or omit sets, because
applications would be unable to find the standards reported by
<constant>VIDIOC_G_STD</constant>. That leaves separate enumerations
for each input. Also selecting a standard by &v4l2-std-id; can be
ambiguous. Advantage of this method is that applications need not
identify the standard indirectly, after enumerating.</para><para>So in
summary, the lookup itself is unavoidable. The difference is only
whether the lookup is necessary to find an enumerated standard or to
switch to a standard by &v4l2-std-id;.</para>
</footnote> Drivers must implement all video standard ioctls
standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the
parameter of all these ioctls is a pointer to a &v4l2-std-id; type
(a standard set), <emphasis>not</emphasis> an index into the standard
enumeration. Drivers must implement all video standard ioctls
when the device has one or more video inputs or outputs.</para>
<para>Special rules apply to devices such as USB cameras where the notion of video
@ -604,17 +514,10 @@ to zero and the <constant>VIDIOC_G_STD</constant>,
<constant>VIDIOC_S_STD</constant>,
<constant>VIDIOC_QUERYSTD</constant> and
<constant>VIDIOC_ENUMSTD</constant> ioctls shall return the
&ENOTTY;.<footnote>
<para>See <xref linkend="buffer" /> for a rationale.</para>
&ENOTTY; or the &EINVAL;.</para>
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
are available for the device.</para>
<para>See <xref linkend="buffer" /> for a rationale. Probably
even USB cameras follow some well known video standard. It might have
been better to explicitly indicate elsewhere if a device cannot live
up to normal expectations, instead of this exception.</para>
</footnote></para>
can be used with the given input or output.</para>
<example>
<title>Information about the current video standard</title>
@ -623,22 +526,22 @@ up to normal expectations, instead of this exception.</para>
&v4l2-std-id; std_id;
&v4l2-standard; standard;
if (-1 == ioctl (fd, &VIDIOC-G-STD;, &amp;std_id)) {
if (-1 == ioctl(fd, &VIDIOC-G-STD;, &amp;std_id)) {
/* Note when VIDIOC_ENUMSTD always returns ENOTTY this
is no video device or it falls under the USB exception,
and VIDIOC_G_STD returning ENOTTY is no error. */
perror ("VIDIOC_G_STD");
exit (EXIT_FAILURE);
perror("VIDIOC_G_STD");
exit(EXIT_FAILURE);
}
memset (&amp;standard, 0, sizeof (standard));
memset(&amp;standard, 0, sizeof(standard));
standard.index = 0;
while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
if (standard.id &amp; std_id) {
printf ("Current video standard: %s\n", standard.name);
exit (EXIT_SUCCESS);
printf("Current video standard: %s\n", standard.name);
exit(EXIT_SUCCESS);
}
standard.index++;
@ -648,8 +551,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
empty unless this device falls under the USB exception. */
if (errno == EINVAL || standard.index == 0) {
perror ("VIDIOC_ENUMSTD");
exit (EXIT_FAILURE);
perror("VIDIOC_ENUMSTD");
exit(EXIT_FAILURE);
}
</programlisting>
</example>
@ -662,26 +565,26 @@ input</title>
&v4l2-input; input;
&v4l2-standard; standard;
memset (&amp;input, 0, sizeof (input));
memset(&amp;input, 0, sizeof(input));
if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &amp;input.index)) {
perror ("VIDIOC_G_INPUT");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &amp;input.index)) {
perror("VIDIOC_G_INPUT");
exit(EXIT_FAILURE);
}
if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
perror ("VIDIOC_ENUM_INPUT");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
perror("VIDIOC_ENUM_INPUT");
exit(EXIT_FAILURE);
}
printf ("Current input %s supports:\n", input.name);
printf("Current input %s supports:\n", input.name);
memset (&amp;standard, 0, sizeof (standard));
memset(&amp;standard, 0, sizeof(standard));
standard.index = 0;
while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
if (standard.id &amp; input.std)
printf ("%s\n", standard.name);
printf("%s\n", standard.name);
standard.index++;
}
@ -690,8 +593,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
empty unless this device falls under the USB exception. */
if (errno != EINVAL || standard.index == 0) {
perror ("VIDIOC_ENUMSTD");
exit (EXIT_FAILURE);
perror("VIDIOC_ENUMSTD");
exit(EXIT_FAILURE);
}
</programlisting>
</example>
@ -703,21 +606,21 @@ if (errno != EINVAL || standard.index == 0) {
&v4l2-input; input;
&v4l2-std-id; std_id;
memset (&amp;input, 0, sizeof (input));
memset(&amp;input, 0, sizeof(input));
if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &amp;input.index)) {
perror ("VIDIOC_G_INPUT");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &amp;input.index)) {
perror("VIDIOC_G_INPUT");
exit(EXIT_FAILURE);
}
if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
perror ("VIDIOC_ENUM_INPUT");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
perror("VIDIOC_ENUM_INPUT");
exit(EXIT_FAILURE);
}
if (0 == (input.std &amp; V4L2_STD_PAL_BG)) {
fprintf (stderr, "Oops. B/G PAL is not supported.\n");
exit (EXIT_FAILURE);
fprintf(stderr, "Oops. B/G PAL is not supported.\n");
exit(EXIT_FAILURE);
}
/* Note this is also supposed to work when only B
@ -725,9 +628,9 @@ if (0 == (input.std &amp; V4L2_STD_PAL_BG)) {
std_id = V4L2_STD_PAL_BG;
if (-1 == ioctl (fd, &VIDIOC-S-STD;, &amp;std_id)) {
perror ("VIDIOC_S_STD");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, &VIDIOC-S-STD;, &amp;std_id)) {
perror("VIDIOC_S_STD");
exit(EXIT_FAILURE);
}
</programlisting>
</example>
@ -740,26 +643,25 @@ corresponding video timings. Today there are many more different hardware interf
such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry
video signals and there is a need to extend the API to select the video timings
for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to
the limited bits available, a new set of IOCTLs was added to set/get video timings at
the input and output: </para><itemizedlist>
<listitem>
<para>DV Timings: This will allow applications to define detailed
video timings for the interface. This includes parameters such as width, height,
polarities, frontporch, backporch etc. The <filename>linux/v4l2-dv-timings.h</filename>
the limited bits available, a new set of ioctls was added to set/get video timings at
the input and output.</para>
<para>These ioctls deal with the detailed digital video timings that define
each video format. This includes parameters such as the active video width and height,
signal polarities, frontporches, backporches, sync widths etc. The <filename>linux/v4l2-dv-timings.h</filename>
header can be used to get the timings of the formats in the <xref linkend="cea861" /> and
<xref linkend="vesadmt" /> standards.
</para>
</listitem>
</itemizedlist>
<para>To enumerate and query the attributes of the DV timings supported by a device,
<para>To enumerate and query the attributes of the DV timings supported by a device
applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls.
To set DV timings for the device, applications use the
To set DV timings for the device applications use the
&VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the
&VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications
use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para>
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the
video timings for the device.</para>
<xref linkend="output-capabilities"/> flags to determine whether the digital video ioctls
can be used with the given input or output.</para>
</section>
&sub-controls;

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

@ -397,7 +397,7 @@ linkend="control" />.</para>
<para>The <structfield>depth</structfield> (average number of
bits per pixel) of a video image is implied by the selected image
format. V4L2 does not explicitely provide such information assuming
format. V4L2 does not explicitly provide such information assuming
applications recognizing the format are aware of the image depth and
others need not know. The <structfield>palette</structfield> field
moved into the &v4l2-pix-format;:<informaltable>
@ -2535,6 +2535,16 @@ fields changed from _s32 to _u32.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.15</title>
<orderedlist>
<listitem>
<para>Added Software Defined Radio (SDR) Interface.
</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
@ -2651,6 +2661,9 @@ ioctls.</para>
<listitem>
<para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para>
</listitem>
<listitem>
<para>Software Defined Radio (SDR) Interface, <xref linkend="sdr" />.</para>
</listitem>
</itemizedlist>
</section>

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

@ -2256,6 +2256,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
<entry>integer</entry>
</row><row><entry spanname="descr">Sets the initial delay in milliseconds for
VBV buffer control.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-hor-search-range">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels
to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
horizontal search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-vert-search-range">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels
to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
vertical search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
@ -4370,6 +4390,24 @@ interface and may change in the future.</para>
<entry>The flash controller has detected a short or open
circuit condition on the indicator LED.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_UNDER_VOLTAGE</constant></entry>
<entry>Flash controller voltage to the flash LED
has been below the minimum limit specific to the flash
controller.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_INPUT_VOLTAGE</constant></entry>
<entry>The input voltage of the flash controller is below
the limit under which strobing the flash at full current
will not be possible.The condition persists until this flag
is no longer set.</entry>
</row>
<row>
<entry><constant>V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE</constant></entry>
<entry>The temperature of the LED has exceeded its
allowed upper limit.</entry>
</row>
</tbody>
</entrytbl>
</row>
@ -4971,4 +5009,142 @@ defines possible values for de-emphasis. Here they are:</entry>
</table>
</section>
<section id="rf-tuner-controls">
<title>RF Tuner Control Reference</title>
<para>
The RF Tuner (RF_TUNER) class includes controls for common features of devices
having RF tuner.
</para>
<para>
In this context, RF tuner is radio receiver circuit between antenna and
demodulator. It receives radio frequency (RF) from the antenna and converts that
received signal to lower intermediate frequency (IF) or baseband frequency (BB).
Tuners that could do baseband output are often called Zero-IF tuners. Older
tuners were typically simple PLL tuners inside a metal box, whilst newer ones
are highly integrated chips without a metal box "silicon tuners". These controls
are mostly applicable for new feature rich silicon tuners, just because older
tuners does not have much adjustable features.
</para>
<para>
For more information about RF tuners see
<ulink url="http://en.wikipedia.org/wiki/Tuner_%28radio%29">Tuner (radio)</ulink>
and
<ulink url="http://en.wikipedia.org/wiki/RF_front_end">RF front end</ulink>
from Wikipedia.
</para>
<table pgwide="1" frame="none" id="rf-tuner-control-id">
<title>RF_TUNER Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />
<colspec colname="c2" colwidth="6*" />
<colspec colname="c3" colwidth="2*" />
<colspec colname="c4" colwidth="6*" />
<spanspec namest="c1" nameend="c2" spanname="id" />
<spanspec namest="c2" nameend="c4" spanname="descr" />
<thead>
<row>
<entry spanname="id" align="left">ID</entry>
<entry align="left">Type</entry>
</row>
<row rowsep="1">
<entry spanname="descr" align="left">Description</entry>
</row>
</thead>
<tbody valign="top">
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_CLASS</constant>&nbsp;</entry>
<entry>class</entry>
</row><row><entry spanname="descr">The RF_TUNER class
descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
description of this control class.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH_AUTO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Enables/disables tuner radio channel
bandwidth configuration. In automatic mode bandwidth configuration is performed
by the driver.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Filter(s) on tuner signal path are used to
filter signal according to receiving party needs. Driver configures filters to
fulfill desired bandwidth requirement. Used when V4L2_CID_RF_TUNER_BANDWIDTH_AUTO is not
set. Unit is in Hz. The range and step are driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Enables/disables LNA automatic gain control (AGC)</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Enables/disables mixer automatic gain control (AGC)</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Enables/disables IF automatic gain control (AGC)</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">LNA (low noise amplifier) gain is first
gain stage on the RF tuner signal path. It is located very close to tuner
antenna input. Used when <constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> is not set.
The range and step are driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">Mixer gain is second gain stage on the RF
tuner signal path. It is located inside mixer block, where RF signal is
down-converted by the mixer. Used when <constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant>
is not set. The range and step are driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">IF gain is last gain stage on the RF tuner
signal path. It is located on output of RF tuner. It controls signal level of
intermediate frequency output or baseband output. Used when
<constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> is not set. The range and step are
driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_PLL_LOCK</constant>&nbsp;</entry>
<entry>boolean</entry>
</row>
<row>
<entry spanname="descr">Is synthesizer PLL locked? RF tuner is
receiving given frequency when that control is set. This is a read-only control.
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</section>

22
Documentation/DocBook/media/v4l/dev-osd.xml
View File

@ -56,18 +56,18 @@ framebuffer device.</para>
unsigned int i;
int fb_fd;
if (-1 == ioctl (fd, VIDIOC_G_FBUF, &amp;fbuf)) {
perror ("VIDIOC_G_FBUF");
exit (EXIT_FAILURE);
if (-1 == ioctl(fd, VIDIOC_G_FBUF, &amp;fbuf)) {
perror("VIDIOC_G_FBUF");
exit(EXIT_FAILURE);
}
for (i = 0; i &gt; 30; ++i) {
for (i = 0; i &lt; 30; i++) {
char dev_name[16];
struct fb_fix_screeninfo si;
snprintf (dev_name, sizeof (dev_name), "/dev/fb%u", i);
snprintf(dev_name, sizeof(dev_name), "/dev/fb%u", i);
fb_fd = open (dev_name, O_RDWR);
fb_fd = open(dev_name, O_RDWR);
if (-1 == fb_fd) {
switch (errno) {
case ENOENT: /* no such file */
@ -75,19 +75,19 @@ for (i = 0; i &gt; 30; ++i) {
continue;
default:
perror ("open");
exit (EXIT_FAILURE);
perror("open");
exit(EXIT_FAILURE);
}
}
if (0 == ioctl (fb_fd, FBIOGET_FSCREENINFO, &amp;si)) {
if (si.smem_start == (unsigned long) fbuf.base)
if (0 == ioctl(fb_fd, FBIOGET_FSCREENINFO, &amp;si)) {
if (si.smem_start == (unsigned long)fbuf.base)
break;
} else {
/* Apparently not a framebuffer device. */
}
close (fb_fd);
close(fb_fd);
fb_fd = -1;
}

110
Documentation/DocBook/media/v4l/dev-sdr.xml Normal file
View File

@ -0,0 +1,110 @@
<title>Software Defined Radio Interface (SDR)</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>
SDR is an abbreviation of Software Defined Radio, the radio device
which uses application software for modulation or demodulation. This interface
is intended for controlling and data streaming of such devices.
</para>
<para>
SDR devices are accessed through character device special files named
<filename>/dev/swradio0</filename> to <filename>/dev/swradio255</filename>
with major number 81 and dynamically allocated minor numbers 0 to 255.
</para>
<section>
<title>Querying Capabilities</title>
<para>
Devices supporting the SDR receiver interface set the
<constant>V4L2_CAP_SDR_CAPTURE</constant> and
<constant>V4L2_CAP_TUNER</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an
Analog to Digital Converter (ADC), which is a mandatory element for the SDR receiver.
At least one of the read/write, streaming or asynchronous I/O methods must
be supported.
</para>
</section>
<section>
<title>Supplemental Functions</title>
<para>
SDR devices can support <link linkend="control">controls</link>, and must
support the <link linkend="tuner">tuner</link> ioctls. Tuner ioctls are used
for setting the ADC sampling rate (sampling frequency) and the possible RF tuner
frequency.
</para>
<para>
The <constant>V4L2_TUNER_ADC</constant> tuner type is used for ADC tuners, and
the <constant>V4L2_TUNER_RF</constant> tuner type is used for RF tuners. The
tuner index of the RF tuner (if any) must always follow the ADC tuner index.
Normally the ADC tuner is #0 and the RF tuner is #1.
</para>
<para>
The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported.
</para>
</section>
<section>
<title>Data Format Negotiation</title>
<para>
The SDR capture device uses the <link linkend="format">format</link> ioctls to
select the capture format. Both the sampling resolution and the data streaming
format are bound to that selectable format. In addition to the basic
<link linkend="format">format</link> ioctls, the &VIDIOC-ENUM-FMT; ioctl
must be supported as well.
</para>
<para>
To use the <link linkend="format">format</link> ioctls applications set the
<structfield>type</structfield> field of a &v4l2-format; to
<constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format;
<structfield>sdr</structfield> member of the <structfield>fmt</structfield>
union as needed per the desired operation.
Currently only the <structfield>pixelformat</structfield> field of
&v4l2-sdr-format; is used. The content of that field is the V4L2 fourcc code
of the data format.
</para>
<table pgwide="1" frame="none" id="v4l2-sdr-format">
<title>struct <structname>v4l2_sdr_format</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>pixelformat</structfield></entry>
<entry>
The data format or type of compression, set by the application. This is a
little endian <link linkend="v4l2-fourcc">four character code</link>.
V4L2 defines SDR formats in <xref linkend="sdr-formats" />.
</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>reserved[28]</structfield></entry>
<entry>This array is reserved for future extensions.
Drivers and applications must set it to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
An SDR device may support <link linkend="rw">read/write</link>
and/or streaming (<link linkend="mmap">memory mapping</link>
or <link linkend="userp">user pointer</link>) I/O.
</para>
</section>

189
Documentation/DocBook/media/v4l/io.xml
View File

@ -339,8 +339,8 @@ returns immediately with an &EAGAIN; when no buffer is available. The
queues as a side effect. Since there is no notion of doing anything
"now" on a multitasking system, if an application needs to synchronize
with another event it should examine the &v4l2-buffer;
<structfield>timestamp</structfield> of captured buffers, or set the
field before enqueuing buffers for output.</para>
<structfield>timestamp</structfield> of captured or outputted buffers.
</para>
<para>Drivers implementing memory mapping I/O must
support the <constant>VIDIOC_REQBUFS</constant>,
@ -457,7 +457,7 @@ queues and unlocks all buffers as a side effect. Since there is no
notion of doing anything "now" on a multitasking system, if an
application needs to synchronize with another event it should examine
the &v4l2-buffer; <structfield>timestamp</structfield> of captured
buffers, or set the field before enqueuing buffers for output.</para>
or outputted buffers.</para>
<para>Drivers implementing user pointer I/O must
support the <constant>VIDIOC_REQBUFS</constant>,
@ -620,8 +620,7 @@ returns immediately with an &EAGAIN; when no buffer is available. The
unlocks all buffers as a side effect. Since there is no notion of doing
anything "now" on a multitasking system, if an application needs to synchronize
with another event it should examine the &v4l2-buffer;
<structfield>timestamp</structfield> of captured buffers, or set the field
before enqueuing buffers for output.</para>
<structfield>timestamp</structfield> of captured or outputted buffers.</para>
<para>Drivers implementing DMABUF importing I/O must support the
<constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>,
@ -654,38 +653,19 @@ plane, are stored in struct <structname>v4l2_plane</structname> instead.
In that case, struct <structname>v4l2_buffer</structname> contains an array of
plane structures.</para>
<para>Nominally timestamps refer to the first data byte transmitted.
In practice however the wide range of hardware covered by the V4L2 API
limits timestamp accuracy. Often an interrupt routine will
sample the system clock shortly after the field or frame was stored
completely in memory. So applications must expect a constant
difference up to one field or frame period plus a small (few scan
lines) random error. The delay and error can be much
larger due to compression or transmission over an external bus when
the frames are not properly stamped by the sender. This is frequently
the case with USB cameras. Here timestamps refer to the instant the
field or frame was received by the driver, not the capture time. These
devices identify by not enumerating any video standards, see <xref
linkend="standard" />.</para>
<para>Similar limitations apply to output timestamps. Typically
the video hardware locks to a clock controlling the video timing, the
horizontal and vertical synchronization pulses. At some point in the
line sequence, possibly the vertical blanking, an interrupt routine
samples the system clock, compares against the timestamp and programs
the hardware to repeat the previous field or frame, or to display the
buffer contents.</para>
<para>Apart of limitations of the video device and natural
inaccuracies of all clocks, it should be noted system time itself is
not perfectly stable. It can be affected by power saving cycles,
warped to insert leap seconds, or even turned back or forth by the
system administrator affecting long term measurements. <footnote>
<para>Since no other Linux multimedia
API supports unadjusted time it would be foolish to introduce here. We
must use a universally supported clock to synchronize different media,
hence time of day.</para>
</footnote></para>
<para>Dequeued video buffers come with timestamps. The driver
decides at which part of the frame and with which clock the
timestamp is taken. Please see flags in the masks
<constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant> and
<constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> in <xref
linkend="buffer-flags" />. These flags are always valid and constant
across all buffers during the whole video stream. Changes in these
flags may take place as a side effect of &VIDIOC-S-INPUT; or
&VIDIOC-S-OUTPUT; however. The
<constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> timestamp type
which is used by e.g. on mem-to-mem devices is an exception to the
rule: the timestamp source flags are copied from the OUTPUT video
buffer to the CAPTURE video buffer.</para>
<table frame="none" pgwide="1" id="v4l2-buffer">
<title>struct <structname>v4l2_buffer</structname></title>
@ -696,10 +676,11 @@ hence time of day.</para>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry></entry>
<entry>Number of the buffer, set by the application. This
field is only used for <link linkend="mmap">memory mapping</link> I/O
and can range from zero to the number of buffers allocated
with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry>
<entry>Number of the buffer, set by the application except
when calling &VIDIOC-DQBUF;, then it is set by the driver.
This field can range from zero to the number of buffers allocated
with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>),
plus any buffers allocated with &VIDIOC-CREATE-BUFS; minus one.</entry>
</row>
<row>
<entry>__u32</entry>
@ -718,7 +699,7 @@ linkend="v4l2-buf-type" /></entry>
buffer. It depends on the negotiated data format and may change with
each buffer for compressed variable size data like JPEG images.
Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when an output stream.</entry>
refers to an input stream, applications when it refers to an output stream.</entry>
</row>
<row>
<entry>__u32</entry>
@ -735,7 +716,7 @@ linkend="buffer-flags" />.</entry>
buffer, see <xref linkend="v4l2-field" />. This field is not used when
the buffer contains VBI data. Drivers must set it when
<structfield>type</structfield> refers to an input stream,
applications when an output stream.</entry>
applications when it refers to an output stream.</entry>
</row>
<row>
<entry>struct timeval</entry>
@ -745,15 +726,13 @@ applications when an output stream.</entry>
byte was captured, as returned by the
<function>clock_gettime()</function> function for the relevant
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
<xref linkend="buffer-flags" />. For output streams the data
will not be displayed before this time, secondary to the nominal
frame rate determined by the current video standard in enqueued
order. Applications can for example zero this field to display
frames as soon as possible. The driver stores the time at which
the first data byte was actually sent out in the
<structfield>timestamp</structfield> field. This permits
<xref linkend="buffer-flags" />. For output streams the driver
stores the time at which the last data byte was actually sent out
in the <structfield>timestamp</structfield> field. This permits
applications to monitor the drift between the video and system
clock.</para></entry>
clock. For output streams that use <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant>
the application has to fill in the timestamp which will be copied
by the driver to the capture stream.</para></entry>
</row>
<row>
<entry>&v4l2-timecode;</entry>
@ -846,7 +825,8 @@ is the file descriptor associated with a DMABUF buffer.</entry>
<entry><structfield>length</structfield></entry>
<entry></entry>
<entry>Size of the buffer (not the payload) in bytes for the
single-planar API. For the multi-planar API the application sets
single-planar API. This is set by the driver based on the calls to
&VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;. For the multi-planar API the application sets
this to the number of elements in the <structfield>planes</structfield>
array. The driver will fill in the actual number of valid elements in
that array.
@ -880,13 +860,15 @@ should set this to 0.</entry>
<entry><structfield>bytesused</structfield></entry>
<entry></entry>
<entry>The number of bytes occupied by data in the plane
(its payload).</entry>
(its payload). Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when it refers to an output stream.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>length</structfield></entry>
<entry></entry>
<entry>Size in bytes of the plane (not its payload).</entry>
<entry>Size in bytes of the plane (not its payload). This is set by the driver
based on the calls to &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;.</entry>
</row>
<row>
<entry>union</entry>
@ -925,7 +907,9 @@ should set this to 0.</entry>
<entry>__u32</entry>
<entry><structfield>data_offset</structfield></entry>
<entry></entry>
<entry>Offset in bytes to video data in the plane, if applicable.
<entry>Offset in bytes to video data in the plane.
Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when it refers to an output stream.
</entry>
</row>
<row>
@ -1005,6 +989,12 @@ should set this to 0.</entry>
<entry>Buffer for video output overlay (OSD), see <xref
linkend="osd" />.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant></entry>
<entry>11</entry>
<entry>Buffer for Software Defined Radio (SDR), see <xref
linkend="sdr" />.</entry>
</row>
</tbody>
</tgroup>
</table>
@ -1016,7 +1006,7 @@ should set this to 0.</entry>
<tbody valign="top">
<row>
<entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry>
<entry>0x0001</entry>
<entry>0x00000001</entry>
<entry>The buffer resides in device memory and has been mapped
into the application's address space, see <xref linkend="mmap" /> for details.
Drivers set or clear this flag when the
@ -1026,7 +1016,7 @@ Drivers set or clear this flag when the
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_QUEUED</constant></entry>
<entry>0x0002</entry>
<entry>0x00000002</entry>
<entry>Internally drivers maintain two buffer queues, an
incoming and outgoing queue. When this flag is set, the buffer is
currently on the incoming queue. It automatically moves to the
@ -1039,7 +1029,7 @@ cleared.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_DONE</constant></entry>
<entry>0x0004</entry>
<entry>0x00000004</entry>
<entry>When this flag is set, the buffer is currently on
the outgoing queue, ready to be dequeued from the driver. Drivers set
or clear this flag when the <constant>VIDIOC_QUERYBUF</constant> ioctl
@ -1049,11 +1039,11 @@ buffer cannot be on both queues at the same time, the
<constant>V4L2_BUF_FLAG_QUEUED</constant> and
<constant>V4L2_BUF_FLAG_DONE</constant> flag are mutually exclusive.
They can be both cleared however, then the buffer is in "dequeued"
state, in the application domain to say so.</entry>
state, in the application domain so to say.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_ERROR</constant></entry>
<entry>0x0040</entry>
<entry>0x00000040</entry>
<entry>When this flag is set, the buffer has been dequeued
successfully, although the data might have been corrupted.
This is recoverable, streaming may continue as normal and
@ -1063,35 +1053,43 @@ state, in the application domain to say so.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_KEYFRAME</constant></entry>
<entry>0x0008</entry>
<entry>0x00000008</entry>
<entry>Drivers set or clear this flag when calling the
<constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video
capture devices when the buffer contains a compressed image which is a
key frame (or field), &ie; can be decompressed on its own.</entry>
key frame (or field), &ie; can be decompressed on its own. Also know as
an I-frame. Applications can set this bit when <structfield>type</structfield>
refers to an output stream.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_PFRAME</constant></entry>
<entry>0x0010</entry>
<entry>0x00000010</entry>
<entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant>
this flags predicted frames or fields which contain only differences to a
previous key frame.</entry>
previous key frame. Applications can set this bit when <structfield>type</structfield>
refers to an output stream.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_BFRAME</constant></entry>
<entry>0x0020</entry>
<entry>Similar to <constant>V4L2_BUF_FLAG_PFRAME</constant>
this is a bidirectional predicted frame or field. [ooc tbd]</entry>
<entry>0x00000020</entry>
<entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant>
this flags a bi-directional predicted frame or field which contains only
the differences between the current frame and both the preceding and following
key frames to specify its content. Applications can set this bit when
<structfield>type</structfield> refers to an output stream.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMECODE</constant></entry>
<entry>0x0100</entry>
<entry>0x00000100</entry>
<entry>The <structfield>timecode</structfield> field is valid.
Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant>
ioctl is called.</entry>
ioctl is called. Applications can set this bit and the corresponding
<structfield>timecode</structfield> structure when <structfield>type</structfield>
refers to an output stream.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>
<entry>0x0400</entry>
<entry>0x00000400</entry>
<entry>The buffer has been prepared for I/O and can be queued by the
application. Drivers set or clear this flag when the
<link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
@ -1101,7 +1099,7 @@ application. Drivers set or clear this flag when the
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
<entry>0x0800</entry>
<entry>0x00000800</entry>
<entry>Caches do not have to be invalidated for this buffer.
Typically applications shall use this flag if the data captured in the buffer
is not going to be touched by the CPU, instead the buffer will, probably, be
@ -1110,7 +1108,7 @@ passed on to a DMA-capable hardware unit for further processing or output.
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
<entry>0x1000</entry>
<entry>0x00001000</entry>
<entry>Caches do not have to be cleaned for this buffer.
Typically applications shall use this flag for output buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
@ -1118,7 +1116,7 @@ in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
<entry>0xe000</entry>
<entry>0x0000e000</entry>
<entry>Mask for timestamp types below. To test the
timestamp type, mask out bits not belonging to timestamp
type by performing a logical and operation with buffer
@ -1126,7 +1124,7 @@ in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
<entry>0x0000</entry>
<entry>0x00000000</entry>
<entry>Unknown timestamp type. This type is used by
drivers before Linux 3.9 and may be either monotonic (see
below) or realtime (wall clock). Monotonic clock has been
@ -1139,7 +1137,7 @@ in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
<entry>0x2000</entry>
<entry>0x00002000</entry>
<entry>The buffer timestamp has been taken from the
<constant>CLOCK_MONOTONIC</constant> clock. To access the
same clock outside V4L2, use
@ -1147,10 +1145,42 @@ in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry>
<entry>0x4000</entry>
<entry>0x00004000</entry>
<entry>The CAPTURE buffer timestamp has been taken from the
corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry>
<entry>0x00070000</entry>
<entry>Mask for timestamp sources below. The timestamp source
defines the point of time the timestamp is taken in relation to
the frame. Logical 'and' operation between the
<structfield>flags</structfield> field and
<constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the
value of the timestamp source. Applications must set the timestamp
source when <structfield>type</structfield> refers to an output stream
and <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> is set.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry>
<entry>0x00000000</entry>
<entry>End Of Frame. The buffer timestamp has been taken
when the last pixel of the frame has been received or the
last pixel of the frame has been transmitted. In practice,
software generated timestamps will typically be read from
the clock a small amount of time after the last pixel has
been received or transmitten, depending on the system and
other activity in it.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry>
<entry>0x00010000</entry>
<entry>Start Of Exposure. The buffer timestamp has been
taken when the exposure of the frame has begun. This is
only valid for the
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> buffer
type.</entry>
</row>
</tbody>
</tgroup>
</table>
@ -1440,10 +1470,9 @@ or application, depending on data direction, must set &v4l2-buffer;
<constant>V4L2_FIELD_BOTTOM</constant>. Any two successive fields pair
to build a frame. If fields are successive, without any dropped fields
between them (fields can drop individually), can be determined from
the &v4l2-buffer; <structfield>sequence</structfield> field. Image
sizes refer to the frame, not fields. This format cannot be selected
when using the read/write I/O method.<!-- Where it's indistinguishable
from V4L2_FIELD_SEQ_*. --></entry>
the &v4l2-buffer; <structfield>sequence</structfield> field. This format
cannot be selected when using the read/write I/O method since there
is no way to communicate if a field was a top or bottom field.</entry>
</row>
<row>
<entry><constant>V4L2_FIELD_INTERLACED_TB</constant></entry>

9
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
View File

@ -12,18 +12,17 @@
<refsect1>
<title>Description</title>
<para>This is a multi-planar, two-plane version of the YUV 4:2:0 format.
<para>This is a multi-planar, two-plane version of the YUV 4:2:2 format.
The three components are separated into two sub-images or planes.
<constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16
</constant> in that the two planes are non-contiguous in memory, i.e. the chroma
plane does not necessarily immediately follows the luma plane.
plane does not necessarily immediately follow the luma plane.
The luminance data occupies the first plane. The Y plane has one byte per pixel.
In the second plane there is chrominance data with alternating chroma samples.
The CbCr plane is the same width and height, in bytes, as the Y plane.
Each CbCr pair belongs to four pixels. For example,
Each CbCr pair belongs to two pixels. For example,
Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>.
<constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant>
except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para>

513
Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
View File

@ -121,14 +121,14 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry><constant>V4L2_PIX_FMT_RGB332</constant></entry>
<entry>'RGB1'</entry>
<entry></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-RGB444">
<entry><constant>V4L2_PIX_FMT_RGB444</constant></entry>
@ -159,18 +159,18 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></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></entry>
<entry>a</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>
<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>
</row>
@ -181,17 +181,17 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></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></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>
<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>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
@ -201,32 +201,32 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>'RGBQ'</entry>
<entry></entry>
<entry>a</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>
<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>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>
</row>
<row id="V4L2-PIX-FMT-RGB565X">
<entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry>
<entry>'RGBR'</entry>
<entry></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>
<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>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
@ -234,11 +234,11 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></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>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-BGR666">
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
@ -385,6 +385,15 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry><constant>V4L2_PIX_FMT_RGB32</constant></entry>
<entry>'RGB4'</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry>
<entry>a<subscript>5</subscript></entry>
<entry>a<subscript>4</subscript></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
@ -411,25 +420,16 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry>
<entry>a<subscript>5</subscript></entry>
<entry>a<subscript>4</subscript></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
</row>
</tbody>
</tgroup>
</table>
<para>Bit 7 is the most significant bit. The value of a = alpha
<para>Bit 7 is the most significant bit. The value of the a = alpha
bits is undefined when reading from the driver, ignored when writing
to the driver, except when alpha blending has been negotiated for a
<link linkend="overlay">Video Overlay</link> or <link linkend="osd">
Video Output Overlay</link> or when alpha component has been configured
Video Output Overlay</link> or when the alpha component has been configured
for a <link linkend="capture">Video Capture</link> by means of <link
linkend="v4l2-alpha-component"> <constant>V4L2_CID_ALPHA_COMPONENT
</constant> </link> control.</para>
@ -512,421 +512,6 @@ image</title>
</formalpara>
</example>
<important>
<para>Drivers may interpret these formats differently.</para>
</important>
<para>Some RGB formats above are uncommon and were probably
defined in error. Drivers may interpret them as in <xref
linkend="rgb-formats-corrected" />.</para>
<table pgwide="1" frame="none" id="rgb-formats-corrected">
<title>Packed RGB Image Formats (corrected)</title>
<tgroup cols="37" align="center">
<colspec colname="id" align="left" />
<colspec colname="fourcc" />
<colspec colname="bit" />
<colspec colnum="4" colname="b07" align="center" />
<colspec colnum="5" colname="b06" align="center" />
<colspec colnum="6" colname="b05" align="center" />
<colspec colnum="7" colname="b04" align="center" />
<colspec colnum="8" colname="b03" align="center" />
<colspec colnum="9" colname="b02" align="center" />
<colspec colnum="10" colname="b01" align="center" />
<colspec colnum="11" colname="b00" align="center" />
<colspec colnum="13" colname="b17" align="center" />
<colspec colnum="14" colname="b16" align="center" />
<colspec colnum="15" colname="b15" align="center" />
<colspec colnum="16" colname="b14" align="center" />
<colspec colnum="17" colname="b13" align="center" />
<colspec colnum="18" colname="b12" align="center" />
<colspec colnum="19" colname="b11" align="center" />
<colspec colnum="20" colname="b10" align="center" />
<colspec colnum="22" colname="b27" align="center" />
<colspec colnum="23" colname="b26" align="center" />
<colspec colnum="24" colname="b25" align="center" />
<colspec colnum="25" colname="b24" align="center" />
<colspec colnum="26" colname="b23" align="center" />
<colspec colnum="27" colname="b22" align="center" />
<colspec colnum="28" colname="b21" align="center" />
<colspec colnum="29" colname="b20" align="center" />
<colspec colnum="31" colname="b37" align="center" />
<colspec colnum="32" colname="b36" align="center" />
<colspec colnum="33" colname="b35" align="center" />
<colspec colnum="34" colname="b34" align="center" />
<colspec colnum="35" colname="b33" align="center" />
<colspec colnum="36" colname="b32" align="center" />
<colspec colnum="37" colname="b31" align="center" />
<colspec colnum="38" colname="b30" align="center" />
<spanspec namest="b07" nameend="b00" spanname="b0" />
<spanspec namest="b17" nameend="b10" spanname="b1" />
<spanspec namest="b27" nameend="b20" spanname="b2" />
<spanspec namest="b37" nameend="b30" spanname="b3" />
<thead>
<row>
<entry>Identifier</entry>
<entry>Code</entry>
<entry>&nbsp;</entry>
<entry spanname="b0">Byte&nbsp;0 in memory</entry>
<entry spanname="b1">Byte&nbsp;1</entry>
<entry spanname="b2">Byte&nbsp;2</entry>
<entry spanname="b3">Byte&nbsp;3</entry>
</row>
<row>
<entry>&nbsp;</entry>
<entry>&nbsp;</entry>
<entry>Bit</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
<entry>&nbsp;</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
<entry>&nbsp;</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
<entry>&nbsp;</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
</row>
</thead>
<tbody valign="top">
<row><!-- id="V4L2-PIX-FMT-RGB332" -->
<entry><constant>V4L2_PIX_FMT_RGB332</constant></entry>
<entry>'RGB1'</entry>
<entry></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row><!-- id="V4L2-PIX-FMT-RGB444" -->
<entry><constant>V4L2_PIX_FMT_RGB444</constant></entry>
<entry>'R444'</entry>
<entry></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</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>
<entry></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row><!-- id="V4L2-PIX-FMT-RGB555" -->
<entry><constant>V4L2_PIX_FMT_RGB555</constant></entry>
<entry>'RGBO'</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>
<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>
</row>
<row><!-- id="V4L2-PIX-FMT-RGB565" -->
<entry><constant>V4L2_PIX_FMT_RGB565</constant></entry>
<entry>'RGBP'</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>
<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>5</subscript></entry>
<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-RGB565X" -->
<entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry>
<entry>'RGBR'</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>5</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-BGR666" -->
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
<entry>'BGRH'</entry>
<entry></entry>
<entry>b<subscript>5</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>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row><!-- id="V4L2-PIX-FMT-BGR24" -->
<entry><constant>V4L2_PIX_FMT_BGR24</constant></entry>
<entry>'BGR3'</entry>
<entry></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</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>
<entry></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></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>
</row>
<row><!-- id="V4L2-PIX-FMT-RGB24" -->
<entry><constant>V4L2_PIX_FMT_RGB24</constant></entry>
<entry>'RGB3'</entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></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></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</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>
<entry></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</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>
<entry></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></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></entry>
<entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry>
<entry>a<subscript>5</subscript></entry>
<entry>a<subscript>4</subscript></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
</row>
<row><!-- id="V4L2-PIX-FMT-RGB32" -->
<entry><constant>V4L2_PIX_FMT_RGB32</constant></entry>
<entry>'RGB4'</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry>
<entry>a<subscript>5</subscript></entry>
<entry>a<subscript>4</subscript></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></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></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</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>
</tbody>
</tgroup>
</table>
<para>A test utility to determine which RGB formats a driver
actually supports is available from the LinuxTV v4l-dvb repository.
See &v4l-dvb; for access instructions.</para>

44
Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml Normal file
View File

@ -0,0 +1,44 @@
<refentry id="V4L2-SDR-FMT-CU08">
<refmeta>
<refentrytitle>V4L2_SDR_FMT_CU8 ('CU08')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>
<constant>V4L2_SDR_FMT_CU8</constant>
</refname>
<refpurpose>Complex unsigned 8-bit IQ sample</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>
This format contains sequence of complex number samples. Each complex number
consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
represented as a 8 bit unsigned number. I value comes first and Q value after
that.
</para>
<example>
<title><constant>V4L2_SDR_FMT_CU8</constant> 1 sample</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="2" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>I'<subscript>0</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;1:</entry>
<entry>Q'<subscript>0</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

46
Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml Normal file
View File

@ -0,0 +1,46 @@
<refentry id="V4L2-SDR-FMT-CU16LE">
<refmeta>
<refentrytitle>V4L2_SDR_FMT_CU16LE ('CU16')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>
<constant>V4L2_SDR_FMT_CU16LE</constant>
</refname>
<refpurpose>Complex unsigned 16-bit little endian IQ sample</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>
This format contains sequence of complex number samples. Each complex number
consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
represented as a 16 bit unsigned little endian number. I value comes first
and Q value after that.
</para>
<example>
<title><constant>V4L2_SDR_FMT_CU16LE</constant> 1 sample</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="3" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>I'<subscript>0[7:0]</subscript></entry>
<entry>I'<subscript>0[15:8]</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;2:</entry>
<entry>Q'<subscript>0[7:0]</subscript></entry>
<entry>Q'<subscript>0[15:8]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

34
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@ -25,7 +25,12 @@ capturing and output, for overlay frame buffer formats see also
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Image height in pixels.</entry>
<entry>Image height in pixels. If <structfield>field</structfield> is
one of <constant>V4L2_FIELD_TOP</constant>, <constant>V4L2_FIELD_BOTTOM</constant>
or <constant>V4L2_FIELD_ALTERNATE</constant> then height refers to the
number of lines in the field, otherwise it refers to the number of
lines in the frame (which is twice the field height for interlaced
formats).</entry>
</row>
<row>
<entry spanname="hspan">Applications set these fields to
@ -54,7 +59,7 @@ linkend="reserved-formats" /></entry>
can request to capture or output only the top or bottom field, or both
fields interlaced or sequentially stored in one buffer or alternating
in separate buffers. Drivers return the actual field order selected.
For details see <xref linkend="field-order" />.</entry>
For more details on fields see <xref linkend="field-order" />.</entry>
</row>
<row>
<entry>__u32</entry>
@ -81,7 +86,10 @@ plane and is divided by the same factor as the
example the Cb and Cr planes of a YUV 4:2:0 image have half as many
padding bytes following each line as the Y plane. To avoid ambiguities
drivers must return a <structfield>bytesperline</structfield> value
rounded up to a multiple of the scale factor.</para></entry>
rounded up to a multiple of the scale factor.</para>
<para>For compressed formats the <structfield>bytesperline</structfield>
value makes no sense. Applications and drivers must set this to 0 in
that case.</para></entry>
</row>
<row>
<entry>__u32</entry>
@ -97,7 +105,8 @@ hold an image.</entry>
<entry>&v4l2-colorspace;</entry>
<entry><structfield>colorspace</structfield></entry>
<entry>This information supplements the
<structfield>pixelformat</structfield> and must be set by the driver,
<structfield>pixelformat</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>
@ -135,7 +144,7 @@ set this field to zero.</entry>
<entry>__u16</entry>
<entry><structfield>bytesperline</structfield></entry>
<entry>Distance in bytes between the leftmost pixels in two adjacent
lines.</entry>
lines. See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>__u16</entry>
@ -154,12 +163,12 @@ set this field to zero.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Image width in pixels.</entry>
<entry>Image width in pixels. See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Image height in pixels.</entry>
<entry>Image height in pixels. See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>__u32</entry>
@ -811,6 +820,17 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
</table>
</section>
<section id="sdr-formats">
<title>SDR Formats</title>
<para>These formats are used for <link linkend="sdr">SDR Capture</link>
interface only.</para>
&sub-sdr-cu08;
&sub-sdr-cu16le;
</section>
<section id="pixfmt-reserved">
<title>Reserved Format Identifiers</title>

143
Documentation/DocBook/media/v4l/remote_controllers.xml
View File

@ -1,10 +1,152 @@
<partinfo>
<authorgroup>
<author>
<firstname>Mauro</firstname>
<surname>Chehab</surname>
<othername role="mi">Carvalho</othername>
<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation>
<contrib>Initial version.</contrib>
</author>
</authorgroup>
<copyright>
<year>2009-2014</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>3.15</revnumber>
<date>2014-02-06</date>
<authorinitials>mcc</authorinitials>
<revremark>Added the interface description and the RC sysfs class description.</revremark>
</revision>
<revision>
<revnumber>1.0</revnumber>
<date>2009-09-06</date>
<authorinitials>mcc</authorinitials>
<revremark>Initial revision</revremark>
</revision>
</revhistory>
</partinfo>
<title>Remote Controller API</title>
<chapter id="remote_controllers">
<title>Remote Controllers</title>
<section id="Remote_controllers_Intro">
<title>Introduction</title>
<para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each
manufacturer has their own type of control. It is not rare for the same manufacturer to ship different
types of controls, depending on the device.</para>
<para>A Remote Controller interface is mapped as a normal evdev/input interface, just like a keyboard or a mouse.
So, it uses all ioctls already defined for any other input devices.</para>
<para>However, remove controllers are more flexible than a normal input device, as the IR
receiver (and/or transmitter) can be used in conjunction with a wide variety of different IR remotes.</para>
<para>In order to allow flexibility, the Remote Controller subsystem allows controlling the
RC-specific attributes via <link linkend="remote_controllers_sysfs_nodes">the sysfs class nodes</link>.</para>
</section>
<section id="remote_controllers_sysfs_nodes">
<title>Remote Controller's sysfs nodes</title>
<para>As defined at <constant>Documentation/ABI/testing/sysfs-class-rc</constant>, those are the sysfs nodes that control the Remote Controllers:</para>
<section id="sys_class_rc">
<title>/sys/class/rc/</title>
<para>The <constant>/sys/class/rc/</constant> class sub-directory belongs to the Remote Controller
core and provides a sysfs interface for configuring infrared remote controller receivers.
</para>
</section>
<section id="sys_class_rc_rcN">
<title>/sys/class/rc/rcN/</title>
<para>A <constant>/sys/class/rc/rcN</constant> directory is created for each remote
control receiver device where N is the number of the receiver.</para>
</section>
<section id="sys_class_rc_rcN_protocols">
<title>/sys/class/rc/rcN/protocols</title>
<para>Reading this file returns a list of available protocols, something like:</para>
<para><constant>rc5 [rc6] nec jvc [sony]</constant></para>
<para>Enabled protocols are shown in [] brackets.</para>
<para>Writing "+proto" will add a protocol to the list of enabled protocols.</para>
<para>Writing "-proto" will remove a protocol from the list of enabled protocols.</para>
<para>Writing "proto" will enable only "proto".</para>
<para>Writing "none" will disable all protocols.</para>
<para>Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used.</para>
</section>
<section id="sys_class_rc_rcN_filter">
<title>/sys/class/rc/rcN/filter</title>
<para>Sets the scancode filter expected value.</para>
<para>Use in combination with <constant>/sys/class/rc/rcN/filter_mask</constant> to set the
expected value of the bits set in the filter mask.
If the hardware supports it then scancodes which do not match
the filter will be ignored. Otherwise the write will fail with
an error.</para>
<para>This value may be reset to 0 if the current protocol is altered.</para>
</section>
<section id="sys_class_rc_rcN_filter_mask">
<title>/sys/class/rc/rcN/filter_mask</title>
<para>Sets the scancode filter mask of bits to compare.
Use in combination with <constant>/sys/class/rc/rcN/filter</constant> to set the bits
of the scancode which should be compared against the expected
value. A value of 0 disables the filter to allow all valid
scancodes to be processed.</para>
<para>If the hardware supports it then scancodes which do not match
the filter will be ignored. Otherwise the write will fail with
an error.</para>
<para>This value may be reset to 0 if the current protocol is altered.</para>
</section>
<section id="sys_class_rc_rcN_wakeup_protocols">
<title>/sys/class/rc/rcN/wakeup_protocols</title>
<para>Reading this file returns a list of available protocols to use for the
wakeup filter, something like:</para>
<para><constant>rc5 rc6 nec jvc [sony]</constant></para>
<para>The enabled wakeup protocol is shown in [] brackets.</para>
<para>Writing "+proto" will add a protocol to the list of enabled wakeup
protocols.</para>
<para>Writing "-proto" will remove a protocol from the list of enabled wakeup
protocols.</para>
<para>Writing "proto" will use "proto" for wakeup events.</para>
<para>Writing "none" will disable wakeup.</para>
<para>Write fails with EINVAL if an invalid protocol combination or unknown
protocol name is used, or if wakeup is not supported by the hardware.</para>
</section>
<section id="sys_class_rc_rcN_wakeup_filter">
<title>/sys/class/rc/rcN/wakeup_filter</title>
<para>Sets the scancode wakeup filter expected value.
Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter_mask</constant> to
set the expected value of the bits set in the wakeup filter mask
to trigger a system wake event.</para>
<para>If the hardware supports it and wakeup_filter_mask is not 0 then
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.</para>
<para>This value may be reset to 0 if the wakeup protocol is altered.</para>
</section>
<section id="sys_class_rc_rcN_wakeup_filter_mask">
<title>/sys/class/rc/rcN/wakeup_filter_mask</title>
<para>Sets the scancode wakeup filter mask of bits to compare.
Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter</constant> to set
the bits of the scancode which should be compared against the
expected value to trigger a system wake event.</para>
<para>If the hardware supports it and wakeup_filter_mask is not 0 then
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.</para>
<para>This value may be reset to 0 if the wakeup protocol is altered.</para>
</section>
</section>
<section id="Remote_controllers_tables">
<title>Remote controller tables</title>
<para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for
different devices. This caused the same IR keyname to be mapped completely differently on
different IR devices. This resulted that the same IR keyname to be mapped completely different on
@ -175,3 +317,4 @@ keymapping.</para>
</section>
&sub-lirc_device_interface;
</chapter>

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

@ -70,7 +70,7 @@ MPEG stream embedded, sliced VBI data format in this specification.
Remote Controller chapter.</contrib>
<affiliation>
<address>
<email>mchehab@redhat.com</email>
<email>m.chehab@samsung.com</email>
</address>
</affiliation>
</author>
@ -107,6 +107,16 @@ Remote Controller chapter.</contrib>
</address>
</affiliation>
</author>
<author>
<firstname>Antti</firstname>
<surname>Palosaari</surname>
<contrib>SDR API.</contrib>
<affiliation>
<address>
<email>crope@iki.fi</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
@ -125,6 +135,7 @@ Remote Controller chapter.</contrib>
<year>2011</year>
<year>2012</year>
<year>2013</year>
<year>2014</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
Pawel Osciak</holder>
@ -140,6 +151,16 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.15</revnumber>
<date>2014-02-03</date>
<authorinitials>hv, ap</authorinitials>
<revremark>Update several sections of "Common API Elements": "Opening and Closing Devices"
"Querying Capabilities", "Application Priority", "Video Inputs and Outputs", "Audio Inputs and Outputs"
"Tuners and Modulators", "Video Standards" and "Digital Video (DV) Timings". Added SDR API.
</revremark>
</revision>
<revision>
<revnumber>3.14</revnumber>
<date>2013-11-25</date>
@ -537,6 +558,7 @@ and discussions on the V4L mailing list.</revremark>
<section id="ttx"> &sub-dev-teletext; </section>
<section id="radio"> &sub-dev-radio; </section>
<section id="rds"> &sub-dev-rds; </section>
<section id="sdr"> &sub-dev-sdr; </section>
<section id="event"> &sub-dev-event; </section>
<section id="subdev"> &sub-dev-subdev; </section>
</chapter>
@ -585,6 +607,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-g-crop;
&sub-g-ctrl;
&sub-g-dv-timings;
&sub-g-edid;
&sub-g-enc-index;
&sub-g-ext-ctrls;
&sub-g-fbuf;
@ -616,7 +639,6 @@ and discussions on the V4L mailing list.</revremark>
&sub-subdev-enum-frame-size;
&sub-subdev-enum-mbus-code;
&sub-subdev-g-crop;
&sub-subdev-g-edid;
&sub-subdev-g-fmt;
&sub-subdev-g-frame-interval;
&sub-subdev-g-selection;

8
Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
View File

@ -100,7 +100,7 @@ See <xref linkend="v4l2-tuner-type" /></entry>
<entry><structfield>capability</structfield></entry>
<entry spanname="hspan">The tuner/modulator capability flags for
this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant>
capability must be the same for all frequency bands of the selected tuner/modulator.
or <constant>V4L2_TUNER_CAP_1HZ</constant> capability must be the same for all frequency bands of the selected tuner/modulator.
So either all bands have that capability set, or none of them have that capability.</entry>
</row>
<row>
@ -109,7 +109,8 @@ So either all bands have that capability set, or none of them have that capabili
<entry spanname="hspan">The lowest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz, for this frequency band.</entry>
Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
</row>
<row>
<entry>__u32</entry>
@ -117,7 +118,8 @@ Hz, for this frequency band.</entry>
<entry spanname="hspan">The highest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz, for this frequency band.</entry>
Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
</row>
<row>
<entry>__u32</entry>

36
Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml → Documentation/DocBook/media/v4l/vidioc-g-edid.xml
View File

@ -1,12 +1,12 @@
<refentry id="vidioc-subdev-g-edid">
<refentry id="vidioc-g-edid">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle>
<refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_G_EDID</refname>
<refname>VIDIOC_SUBDEV_S_EDID</refname>
<refname>VIDIOC_G_EDID</refname>
<refname>VIDIOC_S_EDID</refname>
<refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose>
</refnamediv>
@ -16,7 +16,7 @@
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef>
<paramdef>struct v4l2_edid *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<funcsynopsis>
@ -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_subdev_edid *<parameter>argp</parameter></paramdef>
<paramdef>const struct v4l2_edid *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
@ -42,7 +42,7 @@
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para>
<para>VIDIOC_G_EDID, VIDIOC_S_EDID</para>
</listitem>
</varlistentry>
<varlistentry>
@ -56,12 +56,20 @@
<refsect1>
<title>Description</title>
<para>These ioctls can be used to get or set an EDID associated with an input pad
from a receiver or an output pad of a transmitter subdevice.</para>
<para>These ioctls can be used to get or set an EDID associated with an input
from a receiver or an output of a transmitter device. They can be
used with subdevice nodes (/dev/v4l-subdevX) or with video nodes (/dev/videoX).</para>
<para>When used with video nodes the <structfield>pad</structfield> field represents the
input (for video capture devices) or output (for video output devices) index as
is returned by &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively. When used
with subdevice nodes the <structfield>pad</structfield> field represents the
input or output pad of the subdevice. If there is no EDID support for the given
<structfield>pad</structfield> value, then the &EINVAL; will be returned.</para>
<para>To get the EDID data the application has to fill in the <structfield>pad</structfield>,
<structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield>
fields and call <constant>VIDIOC_SUBDEV_G_EDID</constant>. The current EDID from block
fields and call <constant>VIDIOC_G_EDID</constant>. The current EDID from block
<structfield>start_block</structfield> and of size <structfield>blocks</structfield>
will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield>
pointer must point to memory at least <structfield>blocks</structfield>&nbsp;*&nbsp;128 bytes
@ -91,15 +99,17 @@
data in some way. In any case, the end result is the same: the EDID is no longer available.
</para>
<table pgwide="1" frame="none" id="v4l2-subdev-edid">
<title>struct <structname>v4l2_subdev_edid</structname></title>
<table pgwide="1" frame="none" id="v4l2-edid">
<title>struct <structname>v4l2_edid</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad for which to get/set the EDID blocks.</entry>
<entry>Pad for which to get/set the EDID blocks. When used with a video device
node the pad represents the input or output index as returned by
&VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively.</entry>
</row>
<row>
<entry>__u32</entry>

7
Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
View File

@ -327,7 +327,12 @@ These controls are described in <xref
These controls are described in <xref
linkend="fm-rx-controls" />.</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_CLASS_RF_TUNER</constant></entry>
<entry>0xa20000</entry>
<entry>The class containing RF tuner controls.
These controls are described in <xref linkend="rf-tuner-controls" />.</entry>
</row>
</tbody>
</tgroup>
</table>

7
Documentation/DocBook/media/v4l/vidioc-g-fmt.xml
View File

@ -169,6 +169,13 @@ capture and output devices.</entry>
<entry>Sliced VBI capture or output parameters. See
<xref linkend="sliced" /> for details. Used by sliced VBI
capture and output devices.</entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-sdr-format;</entry>
<entry><structfield>sdr</structfield></entry>
<entry>Definition of a data format, see
<xref linkend="pixfmt" />, used by SDR capture devices.</entry>
</row>
<row>
<entry></entry>

5
Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
View File

@ -109,9 +109,10 @@ See <xref linkend="v4l2-tuner-type" /></entry>
<entry>__u32</entry>
<entry><structfield>frequency</structfield></entry>
<entry>Tuning frequency in units of 62.5 kHz, or if the
&v4l2-tuner; or &v4l2-modulator; <structfield>capabilities</structfield> flag
&v4l2-tuner; or &v4l2-modulator; <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz. A 1 Hz unit is used when the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
</row>
<row>
<entry>__u32</entry>

6
Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
View File

@ -113,7 +113,8 @@ change for example with the current video standard.</entry>
<entry>The lowest tunable frequency in units of 62.5
KHz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry>
</row>
<row>
<entry>__u32</entry>
@ -121,7 +122,8 @@ Hz.</entry>
<entry>The highest tunable frequency in units of 62.5
KHz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry>
</row>
<row>
<entry>__u32</entry>

15
Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
View File

@ -134,7 +134,9 @@ the structure refers to a radio tuner the
<entry spanname="hspan">The lowest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz. If multiple frequency bands are supported, then
Hz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.
If multiple frequency bands are supported, then
<structfield>rangelow</structfield> is the lowest frequency
of all the frequency bands.</entry>
</row>
@ -144,7 +146,9 @@ of all the frequency bands.</entry>
<entry spanname="hspan">The highest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz. If multiple frequency bands are supported, then
Hz, or if the <structfield>capability</structfield> flag
<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.
If multiple frequency bands are supported, then
<structfield>rangehigh</structfield> is the highest frequency
of all the frequency bands.</entry>
</row>
@ -270,7 +274,7 @@ applications must set the array to zero.</entry>
<entry><constant>V4L2_TUNER_CAP_LOW</constant></entry>
<entry>0x0001</entry>
<entry>When set, tuning frequencies are expressed in units of
62.5&nbsp;Hz, otherwise in units of 62.5&nbsp;kHz.</entry>
62.5 Hz instead of 62.5 kHz.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_NORM</constant></entry>
@ -360,6 +364,11 @@ radio tuners.</entry>
<entry>The range to search when using the hardware seek functionality
is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_1HZ</constant></entry>
<entry>0x1000</entry>
<entry>When set, tuning frequencies are expressed in units of 1 Hz instead of 62.5 kHz.</entry>
</row>
</tbody>
</tgroup>
</table>

6
Documentation/DocBook/media/v4l/vidioc-querycap.xml
View File

@ -294,6 +294,12 @@ interface. For more information on audio inputs and outputs see <xref
emit RF-modulated video/audio signals. For more information about
modulator programming see
<xref linkend="tuner" />.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_SDR_CAPTURE</constant></entry>
<entry>0x00100000</entry>
<entry>The device supports the
<link linkend="sdr">SDR Capture</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_READWRITE</constant></entry>

8
Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
View File

@ -121,7 +121,9 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
<entry>If non-zero, the lowest tunable frequency of the band to
search in units of 62.5 kHz, or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz.
If <structfield>rangelow</structfield> is zero a reasonable default value
is used.</entry>
</row>
@ -131,7 +133,9 @@ is used.</entry>
<entry>If non-zero, the highest tunable frequency of the band to
search in units of 62.5 kHz, or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz.
If <structfield>rangehigh</structfield> is zero a reasonable default value
is used.</entry>
</row>

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

@ -52,16 +52,24 @@
<para>The <constant>VIDIOC_STREAMON</constant> and
<constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture
or output process during streaming (<link linkend="mmap">memory
mapping</link> or <link linkend="userp">user pointer</link>) I/O.</para>
mapping</link>, <link linkend="userp">user pointer</link> or
<link linkend="dmabuf">DMABUF</link>) I/O.</para>
<para>Specifically the capture hardware is disabled and no input
<para>Capture hardware is disabled and no input
buffers are filled (if there are any empty buffers in the incoming
queue) until <constant>VIDIOC_STREAMON</constant> has been called.
Accordingly the output hardware is disabled, no video signal is
Output hardware is disabled and no video signal is
produced until <constant>VIDIOC_STREAMON</constant> has been called.
The ioctl will succeed when at least one output buffer is in the
incoming queue.</para>
<para>Memory-to-memory devices will not start until
<constant>VIDIOC_STREAMON</constant> has been called for both the capture
and output stream types.</para>
<para>If <constant>VIDIOC_STREAMON</constant> fails then any already
queued buffers will remain queued.</para>
<para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of
aborting or finishing any DMA in progress, unlocks any user pointer
buffers locked in physical memory, and it removes all buffers from the
@ -70,14 +78,22 @@ dequeued yet will be lost, likewise all images enqueued for output but
not transmitted yet. I/O returns to the same state as after calling
&VIDIOC-REQBUFS; and can be restarted accordingly.</para>
<para>If buffers have been queued with &VIDIOC-QBUF; and
<constant>VIDIOC_STREAMOFF</constant> is called without ever having
called <constant>VIDIOC_STREAMON</constant>, then those queued buffers
will also be removed from the incoming queue and all are returned to the
same state as after calling &VIDIOC-REQBUFS; and can be restarted
accordingly.</para>
<para>Both ioctls take a pointer to an integer, the desired buffer or
stream type. This is the same as &v4l2-requestbuffers;
<structfield>type</structfield>.</para>
<para>If <constant>VIDIOC_STREAMON</constant> is called when streaming
is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called
when streaming is already stopped, then the ioctl does nothing and 0 is
returned.</para>
when streaming is already stopped, then 0 is returned. Nothing happens in the
case of <constant>VIDIOC_STREAMON</constant>, but <constant>VIDIOC_STREAMOFF</constant>
will return queued buffers to their starting state as mentioned above.</para>
<para>Note that applications can be preempted for unknown periods right
before or after the <constant>VIDIOC_STREAMON</constant> or
@ -93,7 +109,7 @@ synchronize with other events.</para>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The buffer<structfield>type</structfield> is not supported,
<para>The buffer <structfield>type</structfield> is not supported,
or no buffers have been allocated (memory mapping) or enqueued
(output) yet.</para>
</listitem>

86
Documentation/DocBook/media_api.tmpl
View File

@ -34,22 +34,20 @@
<book id="media_api">
<bookinfo>
<title>LINUX MEDIA INFRASTRUCTURE API</title>
<title>LINUX MEDIA INFRASTRUCTURE API</title>
<copyright>
<year>2009-2012</year>
<holder>LinuxTV Developers</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation License,
Version 1.1 or any later version published by the Free Software
Foundation. A copy of the license is included in the chapter entitled
"GNU Free Documentation License"</para>
</legalnotice>
<copyright>
<year>2009-2014</year>
<holder>LinuxTV Developers</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation License,
Version 1.1 or any later version published by the Free Software
Foundation. A copy of the license is included in the chapter entitled
"GNU Free Documentation License"</para>
</legalnotice>
</bookinfo>
<toc></toc> <!-- autogenerated -->
@ -58,12 +56,13 @@ Foundation. A copy of the license is included in the chapter entitled
<title>Introduction</title>
<para>This document covers the Linux Kernel to Userspace API's used by
video and radio straming devices, including video cameras,
video and radio streaming devices, including video cameras,
analog and digital TV receiver cards, AM/FM receiver cards,
streaming capture devices.</para>
streaming capture and output devices, codec devices and remote
controllers.</para>
<para>It is divided into four parts.</para>
<para>The first part covers radio, capture,
cameras and analog TV devices.</para>
<para>The first part covers radio, video capture and output,
cameras, analog TV devices and codecs.</para>
<para>The second part covers the
API used for digital TV and Internet reception via one of the
several digital tv standards. While it is called as DVB API,
@ -75,55 +74,14 @@ Foundation. A copy of the license is included in the chapter entitled
<para>For additional information and for the latest development code,
see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
<para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para>
</preface>
<part id="v4l2spec">
&sub-v4l2;
</part>
<part id="dvbapi">
&sub-dvbapi;
</part>
<part id="v4ldvb_common">
<partinfo>
<authorgroup>
<author>
<firstname>Mauro</firstname>
<surname>Chehab</surname>
<othername role="mi">Carvalho</othername>
<affiliation><address><email>mchehab@redhat.com</email></address></affiliation>
<contrib>Initial version.</contrib>
</author>
</authorgroup>
<copyright>
<year>2009-2012</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>1.0.0</revnumber>
<date>2009-09-06</date>
<authorinitials>mcc</authorinitials>
<revremark>Initial revision</revremark>
</revision>
</revhistory>
</partinfo>
<title>Remote Controller API</title>
<chapter id="remote_controllers">
&sub-remote_controllers;
</chapter>
</part>
<part id="media_common">
&sub-media-controller;
</part>
<chapter id="gen_errors">
&sub-gen-errors;
</chapter>
<part id="v4l2spec">&sub-v4l2;</part>
<part id="dvbapi">&sub-dvbapi;</part>
<part id="remotes">&sub-remote_controllers;</part>
<part id="media_common">&sub-media-controller;</part>
<chapter id="gen_errors">&sub-gen-errors;</chapter>
&sub-fdl-appendix;

50
Documentation/SubmittingPatches
View File

@ -14,7 +14,10 @@ Read Documentation/SubmitChecklist for a list of items to check
before submitting code. If you are submitting a driver, also read
Documentation/SubmittingDrivers.
Many of these steps describe the default behavior of the git version
control system; if you use git to prepare your patches, you'll find much
of the mechanical work done for you, though you'll still need to prepare
and document a sensible set of patches.
--------------------------------------------
SECTION 1 - CREATING AND SENDING YOUR CHANGE
@ -25,7 +28,9 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
1) "diff -up"
------------
Use "diff -up" or "diff -uprN" to create patches.
Use "diff -up" or "diff -uprN" to create patches. git generates patches
in this form by default; if you're using git, you can skip this section
entirely.
All changes to the Linux kernel occur in the form of patches, as
generated by diff(1). When creating your patch, make sure to create it
@ -66,19 +71,14 @@ Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-
generated it with diff(1), to ensure accuracy.
If your changes produce a lot of deltas, you may want to look into
splitting them into individual patches which modify things in
logical stages. This will facilitate easier reviewing by other
kernel developers, very important if you want your patch accepted.
There are a number of scripts which can aid in this:
If your changes produce a lot of deltas, you need to split them into
individual patches which modify things in logical stages; see section
#3. This will facilitate easier reviewing by other kernel developers,
very important if you want your patch accepted.
Quilt:
http://savannah.nongnu.org/projects/quilt
Andrew Morton's patch scripts:
http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
Instead of these scripts, quilt is the recommended patch management
tool (see above).
If you're using git, "git rebase -i" can help you with this process. If
you're not using git, quilt <http://savannah.nongnu.org/projects/quilt>
is another popular alternative.
@ -106,8 +106,21 @@ I.e., the patch (series) and its description should be self-contained.
This benefits both the patch merger(s) and reviewers. Some reviewers
probably didn't even receive earlier versions of the patch.
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour.
If the patch fixes a logged bug entry, refer to that bug entry by
number and URL.
number and URL. If the patch follows from a mailing list discussion,
give a URL to the mailing list archive; use the https://lkml.kernel.org/
redirector with a Message-Id, to ensure that the links cannot become
stale.
However, try to make your explanation understandable without external
resources. In addition to giving a URL to a mailing list archive or
bug, summarize the relevant points of the discussion that led to the
patch as submitted.
If you want to refer to a specific commit, don't just refer to the
SHA-1 ID of the commit. Please also include the oneline summary of
@ -594,7 +607,8 @@ patch.
If you are going to include a diffstat after the "---" marker, please
use diffstat options "-p 1 -w 70" so that filenames are listed from
the top of the kernel source tree and don't use too much horizontal
space (easily fit in 80 columns, maybe with some indentation).
space (easily fit in 80 columns, maybe with some indentation). (git
generates appropriate diffstats by default.)
See more details on the proper patch format in the following
references.
@ -725,7 +739,7 @@ SECTION 3 - REFERENCES
----------------------
Andrew Morton, "The perfect patch" (tpp).
<http://userweb.kernel.org/~akpm/stuff/tpp.txt>
<http://www.ozlabs.org/~akpm/stuff/tpp.txt>
Jeff Garzik, "Linux kernel patch submission format".
<http://linux.yyz.us/patch-format.html>
@ -738,7 +752,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
<http://www.kroah.com/log/linux/maintainer-05.html>
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
<https://lkml.org/lkml/2005/7/11/336>
Kernel Documentation/CodingStyle:
<http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>

12
Documentation/arm/Marvell/README
View File

@ -83,14 +83,24 @@ EBU Armada family
88F6710
88F6707
88F6W11
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
Armada 375 Flavors:
88F6720
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
Armada 380/385 Flavors:
88F6810
88F6820
88F6828
Armada XP Flavors:
MV78230
MV78260
MV78460
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
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
No public datasheet available.
Core: Sheeva ARMv7 compatible

10
Documentation/arm64/booting.txt
View File

@ -111,8 +111,14 @@ Before jumping into the kernel, the following conditions must be met:
- Caches, MMUs
The MMU must be off.
Instruction cache may be on or off.
Data cache must be off and invalidated.
External caches (if present) must be configured and disabled.
The address range corresponding to the loaded kernel image must be
cleaned to the PoC. In the presence of a system cache or other
coherent masters with caches enabled, this will typically require
cache maintenance by VA rather than set/way operations.
System caches which respect the architected cache maintenance by VA
operations must be configured and may be enabled.
System caches which do not respect architected cache maintenance by VA
operations (not recommended) must be configured and disabled.
- Architected timers
CNTFRQ must be programmed with the timer frequency and CNTVOFF must

4
Documentation/arm64/memory.txt
View File

@ -39,7 +39,7 @@ ffffffbffa000000 ffffffbffaffffff 16MB PCI I/O space
ffffffbffb000000 ffffffbffbbfffff 12MB [guard]
ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
ffffffbffbc00000 ffffffbffbdfffff 2MB fixed mappings
ffffffbffbe00000 ffffffbffbffffff 2MB [guard]
@ -66,7 +66,7 @@ fffffdfffa000000 fffffdfffaffffff 16MB PCI I/O space
fffffdfffb000000 fffffdfffbbfffff 12MB [guard]
fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk device
fffffdfffbc00000 fffffdfffbdfffff 2MB fixed mappings
fffffdfffbe00000 fffffdfffbffffff 2MB [guard]

54
Documentation/blockdev/zram.txt
View File

@ -21,7 +21,43 @@ Following shows a typical sequence of steps for using zram.
This creates 4 devices: /dev/zram{0,1,2,3}
(num_devices parameter is optional. Default: 1)
2) Set Disksize
2) Set max number of compression streams
Compression backend may use up to max_comp_streams compression streams,
thus allowing up to max_comp_streams concurrent compression operations.
By default, compression backend uses single compression stream.
Examples:
#show max compression streams number
cat /sys/block/zram0/max_comp_streams
#set max compression streams number to 3
echo 3 > /sys/block/zram0/max_comp_streams
Note:
In order to enable compression backend's multi stream support max_comp_streams
must be initially set to desired concurrency level before ZRAM device
initialisation. Once the device initialised as a single stream compression
backend (max_comp_streams equals to 1), you will see error if you try to change
the value of max_comp_streams because single stream compression backend
implemented as a special case by lock overhead issue and does not support
dynamic max_comp_streams. Only multi stream backend supports dynamic
max_comp_streams adjustment.
3) Select compression algorithm
Using comp_algorithm device attribute one can see available and
currently selected (shown in square brackets) compression algortithms,
change selected compression algorithm (once the device is initialised
there is no way to change compression algorithm).
Examples:
#show supported compression algorithms
cat /sys/block/zram0/comp_algorithm
lzo [lz4]
#select lzo compression algorithm
echo lzo > /sys/block/zram0/comp_algorithm
4) Set Disksize
Set disk size by writing the value to sysfs node 'disksize'.
The value can be either in bytes or you can use mem suffixes.
Examples:
@ -33,32 +69,38 @@ Following shows a typical sequence of steps for using zram.
echo 512M > /sys/block/zram0/disksize
echo 1G > /sys/block/zram0/disksize
3) Activate:
Note:
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:
mkswap /dev/zram0
swapon /dev/zram0
mkfs.ext4 /dev/zram1
mount /dev/zram1 /tmp
4) Stats:
6) Stats:
Per-device statistics are exported as various nodes under
/sys/block/zram<id>/
disksize
num_reads
num_writes
failed_reads
failed_writes
invalid_io
notify_free
discard
zero_pages
orig_data_size
compr_data_size
mem_used_total
5) Deactivate:
7) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
6) Reset:
8) Reset:
Write any positive value to 'reset' sysfs node
echo 1 > /sys/block/zram0/reset
echo 1 > /sys/block/zram1/reset

4
Documentation/cgroups/memcg_test.txt
View File

@ -24,7 +24,7 @@ Please note that implementation details can be changed.
a page/swp_entry may be charged (usage += PAGE_SIZE) at
mem_cgroup_newpage_charge()
mem_cgroup_charge_anon()
Called at new page fault and Copy-On-Write.
mem_cgroup_try_charge_swapin()
@ -32,7 +32,7 @@ Please note that implementation details can be changed.
Followed by charge-commit-cancel protocol. (With swap accounting)
At commit, a charge recorded in swap_cgroup is removed.
mem_cgroup_cache_charge()
mem_cgroup_charge_file()
Called at add_to_page_cache()
mem_cgroup_cache_charge_swapin()

12
Documentation/cgroups/resource_counter.txt
View File

@ -76,15 +76,7 @@ to work with it.
limit_fail_at parameter is set to the particular res_counter element
where the charging failed.
d. int res_counter_charge_locked
(struct res_counter *rc, unsigned long val, bool force)
The same as res_counter_charge(), but it must not acquire/release the
res_counter->lock internally (it must be called with res_counter->lock
held). The force parameter indicates whether we can bypass the limit.
e. u64 res_counter_uncharge[_locked]
(struct res_counter *rc, unsigned long val)
d. u64 res_counter_uncharge(struct res_counter *rc, unsigned long val)
When a resource is released (freed) it should be de-accounted
from the resource counter it was accounted to. This is called
@ -93,7 +85,7 @@ to work with it.
The _locked routines imply that the res_counter->lock is taken.
f. u64 res_counter_uncharge_until
e. u64 res_counter_uncharge_until
(struct res_counter *rc, struct res_counter *top,
unsigned long val)

34
Documentation/clk.txt
View File

@ -255,3 +255,37 @@ are sorted out.
To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
kernel.
Part 7 - Locking
The common clock framework uses two global locks, the prepare lock and the
enable lock.
The enable lock is a spinlock and is held across calls to the .enable,
.disable and .is_enabled operations. Those operations are thus not allowed to
sleep, and calls to the clk_enable(), clk_disable() and clk_is_enabled() API
functions are allowed in atomic context.
The prepare lock is a mutex and is held across calls to all other operations.
All those operations are allowed to sleep, and calls to the corresponding API
functions are not allowed in atomic context.
This effectively divides operations in two groups from a locking perspective.
Drivers don't need to manually protect resources shared between the operations
of one group, regardless of whether those resources are shared by multiple
clocks or not. However, access to resources that are shared between operations
of the two groups needs to be protected by the drivers. An example of such a
resource would be a register that controls both the clock rate and the clock
enable/disable state.
The clock framework is reentrant, in that a driver is allowed to call clock
framework functions from within its implementation of clock operations. This
can for instance cause a .set_rate operation of one clock being called from
within the .set_rate operation of another clock. This case must be considered
in the driver implementations, but the code flow is usually controlled by the
driver in that case.
Note that locking must also be considered when code outside of the common
clock framework needs to access resources used by the clock operations. This
is considered out of scope of this document.

45
Documentation/cpu-hotplug.txt
View File

@ -312,12 +312,57 @@ things will happen if a notifier in path sent a BAD notify code.
Q: I don't see my action being called for all CPUs already up and running?
A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined.
If you need to perform some action for each cpu already in the system, then
do this:
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i);
}
However, if you want to register a hotplug callback, as well as perform
some initialization for CPUs that are already online, then do this:
Version 1: (Correct)
---------
cpu_notifier_register_begin();
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier,
CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar_cpu_notifier,
CPU_ONLINE, i);
}
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(&foobar_cpu_notifier);
cpu_notifier_register_done();
Note that the following code is *NOT* the right way to achieve this,
because it is prone to an ABBA deadlock between the cpu_add_remove_lock
and the cpu_hotplug.lock.
Version 2: (Wrong!)
---------
get_online_cpus();
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier,
CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar_cpu_notifier,
CPU_ONLINE, i);
}
register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
So always use the first version shown above when you want to register
callbacks as well as initialize the already online CPUs.
Q: If i would like to develop cpu hotplug support for a new architecture,
what do i need at a minimum?
A: The following are what is required for CPU hotplug infrastructure to work

108
Documentation/device-mapper/era.txt Normal file
View File

@ -0,0 +1,108 @@
Introduction
============
dm-era is a target that behaves similar to the linear target. In
addition it keeps track of which blocks were written within a user
defined period of time called an 'era'. Each era target instance
maintains the current era as a monotonically increasing 32-bit
counter.
Use cases include tracking changed blocks for backup software, and
partially invalidating the contents of a cache to restore cache
coherency after rolling back a vendor snapshot.
Constructor
===========
era <metadata dev> <origin dev> <block size>
metadata dev : fast device holding the persistent metadata
origin dev : device holding data blocks that may change
block size : block size of origin data device, granularity that is
tracked by the target
Messages
========
None of the dm messages take any arguments.
checkpoint
----------
Possibly move to a new era. You shouldn't assume the era has
incremented. After sending this message, you should check the
current era via the status line.
take_metadata_snap
------------------
Create a clone of the metadata, to allow a userland process to read it.
drop_metadata_snap
------------------
Drop the metadata snapshot.
Status
======
<metadata block size> <#used metadata blocks>/<#total metadata blocks>
<current era> <held metadata root | '-'>
metadata block size : Fixed block size for each metadata block in
sectors
#used metadata blocks : Number of metadata blocks used
#total metadata blocks : Total number of metadata blocks
current era : The current era
held metadata root : The location, in blocks, of the metadata root
that has been 'held' for userspace read
access. '-' indicates there is no held root
Detailed use case
=================
The scenario of invalidating a cache when rolling back a vendor
snapshot was the primary use case when developing this target:
Taking a vendor snapshot
------------------------
- Send a checkpoint message to the era target
- Make a note of the current era in its status line
- Take vendor snapshot (the era and snapshot should be forever
associated now).
Rolling back to an vendor snapshot
----------------------------------
- Cache enters passthrough mode (see: dm-cache's docs in cache.txt)
- Rollback vendor storage
- Take metadata snapshot
- Ascertain which blocks have been written since the snapshot was taken
by checking each block's era
- Invalidate those blocks in the caching software
- Cache returns to writeback/writethrough mode
Memory usage
============
The target uses a bitset to record writes in the current era. It also
has a spare bitset ready for switching over to a new era. Other than
that it uses a few 4k blocks for updating metadata.
(4 * nr_blocks) bytes + buffers
Resilience
==========
Metadata is updated on disk before a write to a previously unwritten
block is performed. As such dm-era should not be effected by a hard
crash such as power failure.
Userland tools
==============
Userland tools are found in the increasingly poorly named
thin-provisioning-tools project:
https://github.com/jthornber/thin-provisioning-tools

8
Documentation/devices.txt
View File

@ -353,6 +353,7 @@ Your cooperation is appreciated.
133 = /dev/exttrp External device trap
134 = /dev/apm_bios Advanced Power Management BIOS
135 = /dev/rtc Real Time Clock
137 = /dev/vhci Bluetooth virtual HCI driver
139 = /dev/openprom SPARC OpenBoot PROM
140 = /dev/relay8 Berkshire Products Octal relay card
141 = /dev/relay16 Berkshire Products ISO-16 relay card
@ -1493,10 +1494,17 @@ Your cooperation is appreciated.
64 = /dev/radio0 Radio device
...
127 = /dev/radio63 Radio device
128 = /dev/swradio0 Software Defined Radio device
...
191 = /dev/swradio63 Software Defined Radio device
224 = /dev/vbi0 Vertical blank interrupt
...
255 = /dev/vbi31 Vertical blank interrupt
Minor numbers are allocated dynamically unless
CONFIG_VIDEO_FIXED_MINOR_RANGES (default n)
configuration option is set.
81 block I2O hard disk
0 = /dev/i2o/hdq 17th I2O hard disk, whole disk
16 = /dev/i2o/hdr 18th I2O hard disk, whole disk

9
Documentation/devicetree/bindings/arm/armada-375.txt Normal file
View File

@ -0,0 +1,9 @@
Marvell Armada 375 Platforms Device Tree Bindings
-------------------------------------------------
Boards with a SoC of the Marvell Armada 375 family shall have the
following property:
Required root node property:
compatible: must contain "marvell,armada375"

10
Documentation/devicetree/bindings/arm/armada-38x.txt Normal file
View File

@ -0,0 +1,10 @@
Marvell Armada 38x Platforms Device Tree Bindings
-------------------------------------------------
Boards with a SoC of the Marvell Armada 38x family shall have the
following property:
Required root node property:
- compatible: must contain either "marvell,armada380" or
"marvell,armada385" depending on the variant of the SoC being used.

15
Documentation/devicetree/bindings/arm/bcm/bcm21664.txt Normal file
View File

@ -0,0 +1,15 @@
Broadcom BCM21664 device tree bindings
--------------------------------------
This document describes the device tree bindings for boards with the BCM21664
SoC.
Required root node property:
- compatible: brcm,bcm21664
Example:
/ {
model = "BCM21664 SoC";
compatible = "brcm,bcm21664";
[...]
}

14
Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt Normal file
View File

@ -0,0 +1,14 @@
Broadcom Kona Family Reset Manager
----------------------------------
The reset manager is used on the Broadcom BCM21664 SoC.
Required properties:
- compatible: brcm,bcm21664-resetmgr
- reg: memory address & range
Example:
brcm,resetmgr@35001f00 {
compatible = "brcm,bcm21664-resetmgr";
reg = <0x35001f00 0x24>;
};

8
Documentation/devicetree/bindings/arm/bcm4708.txt Normal file
View File

@ -0,0 +1,8 @@
Broadcom BCM4708 device tree bindings
-------------------------------------------
Boards with the BCM4708 SoC shall have the following properties:
Required root node property:
compatible = "brcm,bcm4708";

25
Documentation/devicetree/bindings/arm/cpus.txt
View File

@ -180,7 +180,11 @@ nodes to be present and contain the properties described below.
be one of:
"spin-table"
"psci"
# On ARM 32-bit systems this property is optional.
# On ARM 32-bit systems this property is optional and
can be one of:
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
- cpu-release-addr
Usage: required for systems that have an "enable-method"
@ -191,6 +195,21 @@ nodes to be present and contain the properties described below.
property identifying a 64-bit zero-initialised
memory location.
- qcom,saw
Usage: required for systems that have an "enable-method"
property value of "qcom,kpss-acc-v1" or
"qcom,kpss-acc-v2"
Value type: <phandle>
Definition: Specifies the SAW[1] node associated with this CPU.
- qcom,acc
Usage: required for systems that have an "enable-method"
property value of "qcom,kpss-acc-v1" or
"qcom,kpss-acc-v2"
Value type: <phandle>
Definition: Specifies the ACC[2] node associated with this CPU.
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
@ -382,3 +401,7 @@ cpus {
cpu-release-addr = <0 0x20000000>;
};
};
--
[1] arm/msm/qcom,saw2.txt
[2] arm/msm/qcom,kpss-acc.txt

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

@ -50,6 +50,11 @@ Optional
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
- arm,routable-irqs : Total number of gic irq inputs which are not directly
connected from the peripherals, but are routed dynamically
by a crossbar/multiplexer preceding the GIC. The GIC irq
input line is assigned dynamically when the corresponding
peripheral's crossbar line is mapped.
Example:
intc: interrupt-controller@fff11000 {
@ -57,6 +62,7 @@ Example:
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
arm,routable-irqs = <160>;
reg = <0xfff11000 0x1000>,
<0xfff10100 0x100>;
};

14
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
View File

@ -30,3 +30,17 @@ Example:
resume-offset = <0x308>;
reboot-offset = <0x4>;
};
PCTRL: Peripheral misc control register
Required Properties:
- compatible: "hisilicon,pctrl"
- reg: Address and size of pctrl.
Example:
/* for Hi3620 */
pctrl: pctrl@fca09000 {
compatible = "hisilicon,pctrl";
reg = <0xfca09000 0x1000>;
};

10
Documentation/devicetree/bindings/arm/keystone/keystone.txt
View File

@ -8,3 +8,13 @@ Required properties:
- compatible: All TI specific devices present in Keystone SOC should be in
the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
type UART should use the specified compatible for those devices.
Boards:
- Keystone 2 Hawking/Kepler EVM
compatible = "ti,k2hk-evm","ti,keystone"
- Keystone 2 Lamarr EVM
compatible = "ti,k2l-evm","ti,keystone"
- Keystone 2 Edison EVM
compatible = "ti,k2e-evm","ti,keystone"

97
Documentation/devicetree/bindings/arm/marvell,kirkwood.txt Normal file
View File

@ -0,0 +1,97 @@
Marvell Kirkwood SoC Family Device Tree Bindings
------------------------------------------------
Boards with a SoC of the Marvell Kirkwook family, eg 88f6281
* Required root node properties:
compatible: must contain "marvell,kirkwood"
In addition, the above compatible shall be extended with the specific
SoC. Currently known SoC compatibles are:
"marvell,kirkwood-88f6192"
"marvell,kirkwood-88f6281"
"marvell,kirkwood-88f6282"
"marvell,kirkwood-88f6283"
"marvell,kirkwood-88f6702"
"marvell,kirkwood-98DX4122"
And in addition, the compatible shall be extended with the specific
board. Currently known boards are:
"buffalo,lschlv2"
"buffalo,lsxhl"
"buffalo,lsxl"
"dlink,dns-320"
"dlink,dns-320-a1"
"dlink,dns-325"
"dlink,dns-325-a1"
"dlink,dns-kirkwood"
"excito,b3"
"globalscale,dreamplug-003-ds2001"
"globalscale,guruplug"
"globalscale,guruplug-server-plus"
"globalscale,sheevaplug"
"globalscale,sheevaplug"
"globalscale,sheevaplug-esata"
"globalscale,sheevaplug-esata-rev13"
"iom,iconnect"
"iom,iconnect-1.1"
"iom,ix2-200"
"keymile,km_kirkwood"
"lacie,cloudbox"
"lacie,inetspace_v2"
"lacie,laplug"
"lacie,netspace_lite_v2"
"lacie,netspace_max_v2"
"lacie,netspace_mini_v2"
"lacie,netspace_v2"
"marvell,db-88f6281-bp"
"marvell,db-88f6282-bp"
"marvell,mv88f6281gtw-ge"
"marvell,rd88f6281"
"marvell,rd88f6281"
"marvell,rd88f6281-a0"
"marvell,rd88f6281-a1"
"mpl,cec4"
"mpl,cec4-10"
"netgear,readynas"
"netgear,readynas"
"netgear,readynas-duo-v2"
"netgear,readynas-nv+-v2"
"plathome,openblocks-a6"
"plathome,openblocks-a7"
"raidsonic,ib-nas6210"
"raidsonic,ib-nas6210-b"
"raidsonic,ib-nas6220"
"raidsonic,ib-nas6220-b"
"raidsonic,ib-nas62x0"
"seagate,dockstar"
"seagate,goflexnet"
"synology,ds109"
"synology,ds110jv10"
"synology,ds110jv20"
"synology,ds110jv30"
"synology,ds111"
"synology,ds209"
"synology,ds210jv10"
"synology,ds210jv20"
"synology,ds212"
"synology,ds212jv10"
"synology,ds212jv20"
"synology,ds212pv10"
"synology,ds409"
"synology,ds409slim"
"synology,ds410j"
"synology,ds411"
"synology,ds411j"
"synology,ds411slim"
"synology,ds413jv10"
"synology,rs212"
"synology,rs409"
"synology,rs411"
"synology,rs812"
"usi,topkick"
"usi,topkick-1281P2"
"zyxel,nsa310"
"zyxel,nsa310a"

16
Documentation/devicetree/bindings/arm/mrvl/feroceon.txt Normal file
View File

@ -0,0 +1,16 @@
* Marvell Feroceon Cache
Required properties:
- compatible : Should be either "marvell,feroceon-cache" or
"marvell,kirkwood-cache".
Optional properties:
- reg : Address of the L2 cache control register. Mandatory for
"marvell,kirkwood-cache", not used by "marvell,feroceon-cache"
Example:
l2: l2-cache@20128 {
compatible = "marvell,kirkwood-cache";
reg = <0x20128 0x4>;
};

30
Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt Normal file
View File

@ -0,0 +1,30 @@
Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
There is one ACC register region per CPU within the KPSS remapped region as
well as an alias register region that remaps accesses to the ACC associated
with the CPU accessing the region.
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: should be one of:
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: the first element specifies the base address and size of
the register region. An optional second element specifies
the base address and size of the alias register region.
Example:
clock-controller@2088000 {
compatible = "qcom,kpss-acc-v2";
reg = <0x02088000 0x1000>,
<0x02008000 0x1000>;
};

35
Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt Normal file
View File

@ -0,0 +1,35 @@
SPM AVS Wrapper 2 (SAW2)
The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
micro-controller that transitions a piece of hardware (like a processor or
subsystem) into and out of low power modes via a direct connection to
the PMIC. It can also be wired up to interact with other processors in the
system, notifying them when a low power state is entered or exited.
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: shall contain "qcom,saw2". A more specific value should be
one of:
"qcom,saw2-v1"
"qcom,saw2-v1.1"
"qcom,saw2-v2"
"qcom,saw2-v2.1"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: the first element specifies the base address and size of
the register region. An optional second element specifies
the base address and size of the alias register region.
Example:
regulator@2099000 {
compatible = "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
};

3
Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
View File

@ -1,12 +1,13 @@
MVEBU System Controller
-----------------------
MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x)
MVEBU (Marvell SOCs: Armada 370/375/XP, Dove, mv78xx0, Kirkwood, Orion5x)
Required properties:
- compatible: one of:
- "marvell,orion-system-controller"
- "marvell,armada-370-xp-system-controller"
- "marvell,armada-375-system-controller"
- reg: Should contain system controller registers location and length.
Example:

27
Documentation/devicetree/bindings/arm/omap/crossbar.txt Normal file
View File

@ -0,0 +1,27 @@
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are preceded by an CROSSBAR
that provides flexibility in muxing the device requests to the controller
inputs.
Required properties:
- compatible : Should be "ti,irq-crossbar"
- reg: Base address and the size of the crossbar registers.
- ti,max-irqs: Total number of irqs available at the interrupt controller.
- ti,reg-size: Size of a individual register in bytes. Every individual
register is assumed to be of same size. Valid sizes are 1, 2, 4.
- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
crossbar. These interrupt lines are reserved in the soc,
so crossbar bar driver should not consider them as free
lines.
Examples:
crossbar_mpu: @4a020000 {
compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>;
ti,max-irqs = <160>;
ti,reg-size = <2>;
ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
};

22
Documentation/devicetree/bindings/arm/omap/dmm.txt Normal file
View File

@ -0,0 +1,22 @@
OMAP Dynamic Memory Manager (DMM) bindings
The dynamic memory manager (DMM) is a module located immediately in front of the
SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory
accesses such as priority generation amongst initiators, configuration of SDRAM
interleaving, optimizing transfer of 2D block objects, and provide MMU-like page
translation for initiators which need contiguous dma bus addresses.
Required properties:
- compatible: Should contain "ti,omap4-dmm" for OMAP4 family
Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family
- reg: Contains DMM register address range (base address and length)
- interrupts: Should contain an interrupt-specifier for DMM_IRQ.
- ti,hwmods: Name of the hwmod associated to DMM, which is typically "dmm"
Example:
dmm@4e000000 {
compatible = "ti,omap4-dmm";
reg = <0x4e000000 0x800>;
ti,hwmods = "dmm";
};

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

@ -99,6 +99,9 @@ Boards:
- OMAP4 PandaBoard : Low cost community board
compatible = "ti,omap4-panda", "ti,omap4430"
- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
compatible = "ti,omap3-evm", "ti,omap3"
@ -114,5 +117,8 @@ Boards:
- AM43x EPOS EVM
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
- AM437x GP EVM
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
- DRA7 EVM: Software Developement Board for DRA7XX
compatible = "ti,dra7-evm", "ti,dra7"

10
Documentation/devicetree/bindings/arm/pmu.txt
View File

@ -9,6 +9,7 @@ Required properties:
- compatible : should be one of
"arm,armv8-pmuv3"
"arm,cortex-a15-pmu"
"arm,cortex-a12-pmu"
"arm,cortex-a9-pmu"
"arm,cortex-a8-pmu"
"arm,cortex-a7-pmu"
@ -16,7 +17,14 @@ Required properties:
"arm,arm11mpcore-pmu"
"arm,arm1176-pmu"
"arm,arm1136-pmu"
- interrupts : 1 combined interrupt or 1 per core.
"qcom,krait-pmu"
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
interrupt (PPI) then 1 interrupt should be specified.
Optional properties:
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
events.
Example:

16
Documentation/devicetree/bindings/arm/rockchip/pmu.txt Normal file
View File

@ -0,0 +1,16 @@
Rockchip power-management-unit:
-------------------------------
The pmu is used to turn off and on different power domains of the SoCs
This includes the power to the CPU cores.
Required node properties:
- compatible value : = "rockchip,rk3066-pmu";
- reg : physical base address and the size of the registers window
Example:
pmu@20004000 {
compatible = "rockchip,rk3066-pmu";
reg = <0x20004000 0x100>;
};

30
Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt Normal file
View File

@ -0,0 +1,30 @@
Rockchip SRAM for smp bringup:
------------------------------
Rockchip's smp-capable SoCs use the first part of the sram for the bringup
of the cores. Once the core gets powered up it executes the code that is
residing at the very beginning of the sram.
Therefore a reserved section sub-node has to be added to the mmio-sram
declaration.
Required sub-node properties:
- compatible : should be "rockchip,rk3066-smp-sram"
The rest of the properties should follow the generic mmio-sram discription
found in ../../misc/sram.txt
Example:
sram: sram@10080000 {
compatible = "mmio-sram";
reg = <0x10080000 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
smp-sram@10080000 {
compatible = "rockchip,rk3066-smp-sram";
reg = <0x10080000 0x50>;
};
};

15
Documentation/devicetree/bindings/arm/samsung/pmu.txt Normal file
View File

@ -0,0 +1,15 @@
SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from following list:
- "samsung,exynos5250-pmu" - for Exynos5250 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
second value must be always "syscon".
- reg : offset and length of the register set.
Example :
pmu_system_controller: system-controller@10040000 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x10040000 0x5000>;
};

7
Documentation/devicetree/bindings/arm/topology.txt
View File

@ -75,9 +75,10 @@ The cpu-map node can only contain three types of child nodes:
whose bindings are described in paragraph 3.
The nodes describing the CPU topology (cluster/core/thread) can only be
defined within the cpu-map node.
Any other configuration is consider invalid and therefore must be ignored.
The nodes describing the CPU topology (cluster/core/thread) can only
be defined within the cpu-map node and every core/thread in the system
must be defined within the topology. Any other configuration is
invalid and therefore must be ignored.
===========================================
2.1 - cpu-map child nodes naming convention

14
Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
View File

@ -1,14 +0,0 @@
* Samsung SATA PHY Controller
SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
Each SATA PHY controller should have its own node.
Required properties:
- compatible : compatible list, contains "samsung,exynos5-sata-phy"
- reg : <registers mapping>
Example:
sata@ffe07000 {
compatible = "samsung,exynos5-sata-phy";
reg = <0xffe07000 0x1000>;
};

31
Documentation/devicetree/bindings/ata/exynos-sata.txt
View File

@ -4,14 +4,27 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
Required properties:
- compatible : compatible list, contains "samsung,exynos5-sata"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
- samsung,sata-freq : <frequency in MHz>
- compatible : compatible list, contains "samsung,exynos5-sata"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
- samsung,sata-freq : <frequency in MHz>
- phys : Must contain exactly one entry as specified
in phy-bindings.txt
- phy-names : Must be "sata-phy"
Optional properties:
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Shall be "sata" for the external SATA bus clock,
and "sclk_sata" for the internal controller clock.
Example:
sata@ffe08000 {
compatible = "samsung,exynos5-sata";
reg = <0xffe08000 0x1000>;
interrupts = <115>;
};
sata@122f0000 {
compatible = "snps,dwc-ahci";
samsung,sata-freq = <66>;
reg = <0x122f0000 0x1ff>;
interrupts = <0 115 0>;
clocks = <&clock 277>, <&clock 143>;
clock-names = "sata", "sclk_sata";
phys = <&sata_phy>;
phy-names = "sata-phy";
};

28
Documentation/devicetree/bindings/bus/imx-weim.txt
View File

@ -8,7 +8,12 @@ The actual devices are instantiated from the child nodes of a WEIM node.
Required properties:
- compatible: Should be set to "fsl,<soc>-weim"
- compatible: Should contain one of the following:
"fsl,imx1-weim"
"fsl,imx27-weim"
"fsl,imx51-weim"
"fsl,imx50-weim"
"fsl,imx6q-weim"
- reg: A resource specifier for the register space
(see the example below)
- clocks: the clock, see the example below.
@ -19,6 +24,26 @@ Required properties:
<cs-number> 0 <physical address of mapping> <size>
Optional properties:
- fsl,weim-cs-gpr: For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
devices, it should be the phandle to the system General
Purpose Register controller that contains WEIM CS GPR
register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0]
should be set up as one of the following 4 possible
values depending on the CS space configuration.
IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3
---------------------------------------------
05 128M 0M 0M 0M
033 64M 64M 0M 0M
0113 64M 32M 32M 0M
01111 32M 32M 32M 32M
In case that the property is absent, the reset value or
what bootloader sets up in IOMUXC_GPR1[11:0] will be
used.
Timing property for child nodes. It is mandatory, not optional.
- fsl,weim-cs-timing: The timing array, contains timing values for the
@ -43,6 +68,7 @@ Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x08000000>;
fsl,weim-cs-gpr = <&gpr>;
nor@0,0 {
compatible = "cfi-flash";

5
Documentation/devicetree/bindings/clock/altr_socfpga.txt
View File

@ -23,3 +23,8 @@ Optional properties:
and the bit index.
- div-reg : For "socfpga-gate-clk", div-reg contains the divider register, bit shift,
and width.
- clk-phase : For the sdmmc_clk, contains the value of the clock phase that controls
the SDMMC CIU clock. The first value is the clk_sample(smpsel), and the second
value is the cclk_in_drv(drvsel). The clk-phase is used to enable the correct
hold/delay times that is needed for the SD/MMC CIU clock. The values of both
can be 0-315 degrees, in 45 degree increments.

34
Documentation/devicetree/bindings/clock/arm-integrator.txt Normal file
View File

@ -0,0 +1,34 @@
Clock bindings for ARM Integrator Core Module clocks
Auxilary Oscillator Clock
This is a configurable clock fed from a 24 MHz chrystal,
used for generating e.g. video clocks. It is located on the
core module and there is only one of these.
This clock node *must* be a subnode of the core module, since
it obtains the base address for it's address range from its
parent node.
Required properties:
- compatible: must be "arm,integrator-cm-auxosc"
- #clock-cells: must be <0>
Optional properties:
- clocks: parent clock(s)
Example:
core-module@10000000 {
xtal24mhz: xtal24mhz@24M {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <24000000>;
};
auxosc: cm_aux_osc@25M {
#clock-cells = <0>;
compatible = "arm,integrator-cm-auxosc";
clocks = <&xtal24mhz>;
};
};

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

@ -5,7 +5,7 @@ This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "adi,axi-clkgen".
- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a".
- #clock-cells : from common clock binding; Should always be set to 0.
- reg : Address and length of the axi-clkgen register set.
- clocks : Phandle and clock specifier for the parent clock.

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

@ -44,6 +44,23 @@ For example:
clocks by index. The names should reflect the clock output signal
names for the device.
clock-indices: If the identifyng number for the clocks in the node
is not linear from zero, then the this mapping allows
the mapping of identifiers into the clock-output-names
array.
For example, if we have two clocks <&oscillator 1> and <&oscillator 3>:
oscillator {
compatible = "myclocktype";
#clock-cells = <1>;
clock-indices = <1>, <3>;
clock-output-names = "clka", "clkb";
}
This ensures we do not have any empty nodes in clock-output-names
==Clock consumers==
Required properties:

259
Documentation/devicetree/bindings/clock/exynos4-clock.txt
View File

@ -15,259 +15,12 @@ Required Properties:
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume. Some of the clocks are available only on a particular
Exynos4 SoC and this is specified where applicable.
[Core Clocks]
Clock ID SoC (if specific)
-----------------------------------------------
xxti 1
xusbxti 2
fin_pll 3
fout_apll 4
fout_mpll 5
fout_epll 6
fout_vpll 7
sclk_apll 8
sclk_mpll 9
sclk_epll 10
sclk_vpll 11
arm_clk 12
aclk200 13
aclk100 14
aclk160 15
aclk133 16
mout_mpll_user_t 17 Exynos4x12
mout_mpll_user_c 18 Exynos4x12
mout_core 19
mout_apll 20
[Clock Gate for Special Clocks]
Clock ID SoC (if specific)
-----------------------------------------------
sclk_fimc0 128
sclk_fimc1 129
sclk_fimc2 130
sclk_fimc3 131
sclk_cam0 132
sclk_cam1 133
sclk_csis0 134
sclk_csis1 135
sclk_hdmi 136
sclk_mixer 137
sclk_dac 138
sclk_pixel 139
sclk_fimd0 140
sclk_mdnie0 141 Exynos4412
sclk_mdnie_pwm0 12 142 Exynos4412
sclk_mipi0 143
sclk_audio0 144
sclk_mmc0 145
sclk_mmc1 146
sclk_mmc2 147
sclk_mmc3 148
sclk_mmc4 149
sclk_sata 150 Exynos4210
sclk_uart0 151
sclk_uart1 152
sclk_uart2 153
sclk_uart3 154
sclk_uart4 155
sclk_audio1 156
sclk_audio2 157
sclk_spdif 158
sclk_spi0 159
sclk_spi1 160
sclk_spi2 161
sclk_slimbus 162
sclk_fimd1 163 Exynos4210
sclk_mipi1 164 Exynos4210
sclk_pcm1 165
sclk_pcm2 166
sclk_i2s1 167
sclk_i2s2 168
sclk_mipihsi 169 Exynos4412
sclk_mfc 170
sclk_pcm0 171
sclk_g3d 172
sclk_pwm_isp 173 Exynos4x12
sclk_spi0_isp 174 Exynos4x12
sclk_spi1_isp 175 Exynos4x12
sclk_uart_isp 176 Exynos4x12
sclk_fimg2d 177
[Peripheral Clock Gates]
Clock ID SoC (if specific)
-----------------------------------------------
fimc0 256
fimc1 257
fimc2 258
fimc3 259
csis0 260
csis1 261
jpeg 262
smmu_fimc0 263
smmu_fimc1 264
smmu_fimc2 265
smmu_fimc3 266
smmu_jpeg 267
vp 268
mixer 269
tvenc 270 Exynos4210
hdmi 271
smmu_tv 272
mfc 273
smmu_mfcl 274
smmu_mfcr 275
g3d 276
g2d 277
rotator 278 Exynos4210
mdma 279 Exynos4210
smmu_g2d 280 Exynos4210
smmu_rotator 281 Exynos4210
smmu_mdma 282 Exynos4210
fimd0 283
mie0 284
mdnie0 285 Exynos4412
dsim0 286
smmu_fimd0 287
fimd1 288 Exynos4210
mie1 289 Exynos4210
dsim1 290 Exynos4210
smmu_fimd1 291 Exynos4210
pdma0 292
pdma1 293
pcie_phy 294
sata_phy 295 Exynos4210
tsi 296
sdmmc0 297
sdmmc1 298
sdmmc2 299
sdmmc3 300
sdmmc4 301
sata 302 Exynos4210
sromc 303
usb_host 304
usb_device 305
pcie 306
onenand 307
nfcon 308
smmu_pcie 309
gps 310
smmu_gps 311
uart0 312
uart1 313
uart2 314
uart3 315
uart4 316
i2c0 317
i2c1 318
i2c2 319
i2c3 320
i2c4 321
i2c5 322
i2c6 323
i2c7 324
i2c_hdmi 325
tsadc 326
spi0 327
spi1 328
spi2 329
i2s1 330
i2s2 331
pcm0 332
i2s0 333
pcm1 334
pcm2 335
pwm 336
slimbus 337
spdif 338
ac97 339
modemif 340
chipid 341
sysreg 342
hdmi_cec 343
mct 344
wdt 345
rtc 346
keyif 347
audss 348
mipi_hsi 349 Exynos4210
mdma2 350 Exynos4210
pixelasyncm0 351
pixelasyncm1 352
fimc_lite0 353 Exynos4x12
fimc_lite1 354 Exynos4x12
ppmuispx 355 Exynos4x12
ppmuispmx 356 Exynos4x12
fimc_isp 357 Exynos4x12
fimc_drc 358 Exynos4x12
fimc_fd 359 Exynos4x12
mcuisp 360 Exynos4x12
gicisp 361 Exynos4x12
smmu_isp 362 Exynos4x12
smmu_drc 363 Exynos4x12
smmu_fd 364 Exynos4x12
smmu_lite0 365 Exynos4x12
smmu_lite1 366 Exynos4x12
mcuctl_isp 367 Exynos4x12
mpwm_isp 368 Exynos4x12
i2c0_isp 369 Exynos4x12
i2c1_isp 370 Exynos4x12
mtcadc_isp 371 Exynos4x12
pwm_isp 372 Exynos4x12
wdt_isp 373 Exynos4x12
uart_isp 374 Exynos4x12
asyncaxim 375 Exynos4x12
smmu_ispcx 376 Exynos4x12
spi0_isp 377 Exynos4x12
spi1_isp 378 Exynos4x12
pwm_isp_sclk 379 Exynos4x12
spi0_isp_sclk 380 Exynos4x12
spi1_isp_sclk 381 Exynos4x12
uart_isp_sclk 382 Exynos4x12
tmu_apbif 383
[Mux Clocks]
Clock ID SoC (if specific)
-----------------------------------------------
mout_fimc0 384
mout_fimc1 385
mout_fimc2 386
mout_fimc3 387
mout_cam0 388
mout_cam1 389
mout_csis0 390
mout_csis1 391
mout_g3d0 392
mout_g3d1 393
mout_g3d 394
aclk400_mcuisp 395 Exynos4x12
[Div Clocks]
Clock ID SoC (if specific)
-----------------------------------------------
div_isp0 450 Exynos4x12
div_isp1 451 Exynos4x12
div_mcuisp0 452 Exynos4x12
div_mcuisp1 453 Exynos4x12
div_aclk200 454 Exynos4x12
div_aclk400_mcuisp 455 Exynos4x12
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos4.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
@ -285,6 +38,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
clocks = <&clock 314>, <&clock 153>;
clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};

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

@ -13,163 +13,12 @@ Required Properties:
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume.
[Core Clocks]
Clock ID
----------------------------
fin_pll 1
[Clock Gate for Special Clocks]
Clock ID
----------------------------
sclk_cam_bayer 128
sclk_cam0 129
sclk_cam1 130
sclk_gscl_wa 131
sclk_gscl_wb 132
sclk_fimd1 133
sclk_mipi1 134
sclk_dp 135
sclk_hdmi 136
sclk_pixel 137
sclk_audio0 138
sclk_mmc0 139
sclk_mmc1 140
sclk_mmc2 141
sclk_mmc3 142
sclk_sata 143
sclk_usb3 144
sclk_jpeg 145
sclk_uart0 146
sclk_uart1 147
sclk_uart2 148
sclk_uart3 149
sclk_pwm 150
sclk_audio1 151
sclk_audio2 152
sclk_spdif 153
sclk_spi0 154
sclk_spi1 155
sclk_spi2 156
div_i2s1 157
div_i2s2 158
sclk_hdmiphy 159
div_pcm0 160
[Peripheral Clock Gates]
Clock ID
----------------------------
gscl0 256
gscl1 257
gscl2 258
gscl3 259
gscl_wa 260
gscl_wb 261
smmu_gscl0 262
smmu_gscl1 263
smmu_gscl2 264
smmu_gscl3 265
mfc 266
smmu_mfcl 267
smmu_mfcr 268
rotator 269
jpeg 270
mdma1 271
smmu_rotator 272
smmu_jpeg 273
smmu_mdma1 274
pdma0 275
pdma1 276
sata 277
usbotg 278
mipi_hsi 279
sdmmc0 280
sdmmc1 281
sdmmc2 282
sdmmc3 283
sromc 284
usb2 285
usb3 286
sata_phyctrl 287
sata_phyi2c 288
uart0 289
uart1 290
uart2 291
uart3 292
uart4 293
i2c0 294
i2c1 295
i2c2 296
i2c3 297
i2c4 298
i2c5 299
i2c6 300
i2c7 301
i2c_hdmi 302
adc 303
spi0 304
spi1 305
spi2 306
i2s1 307
i2s2 308
pcm1 309
pcm2 310
pwm 311
spdif 312
ac97 313
hsi2c0 314
hsi2c1 315
hs12c2 316
hs12c3 317
chipid 318
sysreg 319
pmu 320
cmu_top 321
cmu_core 322
cmu_mem 323
tzpc0 324
tzpc1 325
tzpc2 326
tzpc3 327
tzpc4 328
tzpc5 329
tzpc6 330
tzpc7 331
tzpc8 332
tzpc9 333
hdmi_cec 334
mct 335
wdt 336
rtc 337
tmu 338
fimd1 339
mie1 340
dsim0 341
dp 342
mixer 343
hdmi 344
g2d 345
mdma0 346
smmu_mdma0 347
[Clock Muxes]
Clock ID
----------------------------
mout_hdmi 1024
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos5250.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
@ -187,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
clocks = <&clock 314>, <&clock 153>;
clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};

184
Documentation/devicetree/bindings/clock/exynos5420-clock.txt
View File

@ -13,184 +13,12 @@ Required Properties:
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume.
[Core Clocks]
Clock ID
----------------------------
fin_pll 1
[Clock Gate for Special Clocks]
Clock ID
----------------------------
sclk_uart0 128
sclk_uart1 129
sclk_uart2 130
sclk_uart3 131
sclk_mmc0 132
sclk_mmc1 133
sclk_mmc2 134
sclk_spi0 135
sclk_spi1 136
sclk_spi2 137
sclk_i2s1 138
sclk_i2s2 139
sclk_pcm1 140
sclk_pcm2 141
sclk_spdif 142
sclk_hdmi 143
sclk_pixel 144
sclk_dp1 145
sclk_mipi1 146
sclk_fimd1 147
sclk_maudio0 148
sclk_maupcm0 149
sclk_usbd300 150
sclk_usbd301 151
sclk_usbphy300 152
sclk_usbphy301 153
sclk_unipro 154
sclk_pwm 155
sclk_gscl_wa 156
sclk_gscl_wb 157
sclk_hdmiphy 158
[Peripheral Clock Gates]
Clock ID
----------------------------
aclk66_peric 256
uart0 257
uart1 258
uart2 259
uart3 260
i2c0 261
i2c1 262
i2c2 263
i2c3 264
i2c4 265
i2c5 266
i2c6 267
i2c7 268
i2c_hdmi 269
tsadc 270
spi0 271
spi1 272
spi2 273
keyif 274
i2s1 275
i2s2 276
pcm1 277
pcm2 278
pwm 279
spdif 280
i2c8 281
i2c9 282
i2c10 283
aclk66_psgen 300
chipid 301
sysreg 302
tzpc0 303
tzpc1 304
tzpc2 305
tzpc3 306
tzpc4 307
tzpc5 308
tzpc6 309
tzpc7 310
tzpc8 311
tzpc9 312
hdmi_cec 313
seckey 314
mct 315
wdt 316
rtc 317
tmu 318
tmu_gpu 319
pclk66_gpio 330
aclk200_fsys2 350
mmc0 351
mmc1 352
mmc2 353
sromc 354
ufs 355
aclk200_fsys 360
tsi 361
pdma0 362
pdma1 363
rtic 364
usbh20 365
usbd300 366
usbd301 377
aclk400_mscl 380
mscl0 381
mscl1 382
mscl2 383
smmu_mscl0 384
smmu_mscl1 385
smmu_mscl2 386
aclk333 400
mfc 401
smmu_mfcl 402
smmu_mfcr 403
aclk200_disp1 410
dsim1 411
dp1 412
hdmi 413
aclk300_disp1 420
fimd1 421
smmu_fimd1 422
aclk166 430
mixer 431
aclk266 440
rotator 441
mdma1 442
smmu_rotator 443
smmu_mdma1 444
aclk300_jpeg 450
jpeg 451
jpeg2 452
smmu_jpeg 453
aclk300_gscl 460
smmu_gscl0 461
smmu_gscl1 462
gscl_wa 463
gscl_wb 464
gscl0 465
gscl1 466
clk_3aa 467
aclk266_g2d 470
sss 471
slim_sss 472
mdma0 473
aclk333_g2d 480
g2d 481
aclk333_432_gscl 490
smmu_3aa 491
smmu_fimcl0 492
smmu_fimcl1 493
smmu_fimcl3 494
fimc_lite3 495
aclk_g3d 500
g3d 501
smmu_mixer 502
Mux ID
----------------------------
mout_hdmi 640
Divider ID
----------------------------
dout_pixel 768
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos5420.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
@ -208,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
clocks = <&clock 259>, <&clock 130>;
clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};

43
Documentation/devicetree/bindings/clock/exynos5440-clock.txt
View File

@ -12,45 +12,12 @@ Required Properties:
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume.
[Core Clocks]
Clock ID
----------------------------
xtal 1
arm_clk 2
[Peripheral Clock Gates]
Clock ID
----------------------------
spi_baud 16
pb0_250 17
pr0_250 18
pr1_250 19
b_250 20
b_125 21
b_200 22
sata 23
usb 24
gmac0 25
cs250 26
pb0_250_o 27
pr0_250_o 28
pr1_250_o 29
b_250_o 30
b_125_o 31
b_200_o 32
sata_o 33
usb_o 34
gmac0_o 35
cs250_o 36
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos5440.h header and can be used in device
tree sources.
Example: An example of a clock controller node is listed below.

1
Documentation/devicetree/bindings/clock/hi3620-clock.txt
View File

@ -7,6 +7,7 @@ Required Properties:
- compatible: should be one of the following.
- "hisilicon,hi3620-clock" - controller compatible with Hi3620 SoC.
- "hisilicon,hi3620-mmc-clock" - controller specific for Hi3620 mmc.
- reg: physical base address of the controller and length of memory mapped
region.

48
Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt Normal file
View File

@ -0,0 +1,48 @@
Device Tree Clock bindings for arch-moxart
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
MOXA ART SoCs allow to determine PLL output and APB frequencies
by reading registers holding multiplier and divisor information.
PLL:
Required properties:
- compatible : Must be "moxa,moxart-pll-clock"
- #clock-cells : Should be 0
- reg : Should contain registers location and length
- clocks : Should contain phandle + clock-specifier for the parent clock
Optional properties:
- clock-output-names : Should contain clock name
APB:
Required properties:
- compatible : Must be "moxa,moxart-apb-clock"
- #clock-cells : Should be 0
- reg : Should contain registers location and length
- clocks : Should contain phandle + clock-specifier for the parent clock
Optional properties:
- clock-output-names : Should contain clock name
For example:
clk_pll: clk_pll@98100000 {
compatible = "moxa,moxart-pll-clock";
#clock-cells = <0>;
reg = <0x98100000 0x34>;
};
clk_apb: clk_apb@98100000 {
compatible = "moxa,moxart-apb-clock";
#clock-cells = <0>;
reg = <0x98100000 0x34>;
clocks = <&clk_pll>;
};

14
Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
View File

@ -11,6 +11,18 @@ The following is a list of provided IDs and clock names on Armada 370/XP:
3 = hclk (DRAM control clock)
4 = dramclk (DDR clock)
The following is a list of provided IDs and clock names on Armada 375:
0 = tclk (Internal Bus clock)
1 = cpuclk (CPU clock)
2 = l2clk (L2 Cache clock)
3 = ddrclk (DDR clock)
The following is a list of provided IDs and clock names on Armada 380/385:
0 = tclk (Internal Bus clock)
1 = cpuclk (CPU clock)
2 = l2clk (L2 Cache clock)
3 = ddrclk (DDR clock)
The following is a list of provided IDs and clock names on Kirkwood and Dove:
0 = tclk (Internal Bus clock)
1 = cpuclk (CPU0 clock)
@ -20,6 +32,8 @@ The following is a list of provided IDs and clock names on Kirkwood and Dove:
Required properties:
- compatible : shall be one of the following:
"marvell,armada-370-core-clock" - For Armada 370 SoC core clocks
"marvell,armada-375-core-clock" - For Armada 375 SoC core clocks
"marvell,armada-380-core-clock" - For Armada 380/385 SoC core clocks
"marvell,armada-xp-core-clock" - For Armada XP SoC core clocks
"marvell,dove-core-clock" - for Dove SoC core clocks
"marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180)

5
Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
View File

@ -4,7 +4,10 @@ The following is a list of provided IDs and clock names on Armada 370/XP:
0 = nand (NAND clock)
Required properties:
- compatible : must be "marvell,armada-370-corediv-clock"
- compatible : must be "marvell,armada-370-corediv-clock",
"marvell,armada-375-corediv-clock",
"marvell,armada-380-corediv-clock",
- reg : must be the register address of Core Divider control register
- #clock-cells : from common clock binding; shall be set to 1
- clocks : must be set to the parent's phandle

65
Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
View File

@ -1,9 +1,10 @@
* Gated Clock bindings for Marvell EBU SoCs
Marvell Armada 370/XP, Dove and Kirkwood allow some peripheral clocks to be
gated to save some power. The clock consumer should specify the desired clock
by having the clock ID in its "clocks" phandle cell. The clock ID is directly
mapped to the corresponding clock gating control bit in HW to ease manual clock
Marvell Armada 370/375/380/385/XP, Dove and Kirkwood allow some
peripheral clocks to be gated to save some power. The clock consumer
should specify the desired clock by having the clock ID in its
"clocks" phandle cell. The clock ID is directly mapped to the
corresponding clock gating control bit in HW to ease manual clock
lookup in datasheet.
The following is a list of provided IDs for Armada 370:
@ -22,6 +23,60 @@ ID Clock Peripheral
28 ddr DDR Cntrl
30 sata1 SATA Host 0
The following is a list of provided IDs for Armada 375:
ID Clock Peripheral
-----------------------------------
2 mu Management Unit
3 pp Packet Processor
4 ptp PTP
5 pex0 PCIe 0 Clock out
6 pex1 PCIe 1 Clock out
8 audio Audio Cntrl
11 nd_clk Nand Flash Cntrl
14 sata0_link SATA 0 Link
15 sata0_core SATA 0 Core
16 usb3 USB3 Host
17 sdio SDHCI Host
18 usb USB Host
19 gop Gigabit Ethernet MAC
20 sata1_link SATA 1 Link
21 sata1_core SATA 1 Core
22 xor0 XOR DMA 0
23 xor1 XOR DMA 0
24 copro Coprocessor
25 tdm Time Division Mplx
28 crypto0_enc Cryptographic Unit Port 0 Encryption
29 crypto0_core Cryptographic Unit Port 0 Core
30 crypto1_enc Cryptographic Unit Port 1 Encryption
31 crypto1_core Cryptographic Unit Port 1 Core
The following is a list of provided IDs for Armada 380/385:
ID Clock Peripheral
-----------------------------------
0 audio Audio
2 ge2 Gigabit Ethernet 2
3 ge1 Gigabit Ethernet 1
4 ge0 Gigabit Ethernet 0
5 pex1 PCIe 1
6 pex2 PCIe 2
7 pex3 PCIe 3
8 pex0 PCIe 0
9 usb3h0 USB3 Host 0
10 usb3h1 USB3 Host 1
11 usb3d USB3 Device
13 bm Buffer Management
14 crypto0z Cryptographic 0 Z
15 sata0 SATA 0
16 crypto1z Cryptographic 1 Z
17 sdio SDIO
18 usb2 USB 2
21 crypto1 Cryptographic 1
22 xor0 XOR 0
23 crypto0 Cryptographic 0
25 tdm Time Division Multiplexing
28 xor1 XOR 1
30 sata1 SATA 1
The following is a list of provided IDs for Armada XP:
ID Clock Peripheral
-----------------------------------
@ -95,6 +150,8 @@ ID Clock Peripheral
Required properties:
- compatible : shall be one of the following:
"marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating
"marvell,armada-375-gating-clock" - for Armada 375 SoC clock gating
"marvell,armada-380-gating-clock" - for Armada 380/385 SoC clock gating
"marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating
"marvell,dove-gating-clock" - for Dove SoC clock gating
"marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating

29
Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt Normal file
View File

@ -0,0 +1,29 @@
* Renesas RZ Clock Pulse Generator (CPG)
The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable
CPU and GPU clocks, and several fixed ratio dividers.
Required Properties:
- compatible: Must be one of
- "renesas,r7s72100-cpg-clocks" for the r7s72100 CPG
- "renesas,rz-cpg-clocks" for the generic RZ CPG
- reg: Base address and length of the memory resource used by the CPG
- clocks: References to possible parent clocks. Order must match clock modes
in the datasheet. For the r7s72100, this is extal, usb_x1.
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "pll",
"i", and "g"
Example
-------
cpg_clocks: cpg_clocks@fcfe0000 {
#clock-cells = <1>;
compatible = "renesas,r7s72100-cpg-clocks",
"renesas,rz-cpg-clocks";
reg = <0xfcfe0000 0x18>;
clocks = <&extal_clk>, <&usb_x1_clk>;
clock-output-names = "pll", "i", "g";
};

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