diff options
Diffstat (limited to 'Documentation')
161 files changed, 5022 insertions, 793 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 07de7e1..27e67a9 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -413,8 +413,6 @@ serial-console.txt - how to set up Linux with a serial line console as the default. sgi-ioc4.txt - description of the SGI IOC4 PCI (multi function) device. -sgi-visws.txt - - short blurb on the SGI Visual Workstations. sh/ - directory with info on porting Linux to a new architecture. smsc_ece1099.txt diff --git a/Documentation/ABI/stable/sysfs-firmware-opal-dump b/Documentation/ABI/stable/sysfs-firmware-opal-dump new file mode 100644 index 0000000..32fe7f5 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-firmware-opal-dump @@ -0,0 +1,41 @@ +What: /sys/firmware/opal/dump +Date: Feb 2014 +Contact: Stewart Smith <stewart@linux.vnet.ibm.com> +Description: + This directory exposes interfaces for interacting with + the FSP and platform dumps through OPAL firmware interface. + + This is only for the powerpc/powernv platform. + + initiate_dump: When '1' is written to it, + we will initiate a dump. + Read this file for supported commands. + + 0xXX-0xYYYY: A directory for dump of type 0xXX and + id 0xYYYY (in hex). The name of this + directory should not be relied upon to + be in this format, only that it's unique + among all dumps. For determining the type + and ID of the dump, use the id and type files. + Do not rely on any particular size of dump + type or dump id. + + Each dump has the following files: + id: An ASCII representation of the dump ID + in hex (e.g. '0x01') + type: An ASCII representation of the type of + dump in the format "0x%x %s" with the ID + in hex and a description of the dump type + (or 'unknown'). + Type '0xffffffff unknown' is used when + we could not get the type from firmware. + e.g. '0x02 System/Platform Dump' + dump: A binary file containing the dump. + The size of the dump is the size of this file. + acknowledge: When 'ack' is written to this, we will + acknowledge that we've retrieved the + dump to the service processor. It will + then remove it, making the dump + inaccessible. + Reading this file will get a list of + supported actions. diff --git a/Documentation/ABI/stable/sysfs-firmware-opal-elog b/Documentation/ABI/stable/sysfs-firmware-opal-elog new file mode 100644 index 0000000..e1f3058 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-firmware-opal-elog @@ -0,0 +1,60 @@ +What: /sys/firmware/opal/elog +Date: Feb 2014 +Contact: Stewart Smith <stewart@linux.vnet.ibm.com> +Description: + This directory exposes error log entries retrieved + through the OPAL firmware interface. + + Each error log is identified by a unique ID and will + exist until explicitly acknowledged to firmware. + + Each log entry has a directory in /sys/firmware/opal/elog. + + Log entries may be purged by the service processor + before retrieved by firmware or retrieved/acknowledged by + Linux if there is no room for more log entries. + + In the event that Linux has retrieved the log entries + but not explicitly acknowledged them to firmware and + the service processor needs more room for log entries, + the only remaining copy of a log message may be in + Linux. + + Typically, a user space daemon will monitor for new + entries, read them out and acknowledge them. + + The service processor may be able to store more log + entries than firmware can, so after you acknowledge + an event from Linux you may instantly get another one + from the queue that was generated some time in the past. + + The raw log format is a binary format. We currently + do not parse this at all in kernel, leaving it up to + user space to solve the problem. In future, we may + do more parsing in kernel and add more files to make + it easier for simple user space processes to extract + more information. + + For each log entry (directory), there are the following + files: + + id: An ASCII representation of the ID of the + error log, in hex - e.g. "0x01". + + type: An ASCII representation of the type id and + description of the type of error log. + Currently just "0x00 PEL" - platform error log. + In the future there may be additional types. + + raw: A read-only binary file that can be read + to get the raw log entry. These are + <16kb, often just hundreds of bytes and + "average" 2kb. + + acknowledge: Writing 'ack' to this file will acknowledge + the error log to firmware (and in turn + the service processor, if applicable). + Shortly after acknowledging it, the log + entry will be removed from sysfs. + Reading this file will list the supported + operations (curently just acknowledge).
\ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index 3c1cc24..7b40a3c 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -57,6 +57,523 @@ What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL /sys/devices/cpu/events/PM_LD_REF_L1 /sys/devices/cpu/events/PM_RUN_CYC /sys/devices/cpu/events/PM_RUN_INST_CMPL + /sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_ALL + /sys/devices/cpu/events/PM_GCT_UTIL_7_TO_10_SLOTS + /sys/devices/cpu/events/PM_PMC2_SAVED + /sys/devices/cpu/events/PM_VSU0_16FLOP + /sys/devices/cpu/events/PM_MRK_LSU_DERAT_MISS + /sys/devices/cpu/events/PM_MRK_ST_CMPL + /sys/devices/cpu/events/PM_NEST_PAIR3_ADD + /sys/devices/cpu/events/PM_L2_ST_DISP + /sys/devices/cpu/events/PM_L2_CASTOUT_MOD + /sys/devices/cpu/events/PM_ISEG + /sys/devices/cpu/events/PM_MRK_INST_TIMEO + /sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_ADDR + /sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM + /sys/devices/cpu/events/PM_IERAT_WR_64K + /sys/devices/cpu/events/PM_MRK_DTLB_MISS_16M + /sys/devices/cpu/events/PM_IERAT_MISS + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_LMEM + /sys/devices/cpu/events/PM_FLOP + /sys/devices/cpu/events/PM_THRD_PRIO_4_5_CYC + /sys/devices/cpu/events/PM_BR_PRED_TA + /sys/devices/cpu/events/PM_EXT_INT + /sys/devices/cpu/events/PM_VSU_FSQRT_FDIV + /sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC + /sys/devices/cpu/events/PM_LSU1_LDF + /sys/devices/cpu/events/PM_IC_WRITE_ALL + /sys/devices/cpu/events/PM_LSU0_SRQ_STFWD + /sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_MOD + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR + /sys/devices/cpu/events/PM_DATA_FROM_L21_MOD + /sys/devices/cpu/events/PM_VSU1_SCAL_DOUBLE_ISSUED + /sys/devices/cpu/events/PM_VSU0_8FLOP + /sys/devices/cpu/events/PM_POWER_EVENT1 + /sys/devices/cpu/events/PM_DISP_CLB_HELD_BAL + /sys/devices/cpu/events/PM_VSU1_2FLOP + /sys/devices/cpu/events/PM_LWSYNC_HELD + /sys/devices/cpu/events/PM_PTEG_FROM_DL2L3_SHR + /sys/devices/cpu/events/PM_INST_FROM_L21_MOD + /sys/devices/cpu/events/PM_IERAT_XLATE_WR_16MPLUS + /sys/devices/cpu/events/PM_IC_REQ_ALL + /sys/devices/cpu/events/PM_DSLB_MISS + /sys/devices/cpu/events/PM_L3_MISS + /sys/devices/cpu/events/PM_LSU0_L1_PREF + /sys/devices/cpu/events/PM_VSU_SCALAR_SINGLE_ISSUED + /sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM_STRIDE + /sys/devices/cpu/events/PM_L2_INST + /sys/devices/cpu/events/PM_VSU0_FRSP + /sys/devices/cpu/events/PM_FLUSH_DISP + /sys/devices/cpu/events/PM_PTEG_FROM_L2MISS + /sys/devices/cpu/events/PM_VSU1_DQ_ISSUED + /sys/devices/cpu/events/PM_MRK_DATA_FROM_DMEM + /sys/devices/cpu/events/PM_LSU_FLUSH_ULD + /sys/devices/cpu/events/PM_PTEG_FROM_LMEM + /sys/devices/cpu/events/PM_MRK_DERAT_MISS_16M + /sys/devices/cpu/events/PM_THRD_ALL_RUN_CYC + /sys/devices/cpu/events/PM_MEM0_PREFETCH_DISP + /sys/devices/cpu/events/PM_MRK_STALL_CMPLU_CYC_COUNT + /sys/devices/cpu/events/PM_DATA_FROM_DL2L3_MOD + /sys/devices/cpu/events/PM_VSU_FRSP + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_MOD + /sys/devices/cpu/events/PM_PMC1_OVERFLOW + /sys/devices/cpu/events/PM_VSU0_SINGLE + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L3MISS + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L31_SHR + /sys/devices/cpu/events/PM_VSU0_VECTOR_SP_ISSUED + /sys/devices/cpu/events/PM_VSU1_FEST + /sys/devices/cpu/events/PM_MRK_INST_DISP + /sys/devices/cpu/events/PM_VSU0_COMPLEX_ISSUED + /sys/devices/cpu/events/PM_LSU1_FLUSH_UST + /sys/devices/cpu/events/PM_FXU_IDLE + /sys/devices/cpu/events/PM_LSU0_FLUSH_ULD + /sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_MOD + /sys/devices/cpu/events/PM_LSU_LMQ_SRQ_EMPTY_ALL_CYC + /sys/devices/cpu/events/PM_LSU1_REJECT_LMQ_FULL + /sys/devices/cpu/events/PM_INST_PTEG_FROM_L21_MOD + /sys/devices/cpu/events/PM_INST_FROM_RL2L3_MOD + /sys/devices/cpu/events/PM_SHL_CREATED + /sys/devices/cpu/events/PM_L2_ST_HIT + /sys/devices/cpu/events/PM_DATA_FROM_DMEM + /sys/devices/cpu/events/PM_L3_LD_MISS + /sys/devices/cpu/events/PM_FXU1_BUSY_FXU0_IDLE + /sys/devices/cpu/events/PM_DISP_CLB_HELD_RES + /sys/devices/cpu/events/PM_L2_SN_SX_I_DONE + /sys/devices/cpu/events/PM_STCX_CMPL + /sys/devices/cpu/events/PM_VSU0_2FLOP + /sys/devices/cpu/events/PM_L3_PREF_MISS + /sys/devices/cpu/events/PM_LSU_SRQ_SYNC_CYC + /sys/devices/cpu/events/PM_LSU_REJECT_ERAT_MISS + /sys/devices/cpu/events/PM_L1_ICACHE_MISS + /sys/devices/cpu/events/PM_LSU1_FLUSH_SRQ + /sys/devices/cpu/events/PM_LD_REF_L1_LSU0 + /sys/devices/cpu/events/PM_VSU0_FEST + /sys/devices/cpu/events/PM_VSU_VECTOR_SINGLE_ISSUED + /sys/devices/cpu/events/PM_FREQ_UP + /sys/devices/cpu/events/PM_DATA_FROM_LMEM + /sys/devices/cpu/events/PM_LSU1_LDX + /sys/devices/cpu/events/PM_PMC3_OVERFLOW + /sys/devices/cpu/events/PM_MRK_BR_MPRED + /sys/devices/cpu/events/PM_SHL_MATCH + /sys/devices/cpu/events/PM_MRK_BR_TAKEN + /sys/devices/cpu/events/PM_ISLB_MISS + /sys/devices/cpu/events/PM_DISP_HELD_THERMAL + /sys/devices/cpu/events/PM_INST_PTEG_FROM_RL2L3_SHR + /sys/devices/cpu/events/PM_LSU1_SRQ_STFWD + /sys/devices/cpu/events/PM_PTEG_FROM_DMEM + /sys/devices/cpu/events/PM_VSU_2FLOP + /sys/devices/cpu/events/PM_GCT_FULL_CYC + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L3_CYC + /sys/devices/cpu/events/PM_LSU_SRQ_S0_ALLOC + /sys/devices/cpu/events/PM_MRK_DERAT_MISS_4K + /sys/devices/cpu/events/PM_BR_MPRED_TA + /sys/devices/cpu/events/PM_INST_PTEG_FROM_L2MISS + /sys/devices/cpu/events/PM_DPU_HELD_POWER + /sys/devices/cpu/events/PM_MRK_VSU_FIN + /sys/devices/cpu/events/PM_LSU_SRQ_S0_VALID + /sys/devices/cpu/events/PM_GCT_EMPTY_CYC + /sys/devices/cpu/events/PM_IOPS_DISP + /sys/devices/cpu/events/PM_RUN_SPURR + /sys/devices/cpu/events/PM_PTEG_FROM_L21_MOD + /sys/devices/cpu/events/PM_VSU0_1FLOP + /sys/devices/cpu/events/PM_SNOOP_TLBIE + /sys/devices/cpu/events/PM_DATA_FROM_L3MISS + /sys/devices/cpu/events/PM_VSU_SINGLE + /sys/devices/cpu/events/PM_DTLB_MISS_16G + /sys/devices/cpu/events/PM_FLUSH + /sys/devices/cpu/events/PM_L2_LD_HIT + /sys/devices/cpu/events/PM_NEST_PAIR2_AND + /sys/devices/cpu/events/PM_VSU1_1FLOP + /sys/devices/cpu/events/PM_IC_PREF_REQ + /sys/devices/cpu/events/PM_L3_LD_HIT + /sys/devices/cpu/events/PM_DISP_HELD + /sys/devices/cpu/events/PM_L2_LD + /sys/devices/cpu/events/PM_LSU_FLUSH_SRQ + /sys/devices/cpu/events/PM_BC_PLUS_8_CONV + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_MOD_CYC + /sys/devices/cpu/events/PM_L2_RCST_BUSY_RC_FULL + /sys/devices/cpu/events/PM_TB_BIT_TRANS + /sys/devices/cpu/events/PM_THERMAL_MAX + /sys/devices/cpu/events/PM_LSU1_FLUSH_ULD + /sys/devices/cpu/events/PM_LSU1_REJECT_LHS + /sys/devices/cpu/events/PM_LSU_LRQ_S0_ALLOC + /sys/devices/cpu/events/PM_L3_CO_L31 + /sys/devices/cpu/events/PM_POWER_EVENT4 + /sys/devices/cpu/events/PM_DATA_FROM_L31_SHR + /sys/devices/cpu/events/PM_BR_UNCOND + /sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_ALLOC + /sys/devices/cpu/events/PM_PMC4_REWIND + /sys/devices/cpu/events/PM_L2_RCLD_DISP + /sys/devices/cpu/events/PM_THRD_PRIO_2_3_CYC + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L2MISS + /sys/devices/cpu/events/PM_IC_DEMAND_L2_BHT_REDIRECT + /sys/devices/cpu/events/PM_DATA_FROM_L31_SHR + /sys/devices/cpu/events/PM_IC_PREF_CANCEL_L2 + /sys/devices/cpu/events/PM_MRK_FIN_STALL_CYC_COUNT + /sys/devices/cpu/events/PM_BR_PRED_CCACHE + /sys/devices/cpu/events/PM_GCT_UTIL_1_TO_2_SLOTS + /sys/devices/cpu/events/PM_MRK_ST_CMPL_INT + /sys/devices/cpu/events/PM_LSU_TWO_TABLEWALK_CYC + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L3MISS + /sys/devices/cpu/events/PM_LSU_SET_MPRED + /sys/devices/cpu/events/PM_FLUSH_DISP_TLBIE + /sys/devices/cpu/events/PM_VSU1_FCONV + /sys/devices/cpu/events/PM_DERAT_MISS_16G + /sys/devices/cpu/events/PM_INST_FROM_LMEM + /sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_REDIRECT + /sys/devices/cpu/events/PM_INST_PTEG_FROM_L2 + /sys/devices/cpu/events/PM_PTEG_FROM_L2 + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_SHR_CYC + /sys/devices/cpu/events/PM_MRK_DTLB_MISS_4K + /sys/devices/cpu/events/PM_VSU0_FPSCR + /sys/devices/cpu/events/PM_VSU1_VECT_DOUBLE_ISSUED + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_RL2L3_MOD + /sys/devices/cpu/events/PM_MEM0_RQ_DISP + /sys/devices/cpu/events/PM_L2_LD_MISS + /sys/devices/cpu/events/PM_VMX_RESULT_SAT_1 + /sys/devices/cpu/events/PM_L1_PREF + /sys/devices/cpu/events/PM_MRK_DATA_FROM_LMEM_CYC + /sys/devices/cpu/events/PM_GRP_IC_MISS_NONSPEC + /sys/devices/cpu/events/PM_PB_NODE_PUMP + /sys/devices/cpu/events/PM_SHL_MERGED + /sys/devices/cpu/events/PM_NEST_PAIR1_ADD + /sys/devices/cpu/events/PM_DATA_FROM_L3 + /sys/devices/cpu/events/PM_LSU_FLUSH + /sys/devices/cpu/events/PM_LSU_SRQ_SYNC_COUNT + /sys/devices/cpu/events/PM_PMC2_OVERFLOW + /sys/devices/cpu/events/PM_LSU_LDF + /sys/devices/cpu/events/PM_POWER_EVENT3 + /sys/devices/cpu/events/PM_DISP_WT + /sys/devices/cpu/events/PM_IC_BANK_CONFLICT + /sys/devices/cpu/events/PM_BR_MPRED_CR_TA + /sys/devices/cpu/events/PM_L2_INST_MISS + /sys/devices/cpu/events/PM_NEST_PAIR2_ADD + /sys/devices/cpu/events/PM_MRK_LSU_FLUSH + /sys/devices/cpu/events/PM_L2_LDST + /sys/devices/cpu/events/PM_INST_FROM_L31_SHR + /sys/devices/cpu/events/PM_VSU0_FIN + /sys/devices/cpu/events/PM_VSU1_FCONV + /sys/devices/cpu/events/PM_INST_FROM_RMEM + /sys/devices/cpu/events/PM_DISP_CLB_HELD_TLBIE + /sys/devices/cpu/events/PM_MRK_DATA_FROM_DMEM_CYC + /sys/devices/cpu/events/PM_BR_PRED_CR + /sys/devices/cpu/events/PM_LSU_REJECT + /sys/devices/cpu/events/PM_GCT_UTIL_3_TO_6_SLOTS + /sys/devices/cpu/events/PM_CMPLU_STALL_END_GCT_NOSLOT + /sys/devices/cpu/events/PM_LSU0_REJECT_LMQ_FULL + /sys/devices/cpu/events/PM_VSU_FEST + /sys/devices/cpu/events/PM_NEST_PAIR0_AND + /sys/devices/cpu/events/PM_PTEG_FROM_L3 + /sys/devices/cpu/events/PM_POWER_EVENT2 + /sys/devices/cpu/events/PM_IC_PREF_CANCEL_PAGE + /sys/devices/cpu/events/PM_VSU0_FSQRT_FDIV + /sys/devices/cpu/events/PM_MRK_GRP_CMPL + /sys/devices/cpu/events/PM_VSU0_SCAL_DOUBLE_ISSUED + /sys/devices/cpu/events/PM_GRP_DISP + /sys/devices/cpu/events/PM_LSU0_LDX + /sys/devices/cpu/events/PM_DATA_FROM_L2 + /sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_MOD + /sys/devices/cpu/events/PM_VSU0_VECT_DOUBLE_ISSUED + /sys/devices/cpu/events/PM_VSU1_2FLOP_DOUBLE + /sys/devices/cpu/events/PM_THRD_PRIO_6_7_CYC + /sys/devices/cpu/events/PM_BC_PLUS_8_RSLV_TAKEN + /sys/devices/cpu/events/PM_BR_MPRED_CR + /sys/devices/cpu/events/PM_L3_CO_MEM + /sys/devices/cpu/events/PM_DATA_FROM_RL2L3_MOD + /sys/devices/cpu/events/PM_LSU_SRQ_FULL_CYC + /sys/devices/cpu/events/PM_TABLEWALK_CYC + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_RMEM + /sys/devices/cpu/events/PM_LSU_SRQ_STFWD + /sys/devices/cpu/events/PM_INST_PTEG_FROM_RMEM + /sys/devices/cpu/events/PM_FXU0_FIN + /sys/devices/cpu/events/PM_LSU1_L1_SW_PREF + /sys/devices/cpu/events/PM_PTEG_FROM_L31_MOD + /sys/devices/cpu/events/PM_PMC5_OVERFLOW + /sys/devices/cpu/events/PM_LD_REF_L1_LSU1 + /sys/devices/cpu/events/PM_INST_PTEG_FROM_L21_SHR + /sys/devices/cpu/events/PM_DATA_FROM_RMEM + /sys/devices/cpu/events/PM_VSU0_SCAL_SINGLE_ISSUED + /sys/devices/cpu/events/PM_BR_MPRED_LSTACK + /sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_MOD_CYC + /sys/devices/cpu/events/PM_LSU0_FLUSH_UST + /sys/devices/cpu/events/PM_LSU_NCST + /sys/devices/cpu/events/PM_BR_TAKEN + /sys/devices/cpu/events/PM_INST_PTEG_FROM_LMEM + /sys/devices/cpu/events/PM_DTLB_MISS_4K + /sys/devices/cpu/events/PM_PMC4_SAVED + /sys/devices/cpu/events/PM_VSU1_PERMUTE_ISSUED + /sys/devices/cpu/events/PM_SLB_MISS + /sys/devices/cpu/events/PM_LSU1_FLUSH_LRQ + /sys/devices/cpu/events/PM_DTLB_MISS + /sys/devices/cpu/events/PM_VSU1_FRSP + /sys/devices/cpu/events/PM_VSU_VECTOR_DOUBLE_ISSUED + /sys/devices/cpu/events/PM_L2_CASTOUT_SHR + /sys/devices/cpu/events/PM_DATA_FROM_DL2L3_SHR + /sys/devices/cpu/events/PM_VSU1_STF + /sys/devices/cpu/events/PM_ST_FIN + /sys/devices/cpu/events/PM_PTEG_FROM_L21_SHR + /sys/devices/cpu/events/PM_L2_LOC_GUESS_WRONG + /sys/devices/cpu/events/PM_MRK_STCX_FAIL + /sys/devices/cpu/events/PM_LSU0_REJECT_LHS + /sys/devices/cpu/events/PM_IC_PREF_CANCEL_HIT + /sys/devices/cpu/events/PM_L3_PREF_BUSY + /sys/devices/cpu/events/PM_MRK_BRU_FIN + /sys/devices/cpu/events/PM_LSU1_NCLD + /sys/devices/cpu/events/PM_INST_PTEG_FROM_L31_MOD + /sys/devices/cpu/events/PM_LSU_NCLD + /sys/devices/cpu/events/PM_LSU_LDX + /sys/devices/cpu/events/PM_L2_LOC_GUESS_CORRECT + /sys/devices/cpu/events/PM_THRESH_TIMEO + /sys/devices/cpu/events/PM_L3_PREF_ST + /sys/devices/cpu/events/PM_DISP_CLB_HELD_SYNC + /sys/devices/cpu/events/PM_VSU_SIMPLE_ISSUED + /sys/devices/cpu/events/PM_VSU1_SINGLE + /sys/devices/cpu/events/PM_DATA_TABLEWALK_CYC + /sys/devices/cpu/events/PM_L2_RC_ST_DONE + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L21_MOD + /sys/devices/cpu/events/PM_LARX_LSU1 + /sys/devices/cpu/events/PM_MRK_DATA_FROM_RMEM + /sys/devices/cpu/events/PM_DISP_CLB_HELD + /sys/devices/cpu/events/PM_DERAT_MISS_4K + /sys/devices/cpu/events/PM_L2_RCLD_DISP_FAIL_ADDR + /sys/devices/cpu/events/PM_SEG_EXCEPTION + /sys/devices/cpu/events/PM_FLUSH_DISP_SB + /sys/devices/cpu/events/PM_L2_DC_INV + /sys/devices/cpu/events/PM_PTEG_FROM_DL2L3_MOD + /sys/devices/cpu/events/PM_DSEG + /sys/devices/cpu/events/PM_BR_PRED_LSTACK + /sys/devices/cpu/events/PM_VSU0_STF + /sys/devices/cpu/events/PM_LSU_FX_FIN + /sys/devices/cpu/events/PM_DERAT_MISS_16M + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_DL2L3_MOD + /sys/devices/cpu/events/PM_GCT_UTIL_11_PLUS_SLOTS + /sys/devices/cpu/events/PM_INST_FROM_L3 + /sys/devices/cpu/events/PM_MRK_IFU_FIN + /sys/devices/cpu/events/PM_ITLB_MISS + /sys/devices/cpu/events/PM_VSU_STF + /sys/devices/cpu/events/PM_LSU_FLUSH_UST + /sys/devices/cpu/events/PM_L2_LDST_MISS + /sys/devices/cpu/events/PM_FXU1_FIN + /sys/devices/cpu/events/PM_SHL_DEALLOCATED + /sys/devices/cpu/events/PM_L2_SN_M_WR_DONE + /sys/devices/cpu/events/PM_LSU_REJECT_SET_MPRED + /sys/devices/cpu/events/PM_L3_PREF_LD + /sys/devices/cpu/events/PM_L2_SN_M_RD_DONE + /sys/devices/cpu/events/PM_MRK_DERAT_MISS_16G + /sys/devices/cpu/events/PM_VSU_FCONV + /sys/devices/cpu/events/PM_ANY_THRD_RUN_CYC + /sys/devices/cpu/events/PM_LSU_LMQ_FULL_CYC + /sys/devices/cpu/events/PM_MRK_LSU_REJECT_LHS + /sys/devices/cpu/events/PM_MRK_LD_MISS_L1_CYC + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L2_CYC + /sys/devices/cpu/events/PM_INST_IMC_MATCH_DISP + /sys/devices/cpu/events/PM_MRK_DATA_FROM_RMEM_CYC + /sys/devices/cpu/events/PM_VSU0_SIMPLE_ISSUED + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_RL2L3_SHR + /sys/devices/cpu/events/PM_VSU_FMA_DOUBLE + /sys/devices/cpu/events/PM_VSU_4FLOP + /sys/devices/cpu/events/PM_VSU1_FIN + /sys/devices/cpu/events/PM_NEST_PAIR1_AND + /sys/devices/cpu/events/PM_INST_PTEG_FROM_RL2L3_MOD + /sys/devices/cpu/events/PM_PTEG_FROM_RMEM + /sys/devices/cpu/events/PM_LSU_LRQ_S0_VALID + /sys/devices/cpu/events/PM_LSU0_LDF + /sys/devices/cpu/events/PM_FLUSH_COMPLETION + /sys/devices/cpu/events/PM_ST_MISS_L1 + /sys/devices/cpu/events/PM_L2_NODE_PUMP + /sys/devices/cpu/events/PM_INST_FROM_DL2L3_SHR + /sys/devices/cpu/events/PM_MRK_STALL_CMPLU_CYC + /sys/devices/cpu/events/PM_VSU1_DENORM + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR_CYC + /sys/devices/cpu/events/PM_NEST_PAIR0_ADD + /sys/devices/cpu/events/PM_INST_FROM_L3MISS + /sys/devices/cpu/events/PM_EE_OFF_EXT_INT + /sys/devices/cpu/events/PM_INST_PTEG_FROM_DMEM + /sys/devices/cpu/events/PM_INST_FROM_DL2L3_MOD + /sys/devices/cpu/events/PM_PMC6_OVERFLOW + /sys/devices/cpu/events/PM_VSU_2FLOP_DOUBLE + /sys/devices/cpu/events/PM_TLB_MISS + /sys/devices/cpu/events/PM_FXU_BUSY + /sys/devices/cpu/events/PM_L2_RCLD_DISP_FAIL_OTHER + /sys/devices/cpu/events/PM_LSU_REJECT_LMQ_FULL + /sys/devices/cpu/events/PM_IC_RELOAD_SHR + /sys/devices/cpu/events/PM_GRP_MRK + /sys/devices/cpu/events/PM_MRK_ST_NEST + /sys/devices/cpu/events/PM_VSU1_FSQRT_FDIV + /sys/devices/cpu/events/PM_LSU0_FLUSH_LRQ + /sys/devices/cpu/events/PM_LARX_LSU0 + /sys/devices/cpu/events/PM_IBUF_FULL_CYC + /sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_SHR_CYC + /sys/devices/cpu/events/PM_LSU_DC_PREF_STREAM_ALLOC + /sys/devices/cpu/events/PM_GRP_MRK_CYC + /sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_SHR_CYC + /sys/devices/cpu/events/PM_L2_GLOB_GUESS_CORRECT + /sys/devices/cpu/events/PM_LSU_REJECT_LHS + /sys/devices/cpu/events/PM_MRK_DATA_FROM_LMEM + /sys/devices/cpu/events/PM_INST_PTEG_FROM_L3 + /sys/devices/cpu/events/PM_FREQ_DOWN + /sys/devices/cpu/events/PM_PB_RETRY_NODE_PUMP + /sys/devices/cpu/events/PM_INST_FROM_RL2L3_SHR + /sys/devices/cpu/events/PM_MRK_INST_ISSUED + /sys/devices/cpu/events/PM_PTEG_FROM_L3MISS + /sys/devices/cpu/events/PM_RUN_PURR + /sys/devices/cpu/events/PM_MRK_GRP_IC_MISS + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L3 + /sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_SHR + /sys/devices/cpu/events/PM_LSU_FLUSH_LRQ + /sys/devices/cpu/events/PM_MRK_DERAT_MISS_64K + /sys/devices/cpu/events/PM_INST_PTEG_FROM_DL2L3_MOD + /sys/devices/cpu/events/PM_L2_ST_MISS + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L21_SHR + /sys/devices/cpu/events/PM_LWSYNC + /sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_CONFIRM_STRIDE + /sys/devices/cpu/events/PM_MRK_LSU_FLUSH_LRQ + /sys/devices/cpu/events/PM_INST_IMC_MATCH_CMPL + /sys/devices/cpu/events/PM_NEST_PAIR3_AND + /sys/devices/cpu/events/PM_PB_RETRY_SYS_PUMP + /sys/devices/cpu/events/PM_MRK_INST_FIN + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_DL2L3_SHR + /sys/devices/cpu/events/PM_INST_FROM_L31_MOD + /sys/devices/cpu/events/PM_MRK_DTLB_MISS_64K + /sys/devices/cpu/events/PM_LSU_FIN + /sys/devices/cpu/events/PM_MRK_LSU_REJECT + /sys/devices/cpu/events/PM_L2_CO_FAIL_BUSY + /sys/devices/cpu/events/PM_MEM0_WQ_DISP + /sys/devices/cpu/events/PM_DATA_FROM_L31_MOD + /sys/devices/cpu/events/PM_THERMAL_WARN + /sys/devices/cpu/events/PM_VSU0_4FLOP + /sys/devices/cpu/events/PM_BR_MPRED_CCACHE + /sys/devices/cpu/events/PM_L1_DEMAND_WRITE + /sys/devices/cpu/events/PM_FLUSH_BR_MPRED + /sys/devices/cpu/events/PM_MRK_DTLB_MISS_16G + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_DMEM + /sys/devices/cpu/events/PM_L2_RCST_DISP + /sys/devices/cpu/events/PM_LSU_PARTIAL_CDF + /sys/devices/cpu/events/PM_DISP_CLB_HELD_SB + /sys/devices/cpu/events/PM_VSU0_FMA_DOUBLE + /sys/devices/cpu/events/PM_FXU0_BUSY_FXU1_IDLE + /sys/devices/cpu/events/PM_IC_DEMAND_CYC + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_SHR + /sys/devices/cpu/events/PM_MRK_LSU_FLUSH_UST + /sys/devices/cpu/events/PM_INST_PTEG_FROM_L3MISS + /sys/devices/cpu/events/PM_VSU_DENORM + /sys/devices/cpu/events/PM_MRK_LSU_PARTIAL_CDF + /sys/devices/cpu/events/PM_INST_FROM_L21_SHR + /sys/devices/cpu/events/PM_IC_PREF_WRITE + /sys/devices/cpu/events/PM_BR_PRED + /sys/devices/cpu/events/PM_INST_FROM_DMEM + /sys/devices/cpu/events/PM_IC_PREF_CANCEL_ALL + /sys/devices/cpu/events/PM_LSU_DC_PREF_STREAM_CONFIRM + /sys/devices/cpu/events/PM_MRK_LSU_FLUSH_SRQ + /sys/devices/cpu/events/PM_MRK_FIN_STALL_CYC + /sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_OTHER + /sys/devices/cpu/events/PM_VSU1_DD_ISSUED + /sys/devices/cpu/events/PM_PTEG_FROM_L31_SHR + /sys/devices/cpu/events/PM_DATA_FROM_L21_SHR + /sys/devices/cpu/events/PM_LSU0_NCLD + /sys/devices/cpu/events/PM_VSU1_4FLOP + /sys/devices/cpu/events/PM_VSU1_8FLOP + /sys/devices/cpu/events/PM_VSU_8FLOP + /sys/devices/cpu/events/PM_LSU_LMQ_SRQ_EMPTY_CYC + /sys/devices/cpu/events/PM_DTLB_MISS_64K + /sys/devices/cpu/events/PM_THRD_CONC_RUN_INST + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L2 + /sys/devices/cpu/events/PM_PB_SYS_PUMP + /sys/devices/cpu/events/PM_VSU_FIN + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_MOD + /sys/devices/cpu/events/PM_THRD_PRIO_0_1_CYC + /sys/devices/cpu/events/PM_DERAT_MISS_64K + /sys/devices/cpu/events/PM_PMC2_REWIND + /sys/devices/cpu/events/PM_INST_FROM_L2 + /sys/devices/cpu/events/PM_GRP_BR_MPRED_NONSPEC + /sys/devices/cpu/events/PM_INST_DISP + /sys/devices/cpu/events/PM_MEM0_RD_CANCEL_TOTAL + /sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_CONFIRM + /sys/devices/cpu/events/PM_L1_DCACHE_RELOAD_VALID + /sys/devices/cpu/events/PM_VSU_SCALAR_DOUBLE_ISSUED + /sys/devices/cpu/events/PM_L3_PREF_HIT + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L31_MOD + /sys/devices/cpu/events/PM_MRK_FXU_FIN + /sys/devices/cpu/events/PM_PMC4_OVERFLOW + /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L3 + /sys/devices/cpu/events/PM_LSU0_LMQ_LHR_MERGE + /sys/devices/cpu/events/PM_BTAC_HIT + /sys/devices/cpu/events/PM_L3_RD_BUSY + /sys/devices/cpu/events/PM_LSU0_L1_SW_PREF + /sys/devices/cpu/events/PM_INST_FROM_L2MISS + /sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_ALLOC + /sys/devices/cpu/events/PM_L2_ST + /sys/devices/cpu/events/PM_VSU0_DENORM + /sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_SHR + /sys/devices/cpu/events/PM_BR_PRED_CR_TA + /sys/devices/cpu/events/PM_VSU0_FCONV + /sys/devices/cpu/events/PM_MRK_LSU_FLUSH_ULD + /sys/devices/cpu/events/PM_BTAC_MISS + /sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC_COUNT + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L2 + /sys/devices/cpu/events/PM_LSU_DCACHE_RELOAD_VALID + /sys/devices/cpu/events/PM_VSU_FMA + /sys/devices/cpu/events/PM_LSU0_FLUSH_SRQ + /sys/devices/cpu/events/PM_LSU1_L1_PREF + /sys/devices/cpu/events/PM_IOPS_CMPL + /sys/devices/cpu/events/PM_L2_SYS_PUMP + /sys/devices/cpu/events/PM_L2_RCLD_BUSY_RC_FULL + /sys/devices/cpu/events/PM_LSU_LMQ_S0_ALLOC + /sys/devices/cpu/events/PM_FLUSH_DISP_SYNC + /sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_MOD_CYC + /sys/devices/cpu/events/PM_L2_IC_INV + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_MOD_CYC + /sys/devices/cpu/events/PM_L3_PREF_LDST + /sys/devices/cpu/events/PM_LSU_SRQ_EMPTY_CYC + /sys/devices/cpu/events/PM_LSU_LMQ_S0_VALID + /sys/devices/cpu/events/PM_FLUSH_PARTIAL + /sys/devices/cpu/events/PM_VSU1_FMA_DOUBLE + /sys/devices/cpu/events/PM_1PLUS_PPC_DISP + /sys/devices/cpu/events/PM_DATA_FROM_L2MISS + /sys/devices/cpu/events/PM_SUSPENDED + /sys/devices/cpu/events/PM_VSU0_FMA + /sys/devices/cpu/events/PM_STCX_FAIL + /sys/devices/cpu/events/PM_VSU0_FSQRT_FDIV_DOUBLE + /sys/devices/cpu/events/PM_DC_PREF_DST + /sys/devices/cpu/events/PM_VSU1_SCAL_SINGLE_ISSUED + /sys/devices/cpu/events/PM_L3_HIT + /sys/devices/cpu/events/PM_L2_GLOB_GUESS_WRONG + /sys/devices/cpu/events/PM_MRK_DFU_FIN + /sys/devices/cpu/events/PM_INST_FROM_L1 + /sys/devices/cpu/events/PM_IC_DEMAND_REQ + /sys/devices/cpu/events/PM_VSU1_FSQRT_FDIV_DOUBLE + /sys/devices/cpu/events/PM_VSU1_FMA + /sys/devices/cpu/events/PM_MRK_LD_MISS_L1 + /sys/devices/cpu/events/PM_VSU0_2FLOP_DOUBLE + /sys/devices/cpu/events/PM_LSU_DC_PREF_STRIDED_STREAM_CONFIRM + /sys/devices/cpu/events/PM_INST_PTEG_FROM_L31_SHR + /sys/devices/cpu/events/PM_MRK_LSU_REJECT_ERAT_MISS + /sys/devices/cpu/events/PM_MRK_DATA_FROM_L2MISS + /sys/devices/cpu/events/PM_DATA_FROM_RL2L3_SHR + /sys/devices/cpu/events/PM_INST_FROM_PREF + /sys/devices/cpu/events/PM_VSU1_SQ + /sys/devices/cpu/events/PM_L2_LD_DISP + /sys/devices/cpu/events/PM_L2_DISP_ALL + /sys/devices/cpu/events/PM_THRD_GRP_CMPL_BOTH_CYC + /sys/devices/cpu/events/PM_VSU_FSQRT_FDIV_DOUBLE + /sys/devices/cpu/events/PM_INST_PTEG_FROM_DL2L3_SHR + /sys/devices/cpu/events/PM_VSU_1FLOP + /sys/devices/cpu/events/PM_HV_CYC + /sys/devices/cpu/events/PM_MRK_LSU_FIN + /sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_SHR + /sys/devices/cpu/events/PM_DTLB_MISS_16M + /sys/devices/cpu/events/PM_LSU1_LMQ_LHR_MERGE + /sys/devices/cpu/events/PM_IFU_FIN + /sys/devices/cpu/events/PM_1THRD_CON_RUN_INSTR + /sys/devices/cpu/events/PM_CMPLU_STALL_COUNT + /sys/devices/cpu/events/PM_MEM0_PB_RD_CL + /sys/devices/cpu/events/PM_THRD_1_RUN_CYC + /sys/devices/cpu/events/PM_THRD_2_CONC_RUN_INSTR + /sys/devices/cpu/events/PM_THRD_2_RUN_CYC + /sys/devices/cpu/events/PM_THRD_3_CONC_RUN_INST + /sys/devices/cpu/events/PM_THRD_3_RUN_CYC + /sys/devices/cpu/events/PM_THRD_4_CONC_RUN_INST + /sys/devices/cpu/events/PM_THRD_4_RUN_CYC Date: 2013/01/08 diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 new file mode 100644 index 0000000..e78ee79 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 @@ -0,0 +1,23 @@ +What: /sys/bus/event_source/devices/hv_24x7/interface/catalog +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + Provides access to the binary "24x7 catalog" provided by the + hypervisor on POWER7 and 8 systems. This catalog lists events + avaliable from the powerpc "hv_24x7" pmu. Its format is + documented here: + https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h + +What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_length +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + A number equal to the length in bytes of the catalog. This is + also extractable from the provided binary "catalog" sysfs entry. + +What: /sys/bus/event_source/devices/hv_24x7/interface/catalog_version +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + Exposes the "version" field of the 24x7 catalog. This is also + extractable from the provided binary "catalog" sysfs entry. diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci new file mode 100644 index 0000000..3fa58c2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci @@ -0,0 +1,43 @@ +What: /sys/bus/event_source/devices/hv_gpci/interface/collect_privileged +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + '0' if the hypervisor is configured to forbid access to event + counters being accumulated by other guests and to physical + domain event counters. + '1' if that access is allowed. + +What: /sys/bus/event_source/devices/hv_gpci/interface/ga +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + 0 or 1. Indicates whether we have access to "GA" events (listed + in arch/powerpc/perf/hv-gpci.h). + +What: /sys/bus/event_source/devices/hv_gpci/interface/expanded +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + 0 or 1. Indicates whether we have access to "EXPANDED" events (listed + in arch/powerpc/perf/hv-gpci.h). + +What: /sys/bus/event_source/devices/hv_gpci/interface/lab +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + 0 or 1. Indicates whether we have access to "LAB" events (listed + in arch/powerpc/perf/hv-gpci.h). + +What: /sys/bus/event_source/devices/hv_gpci/interface/version +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + A number indicating the version of the gpci interface that the + hypervisor reports supporting. + +What: /sys/bus/event_source/devices/hv_gpci/interface/kernel_version +Date: February 2014 +Contact: Cody P Schafer <cody@linux.vnet.ibm.com> +Description: + A number indicating the latest version of the gpci interface + that the kernel is aware of. diff --git a/Documentation/ABI/testing/sysfs-class-scsi_host b/Documentation/ABI/testing/sysfs-class-scsi_host index 29a4f89..0eb255e 100644 --- a/Documentation/ABI/testing/sysfs-class-scsi_host +++ b/Documentation/ABI/testing/sysfs-class-scsi_host @@ -11,3 +11,19 @@ Description: guaranteed. The 'isci_id' attribute unambiguously identifies the controller index: '0' for the first controller, '1' for the second. + +What: /sys/class/scsi_host/hostX/acciopath_status +Date: November 2013 +Contact: Stephen M. Cameron <scameron@beardog.cce.hp.com> +Description: This file contains the current status of the "SSD Smart Path" + feature of HP Smart Array RAID controllers using the hpsa + driver. SSD Smart Path, when enabled permits the driver to + send i/o requests directly to physical devices that are part + of a logical drive, bypassing the controllers firmware RAID + stack for a performance advantage when possible. A value of + '1' indicates the feature is enabled, and the controller may + use the direct i/o path to physical devices. A value of zero + means the feature is disabled and the controller may not use + the direct i/o path to physical devices. This setting is + controller wide, affecting all configured logical drives on the + controller. This file is readable and writable. diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index efe449b..7dbf96b 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -187,7 +187,7 @@ Description: Not all drivers support this attribute. If it isn't supported, attempts to read or write it will yield I/O errors. -What: /sys/devices/.../power/pm_qos_latency_us +What: /sys/devices/.../power/pm_qos_resume_latency_us Date: March 2012 Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: @@ -205,6 +205,31 @@ Description: This attribute has no effect on system-wide suspend/resume and hibernation. +What: /sys/devices/.../power/pm_qos_latency_tolerance_us +Date: January 2014 +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> +Description: + The /sys/devices/.../power/pm_qos_latency_tolerance_us attribute + contains the PM QoS active state latency tolerance limit for the + given device in microseconds. That is the maximum memory access + latency the device can suffer without any visible adverse + effects on user space functionality. If that value is the + string "any", the latency does not matter to user space at all, + but hardware should not be allowed to set the latency tolerance + for the device automatically. + + Reading "auto" from this file means that the maximum memory + access latency for the device may be determined automatically + by the hardware as needed. Writing "auto" to it allows the + hardware to be switched to this mode if there are no other + latency tolerance requirements from the kernel side. + + This attribute is only present if the feature controlled by it + is supported by the hardware. + + This attribute has no effect on runtime suspend and resume of + devices and on system-wide suspend/resume and hibernation. + What: /sys/devices/.../power/pm_qos_no_power_off Date: September 2012 Contact: Rafael J. Wysocki <rjw@rjwysocki.net> diff --git a/Documentation/ABI/testing/sysfs-firmware-ofw b/Documentation/ABI/testing/sysfs-firmware-ofw new file mode 100644 index 0000000..f562b18 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-ofw @@ -0,0 +1,28 @@ +What: /sys/firmware/devicetree/* +Date: November 2013 +Contact: Grant Likely <grant.likely@linaro.org> +Description: + When using OpenFirmware or a Flattened Device Tree to enumerate + hardware, the device tree structure will be exposed in this + directory. + + It is possible for multiple device-tree directories to exist. + Some device drivers use a separate detached device tree which + have no attachment to the system tree and will appear in a + different subdirectory under /sys/firmware/devicetree. + + Userspace must not use the /sys/firmware/devicetree/base + path directly, but instead should follow /proc/device-tree + symlink. It is possible that the absolute path will change + in the future, but the symlink is the stable ABI. + + The /proc/device-tree symlink replaces the devicetree /proc + filesystem support, and has largely the same semantics and + should be compatible with existing userspace. + + The contents of /sys/firmware/devicetree/ is a + hierarchy of directories, one per device tree node. The + directory name is the resolved path component name (node + name plus address). Properties are represented as files + in the directory. The contents of each file is the exact + binary data from the device tree. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 205a738..64c9276 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -12,8 +12,9 @@ Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/state file controls the system power state. Reading from this file returns what states are supported, - which is hard-coded to 'standby' (Power-On Suspend), 'mem' - (Suspend-to-RAM), and 'disk' (Suspend-to-Disk). + which is hard-coded to 'freeze' (Low-Power Idle), 'standby' + (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' + (Suspend-to-Disk). Writing to this file one of these strings causes the system to transition into that state. Please see the file diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 0f9c6ff..8d96ebf 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml + tracepoint.xml drm.xml media_api.xml w1.xml include $(srctree)/Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index a9b15e3..24c22ca 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -196,7 +196,7 @@ get/set up to 64 properties. The actual meaning of each property is described on <para>1)For satellital delivery systems, it is measured in kHz. For the other ones, it is measured in Hz.</para> <para>2)For ISDB-T, the channels are usually transmitted with an offset of 143kHz. - E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of + E.g. a valid frequency could be 474143 kHz. The stepping is bound to the bandwidth of the channel which is 6MHz.</para> <para>3)As in ISDB-Tsb the channel consists of only one or three segments the diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index c4cac6d..86c6dd2 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -397,7 +397,7 @@ linkend="control" />.</para> <para>The <structfield>depth</structfield> (average number of bits per pixel) of a video image is implied by the selected image -format. V4L2 does not explicitely provide such information assuming +format. V4L2 does not explicitly provide such information assuming applications recognizing the format are aware of the image depth and others need not know. The <structfield>palette</structfield> field moved into the &v4l2-pix-format;:<informaltable> diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 4c8d282..ab56f89c 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -58,7 +58,7 @@ Foundation. A copy of the license is included in the chapter entitled <title>Introduction</title> <para>This document covers the Linux Kernel to Userspace API's used by - video and radio straming devices, including video cameras, + video and radio streaming devices, including video cameras, analog and digital TV receiver cards, AM/FM receiver cards, streaming capture devices.</para> <para>It is divided into four parts.</para> diff --git a/Documentation/DocBook/w1.tmpl b/Documentation/DocBook/w1.tmpl new file mode 100644 index 0000000..b0228d4 --- /dev/null +++ b/Documentation/DocBook/w1.tmpl @@ -0,0 +1,101 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> + +<book id="w1id"> + <bookinfo> + <title>W1: Dallas' 1-wire bus</title> + + <authorgroup> + <author> + <firstname>David</firstname> + <surname>Fries</surname> + <affiliation> + <address> + <email>David@Fries.net</email> + </address> + </affiliation> + </author> + + </authorgroup> + + <copyright> + <year>2013</year> + <!-- + <holder></holder> + --> + </copyright> + + <legalnotice> + <para> + This documentation is free software; you can redistribute + it and/or modify it under the terms of the GNU General Public + License version 2. + </para> + + <para> + This program is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + For more details see the file COPYING in the source + distribution of Linux. + </para> + </legalnotice> + </bookinfo> + + <toc></toc> + + <chapter id="w1_internal"> + <title>W1 API internal to the kernel</title> + + <sect1 id="w1_internal_api"> + <title>W1 API internal to the kernel</title> + <sect2 id="w1.h"> + <title>drivers/w1/w1.h</title> + <para>W1 core functions.</para> +!Idrivers/w1/w1.h + </sect2> + + <sect2 id="w1.c"> + <title>drivers/w1/w1.c</title> + <para>W1 core functions.</para> +!Idrivers/w1/w1.c + </sect2> + + <sect2 id="w1_family.h"> + <title>drivers/w1/w1_family.h</title> + <para>Allows registering device family operations.</para> +!Idrivers/w1/w1_family.h + </sect2> + + <sect2 id="w1_family.c"> + <title>drivers/w1/w1_family.c</title> + <para>Allows registering device family operations.</para> +!Edrivers/w1/w1_family.c + </sect2> + + <sect2 id="w1_int.c"> + <title>drivers/w1/w1_int.c</title> + <para>W1 internal initialization for master devices.</para> +!Edrivers/w1/w1_int.c + </sect2> + + <sect2 id="w1_netlink.h"> + <title>drivers/w1/w1_netlink.h</title> + <para>W1 external netlink API structures and commands.</para> +!Idrivers/w1/w1_netlink.h + </sect2> + + <sect2 id="w1_io.c"> + <title>drivers/w1/w1_io.c</title> + <para>W1 input/output.</para> +!Edrivers/w1/w1_io.c +!Idrivers/w1/w1_io.c + </sect2> + + </sect1> + + + </chapter> + +</book> diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl index 06741e9..d0056a4 100644 --- a/Documentation/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl @@ -468,8 +468,6 @@ return err; } - snd_card_set_dev(card, &pci->dev); - *rchip = chip; return 0; } @@ -492,7 +490,8 @@ } /* (2) */ - err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); + err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, + 0, &card); if (err < 0) return err; @@ -591,7 +590,8 @@ struct snd_card *card; int err; .... - err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); + err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, + 0, &card); ]]> </programlisting> </informalexample> @@ -809,28 +809,34 @@ <para> As mentioned above, to create a card instance, call - <function>snd_card_create()</function>. + <function>snd_card_new()</function>. <informalexample> <programlisting> <![CDATA[ struct snd_card *card; int err; - err = snd_card_create(index, id, module, extra_size, &card); + err = snd_card_new(&pci->dev, index, id, module, extra_size, &card); ]]> </programlisting> </informalexample> </para> <para> - The function takes five arguments, the card-index number, the - id string, the module pointer (usually + The function takes six arguments: the parent device pointer, + the card-index number, the id string, the module pointer (usually <constant>THIS_MODULE</constant>), the size of extra-data space, and the pointer to return the card instance. The extra_size argument is used to allocate card->private_data for the chip-specific data. Note that these data - are allocated by <function>snd_card_create()</function>. + are allocated by <function>snd_card_new()</function>. + </para> + + <para> + The first argument, the pointer of struct + <structname>device</structname>, specifies the parent device. + For PCI devices, typically &pci-> is passed there. </para> </section> @@ -916,16 +922,16 @@ </para> <section id="card-management-chip-specific-snd-card-new"> - <title>1. Allocating via <function>snd_card_create()</function>.</title> + <title>1. Allocating via <function>snd_card_new()</function>.</title> <para> As mentioned above, you can pass the extra-data-length - to the 4th argument of <function>snd_card_create()</function>, i.e. + to the 5th argument of <function>snd_card_new()</function>, i.e. <informalexample> <programlisting> <![CDATA[ - err = snd_card_create(index[dev], id[dev], THIS_MODULE, - sizeof(struct mychip), &card); + err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, + sizeof(struct mychip), &card); ]]> </programlisting> </informalexample> @@ -954,7 +960,7 @@ <para> After allocating a card instance via - <function>snd_card_create()</function> (with + <function>snd_card_new()</function> (with <constant>0</constant> on the 4th arg), call <function>kzalloc()</function>. @@ -963,7 +969,8 @@ <![CDATA[ struct snd_card *card; struct mychip *chip; - err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); + err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, + 0, &card); ..... chip = kzalloc(sizeof(*chip), GFP_KERNEL); ]]> @@ -1170,8 +1177,6 @@ return err; } - snd_card_set_dev(card, &pci->dev); - *rchip = chip; return 0; } @@ -1526,30 +1531,6 @@ </section> - <section id="pci-resource-device-struct"> - <title>Registration of Device Struct</title> - <para> - At some point, typically after calling <function>snd_device_new()</function>, - you need to register the struct <structname>device</structname> of the chip - you're handling for udev and co. ALSA provides a macro for compatibility with - older kernels. Simply call like the following: - <informalexample> - <programlisting> -<![CDATA[ - snd_card_set_dev(card, &pci->dev); -]]> - </programlisting> - </informalexample> - so that it stores the PCI's device pointer to the card. This will be - referred by ALSA core functions later when the devices are registered. - </para> - <para> - In the case of non-PCI, pass the proper device struct pointer of the BUS - instead. (In the case of legacy ISA without PnP, you don't have to do - anything.) - </para> - </section> - <section id="pci-resource-entries"> <title>PCI Entries</title> <para> @@ -5740,7 +5721,8 @@ struct _snd_pcm_runtime { struct mychip *chip; int err; .... - err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); + err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, + 0, &card); .... chip = kzalloc(sizeof(*chip), GFP_KERNEL); .... @@ -5752,7 +5734,7 @@ struct _snd_pcm_runtime { </informalexample> When you created the chip data with - <function>snd_card_create()</function>, it's anyway accessible + <function>snd_card_new()</function>, it's anyway accessible via <structfield>private_data</structfield> field. <informalexample> @@ -5766,8 +5748,8 @@ struct _snd_pcm_runtime { struct mychip *chip; int err; .... - err = snd_card_create(index[dev], id[dev], THIS_MODULE, - sizeof(struct mychip), &card); + err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, + sizeof(struct mychip), &card); .... chip = card->private_data; .... diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pci-iov-howto.txt index 86551cc..2d91ae2 100644 --- a/Documentation/PCI/pci-iov-howto.txt +++ b/Documentation/PCI/pci-iov-howto.txt @@ -68,10 +68,6 @@ To disable SR-IOV capability: echo 0 > \ /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs -To notify SR-IOV core of Virtual Function Migration: -(a) In the driver: - irqreturn_t pci_sriov_migration(struct pci_dev *dev); - 3.2 Usage example Following piece of code illustrates the usage of the SR-IOV API. diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 273e654d..2f0fcb2 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -31,6 +31,14 @@ has lapsed, so this approach may be used in non-GPL software, if desired. (In contrast, implementation of RCU is permitted only in software licensed under either GPL or LGPL. Sorry!!!) +In 1987, Rashid et al. described lazy TLB-flush [RichardRashid87a]. +At first glance, this has nothing to do with RCU, but nevertheless +this paper helped inspire the update-side batching used in the later +RCU implementation in DYNIX/ptx. In 1988, Barbara Liskov published +a description of Argus that noted that use of out-of-date values can +be tolerated in some situations. Thus, this paper provides some early +theoretical justification for use of stale data. + In 1990, Pugh [Pugh90] noted that explicitly tracking which threads were reading a given data structure permitted deferred free to operate in the presence of non-terminating threads. However, this explicit @@ -41,11 +49,11 @@ providing a fine-grained locking design, however, it would be interesting to see how much of the performance advantage reported in 1990 remains today. -At about this same time, Adams [Adams91] described ``chaotic relaxation'', -where the normal barriers between successive iterations of convergent -numerical algorithms are relaxed, so that iteration $n$ might use -data from iteration $n-1$ or even $n-2$. This introduces error, -which typically slows convergence and thus increases the number of +At about this same time, Andrews [Andrews91textbook] described ``chaotic +relaxation'', where the normal barriers between successive iterations +of convergent numerical algorithms are relaxed, so that iteration $n$ +might use data from iteration $n-1$ or even $n-2$. This introduces +error, which typically slows convergence and thus increases the number of iterations required. However, this increase is sometimes more than made up for by a reduction in the number of expensive barrier operations, which are otherwise required to synchronize the threads at the end @@ -55,7 +63,8 @@ is thus inapplicable to most data structures in operating-system kernels. In 1992, Henry (now Alexia) Massalin completed a dissertation advising parallel programmers to defer processing when feasible to simplify -synchronization. RCU makes extremely heavy use of this advice. +synchronization [HMassalinPhD]. RCU makes extremely heavy use of +this advice. In 1993, Jacobson [Jacobson93] verbally described what is perhaps the simplest deferred-free technique: simply waiting a fixed amount of time @@ -90,27 +99,29 @@ mechanism, which is quite similar to RCU [Gamsa99]. These operating systems made pervasive use of RCU in place of "existence locks", which greatly simplifies locking hierarchies and helps avoid deadlocks. -2001 saw the first RCU presentation involving Linux [McKenney01a] -at OLS. The resulting abundance of RCU patches was presented the -following year [McKenney02a], and use of RCU in dcache was first -described that same year [Linder02a]. +The year 2000 saw an email exchange that would likely have +led to yet another independent invention of something like RCU +[RustyRussell2000a,RustyRussell2000b]. Instead, 2001 saw the first +RCU presentation involving Linux [McKenney01a] at OLS. The resulting +abundance of RCU patches was presented the following year [McKenney02a], +and use of RCU in dcache was first described that same year [Linder02a]. Also in 2002, Michael [Michael02b,Michael02a] presented "hazard-pointer" techniques that defer the destruction of data structures to simplify non-blocking synchronization (wait-free synchronization, lock-free synchronization, and obstruction-free synchronization are all examples of -non-blocking synchronization). In particular, this technique eliminates -locking, reduces contention, reduces memory latency for readers, and -parallelizes pipeline stalls and memory latency for writers. However, -these techniques still impose significant read-side overhead in the -form of memory barriers. Researchers at Sun worked along similar lines -in the same timeframe [HerlihyLM02]. These techniques can be thought -of as inside-out reference counts, where the count is represented by the -number of hazard pointers referencing a given data structure rather than -the more conventional counter field within the data structure itself. -The key advantage of inside-out reference counts is that they can be -stored in immortal variables, thus allowing races between access and -deletion to be avoided. +non-blocking synchronization). The corresponding journal article appeared +in 2004 [MagedMichael04a]. This technique eliminates locking, reduces +contention, reduces memory latency for readers, and parallelizes pipeline +stalls and memory latency for writers. However, these techniques still +impose significant read-side overhead in the form of memory barriers. +Researchers at Sun worked along similar lines in the same timeframe +[HerlihyLM02]. These techniques can be thought of as inside-out reference +counts, where the count is represented by the number of hazard pointers +referencing a given data structure rather than the more conventional +counter field within the data structure itself. The key advantage +of inside-out reference counts is that they can be stored in immortal +variables, thus allowing races between access and deletion to be avoided. By the same token, RCU can be thought of as a "bulk reference count", where some form of reference counter covers all reference by a given CPU @@ -123,8 +134,10 @@ can be thought of in other terms as well. In 2003, the K42 group described how RCU could be used to create hot-pluggable implementations of operating-system functions [Appavoo03a]. -Later that year saw a paper describing an RCU implementation of System -V IPC [Arcangeli03], and an introduction to RCU in Linux Journal +Later that year saw a paper describing an RCU implementation +of System V IPC [Arcangeli03] (following up on a suggestion by +Hugh Dickins [Dickins02a] and an implementation by Mingming Cao +[MingmingCao2002IPCRCU]), and an introduction to RCU in Linux Journal [McKenney03a]. 2004 has seen a Linux-Journal article on use of RCU in dcache @@ -383,6 +396,21 @@ for Programming Languages and Operating Systems}" } } +@phdthesis{HMassalinPhD +,author="H. Massalin" +,title="Synthesis: An Efficient Implementation of Fundamental Operating +System Services" +,school="Columbia University" +,address="New York, NY" +,year="1992" +,annotation={ + Mondo optimizing compiler. + Wait-free stuff. + Good advice: defer work to avoid synchronization. See page 90 + (PDF page 106), Section 5.4, fourth bullet point. +} +} + @unpublished{Jacobson93 ,author="Van Jacobson" ,title="Avoid Read-Side Locking Via Delayed Free" @@ -671,6 +699,20 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" [Viewed October 18, 2004]" } +@conference{Michael02b +,author="Maged M. Michael" +,title="High Performance Dynamic Lock-Free Hash Tables and List-Based Sets" +,Year="2002" +,Month="August" +,booktitle="{Proceedings of the 14\textsuperscript{th} Annual ACM +Symposium on Parallel +Algorithms and Architecture}" +,pages="73-82" +,annotation={ +Like the title says... +} +} + @Conference{Linder02a ,Author="Hanna Linder and Dipankar Sarma and Maneesh Soni" ,Title="Scalability of the Directory Entry Cache" @@ -727,6 +769,24 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" } } +@conference{Michael02a +,author="Maged M. Michael" +,title="Safe Memory Reclamation for Dynamic Lock-Free Objects Using Atomic +Reads and Writes" +,Year="2002" +,Month="August" +,booktitle="{Proceedings of the 21\textsuperscript{st} Annual ACM +Symposium on Principles of Distributed Computing}" +,pages="21-30" +,annotation={ + Each thread keeps an array of pointers to items that it is + currently referencing. Sort of an inside-out garbage collection + mechanism, but one that requires the accessing code to explicitly + state its needs. Also requires read-side memory barriers on + most architectures. +} +} + @unpublished{Dickins02a ,author="Hugh Dickins" ,title="Use RCU for System-V IPC" @@ -735,6 +795,17 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" ,note="private communication" } +@InProceedings{HerlihyLM02 +,author={Maurice Herlihy and Victor Luchangco and Mark Moir} +,title="The Repeat Offender Problem: A Mechanism for Supporting Dynamic-Sized, +Lock-Free Data Structures" +,booktitle={Proceedings of 16\textsuperscript{th} International +Symposium on Distributed Computing} +,year=2002 +,month="October" +,pages="339-353" +} + @unpublished{Sarma02b ,Author="Dipankar Sarma" ,Title="Some dcache\_rcu benchmark numbers" @@ -749,6 +820,19 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" } } +@unpublished{MingmingCao2002IPCRCU +,Author="Mingming Cao" +,Title="[PATCH]updated ipc lock patch" +,month="October" +,year="2002" +,note="Available: +\url{https://lkml.org/lkml/2002/10/24/262} +[Viewed February 15, 2014]" +,annotation={ + Mingming Cao's patch to introduce RCU to SysV IPC. +} +} + @unpublished{LinusTorvalds2003a ,Author="Linus Torvalds" ,Title="Re: {[PATCH]} small fixes in brlock.h" @@ -982,6 +1066,23 @@ Realtime Applications" } } +@article{MagedMichael04a +,author="Maged M. Michael" +,title="Hazard Pointers: Safe Memory Reclamation for Lock-Free Objects" +,Year="2004" +,Month="June" +,journal="IEEE Transactions on Parallel and Distributed Systems" +,volume="15" +,number="6" +,pages="491-504" +,url="Available: +\url{http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf} +[Viewed March 1, 2005]" +,annotation={ + New canonical hazard-pointer citation. +} +} + @phdthesis{PaulEdwardMcKenneyPhD ,author="Paul E. McKenney" ,title="Exploiting Deferred Destruction: diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 9126619..9d10d1d 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -256,10 +256,10 @@ over a rather long period of time, but improvements are always welcome! variations on this theme. b. Limiting update rate. For example, if updates occur only - once per hour, then no explicit rate limiting is required, - unless your system is already badly broken. The dcache - subsystem takes this approach -- updates are guarded - by a global lock, limiting their rate. + once per hour, then no explicit rate limiting is + required, unless your system is already badly broken. + Older versions of the dcache subsystem take this approach, + guarding updates with a global lock, limiting their rate. c. Trusted update -- if updates can only be done manually by superuser or some other trusted user, then it might not @@ -268,7 +268,8 @@ over a rather long period of time, but improvements are always welcome! the machine. d. Use call_rcu_bh() rather than call_rcu(), in order to take - advantage of call_rcu_bh()'s faster grace periods. + advantage of call_rcu_bh()'s faster grace periods. (This + is only a partial solution, though.) e. Periodically invoke synchronize_rcu(), permitting a limited number of updates per grace period. @@ -276,6 +277,13 @@ over a rather long period of time, but improvements are always welcome! The same cautions apply to call_rcu_bh(), call_rcu_sched(), call_srcu(), and kfree_rcu(). + Note that although these primitives do take action to avoid memory + exhaustion when any given CPU has too many callbacks, a determined + user could still exhaust memory. This is especially the case + if a system with a large number of CPUs has been configured to + offload all of its RCU callbacks onto a single CPU, or if the + system has relatively little free memory. + 9. All RCU list-traversal primitives, which include rcu_dereference(), list_for_each_entry_rcu(), and list_for_each_safe_rcu(), must be either within an RCU read-side diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index 5e054bf..85e24c4 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -35,11 +35,13 @@ ffffffbc00000000 ffffffbdffffffff 8GB vmemmap ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap] -ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device +ffffffbffa000000 ffffffbffaffffff 16MB PCI I/O space + +ffffffbffb000000 ffffffbffbbfffff 12MB [guard] -ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space +ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device -ffffffbffbe10000 ffffffbcffffffff ~2MB [guard] +ffffffbffbe00000 ffffffbffbffffff 2MB [guard] ffffffbffc000000 ffffffbfffffffff 64MB modules @@ -60,11 +62,13 @@ fffffdfc00000000 fffffdfdffffffff 8GB vmemmap fffffdfe00000000 fffffdfffbbfffff ~8GB [guard, future vmmemap] -fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk device +fffffdfffa000000 fffffdfffaffffff 16MB PCI I/O space + +fffffdfffb000000 fffffdfffbbfffff 12MB [guard] -fffffdfffbe00000 fffffdfffbe0ffff 64KB PCI I/O space +fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk device -fffffdfffbe10000 fffffdfffbffffff ~2MB [guard] +fffffdfffbe00000 fffffdfffbffffff 2MB [guard] fffffdfffc000000 fffffdffffffffff 64MB modules diff --git a/Documentation/blockdev/drbd/data-structure-v9.txt b/Documentation/blockdev/drbd/data-structure-v9.txt new file mode 100644 index 0000000..1e52a0e --- /dev/null +++ b/Documentation/blockdev/drbd/data-structure-v9.txt @@ -0,0 +1,38 @@ +This describes the in kernel data structure for DRBD-9. Starting with +Linux v3.14 we are reorganizing DRBD to use this data structure. + +Basic Data Structure +==================== + +A node has a number of DRBD resources. Each such resource has a number of +devices (aka volumes) and connections to other nodes ("peer nodes"). Each DRBD +device is represented by a block device locally. + +The DRBD objects are interconnected to form a matrix as depicted below; a +drbd_peer_device object sits at each intersection between a drbd_device and a +drbd_connection: + + /--------------+---------------+.....+---------------\ + | resource | device | | device | + +--------------+---------------+.....+---------------+ + | connection | peer_device | | peer_device | + +--------------+---------------+.....+---------------+ + : : : : : + : : : : : + +--------------+---------------+.....+---------------+ + | connection | peer_device | | peer_device | + \--------------+---------------+.....+---------------/ + +In this table, horizontally, devices can be accessed from resources by their +volume number. Likewise, peer_devices can be accessed from connections by +their volume number. Objects in the vertical direction are connected by double +linked lists. There are back pointers from peer_devices to their connections a +devices, and from connections and devices to their resource. + +All resources are in the drbd_resources double-linked list. In addition, all +devices can be accessed by their minor device number via the drbd_devices idr. + +The drbd_resource, drbd_connection, and drbd_device objects are reference +counted. The peer_device objects only serve to establish the links between +devices and connections; their lifetime is determined by the lifetime of the +device and connection which they reference. diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c index adcca03..d12cc94 100644 --- a/Documentation/connector/cn_test.c +++ b/Documentation/connector/cn_test.c @@ -145,7 +145,7 @@ static void cn_test_timer_func(unsigned long __data) memcpy(m + 1, data, m->len); - cn_netlink_send(m, 0, GFP_ATOMIC); + cn_netlink_send(m, 0, 0, GFP_ATOMIC); kfree(m); } diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt index ce0666e..0060d76 100644 --- a/Documentation/cpu-freq/core.txt +++ b/Documentation/cpu-freq/core.txt @@ -92,7 +92,3 @@ values: cpu - number of the affected CPU old - old frequency new - new frequency - -If the cpufreq core detects the frequency has changed while the system -was suspended, these notifiers are called with CPUFREQ_RESUMECHANGE as -second argument. diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 8b1a445..48da5fd 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -61,7 +61,13 @@ target_index - See below on the differences. And optionally -cpufreq_driver.exit - A pointer to a per-CPU cleanup function. +cpufreq_driver.exit - A pointer to a per-CPU cleanup + function called during CPU_POST_DEAD + phase of cpu hotplug process. + +cpufreq_driver.stop_cpu - A pointer to a per-CPU stop function + called during CPU_DOWN_PREPARE phase of + cpu hotplug process. cpufreq_driver.resume - A pointer to a per-CPU resume function which is called with interrupts disabled diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 04356f5..d154147 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -411,6 +411,7 @@ Your cooperation is appreciated. 194 = /dev/zkshim Zero-Knowledge network shim control 195 = /dev/elographics/e2201 Elographics touchscreen E271-2201 196 = /dev/vfio/vfio VFIO userspace driver interface + 197 = /dev/pxa3xx-gcu PXA3xx graphics controller unit driver 198 = /dev/sexec Signed executable interface 199 = /dev/scanners/cuecat :CueCat barcode scanner 200 = /dev/net/tun TAP/TUN network device @@ -452,6 +453,7 @@ Your cooperation is appreciated. 236 = /dev/mapper/control Device-Mapper control device 237 = /dev/loop-control Loopback control device 238 = /dev/vhost-net Host kernel accelerator for virtio net + 239 = /dev/uhid User-space I/O driver support for HID subsystem 240-254 Reserved for local use 255 Reserved for MISC_DYNAMIC_MINOR diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt index d74091a..5fc0313 100644 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt @@ -1,4 +1,4 @@ -Marvell Armada 370 and Armada XP Interrupt Controller +Marvell Armada 370, 375, 38x, XP Interrupt Controller ----------------------------------------------------- Required properties: @@ -16,7 +16,13 @@ Required properties: automatically map to the interrupt controller registers of the current CPU) +Optional properties: +- interrupts: If defined, then it indicates that this MPIC is + connected as a slave to another interrupt controller. This is + typically the case on Armada 375 and Armada 38x, where the MPIC is + connected as a slave to the Cortex-A9 GIC. The provided interrupt + indicate to which GIC interrupt the MPIC output is connected. Example: diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt index d106146..9a1175b 100644 --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt @@ -5,6 +5,9 @@ Required properties: <chip> can be "at91sam9260", "at91sam9g45" or "at91sam9x5" - reg: Should contain ADC registers location and length - interrupts: Should contain the IRQ line for the ADC + - clock-names: tuple listing input clock names. + Required elements: "adc_clk", "adc_op_clk". + - clocks: phandles to input clocks. - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this device - atmel,adc-startup-time: Startup Time of the ADC in microseconds as @@ -44,6 +47,8 @@ adc0: adc@fffb0000 { compatible = "atmel,at91sam9260-adc"; reg = <0xfffb0000 0x100>; interrupts = <20 4>; + clocks = <&adc_clk>, <&adc_op_clk>; + clock-names = "adc_clk", "adc_op_clk"; atmel,adc-channel-base = <0x30>; atmel,adc-channels-used = <0xff>; atmel,adc-drdy-mask = <0x10000>; diff --git a/Documentation/devicetree/bindings/arm/marvell,dove.txt b/Documentation/devicetree/bindings/arm/marvell,dove.txt new file mode 100644 index 0000000..aaaf64c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/marvell,dove.txt @@ -0,0 +1,22 @@ +Marvell Dove Platforms Device Tree Bindings +----------------------------------------------- + +Boards with a Marvell Dove SoC shall have the following properties: + +Required root node property: +- compatible: must contain "marvell,dove"; + +* Global Configuration registers + +Global Configuration registers of Dove SoC are shared by a syscon node. + +Required properties: +- compatible: must contain "marvell,dove-global-config" and "syscon". +- reg: base address and size of the Global Configuration registers. + +Example: + +gconf: global-config@e802c { + compatible = "marvell,dove-global-config", "syscon"; + reg = <0xe802c 0x14>; +}; diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index 89de156..48b285f 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -4,17 +4,33 @@ SATA nodes are defined to describe on-chip Serial ATA controllers. Each SATA controller should have its own node. Required properties: -- compatible : compatible list, contains "snps,spear-ahci" +- compatible : compatible list, one of "snps,spear-ahci", + "snps,exynos5440-ahci", "ibm,476gtr-ahci", + "allwinner,sun4i-a10-ahci", "fsl,imx53-ahci" + "fsl,imx6q-ahci" or "snps,dwc-ahci" - interrupts : <interrupt mapping for SATA IRQ> - reg : <registers mapping> Optional properties: - dma-coherent : Present if dma operations are coherent +- clocks : a list of phandle + clock specifier pairs +- target-supply : regulator for SATA target power -Example: +"fsl,imx53-ahci", "fsl,imx6q-ahci" required properties: +- clocks : must contain the sata, sata_ref and ahb clocks +- clock-names : must contain "ahb" for the ahb clock + +Examples: sata@ffe08000 { compatible = "snps,spear-ahci"; reg = <0xffe08000 0x1000>; interrupts = <115>; - }; + + ahci: sata@01c18000 { + compatible = "allwinner,sun4i-a10-ahci"; + reg = <0x01c18000 0x1000>; + interrupts = <56>; + clocks = <&pll6 0>, <&ahb_gates 25>; + target-supply = <®_ahci_5v>; + }; diff --git a/Documentation/devicetree/bindings/ata/apm-xgene.txt b/Documentation/devicetree/bindings/ata/apm-xgene.txt new file mode 100644 index 0000000..7bcfbf5 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/apm-xgene.txt @@ -0,0 +1,76 @@ +* APM X-Gene 6.0 Gb/s SATA host controller nodes + +SATA host controller nodes are defined to describe on-chip Serial ATA +controllers. Each SATA controller (pair of ports) have its own node. + +Required properties: +- compatible : Shall contain: + * "apm,xgene-ahci" +- reg : First memory resource shall be the AHCI memory + resource. + Second memory resource shall be the host controller + core memory resource. + Third memory resource shall be the host controller + diagnostic memory resource. + 4th memory resource shall be the host controller + AXI memory resource. + 5th optional memory resource shall be the host + controller MUX memory resource if required. +- interrupts : Interrupt-specifier for SATA host controller IRQ. +- clocks : Reference to the clock entry. +- phys : A list of phandles + phy-specifiers, one for each + entry in phy-names. +- phy-names : Should contain: + * "sata-phy" for the SATA 6.0Gbps PHY + +Optional properties: +- status : Shall be "ok" if enabled or "disabled" if disabled. + Default is "ok". + +Example: + sataclk: sataclk { + compatible = "fixed-clock"; + #clock-cells = <1>; + clock-frequency = <100000000>; + clock-output-names = "sataclk"; + }; + + phy2: phy@1f22a000 { + compatible = "apm,xgene-phy"; + reg = <0x0 0x1f22a000 0x0 0x100>; + #phy-cells = <1>; + }; + + phy3: phy@1f23a000 { + compatible = "apm,xgene-phy"; + reg = <0x0 0x1f23a000 0x0 0x100>; + #phy-cells = <1>; + }; + + sata2: sata@1a400000 { + compatible = "apm,xgene-ahci"; + reg = <0x0 0x1a400000 0x0 0x1000>, + <0x0 0x1f220000 0x0 0x1000>, + <0x0 0x1f22d000 0x0 0x1000>, + <0x0 0x1f22e000 0x0 0x1000>, + <0x0 0x1f227000 0x0 0x1000>; + interrupts = <0x0 0x87 0x4>; + status = "ok"; + clocks = <&sataclk 0>; + phys = <&phy2 0>; + phy-names = "sata-phy"; + }; + + sata3: sata@1a800000 { + compatible = "apm,xgene-ahci-pcie"; + reg = <0x0 0x1a800000 0x0 0x1000>, + <0x0 0x1f230000 0x0 0x1000>, + <0x0 0x1f23d000 0x0 0x1000>, + <0x0 0x1f23e000 0x0 0x1000>, + <0x0 0x1f237000 0x0 0x1000>; + interrupts = <0x0 0x88 0x4>; + status = "ok"; + clocks = <&sataclk 0>; + phys = <&phy3 0>; + phy-names = "sata-phy"; + }; diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt new file mode 100644 index 0000000..1a69c07 --- /dev/null +++ b/Documentation/devicetree/bindings/graph.txt @@ -0,0 +1,129 @@ +Common bindings for device graphs + +General concept +--------------- + +The hierarchical organisation of the device tree is well suited to describe +control flow to devices, but there can be more complex connections between +devices that work together to form a logical compound device, following an +arbitrarily complex graph. +There already is a simple directed graph between devices tree nodes using +phandle properties pointing to other nodes to describe connections that +can not be inferred from device tree parent-child relationships. The device +tree graph bindings described herein abstract more complex devices that can +have multiple specifiable ports, each of which can be linked to one or more +ports of other devices. + +These common bindings do not contain any information about the direction or +type of the connections, they just map their existence. Specific properties +may be described by specialized bindings depending on the type of connection. + +To see how this binding applies to video pipelines, for example, see +Documentation/device-tree/bindings/media/video-interfaces.txt. +Here the ports describe data interfaces, and the links between them are +the connecting data buses. A single port with multiple connections can +correspond to multiple devices being connected to the same physical bus. + +Organisation of ports and endpoints +----------------------------------- + +Ports are described by child 'port' nodes contained in the device node. +Each port node contains an 'endpoint' subnode for each remote device port +connected to this port. If a single port is connected to more than one +remote device, an 'endpoint' child node must be provided for each link. +If more than one port is present in a device node or there is more than one +endpoint at a port, or a port node needs to be associated with a selected +hardware interface, a common scheme using '#address-cells', '#size-cells' +and 'reg' properties is used number the nodes. + +device { + ... + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + endpoint@0 { + reg = <0>; + ... + }; + endpoint@1 { + reg = <1>; + ... + }; + }; + + port@1 { + reg = <1>; + + endpoint { ... }; + }; +}; + +All 'port' nodes can be grouped under an optional 'ports' node, which +allows to specify #address-cells, #size-cells properties for the 'port' +nodes independently from any other child device nodes a device might +have. + +device { + ... + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + ... + endpoint@0 { ... }; + endpoint@1 { ... }; + }; + + port@1 { ... }; + }; +}; + +Links between endpoints +----------------------- + +Each endpoint should contain a 'remote-endpoint' phandle property that points +to the corresponding endpoint in the port of the remote device. In turn, the +remote endpoint should contain a 'remote-endpoint' property. If it has one, +it must not point to another than the local endpoint. Two endpoints with their +'remote-endpoint' phandles pointing at each other form a link between the +containing ports. + +device-1 { + port { + device_1_output: endpoint { + remote-endpoint = <&device_2_input>; + }; + }; +}; + +device-2 { + port { + device_2_input: endpoint { + remote-endpoint = <&device_1_output>; + }; + }; +}; + + +Required properties +------------------- + +If there is more than one 'port' or more than one 'endpoint' node or 'reg' +property is present in port and/or endpoint nodes the following properties +are required in a relevant parent node: + + - #address-cells : number of cells required to define port/endpoint + identifier, should be 1. + - #size-cells : should be zero. + +Optional endpoint properties +---------------------------- + +- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node. + diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index 1a1ac2e..f47e56b 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -18,6 +18,7 @@ atmel,24c02 i2c serial eeprom (24cxx) atmel,at97sc3204t i2c trusted platform module (TPM) capella,cm32181 CM32181: Ambient Light Sensor catalyst,24c32 i2c serial eeprom +cirrus,cs42l51 Cirrus Logic CS42L51 audio codec dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock dallas,ds1338 I2C RTC with 56-Byte NV RAM dallas,ds1339 I2C Serial Real-Time Clock diff --git a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt new file mode 100644 index 0000000..dcebff1 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt @@ -0,0 +1,22 @@ +Freescale vf610 Analog to Digital Converter bindings + +The devicetree bindings are for the new ADC driver written for +vf610/i.MX6slx and upward SoCs from Freescale. + +Required properties: +- compatible: Should contain "fsl,vf610-adc" +- reg: Offset and length of the register set for the device +- interrupts: Should contain the interrupt for the device +- clocks: The clock is needed by the ADC controller, ADC clock source is ipg clock. +- clock-names: Must contain "adc", matching entry in the clocks property. +- vref-supply: The regulator supply ADC refrence voltage. + +Example: +adc0: adc@4003b000 { + compatible = "fsl,vf610-adc"; + reg = <0x4003b000 0x1000>; + interrupts = <0 53 0x04>; + clocks = <&clks VF610_CLK_ADC0>; + clock-names = "adc"; + vref-supply = <®_vcc_3v3_mcu>; +}; diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt new file mode 100644 index 0000000..d9ee909 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt @@ -0,0 +1,113 @@ +Xilinx XADC device driver + +This binding document describes the bindings for both of them since the +bindings are very similar. The Xilinx XADC is a ADC that can be found in the +series 7 FPGAs from Xilinx. The XADC has a DRP interface for communication. +Currently two different frontends for the DRP interface exist. One that is only +available on the ZYNQ family as a hardmacro in the SoC portion of the ZYNQ. The +other one is available on all series 7 platforms and is a softmacro with a AXI +interface. This binding document describes the bindings for both of them since +the bindings are very similar. + +Required properties: + - compatible: Should be one of + * "xlnx,zynq-xadc-1.00.a": When using the ZYNQ device + configuration interface to interface to the XADC hardmacro. + * "xlnx,axi-xadc-1.00.a": When using the axi-xadc pcore to + interface to the XADC hardmacro. + - reg: Address and length of the register set for the device + - interrupts: Interrupt for the XADC control interface. + - clocks: When using the ZYNQ this must be the ZYNQ PCAP clock, + when using the AXI-XADC pcore this must be the clock that provides the + clock to the AXI bus interface of the core. + +Optional properties: + - interrupt-parent: phandle to the parent interrupt controller + - xlnx,external-mux: + * "none": No external multiplexer is used, this is the default + if the property is omitted. + * "single": External multiplexer mode is used with one + multiplexer. + * "dual": External multiplexer mode is used with two + multiplexers for simultaneous sampling. + - xlnx,external-mux-channel: Configures which pair of pins is used to + sample data in external mux mode. + Valid values for single external multiplexer mode are: + 0: VP/VN + 1: VAUXP[0]/VAUXN[0] + 2: VAUXP[1]/VAUXN[1] + ... + 16: VAUXP[15]/VAUXN[15] + Valid values for dual external multiplexer mode are: + 1: VAUXP[0]/VAUXN[0] - VAUXP[8]/VAUXN[8] + 2: VAUXP[1]/VAUXN[1] - VAUXP[9]/VAUXN[9] + ... + 8: VAUXP[7]/VAUXN[7] - VAUXP[15]/VAUXN[15] + + This property needs to be present if the device is configured for + external multiplexer mode (either single or dual). If the device is + not using external multiplexer mode the property is ignored. + - xnlx,channels: List of external channels that are connected to the ADC + Required properties: + * #address-cells: Should be 1. + * #size-cells: Should be 0. + + The child nodes of this node represent the external channels which are + connected to the ADC. If the property is no present no external + channels will be assumed to be connected. + + Each child node represents one channel and has the following + properties: + Required properties: + * reg: Pair of pins the the channel is connected to. + 0: VP/VN + 1: VAUXP[0]/VAUXN[0] + 2: VAUXP[1]/VAUXN[1] + ... + 16: VAUXP[15]/VAUXN[15] + Note each channel number should only be used at most + once. + Optional properties: + * xlnx,bipolar: If set the channel is used in bipolar + mode. + + +Examples: + xadc@f8007100 { + compatible = "xlnx,zynq-xadc-1.00.a"; + reg = <0xf8007100 0x20>; + interrupts = <0 7 4>; + interrupt-parent = <&gic>; + clocks = <&pcap_clk>; + + xlnx,channels { + #address-cells = <1>; + #size-cells = <0>; + channel@0 { + reg = <0>; + }; + channel@1 { + reg = <1>; + }; + channel@8 { + reg = <8>; + }; + }; + }; + + xadc@43200000 { + compatible = "xlnx,axi-xadc-1.00.a"; + reg = <0x43200000 0x1000>; + interrupts = <0 53 4>; + interrupt-parent = <&gic>; + clocks = <&fpga1_clk>; + + xlnx,channels { + #address-cells = <1>; + #size-cells = <0>; + channel@0 { + reg = <0>; + xlnx,bipolar; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt index 32cec4b..b290ca1 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt @@ -2,7 +2,7 @@ Allwinner Sunxi Interrupt Controller Required properties: -- compatible : should be "allwinner,sun4i-ic" +- compatible : should be "allwinner,sun4i-a10-ic" - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Specifies the number of cells needed to encode an @@ -11,7 +11,7 @@ Required properties: Example: intc: interrupt-controller { - compatible = "allwinner,sun4i-ic"; + compatible = "allwinner,sun4i-a10-ic"; reg = <0x01c20400 0x400>; interrupt-controller; #interrupt-cells = <1>; diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt new file mode 100644 index 0000000..d1c5cda --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt @@ -0,0 +1,27 @@ +Allwinner Sunxi NMI Controller +============================== + +Required properties: + +- compatible : should be "allwinner,sun7i-a20-sc-nmi" or + "allwinner,sun6i-a31-sc-nmi" +- reg : Specifies base physical address and size of the registers. +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The value shall be 2. The first cell is the IRQ number, the + second cell the trigger type as defined in interrupt.txt in this directory. +- interrupt-parent: Specifies the parent interrupt controller. +- interrupts: Specifies the interrupt line (NMI) which is handled by + the interrupt controller in the parent controller's notation. This value + shall be the NMI. + +Example: + +sc-nmi-intc@01c00030 { + compatible = "allwinner,sun7i-a20-sc-nmi"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0x01c00030 0x0c>; + interrupt-parent = <&gic>; + interrupts = <0 0 4>; +}; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt index d5e3704..d5e3704 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt new file mode 100644 index 0000000..9592717 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt @@ -0,0 +1,210 @@ +* Device tree bindings for Texas instruments AEMIF controller + +The Async External Memory Interface (EMIF16/AEMIF) controller is intended to +provide a glue-less interface to a variety of asynchronous memory devices like +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories +can be accessed at any given time via four chip selects with 64M byte access +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM +and Mobile SDR are not supported. + +Documentation: +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf + +Required properties: + +- compatible: "ti,davinci-aemif" + "ti,keystone-aemif" + "ti,da850-aemif" + +- reg: contains offset/length value for AEMIF control registers + space. + +- #address-cells: Must be 2. The partition number has to be encoded in the + first address cell and it may accept values 0..N-1 + (N - total number of partitions). It's recommended to + assign N-1 number for the control partition. The second + cell is the offset into the partition. + +- #size-cells: Must be set to 1. + +- ranges: Contains memory regions. There are two types of + ranges/partitions: + - CS-specific partition/range. If continuous, must be + set up to reflect the memory layout for 4 chipselects, + if not then additional range/partition can be added and + child device can select the proper one. + - control partition which is common for all CS + interfaces. + +- clocks: the clock feeding the controller clock. Required only + if clock tree data present in device tree. + See clock-bindings.txt + +- clock-names: clock name. It has to be "aemif". Required only if clock + tree data present in device tree, in another case don't + use it. + See clock-bindings.txt + +- clock-ranges: Empty property indicating that child nodes can inherit + named clocks. Required only if clock tree data present + in device tree. + See clock-bindings.txt + + +Child chip-select (cs) nodes contain the memory devices nodes connected to +such as NOR (e.g. cfi-flash) and NAND (ti,davinci-nand, see davinci-nand.txt). +There might be board specific devices like FPGAs. + +Required child cs node properties: + +- #address-cells: Must be 2. + +- #size-cells: Must be 1. + +- ranges: Empty property indicating that child nodes can inherit + memory layout. + +- clock-ranges: Empty property indicating that child nodes can inherit + named clocks. Required only if clock tree data present + in device tree. + +- ti,cs-chipselect: number of chipselect. Indicates on the aemif driver + which chipselect is used for accessing the memory. For + compatibles "ti,davinci-aemif" and "ti,keystone-aemif" + it can be in range [0-3]. For compatible + "ti,da850-aemif" range is [2-5]. + +Optional child cs node properties: + +- ti,cs-bus-width: width of the asynchronous device's data bus + 8 or 16 if not preset 8 + +- ti,cs-select-strobe-mode: enable/disable select strobe mode + In select strobe mode chip select behaves as + the strobe and is active only during the strobe + period. If present then enable. + +- ti,cs-extended-wait-mode: enable/disable extended wait mode + if set, the controller monitors the EMIFWAIT pin + mapped to that chip select to determine if the + device wants to extend the strobe period. If + present then enable. + +- ti,cs-min-turnaround-ns: minimum turn around time, ns + Time between the end of one asynchronous memory + access and the start of another asynchronous + memory access. This delay is not incurred + between a read followed by read or a write + followed by a write to same chip select. + +- ti,cs-read-setup-ns: read setup width, ns + Time between the beginning of a memory cycle + and the activation of read strobe. + Minimum value is 1 (0 treated as 1). + +- ti,cs-read-strobe-ns: read strobe width, ns + Time between the activation and deactivation of + the read strobe. + Minimum value is 1 (0 treated as 1). + +- ti,cs-read-hold-ns: read hold width, ns + Time between the deactivation of the read + strobe and the end of the cycle (which may be + either an address change or the deactivation of + the chip select signal. + Minimum value is 1 (0 treated as 1). + +- ti,cs-write-setup-ns: write setup width, ns + Time between the beginning of a memory cycle + and the activation of write strobe. + Minimum value is 1 (0 treated as 1). + +- ti,cs-write-strobe-ns: write strobe width, ns + Time between the activation and deactivation of + the write strobe. + Minimum value is 1 (0 treated as 1). + +- ti,cs-write-hold-ns: write hold width, ns + Time between the deactivation of the write + strobe and the end of the cycle (which may be + either an address change or the deactivation of + the chip select signal. + Minimum value is 1 (0 treated as 1). + +If any of the above parameters are absent, current parameter value will be taken +from the corresponding HW reg. + +Example for aemif, davinci nand and nor flash chip select shown below. + +memory-controller@21000A00 { + compatible = "ti,davinci-aemif"; + #address-cells = <2>; + #size-cells = <1>; + clocks = <&clkaemif 0>; + clock-names = "aemif"; + clock-ranges; + reg = <0x21000A00 0x00000100>; + ranges = <0 0 0x70000000 0x10000000 + 1 0 0x21000A00 0x00000100>; + /* + * Partition0: CS-specific memory range which is + * implemented as continuous physical memory region + * Partition1: control memory range + */ + + nand:cs2 { + #address-cells = <2>; + #size-cells = <1>; + clock-ranges; + ranges; + + ti,cs-chipselect = <2>; + /* all timings in nanoseconds */ + ti,cs-min-turnaround-ns = <0>; + ti,cs-read-hold-ns = <7>; + ti,cs-read-strobe-ns = <42>; + ti,cs-read-setup-ns = <14>; + ti,cs-write-hold-ns = <7>; + ti,cs-write-strobe-ns = <42>; + ti,cs-write-setup-ns = <14>; + + nand@0,0x8000000 { + compatible = "ti,davinci-nand"; + reg = <0 0x8000000 0x4000000 + 1 0x0000000 0x0000100>; + /* + * Partition0, offset 0x8000000, size 0x4000000 + * Partition1, offset 0x0000000, size 0x0000100 + */ + + .. see davinci-nand.txt + }; + }; + + nor:cs0 { + #address-cells = <2>; + #size-cells = <1>; + clock-ranges; + ranges; + + ti,cs-chipselect = <0>; + /* all timings in nanoseconds */ + ti,cs-min-turnaround-ns = <0>; + ti,cs-read-hold-ns = <8>; + ti,cs-read-strobe-ns = <40>; + ti,cs-read-setup-ns = <14>; + ti,cs-write-hold-ns = <7>; + ti,cs-write-strobe-ns = <40>; + ti,cs-write-setup-ns = <14>; + ti,cs-bus-width = <16>; + + flash@0,0x0000000 { + compatible = "cfi-flash"; + reg = <0 0x0000000 0x4000000>; + + ... + }; + }; +}; diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt b/Documentation/devicetree/bindings/mfd/s2mpa01.txt new file mode 100644 index 0000000..c13d3d8 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/s2mpa01.txt @@ -0,0 +1,90 @@ + +* Samsung S2MPA01 Voltage and Current Regulator + +The Samsung S2MPA01 is a multi-function device which includes high +efficiency buck converters including Dual-Phase buck converter, various LDOs, +and an RTC. It is interfaced to the host controller using an I2C interface. +Each sub-block is addressed by the host system using different I2C slave +addresses. + +Required properties: +- compatible: Should be "samsung,s2mpa01-pmic". +- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66. + +Optional properties: +- interrupt-parent: Specifies the phandle of the interrupt controller to which + the interrupts from s2mpa01 are delivered to. +- interrupts: An interrupt specifier for the sole interrupt generated by the + device. + +Optional nodes: +- regulators: The regulators of s2mpa01 that have to be instantiated should be + included in a sub-node named 'regulators'. Regulator nodes and constraints + included in this sub-node use the standard regulator bindings which are + documented elsewhere. + +Properties for BUCK regulator nodes: +- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500 + (default), 25000, or 50000. May be 0 for disabling the ramp delay on + BUCK{1,2,3,4}. + + In the absence of the regulator-ramp-delay property, the default ramp + delay will be used. + + NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set + for a particular group of BUCKs. So provide same regulator-ramp-delay=<value>. + + The following BUCKs share ramp settings: + * 1 and 6 + * 2 and 4 + * 8, 9, and 10 + +The following are the names of the regulators that the s2mpa01 PMIC block +supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number +as per the datasheet of s2mpa01. + + - LDOn + - valid values for n are 1 to 26 + - Example: LDO1, LD02, LDO26 + - BUCKn + - valid values for n are 1 to 10. + - Example: BUCK1, BUCK2, BUCK9 + +Example: + + s2mpa01_pmic@66 { + compatible = "samsung,s2mpa01-pmic"; + reg = <0x66>; + + regulators { + ldo1_reg: LDO1 { + regulator-name = "VDD_ALIVE"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + }; + + ldo2_reg: LDO2 { + regulator-name = "VDDQ_MMC2"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-always-on; + }; + + buck1_reg: BUCK1 { + regulator-name = "vdd_mif"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + }; + + buck2_reg: BUCK2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + regulator-ramp-delay = <50000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 15ee89c3c..f69bec2 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11 Voltage and Current Regulator +* Samsung S2MPS11 and S2MPS14 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,7 +7,7 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic". +- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -59,10 +59,14 @@ supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number as per the datasheet of s2mps11. - LDOn - - valid values for n are 1 to 38 + - valid values for n are: + - S2MPS11: 1 to 38 + - S2MPS14: 1 to 25 - Example: LDO1, LD02, LDO28 - BUCKn - - valid values for n are 1 to 10. + - valid values for n are: + - S2MPS11: 1 to 10 + - S2MPS14: 1 to 5 - Example: BUCK1, BUCK2, BUCK9 Example: diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt b/Documentation/devicetree/bindings/mfd/tps65910.txt index b4bd98a..38833e6 100644 --- a/Documentation/devicetree/bindings/mfd/tps65910.txt +++ b/Documentation/devicetree/bindings/mfd/tps65910.txt @@ -11,7 +11,7 @@ Required properties: - #interrupt-cells: the number of cells to describe an IRQ, this should be 2. The first cell is the IRQ number. The second cell is the flags, encoded as the trigger masks from - Documentation/devicetree/bindings/interrupts.txt + Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - regulators: This is the list of child nodes that specify the regulator initialization data for defined regulators. Not all regulators for the given device need to be present. The definition for each of these nodes is defined diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt index 68ba372..fabdf64 100644 --- a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt +++ b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt @@ -1,12 +1,12 @@ Allwinner sunxi-sid Required properties: -- compatible: "allwinner,sun4i-sid" or "allwinner,sun7i-a20-sid". +- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid" - reg: Should contain registers location and length Example for sun4i: sid@01c23800 { - compatible = "allwinner,sun4i-sid"; + compatible = "allwinner,sun4i-a10-sid"; reg = <0x01c23800 0x10> }; diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt index 60960b2..efc98ea 100644 --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt @@ -17,6 +17,14 @@ Required properties for devices compatible with "atmel,at91sam9g45-ssc": See Documentation/devicetree/bindings/dma/atmel-dma.txt for details. - dma-names: Must be "tx", "rx". +Optional properties: + - atmel,clk-from-rk-pin: bool property. + - When SSC works in slave mode, according to the hardware design, the + clock can get from TK pin, and also can get from RK pin. So, add + this parameter to choose where the clock from. + - By default the clock is from TK pin, if the clock from RK pin, this + property is needed. + Examples: - PDC transfer: ssc0: ssc@fffbc000 { diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt index 4d0a00e..36cbe5a 100644 --- a/Documentation/devicetree/bindings/misc/sram.txt +++ b/Documentation/devicetree/bindings/misc/sram.txt @@ -8,9 +8,44 @@ Required properties: - reg : SRAM iomem address range +Reserving sram areas: +--------------------- + +Each child of the sram node specifies a region of reserved memory. Each +child node should use a 'reg' property to specify a specific range of +reserved memory. + +Following the generic-names recommended practice, node names should +reflect the purpose of the node. Unit address (@<address>) should be +appended to the name. + +Required properties in the sram node: + +- #address-cells, #size-cells : should use the same values as the root node +- ranges : standard definition, should translate from local addresses + within the sram to bus addresses + +Required properties in the area nodes: + +- reg : iomem address range, relative to the SRAM range + +Optional properties in the area nodes: + +- compatible : standard definition, should contain a vendor specific string + in the form <vendor>,[<device>-]<usage> + Example: sram: sram@5c000000 { compatible = "mmio-sram"; reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */ + + #adress-cells = <1>; + #size-cells = <1>; + ranges = <0 0x5c000000 0x40000>; + + smp-sram@100 { + compatible = "socvendor,smp-sram"; + reg = <0x100 0x50>; + }; }; diff --git a/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt new file mode 100644 index 0000000..5f3a65a --- /dev/null +++ b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt @@ -0,0 +1,79 @@ +* APM X-Gene 15Gbps Multi-purpose PHY nodes + +PHY nodes are defined to describe on-chip 15Gbps Multi-purpose PHY. Each +PHY (pair of lanes) has its own node. + +Required properties: +- compatible : Shall be "apm,xgene-phy". +- reg : PHY memory resource is the SDS PHY access resource. +- #phy-cells : Shall be 1 as it expects one argument for setting + the mode of the PHY. Possible values are 0 (SATA), + 1 (SGMII), 2 (PCIe), 3 (USB), and 4 (XFI). + +Optional properties: +- status : Shall be "ok" if enabled or "disabled" if disabled. + Default is "ok". +- clocks : Reference to the clock entry. +- apm,tx-eye-tuning : Manual control to fine tune the capture of the serial + bit lines from the automatic calibrated position. + Two set of 3-tuple setting for each (up to 3) + supported link speed on the host. Range from 0 to + 127 in unit of one bit period. Default is 10. +- apm,tx-eye-direction : Eye tuning manual control direction. 0 means sample + data earlier than the nominal sampling point. 1 means + sample data later than the nominal sampling point. + Two set of 3-tuple setting for each (up to 3) + supported link speed on the host. Default is 0. +- apm,tx-boost-gain : Frequency boost AC (LSB 3-bit) and DC (2-bit) + gain control. Two set of 3-tuple setting for each + (up to 3) supported link speed on the host. Range is + between 0 to 31 in unit of dB. Default is 3. +- apm,tx-amplitude : Amplitude control. Two set of 3-tuple setting for + each (up to 3) supported link speed on the host. + Range is between 0 to 199500 in unit of uV. + Default is 199500 uV. +- apm,tx-pre-cursor1 : 1st pre-cursor emphasis taps control. Two set of + 3-tuple setting for each (up to 3) supported link + speed on the host. Range is 0 to 273000 in unit of + uV. Default is 0. +- apm,tx-pre-cursor2 : 2st pre-cursor emphasis taps control. Two set of + 3-tuple setting for each (up to 3) supported link + speed on the host. Range is 0 to 127400 in unit uV. + Default is 0x0. +- apm,tx-post-cursor : Post-cursor emphasis taps control. Two set of + 3-tuple setting for Gen1, Gen2, and Gen3. Range is + between 0 to 0x1f in unit of 18.2mV. Default is 0xf. +- apm,tx-speed : Tx operating speed. One set of 3-tuple for each + supported link speed on the host. + 0 = 1-2Gbps + 1 = 2-4Gbps (1st tuple default) + 2 = 4-8Gbps + 3 = 8-15Gbps (2nd tuple default) + 4 = 2.5-4Gbps + 5 = 4-5Gbps + 6 = 5-6Gbps + 7 = 6-16Gbps (3rd tuple default) + +NOTE: PHY override parameters are board specific setting. + +Example: + phy1: phy@1f21a000 { + compatible = "apm,xgene-phy"; + reg = <0x0 0x1f21a000 0x0 0x100>; + #phy-cells = <1>; + status = "disabled"; + }; + + phy2: phy@1f22a000 { + compatible = "apm,xgene-phy"; + reg = <0x0 0x1f22a000 0x0 0x100>; + #phy-cells = <1>; + status = "ok"; + }; + + phy3: phy@1f23a000 { + compatible = "apm,xgene-phy"; + reg = <0x0 0x1f23a000 0x0 0x100>; + #phy-cells = <1>; + status = "ok"; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index c0fccaa..28f9edb 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -20,3 +20,57 @@ Required properties: - compatible : should be "samsung,exynos5250-dp-video-phy"; - reg : offset and length of the Display Port PHY register set; - #phy-cells : from the generic PHY bindings, must be 0; + +Samsung S5P/EXYNOS SoC series USB PHY +------------------------------------------------- + +Required properties: +- compatible : should be one of the listed compatibles: + - "samsung,exynos4210-usb2-phy" + - "samsung,exynos4x12-usb2-phy" + - "samsung,exynos5250-usb2-phy" +- reg : a list of registers used by phy driver + - first and obligatory is the location of phy modules registers +- samsung,sysreg-phandle - handle to syscon used to control the system registers +- samsung,pmureg-phandle - handle to syscon used to control PMU registers +- #phy-cells : from the generic phy bindings, must be 1; +- clocks and clock-names: + - the "phy" clock is required by the phy module, used as a gate + - the "ref" clock is used to get the rate of the clock provided to the + PHY module + +The first phandle argument in the PHY specifier identifies the PHY, its +meaning is compatible dependent. For the currently supported SoCs (Exynos 4210 +and Exynos 4212) it is as follows: + 0 - USB device ("device"), + 1 - USB host ("host"), + 2 - HSIC0 ("hsic0"), + 3 - HSIC1 ("hsic1"), + +Exynos 4210 and Exynos 4212 use mode switching and require that mode switch +register is supplied. + +Example: + +For Exynos 4412 (compatible with Exynos 4212): + +usbphy: phy@125b0000 { + compatible = "samsung,exynos4x12-usb2-phy"; + reg = <0x125b0000 0x100>; + clocks = <&clock 305>, <&clock 2>; + clock-names = "phy", "ref"; + status = "okay"; + #phy-cells = <1>; + samsung,sysreg-phandle = <&sys_reg>; + samsung,pmureg-phandle = <&pmu_reg>; +}; + +Then the PHY can be used in other nodes such as: + +phy-consumer@12340000 { + phys = <&usbphy 2>; + phy-names = "phy"; +}; + +Refer to DT bindings documentation of particular PHY consumer devices for more +information about required PHYs and the way of specification. diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt new file mode 100644 index 0000000..a82361b --- /dev/null +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt @@ -0,0 +1,26 @@ +Allwinner sun4i USB PHY +----------------------- + +Required properties: +- compatible : should be one of "allwinner,sun4i-a10-usb-phy", + "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy" +- reg : a list of offset + length pairs +- reg-names : "phy_ctrl", "pmu1" and for sun4i or sun7i "pmu2" +- #phy-cells : from the generic phy bindings, must be 1 +- clocks : phandle + clock specifier for the phy clock +- clock-names : "usb_phy" +- resets : a list of phandle + reset specifier pairs +- reset-names : "usb0_reset", "usb1_reset" and for sun4i or sun7i "usb2_reset" + +Example: + usbphy: phy@0x01c13400 { + #phy-cells = <1>; + compatible = "allwinner,sun4i-a10-usb-phy"; + /* phy base regs, phy1 pmu reg, phy2 pmu reg */ + reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>; + reg-names = "phy_ctrl", "pmu1", "pmu2"; + clocks = <&usb_clk 8>; + clock-names = "usb_phy"; + resets = <&usb_clk 1>, <&usb_clk 2>; + reset-names = "usb1_reset", "usb2_reset"; + }; diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt new file mode 100644 index 0000000..788fb0f --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -0,0 +1,86 @@ +TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs + +OMAP CONTROL PHY + +Required properties: + - compatible: Should be one of + "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4. + "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register + e.g. USB2_PHY on OMAP5. + "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control + e.g. USB3 PHY and SATA PHY on OMAP5. + "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on + DRA7 platform. + "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on + AM437 platform. + - reg : Address and length of the register set for the device. It contains + the address of "otghs_control" for control-phy-otghs or "power" register + for other types. + - reg-names: should be "otghs_control" control-phy-otghs and "power" for + other types. + +omap_control_usb: omap-control-usb@4a002300 { + compatible = "ti,control-phy-otghs"; + reg = <0x4a00233c 0x4>; + reg-names = "otghs_control"; +}; + +OMAP USB2 PHY + +Required properties: + - compatible: Should be "ti,omap-usb2" + - reg : Address and length of the register set for the device. + - #phy-cells: determine the number of cells that should be given in the + phandle while referencing this phy. + +Optional properties: + - ctrl-module : phandle of the control module used by PHY driver to power on + the PHY. + +This is usually a subnode of ocp2scp to which it is connected. + +usb2phy@4a0ad080 { + compatible = "ti,omap-usb2"; + reg = <0x4a0ad080 0x58>; + ctrl-module = <&omap_control_usb>; + #phy-cells = <0>; +}; + +TI PIPE3 PHY + +Required properties: + - compatible: Should be "ti,phy-usb3" or "ti,phy-pipe3-sata". + "ti,omap-usb3" is deprecated. + - reg : Address and length of the register set for the device. + - reg-names: The names of the register addresses corresponding to the registers + filled in "reg". + - #phy-cells: determine the number of cells that should be given in the + phandle while referencing this phy. + - clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + - clock-names: should include: + * "wkupclk" - wakeup clock. + * "sysclk" - system clock. + * "refclk" - reference clock. + +Optional properties: + - ctrl-module : phandle of the control module used by PHY driver to power on + the PHY. + +This is usually a subnode of ocp2scp to which it is connected. + +usb3phy@4a084400 { + compatible = "ti,phy-usb3"; + reg = <0x4a084400 0x80>, + <0x4a084800 0x64>, + <0x4a084c00 0x40>; + reg-names = "phy_rx", "phy_tx", "pll_ctrl"; + ctrl-module = <&omap_control_usb>; + #phy-cells = <0>; + clocks = <&usb_phy_cm_clk32k>, + <&sys_clkin>, + <&usb_otg_ss_refclk960m>; + clock-names = "wkupclk", + "sysclk", + "refclk"; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt index 01ef408..adda2a8 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt @@ -5,6 +5,7 @@ part and usage. Required properties: - compatible: "marvell,88f6710-pinctrl" +- reg: register specifier of MPP registers Available mpp pins/groups and functions: Note: brackets (x) are not part of the mpp name for marvell,function and given diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt new file mode 100644 index 0000000..7de0cda --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt @@ -0,0 +1,82 @@ +* Marvell Armada 375 SoC pinctrl driver for mpp + +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding +part and usage. + +Required properties: +- compatible: "marvell,88f6720-pinctrl" +- reg: register specifier of MPP registers + +Available mpp pins/groups and functions: +Note: brackets (x) are not part of the mpp name for marvell,function and given +only for more detailed description in this document. + +name pins functions +================================================================================ +mpp0 0 gpio, dev(ad2), spi0(cs1), spi1(cs1) +mpp1 1 gpio, dev(ad3), spi0(mosi), spi1(mosi) +mpp2 2 gpio, dev(ad4), ptp(eventreq), led(c0), audio(sdi) +mpp3 3 gpio, dev(ad5), ptp(triggen), led(p3), audio(mclk) +mpp4 4 gpio, dev(ad6), spi0(miso), spi1(miso) +mpp5 5 gpio, dev(ad7), spi0(cs2), spi1(cs2) +mpp6 6 gpio, dev(ad0), led(p1), audio(rclk) +mpp7 7 gpio, dev(ad1), ptp(clk), led(p2), audio(extclk) +mpp8 8 gpio, dev (bootcs), spi0(cs0), spi1(cs0) +mpp9 9 gpio, nf(wen), spi0(sck), spi1(sck) +mpp10 10 gpio, nf(ren), dram(vttctrl), led(c1) +mpp11 11 gpio, dev(a0), led(c2), audio(sdo) +mpp12 12 gpio, dev(a1), audio(bclk) +mpp13 13 gpio, dev(readyn), pcie0(rstoutn), pcie1(rstoutn) +mpp14 14 gpio, i2c0(sda), uart1(txd) +mpp15 15 gpio, i2c0(sck), uart1(rxd) +mpp16 16 gpio, uart0(txd) +mpp17 17 gpio, uart0(rxd) +mpp18 18 gpio, tdm(intn) +mpp19 19 gpio, tdm(rstn) +mpp20 20 gpio, tdm(pclk) +mpp21 21 gpio, tdm(fsync) +mpp22 22 gpio, tdm(drx) +mpp23 23 gpio, tdm(dtx) +mpp24 24 gpio, led(p0), ge1(rxd0), sd(cmd), uart0(rts) +mpp25 25 gpio, led(p2), ge1(rxd1), sd(d0), uart0(cts) +mpp26 26 gpio, pcie0(clkreq), ge1(rxd2), sd(d2), uart1(rts) +mpp27 27 gpio, pcie1(clkreq), ge1(rxd3), sd(d1), uart1(cts) +mpp28 28 gpio, led(p3), ge1(txctl), sd(clk) +mpp29 29 gpio, pcie1(clkreq), ge1(rxclk), sd(d3) +mpp30 30 gpio, ge1(txd0), spi1(cs0) +mpp31 31 gpio, ge1(txd1), spi1(mosi) +mpp32 32 gpio, ge1(txd2), spi1(sck), ptp(triggen) +mpp33 33 gpio, ge1(txd3), spi1(miso) +mpp34 34 gpio, ge1(txclkout), spi1(sck) +mpp35 35 gpio, ge1(rxctl), spi1(cs1), spi0(cs2) +mpp36 36 gpio, pcie0(clkreq) +mpp37 37 gpio, pcie0(clkreq), tdm(intn), ge(mdc) +mpp38 38 gpio, pcie1(clkreq), ge(mdio) +mpp39 39 gpio, ref(clkout) +mpp40 40 gpio, uart1(txd) +mpp41 41 gpio, uart1(rxd) +mpp42 42 gpio, spi1(cs2), led(c0) +mpp43 43 gpio, sata0(prsnt), dram(vttctrl) +mpp44 44 gpio, sata0(prsnt) +mpp45 45 gpio, spi0(cs2), pcie0(rstoutn) +mpp46 46 gpio, led(p0), ge0(txd0), ge1(txd0) +mpp47 47 gpio, led(p1), ge0(txd1), ge1(txd1) +mpp48 48 gpio, led(p2), ge0(txd2), ge1(txd2) +mpp49 49 gpio, led(p3), ge0(txd3), ge1(txd3) +mpp50 50 gpio, led(c0), ge0(rxd0), ge1(rxd0) +mpp51 51 gpio, led(c1), ge0(rxd1), ge1(rxd1) +mpp52 52 gpio, led(c2), ge0(rxd2), ge1(rxd2) +mpp53 53 gpio, pcie1(rstoutn), ge0(rxd3), ge1(rxd3) +mpp54 54 gpio, pcie0(rstoutn), ge0(rxctl), ge1(rxctl) +mpp55 55 gpio, ge0(rxclk), ge1(rxclk) +mpp56 56 gpio, ge0(txclkout), ge1(txclkout) +mpp57 57 gpio, ge0(txctl), ge1(txctl) +mpp58 58 gpio, led(c0) +mpp59 59 gpio, led(c1) +mpp60 60 gpio, uart1(txd), led(c2) +mpp61 61 gpio, i2c1(sda), uart1(rxd), spi1(cs2), led(p0) +mpp62 62 gpio, i2c1(sck), led(p1) +mpp63 63 gpio, ptp(triggen), led(p2) +mpp64 64 gpio, dram(vttctrl), led(p3) +mpp65 65 gpio, sata1(prsnt) +mpp66 66 gpio, ptp(eventreq), spi1(cs3) diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt new file mode 100644 index 0000000..b17c968 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt @@ -0,0 +1,80 @@ +* Marvell Armada 380/385 SoC pinctrl driver for mpp + +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding +part and usage. + +Required properties: +- compatible: "marvell,88f6810-pinctrl", "marvell,88f6820-pinctrl" or + "marvell,88f6828-pinctrl" depending on the specific variant of the + SoC being used. +- reg: register specifier of MPP registers + +Available mpp pins/groups and functions: +Note: brackets (x) are not part of the mpp name for marvell,function and given +only for more detailed description in this document. + +name pins functions +================================================================================ +mpp0 0 gpio, ua0(rxd) +mpp1 1 gpio, ua0(txd) +mpp2 2 gpio, i2c0(sck) +mpp3 3 gpio, i2c0(sda) +mpp4 4 gpio, ge(mdc), ua1(txd), ua0(rts) +mpp5 5 gpio, ge(mdio), ua1(rxd), ua0(cts) +mpp6 6 gpio, ge0(txclkout), ge0(crs), dev(cs3) +mpp7 7 gpio, ge0(txd0), dev(ad9) +mpp8 8 gpio, ge0(txd1), dev(ad10) +mpp9 9 gpio, ge0(txd2), dev(ad11) +mpp10 10 gpio, ge0(txd3), dev(ad12) +mpp11 11 gpio, ge0(txctl), dev(ad13) +mpp12 12 gpio, ge0(rxd0), pcie0(rstout), pcie1(rstout) [1], spi0(cs1), dev(ad14) +mpp13 13 gpio, ge0(rxd1), pcie0(clkreq), pcie1(clkreq) [1], spi0(cs2), dev(ad15) +mpp14 14 gpio, ge0(rxd2), ptp(clk), m(vtt_ctrl), spi0(cs3), dev(wen1) +mpp15 15 gpio, ge0(rxd3), ge(mdc slave), pcie0(rstout), spi0(mosi), pcie1(rstout) [1] +mpp16 16 gpio, ge0(rxctl), ge(mdio slave), m(decc_err), spi0(miso), pcie0(clkreq) +mpp17 17 gpio, ge0(rxclk), ptp(clk), ua1(rxd), spi0(sck), sata1(prsnt) +mpp18 18 gpio, ge0(rxerr), ptp(trig_gen), ua1(txd), spi0(cs0), pcie1(rstout) [1] +mpp19 19 gpio, ge0(col), ptp(event_req), pcie0(clkreq), sata1(prsnt), ua0(cts) +mpp20 20 gpio, ge0(txclk), ptp(clk), pcie1(rstout) [1], sata0(prsnt), ua0(rts) +mpp21 21 gpio, spi0(cs1), ge1(rxd0), sata0(prsnt), sd0(cmd), dev(bootcs) +mpp22 22 gpio, spi0(mosi), dev(ad0) +mpp23 23 gpio, spi0(sck), dev(ad2) +mpp24 24 gpio, spi0(miso), ua0(cts), ua1(rxd), sd0(d4), dev(ready) +mpp25 25 gpio, spi0(cs0), ua0(rts), ua1(txd), sd0(d5), dev(cs0) +mpp26 26 gpio, spi0(cs2), i2c1(sck), sd0(d6), dev(cs1) +mpp27 27 gpio, spi0(cs3), ge1(txclkout), i2c1(sda), sd0(d7), dev(cs2) +mpp28 28 gpio, ge1(txd0), sd0(clk), dev(ad5) +mpp29 29 gpio, ge1(txd1), dev(ale0) +mpp30 30 gpio, ge1(txd2), dev(oen) +mpp31 31 gpio, ge1(txd3), dev(ale1) +mpp32 32 gpio, ge1(txctl), dev(wen0) +mpp33 33 gpio, m(decc_err), dev(ad3) +mpp34 34 gpio, dev(ad1) +mpp35 35 gpio, ref(clk_out1), dev(a1) +mpp36 36 gpio, ptp(trig_gen), dev(a0) +mpp37 37 gpio, ptp(clk), ge1(rxclk), sd0(d3), dev(ad8) +mpp38 38 gpio, ptp(event_req), ge1(rxd1), ref(clk_out0), sd0(d0), dev(ad4) +mpp39 39 gpio, i2c1(sck), ge1(rxd2), ua0(cts), sd0(d1), dev(a2) +mpp40 40 gpio, i2c1(sda), ge1(rxd3), ua0(rts), sd0(d2), dev(ad6) +mpp41 41 gpio, ua1(rxd), ge1(rxctl), ua0(cts), spi1(cs3), dev(burst/last) +mpp42 42 gpio, ua1(txd), ua0(rts), dev(ad7) +mpp43 43 gpio, pcie0(clkreq), m(vtt_ctrl), m(decc_err), pcie0(rstout), dev(clkout) +mpp44 44 gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], sata3(prsnt) [3], pcie0(rstout) +mpp45 45 gpio, ref(clk_out0), pcie0(rstout), pcie1(rstout) [1], pcie2(rstout), pcie3(rstout) +mpp46 46 gpio, ref(clk_out1), pcie0(rstout), pcie1(rstout) [1], pcie2(rstout), pcie3(rstout) +mpp47 47 gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], spi1(cs2), sata3(prsnt) [2] +mpp48 48 gpio, sata0(prsnt), m(vtt_ctrl), tdm2c(pclk), audio(mclk), sd0(d4) +mpp49 49 gpio, sata2(prsnt) [2], sata3(prsnt) [2], tdm2c(fsync), audio(lrclk), sd0(d5) +mpp50 50 gpio, pcie0(rstout), pcie1(rstout) [1], tdm2c(drx), audio(extclk), sd0(cmd) +mpp51 51 gpio, tdm2c(dtx), audio(sdo), m(decc_err) +mpp52 52 gpio, pcie0(rstout), pcie1(rstout) [1], tdm2c(intn), audio(sdi), sd0(d6) +mpp53 53 gpio, sata1(prsnt), sata0(prsnt), tdm2c(rstn), audio(bclk), sd0(d7) +mpp54 54 gpio, sata0(prsnt), sata1(prsnt), pcie0(rstout), pcie1(rstout) [1], sd0(d3) +mpp55 55 gpio, ua1(cts), ge(mdio), pcie1(clkreq) [1], spi1(cs1), sd0(d0) +mpp56 56 gpio, ua1(rts), ge(mdc), m(decc_err), spi1(mosi) +mpp57 57 gpio, spi1(sck), sd0(clk) +mpp58 58 gpio, pcie1(clkreq) [1], i2c1(sck), pcie2(clkreq), spi1(miso), sd0(d1) +mpp59 59 gpio, pcie0(rstout), i2c1(sda), pcie1(rstout) [1], spi1(cs0), sd0(d2) + +[1]: only available on 88F6820 and 88F6828 +[2]: only available on 88F6828 diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt index bfa0a2e..373dbccd 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt @@ -6,6 +6,7 @@ part and usage. Required properties: - compatible: "marvell,mv78230-pinctrl", "marvell,mv78260-pinctrl", "marvell,mv78460-pinctrl" +- reg: register specifier of MPP registers This driver supports all Armada XP variants, i.e. mv78230, mv78260, and mv78460. diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt index 50ec351..cf52477 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt @@ -6,6 +6,7 @@ part and usage. Required properties: - compatible: "marvell,dove-pinctrl" - clocks: (optional) phandle of pdma clock +- reg: register specifiers of MPP, MPP4, and PMU MPP registers Available mpp pins/groups and functions: Note: brackets (x) are not part of the mpp name for marvell,function and given diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt index 95daf63..730444a 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt @@ -8,6 +8,7 @@ Required properties: "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl", "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl" "marvell,98dx4122-pinctrl" +- reg: register specifier of MPP registers This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x. It also support the 88f6281-based variant in the 98dx412x Bobcat SoCs. diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt index 0a26c3a..0c09f4e 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt @@ -37,7 +37,7 @@ uart1: serial@12100 { pinctrl: pinctrl@d0200 { compatible = "marvell,dove-pinctrl"; - reg = <0xd0200 0x20>; + reg = <0xd0200 0x14>, <0xd0440 0x04>, <0xd802c 0x08>; pmx_uart1_sw: pmx-uart1-sw { marvell,pins = "mpp_uart1"; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt index bc0dfdf..66dcaa9 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt @@ -63,6 +63,13 @@ Optional properties: /* input, enable bits, disable bits, mask */ pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>; +- pinctrl-single,low-power-mode : array of value that are used to configure + low power mode of this pin. For some silicons, the low power mode will + control the output of the pin when the pad including the pin enter low + power mode. + /* low power mode value, mask */ + pinctrl-single,low-power-mode = <0x288 0x388>; + - pinctrl-single,gpio-range : list of value that are used to configure a GPIO range. They're value of subnode phandle, pin base in pinctrl device, pin number in this range, GPIO function value of this GPIO range. diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt index 05bf82a..4bd5be0 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt @@ -11,18 +11,68 @@ Pull Up (PU) are driven by the related PIO block. ST pinctrl driver controls PIO multiplexing block and also interacts with gpio driver to configure a pin. -Required properties: (PIO multiplexing block) +GPIO bank can have one of the two possible types of interrupt-wirings. + +First type is via irqmux, single interrupt is used by multiple gpio banks. This +reduces number of overall interrupts numbers required. All these banks belong to +a single pincontroller. + _________ + | |----> [gpio-bank (n) ] + | |----> [gpio-bank (n + 1)] + [irqN]-- | irq-mux |----> [gpio-bank (n + 2)] + | |----> [gpio-bank (... )] + |_________|----> [gpio-bank (n + 7)] + +Second type has a dedicated interrupt per gpio bank. + + [irqN]----> [gpio-bank (n)] + + +Pin controller node: +Required properties: - compatible : should be "st,<SOC>-<pio-block>-pinctrl" like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on. -- gpio-controller : Indicates this device is a GPIO controller -- #gpio-cells : Should be one. The first cell is the pin number. +- st,syscfg : Should be a phandle of the syscfg node. - st,retime-pin-mask : Should be mask to specify which pins can be retimed. If the property is not present, it is assumed that all the pins in the bank are capable of retiming. Retiming is mainly used to improve the IO timing margins of external synchronous interfaces. -- st,bank-name : Should be a name string for this bank as - specified in datasheet. -- st,syscfg : Should be a phandle of the syscfg node. +- ranges : defines mapping between pin controller node (parent) to gpio-bank + node (children). + +Optional properties: +- interrupts : Interrupt number of the irqmux. If the interrupt is shared + with other gpio banks via irqmux. + a irqline and gpio banks. +- reg : irqmux memory resource. If irqmux is present. +- reg-names : irqmux resource should be named as "irqmux". + +GPIO controller/bank node. +Required properties: +- gpio-controller : Indicates this device is a GPIO controller +- #gpio-cells : Should be one. The first cell is the pin number. +- st,bank-name : Should be a name string for this bank as specified in + datasheet. + +Optional properties: +- interrupts : Interrupt number for this gpio bank. If there is a dedicated + interrupt wired up for this gpio bank. + +- interrupt-controller : Indicates this device is a interrupt controller. GPIO + bank can be an interrupt controller iff one of the interrupt type either via +irqmux or a dedicated interrupt per bank is specified. + +- #interrupt-cells: the value of this property should be 2. + - First Cell: represents the external gpio interrupt number local to the + gpio interrupt space of the controller. + - Second Cell: flags to identify the type of the interrupt + - 1 = rising edge triggered + - 2 = falling edge triggered + - 3 = rising and falling edge triggered + - 4 = high level triggered + - 8 = low level triggered +for related macros look in: +include/dt-bindings/interrupt-controller/irq.h Example: pin-controller-sbc { @@ -30,10 +80,17 @@ Example: #size-cells = <1>; compatible = "st,stih415-sbc-pinctrl"; st,syscfg = <&syscfg_sbc>; + reg = <0xfe61f080 0x4>; + reg-names = "irqmux"; + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>; + interrupts-names = "irqmux"; ranges = <0 0xfe610000 0x5000>; + PIO0: gpio@fe610000 { gpio-controller; #gpio-cells = <1>; + interrupt-controller; + #interrupt-cells = <2>; reg = <0 0x100>; st,bank-name = "PIO0"; }; @@ -105,6 +162,10 @@ pin-controller { sdhci0:sdhci@fe810000{ ... + interrupt-parent = <&PIO3>; + #interrupt-cells = <2>; + interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; /* Interrupt line via PIO3-3 */ + interrupts-names = "card-detect"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_mmc>; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt index 4c352be..9fb89e3 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt @@ -1,7 +1,7 @@ Qualcomm MSM8974 TLMM block Required properties: -- compatible: "qcom,msm8x74-pinctrl" +- compatible: "qcom,msm8974-pinctrl" - reg: Should be the base address and length of the TLMM block. - interrupts: Should be the parent IRQ of the TLMM block. - interrupt-controller: Marks the device node as an interrupt controller. @@ -42,14 +42,14 @@ Non-empty subnodes must specify the 'pins' property. Note that not all properties are valid for all pins. -Valid values for qcom,pins are: +Valid values for pins are: gpio0-gpio145 Supports mux, bias and drive-strength sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data Supports bias and drive-strength -Valid values for qcom,function are: +Valid values for function are: blsp_i2c2, blsp_i2c6, blsp_i2c11, blsp_spi1, blsp_uart2, blsp_uart8, slimbus (Note that this is not yet the complete list of functions) @@ -73,18 +73,18 @@ Example: uart2_default: uart2_default { mux { - qcom,pins = "gpio4", "gpio5"; - qcom,function = "blsp_uart2"; + pins = "gpio4", "gpio5"; + function = "blsp_uart2"; }; tx { - qcom,pins = "gpio4"; + pins = "gpio4"; drive-strength = <4>; bias-disable; }; rx { - qcom,pins = "gpio5"; + pins = "gpio5"; drive-strength = <2>; bias-pull-up; }; diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index 257677d..2b32783 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -16,6 +16,7 @@ Required Properties: - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller. - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller. - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller. + - "samsung,exynos5260-pinctrl": for Exynos5260 compatible pin-controller. - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller. - reg: Base address of the pin controller hardware module and length of diff --git a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt b/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt new file mode 100644 index 0000000..c41b218 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt @@ -0,0 +1,23 @@ +Freescale L2 Cache Controller + +L2 cache is present in Freescale's QorIQ and QorIQ Qonverge platforms. +The cache bindings explained below are ePAPR compliant + +Required Properties: + +- compatible : Should include "fsl,chip-l2-cache-controller" and "cache" + where chip is the processor (bsc9132, npc8572 etc.) +- reg : Address and size of L2 cache controller registers +- cache-size : Size of the entire L2 cache +- interrupts : Error interrupt of L2 controller +- cache-line-size : Size of L2 cache lines + +Example: + + L2: l2-cache-controller@20000 { + compatible = "fsl,bsc9132-l2-cache-controller", "cache"; + reg = <0x20000 0x1000>; + cache-line-size = <32>; // 32 bytes + cache-size = <0x40000>; // L2,256K + interrupts = <16 2 1 0>; + }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt b/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt new file mode 100644 index 0000000..f87856f --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt @@ -0,0 +1,27 @@ +Freescale DDR memory controller + +Properties: + +- compatible : Should include "fsl,chip-memory-controller" where + chip is the processor (bsc9132, mpc8572 etc.), or + "fsl,qoriq-memory-controller". +- reg : Address and size of DDR controller registers +- interrupts : Error interrupt of DDR controller + +Example 1: + + memory-controller@2000 { + compatible = "fsl,bsc9132-memory-controller"; + reg = <0x2000 0x1000>; + interrupts = <16 2 1 8>; + }; + + +Example 2: + + ddr1: memory-controller@8000 { + compatible = "fsl,qoriq-memory-controller-v4.7", + "fsl,qoriq-memory-controller"; + reg = <0x8000 0x1000>; + interrupts = <16 2 1 23>; + }; diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt index 63c6598..e5cac1e 100644 --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt @@ -8,8 +8,12 @@ Required properties: Optional properties: - enable-gpio : GPIO to use to enable/disable the regulator. - gpios : GPIO group used to control voltage. +- gpios-states : gpios pin's initial states array. 0: LOW, 1: HIGH. + defualt is LOW if nothing is specified. - startup-delay-us : Startup time in microseconds. - enable-active-high : Polarity of GPIO is active high (default is low). +- regulator-type : Specifies what is being regulated, must be either + "voltage" or "current", defaults to current. Any property defined as part of the core regulator binding defined in regulator.txt can also be used. diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt b/Documentation/devicetree/bindings/regulator/pfuze100.txt index fc989b2..34ef5d1 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.txt +++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt @@ -1,7 +1,7 @@ PFUZE100 family of regulators Required properties: -- compatible: "fsl,pfuze100" +- compatible: "fsl,pfuze100" or "fsl,pfuze200" - reg: I2C slave address Required child node: @@ -10,11 +10,14 @@ Required child node: Documentation/devicetree/bindings/regulator/regulator.txt. The valid names for regulators are: + --PFUZE100 sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6 + --PFUZE200 + sw1ab,sw2,sw3a,sw3b,swbst,vsnvs,vrefddr,vgen1~vgen6 Each regulator is defined using the standard binding for regulators. -Example: +Example 1: PFUZE100 pmic: pfuze100@08 { compatible = "fsl,pfuze100"; @@ -113,3 +116,92 @@ Example: }; }; }; + + +Example 2: PFUZE200 + + pmic: pfuze200@08 { + compatible = "fsl,pfuze200"; + reg = <0x08>; + + regulators { + sw1a_reg: sw1ab { + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1875000>; + regulator-boot-on; + regulator-always-on; + regulator-ramp-delay = <6250>; + }; + + sw2_reg: sw2 { + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + sw3a_reg: sw3a { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1975000>; + regulator-boot-on; + regulator-always-on; + }; + + sw3b_reg: sw3b { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1975000>; + regulator-boot-on; + regulator-always-on; + }; + + swbst_reg: swbst { + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5150000>; + }; + + snvs_reg: vsnvs { + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3000000>; + regulator-boot-on; + regulator-always-on; + }; + + vref_reg: vrefddr { + regulator-boot-on; + regulator-always-on; + }; + + vgen1_reg: vgen1 { + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1550000>; + }; + + vgen2_reg: vgen2 { + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1550000>; + }; + + vgen3_reg: vgen3 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + }; + + vgen4_reg: vgen4 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + vgen5_reg: vgen5 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + vgen6_reg: vgen6 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt index fc6b38f..d290988 100644 --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt @@ -69,13 +69,16 @@ sub-node should be of the format as listed below. }; }; The above regulator entries are defined in regulator bindings documentation -except op_mode description. +except these properties: - op_mode: describes the different operating modes of the LDO's with power mode change in SOC. The different possible values are, 0 - always off mode 1 - on in normal mode 2 - low power mode 3 - suspend mode + - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one + GPIO controlling this regulator (enable/disable); This is + valid only for buck9. The following are the names of the regulators that the s5m8767 pmic block supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number @@ -148,5 +151,13 @@ Example: regulator-always-on; regulator-boot-on; }; + + vemmc_reg: BUCK9 { + regulator-name = "VMEM_VDD_2.8V"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + op_mode = <3>; /* Standby Mode */ + s5m8767,pmic-ext-control-gpios = <&gpk0 2 0>; + }; }; }; diff --git a/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt index 2e57a33..c58db75 100644 --- a/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt @@ -4,10 +4,14 @@ Required Properties: - compatible: Should be one of: - "ti,abb-v1" for older SoCs like OMAP3 - "ti,abb-v2" for newer SoCs like OMAP4, OMAP5 + - "ti,abb-v3" for a generic definition where setup and control registers are + provided (example: DRA7) - reg: Address and length of the register set for the device. It contains the information of registers in the same order as described by reg-names - reg-names: Should contain the reg names - - "base-address" - contains base address of ABB module + - "base-address" - contains base address of ABB module (ti,abb-v1,ti,abb-v2) + - "control-address" - contains control register address of ABB module (ti,abb-v3) + - "setup-address" - contains setup register address of ABB module (ti,abb-v3) - "int-address" - contains address of interrupt register for ABB module (also see Optional properties) - #address-cell: should be 0 diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt new file mode 100644 index 0000000..3da0ebd --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt @@ -0,0 +1,133 @@ +*** Reserved memory regions *** + +Reserved memory is specified as a node under the /reserved-memory node. +The operating system shall exclude reserved memory from normal usage +one can create child nodes describing particular reserved (excluded from +normal use) memory regions. Such memory regions are usually designed for +the special usage by various device drivers. + +Parameters for each memory region can be encoded into the device tree +with the following nodes: + +/reserved-memory node +--------------------- +#address-cells, #size-cells (required) - standard definition + - Should use the same values as the root node +ranges (required) - standard definition + - Should be empty + +/reserved-memory/ child nodes +----------------------------- +Each child of the reserved-memory node specifies one or more regions of +reserved memory. Each child node may either use a 'reg' property to +specify a specific range of reserved memory, or a 'size' property with +optional constraints to request a dynamically allocated block of memory. + +Following the generic-names recommended practice, node names should +reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit +address (@<address>) should be appended to the name if the node is a +static allocation. + +Properties: +Requires either a) or b) below. +a) static allocation + reg (required) - standard definition +b) dynamic allocation + size (required) - length based on parent's #size-cells + - Size in bytes of memory to reserve. + alignment (optional) - length based on parent's #size-cells + - Address boundary for alignment of allocation. + alloc-ranges (optional) - prop-encoded-array (address, length pairs). + - Specifies regions of memory that are + acceptable to allocate from. + +If both reg and size are present, then the reg property takes precedence +and size is ignored. + +Additional properties: +compatible (optional) - standard definition + - may contain the following strings: + - shared-dma-pool: This indicates a region of memory meant to be + used as a shared pool of DMA buffers for a set of devices. It can + be used by an operating system to instanciate the necessary pool + management subsystem if necessary. + - vendor specific string in the form <vendor>,[<device>-]<usage> +no-map (optional) - empty property + - Indicates the operating system must not create a virtual mapping + of the region as part of its standard mapping of system memory, + nor permit speculative access to it under any circumstances other + than under the control of the device driver using the region. +reusable (optional) - empty property + - The operating system can use the memory in this region with the + limitation that the device driver(s) owning the region need to be + able to reclaim it back. Typically that means that the operating + system can use that region to store volatile or cached data that + can be otherwise regenerated or migrated elsewhere. + +Linux implementation note: +- If a "linux,cma-default" property is present, then Linux will use the + region for the default pool of the contiguous memory allocator. + +Device node references to reserved memory +----------------------------------------- +Regions in the /reserved-memory node may be referenced by other device +nodes by adding a memory-region property to the device node. + +memory-region (optional) - phandle, specifier pairs to children of /reserved-memory + +Example +------- +This example defines 3 contiguous regions are defined for Linux kernel: +one default of all device drivers (named linux,cma@72000000 and 64MiB in size), +one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), and +one for multimedia processing (named multimedia-memory@77000000, 64MiB). + +/ { + #address-cells = <1>; + #size-cells = <1>; + + memory { + reg = <0x40000000 0x40000000>; + }; + + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + /* global autoconfigured region for contiguous allocations */ + linux,cma { + compatible = "shared-dma-pool"; + reusable; + size = <0x4000000>; + alignment = <0x2000>; + linux,cma-default; + }; + + display_reserved: framebuffer@78000000 { + reg = <0x78000000 0x800000>; + }; + + multimedia_reserved: multimedia@77000000 { + compatible = "acme,multimedia-memory"; + reg = <0x77000000 0x4000000>; + }; + }; + + /* ... */ + + fb0: video@12300000 { + memory-region = <&display_reserved>; + /* ... */ + }; + + scaler: scaler@12500000 { + memory-region = <&multimedia_reserved>; + /* ... */ + }; + + codec: codec@12600000 { + memory-region = <&multimedia_reserved>; + /* ... */ + }; +}; diff --git a/Documentation/devicetree/bindings/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt index 8e080b8..1984bdf 100644 --- a/Documentation/devicetree/bindings/serial/efm32-uart.txt +++ b/Documentation/devicetree/bindings/serial/efm32-uart.txt @@ -6,7 +6,7 @@ Required properties: - interrupts : Should contain uart interrupt Optional properties: -- location : Decides the location of the USART I/O pins. +- efm32,location : Decides the location of the USART I/O pins. Allowed range : [0 .. 5] Default: 0 @@ -16,5 +16,5 @@ uart@0x4000c400 { compatible = "efm32,uart"; reg = <0x4000c400 0x400>; interrupts = <15>; - location = <0>; + efm32,location = <0>; }; diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt index 6fd1dd1..a1d1205 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt @@ -4,11 +4,24 @@ Required properties: - compatible : Should be "fsl,<soc>-lpuart" - reg : Address and length of the register set for the device - interrupts : Should contain uart interrupt +- clocks : phandle + clock specifier pairs, one for each entry in clock-names +- clock-names : should contain: "ipg" - the uart clock + +Optional properties: +- dmas: A list of two dma specifiers, one for each entry in dma-names. +- dma-names: should contain "tx" and "rx". + +Note: Optional properties for DMA support. Write them both or both not. Example: uart0: serial@40027000 { - compatible = "fsl,vf610-lpuart"; - reg = <0x40027000 0x1000>; - interrupts = <0 61 0x00>; - }; + compatible = "fsl,vf610-lpuart"; + reg = <0x40027000 0x1000>; + interrupts = <0 61 0x00>; + clocks = <&clks VF610_CLK_UART0>; + clock-names = "ipg"; + dmas = <&edma0 0 2>, + <&edma0 0 3>; + dma-names = "rx","tx"; + }; diff --git a/Documentation/devicetree/bindings/serial/maxim,max310x.txt b/Documentation/devicetree/bindings/serial/maxim,max310x.txt new file mode 100644 index 0000000..83a919c --- /dev/null +++ b/Documentation/devicetree/bindings/serial/maxim,max310x.txt @@ -0,0 +1,36 @@ +* Maxim MAX310X advanced Universal Asynchronous Receiver-Transmitter (UART) + +Required properties: +- compatible: Should be one of the following: + - "maxim,max3107" for Maxim MAX3107, + - "maxim,max3108" for Maxim MAX3108, + - "maxim,max3109" for Maxim MAX3109, + - "maxim,max14830" for Maxim MAX14830. +- reg: SPI chip select number. +- interrupt-parent: The phandle for the interrupt controller that + services interrupts for this IC. +- interrupts: Specifies the interrupt source of the parent interrupt + controller. The format of the interrupt specifier depends on the + parent interrupt controller. +- clocks: phandle to the IC source clock. +- clock-names: Should be "xtal" if clock is an external crystal or + "osc" if an external clock source is used. + +Optional properties: +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells: Should be two. The first cell is the GPIO number and + the second cell is used to specify the GPIO polarity: + 0 = active high, + 1 = active low. + +Example: + max14830: max14830@0 { + compatible = "maxim,max14830"; + reg = <0>; + clocks = <&clk20m>; + clock-names = "osc"; + interrupt-parent = <&gpio3>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index f372cf2..53e6c17 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -37,7 +37,7 @@ Example: }; scifa0: serial@e6c40000 { - compatible = "renesas,scifa-r8a7790", "renesas,scifa-generic"; + compatible = "renesas,scifa-r8a7790", "renesas,scifa"; reg = <0 0xe6c40000 0 64>; interrupt-parent = <&gic>; interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>; diff --git a/Documentation/devicetree/bindings/sound/armada-370db-audio.txt b/Documentation/devicetree/bindings/sound/armada-370db-audio.txt new file mode 100644 index 0000000..bf984d2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/armada-370db-audio.txt @@ -0,0 +1,27 @@ +Device Tree bindings for the Armada 370 DB audio +================================================ + +These Device Tree bindings are used to describe the audio complex +found on the Armada 370 DB platform. + +Mandatory properties: + + * compatible: must be "marvell,a370db-audio" + + * marvell,audio-controller: a phandle that points to the audio + controller of the Armada 370 SoC. + + * marvell,audio-codec: a set of three phandles that points to: + + 1/ the analog audio codec connected to the Armada 370 SoC + 2/ the S/PDIF transceiver + 3/ the S/PDIF receiver + +Example: + + sound { + compatible = "marvell,a370db-audio"; + marvell,audio-controller = <&audio_controller>; + marvell,audio-codec = <&audio_codec &spdif_out &spdif_in>; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/sound/cs42xx8.txt b/Documentation/devicetree/bindings/sound/cs42xx8.txt new file mode 100644 index 0000000..f631fbc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cs42xx8.txt @@ -0,0 +1,28 @@ +CS42448/CS42888 audio CODEC + +Required properties: + + - compatible : must contain one of "cirrus,cs42448" and "cirrus,cs42888" + + - reg : the I2C address of the device for I2C + + - clocks : a list of phandles + clock-specifiers, one for each entry in + clock-names + + - clock-names : must contain "mclk" + + - VA-supply, VD-supply, VLS-supply, VLC-supply: power supplies for the device, + as covered in Documentation/devicetree/bindings/regulator/regulator.txt + +Example: + +codec: cs42888@48 { + compatible = "cirrus,cs42888"; + reg = <0x48>; + clocks = <&codec_mclk 0>; + clock-names = "mclk"; + VA-supply = <®_audio>; + VD-supply = <®_audio>; + VLS-supply = <®_audio>; + VLC-supply = <®_audio>; +}; diff --git a/Documentation/devicetree/bindings/sound/da9055.txt b/Documentation/devicetree/bindings/sound/da9055.txt new file mode 100644 index 0000000..ed1b7cc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/da9055.txt @@ -0,0 +1,22 @@ +* Dialog DA9055 Audio CODEC + +DA9055 provides Audio CODEC support (I2C only). + +The Audio CODEC device in DA9055 has it's own I2C address which is configurable, +so the device is instantiated separately from the PMIC (MFD) device. + +For details on accompanying PMIC I2C device, see the following: +Documentation/devicetree/bindings/mfd/da9055.txt + +Required properties: + + - compatible: "dlg,da9055-codec" + - reg: Specifies the I2C slave address + + +Example: + + codec: da9055-codec@1a { + compatible = "dlg,da9055-codec"; + reg = <0x1a>; + }; diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt index 865178d..963e100 100644 --- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt +++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt @@ -5,12 +5,19 @@ Required properties: - ti,model : The user-visible name of this sound complex. - ti,audio-codec : The phandle of the TLV320AIC3x audio codec - ti,mcasp-controller : The phandle of the McASP controller -- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec - ti,audio-routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. Valid names for sources and sinks are the codec's pins, and the jacks on the board: +Optional properties: +- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec. +- clocks : Reference to the master clock +- clock-names : The clock should be named "mclk" +- Either codec-clock-rate or the codec-clock reference has to be defined. If + the both are defined the driver attempts to set referenced clock to the + defined rate and takes the rate from the clock reference. + Board connectors: * Headphone Jack diff --git a/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt new file mode 100644 index 0000000..0d7985c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt @@ -0,0 +1,21 @@ +Audio complex for Eukrea boards with tlv320aic23 codec. + +Required properties: +- compatible : "eukrea,asoc-tlv320" +- eukrea,model : The user-visible name of this sound complex. +- ssi-controller : The phandle of the SSI controller. +- fsl,mux-int-port : The internal port of the i.MX audio muxer (AUDMUX). +- fsl,mux-ext-port : The external port of the i.MX audio muxer. + +Note: The AUDMUX port numbering should start at 1, which is consistent with +hardware manual. + +Example: + + sound { + compatible = "eukrea,asoc-tlv320"; + eukrea,model = "imx51-eukrea-tlv320aic23"; + ssi-controller = <&ssi2>; + fsl,mux-int-port = <2>; + fsl,mux-ext-port = <3>; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt index d7b99fa..aeb8c4a 100644 --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt +++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt @@ -34,6 +34,10 @@ Required properties: that ESAI would work in the synchronous mode, which means all the settings for Receiving would be duplicated from Transmition related registers. + - big-endian : If this property is absent, the native endian mode will + be in use as default, or the big endian mode will be in use for all the + device registers. + Example: esai: esai@02024000 { @@ -46,5 +50,6 @@ esai: esai@02024000 { dma-names = "rx", "tx"; fsl,fifo-depth = <128>; fsl,esai-synchronous; + big-endian; status = "disabled"; }; diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt b/Documentation/devicetree/bindings/sound/fsl,spdif.txt index f2ae335..3e9e82c8 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt @@ -29,6 +29,10 @@ Required properties: can also be referred to TxClk_Source bit of register SPDIF_STC. + - big-endian : If this property is absent, the native endian mode will + be in use as default, or the big endian mode will be in use for all the + device registers. + Example: spdif: spdif@02004000 { @@ -50,5 +54,6 @@ spdif: spdif@02004000 { "rxtx5", "rxtx6", "rxtx7"; + big-endian; status = "okay"; }; diff --git a/Documentation/devicetree/bindings/sound/mvebu-audio.txt b/Documentation/devicetree/bindings/sound/mvebu-audio.txt index f0062c5..cb8c07c 100644 --- a/Documentation/devicetree/bindings/sound/mvebu-audio.txt +++ b/Documentation/devicetree/bindings/sound/mvebu-audio.txt @@ -5,6 +5,7 @@ Required properties: - compatible: "marvell,kirkwood-audio" for Kirkwood platforms "marvell,dove-audio" for Dove platforms + "marvell,armada370-audio" for Armada 370 platforms - reg: physical base address of the controller and length of memory mapped region. diff --git a/Documentation/devicetree/bindings/sound/pcm512x.txt b/Documentation/devicetree/bindings/sound/pcm512x.txt new file mode 100644 index 0000000..faff75e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/pcm512x.txt @@ -0,0 +1,30 @@ +PCM512x audio CODECs + +These devices support both I2C and SPI (configured with pin strapping +on the board). + +Required properties: + + - compatible : One of "ti,pcm5121" or "ti,pcm5122" + + - reg : the I2C address of the device for I2C, the chip select + number for SPI. + + - AVDD-supply, DVDD-supply, and CPVDD-supply : power supplies for the + device, as covered in bindings/regulator/regulator.txt + +Optional properties: + + - clocks : A clock specifier for the clock connected as SCLK. If this + is absent the device will be configured to clock from BCLK. + +Example: + + pcm5122: pcm5122@4c { + compatible = "ti,pcm5122"; + reg = <0x4c>; + + AVDD-supply = <®_3v3_analog>; + DVDD-supply = <®_1v8>; + CPVDD-supply = <®_3v3>; + }; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt new file mode 100644 index 0000000..a44e917 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -0,0 +1,105 @@ +Renesas R-Car sound + +Required properties: +- compatible : "renesas,rcar_sound-gen1" if generation1 + "renesas,rcar_sound-gen2" if generation2 +- reg : Should contain the register physical address. + required register is + SRU/ADG/SSI if generation1 + SRU/ADG/SSIU/SSI if generation2 +- rcar_sound,ssi : Should contain SSI feature. + The number of SSI subnode should be same as HW. + see below for detail. +- rcar_sound,src : Should contain SRC feature. + The number of SRC subnode should be same as HW. + see below for detail. +- rcar_sound,dai : DAI contents. + The number of DAI subnode should be same as HW. + see below for detail. + +SSI subnode properties: +- interrupts : Should contain SSI interrupt for PIO transfer +- shared-pin : if shared clock pin + +SRC subnode properties: +no properties at this point + +DAI subnode properties: +- playback : list of playback modules +- capture : list of capture modules + +Example: + +rcar_sound: rcar_sound@0xffd90000 { + #sound-dai-cells = <1>; + compatible = "renesas,rcar_sound-gen2"; + reg = <0 0xec500000 0 0x1000>, /* SCU */ + <0 0xec5a0000 0 0x100>, /* ADG */ + <0 0xec540000 0 0x1000>, /* SSIU */ + <0 0xec541000 0 0x1280>; /* SSI */ + + rcar_sound,src { + src0: src@0 { }; + src1: src@1 { }; + src2: src@2 { }; + src3: src@3 { }; + src4: src@4 { }; + src5: src@5 { }; + src6: src@6 { }; + src7: src@7 { }; + src8: src@8 { }; + src9: src@9 { }; + }; + + rcar_sound,ssi { + ssi0: ssi@0 { + interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi1: ssi@1 { + interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi2: ssi@2 { + interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi3: ssi@3 { + interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi4: ssi@4 { + interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi5: ssi@5 { + interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi6: ssi@6 { + interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi7: ssi@7 { + interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi8: ssi@8 { + interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>; + }; + ssi9: ssi@9 { + interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + + rcar_sound,dai { + dai0 { + playback = <&ssi5 &src5>; + capture = <&ssi6>; + }; + dai1 { + playback = <&ssi3>; + }; + dai2 { + capture = <&ssi4>; + }; + dai3 { + playback = <&ssi7>; + }; + dai4 { + capture = <&ssi8>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 19c84df..131aa2a 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -8,16 +8,26 @@ Required properties: Optional properties: +- simple-audio-card,name : User specified audio sound card name, one string + property. - simple-audio-card,format : CPU/CODEC common audio format. "i2s", "right_j", "left_j" , "dsp_a" "dsp_b", "ac97", "pdm", "msb", "lsb" +- simple-audio-card,widgets : Please refer to widgets.txt. - simple-audio-card,routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. +- dai-tdm-slot-num : Please refer to tdm-slot.txt. +- dai-tdm-slot-width : Please refer to tdm-slot.txt. Required subnodes: +- simple-audio-card,dai-link : container for the CPU and CODEC sub-nodes + This container may be omitted when the + card has only one DAI link. + See the examples. + - simple-audio-card,cpu : CPU sub-node - simple-audio-card,codec : CODEC sub-node @@ -38,15 +48,29 @@ Optional CPU/CODEC subnodes properties: clock node (= common clock), or "system-clock-frequency" (if system doens't support common clock) -Example: +Note: + * For 'format', 'frame-master', 'bitclock-master', 'bitclock-inversion' and + 'frame-inversion', the simple card will use the settings of CODEC for both + CPU and CODEC sides as we need to keep the settings identical for both ends + of the link. + +Example 1 - single DAI link: sound { compatible = "simple-audio-card"; + simple-audio-card,name = "VF610-Tower-Sound-Card"; simple-audio-card,format = "left_j"; + simple-audio-card,widgets = + "Microphone", "Microphone Jack", + "Headphone", "Headphone Jack", + "Speaker", "External Speaker"; simple-audio-card,routing = - "MIC_IN", "Mic Jack", + "MIC_IN", "Microphone Jack", "Headphone Jack", "HP_OUT", - "Ext Spk", "LINE_OUT"; + "External Speaker", "LINE_OUT"; + + dai-tdm-slot-num = <2>; + dai-tdm-slot-width = <8>; simple-audio-card,cpu { sound-dai = <&sh_fsi2 0>; @@ -75,3 +99,38 @@ sh_fsi2: sh_fsi2@ec230000 { interrupt-parent = <&gic>; interrupts = <0 146 0x4>; }; + +Example 2 - many DAI links: + +sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "Cubox Audio"; + simple-audio-card,format = "i2s"; + + simple-audio-card,dai-link@0 { /* I2S - HDMI */ + simple-audio-card,cpu { + sound-dai = <&audio1 0>; + }; + simple-audio-card,codec { + sound-dai = <&tda998x 0>; + }; + }; + + simple-audio-card,dai-link@1 { /* S/PDIF - HDMI */ + simple-audio-card,cpu { + sound-dai = <&audio1 1>; + }; + simple-audio-card,codec { + sound-dai = <&tda998x 1>; + }; + }; + + simple-audio-card,dai-link@2 { /* S/PDIF - S/PDIF */ + simple-audio-card,cpu { + sound-dai = <&audio1 1>; + }; + simple-audio-card,codec { + sound-dai = <&spdif_codec>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/sound/sirf-audio-codec.txt b/Documentation/devicetree/bindings/sound/sirf-audio-codec.txt new file mode 100644 index 0000000..062f5ec --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sirf-audio-codec.txt @@ -0,0 +1,17 @@ +SiRF internal audio CODEC + +Required properties: + + - compatible : "sirf,atlas6-audio-codec" or "sirf,prima2-audio-codec" + + - reg : the register address of the device. + + - clocks: the clock of SiRF internal audio codec + +Example: + +audiocodec: audiocodec@b0040000 { + compatible = "sirf,atlas6-audio-codec"; + reg = <0xb0040000 0x10000>; + clocks = <&clks 27>; +}; diff --git a/Documentation/devicetree/bindings/sound/sirf-audio-port.txt b/Documentation/devicetree/bindings/sound/sirf-audio-port.txt new file mode 100644 index 0000000..1f66de3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sirf-audio-port.txt @@ -0,0 +1,20 @@ +* SiRF SoC audio port + +Required properties: +- compatible: "sirf,audio-port" +- reg: Base address and size entries: +- dmas: List of DMA controller phandle and DMA request line ordered pairs. +- dma-names: Identifier string for each DMA request line in the dmas property. + These strings correspond 1:1 with the ordered pairs in dmas. + + One of the DMA channels will be responsible for transmission (should be + named "tx") and one for reception (should be named "rx"). + +Example: + +audioport: audioport@b0040000 { + compatible = "sirf,audio-port"; + reg = <0xb0040000 0x10000>; + dmas = <&dmac1 3>, <&dmac1 8>; + dma-names = "rx", "tx"; +}; diff --git a/Documentation/devicetree/bindings/sound/sirf-audio.txt b/Documentation/devicetree/bindings/sound/sirf-audio.txt new file mode 100644 index 0000000..c88882c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sirf-audio.txt @@ -0,0 +1,41 @@ +* SiRF atlas6 and prima2 internal audio codec and port based audio setups + +Required properties: +- compatible: "sirf,sirf-audio-card" +- sirf,audio-platform: phandle for the platform node +- sirf,audio-codec: phandle for the SiRF internal codec node + +Optional properties: +- hp-pa-gpios: Need to be present if the board need control external + headphone amplifier. +- spk-pa-gpios: Need to be present if the board need control external + speaker amplifier. +- hp-switch-gpios: Need to be present if the board capable to detect jack + insertion, removal. + +Available audio endpoints for the audio-routing table: + +Board connectors: + * Headset Stereophone + * Ext Spk + * Line In + * Mic + +SiRF internal audio codec pins: + * HPOUTL + * HPOUTR + * SPKOUT + * Ext Mic + * Mic Bias + +Example: + +sound { + compatible = "sirf,sirf-audio-card"; + sirf,audio-codec = <&audiocodec>; + sirf,audio-platform = <&audioport>; + hp-pa-gpios = <&gpio 44 0>; + spk-pa-gpios = <&gpio 46 0>; + hp-switch-gpios = <&gpio 45 0>; +}; + diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt b/Documentation/devicetree/bindings/sound/tdm-slot.txt new file mode 100644 index 0000000..6a2c842 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tdm-slot.txt @@ -0,0 +1,20 @@ +TDM slot: + +This specifies audio DAI's TDM slot. + +TDM slot properties: +dai-tdm-slot-num : Number of slots in use. +dai-tdm-slot-width : Width in bits for each slot. + +For instance: + dai-tdm-slot-num = <2>; + dai-tdm-slot-width = <8>; + +And for each spcified driver, there could be one .of_xlate_tdm_slot_mask() +to specify a explicit mapping of the channels and the slots. If it's absent +the default snd_soc_of_xlate_tdm_slot_mask() will be used to generating the +tx and rx masks. + +For snd_soc_of_xlate_tdm_slot_mask(), the tx and rx masks will use a 1 bit +for an active slot as default, and the default active bits are at the LSB of +the masks. diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt new file mode 100644 index 0000000..74c66de --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt @@ -0,0 +1,61 @@ +Texas Instruments - tlv320aic31xx Codec module + +The tlv320aic31xx serial control bus communicates through I2C protocols + +Required properties: + +- compatible - "string" - One of: + "ti,tlv320aic310x" - Generic TLV320AIC31xx with mono speaker amp + "ti,tlv320aic311x" - Generic TLV320AIC31xx with stereo speaker amp + "ti,tlv320aic3100" - TLV320AIC3100 (mono speaker amp, no MiniDSP) + "ti,tlv320aic3110" - TLV320AIC3110 (stereo speaker amp, no MiniDSP) + "ti,tlv320aic3120" - TLV320AIC3120 (mono speaker amp, MiniDSP) + "ti,tlv320aic3111" - TLV320AIC3111 (stereo speaker amp, MiniDSP) + +- reg - <int> - I2C slave address + + +Optional properties: + +- gpio-reset - gpio pin number used for codec reset +- ai31xx-micbias-vg - MicBias Voltage setting + 1 or MICBIAS_2_0V - MICBIAS output is powered to 2.0V + 2 or MICBIAS_2_5V - MICBIAS output is powered to 2.5V + 3 or MICBIAS_AVDD - MICBIAS output is connected to AVDD + If this node is not mentioned or if the value is unknown, then + micbias is set to 2.0V. +- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply, + DVDD-supply : power supplies for the device as covered in + Documentation/devicetree/bindings/regulator/regulator.txt + +CODEC output pins: + * HPL + * HPR + * SPL, devices with stereo speaker amp + * SPR, devices with stereo speaker amp + * SPK, devices with mono speaker amp + * MICBIAS + +CODEC input pins: + * MIC1LP + * MIC1RP + * MIC1LM + +The pins can be used in referring sound node's audio-routing property. + +Example: +#include <dt-bindings/sound/tlv320aic31xx-micbias.h> + +tlv320aic31xx: tlv320aic31xx@18 { + compatible = "ti,tlv320aic311x"; + reg = <0x18>; + + ai31xx-micbias-vg = <MICBIAS_OFF>; + + HPVDD-supply = <®ulator>; + SPRVDD-supply = <®ulator>; + SPLVDD-supply = <®ulator>; + AVDD-supply = <®ulator>; + IOVDD-supply = <®ulator>; + DVDD-supply = <®ulator>; +}; diff --git a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt new file mode 100644 index 0000000..5e2741a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt @@ -0,0 +1,30 @@ +Texas Instruments - tlv320aic32x4 Codec module + +The tlv320aic32x4 serial control bus communicates through I2C protocols + +Required properties: + - compatible: Should be "ti,tlv320aic32x4" + - reg: I2C slave address + - supply-*: Required supply regulators are: + "iov" - digital IO power supply + "ldoin" - LDO power supply + "dv" - Digital core power supply + "av" - Analog core power supply + If you supply ldoin, dv and av are optional. Otherwise they are required + See regulator/regulator.txt for more information about the detailed binding + format. + +Optional properties: + - reset-gpios: Reset-GPIO phandle with args as described in gpio/gpio.txt + - clocks/clock-names: Clock named 'mclk' for the master clock of the codec. + See clock/clock-bindings.txt for information about the detailed format. + + +Example: + +codec: tlv320aic32x4@18 { + compatible = "ti,tlv320aic32x4"; + reg = <0x18>; + clocks = <&clks 201>; + clock-names = "mclk"; +}; diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt index 9d8ea14..5e6040c 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt @@ -6,7 +6,6 @@ Required properties: - compatible - "string" - One of: "ti,tlv320aic3x" - Generic TLV320AIC3x device - "ti,tlv320aic32x4" - TLV320AIC32x4 "ti,tlv320aic33" - TLV320AIC33 "ti,tlv320aic3007" - TLV320AIC3007 "ti,tlv320aic3106" - TLV320AIC3106 diff --git a/Documentation/devicetree/bindings/sound/widgets.txt b/Documentation/devicetree/bindings/sound/widgets.txt new file mode 100644 index 0000000..b6de5ba --- /dev/null +++ b/Documentation/devicetree/bindings/sound/widgets.txt @@ -0,0 +1,20 @@ +Widgets: + +This mainly specifies audio off-codec DAPM widgets. + +Each entry is a pair of strings in DT: + + "template-wname", "user-supplied-wname" + +The "template-wname" being the template widget name and currently includes: +"Microphone", "Line", "Headphone" and "Speaker". + +The "user-supplied-wname" being the user specified widget name. + +For instance: + simple-audio-widgets = + "Microphone", "Microphone Jack", + "Line", "Line In Jack", + "Line", "Line Out Jack", + "Headphone", "Headphone Jack", + "Speaker", "Speaker External"; diff --git a/Documentation/devicetree/bindings/spi/efm32-spi.txt b/Documentation/devicetree/bindings/spi/efm32-spi.txt index a590ca5..8f081c9 100644 --- a/Documentation/devicetree/bindings/spi/efm32-spi.txt +++ b/Documentation/devicetree/bindings/spi/efm32-spi.txt @@ -3,24 +3,24 @@ Required properties: - #address-cells: see spi-bus.txt - #size-cells: see spi-bus.txt -- compatible: should be "efm32,spi" +- compatible: should be "energymicro,efm32-spi" - reg: Offset and length of the register set for the controller - interrupts: pair specifying rx and tx irq - clocks: phandle to the spi clock - cs-gpios: see spi-bus.txt -- location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values. +- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values. Example: spi1: spi@0x4000c400 { /* USART1 */ #address-cells = <1>; #size-cells = <0>; - compatible = "efm32,spi"; + compatible = "energymicro,efm32-spi"; reg = <0x4000c400 0x400>; interrupts = <15 16>; clocks = <&cmu 20>; cs-gpios = <&gpio 51 1>; // D3 - location = <1>; + efm32,location = <1>; status = "ok"; ks8851@0 { diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt new file mode 100644 index 0000000..b82a268 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt @@ -0,0 +1,85 @@ +Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI) + +The QUP core is an AHB slave that provides a common data path (an output FIFO +and an input FIFO) for serial peripheral interface (SPI) mini-core. + +SPI in master mode supports up to 50MHz, up to four chip selects, programmable +data path from 4 bits to 32 bits and numerous protocol variants. + +Required properties: +- compatible: Should contain "qcom,spi-qup-v2.1.1" or "qcom,spi-qup-v2.2.1" +- reg: Should contain base register location and length +- interrupts: Interrupt number used by this controller + +- clocks: Should contain the core clock and the AHB clock. +- clock-names: Should be "core" for the core clock and "iface" for the + AHB clock. + +- #address-cells: Number of cells required to define a chip select + address on the SPI bus. Should be set to 1. +- #size-cells: Should be zero. + +Optional properties: +- spi-max-frequency: Specifies maximum SPI clock frequency, + Units - Hz. Definition as per + Documentation/devicetree/bindings/spi/spi-bus.txt + +SPI slave nodes must be children of the SPI master node and can contain +properties described in Documentation/devicetree/bindings/spi/spi-bus.txt + +Example: + + spi_8: spi@f9964000 { /* BLSP2 QUP2 */ + + compatible = "qcom,spi-qup-v2"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xf9964000 0x1000>; + interrupts = <0 102 0>; + spi-max-frequency = <19200000>; + + clocks = <&gcc GCC_BLSP2_QUP2_SPI_APPS_CLK>, <&gcc GCC_BLSP2_AHB_CLK>; + clock-names = "core", "iface"; + + pinctrl-names = "default"; + pinctrl-0 = <&spi8_default>; + + device@0 { + compatible = "arm,pl022-dummy"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0>; /* Chip select 0 */ + spi-max-frequency = <19200000>; + spi-cpol; + }; + + device@1 { + compatible = "arm,pl022-dummy"; + #address-cells = <1>; + #size-cells = <1>; + reg = <1>; /* Chip select 1 */ + spi-max-frequency = <9600000>; + spi-cpha; + }; + + device@2 { + compatible = "arm,pl022-dummy"; + #address-cells = <1>; + #size-cells = <1>; + reg = <2>; /* Chip select 2 */ + spi-max-frequency = <19200000>; + spi-cpol; + spi-cpha; + }; + + device@3 { + compatible = "arm,pl022-dummy"; + #address-cells = <1>; + #size-cells = <1>; + reg = <3>; /* Chip select 3 */ + spi-max-frequency = <19200000>; + spi-cpol; + spi-cpha; + spi-cs-high; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/sh-hspi.txt b/Documentation/devicetree/bindings/spi/sh-hspi.txt index 30b57b1..319bad4 100644 --- a/Documentation/devicetree/bindings/spi/sh-hspi.txt +++ b/Documentation/devicetree/bindings/spi/sh-hspi.txt @@ -1,7 +1,29 @@ Renesas HSPI. Required properties: -- compatible : "renesas,hspi" -- reg : Offset and length of the register set for the device -- interrupts : interrupt line used by HSPI +- compatible : "renesas,hspi-<soctype>", "renesas,hspi" as fallback. + Examples with soctypes are: + - "renesas,hspi-r8a7778" (R-Car M1) + - "renesas,hspi-r8a7779" (R-Car H1) +- reg : Offset and length of the register set for the device +- interrupt-parent : The phandle for the interrupt controller that + services interrupts for this device +- interrupts : Interrupt specifier +- #address-cells : Must be <1> +- #size-cells : Must be <0> + +Pinctrl properties might be needed, too. See +Documentation/devicetree/bindings/pinctrl/renesas,*. + +Example: + + hspi0: spi@fffc7000 { + compatible = "renesas,hspi-r8a7778", "renesas,hspi"; + reg = <0xfffc7000 0x18>; + interrupt-parent = <&gic>; + interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt index e622210..f24baf3 100644 --- a/Documentation/devicetree/bindings/spi/sh-msiof.txt +++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt @@ -1,12 +1,40 @@ Renesas MSIOF spi controller Required properties: -- compatible : "renesas,sh-msiof" for SuperH or - "renesas,sh-mobile-msiof" for SH Mobile series -- reg : Offset and length of the register set for the device -- interrupts : interrupt line used by MSIOF +- compatible : "renesas,msiof-<soctype>" for SoCs, + "renesas,sh-msiof" for SuperH, or + "renesas,sh-mobile-msiof" for SH Mobile series. + Examples with soctypes are: + "renesas,msiof-r8a7790" (R-Car H2) + "renesas,msiof-r8a7791" (R-Car M2) +- reg : Offset and length of the register set for the device +- interrupt-parent : The phandle for the interrupt controller that + services interrupts for this device +- interrupts : Interrupt specifier +- #address-cells : Must be <1> +- #size-cells : Must be <0> Optional properties: -- num-cs : total number of chip-selects -- renesas,tx-fifo-size : Overrides the default tx fifo size given in words -- renesas,rx-fifo-size : Overrides the default rx fifo size given in words +- clocks : Must contain a reference to the functional clock. +- num-cs : Total number of chip-selects (default is 1) + +Optional properties, deprecated for soctype-specific bindings: +- renesas,tx-fifo-size : Overrides the default tx fifo size given in words + (default is 64) +- renesas,rx-fifo-size : Overrides the default rx fifo size given in words + (default is 64, or 256 on R-Car H2 and M2) + +Pinctrl properties might be needed, too. See +Documentation/devicetree/bindings/pinctrl/renesas,*. + +Example: + + msiof0: spi@e6e20000 { + compatible = "renesas,msiof-r8a7791"; + reg = <0 0xe6e20000 0 0x0064>; + interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>; + #address-cells = <1>; + #size-cells = <0>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt index a1fb303..5376de4 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt @@ -10,6 +10,7 @@ Required properties: - pinctrl-names: must contain a "default" entry. - spi-num-chipselects : the number of the chipselect signals. - bus-num : the slave chip chipselect signal number. +- big-endian : if DSPI modudle is big endian, the bool will be set in node. Example: dspi0@4002c000 { @@ -24,6 +25,7 @@ dspi0@4002c000 { bus-num = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_dspi0_1>; + big-endian; status = "okay"; sflash: at26df081a@0 { diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt new file mode 100644 index 0000000..d57d82a --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt @@ -0,0 +1,61 @@ +Device tree configuration for Renesas RSPI/QSPI driver + +Required properties: +- compatible : For Renesas Serial Peripheral Interface on legacy SH: + "renesas,rspi-<soctype>", "renesas,rspi" as fallback. + For Renesas Serial Peripheral Interface on RZ/A1H: + "renesas,rspi-<soctype>", "renesas,rspi-rz" as fallback. + For Quad Serial Peripheral Interface on R-Car Gen2: + "renesas,qspi-<soctype>", "renesas,qspi" as fallback. + Examples with soctypes are: + - "renesas,rspi-sh7757" (SH) + - "renesas,rspi-r7s72100" (RZ/A1H) + - "renesas,qspi-r8a7790" (R-Car H2) + - "renesas,qspi-r8a7791" (R-Car M2) +- reg : Address start and address range size of the device +- interrupts : A list of interrupt-specifiers, one for each entry in + interrupt-names. + If interrupt-names is not present, an interrupt specifier + for a single muxed interrupt. +- interrupt-names : A list of interrupt names. Should contain (if present): + - "error" for SPEI, + - "rx" for SPRI, + - "tx" to SPTI, + - "mux" for a single muxed interrupt. +- interrupt-parent : The phandle for the interrupt controller that + services interrupts for this device. +- num-cs : Number of chip selects. Some RSPI cores have more than 1. +- #address-cells : Must be <1> +- #size-cells : Must be <0> + +Optional properties: +- clocks : Must contain a reference to the functional clock. + +Pinctrl properties might be needed, too. See +Documentation/devicetree/bindings/pinctrl/renesas,*. + +Examples: + + spi0: spi@e800c800 { + compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz"; + reg = <0xe800c800 0x24>; + interrupts = <0 238 IRQ_TYPE_LEVEL_HIGH>, + <0 239 IRQ_TYPE_LEVEL_HIGH>, + <0 240 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "error", "rx", "tx"; + interrupt-parent = <&gic>; + num-cs = <1>; + #address-cells = <1>; + #size-cells = <0>; + }; + + spi: spi@e6b10000 { + compatible = "renesas,qspi-r8a7791", "renesas,qspi"; + reg = <0 0xe6b10000 0 0x2c>; + interrupt-parent = <&gic>; + interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp9_clks R8A7791_CLK_QSPI_MOD>; + num-cs = <1>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt b/Documentation/devicetree/bindings/spi/spi-sun4i.txt new file mode 100644 index 0000000..de827f5 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt @@ -0,0 +1,24 @@ +Allwinner A10 SPI controller + +Required properties: +- compatible: Should be "allwinner,sun4-a10-spi". +- reg: Should contain register location and length. +- interrupts: Should contain interrupt. +- clocks: phandle to the clocks feeding the SPI controller. Two are + needed: + - "ahb": the gated AHB parent clock + - "mod": the parent module clock +- clock-names: Must contain the clock names described just above + +Example: + +spi1: spi@01c06000 { + compatible = "allwinner,sun4i-a10-spi"; + reg = <0x01c06000 0x1000>; + interrupts = <11>; + clocks = <&ahb_gates 21>, <&spi1_clk>; + clock-names = "ahb", "mod"; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; +}; diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt b/Documentation/devicetree/bindings/spi/spi-sun6i.txt new file mode 100644 index 0000000..21de73d --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-sun6i.txt @@ -0,0 +1,24 @@ +Allwinner A31 SPI controller + +Required properties: +- compatible: Should be "allwinner,sun6i-a31-spi". +- reg: Should contain register location and length. +- interrupts: Should contain interrupt. +- clocks: phandle to the clocks feeding the SPI controller. Two are + needed: + - "ahb": the gated AHB parent clock + - "mod": the parent module clock +- clock-names: Must contain the clock names described just above +- resets: phandle to the reset controller asserting this device in + reset + +Example: + +spi1: spi@01c69000 { + compatible = "allwinner,sun6i-a31-spi"; + reg = <0x01c69000 0x1000>; + interrupts = <0 66 4>; + clocks = <&ahb1_gates 21>, <&spi1_clk>; + clock-names = "ahb", "mod"; + resets = <&ahb1_rst 21>; +}; diff --git a/Documentation/devicetree/bindings/spi/spi-xtensa-xtfpga.txt b/Documentation/devicetree/bindings/spi/spi-xtensa-xtfpga.txt new file mode 100644 index 0000000..b6ebe2b --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-xtensa-xtfpga.txt @@ -0,0 +1,9 @@ +Cadence Xtensa XTFPGA platform SPI controller. + +This simple SPI master controller is built into xtfpga bitstreams and is used +to control daughterboard audio codec. + +Required properties: +- compatible: should be "cdns,xtfpga-spi". +- reg: physical base address of the controller and length of memory mapped + region. diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt new file mode 100644 index 0000000..715d099 --- /dev/null +++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt @@ -0,0 +1,61 @@ +Qualcomm SPMI Controller (PMIC Arbiter) + +The SPMI PMIC Arbiter is found on the Snapdragon 800 Series. It is an SPMI +controller with wrapping arbitration logic to allow for multiple on-chip +devices to control a single SPMI master. + +The PMIC Arbiter can also act as an interrupt controller, providing interrupts +to slave devices. + +See spmi.txt for the generic SPMI controller binding requirements for child +nodes. + +See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for +generic interrupt controller binding documentation. + +Required properties: +- compatible : should be "qcom,spmi-pmic-arb". +- reg-names : must contain: + "core" - core registers + "intr" - interrupt controller registers + "cnfg" - configuration registers +- reg : address + size pairs describing the PMIC arb register sets; order must + correspond with the order of entries in reg-names +- #address-cells : must be set to 2 +- #size-cells : must be set to 0 +- qcom,ee : indicates the active Execution Environment identifier (0-5) +- qcom,channel : which of the PMIC Arb provided channels to use for accesses (0-5) +- interrupts : interrupt list for the PMIC Arb controller, must contain a + single interrupt entry for the peripheral interrupt +- interrupt-names : corresponding interrupt names for the interrupts + listed in the 'interrupts' property, must contain: + "periph_irq" - summary interrupt for PMIC peripherals +- interrupt-controller : boolean indicator that the PMIC arbiter is an interrupt controller +- #interrupt-cells : must be set to 4. Interrupts are specified as a 4-tuple: + cell 1: slave ID for the requested interrupt (0-15) + cell 2: peripheral ID for requested interrupt (0-255) + cell 3: the requested peripheral interrupt (0-7) + cell 4: interrupt flags indicating level-sense information, as defined in + dt-bindings/interrupt-controller/irq.h + +Example: + + spmi { + compatible = "qcom,spmi-pmic-arb"; + reg-names = "core", "intr", "cnfg"; + reg = <0xfc4cf000 0x1000>, + <0xfc4cb000 0x1000>, + <0xfc4ca000 0x1000>; + + interrupt-names = "periph_irq"; + interrupts = <0 190 0>; + + qcom,ee = <0>; + qcom,channel = <0>; + + #address-cells = <2>; + #size-cells = <0>; + + interrupt-controller; + #interrupt-cells = <4>; + }; diff --git a/Documentation/devicetree/bindings/spmi/spmi.txt b/Documentation/devicetree/bindings/spmi/spmi.txt new file mode 100644 index 0000000..462a42f --- /dev/null +++ b/Documentation/devicetree/bindings/spmi/spmi.txt @@ -0,0 +1,41 @@ +System Power Management Interface (SPMI) Controller + +This document defines a generic set of bindings for use by SPMI controllers. A +controller is modelled in device tree as a node with zero or more child nodes, +each representing a unique slave on the bus. + +Required properties: +- #address-cells : must be set to 2 +- #size-cells : must be set to 0 + +Child nodes: + +An SPMI controller node can contain zero or more child nodes representing slave +devices on the bus. Child 'reg' properties are specified as an address, type +pair. The address must be in the range 0-15 (4 bits). The type must be one of +SPMI_USID (0) or SPMI_GSID (1) for Unique Slave ID or Group Slave ID respectively. +These are the identifiers "statically assigned by the system integrator", as +per the SPMI spec. + +Each child node must have one and only one 'reg' entry of type SPMI_USID. + +#include <dt-bindings/spmi/spmi.h> + + spmi@.. { + compatible = "..."; + reg = <...>; + + #address-cells = <2>; + #size-cells <0>; + + child@0 { + compatible = "..."; + reg = <0 SPMI_USID>; + }; + + child@7 { + compatible = "..."; + reg = <7 SPMI_USID + 3 SPMI_GSID>; + }; + }; diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt index b876d49..3be5ce7 100644 --- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt +++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt @@ -1,3 +1,22 @@ +Freescale i.MX DRM master device +================================ + +The freescale i.MX DRM master device is a virtual device needed to list all +IPU or other display interface nodes that comprise the graphics subsystem. + +Required properties: +- compatible: Should be "fsl,imx-display-subsystem" +- ports: Should contain a list of phandles pointing to display interface ports + of IPU devices + +example: + +display-subsystem { + compatible = "fsl,display-subsystem"; + ports = <&ipu_di0>; +}; + + Freescale i.MX IPUv3 ==================== @@ -7,18 +26,31 @@ Required properties: datasheet - interrupts: Should contain sync interrupt and error interrupt, in this order. -- #crtc-cells: 1, See below - resets: phandle pointing to the system reset controller and reset line index, see reset/fsl,imx-src.txt for details +Optional properties: +- port@[0-3]: Port nodes with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + Ports 0 and 1 should correspond to CSI0 and CSI1, + ports 2 and 3 should correspond to DI0 and DI1, respectively. example: ipu: ipu@18000000 { - #crtc-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; compatible = "fsl,imx53-ipu"; reg = <0x18000000 0x080000000>; interrupts = <11 10>; resets = <&src 2>; + + ipu_di0: port@2 { + reg = <2>; + + ipu_di0_disp0: endpoint { + remote-endpoint = <&display_in>; + }; + }; }; Parallel display support @@ -26,19 +58,25 @@ Parallel display support Required properties: - compatible: Should be "fsl,imx-parallel-display" -- crtc: the crtc this display is connected to, see below Optional properties: - interface_pix_fmt: How this display is connected to the - crtc. Currently supported types: "rgb24", "rgb565", "bgr666" + display interface. Currently supported types: "rgb24", "rgb565", "bgr666" - edid: verbatim EDID data block describing attached display. - ddc: phandle describing the i2c bus handling the display data channel +- port: A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. example: display@di0 { compatible = "fsl,imx-parallel-display"; edid = [edid-data]; - crtc = <&ipu 0>; interface-pix-fmt = "rgb24"; + + port { + display_in: endpoint { + remote-endpoint = <&ipu_di0_disp0>; + }; + }; }; diff --git a/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt new file mode 100644 index 0000000..1b756cf --- /dev/null +++ b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt @@ -0,0 +1,58 @@ +Device-Tree bindings for HDMI Transmitter + +HDMI Transmitter +================ + +The HDMI Transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with accompanying PHY IP. + +Required properties: + - #address-cells : should be <1> + - #size-cells : should be <0> + - compatible : should be "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi". + - gpr : should be <&gpr>. + The phandle points to the iomuxc-gpr region containing the HDMI + multiplexer control register. + - clocks, clock-names : phandles to the HDMI iahb and isrf clocks, as described + in Documentation/devicetree/bindings/clock/clock-bindings.txt and + Documentation/devicetree/bindings/clock/imx6q-clock.txt. + - port@[0-4]: Up to four port nodes with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt, + corresponding to the four inputs to the HDMI multiplexer. + +Optional properties: + - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + +example: + + gpr: iomuxc-gpr@020e0000 { + /* ... */ + }; + + hdmi: hdmi@0120000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx6q-hdmi"; + reg = <0x00120000 0x9000>; + interrupts = <0 115 0x04>; + gpr = <&gpr>; + clocks = <&clks 123>, <&clks 124>; + clock-names = "iahb", "isfr"; + ddc-i2c-bus = <&i2c2>; + + port@0 { + reg = <0>; + + hdmi_mux_0: endpoint { + remote-endpoint = <&ipu1_di0_hdmi>; + }; + }; + + port@1 { + reg = <1>; + + hdmi_mux_1: endpoint { + remote-endpoint = <&ipu1_di1_hdmi>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt index ed93778..578a1fc 100644 --- a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt +++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt @@ -50,12 +50,14 @@ have a look at Documentation/devicetree/bindings/video/display-timing.txt. Required properties: - reg : should be <0> or <1> - - crtcs : a list of phandles with index pointing to the IPU display interfaces - that can be used as video source for this channel. - fsl,data-mapping : should be "spwg" or "jeida" This describes how the color bits are laid out in the serialized LVDS signal. - fsl,data-width : should be <18> or <24> + - port: A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + On i.MX6, there should be four ports (port@[0-3]) that correspond + to the four LVDS multiplexer inputs. example: @@ -77,23 +79,33 @@ ldb: ldb@53fa8008 { lvds-channel@0 { reg = <0>; - crtcs = <&ipu 0>; fsl,data-mapping = "spwg"; fsl,data-width = <24>; display-timings { /* ... */ }; + + port { + lvds0_in: endpoint { + remote-endpoint = <&ipu_di0_lvds0>; + }; + }; }; lvds-channel@1 { reg = <1>; - crtcs = <&ipu 1>; fsl,data-mapping = "spwg"; fsl,data-width = <24>; display-timings { /* ... */ }; + + port { + lvds1_in: endpoint { + remote-endpoint = <&ipu_di1_lvds1>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt index 48aeb78..5c2e235 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt @@ -2,7 +2,7 @@ Allwinner A1X SoCs Timer Controller Required properties: -- compatible : should be "allwinner,sun4i-timer" +- compatible : should be "allwinner,sun4i-a10-timer" - reg : Specifies base physical address and size of the registers. - interrupts : The interrupt of the first timer - clocks: phandle to the source clock (usually a 24 MHz fixed clock) @@ -10,7 +10,7 @@ Required properties: Example: timer { - compatible = "allwinner,sun4i-timer"; + compatible = "allwinner,sun4i-a10-timer"; reg = <0x01c20c00 0x400>; interrupts = <22>; clocks = <&osc>; diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt new file mode 100644 index 0000000..5fbe361 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt @@ -0,0 +1,29 @@ +* Device tree bindings for Texas instruments Keystone timer + +This document provides bindings for the 64-bit timer in the KeyStone +architecture devices. The timer can be configured as a general-purpose 64-bit +timer, dual general-purpose 32-bit timers. When configured as dual 32-bit +timers, each half can operate in conjunction (chain mode) or independently +(unchained mode) of each other. + +It is global timer is a free running up-counter and can generate interrupt +when the counter reaches preset counter values. + +Documentation: +http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf + +Required properties: + +- compatible : should be "ti,keystone-timer". +- reg : specifies base physical address and count of the registers. +- interrupts : interrupt generated by the timer. +- clocks : the clock feeding the timer clock. + +Example: + +timer@22f0000 { + compatible = "ti,keystone-timer"; + reg = <0x022f0000 0x80>; + interrupts = <GIC_SPI 110 IRQ_TYPE_EDGE_RISING>; + clocks = <&clktimer15>; +}; diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt index b4b5b79..a6a32cb 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt @@ -18,6 +18,7 @@ Optional properties: - vbus-supply: regulator for vbus - disable-over-current: disable over current detect - external-vbus-divider: enables off-chip resistor divider for Vbus +- maximum-speed: limit the maximum connection speed to "full-speed". Examples: usb@02184000 { /* USB OTG */ @@ -28,4 +29,5 @@ usb@02184000 { /* USB OTG */ fsl,usbmisc = <&usbmisc 0>; disable-over-current; external-vbus-divider; + maximum-speed = "full-speed"; }; diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt new file mode 100644 index 0000000..abbcb2a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt @@ -0,0 +1,17 @@ +* LSI Zevio USB OTG Controller + +Required properties: +- compatible: Should be "lsi,zevio-usb" +- reg: Should contain registers location and length +- interrupts: Should contain controller interrupt + +Optional properties: +- vbus-supply: regulator for vbus + +Examples: + usb0: usb@b0000000 { + reg = <0xb0000000 0x1000>; + compatible = "lsi,zevio-usb"; + interrupts = <8>; + vbus-supply = <&vbus_reg>; + }; diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index e807635..471366d 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -6,11 +6,13 @@ Required properties: - compatible: must be "snps,dwc3" - reg : Address and length of the register set for the device - interrupts: Interrupts used by the dwc3 controller. + +Optional properties: - usb-phy : array of phandle for the PHY device. The first element in the array is expected to be a handle to the USB2/HS PHY and the second element is expected to be a handle to the USB3/SS PHY - -Optional properties: + - phys: from the *Generic PHY* bindings + - phy-names: from the *Generic PHY* bindings - tx-fifo-resize: determines if the FIFO *has* to be reallocated. This is usually a subnode to DWC3 glue to which it is connected. diff --git a/Documentation/devicetree/bindings/usb/fsl-usb.txt b/Documentation/devicetree/bindings/usb/fsl-usb.txt index bd5723f..4779c02 100644 --- a/Documentation/devicetree/bindings/usb/fsl-usb.txt +++ b/Documentation/devicetree/bindings/usb/fsl-usb.txt @@ -8,7 +8,9 @@ and additions : Required properties : - compatible : Should be "fsl-usb2-mph" for multi port host USB controllers, or "fsl-usb2-dr" for dual role USB controllers - or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121 + or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121. + Wherever applicable, the IP version of the USB controller should + also be mentioned (for eg. fsl-usb2-dr-v2.2 for bsc9132). - phy_type : For multi port host USB controllers, should be one of "ulpi", or "serial". For dual role USB controllers, should be one of "ulpi", "utmi", "utmi_wide", or "serial". diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt b/Documentation/devicetree/bindings/usb/mxs-phy.txt index 5835b27..cef181a 100644 --- a/Documentation/devicetree/bindings/usb/mxs-phy.txt +++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt @@ -1,13 +1,19 @@ * Freescale MXS USB Phy Device Required properties: -- compatible: Should be "fsl,imx23-usbphy" +- compatible: should contain: + * "fsl,imx23-usbphy" for imx23 and imx28 + * "fsl,imx6q-usbphy" for imx6dq and imx6dl + * "fsl,imx6sl-usbphy" for imx6sl + "fsl,imx23-usbphy" is still a fallback for other strings - reg: Should contain registers location and length - interrupts: Should contain phy interrupt +- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series Example: usbphy1: usbphy@020c9000 { compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy"; reg = <0x020c9000 0x1000>; interrupts = <0 44 0x04>; + fsl,anatop = <&anatop>; }; diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index c495135..38b2fae 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -76,27 +76,3 @@ omap_dwc3 { ranges; }; -OMAP CONTROL USB - -Required properties: - - compatible: Should be one of - "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4. - "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register - e.g. USB2_PHY on OMAP5. - "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control - e.g. USB3 PHY and SATA PHY on OMAP5. - "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on - DRA7 platform. - "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on - AM437 platform. - - reg : Address and length of the register set for the device. It contains - the address of "otghs_control" for control-phy-otghs or "power" register - for other types. - - reg-names: should be "otghs_control" control-phy-otghs and "power" for - other types. - -omap_control_usb: omap-control-usb@4a002300 { - compatible = "ti,control-phy-otghs"; - reg = <0x4a00233c 0x4>; - reg-names = "otghs_control"; -}; diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index fa18612..ff151ec 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -1,19 +1,20 @@ USB EHCI controllers Required properties: - - compatible : should be "usb-ehci". + - compatible : should be "generic-ehci". - reg : should contain at least address and length of the standard EHCI register set for the device. Optional platform-dependent registers (debug-port or other) can be also specified here, but only after definition of standard EHCI registers. - interrupts : one EHCI interrupt should be described here. -If device registers are implemented in big endian mode, the device -node should have "big-endian-regs" property. -If controller implementation operates with big endian descriptors, -"big-endian-desc" property should be specified. -If both big endian registers and descriptors are used by the controller -implementation, "big-endian" property can be specified instead of having -both "big-endian-regs" and "big-endian-desc". + +Optional properties: + - big-endian-regs : boolean, set this for hcds with big-endian registers + - big-endian-desc : boolean, set this for hcds with big-endian descriptors + - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc + - clocks : a list of phandle + clock specifier pairs + - phys : phandle + phy specifier pair + - phy-names : "usb" Example (Sequoia 440EPx): ehci@e0000300 { @@ -23,3 +24,13 @@ Example (Sequoia 440EPx): reg = <0 e0000300 90 0 e0000390 70>; big-endian; }; + +Example (Allwinner sun4i A10 SoC): + ehci0: usb@01c14000 { + compatible = "allwinner,sun4i-a10-ehci", "generic-ehci"; + reg = <0x01c14000 0x100>; + interrupts = <39>; + clocks = <&ahb_gates 1>; + phys = <&usbphy 1>; + phy-names = "usb"; + }; diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt new file mode 100644 index 0000000..45f67d9 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt @@ -0,0 +1,25 @@ +USB OHCI controllers + +Required properties: +- compatible : "generic-ohci" +- reg : ohci controller register range (address and length) +- interrupts : ohci controller interrupt + +Optional properties: +- big-endian-regs : boolean, set this for hcds with big-endian registers +- big-endian-desc : boolean, set this for hcds with big-endian descriptors +- big-endian : boolean, for hcds with big-endian-regs + big-endian-desc +- clocks : a list of phandle + clock specifier pairs +- phys : phandle + phy specifier pair +- phy-names : "usb" + +Example: + + ohci0: usb@01c14400 { + compatible = "allwinner,sun4i-a10-ohci", "generic-ohci"; + reg = <0x01c14400 0x100>; + interrupts = <64>; + clocks = <&usb_clk 6>, <&ahb_gates 2>; + phys = <&usbphy 1>; + phy-names = "usb"; + }; diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt deleted file mode 100644 index c0245c8..0000000 --- a/Documentation/devicetree/bindings/usb/usb-phy.txt +++ /dev/null @@ -1,48 +0,0 @@ -USB PHY - -OMAP USB2 PHY - -Required properties: - - compatible: Should be "ti,omap-usb2" - - reg : Address and length of the register set for the device. - - #phy-cells: determine the number of cells that should be given in the - phandle while referencing this phy. - -Optional properties: - - ctrl-module : phandle of the control module used by PHY driver to power on - the PHY. - -This is usually a subnode of ocp2scp to which it is connected. - -usb2phy@4a0ad080 { - compatible = "ti,omap-usb2"; - reg = <0x4a0ad080 0x58>; - ctrl-module = <&omap_control_usb>; - #phy-cells = <0>; -}; - -OMAP USB3 PHY - -Required properties: - - compatible: Should be "ti,omap-usb3" - - reg : Address and length of the register set for the device. - - reg-names: The names of the register addresses corresponding to the registers - filled in "reg". - - #phy-cells: determine the number of cells that should be given in the - phandle while referencing this phy. - -Optional properties: - - ctrl-module : phandle of the control module used by PHY driver to power on - the PHY. - -This is usually a subnode of ocp2scp to which it is connected. - -usb3phy@4a084400 { - compatible = "ti,omap-usb3"; - reg = <0x4a084400 0x80>, - <0x4a084800 0x64>, - <0x4a084c00 0x40>; - reg-names = "phy_rx", "phy_tx", "pll_ctrl"; - ctrl-module = <&omap_control_usb>; - #phy-cells = <0>; -}; diff --git a/Documentation/devicetree/bindings/usb/platform-uhci.txt b/Documentation/devicetree/bindings/usb/usb-uhci.txt index a4fb071..2981334 100644 --- a/Documentation/devicetree/bindings/usb/platform-uhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-uhci.txt @@ -2,14 +2,14 @@ Generic Platform UHCI Controller ----------------------------------------------------- Required properties: -- compatible : "platform-uhci" +- compatible : "generic-uhci" (deprecated: "platform-uhci") - reg : Should contain 1 register ranges(address and length) - interrupts : UHCI controller interrupt Example: uhci@d8007b00 { - compatible = "platform-uhci"; + compatible = "generic-uhci"; reg = <0xd8007b00 0x200>; interrupts = <43>; }; diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 5752df0..90f8f60 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -1,14 +1,14 @@ USB xHCI controllers Required properties: - - compatible: should be "xhci-platform". + - compatible: should be "generic-xhci" (deprecated: "xhci-platform"). - reg: should contain address and length of the standard XHCI register set for the device. - interrupts: one XHCI interrupt should be described here. Example: usb@f0931000 { - compatible = "xhci-platform"; + compatible = "generic-xhci"; reg = <0xf0931000 0x8c8>; interrupts = <0x0 0x4e 0x0>; }; diff --git a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt b/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt deleted file mode 100644 index 17b3ad1..0000000 --- a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt +++ /dev/null @@ -1,15 +0,0 @@ -VIA/Wondermedia VT8500 EHCI Controller ------------------------------------------------------ - -Required properties: -- compatible : "via,vt8500-ehci" -- reg : Should contain 1 register ranges(address and length) -- interrupts : ehci controller interrupt - -Example: - - ehci@d8007900 { - compatible = "via,vt8500-ehci"; - reg = <0xd8007900 0x200>; - interrupts = <43>; - }; diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt deleted file mode 100644 index 5fb8fd6..0000000 --- a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt +++ /dev/null @@ -1,12 +0,0 @@ -VIA VT8500 and Wondermedia WM8xxx SoC USB controllers. - -Required properties: - - compatible: Should be "via,vt8500-ehci" or "wm,prizm-ehci". - - reg: Address range of the ehci registers. size should be 0x200 - - interrupts: Should contain the ehci interrupt. - -usb: ehci@D8007100 { - compatible = "wm,prizm-ehci", "usb-ehci"; - reg = <0xD8007100 0x200>; - interrupts = <1>; -}; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 40ce2df..95465d5 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -3,6 +3,7 @@ Device tree binding vendor prefix registry. Keep list in alphabetical order. This isn't an exhaustive list, but you should add new prefixes to it before using them to avoid name-space collisions. +abilis Abilis Systems active-semi Active-Semi International Inc ad Avionic Design GmbH adi Analog Devices, Inc. @@ -11,14 +12,17 @@ ak Asahi Kasei Corp. allwinner Allwinner Technology Co., Ltd. altr Altera Corp. amcc Applied Micro Circuits Corporation (APM, formally AMCC) +amd Advanced Micro Devices (AMD), Inc. amstaos AMS-Taos Inc. apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. +armadeus ARMadeus Systems SARL atmel Atmel Corporation auo AU Optronics Corporation avago Avago Technologies bosch Bosch Sensortec GmbH brcm Broadcom Corporation +calxeda Calxeda capella Capella Microsystems, Inc cavium Cavium, Inc. cdns Cadence Design Systems Inc. @@ -26,8 +30,10 @@ chrp Common Hardware Reference Platform chunghwa Chunghwa Picture Tubes Ltd. cirrus Cirrus Logic, Inc. cortina Cortina Systems, Inc. +crystalfontz Crystalfontz America, Inc. dallas Maxim Integrated Products (formerly Dallas Semiconductor) davicom DAVICOM Semiconductor, Inc. +dlink D-Link Systems, Inc. denx Denx Software Engineering edt Emerging Display Technologies emmicro EM Microelectronic @@ -37,7 +43,9 @@ est ESTeem Wireless Modems fsl Freescale Semiconductor GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. +globalscale Globalscale Technologies, Inc. gmt Global Mixed-mode Technology, Inc. +google Google, Inc. gumstix Gumstix, Inc. haoyu Haoyu Microelectronic Co. Ltd. hisilicon Hisilicon Limited. @@ -46,9 +54,12 @@ hp Hewlett Packard ibm International Business Machines (IBM) idt Integrated Device Technologies, Inc. img Imagination Technologies Ltd. +intel Intel Corporation intercontrol Inter Control Group isl Intersil karo Ka-Ro electronics GmbH +lacie LaCie +lantiq Lantiq Semiconductor lg LG Corporation linux Linux-specific binding lsi LSI Corp. (LSI Logic) @@ -56,12 +67,16 @@ marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products microchip Microchip Technology Inc. mosaixtech Mosaix Technologies, Inc. +moxa Moxa national National Semiconductor neonode Neonode Inc. +netgear NETGEAR nintendo Nintendo +nokia Nokia nvidia NVIDIA nxp NXP Semiconductors onnn ON Semiconductor Corp. +opencores OpenCores.org panasonic Panasonic Corporation phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd @@ -80,6 +95,7 @@ sil Silicon Image silabs Silicon Laboratories simtek sirf SiRF Technology, Inc. +smsc Standard Microsystems Corporation snps Synopsys, Inc. spansion Spansion Inc. st STMicroelectronics @@ -94,4 +110,5 @@ via VIA Technologies, Inc. winbond Winbond Electronics corp. wlf Wolfson Microelectronics wm Wondermedia Technologies, Inc. +xes Extreme Engineering Solutions (X-ES) xlnx Xilinx diff --git a/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt b/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt new file mode 100644 index 0000000..6d63782 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt @@ -0,0 +1,23 @@ +Xilinx AXI/PLB soft-core watchdog Device Tree Bindings +--------------------------------------------------------- + +Required properties: +- compatible : Should be "xlnx,xps-timebase-wdt-1.00.a" or + "xlnx,xps-timebase-wdt-1.01.a". +- reg : Physical base address and size + +Optional properties: +- clock-frequency : Frequency of clock in Hz +- xlnx,wdt-enable-once : 0 - Watchdog can be restarted + 1 - Watchdog can be enabled just once +- xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles, + <val> is integer from 8 to 31. + +Example: +axi-timebase-wdt@40100000 { + clock-frequency = <50000000>; + compatible = "xlnx,xps-timebase-wdt-1.00.a"; + reg = <0x40100000 0x10000>; + xlnx,wdt-enable-once = <0x0>; + xlnx,wdt-interval = <0x1b>; +} ; diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt index e39cb26..b8f75c5 100644 --- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt @@ -2,13 +2,13 @@ Allwinner SoCs Watchdog timer Required properties: -- compatible : should be "allwinner,<soc-family>-wdt", the currently supported - SoC families being sun4i and sun6i +- compatible : should be either "allwinner,sun4i-a10-wdt" or + "allwinner,sun6i-a31-wdt" - reg : Specifies base physical address and size of the registers. Example: wdt: watchdog@01c20c90 { - compatible = "allwinner,sun4i-wdt"; + compatible = "allwinner,sun4i-a10-wdt"; reg = <0x01c20c90 0x10>; }; diff --git a/Documentation/filesystems/autofs4-mount-control.txt b/Documentation/filesystems/autofs4-mount-control.txt index 4c95935..aff2211 100644 --- a/Documentation/filesystems/autofs4-mount-control.txt +++ b/Documentation/filesystems/autofs4-mount-control.txt @@ -255,7 +255,7 @@ AUTOFS_DEV_IOCTL_OPENMOUNT and AUTOFS_DEV_IOCTL_CLOSEMOUNT Obtain and release a file descriptor for an autofs managed mount point path. The open call requires an initialized struct autofs_dev_ioctl with -the the path field set and the size field adjusted appropriately as well +the path field set and the size field adjusted appropriately as well as the arg1 field set to the device number of the autofs mount. The device number can be obtained from the mount options shown in /proc/mounts. The close call requires an initialized struct diff --git a/Documentation/filesystems/hfsplus.txt b/Documentation/filesystems/hfsplus.txt index af1628a..59f7569 100644 --- a/Documentation/filesystems/hfsplus.txt +++ b/Documentation/filesystems/hfsplus.txt @@ -56,4 +56,4 @@ References kernel source: <file:fs/hfsplus> -Apple Technote 1150 http://developer.apple.com/technotes/tn/tn1150.html +Apple Technote 1150 https://developer.apple.com/legacy/library/technotes/tn/tn1150.html diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt index 44a3bc6..e0a9712 100644 --- a/Documentation/fmc/fmc-write-eeprom.txt +++ b/Documentation/fmc/fmc-write-eeprom.txt @@ -9,7 +9,12 @@ Overwriting the EEPROM is not something you should do daily, and it is expected to only happen during manufacturing. For this reason, the module makes it unlikely for the random user to change a working EEPROM. -The module takes the following measures: +However, since the EEPROM may include application-specific information +other than the identification, later versions of this packages added +write-support through sysfs. See *note Accessing the EEPROM::. + +To avoid damaging the EEPROM content, the module takes the following +measures: * It accepts a `file=' argument (within /lib/firmware) and if no such argument is received, it doesn't write anything to EEPROM @@ -70,56 +75,24 @@ first time. [ 132.899872] fake-fmc: Product name: FmcDelay1ns4cha -Writing to the EEPROM +Accessing the EEPROM ===================== -Once you have created a binary file for your EEPROM, you can write it -to the storage medium using the fmc-write-eeprom (See *note -fmc-write-eeprom::, while relying on a carrier driver. The procedure -here shown here uses the SPEC driver -(`http://www.ohwr.org/projects/spec-sw'). - -The example assumes no driver is already loaded (actually, I unloaded -them by hand as everything loads automatically at boot time after you -installed the modules), and shows kernel messages together with -commands. Here the prompt is spusa.root# and two SPEC cards are plugged -in the system. - - spusa.root# insmod fmc.ko - spusa.root# insmod spec.ko - [13972.382818] spec 0000:02:00.0: probe for device 0002:0000 - [13972.392773] spec 0000:02:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes - [13972.591388] spec 0000:02:00.0: FPGA programming successful - [13972.883011] spec 0000:02:00.0: EEPROM has no FRU information - [13972.888719] spec 0000:02:00.0: No device_id filled, using index - [13972.894676] spec 0000:02:00.0: No mezzanine_name found - [13972.899863] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init - [13972.906578] spec 0000:04:00.0: probe for device 0004:0000 - [13972.916509] spec 0000:04:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes - [13973.115096] spec 0000:04:00.0: FPGA programming successful - [13973.401798] spec 0000:04:00.0: EEPROM has no FRU information - [13973.407474] spec 0000:04:00.0: No device_id filled, using index - [13973.413417] spec 0000:04:00.0: No mezzanine_name found - [13973.418600] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init - spusa.root# ls /sys/bus/fmc/devices - fmc-0000 fmc-0001 - spusa.root# insmod fmc-write-eeprom.ko busid=0x0200 file=fdelay-eeprom.bin - [14103.966259] spec 0000:02:00.0: Matching an generic driver (no ID) - [14103.975519] spec 0000:02:00.0: programming 6155 bytes - [14126.373762] spec 0000:02:00.0: write_eeprom: success - [14126.378770] spec 0000:04:00.0: Matching an generic driver (no ID) - [14126.384903] spec 0000:04:00.0: fmc_write_eeprom: no filename given: not programming - [14126.392600] fmc_write_eeprom: probe of fmc-0001 failed with error -2 - -Reading back the EEPROM -======================= - -In order to read back the binary content of the EEPROM of your -mezzanine device, the bus creates a read-only sysfs file called eeprom -for each mezzanine it knows about: - - spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom - -r--r--r-- 1 root root 8192 Apr 9 16:53 FmcDelay1ns4cha-f001/eeprom - -r--r--r-- 1 root root 8192 Apr 9 17:19 fake-design-for-testing-f002/eeprom - -r--r--r-- 1 root root 8192 Apr 9 17:19 fake-design-for-testing-f003/eeprom - -r--r--r-- 1 root root 8192 Apr 9 17:19 fmc-f004/eeprom +The bus creates a sysfs binary file called eeprom for each mezzanine it +knows about: + + spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom + -r--r--r-- 1 root root 8192 Feb 21 12:30 FmcAdc100m14b4cha-0800/eeprom + -r--r--r-- 1 root root 8192 Feb 21 12:30 FmcDelay1ns4cha-0200/eeprom + -r--r--r-- 1 root root 8192 Feb 21 12:30 FmcDio5cha-0400/eeprom + +Everybody can read the files and the superuser can also modify it, but +the operation may on the carrier driver, if the carrier is unable to +access the I2C bus. For example, the spec driver can access the bus +only with its golden gateware: after a mezzanine driver reprogrammed +the FPGA with a custom circuit, the carrier is unable to access the +EEPROM and returns ENOTSUPP. + +An alternative way to write the EEPROM is the mezzanine driver +fmc-write-eeprom (See *note fmc-write-eeprom::), but the procedure is +more complex. diff --git a/Documentation/futex-requeue-pi.txt b/Documentation/futex-requeue-pi.txt index 9dc1ff4..31b1661 100644 --- a/Documentation/futex-requeue-pi.txt +++ b/Documentation/futex-requeue-pi.txt @@ -67,7 +67,7 @@ pthread_cond_wait_pi(cond, mutex) lock(cond->__data.__lock); } while(...) unlock(cond->__data.__lock); - /* the kernel acquired the the mutex for us */ + /* the kernel acquired the mutex for us */ } pthread_cond_broadcast_pi(cond) diff --git a/Documentation/hid/hid-transport.txt b/Documentation/hid/hid-transport.txt new file mode 100644 index 0000000..3dcba9f --- /dev/null +++ b/Documentation/hid/hid-transport.txt @@ -0,0 +1,317 @@ + HID I/O Transport Drivers + =========================== + +The HID subsystem is independent of the underlying transport driver. Initially, +only USB was supported, but other specifications adopted the HID design and +provided new transport drivers. The kernel includes at least support for USB, +Bluetooth, I2C and user-space I/O drivers. + +1) HID Bus +========== + +The HID subsystem is designed as a bus. Any I/O subsystem may provide HID +devices and register them with the HID bus. HID core then loads generic device +drivers on top of it. The transport drivers are responsible of raw data +transport and device setup/management. HID core is responsible of +report-parsing, report interpretation and the user-space API. Device specifics +and quirks are handled by all layers depending on the quirk. + + +-----------+ +-----------+ +-----------+ +-----------+ + | Device #1 | | Device #i | | Device #j | | Device #k | + +-----------+ +-----------+ +-----------+ +-----------+ + \\ // \\ // + +------------+ +------------+ + | I/O Driver | | I/O Driver | + +------------+ +------------+ + || || + +------------------+ +------------------+ + | Transport Driver | | Transport Driver | + +------------------+ +------------------+ + \___ ___/ + \ / + +----------------+ + | HID Core | + +----------------+ + / | | \ + / | | \ + ____________/ | | \_________________ + / | | \ + / | | \ + +----------------+ +-----------+ +------------------+ +------------------+ + | Generic Driver | | MT Driver | | Custom Driver #1 | | Custom Driver #2 | + +----------------+ +-----------+ +------------------+ +------------------+ + +Example Drivers: + I/O: USB, I2C, Bluetooth-l2cap + Transport: USB-HID, I2C-HID, BT-HIDP + +Everything below "HID Core" is simplified in this graph as it is only of +interest to HID device drivers. Transport drivers do not need to know the +specifics. + +1.1) Device Setup +----------------- + +I/O drivers normally provide hotplug detection or device enumeration APIs to the +transport drivers. Transport drivers use this to find any suitable HID device. +They allocate HID device objects and register them with HID core. Transport +drivers are not required to register themselves with HID core. HID core is never +aware of which transport drivers are available and is not interested in it. It +is only interested in devices. + +Transport drivers attach a constant "struct hid_ll_driver" object with each +device. Once a device is registered with HID core, the callbacks provided via +this struct are used by HID core to communicate with the device. + +Transport drivers are responsible of detecting device failures and unplugging. +HID core will operate a device as long as it is registered regardless of any +device failures. Once transport drivers detect unplug or failure events, they +must unregister the device from HID core and HID core will stop using the +provided callbacks. + +1.2) Transport Driver Requirements +---------------------------------- + +The terms "asynchronous" and "synchronous" in this document describe the +transmission behavior regarding acknowledgements. An asynchronous channel must +not perform any synchronous operations like waiting for acknowledgements or +verifications. Generally, HID calls operating on asynchronous channels must be +running in atomic-context just fine. +On the other hand, synchronous channels can be implemented by the transport +driver in whatever way they like. They might just be the same as asynchronous +channels, but they can also provide acknowledgement reports, automatic +retransmission on failure, etc. in a blocking manner. If such functionality is +required on asynchronous channels, a transport-driver must implement that via +its own worker threads. + +HID core requires transport drivers to follow a given design. A Transport +driver must provide two bi-directional I/O channels to each HID device. These +channels must not necessarily be bi-directional in the hardware itself. A +transport driver might just provide 4 uni-directional channels. Or it might +multiplex all four on a single physical channel. However, in this document we +will describe them as two bi-directional channels as they have several +properties in common. + + - Interrupt Channel (intr): The intr channel is used for asynchronous data + reports. No management commands or data acknowledgements are sent on this + channel. Any unrequested incoming or outgoing data report must be sent on + this channel and is never acknowledged by the remote side. Devices usually + send their input events on this channel. Outgoing events are normally + not send via intr, except if high throughput is required. + - Control Channel (ctrl): The ctrl channel is used for synchronous requests and + device management. Unrequested data input events must not be sent on this + channel and are normally ignored. Instead, devices only send management + events or answers to host requests on this channel. + The control-channel is used for direct blocking queries to the device + independent of any events on the intr-channel. + Outgoing reports are usually sent on the ctrl channel via synchronous + SET_REPORT requests. + +Communication between devices and HID core is mostly done via HID reports. A +report can be of one of three types: + + - INPUT Report: Input reports provide data from device to host. This + data may include button events, axis events, battery status or more. This + data is generated by the device and sent to the host with or without + requiring explicit requests. Devices can choose to send data continuously or + only on change. + - OUTPUT Report: Output reports change device states. They are sent from host + to device and may include LED requests, rumble requests or more. Output + reports are never sent from device to host, but a host can retrieve their + current state. + Hosts may choose to send output reports either continuously or only on + change. + - FEATURE Report: Feature reports are used for specific static device features + and never reported spontaneously. A host can read and/or write them to access + data like battery-state or device-settings. + Feature reports are never sent without requests. A host must explicitly set + or retrieve a feature report. This also means, feature reports are never sent + on the intr channel as this channel is asynchronous. + +INPUT and OUTPUT reports can be sent as pure data reports on the intr channel. +For INPUT reports this is the usual operational mode. But for OUTPUT reports, +this is rarely done as OUTPUT reports are normally quite scarce. But devices are +free to make excessive use of asynchronous OUTPUT reports (for instance, custom +HID audio speakers make great use of it). + +Plain reports must not be sent on the ctrl channel, though. Instead, the ctrl +channel provides synchronous GET/SET_REPORT requests. Plain reports are only +allowed on the intr channel and are the only means of data there. + + - GET_REPORT: A GET_REPORT request has a report ID as payload and is sent + from host to device. The device must answer with a data report for the + requested report ID on the ctrl channel as a synchronous acknowledgement. + Only one GET_REPORT request can be pending for each device. This restriction + is enforced by HID core as several transport drivers don't allow multiple + simultaneous GET_REPORT requests. + Note that data reports which are sent as answer to a GET_REPORT request are + not handled as generic device events. That is, if a device does not operate + in continuous data reporting mode, an answer to GET_REPORT does not replace + the raw data report on the intr channel on state change. + GET_REPORT is only used by custom HID device drivers to query device state. + Normally, HID core caches any device state so this request is not necessary + on devices that follow the HID specs except during device initialization to + retrieve the current state. + GET_REPORT requests can be sent for any of the 3 report types and shall + return the current report state of the device. However, OUTPUT reports as + payload may be blocked by the underlying transport driver if the + specification does not allow them. + - SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is + sent from host to device and a device must update it's current report state + according to the given data. Any of the 3 report types can be used. However, + INPUT reports as payload might be blocked by the underlying transport driver + if the specification does not allow them. + A device must answer with a synchronous acknowledgement. However, HID core + does not require transport drivers to forward this acknowledgement to HID + core. + Same as for GET_REPORT, only one SET_REPORT can be pending at a time. This + restriction is enforced by HID core as some transport drivers do not support + multiple synchronous SET_REPORT requests. + +Other ctrl-channel requests are supported by USB-HID but are not available +(or deprecated) in most other transport level specifications: + + - GET/SET_IDLE: Only used by USB-HID and I2C-HID. + - GET/SET_PROTOCOL: Not used by HID core. + - RESET: Used by I2C-HID, not hooked up in HID core. + - SET_POWER: Used by I2C-HID, not hooked up in HID core. + +2) HID API +========== + +2.1) Initialization +------------------- + +Transport drivers normally use the following procedure to register a new device +with HID core: + + struct hid_device *hid; + int ret; + + hid = hid_allocate_device(); + if (IS_ERR(hid)) { + ret = PTR_ERR(hid); + goto err_<...>; + } + + strlcpy(hid->name, <device-name-src>, 127); + strlcpy(hid->phys, <device-phys-src>, 63); + strlcpy(hid->uniq, <device-uniq-src>, 63); + + hid->ll_driver = &custom_ll_driver; + hid->bus = <device-bus>; + hid->vendor = <device-vendor>; + hid->product = <device-product>; + hid->version = <device-version>; + hid->country = <device-country>; + hid->dev.parent = <pointer-to-parent-device>; + hid->driver_data = <transport-driver-data-field>; + + ret = hid_add_device(hid); + if (ret) + goto err_<...>; + +Once hid_add_device() is entered, HID core might use the callbacks provided in +"custom_ll_driver". Note that fields like "country" can be ignored by underlying +transport-drivers if not supported. + +To unregister a device, use: + + hid_destroy_device(hid); + +Once hid_destroy_device() returns, HID core will no longer make use of any +driver callbacks. + +2.2) hid_ll_driver operations +----------------------------- + +The available HID callbacks are: + - int (*start) (struct hid_device *hdev) + Called from HID device drivers once they want to use the device. Transport + drivers can choose to setup their device in this callback. However, normally + devices are already set up before transport drivers register them to HID core + so this is mostly only used by USB-HID. + + - void (*stop) (struct hid_device *hdev) + Called from HID device drivers once they are done with a device. Transport + drivers can free any buffers and deinitialize the device. But note that + ->start() might be called again if another HID device driver is loaded on the + device. + Transport drivers are free to ignore it and deinitialize devices after they + destroyed them via hid_destroy_device(). + + - int (*open) (struct hid_device *hdev) + Called from HID device drivers once they are interested in data reports. + Usually, while user-space didn't open any input API/etc., device drivers are + not interested in device data and transport drivers can put devices asleep. + However, once ->open() is called, transport drivers must be ready for I/O. + ->open() calls are nested for each client that opens the HID device. + + - void (*close) (struct hid_device *hdev) + Called from HID device drivers after ->open() was called but they are no + longer interested in device reports. (Usually if user-space closed any input + devices of the driver). + Transport drivers can put devices asleep and terminate any I/O of all + ->open() calls have been followed by a ->close() call. However, ->start() may + be called again if the device driver is interested in input reports again. + + - int (*parse) (struct hid_device *hdev) + Called once during device setup after ->start() has been called. Transport + drivers must read the HID report-descriptor from the device and tell HID core + about it via hid_parse_report(). + + - int (*power) (struct hid_device *hdev, int level) + Called by HID core to give PM hints to transport drivers. Usually this is + analogical to the ->open() and ->close() hints and redundant. + + - void (*request) (struct hid_device *hdev, struct hid_report *report, + int reqtype) + Send an HID request on the ctrl channel. "report" contains the report that + should be sent and "reqtype" the request type. Request-type can be + HID_REQ_SET_REPORT or HID_REQ_GET_REPORT. + This callback is optional. If not provided, HID core will assemble a raw + report following the HID specs and send it via the ->raw_request() callback. + The transport driver is free to implement this asynchronously. + + - int (*wait) (struct hid_device *hdev) + Used by HID core before calling ->request() again. A transport driver can use + it to wait for any pending requests to complete if only one request is + allowed at a time. + + - int (*raw_request) (struct hid_device *hdev, unsigned char reportnum, + __u8 *buf, size_t count, unsigned char rtype, + int reqtype) + Same as ->request() but provides the report as raw buffer. This request shall + be synchronous. A transport driver must not use ->wait() to complete such + requests. This request is mandatory and hid core will reject the device if + it is missing. + + - int (*output_report) (struct hid_device *hdev, __u8 *buf, size_t len) + Send raw output report via intr channel. Used by some HID device drivers + which require high throughput for outgoing requests on the intr channel. This + must not cause SET_REPORT calls! This must be implemented as asynchronous + output report on the intr channel! + + - int (*idle) (struct hid_device *hdev, int report, int idle, int reqtype) + Perform SET/GET_IDLE request. Only used by USB-HID, do not implement! + +2.3) Data Path +-------------- + +Transport drivers are responsible of reading data from I/O devices. They must +handle any I/O-related state-tracking themselves. HID core does not implement +protocol handshakes or other management commands which can be required by the +given HID transport specification. + +Every raw data packet read from a device must be fed into HID core via +hid_input_report(). You must specify the channel-type (intr or ctrl) and report +type (input/output/feature). Under normal conditions, only input reports are +provided via this API. + +Responses to GET_REPORT requests via ->request() must also be provided via this +API. Responses to ->raw_request() are synchronous and must be intercepted by the +transport driver and not passed to hid_input_report(). +Acknowledgements to SET_REPORT requests are not of interest to HID core. + +---------------------------------------------------- +Written 2013, David Herrmann <dh.herrmann@gmail.com> diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index dc35a2b..ee65936 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -93,6 +93,11 @@ the request was handled successfully. event to the kernel. The payload is of type struct uhid_create_req and contains information about your device. You can start I/O now. + UHID_CREATE2: + Same as UHID_CREATE, but the HID report descriptor data (rd_data) is an array + inside struct uhid_create2_req, instead of a pointer to a separate array. + Enables use from languages that don't support pointers, e.g. Python. + UHID_DESTROY: This destroys the internal HID device. No further I/O will be accepted. There may still be pending messages that you can receive with read() but no further @@ -105,6 +110,12 @@ the request was handled successfully. contains a data-payload. This is the raw data that you read from your device. The kernel will parse the HID reports and react on it. + UHID_INPUT2: + Same as UHID_INPUT, but the data array is the last field of uhid_input2_req. + Enables userspace to write only the required bytes to kernel (ev.type + + ev.u.input2.size + the part of the data array that matters), instead of + the entire struct uhid_input2_req. + UHID_FEATURE_ANSWER: If you receive a UHID_FEATURE request you must answer with this request. You must copy the "id" field from the request into the answer. Set the "err" field diff --git a/Documentation/hwmon/adc128d818 b/Documentation/hwmon/adc128d818 new file mode 100644 index 0000000..39c9500 --- /dev/null +++ b/Documentation/hwmon/adc128d818 @@ -0,0 +1,47 @@ +Kernel driver adc128d818 +======================== + +Supported chips: + * Texas Instruments ADC818D818 + Prefix: 'adc818d818' + Addresses scanned: I2C 0x1d, 0x1e, 0x1f, 0x2d, 0x2e, 0x2f + Datasheet: Publicly available at the TI website + http://www.ti.com/ + +Author: Guenter Roeck + +Description +----------- + +This driver implements support for the Texas Instruments ADC128D818. +It is described as 'ADC System Monitor with Temperature Sensor'. + +The ADC128D818 implements one temperature sensor and seven voltage sensors. + +Temperatures are measured in degrees Celsius. There is one set of limits. +When the HOT Temperature Limit is crossed, this will cause an alarm that will +be reasserted until the temperature drops below the HOT Hysteresis. +Measurements are guaranteed between -55 and +125 degrees. The temperature +measurement has a resolution of 0.5 degrees; the limits have a resolution +of 1 degree. + +Voltage sensors (also known as IN sensors) report their values in volts. +An alarm is triggered if the voltage has crossed a programmable minimum +or maximum limit. Note that minimum in this case always means 'closest to +zero'; this is important for negative voltage measurements. All voltage +inputs can measure voltages between 0 and 2.55 volts, with a resolution +of 0.625 mV. + +If an alarm triggers, it will remain triggered until the hardware register +is read at least once. This means that the cause for the alarm may +already have disappeared by the time the alarm is read. The driver +caches the alarm status for each sensor until it is at least reported +once, to ensure that alarms are reported to user space. + +The ADC128D818 only updates its values approximately once per second; +reading it more often will do no harm, but will return 'old' values. + +In addition to the scanned address list, the chip can also be configured for +addresses 0x35 to 0x37. Those addresses are not scanned. You have to instantiate +the driver explicitly if the chip is configured for any of those addresses in +your system. diff --git a/Documentation/hwmon/lm95245 b/Documentation/hwmon/lm95245 index cbd8aea..77eaf28 100644 --- a/Documentation/hwmon/lm95245 +++ b/Documentation/hwmon/lm95245 @@ -24,8 +24,12 @@ is given within a range of -127 to +127.875 degrees. Remote temperatures are given within a range of -127 to +255 degrees. Resolution depends on temperature input and range. -Each sensor has its own critical limit, but the hysteresis is common to all -two channels. +Each sensor has its own critical limit. Additionally, there is a relative +hysteresis value common to both critical limits. To make life easier to +user-space applications, two absolute values are exported, one for each +channel, but these values are of course linked. Only the local hysteresis +can be set from user-space, and the same delta applies to the remote +hysteresis. The lm95245 driver can change its update interval to a fixed set of values. It will round up to the next selectable interval. See the datasheet for exact diff --git a/Documentation/hwmon/ltc2945 b/Documentation/hwmon/ltc2945 new file mode 100644 index 0000000..f8d0f7f --- /dev/null +++ b/Documentation/hwmon/ltc2945 @@ -0,0 +1,84 @@ +Kernel driver ltc2945 +===================== + +Supported chips: + * Linear Technology LTC2945 + Prefix: 'ltc2945' + Addresses scanned: - + Datasheet: + http://cds.linear.com/docs/en/datasheet/2945fa.pdf + +Author: Guenter Roeck <linux@roeck-us.net> + + +Description +----------- + +The LTC2945 is a rail-to-rail system monitor that measures current, voltage, +and power consumption. + + +Usage Notes +----------- + +This driver does not probe for LTC2945 devices, since there is no register +which can be safely used to identify the chip. You will have to instantiate +the devices explicitly. + +Example: the following will load the driver for an LTC2945 at address 0x10 +on I2C bus #1: +$ modprobe ltc2945 +$ echo ltc2945 0x10 > /sys/bus/i2c/devices/i2c-1/new_device + + +Sysfs entries +------------- + +Voltage readings provided by this driver are reported as obtained from the ADC +registers. If a set of voltage divider resistors is installed, calculate the +real voltage by multiplying the reported value with (R1+R2)/R2, where R1 is the +value of the divider resistor against the measured voltage and R2 is the value +of the divider resistor against Ground. + +Current reading provided by this driver is reported as obtained from the ADC +Current Sense register. The reported value assumes that a 1 mOhm sense resistor +is installed. If a different sense resistor is installed, calculate the real +current by dividing the reported value by the sense resistor value in mOhm. + +in1_input VIN voltage (mV). Voltage is measured either at + SENSE+ or VDD pin depending on chip configuration. +in1_min Undervoltage threshold +in1_max Overvoltage threshold +in1_lowest Lowest measured voltage +in1_highest Highest measured voltage +in1_reset_history Write 1 to reset in1 history +in1_min_alarm Undervoltage alarm +in1_max_alarm Overvoltage alarm + +in2_input ADIN voltage (mV) +in2_min Undervoltage threshold +in2_max Overvoltage threshold +in2_lowest Lowest measured voltage +in2_highest Highest measured voltage +in2_reset_history Write 1 to reset in2 history +in2_min_alarm Undervoltage alarm +in2_max_alarm Overvoltage alarm + +curr1_input SENSE current (mA) +curr1_min Undercurrent threshold +curr1_max Overcurrent threshold +curr1_lowest Lowest measured current +curr1_highest Highest measured current +curr1_reset_history Write 1 to reset curr1 history +curr1_min_alarm Undercurrent alarm +curr1_max_alarm Overcurrent alarm + +power1_input Power (in uW). Power is calculated based on SENSE+/VDD + voltage or ADIN voltage depending on chip configuration. +power1_min Low lower threshold +power1_max High power threshold +power1_input_lowest Historical minimum power use +power1_input_highest Historical maximum power use +power1_reset_history Write 1 to reset power1 history +power1_min_alarm Low power alarm +power1_max_alarm High power alarm diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978 index a0546fc..686c078 100644 --- a/Documentation/hwmon/ltc2978 +++ b/Documentation/hwmon/ltc2978 @@ -23,6 +23,10 @@ Supported chips: Prefix: 'ltc3883' Addresses scanned: - Datasheet: http://www.linear.com/product/ltc3883 + * Linear Technology LTM4676 + Prefix: 'ltm4676' + Addresses scanned: - + Datasheet: http://www.linear.com/product/ltm4676 Author: Guenter Roeck <linux@roeck-us.net> @@ -33,7 +37,8 @@ Description LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply monitor. LTC2977 is a pin compatible replacement for LTC2978. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883 is a single phase -step-down DC/DC controller. +step-down DC/DC controller. LTM4676 is a dual 13A or single 26A uModule +regulator. Usage Notes @@ -75,7 +80,7 @@ in[N]_label "vout[1-8]". LTC2974: N=2-5 LTC2977: N=2-9 LTC2978: N=2-9 - LTC3880: N=2-3 + LTC3880, LTM4676: N=2-3 LTC3883: N=2 in[N]_input Measured output voltage. in[N]_min Minimum output voltage. @@ -95,7 +100,7 @@ temp[N]_input Measured temperature. and temp5 reports the chip temperature. On LTC2977 and LTC2978, only one temperature measurement is supported and reports the chip temperature. - On LTC3880, temp1 and temp2 report external + On LTC3880 and LTM4676, temp1 and temp2 report external temperatures, and temp3 reports the chip temperature. On LTC3883, temp1 reports an external temperature, and temp2 reports the chip temperature. @@ -123,11 +128,11 @@ power[N]_label "pout[1-4]". LTC2974: N=1-4 LTC2977: Not supported LTC2978: Not supported - LTC3880: N=1-2 + LTC3880, LTM4676: N=1-2 LTC3883: N=2 power[N]_input Measured output power. -curr1_label "iin". LTC3880 and LTC3883 only. +curr1_label "iin". LTC3880, LTC3883, and LTM4676 only. curr1_input Measured input current. curr1_max Maximum input current. curr1_max_alarm Input current high alarm. @@ -138,7 +143,7 @@ curr[N]_label "iout[1-4]". LTC2974: N=1-4 LTC2977: not supported LTC2978: not supported - LTC3880: N=2-3 + LTC3880, LTM4676: N=2-3 LTC3883: N=2 curr[N]_input Measured output current. curr[N]_max Maximum output current. diff --git a/Documentation/hwmon/ltc4260 b/Documentation/hwmon/ltc4260 new file mode 100644 index 0000000..c4ff4ad --- /dev/null +++ b/Documentation/hwmon/ltc4260 @@ -0,0 +1,56 @@ +Kernel driver ltc4260 +===================== + +Supported chips: + * Linear Technology LTC4260 + Prefix: 'ltc4260' + Addresses scanned: - + Datasheet: + http://cds.linear.com/docs/en/datasheet/4260fc.pdf + +Author: Guenter Roeck <linux@roeck-us.net> + + +Description +----------- + +The LTC4260 Hot Swap controller allows a board to be safely inserted +and removed from a live backplane. + + +Usage Notes +----------- + +This driver does not probe for LTC4260 devices, since there is no register +which can be safely used to identify the chip. You will have to instantiate +the devices explicitly. + +Example: the following will load the driver for an LTC4260 at address 0x10 +on I2C bus #1: +$ modprobe ltc4260 +$ echo ltc4260 0x10 > /sys/bus/i2c/devices/i2c-1/new_device + + +Sysfs entries +------------- + +Voltage readings provided by this driver are reported as obtained from the ADC +registers. If a set of voltage divider resistors is installed, calculate the +real voltage by multiplying the reported value with (R1+R2)/R2, where R1 is the +value of the divider resistor against the measured voltage and R2 is the value +of the divider resistor against Ground. + +Current reading provided by this driver is reported as obtained from the ADC +Current Sense register. The reported value assumes that a 1 mOhm sense resistor +is installed. If a different sense resistor is installed, calculate the real +current by dividing the reported value by the sense resistor value in mOhm. + +in1_input SOURCE voltage (mV) +in1_min_alarm Undervoltage alarm +in1_max_alarm Overvoltage alarm + +in2_input ADIN voltage (mV) +in2_alarm Power bad alarm + +curr1_input SENSE current (mA) +curr1_alarm SENSE overcurrent alarm diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index de139b1..7b4f59c 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -372,7 +372,7 @@ simple scheme, which is compatible with earlier usage, is: Rationale: We have no information about the orientation of the touching ellipse, so approximate it with an inscribed circle instead. The tool -ellipse should align with the the vector (T - C), so the diameter must +ellipse should align with the vector (T - C), so the diameter must increase with distance(T, C). Finally, assume that the touch diameter is equal to the tool thickness, and we arrive at the formulas above. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 7116fda..bc34785 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -229,8 +229,24 @@ bytes respectively. Such letter suffixes can also be entirely omitted. use by PCI Format: <irq>,<irq>... + acpi_no_auto_serialize [HW,ACPI] + Disable auto-serialization of AML methods + AML control methods that contain the opcodes to create + named objects will be marked as "Serialized" by the + auto-serialization feature. + This feature is enabled by default. + This option allows to turn off the feature. + acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT + acpica_no_return_repair [HW, ACPI] + Disable AML predefined validation mechanism + This mechanism can repair the evaluation result to make + the return objects more ACPI specification compliant. + This option is useful for developers to identify the + root cause of an AML interpreter issue when the issue + has something to do with the repair mechanism. + acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS Format: To spoof as Windows 98: ="Microsoft Windows" @@ -298,8 +314,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode Format: { level | edge | high | low } - acpi_serialize [HW,ACPI] force serialization of AML methods - acpi_skip_timer_override [HW,ACPI] Recognize and ignore IRQ0/pin2 Interrupt Override. For broken nForce2 BIOS resulting in XT-PIC timer. @@ -1011,6 +1025,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. parameter will force ia64_sal_cache_flush to call ia64_pal_cache_flush instead of SAL_CACHE_FLUSH. + forcepae [X86-32] + Forcefully enable Physical Address Extension (PAE). + Many Pentium M systems disable PAE but may have a + functionally usable PAE implementation. + Warning: use of this parameter will taint the kernel + and may cause unknown problems. + ftrace=[tracer] [FTRACE] will set and start the specified tracer as early as possible in order to facilitate early @@ -2053,8 +2074,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. IOAPICs that may be present in the system. nokaslr [X86] - Disable kernel base offset ASLR (Address Space - Layout Randomization) if built into the kernel. + Disable kernel and module base offset ASLR (Address + Space Layout Randomization) if built into the kernel. noautogroup Disable scheduler automatic task group creation. @@ -3409,14 +3430,24 @@ bytes respectively. Such letter suffixes can also be entirely omitted. of CONFIG_HIGHPTE. vdso= [X86,SH] - vdso=2: enable compat VDSO (default with COMPAT_VDSO) - vdso=1: enable VDSO (default) + On X86_32, this is an alias for vdso32=. Otherwise: + + vdso=1: enable VDSO (the default) vdso=0: disable VDSO mapping - vdso32= [X86] - vdso32=2: enable compat VDSO (default with COMPAT_VDSO) - vdso32=1: enable 32-bit VDSO (default) - vdso32=0: disable 32-bit VDSO mapping + vdso32= [X86] Control the 32-bit vDSO + vdso32=1: enable 32-bit VDSO + vdso32=0 or vdso32=2: disable 32-bit VDSO + + See the help text for CONFIG_COMPAT_VDSO for more + details. If CONFIG_COMPAT_VDSO is set, the default is + vdso32=0; otherwise, the default is vdso32=1. + + For compatibility with older kernels, vdso32=2 is an + alias for vdso32=0. + + Try vdso32=0 if you encounter an error that says: + dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed! vector= [IA-64,SMP] vector=percpu: enable percpu vector domain diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt index 827104f..f3cd299 100644 --- a/Documentation/kernel-per-CPU-kthreads.txt +++ b/Documentation/kernel-per-CPU-kthreads.txt @@ -162,7 +162,18 @@ Purpose: Execute workqueue requests To reduce its OS jitter, do any of the following: 1. Run your workload at a real-time priority, which will allow preempting the kworker daemons. -2. Do any of the following needed to avoid jitter that your +2. A given workqueue can be made visible in the sysfs filesystem + by passing the WQ_SYSFS to that workqueue's alloc_workqueue(). + Such a workqueue can be confined to a given subset of the + CPUs using the /sys/devices/virtual/workqueue/*/cpumask sysfs + files. The set of WQ_SYSFS workqueues can be displayed using + "ls sys/devices/virtual/workqueue". That said, the workqueues + maintainer would like to caution people against indiscriminately + sprinkling WQ_SYSFS across all the workqueues. The reason for + caution is that it is easy to add WQ_SYSFS, but because sysfs is + part of the formal user/kernel API, it can be nearly impossible + to remove it, even if its addition was a mistake. +3. Do any of the following needed to avoid jitter that your application cannot tolerate: a. Build your kernel with CONFIG_SLUB=y rather than CONFIG_SLAB=y, thus avoiding the slab allocator's periodic diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt index 9398a50..a41bdeb 100644 --- a/Documentation/kmemcheck.txt +++ b/Documentation/kmemcheck.txt @@ -541,7 +541,7 @@ initialized. This is the beginning of the struct: 92 } _sifields; 93 } siginfo_t; -On 64-bit, the int is 4 bytes long, so it must the the union member that has +On 64-bit, the int is 4 bytes long, so it must the union member that has not been initialized. We can verify this using gdb: $ gdb vmlinux diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 102dc19..556f951 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -608,26 +608,30 @@ as follows: b = p; /* BUG: Compiler can reorder!!! */ do_something(); -The solution is again ACCESS_ONCE(), which preserves the ordering between -the load from variable 'a' and the store to variable 'b': +The solution is again ACCESS_ONCE() and barrier(), which preserves the +ordering between the load from variable 'a' and the store to variable 'b': q = ACCESS_ONCE(a); if (q) { + barrier(); ACCESS_ONCE(b) = p; do_something(); } else { + barrier(); ACCESS_ONCE(b) = p; do_something_else(); } -You could also use barrier() to prevent the compiler from moving -the stores to variable 'b', but barrier() would not prevent the -compiler from proving to itself that a==1 always, so ACCESS_ONCE() -is also needed. +The initial ACCESS_ONCE() is required to prevent the compiler from +proving the value of 'a', and the pair of barrier() invocations are +required to prevent the compiler from pulling the two identical stores +to 'b' out from the legs of the "if" statement. It is important to note that control dependencies absolutely require a a conditional. For example, the following "optimized" version of -the above example breaks ordering: +the above example breaks ordering, which is why the barrier() invocations +are absolutely required if you have identical stores in both legs of +the "if" statement: q = ACCESS_ONCE(a); ACCESS_ONCE(b) = p; /* BUG: No ordering vs. load from a!!! */ @@ -643,9 +647,11 @@ It is of course legal for the prior load to be part of the conditional, for example, as follows: if (ACCESS_ONCE(a) > 0) { + barrier(); ACCESS_ONCE(b) = q / 2; do_something(); } else { + barrier(); ACCESS_ONCE(b) = q / 3; do_something_else(); } @@ -659,9 +665,11 @@ the needed conditional. For example: q = ACCESS_ONCE(a); if (q % MAX) { + barrier(); ACCESS_ONCE(b) = p; do_something(); } else { + barrier(); ACCESS_ONCE(b) = p; do_something_else(); } @@ -723,8 +731,13 @@ In summary: use smb_rmb(), smp_wmb(), or, in the case of prior stores and later loads, smp_mb(). + (*) If both legs of the "if" statement begin with identical stores + to the same variable, a barrier() statement is required at the + beginning of each leg of the "if" statement. + (*) Control dependencies require at least one run-time conditional - between the prior load and the subsequent store. If the compiler + between the prior load and the subsequent store, and this + conditional must involve the prior load. If the compiler is able to optimize the conditional away, it will have also optimized away the ordering. Careful use of ACCESS_ONCE() can help to preserve the needed conditional. @@ -1249,6 +1262,23 @@ The ACCESS_ONCE() function can prevent any number of optimizations that, while perfectly safe in single-threaded code, can be fatal in concurrent code. Here are some examples of these sorts of optimizations: + (*) The compiler is within its rights to reorder loads and stores + to the same variable, and in some cases, the CPU is within its + rights to reorder loads to the same variable. This means that + the following code: + + a[0] = x; + a[1] = x; + + Might result in an older value of x stored in a[1] than in a[0]. + Prevent both the compiler and the CPU from doing this as follows: + + a[0] = ACCESS_ONCE(x); + a[1] = ACCESS_ONCE(x); + + In short, ACCESS_ONCE() provides cache coherence for accesses from + multiple CPUs to a single variable. + (*) The compiler is within its rights to merge successive loads from the same variable. Such merging can cause the compiler to "optimize" the following code: @@ -1371,7 +1401,7 @@ code. Here are some examples of these sorts of optimizations: process_message(msg); } - There is nothing to prevent the the compiler from transforming + There is nothing to prevent the compiler from transforming process_level() to the following, in fact, this might well be a win for single-threaded code: @@ -1644,12 +1674,12 @@ for each construct. These operations all imply certain barriers: Memory operations issued after the ACQUIRE will be completed after the ACQUIRE operation has completed. - Memory operations issued before the ACQUIRE may be completed after the - ACQUIRE operation has completed. An smp_mb__before_spinlock(), combined - with a following ACQUIRE, orders prior loads against subsequent stores and - stores and prior stores against subsequent stores. Note that this is - weaker than smp_mb()! The smp_mb__before_spinlock() primitive is free on - many architectures. + Memory operations issued before the ACQUIRE may be completed after + the ACQUIRE operation has completed. An smp_mb__before_spinlock(), + combined with a following ACQUIRE, orders prior loads against + subsequent loads and stores and also orders prior stores against + subsequent stores. Note that this is weaker than smp_mb()! The + smp_mb__before_spinlock() primitive is free on many architectures. (2) RELEASE operation implication: @@ -1694,24 +1724,21 @@ may occur as: ACQUIRE M, STORE *B, STORE *A, RELEASE M -This same reordering can of course occur if the lock's ACQUIRE and RELEASE are -to the same lock variable, but only from the perspective of another CPU not -holding that lock. - -In short, a RELEASE followed by an ACQUIRE may -not- be assumed to be a full -memory barrier because it is possible for a preceding RELEASE to pass a -later ACQUIRE from the viewpoint of the CPU, but not from the viewpoint -of the compiler. Note that deadlocks cannot be introduced by this -interchange because if such a deadlock threatened, the RELEASE would -simply complete. - -If it is necessary for a RELEASE-ACQUIRE pair to produce a full barrier, the -ACQUIRE can be followed by an smp_mb__after_unlock_lock() invocation. This -will produce a full barrier if either (a) the RELEASE and the ACQUIRE are -executed by the same CPU or task, or (b) the RELEASE and ACQUIRE act on the -same variable. The smp_mb__after_unlock_lock() primitive is free on many -architectures. Without smp_mb__after_unlock_lock(), the critical sections -corresponding to the RELEASE and the ACQUIRE can cross: +When the ACQUIRE and RELEASE are a lock acquisition and release, +respectively, this same reordering can occur if the lock's ACQUIRE and +RELEASE are to the same lock variable, but only from the perspective of +another CPU not holding that lock. In short, a ACQUIRE followed by an +RELEASE may -not- be assumed to be a full memory barrier. + +Similarly, the reverse case of a RELEASE followed by an ACQUIRE does not +imply a full memory barrier. If it is necessary for a RELEASE-ACQUIRE +pair to produce a full barrier, the ACQUIRE can be followed by an +smp_mb__after_unlock_lock() invocation. This will produce a full barrier +if either (a) the RELEASE and the ACQUIRE are executed by the same +CPU or task, or (b) the RELEASE and ACQUIRE act on the same variable. +The smp_mb__after_unlock_lock() primitive is free on many architectures. +Without smp_mb__after_unlock_lock(), the CPU's execution of the critical +sections corresponding to the RELEASE and the ACQUIRE can cross, so that: *A = a; RELEASE M @@ -1722,7 +1749,36 @@ could occur as: ACQUIRE N, STORE *B, STORE *A, RELEASE M -With smp_mb__after_unlock_lock(), they cannot, so that: +It might appear that this reordering could introduce a deadlock. +However, this cannot happen because if such a deadlock threatened, +the RELEASE would simply complete, thereby avoiding the deadlock. + + Why does this work? + + One key point is that we are only talking about the CPU doing + the reordering, not the compiler. If the compiler (or, for + that matter, the developer) switched the operations, deadlock + -could- occur. + + But suppose the CPU reordered the operations. In this case, + the unlock precedes the lock in the assembly code. The CPU + simply elected to try executing the later lock operation first. + If there is a deadlock, this lock operation will simply spin (or + try to sleep, but more on that later). The CPU will eventually + execute the unlock operation (which preceded the lock operation + in the assembly code), which will unravel the potential deadlock, + allowing the lock operation to succeed. + + But what if the lock is a sleeplock? In that case, the code will + try to enter the scheduler, where it will eventually encounter + a memory barrier, which will force the earlier unlock operation + to complete, again unraveling the deadlock. There might be + a sleep-unlock race, but the locking primitive needs to resolve + such races properly in any case. + +With smp_mb__after_unlock_lock(), the two critical sections cannot overlap. +For example, with the following code, the store to *A will always be +seen by other CPUs before the store to *B: *A = a; RELEASE M @@ -1730,13 +1786,18 @@ With smp_mb__after_unlock_lock(), they cannot, so that: smp_mb__after_unlock_lock(); *B = b; -will always occur as either of the following: +The operations will always occur in one of the following orders: - STORE *A, RELEASE, ACQUIRE, STORE *B - STORE *A, ACQUIRE, RELEASE, STORE *B + STORE *A, RELEASE, ACQUIRE, smp_mb__after_unlock_lock(), STORE *B + STORE *A, ACQUIRE, RELEASE, smp_mb__after_unlock_lock(), STORE *B + ACQUIRE, STORE *A, RELEASE, smp_mb__after_unlock_lock(), STORE *B If the RELEASE and ACQUIRE were instead both operating on the same lock -variable, only the first of these two alternatives can occur. +variable, only the first of these alternatives can occur. In addition, +the more strongly ordered systems may rule out some of the above orders. +But in any case, as noted earlier, the smp_mb__after_unlock_lock() +ensures that the store to *A will always be seen as happening before +the store to *B. Locks and semaphores may not provide any guarantee of ordering on UP compiled systems, and so cannot be counted on in such a situation to actually achieve @@ -2757,7 +2818,7 @@ in that order, but, without intervention, the sequence may have almost any combination of elements combined or discarded, provided the program's view of the world remains consistent. Note that ACCESS_ONCE() is -not- optional in the above example, as there are architectures where a given CPU might -interchange successive loads to the same location. On such architectures, +reorder successive loads to the same location. On such architectures, ACCESS_ONCE() does whatever is necessary to prevent this, for example, on Itanium the volatile casts used by ACCESS_ONCE() cause GCC to emit the special ld.acq and st.rel instructions that prevent such reordering. diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt index 2b40e04..09b583e 100644 --- a/Documentation/module-signing.txt +++ b/Documentation/module-signing.txt @@ -77,11 +77,11 @@ This has a number of options available: This presents a choice of which hash algorithm the installation phase will sign the modules with: - CONFIG_SIG_SHA1 "Sign modules with SHA-1" - CONFIG_SIG_SHA224 "Sign modules with SHA-224" - CONFIG_SIG_SHA256 "Sign modules with SHA-256" - CONFIG_SIG_SHA384 "Sign modules with SHA-384" - CONFIG_SIG_SHA512 "Sign modules with SHA-512" + CONFIG_MODULE_SIG_SHA1 "Sign modules with SHA-1" + CONFIG_MODULE_SIG_SHA224 "Sign modules with SHA-224" + CONFIG_MODULE_SIG_SHA256 "Sign modules with SHA-256" + CONFIG_MODULE_SIG_SHA384 "Sign modules with SHA-384" + CONFIG_MODULE_SIG_SHA512 "Sign modules with SHA-512" The algorithm selected here will also be built into the kernel (rather than being a module) so that modules signed with that algorithm can have diff --git a/Documentation/networking/spider_net.txt b/Documentation/networking/spider_net.txt index 4b4adb8..b0b75f8 100644 --- a/Documentation/networking/spider_net.txt +++ b/Documentation/networking/spider_net.txt @@ -73,7 +73,7 @@ Thus, in an idle system, the GDACTDPA, tail and head pointers will all be pointing at the same descr, which should be "empty". All of the other descrs in the ring should be "empty" as well. -The show_rx_chain() routine will print out the the locations of the +The show_rx_chain() routine will print out the locations of the GDACTDPA, tail and head pointers. It will also summarize the contents of the ring, starting at the tail pointer, and listing the status of the descrs that follow. diff --git a/Documentation/phy/samsung-usb2.txt b/Documentation/phy/samsung-usb2.txt new file mode 100644 index 0000000..ed12d43 --- /dev/null +++ b/Documentation/phy/samsung-usb2.txt @@ -0,0 +1,135 @@ +.------------------------------------------------------------------------------+ +| Samsung USB 2.0 PHY adaptation layer | ++-----------------------------------------------------------------------------+' + +| 1. Description ++---------------- + +The architecture of the USB 2.0 PHY module in Samsung SoCs is similar +among many SoCs. In spite of the similarities it proved difficult to +create a one driver that would fit all these PHY controllers. Often +the differences were minor and were found in particular bits of the +registers of the PHY. In some rare cases the order of register writes or +the PHY powering up process had to be altered. This adaptation layer is +a compromise between having separate drivers and having a single driver +with added support for many special cases. + +| 2. Files description ++---------------------- + +- phy-samsung-usb2.c + This is the main file of the adaptation layer. This file contains + the probe function and provides two callbacks to the Generic PHY + Framework. This two callbacks are used to power on and power off the + phy. They carry out the common work that has to be done on all version + of the PHY module. Depending on which SoC was chosen they execute SoC + specific callbacks. The specific SoC version is selected by choosing + the appropriate compatible string. In addition, this file contains + struct of_device_id definitions for particular SoCs. + +- phy-samsung-usb2.h + This is the include file. It declares the structures used by this + driver. In addition it should contain extern declarations for + structures that describe particular SoCs. + +| 3. Supporting SoCs ++-------------------- + +To support a new SoC a new file should be added to the drivers/phy +directory. Each SoC's configuration is stored in an instance of the +struct samsung_usb2_phy_config. + +struct samsung_usb2_phy_config { + const struct samsung_usb2_common_phy *phys; + int (*rate_to_clk)(unsigned long, u32 *); + unsigned int num_phys; + bool has_mode_switch; +}; + +The num_phys is the number of phys handled by the driver. *phys is an +array that contains the configuration for each phy. The has_mode_switch +property is a boolean flag that determines whether the SoC has USB host +and device on a single pair of pins. If so, a special register has to +be modified to change the internal routing of these pins between a USB +device or host module. + +For example the configuration for Exynos 4210 is following: + +const struct samsung_usb2_phy_config exynos4210_usb2_phy_config = { + .has_mode_switch = 0, + .num_phys = EXYNOS4210_NUM_PHYS, + .phys = exynos4210_phys, + .rate_to_clk = exynos4210_rate_to_clk, +} + +- int (*rate_to_clk)(unsigned long, u32 *) + The rate_to_clk callback is to convert the rate of the clock + used as the reference clock for the PHY module to the value + that should be written in the hardware register. + +The exynos4210_phys configuration array is as follows: + +static const struct samsung_usb2_common_phy exynos4210_phys[] = { + { + .label = "device", + .id = EXYNOS4210_DEVICE, + .power_on = exynos4210_power_on, + .power_off = exynos4210_power_off, + }, + { + .label = "host", + .id = EXYNOS4210_HOST, + .power_on = exynos4210_power_on, + .power_off = exynos4210_power_off, + }, + { + .label = "hsic0", + .id = EXYNOS4210_HSIC0, + .power_on = exynos4210_power_on, + .power_off = exynos4210_power_off, + }, + { + .label = "hsic1", + .id = EXYNOS4210_HSIC1, + .power_on = exynos4210_power_on, + .power_off = exynos4210_power_off, + }, + {}, +}; + +- int (*power_on)(struct samsung_usb2_phy_instance *); +- int (*power_off)(struct samsung_usb2_phy_instance *); + These two callbacks are used to power on and power off the phy + by modifying appropriate registers. + +Final change to the driver is adding appropriate compatible value to the +phy-samsung-usb2.c file. In case of Exynos 4210 the following lines were +added to the struct of_device_id samsung_usb2_phy_of_match[] array: + +#ifdef CONFIG_PHY_EXYNOS4210_USB2 + { + .compatible = "samsung,exynos4210-usb2-phy", + .data = &exynos4210_usb2_phy_config, + }, +#endif + +To add further flexibility to the driver the Kconfig file enables to +include support for selected SoCs in the compiled driver. The Kconfig +entry for Exynos 4210 is following: + +config PHY_EXYNOS4210_USB2 + bool "Support for Exynos 4210" + depends on PHY_SAMSUNG_USB2 + depends on CPU_EXYNOS4210 + help + Enable USB PHY support for Exynos 4210. This option requires that + Samsung USB 2.0 PHY driver is enabled and means that support for this + particular SoC is compiled in the driver. In case of Exynos 4210 four + phys are available - device, host, HSCI0 and HSCI1. + +The newly created file that supports the new SoC has to be also added to the +Makefile. In case of Exynos 4210 the added line is following: + +obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o + +After completing these steps the support for the new SoC should be ready. diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index a66c982..47d46df 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -391,7 +391,7 @@ When resuming from freeze, standby or memory sleep, the phases are: the resume methods. This generally involves undoing the actions of the preceding suspend_late phase. - 3 The resume methods should bring the the device back to its operating + 3 The resume methods should bring the device back to its operating state, so that it can perform normal I/O. This generally involves undoing the actions of the suspend phase. diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt index 4836320..a5da5c7 100644 --- a/Documentation/power/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt @@ -88,17 +88,19 @@ node. 2. PM QoS per-device latency and flags framework -For each device, there are two lists of PM QoS requests. One is maintained -along with the aggregated target of latency value and the other is for PM QoS -flags. Values are updated in response to changes of the request list. +For each device, there are three lists of PM QoS requests. Two of them are +maintained along with the aggregated targets of resume latency and active +state latency tolerance (in microseconds) and the third one is for PM QoS flags. +Values are updated in response to changes of the request list. -Target latency value is simply the minimum of the request values held in the -parameter list elements. The PM QoS flags aggregate value is a gather (bitwise -OR) of all list elements' values. Two device PM QoS flags are defined currently: -PM_QOS_FLAG_NO_POWER_OFF and PM_QOS_FLAG_REMOTE_WAKEUP. +The target values of resume latency and active state latency tolerance are +simply the minimum of the request values held in the parameter list elements. +The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements' +values. Two device PM QoS flags are defined currently: PM_QOS_FLAG_NO_POWER_OFF +and PM_QOS_FLAG_REMOTE_WAKEUP. -Note: the aggregated target value is implemented as an atomic variable so that -reading the aggregated value does not require any locking mechanism. +Note: The aggregated target values are implemented in such a way that reading +the aggregated value does not require any locking mechanism. From kernel mode the use of this interface is the following: @@ -132,19 +134,21 @@ The meaning of the return values is as follows: PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been initialized or the list of requests is empty. -int dev_pm_qos_add_ancestor_request(dev, handle, value) +int dev_pm_qos_add_ancestor_request(dev, handle, type, value) Add a PM QoS request for the first direct ancestor of the given device whose -power.ignore_children flag is unset. +power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests) +or whose power.set_latency_tolerance callback pointer is not NULL (for +DEV_PM_QOS_LATENCY_TOLERANCE requests). int dev_pm_qos_expose_latency_limit(device, value) -Add a request to the device's PM QoS list of latency constraints and create -a sysfs attribute pm_qos_resume_latency_us under the device's power directory -allowing user space to manipulate that request. +Add a request to the device's PM QoS list of resume latency constraints and +create a sysfs attribute pm_qos_resume_latency_us under the device's power +directory allowing user space to manipulate that request. void dev_pm_qos_hide_latency_limit(device) Drop the request added by dev_pm_qos_expose_latency_limit() from the device's -PM QoS list of latency constraints and remove sysfs attribute pm_qos_resume_latency_us -from the device's power directory. +PM QoS list of resume latency constraints and remove sysfs attribute +pm_qos_resume_latency_us from the device's power directory. int dev_pm_qos_expose_flags(device, value) Add a request to the device's PM QoS list of flags and create sysfs attributes @@ -163,7 +167,7 @@ a per-device notification tree and a global notification tree. int dev_pm_qos_add_notifier(device, notifier): Adds a notification callback function for the device. The callback is called when the aggregated value of the device constraints list -is changed. +is changed (for resume latency device PM QoS only). int dev_pm_qos_remove_notifier(device, notifier): Removes the notification callback function for the device. @@ -171,14 +175,48 @@ Removes the notification callback function for the device. int dev_pm_qos_add_global_notifier(notifier): Adds a notification callback function in the global notification tree of the framework. -The callback is called when the aggregated value for any device is changed. +The callback is called when the aggregated value for any device is changed +(for resume latency device PM QoS only). int dev_pm_qos_remove_global_notifier(notifier): Removes the notification callback function from the global notification tree of the framework. -From user mode: -No API for user space access to the per-device latency constraints is provided -yet - still under discussion. - +Active state latency tolerance + +This device PM QoS type is used to support systems in which hardware may switch +to energy-saving operation modes on the fly. In those systems, if the operation +mode chosen by the hardware attempts to save energy in an overly aggressive way, +it may cause excess latencies to be visible to software, causing it to miss +certain protocol requirements or target frame or sample rates etc. + +If there is a latency tolerance control mechanism for a given device available +to software, the .set_latency_tolerance callback in that device's dev_pm_info +structure should be populated. The routine pointed to by it is should implement +whatever is necessary to transfer the effective requirement value to the +hardware. + +Whenever the effective latency tolerance changes for the device, its +.set_latency_tolerance() callback will be executed and the effective value will +be passed to it. If that value is negative, which means that the list of +latency tolerance requirements for the device is empty, the callback is expected +to switch the underlying hardware latency tolerance control mechanism to an +autonomous mode if available. If that value is PM_QOS_LATENCY_ANY, in turn, and +the hardware supports a special "no requirement" setting, the callback is +expected to use it. That allows software to prevent the hardware from +automatically updating the device's latency tolerance in response to its power +state changes (e.g. during transitions from D3cold to D0), which generally may +be done in the autonomous latency tolerance control mode. + +If .set_latency_tolerance() is present for the device, sysfs attribute +pm_qos_latency_tolerance_us will be present in the devivce's power directory. +Then, user space can use that attribute to specify its latency tolerance +requirement for the device, if any. Writing "any" to it means "no requirement, +but do not let the hardware control latency tolerance" and writing "auto" to it +allows the hardware to be switched to the autonomous mode if there are no other +requirements from the kernel side in the device's list. + +Kernel code can use the functions described above along with the +DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type to add, remove and update +latency tolerance requirements for devices. diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index b6ce00b..5f96daf 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -232,7 +232,7 @@ defined in include/linux/pm.h: equal to zero); the initial value of it is 1 (i.e. runtime PM is initially disabled for all devices) - unsigned int runtime_error; + int runtime_error; - if set, there was a fatal error (one of the callbacks returned error code as described in Section 2), so the helper funtions will not work until this flag is cleared; this is the error code returned by the failing @@ -401,11 +401,11 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: int pm_runtime_disable(struct device *dev); - increment the device's 'power.disable_depth' field (if the value of that field was previously zero, this prevents subsystem-level runtime PM - callbacks from being run for the device), make sure that all of the pending - runtime PM operations on the device are either completed or canceled; - returns 1 if there was a resume request pending and it was necessary to - execute the subsystem-level resume callback for the device to satisfy that - request, otherwise 0 is returned + callbacks from being run for the device), make sure that all of the + pending runtime PM operations on the device are either completed or + canceled; returns 1 if there was a resume request pending and it was + necessary to execute the subsystem-level resume callback for the device + to satisfy that request, otherwise 0 is returned int pm_runtime_barrier(struct device *dev); - check if there's a resume request pending for the device and resume it @@ -667,11 +667,11 @@ driver/base/power/generic_ops.c: int pm_generic_runtime_suspend(struct device *dev); - invoke the ->runtime_suspend() callback provided by the driver of this - device and return its result, or return -EINVAL if not defined + device and return its result, or return 0 if not defined int pm_generic_runtime_resume(struct device *dev); - invoke the ->runtime_resume() callback provided by the driver of this - device and return its result, or return -EINVAL if not defined + device and return its result, or return 0 if not defined int pm_generic_suspend(struct device *dev); - if the device has not been suspended at run time, invoke the ->suspend() @@ -727,15 +727,12 @@ driver/base/power/generic_ops.c: int pm_generic_restore_noirq(struct device *dev); - invoke the ->restore_noirq() callback provided by the device's driver -These functions can be assigned to the ->runtime_idle(), ->runtime_suspend(), +These functions are the defaults used by the PM core, if a subsystem doesn't +provide its own callbacks for ->runtime_idle(), ->runtime_suspend(), ->runtime_resume(), ->suspend(), ->suspend_noirq(), ->resume(), ->resume_noirq(), ->freeze(), ->freeze_noirq(), ->thaw(), ->thaw_noirq(), -->poweroff(), ->poweroff_noirq(), ->restore(), ->restore_noirq() callback -pointers in the subsystem-level dev_pm_ops structures. - -If a subsystem wishes to use all of them at the same time, it can simply assign -the GENERIC_SUBSYS_PM_OPS macro, defined in include/linux/pm.h, to its -dev_pm_ops structure pointer. +->poweroff(), ->poweroff_noirq(), ->restore(), ->restore_noirq() in the +subsystem-level dev_pm_ops structure. Device drivers that wish to use the same function as a system suspend, freeze, poweroff and runtime suspend callback, and similarly for system resume, thaw, @@ -873,7 +870,7 @@ Here is a schematic pseudo-code example: foo->is_suspended = 0; pm_runtime_mark_last_busy(&foo->dev); if (foo->num_pending_requests > 0) - foo_process_requests(foo); + foo_process_next_request(foo); unlock(&foo->private_lock); return 0; } diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 6edaa65..91ba58e 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,16 @@ +Release Date : Mon. Mar 10, 2014 17:00:00 PST 2014 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford + Kashyap Desai + Sumit Saxena +Current Version : 06.803.01.00-rc1 +Old Version : 06.700.06.00-rc1 + 1. Load correct raid context timeout value for multipathing & clustering. + 2. Fix megasas_ioc_init_fusion to use local stack variable. + 3. Return leaked MPT frames to MPT command pool. + 4. Add Dell PowerEdge VRTX SR-IOV VF device support. + 5. Version and Changelog update. +------------------------------------------------------------------------------- Release Date : Sat. Aug 31, 2013 17:00:00 PST 2013 - (emaild-id:megaraidlinux@lsi.com) Adam Radford diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt index 7a2d30c..5ea996f 100644 --- a/Documentation/security/Smack.txt +++ b/Documentation/security/Smack.txt @@ -3,7 +3,7 @@ "Good for you, you've decided to clean the elevator!" - The Elevator, from Dark Star -Smack is the the Simplified Mandatory Access Control Kernel. +Smack is the Simplified Mandatory Access Control Kernel. Smack is a kernel based implementation of mandatory access control that includes simplicity in its primary design goals. diff --git a/Documentation/sgi-visws.txt b/Documentation/sgi-visws.txt deleted file mode 100644 index 7ff0811..0000000 --- a/Documentation/sgi-visws.txt +++ /dev/null @@ -1,13 +0,0 @@ - -The SGI Visual Workstations (models 320 and 540) are based around -the Cobalt, Lithium, and Arsenic ASICs. The Cobalt ASIC is the -main system ASIC which interfaces the 1-4 IA32 cpus, the memory -system, and the I/O system in the Lithium ASIC. The Cobalt ASIC -also contains the 3D gfx rendering engine which renders to main -system memory -- part of which is used as the frame buffer which -is DMA'ed to a video connector using the Arsenic ASIC. A PIIX4 -chip and NS87307 are used to provide legacy device support (IDE, -serial, floppy, and parallel). - -The Visual Workstation chipset largely conforms to the PC architecture -with some notable exceptions such as interrupt handling. diff --git a/Documentation/sound/oss/vwsnd b/Documentation/sound/oss/vwsnd deleted file mode 100644 index 4c6cbdb..0000000 --- a/Documentation/sound/oss/vwsnd +++ /dev/null @@ -1,293 +0,0 @@ -vwsnd - Sound driver for the Silicon Graphics 320 and 540 Visual -Workstations' onboard audio. - -Copyright 1999 Silicon Graphics, Inc. All rights reserved. - - -At the time of this writing, March 1999, there are two models of -Visual Workstation, the 320 and the 540. This document only describes -those models. Future Visual Workstation models may have different -sound capabilities, and this driver will probably not work on those -boxes. - -The Visual Workstation has an Analog Devices AD1843 "SoundComm" audio -codec chip. The AD1843 is accessed through the Cobalt I/O ASIC, also -known as Lithium. This driver programs both chips. - -============================================================================== -QUICK CONFIGURATION - - # insmod soundcore - # insmod vwsnd - -============================================================================== -I/O CONNECTIONS - -On the Visual Workstation, only three of the AD1843 inputs are hooked -up. The analog line in jacks are connected to the AD1843's AUX1 -input. The CD audio lines are connected to the AD1843's AUX2 input. -The microphone jack is connected to the AD1843's MIC input. The mic -jack is mono, but the signal is delivered to both the left and right -MIC inputs. You can record in stereo from the mic input, but you will -get the same signal on both channels (within the limits of A/D -accuracy). Full scale on the Line input is +/- 2.0 V. Full scale on -the MIC input is 20 dB less, or +/- 0.2 V. - -The AD1843's LOUT1 outputs are connected to the Line Out jacks. The -AD1843's HPOUT outputs are connected to the speaker/headphone jack. -LOUT2 is not connected. Line out's maximum level is +/- 2.0 V peak to -peak. The speaker/headphone out's maximum is +/- 4.0 V peak to peak. - -The AD1843's PCM input channel and one of its output channels (DAC1) -are connected to Lithium. The other output channel (DAC2) is not -connected. - -============================================================================== -CAPABILITIES - -The AD1843 has PCM input and output (Pulse Code Modulation, also known -as wavetable). PCM input and output can be mono or stereo in any of -four formats. The formats are 16 bit signed and 8 bit unsigned, -u-Law, and A-Law format. Any sample rate from 4 KHz to 49 KHz is -available, in 1 Hz increments. - -The AD1843 includes an analog mixer that can mix all three input -signals (line, mic and CD) into the analog outputs. The mixer has a -separate gain control and mute switch for each input. - -There are two outputs, line out and speaker/headphone out. They -always produce the same signal, and the speaker always has 3 dB more -gain than the line out. The speaker/headphone output can be muted, -but this driver does not export that function. - -The hardware can sync audio to the video clock, but this driver does -not have a way to specify syncing to video. - -============================================================================== -PROGRAMMING - -This section explains the API supported by the driver. Also see the -Open Sound Programming Guide at http://www.opensound.com/pguide/ . -This section assumes familiarity with that document. - -The driver has two interfaces, an I/O interface and a mixer interface. -There is no MIDI or sequencer capability. - -============================================================================== -PROGRAMMING PCM I/O - -The I/O interface is usually accessed as /dev/audio or /dev/dsp. -Using the standard Open Sound System (OSS) ioctl calls, the sample -rate, number of channels, and sample format may be set within the -limitations described above. The driver supports triggering. It also -supports getting the input and output pointers with one-sample -accuracy. - -The SNDCTL_DSP_GETCAP ioctl returns these capabilities. - - DSP_CAP_DUPLEX - driver supports full duplex. - - DSP_CAP_TRIGGER - driver supports triggering. - - DSP_CAP_REALTIME - values returned by SNDCTL_DSP_GETIPTR - and SNDCTL_DSP_GETOPTR are accurate to a few samples. - -Memory mapping (mmap) is not implemented. - -The driver permits subdivided fragment sizes from 64 to 4096 bytes. -The number of fragments can be anything from 3 fragments to however -many fragments fit into 124 kilobytes. It is up to the user to -determine how few/small fragments can be used without introducing -glitches with a given workload. Linux is not realtime, so we can't -promise anything. (sigh...) - -When this driver is switched into or out of mu-Law or A-Law mode on -output, it may produce an audible click. This is unavoidable. To -prevent clicking, use signed 16-bit mode instead, and convert from -mu-Law or A-Law format in software. - -============================================================================== -PROGRAMMING THE MIXER INTERFACE - -The mixer interface is usually accessed as /dev/mixer. It is accessed -through ioctls. The mixer allows the application to control gain or -mute several audio signal paths, and also allows selection of the -recording source. - -Each of the constants described here can be read using the -MIXER_READ(SOUND_MIXER_xxx) ioctl. Those that are not read-only can -also be written using the MIXER_WRITE(SOUND_MIXER_xxx) ioctl. In most -cases, <sys/soundcard.h> defines constants SOUND_MIXER_READ_xxx and -SOUND_MIXER_WRITE_xxx which work just as well. - -SOUND_MIXER_CAPS Read-only - -This is a mask of optional driver capabilities that are implemented. -This driver's only capability is SOUND_CAP_EXCL_INPUT, which means -that only one recording source can be active at a time. - -SOUND_MIXER_DEVMASK Read-only - -This is a mask of the sound channels. This driver's channels are PCM, -LINE, MIC, CD, and RECLEV. - -SOUND_MIXER_STEREODEVS Read-only - -This is a mask of which sound channels are capable of stereo. All -channels are capable of stereo. (But see caveat on MIC input in I/O -CONNECTIONS section above). - -SOUND_MIXER_OUTMASK Read-only - -This is a mask of channels that route inputs through to outputs. -Those are LINE, MIC, and CD. - -SOUND_MIXER_RECMASK Read-only - -This is a mask of channels that can be recording sources. Those are -PCM, LINE, MIC, CD. - -SOUND_MIXER_PCM Default: 0x5757 (0 dB) - -This is the gain control for PCM output. The left and right channel -gain are controlled independently. This gain control has 64 levels, -which range from -82.5 dB to +12.0 dB in 1.5 dB steps. Those 64 -levels are mapped onto 100 levels at the ioctl, see below. - -SOUND_MIXER_LINE Default: 0x4a4a (0 dB) - -This is the gain control for mixing the Line In source into the -outputs. The left and right channel gain are controlled -independently. This gain control has 32 levels, which range from --34.5 dB to +12.0 dB in 1.5 dB steps. Those 32 levels are mapped onto -100 levels at the ioctl, see below. - -SOUND_MIXER_MIC Default: 0x4a4a (0 dB) - -This is the gain control for mixing the MIC source into the outputs. -The left and right channel gain are controlled independently. This -gain control has 32 levels, which range from -34.5 dB to +12.0 dB in -1.5 dB steps. Those 32 levels are mapped onto 100 levels at the -ioctl, see below. - -SOUND_MIXER_CD Default: 0x4a4a (0 dB) - -This is the gain control for mixing the CD audio source into the -outputs. The left and right channel gain are controlled -independently. This gain control has 32 levels, which range from --34.5 dB to +12.0 dB in 1.5 dB steps. Those 32 levels are mapped onto -100 levels at the ioctl, see below. - -SOUND_MIXER_RECLEV Default: 0 (0 dB) - -This is the gain control for PCM input (RECording LEVel). The left -and right channel gain are controlled independently. This gain -control has 16 levels, which range from 0 dB to +22.5 dB in 1.5 dB -steps. Those 16 levels are mapped onto 100 levels at the ioctl, see -below. - -SOUND_MIXER_RECSRC Default: SOUND_MASK_LINE - -This is a mask of currently selected PCM input sources (RECording -SouRCes). Because the AD1843 can only have a single recording source -at a time, only one bit at a time can be set in this mask. The -allowable values are SOUND_MASK_PCM, SOUND_MASK_LINE, SOUND_MASK_MIC, -or SOUND_MASK_CD. Selecting SOUND_MASK_PCM sets up internal -resampling which is useful for loopback testing and for hardware -sample rate conversion. But software sample rate conversion is -probably faster, so I don't know how useful that is. - -SOUND_MIXER_OUTSRC DEFAULT: SOUND_MASK_LINE|SOUND_MASK_MIC|SOUND_MASK_CD - -This is a mask of sources that are currently passed through to the -outputs. Those sources whose bits are not set are muted. - -============================================================================== -GAIN CONTROL - -There are five gain controls listed above. Each has 16, 32, or 64 -steps. Each control has 1.5 dB of gain per step. Each control is -stereo. - -The OSS defines the argument to a channel gain ioctl as having two -components, left and right, each of which ranges from 0 to 100. The -two components are packed into the same word, with the left side gain -in the least significant byte, and the right side gain in the second -least significant byte. In C, we would say this. - - #include <assert.h> - - ... - - assert(leftgain >= 0 && leftgain <= 100); - assert(rightgain >= 0 && rightgain <= 100); - arg = leftgain | rightgain << 8; - -So each OSS gain control has 101 steps. But the hardware has 16, 32, -or 64 steps. The hardware steps are spread across the 101 OSS steps -nearly evenly. The conversion formulas are like this, given N equals -16, 32, or 64. - - int round = N/2 - 1; - OSS_gain_steps = (hw_gain_steps * 100 + round) / (N - 1); - hw_gain_steps = (OSS_gain_steps * (N - 1) + round) / 100; - -Here is a snippet of C code that will return the left and right gain -of any channel in dB. Pass it one of the predefined gain_desc_t -structures to access any of the five channels' gains. - - typedef struct gain_desc { - float min_gain; - float gain_step; - int nbits; - int chan; - } gain_desc_t; - - const gain_desc_t gain_pcm = { -82.5, 1.5, 6, SOUND_MIXER_PCM }; - const gain_desc_t gain_line = { -34.5, 1.5, 5, SOUND_MIXER_LINE }; - const gain_desc_t gain_mic = { -34.5, 1.5, 5, SOUND_MIXER_MIC }; - const gain_desc_t gain_cd = { -34.5, 1.5, 5, SOUND_MIXER_CD }; - const gain_desc_t gain_reclev = { 0.0, 1.5, 4, SOUND_MIXER_RECLEV }; - - int get_gain_dB(int fd, const gain_desc_t *gp, - float *left, float *right) - { - int word; - int lg, rg; - int mask = (1 << gp->nbits) - 1; - - if (ioctl(fd, MIXER_READ(gp->chan), &word) != 0) - return -1; /* fail */ - lg = word & 0xFF; - rg = word >> 8 & 0xFF; - lg = (lg * mask + mask / 2) / 100; - rg = (rg * mask + mask / 2) / 100; - *left = gp->min_gain + gp->gain_step * lg; - *right = gp->min_gain + gp->gain_step * rg; - return 0; - } - -And here is the corresponding routine to set a channel's gain in dB. - - int set_gain_dB(int fd, const gain_desc_t *gp, float left, float right) - { - float max_gain = - gp->min_gain + (1 << gp->nbits) * gp->gain_step; - float round = gp->gain_step / 2; - int mask = (1 << gp->nbits) - 1; - int word; - int lg, rg; - - if (left < gp->min_gain || right < gp->min_gain) - return EINVAL; - lg = (left - gp->min_gain + round) / gp->gain_step; - rg = (right - gp->min_gain + round) / gp->gain_step; - if (lg >= (1 << gp->nbits) || rg >= (1 << gp->nbits)) - return EINVAL; - lg = (100 * lg + mask / 2) / mask; - rg = (100 * rg + mask / 2) / mask; - word = lg | rg << 8; - - return ioctl(fd, MIXER_WRITE(gp->chan), &word); - } - diff --git a/Documentation/spi/spidev b/Documentation/spi/spidev index ed2da5e..3d14035 100644 --- a/Documentation/spi/spidev +++ b/Documentation/spi/spidev @@ -85,6 +85,12 @@ settings for data transfer parameters: SPI_MODE_0..SPI_MODE_3; or if you prefer you can combine SPI_CPOL (clock polarity, idle high iff this is set) or SPI_CPHA (clock phase, sample on trailing edge iff this is set) flags. + Note that this request is limited to SPI mode flags that fit in a + single byte. + + SPI_IOC_RD_MODE32, SPI_IOC_WR_MODE32 ... pass a pointer to a uin32_t + which will return (RD) or assign (WR) the full SPI transfer mode, + not limited to the bits that fit in one byte. SPI_IOC_RD_LSB_FIRST, SPI_IOC_WR_LSB_FIRST ... pass a pointer to a byte which will return (RD) or assign (WR) the bit justification used to diff --git a/Documentation/spi/spidev_fdx.c b/Documentation/spi/spidev_fdx.c index 36ec077..0ea3e51 100644 --- a/Documentation/spi/spidev_fdx.c +++ b/Documentation/spi/spidev_fdx.c @@ -78,10 +78,10 @@ static void do_msg(int fd, int len) static void dumpstat(const char *name, int fd) { - __u8 mode, lsb, bits; - __u32 speed; + __u8 lsb, bits; + __u32 mode, speed; - if (ioctl(fd, SPI_IOC_RD_MODE, &mode) < 0) { + if (ioctl(fd, SPI_IOC_RD_MODE32, &mode) < 0) { perror("SPI rd_mode"); return; } @@ -98,7 +98,7 @@ static void dumpstat(const char *name, int fd) return; } - printf("%s: spi mode %d, %d bits %sper word, %d Hz max\n", + printf("%s: spi mode 0x%x, %d bits %sper word, %d Hz max\n", name, mode, bits, lsb ? "(lsb first) " : "", speed); } diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c index 16feda9..3a2f9d5 100644 --- a/Documentation/spi/spidev_test.c +++ b/Documentation/spi/spidev_test.c @@ -30,7 +30,7 @@ static void pabort(const char *s) } static const char *device = "/dev/spidev1.1"; -static uint8_t mode; +static uint32_t mode; static uint8_t bits = 8; static uint32_t speed = 500000; static uint16_t delay; @@ -57,6 +57,21 @@ static void transfer(int fd) .bits_per_word = bits, }; + if (mode & SPI_TX_QUAD) + tr.tx_nbits = 4; + else if (mode & SPI_TX_DUAL) + tr.tx_nbits = 2; + if (mode & SPI_RX_QUAD) + tr.rx_nbits = 4; + else if (mode & SPI_RX_DUAL) + tr.rx_nbits = 2; + if (!(mode & SPI_LOOP)) { + if (mode & (SPI_TX_QUAD | SPI_TX_DUAL)) + tr.rx_buf = 0; + else if (mode & (SPI_RX_QUAD | SPI_RX_DUAL)) + tr.tx_buf = 0; + } + ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr); if (ret < 1) pabort("can't send spi message"); @@ -81,7 +96,11 @@ static void print_usage(const char *prog) " -O --cpol clock polarity\n" " -L --lsb least significant bit first\n" " -C --cs-high chip select active high\n" - " -3 --3wire SI/SO signals shared\n"); + " -3 --3wire SI/SO signals shared\n" + " -N --no-cs no chip select\n" + " -R --ready slave pulls low to pause\n" + " -2 --dual dual transfer\n" + " -4 --quad quad transfer\n"); exit(1); } @@ -101,11 +120,13 @@ static void parse_opts(int argc, char *argv[]) { "3wire", 0, 0, '3' }, { "no-cs", 0, 0, 'N' }, { "ready", 0, 0, 'R' }, + { "dual", 0, 0, '2' }, + { "quad", 0, 0, '4' }, { NULL, 0, 0, 0 }, }; int c; - c = getopt_long(argc, argv, "D:s:d:b:lHOLC3NR", lopts, NULL); + c = getopt_long(argc, argv, "D:s:d:b:lHOLC3NR24", lopts, NULL); if (c == -1) break; @@ -147,11 +168,23 @@ static void parse_opts(int argc, char *argv[]) case 'R': mode |= SPI_READY; break; + case '2': + mode |= SPI_TX_DUAL; + break; + case '4': + mode |= SPI_TX_QUAD; + break; default: print_usage(argv[0]); break; } } + if (mode & SPI_LOOP) { + if (mode & SPI_TX_DUAL) + mode |= SPI_RX_DUAL; + if (mode & SPI_TX_QUAD) + mode |= SPI_RX_QUAD; + } } int main(int argc, char *argv[]) @@ -168,11 +201,11 @@ int main(int argc, char *argv[]) /* * spi mode */ - ret = ioctl(fd, SPI_IOC_WR_MODE, &mode); + ret = ioctl(fd, SPI_IOC_WR_MODE32, &mode); if (ret == -1) pabort("can't set spi mode"); - ret = ioctl(fd, SPI_IOC_RD_MODE, &mode); + ret = ioctl(fd, SPI_IOC_RD_MODE32, &mode); if (ret == -1) pabort("can't get spi mode"); @@ -198,7 +231,7 @@ int main(int argc, char *argv[]) if (ret == -1) pabort("can't get max speed hz"); - printf("spi mode: %d\n", mode); + printf("spi mode: 0x%x\n", mode); printf("bits per word: %d\n", bits); printf("max speed: %d Hz (%d KHz)\n", speed, speed/1000); diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index e55124e..ec8be46 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -320,10 +320,11 @@ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. ============================================================== -hung_task_warning: +hung_task_warnings: The maximum number of warnings to report. During a check interval -When this value is reached, no more the warnings will be reported. +if a hung task is detected, this value is decreased by 1. +When this value reaches 0, no more warnings will be reported. This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. -1: report an infinite number of warnings. @@ -441,8 +442,7 @@ feature should be disabled. Otherwise, if the system overhead from the feature is too high then the rate the kernel samples for NUMA hinting faults may be controlled by the numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, -numa_balancing_scan_size_mb, numa_balancing_settle_count sysctls and -numa_balancing_migrate_deferred. +numa_balancing_scan_size_mb, and numa_balancing_settle_count sysctls. ============================================================== @@ -483,13 +483,6 @@ rate for each task. numa_balancing_scan_size_mb is how many megabytes worth of pages are scanned for a given scan. -numa_balancing_migrate_deferred is how many page migrations get skipped -unconditionally, after a page migration is skipped because a page is shared -with other tasks. This reduces page migration overhead, and determines -how much stronger the "move task near its memory" policy scheduler becomes, -versus the "move memory near its task" memory management policy, for workloads -with shared memory. - ============================================================== osrelease, ostype & version: diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt index 3bd33b8..21d514c 100644 --- a/Documentation/trace/events-power.txt +++ b/Documentation/trace/events-power.txt @@ -92,5 +92,5 @@ dev_pm_qos_remove_request "device=%s type=%s new_value=%d" The first parameter gives the device name which tries to add/update/remove QoS requests. -The second parameter gives the request type (e.g. "DEV_PM_QOS_LATENCY"). +The second parameter gives the request type (e.g. "DEV_PM_QOS_RESUME_LATENCY"). The third parameter is value to be added/updated/removed. diff --git a/Documentation/trace/ring-buffer-design.txt b/Documentation/trace/ring-buffer-design.txt index 7d350b4..ff747b6 100644 --- a/Documentation/trace/ring-buffer-design.txt +++ b/Documentation/trace/ring-buffer-design.txt @@ -683,7 +683,7 @@ against nested writers. cmpxchg(tail_page, temp_page, next_page) The above will update the tail page if it is still pointing to the expected -page. If this fails, a nested write pushed it forward, the the current write +page. If this fails, a nested write pushed it forward, the current write does not need to push it. diff --git a/Documentation/usb/WUSB-Design-overview.txt b/Documentation/usb/WUSB-Design-overview.txt index 4c5e379..1cd07c0 100644 --- a/Documentation/usb/WUSB-Design-overview.txt +++ b/Documentation/usb/WUSB-Design-overview.txt @@ -25,7 +25,7 @@ updated content. * Design-overview.txt-1.8 This code implements a Ultra Wide Band stack for Linux, as well as -drivers for the the USB based UWB radio controllers defined in the +drivers for the USB based UWB radio controllers defined in the Wireless USB 1.0 specification (including Wireless USB host controller and an Intel WiNET controller). diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 6cd63a9..a9380ba5 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -586,8 +586,8 @@ struct kvm_fpu { 4.24 KVM_CREATE_IRQCHIP -Capability: KVM_CAP_IRQCHIP -Architectures: x86, ia64, ARM, arm64 +Capability: KVM_CAP_IRQCHIP, KVM_CAP_S390_IRQCHIP (s390) +Architectures: x86, ia64, ARM, arm64, s390 Type: vm ioctl Parameters: none Returns: 0 on success, -1 on error @@ -596,7 +596,10 @@ Creates an interrupt controller model in the kernel. On x86, creates a virtual ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23 only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is -created. +created. On s390, a dummy irq routing table is created. + +Note that on s390 the KVM_CAP_S390_IRQCHIP vm capability needs to be enabled +before KVM_CREATE_IRQCHIP can be used. 4.25 KVM_IRQ_LINE @@ -612,6 +615,20 @@ On some architectures it is required that an interrupt controller model has been previously created with KVM_CREATE_IRQCHIP. Note that edge-triggered interrupts require the level to be set to 1 and then back to 0. +On real hardware, interrupt pins can be active-low or active-high. This +does not matter for the level field of struct kvm_irq_level: 1 always +means active (asserted), 0 means inactive (deasserted). + +x86 allows the operating system to program the interrupt polarity +(active-low/active-high) for level-triggered interrupts, and KVM used +to consider the polarity. However, due to bitrot in the handling of +active-low interrupts, the above convention is now valid on x86 too. +This is signaled by KVM_CAP_X86_IOAPIC_POLARITY_IGNORED. Userspace +should not present interrupts to the guest as active-low unless this +capability is present (or unless it is not using the in-kernel irqchip, +of course). + + ARM/arm64 can signal an interrupt either at the CPU level, or at the in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for specific cpus. The irq field is interpreted @@ -628,7 +645,7 @@ The irq_type field has the following values: (The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs) -In both cases, level is used to raise/lower the line. +In both cases, level is used to assert/deassert the line. struct kvm_irq_level { union { @@ -918,9 +935,9 @@ documentation when it pops into existence). 4.37 KVM_ENABLE_CAP -Capability: KVM_CAP_ENABLE_CAP +Capability: KVM_CAP_ENABLE_CAP, KVM_CAP_ENABLE_CAP_VM Architectures: ppc, s390 -Type: vcpu ioctl +Type: vcpu ioctl, vm ioctl (with KVM_CAP_ENABLE_CAP_VM) Parameters: struct kvm_enable_cap (in) Returns: 0 on success; -1 on error @@ -951,6 +968,8 @@ function properly, this is the place to put them. __u8 pad[64]; }; +The vcpu ioctl should be used for vcpu-specific capabilities, the vm ioctl +for vm-wide capabilities. 4.38 KVM_GET_MP_STATE @@ -1320,7 +1339,7 @@ KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed. 4.52 KVM_SET_GSI_ROUTING Capability: KVM_CAP_IRQ_ROUTING -Architectures: x86 ia64 +Architectures: x86 ia64 s390 Type: vm ioctl Parameters: struct kvm_irq_routing (in) Returns: 0 on success, -1 on error @@ -1343,6 +1362,7 @@ struct kvm_irq_routing_entry { union { struct kvm_irq_routing_irqchip irqchip; struct kvm_irq_routing_msi msi; + struct kvm_irq_routing_s390_adapter adapter; __u32 pad[8]; } u; }; @@ -1350,6 +1370,7 @@ struct kvm_irq_routing_entry { /* gsi routing entry types */ #define KVM_IRQ_ROUTING_IRQCHIP 1 #define KVM_IRQ_ROUTING_MSI 2 +#define KVM_IRQ_ROUTING_S390_ADAPTER 3 No flags are specified so far, the corresponding field must be set to zero. @@ -1365,6 +1386,14 @@ struct kvm_irq_routing_msi { __u32 pad; }; +struct kvm_irq_routing_s390_adapter { + __u64 ind_addr; + __u64 summary_addr; + __u64 ind_offset; + __u32 summary_offset; + __u32 adapter_id; +}; + 4.53 KVM_ASSIGN_SET_MSIX_NR @@ -1462,7 +1491,7 @@ struct kvm_lapic_state { char regs[KVM_APIC_REG_SIZE]; }; -Copies the input argument into the the Local APIC registers. The data format +Copies the input argument into the Local APIC registers. The data format and layout are the same as documented in the architecture manual. @@ -2566,6 +2595,10 @@ executed a memory-mapped I/O instruction which could not be satisfied by kvm. The 'data' member contains the written data if 'is_write' is true, and should be filled by application code otherwise. +The 'data' member contains, in its first 'len' bytes, the value as it would +appear if the VCPU performed a load or store of the appropriate width directly +to the byte array. + NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR, KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding operations are complete (and guest state is consistent) only after userspace diff --git a/Documentation/virtual/kvm/devices/s390_flic.txt b/Documentation/virtual/kvm/devices/s390_flic.txt new file mode 100644 index 0000000..4ceef53 --- /dev/null +++ b/Documentation/virtual/kvm/devices/s390_flic.txt @@ -0,0 +1,91 @@ +FLIC (floating interrupt controller) +==================================== + +FLIC handles floating (non per-cpu) interrupts, i.e. I/O, service and some +machine check interruptions. All interrupts are stored in a per-vm list of +pending interrupts. FLIC performs operations on this list. + +Only one FLIC instance may be instantiated. + +FLIC provides support to +- add interrupts (KVM_DEV_FLIC_ENQUEUE) +- inspect currently pending interrupts (KVM_FLIC_GET_ALL_IRQS) +- purge all pending floating interrupts (KVM_DEV_FLIC_CLEAR_IRQS) +- enable/disable for the guest transparent async page faults +- register and modify adapter interrupt sources (KVM_DEV_FLIC_ADAPTER_*) + +Groups: + KVM_DEV_FLIC_ENQUEUE + Passes a buffer and length into the kernel which are then injected into + the list of pending interrupts. + attr->addr contains the pointer to the buffer and attr->attr contains + the length of the buffer. + The format of the data structure kvm_s390_irq as it is copied from userspace + is defined in usr/include/linux/kvm.h. + + KVM_DEV_FLIC_GET_ALL_IRQS + Copies all floating interrupts into a buffer provided by userspace. + When the buffer is too small it returns -ENOMEM, which is the indication + for userspace to try again with a bigger buffer. + All interrupts remain pending, i.e. are not deleted from the list of + currently pending interrupts. + attr->addr contains the userspace address of the buffer into which all + interrupt data will be copied. + attr->attr contains the size of the buffer in bytes. + + KVM_DEV_FLIC_CLEAR_IRQS + Simply deletes all elements from the list of currently pending floating + interrupts. No interrupts are injected into the guest. + + KVM_DEV_FLIC_APF_ENABLE + Enables async page faults for the guest. So in case of a major page fault + the host is allowed to handle this async and continues the guest. + + KVM_DEV_FLIC_APF_DISABLE_WAIT + Disables async page faults for the guest and waits until already pending + async page faults are done. This is necessary to trigger a completion interrupt + for every init interrupt before migrating the interrupt list. + + KVM_DEV_FLIC_ADAPTER_REGISTER + Register an I/O adapter interrupt source. Takes a kvm_s390_io_adapter + describing the adapter to register: + +struct kvm_s390_io_adapter { + __u32 id; + __u8 isc; + __u8 maskable; + __u8 swap; + __u8 pad; +}; + + id contains the unique id for the adapter, isc the I/O interruption subclass + to use, maskable whether this adapter may be masked (interrupts turned off) + and swap whether the indicators need to be byte swapped. + + + KVM_DEV_FLIC_ADAPTER_MODIFY + Modifies attributes of an existing I/O adapter interrupt source. Takes + a kvm_s390_io_adapter_req specifiying the adapter and the operation: + +struct kvm_s390_io_adapter_req { + __u32 id; + __u8 type; + __u8 mask; + __u16 pad0; + __u64 addr; +}; + + id specifies the adapter and type the operation. The supported operations + are: + + KVM_S390_IO_ADAPTER_MASK + mask or unmask the adapter, as specified in mask + + KVM_S390_IO_ADAPTER_MAP + perform a gmap translation for the guest address provided in addr, + pin a userspace page for the translated address and add it to the + list of mappings + + KVM_S390_IO_ADAPTER_UNMAP + release a userspace page for the translated address specified in addr + from the list of mappings diff --git a/Documentation/vm/unevictable-lru.txt b/Documentation/vm/unevictable-lru.txt index a68db769..744f82f 100644 --- a/Documentation/vm/unevictable-lru.txt +++ b/Documentation/vm/unevictable-lru.txt @@ -453,7 +453,7 @@ putback_lru_page() function to add migrated pages back to the LRU. mmap(MAP_LOCKED) SYSTEM CALL HANDLING ------------------------------------- -In addition the the mlock()/mlockall() system calls, an application can request +In addition the mlock()/mlockall() system calls, an application can request that a region of memory be mlocked supplying the MAP_LOCKED flag to the mmap() call. Furthermore, any mmap() call or brk() call that expands the heap by a task that has previously called mlockall() with the MCL_FUTURE flag will result diff --git a/Documentation/w1/masters/ds2490 b/Documentation/w1/masters/ds2490 index 28176de..3e09115 100644 --- a/Documentation/w1/masters/ds2490 +++ b/Documentation/w1/masters/ds2490 @@ -21,8 +21,6 @@ Notes and limitations. - The weak pullup current is a minimum of 0.9mA and maximum of 6.0mA. - The 5V strong pullup is supported with a minimum of 5.9mA and a maximum of 30.4 mA. (From DS2490.pdf) -- While the ds2490 supports a hardware search the code doesn't take - advantage of it (in tested case it only returned first device). - The hardware will detect when devices are attached to the bus on the next bus (reset?) operation, however only a message is printed as the core w1 code doesn't make use of the information. Connecting diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink index f59a319..927a52c 100644 --- a/Documentation/w1/w1.netlink +++ b/Documentation/w1/w1.netlink @@ -5,8 +5,8 @@ Message types. ============= There are three types of messages between w1 core and userspace: -1. Events. They are generated each time new master or slave device - found either due to automatic or requested search. +1. Events. They are generated each time a new master or slave device + is found either due to automatic or requested search. 2. Userspace commands. 3. Replies to userspace commands. @@ -131,7 +131,7 @@ of the w1_netlink_cmd structure and cn_msg.len will be equal to the sum of the sizeof(struct w1_netlink_msg) and sizeof(struct w1_netlink_cmd). If reply is generated for master or root command (which do not have w1_netlink_cmd attached), reply will contain only cn_msg and w1_netlink_msg -structires. +structures. w1_netlink_msg.status field will carry positive error value (EINVAL for example) or zero in case of success. @@ -160,7 +160,7 @@ procedure is started to select given device. Then all requested in w1_netlink_msg operations are performed one by one. If command requires reply (like read command) it is sent on command completion. -When all commands (w1_netlink_cmd) are processed muster device is unlocked +When all commands (w1_netlink_cmd) are processed master device is unlocked and next w1_netlink_msg header processing started. diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt index f9492fe..692791c 100644 --- a/Documentation/watchdog/watchdog-parameters.txt +++ b/Documentation/watchdog/watchdog-parameters.txt @@ -150,6 +150,8 @@ nowayout: Disable watchdog shutdown on close ------------------------------------------------- it87_wdt: nogameport: Forbid the activation of game port, default=0 +nocir: Forbid the use of CIR (workaround for some buggy setups); set to 1 if +system resets despite watchdog daemon running, default=0 exclusive: Watchdog exclusive device open, default=1 timeout: Watchdog timeout in seconds, default=60 testmode: Watchdog test mode (1 = no reboot), default=0 @@ -325,6 +327,11 @@ soft_noboot: Softdog action, set to 1 to ignore reboots, 0 to reboot stmp3xxx_wdt: heartbeat: Watchdog heartbeat period in seconds from 1 to 4194304, default 19 ------------------------------------------------- +tegra_wdt: +heartbeat: Watchdog heartbeats in seconds. (default = 120) +nowayout: Watchdog cannot be stopped once started + (default=kernel config parameter) +------------------------------------------------- ts72xx_wdt: timeout: Watchdog timeout in seconds. (1 <= timeout <= 8, default=8) nowayout: Disable watchdog shutdown on close diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index cb81741d..a75e3ad 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -182,7 +182,7 @@ Offset Proto Name Meaning 0226/1 2.02+(3 ext_loader_ver Extended boot loader version 0227/1 2.02+(3 ext_loader_type Extended boot loader ID 0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line -022C/4 2.03+ ramdisk_max Highest legal initrd address +022C/4 2.03+ initrd_addr_max Highest legal initrd address 0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel 0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not 0235/1 2.10+ min_alignment Minimum alignment, as a power of two @@ -534,7 +534,7 @@ Protocol: 2.02+ zero, the kernel will assume that your boot loader does not support the 2.02+ protocol. -Field name: ramdisk_max +Field name: initrd_addr_max Type: read Offset/size: 0x22c/4 Protocol: 2.03+ |