redonkable/remarkable-linux
redonkable/remarkable-linux
1
0
Fork 0
Code Releases Activity

Merge branch 'topic/enum-info-cleanup' into for-next

Browse source 
this is a series of patches to just convert the plain info callback
for enum ctl elements to snd_ctl_elem_info().  Also, it includes the
extension of snd_ctl_elem_info(), for catching the unexpected string
cut-off and handling the zero items.
This commit is contained in:
Takashi Iwai 2014-10-22 12:19:57 +02:00
parent b46882b6eb 7bbd03e014
commit 930352862e
8147 changed files with 385006 additions and 274748 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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>

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.

2
Documentation/ABI/testing/sysfs-class-net
View file

@ -159,7 +159,7 @@ Description:
lower-level interface protocol used. Ethernet devices will show
a 'mtu' attribute value of 1500 unless changed.
What: /sys/calss/net/<iface>/netdev_group
What: /sys/class/net/<iface>/netdev_group
Date: January 2011
KernelVersion: 2.6.39
Contact: netdev@vger.kernel.org

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>

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>

21
Documentation/Changes
View file

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

2
Documentation/CodingStyle
View file

@ -675,7 +675,7 @@ the ones already enabled by DEBUG.
Many subsystems have Kconfig debug options to turn on -DDEBUG in the
corresponding Makefile; in other cases specific files #define DEBUG. And
when a debug message should be unconditionally printed, such as if it is
already inside a debug-related #ifdef secton, printk(KERN_DEBUG ...) can be
already inside a debug-related #ifdef section, printk(KERN_DEBUG ...) can be
used.

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

16
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
@ -3386,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
@ -3400,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>
@ -3918,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/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>

6
Documentation/DocBook/media/v4l/compat.xml
View file

@ -2566,6 +2566,12 @@ fields changed from _s32 to _u32.
<para>Added compound control types and &VIDIOC-QUERY-EXT-CTRL;.
</para>
</listitem>
<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>

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>

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>

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-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>,

23
Documentation/DocBook/writing-an-alsa-driver.tmpl
View file

@ -3657,6 +3657,29 @@ struct _snd_pcm_runtime {
</informalexample>
</para>
<para>
The above callback can be simplified with a helper function,
<function>snd_ctl_enum_info</function>. The final code
looks like below.
(You can pass ARRAY_SIZE(texts) instead of 4 in the third
argument; it's a matter of taste.)
<informalexample>
<programlisting>
<![CDATA[
static int snd_myctl_enum_info(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
static char *texts[4] = {
"First", "Second", "Third", "Fourth"
};
return snd_ctl_enum_info(uinfo, 1, 4, texts);
}
]]>
</programlisting>
</informalexample>
</para>
<para>
Some common info callbacks are available for your convenience:
<function>snd_ctl_boolean_mono_info()</function> and

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.

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.

2
Documentation/applying-patches.txt
View file

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

1
Documentation/arm/Makefile Normal file
View file

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

4
Documentation/arm/Marvell/README
View file

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

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;

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>

4
Documentation/block/null_blk.txt
View file

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

6
Documentation/block/queue-sysfs.txt
View file

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

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

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";

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:

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"

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";

9
Documentation/devicetree/bindings/arm/cpus.txt
View file

@ -166,6 +166,7 @@ nodes to be present and contain the properties described below.
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
"cavium,thunder"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
@ -219,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):
@ -415,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"

23
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:
@ -55,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

6
Documentation/devicetree/bindings/arm/mediatek.txt
View file

@ -6,3 +6,9 @@ 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:

12
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"

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

18
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
View file

@ -11,13 +11,25 @@ New driver handles the following
Required properties:
- compatible: Must be "samsung,exynos-adc-v1"
for exynos4412/5250 controllers.
for exynos4412/5250 and s5pv210 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
Must be "samsung,exynos3250-adc" for
controllers compatible with ADC of Exynos3250.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
Must be "samsung,s3c2410-adc" for
the ADC in s3c2410 and compatibles
Must be "samsung,s3c2416-adc" for
the ADC in s3c2416 and compatibles
Must be "samsung,s3c2440-adc" for
the ADC in s3c2440 and compatibles
Must be "samsung,s3c2443-adc" for
the ADC in s3c2443 and compatibles
Must be "samsung,s3c6410-adc" for
the ADC in s3c6410 and compatibles
- reg: List of ADC register address range
- The base address and range of ADC register
- The base address and range of ADC_PHY register (every
SoC except for s3c24xx/s3c64xx ADC)
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.

71
Documentation/devicetree/bindings/arm/shmobile.txt Normal file
View file

@ -0,0 +1,71 @@
Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings
--------------------------------------------------------------------
SoCs:
- Emma Mobile EV2
compatible = "renesas,emev2"
- RZ/A1H (R7S72100)
compatible = "renesas,r7s72100"
- SH-Mobile AP4 (R8A73720/SH7372)
compatible = "renesas,sh7372"
- SH-Mobile AG5 (R8A73A00/SH73A0)
compatible = "renesas,sh73a0"
- R-Mobile APE6 (R8A73A40)
compatible = "renesas,r8a73a4"
- R-Mobile A1 (R8A77400)
compatible = "renesas,r8a7740"
- R-Car M1A (R8A77781)
compatible = "renesas,r8a7778"
- R-Car H1 (R8A77790)
compatible = "renesas,r8a7779"
- R-Car H2 (R8A77900)
compatible = "renesas,r8a7790"
- R-Car M2-W (R8A77910)
compatible = "renesas,r8a7791"
- R-Car V2H (R8A77920)
compatible = "renesas,r8a7792"
- R-Car M2-N (R8A77930)
compatible = "renesas,r8a7793"
- R-Car E2 (R8A77940)
compatible = "renesas,r8a7794"
Boards:
- Alt
compatible = "renesas,alt", "renesas,r8a7794"
- APE6-EVM
compatible = "renesas,ape6evm", "renesas,r8a73a4"
- APE6-EVM - Reference Device Tree Implementation
compatible = "renesas,ape6evm-reference", "renesas,r8a73a4"
- Atmark Techno Armadillo-800 EVA
compatible = "renesas,armadillo800eva"
- BOCK-W
compatible = "renesas,bockw", "renesas,r8a7778"
- BOCK-W - Reference Device Tree Implementation
compatible = "renesas,bockw-reference", "renesas,r8a7778"
- Genmai (RTK772100BC00000BR)
compatible = "renesas,genmai", "renesas,r7s72100"
- Gose
compatible = "renesas,gose", "renesas,r8a7793"
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
- Koelsch (RTP0RC7791SEB00010S)
compatible = "renesas,koelsch", "renesas,r8a7791"
- Kyoto Microcomputer Co. KZM-A9-Dual
compatible = "renesas,kzm9d", "renesas,emev2"
- Kyoto Microcomputer Co. KZM-A9-GT
compatible = "renesas,kzm9g", "renesas,sh73a0"
- Kyoto Microcomputer Co. KZM-A9-GT - Reference Device Tree Implementation
compatible = "renesas,kzm9g-reference", "renesas,sh73a0"
- Lager (RTP0RC7790SEB00010S)
compatible = "renesas,lager", "renesas,r8a7790"
- Mackerel (R0P7372LC0016RL, AP4 EVM 2nd)
compatible = "renesas,mackerel"
- Marzen
compatible = "renesas,marzen", "renesas,r8a7779"
Note: Reference Device Tree Implementations are temporary implementations
to ease the migration from platform devices to Device Tree, and are
intended to be removed in the future.

12
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt Normal file
View file

@ -0,0 +1,12 @@
NVIDIA Tegra Flow Controller
Required properties:
- compatible: Should be "nvidia,tegra<chip>-flowctrl"
- reg: Should contain one register range (address and length)
Example:
flow-controller@60007000 {
compatible = "nvidia,tegra20-flowctrl";
reg = <0x60007000 0x1000>;
};

48
Documentation/devicetree/bindings/ata/qcom-sata.txt Normal file
View file

@ -0,0 +1,48 @@
* Qualcomm AHCI SATA Controller
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
Required properties:
- compatible : compatible list, must contain "generic-ahci"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
- phys : Must contain exactly one entry as specified
in phy-bindings.txt
- phy-names : Must be "sata-phy"
Required properties for "qcom,ipq806x-ahci" compatible:
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Shall be:
"slave_iface" - Fabric port AHB clock for SATA
"iface" - AHB clock
"core" - core clock
"rxoob" - RX out-of-band clock
"pmalive" - Power Module Alive clock
- assigned-clocks : Shall be:
SATA_RXOOB_CLK
SATA_PMALIVE_CLK
- assigned-clock-rates : Shall be:
100Mhz (100000000) for SATA_RXOOB_CLK
100Mhz (100000000) for SATA_PMALIVE_CLK
Example:
sata@29000000 {
compatible = "qcom,ipq806x-ahci", "generic-ahci";
reg = <0x29000000 0x180>;
interrupts = <0 209 0x0>;
clocks = <&gcc SFAB_SATA_S_H_CLK>,
<&gcc SATA_H_CLK>,
<&gcc SATA_A_CLK>,
<&gcc SATA_RXOOB_CLK>,
<&gcc SATA_PMALIVE_CLK>;
clock-names = "slave_iface", "iface", "core",
"rxoob", "pmalive";
assigned-clocks = <&gcc SATA_RXOOB_CLK>, <&gcc SATA_PMALIVE_CLK>;
assigned-clock-rates = <100000000>, <100000000>;
phys = <&sata_phy>;
phy-names = "sata-phy";
};

32
Documentation/devicetree/bindings/bus/bcma.txt Normal file
View file

@ -0,0 +1,32 @@
Driver for ARM AXI Bus with Broadcom Plugins (bcma)
Required properties:
- compatible : brcm,bus-axi
- reg : iomem address range of chipcommon core
The cores on the AXI bus are automatically detected by bcma with the
memory ranges they are using and they get registered afterwards.
The top-level axi bus may contain children representing attached cores
(devices). This is needed since some hardware details can't be auto
detected (e.g. IRQ numbers). Also some of the cores may be responsible
for extra things, e.g. ChipCommon providing access to the GPIO chip.
Example:
axi@18000000 {
compatible = "brcm,bus-axi";
reg = <0x18000000 0x1000>;
ranges = <0x00000000 0x18000000 0x00100000>;
#address-cells = <1>;
#size-cells = <1>;
chipcommon {
reg = <0x00000000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
};
};

2
Documentation/devicetree/bindings/clock/arm-integrator.txt
View file

@ -1,6 +1,6 @@
Clock bindings for ARM Integrator and Versatile Core Module clocks
Auxilary Oscillator Clock
Auxiliary Oscillator Clock
This is a configurable clock fed from a 24 MHz chrystal,
used for generating e.g. video clocks. It is located on the

14
Documentation/devicetree/bindings/clock/at91-clock.txt
View file

@ -74,6 +74,9 @@ Required properties:
"atmel,at91sam9x5-clk-utmi":
at91 utmi clock
"atmel,sama5d4-clk-h32mx":
at91 h32mx clock
Required properties for SCKC node:
- reg : defines the IO memory reserved for the SCKC.
- #size-cells : shall be 0 (reg is used to encode clk id).
@ -447,3 +450,14 @@ For example:
#clock-cells = <0>;
clocks = <&main>;
};
Required properties for 32 bits bus Matrix clock (h32mx clock):
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : shall be the master clock source phandle.
For example:
h32ck: h32mxck {
#clock-cells = <0>;
compatible = "atmel,sama5d4-clk-h32mx";
clocks = <&mck>;
};

10
Documentation/devicetree/bindings/clock/exynos3250-clock.txt
View file

@ -7,6 +7,8 @@ Required Properties:
- compatible: should be one of the following.
- "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
- "samsung,exynos3250-cmu-dmc" - controller compatible with
Exynos3250 SoC for Dynamic Memory Controller domain.
- reg: physical base address of the controller and length of memory mapped
region.
@ -20,7 +22,7 @@ All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos3250.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
Example 1: Examples of clock controller nodes are listed below.
cmu: clock-controller@10030000 {
compatible = "samsung,exynos3250-cmu";
@ -28,6 +30,12 @@ Example 1: An example of a clock controller node is listed below.
#clock-cells = <1>;
};
cmu_dmc: clock-controller@105C0000 {
compatible = "samsung,exynos3250-cmu-dmc";
reg = <0x105C0000 0x2000>;
#clock-cells = <1>;
};
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.

21
Documentation/devicetree/bindings/clock/gpio-gate-clock.txt Normal file
View file

@ -0,0 +1,21 @@
Binding for simple gpio gated clock.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "gpio-gate-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- enable-gpios : GPIO reference for enabling and disabling the clock.
Optional properties:
- clocks: Maximum of one parent clock is supported.
Example:
clock {
compatible = "gpio-gate-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
};

16
Documentation/devicetree/bindings/clock/maxim,max77686.txt
View file

@ -9,13 +9,21 @@ The MAX77686 contains three 32.768khz clock outputs that can be controlled
Following properties should be presend in main device node of the MFD chip.
Required properties:
- #clock-cells: simple one-cell clock specifier format is used, where the
only cell is used as an index of the clock inside the provider. Following
indices are allowed:
- #clock-cells: from common clock binding; shall be set to 1.
Optional properties:
- clock-output-names: From common clock binding.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. Following indices are allowed:
- 0: 32khz_ap clock,
- 1: 32khz_cp clock,
- 2: 32khz_pmic clock.
Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77686.h
header and can be used in device tree sources.
Example: Node of the MFD chip
max77686: max77686@09 {
@ -34,5 +42,5 @@ Example: Clock consumer node
compatible = "bar,foo";
/* ... */
clock-names = "my-clock";
clocks = <&max77686 2>;
clocks = <&max77686 MAX77686_CLK_PMIC>;
};

44
Documentation/devicetree/bindings/clock/maxim,max77802.txt Normal file
View file

@ -0,0 +1,44 @@
Binding for Maxim MAX77802 32k clock generator block
This is a part of device tree bindings of MAX77802 multi-function device.
More information can be found in bindings/mfd/max77802.txt file.
The MAX77802 contains two 32.768khz clock outputs that can be controlled
(gated/ungated) over I2C.
Following properties should be present in main device node of the MFD chip.
Required properties:
- #clock-cells: From common clock binding; shall be set to 1.
Optional properties:
- clock-output-names: From common clock binding.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. Following indices are allowed:
- 0: 32khz_ap clock,
- 1: 32khz_cp clock.
Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77802.h
header and can be used in device tree sources.
Example: Node of the MFD chip
max77802: max77802@09 {
compatible = "maxim,max77802";
interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>;
reg = <0x09>;
#clock-cells = <1>;
/* ... */
};
Example: Clock consumer node
foo@0 {
compatible = "bar,foo";
/* ... */
clock-names = "my-clock";
clocks = <&max77802 MAX77802_CLK_32K_AP>;
};

16
Documentation/devicetree/bindings/clock/pxa-clock.txt Normal file
View file

@ -0,0 +1,16 @@
* Clock bindings for Marvell PXA chips
Required properties:
- compatible: Should be "marvell,pxa-clocks"
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell (see include/.../pxa-clock.h).
Examples:
pxa2xx_clks: pxa2xx_clks@41300004 {
compatible = "marvell,pxa-clocks";
#clock-cells = <1>;
status = "okay";
};

3
Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
View file

@ -11,9 +11,12 @@ Required Properties:
- compatible: Must be one of the following
- "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks
- "renesas,r8a7740-mstp-clocks" for R8A7740 (R-Mobile A1) MSTP gate clocks
- "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks
- "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks
- "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2) MSTP gate clocks
- "renesas,r8a7794-mstp-clocks" for R8A7794 (R-Car E2) MSTP gate clocks
- "renesas,sh73a0-mstp-clocks" for SH73A0 (SH-MobileAG5) MSTP gate clocks
- "renesas,cpg-mstp-clock" for generic MSTP gate clocks
- reg: Base address and length of the I/O mapped registers used by the MSTP
clocks. The first register is the clock control register and is mandatory.

1
Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
View file

@ -8,6 +8,7 @@ Required Properties:
- compatible: Must be one of
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
- "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
- "renesas,r8a7794-cpg-clocks" for the r8a7794 CPG
- "renesas,rcar-gen2-cpg-clocks" for the generic R-Car Gen2 CPG
- reg: Base address and length of the memory resource used by the CPG

4
Documentation/devicetree/bindings/clock/sunxi.txt
View file

@ -46,7 +46,11 @@ Required properties:
"allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
"allwinner,sun4i-a10-mmc-output-clk" - for the MMC output clock on A10
"allwinner,sun4i-a10-mmc-sample-clk" - for the MMC sample clock on A10
"allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
"allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
"allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20

8
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt → Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
View file

@ -1,8 +1,8 @@
Generic CPU0 cpufreq driver
Generic cpufreq driver
It is a generic cpufreq driver for CPU0 frequency management. It
supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
systems which share clock and voltage across all CPUs.
It is a generic DT based cpufreq driver for frequency management. It supports
both uniprocessor (UP) and symmetric multiprocessor (SMP) systems which share
clock and voltage across all CPUs.
Both required and optional properties listed below must be defined
under node /cpus/cpu@0.

2
Documentation/devicetree/bindings/crypto/fsl-sec6.txt
View file

@ -1,5 +1,5 @@
SEC 6 is as Freescale's Cryptographic Accelerator and Assurance Module (CAAM).
Currently Freescale powerpc chip C29X is embeded with SEC 6.
Currently Freescale powerpc chip C29X is embedded with SEC 6.
SEC 6 device tree binding include:
-SEC 6 Node
-Job Ring Node

62
Documentation/devicetree/bindings/dma/qcom_adm.txt Normal file
View file

@ -0,0 +1,62 @@
QCOM ADM DMA Controller
Required properties:
- compatible: must contain "qcom,adm" for IPQ/APQ8064 and MSM8960
- reg: Address range for DMA registers
- interrupts: Should contain one interrupt shared by all channels
- #dma-cells: must be <2>. First cell denotes the channel number. Second cell
denotes CRCI (client rate control interface) flow control assignment.
- clocks: Should contain the core clock and interface clock.
- clock-names: Must contain "core" for the core clock and "iface" for the
interface clock.
- resets: Must contain an entry for each entry in reset names.
- reset-names: Must include the following entries:
- clk
- c0
- c1
- c2
- qcom,ee: indicates the security domain identifier used in the secure world.
Example:
adm_dma: dma@18300000 {
compatible = "qcom,adm";
reg = <0x18300000 0x100000>;
interrupts = <0 170 0>;
#dma-cells = <2>;
clocks = <&gcc ADM0_CLK>, <&gcc ADM0_PBUS_CLK>;
clock-names = "core", "iface";
resets = <&gcc ADM0_RESET>,
<&gcc ADM0_C0_RESET>,
<&gcc ADM0_C1_RESET>,
<&gcc ADM0_C2_RESET>;
reset-names = "clk", "c0", "c1", "c2";
qcom,ee = <0>;
};
DMA clients must use the format descripted in the dma.txt file, using a three
cell specifier for each channel.
Each dmas request consists of 3 cells:
1. phandle pointing to the DMA controller
2. channel number
3. CRCI assignment, if applicable. If no CRCI flow control is required, use 0.
The CRCI is used for flow control. It identifies the peripheral device that
is the source/destination for the transferred data.
Example:
spi4: spi@1a280000 {
status = "ok";
spi-max-frequency = <50000000>;
pinctrl-0 = <&spi_pins>;
pinctrl-names = "default";
cs-gpios = <&qcom_pinmux 20 0>;
dmas = <&adm_dma 6 9>,
<&adm_dma 5 10>;
dma-names = "rx", "tx";
};

65
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt Normal file
View file

@ -0,0 +1,65 @@
Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
target devices. It can be configured to have one channel or two channels.
If configured as two channels, one is to transmit to the device and another
is to receive from the device.
Required properties:
- compatible: Should be "xlnx,axi-dma-1.00.a"
- #dma-cells: Should be <1>, see "dmas" property below
- reg: Should contain DMA registers location and length.
- dma-channel child node: Should have atleast one channel and can have upto
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
Optional properties:
- xlnx,include-sg: Tells whether configured for Scatter-mode in
the hardware.
Required child node properties:
- compatible: It should be either "xlnx,axi-dma-mm2s-channel" or
"xlnx,axi-dma-s2mm-channel".
- interrupts: Should contain per channel DMA interrupts.
- xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
Option child node properties:
- xlnx,include-dre: Tells whether hardware is configured for Data
Realignment Engine.
Example:
++++++++
axi_dma_0: axidma@40400000 {
compatible = "xlnx,axi-dma-1.00.a";
#dma_cells = <1>;
reg = < 0x40400000 0x10000 >;
dma-channel@40400000 {
compatible = "xlnx,axi-dma-mm2s-channel";
interrupts = < 0 59 4 >;
xlnx,datawidth = <0x40>;
} ;
dma-channel@40400030 {
compatible = "xlnx,axi-dma-s2mm-channel";
interrupts = < 0 58 4 >;
xlnx,datawidth = <0x40>;
} ;
} ;
* DMA client
Required properties:
- dmas: a list of <[DMA device phandle] [Channel ID]> pairs,
where Channel ID is '0' for write/tx and '1' for read/rx
channel.
- dma-names: a list of DMA channel names, one per "dmas" entry
Example:
++++++++
dmatest_0: dmatest@0 {
compatible ="xlnx,axi-dma-test-1.00.a";
dmas = <&axi_dma_0 0
&axi_dma_0 1>;
dma-names = "dma0", "dma1";
} ;

7
Documentation/devicetree/bindings/drm/tilcdc/panel.txt
View file

@ -18,6 +18,10 @@ Required properties:
Documentation/devicetree/bindings/video/display-timing.txt for display
timing binding details.
Optional properties:
- backlight: phandle of the backlight device attached to the panel
- enable-gpios: GPIO pin to enable or disable the panel
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
@ -29,6 +33,9 @@ Example:
compatible = "ti,tilcdc,panel";
pinctrl-names = "default";
pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
backlight = <&backlight>;
enable-gpios = <&gpio3 19 0>;
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;

25
Documentation/devicetree/bindings/extcon/extcon-rt8973a.txt Normal file
View file

@ -0,0 +1,25 @@
* Richtek RT8973A - Micro USB Switch device
The Richtek RT8973A is Micro USB Switch with OVP and I2C interface. The RT8973A
is a USB port accessory detector and switch that is optimized to protect low
voltage system from abnormal high input voltage (up to 28V) and supports high
speed USB operation. Also, RT8973A support 'auto-configuration' mode.
If auto-configuration mode is enabled, RT8973A would control internal h/w patch
for USB D-/D+ switching.
Required properties:
- compatible: Should be "richtek,rt8973a-muic"
- reg: Specifies the I2C slave address of the MUIC block. It should be 0x14
- interrupt-parent: Specifies the phandle of the interrupt controller to which
the interrupts from rt8973a are delivered to.
- interrupts: Interrupt specifiers for detection interrupt sources.
Example:
rt8973a@14 {
compatible = "richtek,rt8973a-muic";
interrupt-parent = <&gpx1>;
interrupts = <5 0>;
reg = <0x14>;
};

39
Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt Normal file
View file

@ -0,0 +1,39 @@
Keystone 2 DSP GPIO controller bindings
HOST OS userland running on ARM can send interrupts to DSP cores using
the DSP GPIO controller IP. It provides 28 IRQ signals per each DSP core.
This is one of the component used by the IPC mechanism used on Keystone SOCs.
For example TCI6638K2K SoC has 8 DSP GPIO controllers:
- 8 for C66x CorePacx CPUs 0-7
Keystone 2 DSP GPIO controller has specific features:
- each GPIO can be configured only as output pin;
- setting GPIO value to 1 causes IRQ generation on target DSP core;
- reading pin value returns 0 - if IRQ was handled or 1 - IRQ is still
pending.
Required Properties:
- compatible: should be "ti,keystone-dsp-gpio"
- ti,syscon-dev: phandle/offset pair. The phandle to syscon used to
access device state control registers and the offset of device's specific
registers within device state control registers range.
- gpio-controller: Marks the device node as a gpio controller.
- #gpio-cells: Should be 2.
Please refer to gpio.txt in this directory for details of the common GPIO
bindings used by client devices.
Example:
dspgpio0: keystone_dsp_gpio@02620240 {
compatible = "ti,keystone-dsp-gpio";
ti,syscon-dev = <&devctrl 0x240>;
gpio-controller;
#gpio-cells = <2>;
};
dsp0: dsp0 {
compatible = "linux,rproc-user";
...
kick-gpio = <&dspgpio0 27>;
};

39
Documentation/devicetree/bindings/gpio/gpio-pca953x.txt Normal file
View file

@ -0,0 +1,39 @@
* NXP PCA953x I2C GPIO multiplexer
Required properties:
- compatible: Has to contain one of the following:
nxp,pca9505
nxp,pca9534
nxp,pca9535
nxp,pca9536
nxp,pca9537
nxp,pca9538
nxp,pca9539
nxp,pca9554
nxp,pca9555
nxp,pca9556
nxp,pca9557
nxp,pca9574
nxp,pca9575
nxp,pca9698
maxim,max7310
maxim,max7312
maxim,max7313
maxim,max7315
ti,pca6107
ti,tca6408
ti,tca6416
ti,tca6424
exar,xra1202
Example:
gpio@20 {
compatible = "nxp,pca9505";
reg = <0x20>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pca9505>;
interrupt-parent = <&gpio3>;
interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
};

54
Documentation/devicetree/bindings/gpio/gpio-restart.txt Normal file
View file

@ -0,0 +1,54 @@
Drive a GPIO line that can be used to restart the system from a restart
handler.
This binding supports level and edge triggered reset. At driver load
time, the driver will request the given gpio line and install a restart
handler. If the optional properties 'open-source' is not found, the GPIO line
will be driven in the inactive state. Otherwise its not driven until
the restart is initiated.
When the system is restarted, the restart handler will be invoked in
priority order. The gpio is configured as an output, and driven active,
triggering a level triggered reset condition. This will also cause an
inactive->active edge condition, triggering positive edge triggered
reset. After a delay specified by active-delay, the GPIO is set to
inactive, thus causing an active->inactive edge, triggering negative edge
triggered reset. After a delay specified by inactive-delay, the GPIO
is driven active again. After a delay specified by wait-delay, the
restart handler completes allowing other restart handlers to be attempted.
Required properties:
- compatible : should be "gpio-restart".
- gpios : The GPIO to set high/low, see "gpios property" in
Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be
low to reset the board set it to "Active Low", otherwise set
gpio to "Active High".
Optional properties:
- open-source : Treat the GPIO as being open source and defer driving
it to when the restart is initiated. If this optional property is not
specified, the GPIO is initialized as an output in its inactive state.
- priority : A priority ranging from 0 to 255 (default 128) according to
the following guidelines:
0: Restart handler of last resort, with limited restart
capabilities
128: Default restart handler; use if no other restart handler is
expected to be available, and/or if restart functionality is
sufficient to restart the entire system
255: Highest priority restart handler, will preempt all other
restart handlers
- active-delay: Delay (default 100) to wait after driving gpio active [ms]
- inactive-delay: Delay (default 100) to wait after driving gpio inactive [ms]
- wait-delay: Delay (default 3000) to wait after completing restart
sequence [ms]
Examples:
gpio-restart {
compatible = "gpio-restart";
gpios = <&gpio 4 0>;
priority = <128>;
active-delay = <100>;
inactive-delay = <100>;
wait-delay = <3000>;
};

22
Documentation/devicetree/bindings/gpio/gpio-xgene.txt Normal file
View file

@ -0,0 +1,22 @@
APM X-Gene SoC GPIO controller bindings
This is a gpio controller that is part of the flash controller.
This gpio controller controls a total of 48 gpios.
Required properties:
- compatible: "apm,xgene-gpio" for X-Gene GPIO controller
- reg: Physical base address and size of the controller's registers
- #gpio-cells: Should be two.
- first cell is the pin number
- second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- gpio-controller: Marks the device node as a GPIO controller.
Example:
gpio0: gpio0@1701c000 {
compatible = "apm,xgene-gpio";
reg = <0x0 0x1701c000 0x0 0x40>;
gpio-controller;
#gpio-cells = <2>;
};

15
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
View file

@ -19,7 +19,7 @@ Required properties:
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be one. It is the pin number.
Example:
Example for a MMP platform:
gpio: gpio@d4019000 {
compatible = "marvell,mmp-gpio";
@ -32,6 +32,19 @@ Example:
#interrupt-cells = <1>;
};
Example for a PXA3xx platform:
gpio: gpio@40e00000 {
compatible = "intel,pxa3xx-gpio";
reg = <0x40e00000 0x10000>;
interrupt-names = "gpio0", "gpio1", "gpio_mux";
interrupts = <8 9 10>;
gpio-controller;
#gpio-cells = <0x2>;
interrupt-controller;
#interrupt-cells = <0x2>;
};
* Marvell Orion GPIO Controller
Required properties:

3
Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
View file

@ -25,6 +25,9 @@ Requires node properties:
- "io-channels" Channel node of ADC to be used for
conversion.
Optional node properties:
- "#thermal-sensor-cells" Used to expose itself to thermal fw.
Read more about iio bindings at
Documentation/devicetree/bindings/iio/iio-bindings.txt

30
Documentation/devicetree/bindings/i2c/i2c-axxia.txt Normal file
View file

@ -0,0 +1,30 @@
LSI Axxia I2C
Required properties :
- compatible : Must be "lsi,api2c"
- reg : Offset and length of the register set for the device
- interrupts : the interrupt specifier
- #address-cells : Must be <1>;
- #size-cells : Must be <0>;
- clock-names : Must contain "i2c".
- clocks: Must contain an entry for each name in clock-names. See the common
clock bindings.
Optional properties :
- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
the default 100 kHz frequency will be used. As only Normal and Fast modes
are supported, possible values are 100000 and 400000.
Example :
i2c@02010084000 {
compatible = "lsi,api2c";
device_type = "i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x20 0x10084000 0x00 0x1000>;
interrupts = <0 19 4>;
clocks = <&clk_per>;
clock-names = "i2c";
clock-frequency = <400000>;
};

2
Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
View file

@ -12,6 +12,8 @@ Required properties:
on Exynos5250 and Exynos5420 SoCs.
-> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available
on Exynos5260 SoCs.
-> "samsung,exynos7-hsi2c", for i2c compatible with HSI2C available
on Exynos7 SoCs.
- reg: physical base address of the controller and length of memory mapped
region.

24
Documentation/devicetree/bindings/i2c/i2c-hix5hd2.txt Normal file
View file

@ -0,0 +1,24 @@
I2C for Hisilicon hix5hd2 chipset platform
Required properties:
- compatible: Must be "hisilicon,hix5hd2-i2c"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
- #address-cells = <1>;
- #size-cells = <0>;
- clocks: phandles to input clocks.
Optional properties:
- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to 100000
- Child nodes conforming to i2c bus binding
Examples:
I2C0@f8b10000 {
compatible = "hisilicon,hix5hd2-i2c";
reg = <0xf8b10000 0x1000>;
interrupts = <0 38 4>;
clocks = <&clock HIX5HD2_I2C0_RST>;
#address-cells = <1>;
#size-cells = <0>;
}

18
Documentation/devicetree/bindings/i2c/ti,bq32k.txt Normal file
View file

@ -0,0 +1,18 @@
* TI BQ32000 I2C Serial Real-Time Clock
Required properties:
- compatible: Should contain "ti,bq32000".
- reg: I2C address for chip
Optional properties:
- trickle-resistor-ohms : Selected resistor for trickle charger
Values usable are 1120 and 20180
Should be given if trickle charger should be enabled
- trickle-diode-disable : Do not use internal trickle charger diode
Should be given if internal trickle charger diode should be disabled
Example:
bq32000: rtc@68 {
compatible = "ti,bq32000";
trickle-resistor-ohms = <1120>;
reg = <0x68>;
};

3
Documentation/devicetree/bindings/i2c/trivial-devices.txt
View file

@ -35,7 +35,6 @@ catalyst,24c32 i2c serial eeprom
cirrus,cs42l51 Cirrus Logic CS42L51 audio codec
dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock
dallas,ds1338 I2C RTC with 56-Byte NV RAM
dallas,ds1339 I2C Serial Real-Time Clock
dallas,ds1340 I2C RTC with Trickle Charger
dallas,ds1374 I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output
dallas,ds1631 High-Precision Digital Thermometer
@ -44,7 +43,7 @@ dallas,ds1775 Tiny Digital Thermometer and Thermostat
dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM
dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O
dallas,ds75 Digital Thermometer and Thermostat
dialog,da9053 DA9053: flexible system level PMIC with multicore support
dlg,da9053 DA9053: flexible system level PMIC with multicore support
epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE
epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer

24
Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt Normal file
View file

@ -0,0 +1,24 @@
Rockchip Successive Approximation Register (SAR) A/D Converter bindings
Required properties:
- compatible: Should be "rockchip,saradc"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu. The interrupt specifier format
depends on the interrupt controller.
- clocks: Must contain an entry for each entry in clock-names.
- clock-names: Shall be "saradc" for the converter-clock, and "apb_pclk" for
the peripheral clock.
- vref-supply: The regulator supply ADC reference voltage.
- #io-channel-cells: Should be 1, see ../iio-bindings.txt
Example:
saradc: saradc@2006c000 {
compatible = "rockchip,saradc";
reg = <0x2006c000 0x100>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>;
clock-names = "saradc", "apb_pclk";
#io-channel-cells = <1>;
vref-supply = <&vcc18>;
};

2
Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
View file

@ -9,7 +9,7 @@ Required properties:
- interrupts: Should contain the interrupt for the device
- clocks: The clock is needed by the ADC controller, ADC clock source is ipg clock.
- clock-names: Must contain "adc", matching entry in the clocks property.
- vref-supply: The regulator supply ADC refrence voltage.
- vref-supply: The regulator supply ADC reference voltage.
Example:
adc0: adc@4003b000 {

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