Merge Linus' tree to be be to apply submitted patches to newer code than
current trivial.git base
This commit is contained in:
Jiri Kosina
commit
a02001086b
.gitignoreCREDITS
Documentation
.gitignore00-INDEXDMA-API-HOWTO.txt
ABI
removed
stable
testing
configfs-usb-gadget-uac1configfs-usb-gadget-uac2sysfs-blocksysfs-block-zramsysfs-bus-event_source-devices-eventssysfs-bus-event_source-devices-hv_24x7sysfs-bus-event_source-devices-hv_gpcisysfs-bus-iio-accel-bmc150sysfs-bus-iio-gyro-bmg160sysfs-bus-pcisysfs-bus-rbdsysfs-class-cxlsysfs-class-leds-gt683rsysfs-class-mtdsysfs-class-powersysfs-class-uwb_rcsysfs-devices-memorysysfs-driver-pcibacksysfs-driver-tegra-fusesysfs-driver-wacomsysfs-fs-f2fssysfs-fs-nilfs2sysfs-fs-xfssysfs-ibft
DocBook
HOWTOMakefileRCU
SubmittingPatchesaccounting
acpi
arm
arm64
auxdisplay
binfmt_misc.txtblackfin
block
blockdev
cgroups
development-process
device-mapper
devicetree/bindings/arm
|
|
@ -34,6 +34,7 @@
|
|||
*.gcno
|
||||
modules.builtin
|
||||
Module.symvers
|
||||
*.dwo
|
||||
|
||||
#
|
||||
# Top-level generic files
|
||||
|
|
|
|||
7
CREDITS
7
CREDITS
|
|
@ -1381,6 +1381,9 @@ S: 17 rue Danton
|
|||
S: F - 94270 Le Kremlin-Bicêtre
|
||||
S: France
|
||||
|
||||
N: Jack Hammer
|
||||
D: IBM ServeRAID RAID (ips) driver maintenance
|
||||
|
||||
N: Greg Hankins
|
||||
E: gregh@cc.gatech.edu
|
||||
D: fixed keyboard driver to separate LED and locking status
|
||||
|
|
@ -1691,6 +1694,10 @@ S: Reading
|
|||
S: RG6 2NU
|
||||
S: United Kingdom
|
||||
|
||||
N: Dave Jeffery
|
||||
E: dhjeffery@gmail.com
|
||||
D: SCSI hacks and IBM ServeRAID RAID driver maintenance
|
||||
|
||||
N: Jakub Jelinek
|
||||
E: jakub@redhat.com
|
||||
W: http://sunsite.mff.cuni.cz/~jj
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
filesystems/dnotify_test
|
||||
laptops/dslm
|
||||
timers/hpet_example
|
||||
vm/hugepage-mmap
|
||||
vm/hugepage-shm
|
||||
vm/map_hugetlb
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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)
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -94,5 +94,5 @@ current_snap
|
|||
|
||||
parent
|
||||
|
||||
Information identifying the pool, image, and snapshot id for
|
||||
the parent image in a layered rbd image (format 2 only).
|
||||
Information identifying the chain of parent images in a layered rbd
|
||||
image. Entries are separated by empty lines.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
What: /sys/class/leds/<led>/gt683r/mode
|
||||
Date: Jun 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
|
||||
Description:
|
||||
Set the mode of LEDs. You should notice that changing the mode
|
||||
of one LED will update the mode of its two sibling devices as
|
||||
well.
|
||||
|
||||
0 - normal
|
||||
1 - audio
|
||||
2 - breathing
|
||||
|
||||
Normal: LEDs are fully on when enabled
|
||||
Audio: LEDs brightness depends on sound level
|
||||
Breathing: LEDs brightness varies at human breathing rate
|
||||
|
|
@ -184,3 +184,41 @@ Description:
|
|||
|
||||
It will always be a non-negative integer. In the case of
|
||||
devices lacking any ECC capability, it is 0.
|
||||
|
||||
What: /sys/class/mtd/mtdX/ecc_failures
|
||||
Date: June 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
The number of failures reported by this device's ECC. Typically,
|
||||
these failures are associated with failed read operations.
|
||||
|
||||
It will always be a non-negative integer. In the case of
|
||||
devices lacking any ECC capability, it is 0.
|
||||
|
||||
What: /sys/class/mtd/mtdX/corrected_bits
|
||||
Date: June 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
The number of bits that have been corrected by means of the
|
||||
device's ECC.
|
||||
|
||||
It will always be a non-negative integer. In the case of
|
||||
devices lacking any ECC capability, it is 0.
|
||||
|
||||
What: /sys/class/mtd/mtdX/bad_blocks
|
||||
Date: June 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
The number of blocks marked as bad, if any, in this partition.
|
||||
|
||||
What: /sys/class/mtd/mtdX/bbt_blocks
|
||||
Date: June 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
The number of blocks that are marked as reserved, if any, in
|
||||
this partition. These are typically used to store the in-flash
|
||||
bad block table (BBT).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,13 @@
|
|||
What: /sys/bus/pci/drivers/pciback/quirks
|
||||
Date: Oct 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description:
|
||||
If the permissive attribute is set, then writing a string in
|
||||
the format of DDDD:BB:DD.F-REG:SIZE:MASK will allow the guest
|
||||
to write and read from the PCI device. That is Domain:Bus:
|
||||
Device.Function-Register:Size:Mask (Domain is optional).
|
||||
For example:
|
||||
#echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
|
||||
will allow the guest to read and write to the configuration
|
||||
register 0x0E.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
What: /sys/devices/*/<our-device>/fuse
|
||||
Date: February 2014
|
||||
Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
|
||||
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
|
||||
and Tegra124 SoC's from NVIDIA. The efuses contain write once
|
||||
data programmed at the factory. The data is layed out in 32bit
|
||||
words in LSB first format. Each bit represents a single value
|
||||
as decoded from the fuse registers. Bits order/assignment
|
||||
exactly matches the HW registers, including any unused bits.
|
||||
Users: any user space application which wants to read the efuses on
|
||||
Tegra SoC's
|
||||
|
|
@ -1,48 +1,27 @@
|
|||
WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
|
||||
Date: June 2012
|
||||
Contact: linux-bluetooth@vger.kernel.org
|
||||
Description:
|
||||
The /sys/class/hidraw/hidraw*/device/oled*_img files control
|
||||
OLED mocro displays on Intuos4 Wireless tablet. Accepted image
|
||||
has to contain 256 bytes (64x32 px 1 bit colour). The format
|
||||
is the same as PBM image 62x32px without header (64 bits per
|
||||
horizontal line, 32 lines). An example of setting OLED No. 0:
|
||||
dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
|
||||
The attribute is read only and no local copy of the image is
|
||||
stored.
|
||||
|
||||
What: /sys/class/hidraw/hidraw*/device/speed
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.35
|
||||
Contact: linux-bluetooth@vger.kernel.org
|
||||
Description:
|
||||
The /sys/class/hidraw/hidraw*/device/speed file controls
|
||||
reporting speed of Wacom bluetooth tablet. Reading from
|
||||
this file returns 1 if tablet reports in high speed mode
|
||||
The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
|
||||
controls reporting speed of Wacom bluetooth tablet. Reading
|
||||
from this file returns 1 if tablet reports in high speed mode
|
||||
or 0 otherwise. Writing to this file one of these values
|
||||
switches reporting speed.
|
||||
|
||||
What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
|
||||
Date: May 2012
|
||||
Kernel Version: 3.5
|
||||
Contact: linux-bluetooth@vger.kernel.org
|
||||
Description:
|
||||
LED selector for Intuos4 WL. There are 4 leds, but only one LED
|
||||
can be lit at a time. Max brightness is 127.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
|
||||
Date: August 2011
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
|
||||
Date: August 2014
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Attribute group for control of the status LEDs and the OLEDs.
|
||||
This attribute group is only available for Intuos 4 M, L,
|
||||
and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
|
||||
21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
|
||||
implicitly signifies the presence of said LEDs and OLEDs on the
|
||||
tablet device.
|
||||
and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
|
||||
Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
|
||||
(LEDs only). Therefore its presence implicitly signifies the
|
||||
presence of said LEDs and OLEDs on the tablet device.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
|
||||
Date: August 2011
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
|
||||
Date: August 2014
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets the status LED luminance (1..127)
|
||||
|
|
@ -50,16 +29,16 @@ Description:
|
|||
button is pressed on the stylus. This luminance level is
|
||||
normally lower than the level when a button is pressed.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
|
||||
Date: August 2011
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
|
||||
Date: August 2014
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets the status LED luminance (1..127)
|
||||
when the stylus touches the tablet surface, or any button is
|
||||
pressed on the stylus.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
|
||||
Date: August 2011
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
|
||||
Date: August 2014
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the four (for Intuos 4
|
||||
|
|
@ -67,23 +46,23 @@ Description:
|
|||
24HD) status LEDs is active (0..3). The other three LEDs on the
|
||||
same side are always inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
|
||||
Date: September 2011
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
|
||||
Date: August 2014
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the left four (for Cintiq 21UX2
|
||||
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
|
||||
the left are always inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
|
||||
Date: August 2011
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
|
||||
Date: August 2014
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets the overall luminance level (0..15)
|
||||
of all eight button OLED displays.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
|
||||
Date: August 2011
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
|
||||
Date: August 2014
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
When writing a 1024 byte raw image in Wacom Intuos 4
|
||||
|
|
@ -93,3 +72,8 @@ Description:
|
|||
byte chunk encodes the image data for two consecutive lines on
|
||||
the display. The low nibble of each byte contains the first
|
||||
line, and the high nibble contains the second line.
|
||||
When the Wacom Intuos 4 is connected over Bluetooth, the
|
||||
image has to contain 256 bytes (64x32 px 1 bit colour).
|
||||
The format is also scrambled, like in the USB mode, and it can
|
||||
be summarized by converting 76543210 into GECA6420.
|
||||
HGFEDCBA HFDB7531
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,269 @@
|
|||
|
||||
What: /sys/fs/nilfs2/features/revision
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show current revision of NILFS file system driver.
|
||||
This value informs about file system revision that
|
||||
driver is ready to support.
|
||||
|
||||
What: /sys/fs/nilfs2/features/README
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Describe attributes of /sys/fs/nilfs2/features group.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/revision
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show NILFS file system revision on volume.
|
||||
This value informs about metadata structures'
|
||||
revision on mounted volume.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/blocksize
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show volume's block size in bytes.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/device_size
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show volume size in bytes.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/free_blocks
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show count of free blocks on volume.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/uuid
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show volume's UUID (Universally Unique Identifier).
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/volume_name
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show volume's label.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/README
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Describe attributes of /sys/fs/nilfs2/<device> group.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/superblock/sb_write_time
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show last write time of super block in human-readable
|
||||
format.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/superblock/sb_write_time_secs
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show last write time of super block in seconds.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/superblock/sb_write_count
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show current write count of super block.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/superblock/sb_update_frequency
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show/Set interval of periodical update of superblock
|
||||
(in seconds).
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/superblock/README
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Describe attributes of /sys/fs/nilfs2/<device>/superblock
|
||||
group.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/last_pseg_block
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show start block number of the latest segment.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/last_seg_sequence
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show sequence value of the latest segment.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/last_seg_checkpoint
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show checkpoint number of the latest segment.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/current_seg_sequence
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show segment sequence counter.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/current_last_full_seg
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show index number of the latest full segment.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/next_full_seg
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show index number of the full segment index
|
||||
to be used next.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/next_pseg_offset
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show offset of next partial segment in the current
|
||||
full segment.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/next_checkpoint
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show next checkpoint number.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show write time of the last segment in
|
||||
human-readable format.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time_secs
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show write time of the last segment in seconds.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show write time of the last segment not for cleaner
|
||||
operation in human-readable format.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time_secs
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show write time of the last segment not for cleaner
|
||||
operation in seconds.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/dirty_data_blocks_count
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show number of dirty data blocks.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segctor/README
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Describe attributes of /sys/fs/nilfs2/<device>/segctor
|
||||
group.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segments/segments_number
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show number of segments on a volume.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segments/blocks_per_segment
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show number of blocks in segment.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segments/clean_segments
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show count of clean segments.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segments/dirty_segments
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show count of dirty segments.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/segments/README
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Describe attributes of /sys/fs/nilfs2/<device>/segments
|
||||
group.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/checkpoints/checkpoints_number
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show number of checkpoints on volume.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/checkpoints/snapshots_number
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show number of snapshots on volume.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/checkpoints/last_seg_checkpoint
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show checkpoint number of the latest segment.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/checkpoints/next_checkpoint
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show next checkpoint number.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/checkpoints/README
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Describe attributes of /sys/fs/nilfs2/<device>/checkpoints
|
||||
group.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/mounted_snapshots/README
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Describe content of /sys/fs/nilfs2/<device>/mounted_snapshots
|
||||
group.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/inodes_count
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show number of inodes for snapshot.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/blocks_count
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Show number of blocks for snapshot.
|
||||
|
||||
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/README
|
||||
Date: April 2014
|
||||
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
|
||||
Description:
|
||||
Describe attributes of /sys/fs/nilfs2/<device>/mounted_snapshots/<id>
|
||||
group.
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
What: /sys/fs/xfs/<disk>/log/log_head_lsn
|
||||
Date: July 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: xfs@oss.sgi.com
|
||||
Description:
|
||||
The log sequence number (LSN) of the current head of the
|
||||
log. The LSN is exported in "cycle:basic block" format.
|
||||
Users: xfstests
|
||||
|
||||
What: /sys/fs/xfs/<disk>/log/log_tail_lsn
|
||||
Date: July 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: xfs@oss.sgi.com
|
||||
Description:
|
||||
The log sequence number (LSN) of the current tail of the
|
||||
log. The LSN is exported in "cycle:basic block" format.
|
||||
|
||||
What: /sys/fs/xfs/<disk>/log/reserve_grant_head
|
||||
Date: July 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: xfs@oss.sgi.com
|
||||
Description:
|
||||
The current state of the log reserve grant head. It
|
||||
represents the total log reservation of all currently
|
||||
outstanding transactions. The grant head is exported in
|
||||
"cycle:bytes" format.
|
||||
Users: xfstests
|
||||
|
||||
What: /sys/fs/xfs/<disk>/log/write_grant_head
|
||||
Date: July 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: xfs@oss.sgi.com
|
||||
Description:
|
||||
The current state of the log write grant head. It
|
||||
represents the total log reservation of all currently
|
||||
oustanding transactions, including regrants due to
|
||||
rolling transactions. The grant head is exported in
|
||||
"cycle:bytes" format.
|
||||
Users: xfstests
|
||||
|
|
@ -20,4 +20,4 @@ Date: November 2007
|
|||
Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
|
||||
Description: The /sys/firmware/ibft/ethernetX directory will contain
|
||||
files that expose the iSCSI Boot Firmware Table NIC data.
|
||||
This can this can the IP address, MAC, and gateway of the NIC.
|
||||
Usually this contains the IP address, MAC, and gateway of the NIC.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -291,10 +291,9 @@ char *date;</synopsis>
|
|||
<title>Device Registration</title>
|
||||
<para>
|
||||
A number of functions are provided to help with device registration.
|
||||
The functions deal with PCI, USB and platform devices, respectively.
|
||||
The functions deal with PCI and platform devices, respectively.
|
||||
</para>
|
||||
!Edrivers/gpu/drm/drm_pci.c
|
||||
!Edrivers/gpu/drm/drm_usb.c
|
||||
!Edrivers/gpu/drm/drm_platform.c
|
||||
<para>
|
||||
New drivers that no longer rely on the services provided by the
|
||||
|
|
@ -315,7 +314,7 @@ char *date;</synopsis>
|
|||
<function>drm_dev_unregister()</function> followed by a call to
|
||||
<function>drm_dev_unref()</function>.
|
||||
</para>
|
||||
!Edrivers/gpu/drm/drm_stub.c
|
||||
!Edrivers/gpu/drm/drm_drv.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Driver Load</title>
|
||||
|
|
@ -1610,7 +1609,7 @@ int max_width, max_height;</synopsis>
|
|||
The connector is then registered with a call to
|
||||
<function>drm_connector_init</function> with a pointer to the connector
|
||||
functions and a connector type, and exposed through sysfs with a call to
|
||||
<function>drm_sysfs_connector_add</function>.
|
||||
<function>drm_connector_register</function>.
|
||||
</para>
|
||||
<para>
|
||||
Supported connector types are
|
||||
|
|
@ -1768,7 +1767,7 @@ int max_width, max_height;</synopsis>
|
|||
(<function>drm_encoder_cleanup</function>) and connectors
|
||||
(<function>drm_connector_cleanup</function>). Furthermore, connectors
|
||||
that have been added to sysfs must be removed by a call to
|
||||
<function>drm_sysfs_connector_remove</function> before calling
|
||||
<function>drm_connector_unregister</function> before calling
|
||||
<function>drm_connector_cleanup</function>.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -1813,7 +1812,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs);
|
||||
drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
|
||||
|
||||
drm_sysfs_connector_add(connector);
|
||||
drm_connector_register(connector);
|
||||
}]]></programlisting>
|
||||
<para>
|
||||
In the example above (taken from the i915 driver), a CRTC, connector and
|
||||
|
|
@ -2336,6 +2335,12 @@ void intel_crt_init(struct drm_device *dev)
|
|||
!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
|
||||
!Iinclude/drm/drm_dp_helper.h
|
||||
!Edrivers/gpu/drm/drm_dp_helper.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Display Port MST Helper Functions Reference</title>
|
||||
!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
|
||||
!Iinclude/drm/drm_dp_mst_helper.h
|
||||
!Edrivers/gpu/drm/drm_dp_mst_topology.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>EDID Helper Functions Reference</title>
|
||||
|
|
@ -2502,7 +2507,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >Description/Restrictions</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="20" valign="top" >DRM</td>
|
||||
<td rowspan="21" valign="top" >DRM</td>
|
||||
<td rowspan="2" valign="top" >Generic</td>
|
||||
<td valign="top" >“EDID”</td>
|
||||
<td valign="top" >BLOB | IMMUTABLE</td>
|
||||
|
|
@ -2633,7 +2638,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="2" valign="top" >Optional</td>
|
||||
<td rowspan="3" valign="top" >Optional</td>
|
||||
<td valign="top" >“scaling mode”</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
|
||||
|
|
@ -2641,6 +2646,15 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >"aspect ratio"</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
<td valign="top" >{ "None", "4:3", "16:9" }</td>
|
||||
<td valign="top" >Connector</td>
|
||||
<td valign="top" >DRM property to set aspect ratio from user space app.
|
||||
This enum is made generic to allow addition of custom aspect
|
||||
ratios.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“dirty”</td>
|
||||
<td valign="top" >ENUM | IMMUTABLE</td>
|
||||
<td valign="top" >{ "Off", "On", "Annotate" }</td>
|
||||
|
|
@ -2649,7 +2663,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
</tr>
|
||||
<tr>
|
||||
<td rowspan="21" valign="top" >i915</td>
|
||||
<td rowspan="3" valign="top" >Generic</td>
|
||||
<td rowspan="2" valign="top" >Generic</td>
|
||||
<td valign="top" >"Broadcast RGB"</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
<td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td>
|
||||
|
|
@ -2664,10 +2678,11 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >Standard name as in DRM</td>
|
||||
<td valign="top" >Standard type as in DRM</td>
|
||||
<td valign="top" >Standard value as in DRM</td>
|
||||
<td valign="top" >Standard Object as in DRM</td>
|
||||
<td rowspan="1" valign="top" >Plane</td>
|
||||
<td valign="top" >“rotation”</td>
|
||||
<td valign="top" >BITMASK</td>
|
||||
<td valign="top" >{ 0, "rotate-0" }, { 2, "rotate-180" }</td>
|
||||
<td valign="top" >Plane</td>
|
||||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -2799,8 +2814,8 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="3" valign="top" >CDV gma-500</td>
|
||||
<td rowspan="3" valign="top" >Generic</td>
|
||||
<td rowspan="2" valign="top" >CDV gma-500</td>
|
||||
<td rowspan="2" valign="top" >Generic</td>
|
||||
<td valign="top" >"Broadcast RGB"</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
<td valign="top" >{ “Full”, “Limited 16:235” }</td>
|
||||
|
|
@ -2815,15 +2830,8 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >Standard name as in DRM</td>
|
||||
<td valign="top" >Standard type as in DRM</td>
|
||||
<td valign="top" >Standard value as in DRM</td>
|
||||
<td valign="top" >Standard Object as in DRM</td>
|
||||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="20" valign="top" >Poulsbo</td>
|
||||
<td rowspan="2" valign="top" >Generic</td>
|
||||
<td rowspan="19" valign="top" >Poulsbo</td>
|
||||
<td rowspan="1" valign="top" >Generic</td>
|
||||
<td valign="top" >“backlight”</td>
|
||||
<td valign="top" >RANGE</td>
|
||||
<td valign="top" >Min=0, Max=100</td>
|
||||
|
|
@ -2831,13 +2839,6 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >Standard name as in DRM</td>
|
||||
<td valign="top" >Standard type as in DRM</td>
|
||||
<td valign="top" >Standard value as in DRM</td>
|
||||
<td valign="top" >Standard Object as in DRM</td>
|
||||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="17" valign="top" >SDVO-TV</td>
|
||||
<td valign="top" >“mode”</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
|
|
@ -3064,7 +3065,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="3" valign="top" >i2c/ch7006_drv</td>
|
||||
<td rowspan="2" valign="top" >i2c/ch7006_drv</td>
|
||||
<td valign="top" >Generic</td>
|
||||
<td valign="top" >“scale”</td>
|
||||
<td valign="top" >RANGE</td>
|
||||
|
|
@ -3073,14 +3074,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="2" valign="top" >TV</td>
|
||||
<td valign="top" >Standard names as in DRM</td>
|
||||
<td valign="top" >Standard types as in DRM</td>
|
||||
<td valign="top" >Standard Values as in DRM</td>
|
||||
<td valign="top" >Standard object as in DRM</td>
|
||||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" valign="top" >TV</td>
|
||||
<td valign="top" >“mode”</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
<td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc"
|
||||
|
|
@ -3089,7 +3083,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="16" valign="top" >nouveau</td>
|
||||
<td rowspan="15" valign="top" >nouveau</td>
|
||||
<td rowspan="6" valign="top" >NV10 Overlay</td>
|
||||
<td valign="top" >"colorkey"</td>
|
||||
<td valign="top" >RANGE</td>
|
||||
|
|
@ -3198,14 +3192,6 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >Generic</td>
|
||||
<td valign="top" >Standard name as in DRM</td>
|
||||
<td valign="top" >Standard type as in DRM</td>
|
||||
<td valign="top" >Standard value as in DRM</td>
|
||||
<td valign="top" >Standard Object as in DRM</td>
|
||||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="2" valign="top" >omap</td>
|
||||
<td rowspan="2" valign="top" >Generic</td>
|
||||
<td valign="top" >“rotation”</td>
|
||||
|
|
@ -3236,7 +3222,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="10" valign="top" >radeon</td>
|
||||
<td rowspan="9" valign="top" >radeon</td>
|
||||
<td valign="top" >DVI-I</td>
|
||||
<td valign="top" >“coherent”</td>
|
||||
<td valign="top" >RANGE</td>
|
||||
|
|
@ -3308,14 +3294,6 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >Generic</td>
|
||||
<td valign="top" >Standard name as in DRM</td>
|
||||
<td valign="top" >Standard type as in DRM</td>
|
||||
<td valign="top" >Standard value as in DRM</td>
|
||||
<td valign="top" >Standard Object as in DRM</td>
|
||||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="3" valign="top" >rcar-du</td>
|
||||
<td rowspan="3" valign="top" >Generic</td>
|
||||
<td valign="top" >"alpha"</td>
|
||||
|
|
@ -3407,6 +3385,13 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
|
|||
by scheduling a timer. The delay is accessible through the vblankoffdelay
|
||||
module parameter or the <varname>drm_vblank_offdelay</varname> global
|
||||
variable and expressed in milliseconds. Its default value is 5000 ms.
|
||||
Zero means never disable, and a negative value means disable immediately.
|
||||
Drivers may override the behaviour by setting the
|
||||
<structname>drm_device</structname>
|
||||
<structfield>vblank_disable_immediate</structfield> flag, which when set
|
||||
causes vblank interrupts to be disabled immediately regardless of the
|
||||
drm_vblank_offdelay value. The flag should only be set if there's a
|
||||
properly working hardware vblank counter present.
|
||||
</para>
|
||||
<para>
|
||||
When a vertical blanking interrupt occurs drivers only need to call the
|
||||
|
|
@ -3421,6 +3406,7 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
|
|||
<sect2>
|
||||
<title>Vertical Blanking and Interrupt Handling Functions Reference</title>
|
||||
!Edrivers/gpu/drm/drm_irq.c
|
||||
!Finclude/drm/drmP.h drm_crtc_vblank_waitqueue
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
@ -3939,6 +3925,11 @@ int num_ioctls;</synopsis>
|
|||
!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
|
||||
!Idrivers/gpu/drm/i915/i915_cmd_parser.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Logical Rings, Logical Ring Contexts and Execlists</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists
|
||||
!Idrivers/gpu/drm/i915/intel_lrc.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
</part>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP))
|
|||
PHONY += cleanmediadocs
|
||||
|
||||
cleanmediadocs:
|
||||
-@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2>/dev/null
|
||||
-@rm -f `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2>/dev/null
|
||||
|
||||
$(obj)/media_api.xml: $(GENFILES) FORCE
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -2545,6 +2545,40 @@ fields changed from _s32 to _u32.
|
|||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.16</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added event V4L2_EVENT_SOURCE_CHANGE.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.17</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Extended &v4l2-pix-format;. Added format flags.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Added compound control types and &VIDIOC-QUERY-EXT-CTRL;.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.18</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added <constant>V4L2_CID_PAN_SPEED</constant> and
|
||||
<constant>V4L2_CID_TILT_SPEED</constant> camera controls.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
||||
|
|
|
|||
|
|
@ -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> </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> </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>
|
||||
|
|
|
|||
|
|
@ -29,9 +29,12 @@ can suspend execution until the driver has captured data or is ready
|
|||
to accept data for output.</para>
|
||||
|
||||
<para>When streaming I/O has been negotiated this function waits
|
||||
until a buffer has been filled or displayed and can be dequeued with
|
||||
the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing
|
||||
queue of the driver the function returns immediately.</para>
|
||||
until a buffer has been filled by the capture device and can be dequeued
|
||||
with the &VIDIOC-DQBUF; ioctl. For output devices this function waits
|
||||
until the device is ready to accept a new buffer to be queued up with
|
||||
the &VIDIOC-QBUF; ioctl for display. When buffers are already in the outgoing
|
||||
queue of the driver (capture) or the incoming queue isn't full (display)
|
||||
the function returns immediately.</para>
|
||||
|
||||
<para>On success <function>poll()</function> returns the number of
|
||||
file descriptors that have been selected (that is, file descriptors
|
||||
|
|
@ -44,10 +47,22 @@ Capture devices set the <constant>POLLIN</constant> and
|
|||
flags. When the function timed out it returns a value of zero, on
|
||||
failure it returns <returnvalue>-1</returnvalue> and the
|
||||
<varname>errno</varname> variable is set appropriately. When the
|
||||
application did not call &VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the
|
||||
application did not call &VIDIOC-STREAMON; the
|
||||
<function>poll()</function> function succeeds, but sets the
|
||||
<constant>POLLERR</constant> flag in the
|
||||
<structfield>revents</structfield> field.</para>
|
||||
<structfield>revents</structfield> field. When the
|
||||
application has called &VIDIOC-STREAMON; for a capture device but hasn't
|
||||
yet called &VIDIOC-QBUF;, the <function>poll()</function> function
|
||||
succeeds and sets the <constant>POLLERR</constant> flag in the
|
||||
<structfield>revents</structfield> field. For output devices this
|
||||
same situation will cause <function>poll()</function> to succeed
|
||||
as well, but it sets the <constant>POLLOUT</constant> and
|
||||
<constant>POLLWRNORM</constant> flags in the <structfield>revents</structfield>
|
||||
field.</para>
|
||||
|
||||
<para>If an event occurred (see &VIDIOC-DQEVENT;) then
|
||||
<constant>POLLPRI</constant> will be set in the <structfield>revents</structfield>
|
||||
field and <function>poll()</function> will return.</para>
|
||||
|
||||
<para>When use of the <function>read()</function> function has
|
||||
been negotiated and the driver does not capture yet, the
|
||||
|
|
@ -58,10 +73,18 @@ continuously (as opposed to, for example, still images) the function
|
|||
may return immediately.</para>
|
||||
|
||||
<para>When use of the <function>write()</function> function has
|
||||
been negotiated the <function>poll</function> function just waits
|
||||
been negotiated and the driver does not stream yet, the
|
||||
<function>poll</function> function starts streaming. When that fails
|
||||
it returns a <constant>POLLERR</constant> as above. Otherwise it waits
|
||||
until the driver is ready for a non-blocking
|
||||
<function>write()</function> call.</para>
|
||||
|
||||
<para>If the caller is only interested in events (just
|
||||
<constant>POLLPRI</constant> is set in the <structfield>events</structfield>
|
||||
field), then <function>poll()</function> will <emphasis>not</emphasis>
|
||||
start streaming if the driver does not stream yet. This makes it
|
||||
possible to just poll for events and not for buffers.</para>
|
||||
|
||||
<para>All drivers implementing the <function>read()</function> or
|
||||
<function>write()</function> function or streaming I/O must also
|
||||
support the <function>poll()</function> function.</para>
|
||||
|
|
|
|||
|
|
@ -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 << 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 << 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>
|
||||
|
|
|
|||
|
|
@ -152,10 +152,11 @@ structs, ioctls) must be noted in more detail in the history chapter
|
|||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.16</revnumber>
|
||||
<date>2014-05-27</date>
|
||||
<authorinitials>lp</authorinitials>
|
||||
<revremark>Extended &v4l2-pix-format;. Added format flags.
|
||||
<revnumber>3.17</revnumber>
|
||||
<date>2014-08-04</date>
|
||||
<authorinitials>lp, hv</authorinitials>
|
||||
<revremark>Extended &v4l2-pix-format;. Added format flags. Added compound control types
|
||||
and VIDIOC_QUERY_EXT_CTRL.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
|
|
@ -538,7 +539,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.14</subtitle>
|
||||
<subtitle>Revision 3.17</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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 *</entry>
|
||||
<entry><structfield>edid</structfield></entry>
|
||||
<entry>Pointer to memory that contains the EDID. The minimum size is
|
||||
<structfield>blocks</structfield> * 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 *</entry>
|
||||
<entry><structfield>edid</structfield></entry>
|
||||
<entry>Pointer to memory that contains the EDID. The minimum size is
|
||||
<structfield>blocks</structfield> * 128.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@
|
|||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-rect;</entry>
|
||||
<entry><structfield>rect</structfield></entry>
|
||||
<entry><structfield>r</structfield></entry>
|
||||
<entry>Selection rectangle, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>,
|
||||
|
|
|
|||
|
|
@ -2742,7 +2742,9 @@ struct _snd_pcm_runtime {
|
|||
|
||||
<para>
|
||||
Another note is that this callback is non-atomic
|
||||
(schedulable). This is important, because the
|
||||
(schedulable) as default, i.e. when no
|
||||
<structfield>nonatomic</structfield> flag set.
|
||||
This is important, because the
|
||||
<structfield>trigger</structfield> callback
|
||||
is atomic (non-schedulable). That is, mutexes or any
|
||||
schedule-related functions are not available in
|
||||
|
|
@ -2900,8 +2902,9 @@ struct _snd_pcm_runtime {
|
|||
</para>
|
||||
|
||||
<para>
|
||||
As mentioned, this callback is atomic. You cannot call
|
||||
functions which may sleep.
|
||||
As mentioned, this callback is atomic as default unless
|
||||
<structfield>nonatomic</structfield> flag set, and
|
||||
you cannot call functions which may sleep.
|
||||
The trigger callback should be as minimal as possible,
|
||||
just really triggering the DMA. The other stuff should be
|
||||
initialized hw_params and prepare callbacks properly
|
||||
|
|
@ -2936,7 +2939,7 @@ struct _snd_pcm_runtime {
|
|||
</para>
|
||||
|
||||
<para>
|
||||
This callback is also atomic.
|
||||
This callback is also atomic as default.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
@ -2972,7 +2975,7 @@ struct _snd_pcm_runtime {
|
|||
is useful only for such a purpose.
|
||||
</para>
|
||||
<para>
|
||||
This callback is atomic.
|
||||
This callback is atomic as default.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
@ -3175,6 +3178,21 @@ struct _snd_pcm_runtime {
|
|||
called with local interrupts disabled.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The recent changes in PCM core code, however, allow all PCM
|
||||
operations to be non-atomic. This assumes that the all caller
|
||||
sides are in non-atomic contexts. For example, the function
|
||||
<function>snd_pcm_period_elapsed()</function> is called
|
||||
typically from the interrupt handler. But, if you set up the
|
||||
driver to use a threaded interrupt handler, this call can be in
|
||||
non-atomic context, too. In such a case, you can set
|
||||
<structfield>nonatomic</structfield> filed of
|
||||
<structname>snd_pcm</structname> object after creating it.
|
||||
When this flag is set, mutex and rwsem are used internally in
|
||||
the PCM core instead of spin and rwlocks, so that you can call
|
||||
all PCM functions safely in a non-atomic context.
|
||||
</para>
|
||||
|
||||
</section>
|
||||
<section id="pcm-interface-constraints">
|
||||
<title>Constraints</title>
|
||||
|
|
|
|||
|
|
@ -324,7 +324,6 @@ tree, they need to be integration-tested. For this purpose, a special
|
|||
testing repository exists into which virtually all subsystem trees are
|
||||
pulled on an almost daily basis:
|
||||
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
|
||||
http://linux.f-seidel.de/linux-next/pmwiki/
|
||||
|
||||
This way, the -next kernel gives a summary outlook onto what will be
|
||||
expected to go into the mainline kernel at the next merge period.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -818,7 +818,7 @@ RCU pointer/list update:
|
|||
list_add_tail_rcu
|
||||
list_del_rcu
|
||||
list_replace_rcu
|
||||
hlist_add_after_rcu
|
||||
hlist_add_behind_rcu
|
||||
hlist_add_before_rcu
|
||||
hlist_add_head_rcu
|
||||
hlist_del_rcu
|
||||
|
|
|
|||
|
|
@ -84,18 +84,42 @@ is another popular alternative.
|
|||
|
||||
2) Describe your changes.
|
||||
|
||||
Describe the technical detail of the change(s) your patch includes.
|
||||
Describe your problem. Whether your patch is a one-line bug fix or
|
||||
5000 lines of a new feature, there must be an underlying problem that
|
||||
motivated you to do this work. Convince the reviewer that there is a
|
||||
problem worth fixing and that it makes sense for them to read past the
|
||||
first paragraph.
|
||||
|
||||
Be as specific as possible. The WORST descriptions possible include
|
||||
things like "update driver X", "bug fix for driver X", or "this patch
|
||||
includes updates for subsystem X. Please apply."
|
||||
Describe user-visible impact. Straight up crashes and lockups are
|
||||
pretty convincing, but not all bugs are that blatant. Even if the
|
||||
problem was spotted during code review, describe the impact you think
|
||||
it can have on users. Keep in mind that the majority of Linux
|
||||
installations run kernels from secondary stable trees or
|
||||
vendor/product-specific trees that cherry-pick only specific patches
|
||||
from upstream, so include anything that could help route your change
|
||||
downstream: provoking circumstances, excerpts from dmesg, crash
|
||||
descriptions, performance regressions, latency spikes, lockups, etc.
|
||||
|
||||
Quantify optimizations and trade-offs. If you claim improvements in
|
||||
performance, memory consumption, stack footprint, or binary size,
|
||||
include numbers that back them up. But also describe non-obvious
|
||||
costs. Optimizations usually aren't free but trade-offs between CPU,
|
||||
memory, and readability; or, when it comes to heuristics, between
|
||||
different workloads. Describe the expected downsides of your
|
||||
optimization so that the reviewer can weigh costs against benefits.
|
||||
|
||||
Once the problem is established, describe what you are actually doing
|
||||
about it in technical detail. It's important to describe the change
|
||||
in plain English for the reviewer to verify that the code is behaving
|
||||
as you intend it to.
|
||||
|
||||
The maintainer will thank you if you write your patch description in a
|
||||
form which can be easily pulled into Linux's source code management
|
||||
system, git, as a "commit log". See #15, below.
|
||||
|
||||
If your description starts to get long, that's a sign that you probably
|
||||
need to split up your patch. See #3, next.
|
||||
Solve only one problem per patch. If your description starts to get
|
||||
long, that's a sign that you probably need to split up your patch.
|
||||
See #3, next.
|
||||
|
||||
When you submit or resubmit a patch or patch series, include the
|
||||
complete patch description and justification for it. Don't just
|
||||
|
|
@ -459,12 +483,10 @@ have been included in the discussion
|
|||
|
||||
14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
|
||||
|
||||
If this patch fixes a problem reported by somebody else, consider adding a
|
||||
Reported-by: tag to credit the reporter for their contribution. Please
|
||||
note that this tag should not be added without the reporter's permission,
|
||||
especially if the problem was not reported in a public forum. That said,
|
||||
if we diligently credit our bug reporters, they will, hopefully, be
|
||||
inspired to help us again in the future.
|
||||
The Reported-by tag gives credit to people who find bugs and report them and it
|
||||
hopefully inspires them to help us again in the future. Please note that if
|
||||
the bug was reported in private, then ask for permission first before using the
|
||||
Reported-by tag.
|
||||
|
||||
A Tested-by: tag indicates that the patch has been successfully tested (in
|
||||
some environment) by the person named. This tag informs maintainers that
|
||||
|
|
@ -770,6 +792,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
|
|||
<http://www.kroah.com/log/linux/maintainer-03.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-04.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-05.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-06.html>
|
||||
|
||||
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
||||
<https://lkml.org/lkml/2005/7/11/336>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,52 @@
|
|||
ARM Cache Coherent Network
|
||||
==========================
|
||||
|
||||
CCN-504 is a ring-bus interconnect consisting of 11 crosspoints
|
||||
(XPs), with each crosspoint supporting up to two device ports,
|
||||
so nodes (devices) 0 and 1 are connected to crosspoint 0,
|
||||
nodes 2 and 3 to crosspoint 1 etc.
|
||||
|
||||
PMU (perf) driver
|
||||
-----------------
|
||||
|
||||
The CCN driver registers a perf PMU driver, which provides
|
||||
description of available events and configuration options
|
||||
in sysfs, see /sys/bus/event_source/devices/ccn*.
|
||||
|
||||
The "format" directory describes format of the config, config1
|
||||
and config2 fields of the perf_event_attr structure. The "events"
|
||||
directory provides configuration templates for all documented
|
||||
events, that can be used with perf tool. For example "xp_valid_flit"
|
||||
is an equivalent of "type=0x8,event=0x4". Other parameters must be
|
||||
explicitly specified. For events originating from device, "node"
|
||||
defines its index. All crosspoint events require "xp" (index),
|
||||
"port" (device port number) and "vc" (virtual channel ID) and
|
||||
"dir" (direction). Watchpoints (special "event" value 0xfe) also
|
||||
require comparator values ("cmp_l" and "cmp_h") and "mask", being
|
||||
index of the comparator mask.
|
||||
|
||||
Masks are defined separately from the event description
|
||||
(due to limited number of the config values) in the "cmp_mask"
|
||||
directory, with first 8 configurable by user and additional
|
||||
4 hardcoded for the most frequent use cases.
|
||||
|
||||
Cycle counter is described by a "type" value 0xff and does
|
||||
not require any other settings.
|
||||
|
||||
Example of perf tool use:
|
||||
|
||||
/ # perf list | grep ccn
|
||||
ccn/cycles/ [Kernel PMU event]
|
||||
<...>
|
||||
ccn/xp_valid_flit/ [Kernel PMU event]
|
||||
<...>
|
||||
|
||||
/ # perf stat -C 0 -e ccn/cycles/,ccn/xp_valid_flit,xp=1,port=0,vc=1,dir=1/ \
|
||||
sleep 1
|
||||
|
||||
The driver does not support sampling, therefore "perf record" will
|
||||
not work. Also notice that only single cpu is being selected
|
||||
("-C 0") - this is because perf framework does not support
|
||||
"non-CPU related" counters (yet?) so system-wide session ("-a")
|
||||
would try (and in most cases fail) to set up the same event
|
||||
per each CPU.
|
||||
|
|
@ -0,0 +1 @@
|
|||
subdir-y := SH-Mobile
|
||||
|
|
@ -53,8 +53,8 @@ Kirkwood family
|
|||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-kirkwood
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
Linux kernel mach directory: arch/arm/mach-mvebu
|
||||
Linux kernel plat directory: none
|
||||
|
||||
Discovery family
|
||||
----------------
|
||||
|
|
@ -83,7 +83,9 @@ EBU Armada family
|
|||
88F6710
|
||||
88F6707
|
||||
88F6W11
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
|
||||
Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
|
||||
|
||||
Armada 375 Flavors:
|
||||
88F6720
|
||||
|
|
@ -100,8 +102,11 @@ EBU Armada family
|
|||
MV78460
|
||||
NOTE: not to be confused with the non-SMP 78xx0 SoCs
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
|
||||
|
||||
No public datasheet available.
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
|
||||
Hardware Specs:
|
||||
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
|
||||
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
|
||||
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
|
||||
|
||||
Core: Sheeva ARMv7 compatible
|
||||
|
||||
|
|
@ -135,7 +140,9 @@ Dove family (application processor)
|
|||
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
|
||||
Homepage: http://www.marvell.com/application-processors/armada-500/
|
||||
Core: ARMv7 compatible
|
||||
Directory: arch/arm/mach-dove
|
||||
|
||||
Directory: arch/arm/mach-mvebu (DT enabled platforms)
|
||||
arch/arm/mach-dove (non-DT enabled platforms)
|
||||
|
||||
PXA 2xx/3xx/93x/95x family
|
||||
--------------------------
|
||||
|
|
@ -253,10 +260,10 @@ Berlin family (Digital Entertainment)
|
|||
Long-term plans
|
||||
---------------
|
||||
|
||||
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and
|
||||
mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the
|
||||
Marvell EBU (Engineering Business Unit) in a single mach-<foo>
|
||||
directory. The plat-orion/ would therefore disappear.
|
||||
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the
|
||||
mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering
|
||||
Business Unit) in a single mach-<foo> directory. The plat-orion/
|
||||
would therefore disappear.
|
||||
|
||||
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
|
||||
directory. The plat-pxa/ would therefore disappear.
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
vrl4
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
||||
|
|
|
|||
|
|
@ -13,8 +13,6 @@ Introduction
|
|||
|
||||
- S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
|
||||
- S3C64XX: S3C6400 and S3C6410
|
||||
- S5P6440
|
||||
- S5PC100
|
||||
- S5PC110 / S5PV210
|
||||
|
||||
|
||||
|
|
@ -34,8 +32,6 @@ Configuration
|
|||
A number of configurations are supplied, as there is no current way of
|
||||
unifying all the SoCs into one kernel.
|
||||
|
||||
s5p6440_defconfig - S5P6440 specific default configuration
|
||||
s5pc100_defconfig - S5PC100 specific default configuration
|
||||
s5pc110_defconfig - S5PC110 specific default configuration
|
||||
s5pv210_defconfig - S5PV210 specific default configuration
|
||||
|
||||
|
|
@ -67,13 +63,6 @@ Layout changes
|
|||
where to simplify the include and dependency issues involved with having
|
||||
so many different platform directories.
|
||||
|
||||
It was decided to remove plat-s5pc1xx as some of the support was already
|
||||
in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210
|
||||
the only user was the S5PC100. The S5PC100 specific items where moved to
|
||||
arch/arm/mach-s5pc100.
|
||||
|
||||
|
||||
|
||||
|
||||
Port Contributors
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -68,7 +68,6 @@ BEGIN {
|
|||
|
||||
while (getline line < ARGV[1] > 0) {
|
||||
if (line ~ /\#define.*_MASK/ &&
|
||||
!(line ~ /S5PC100_EPLL_MASK/) &&
|
||||
!(line ~ /USB_SIG_MASK/)) {
|
||||
splitdefine(line, fields)
|
||||
name = fields[0]
|
||||
|
|
|
|||
|
|
@ -168,6 +168,14 @@ Before jumping into the kernel, the following conditions must be met:
|
|||
the kernel image will be entered must be initialised by software at a
|
||||
higher exception level to prevent execution in an UNKNOWN state.
|
||||
|
||||
For systems with a GICv3 interrupt controller:
|
||||
- If EL3 is present:
|
||||
ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
|
||||
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
|
||||
- If the kernel is entered at EL1:
|
||||
ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
|
||||
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
|
||||
|
||||
The requirements described above for CPU mode, caches, MMUs, architected
|
||||
timers, coherency and system registers apply to all CPUs. All CPUs must
|
||||
enter the kernel in the same exception level.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ User addresses have bits 63:48 set to 0 while the kernel addresses have
|
|||
the same bits set to 1. TTBRx selection is given by bit 63 of the
|
||||
virtual address. The swapper_pg_dir contains only kernel (global)
|
||||
mappings while the user pgd contains only user (non-global) mappings.
|
||||
The swapper_pgd_dir address is written to TTBR1 and never written to
|
||||
The swapper_pg_dir address is written to TTBR1 and never written to
|
||||
TTBR0.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,3 @@
|
|||
ifneq ($(CONFIG_BLACKFIN),)
|
||||
obj-m := gptimers-example.o
|
||||
|
||||
all: modules
|
||||
|
||||
modules clean:
|
||||
$(MAKE) -C ../.. SUBDIRS=$(PWD) $@
|
||||
endif
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -345,14 +345,14 @@ the named feature on.
|
|||
The implementation is simple.
|
||||
|
||||
Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
|
||||
PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
|
||||
PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently
|
||||
joins that cpuset. The page allocation calls for the page cache
|
||||
is modified to perform an inline check for this PF_SPREAD_PAGE task
|
||||
is modified to perform an inline check for this PFA_SPREAD_PAGE task
|
||||
flag, and if set, a call to a new routine cpuset_mem_spread_node()
|
||||
returns the node to prefer for the allocation.
|
||||
|
||||
Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
|
||||
PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
|
||||
PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate
|
||||
pages from the node returned by cpuset_mem_spread_node().
|
||||
|
||||
The cpuset_mem_spread_node() routine is also simple. It uses the
|
||||
|
|
|
|||
|
|
@ -24,64 +24,27 @@ Please note that implementation details can be changed.
|
|||
|
||||
a page/swp_entry may be charged (usage += PAGE_SIZE) at
|
||||
|
||||
mem_cgroup_charge_anon()
|
||||
Called at new page fault and Copy-On-Write.
|
||||
|
||||
mem_cgroup_try_charge_swapin()
|
||||
Called at do_swap_page() (page fault on swap entry) and swapoff.
|
||||
Followed by charge-commit-cancel protocol. (With swap accounting)
|
||||
At commit, a charge recorded in swap_cgroup is removed.
|
||||
|
||||
mem_cgroup_charge_file()
|
||||
Called at add_to_page_cache()
|
||||
|
||||
mem_cgroup_cache_charge_swapin()
|
||||
Called at shmem's swapin.
|
||||
|
||||
mem_cgroup_prepare_migration()
|
||||
Called before migration. "extra" charge is done and followed by
|
||||
charge-commit-cancel protocol.
|
||||
At commit, charge against oldpage or newpage will be committed.
|
||||
mem_cgroup_try_charge()
|
||||
|
||||
2. Uncharge
|
||||
a page/swp_entry may be uncharged (usage -= PAGE_SIZE) by
|
||||
|
||||
mem_cgroup_uncharge_page()
|
||||
Called when an anonymous page is fully unmapped. I.e., mapcount goes
|
||||
to 0. If the page is SwapCache, uncharge is delayed until
|
||||
mem_cgroup_uncharge_swapcache().
|
||||
|
||||
mem_cgroup_uncharge_cache_page()
|
||||
Called when a page-cache is deleted from radix-tree. If the page is
|
||||
SwapCache, uncharge is delayed until mem_cgroup_uncharge_swapcache().
|
||||
|
||||
mem_cgroup_uncharge_swapcache()
|
||||
Called when SwapCache is removed from radix-tree. The charge itself
|
||||
is moved to swap_cgroup. (If mem+swap controller is disabled, no
|
||||
charge to swap occurs.)
|
||||
mem_cgroup_uncharge()
|
||||
Called when a page's refcount goes down to 0.
|
||||
|
||||
mem_cgroup_uncharge_swap()
|
||||
Called when swp_entry's refcnt goes down to 0. A charge against swap
|
||||
disappears.
|
||||
|
||||
mem_cgroup_end_migration(old, new)
|
||||
At success of migration old is uncharged (if necessary), a charge
|
||||
to new page is committed. At failure, charge to old page is committed.
|
||||
|
||||
3. charge-commit-cancel
|
||||
In some case, we can't know this "charge" is valid or not at charging
|
||||
(because of races).
|
||||
To handle such case, there are charge-commit-cancel functions.
|
||||
mem_cgroup_try_charge_XXX
|
||||
mem_cgroup_commit_charge_XXX
|
||||
mem_cgroup_cancel_charge_XXX
|
||||
these are used in swap-in and migration.
|
||||
Memcg pages are charged in two steps:
|
||||
mem_cgroup_try_charge()
|
||||
mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
|
||||
|
||||
At try_charge(), there are no flags to say "this page is charged".
|
||||
at this point, usage += PAGE_SIZE.
|
||||
|
||||
At commit(), the function checks the page should be charged or not
|
||||
and set flags or avoid charging.(usage -= PAGE_SIZE)
|
||||
At commit(), the page is associated with the memcg.
|
||||
|
||||
At cancel(), simply usage -= PAGE_SIZE.
|
||||
|
||||
|
|
@ -91,18 +54,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||
Anonymous page is newly allocated at
|
||||
- page fault into MAP_ANONYMOUS mapping.
|
||||
- Copy-On-Write.
|
||||
It is charged right after it's allocated before doing any page table
|
||||
related operations. Of course, it's uncharged when another page is used
|
||||
for the fault address.
|
||||
|
||||
At freeing anonymous page (by exit() or munmap()), zap_pte() is called
|
||||
and pages for ptes are freed one by one.(see mm/memory.c). Uncharges
|
||||
are done at page_remove_rmap() when page_mapcount() goes down to 0.
|
||||
|
||||
Another page freeing is by page-reclaim (vmscan.c) and anonymous
|
||||
pages are swapped out. In this case, the page is marked as
|
||||
PageSwapCache(). uncharge() routine doesn't uncharge the page marked
|
||||
as SwapCache(). It's delayed until __delete_from_swap_cache().
|
||||
|
||||
4.1 Swap-in.
|
||||
At swap-in, the page is taken from swap-cache. There are 2 cases.
|
||||
|
|
@ -111,41 +62,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||
(b) If the SwapCache has been mapped by processes, it has been
|
||||
charged already.
|
||||
|
||||
This swap-in is one of the most complicated work. In do_swap_page(),
|
||||
following events occur when pte is unchanged.
|
||||
|
||||
(1) the page (SwapCache) is looked up.
|
||||
(2) lock_page()
|
||||
(3) try_charge_swapin()
|
||||
(4) reuse_swap_page() (may call delete_swap_cache())
|
||||
(5) commit_charge_swapin()
|
||||
(6) swap_free().
|
||||
|
||||
Considering following situation for example.
|
||||
|
||||
(A) The page has not been charged before (2) and reuse_swap_page()
|
||||
doesn't call delete_from_swap_cache().
|
||||
(B) The page has not been charged before (2) and reuse_swap_page()
|
||||
calls delete_from_swap_cache().
|
||||
(C) The page has been charged before (2) and reuse_swap_page() doesn't
|
||||
call delete_from_swap_cache().
|
||||
(D) The page has been charged before (2) and reuse_swap_page() calls
|
||||
delete_from_swap_cache().
|
||||
|
||||
memory.usage/memsw.usage changes to this page/swp_entry will be
|
||||
Case (A) (B) (C) (D)
|
||||
Event
|
||||
Before (2) 0/ 1 0/ 1 1/ 1 1/ 1
|
||||
===========================================
|
||||
(3) +1/+1 +1/+1 +1/+1 +1/+1
|
||||
(4) - 0/ 0 - -1/ 0
|
||||
(5) 0/-1 0/ 0 -1/-1 0/ 0
|
||||
(6) - 0/-1 - 0/-1
|
||||
===========================================
|
||||
Result 1/ 1 1/ 1 1/ 1 1/ 1
|
||||
|
||||
In any cases, charges to this page should be 1/ 1.
|
||||
|
||||
4.2 Swap-out.
|
||||
At swap-out, typical state transition is below.
|
||||
|
||||
|
|
@ -158,28 +74,20 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||
swp_entry's refcnt -= 1.
|
||||
|
||||
|
||||
At (b), the page is marked as SwapCache and not uncharged.
|
||||
At (d), the page is removed from SwapCache and a charge in page_cgroup
|
||||
is moved to swap_cgroup.
|
||||
|
||||
Finally, at task exit,
|
||||
(e) zap_pte() is called and swp_entry's refcnt -=1 -> 0.
|
||||
Here, a charge in swap_cgroup disappears.
|
||||
|
||||
5. Page Cache
|
||||
Page Cache is charged at
|
||||
- add_to_page_cache_locked().
|
||||
|
||||
uncharged at
|
||||
- __remove_from_page_cache().
|
||||
|
||||
The logic is very clear. (About migration, see below)
|
||||
Note: __remove_from_page_cache() is called by remove_from_page_cache()
|
||||
and __remove_mapping().
|
||||
|
||||
6. Shmem(tmpfs) Page Cache
|
||||
Memcg's charge/uncharge have special handlers of shmem. The best way
|
||||
to understand shmem's page state transition is to read mm/shmem.c.
|
||||
The best way to understand shmem's page state transition is to read
|
||||
mm/shmem.c.
|
||||
But brief explanation of the behavior of memcg around shmem will be
|
||||
helpful to understand the logic.
|
||||
|
||||
|
|
@ -192,56 +100,10 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||
It's charged when...
|
||||
- A new page is added to shmem's radix-tree.
|
||||
- A swp page is read. (move a charge from swap_cgroup to page_cgroup)
|
||||
It's uncharged when
|
||||
- A page is removed from radix-tree and not SwapCache.
|
||||
- When SwapCache is removed, a charge is moved to swap_cgroup.
|
||||
- When swp_entry's refcnt goes down to 0, a charge in swap_cgroup
|
||||
disappears.
|
||||
|
||||
7. Page Migration
|
||||
One of the most complicated functions is page-migration-handler.
|
||||
Memcg has 2 routines. Assume that we are migrating a page's contents
|
||||
from OLDPAGE to NEWPAGE.
|
||||
|
||||
Usual migration logic is..
|
||||
(a) remove the page from LRU.
|
||||
(b) allocate NEWPAGE (migration target)
|
||||
(c) lock by lock_page().
|
||||
(d) unmap all mappings.
|
||||
(e-1) If necessary, replace entry in radix-tree.
|
||||
(e-2) move contents of a page.
|
||||
(f) map all mappings again.
|
||||
(g) pushback the page to LRU.
|
||||
(-) OLDPAGE will be freed.
|
||||
|
||||
Before (g), memcg should complete all necessary charge/uncharge to
|
||||
NEWPAGE/OLDPAGE.
|
||||
|
||||
The point is....
|
||||
- If OLDPAGE is anonymous, all charges will be dropped at (d) because
|
||||
try_to_unmap() drops all mapcount and the page will not be
|
||||
SwapCache.
|
||||
|
||||
- If OLDPAGE is SwapCache, charges will be kept at (g) because
|
||||
__delete_from_swap_cache() isn't called at (e-1)
|
||||
|
||||
- If OLDPAGE is page-cache, charges will be kept at (g) because
|
||||
remove_from_swap_cache() isn't called at (e-1)
|
||||
|
||||
memcg provides following hooks.
|
||||
|
||||
- mem_cgroup_prepare_migration(OLDPAGE)
|
||||
Called after (b) to account a charge (usage += PAGE_SIZE) against
|
||||
memcg which OLDPAGE belongs to.
|
||||
|
||||
- mem_cgroup_end_migration(OLDPAGE, NEWPAGE)
|
||||
Called after (f) before (g).
|
||||
If OLDPAGE is used, commit OLDPAGE again. If OLDPAGE is already
|
||||
charged, a charge by prepare_migration() is automatically canceled.
|
||||
If NEWPAGE is used, commit NEWPAGE and uncharge OLDPAGE.
|
||||
|
||||
But zap_pte() (by exit or munmap) can be called while migration,
|
||||
we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
|
||||
mem_cgroup_migrate()
|
||||
|
||||
8. LRU
|
||||
Each memcg has its own private LRU. Now, its handling is under global
|
||||
|
|
|
|||
|
|
@ -289,10 +289,6 @@ lists when they are assembled; they can be downloaded from:
|
|||
|
||||
http://www.kernel.org/pub/linux/kernel/next/
|
||||
|
||||
Some information about linux-next has been gathered at:
|
||||
|
||||
http://linux.f-seidel.de/linux-next/pmwiki/
|
||||
|
||||
Linux-next has become an integral part of the kernel development process;
|
||||
all patches merged during a given merge window should really have found
|
||||
their way into linux-next some time before the merge window opens.
|
||||
|
|
|
|||
|
|
@ -22,10 +22,6 @@ Beyond that, a valuable resource for kernel developers is:
|
|||
|
||||
http://kernelnewbies.org/
|
||||
|
||||
Information about the linux-next tree gathers at:
|
||||
|
||||
http://linux.f-seidel.de/linux-next/pmwiki/
|
||||
|
||||
And, of course, one should not forget http://kernel.org/, the definitive
|
||||
location for kernel release information.
|
||||
|
||||
|
|
|
|||
|
|
@ -106,6 +106,11 @@ which paths.
|
|||
The path number in the range 0 ... (<num_paths> - 1).
|
||||
Expressed in hexadecimal (WITHOUT any prefix like 0x).
|
||||
|
||||
R<n>,<m>
|
||||
This parameter allows repetitive patterns to be loaded quickly. <n> and <m>
|
||||
are hexadecimal numbers. The last <n> mappings are repeated in the next <m>
|
||||
slots.
|
||||
|
||||
Status
|
||||
======
|
||||
|
||||
|
|
@ -124,3 +129,10 @@ Create a switch device with 64kB region size:
|
|||
Set mappings for the first 7 entries to point to devices switch0, switch1,
|
||||
switch2, switch0, switch1, switch2, switch1:
|
||||
dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1
|
||||
|
||||
Set repetitive mapping. This command:
|
||||
dmsetup message switch 0 set_region_mappings 1000:1 :2 R2,10
|
||||
is equivalent to:
|
||||
dmsetup message switch 0 set_region_mappings 1000:1 :2 :1 :2 :1 :2 :1 :2 \
|
||||
:1 :2 :1 :2 :1 :2 :1 :2 :1 :2
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
Adapteva Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Parallella board
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "adapteva,parallella";
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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";
|
||||
|
|
@ -86,3 +86,9 @@ Interrupt controllers:
|
|||
compatible = "arm,versatile-sic";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
Required nodes:
|
||||
|
||||
- core-module: the root node to the Versatile platforms must have
|
||||
a core-module with regs and the compatible strings
|
||||
"arm,core-module-versatile", "syscon"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,14 @@
|
|||
Marvell Armada 38x CA9 MPcore SoC Controller
|
||||
============================================
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
|
||||
|
||||
- reg: should be the register base and length as documented in the
|
||||
datasheet for the CA9 MPcore SoC Control registers
|
||||
|
||||
mpcore-soc-ctrl@20d20 {
|
||||
compatible = "marvell,armada-380-mpcore-soc-ctrl";
|
||||
reg = <0x20d20 0x6c>;
|
||||
};
|
||||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
* Power Management Controller (PMC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-pmc"
|
||||
- compatible: Should be "atmel,<chip>-pmc".
|
||||
<chip> can be: at91rm9200, at91sam9260, at91sam9g45, at91sam9n12,
|
||||
at91sam9x5, sama5d3
|
||||
|
||||
- reg: Should contain PMC registers location and length
|
||||
|
||||
Examples:
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
Broadcom Kona Family CPU Enable Method
|
||||
--------------------------------------
|
||||
This binding defines the enable method used for starting secondary
|
||||
CPUs in the following Broadcom SoCs:
|
||||
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
|
||||
|
||||
The enable method is specified by defining the following required
|
||||
properties in the "cpus" device tree node:
|
||||
- enable-method = "brcm,bcm11351-cpu-method";
|
||||
- secondary-boot-reg = <...>;
|
||||
|
||||
The secondary-boot-reg property is a u32 value that specifies the
|
||||
physical address of the register used to request the ROM holding pen
|
||||
code release a secondary CPU. The value written to the register is
|
||||
formed by encoding the target CPU id into the low bits of the
|
||||
physical start address it should jump to.
|
||||
|
||||
Example:
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
enable-method = "brcm,bcm11351-cpu-method";
|
||||
secondary-boot-reg = <0x3500417c>;
|
||||
|
||||
cpu0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
cpu1: cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
ARM Broadcom STB platforms Device Tree Bindings
|
||||
-----------------------------------------------
|
||||
Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
|
||||
SoC shall have the following DT organization:
|
||||
|
||||
Required root node properties:
|
||||
- compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
|
||||
|
||||
example:
|
||||
/ {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
model = "Broadcom STB (bcm7445)";
|
||||
compatible = "brcm,bcm7445", "brcm,brcmstb";
|
||||
|
||||
Further, syscon nodes that map platform-specific registers used for general
|
||||
system control is required:
|
||||
|
||||
- compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
|
||||
- compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
|
||||
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
|
||||
|
||||
example:
|
||||
rdb {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "simple-bus";
|
||||
ranges = <0 0x00 0xf0000000 0x1000000>;
|
||||
|
||||
sun_top_ctrl: syscon@404000 {
|
||||
compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
|
||||
reg = <0x404000 0x51c>;
|
||||
};
|
||||
|
||||
hif_cpubiuctrl: syscon@3e2400 {
|
||||
compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
|
||||
reg = <0x3e2400 0x5b4>;
|
||||
};
|
||||
|
||||
hif_continuation: syscon@452000 {
|
||||
compatible = "brcm,bcm7445-hif-continuation", "syscon";
|
||||
reg = <0x452000 0x100>;
|
||||
};
|
||||
};
|
||||
|
||||
Lastly, nodes that allow for support of SMP initialization and reboot are
|
||||
required:
|
||||
|
||||
smpboot
|
||||
-------
|
||||
Required properties:
|
||||
|
||||
- compatible
|
||||
The string "brcm,brcmstb-smpboot".
|
||||
|
||||
- syscon-cpu
|
||||
A phandle / integer array property which lets the BSP know the location
|
||||
of certain CPU power-on registers.
|
||||
|
||||
The layout of the property is as follows:
|
||||
o a phandle to the "hif_cpubiuctrl" syscon node
|
||||
o offset to the base CPU power zone register
|
||||
o offset to the base CPU reset register
|
||||
|
||||
- syscon-cont
|
||||
A phandle pointing to the syscon node which describes the CPU boot
|
||||
continuation registers.
|
||||
o a phandle to the "hif_continuation" syscon node
|
||||
|
||||
example:
|
||||
smpboot {
|
||||
compatible = "brcm,brcmstb-smpboot";
|
||||
syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
|
||||
syscon-cont = <&hif_continuation>;
|
||||
};
|
||||
|
||||
reboot
|
||||
-------
|
||||
Required properties
|
||||
|
||||
- compatible
|
||||
The string property "brcm,brcmstb-reboot".
|
||||
|
||||
- syscon
|
||||
A phandle / integer array that points to the syscon node which describes
|
||||
the general system reset registers.
|
||||
o a phandle to "sun_top_ctrl"
|
||||
o offset to the "reset source enable" register
|
||||
o offset to the "software master reset" register
|
||||
|
||||
example:
|
||||
reboot {
|
||||
compatible = "brcm,brcmstb-reboot";
|
||||
syscon = <&sun_top_ctrl 0x304 0x308>;
|
||||
};
|
||||
|
|
@ -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";
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
* ARM CCN (Cache Coherent Network)
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: (standard compatible string) should be one of:
|
||||
"arm,ccn-504"
|
||||
"arm,ccn-508"
|
||||
|
||||
- reg: (standard registers property) physical address and size
|
||||
(16MB) of the configuration registers block
|
||||
|
||||
- interrupts: (standard interrupt property) single interrupt
|
||||
generated by the control block
|
||||
|
||||
Example:
|
||||
|
||||
ccn@0x2000000000 {
|
||||
compatible = "arm,ccn-504";
|
||||
reg = <0x20 0x00000000 0 0x1000000>;
|
||||
interrupts = <0 181 4>;
|
||||
};
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
========================================================
|
||||
Secondary CPU enable-method "marvell,berlin-smp" binding
|
||||
========================================================
|
||||
|
||||
This document describes the "marvell,berlin-smp" method for enabling secondary
|
||||
CPUs. To apply to all CPUs, a single "marvell,berlin-smp" enable method should
|
||||
be defined in the "cpus" node.
|
||||
|
||||
Enable method name: "marvell,berlin-smp"
|
||||
Compatible machines: "marvell,berlin2" and "marvell,berlin2q"
|
||||
Compatible CPUs: "marvell,pj4b" and "arm,cortex-a9"
|
||||
Related properties: (none)
|
||||
|
||||
Note:
|
||||
This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and
|
||||
"marvell,berlin-cpu-ctrl"[1].
|
||||
|
||||
Example:
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
enable-method = "marvell,berlin-smp";
|
||||
|
||||
cpu@0 {
|
||||
compatible = "marvell,pj4b";
|
||||
device_type = "cpu";
|
||||
next-level-cache = <&l2>;
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "marvell,pj4b";
|
||||
device_type = "cpu";
|
||||
next-level-cache = <&l2>;
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
--
|
||||
[1] arm/marvell,berlin.txt
|
||||
|
|
@ -152,7 +152,9 @@ nodes to be present and contain the properties described below.
|
|||
"arm,cortex-a7"
|
||||
"arm,cortex-a8"
|
||||
"arm,cortex-a9"
|
||||
"arm,cortex-a12"
|
||||
"arm,cortex-a15"
|
||||
"arm,cortex-a17"
|
||||
"arm,cortex-a53"
|
||||
"arm,cortex-a57"
|
||||
"arm,cortex-m0"
|
||||
|
|
@ -163,6 +165,8 @@ nodes to be present and contain the properties described below.
|
|||
"arm,cortex-r4"
|
||||
"arm,cortex-r5"
|
||||
"arm,cortex-r7"
|
||||
"brcm,brahma-b15"
|
||||
"cavium,thunder"
|
||||
"faraday,fa526"
|
||||
"intel,sa110"
|
||||
"intel,sa1100"
|
||||
|
|
@ -184,6 +188,7 @@ nodes to be present and contain the properties described below.
|
|||
can be one of:
|
||||
"allwinner,sun6i-a31"
|
||||
"arm,psci"
|
||||
"brcm,brahma-b15"
|
||||
"marvell,armada-375-smp"
|
||||
"marvell,armada-380-smp"
|
||||
"marvell,armada-xp-smp"
|
||||
|
|
@ -215,6 +220,12 @@ nodes to be present and contain the properties described below.
|
|||
Value type: <phandle>
|
||||
Definition: Specifies the ACC[2] node associated with this CPU.
|
||||
|
||||
- cpu-idle-states
|
||||
Usage: Optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition:
|
||||
# List of phandles to idle state nodes supported
|
||||
by this cpu [3].
|
||||
|
||||
Example 1 (dual-cluster big.LITTLE system 32-bit):
|
||||
|
||||
|
|
@ -411,3 +422,5 @@ cpus {
|
|||
--
|
||||
[1] arm/msm/qcom,saw2.txt
|
||||
[2] arm/msm/qcom,kpss-acc.txt
|
||||
[3] ARM Linux kernel documentation - idle states bindings
|
||||
Documentation/devicetree/bindings/arm/idle-states.txt
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
Geniatech platforms device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
Geniatech ATV1200
|
||||
- compatible = "geniatech,atv1200"
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
* ARM Generic Interrupt Controller, version 3
|
||||
|
||||
AArch64 SMP cores are often associated with a GICv3, providing Private
|
||||
Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
|
||||
Software Generated Interrupts (SGI), and Locality-specific Peripheral
|
||||
Interrupts (LPI).
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should at least contain "arm,gic-v3".
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. Must be a single cell with a value of at least 3.
|
||||
|
||||
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
|
||||
interrupts. Other values are reserved for future use.
|
||||
|
||||
The 2nd cell contains the interrupt number for the interrupt type.
|
||||
SPI interrupts are in the range [0-987]. PPI interrupts are in the
|
||||
range [0-15].
|
||||
|
||||
The 3rd cell is the flags, encoded as follows:
|
||||
bits[3:0] trigger type and level flags.
|
||||
1 = edge triggered
|
||||
4 = level triggered
|
||||
|
||||
Cells 4 and beyond are reserved for future use. When the 1st cell
|
||||
has a value of 0 or 1, cells 4 and beyond act as padding, and may be
|
||||
ignored. It is recommended that padding cells have a value of 0.
|
||||
|
||||
- reg : Specifies base physical address(s) and size of the GIC
|
||||
registers, in the following order:
|
||||
- GIC Distributor interface (GICD)
|
||||
- GIC Redistributors (GICR), one range per redistributor region
|
||||
- GIC CPU interface (GICC)
|
||||
- GIC Hypervisor interface (GICH)
|
||||
- GIC Virtual CPU interface (GICV)
|
||||
|
||||
GICC, GICH and GICV are optional.
|
||||
|
||||
- interrupts : Interrupt source of the VGIC maintenance interrupt.
|
||||
|
||||
Optional
|
||||
|
||||
- redistributor-stride : If using padding pages, specifies the stride
|
||||
of consecutive redistributors. Must be a multiple of 64kB.
|
||||
|
||||
- #redistributor-regions: The number of independent contiguous regions
|
||||
occupied by the redistributors. Required if more than one such
|
||||
region is present.
|
||||
|
||||
Examples:
|
||||
|
||||
gic: interrupt-controller@2cf00000 {
|
||||
compatible = "arm,gic-v3";
|
||||
#interrupt-cells = <3>;
|
||||
interrupt-controller;
|
||||
reg = <0x0 0x2f000000 0 0x10000>, // GICD
|
||||
<0x0 0x2f100000 0 0x200000>, // GICR
|
||||
<0x0 0x2c000000 0 0x2000>, // GICC
|
||||
<0x0 0x2c010000 0 0x2000>, // GICH
|
||||
<0x0 0x2c020000 0 0x2000>; // GICV
|
||||
interrupts = <1 9 4>;
|
||||
};
|
||||
|
||||
gic: interrupt-controller@2c010000 {
|
||||
compatible = "arm,gic-v3";
|
||||
#interrupt-cells = <3>;
|
||||
interrupt-controller;
|
||||
redistributor-stride = <0x0 0x40000>; // 256kB stride
|
||||
#redistributor-regions = <2>;
|
||||
reg = <0x0 0x2c010000 0 0x10000>, // GICD
|
||||
<0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31
|
||||
<0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63
|
||||
<0x0 0x2c040000 0 0x2000>, // GICC
|
||||
<0x0 0x2c060000 0 0x2000>, // GICH
|
||||
<0x0 0x2c080000 0 0x2000>; // GICV
|
||||
interrupts = <1 9 4>;
|
||||
};
|
||||
|
|
@ -16,6 +16,7 @@ Main node required properties:
|
|||
"arm,cortex-a9-gic"
|
||||
"arm,cortex-a7-gic"
|
||||
"arm,arm11mp-gic"
|
||||
"brcm,brahma-b15-gic"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 3.
|
||||
|
|
|
|||
|
|
@ -5,6 +5,11 @@ Hi4511 Board
|
|||
Required root node properties:
|
||||
- compatible = "hisilicon,hi3620-hi4511";
|
||||
|
||||
HiP04 D01 Board
|
||||
Required root node properties:
|
||||
- compatible = "hisilicon,hip04-d01";
|
||||
|
||||
|
||||
Hisilicon system controller
|
||||
|
||||
Required properties:
|
||||
|
|
@ -31,6 +36,17 @@ Example:
|
|||
reboot-offset = <0x4>;
|
||||
};
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Hisilicon CPU controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "hisilicon,cpuctrl"
|
||||
- reg : Register address and size
|
||||
|
||||
The clock registers and power registers of secondary cores are defined
|
||||
in CPU controller, especially in HIX5HD2 SoC.
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
PCTRL: Peripheral misc control register
|
||||
|
||||
Required Properties:
|
||||
|
|
@ -44,3 +60,21 @@ Example:
|
|||
compatible = "hisilicon,pctrl";
|
||||
reg = <0xfca09000 0x1000>;
|
||||
};
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Fabric:
|
||||
|
||||
Required Properties:
|
||||
- compatible: "hisilicon,hip04-fabric";
|
||||
- reg: Address and size of Fabric
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Bootwrapper boot method (software protocol on SMP):
|
||||
|
||||
Required Properties:
|
||||
- compatible: "hisilicon,hip04-bootwrapper";
|
||||
- boot-method: Address and size of boot method.
|
||||
[0]: bootwrapper physical address
|
||||
[1]: bootwrapper size
|
||||
[2]: relocation physical address
|
||||
[3]: relocation size
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -24,6 +24,22 @@ SoC and board used. Currently known SoC compatibles are:
|
|||
...
|
||||
}
|
||||
|
||||
* Marvell Berlin CPU control bindings
|
||||
|
||||
CPU control register allows various operations on CPUs, like resetting them
|
||||
independently.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "marvell,berlin-cpu-ctrl"
|
||||
- reg: address and length of the register set
|
||||
|
||||
Example:
|
||||
|
||||
cpu-ctrl@f7dd0000 {
|
||||
compatible = "marvell,berlin-cpu-ctrl";
|
||||
reg = <0xf7dd0000 0x10000>;
|
||||
};
|
||||
|
||||
* Marvell Berlin2 chip control binding
|
||||
|
||||
Marvell Berlin SoCs have a chip control register set providing several
|
||||
|
|
|
|||
|
|
@ -0,0 +1,14 @@
|
|||
Mediatek MT6589 Platforms Device Tree Bindings
|
||||
|
||||
Boards with a SoC of the Mediatek MT6589 shall have the following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: must contain "mediatek,mt6589"
|
||||
|
||||
|
||||
Supported boards:
|
||||
|
||||
- bq Aquaris5 smart phone:
|
||||
Required root node properties:
|
||||
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
|
||||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -85,6 +85,18 @@ SoCs:
|
|||
- DRA722
|
||||
compatible = "ti,dra722", "ti,dra72", "ti,dra7"
|
||||
|
||||
- AM5728
|
||||
compatible = "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
- AM5726
|
||||
compatible = "ti,am5726", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
- AM5718
|
||||
compatible = "ti,am5718", "ti,dra722", "ti,dra72", "ti,dra7"
|
||||
|
||||
- AM5716
|
||||
compatible = "ti,am5716", "ti,dra722", "ti,dra72", "ti,dra7"
|
||||
|
||||
- AM4372
|
||||
compatible = "ti,am4372", "ti,am43"
|
||||
|
||||
|
|
@ -129,6 +141,9 @@ Boards:
|
|||
- AM437x GP EVM
|
||||
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
|
||||
|
||||
- AM437x SK EVM: AM437x StarterKit Evaluation Module
|
||||
compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
|
||||
|
||||
- DRA742 EVM: Software Development Board for DRA742
|
||||
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,65 @@
|
|||
OMAP PRCM bindings
|
||||
|
||||
Power Reset and Clock Manager lists the device clocks and clockdomains under
|
||||
a DT hierarchy. Each TI SoC can have multiple PRCM entities listed for it,
|
||||
each describing one module and the clock hierarchy under it. see [1] for
|
||||
documentation about the individual clock/clockdomain nodes.
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/ti/*
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be one of:
|
||||
"ti,am3-prcm"
|
||||
"ti,am3-scrm"
|
||||
"ti,am4-prcm"
|
||||
"ti,am4-scrm"
|
||||
"ti,omap2-prcm"
|
||||
"ti,omap2-scrm"
|
||||
"ti,omap3-prm"
|
||||
"ti,omap3-cm"
|
||||
"ti,omap3-scrm"
|
||||
"ti,omap4-cm1"
|
||||
"ti,omap4-prm"
|
||||
"ti,omap4-cm2"
|
||||
"ti,omap4-scrm"
|
||||
"ti,omap5-prm"
|
||||
"ti,omap5-cm-core-aon"
|
||||
"ti,omap5-scrm"
|
||||
"ti,omap5-cm-core"
|
||||
"ti,dra7-prm"
|
||||
"ti,dra7-cm-core-aon"
|
||||
"ti,dra7-cm-core"
|
||||
- reg: Contains PRCM module register address range
|
||||
(base address and length)
|
||||
- clocks: clocks for this module
|
||||
- clockdomains: clockdomains for this module
|
||||
|
||||
Example:
|
||||
|
||||
cm: cm@48004000 {
|
||||
compatible = "ti,omap3-cm";
|
||||
reg = <0x48004000 0x4000>;
|
||||
|
||||
cm_clocks: clocks {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
||||
cm_clockdomains: clockdomains {
|
||||
};
|
||||
}
|
||||
|
||||
&cm_clocks {
|
||||
omap2_32k_fck: omap_32k_fck {
|
||||
#clock-cells = <0>;
|
||||
compatible = "fixed-clock";
|
||||
clock-frequency = <32768>;
|
||||
};
|
||||
};
|
||||
|
||||
&cm_clockdomains {
|
||||
core_l3_clkdm: core_l3_clkdm {
|
||||
compatible = "ti,clockdomain";
|
||||
clocks = <&sdrc_ick>;
|
||||
};
|
||||
};
|
||||
|
|
@ -50,6 +50,16 @@ Main node optional properties:
|
|||
|
||||
- migrate : Function ID for MIGRATE operation
|
||||
|
||||
Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
|
||||
state nodes, as per bindings in [1]) must specify the following properties:
|
||||
|
||||
- arm,psci-suspend-param
|
||||
Usage: Required for state nodes[1] if the corresponding
|
||||
idle-states node entry-method property is set
|
||||
to "psci".
|
||||
Value type: <u32>
|
||||
Definition: power_state parameter to pass to the PSCI
|
||||
suspend call.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -64,7 +74,6 @@ Case 1: PSCI v0.1 only.
|
|||
migrate = <0x95c10003>;
|
||||
};
|
||||
|
||||
|
||||
Case 2: PSCI v0.2 only
|
||||
|
||||
psci {
|
||||
|
|
@ -88,3 +97,6 @@ Case 3: PSCI v0.2 and PSCI v0.1.
|
|||
|
||||
...
|
||||
};
|
||||
|
||||
[1] Kernel documentation - ARM idle states bindings
|
||||
Documentation/devicetree/bindings/arm/idle-states.txt
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue