brain-hackers_pepepper-mirror/linux-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/linux-brain.git synced 2024-06-09 07:16:21 +09:00
Code Issues Projects Releases Wiki Activity

Merge Linus' tree to be be to apply submitted patches to newer code than

Browse Source 
current trivial.git base
This commit is contained in:
Jiri Kosina 2014-11-20 14:42:02 +01:00
commit a02001086b
12063 changed files with 593833 additions and 390844 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -34,6 +34,7 @@
*.gcno
modules.builtin
Module.symvers
*.dwo
#
# Top-level generic files

7
CREDITS
View File

@ -1381,6 +1381,9 @@ S: 17 rue Danton
S: F - 94270 Le Kremlin-Bicêtre
S: France
N: Jack Hammer
D: IBM ServeRAID RAID (ips) driver maintenance
N: Greg Hankins
E: gregh@cc.gatech.edu
D: fixed keyboard driver to separate LED and locking status
@ -1691,6 +1694,10 @@ S: Reading
S: RG6 2NU
S: United Kingdom
N: Dave Jeffery
E: dhjeffery@gmail.com
D: SCSI hacks and IBM ServeRAID RAID driver maintenance
N: Jakub Jelinek
E: jakub@redhat.com
W: http://sunsite.mff.cuni.cz/~jj

7
Documentation/.gitignore vendored
View File

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

2
Documentation/00-INDEX
View File

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

8
Documentation/ABI/removed/net_dma Normal file
View File

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

8
Documentation/ABI/stable/sysfs-devices-node
View File

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

12
Documentation/ABI/testing/configfs-usb-gadget-uac1 Normal file
View File

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

12
Documentation/ABI/testing/configfs-usb-gadget-uac2 Normal file
View File

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

8
Documentation/ABI/testing/sysfs-block
View File

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

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

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

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

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

6
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
View File

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

12
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
View File

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

7
Documentation/ABI/testing/sysfs-bus-iio-accel-bmc150 Normal file
View File

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

7
Documentation/ABI/testing/sysfs-bus-iio-gyro-bmg160 Normal file
View File

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

10
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -65,6 +65,16 @@ Description:
force a rescan of all PCI buses in the system, and
re-discover previously removed devices.
What: /sys/bus/pci/devices/.../msi_bus
Date: September 2014
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
Writing a zero value to this attribute disallows MSI and
MSI-X for any future drivers of the device. If the device
is a bridge, MSI and MSI-X will be disallowed for future
drivers of all child devices under the bridge. Drivers
must be reloaded for the new setting to take effect.
What: /sys/bus/pci/devices/.../msi_irqs/
Date: September, 2011
Contact: Neil Horman <nhorman@tuxdriver.com>

4
Documentation/ABI/testing/sysfs-bus-rbd
View File

@ -94,5 +94,5 @@ current_snap
parent
Information identifying the pool, image, and snapshot id for
the parent image in a layered rbd image (format 2 only).
Information identifying the chain of parent images in a layered rbd
image. Entries are separated by empty lines.

129
Documentation/ABI/testing/sysfs-class-cxl Normal file
View File

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

16
Documentation/ABI/testing/sysfs-class-leds-gt683r Normal file
View File

@ -0,0 +1,16 @@
What: /sys/class/leds/<led>/gt683r/mode
Date: Jun 2014
KernelVersion: 3.17
Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
Description:
Set the mode of LEDs. You should notice that changing the mode
of one LED will update the mode of its two sibling devices as
well.
0 - normal
1 - audio
2 - breathing
Normal: LEDs are fully on when enabled
Audio: LEDs brightness depends on sound level
Breathing: LEDs brightness varies at human breathing rate

38
Documentation/ABI/testing/sysfs-class-mtd
View File

@ -184,3 +184,41 @@ Description:
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/ecc_failures
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of failures reported by this device's ECC. Typically,
these failures are associated with failed read operations.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/corrected_bits
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of bits that have been corrected by means of the
device's ECC.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/bad_blocks
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of blocks marked as bad, if any, in this partition.
What: /sys/class/mtd/mtdX/bbt_blocks
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of blocks that are marked as reserved, if any, in
this partition. These are typically used to store the in-flash
bad block table (BBT).

14
Documentation/ABI/testing/sysfs-class-power
View File

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

13
Documentation/ABI/testing/sysfs-class-uwb_rc
View File

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

8
Documentation/ABI/testing/sysfs-devices-memory
View File

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

13
Documentation/ABI/testing/sysfs-driver-pciback Normal file
View File

@ -0,0 +1,13 @@
What: /sys/bus/pci/drivers/pciback/quirks
Date: Oct 2011
KernelVersion: 3.1
Contact: xen-devel@lists.xenproject.org
Description:
If the permissive attribute is set, then writing a string in
the format of DDDD:BB:DD.F-REG:SIZE:MASK will allow the guest
to write and read from the PCI device. That is Domain:Bus:
Device.Function-Register:Size:Mask (Domain is optional).
For example:
#echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
will allow the guest to read and write to the configuration
register 0x0E.

11
Documentation/ABI/testing/sysfs-driver-tegra-fuse Normal file
View File

@ -0,0 +1,11 @@
What: /sys/devices/*/<our-device>/fuse
Date: February 2014
Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
data programmed at the factory. The data is layed out in 32bit
words in LSB first format. Each bit represents a single value
as decoded from the fuse registers. Bits order/assignment
exactly matches the HW registers, including any unused bits.
Users: any user space application which wants to read the efuses on
Tegra SoC's

70
Documentation/ABI/testing/sysfs-driver-wacom
View File

@ -1,48 +1,27 @@
WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
Date: June 2012
Contact: linux-bluetooth@vger.kernel.org
Description:
The /sys/class/hidraw/hidraw*/device/oled*_img files control
OLED mocro displays on Intuos4 Wireless tablet. Accepted image
has to contain 256 bytes (64x32 px 1 bit colour). The format
is the same as PBM image 62x32px without header (64 bits per
horizontal line, 32 lines). An example of setting OLED No. 0:
dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
The attribute is read only and no local copy of the image is
stored.
What: /sys/class/hidraw/hidraw*/device/speed
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
Date: April 2010
Kernel Version: 2.6.35
Contact: linux-bluetooth@vger.kernel.org
Description:
The /sys/class/hidraw/hidraw*/device/speed file controls
reporting speed of Wacom bluetooth tablet. Reading from
this file returns 1 if tablet reports in high speed mode
The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
controls reporting speed of Wacom bluetooth tablet. Reading
from this file returns 1 if tablet reports in high speed mode
or 0 otherwise. Writing to this file one of these values
switches reporting speed.
What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
Date: May 2012
Kernel Version: 3.5
Contact: linux-bluetooth@vger.kernel.org
Description:
LED selector for Intuos4 WL. There are 4 leds, but only one LED
can be lit at a time. Max brightness is 127.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Attribute group for control of the status LEDs and the OLEDs.
This attribute group is only available for Intuos 4 M, L,
and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
implicitly signifies the presence of said LEDs and OLEDs on the
tablet device.
and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
(LEDs only). Therefore its presence implicitly signifies the
presence of said LEDs and OLEDs on the tablet device.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the status LED luminance (1..127)
@ -50,16 +29,16 @@ Description:
button is pressed on the stylus. This luminance level is
normally lower than the level when a button is pressed.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the status LED luminance (1..127)
when the stylus touches the tablet surface, or any button is
pressed on the stylus.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets which one of the four (for Intuos 4
@ -67,23 +46,23 @@ Description:
24HD) status LEDs is active (0..3). The other three LEDs on the
same side are always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
Date: September 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets which one of the left four (for Cintiq 21UX2
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
the left are always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the overall luminance level (0..15)
of all eight button OLED displays.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
When writing a 1024 byte raw image in Wacom Intuos 4
@ -93,3 +72,8 @@ Description:
byte chunk encodes the image data for two consecutive lines on
the display. The low nibble of each byte contains the first
line, and the high nibble contains the second line.
When the Wacom Intuos 4 is connected over Bluetooth, the
image has to contain 256 bytes (64x32 px 1 bit colour).
The format is also scrambled, like in the USB mode, and it can
be summarized by converting 76543210 into GECA6420.
HGFEDCBA HFDB7531

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

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

269
Documentation/ABI/testing/sysfs-fs-nilfs2 Normal file
View File

@ -0,0 +1,269 @@
What: /sys/fs/nilfs2/features/revision
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show current revision of NILFS file system driver.
This value informs about file system revision that
driver is ready to support.
What: /sys/fs/nilfs2/features/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/features group.
What: /sys/fs/nilfs2/<device>/revision
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show NILFS file system revision on volume.
This value informs about metadata structures'
revision on mounted volume.
What: /sys/fs/nilfs2/<device>/blocksize
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's block size in bytes.
What: /sys/fs/nilfs2/<device>/device_size
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume size in bytes.
What: /sys/fs/nilfs2/<device>/free_blocks
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of free blocks on volume.
What: /sys/fs/nilfs2/<device>/uuid
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's UUID (Universally Unique Identifier).
What: /sys/fs/nilfs2/<device>/volume_name
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's label.
What: /sys/fs/nilfs2/<device>/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device> group.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show last write time of super block in human-readable
format.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show last write time of super block in seconds.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show current write count of super block.
What: /sys/fs/nilfs2/<device>/superblock/sb_update_frequency
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show/Set interval of periodical update of superblock
(in seconds).
What: /sys/fs/nilfs2/<device>/superblock/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/superblock
group.
What: /sys/fs/nilfs2/<device>/segctor/last_pseg_block
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show start block number of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_sequence
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show sequence value of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show checkpoint number of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/current_seg_sequence
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show segment sequence counter.
What: /sys/fs/nilfs2/<device>/segctor/current_last_full_seg
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show index number of the latest full segment.
What: /sys/fs/nilfs2/<device>/segctor/next_full_seg
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show index number of the full segment index
to be used next.
What: /sys/fs/nilfs2/<device>/segctor/next_pseg_offset
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show offset of next partial segment in the current
full segment.
What: /sys/fs/nilfs2/<device>/segctor/next_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show next checkpoint number.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment in
human-readable format.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment in seconds.
What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment not for cleaner
operation in human-readable format.
What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment not for cleaner
operation in seconds.
What: /sys/fs/nilfs2/<device>/segctor/dirty_data_blocks_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of dirty data blocks.
What: /sys/fs/nilfs2/<device>/segctor/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/segctor
group.
What: /sys/fs/nilfs2/<device>/segments/segments_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of segments on a volume.
What: /sys/fs/nilfs2/<device>/segments/blocks_per_segment
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of blocks in segment.
What: /sys/fs/nilfs2/<device>/segments/clean_segments
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of clean segments.
What: /sys/fs/nilfs2/<device>/segments/dirty_segments
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of dirty segments.
What: /sys/fs/nilfs2/<device>/segments/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/segments
group.
What: /sys/fs/nilfs2/<device>/checkpoints/checkpoints_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of checkpoints on volume.
What: /sys/fs/nilfs2/<device>/checkpoints/snapshots_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of snapshots on volume.
What: /sys/fs/nilfs2/<device>/checkpoints/last_seg_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show checkpoint number of the latest segment.
What: /sys/fs/nilfs2/<device>/checkpoints/next_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show next checkpoint number.
What: /sys/fs/nilfs2/<device>/checkpoints/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/checkpoints
group.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe content of /sys/fs/nilfs2/<device>/mounted_snapshots
group.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/inodes_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of inodes for snapshot.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/blocks_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of blocks for snapshot.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/mounted_snapshots/<id>
group.

39
Documentation/ABI/testing/sysfs-fs-xfs Normal file
View File

@ -0,0 +1,39 @@
What: /sys/fs/xfs/<disk>/log/log_head_lsn
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The log sequence number (LSN) of the current head of the
log. The LSN is exported in "cycle:basic block" format.
Users: xfstests
What: /sys/fs/xfs/<disk>/log/log_tail_lsn
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The log sequence number (LSN) of the current tail of the
log. The LSN is exported in "cycle:basic block" format.
What: /sys/fs/xfs/<disk>/log/reserve_grant_head
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The current state of the log reserve grant head. It
represents the total log reservation of all currently
outstanding transactions. The grant head is exported in
"cycle:bytes" format.
Users: xfstests
What: /sys/fs/xfs/<disk>/log/write_grant_head
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The current state of the log write grant head. It
represents the total log reservation of all currently
oustanding transactions, including regrants due to
rolling transactions. The grant head is exported in
"cycle:bytes" format.
Users: xfstests

2
Documentation/ABI/testing/sysfs-ibft
View File

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

6
Documentation/DMA-API-HOWTO.txt
View File

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

107
Documentation/DocBook/drm.tmpl
View File

@ -291,10 +291,9 @@ char *date;</synopsis>
<title>Device Registration</title>
<para>
A number of functions are provided to help with device registration.
The functions deal with PCI, USB and platform devices, respectively.
The functions deal with PCI and platform devices, respectively.
</para>
!Edrivers/gpu/drm/drm_pci.c
!Edrivers/gpu/drm/drm_usb.c
!Edrivers/gpu/drm/drm_platform.c
<para>
New drivers that no longer rely on the services provided by the
@ -315,7 +314,7 @@ char *date;</synopsis>
<function>drm_dev_unregister()</function> followed by a call to
<function>drm_dev_unref()</function>.
</para>
!Edrivers/gpu/drm/drm_stub.c
!Edrivers/gpu/drm/drm_drv.c
</sect2>
<sect2>
<title>Driver Load</title>
@ -1610,7 +1609,7 @@ int max_width, max_height;</synopsis>
The connector is then registered with a call to
<function>drm_connector_init</function> with a pointer to the connector
functions and a connector type, and exposed through sysfs with a call to
<function>drm_sysfs_connector_add</function>.
<function>drm_connector_register</function>.
</para>
<para>
Supported connector types are
@ -1768,7 +1767,7 @@ int max_width, max_height;</synopsis>
(<function>drm_encoder_cleanup</function>) and connectors
(<function>drm_connector_cleanup</function>). Furthermore, connectors
that have been added to sysfs must be removed by a call to
<function>drm_sysfs_connector_remove</function> before calling
<function>drm_connector_unregister</function> before calling
<function>drm_connector_cleanup</function>.
</para>
<para>
@ -1813,7 +1812,7 @@ void intel_crt_init(struct drm_device *dev)
drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs);
drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
drm_sysfs_connector_add(connector);
drm_connector_register(connector);
}]]></programlisting>
<para>
In the example above (taken from the i915 driver), a CRTC, connector and
@ -2336,6 +2335,12 @@ void intel_crt_init(struct drm_device *dev)
!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
!Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
<sect2>
<title>Display Port MST Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
!Iinclude/drm/drm_dp_mst_helper.h
!Edrivers/gpu/drm/drm_dp_mst_topology.c
</sect2>
<sect2>
<title>EDID Helper Functions Reference</title>
@ -2502,7 +2507,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Description/Restrictions</td>
</tr>
<tr>
<td rowspan="20" valign="top" >DRM</td>
<td rowspan="21" valign="top" >DRM</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“EDID”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
@ -2633,7 +2638,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >Optional</td>
<td rowspan="3" valign="top" >Optional</td>
<td valign="top" >“scaling mode”</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
@ -2641,6 +2646,15 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >"aspect ratio"</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "None", "4:3", "16:9" }</td>
<td valign="top" >Connector</td>
<td valign="top" >DRM property to set aspect ratio from user space app.
This enum is made generic to allow addition of custom aspect
ratios.</td>
</tr>
<tr>
<td valign="top" >“dirty”</td>
<td valign="top" >ENUM | IMMUTABLE</td>
<td valign="top" >{ "Off", "On", "Annotate" }</td>
@ -2649,7 +2663,7 @@ void intel_crt_init(struct drm_device *dev)
</tr>
<tr>
<td rowspan="21" valign="top" >i915</td>
<td rowspan="3" valign="top" >Generic</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >"Broadcast RGB"</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td>
@ -2664,10 +2678,11 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td rowspan="1" valign="top" >Plane</td>
<td valign="top" >“rotation”</td>
<td valign="top" >BITMASK</td>
<td valign="top" >{ 0, "rotate-0" }, { 2, "rotate-180" }</td>
<td valign="top" >Plane</td>
<td valign="top" >TBD</td>
</tr>
<tr>
@ -2799,8 +2814,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="3" valign="top" >CDV gma-500</td>
<td rowspan="3" valign="top" >Generic</td>
<td rowspan="2" valign="top" >CDV gma-500</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >"Broadcast RGB"</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ “Full”, “Limited 16:235” }</td>
@ -2815,15 +2830,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="20" valign="top" >Poulsbo</td>
<td rowspan="2" valign="top" >Generic</td>
<td rowspan="19" valign="top" >Poulsbo</td>
<td rowspan="1" valign="top" >Generic</td>
<td valign="top" >“backlight”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=100</td>
@ -2831,13 +2839,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="17" valign="top" >SDVO-TV</td>
<td valign="top" >“mode”</td>
<td valign="top" >ENUM</td>
@ -3064,7 +3065,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="3" valign="top" >i2c/ch7006_drv</td>
<td rowspan="2" valign="top" >i2c/ch7006_drv</td>
<td valign="top" >Generic</td>
<td valign="top" >“scale”</td>
<td valign="top" >RANGE</td>
@ -3073,14 +3074,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >TV</td>
<td valign="top" >Standard names as in DRM</td>
<td valign="top" >Standard types as in DRM</td>
<td valign="top" >Standard Values as in DRM</td>
<td valign="top" >Standard object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="1" valign="top" >TV</td>
<td valign="top" >“mode”</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc"
@ -3089,7 +3083,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="16" valign="top" >nouveau</td>
<td rowspan="15" valign="top" >nouveau</td>
<td rowspan="6" valign="top" >NV10 Overlay</td>
<td valign="top" >"colorkey"</td>
<td valign="top" >RANGE</td>
@ -3198,14 +3192,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Generic</td>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >omap</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“rotation”</td>
@ -3236,7 +3222,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="10" valign="top" >radeon</td>
<td rowspan="9" valign="top" >radeon</td>
<td valign="top" >DVI-I</td>
<td valign="top" >“coherent”</td>
<td valign="top" >RANGE</td>
@ -3308,14 +3294,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Generic</td>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="3" valign="top" >rcar-du</td>
<td rowspan="3" valign="top" >Generic</td>
<td valign="top" >"alpha"</td>
@ -3407,6 +3385,13 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
by scheduling a timer. The delay is accessible through the vblankoffdelay
module parameter or the <varname>drm_vblank_offdelay</varname> global
variable and expressed in milliseconds. Its default value is 5000 ms.
Zero means never disable, and a negative value means disable immediately.
Drivers may override the behaviour by setting the
<structname>drm_device</structname>
<structfield>vblank_disable_immediate</structfield> flag, which when set
causes vblank interrupts to be disabled immediately regardless of the
drm_vblank_offdelay value. The flag should only be set if there's a
properly working hardware vblank counter present.
</para>
<para>
When a vertical blanking interrupt occurs drivers only need to call the
@ -3421,6 +3406,7 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
<sect2>
<title>Vertical Blanking and Interrupt Handling Functions Reference</title>
!Edrivers/gpu/drm/drm_irq.c
!Finclude/drm/drmP.h drm_crtc_vblank_waitqueue
</sect2>
</sect1>
@ -3939,6 +3925,11 @@ int num_ioctls;</synopsis>
!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
!Idrivers/gpu/drm/i915/i915_cmd_parser.c
</sect2>
<sect2>
<title>Logical Rings, Logical Ring Contexts and Execlists</title>
!Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists
!Idrivers/gpu/drm/i915/intel_lrc.c
</sect2>
</sect1>
</chapter>
</part>

2
Documentation/DocBook/kernel-locking.tmpl
View File

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

2
Documentation/DocBook/media/Makefile
View File

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

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

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

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

@ -2545,6 +2545,40 @@ fields changed from _s32 to _u32.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.16</title>
<orderedlist>
<listitem>
<para>Added event V4L2_EVENT_SOURCE_CHANGE.
</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.17</title>
<orderedlist>
<listitem>
<para>Extended &v4l2-pix-format;. Added format flags.
</para>
</listitem>
<listitem>
<para>Added compound control types and &VIDIOC-QUERY-EXT-CTRL;.
</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.18</title>
<orderedlist>
<listitem>
<para>Added <constant>V4L2_CID_PAN_SPEED</constant> and
<constant>V4L2_CID_TILT_SPEED</constant> camera controls.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>

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

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

35
Documentation/DocBook/media/v4l/func-poll.xml
View File

@ -29,9 +29,12 @@ can suspend execution until the driver has captured data or is ready
to accept data for output.</para>
<para>When streaming I/O has been negotiated this function waits
until a buffer has been filled or displayed and can be dequeued with
the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing
queue of the driver the function returns immediately.</para>
until a buffer has been filled by the capture device and can be dequeued
with the &VIDIOC-DQBUF; ioctl. For output devices this function waits
until the device is ready to accept a new buffer to be queued up with
the &VIDIOC-QBUF; ioctl for display. When buffers are already in the outgoing
queue of the driver (capture) or the incoming queue isn't full (display)
the function returns immediately.</para>
<para>On success <function>poll()</function> returns the number of
file descriptors that have been selected (that is, file descriptors
@ -44,10 +47,22 @@ Capture devices set the <constant>POLLIN</constant> and
flags. When the function timed out it returns a value of zero, on
failure it returns <returnvalue>-1</returnvalue> and the
<varname>errno</varname> variable is set appropriately. When the
application did not call &VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the
application did not call &VIDIOC-STREAMON; the
<function>poll()</function> function succeeds, but sets the
<constant>POLLERR</constant> flag in the
<structfield>revents</structfield> field.</para>
<structfield>revents</structfield> field. When the
application has called &VIDIOC-STREAMON; for a capture device but hasn't
yet called &VIDIOC-QBUF;, the <function>poll()</function> function
succeeds and sets the <constant>POLLERR</constant> flag in the
<structfield>revents</structfield> field. For output devices this
same situation will cause <function>poll()</function> to succeed
as well, but it sets the <constant>POLLOUT</constant> and
<constant>POLLWRNORM</constant> flags in the <structfield>revents</structfield>
field.</para>
<para>If an event occurred (see &VIDIOC-DQEVENT;) then
<constant>POLLPRI</constant> will be set in the <structfield>revents</structfield>
field and <function>poll()</function> will return.</para>
<para>When use of the <function>read()</function> function has
been negotiated and the driver does not capture yet, the
@ -58,10 +73,18 @@ continuously (as opposed to, for example, still images) the function
may return immediately.</para>
<para>When use of the <function>write()</function> function has
been negotiated the <function>poll</function> function just waits
been negotiated and the driver does not stream yet, the
<function>poll</function> function starts streaming. When that fails
it returns a <constant>POLLERR</constant> as above. Otherwise it waits
until the driver is ready for a non-blocking
<function>write()</function> call.</para>
<para>If the caller is only interested in events (just
<constant>POLLPRI</constant> is set in the <structfield>events</structfield>
field), then <function>poll()</function> will <emphasis>not</emphasis>
start streaming if the driver does not stream yet. This makes it
possible to just poll for events and not for buffers.</para>
<para>All drivers implementing the <function>read()</function> or
<function>write()</function> function or streaming I/O must also
support the <function>poll()</function> function.</para>

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

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

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

@ -152,10 +152,11 @@ structs, ioctls) must be noted in more detail in the history chapter
applications. -->
<revision>
<revnumber>3.16</revnumber>
<date>2014-05-27</date>
<authorinitials>lp</authorinitials>
<revremark>Extended &v4l2-pix-format;. Added format flags.
<revnumber>3.17</revnumber>
<date>2014-08-04</date>
<authorinitials>lp, hv</authorinitials>
<revremark>Extended &v4l2-pix-format;. Added format flags. Added compound control types
and VIDIOC_QUERY_EXT_CTRL.
</revremark>
</revision>
@ -538,7 +539,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.14</subtitle>
<subtitle>Revision 3.17</subtitle>
<chapter id="common">
&sub-common;

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

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

14
Documentation/DocBook/media/v4l/vidioc-g-edid.xml
View File

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

2
Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
View File

@ -119,7 +119,7 @@
</row>
<row>
<entry>&v4l2-rect;</entry>
<entry><structfield>rect</structfield></entry>
<entry><structfield>r</structfield></entry>
<entry>Selection rectangle, in pixels.</entry>
</row>
<row>

2
Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
View File

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

2
Documentation/DocBook/usb.tmpl
View File

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

28
Documentation/DocBook/writing-an-alsa-driver.tmpl
View File

@ -2742,7 +2742,9 @@ struct _snd_pcm_runtime {
<para>
Another note is that this callback is non-atomic
(schedulable). This is important, because the
(schedulable) as default, i.e. when no
<structfield>nonatomic</structfield> flag set.
This is important, because the
<structfield>trigger</structfield> callback
is atomic (non-schedulable). That is, mutexes or any
schedule-related functions are not available in
@ -2900,8 +2902,9 @@ struct _snd_pcm_runtime {
</para>
<para>
As mentioned, this callback is atomic. You cannot call
functions which may sleep.
As mentioned, this callback is atomic as default unless
<structfield>nonatomic</structfield> flag set, and
you cannot call functions which may sleep.
The trigger callback should be as minimal as possible,
just really triggering the DMA. The other stuff should be
initialized hw_params and prepare callbacks properly
@ -2936,7 +2939,7 @@ struct _snd_pcm_runtime {
</para>
<para>
This callback is also atomic.
This callback is also atomic as default.
</para>
</section>
@ -2972,7 +2975,7 @@ struct _snd_pcm_runtime {
is useful only for such a purpose.
</para>
<para>
This callback is atomic.
This callback is atomic as default.
</para>
</section>
@ -3175,6 +3178,21 @@ struct _snd_pcm_runtime {
called with local interrupts disabled.
</para>
<para>
The recent changes in PCM core code, however, allow all PCM
operations to be non-atomic. This assumes that the all caller
sides are in non-atomic contexts. For example, the function
<function>snd_pcm_period_elapsed()</function> is called
typically from the interrupt handler. But, if you set up the
driver to use a threaded interrupt handler, this call can be in
non-atomic context, too. In such a case, you can set
<structfield>nonatomic</structfield> filed of
<structname>snd_pcm</structname> object after creating it.
When this flag is set, mutex and rwsem are used internally in
the PCM core instead of spin and rwlocks, so that you can call
all PCM functions safely in a non-atomic context.
</para>
</section>
<section id="pcm-interface-constraints">
<title>Constraints</title>

1
Documentation/HOWTO
View File

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

7
Documentation/Makefile
View File

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

33
Documentation/RCU/stallwarn.txt
View File

@ -56,8 +56,20 @@ RCU_STALL_RAT_DELAY
two jiffies. (This is a cpp macro, not a kernel configuration
parameter.)
When a CPU detects that it is stalling, it will print a message similar
to the following:
rcupdate.rcu_task_stall_timeout
This boot/sysfs parameter controls the RCU-tasks stall warning
interval. A value of zero or less suppresses RCU-tasks stall
warnings. A positive value sets the stall-warning interval
in jiffies. An RCU-tasks stall warning starts wtih the line:
INFO: rcu_tasks detected stalls on tasks:
And continues with the output of sched_show_task() for each
task stalling the current RCU-tasks grace period.
For non-RCU-tasks flavors of RCU, when a CPU detects that it is stalling,
it will print a message similar to the following:
INFO: rcu_sched_state detected stall on CPU 5 (t=2500 jiffies)
@ -174,8 +186,12 @@ o A CPU looping with preemption disabled. This condition can
o A CPU looping with bottom halves disabled. This condition can
result in RCU-sched and RCU-bh stalls.
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel
without invoking schedule().
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the
kernel without invoking schedule(). Note that cond_resched()
does not necessarily prevent RCU CPU stall warnings. Therefore,
if the looping in the kernel is really expected and desirable
behavior, you might need to replace some of the cond_resched()
calls with calls to cond_resched_rcu_qs().
o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
happen to preempt a low-priority task in the middle of an RCU
@ -208,11 +224,10 @@ o A hardware failure. This is quite unlikely, but has occurred
This resulted in a series of RCU CPU stall warnings, eventually
leading the realization that the CPU had failed.
The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.
SRCU does not have its own CPU stall warnings, but its calls to
synchronize_sched() will result in RCU-sched detecting RCU-sched-related
CPU stalls. Please note that RCU only detects CPU stalls when there is
a grace period in progress. No grace period, no CPU stall warnings.
The RCU, RCU-sched, RCU-bh, and RCU-tasks implementations have CPU stall
warning. Note that SRCU does -not- have CPU stall warnings. Please note
that RCU only detects CPU stalls when there is a grace period in progress.
No grace period, no CPU stall warnings.
To diagnose the cause of the stall, inspect the stack traces.
The offending function will usually be near the top of the stack.

2
Documentation/RCU/whatisRCU.txt
View File

@ -818,7 +818,7 @@ RCU pointer/list update:
list_add_tail_rcu
list_del_rcu
list_replace_rcu
hlist_add_after_rcu
hlist_add_behind_rcu
hlist_add_before_rcu
hlist_add_head_rcu
hlist_del_rcu

47
Documentation/SubmittingPatches
View File

@ -84,18 +84,42 @@ is another popular alternative.
2) Describe your changes.
Describe the technical detail of the change(s) your patch includes.
Describe your problem. Whether your patch is a one-line bug fix or
5000 lines of a new feature, there must be an underlying problem that
motivated you to do this work. Convince the reviewer that there is a
problem worth fixing and that it makes sense for them to read past the
first paragraph.
Be as specific as possible. The WORST descriptions possible include
things like "update driver X", "bug fix for driver X", or "this patch
includes updates for subsystem X. Please apply."
Describe user-visible impact. Straight up crashes and lockups are
pretty convincing, but not all bugs are that blatant. Even if the
problem was spotted during code review, describe the impact you think
it can have on users. Keep in mind that the majority of Linux
installations run kernels from secondary stable trees or
vendor/product-specific trees that cherry-pick only specific patches
from upstream, so include anything that could help route your change
downstream: provoking circumstances, excerpts from dmesg, crash
descriptions, performance regressions, latency spikes, lockups, etc.
Quantify optimizations and trade-offs. If you claim improvements in
performance, memory consumption, stack footprint, or binary size,
include numbers that back them up. But also describe non-obvious
costs. Optimizations usually aren't free but trade-offs between CPU,
memory, and readability; or, when it comes to heuristics, between
different workloads. Describe the expected downsides of your
optimization so that the reviewer can weigh costs against benefits.
Once the problem is established, describe what you are actually doing
about it in technical detail. It's important to describe the change
in plain English for the reviewer to verify that the code is behaving
as you intend it to.
The maintainer will thank you if you write your patch description in a
form which can be easily pulled into Linux's source code management
system, git, as a "commit log". See #15, below.
If your description starts to get long, that's a sign that you probably
need to split up your patch. See #3, next.
Solve only one problem per patch. If your description starts to get
long, that's a sign that you probably need to split up your patch.
See #3, next.
When you submit or resubmit a patch or patch series, include the
complete patch description and justification for it. Don't just
@ -459,12 +483,10 @@ have been included in the discussion
14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
If this patch fixes a problem reported by somebody else, consider adding a
Reported-by: tag to credit the reporter for their contribution. Please
note that this tag should not be added without the reporter's permission,
especially if the problem was not reported in a public forum. That said,
if we diligently credit our bug reporters, they will, hopefully, be
inspired to help us again in the future.
The Reported-by tag gives credit to people who find bugs and report them and it
hopefully inspires them to help us again in the future. Please note that if
the bug was reported in private, then ask for permission first before using the
Reported-by tag.
A Tested-by: tag indicates that the patch has been successfully tested (in
some environment) by the person named. This tag informs maintainers that
@ -770,6 +792,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
<http://www.kroah.com/log/linux/maintainer-03.html>
<http://www.kroah.com/log/linux/maintainer-04.html>
<http://www.kroah.com/log/linux/maintainer-05.html>
<http://www.kroah.com/log/linux/maintainer-06.html>
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
<https://lkml.org/lkml/2005/7/11/336>

3
Documentation/accounting/Makefile
View File

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

27
Documentation/acpi/enumeration.txt
View File

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

52
Documentation/arm/CCN.txt Normal file
View File

@ -0,0 +1,52 @@
ARM Cache Coherent Network
==========================
CCN-504 is a ring-bus interconnect consisting of 11 crosspoints
(XPs), with each crosspoint supporting up to two device ports,
so nodes (devices) 0 and 1 are connected to crosspoint 0,
nodes 2 and 3 to crosspoint 1 etc.
PMU (perf) driver
-----------------
The CCN driver registers a perf PMU driver, which provides
description of available events and configuration options
in sysfs, see /sys/bus/event_source/devices/ccn*.
The "format" directory describes format of the config, config1
and config2 fields of the perf_event_attr structure. The "events"
directory provides configuration templates for all documented
events, that can be used with perf tool. For example "xp_valid_flit"
is an equivalent of "type=0x8,event=0x4". Other parameters must be
explicitly specified. For events originating from device, "node"
defines its index. All crosspoint events require "xp" (index),
"port" (device port number) and "vc" (virtual channel ID) and
"dir" (direction). Watchpoints (special "event" value 0xfe) also
require comparator values ("cmp_l" and "cmp_h") and "mask", being
index of the comparator mask.
Masks are defined separately from the event description
(due to limited number of the config values) in the "cmp_mask"
directory, with first 8 configurable by user and additional
4 hardcoded for the most frequent use cases.
Cycle counter is described by a "type" value 0xff and does
not require any other settings.
Example of perf tool use:
/ # perf list | grep ccn
ccn/cycles/ [Kernel PMU event]
<...>
ccn/xp_valid_flit/ [Kernel PMU event]
<...>
/ # perf stat -C 0 -e ccn/cycles/,ccn/xp_valid_flit,xp=1,port=0,vc=1,dir=1/ \
sleep 1
The driver does not support sampling, therefore "perf record" will
not work. Also notice that only single cpu is being selected
("-C 0") - this is because perf framework does not support
"non-CPU related" counters (yet?) so system-wide session ("-a")
would try (and in most cases fail) to set up the same event
per each CPU.

1
Documentation/arm/Makefile Normal file
View File

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

27
Documentation/arm/Marvell/README
View File

@ -53,8 +53,8 @@ Kirkwood family
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
Core: Feroceon ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-kirkwood
Linux kernel plat directory: arch/arm/plat-orion
Linux kernel mach directory: arch/arm/mach-mvebu
Linux kernel plat directory: none
Discovery family
----------------
@ -83,7 +83,9 @@ EBU Armada family
88F6710
88F6707
88F6W11
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
Armada 375 Flavors:
88F6720
@ -100,8 +102,11 @@ EBU Armada family
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
No public datasheet available.
Functional Spec: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
Hardware Specs:
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core: Sheeva ARMv7 compatible
@ -135,7 +140,9 @@ Dove family (application processor)
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
Homepage: http://www.marvell.com/application-processors/armada-500/
Core: ARMv7 compatible
Directory: arch/arm/mach-dove
Directory: arch/arm/mach-mvebu (DT enabled platforms)
arch/arm/mach-dove (non-DT enabled platforms)
PXA 2xx/3xx/93x/95x family
--------------------------
@ -253,10 +260,10 @@ Berlin family (Digital Entertainment)
Long-term plans
---------------
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and
mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the
Marvell EBU (Engineering Business Unit) in a single mach-<foo>
directory. The plat-orion/ would therefore disappear.
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the
mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering
Business Unit) in a single mach-<foo> directory. The plat-orion/
would therefore disappear.
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
directory. The plat-pxa/ would therefore disappear.

1
Documentation/arm/SH-Mobile/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
vrl4

11
Documentation/arm/SH-Mobile/Makefile
View File

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

7
Documentation/arm/SH-Mobile/vrl4.c
View File

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

11
Documentation/arm/Samsung/Overview.txt
View File

@ -13,8 +13,6 @@ Introduction
- S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
- S3C64XX: S3C6400 and S3C6410
- S5P6440
- S5PC100
- S5PC110 / S5PV210
@ -34,8 +32,6 @@ Configuration
A number of configurations are supplied, as there is no current way of
unifying all the SoCs into one kernel.
s5p6440_defconfig - S5P6440 specific default configuration
s5pc100_defconfig - S5PC100 specific default configuration
s5pc110_defconfig - S5PC110 specific default configuration
s5pv210_defconfig - S5PV210 specific default configuration
@ -67,13 +63,6 @@ Layout changes
where to simplify the include and dependency issues involved with having
so many different platform directories.
It was decided to remove plat-s5pc1xx as some of the support was already
in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210
the only user was the S5PC100. The S5PC100 specific items where moved to
arch/arm/mach-s5pc100.
Port Contributors
-----------------

1
Documentation/arm/Samsung/clksrc-change-registers.awk
View File

@ -68,7 +68,6 @@ BEGIN {
while (getline line < ARGV[1] > 0) {
if (line ~ /\#define.*_MASK/ &&
!(line ~ /S5PC100_EPLL_MASK/) &&
!(line ~ /USB_SIG_MASK/)) {
splitdefine(line, fields)
name = fields[0]

8
Documentation/arm64/booting.txt
View File

@ -168,6 +168,14 @@ Before jumping into the kernel, the following conditions must be met:
the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state.
For systems with a GICv3 interrupt controller:
- If EL3 is present:
ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
- If the kernel is entered at EL1:
ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level.

2
Documentation/arm64/memory.txt
View File

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

3
Documentation/auxdisplay/Makefile
View File

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

50
Documentation/binfmt_misc.txt
View File

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

7
Documentation/blackfin/Makefile
View File

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

54
Documentation/block/data-integrity.txt
View File

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

25
Documentation/blockdev/zram.txt
View File

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

6
Documentation/cgroups/cpusets.txt
View File

@ -345,14 +345,14 @@ the named feature on.
The implementation is simple.
Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently
joins that cpuset. The page allocation calls for the page cache
is modified to perform an inline check for this PF_SPREAD_PAGE task
is modified to perform an inline check for this PFA_SPREAD_PAGE task
flag, and if set, a call to a new routine cpuset_mem_spread_node()
returns the node to prefer for the allocation.
Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate
pages from the node returned by cpuset_mem_spread_node().
The cpuset_mem_spread_node() routine is also simple. It uses the

158
Documentation/cgroups/memcg_test.txt
View File

@ -24,64 +24,27 @@ Please note that implementation details can be changed.
a page/swp_entry may be charged (usage += PAGE_SIZE) at
mem_cgroup_charge_anon()
Called at new page fault and Copy-On-Write.
mem_cgroup_try_charge_swapin()
Called at do_swap_page() (page fault on swap entry) and swapoff.
Followed by charge-commit-cancel protocol. (With swap accounting)
At commit, a charge recorded in swap_cgroup is removed.
mem_cgroup_charge_file()
Called at add_to_page_cache()
mem_cgroup_cache_charge_swapin()
Called at shmem's swapin.
mem_cgroup_prepare_migration()
Called before migration. "extra" charge is done and followed by
charge-commit-cancel protocol.
At commit, charge against oldpage or newpage will be committed.
mem_cgroup_try_charge()
2. Uncharge
a page/swp_entry may be uncharged (usage -= PAGE_SIZE) by
mem_cgroup_uncharge_page()
Called when an anonymous page is fully unmapped. I.e., mapcount goes
to 0. If the page is SwapCache, uncharge is delayed until
mem_cgroup_uncharge_swapcache().
mem_cgroup_uncharge_cache_page()
Called when a page-cache is deleted from radix-tree. If the page is
SwapCache, uncharge is delayed until mem_cgroup_uncharge_swapcache().
mem_cgroup_uncharge_swapcache()
Called when SwapCache is removed from radix-tree. The charge itself
is moved to swap_cgroup. (If mem+swap controller is disabled, no
charge to swap occurs.)
mem_cgroup_uncharge()
Called when a page's refcount goes down to 0.
mem_cgroup_uncharge_swap()
Called when swp_entry's refcnt goes down to 0. A charge against swap
disappears.
mem_cgroup_end_migration(old, new)
At success of migration old is uncharged (if necessary), a charge
to new page is committed. At failure, charge to old page is committed.
3. charge-commit-cancel
In some case, we can't know this "charge" is valid or not at charging
(because of races).
To handle such case, there are charge-commit-cancel functions.
mem_cgroup_try_charge_XXX
mem_cgroup_commit_charge_XXX
mem_cgroup_cancel_charge_XXX
these are used in swap-in and migration.
Memcg pages are charged in two steps:
mem_cgroup_try_charge()
mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
At try_charge(), there are no flags to say "this page is charged".
at this point, usage += PAGE_SIZE.
At commit(), the function checks the page should be charged or not
and set flags or avoid charging.(usage -= PAGE_SIZE)
At commit(), the page is associated with the memcg.
At cancel(), simply usage -= PAGE_SIZE.
@ -91,18 +54,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
Anonymous page is newly allocated at
- page fault into MAP_ANONYMOUS mapping.
- Copy-On-Write.
It is charged right after it's allocated before doing any page table
related operations. Of course, it's uncharged when another page is used
for the fault address.
At freeing anonymous page (by exit() or munmap()), zap_pte() is called
and pages for ptes are freed one by one.(see mm/memory.c). Uncharges
are done at page_remove_rmap() when page_mapcount() goes down to 0.
Another page freeing is by page-reclaim (vmscan.c) and anonymous
pages are swapped out. In this case, the page is marked as
PageSwapCache(). uncharge() routine doesn't uncharge the page marked
as SwapCache(). It's delayed until __delete_from_swap_cache().
4.1 Swap-in.
At swap-in, the page is taken from swap-cache. There are 2 cases.
@ -111,41 +62,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
(b) If the SwapCache has been mapped by processes, it has been
charged already.
This swap-in is one of the most complicated work. In do_swap_page(),
following events occur when pte is unchanged.
(1) the page (SwapCache) is looked up.
(2) lock_page()
(3) try_charge_swapin()
(4) reuse_swap_page() (may call delete_swap_cache())
(5) commit_charge_swapin()
(6) swap_free().
Considering following situation for example.
(A) The page has not been charged before (2) and reuse_swap_page()
doesn't call delete_from_swap_cache().
(B) The page has not been charged before (2) and reuse_swap_page()
calls delete_from_swap_cache().
(C) The page has been charged before (2) and reuse_swap_page() doesn't
call delete_from_swap_cache().
(D) The page has been charged before (2) and reuse_swap_page() calls
delete_from_swap_cache().
memory.usage/memsw.usage changes to this page/swp_entry will be
Case (A) (B) (C) (D)
Event
Before (2) 0/ 1 0/ 1 1/ 1 1/ 1
===========================================
(3) +1/+1 +1/+1 +1/+1 +1/+1
(4) - 0/ 0 - -1/ 0
(5) 0/-1 0/ 0 -1/-1 0/ 0
(6) - 0/-1 - 0/-1
===========================================
Result 1/ 1 1/ 1 1/ 1 1/ 1
In any cases, charges to this page should be 1/ 1.
4.2 Swap-out.
At swap-out, typical state transition is below.
@ -158,28 +74,20 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
swp_entry's refcnt -= 1.
At (b), the page is marked as SwapCache and not uncharged.
At (d), the page is removed from SwapCache and a charge in page_cgroup
is moved to swap_cgroup.
Finally, at task exit,
(e) zap_pte() is called and swp_entry's refcnt -=1 -> 0.
Here, a charge in swap_cgroup disappears.
5. Page Cache
Page Cache is charged at
- add_to_page_cache_locked().
uncharged at
- __remove_from_page_cache().
The logic is very clear. (About migration, see below)
Note: __remove_from_page_cache() is called by remove_from_page_cache()
and __remove_mapping().
6. Shmem(tmpfs) Page Cache
Memcg's charge/uncharge have special handlers of shmem. The best way
to understand shmem's page state transition is to read mm/shmem.c.
The best way to understand shmem's page state transition is to read
mm/shmem.c.
But brief explanation of the behavior of memcg around shmem will be
helpful to understand the logic.
@ -192,56 +100,10 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
It's charged when...
- A new page is added to shmem's radix-tree.
- A swp page is read. (move a charge from swap_cgroup to page_cgroup)
It's uncharged when
- A page is removed from radix-tree and not SwapCache.
- When SwapCache is removed, a charge is moved to swap_cgroup.
- When swp_entry's refcnt goes down to 0, a charge in swap_cgroup
disappears.
7. Page Migration
One of the most complicated functions is page-migration-handler.
Memcg has 2 routines. Assume that we are migrating a page's contents
from OLDPAGE to NEWPAGE.
Usual migration logic is..
(a) remove the page from LRU.
(b) allocate NEWPAGE (migration target)
(c) lock by lock_page().
(d) unmap all mappings.
(e-1) If necessary, replace entry in radix-tree.
(e-2) move contents of a page.
(f) map all mappings again.
(g) pushback the page to LRU.
(-) OLDPAGE will be freed.
Before (g), memcg should complete all necessary charge/uncharge to
NEWPAGE/OLDPAGE.
The point is....
- If OLDPAGE is anonymous, all charges will be dropped at (d) because
try_to_unmap() drops all mapcount and the page will not be
SwapCache.
- If OLDPAGE is SwapCache, charges will be kept at (g) because
__delete_from_swap_cache() isn't called at (e-1)
- If OLDPAGE is page-cache, charges will be kept at (g) because
remove_from_swap_cache() isn't called at (e-1)
memcg provides following hooks.
- mem_cgroup_prepare_migration(OLDPAGE)
Called after (b) to account a charge (usage += PAGE_SIZE) against
memcg which OLDPAGE belongs to.
- mem_cgroup_end_migration(OLDPAGE, NEWPAGE)
Called after (f) before (g).
If OLDPAGE is used, commit OLDPAGE again. If OLDPAGE is already
charged, a charge by prepare_migration() is automatically canceled.
If NEWPAGE is used, commit NEWPAGE and uncharge OLDPAGE.
But zap_pte() (by exit or munmap) can be called while migration,
we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
mem_cgroup_migrate()
8. LRU
Each memcg has its own private LRU. Now, its handling is under global

4
Documentation/development-process/2.Process
View File

@ -289,10 +289,6 @@ lists when they are assembled; they can be downloaded from:
http://www.kernel.org/pub/linux/kernel/next/
Some information about linux-next has been gathered at:
http://linux.f-seidel.de/linux-next/pmwiki/
Linux-next has become an integral part of the kernel development process;
all patches merged during a given merge window should really have found
their way into linux-next some time before the merge window opens.

4
Documentation/development-process/8.Conclusion
View File

@ -22,10 +22,6 @@ Beyond that, a valuable resource for kernel developers is:
http://kernelnewbies.org/
Information about the linux-next tree gathers at:
http://linux.f-seidel.de/linux-next/pmwiki/
And, of course, one should not forget http://kernel.org/, the definitive
location for kernel release information.

12
Documentation/device-mapper/switch.txt
View File

@ -106,6 +106,11 @@ which paths.
The path number in the range 0 ... (<num_paths> - 1).
Expressed in hexadecimal (WITHOUT any prefix like 0x).
R<n>,<m>
This parameter allows repetitive patterns to be loaded quickly. <n> and <m>
are hexadecimal numbers. The last <n> mappings are repeated in the next <m>
slots.
Status
======
@ -124,3 +129,10 @@ Create a switch device with 64kB region size:
Set mappings for the first 7 entries to point to devices switch0, switch1,
switch2, switch0, switch1, switch2, switch1:
dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1
Set repetitive mapping. This command:
dmsetup message switch 0 set_region_mappings 1000:1 :2 R2,10
is equivalent to:
dmsetup message switch 0 set_region_mappings 1000:1 :2 :1 :2 :1 :2 :1 :2 \
:1 :2 :1 :2 :1 :2 :1 :2 :1 :2

7
Documentation/devicetree/bindings/arm/adapteva.txt Normal file
View File

@ -0,0 +1,7 @@
Adapteva Platforms Device Tree Bindings
---------------------------------------
Parallella board
Required root node properties:
- compatible = "adapteva,parallella";

15
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt Normal file
View File

@ -0,0 +1,15 @@
Altera SOCFPGA SDRAM Error Detection & Correction [EDAC]
The EDAC accesses a range of registers in the SDRAM controller.
Required properties:
- compatible : should contain "altr,sdram-edac";
- altr,sdr-syscon : phandle of the sdr module
- interrupts : Should contain the SDRAM ECC IRQ in the
appropriate format for the IRQ controller.
Example:
sdramedac {
compatible = "altr,sdram-edac";
altr,sdr-syscon = <&sdr>;
interrupts = <0 39 4>;
};

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

@ -0,0 +1,8 @@
Amlogic MesonX device tree bindings
-------------------------------------------
Boards with the Amlogic Meson6 SoC shall have the following properties:
Required root node property:
compatible = "amlogic,meson6";

6
Documentation/devicetree/bindings/arm/arm-boards
View File

@ -86,3 +86,9 @@ Interrupt controllers:
compatible = "arm,versatile-sic";
interrupt-controller;
#interrupt-cells = <1>;
Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"

14
Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt Normal file
View File

@ -0,0 +1,14 @@
Marvell Armada 38x CA9 MPcore SoC Controller
============================================
Required properties:
- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
- reg: should be the register base and length as documented in the
datasheet for the CA9 MPcore SoC Control registers
mpcore-soc-ctrl@20d20 {
compatible = "marvell,armada-380-mpcore-soc-ctrl";
reg = <0x20d20 0x6c>;
};

45
Documentation/devicetree/bindings/arm/atmel-at91.txt
View File

@ -1,6 +1,43 @@
Atmel AT91 device tree bindings.
================================
Boards with a SoC of the Atmel AT91 or SMART family shall have the following
properties:
Required root node properties:
compatible: must be one of:
* "atmel,at91rm9200"
* "atmel,at91sam9" for SoCs using an ARM926EJ-S core, shall be extended with
the specific SoC family or compatible:
o "atmel,at91sam9260"
o "atmel,at91sam9261"
o "atmel,at91sam9263"
o "atmel,at91sam9x5" for the 5 series, shall be extended with the specific
SoC compatible:
- "atmel,at91sam9g15"
- "atmel,at91sam9g25"
- "atmel,at91sam9g35"
- "atmel,at91sam9x25"
- "atmel,at91sam9x35"
o "atmel,at91sam9g20"
o "atmel,at91sam9g45"
o "atmel,at91sam9n12"
o "atmel,at91sam9rl"
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
SoC family:
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
- "atmel,sama5d31"
- "atmel,sama5d33"
- "atmel,sama5d34"
- "atmel,sama5d35"
- "atmel,sama5d36"
o "atmel,sama5d4" shall be extended with the specific SoC compatible:
- "atmel,sama5d41"
- "atmel,sama5d42"
- "atmel,sama5d43"
- "atmel,sama5d44"
PIT Timer required properties:
- compatible: Should be "atmel,at91sam9260-pit"
- reg: Should contain registers location and length
@ -61,8 +98,8 @@ RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91rm9200-sdramc",
"atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
"atmel,sama5d3-ddramc",
- reg: Should contain registers location and length
For at91sam9263 and at91sam9g45 you must specify 2 entries.
Examples:
@ -71,12 +108,6 @@ Examples:
reg = <0xffffe800 0x200>;
};
ramc0: ramc@ffffe400 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe400 0x200
0xffffe600 0x200>;
};
SHDWC Shutdown Controller
required properties:

5
Documentation/devicetree/bindings/arm/atmel-pmc.txt
View File

@ -1,7 +1,10 @@
* Power Management Controller (PMC)
Required properties:
- compatible: Should be "atmel,at91rm9200-pmc"
- compatible: Should be "atmel,<chip>-pmc".
<chip> can be: at91rm9200, at91sam9260, at91sam9g45, at91sam9n12,
at91sam9x5, sama5d3
- reg: Should contain PMC registers location and length
Examples:

9
Documentation/devicetree/bindings/arm/bcm/bcm63138.txt Normal file
View File

@ -0,0 +1,9 @@
Broadcom BCM63138 DSL System-on-a-Chip device tree bindings
-----------------------------------------------------------
Boards compatible with the BCM63138 DSL System-on-a-Chip should have the
following properties:
Required root node property:
compatible: should be "brcm,bcm63138"

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method Normal file
View File

@ -0,0 +1,36 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
The enable method is specified by defining the following required
properties in the "cpus" device tree node:
- enable-method = "brcm,bcm11351-cpu-method";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "brcm,bcm11351-cpu-method";
secondary-boot-reg = <0x3500417c>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
};
};

95
Documentation/devicetree/bindings/arm/brcm-brcmstb.txt Normal file
View File

@ -0,0 +1,95 @@
ARM Broadcom STB platforms Device Tree Bindings
-----------------------------------------------
Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
SoC shall have the following DT organization:
Required root node properties:
- compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
example:
/ {
#address-cells = <2>;
#size-cells = <2>;
model = "Broadcom STB (bcm7445)";
compatible = "brcm,bcm7445", "brcm,brcmstb";
Further, syscon nodes that map platform-specific registers used for general
system control is required:
- compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
example:
rdb {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges = <0 0x00 0xf0000000 0x1000000>;
sun_top_ctrl: syscon@404000 {
compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
reg = <0x404000 0x51c>;
};
hif_cpubiuctrl: syscon@3e2400 {
compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
reg = <0x3e2400 0x5b4>;
};
hif_continuation: syscon@452000 {
compatible = "brcm,bcm7445-hif-continuation", "syscon";
reg = <0x452000 0x100>;
};
};
Lastly, nodes that allow for support of SMP initialization and reboot are
required:
smpboot
-------
Required properties:
- compatible
The string "brcm,brcmstb-smpboot".
- syscon-cpu
A phandle / integer array property which lets the BSP know the location
of certain CPU power-on registers.
The layout of the property is as follows:
o a phandle to the "hif_cpubiuctrl" syscon node
o offset to the base CPU power zone register
o offset to the base CPU reset register
- syscon-cont
A phandle pointing to the syscon node which describes the CPU boot
continuation registers.
o a phandle to the "hif_continuation" syscon node
example:
smpboot {
compatible = "brcm,brcmstb-smpboot";
syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
syscon-cont = <&hif_continuation>;
};
reboot
-------
Required properties
- compatible
The string property "brcm,brcmstb-reboot".
- syscon
A phandle / integer array that points to the syscon node which describes
the general system reset registers.
o a phandle to "sun_top_ctrl"
o offset to the "reset source enable" register
o offset to the "software master reset" register
example:
reboot {
compatible = "brcm,brcmstb-reboot";
syscon = <&sun_top_ctrl 0x304 0x308>;
};

10
Documentation/devicetree/bindings/arm/cavium-thunder.txt Normal file
View File

@ -0,0 +1,10 @@
Cavium Thunder platform device tree bindings
--------------------------------------------
Boards with Cavium's Thunder SoC shall have following properties.
Root Node
---------
Required root node properties:
- compatible = "cavium,thunder-88xx";

21
Documentation/devicetree/bindings/arm/ccn.txt Normal file
View File

@ -0,0 +1,21 @@
* ARM CCN (Cache Coherent Network)
Required properties:
- compatible: (standard compatible string) should be one of:
"arm,ccn-504"
"arm,ccn-508"
- reg: (standard registers property) physical address and size
(16MB) of the configuration registers block
- interrupts: (standard interrupt property) single interrupt
generated by the control block
Example:
ccn@0x2000000000 {
compatible = "arm,ccn-504";
reg = <0x20 0x00000000 0 0x1000000>;
interrupts = <0 181 4>;
};

41
Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp Normal file
View File

@ -0,0 +1,41 @@
========================================================
Secondary CPU enable-method "marvell,berlin-smp" binding
========================================================
This document describes the "marvell,berlin-smp" method for enabling secondary
CPUs. To apply to all CPUs, a single "marvell,berlin-smp" enable method should
be defined in the "cpus" node.
Enable method name: "marvell,berlin-smp"
Compatible machines: "marvell,berlin2" and "marvell,berlin2q"
Compatible CPUs: "marvell,pj4b" and "arm,cortex-a9"
Related properties: (none)
Note:
This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and
"marvell,berlin-cpu-ctrl"[1].
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "marvell,berlin-smp";
cpu@0 {
compatible = "marvell,pj4b";
device_type = "cpu";
next-level-cache = <&l2>;
reg = <0>;
};
cpu@1 {
compatible = "marvell,pj4b";
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
};
};
--
[1] arm/marvell,berlin.txt

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

@ -152,7 +152,9 @@ nodes to be present and contain the properties described below.
"arm,cortex-a7"
"arm,cortex-a8"
"arm,cortex-a9"
"arm,cortex-a12"
"arm,cortex-a15"
"arm,cortex-a17"
"arm,cortex-a53"
"arm,cortex-a57"
"arm,cortex-m0"
@ -163,6 +165,8 @@ nodes to be present and contain the properties described below.
"arm,cortex-r4"
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
"cavium,thunder"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
@ -184,6 +188,7 @@ nodes to be present and contain the properties described below.
can be one of:
"allwinner,sun6i-a31"
"arm,psci"
"brcm,brahma-b15"
"marvell,armada-375-smp"
"marvell,armada-380-smp"
"marvell,armada-xp-smp"
@ -215,6 +220,12 @@ nodes to be present and contain the properties described below.
Value type: <phandle>
Definition: Specifies the ACC[2] node associated with this CPU.
- cpu-idle-states
Usage: Optional
Value type: <prop-encoded-array>
Definition:
# List of phandles to idle state nodes supported
by this cpu [3].
Example 1 (dual-cluster big.LITTLE system 32-bit):
@ -411,3 +422,5 @@ cpus {
--
[1] arm/msm/qcom,saw2.txt
[2] arm/msm/qcom,kpss-acc.txt
[3] ARM Linux kernel documentation - idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt

13
Documentation/devicetree/bindings/arm/exynos/power_domain.txt
View File

@ -8,6 +8,8 @@ Required Properties:
* samsung,exynos4210-pd - for exynos4210 type power domain.
- reg: physical base address of the controller and length of memory mapped
region.
- #power-domain-cells: number of cells in power domain specifier;
must be 0.
Optional Properties:
- clocks: List of clock handles. The parent clocks of the input clocks to the
@ -29,6 +31,7 @@ Example:
lcd0: power-domain-lcd0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x10>;
#power-domain-cells = <0>;
};
mfc_pd: power-domain@10044060 {
@ -37,12 +40,8 @@ Example:
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
<&clock CLK_MOUT_USER_ACLK333>;
clock-names = "oscclk", "pclk0", "clk0";
#power-domain-cells = <0>;
};
Example of the node using power domain:
node {
/* ... */
samsung,power-domain = <&lcd0>;
/* ... */
};
See Documentation/devicetree/bindings/power/power_domain.txt for description
of consumer-side bindings.

5
Documentation/devicetree/bindings/arm/geniatech.txt Normal file
View File

@ -0,0 +1,5 @@
Geniatech platforms device tree bindings
-------------------------------------------
Geniatech ATV1200
- compatible = "geniatech,atv1200"

79
Documentation/devicetree/bindings/arm/gic-v3.txt Normal file
View File

@ -0,0 +1,79 @@
* ARM Generic Interrupt Controller, version 3
AArch64 SMP cores are often associated with a GICv3, providing Private
Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
Software Generated Interrupts (SGI), and Locality-specific Peripheral
Interrupts (LPI).
Main node required properties:
- compatible : should at least contain "arm,gic-v3".
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. Must be a single cell with a value of at least 3.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts. Other values are reserved for future use.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = edge triggered
4 = level triggered
Cells 4 and beyond are reserved for future use. When the 1st cell
has a value of 0 or 1, cells 4 and beyond act as padding, and may be
ignored. It is recommended that padding cells have a value of 0.
- reg : Specifies base physical address(s) and size of the GIC
registers, in the following order:
- GIC Distributor interface (GICD)
- GIC Redistributors (GICR), one range per redistributor region
- GIC CPU interface (GICC)
- GIC Hypervisor interface (GICH)
- GIC Virtual CPU interface (GICV)
GICC, GICH and GICV are optional.
- interrupts : Interrupt source of the VGIC maintenance interrupt.
Optional
- redistributor-stride : If using padding pages, specifies the stride
of consecutive redistributors. Must be a multiple of 64kB.
- #redistributor-regions: The number of independent contiguous regions
occupied by the redistributors. Required if more than one such
region is present.
Examples:
gic: interrupt-controller@2cf00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x0 0x2f000000 0 0x10000>, // GICD
<0x0 0x2f100000 0 0x200000>, // GICR
<0x0 0x2c000000 0 0x2000>, // GICC
<0x0 0x2c010000 0 0x2000>, // GICH
<0x0 0x2c020000 0 0x2000>; // GICV
interrupts = <1 9 4>;
};
gic: interrupt-controller@2c010000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
interrupt-controller;
redistributor-stride = <0x0 0x40000>; // 256kB stride
#redistributor-regions = <2>;
reg = <0x0 0x2c010000 0 0x10000>, // GICD
<0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31
<0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63
<0x0 0x2c040000 0 0x2000>, // GICC
<0x0 0x2c060000 0 0x2000>, // GICH
<0x0 0x2c080000 0 0x2000>; // GICV
interrupts = <1 9 4>;
};

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

@ -16,6 +16,7 @@ Main node required properties:
"arm,cortex-a9-gic"
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
"brcm,brahma-b15-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.

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

@ -5,6 +5,11 @@ Hi4511 Board
Required root node properties:
- compatible = "hisilicon,hi3620-hi4511";
HiP04 D01 Board
Required root node properties:
- compatible = "hisilicon,hip04-d01";
Hisilicon system controller
Required properties:
@ -31,6 +36,17 @@ Example:
reboot-offset = <0x4>;
};
-----------------------------------------------------------------------
Hisilicon CPU controller
Required properties:
- compatible : "hisilicon,cpuctrl"
- reg : Register address and size
The clock registers and power registers of secondary cores are defined
in CPU controller, especially in HIX5HD2 SoC.
-----------------------------------------------------------------------
PCTRL: Peripheral misc control register
Required Properties:
@ -44,3 +60,21 @@ Example:
compatible = "hisilicon,pctrl";
reg = <0xfca09000 0x1000>;
};
-----------------------------------------------------------------------
Fabric:
Required Properties:
- compatible: "hisilicon,hip04-fabric";
- reg: Address and size of Fabric
-----------------------------------------------------------------------
Bootwrapper boot method (software protocol on SMP):
Required Properties:
- compatible: "hisilicon,hip04-bootwrapper";
- boot-method: Address and size of boot method.
[0]: bootwrapper physical address
[1]: bootwrapper size
[2]: relocation physical address
[3]: relocation size

679
Documentation/devicetree/bindings/arm/idle-states.txt Normal file
View File

@ -0,0 +1,679 @@
==========================================
ARM idle states binding description
==========================================
==========================================
1 - Introduction
==========================================
ARM systems contain HW capable of managing power consumption dynamically,
where cores can be put in different low-power states (ranging from simple
wfi to power gating) according to OS PM policies. The CPU states representing
the range of dynamic idle states that a processor can enter at run-time, can be
specified through device tree bindings representing the parameters required
to enter/exit specific idle states on a given processor.
According to the Server Base System Architecture document (SBSA, [3]), the
power states an ARM CPU can be put into are identified by the following list:
- Running
- Idle_standby
- Idle_retention
- Sleep
- Off
The power states described in the SBSA document define the basic CPU states on
top of which ARM platforms implement power management schemes that allow an OS
PM implementation to put the processor in different idle states (which include
states listed above; "off" state is not an idle state since it does not have
wake-up capabilities, hence it is not considered in this document).
Idle state parameters (eg entry latency) are platform specific and need to be
characterized with bindings that provide the required information to OS PM
code so that it can build the required tables and use them at runtime.
The device tree binding definition for ARM idle states is the subject of this
document.
===========================================
2 - idle-states definitions
===========================================
Idle states are characterized for a specific system through a set of
timing and energy related properties, that underline the HW behaviour
triggered upon idle states entry and exit.
The following diagram depicts the CPU execution phases and related timing
properties required to enter and exit an idle state:
..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__..
| | | | |
|<------ entry ------->|
| latency |
|<- exit ->|
| latency |
|<-------- min-residency -------->|
|<------- wakeup-latency ------->|
Diagram 1: CPU idle state execution phases
EXEC: Normal CPU execution.
PREP: Preparation phase before committing the hardware to idle mode
like cache flushing. This is abortable on pending wake-up
event conditions. The abort latency is assumed to be negligible
(i.e. less than the ENTRY + EXIT duration). If aborted, CPU
goes back to EXEC. This phase is optional. If not abortable,
this should be included in the ENTRY phase instead.
ENTRY: The hardware is committed to idle mode. This period must run
to completion up to IDLE before anything else can happen.
IDLE: This is the actual energy-saving idle period. This may last
between 0 and infinite time, until a wake-up event occurs.
EXIT: Period during which the CPU is brought back to operational
mode (EXEC).
entry-latency: Worst case latency required to enter the idle state. The
exit-latency may be guaranteed only after entry-latency has passed.
min-residency: Minimum period, including preparation and entry, for a given
idle state to be worthwhile energywise.
wakeup-latency: Maximum delay between the signaling of a wake-up event and the
CPU being able to execute normal code again. If not specified, this is assumed
to be entry-latency + exit-latency.
These timing parameters can be used by an OS in different circumstances.
An idle CPU requires the expected min-residency time to select the most
appropriate idle state based on the expected expiry time of the next IRQ
(ie wake-up) that causes the CPU to return to the EXEC phase.
An operating system scheduler may need to compute the shortest wake-up delay
for CPUs in the system by detecting how long will it take to get a CPU out
of an idle state, eg:
wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
In other words, the scheduler can make its scheduling decision by selecting
(eg waking-up) the CPU with the shortest wake-up latency.
The wake-up latency must take into account the entry latency if that period
has not expired. The abortable nature of the PREP period can be ignored
if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
the worst case since it depends on the CPU operating conditions, ie caches
state).
An OS has to reliably probe the wakeup-latency since some devices can enforce
latency constraints guarantees to work properly, so the OS has to detect the
worst case wake-up latency it can incur if a CPU is allowed to enter an
idle state, and possibly to prevent that to guarantee reliable device
functioning.
The min-residency time parameter deserves further explanation since it is
expressed in time units but must factor in energy consumption coefficients.
The energy consumption of a cpu when it enters a power state can be roughly
characterised by the following graph:
|
|
|
e |
n | /---
e | /------
r | /------
g | /-----
y | /------
| ----
| /|
| / |
| / |
| / |
| / |
| / |
|/ |
-----|-------+----------------------------------
0| 1 time(ms)
Graph 1: Energy vs time example
The graph is split in two parts delimited by time 1ms on the X-axis.
The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope
and denotes the energy costs incurred whilst entering and leaving the idle
state.
The graph curve in the area delimited by X-axis values = {x | x > 1ms } has
shallower slope and essentially represents the energy consumption of the idle
state.
min-residency is defined for a given idle state as the minimum expected
residency time for a state (inclusive of preparation and entry) after
which choosing that state become the most energy efficient option. A good
way to visualise this, is by taking the same graph above and comparing some
states energy consumptions plots.
For sake of simplicity, let's consider a system with two idle states IDLE1,
and IDLE2:
|
|
|
| /-- IDLE1
e | /---
n | /----
e | /---
r | /-----/--------- IDLE2
g | /-------/---------
y | ------------ /---|
| / /---- |
| / /--- |
| / /---- |
| / /--- |
| --- |
| / |
| / |
|/ | time
---/----------------------------+------------------------
|IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy
|
IDLE2-min-residency
Graph 2: idle states min-residency example
In graph 2 above, that takes into account idle states entry/exit energy
costs, it is clear that if the idle state residency time (ie time till next
wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
choice energywise.
This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
than IDLE2.
However, the lower power consumption (ie shallower energy curve slope) of idle
state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
efficient.
The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
shallower states in a system with multiple idle states) is defined
IDLE2-min-residency and corresponds to the time when energy consumption of
IDLE1 and IDLE2 states breaks even.
The definitions provided in this section underpin the idle states
properties specification that is the subject of the following sections.
===========================================
3 - idle-states node
===========================================
ARM processor idle states are defined within the idle-states node, which is
a direct child of the cpus node [1] and provides a container where the
processor idle states, defined as device tree nodes, are listed.
- idle-states node
Usage: Optional - On ARM systems, it is a container of processor idle
states nodes. If the system does not provide CPU
power management capabilities or the processor just
supports idle_standby an idle-states node is not
required.
Description: idle-states node is a container node, where its
subnodes describe the CPU idle states.
Node name must be "idle-states".
The idle-states node's parent node must be the cpus node.
The idle-states node's child nodes can be:
- one or more state nodes
Any other configuration is considered invalid.
An idle-states node defines the following properties:
- entry-method
Value type: <stringlist>
Usage and definition depend on ARM architecture version.
# On ARM v8 64-bit this property is required and must
be one of:
- "psci" (see bindings in [2])
# On ARM 32-bit systems this property is optional
The nodes describing the idle states (state) can only be defined within the
idle-states node, any other configuration is considered invalid and therefore
must be ignored.
===========================================
4 - state node
===========================================
A state node represents an idle state description and must be defined as
follows:
- state node
Description: must be child of the idle-states node
The state node name shall follow standard device tree naming
rules ([5], 2.2.1 "Node names"), in particular state nodes which
are siblings within a single common parent must be given a unique name.
The idle state entered by executing the wfi instruction (idle_standby
SBSA,[3][4]) is considered standard on all ARM platforms and therefore
must not be listed.
With the definitions provided above, the following list represents
the valid properties for a state node:
- compatible
Usage: Required
Value type: <stringlist>
Definition: Must be "arm,idle-state".
- local-timer-stop
Usage: See definition
Value type: <none>
Definition: if present the CPU local timer control logic is
lost on state entry, otherwise it is retained.
- entry-latency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency in
microseconds required to enter the idle state.
The exit-latency-us duration may be guaranteed
only after entry-latency-us has passed.
- exit-latency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency
in microseconds required to exit the idle state.
- min-residency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing minimum residency duration
in microseconds, inclusive of preparation and
entry, for this idle state to be considered
worthwhile energy wise (refer to section 2 of
this document for a complete description).
- wakeup-latency-us:
Usage: Optional
Value type: <prop-encoded-array>
Definition: u32 value representing maximum delay between the
signaling of a wake-up event and the CPU being
able to execute normal code again. If omitted,
this is assumed to be equal to:
entry-latency-us + exit-latency-us
It is important to supply this value on systems
where the duration of PREP phase (see diagram 1,
section 2) is non-neglibigle.
In such systems entry-latency-us + exit-latency-us
will exceed wakeup-latency-us by this duration.
In addition to the properties listed above, a state node may require
additional properties specifics to the entry-method defined in the
idle-states node, please refer to the entry-method bindings
documentation for properties definitions.
===========================================
4 - Examples
===========================================
Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method):
cpus {
#size-cells = <0>;
#address-cells = <2>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU4: cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU5: cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU6: cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU7: cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU8: cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU9: cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU10: cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU11: cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU12: cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10000>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU13: cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10001>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU14: cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU15: cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
idle-states {
entry-method = "arm,psci";
CPU_RETENTION_0_0: cpu-retention-0-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <20>;
exit-latency-us = <40>;
min-residency-us = <80>;
};
CLUSTER_RETENTION_0: cluster-retention-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <50>;
exit-latency-us = <100>;
min-residency-us = <250>;
wakeup-latency-us = <130>;
};
CPU_SLEEP_0_0: cpu-sleep-0-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <250>;
exit-latency-us = <500>;
min-residency-us = <950>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <600>;
exit-latency-us = <1100>;
min-residency-us = <2700>;
wakeup-latency-us = <1500>;
};
CPU_RETENTION_1_0: cpu-retention-1-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <20>;
exit-latency-us = <40>;
min-residency-us = <90>;
};
CLUSTER_RETENTION_1: cluster-retention-1 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <50>;
exit-latency-us = <100>;
min-residency-us = <270>;
wakeup-latency-us = <100>;
};
CPU_SLEEP_1_0: cpu-sleep-1-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <70>;
exit-latency-us = <100>;
min-residency-us = <300>;
wakeup-latency-us = <150>;
};
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <500>;
exit-latency-us = <1200>;
min-residency-us = <3500>;
wakeup-latency-us = <1300>;
};
};
};
Example 2 (ARM 32-bit, 8-cpu system, two clusters):
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU5: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU6: cpu@102 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU7: cpu@103 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
idle-states {
CPU_SLEEP_0_0: cpu-sleep-0-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <200>;
exit-latency-us = <100>;
min-residency-us = <400>;
wakeup-latency-us = <250>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <500>;
exit-latency-us = <1500>;
min-residency-us = <2500>;
wakeup-latency-us = <1700>;
};
CPU_SLEEP_1_0: cpu-sleep-1-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <300>;
exit-latency-us = <500>;
min-residency-us = <900>;
wakeup-latency-us = <600>;
};
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <800>;
exit-latency-us = <2000>;
min-residency-us = <6500>;
wakeup-latency-us = <2300>;
};
};
};
===========================================
5 - References
===========================================
[1] ARM Linux Kernel documentation - CPUs bindings
Documentation/devicetree/bindings/arm/cpus.txt
[2] ARM Linux Kernel documentation - PSCI bindings
Documentation/devicetree/bindings/arm/psci.txt
[3] ARM Server Base System Architecture (SBSA)
http://infocenter.arm.com/help/index.jsp
[4] ARM Architecture Reference Manuals
http://infocenter.arm.com/help/index.jsp
[5] ePAPR standard
https://www.power.org/documentation/epapr-version-1-1/

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

@ -2,6 +2,10 @@
ARM cores often have a separate level 2 cache controller. There are various
implementations of the L2 cache controller with compatible programming models.
Some of the properties that are just prefixed "cache-*" are taken from section
3.7.3 of the ePAPR v1.1 specification which can be found at:
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
The ARM L2 cache representation in the device tree should be done as follows:
Required properties:
@ -44,6 +48,12 @@ Optional properties:
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
- interrupts : 1 combined interrupt.
- cache-size : specifies the size in bytes of the cache
- cache-sets : specifies the number of associativity sets of the cache
- cache-block-size : specifies the size in bytes of a cache block
- cache-line-size : specifies the size in bytes of a line in the cache,
if this is not specified, the line size is assumed to be equal to the
cache block size
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode

16
Documentation/devicetree/bindings/arm/marvell,berlin.txt
View File

@ -24,6 +24,22 @@ SoC and board used. Currently known SoC compatibles are:
...
}
* Marvell Berlin CPU control bindings
CPU control register allows various operations on CPUs, like resetting them
independently.
Required properties:
- compatible: should be "marvell,berlin-cpu-ctrl"
- reg: address and length of the register set
Example:
cpu-ctrl@f7dd0000 {
compatible = "marvell,berlin-cpu-ctrl";
reg = <0xf7dd0000 0x10000>;
};
* Marvell Berlin2 chip control binding
Marvell Berlin SoCs have a chip control register set providing several

14
Documentation/devicetree/bindings/arm/mediatek.txt Normal file
View File

@ -0,0 +1,14 @@
Mediatek MT6589 Platforms Device Tree Bindings
Boards with a SoC of the Mediatek MT6589 shall have the following property:
Required root node property:
compatible: must contain "mediatek,mt6589"
Supported boards:
- bq Aquaris5 smart phone:
Required root node properties:
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";

3
Documentation/devicetree/bindings/arm/omap/mpu.txt
View File

@ -10,6 +10,9 @@ Required properties:
Should be "ti,omap5-mpu" for OMAP5
- ti,hwmods: "mpu"
Optional properties:
- sram: Phandle to the ocmcram node
Examples:
- For an OMAP5 SMP system:

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

@ -85,6 +85,18 @@ SoCs:
- DRA722
compatible = "ti,dra722", "ti,dra72", "ti,dra7"
- AM5728
compatible = "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
- AM5726
compatible = "ti,am5726", "ti,dra742", "ti,dra74", "ti,dra7"
- AM5718
compatible = "ti,am5718", "ti,dra722", "ti,dra72", "ti,dra7"
- AM5716
compatible = "ti,am5716", "ti,dra722", "ti,dra72", "ti,dra7"
- AM4372
compatible = "ti,am4372", "ti,am43"
@ -129,6 +141,9 @@ Boards:
- AM437x GP EVM
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
- AM437x SK EVM: AM437x StarterKit Evaluation Module
compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
- DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"

65
Documentation/devicetree/bindings/arm/omap/prcm.txt Normal file
View File

@ -0,0 +1,65 @@
OMAP PRCM bindings
Power Reset and Clock Manager lists the device clocks and clockdomains under
a DT hierarchy. Each TI SoC can have multiple PRCM entities listed for it,
each describing one module and the clock hierarchy under it. see [1] for
documentation about the individual clock/clockdomain nodes.
[1] Documentation/devicetree/bindings/clock/ti/*
Required properties:
- compatible: Must be one of:
"ti,am3-prcm"
"ti,am3-scrm"
"ti,am4-prcm"
"ti,am4-scrm"
"ti,omap2-prcm"
"ti,omap2-scrm"
"ti,omap3-prm"
"ti,omap3-cm"
"ti,omap3-scrm"
"ti,omap4-cm1"
"ti,omap4-prm"
"ti,omap4-cm2"
"ti,omap4-scrm"
"ti,omap5-prm"
"ti,omap5-cm-core-aon"
"ti,omap5-scrm"
"ti,omap5-cm-core"
"ti,dra7-prm"
"ti,dra7-cm-core-aon"
"ti,dra7-cm-core"
- reg: Contains PRCM module register address range
(base address and length)
- clocks: clocks for this module
- clockdomains: clockdomains for this module
Example:
cm: cm@48004000 {
compatible = "ti,omap3-cm";
reg = <0x48004000 0x4000>;
cm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
};
cm_clockdomains: clockdomains {
};
}
&cm_clocks {
omap2_32k_fck: omap_32k_fck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
};
};
&cm_clockdomains {
core_l3_clkdm: core_l3_clkdm {
compatible = "ti,clockdomain";
clocks = <&sdrc_ick>;
};
};

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

@ -50,6 +50,16 @@ Main node optional properties:
- migrate : Function ID for MIGRATE operation
Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
state nodes, as per bindings in [1]) must specify the following properties:
- arm,psci-suspend-param
Usage: Required for state nodes[1] if the corresponding
idle-states node entry-method property is set
to "psci".
Value type: <u32>
Definition: power_state parameter to pass to the PSCI
suspend call.
Example:
@ -64,7 +74,6 @@ Case 1: PSCI v0.1 only.
migrate = <0x95c10003>;
};
Case 2: PSCI v0.2 only
psci {
@ -88,3 +97,6 @@ Case 3: PSCI v0.2 and PSCI v0.1.
...
};
[1] Kernel documentation - ARM idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt

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