diff options
Diffstat (limited to 'Documentation')
383 files changed, 13186 insertions, 8875 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 7f3a072..708dc4c 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -66,8 +66,6 @@ backlight/ - directory with info on controlling backlights in flat panel displays bcache.txt - Block-layer cache on fast SSDs to improve slow (raid) I/O performance. -blackfin/ - - directory with documentation for the Blackfin arch. block/ - info on the Block I/O (BIO) layer. blockdev/ @@ -114,8 +112,6 @@ cputopology.txt - documentation on how CPU topology info is exported via sysfs. crc32.txt - brief tutorial on CRC computation -cris/ - - directory with info about Linux on CRIS architecture. crypto/ - directory with info on the Crypto API. dcdbas.txt @@ -172,8 +168,6 @@ fmc/ - information about the FMC bus abstraction fpga/ - FPGA Manager Core. -frv/ - - Fujitsu FR-V Linux documentation. futex-requeue-pi.txt - info on requeueing of tasks from a non-PI futex to a PI futex gcc-plugins.txt @@ -276,8 +270,6 @@ memory-hotplug.txt - Hotpluggable memory support, how to use and current status. men-chameleon-bus.txt - info on MEN chameleon bus. -metag/ - - directory with info about Linux on Meta architecture. mic/ - Intel Many Integrated Core (MIC) architecture device driver. mips/ @@ -286,8 +278,6 @@ misc-devices/ - directory with info about devices using the misc dev subsystem mmc/ - directory with info about the MMC subsystem -mn10300/ - - directory with info about the mn10300 architecture port mtd/ - directory with info about memory technology devices (flash) namespaces/ diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus b/Documentation/ABI/stable/sysfs-bus-vmbus index e46be65..0c9d9dc 100644 --- a/Documentation/ABI/stable/sysfs-bus-vmbus +++ b/Documentation/ABI/stable/sysfs-bus-vmbus @@ -132,3 +132,10 @@ KernelVersion: 4.16 Contact: Stephen Hemminger <sthemmin@microsoft.com> Description: Monitor bit associated with channel Users: Debugging tools and userspace drivers + +What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/ring +Date: January. 2018 +KernelVersion: 4.16 +Contact: Stephen Hemminger <sthemmin@microsoft.com> +Description: Binary file created by uio_hv_generic for ring buffer +Users: Userspace drivers diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband new file mode 100644 index 0000000..17211ce --- /dev/null +++ b/Documentation/ABI/stable/sysfs-class-infiniband @@ -0,0 +1,818 @@ +sysfs interface common for all infiniband devices +------------------------------------------------- + +What: /sys/class/infiniband/<device>/node_type +What: /sys/class/infiniband/<device>/node_guid +What: /sys/class/infiniband/<device>/sys_image_guid +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: linux-rdma@vger.kernel.org +Description: + node_type: (RO) Node type (CA, RNIC, usNIC, usNIC UDP, + switch or router) + + node_guid: (RO) Node GUID + + sys_image_guid: (RO) System image GUID + + +What: /sys/class/infiniband/<device>/node_desc +Date: Feb, 2006 +KernelVersion: v2.6.17 +Contact: linux-rdma@vger.kernel.org +Description: + (RW) Update the node description with information such as the + node's hostname, so that IB network management software can tie + its view to the real world. + + +What: /sys/class/infiniband/<device>/fw_ver +Date: Jun, 2016 +KernelVersion: v4.10 +Contact: linux-rdma@vger.kernel.org +Description: + (RO) Display firmware version + + +What: /sys/class/infiniband/<device>/ports/<port-num>/lid +What: /sys/class/infiniband/<device>/ports/<port-num>/rate +What: /sys/class/infiniband/<device>/ports/<port-num>/lid_mask_count +What: /sys/class/infiniband/<device>/ports/<port-num>/sm_sl +What: /sys/class/infiniband/<device>/ports/<port-num>/sm_lid +What: /sys/class/infiniband/<device>/ports/<port-num>/state +What: /sys/class/infiniband/<device>/ports/<port-num>/phys_state +What: /sys/class/infiniband/<device>/ports/<port-num>/cap_mask +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: linux-rdma@vger.kernel.org +Description: + + lid: (RO) Port LID + + rate: (RO) Port data rate (active width * active + speed) + + lid_mask_count: (RO) Port LID mask count + + sm_sl: (RO) Subnet manager SL for port's subnet + + sm_lid: (RO) Subnet manager LID for port's subnet + + state: (RO) Port state (DOWN, INIT, ARMED, ACTIVE or + ACTIVE_DEFER) + + phys_state: (RO) Port physical state (Sleep, Polling, + LinkUp, etc) + + cap_mask: (RO) Port capability mask. 2 bits here are + settable- IsCommunicationManagementSupported + (set when CM module is loaded) and IsSM (set via + open of issmN file). + + +What: /sys/class/infiniband/<device>/ports/<port-num>/link_layer +Date: Oct, 2010 +KernelVersion: v2.6.37 +Contact: linux-rdma@vger.kernel.org +Description: + (RO) Link layer type information (Infiniband or Ethernet type) + + +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/symbol_error +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_errors +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_remote_physical_errors +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_switch_relay_errors +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/link_error_recovery +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_constraint_errors +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_contraint_errors +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/local_link_integrity_errors +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/excessive_buffer_overrun_errors +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_data +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_data +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_packets +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_packets +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/unicast_rcv_packets +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/unicast_xmit_packets +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/multicast_rcv_packets +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/multicast_xmit_packets +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/link_downed +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_discards +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/VL15_dropped +What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_wait +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: linux-rdma@vger.kernel.org +Description: + Errors info: + ----------- + + symbol_error: (RO) Total number of minor link errors detected on + one or more physical lanes. + + port_rcv_errors : (RO) Total number of packets containing an + error that were received on the port. + + port_rcv_remote_physical_errors : (RO) Total number of packets + marked with the EBP delimiter received on the port. + + port_rcv_switch_relay_errors : (RO) Total number of packets + received on the port that were discarded because they could not + be forwarded by the switch relay. + + link_error_recovery: (RO) Total number of times the Port + Training state machine has successfully completed the link error + recovery process. + + port_xmit_constraint_errors: (RO) Total number of packets not + transmitted from the switch physical port due to outbound raw + filtering or failing outbound partition or IP version check. + + port_rcv_constraint_errors: (RO) Total number of packets + received on the switch physical port that are discarded due to + inbound raw filtering or failing inbound partition or IP version + check. + + local_link_integrity_errors: (RO) The number of times that the + count of local physical errors exceeded the threshold specified + by LocalPhyErrors + + excessive_buffer_overrun_errors: (RO) This counter, indicates an + input buffer overrun. It indicates possible misconfiguration of + a port, either by the Subnet Manager (SM) or by user + intervention. It can also indicate hardware issues or extremely + poor link signal integrity + + Data info: + --------- + + port_xmit_data: (RO) Total number of data octets, divided by 4 + (lanes), transmitted on all VLs. This is 64 bit counter + + port_rcv_data: (RO) Total number of data octets, divided by 4 + (lanes), received on all VLs. This is 64 bit counter. + + port_xmit_packets: (RO) Total number of packets transmitted on + all VLs from this port. This may include packets with errors. + This is 64 bit counter. + + port_rcv_packets: (RO) Total number of packets (this may include + packets containing Errors. This is 64 bit counter. + + link_downed: (RO) Total number of times the Port Training state + machine has failed the link error recovery process and downed + the link. + + unicast_rcv_packets: (RO) Total number of unicast packets, + including unicast packets containing errors. + + unicast_xmit_packets: (RO) Total number of unicast packets + transmitted on all VLs from the port. This may include unicast + packets with errors. + + multicast_rcv_packets: (RO) Total number of multicast packets, + including multicast packets containing errors. + + multicast_xmit_packets: (RO) Total number of multicast packets + transmitted on all VLs from the port. This may include multicast + packets with errors. + + Misc info: + --------- + + port_xmit_discards: (RO) Total number of outbound packets + discarded by the port because the port is down or congested. + + VL15_dropped: (RO) Number of incoming VL15 packets dropped due + to resource limitations (e.g., lack of buffers) of the port. + + port_xmit_wait: (RO) The number of ticks during which the port + had data to transmit but no data was sent during the entire tick + (either because of insufficient credits or because of lack of + arbitration). + + Each of these files contains the corresponding value from the + port's Performance Management PortCounters attribute, as + described in the InfiniBand Architecture Specification. + + +What: /sys/class/infiniband/<device-name>/hw_counters/lifespan +What: /sys/class/infiniband/<device-name>/ports/<port-num>/hw_counters/lifespan +Date: May, 2016 +KernelVersion: 4.6 +Contact: linux-rdma@vger.kernel.org +Description: + The optional "hw_counters" subdirectory can be under either the + parent device or the port subdirectories or both. If present, + there are a list of counters provided by the hardware. They may + match some of the counters in the counters directory, but they + often include many other counters. In addition to the various + counters, there will be a file named "lifespan" that configures + how frequently the core should update the counters when they are + being accessed (counters are not updated if they are not being + accessed). The lifespan is in milliseconds and defaults to 10 + unless set to something else by the driver. Users may echo a + value between 0-10000 to the lifespan file to set the length + of time between updates in milliseconds. + + +What: /sys/class/infiniband/<hca>/ports/<port-number>/gid_attrs/ndevs/<gid-index> +Date: November 29, 2015 +KernelVersion: 4.4.0 +Contact: linux-rdma@vger.kernel.org +Description: The net-device's name associated with the GID resides + at index <gid-index>. + +What: /sys/class/infiniband/<hca>/ports/<port-number>/gid_attrs/types/<gid-index> +Date: November 29, 2015 +KernelVersion: 4.4.0 +Contact: linux-rdma@vger.kernel.org +Description: The RoCE type of the associated GID resides at index <gid-index>. + This could either be "IB/RoCE v1" for IB and RoCE v1 based GIDs + or "RoCE v2" for RoCE v2 based GIDs. + + +What: /sys/class/infiniband_mad/umadN/ibdev +What: /sys/class/infiniband_mad/umadN/port +What: /sys/class/infiniband_mad/issmN/ibdev +What: /sys/class/infiniband_mad/issmN/port +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: linux-rdma@vger.kernel.org +Description: + Each port of each InfiniBand device has a "umad" device and an + "issm" device attached. For example, a two-port HCA will have + two umad devices and two issm devices, while a switch will have + one device of each type (for switch port 0). + + ibdev: (RO) Show Infiniband (IB) device name + + port: (RO) Display port number + + +What: /sys/class/infiniband_mad/abi_version +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: linux-rdma@vger.kernel.org +Description: + (RO) Value is incremented if any changes are made that break + userspace ABI compatibility of umad & issm devices. + + +What: /sys/class/infiniband_cm/ucmN/ibdev +Date: Oct, 2005 +KernelVersion: v2.6.14 +Contact: linux-rdma@vger.kernel.org +Description: + (RO) Display Infiniband (IB) device name + + +What: /sys/class/infiniband_cm/abi_version +Date: Oct, 2005 +KernelVersion: v2.6.14 +Contact: linux-rdma@vger.kernel.org +Description: + (RO) Value is incremented if any changes are made that break + userspace ABI compatibility of ucm devices. + + +What: /sys/class/infiniband_verbs/uverbsN/ibdev +What: /sys/class/infiniband_verbs/uverbsN/abi_version +Date: Sept, 2005 +KernelVersion: v2.6.14 +Contact: linux-rdma@vger.kernel.org +Description: + ibdev: (RO) Display Infiniband (IB) device name + + abi_version: (RO) Show ABI version of IB device specific + interfaces. + + +What: /sys/class/infiniband_verbs/abi_version +Date: Sep, 2005 +KernelVersion: v2.6.14 +Contact: linux-rdma@vger.kernel.org +Description: + (RO) Value is incremented if any changes are made that break + userspace ABI compatibility of uverbs devices. + + +sysfs interface for Mellanox IB HCA low-level driver (mthca) +------------------------------------------------------------ + +What: /sys/class/infiniband/mthcaX/hw_rev +What: /sys/class/infiniband/mthcaX/hca_type +What: /sys/class/infiniband/mthcaX/board_id +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: linux-rdma@vger.kernel.org +Description: + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Host Channel Adapter type: MT23108, MT25208 + (MT23108 compat mode), MT25208 or MT25204 + + board_id: (RO) Manufacturing board ID + + +sysfs interface for Chelsio T3 RDMA Driver (cxgb3) +-------------------------------------------------- + +What: /sys/class/infiniband/cxgb3_X/hw_rev +What: /sys/class/infiniband/cxgb3_X/hca_type +What: /sys/class/infiniband/cxgb3_X/board_id +Date: Feb, 2007 +KernelVersion: v2.6.21 +Contact: linux-rdma@vger.kernel.org +Description: + hw_rev: (RO) Hardware revision number + + hca_type: (RO) HCA type. Here it is a driver short name. + It should normally match the name in its bus + driver structure (e.g. pci_driver::name). + + board_id: (RO) Manufacturing board id + + +sysfs interface for Mellanox ConnectX HCA IB driver (mlx4) +---------------------------------------------------------- + +What: /sys/class/infiniband/mlx4_X/hw_rev +What: /sys/class/infiniband/mlx4_X/hca_type +What: /sys/class/infiniband/mlx4_X/board_id +Date: Sep, 2007 +KernelVersion: v2.6.24 +Contact: linux-rdma@vger.kernel.org +Description: + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Host channel adapter type + + board_id: (RO) Manufacturing board ID + + +What: /sys/class/infiniband/mlx4_X/iov/ports/<port-num>/gids/<n> +What: /sys/class/infiniband/mlx4_X/iov/ports/<port-num>/admin_guids/<n> +What: /sys/class/infiniband/mlx4_X/iov/ports/<port-num>/pkeys/<n> +What: /sys/class/infiniband/mlx4_X/iov/ports/<port-num>/mcgs/ +What: /sys/class/infiniband/mlx4_X/iov/ports/<pci-slot-num>/ports/<m>/gid_idx/0 +What: /sys/class/infiniband/mlx4_X/iov/ports/<pci-slot-num>/ports/<m>/pkey_idx/<n> +Date: Aug, 2012 +KernelVersion: v3.6.15 +Contact: linux-rdma@vger.kernel.org +Description: + The sysfs iov directory is used to manage and examine the port + P_Key and guid paravirtualization. This directory is added only + for the master -- slaves do not have it. + + Under iov/ports, the administrator may examine the gid and P_Key + tables as they are present in the device (and as are seen in the + "network view" presented to the SM). + + The "pkeys" and "gids" subdirectories contain one file for each + entry in the port's P_Key or GID table respectively. For + example, ports/1/pkeys/10 contains the value at index 10 in port + 1's P_Key table. + + gids/<n>: (RO) The physical port gids n = 0..127 + + admin_guids/<n>: (RW) Allows examining or changing the + administrative state of a given GUID + n = 0..127 + + pkeys/<n>: (RO) Displays the contents of the physical + key table n = 0..126 + + mcgs/: (RO) Muticast group table + + <m>/gid_idx/0: (RO) Display the GID mapping m = 1..2 + + <m>/pkey_idx/<n>: (RW) Writable except for RoCE pkeys. + m = 1..2, n = 0..126 + + Under the iov/<pci slot number> + directories, the admin may map the index + numbers in the physical tables (as under + iov/ports) to the paravirtualized index + numbers that guests see. + + For example, if the administrator, for + port 1 on guest 2 maps physical pkey + index 10 to virtual index 1, then that + guest, whenever it uses its pkey index + 1, will actually be using the real pkey + index 10. + + +What: /sys/class/infiniband/mlx4_X/iov/<pci-slot-num>/ports/<m>/smi_enabled +What: /sys/class/infiniband/mlx4_X/iov/<pci-slot-num>/ports/<m>/enable_smi_admin +Date: May, 2014 +KernelVersion: v3.15.7 +Contact: linux-rdma@vger.kernel.org +Description: + Enabling QP0 on VFs for selected VF/port. By default, no VFs are + enabled for QP0 operation. + + smi_enabled: (RO) Indicates whether smi is currently enabled + for the indicated VF/port + + enable_smi_admin:(RW) Used by the admin to request that smi + capability be enabled or disabled for the + indicated VF/port. 0 = disable, 1 = enable. + + The requested enablement will occur at the next reset of the VF + (e.g. driver restart on the VM which owns the VF). + + +sysfs interface for NetEffect RNIC Low-Level iWARP driver (nes) +--------------------------------------------------------------- + +What: /sys/class/infiniband/nesX/hw_rev +What: /sys/class/infiniband/nesX/hca_type +What: /sys/class/infiniband/nesX/board_id +Date: Feb, 2008 +KernelVersion: v2.6.25 +Contact: linux-rdma@vger.kernel.org +Description: + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Host Channel Adapter type (NEX020) + + board_id: (RO) Manufacturing board id + + +sysfs interface for Chelsio T4/T5 RDMA driver (cxgb4) +----------------------------------------------------- + +What: /sys/class/infiniband/cxgb4_X/hw_rev +What: /sys/class/infiniband/cxgb4_X/hca_type +What: /sys/class/infiniband/cxgb4_X/board_id +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: linux-rdma@vger.kernel.org +Description: + + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Driver short name. Should normally match + the name in its bus driver structure (e.g. + pci_driver::name) + + board_id: (RO) Manufacturing board id. (Vendor + device + information) + + +sysfs interface for Intel IB driver qib +--------------------------------------- + +What: /sys/class/infiniband/qibX/version +What: /sys/class/infiniband/qibX/hw_rev +What: /sys/class/infiniband/qibX/hca_type +What: /sys/class/infiniband/qibX/board_id +What: /sys/class/infiniband/qibX/boardversion +What: /sys/class/infiniband/qibX/nctxts +What: /sys/class/infiniband/qibX/localbus_info +What: /sys/class/infiniband/qibX/tempsense +What: /sys/class/infiniband/qibX/serial +What: /sys/class/infiniband/qibX/nfreectxts +What: /sys/class/infiniband/qibX/chip_reset +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: linux-rdma@vger.kernel.org +Description: + version: (RO) Display version information of installed software + and drivers. + + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Host channel adapter type + + board_id: (RO) Manufacturing board id + + boardversion: (RO) Current version of the chip architecture + + nctxts: (RO) Return the number of user ports (contexts) + available + + localbus_info: (RO) Human readable localbus info + + tempsense: (RO) Display temp sense registers in decimal + + serial: (RO) Serial number of the HCA + + nfreectxts: (RO) The number of free user ports (contexts) + available. + + chip_reset: (WO) Reset the chip if possible by writing + "reset" to this file. Only allowed if no user + contexts are open that use chip resources. + + +What: /sys/class/infiniband/qibX/ports/N/sl2vl/[0-15] +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: linux-rdma@vger.kernel.org +Description: + (RO) The directory contains 16 files numbered 0-15 that specify + the Service Level (SL). Listing the SL files returns the Virtual + Lane (VL) as programmed by the SL. + +What: /sys/class/infiniband/qibX/ports/N/CCMgtA/cc_settings_bin +What: /sys/class/infiniband/qibX/ports/N/CCMgtA/cc_table_bin +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: linux-rdma@vger.kernel.org +Description: + Per-port congestion control. Both are binary attributes. + + cc_table_bin: (RO) Congestion control table size followed by + table entries. + + cc_settings_bin:(RO) Congestion settings: port control, control + map and an array of 16 entries for the + congestion entries - increase, timer, event log + trigger threshold and the minimum injection rate + delay. + +What: /sys/class/infiniband/qibX/ports/N/linkstate/loopback +What: /sys/class/infiniband/qibX/ports/N/linkstate/led_override +What: /sys/class/infiniband/qibX/ports/N/linkstate/hrtbt_enable +What: /sys/class/infiniband/qibX/ports/N/linkstate/status +What: /sys/class/infiniband/qibX/ports/N/linkstate/status_str +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: linux-rdma@vger.kernel.org +Description: + [to be documented] + + loopback: (WO) + led_override: (WO) + hrtbt_enable: (RW) + status: (RO) + + status_str: (RO) Displays information about the link state, + possible cable/switch problems, and hardware + errors. Possible states are- "Initted", + "Present", "IB_link_up", "IB_configured" or + "Fatal_Hardware_Error". + +What: /sys/class/infiniband/qibX/ports/N/diag_counters/rc_resends +What: /sys/class/infiniband/qibX/ports/N/diag_counters/seq_naks +What: /sys/class/infiniband/qibX/ports/N/diag_counters/rdma_seq +What: /sys/class/infiniband/qibX/ports/N/diag_counters/rnr_naks +What: /sys/class/infiniband/qibX/ports/N/diag_counters/other_naks +What: /sys/class/infiniband/qibX/ports/N/diag_counters/rc_timeouts +What: /sys/class/infiniband/qibX/ports/N/diag_counters/look_pkts +What: /sys/class/infiniband/qibX/ports/N/diag_counters/pkt_drops +What: /sys/class/infiniband/qibX/ports/N/diag_counters/dma_wait +What: /sys/class/infiniband/qibX/ports/N/diag_counters/unaligned +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: linux-rdma@vger.kernel.org +Description: + [to be documented] + + +sysfs interface for Mellanox Connect-IB HCA driver mlx5 +------------------------------------------------------- + +What: /sys/class/infiniband/mlx5_X/hw_rev +What: /sys/class/infiniband/mlx5_X/hca_type +What: /sys/class/infiniband/mlx5_X/reg_pages +What: /sys/class/infiniband/mlx5_X/fw_pages +Date: Jul, 2013 +KernelVersion: v3.11 +Contact: linux-rdma@vger.kernel.org +Description: + [to be documented] + + +sysfs interface for Cisco VIC (usNIC) Verbs Driver +-------------------------------------------------- + +What: /sys/class/infiniband/usnic_X/board_id +What: /sys/class/infiniband/usnic_X/config +What: /sys/class/infiniband/usnic_X/qp_per_vf +What: /sys/class/infiniband/usnic_X/max_vf +What: /sys/class/infiniband/usnic_X/cq_per_vf +What: /sys/class/infiniband/usnic_X/iface +Date: Sep, 2013 +KernelVersion: v3.14 +Contact: Christian Benvenuti <benve@cisco.com>, + Dave Goodell <dgoodell@cisco.com>, + linux-rdma@vger.kernel.org +Description: + + board_id: (RO) Manufacturing board id + + config: (RO) Report the configuration for this PF + + qp_per_vf: (RO) Queue pairs per virtual function. + + max_vf: (RO) Max virtual functions + + cq_per_vf: (RO) Completion queue per virtual function + + iface: (RO) Shows which network interface this usNIC + entry is associated to (visible with ifconfig). + +What: /sys/class/infiniband/usnic_X/qpn/summary +What: /sys/class/infiniband/usnic_X/qpn/context +Date: Sep, 2013 +KernelVersion: v3.14 +Contact: Christian Benvenuti <benve@cisco.com>, + Dave Goodell <dgoodell@cisco.com>, + linux-rdma@vger.kernel.org +Description: + [to be documented] + + +sysfs interface for Emulex RoCE HCA Driver +------------------------------------------ + +What: /sys/class/infiniband/ocrdmaX/hw_rev +Date: Feb, 2014 +KernelVersion: v3.14 +Description: + hw_rev: (RO) Hardware revision number + +What: /sys/class/infiniband/ocrdmaX/hca_type +Date: Jun, 2014 +KernelVersion: v3.16 +Contact: linux-rdma@vger.kernel.org +Description: + hca_type: (RO) Display FW version + + +sysfs interface for Intel Omni-Path driver (HFI1) +------------------------------------------------- + +What: /sys/class/infiniband/hfi1_X/hw_rev +What: /sys/class/infiniband/hfi1_X/board_id +What: /sys/class/infiniband/hfi1_X/nctxts +What: /sys/class/infiniband/hfi1_X/serial +What: /sys/class/infiniband/hfi1_X/chip_reset +What: /sys/class/infiniband/hfi1_X/boardversion +What: /sys/class/infiniband/hfi1_X/nfreectxts +What: /sys/class/infiniband/hfi1_X/tempsense +Date: May, 2016 +KernelVersion: v4.6 +Contact: linux-rdma@vger.kernel.org +Description: + hw_rev: (RO) Hardware revision number + + board_id: (RO) Manufacturing board id + + nctxts: (RO) Total contexts available. + + serial: (RO) Board serial number + + chip_reset: (WO) Write "reset" to this file to reset the + chip if possible. Only allowed if no user + contexts are open that use chip resources. + + boardversion: (RO) Human readable board info + + nfreectxts: (RO) The number of free user ports (contexts) + available. + + tempsense: (RO) Thermal sense information + + +What: /sys/class/infiniband/hfi1_X/ports/N/CCMgtA/cc_settings_bin +What: /sys/class/infiniband/hfi1_X/ports/N/CCMgtA/cc_table_bin +What: /sys/class/infiniband/hfi1_X/ports/N/CCMgtA/cc_prescan +Date: May, 2016 +KernelVersion: v4.6 +Contact: linux-rdma@vger.kernel.org +Description: + Per-port congestion control. + + cc_table_bin: (RO) CCA tables used by PSM2 Congestion control + table size followed by table entries. Binary + attribute. + + cc_settings_bin:(RO) Congestion settings: port control, control + map and an array of 16 entries for the + congestion entries - increase, timer, event log + trigger threshold and the minimum injection rate + delay. Binary attribute. + + cc_prescan: (RW) enable prescanning for faster BECN + response. Write "on" to enable and "off" to + disable. + +What: /sys/class/infiniband/hfi1_X/ports/N/sc2vl/[0-31] +What: /sys/class/infiniband/hfi1_X/ports/N/sl2sc/[0-31] +What: /sys/class/infiniband/hfi1_X/ports/N/vl2mtu/[0-15] +Date: May, 2016 +KernelVersion: v4.6 +Contact: linux-rdma@vger.kernel.org +Description: + sc2vl/: (RO) 32 files (0 - 31) used to translate sl->vl + + sl2sc/: (RO) 32 files (0 - 31) used to translate sl->sc + + vl2mtu/: (RO) 16 files (0 - 15) used to determine MTU for vl + + +What: /sys/class/infiniband/hfi1_X/sdma_N/cpu_list +What: /sys/class/infiniband/hfi1_X/sdma_N/vl +Date: Sept, 2016 +KernelVersion: v4.8 +Contact: linux-rdma@vger.kernel.org +Description: + sdma<N>/ contains one directory per sdma engine (0 - 15) + + cpu_list: (RW) List of cpus for user-process to sdma + engine assignment. + + vl: (RO) Displays the virtual lane (vl) the sdma + engine maps to. + + This interface gives the user control on the affinity settings + for the device. As an example, to set an sdma engine irq + affinity and thread affinity of a user processes to use the + sdma engine, which is "near" in terms of NUMA configuration, or + physical cpu location, the user will do: + + echo "3" > /proc/irq/<N>/smp_affinity_list + echo "4-7" > /sys/devices/.../sdma3/cpu_list + cat /sys/devices/.../sdma3/vl + 0 + echo "8" > /proc/irq/<M>/smp_affinity_list + echo "9-12" > /sys/devices/.../sdma4/cpu_list + cat /sys/devices/.../sdma4/vl + 1 + + to make sure that when a process runs on cpus 4,5,6, or 7, and + uses vl=0, then sdma engine 3 is selected by the driver, and + also the interrupt of the sdma engine 3 is steered to cpu 3. + Similarly, when a process runs on cpus 9,10,11, or 12 and sets + vl=1, then engine 4 will be selected and the irq of the sdma + engine 4 is steered to cpu 8. This assumes that in the above N + is the irq number of "sdma3", and M is irq number of "sdma4" in + the /proc/interrupts file. + + +sysfs interface for Intel(R) X722 iWARP i40iw driver +---------------------------------------------------- + +What: /sys/class/infiniband/i40iwX/hw_rev +What: /sys/class/infiniband/i40iwX/hca_type +What: /sys/class/infiniband/i40iwX/board_id +Date: Jan, 2016 +KernelVersion: v4.10 +Contact: linux-rdma@vger.kernel.org +Description: + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Show HCA type (I40IW) + + board_id: (RO) I40IW board ID + + +sysfs interface for QLogic qedr NIC Driver +------------------------------------------ + +What: /sys/class/infiniband/qedrX/hw_rev +What: /sys/class/infiniband/qedrX/hca_type +Date: Oct, 2016 +KernelVersion: v4.10 +Contact: linux-rdma@vger.kernel.org +Description: + + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Display HCA type + + +sysfs interface for VMware Paravirtual RDMA driver +-------------------------------------------------- + +What: /sys/class/infiniband/vmw_pvrdmaX/hw_rev +What: /sys/class/infiniband/vmw_pvrdmaX/hca_type +What: /sys/class/infiniband/vmw_pvrdmaX/board_id +Date: Oct, 2016 +KernelVersion: v4.10 +Contact: linux-rdma@vger.kernel.org +Description: + + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Host channel adapter type + + board_id: (RO) Display PVRDMA manufacturing board ID + + +sysfs interface for Broadcom NetXtreme-E RoCE driver +---------------------------------------------------- + +What: /sys/class/infiniband/bnxt_reX/hw_rev +What: /sys/class/infiniband/bnxt_reX/hca_type +Date: Feb, 2017 +KernelVersion: v4.11 +Contact: linux-rdma@vger.kernel.org +Description: + hw_rev: (RO) Hardware revision number + + hca_type: (RO) Host channel adapter type diff --git a/Documentation/ABI/testing/debugfs-cec-error-inj b/Documentation/ABI/testing/debugfs-cec-error-inj new file mode 100644 index 0000000..122b65c --- /dev/null +++ b/Documentation/ABI/testing/debugfs-cec-error-inj @@ -0,0 +1,40 @@ +What: /sys/kernel/debug/cec/*/error-inj +Date: March 2018 +Contact: Hans Verkuil <hans.verkuil@cisco.com> +Description: + +The CEC Framework allows for CEC error injection commands through +debugfs. Drivers that support this will create an error-inj file +through which the error injection commands can be given. + +The basic syntax is as follows: + +Leading spaces/tabs are ignored. If the next character is a '#' or the +end of the line was reached, then the whole line is ignored. Otherwise +a command is expected. + +It is up to the driver to decide what commands to implement. The only +exception is that the command 'clear' without any arguments must be +implemented and that it will remove all current error injection +commands. + +This ensures that you can always do 'echo clear >error-inj' to clear any +error injections without having to know the details of the driver-specific +commands. + +Note that the output of 'error-inj' shall be valid as input to 'error-inj'. +So this must work: + + $ cat error-inj >einj.txt + $ cat einj.txt >error-inj + +Other than these basic rules described above this ABI is not considered +stable and may change in the future. + +Drivers that implement this functionality must document the commands as +part of the CEC documentation and must keep that documentation up to date +when changes are made. + +The following CEC error injection implementations exist: + +- Documentation/media/uapi/cec/cec-pin-error-inj.rst diff --git a/Documentation/ABI/testing/sysfs-block-aoe b/Documentation/ABI/testing/sysfs-block-aoe new file mode 100644 index 0000000..b583776 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-block-aoe @@ -0,0 +1,45 @@ +What: /sys/block/etherd*/mac +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: Ed L. Cashin <ed.cashin@acm.org> +Description: + (RO) The ethernet address of the remote Ata over Ethernet (AoE) + device. + +What: /sys/block/etherd*/netif +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: Ed L. Cashin <ed.cashin@acm.org> +Description: + (RO) The names of the network interfaces on the localhost (comma + separated) through which we are communicating with the remote + AoE device. + +What: /sys/block/etherd*/state +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: Ed L. Cashin <ed.cashin@acm.org> +Description: + (RO) Device status. The state attribute is "up" when the device + is ready for I/O and "down" if detected but unusable. The + "down,closewait" state shows that the device is still open and + cannot come up again until it has been closed. The "up,kickme" + state means that the driver wants to send more commands to the + target but found out there were already the max number of + commands waiting for a response. It will retry again after being + kicked by the periodic timer handler routine. + +What: /sys/block/etherd*/firmware-version +Date: Apr, 2005 +KernelVersion: v2.6.12 +Contact: Ed L. Cashin <ed.cashin@acm.org> +Description: + (RO) Version of the firmware in the target. + +What: /sys/block/etherd*/payload +Date: Dec, 2012 +KernelVersion: v3.10 +Contact: Ed L. Cashin <ed.cashin@acm.org> +Description: + (RO) The amount of user data transferred (in bytes) inside each AoE + command on the network, network headers excluded. diff --git a/Documentation/ABI/testing/sysfs-block-loop b/Documentation/ABI/testing/sysfs-block-loop new file mode 100644 index 0000000..627f4eb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-block-loop @@ -0,0 +1,50 @@ +What: /sys/block/loopX/loop/autoclear +Date: Aug, 2010 +KernelVersion: v2.6.37 +Contact: linux-block@vger.kernel.org +Description: + (RO) Shows if the device is in autoclear mode or not ( "1" or + "0"). Autoclear (if set) indicates that the loopback device will + self-distruct after last close. + +What: /sys/block/loopX/loop/backing_file +Date: Aug, 2010 +KernelVersion: v2.6.37 +Contact: linux-block@vger.kernel.org +Description: + (RO) The path of the backing file that the loop device maps its + data blocks to. + +What: /sys/block/loopX/loop/offset +Date: Aug, 2010 +KernelVersion: v2.6.37 +Contact: linux-block@vger.kernel.org +Description: + (RO) Start offset (in bytes). + +What: /sys/block/loopX/loop/sizelimit +Date: Aug, 2010 +KernelVersion: v2.6.37 +Contact: linux-block@vger.kernel.org +Description: + (RO) The size (in bytes) that the block device maps, starting + from the offset. + +What: /sys/block/loopX/loop/partscan +Date: Aug, 2011 +KernelVersion: v3.10 +Contact: linux-block@vger.kernel.org +Description: + (RO) Shows if automatic partition scanning is enabled for the + device or not ("1" or "0"). This can be requested individually + per loop device during its setup by setting LO_FLAGS_PARTSCAN in + in the ioctl request. By default, no partition tables are + scanned. + +What: /sys/block/loopX/loop/dio +Date: Aug, 2015 +KernelVersion: v4.10 +Contact: linux-block@vger.kernel.org +Description: + (RO) Shows if direct IO is being used to access backing file or + not ("1 or "0"). diff --git a/Documentation/ABI/testing/sysfs-bus-acpi b/Documentation/ABI/testing/sysfs-bus-acpi index 7fa9cbc..e7898cf 100644 --- a/Documentation/ABI/testing/sysfs-bus-acpi +++ b/Documentation/ABI/testing/sysfs-bus-acpi @@ -56,3 +56,40 @@ Description: Writing 1 to this attribute will trigger hot removal of this device object. This file exists for every device object that has _EJ0 method. + +What: /sys/bus/acpi/devices/.../status +Date: Jan, 2014 +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> +Description: + (RO) Returns the ACPI device status: enabled, disabled or + functioning or present, if the method _STA is present. + + The return value is a decimal integer representing the device's + status bitmap: + + Bit [0] – Set if the device is present. + Bit [1] – Set if the device is enabled and decoding its + resources. + Bit [2] – Set if the device should be shown in the UI. + Bit [3] – Set if the device is functioning properly (cleared if + device failed its diagnostics). + Bit [4] – Set if the battery is present. + Bits [31:5] – Reserved (must be cleared) + + If bit [0] is clear, then bit 1 must also be clear (a device + that is not present cannot be enabled). + + Bit 0 can be clear (not present) with bit [3] set (device is + functional). This case is used to indicate a valid device for + which no device driver should be loaded. + + More special cases are covered in the ACPI specification. + +What: /sys/bus/acpi/devices/.../hrv +Date: Apr, 2016 +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> +Description: + (RO) Allows users to read the hardware version of non-PCI + hardware, if the _HRV control method is present. It is mostly + useful for non-PCI devices because lspci can list the hardware + version for PCI devices. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x index c0c1ea9..d512f86 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x @@ -1,7 +1,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw Date: September 2015 KernelVersion: 4.3 -Contact: Matt Ranostay <mranostay@gmail.com> +Contact: Matt Ranostay <matt.ranostay@konsulko.com> Description: Get the raw calibration VOC value from the sensor. This value has little application outside of calibration. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 index 147d4e8..9a17ab5 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 +++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 @@ -1,7 +1,7 @@ What /sys/bus/iio/devices/iio:deviceX/in_proximity_input Date: March 2014 KernelVersion: 3.15 -Contact: Matt Ranostay <mranostay@gmail.com> +Contact: Matt Ranostay <matt.ranostay@konsulko.com> Description: Get the current distance in meters of storm (1km steps) 1000-40000 = distance in meters @@ -9,7 +9,7 @@ Description: What /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity Date: March 2014 KernelVersion: 3.15 -Contact: Matt Ranostay <mranostay@gmail.com> +Contact: Matt Ranostay <matt.ranostay@konsulko.com> Description: Show or set the gain boost of the amp, from 0-31 range. 18 = indoors (default) diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit new file mode 100644 index 0000000..619eb8c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-nfit @@ -0,0 +1,233 @@ +For all of the nmem device attributes under nfit/*, see the 'NVDIMM Firmware +Interface Table (NFIT)' section in the ACPI specification +(http://www.uefi.org/specifications) for more details. + +What: /sys/bus/nd/devices/nmemX/nfit/serial +Date: Jun, 2015 +KernelVersion: v4.2 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Serial number of the NVDIMM (non-volatile dual in-line + memory module), assigned by the module vendor. + + +What: /sys/bus/nd/devices/nmemX/nfit/handle +Date: Apr, 2015 +KernelVersion: v4.2 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) The address (given by the _ADR object) of the device on its + parent bus of the NVDIMM device containing the NVDIMM region. + + +What: /sys/bus/nd/devices/nmemX/nfit/device +Date: Apr, 2015 +KernelVersion: v4.1 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Device id for the NVDIMM, assigned by the module vendor. + + +What: /sys/bus/nd/devices/nmemX/nfit/rev_id +Date: Jun, 2015 +KernelVersion: v4.2 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Revision of the NVDIMM, assigned by the module vendor. + + +What: /sys/bus/nd/devices/nmemX/nfit/phys_id +Date: Apr, 2015 +KernelVersion: v4.2 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Handle (i.e., instance number) for the SMBIOS (system + management BIOS) Memory Device structure describing the NVDIMM + containing the NVDIMM region. + + +What: /sys/bus/nd/devices/nmemX/nfit/flags +Date: Jun, 2015 +KernelVersion: v4.2 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) The flags in the NFIT memory device sub-structure indicate + the state of the data on the nvdimm relative to its energy + source or last "flush to persistence". + + The attribute is a translation of the 'NVDIMM State Flags' field + in section 5.2.25.3 'NVDIMM Region Mapping' Structure of the + ACPI specification 6.2. + + The health states are "save_fail", "restore_fail", "flush_fail", + "not_armed", "smart_event", "map_fail" and "smart_notify". + + +What: /sys/bus/nd/devices/nmemX/nfit/format +What: /sys/bus/nd/devices/nmemX/nfit/format1 +What: /sys/bus/nd/devices/nmemX/nfit/formats +Date: Apr, 2016 +KernelVersion: v4.7 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) The interface codes indicate support for persistent memory + mapped directly into system physical address space and / or a + block aperture access mechanism to the NVDIMM media. + The 'formats' attribute displays the number of supported + interfaces. + + This layout is compatible with existing libndctl binaries that + only expect one code per-dimm as they will ignore + nmemX/nfit/formats and nmemX/nfit/formatN. + + +What: /sys/bus/nd/devices/nmemX/nfit/vendor +Date: Apr, 2016 +KernelVersion: v4.7 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Vendor id of the NVDIMM. + + +What: /sys/bus/nd/devices/nmemX/nfit/dsm_mask +Date: May, 2016 +KernelVersion: v4.7 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) The bitmask indicates the supported device specific control + functions relative to the NVDIMM command family supported by the + device + + +What: /sys/bus/nd/devices/nmemX/nfit/family +Date: Apr, 2016 +KernelVersion: v4.7 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Displays the NVDIMM family command sets. Values + 0, 1, 2 and 3 correspond to NVDIMM_FAMILY_INTEL, + NVDIMM_FAMILY_HPE1, NVDIMM_FAMILY_HPE2 and NVDIMM_FAMILY_MSFT + respectively. + + See the specifications for these command families here: + http://pmem.io/documents/NVDIMM_DSM_Interface-V1.6.pdf + https://github.com/HewlettPackard/hpe-nvm/blob/master/Documentation/ + https://msdn.microsoft.com/library/windows/hardware/mt604741" + + +What: /sys/bus/nd/devices/nmemX/nfit/id +Date: Apr, 2016 +KernelVersion: v4.7 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) ACPI specification 6.2 section 5.2.25.9, defines an + identifier for an NVDIMM, which refelects the id attribute. + + +What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor +Date: Apr, 2016 +KernelVersion: v4.7 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Sub-system vendor id of the NVDIMM non-volatile memory + subsystem controller. + + +What: /sys/bus/nd/devices/nmemX/nfit/subsystem_rev_id +Date: Apr, 2016 +KernelVersion: v4.7 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Sub-system revision id of the NVDIMM non-volatile memory subsystem + controller, assigned by the non-volatile memory subsystem + controller vendor. + + +What: /sys/bus/nd/devices/nmemX/nfit/subsystem_device +Date: Apr, 2016 +KernelVersion: v4.7 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Sub-system device id for the NVDIMM non-volatile memory + subsystem controller, assigned by the non-volatile memory + subsystem controller vendor. + + +What: /sys/bus/nd/devices/ndbusX/nfit/revision +Date: Jun, 2015 +KernelVersion: v4.2 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) ACPI NFIT table revision number. + + +What: /sys/bus/nd/devices/ndbusX/nfit/scrub +Date: Sep, 2016 +KernelVersion: v4.9 +Contact: linux-nvdimm@lists.01.org +Description: + (RW) This shows the number of full Address Range Scrubs (ARS) + that have been completed since driver load time. Userspace can + wait on this using select/poll etc. A '+' at the end indicates + an ARS is in progress + + Writing a value of 1 triggers an ARS scan. + + +What: /sys/bus/nd/devices/ndbusX/nfit/hw_error_scrub +Date: Sep, 2016 +KernelVersion: v4.9 +Contact: linux-nvdimm@lists.01.org +Description: + (RW) Provides a way to toggle the behavior between just adding + the address (cache line) where the MCE happened to the poison + list and doing a full scrub. The former (selective insertion of + the address) is done unconditionally. + + This attribute can have the following values written to it: + + '0': Switch to the default mode where an exception will only + insert the address of the memory error into the poison and + badblocks lists. + '1': Enable a full scrub to happen if an exception for a memory + error is received. + + +What: /sys/bus/nd/devices/ndbusX/nfit/dsm_mask +Date: Jun, 2017 +KernelVersion: v4.13 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) The bitmask indicates the supported bus specific control + functions. See the section named 'NVDIMM Root Device _DSMs' in + the ACPI specification. + + +What: /sys/bus/nd/devices/regionX/nfit/range_index +Date: Jun, 2015 +KernelVersion: v4.2 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) A unique number provided by the BIOS to identify an address + range. Used by NVDIMM Region Mapping Structure to uniquely refer + to this structure. Value of 0 is reserved and not used as an + index. + + +What: /sys/bus/nd/devices/regionX/nfit/ecc_unit_size +Date: Aug, 2017 +KernelVersion: v4.14 +Contact: linux-nvdimm@lists.01.org +Description: + (RO) Size of a write request to a DIMM that will not incur a + read-modify-write cycle at the memory controller. + + When the nfit driver initializes it runs an ARS (Address Range + Scrub) operation across every pmem range. Part of that process + involves determining the ARS capabilities of a given address + range. One of the capabilities that is reported is the 'Clear + Uncorrectable Error Range Length Unit Size' (see: ACPI 6.2 + section 9.20.7.4 Function Index 1 - Query ARS Capabilities). + This property indicates the boundary at which the NVDIMM may + need to perform read-modify-write cycles to maintain ECC (Error + Correcting Code) blocks. diff --git a/Documentation/ABI/testing/sysfs-bus-rapidio b/Documentation/ABI/testing/sysfs-bus-rapidio new file mode 100644 index 0000000..13208b2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-rapidio @@ -0,0 +1,198 @@ +What: /sys/bus/rapidio/devices/nn:d:iiii +Description: + For each RapidIO device, the RapidIO subsystem creates files in + an individual subdirectory with the following name format of + device_name "nn:d:iiii", where: + + nn - two-digit hexadecimal ID of RapidIO network where the + device resides + d - device type: 'e' - for endpoint or 's' - for switch + iiii - four-digit device destID for endpoints, or switchID for + switches + + For example, below is a list of device directories that + represents a typical RapidIO network with one switch, one host, + and two agent endpoints, as it is seen by the enumerating host + (with destID = 1): + + /sys/bus/rapidio/devices/00:e:0000 + /sys/bus/rapidio/devices/00:e:0002 + /sys/bus/rapidio/devices/00:s:0001 + + NOTE: An enumerating or discovering endpoint does not create a + sysfs entry for itself, this is why an endpoint with destID=1 is + not shown in the list. + +Attributes Common for All RapidIO Devices +----------------------------------------- + +What: /sys/bus/rapidio/devices/nn:d:iiii/did +Date: Nov, 2005 +KernelVersion: v2.6.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns the device identifier + +What: /sys/bus/rapidio/devices/nn:d:iiii/vid +Date: Nov, 2005 +KernelVersion: v2.6.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns the device vendor identifier + +What: /sys/bus/rapidio/devices/nn:d:iiii/device_rev +Date: Nov, 2005 +KernelVersion: v2.6.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns the device revision level + +What: /sys/bus/rapidio/devices/nn:d:iiii/asm_did +Date: Nov, 2005 +KernelVersion: v2.6.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns identifier for the assembly containing the device + +What: /sys/bus/rapidio/devices/nn:d:iiii/asm_rev +Date: Nov, 2005 +KernelVersion: v2.6.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns revision level of the assembly containing the + device + +What: /sys/bus/rapidio/devices/nn:d:iiii/asm_vid +Date: Nov, 2005 +KernelVersion: v2.6.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns vendor identifier of the assembly containing the + device + +What: /sys/bus/rapidio/devices/nn:d:iiii/destid +Date: Mar, 2011 +KernelVersion: v2.6.3 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns device destination ID assigned by the enumeration + routine + +What: /sys/bus/rapidio/devices/nn:d:iiii/lprev +Date: Mar, 2011 +KernelVersion: v2.6.39 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns name of previous device (switch) on the path to the + device that that owns this attribute + +What: /sys/bus/rapidio/devices/nn:d:iiii/modalias +Date: Jul, 2013 +KernelVersion: v3.11 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns the device modalias + +What: /sys/bus/rapidio/devices/nn:d:iiii/config +Date: Nov, 2005 +KernelVersion: v2.6.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RW) Binary attribute to read from and write to the device + configuration registers using the RapidIO maintenance + transactions. This attribute is similar in behaviour to the + "config" attribute of PCI devices and provides an access to the + RapidIO device registers using standard file read and write + operations. + +RapidIO Switch Device Attributes +-------------------------------- + +RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports +common and device-specific sysfs attributes for switches. Because switches are +integrated into the RapidIO subsystem, it offers a method to create +device-specific sysfs attributes by specifying a callback function that may be +set by the switch initialization routine during enumeration or discovery +process. + +What: /sys/bus/rapidio/devices/nn:s:iiii/routes +Date: Nov, 2005 +KernelVersion: v2.6.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) reports switch routing information in "destID port" format. + This attribute reports only valid routing table entries, one + line for each entry. + +What: /sys/bus/rapidio/devices/nn:s:iiii/destid +Date: Mar, 2011 +KernelVersion: v2.6.3 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) device destination ID of the associated device that defines + a route to the switch + +What: /sys/bus/rapidio/devices/nn:s:iiii/hopcount +Date: Mar, 2011 +KernelVersion: v2.6.39 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) number of hops on the path to the switch + +What: /sys/bus/rapidio/devices/nn:s:iiii/lnext +Date: Mar, 2011 +KernelVersion: v2.6.39 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) returns names of devices linked to the switch except one of + a device linked to the ingress port (reported as "lprev"). This + is an array names with number of lines equal to number of ports + in switch. If a switch port has no attached device, returns + "null" instead of a device name. + +Device-specific Switch Attributes +--------------------------------- + +IDT_GEN2- + +What: /sys/bus/rapidio/devices/nn:s:iiii/errlog +Date: Oct, 2010 +KernelVersion: v2.6.37 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) reads contents of device error log until it is empty. + +RapidIO Bus Attributes +---------------------- + +What: /sys/bus/rapidio/scan +Date: May, 2013 +KernelVersion: v3.11 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (WO) Allows to trigger enumeration discovery process from user + space. To initiate an enumeration or discovery process on + specific mport device, a user needs to write mport_ID (not + RapidIO destination ID) into this file. The mport_ID is a + sequential number (0 ... RIO_MAX_MPORTS) assigned to the mport + device. For example, for a machine with a single RapidIO + controller, mport_ID for that controller always will be 0. To + initiate RapidIO enumeration/discovery on all available mports a + user must write '-1' (or RIO_MPORT_ANY) into this attribute + file. diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd index f208ac5..cc30bee 100644 --- a/Documentation/ABI/testing/sysfs-bus-rbd +++ b/Documentation/ABI/testing/sysfs-bus-rbd @@ -1,121 +1,162 @@ -What: /sys/bus/rbd/ -Date: November 2010 -Contact: Yehuda Sadeh <yehuda@newdream.net>, - Sage Weil <sage@newdream.net> +What: /sys/bus/rbd/add +Date: Oct, 2010 +KernelVersion: v2.6.37 +Contact: Sage Weil <sage@newdream.net> Description: + (WO) Add rbd block device. -Being used for adding and removing rbd block devices. + Usage: <mon ip addr> <options> <pool name> <rbd image name> [<snap name>] -Usage: <mon ip addr> <options> <pool name> <rbd image name> [<snap name>] + $ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add - $ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add + The snapshot name can be "-" or omitted to map the image + read/write. A <dev-id> will be assigned for any registered block + device. If snapshot is used, it will be mapped read-only. -The snapshot name can be "-" or omitted to map the image read/write. A <dev-id> -will be assigned for any registered block device. If snapshot is used, it will -be mapped read-only. -Usage: <dev-id> [force] +What: /sys/bus/rbd/remove +Date: Oct, 2010 +KernelVersion: v2.6.37 +Contact: Sage Weil <sage@newdream.net> +Description: + (WO) Remove rbd block device. + + Usage: <dev-id> [force] - $ echo 2 > /sys/bus/rbd/remove + $ echo 2 > /sys/bus/rbd/remove + + Optional "force" argument which when passed will wait for + running requests and then unmap the image. Requests sent to the + driver after initiating the removal will be failed. (August + 2016, since 4.9.) -Optional "force" argument which when passed will wait for running requests and -then unmap the image. Requests sent to the driver after initiating the removal -will be failed. (August 2016, since 4.9.) What: /sys/bus/rbd/add_single_major -Date: December 2013 -KernelVersion: 3.14 -Contact: Sage Weil <sage@inktank.com> -Description: Available only if rbd module is inserted with single_major +Date: Dec, 2013 +KernelVersion: v3.14 +Contact: Sage Weil <sage@newdream.net> +Description: + (WO) Available only if rbd module is inserted with single_major parameter set to true. - Usage is the same as for /sys/bus/rbd/add. If present, + + Usage is the same as for /sys/bus/rbd/add. If present, this should be used instead of the latter: any attempts to use - /sys/bus/rbd/add if /sys/bus/rbd/add_single_major is - available will fail for backwards compatibility reasons. + /sys/bus/rbd/add if /sys/bus/rbd/add_single_major is available + will fail for backwards compatibility reasons. + What: /sys/bus/rbd/remove_single_major -Date: December 2013 -KernelVersion: 3.14 -Contact: Sage Weil <sage@inktank.com> -Description: Available only if rbd module is inserted with single_major +Date: Dec, 2013 +KernelVersion: v3.14 +Contact: Sage Weil <sage@newdream.net> +Description: + (WO) Available only if rbd module is inserted with single_major parameter set to true. - Usage is the same as for /sys/bus/rbd/remove. If present, + + Usage is the same as for /sys/bus/rbd/remove. If present, this should be used instead of the latter: any attempts to use /sys/bus/rbd/remove if /sys/bus/rbd/remove_single_major is available will fail for backwards compatibility reasons. -Entries under /sys/bus/rbd/devices/<dev-id>/ --------------------------------------------- - -client_addr - - The ceph unique client entity_addr_t (address + nonce). - The format is <address>:<port>/<nonce>: '1.2.3.4:1234/5678' or - '[1:2:3:4:5:6:7:8]:1234/5678'. (August 2016, since 4.9.) - -client_id - - The ceph unique client id that was assigned for this specific session. - -cluster_fsid - The ceph cluster UUID. (August 2016, since 4.9.) - -config_info - - The string written into /sys/bus/rbd/add{,_single_major}. (August - 2016, since 4.9.) - -features - - A hexadecimal encoding of the feature bits for this image. - -major - - The block device major number. +What: /sys/bus/rbd/supported_features +Date: Mar, 2017 +KernelVersion: v4.11 +Contact: Sage Weil <sage@newdream.net> +Description: + (RO) Displays the features supported by the rbd module so that + userspace can generate meaningful error messages and spell out + unsupported features that need to be disabled. + + +What: /sys/bus/rbd/devices/<dev-id>/size +What: /sys/bus/rbd/devices/<dev-id>/major +What: /sys/bus/rbd/devices/<dev-id>/client_id +What: /sys/bus/rbd/devices/<dev-id>/pool +What: /sys/bus/rbd/devices/<dev-id>/name +What: /sys/bus/rbd/devices/<dev-id>/refresh +What: /sys/bus/rbd/devices/<dev-id>/current_snap +Date: Oct, 2010 +KernelVersion: v2.6.37 +Contact: Sage Weil <sage@newdream.net> +Description: + size: (RO) The size (in bytes) of the mapped block + device. -minor + major: (RO) The block device major number. - The block device minor number. (December 2013, since 3.14.) + client_id: (RO) The ceph unique client id that was assigned + for this specific session. -name + pool: (RO) The name of the storage pool where this rbd + image resides. An rbd image name is unique + within its pool. - The name of the rbd image. + name: (RO) The name of the rbd image. -image_id + refresh: (WO) Writing to this file will reread the image + header data and set all relevant data structures + accordingly. - The unique id for the rbd image. (For rbd image format 1 - this is empty.) + current_snap: (RO) The current snapshot for which the device + is mapped. -pool - The name of the storage pool where this rbd image resides. - An rbd image name is unique within its pool. +What: /sys/bus/rbd/devices/<dev-id>/pool_id +Date: Jul, 2012 +KernelVersion: v3.6 +Contact: Sage Weil <sage@newdream.net> +Description: + (RO) The unique identifier for the rbd image's pool. This is a + permanent attribute of the pool. A pool's id will never change. -pool_id - The unique identifier for the rbd image's pool. This is - a permanent attribute of the pool. A pool's id will never - change. +What: /sys/bus/rbd/devices/<dev-id>/image_id +What: /sys/bus/rbd/devices/<dev-id>/features +Date: Oct, 2012 +KernelVersion: v3.7 +Contact: Sage Weil <sage@newdream.net> +Description: + image_id: (RO) The unique id for the rbd image. (For rbd + image format 1 this is empty.) -size + features: (RO) A hexadecimal encoding of the feature bits + for this image. - The size (in bytes) of the mapped block device. -refresh +What: /sys/bus/rbd/devices/<dev-id>/parent +Date: Nov, 2012 +KernelVersion: v3.8 +Contact: Sage Weil <sage@newdream.net> +Description: + (RO) Information identifying the chain of parent images in a + layered rbd image. Entries are separated by empty lines. - Writing to this file will reread the image header data and set - all relevant datastructures accordingly. -current_snap +What: /sys/bus/rbd/devices/<dev-id>/minor +Date: Dec, 2013 +KernelVersion: v3.14 +Contact: Sage Weil <sage@newdream.net> +Description: + (RO) The block device minor number. - The current snapshot for which the device is mapped. -snap_id +What: /sys/bus/rbd/devices/<dev-id>/snap_id +What: /sys/bus/rbd/devices/<dev-id>/config_info +What: /sys/bus/rbd/devices/<dev-id>/cluster_fsid +What: /sys/bus/rbd/devices/<dev-id>/client_addr +Date: Aug, 2016 +KernelVersion: v4.9 +Contact: Sage Weil <sage@newdream.net> +Description: + snap_id: (RO) The current snapshot's id. - The current snapshot's id. (August 2016, since 4.9.) + config_info: (RO) The string written into + /sys/bus/rbd/add{,_single_major}. -parent + cluster_fsid: (RO) The ceph cluster UUID. - Information identifying the chain of parent images in a layered rbd - image. Entries are separated by empty lines. + client_addr: (RO) The ceph unique client + entity_addr_t (address + nonce). The format is + <address>:<port>/<nonce>: '1.2.3.4:1234/5678' or + '[1:2:3:4:5:6:7:8]:1234/5678'. diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 93798c0..151584a 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -1,3 +1,26 @@ +What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl +Date: Jun 2018 +KernelVersion: 4.17 +Contact: thunderbolt-software@lists.01.org +Description: Holds a comma separated list of device unique_ids that + are allowed to be connected automatically during system + startup (e.g boot devices). The list always contains + maximum supported number of unique_ids where unused + entries are empty. This allows the userspace software + to determine how many entries the controller supports. + If there are multiple controllers, each controller has + its own ACL list and size may be different between the + controllers. + + System BIOS may have an option "Preboot ACL" or similar + that needs to be selected before this list is taken into + consideration. + + Software always updates a full list in each write. + + If a device is authorized automatically during boot its + boot attribute is set to 1. + What: /sys/bus/thunderbolt/devices/.../domainX/security Date: Sep 2017 KernelVersion: 4.13 @@ -12,6 +35,9 @@ Description: This attribute holds current Thunderbolt security level minimum. User needs to authorize each device. dponly: Automatically tunnel Display port (and USB). No PCIe tunnels are created. + usbonly: Automatically tunnel USB controller of the + connected Thunderbolt dock (and Display Port). All + PCIe links downstream of the dock are removed. What: /sys/bus/thunderbolt/devices/.../authorized Date: Sep 2017 @@ -38,6 +64,13 @@ Description: This attribute is used to authorize Thunderbolt devices the device did not contain a key at all, and EKEYREJECTED if the challenge response did not match. +What: /sys/bus/thunderbolt/devices/.../boot +Date: Jun 2018 +KernelVersion: 4.17 +Contact: thunderbolt-software@lists.01.org +Description: This attribute contains 1 if Thunderbolt device was already + authorized on boot and 0 otherwise. + What: /sys/bus/thunderbolt/devices/.../key Date: Sep 2017 KernelVersion: 4.13 diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 0bd731c..c702c78 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -189,6 +189,16 @@ Description: The file will read "hotplug", "wired" and "not used" if the information is available, and "unknown" otherwise. +What: /sys/bus/usb/devices/.../(hub interface)/portX/over_current_count +Date: February 2018 +Contact: Richard Leitner <richard.leitner@skidata.com> +Description: + Most hubs are able to detect over-current situations on their + ports and report them to the kernel. This attribute is to expose + the number of over-current situation occurred on a specific port + to user space. This file will contain an unsigned 32 bit value + which wraps to 0 after its maximum is reached. + What: /sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit Date: November 2015 Contact: Lu Baolu <baolu.lu@linux.intel.com> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 b/Documentation/ABI/testing/sysfs-class-backlight-adp5520 new file mode 100644 index 0000000..34b6eba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-adp5520 @@ -0,0 +1,31 @@ +sysfs interface for analog devices adp5520(01) backlight driver +--------------------------------------------------------------- + +The backlight brightness control operates at three different levels for the +adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark +(level 3). By default the brightness operates at the daylight brightness level. + +What: /sys/class/backlight/<backlight>/daylight_max +What: /sys/class/backlight/<backlight>/office_max +What: /sys/class/backlight/<backlight>/dark_max +Date: Sep, 2009 +KernelVersion: v2.6.32 +Contact: Michael Hennerich <michael.hennerich@analog.com> +Description: + (RW) Maximum current setting for the backlight when brightness + is at one of the three levels (daylight, office or dark). This + is an input code between 0 and 127, which is transformed to a + value between 0 mA and 30 mA using linear or non-linear + algorithms. + +What: /sys/class/backlight/<backlight>/daylight_dim +What: /sys/class/backlight/<backlight>/office_dim +What: /sys/class/backlight/<backlight>/dark_dim +Date: Sep, 2009 +KernelVersion: v2.6.32 +Contact: Michael Hennerich <michael.hennerich@analog.com> +Description: + (RW) Dim current setting for the backlight when brightness is at + one of the three levels (daylight, office or dark). This is an + input code between 0 and 127, which is transformed to a value + between 0 mA and 30 mA using linear or non-linear algorithms. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 b/Documentation/ABI/testing/sysfs-class-backlight-adp8860 new file mode 100644 index 0000000..54d61c7 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-adp8860 @@ -0,0 +1,54 @@ +sysfs interface for analog devices adp8860 backlight driver +----------------------------------------------------------- + +The backlight brightness control operates at three different levels for the +adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and +dark (level 3). By default the brightness operates at the daylight brightness +level. + +What: /sys/class/backlight/<backlight>/ambient_light_level +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich <michael.hennerich@analog.com> +Description: + (RO) 13-bit conversion value for the first light sensor—high + byte (Bit 12 to Bit 8). The value is updated every 80 ms (when + the light sensor is enabled). + + +What: /sys/class/backlight/<backlight>/ambient_light_zone +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich <michael.hennerich@analog.com> +Description: + (RW) Read or write the specific level at which the backlight + operates. Value "0" enables automatic ambient light sensing, and + values "1", "2" or "3" set the control to daylight, office or + dark respectively. + + +What: /sys/class/backlight/<backlight>/l1_daylight_max +What: /sys/class/backlight/<backlight>/l2_office_max +What: /sys/class/backlight/<backlight>/l3_dark_max +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich <michael.hennerich@analog.com> +Description: + (RW) Maximum current setting for the backlight when brightness + is at one of the three levels (daylight, office or dark). This + is an input code between 0 and 127, which is transformed to a + value between 0 mA and 30 mA using linear or non-linear + algorithms. + + +What: /sys/class/backlight/<backlight>/l1_daylight_dim +What: /sys/class/backlight/<backlight>/l2_office_dim +What: /sys/class/backlight/<backlight>/l3_dark_dim +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich <michael.hennerich@analog.com> +Description: + (RW) Dim current setting for the backlight when brightness is at + one of the three levels (daylight, office or dark). This is an + input code between 0 and 127, which is transformed to a value + between 0 mA and 30 mA using linear or non-linear algorithms. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lm3639 b/Documentation/ABI/testing/sysfs-class-backlight-lm3639 new file mode 100644 index 0000000..f7e92a8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-lm3639 @@ -0,0 +1,11 @@ +sysfs interface for Texas Instruments lm3639 backlight + flash led driver chip +------------------------------------------------------------------------------ + +What: /sys/class/backlight/<backlight>/bled_mode +Date: Oct, 2012 +KernelVersion: v3.10 +Contact: dri-devel@lists.freedesktop.org +Description: + (WO) Write to the backlight mapping mode. The backlight current + can be mapped for either exponential (value "0") or linear + mapping modes (default). diff --git a/Documentation/ABI/testing/sysfs-class-bsr b/Documentation/ABI/testing/sysfs-class-bsr new file mode 100644 index 0000000..7bf145d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-bsr @@ -0,0 +1,25 @@ +What: /sys/class/bsr/bsr*/bsr_size +Date: Jul, 2008 +KernelVersion: 2.6.27 +Contact: Arnd Bergmann <arnd@arndb.de>, + Greg Kroah-Hartman <gregkh@linuxfoundation.org> +Description: + (RO) Size of the barrier-synchronization register (BSR) + register in bytes. + +What: /sys/class/bsr/bsr*/bsr_length +Date: Jul, 2008 +KernelVersion: 2.6.27 +Contact: Arnd Bergmann <arnd@arndb.de>, + Greg Kroah-Hartman <gregkh@linuxfoundation.org> +Description: + (RO) The length of memory region that can be mapped in bytes. + +What: /sys/class/bsr/bsr*/bsr_stride +Date: Jul, 2008 +KernelVersion: 2.6.27 +Contact: Arnd Bergmann <arnd@arndb.de>, + Greg Kroah-Hartman <gregkh@linuxfoundation.org> +Description: + (RO) The stride or the interval at which the allocated BSR bytes + repeat within the mapping. diff --git a/Documentation/ABI/testing/sysfs-class-infiniband b/Documentation/ABI/testing/sysfs-class-infiniband deleted file mode 100644 index a86abe6..0000000 --- a/Documentation/ABI/testing/sysfs-class-infiniband +++ /dev/null @@ -1,16 +0,0 @@ -What: /sys/class/infiniband/<hca>/ports/<port-number>/gid_attrs/ndevs/<gid-index> -Date: November 29, 2015 -KernelVersion: 4.4.0 -Contact: linux-rdma@vger.kernel.org -Description: The net-device's name associated with the GID resides - at index <gid-index>. - -What: /sys/class/infiniband/<hca>/ports/<port-number>/gid_attrs/types/<gid-index> -Date: November 29, 2015 -KernelVersion: 4.4.0 -Contact: linux-rdma@vger.kernel.org -Description: The RoCE type of the associated GID resides at index <gid-index>. - This could either be "IB/RoCE v1" for IB and RoCE v1 based GODs - or "RoCE v2" for RoCE v2 based GIDs. - - diff --git a/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 b/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 new file mode 100644 index 0000000..ae0a2d3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 @@ -0,0 +1,27 @@ +sysfs interface for the S6E63M0 AMOLED LCD panel driver +------------------------------------------------------- + +What: /sys/class/lcd/<lcd>/gamma_mode +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: dri-devel@lists.freedesktop.org +Description: + (RW) Read or write the gamma mode. Following three modes are + supported: + 0 - gamma value 2.2, + 1 - gamma value 1.9 and + 2 - gamma value 1.7. + + +What: /sys/class/lcd/<lcd>/gamma_table +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: dri-devel@lists.freedesktop.org +Description: + (RO) Displays the size of the gamma table i.e. the number of + gamma modes available. + +This is a backlight lcd driver. These interfaces are an extension to the API +documented in Documentation/ABI/testing/sysfs-class-lcd and in +Documentation/ABI/stable/sysfs-class-backlight (under +/sys/class/backlight/<backlight>/). diff --git a/Documentation/ABI/testing/sysfs-class-mei b/Documentation/ABI/testing/sysfs-class-mei index 5096a82..81ff6ab 100644 --- a/Documentation/ABI/testing/sysfs-class-mei +++ b/Documentation/ABI/testing/sysfs-class-mei @@ -45,3 +45,12 @@ Contact: Tomas Winkler <tomas.winkler@intel.com> Description: Display the driver HBM protocol version. The HBM protocol version supported by the driver. + +What: /sys/class/mei/meiN/tx_queue_limit +Date: Jan 2018 +KernelVersion: 4.16 +Contact: Tomas Winkler <tomas.winkler@intel.com> +Description: Configure tx queue limit + + Set maximal number of pending writes + per opened session. diff --git a/Documentation/ABI/testing/sysfs-class-pktcdvd b/Documentation/ABI/testing/sysfs-class-pktcdvd index b1c3f02..dde4f26 100644 --- a/Documentation/ABI/testing/sysfs-class-pktcdvd +++ b/Documentation/ABI/testing/sysfs-class-pktcdvd @@ -1,60 +1,81 @@ -What: /sys/class/pktcdvd/ -Date: Oct. 2006 -KernelVersion: 2.6.20 -Contact: Thomas Maier <balagi@justmail.de> -Description: - sysfs interface --------------- +The pktcdvd module (packet writing driver) creates the following files in the +sysfs: (<devid> is in the format major:minor) + +What: /sys/class/pktcdvd/add +What: /sys/class/pktcdvd/remove +What: /sys/class/pktcdvd/device_map +Date: Oct. 2006 +KernelVersion: 2.6.20 +Contact: Thomas Maier <balagi@justmail.de> +Description: + + add: (WO) Write a block device id (major:minor) to + create a new pktcdvd device and map it to the + block device. + + remove: (WO) Write the pktcdvd device id (major:minor) + to remove the pktcdvd device. + + device_map: (RO) Shows the device mapping in format: + pktcdvd[0-7] <pktdevid> <blkdevid> + + +What: /sys/class/pktcdvd/pktcdvd[0-7]/dev +What: /sys/class/pktcdvd/pktcdvd[0-7]/uevent +Date: Oct. 2006 +KernelVersion: 2.6.20 +Contact: Thomas Maier <balagi@justmail.de> +Description: + dev: (RO) Device id + + uevent: (WO) To send a uevent + + +What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/packets_started +What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/packets_finished +What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_written +What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_read +What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_read_gather +What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/reset +Date: Oct. 2006 +KernelVersion: 2.6.20 +Contact: Thomas Maier <balagi@justmail.de> +Description: + packets_started: (RO) Number of started packets. + + packets_finished: (RO) Number of finished packets. + + kb_written: (RO) kBytes written. + + kb_read: (RO) kBytes read. + + kb_read_gather: (RO) kBytes read to fill write packets. + + reset: (WO) Write any value to it to reset + pktcdvd device statistic values, like + bytes read/written. + + +What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/size +What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/congestion_off +What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/congestion_on +Date: Oct. 2006 +KernelVersion: 2.6.20 +Contact: Thomas Maier <balagi@justmail.de> +Description: + size: (RO) Contains the size of the bio write queue. + + congestion_off: (RW) If bio write queue size is below this mark, + accept new bio requests from the block layer. -The pktcdvd module (packet writing driver) creates -these files in the sysfs: -(<devid> is in format major:minor ) - -/sys/class/pktcdvd/ - add (0200) Write a block device id (major:minor) - to create a new pktcdvd device and map - it to the block device. - - remove (0200) Write the pktcdvd device id (major:minor) - to it to remove the pktcdvd device. - - device_map (0444) Shows the device mapping in format: - pktcdvd[0-7] <pktdevid> <blkdevid> - -/sys/class/pktcdvd/pktcdvd[0-7]/ - dev (0444) Device id - uevent (0200) To send an uevent. - -/sys/class/pktcdvd/pktcdvd[0-7]/stat/ - packets_started (0444) Number of started packets. - packets_finished (0444) Number of finished packets. - - kb_written (0444) kBytes written. - kb_read (0444) kBytes read. - kb_read_gather (0444) kBytes read to fill write packets. - - reset (0200) Write any value to it to reset - pktcdvd device statistic values, like - bytes read/written. - -/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/ - size (0444) Contains the size of the bio write - queue. - - congestion_off (0644) If bio write queue size is below - this mark, accept new bio requests - from the block layer. - - congestion_on (0644) If bio write queue size is higher - as this mark, do no longer accept - bio write requests from the block - layer and wait till the pktcdvd - device has processed enough bio's - so that bio write queue size is - below congestion off mark. - A value of <= 0 disables congestion - control. + congestion_on: (RW) If bio write queue size is higher as this + mark, do no longer accept bio write requests + from the block layer and wait till the pktcdvd + device has processed enough bio's so that bio + write queue size is below congestion off mark. + A value of <= 0 disables congestion control. Example: diff --git a/Documentation/ABI/testing/sysfs-class-rapidio b/Documentation/ABI/testing/sysfs-class-rapidio new file mode 100644 index 0000000..8716bee --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-rapidio @@ -0,0 +1,55 @@ +What: /sys/class/rapidio_port +Description: + On-chip RapidIO controllers and PCIe-to-RapidIO bridges + (referenced as "Master Port" or "mport") are presented in sysfs + as the special class of devices: "rapidio_port". + The /sys/class/rapidio_port subdirectory contains individual + subdirectories named as "rapidioN" where N = mport ID registered + with RapidIO subsystem. + NOTE: An mport ID is not a RapidIO destination ID assigned to a + given local mport device. + +What: /sys/class/rapidio_port/rapidioN/sys_size +Date: Apr, 2014 +KernelVersion: v3.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) reports RapidIO common transport system size: + 0 = small (8-bit destination ID, max. 256 devices), + 1 = large (16-bit destination ID, max. 65536 devices). + +What: /sys/class/rapidio_port/rapidioN/port_destid +Date: Apr, 2014 +KernelVersion: v3.15 +Contact: Matt Porter <mporter@kernel.crashing.org>, + Alexandre Bounine <alexandre.bounine@idt.com> +Description: + (RO) reports RapidIO destination ID assigned to the given + RapidIO mport device. If value 0xFFFFFFFF is returned this means + that no valid destination ID have been assigned to the mport + (yet). Normally, before enumeration/discovery have been executed + only fabric enumerating mports have a valid destination ID + assigned to them using "hdid=..." rapidio module parameter. + +After enumeration or discovery was performed for a given mport device, +the corresponding subdirectory will also contain subdirectories for each +child RapidIO device connected to the mport. + +The example below shows mport device subdirectory with several child RapidIO +devices attached to it. + +[rio@rapidio ~]$ ls /sys/class/rapidio_port/rapidio0/ -l +total 0 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0001 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0004 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0007 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0002 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0003 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0005 +lrwxrwxrwx 1 root root 0 Feb 11 15:11 device -> ../../../0000:01:00.0 +-r--r--r-- 1 root root 4096 Feb 11 15:11 port_destid +drwxr-xr-x 2 root root 0 Feb 11 15:11 power +lrwxrwxrwx 1 root root 0 Feb 11 15:04 subsystem -> ../../../../../../class/rapidio_port +-r--r--r-- 1 root root 4096 Feb 11 15:11 sys_size +-rw-r--r-- 1 root root 4096 Feb 11 15:04 uevent diff --git a/Documentation/ABI/testing/sysfs-class-usb_role b/Documentation/ABI/testing/sysfs-class-usb_role new file mode 100644 index 0000000..3b810a4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-usb_role @@ -0,0 +1,21 @@ +What: /sys/class/usb_role/ +Date: Jan 2018 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + Place in sysfs for USB Role Switches. USB Role Switch is a + device that can select the data role (host or device) for USB + port. + +What: /sys/class/usb_role/<switch>/role +Date: Jan 2018 +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> +Description: + The current role of the switch. This attribute can be used for + requesting role swapping with non-USB Type-C ports. With USB + Type-C ports, the ABI defined for USB Type-C connector class + must be used. + + Valid values: + - none + - host + - device diff --git a/Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD b/Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD new file mode 100644 index 0000000..7e43cdc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD @@ -0,0 +1,113 @@ + ACPI Time and Alarm (TAD) device attributes. + +What: /sys/bus/platform/devices/ACPI000E:00/caps +Date: March 2018 +Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> +Description: + (RO) Hexadecimal bitmask of the TAD attributes are reported by + the platform firmware (see ACPI 6.2, section 9.18.2): + + BIT(0): AC wakeup implemented if set + BIT(1): DC wakeup implemented if set + BIT(2): Get/set real time features implemented if set + BIT(3): Real time accuracy in milliseconds if set + BIT(4): Correct status reported for wakeups from S4/S5 if set + BIT(5): The AC timer wakes up from S4 if set + BIT(6): The AC timer wakes up from S5 if set + BIT(7): The DC timer wakes up from S4 if set + BIT(8): The DC timer wakes up from S5 if set + + The other bits are reserved. + +What: /sys/bus/platform/devices/ACPI000E:00/ac_alarm +Date: March 2018 +Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> +Description: + (RW) The AC alarm timer value. + + Reads return the current AC alarm timer value in seconds or + "disabled", if the AC alarm is not set to wake up the system. + + Write a new AC alarm timer value in seconds or "disabled" to it + to set the AC alarm timer or to disable it, respectively. + + If the AC alarm timer is set through this attribute and it + expires, it will immediately wake up the system from the S3 + sleep state (and from S4/S5 too if supported) until its status + is explicitly cleared via the ac_status attribute. + +What: /sys/bus/platform/devices/ACPI000E:00/ac_policy +Date: March 2018 +Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> +Description: + (RW) The AC alarm expired timer wake policy (see ACPI 6.2, + Section 9.18 for details). + + Reads return the current expired timer wake delay for the AC + alarm timer or "never", if the policy is to discard AC timer + wakeups if the system is on DC power. + + Write a new expired timer wake delay for the AC alarm timer in + seconds or "never" to it to set the expired timer wake delay for + the AC alarm timer or to set its expired wake policy to discard + wakeups if the system is on DC power, respectively. + +What: /sys/bus/platform/devices/ACPI000E:00/ac_status +Date: March 2018 +Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> +Description: + (RW) The AC alarm status. + + Reads return a hexadecimal bitmask representing the AC alarm + timer status with the following meaning of bits (see ACPI 6.2, + Section 9.18.5): + + Bit(0): The timer has expired if set. + Bit(1): The timer has woken up the system from a sleep state + (S3 or S4/S5 if supported) if set. + + The other bits are reserved. + + Reads also cause the AC alarm timer status to be reset. + + Another way to reset the the status of the AC alarm timer is to + write (the number) 0 to this file. + + If the status return value indicates that the timer has expired, + it will immediately wake up the system from the S3 sleep state + (and from S4/S5 too if supported) until its status is explicitly + cleared through this attribute. + +What: /sys/bus/platform/devices/ACPI000E:00/dc_alarm +Date: March 2018 +Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> +Description: + (RW,optional) The DC alarm timer value. + + This attribute is only present if the TAD supports a separate + DC timer. + + It is analogous to the ac_alarm attribute. + +What: /sys/bus/platform/devices/ACPI000E:00/dc_policy +Date: March 2018 +Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> +Description: + (RW,optional) The DC alarm expired timer wake policy. + + This attribute is only present if the TAD supports a separate + DC timer. + + It is analogous to the ac_policy attribute. + +What: /sys/bus/platform/devices/ACPI000E:00/dc_status +Date: March 2018 +Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> + +Description: + (RW,optional) The DC alarm status. + + This attribute is only present if the TAD supports a separate + DC timer. + + It is analogous to the ac_status attribute. diff --git a/Documentation/ABI/testing/sysfs-devices-platform-ipmi b/Documentation/ABI/testing/sysfs-devices-platform-ipmi new file mode 100644 index 0000000..2a781e7 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-ipmi @@ -0,0 +1,238 @@ +What: /sys/devices/platform/ipmi_bmc.*/firmware_revision +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) The major and minor revision of the firmware. + + +What: /sys/devices/platform/ipmi_bmc.*/aux_firmware_revision +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Holds additional information about the firmware revision, + such as boot block or internal data structure version numbers. + The meanings of the numbers are specific to the vendor + identified by Manufacturer ID. + + +What: /sys/devices/platform/ipmi_bmc.*/revision +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Device revision. Useful for identifying if significant + hardware changes have been made to the implementation of the + management controller. + + +What: /sys/devices/platform/ipmi_bmc.*/provides_device_sdrs +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Indicates whether device provides device sensor data + records (1) or not (0). + + +What: /sys/devices/platform/ipmi_bmc.*/device_id +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Device id is specified by the manufacturer identified by + the Manufacturer ID field. This field allows controller specific + software to identify the unique application command, OEM + fields, and functionality that are provided by the controller + + +What: /sys/devices/platform/ipmi_bmc.*/additional_device_support +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Lists the IPMI ‘logical device’ commands and functions + that the controller supports that are in addition to the + mandatory IPM and Application commands. + + +What: /sys/devices/platform/ipmi_bmc.*/ipmi_version +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Displays the IPMI Command Specification Version. + + +What: /sys/devices/platform/ipmi_bmc.*/manufacturer_id +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Identifies the manufacturer responsible for the + specification of functionality of the vendor (OEM)-specific + commands, codes, and interfaces used in the controller. + + +What: /sys/devices/platform/ipmi_bmc.*/product_id +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Displays a number that identifies a particular system, + module, add-in card, or board set. The number is specified + according to the manufacturer given by Manufacturer ID. + +For detailed definitions of the above attributes, refer to section 20.1 'Get +Device ID Command' of the IPMI specification v2.0. + + +What: /sys/devices/platform/ipmi_bmc.*/guid +Date: Mar, 2006 +KernelVersion: v2.6.17 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) A GUID (Globally Unique ID), also referred to as a UUID + (Universally Unique Identifier), for the management controller, + as described in section 20.8 'Get Device GUID Command' of the + IPMI specification v2.0. + + +What: /sys/devices/platform/ipmi_si.*/type +Date: Sep, 2017 +KernelVersion: v4.15 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) The device interface for IPMI "kcs", "smic", "bt" or + "invalid" + +What: /sys/devices/platform/ipmi_si.*/idles +What: /sys/devices/platform/ipmi_si.*/watchdog_pretimeouts +What: /sys/devices/platform/ipmi_si.*/complete_transactions +What: /sys/devices/platform/ipmi_si.*/events +What: /sys/devices/platform/ipmi_si.*/interrupts +What: /sys/devices/platform/ipmi_si.*/hosed_count +What: /sys/devices/platform/ipmi_si.*/long_timeouts +What: /sys/devices/platform/ipmi_si.*/flag_fetches +What: /sys/devices/platform/ipmi_si.*/attentions +What: /sys/devices/platform/ipmi_si.*/incoming_messages +What: /sys/devices/platform/ipmi_si.*/short_timeouts +Date: Sep, 2017 +KernelVersion: v4.15 +Contact: openipmi-developer@lists.sourceforge.net +Description: + + idles: (RO) Number of times the interface was + idle while being polled. + + watchdog_pretimeouts: (RO) Number of watchdog pretimeouts. + + complete_transactions: (RO) Number of completed messages. + + events: (RO) Number of IPMI events received from + the hardware. + + interrupts: (RO) Number of interrupts the driver + handled. + + hosed_count: (RO) Number of times the hardware didn't + follow the state machine. + + long_timeouts: (RO) Number of times the driver + requested a timer while nothing was in + progress. + + flag_fetches: (RO) Number of times the driver + requested flags from the hardware. + + attentions: (RO) Number of time the driver got an + ATTN from the hardware. + + incoming_messages: (RO) Number of asynchronous messages + received. + + short_timeouts: (RO) Number of times the driver + requested a timer while an operation was + in progress. + + +What: /sys/devices/platform/ipmi_si.*/interrupts_enabled +Date: Sep, 2017 +KernelVersion: v4.15 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Indicates whether interrupts are enabled or not. The driver + disables interrupts when it gets into a situation where it + cannot handle messages due to lack of memory. Once that + situation clears up, it will re-enable interrupts. + + +What: /sys/devices/platform/ipmi_si.*/params +Date: Sep, 2017 +KernelVersion: v4.15 +Contact: openipmi-developer@lists.sourceforge.net +Description: + [to be documented] + + +What: /sys/devices/platform/dmi-ipmi-ssif.*/type +Date: Sep, 2017 +KernelVersion: v4.15 +Contact: openipmi-developer@lists.sourceforge.net +Description: + (RO) Shows the IMPI device interface type - "ssif" here. + + +What: /sys/devices/platform/dmi-ipmi-ssif.*/hosed +What: /sys/devices/platform/dmi-ipmi-ssif.*/alerts +What: /sys/devices/platform/dmi-ipmi-ssif.*/sent_messages +What: /sys/devices/platform/dmi-ipmi-ssif.*/sent_messages_parts +What: /sys/devices/platform/dmi-ipmi-ssif.*/received_messages +What: /sys/devices/platform/dmi-ipmi-ssif.*/received_message_parts +What: /sys/devices/platform/dmi-ipmi-ssif.*/events +What: /sys/devices/platform/dmi-ipmi-ssif.*/watchdog_pretimeouts +What: /sys/devices/platform/dmi-ipmi-ssif.*/flag_fetches +What: /sys/devices/platform/dmi-ipmi-ssif.*/send_retries +What: /sys/devices/platform/dmi-ipmi-ssif.*/receive_retries +What: /sys/devices/platform/dmi-ipmi-ssif.*/send_errors +What: /sys/devices/platform/dmi-ipmi-ssif.*/receive_errors +Date: Sep, 2017 +KernelVersion: v4.15 +Contact: openipmi-developer@lists.sourceforge.net +Description: + hosed: (RO) Number of times the hardware didn't + follow the state machine. + + alerts: (RO) Number of alerts received. + + sent_messages: (RO) Number of total messages sent. + + sent_message_parts: (RO) Number of message parts sent. + Messages may be broken into parts if + they are long. + + receieved_messages: (RO) Number of message responses + received. + + received_message_parts: (RO) Number of message fragments + received. + + events: (RO) Number of received events. + + watchdog_pretimeouts: (RO) Number of watchdog pretimeouts. + + flag_fetches: (RO) Number of times a flag fetch was + requested. + + send_retries: (RO) Number of time a message was + retried. + + receive_retries: (RO) Number of times the receive of a + message was retried. + + send_errors: (RO) Number of times the send of a + message failed. + + receive_errors: (RO) Number of errors in receiving + messages. diff --git a/Documentation/ABI/testing/sysfs-devices-platform-trackpoint b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint new file mode 100644 index 0000000..df11901 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint @@ -0,0 +1,115 @@ +What: /sys/devices/platform/i8042/.../sensitivity +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Trackpoint sensitivity. + +What: /sys/devices/platform/i8042/.../intertia +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Negative inertia factor. High values cause the cursor to + snap backward when the trackpoint is released. + +What: /sys/devices/platform/i8042/.../reach +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Backup range for z-axis press. + +What: /sys/devices/platform/i8042/.../draghys +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) The drag hysteresis controls how hard it is to drag with + z-axis pressed. + +What: /sys/devices/platform/i8042/.../mindrag +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Minimum amount of force needed to trigger dragging. + +What: /sys/devices/platform/i8042/.../speed +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Speed of the trackpoint cursor. + +What: /sys/devices/platform/i8042/.../thresh +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Minimum value for z-axis force required to trigger a press + or release, relative to the running average. + +What: /sys/devices/platform/i8042/.../upthresh +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) The offset from the running average required to generate a + select (click) on z-axis on release. + +What: /sys/devices/platform/i8042/.../ztime +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) This attribute determines how sharp a press has to be in + order to be recognized. + +What: /sys/devices/platform/i8042/.../jenks +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Minimum curvature in degrees required to generate a double + click without a release. + +What: /sys/devices/platform/i8042/.../skipback +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) When the skipback bit is set, backup cursor movement during + releases from drags will be suppressed. The default value for + this bit is 0. + +What: /sys/devices/platform/i8042/.../ext_dev +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Disable (0) or enable (1) external pointing device. + +What: /sys/devices/platform/i8042/.../press_to_select +Date: Aug, 2005 +KernelVersion: 2.6.14 +Contact: linux-input@vger.kernel.org +Description: + (RW) Writing a value of 1 to this file will enable the Press to + Select functions like tapping the control stick to simulate a + left click, and writing 0 will disable it. + +What: /sys/devices/platform/i8042/.../drift_time +Date: Dec, 2014 +KernelVersion: 3.19 +Contact: linux-input@vger.kernel.org +Description: + (RW) This parameter controls the period of time to test for a + ‘hands off’ condition (i.e. when no force is applied) before a + drift (noise) calibration occurs. + + IBM Trackpoints have a feature to compensate for drift by + recalibrating themselves periodically. By default, if for 0.5 + seconds there is no change in position, it's used as the new + zero. This duration is too low. Often, the calibration happens + when the trackpoint is in fact being used. diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 4ed63b6..025b7cf 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -198,6 +198,31 @@ Description: time (in microseconds) this cpu should spend in this idle state to make the transition worth the effort. +What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/ +Date: March 2018 +KernelVersion: v4.17 +Contact: Linux power management list <linux-pm@vger.kernel.org> +Description: + Idle state usage statistics related to suspend-to-idle. + + This attribute group is only present for states that can be + used in suspend-to-idle with suspended timekeeping. + +What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/time +Date: March 2018 +KernelVersion: v4.17 +Contact: Linux power management list <linux-pm@vger.kernel.org> +Description: + Total time spent by the CPU in suspend-to-idle (with scheduler + tick suspended) after requesting this state. + +What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/usage +Date: March 2018 +KernelVersion: v4.17 +Contact: Linux power management list <linux-pm@vger.kernel.org> +Description: + Total number of times this state has been requested by the CPU + while entering suspend-to-idle. What: /sys/devices/system/cpu/cpu#/cpufreq/* Date: pre-git history diff --git a/Documentation/ABI/testing/sysfs-driver-fsi-master-gpio b/Documentation/ABI/testing/sysfs-driver-fsi-master-gpio new file mode 100644 index 0000000..1f29c88 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-fsi-master-gpio @@ -0,0 +1,10 @@ +What: /sys/bus/platform/devices/[..]/fsi-master-gpio/external_mode +Date: Feb 2018 +KernelVersion: 4.17 +Contact: jk@ozlabs.org +Description: + Controls access arbitration for GPIO-based FSI master. A + value of 0 (the default) sets normal mode, where the + driver performs FSI bus transactions, 1 sets external mode, + where the FSI bus is driven externally (for example, by + a debug device). diff --git a/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp b/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp new file mode 100644 index 0000000..d8f831f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp @@ -0,0 +1,19 @@ +What: /sys/bus/hid/drivers/logitech-hidpp-device/<dev>/range +Date: Jan, 2016 +KernelVersion: 4.6 +Contact: linux-input@vger.kernel.org +Description: + (RW) This attribute controls the amount of 'turn' permitted in + Logitech G920 wheel. Reading from the file shows the current + range of the steering wheel. Writing a value within the min and + max boundary sets the range of the wheel. + +What: /sys/bus/hid/drivers/logitech-hidpp-device/<dev>/builtin_power_supply +Date: Apr, 2017 +KernelVersion: 4.12 +Contact: linux-input@vger.kernel.org +Description: + Presence of this file indicates that HID++ driver is capable of + handling battery properties in the kernel. This way, upower can + add a udev rule to decide whether or not it should use the + internal unifying support or the generic kernel one. diff --git a/Documentation/ABI/testing/sysfs-driver-hid-ntrig b/Documentation/ABI/testing/sysfs-driver-hid-ntrig new file mode 100644 index 0000000..e574a56 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-ntrig @@ -0,0 +1,70 @@ +What: /sys/bus/hid/drivers/ntrig/<dev>/activate_slack +Date: May, 2010 +KernelVersion: 2.6.35 +Contact: linux-input@vger.kernel.org +Description: + (RW) Number of contact frames ignored before acknowledging the + start of activity (activating touch). + + +What: /sys/bus/hid/drivers/ntrig/<dev>/decativate_slack +Date: May, 2010 +KernelVersion: 2.6.35 +Contact: linux-input@vger.kernel.org +Description: + (RW) Number of empty (no contact) frames ignored before + acknowledging the end of activity (deactivating touch). + + When the last finger is removed from the device, it sends a + number of empty frames. By holding off on deactivation for a few + frames false erroneous disconnects can be tolerated, where the + sensor may mistakenly not detect a finger that is still present. + + +What: /sys/bus/hid/drivers/ntrig/<dev>/activation_width +What: /sys/bus/hid/drivers/ntrig/<dev>/activation_height +Date: May, 2010 +KernelVersion: 2.6.35 +Contact: linux-input@vger.kernel.org +Description: + Threholds to override activation slack. + + activation_width: (RW) Width threshold to immediately + start processing touch events. + + activation_height: (RW) Height threshold to immediately + start processing touch events. + + +What: /sys/bus/hid/drivers/ntrig/<dev>/min_width +What: /sys/bus/hid/drivers/ntrig/<dev>/min_height +Date: May, 2010 +KernelVersion: 2.6.35 +Contact: linux-input@vger.kernel.org +Description: + Minimum size contact accepted. + + min_width: (RW) Minimum touch contact width to decide + activation and activity. + + min_height: (RW) Minimum touch contact height to decide + activation and activity. + + +What: /sys/bus/hid/drivers/ntrig/<dev>/sensor_physical_width +What: /sys/bus/hid/drivers/ntrig/<dev>/sensor_physical_height +Date: May, 2010 +KernelVersion: 2.6.35 +Contact: linux-input@vger.kernel.org +Description: + (RO) These are internal ranges not used for normal events but + useful for tuning. + + +What: /sys/bus/hid/drivers/ntrig/<dev>/sensor_logical_width +What: /sys/bus/hid/drivers/ntrig/<dev>/sensor_logical_height +Date: May, 2010 +KernelVersion: 2.6.35 +Contact: linux-input@vger.kernel.org +Description: + (RO) The range for positions reported during activity. diff --git a/Documentation/ABI/testing/sysfs-kernel-irq b/Documentation/ABI/testing/sysfs-kernel-irq index eb074b1..8910d0c 100644 --- a/Documentation/ABI/testing/sysfs-kernel-irq +++ b/Documentation/ABI/testing/sysfs-kernel-irq @@ -51,3 +51,10 @@ Date: September 2016 KernelVersion: 4.9 Contact: Craig Gallek <kraig@google.com> Description: The type of the interrupt. Either the string 'level' or 'edge'. + +What: /sys/kernel/irq/<irq>/wakeup +Date: March 2018 +KernelVersion: 4.17 +Contact: Andy Shevchenko <andriy.shevchenko@linux.intel.com> +Description: The wakeup state of the interrupt. Either the string + 'enabled' or 'disabled'. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 1e0d1da..2f813d6 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -287,3 +287,17 @@ Description: Writing a "1" to this file enables the debug messages and writing a "0" (default) to it disables them. Reads from this file return the current value. + +What: /sys/power/resume_offset +Date: April 2018 +Contact: Mario Limonciello <mario.limonciello@dell.com> +Description: + This file is used for telling the kernel an offset into a disk + to use when hibernating the system such as with a swap file. + + Reads from this file will display the current offset + the kernel will be using on the next hibernation + attempt. + + Using this sysfs file will override any values that were + set using the kernel command line for disk offset.
\ No newline at end of file diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index af5a437..02caa7e 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -26,8 +26,8 @@ On what hardware does it run? Although originally developed first for 32-bit x86-based PCs (386 or higher), today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, - IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, - Xtensa, Tilera TILE, ARC and Renesas M32R architectures. + IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 Xtensa, and + ARC architectures. Linux is easily portable to most general-purpose 32- or 64-bit architectures as long as they have a paged memory management unit (PMMU) and a port of the @@ -218,6 +218,13 @@ Configuring the kernel "make localyesconfig" Similar to localmodconfig, except it will convert all module options to built in (=y) options. + "make kvmconfig" Enable additional options for kvm guest kernel support. + + "make xenconfig" Enable additional options for xen dom0 guest kernel + support. + + "make tinyconfig" Configure the tiniest possible kernel. + You can find more information on using the Linux kernel config tools in Documentation/kbuild/kconfig.txt. diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 7242cbd..b8d0bc0 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -89,7 +89,6 @@ parameter is applicable:: APM Advanced Power Management support is enabled. ARM ARM architecture is enabled. AX25 Appropriate AX.25 support is enabled. - BLACKFIN Blackfin architecture is enabled. CLK Common clock infrastructure is enabled. CMA Contiguous Memory Area support is enabled. DRM Direct Rendering Management support is enabled. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 1d1d53f..34dac7c 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1025,7 +1025,7 @@ address. The serial port must already be setup and configured. Options are not yet supported. - earlyprintk= [X86,SH,BLACKFIN,ARM,M68k,S390] + earlyprintk= [X86,SH,ARM,M68k,S390] earlyprintk=vga earlyprintk=efi earlyprintk=sclp @@ -1347,10 +1347,6 @@ If specified, z/VM IUCV HVC accepts connections from listed z/VM user IDs only. - hwthread_map= [METAG] Comma-separated list of Linux cpu id to - hardware thread id mappings. - Format: <cpu>:<hwthread> - keep_bootcon [KNL] Do not unregister boot console at start. This is only useful for debugging when something happens in the window @@ -1743,6 +1739,14 @@ of a GICv2 controller even if the memory range exposed by the device tree is too small. + irqchip.gicv3_nolpi= + [ARM, ARM64] + Force the kernel to ignore the availability of + LPIs (and by consequence ITSs). Intended for system + that use the kernel as a bootloader, and thus want + to let secondary kernels in charge of setting up + LPIs. + irqfixup [HW] When an interrupt is not handled search all handlers for it. Intended to get systems with badly broken @@ -1766,6 +1770,17 @@ nohz Disable the tick when a single task runs. + + A residual 1Hz tick is offloaded to workqueues, which you + need to affine to housekeeping through the global + workqueue's affinity configured via the + /sys/devices/virtual/workqueue/cpumask sysfs file, or + by using the 'domain' flag described below. + + NOTE: by default the global workqueue runs on all CPUs, + so to protect individual CPUs the 'cpumask' file has to + be configured manually after bootup. + domain Isolate from the general SMP balancing and scheduling algorithms. Note that performing domain isolation this way @@ -2237,6 +2252,15 @@ The memory region may be marked as e820 type 12 (0xc) and is NVDIMM or ADR memory. + memmap=<size>%<offset>-<oldtype>+<newtype> + [KNL,ACPI] Convert memory within the specified region + from <oldtype> to <newtype>. If "-<oldtype>" is left + out, the whole region will be marked as <newtype>, + even if previously unavailable. If "+<newtype>" is left + out, matching memory will be removed. Types are + specified as e820 types, e.g., 1 = RAM, 2 = reserved, + 3 = ACPI, 12 = PRAM. + memory_corruption_check=0/1 [X86] Some BIOSes seem to corrupt the first 64k of memory when doing things like suspend/resume. @@ -4368,12 +4392,73 @@ usbcore.nousb [USB] Disable the USB subsystem + usbcore.quirks= + [USB] A list of quirk entries to augment the built-in + usb core quirk list. List entries are separated by + commas. Each entry has the form + VendorID:ProductID:Flags. The IDs are 4-digit hex + numbers and Flags is a set of letters. Each letter + will change the built-in quirk; setting it if it is + clear and clearing it if it is set. The letters have + the following meanings: + a = USB_QUIRK_STRING_FETCH_255 (string + descriptors must not be fetched using + a 255-byte read); + b = USB_QUIRK_RESET_RESUME (device can't resume + correctly so reset it instead); + c = USB_QUIRK_NO_SET_INTF (device can't handle + Set-Interface requests); + d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't + handle its Configuration or Interface + strings); + e = USB_QUIRK_RESET (device can't be reset + (e.g morph devices), don't use reset); + f = USB_QUIRK_HONOR_BNUMINTERFACES (device has + more interface descriptions than the + bNumInterfaces count, and can't handle + talking to these interfaces); + g = USB_QUIRK_DELAY_INIT (device needs a pause + during initialization, after we read + the device descriptor); + h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For + high speed and super speed interrupt + endpoints, the USB 2.0 and USB 3.0 spec + require the interval in microframes (1 + microframe = 125 microseconds) to be + calculated as interval = 2 ^ + (bInterval-1). + Devices with this quirk report their + bInterval as the result of this + calculation instead of the exponent + variable used in the calculation); + i = USB_QUIRK_DEVICE_QUALIFIER (device can't + handle device_qualifier descriptor + requests); + j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device + generates spurious wakeup, ignore + remote wakeup capability); + k = USB_QUIRK_NO_LPM (device can't handle Link + Power Management); + l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL + (Device reports its bInterval as linear + frames instead of the USB 2.0 + calculation); + m = USB_QUIRK_DISCONNECT_SUSPEND (Device needs + to be disconnected before suspend to + prevent spurious wakeup); + n = USB_QUIRK_DELAY_CTRL_MSG (Device needs a + pause after every control message); + Example: quirks=0781:5580:bk,0a5c:5834:gij + usbhid.mousepoll= [USBHID] The interval which mice are to be polled at. usbhid.jspoll= [USBHID] The interval which joysticks are to be polled at. + usbhid.kbpoll= + [USBHID] The interval which keyboards are to be polled at. + usb-storage.delay_use= [UMS] The delay in seconds before a new device is scanned for Logical Units (default 1). diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 27e5949..f8b5841 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -180,11 +180,11 @@ Public keys in the kernel ========================= The kernel contains a ring of public keys that can be viewed by root. They're -in a keyring called ".system_keyring" that can be seen by:: +in a keyring called ".builtin_trusted_keys" that can be seen by:: [root@deneb ~]# cat /proc/keys ... - 223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1 + 223c7853 I------ 1 perm 1f030000 0 0 keyring .builtin_trusted_keys: 1 302d2d52 I------ 1 perm 1f010000 0 0 asymmetri Fedora kernel signing key: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ... @@ -197,15 +197,15 @@ add those in also (e.g. from the UEFI key database). Finally, it is possible to add additional public keys by doing:: - keyctl padd asymmetric "" [.system_keyring-ID] <[key-file] + keyctl padd asymmetric "" [.builtin_trusted_keys-ID] <[key-file] e.g.:: keyctl padd asymmetric "" 0x223c7853 <my_public_key.x509 Note, however, that the kernel will only permit keys to be added to -``.system_keyring _if_`` the new key's X.509 wrapper is validly signed by a key -that is already resident in the .system_keyring at the time the key was added. +``.builtin_trusted_keys`` **if** the new key's X.509 wrapper is validly signed by a key +that is already resident in the ``.builtin_trusted_keys`` at the time the key was added. ======================== diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst index 47574b3..30491d9 100644 --- a/Documentation/admin-guide/security-bugs.rst +++ b/Documentation/admin-guide/security-bugs.rst @@ -29,18 +29,20 @@ made public. Disclosure ---------- -The goal of the Linux kernel security team is to work with the -bug submitter to bug resolution as well as disclosure. We prefer -to fully disclose the bug as soon as possible. It is reasonable to -delay disclosure when the bug or the fix is not yet fully understood, -the solution is not well-tested or for vendor coordination. However, we -expect these delays to be short, measurable in days, not weeks or months. -A disclosure date is negotiated by the security team working with the -bug submitter as well as vendors. However, the kernel security team -holds the final say when setting a disclosure date. The timeframe for -disclosure is from immediate (esp. if it's already publicly known) +The goal of the Linux kernel security team is to work with the bug +submitter to understand and fix the bug. We prefer to publish the fix as +soon as possible, but try to avoid public discussion of the bug itself +and leave that to others. + +Publishing the fix may be delayed when the bug or the fix is not yet +fully understood, the solution is not well-tested or for vendor +coordination. However, we expect these delays to be short, measurable in +days, not weeks or months. A release date is negotiated by the security +team working with the bug submitter as well as vendors. However, the +kernel security team holds the final say when setting a timeframe. The +timeframe varies from immediate (esp. if it's already publicly known bug) to a few weeks. As a basic default policy, we expect report date to -disclosure date to be on the order of 7 days. +release date to be on the order of 7 days. Coordination ------------ diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index 1df03b5..28a869c 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -6,34 +6,34 @@ counter. This indicates that the kernel has been tainted by some mechanism. The string is followed by a series of position-sensitive characters, each representing a particular tainted value. - 1) 'G' if all modules loaded have a GPL or compatible license, 'P' if + 1) ``G`` if all modules loaded have a GPL or compatible license, ``P`` if any proprietary module has been loaded. Modules without a MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary. - 2) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all + 2) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all modules were loaded normally. - 3) ``S`` if the oops occurred on an SMP kernel running on hardware that + 3) ``S`` if the oops occurred on an SMP kernel running on hardware that hasn't been certified as safe to run multiprocessor. Currently this occurs only on various Athlons that are not SMP capable. - 4) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all + 4) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all modules were unloaded normally. - 5) ``M`` if any processor has reported a Machine Check Exception, + 5) ``M`` if any processor has reported a Machine Check Exception, ``' '`` if no Machine Check Exceptions have occurred. - 6) ``B`` if a page-release function has found a bad page reference or + 6) ``B`` if a page-release function has found a bad page reference or some unexpected page flags. - 7) ``U`` if a user or user application specifically requested that the + 7) ``U`` if a user or user application specifically requested that the Tainted flag be set, ``' '`` otherwise. - 8) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG. + 8) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG. - 9) ``A`` if the ACPI table has been overridden. + 9) ``A`` if the ACPI table has been overridden. 10) ``W`` if a warning has previously been issued by the kernel. (Though some warnings may set more specific taint flags.) diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index 9948ec3..35fccba 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -21,11 +21,11 @@ vulnerable to DMA attacks. Security levels and how to use them ----------------------------------- Starting with Intel Falcon Ridge Thunderbolt controller there are 4 -security levels available. The reason for these is the fact that the -connected devices can be DMA masters and thus read contents of the host -memory without CPU and OS knowing about it. There are ways to prevent -this by setting up an IOMMU but it is not always available for various -reasons. +security levels available. Intel Titan Ridge added one more security level +(usbonly). The reason for these is the fact that the connected devices can +be DMA masters and thus read contents of the host memory without CPU and OS +knowing about it. There are ways to prevent this by setting up an IOMMU but +it is not always available for various reasons. The security levels are as follows: @@ -52,6 +52,11 @@ The security levels are as follows: USB. No PCIe tunneling is done. In BIOS settings this is typically called *Display Port Only*. + usbonly + The firmware automatically creates tunnels for the USB controller and + Display Port in a dock. All PCIe links downstream of the dock are + removed. + The current security level can be read from ``/sys/bus/thunderbolt/devices/domainX/security`` where ``domainX`` is the Thunderbolt domain the host controller manages. There is typically diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt index a70090b..7964f03 100644 --- a/Documentation/arm64/cpu-feature-registers.txt +++ b/Documentation/arm64/cpu-feature-registers.txt @@ -110,7 +110,7 @@ infrastructure: x--------------------------------------------------x | Name | bits | visible | |--------------------------------------------------| - | RES0 | [63-52] | n | + | TS | [55-52] | y | |--------------------------------------------------| | FHM | [51-48] | y | |--------------------------------------------------| @@ -124,8 +124,6 @@ infrastructure: |--------------------------------------------------| | RDM | [31-28] | y | |--------------------------------------------------| - | RES0 | [27-24] | n | - |--------------------------------------------------| | ATOMICS | [23-20] | y | |--------------------------------------------------| | CRC32 | [19-16] | y | @@ -135,8 +133,6 @@ infrastructure: | SHA1 | [11-8] | y | |--------------------------------------------------| | AES | [7-4] | y | - |--------------------------------------------------| - | RES0 | [3-0] | n | x--------------------------------------------------x @@ -144,12 +140,10 @@ infrastructure: x--------------------------------------------------x | Name | bits | visible | |--------------------------------------------------| - | RES0 | [63-36] | n | + | DIT | [51-48] | y | |--------------------------------------------------| | SVE | [35-32] | y | |--------------------------------------------------| - | RES0 | [31-28] | n | - |--------------------------------------------------| | GIC | [27-24] | n | |--------------------------------------------------| | AdvSIMD | [23-20] | y | @@ -199,6 +193,14 @@ infrastructure: | DPB | [3-0] | y | x--------------------------------------------------x + 5) ID_AA64MMFR2_EL1 - Memory model feature register 2 + + x--------------------------------------------------x + | Name | bits | visible | + |--------------------------------------------------| + | AT | [35-32] | y | + x--------------------------------------------------x + Appendix I: Example --------------------------- diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt index 57324ee..d6aff2c 100644 --- a/Documentation/arm64/elf_hwcaps.txt +++ b/Documentation/arm64/elf_hwcaps.txt @@ -162,3 +162,19 @@ HWCAP_SVE HWCAP_ASIMDFHM Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001. + +HWCAP_DIT + + Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001. + +HWCAP_USCAT + + Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001. + +HWCAP_ILRCPC + + Functionality implied by ID_AA64ISR1_EL1.LRCPC == 0b0002. + +HWCAP_FLAGM + + Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001. diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt index c1d520d..3b2f2dd 100644 --- a/Documentation/arm64/silicon-errata.txt +++ b/Documentation/arm64/silicon-errata.txt @@ -55,6 +55,7 @@ stable kernels. | ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | | ARM | Cortex-A72 | #853709 | N/A | | ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 | +| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 | | ARM | MMU-500 | #841119,#826419 | N/A | | | | | | | Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 | diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX deleted file mode 100644 index 265a1ef..0000000 --- a/Documentation/blackfin/00-INDEX +++ /dev/null @@ -1,6 +0,0 @@ -00-INDEX - - This file -bfin-gpio-notes.txt - - Notes in developing/using bfin-gpio driver. -bfin-spi-notes.txt - - Notes for using bfin spi bus driver. diff --git a/Documentation/blackfin/bfin-gpio-notes.txt b/Documentation/blackfin/bfin-gpio-notes.txt deleted file mode 100644 index d245f39..0000000 --- a/Documentation/blackfin/bfin-gpio-notes.txt +++ /dev/null @@ -1,71 +0,0 @@ -/* - * File: Documentation/blackfin/bfin-gpio-notes.txt - * Based on: - * Author: - * - * Created: $Id: bfin-gpio-note.txt 2008-11-24 16:42 grafyang $ - * Description: This file contains the notes in developing/using bfin-gpio. - * - * - * Rev: - * - * Modified: - * Copyright 2004-2008 Analog Devices Inc. - * - * Bugs: Enter bugs at http://blackfin.uclinux.org/ - * - */ - - -1. Blackfin GPIO introduction - - There are many GPIO pins on Blackfin. Most of these pins are muxed to - multi-functions. They can be configured as peripheral, or just as GPIO, - configured to input with interrupt enabled, or output. - - For detailed information, please see "arch/blackfin/kernel/bfin_gpio.c", - or the relevant HRM. - - -2. Avoiding resource conflict - - Followed function groups are used to avoiding resource conflict, - - Use the pin as peripheral, - int peripheral_request(unsigned short per, const char *label); - int peripheral_request_list(const unsigned short per[], const char *label); - void peripheral_free(unsigned short per); - void peripheral_free_list(const unsigned short per[]); - - Use the pin as GPIO, - int bfin_gpio_request(unsigned gpio, const char *label); - void bfin_gpio_free(unsigned gpio); - - Use the pin as GPIO interrupt, - int bfin_gpio_irq_request(unsigned gpio, const char *label); - void bfin_gpio_irq_free(unsigned gpio); - - The request functions will record the function state for a certain pin, - the free functions will clear its function state. - Once a pin is requested, it can't be requested again before it is freed by - previous caller, otherwise kernel will dump stacks, and the request - function fail. - These functions are wrapped by other functions, most of the users need not - care. - - -3. But there are some exceptions - - Kernel permit the identical GPIO be requested both as GPIO and GPIO - interrupt. - Some drivers, like gpio-keys, need this behavior. Kernel only print out - warning messages like, - bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are -configuring it as IRQ! - - Note: Consider the case that, if there are two drivers need the - identical GPIO, one of them use it as GPIO, the other use it as - GPIO interrupt. This will really cause resource conflict. So if - there is any abnormal driver behavior, please check the bfin-gpio - warning messages. - - - Kernel permit the identical GPIO be requested from the same driver twice. - - - diff --git a/Documentation/blackfin/bfin-spi-notes.txt b/Documentation/blackfin/bfin-spi-notes.txt deleted file mode 100644 index eae6eaf..0000000 --- a/Documentation/blackfin/bfin-spi-notes.txt +++ /dev/null @@ -1,16 +0,0 @@ -SPI Chip Select behavior: - -With the Blackfin on-chip SPI peripheral, there is some logic tied to the CPHA -bit whether the Slave Select Line is controlled by hardware (CPHA=0) or -controlled by software (CPHA=1). However, the Linux SPI bus driver assumes that -the Slave Select is always under software control and being asserted during -the entire SPI transfer. - And not just bits_per_word duration. - -In most cases you can utilize SPI MODE_3 instead of MODE_0 to work-around this -behavior. If your SPI slave device in question requires SPI MODE_0 or MODE_2 -timing, you can utilize the GPIO controlled SPI Slave Select option instead. -In this case, you should use GPIO based CS for all of your slaves and not just -the ones using mode 0 or 2 in order to guarantee correct CS toggling behavior. - -You can even use the same pin whose peripheral role is a SSEL, -but use it as a GPIO instead. diff --git a/Documentation/bpf/bpf_devel_QA.txt b/Documentation/bpf/bpf_devel_QA.txt index 84cbb30..1a0b704 100644 --- a/Documentation/bpf/bpf_devel_QA.txt +++ b/Documentation/bpf/bpf_devel_QA.txt @@ -539,6 +539,18 @@ A: Although LLVM IR generation and optimization try to stay architecture The clang option "-fno-jump-tables" can be used to disable switch table generation. + - For clang -target bpf, it is guaranteed that pointer or long / + unsigned long types will always have a width of 64 bit, no matter + whether underlying clang binary or default target (or kernel) is + 32 bit. However, when native clang target is used, then it will + compile these types based on the underlying architecture's conventions, + meaning in case of 32 bit architecture, pointer or long / unsigned + long types e.g. in BPF context structure will have width of 32 bit + while the BPF LLVM back end still operates in 64 bit. The native + target is mostly needed in tracing for the case of walking pt_regs + or other kernel structures where CPU's register width matters. + Otherwise, clang -target bpf is generally recommended. + You should use default target when: - Your program includes a header file, e.g., ptrace.h, which eventually diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index 934559b..eb30efd 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -60,8 +60,8 @@ Plain Pointers Pointers printed without a specifier extension (i.e unadorned %p) are hashed to prevent leaking information about the kernel memory layout. This has the added benefit of providing a unique identifier. On 64-bit machines -the first 32 bits are zeroed. If you *really* want the address see %px -below. +the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it +gathers enough entropy. If you *really* want the address see %px below. Symbols/Function Pointers ------------------------- diff --git a/Documentation/cris/README b/Documentation/cris/README deleted file mode 100644 index 8dbdb1a..0000000 --- a/Documentation/cris/README +++ /dev/null @@ -1,195 +0,0 @@ -Linux on the CRIS architecture -============================== - -This is a port of Linux to Axis Communications ETRAX 100LX, -ETRAX FS and ARTPEC-3 embedded network CPUs. - -For more information about CRIS and ETRAX please see further below. - -In order to compile this you need a version of gcc with support for the -ETRAX chip family. Please see this link for more information on how to -download the compiler and other tools useful when building and booting -software for the ETRAX platform: - -http://developer.axis.com/wiki/doku.php?id=axis:install-howto-2_20 - -What is CRIS ? --------------- - -CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU -architecture in Axis Communication AB's range of embedded network CPU's, -called ETRAX. - -The ETRAX 100LX chip --------------------- - -For reference, please see the following link: - -http://www.axis.com/products/dev_etrax_100lx/index.htm - -The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad -range of built-in interfaces, all with modern scatter/gather DMA. - -Memory interfaces: - - * SRAM - * NOR-flash/ROM - * EDO or page-mode DRAM - * SDRAM - -I/O interfaces: - - * one 10/100 Mbit/s ethernet controller - * four serial-ports (up to 6 Mbit/s) - * two synchronous serial-ports for multimedia codec's etc. - * USB host controller and USB slave - * ATA - * SCSI - * two parallel-ports - * two generic 8-bit ports - - (not all interfaces are available at the same time due to chip pin - multiplexing) - -ETRAX 100LX is CRISv10 architecture. - - -The ETRAX FS and ARTPEC-3 chips -------------------------------- - -The ETRAX FS is a 200MHz 32-bit RISC processor with on-chip 16kB -I-cache and 16kB D-cache and with a wide range of device interfaces -including multiple high speed serial ports and an integrated USB 1.1 PHY. - -The ARTPEC-3 is a variant of the ETRAX FS with additional IO-units -used by the Axis Communications network cameras. - -See below link for more information: - -http://www.axis.com/products/dev_etrax_fs/index.htm - -ETRAX FS and ARTPEC-3 are both CRISv32 architectures. - -Bootlog -------- - -Just as an example, this is the debug-output from a boot of Linux 2.4 on -a board with ETRAX 100LX. The displayed BogoMIPS value is 5 times too small :) -At the end you see some user-mode programs booting like telnet and ftp daemons. - -Linux version 2.4.1 (bjornw@godzilla.axis.se) (gcc version 2.96 20000427 (experimental)) #207 Wed Feb 21 15:48:15 CET 2001 -ROM fs in RAM, size 1376256 bytes -Setting up paging and the MMU. -On node 0 totalpages: 2048 -zone(0): 2048 pages. -zone(1): 0 pages. -zone(2): 0 pages. -Linux/CRIS port on ETRAX 100LX (c) 2001 Axis Communications AB -Kernel command line: -Calibrating delay loop... 19.91 BogoMIPS -Memory: 13872k/16384k available (587k kernel code, 2512k reserved, 44k data, 24k init) -kmem_create: Forcing size word alignment - vm_area_struct -kmem_create: Forcing size word alignment - filp -Dentry-cache hash table entries: 2048 (order: 1, 16384 bytes) -Buffer-cache hash table entries: 2048 (order: 0, 8192 bytes) -Page-cache hash table entries: 2048 (order: 0, 8192 bytes) -kmem_create: Forcing size word alignment - kiobuf -kmem_create: Forcing size word alignment - bdev_cache -Inode-cache hash table entries: 1024 (order: 0, 8192 bytes) -kmem_create: Forcing size word alignment - inode_cache -POSIX conformance testing by UNIFIX -Linux NET4.0 for Linux 2.4 -Based upon Swansea University Computer Society NET3.039 -Starting kswapd v1.8 -kmem_create: Forcing size word alignment - file lock cache -kmem_create: Forcing size word alignment - blkdev_requests -block: queued sectors max/low 9109kB/3036kB, 64 slots per queue -ETRAX 100LX 10/100MBit ethernet v2.0 (c) 2000 Axis Communications AB -eth0 initialized -eth0: changed MAC to 00:40:8C:CD:00:00 -ETRAX 100LX serial-driver $Revision: 1.7 $, (c) 2000 Axis Communications AB -ttyS0 at 0xb0000060 is a builtin UART with DMA -ttyS1 at 0xb0000068 is a builtin UART with DMA -ttyS2 at 0xb0000070 is a builtin UART with DMA -ttyS3 at 0xb0000078 is a builtin UART with DMA -Axis flash mapping: 200000 at 50000000 -Axis flash: Found 1 x16 CFI device at 0x0 in 16 bit mode - Amd/Fujitsu Extended Query Table v1.0 at 0x0040 -Axis flash: JEDEC Device ID is 0xC4. Assuming broken CFI table. -Axis flash: Swapping erase regions for broken CFI table. -number of CFI chips: 1 - Using default partition table -I2C driver v2.2, (c) 1999-2001 Axis Communications AB -ETRAX 100LX GPIO driver v2.1, (c) 2001 Axis Communications AB -NET4: Linux TCP/IP 1.0 for NET4.0 -IP Protocols: ICMP, UDP, TCP -kmem_create: Forcing size word alignment - ip_dst_cache -IP: routing cache hash table of 1024 buckets, 8Kbytes -TCP: Hash tables configured (established 2048 bind 2048) -NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. -VFS: Mounted root (cramfs filesystem) readonly. -Init starts up... -Mounted none on /proc ok. -Setting up eth0 with ip 10.13.9.116 and mac 00:40:8c:18:04:60 -eth0: changed MAC to 00:40:8C:18:04:60 -Setting up lo with ip 127.0.0.1 -Default gateway is 10.13.9.1 -Hostname is bbox1 -Telnetd starting, using port 23. - using /bin/sash as shell. -sftpd[15]: sftpd $Revision: 1.7 $ starting up - - - -And here is how some /proc entries look: - -17# cd /proc -17# cat cpuinfo -cpu : CRIS -cpu revision : 10 -cpu model : ETRAX 100LX -cache size : 8 kB -fpu : no -mmu : yes -ethernet : 10/100 Mbps -token ring : no -scsi : yes -ata : yes -usb : yes -bogomips : 99.84 - -17# cat meminfo - total: used: free: shared: buffers: cached: -Mem: 7028736 925696 6103040 114688 0 229376 -Swap: 0 0 0 -MemTotal: 6864 kB -MemFree: 5960 kB -MemShared: 112 kB -Buffers: 0 kB -Cached: 224 kB -Active: 224 kB -Inact_dirty: 0 kB -Inact_clean: 0 kB -Inact_target: 0 kB -HighTotal: 0 kB -HighFree: 0 kB -LowTotal: 6864 kB -LowFree: 5960 kB -SwapTotal: 0 kB -SwapFree: 0 kB -17# ls -l /bin --rwxr-xr-x 1 342 100 10356 Jan 01 00:00 ifconfig --rwxr-xr-x 1 342 100 17548 Jan 01 00:00 init --rwxr-xr-x 1 342 100 9488 Jan 01 00:00 route --rwxr-xr-x 1 342 100 46036 Jan 01 00:00 sftpd --rwxr-xr-x 1 342 100 48104 Jan 01 00:00 sh --rwxr-xr-x 1 342 100 16252 Jan 01 00:00 telnetd - - - - - - - - - diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst new file mode 100644 index 0000000..8272ac9 --- /dev/null +++ b/Documentation/crypto/crypto_engine.rst @@ -0,0 +1,48 @@ +============= +CRYPTO ENGINE +============= + +Overview +-------- +The crypto engine API (CE), is a crypto queue manager. + +Requirement +----------- +You have to put at start of your tfm_ctx the struct crypto_engine_ctx +struct your_tfm_ctx { + struct crypto_engine_ctx enginectx; + ... +}; +Why: Since CE manage only crypto_async_request, it cannot know the underlying +request_type and so have access only on the TFM. +So using container_of for accessing __ctx is impossible. +Furthermore, the crypto engine cannot know the "struct your_tfm_ctx", +so it must assume that crypto_engine_ctx is at start of it. + +Order of operations +------------------- +You have to obtain a struct crypto_engine via crypto_engine_alloc_init(). +And start it via crypto_engine_start(). + +Before transferring any request, you have to fill the enginectx. +- prepare_request: (taking a function pointer) If you need to do some processing before doing the request +- unprepare_request: (taking a function pointer) Undoing what's done in prepare_request +- do_one_request: (taking a function pointer) Do encryption for current request + +Note: that those three functions get the crypto_async_request associated with the received request. +So your need to get the original request via container_of(areq, struct yourrequesttype_request, base); + +When your driver receive a crypto_request, you have to transfer it to +the cryptoengine via one of: +- crypto_transfer_ablkcipher_request_to_engine() +- crypto_transfer_aead_request_to_engine() +- crypto_transfer_akcipher_request_to_engine() +- crypto_transfer_hash_request_to_engine() +- crypto_transfer_skcipher_request_to_engine() + +At the end of the request process, a call to one of the following function is needed: +- crypto_finalize_ablkcipher_request +- crypto_finalize_aead_request +- crypto_finalize_akcipher_request +- crypto_finalize_hash_request +- crypto_finalize_skcipher_request diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst index 66f50d3..c45c6f4 100644 --- a/Documentation/crypto/devel-algos.rst +++ b/Documentation/crypto/devel-algos.rst @@ -236,6 +236,14 @@ when used from another part of the kernel. | '---------------> HASH2 +Note that it is perfectly legal to "abandon" a request object: +- call .init() and then (as many times) .update() +- _not_ call any of .final(), .finup() or .export() at any point in future + +In other words implementations should mind the resource allocation and clean-up. +No resources related to request objects should remain allocated after a call +to .init() or .update(), since there might be no chance to free them. + Specifics Of Asynchronous HASH Transformation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst index cb88626..e6f5126 100644 --- a/Documentation/dev-tools/kmemleak.rst +++ b/Documentation/dev-tools/kmemleak.rst @@ -8,7 +8,7 @@ with the difference that the orphan objects are not freed but only reported via /sys/kernel/debug/kmemleak. A similar method is used by the Valgrind tool (``memcheck --leak-check``) to detect the memory leaks in user-space applications. -Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390 and tile. Usage ----- diff --git a/Documentation/dev-tools/sparse.rst b/Documentation/dev-tools/sparse.rst index 78aa00a..c401c95 100644 --- a/Documentation/dev-tools/sparse.rst +++ b/Documentation/dev-tools/sparse.rst @@ -67,7 +67,7 @@ __releases - The specified lock is held on function entry, but not exit. If the function enters and exits without the lock held, acquiring and releasing the lock inside the function in a balanced way, no -annotation is needed. The tree annotations above are for cases where +annotation is needed. The three annotations above are for cases where sparse would otherwise report a context imbalance. Getting sparse diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index 7111fbc8..199cd36 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -75,6 +75,29 @@ Example: }; ----------------------------------------------------------------------- +Hisilicon Hi3798CV200 Peripheral Controller + +The Hi3798CV200 Peripheral Controller controls peripherals, queries +their status, and configures some functions of peripherals. + +Required properties: +- compatible: Should contain "hisilicon,hi3798cv200-perictrl", "syscon" + and "simple-mfd". +- reg: Register address and size of Peripheral Controller. +- #address-cells: Should be 1. +- #size-cells: Should be 1. + +Examples: + + perictrl: peripheral-controller@8a20000 { + compatible = "hisilicon,hi3798cv200-perictrl", "syscon", + "simple-mfd"; + reg = <0x8a20000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + }; + +----------------------------------------------------------------------- Hisilicon Hi6220 system controller Required properties: diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index c760ecb..f4006d3 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -30,6 +30,7 @@ compatible: Optional properties: - dma-coherent : Present if dma operations are coherent - clocks : a list of phandle + clock specifier pairs +- resets : a list of phandle + reset specifier pairs - target-supply : regulator for SATA target power - phys : reference to the SATA PHY node - phy-names : must be "sata-phy" diff --git a/Documentation/devicetree/bindings/ata/imx-sata.txt b/Documentation/devicetree/bindings/ata/imx-sata.txt index a3d1471..781f887 100644 --- a/Documentation/devicetree/bindings/ata/imx-sata.txt +++ b/Documentation/devicetree/bindings/ata/imx-sata.txt @@ -7,6 +7,7 @@ Required properties: - compatible : should be one of the following: - "fsl,imx53-ahci" for i.MX53 SATA controller - "fsl,imx6q-ahci" for i.MX6Q SATA controller + - "fsl,imx6qp-ahci" for i.MX6QP SATA controller - interrupts : interrupt mapping for SATA IRQ - reg : registers mapping - clocks : list of clock specifiers, must contain an entry for each diff --git a/Documentation/devicetree/bindings/ata/nvidia,tegra124-ahci.txt b/Documentation/devicetree/bindings/ata/nvidia,tegra124-ahci.txt index 66c83c3..12ab2f7 100644 --- a/Documentation/devicetree/bindings/ata/nvidia,tegra124-ahci.txt +++ b/Documentation/devicetree/bindings/ata/nvidia,tegra124-ahci.txt @@ -1,9 +1,10 @@ -Tegra124 SoC SATA AHCI controller +Tegra SoC SATA AHCI controller Required properties : -- compatible : For Tegra124, must contain "nvidia,tegra124-ahci". Otherwise, - must contain '"nvidia,<chip>-ahci", "nvidia,tegra124-ahci"', where <chip> - is tegra132. +- compatible : Must be one of: + - Tegra124 : "nvidia,tegra124-ahci" + - Tegra132 : "nvidia,tegra132-ahci", "nvidia,tegra124-ahci" + - Tegra210 : "nvidia,tegra210-ahci" - reg : Should contain 2 entries: - AHCI register set (SATA BAR5) - SATA register set @@ -13,8 +14,6 @@ Required properties : - clock-names : Must include the following entries: - sata - sata-oob - - cml1 - - pll_e - resets : Must contain an entry for each entry in reset-names. See ../reset/reset.txt for details. - reset-names : Must include the following entries: @@ -24,9 +23,22 @@ Required properties : - phys : Must contain an entry for each entry in phy-names. See ../phy/phy-bindings.txt for details. - phy-names : Must include the following entries: - - sata-phy : XUSB PADCTL SATA PHY -- hvdd-supply : Defines the SATA HVDD regulator -- vddio-supply : Defines the SATA VDDIO regulator -- avdd-supply : Defines the SATA AVDD regulator -- target-5v-supply : Defines the SATA 5V power regulator -- target-12v-supply : Defines the SATA 12V power regulator + - For Tegra124 and Tegra132: + - sata-phy : XUSB PADCTL SATA PHY +- For Tegra124 and Tegra132: + - hvdd-supply : Defines the SATA HVDD regulator + - vddio-supply : Defines the SATA VDDIO regulator + - avdd-supply : Defines the SATA AVDD regulator + - target-5v-supply : Defines the SATA 5V power regulator + - target-12v-supply : Defines the SATA 12V power regulator + +Optional properties: +- reg : + - AUX register set +- clock-names : + - cml1 : + cml1 clock should be defined here if the PHY driver + doesn't manage them. If it does, they should not be. +- phy-names : + - For T210: + - sata-phy diff --git a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt new file mode 100644 index 0000000..22256e2 --- /dev/null +++ b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt @@ -0,0 +1,49 @@ +Samsung micro-USB 11-pin connector +================================== + +Samsung micro-USB 11-pin connector is an extension of micro-USB connector. +It is present in multiple Samsung mobile devices. +It has additional pins to route MHL traffic simultanously with USB. + +The bindings are superset of usb-connector bindings for micro-USB connector[1]. + +Required properties: +- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector", +- type: must be "micro". + +Required nodes: +- any data bus to the connector should be modeled using the OF graph bindings + specified in bindings/graph.txt, unless the bus is between parent node and + the connector. Since single connector can have multpile data buses every bus + has assigned OF graph port number as follows: + 0: High Speed (HS), + 3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB. + +[1]: bindings/connector/usb-connector.txt + +Example +------- + +Micro-USB connector with HS lines routed via controller (MUIC) and MHL lines +connected to HDMI-MHL bridge (sii8620): + +muic-max77843@66 { + ... + usb_con: connector { + compatible = "samsung,usb-connector-11pin", "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@3 { + reg = <3>; + usb_con_mhl: endpoint { + remote-endpoint = <&sii8620_mhl>; + }; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt new file mode 100644 index 0000000..e1463f1 --- /dev/null +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt @@ -0,0 +1,75 @@ +USB Connector +============= + +USB connector node represents physical USB connector. It should be +a child of USB interface controller. + +Required properties: +- compatible: describes type of the connector, must be one of: + "usb-a-connector", + "usb-b-connector", + "usb-c-connector". + +Optional properties: +- label: symbolic name for the connector, +- type: size of the connector, should be specified in case of USB-A, USB-B + non-fullsize connectors: "mini", "micro". + +Required nodes: +- any data bus to the connector should be modeled using the OF graph bindings + specified in bindings/graph.txt, unless the bus is between parent node and + the connector. Since single connector can have multpile data buses every bus + has assigned OF graph port number as follows: + 0: High Speed (HS), present in all connectors, + 1: Super Speed (SS), present in SS capable connectors, + 2: Sideband use (SBU), present in USB-C. + +Examples +-------- + +1. Micro-USB connector with HS lines routed via controller (MUIC): + +muic-max77843@66 { + ... + usb_con: connector { + compatible = "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + }; +}; + +2. USB-C connector attached to CC controller (s2mm005), HS lines routed +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort. +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY. + +ccic: s2mm005@33 { + ... + usb_con: connector { + compatible = "usb-c-connector"; + label = "USB-C"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + usb_con_hs: endpoint { + remote-endpoint = <&max77865_usbc_hs>; + }; + }; + port@1 { + reg = <1>; + usb_con_ss: endpoint { + remote-endpoint = <&usbdrd_phy_ss>; + }; + }; + port@2 { + reg = <2>; + usb_con_sbu: endpoint { + remote-endpoint = <&dp_aux>; + }; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt index dd3929e..332aed8 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt @@ -18,8 +18,6 @@ Optional properties: in unit of nanoseconds. - voltage-tolerance: Specify the CPU voltage tolerance in percentage. - #cooling-cells: -- cooling-min-level: -- cooling-max-level: Please refer to Documentation/devicetree/bindings/thermal/thermal.txt. Examples: @@ -40,8 +38,6 @@ cpus { >; clock-latency = <61036>; /* two CLK32 periods */ #cooling-cells = <2>; - cooling-min-level = <0>; - cooling-max-level = <2>; }; cpu@1 { diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt index f640308..d36f07e 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt @@ -21,8 +21,6 @@ Optional properties: flow is handled by hardware, hence no software "voltage tracking" is needed. - #cooling-cells: -- cooling-min-level: -- cooling-max-level: Please refer to Documentation/devicetree/bindings/thermal/thermal.txt for detail. @@ -67,8 +65,6 @@ Example 1 (MT7623 SoC): clock-names = "cpu", "intermediate"; operating-points-v2 = <&cpu_opp_table>; #cooling-cells = <2>; - cooling-min-level = <0>; - cooling-max-level = <7>; }; cpu@1 { device_type = "cpu"; diff --git a/Documentation/devicetree/bindings/cris/axis.txt b/Documentation/devicetree/bindings/cris/axis.txt deleted file mode 100644 index d209ca2..0000000 --- a/Documentation/devicetree/bindings/cris/axis.txt +++ /dev/null @@ -1,9 +0,0 @@ -Axis Communications AB -ARTPEC series SoC Device Tree Bindings - - -CRISv32 based SoCs are ETRAX FS and ARTPEC-3: - - - compatible = "axis,crisv32"; - - diff --git a/Documentation/devicetree/bindings/cris/boards.txt b/Documentation/devicetree/bindings/cris/boards.txt deleted file mode 100644 index 533dd27..0000000 --- a/Documentation/devicetree/bindings/cris/boards.txt +++ /dev/null @@ -1,8 +0,0 @@ -Boards based on the CRIS SoCs: - -Required root node properties: - - compatible = should be one or more of the following: - - "axis,dev88" - for Axis devboard 88 with ETRAX FS - -Optional: - diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt index cec8d5d..c2598ab 100644 --- a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt +++ b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt @@ -1,7 +1,8 @@ Arm TrustZone CryptoCell cryptographic engine Required properties: -- compatible: Should be "arm,cryptocell-712-ree". +- compatible: Should be one of: "arm,cryptocell-712-ree", + "arm,cryptocell-710-ree" or "arm,cryptocell-630p-ree". - reg: Base physical address of the engine and length of memory mapped region. - interrupts: Interrupt number for the device. diff --git a/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt index 30c3ce6..5dba55c 100644 --- a/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt +++ b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt @@ -8,7 +8,11 @@ Required properties: - interrupt-names: Should be "ring0", "ring1", "ring2", "ring3", "eip", "mem". Optional properties: -- clocks: Reference to the crypto engine clock. +- clocks: Reference to the crypto engine clocks, the second clock is + needed for the Armada 7K/8K SoCs. +- clock-names: mandatory if there is a second clock, in this case the + name must be "core" for the first clock and "reg" for + the second one. Example: diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt new file mode 100644 index 0000000..4f0ab3e --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@ -0,0 +1,58 @@ +Renesas R-Car LVDS Encoder +========================== + +These DT bindings describe the LVDS encoder embedded in the Renesas R-Car +Gen2, R-Car Gen3 and RZ/G SoCs. + +Required properties: + +- compatible : Shall contain one of + - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders + - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders + - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders + - "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders + - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders + - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders + - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders + - "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders + +- reg: Base address and length for the memory-mapped registers +- clocks: A phandle + clock-specifier pair for the functional clock +- resets: A phandle + reset specifier for the module reset + +Required nodes: + +The LVDS encoder has two video ports. Their connections are modelled using the +OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video port 0 corresponds to the parallel RGB input +- Video port 1 corresponds to the LVDS output + +Each port shall have a single endpoint. + + +Example: + + lvds0: lvds@feb90000 { + compatible = "renesas,r8a7790-lvds"; + reg = <0 0xfeb90000 0 0x1c>; + clocks = <&cpg CPG_MOD 726>; + resets = <&cpg 726>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + lvds0_in: endpoint { + remote-endpoint = <&du_out_lvds0>; + }; + }; + port@1 { + reg = <1>; + lvds0_out: endpoint { + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt index 6ec1a88..df3d7c1 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt @@ -1,11 +1,16 @@ -THS8135 Video DAC ------------------ +THS8134 and THS8135 Video DAC +----------------------------- -This is the binding for Texas Instruments THS8135 Video DAC bridge. +This is the binding for Texas Instruments THS8134, THS8134A, THS8134B and +THS8135 Video DAC bridges. Required properties: -- compatible: Must be "ti,ths8135" +- compatible: Must be one of + "ti,ths8134" + "ti,ths8134a," "ti,ths8134" + "ti,ths8134b", "ti,ths8134" + "ti,ths8135" Required nodes: diff --git a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt index fc53f7c..207e42e 100644 --- a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt +++ b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt @@ -10,6 +10,7 @@ Optional properties: - analog: the connector has DVI analog pins - digital: the connector has DVI digital pins - dual-link: the connector has pins for DVI dual-link +- hpd-gpios: HPD GPIO number Required nodes: - Video port for DVI input diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt index 05176f1..8def11b 100644 --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt @@ -1,23 +1,3 @@ -Etnaviv DRM master device -========================= - -The Etnaviv DRM master device is a virtual device needed to list all -Vivante GPU cores that comprise the GPU subsystem. - -Required properties: -- compatible: Should be one of - "fsl,imx-gpu-subsystem" - "marvell,dove-gpu-subsystem" -- cores: Should contain a list of phandles pointing to Vivante GPU devices - -example: - -gpu-subsystem { - compatible = "fsl,imx-gpu-subsystem"; - cores = <&gpu_2d>, <&gpu_3d>; -}; - - Vivante GPU core devices ======================== @@ -32,7 +12,9 @@ Required properties: - clocks: should contain one clock for entry in clock-names see Documentation/devicetree/bindings/clock/clock-bindings.txt - clock-names: - - "bus": AXI/register clock + - "bus": AXI/master interface clock + - "reg": AHB/slave interface clock + (only required if GPU can gate slave interface independently) - "core": GPU core clock - "shader": Shader clock (only required if GPU has feature PIPE_3D) diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt index 6394ea9e..58b12e2 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt @@ -16,6 +16,7 @@ Required properties: - ddc: phandle to the hdmi ddc node - phy: phandle to the hdmi phy node - samsung,syscon-phandle: phandle for system controller node for PMU. +- #sound-dai-cells: should be 0. Required properties for Exynos 4210, 4212, 5420 and 5433: - clocks: list of clock IDs from SoC clock driver. diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index a6671bd..518e9cd 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -7,8 +7,6 @@ Required properties: - reg: Physical base address and length of the registers of controller - reg-names: The names of register regions. The following regions are required: * "dsi_ctrl" -- qcom,dsi-host-index: The ID of DSI controller hardware instance. This should - be 0 or 1, since we have 2 DSI controllers at most for now. - interrupts: The interrupt signal from the DSI block. - power-domains: Should be <&mmcc MDSS_GDSC>. - clocks: Phandles to device clocks. @@ -22,6 +20,8 @@ Required properties: * "core" For DSIv2, we need an additional clock: * "src" + For DSI6G v2.0 onwards, we need also need the clock: + * "byte_intf" - assigned-clocks: Parents of "byte" and "pixel" for the given platform. - assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block. See [1] for details on clock bindings. @@ -88,21 +88,35 @@ Required properties: * "qcom,dsi-phy-28nm-lp" * "qcom,dsi-phy-20nm" * "qcom,dsi-phy-28nm-8960" -- reg: Physical base address and length of the registers of PLL, PHY and PHY - regulator + * "qcom,dsi-phy-14nm" + * "qcom,dsi-phy-10nm" +- reg: Physical base address and length of the registers of PLL, PHY. Some + revisions require the PHY regulator base address, whereas others require the + PHY lane base address. See below for each PHY revision. - reg-names: The names of register regions. The following regions are required: + For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY: * "dsi_pll" * "dsi_phy" * "dsi_phy_regulator" + For DSI 14nm and 10nm PHYs: + * "dsi_pll" + * "dsi_phy" + * "dsi_phy_lane" - clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating 2 clocks: A byte clock (index 0), and a pixel clock (index 1). -- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should - be 0 or 1, since we have 2 DSI PHYs at most for now. - power-domains: Should be <&mmcc MDSS_GDSC>. - clocks: Phandles to device clocks. See [1] for details on clock bindings. - clock-names: the following clocks are required: * "iface" + For 28nm HPM/LP, 28nm 8960 PHYs: +- vddio-supply: phandle to vdd-io regulator device node + For 20nm PHY: - vddio-supply: phandle to vdd-io regulator device node +- vcca-supply: phandle to vcca regulator device node + For 14nm PHY: +- vcca-supply: phandle to vcca regulator device node + For 10nm PHY: +- vdds-supply: phandle to vdds regulator device node Optional properties: - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY diff --git a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt new file mode 100644 index 0000000..248141c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt @@ -0,0 +1,31 @@ +ARM Versatile TFT Panels + +These panels are connected to the daughterboards found on the +ARM Versatile reference designs. + +This device node must appear as a child to a "syscon"-compatible +node. + +Required properties: +- compatible: should be "arm,versatile-tft-panel" + +Required subnodes: +- port: see display/panel/panel-common.txt, graph.txt + + +Example: + +sysreg@0 { + compatible = "arm,versatile-sysreg", "syscon", "simple-mfd"; + reg = <0x00000 0x1000>; + + panel: display@0 { + compatible = "arm,versatile-tft-panel"; + + port { + panel_in: endpoint { + remote-endpoint = <&foo>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt b/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt new file mode 100644 index 0000000..85626ed --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt @@ -0,0 +1,12 @@ +AU Optronics Corporation 10.4" (800x600) color TFT LCD panel + +Required properties: +- compatible: should be "auo,g104sn02" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/display-timing.txt b/Documentation/devicetree/bindings/display/panel/display-timing.txt index 58fa3e4..78222ce 100644 --- a/Documentation/devicetree/bindings/display/panel/display-timing.txt +++ b/Documentation/devicetree/bindings/display/panel/display-timing.txt @@ -80,6 +80,11 @@ The parameters are defined as: | | v | | | +----------+-------------------------------------+----------+-------+ +Note: In addition to being used as subnode(s) of display-timings, the timing + subnode may also be used on its own. This is appropriate if only one mode + need be conveyed. In this case, the node should be named 'panel-timing'. + + Example: display-timings { diff --git a/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt new file mode 100644 index 0000000..6a036ed --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt @@ -0,0 +1,25 @@ +Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. + +Required properties: +- compatible: should be "koe,tx31d200vm0baa" + +Optional properties: +- backlight: phandle of the backlight device attached to the panel + +Optional nodes: +- Video port for LVDS panel input. + +Example: + panel { + compatible = "koe,tx31d200vm0baa"; + backlight = <&backlight_lvds>; + + port { + panel_in: endpoint { + remote-endpoint = <&lvds0_out>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt index 6862028..203b03e 100644 --- a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt +++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt @@ -9,6 +9,7 @@ Required properties: Optional properties: - reset-gpios: a GPIO spec for the reset pin (active low). + - power-supply: phandle of the regulator that provides the supply voltage. Example: &dsi { @@ -17,5 +18,6 @@ Example: compatible = "orisetech,otm8009a"; reg = <0>; reset-gpios = <&gpioh 7 GPIO_ACTIVE_LOW>; + power-supply = <&v1v8>; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt new file mode 100644 index 0000000..cbb79ef --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt @@ -0,0 +1,25 @@ +Raydium Semiconductor Corporation RM68200 5.5" 720p MIPI-DSI TFT LCD panel + +The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD +panel connected using a MIPI-DSI video interface. + +Required properties: + - compatible: "raydium,rm68200" + - reg: the virtual channel number of a DSI peripheral + +Optional properties: + - reset-gpios: a GPIO spec for the reset pin (active low). + - power-supply: phandle of the regulator that provides the supply voltage. + - backlight: phandle of the backlight device attached to the panel. + +Example: +&dsi { + ... + panel@0 { + compatible = "raydium,rm68200"; + reg = <0>; + reset-gpios = <&gpiof 15 GPIO_ACTIVE_LOW>; + power-supply = <&v1v8>; + backlight = <&pwm_backlight>; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt index 16d8ff0..45a457a 100644 --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt @@ -1,4 +1,8 @@ Simple display panel +==================== + +panel node +---------- Required properties: - power-supply: See panel-common.txt diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt index cd48aba..c9cd17f 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ b/Documentation/devicetree/bindings/display/renesas,du.txt @@ -13,13 +13,10 @@ Required Properties: - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU + - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU + - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU - - reg: A list of base address and length of each memory resource, one for - each entry in the reg-names property. - - reg-names: Name of the memory resources. The DU requires one memory - resource for the DU core (named "du") and one memory resource for each - LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical - index). + - reg: the memory-mapped I/O registers base address and length - interrupt-parent: phandle of the parent interrupt controller. - interrupts: Interrupt specifiers for the DU interrupts. @@ -29,14 +26,13 @@ Required Properties: - clock-names: Name of the clocks. This property is model-dependent. - R8A7779 uses a single functional clock. The clock doesn't need to be named. - - All other DU instances use one functional clock per channel and one - clock per LVDS encoder (if available). The functional clocks must be - named "du.x" with "x" being the channel numerical index. The LVDS clocks - must be named "lvds.x" with "x" being the LVDS encoder numerical index. - - In addition to the functional and encoder clocks, all DU versions also - support externally supplied pixel clocks. Those clocks are optional. - When supplied they must be named "dclkin.x" with "x" being the input - clock numerical index. + - All other DU instances use one functional clock per channel The + functional clocks must be named "du.x" with "x" being the channel + numerical index. + - In addition to the functional clocks, all DU versions also support + externally supplied pixel clocks. Those clocks are optional. When + supplied they must be named "dclkin.x" with "x" being the input clock + numerical index. - vsps: A list of phandle and channel index tuples to the VSPs that handle the memory interfaces for the DU channels. The phandle identifies the VSP @@ -63,15 +59,15 @@ corresponding to each DU output. R8A7794 (R-Car E2) DPAD 0 DPAD 1 - - R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0 R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 - + R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - - + R8A77995 (R-Car D3) DPAD 0 LVDS 0 LVDS 1 - Example: R8A7795 (R-Car H3) ES2.0 DU du: display@feb00000 { compatible = "renesas,du-r8a7795"; - reg = <0 0xfeb00000 0 0x80000>, - <0 0xfeb90000 0 0x14>; - reg-names = "du", "lvds.0"; + reg = <0 0xfeb00000 0 0x80000>; interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>, @@ -79,9 +75,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>, <&cpg CPG_MOD 722>, - <&cpg CPG_MOD 721>, - <&cpg CPG_MOD 727>; - clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0"; + <&cpg CPG_MOD 721>; + clock-names = "du.0", "du.1", "du.2", "du.3"; vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>; ports { diff --git a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt new file mode 100644 index 0000000..8df7d2e --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt @@ -0,0 +1,74 @@ +Rockchip RK3399 specific extensions to the cdn Display Port +================================ + +Required properties: +- compatible: must be "rockchip,rk3399-cdn-dp" + +- reg: physical base address of the controller and length + +- clocks: from common clock binding: handle to dp clock. + +- clock-names: from common clock binding: + Required elements: "core-clk" "pclk" "spdif" "grf" + +- resets : a list of phandle + reset specifier pairs +- reset-names : string of reset names + Required elements: "apb", "core", "dptx", "spdif" +- power-domains : power-domain property defined with a phandle + to respective power domain. +- assigned-clocks: main clock, should be <&cru SCLK_DP_CORE> +- assigned-clock-rates : the DP core clk frequency, shall be: 100000000 + +- rockchip,grf: this soc should set GRF regs, so need get grf here. + +- ports: contain a port nodes with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + contained 2 endpoints, connecting to the output of vop. + +- phys: from general PHY binding: the phandle for the PHY device. + +- extcon: extcon specifier for the Power Delivery + +- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF + +------------------------------------------------------------------------------- + +Example: + cdn_dp: dp@fec00000 { + compatible = "rockchip,rk3399-cdn-dp"; + reg = <0x0 0xfec00000 0x0 0x100000>; + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_DP_CORE>, <&cru PCLK_DP_CTRL>, + <&cru SCLK_SPDIF_REC_DPTX>, <&cru PCLK_VIO_GRF>; + clock-names = "core-clk", "pclk", "spdif", "grf"; + assigned-clocks = <&cru SCLK_DP_CORE>; + assigned-clock-rates = <100000000>; + power-domains = <&power RK3399_PD_HDCP>; + phys = <&tcphy0_dp>, <&tcphy1_dp>; + resets = <&cru SRST_DPTX_SPDIF_REC>; + reset-names = "spdif"; + extcon = <&fusb0>, <&fusb1>; + rockchip,grf = <&grf>; + #address-cells = <1>; + #size-cells = <0>; + #sound-dai-cells = <1>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + dp_in: port { + #address-cells = <1>; + #size-cells = <0>; + dp_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_dp>; + }; + + dp_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_dp>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt index 0292522..3eb1b48 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt @@ -98,7 +98,7 @@ Example 2: DSI panel compatible = "st,stm32-dsi"; reg = <0x40016c00 0x800>; clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>; - clock-names = "ref", "pclk"; + clock-names = "pclk", "ref"; resets = <&rcc STM32F4_APB2_RESET(DSI)>; reset-names = "apb"; diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index cd626ee..3346c1e 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -64,6 +64,56 @@ Required properties: first port should be the input endpoint. The second should be the output, usually to an HDMI connector. +DWC HDMI TX Encoder +------------------- + +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the +following device-specific properties. + +Required properties: + + - compatible: value must be one of: + * "allwinner,sun8i-a83t-dw-hdmi" + - reg: base address and size of memory-mapped region + - reg-io-width: See dw_hdmi.txt. Shall be 1. + - interrupts: HDMI interrupt number + - clocks: phandles to the clocks feeding the HDMI encoder + * iahb: the HDMI bus clock + * isfr: the HDMI register clock + * tmds: TMDS clock + - clock-names: the clock names mentioned above + - resets: phandle to the reset controller + - reset-names: must be "ctrl" + - phys: phandle to the DWC HDMI PHY + - phy-names: must be "phy" + + - ports: A ports node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. The + first port should be the input endpoint. The second should be the + output, usually to an HDMI connector. + +DWC HDMI PHY +------------ + +Required properties: + - compatible: value must be one of: + * allwinner,sun8i-a83t-hdmi-phy + * allwinner,sun8i-h3-hdmi-phy + - reg: base address and size of memory-mapped region + - clocks: phandles to the clocks feeding the HDMI PHY + * bus: the HDMI PHY interface clock + * mod: the HDMI PHY module clock + - clock-names: the clock names mentioned above + - resets: phandle to the reset controller driving the PHY + - reset-names: must be "phy" + +H3 HDMI PHY requires additional clock: + - pll-0: parent of phy clock + TV Encoder ---------- @@ -94,24 +144,29 @@ Required properties: * allwinner,sun7i-a20-tcon * allwinner,sun8i-a33-tcon * allwinner,sun8i-a83t-tcon-lcd + * allwinner,sun8i-a83t-tcon-tv * allwinner,sun8i-v3s-tcon + * allwinner,sun9i-a80-tcon-lcd + * allwinner,sun9i-a80-tcon-tv - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - - clocks: phandles to the clocks feeding the TCON. Three are needed: + - clocks: phandles to the clocks feeding the TCON. - 'ahb': the interface clocks - - 'tcon-ch0': The clock driving the TCON channel 0 + - 'tcon-ch0': The clock driving the TCON channel 0, if supported - resets: phandles to the reset controllers driving the encoder - - "lcd": the reset line for the TCON channel 0 + - "lcd": the reset line for the TCON + - "edp": the reset line for the eDP block (A80 only) - clock-names: the clock names mentioned above - reset-names: the reset names mentioned above - - clock-output-names: Name of the pixel clock created + - clock-output-names: Name of the pixel clock created, if TCON supports + channel 0. - ports: A ports node with endpoint definitions as defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The first port should be the input endpoint, the second one the output - The output may have multiple endpoints. The TCON has two channels, + The output may have multiple endpoints. TCON can have 1 or 2 channels, usually with the first channel being used for the panels interfaces (RGB, LVDS, etc.), and the second being used for the outputs that require another controller (TV Encoder, HDMI, etc.). The endpoints @@ -119,11 +174,13 @@ Required properties: channel the endpoint is associated to. If that property is not present, the endpoint number will be used as the channel number. -On SoCs other than the A33 and V3s, there is one more clock required: +For TCONs with channel 0, there is one more clock required: + - 'tcon-ch0': The clock driving the TCON channel 0 +For TCONs with channel 1, there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 -On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you -need one more reset line: +When TCON support LVDS (all TCONs except TV TCON on A83T and those found +in A13, H3, H5 and V3s SoCs), you need one more reset line: - 'lvds': The reset line driving the LVDS logic And on the A23, A31, A31s and A33, you need one more clock line: @@ -134,7 +191,7 @@ DRC --- The DRC (Dynamic Range Controller), found in the latest Allwinner SoCs -(A31, A23, A33), allows to dynamically adjust pixel +(A31, A23, A33, A80), allows to dynamically adjust pixel brightness/contrast based on histogram measurements for LCD content adaptive backlight control. @@ -144,6 +201,7 @@ Required properties: * allwinner,sun6i-a31-drc * allwinner,sun6i-a31s-drc * allwinner,sun8i-a33-drc + * allwinner,sun9i-a80-drc - reg: base address and size of the memory-mapped region. - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the DRC @@ -170,6 +228,7 @@ Required properties: * allwinner,sun6i-a31-display-backend * allwinner,sun7i-a20-display-backend * allwinner,sun8i-a33-display-backend + * allwinner,sun9i-a80-display-backend - reg: base address and size of the memory-mapped region. - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the frontend and backend @@ -191,6 +250,28 @@ On the A33, some additional properties are required: - resets and reset-names need to have a phandle to the SAT bus resets, whose name will be "sat" +DEU +--- + +The DEU (Detail Enhancement Unit), found in the Allwinner A80 SoC, +can sharpen the display content in both luma and chroma channels. + +Required properties: + - compatible: value must be one of: + * allwinner,sun9i-a80-deu + - reg: base address and size of the memory-mapped region. + - interrupts: interrupt associated to this IP + - clocks: phandles to the clocks feeding the DEU + * ahb: the DEU interface clock + * mod: the DEU module clock + * ram: the DEU DRAM clock + - clock-names: the clock names mentioned above + - resets: phandles to the reset line driving the DEU + +- ports: A ports node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. The + first port should be the input endpoints, the second one the outputs + Display Engine Frontend ----------------------- @@ -204,6 +285,7 @@ Required properties: * allwinner,sun6i-a31-display-frontend * allwinner,sun7i-a20-display-frontend * allwinner,sun8i-a33-display-frontend + * allwinner,sun9i-a80-display-frontend - reg: base address and size of the memory-mapped region. - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the frontend and backend @@ -226,6 +308,8 @@ supported. Required properties: - compatible: value must be one of: * allwinner,sun8i-a83t-de2-mixer-0 + * allwinner,sun8i-a83t-de2-mixer-1 + * allwinner,sun8i-h3-de2-mixer-0 * allwinner,sun8i-v3s-de2-mixer - reg: base address and size of the memory-mapped region. - clocks: phandles to the clocks feeding the mixer @@ -256,7 +340,9 @@ Required properties: * allwinner,sun7i-a20-display-engine * allwinner,sun8i-a33-display-engine * allwinner,sun8i-a83t-display-engine + * allwinner,sun8i-h3-display-engine * allwinner,sun8i-v3s-display-engine + * allwinner,sun9i-a80-display-engine - allwinner,pipelines: list of phandle to the display engine frontends (DE 1.0) or mixers (DE 2.0) available. diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt new file mode 100644 index 0000000..ab516c6 --- /dev/null +++ b/Documentation/devicetree/bindings/fsi/fsi.txt @@ -0,0 +1,151 @@ +FSI bus & engine generic device tree bindings +============================================= + +The FSI bus is probe-able, so the OS is able to enumerate FSI slaves, and +engines within those slaves. However, we have a facility to match devicetree +nodes to probed engines. This allows for fsi engines to expose non-probeable +busses, which are then exposed by the device tree. For example, an FSI engine +that is an I2C master - the I2C bus can be described by the device tree under +the engine's device tree node. + +FSI masters may require their own DT nodes (to describe the master HW itself); +that requirement is defined by the master's implementation, and is described by +the fsi-master-* binding specifications. + +Under the masters' nodes, we can describe the bus topology using nodes to +represent the FSI slaves and their slave engines. As a basic outline: + + fsi-master { + /* top-level of FSI bus topology, bound to an FSI master driver and + * exposes an FSI bus */ + + fsi-slave@<link,id> { + /* this node defines the FSI slave device, and is handled + * entirely with FSI core code */ + + fsi-slave-engine@<addr> { + /* this node defines the engine endpoint & address range, which + * is bound to the relevant fsi device driver */ + ... + }; + + fsi-slave-engine@<addr> { + ... + }; + + }; + }; + +Note that since the bus is probe-able, some (or all) of the topology may +not be described; this binding only provides an optional facility for +adding subordinate device tree nodes as children of FSI engines. + +FSI masters +----------- + +FSI master nodes declare themselves as such with the "fsi-master" compatible +value. It's likely that an implementation-specific compatible value will +be needed as well, for example: + + compatible = "fsi-master-gpio", "fsi-master"; + +Since the master nodes describe the top-level of the FSI topology, they also +need to declare the FSI-standard addressing scheme. This requires two cells for +addresses (link index and slave ID), and no size: + + #address-cells = <2>; + #size-cells = <0>; + +An optional boolean property can be added to indicate that a particular master +should not scan for connected devices at initialization time. This is +necessary in cases where a scan could cause arbitration issues with other +masters that may be present on the bus. + + no-scan-on-init; + +FSI slaves +---------- + +Slaves are identified by a (link-index, slave-id) pair, so require two cells +for an address identifier. Since these are not a range, no size cells are +required. For an example, a slave on link 1, with ID 2, could be represented +as: + + cfam@1,2 { + reg = <1 2>; + [...]; + } + +Each slave provides an address-space, under which the engines are accessible. +That address space has a maximum of 23 bits, so we use one cell to represent +addresses and sizes in the slave address space: + + #address-cells = <1>; + #size-cells = <1>; + + +FSI engines (devices) +--------------------- + +Engines are identified by their address under the slaves' address spaces. We +use a single cell for address and size. Engine nodes represent the endpoint +FSI device, and are passed to those FSI device drivers' ->probe() functions. + +For example, for a slave using a single 0x400-byte page starting at address +0xc00: + + engine@c00 { + reg = <0xc00 0x400>; + }; + + +Full example +------------ + +Here's an example that illustrates: + - an FSI master + - connected to an FSI slave + - that contains an engine that is an I2C master + - connected to an I2C EEPROM + +The FSI master may be connected to additional slaves, and slaves may have +additional engines, but they don't necessarily need to be describe in the +device tree if no extra platform information is required. + + /* The GPIO-based FSI master node, describing the top level of the + * FSI bus + */ + gpio-fsi { + compatible = "fsi-master-gpio", "fsi-master"; + #address-cells = <2>; + #size-cells = <0>; + + /* A FSI slave (aka. CFAM) at link 0, ID 0. */ + cfam@0,0 { + reg = <0 0>; + #address-cells = <1>; + #size-cells = <1>; + + /* FSI engine at 0xc00, using a single page. In this example, + * it's an I2C master controller, so subnodes describe the + * I2C bus. + */ + i2c-controller@c00 { + reg = <0xc00 0x400>; + + /* Engine-specific data. In this case, we're describing an + * I2C bus, so we're conforming to the generic I2C binding + */ + compatible = "some-vendor,fsi-i2c-controller"; + #address-cells = <1>; + #size-cells = <1>; + + /* I2C endpoint device: an Atmel EEPROM */ + eeprom@50 { + compatible = "atmel,24c256"; + reg = <0x50>; + pagesize = <64>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt b/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt new file mode 100644 index 0000000..93d98d0 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt @@ -0,0 +1,97 @@ +Spreadtrum EIC controller bindings + +The EIC is the abbreviation of external interrupt controller, which can +be used only in input mode. The Spreadtrum platform has 2 EIC controllers, +one is in digital chip, and another one is in PMIC. The digital chip EIC +controller contains 4 sub-modules: EIC-debounce, EIC-latch, EIC-async and +EIC-sync. But the PMIC EIC controller contains only one EIC-debounce sub- +module. + +The EIC-debounce sub-module provides up to 8 source input signal +connections. A debounce mechanism is used to capture the input signals' +stable status (millisecond resolution) and a single-trigger mechanism +is introduced into this sub-module to enhance the input event detection +reliability. In addition, this sub-module's clock can be shut off +automatically to reduce power dissipation. Moreover the debounce range +is from 1ms to 4s with a step size of 1ms. The input signal will be +ignored if it is asserted for less than 1 ms. + +The EIC-latch sub-module is used to latch some special power down signals +and generate interrupts, since the EIC-latch does not depend on the APB +clock to capture signals. + +The EIC-async sub-module uses a 32kHz clock to capture the short signals +(microsecond resolution) to generate interrupts by level or edge trigger. + +The EIC-sync is similar with GPIO's input function, which is a synchronized +signal input register. It can generate interrupts by level or edge trigger +when detecting input signals. + +Required properties: +- compatible: Should be one of the following: + "sprd,sc9860-eic-debounce", + "sprd,sc9860-eic-latch", + "sprd,sc9860-eic-async", + "sprd,sc9860-eic-sync", + "sprd,sc27xx-eic". +- reg: Define the base and range of the I/O address space containing + the GPIO controller registers. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells: Should be <2>. The first cell is the gpio number and + the second cell is used to specify optional parameters. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be <2>. Specifies the number of cells needed + to encode interrupt source. +- interrupts: Should be the port interrupt shared by all the gpios. + +Example: + eic_debounce: gpio@40210000 { + compatible = "sprd,sc9860-eic-debounce"; + reg = <0 0x40210000 0 0x80>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>; + }; + + eic_latch: gpio@40210080 { + compatible = "sprd,sc9860-eic-latch"; + reg = <0 0x40210080 0 0x20>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>; + }; + + eic_async: gpio@402100a0 { + compatible = "sprd,sc9860-eic-async"; + reg = <0 0x402100a0 0 0x20>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>; + }; + + eic_sync: gpio@402100c0 { + compatible = "sprd,sc9860-eic-sync"; + reg = <0 0x402100c0 0 0x20>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>; + }; + + pmic_eic: gpio@300 { + compatible = "sprd,sc27xx-eic"; + reg = <0x300>; + interrupt-parent = <&sc2731_pmic>; + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-etraxfs.txt b/Documentation/devicetree/bindings/gpio/gpio-etraxfs.txt deleted file mode 100644 index 170194a..0000000 --- a/Documentation/devicetree/bindings/gpio/gpio-etraxfs.txt +++ /dev/null @@ -1,22 +0,0 @@ -Axis ETRAX FS General I/O controller bindings - -Required properties: - -- compatible: one of: - - "axis,etraxfs-gio" - - "axis,artpec3-gio" -- reg: Physical base address and length of the controller's registers. -- #gpio-cells: Should be 3 - - The first cell is the gpio offset number. - - The second cell is reserved and is currently unused. - - The third cell is the port number (hex). -- gpio-controller: Marks the device node as a GPIO controller. - -Example: - - gio: gpio@b001a000 { - compatible = "axis,etraxfs-gio"; - reg = <0xb001a000 0x1000>; - gpio-controller; - #gpio-cells = <3>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt index 0d01587..d2a9376 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt @@ -16,6 +16,8 @@ Required properties: nxp,pca9574 nxp,pca9575 nxp,pca9698 + nxp,pcal6524 + nxp,pcal9555a maxim,max7310 maxim,max7312 maxim,max7313 diff --git a/Documentation/devicetree/bindings/gpio/gpio-sprd.txt b/Documentation/devicetree/bindings/gpio/gpio-sprd.txt new file mode 100644 index 0000000..eca97d4 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-sprd.txt @@ -0,0 +1,28 @@ +Spreadtrum GPIO controller bindings + +The controller's registers are organized as sets of sixteen 16-bit +registers with each set controlling a bank of up to 16 pins. A single +interrupt is shared for all of the banks handled by the controller. + +Required properties: +- compatible: Should be "sprd,sc9860-gpio". +- reg: Define the base and range of the I/O address space containing +the GPIO controller registers. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells: Should be <2>. The first cell is the gpio number and +the second cell is used to specify optional parameters. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be <2>. Specifies the number of cells needed +to encode interrupt source. +- interrupts: Should be the port interrupt shared by all the gpios. + +Example: + ap_gpio: gpio@40280000 { + compatible = "sprd,sc9860-gpio"; + reg = <0 0x40280000 0 0x1000>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt b/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt deleted file mode 100644 index 528f5ef..0000000 --- a/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt +++ /dev/null @@ -1,45 +0,0 @@ -ImgTec TZ1090 PDC GPIO Controller - -Required properties: -- compatible: Compatible property value should be "img,tz1090-pdc-gpio". - -- reg: Physical base address of the controller and length of memory mapped - region. This starts at and cover the SOC_GPIO_CONTROL registers. - -- gpio-controller: Specifies that the node is a gpio controller. - -- #gpio-cells: Should be 2. The syntax of the gpio specifier used by client - nodes should have the following values. - <[phandle of the gpio controller node] - [PDC gpio number] - [gpio flags]> - - Values for gpio specifier: - - GPIO number: a value in the range 0 to 6. - - GPIO flags: bit field of flags, as defined in <dt-bindings/gpio/gpio.h>. - Only the following flags are supported: - GPIO_ACTIVE_HIGH - GPIO_ACTIVE_LOW - -Optional properties: -- gpio-ranges: Mapping to pin controller pins (as described in - Documentation/devicetree/bindings/gpio/gpio.txt) - -- interrupts: Individual syswake interrupts (other GPIOs cannot interrupt) - - -Example: - - pdc_gpios: gpio-controller@2006500 { - gpio-controller; - #gpio-cells = <2>; - - compatible = "img,tz1090-pdc-gpio"; - reg = <0x02006500 0x100>; - - interrupt-parent = <&pdc>; - interrupts = <8 IRQ_TYPE_NONE>, /* Syswake 0 */ - <9 IRQ_TYPE_NONE>, /* Syswake 1 */ - <10 IRQ_TYPE_NONE>; /* Syswake 2 */ - gpio-ranges = <&pdc_pinctrl 0 0 7>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt deleted file mode 100644 index b05a90e..0000000 --- a/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt +++ /dev/null @@ -1,88 +0,0 @@ -ImgTec TZ1090 GPIO Controller - -Required properties: -- compatible: Compatible property value should be "img,tz1090-gpio". - -- reg: Physical base address of the controller and length of memory mapped - region. - -- #address-cells: Should be 1 (for bank subnodes) - -- #size-cells: Should be 0 (for bank subnodes) - -- Each bank of GPIOs should have a subnode to represent it. - - Bank subnode required properties: - - reg: Index of bank in the range 0 to 2. - - - gpio-controller: Specifies that the node is a gpio controller. - - - #gpio-cells: Should be 2. The syntax of the gpio specifier used by client - nodes should have the following values. - <[phandle of the gpio controller node] - [gpio number within the gpio bank] - [gpio flags]> - - Values for gpio specifier: - - GPIO number: a value in the range 0 to 29. - - GPIO flags: bit field of flags, as defined in <dt-bindings/gpio/gpio.h>. - Only the following flags are supported: - GPIO_ACTIVE_HIGH - GPIO_ACTIVE_LOW - - Bank subnode optional properties: - - gpio-ranges: Mapping to pin controller pins (as described in - Documentation/devicetree/bindings/gpio/gpio.txt) - - - interrupts: Interrupt for the entire bank - - - interrupt-controller: Specifies that the node is an interrupt controller - - - #interrupt-cells: Should be 2. The syntax of the interrupt specifier used by - client nodes should have the following values. - <[phandle of the interurupt controller] - [gpio number within the gpio bank] - [irq flags]> - - Values for irq specifier: - - GPIO number: a value in the range 0 to 29 - - IRQ flags: value to describe edge and level triggering, as defined in - <dt-bindings/interrupt-controller/irq.h>. Only the following flags are - supported: - IRQ_TYPE_EDGE_RISING - IRQ_TYPE_EDGE_FALLING - IRQ_TYPE_EDGE_BOTH - IRQ_TYPE_LEVEL_HIGH - IRQ_TYPE_LEVEL_LOW - - - -Example: - - gpios: gpio-controller@2005800 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "img,tz1090-gpio"; - reg = <0x02005800 0x90>; - - /* bank 0 with an interrupt */ - gpios0: bank@0 { - #gpio-cells = <2>; - #interrupt-cells = <2>; - reg = <0>; - interrupts = <13 IRQ_TYPE_LEVEL_HIGH>; - gpio-controller; - gpio-ranges = <&pinctrl 0 0 30>; - interrupt-controller; - }; - - /* bank 2 without interrupt */ - gpios2: bank@2 { - #gpio-cells = <2>; - reg = <2>; - gpio-controller; - gpio-ranges = <&pinctrl 0 60 30>; - }; - }; - - diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index b5de08e..a7c31de 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -151,9 +151,9 @@ in a lot of designs, some using all 32 bits, some using 18 and some using first 18 GPIOs, at local offset 0 .. 17, are in use. If these GPIOs do not happen to be the first N GPIOs at offset 0...N-1, an -additional bitmask is needed to specify which GPIOs are actually in use, -and which are dummies. The bindings for this case has not yet been -specified, but should be specified if/when such hardware appears. +additional set of tuples is needed to specify which GPIOs are unusable, with +the gpio-reserved-ranges binding. This property indicates the start and size +of the GPIOs that can't be used. Optionally, a GPIO controller may have a "gpio-line-names" property. This is an array of strings defining the names of the GPIO lines going out of the @@ -178,6 +178,7 @@ gpio-controller@00000000 { gpio-controller; #gpio-cells = <2>; ngpios = <18>; + gpio-reserved-ranges = <0 4>, <12 2>; gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R", "LED G", "LED B", "Col A", "Col B", "Col C", "Col D", "Row A", "Row B", "Row C", "Row D", "NMI button", diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt new file mode 100644 index 0000000..20fc72d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt @@ -0,0 +1,27 @@ +Nintendo Wii (Hollywood) GPIO controller + +Required properties: +- compatible: "nintendo,hollywood-gpio +- reg: Physical base address and length of the controller's registers. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells: Should be <2>. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted). + +Optional properties: +- ngpios: see Documentation/devicetree/bindings/gpio/gpio.txt +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be two. +- interrupts: Interrupt specifier for the controller's Broadway (PowerPC) + interrupt. +- interrupt-parent: phandle of the parent interrupt controller. + +Example: + + GPIO: gpio@d8000c0 { + #gpio-cells = <2>; + compatible = "nintendo,hollywood-gpio"; + reg = <0x0d8000c0 0x40>; + gpio-controller; + ngpios = <24>; + } diff --git a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt b/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt new file mode 100644 index 0000000..ce97265 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt @@ -0,0 +1,30 @@ +Raspberry Pi GPIO expander + +The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The +firmware exposes a mailbox interface that allows the ARM core to control the +GPIO lines on the expander. + +The Raspberry Pi GPIO expander node must be a child node of the Raspberry Pi +firmware node. + +Required properties: + +- compatible : Should be "raspberrypi,firmware-gpio" +- gpio-controller : Marks the device node as a gpio controller +- #gpio-cells : Should be two. The first cell is the pin number, and + the second cell is used to specify the gpio polarity: + 0 = active high + 1 = active low + +Example: + +firmware: firmware-rpi { + compatible = "raspberrypi,bcm2835-firmware"; + mboxes = <&mailbox>; + + expgpio: gpio { + compatible = "raspberrypi,firmware-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; +}; diff --git a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt new file mode 100644 index 0000000..7a63139 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt @@ -0,0 +1,48 @@ +* X-Powers AXP ADC bindings + +Required properties: + - compatible: should be one of: + - "x-powers,axp209-adc", + - "x-powers,axp221-adc", + - "x-powers,axp813-adc", + - #io-channel-cells: should be 1, + +Example: + +&axp22x { + adc { + compatible = "x-powers,axp221-adc"; + #io-channel-cells = <1>; + }; +}; + +ADC channels and their indexes per variant: + +AXP209 +------ + 0 | acin_v + 1 | acin_i + 2 | vbus_v + 3 | vbus_i + 4 | pmic_temp + 5 | gpio0_v + 6 | gpio1_v + 7 | ipsout_v + 8 | batt_v + 9 | batt_chrg_i +10 | batt_dischrg_i + +AXP22x +------ + 0 | pmic_temp + 1 | batt_v + 2 | batt_chrg_i + 3 | batt_dischrg_i + +AXP813 +------ + 0 | pmic_temp + 1 | gpio0_v + 2 | batt_v + 3 | batt_chrg_i + 4 | batt_dischrg_i diff --git a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt index e9ebb8a..ba24ca7 100644 --- a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt +++ b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt @@ -3,11 +3,11 @@ Device-Tree bindings for sigma delta modulator Required properties: - compatible: should be "ads1201", "sd-modulator". "sd-modulator" can be use as a generic SD modulator if modulator not specified in compatible list. -- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers". +- #io-channel-cells = <0>: See the IIO bindings section "IIO consumers". Example node: ads1202: adc@0 { compatible = "sd-modulator"; - #io-channel-cells = <1>; + #io-channel-cells = <0>; }; diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt index 911492da..ed7520d 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt @@ -32,6 +32,10 @@ Optional properties: to "clock" property. Frequency must be a multiple of the rcc clock frequency. If not, SPI CLKOUT frequency will not be accurate. +- pinctrl-names: Set to "default". +- pinctrl-0: List of phandles pointing to pin configuration + nodes to set pins in mode of operation for dfsdm + on external pin. Contents of a STM32 DFSDM child nodes: -------------------------------------- @@ -68,8 +72,8 @@ Optional properties: - st,adc-channel-types: Single-ended channel input type. - "SPI_R": SPI with data on rising edge (default) - "SPI_F": SPI with data on falling edge - - "MANCH_R": manchester codec, rising edge = logic 0 - - "MANCH_F": manchester codec, falling edge = logic 1 + - "MANCH_R": manchester codec, rising edge = logic 0, falling edge = logic 1 + - "MANCH_F": manchester codec, rising edge = logic 1, falling edge = logic 0 - st,adc-channel-clk-src: Conversion clock source. - "CLKIN": external SPI clock (CLKIN x) - "CLKOUT": internal SPI clock (CLKOUT) (default) diff --git a/Documentation/devicetree/bindings/iio/potentiometer/ad5272.txt b/Documentation/devicetree/bindings/iio/potentiometer/ad5272.txt new file mode 100644 index 0000000..f9b2eef --- /dev/null +++ b/Documentation/devicetree/bindings/iio/potentiometer/ad5272.txt @@ -0,0 +1,27 @@ +* Analog Devices AD5272 digital potentiometer + +The node for this device must be a child node of a I2C controller, hence +all mandatory properties for your controller must be specified. See directory: + + Documentation/devicetree/bindings/i2c + +for more details. + +Required properties: + - compatible: Must be one of the following, depending on the model: + adi,ad5272-020 + adi,ad5272-050 + adi,ad5272-100 + adi,ad5274-020 + adi,ad5274-100 + +Optional properties: + - reset-gpios: GPIO specification for the RESET input. This is an + active low signal to the AD5272. + +Example: +ad5272: potentiometer@2f { + reg = <0x2F>; + compatible = "adi,ad5272-020"; + reset-gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>; +}; diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt new file mode 100644 index 0000000..0b05812 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt @@ -0,0 +1,28 @@ +* Melexis MLX90632 contactless Infra Red temperature sensor + +Link to datasheet: https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632 + +There are various applications for the Infra Red contactless temperature sensor +and MLX90632 is most suitable for consumer applications where measured object +temperature is in range between -20 to 200 degrees Celsius with relative error +of measurement below 1 degree Celsius in object temperature range for +industrial applications. Since it can operate and measure ambient temperature +in range of -20 to 85 degrees Celsius it is suitable also for outdoor use. + +Be aware that electronics surrounding the sensor can increase ambient +temperature. MLX90632 can be calibrated to reduce the housing effect via +already existing EEPROM parameters. + +Since measured object emissivity effects Infra Red energy emitted, emissivity +should be set before requesting the object temperature. + +Required properties: + - compatible: should be "melexis,mlx90632" + - reg: the I2C address of the sensor (default 0x3a) + +Example: + +mlx90632@3a { + compatible = "melexis,mlx90632"; + reg = <0x3a>; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt b/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt new file mode 100644 index 0000000..f4b4193 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt @@ -0,0 +1,19 @@ +* Andestech Internal Vector Interrupt Controller + +The Internal Vector Interrupt Controller (IVIC) is a basic interrupt controller +suitable for a simpler SoC platform not requiring a more sophisticated and +bigger External Vector Interrupt Controller. + + +Main node required properties: + +- compatible : should at least contain "andestech,ativic32". +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells: 1 cells and refer to interrupt-controller/interrupts + +Examples: + intc: interrupt-controller { + compatible = "andestech,ativic32"; + #interrupt-cells = <1>; + interrupt-controller; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/axis,crisv32-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/axis,crisv32-intc.txt deleted file mode 100644 index e8b123b..0000000 --- a/Documentation/devicetree/bindings/interrupt-controller/axis,crisv32-intc.txt +++ /dev/null @@ -1,23 +0,0 @@ -* CRISv32 Interrupt Controller - -Interrupt controller for the CRISv32 SoCs. - -Main node required properties: - -- compatible : should be: - "axis,crisv32-intc" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The type shall be a <u32> and the value shall be 1. -- reg: physical base address and size of the intc registers map. - -Example: - - intc: interrupt-controller { - compatible = "axis,crisv32-intc"; - reg = <0xb001c000 0x1000>; - interrupt-controller; - #interrupt-cells = <1>; - }; - - diff --git a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt new file mode 100644 index 0000000..b47a8a0 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt @@ -0,0 +1,22 @@ +Microsemi Ocelot SoC ICPU Interrupt Controller + +Required properties: + +- compatible : should be "mscc,ocelot-icpu-intr" +- 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 1. +- interrupt-parent : phandle of the CPU interrupt controller. +- interrupts : Specifies the CPU interrupt the controller is connected to. + +Example: + + intc: interrupt-controller@70000070 { + compatible = "mscc,ocelot-icpu-intr"; + reg = <0x70000070 0x70>; + #interrupt-cells = <1>; + interrupt-controller; + interrupt-parent = <&cpuintc>; + interrupts = <2>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt new file mode 100644 index 0000000..0b2c97d --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt @@ -0,0 +1,78 @@ +PDC interrupt controller + +Qualcomm Technologies Inc. SoCs based on the RPM Hardened architecture have a +Power Domain Controller (PDC) that is on always-on domain. In addition to +providing power control for the power domains, the hardware also has an +interrupt controller that can be used to help detect edge low interrupts as +well detect interrupts when the GIC is non-operational. + +GIC is parent interrupt controller at the highest level. Platform interrupt +controller PDC is next in hierarchy, followed by others. Drivers requiring +wakeup capabilities of their device interrupts routed through the PDC, must +specify PDC as their interrupt controller and request the PDC port associated +with the GIC interrupt. See example below. + +Properties: + +- compatible: + Usage: required + Value type: <string> + Definition: Should contain "qcom,<soc>-pdc" + - "qcom,sdm845-pdc": For SDM845 + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: Specifies the base physical address for PDC hardware. + +- interrupt-cells: + Usage: required + Value type: <u32> + Definition: Specifies the number of cells needed to encode an interrupt + source. + Must be 2. + The first element of the tuple is the PDC pin for the + interrupt. + The second element is the trigger type. + +- interrupt-parent: + Usage: required + Value type: <phandle> + Definition: Specifies the interrupt parent necessary for hierarchical + domain to operate. + +- interrupt-controller: + Usage: required + Value type: <bool> + Definition: Identifies the node as an interrupt controller. + +- qcom,pdc-ranges: + Usage: required + Value type: <u32 array> + Definition: Specifies the PDC pin offset and the number of PDC ports. + The tuples indicates the valid mapping of valid PDC ports + and their hwirq mapping. + The first element of the tuple is the starting PDC port. + The second element is the GIC hwirq number for the PDC port. + The third element is the number of interrupts in sequence. + +Example: + + pdc: interrupt-controller@b220000 { + compatible = "qcom,sdm845-pdc"; + reg = <0xb220000 0x30000>; + qcom,pdc-ranges = <0 512 94>, <94 641 15>, <115 662 7>; + #interrupt-cells = <2>; + interrupt-parent = <&intc>; + interrupt-controller; + }; + +DT binding of a device that wants to use the GIC SPI 514 as a wakeup +interrupt, must do - + + wake-device { + interrupts-extended = <&pdc 2 IRQ_TYPE_LEVEL_HIGH>; + }; + +In this case interrupt 514 would be mapped to port 2 on the PDC as defined by +the qcom,pdc-ranges property. diff --git a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt new file mode 100644 index 0000000..d98a9bf --- /dev/null +++ b/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt @@ -0,0 +1,25 @@ +* Aspeed KCS (Keyboard Controller Style) IPMI interface + +The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs +(Baseboard Management Controllers) and the KCS interface can be +used to perform in-band IPMI communication with their host. + +Required properties: +- compatible : should be one of + "aspeed,ast2400-kcs-bmc" + "aspeed,ast2500-kcs-bmc" +- interrupts : interrupt generated by the controller +- kcs_chan : The LPC channel number in the controller +- kcs_addr : The host CPU IO map address + + +Example: + + kcs3: kcs3@0 { + compatible = "aspeed,ast2500-kcs-bmc"; + reg = <0x0 0x80>; + interrupts = <8>; + kcs_chan = <3>; + kcs_addr = <0xCA2>; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/jailhouse.txt b/Documentation/devicetree/bindings/jailhouse.txt new file mode 100644 index 0000000..2901c25f --- /dev/null +++ b/Documentation/devicetree/bindings/jailhouse.txt @@ -0,0 +1,8 @@ +Jailhouse non-root cell device tree bindings +-------------------------------------------- + +When running in a non-root Jailhouse cell (partition), the device tree of this +platform shall have a top-level "hypervisor" node with the following +properties: + +- compatible = "jailhouse,cell" diff --git a/Documentation/devicetree/bindings/media/coda.txt b/Documentation/devicetree/bindings/media/coda.txt index 2865d04..90eb74c 100644 --- a/Documentation/devicetree/bindings/media/coda.txt +++ b/Documentation/devicetree/bindings/media/coda.txt @@ -7,8 +7,9 @@ called VPU (Video Processing Unit). Required properties: - compatible : should be "fsl,<chip>-src" for i.MX SoCs: (a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27 - (b) "fsl,imx53-vpu" for CODA7541 present in i.MX53 - (c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q + (b) "fsl,imx51-vpu" for CodaHx4 present in i.MX51 + (c) "fsl,imx53-vpu" for CODA7541 present in i.MX53 + (d) "fsl,imx6q-vpu" for CODA960 present in i.MX6q - reg: should be register base and length as documented in the SoC reference manual - interrupts : Should contain the VPU interrupt. For CODA960, diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index 9cbd92e..dcf57e7 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -13,7 +13,11 @@ Required Properties: - "adi,adv7611" for the ADV7611 - "adi,adv7612" for the ADV7612 - - reg: I2C slave address + - reg: I2C slave addresses + The ADV76xx has up to thirteen 256-byte maps that can be accessed via the + main I2C ports. Each map has it own I2C address and acts as a standard + slave device on the I2C bus. The main address is mandatory, others are + optional and revert to defaults if not specified. - hpd-gpios: References to the GPIOs that control the HDMI hot-plug detection pins, one per HDMI input. The active flag indicates the GPIO @@ -35,6 +39,11 @@ Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. - default-input: Select which input is selected after reset. + - reg-names : Names of maps with programmable addresses. + It can contain any map needing a non-default address. + Possible maps names are : + "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe", + "rep", "edid", "hdmi", "test", "cp", "vdp" Optional Endpoint Properties: @@ -52,7 +61,12 @@ Example: hdmi_receiver@4c { compatible = "adi,adv7611"; - reg = <0x4c>; + /* + * The edid page will be accessible @ 0x66 on the I2C bus. All + * other maps will retain their default addresses. + */ + reg = <0x4c>, <0x66>; + reg-names "main", "edid"; reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>; hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>; diff --git a/Documentation/devicetree/bindings/media/i2c/ov2685.txt b/Documentation/devicetree/bindings/media/i2c/ov2685.txt new file mode 100644 index 0000000..625c4a8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ov2685.txt @@ -0,0 +1,41 @@ +* Omnivision OV2685 MIPI CSI-2 sensor + +Required Properties: +- compatible: shall be "ovti,ov2685" +- clocks: reference to the xvclk input clock +- clock-names: shall be "xvclk" +- avdd-supply: Analog voltage supply, 2.8 volts +- dovdd-supply: Digital I/O voltage supply, 1.8 volts +- dvdd-supply: Digital core voltage supply, 1.8 volts +- reset-gpios: Low active reset gpio + +The device node shall contain one 'port' child node with an +'endpoint' subnode for its digital output video port, +in accordance with the video interface bindings defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. +The endpoint optional property 'data-lanes' shall be "<1>". + +Example: +&i2c7 { + ov2685: camera-sensor@3c { + compatible = "ovti,ov2685"; + reg = <0x3c>; + pinctrl-names = "default"; + pinctrl-0 = <&clk_24m_cam>; + + clocks = <&cru SCLK_TESTCLKOUT1>; + clock-names = "xvclk"; + + avdd-supply = <&pp2800_cam>; + dovdd-supply = <&pp1800>; + dvdd-supply = <&pp1800>; + reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>; + + port { + ucam_out: endpoint { + remote-endpoint = <&mipi_in_ucam>; + data-lanes = <1>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/media/i2c/ov5695.txt b/Documentation/devicetree/bindings/media/i2c/ov5695.txt new file mode 100644 index 0000000..640a637 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ov5695.txt @@ -0,0 +1,41 @@ +* Omnivision OV5695 MIPI CSI-2 sensor + +Required Properties: +- compatible: shall be "ovti,ov5695" +- clocks: reference to the xvclk input clock +- clock-names: shall be "xvclk" +- avdd-supply: Analog voltage supply, 2.8 volts +- dovdd-supply: Digital I/O voltage supply, 1.8 volts +- dvdd-supply: Digital core voltage supply, 1.2 volts +- reset-gpios: Low active reset gpio + +The device node shall contain one 'port' child node with an +'endpoint' subnode for its digital output video port, +in accordance with the video interface bindings defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. +The endpoint optional property 'data-lanes' shall be "<1 2>". + +Example: +&i2c7 { + ov5695: camera-sensor@36 { + compatible = "ovti,ov5695"; + reg = <0x36>; + pinctrl-names = "default"; + pinctrl-0 = <&clk_24m_cam>; + + clocks = <&cru SCLK_TESTCLKOUT1>; + clock-names = "xvclk"; + + avdd-supply = <&pp2800_cam>; + dovdd-supply = <&pp1800>; + dvdd-supply = <&pp1250_cam>; + reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; + + port { + wcam_out: endpoint { + remote-endpoint = <&mipi_in_wcam>; + data-lanes = <1 2>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt b/Documentation/devicetree/bindings/media/i2c/ov7670.txt index 826b656..2c972a5 100644 --- a/Documentation/devicetree/bindings/media/i2c/ov7670.txt +++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt @@ -9,14 +9,21 @@ Required Properties: - clocks: reference to the xclk input clock. - clock-names: should be "xclk". +Required Endpoint Properties: +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively. +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. + Optional Properties: - reset-gpios: reference to the GPIO connected to the resetb pin, if any. Active is low. - powerdown-gpios: reference to the GPIO connected to the pwdn pin, if any. Active is high. +- ov7670,pclk-hb-disable: a boolean property to suppress pixel clock output + signal during horizontal blankings. -The device node must contain one 'port' child node for its digital output -video port, in accordance with the video interface bindings defined in +The device node must contain one 'port' child node with one 'endpoint' child +sub-node for its digital output video port, in accordance with the video +interface bindings defined in: Documentation/devicetree/bindings/media/video-interfaces.txt. Example: @@ -34,8 +41,13 @@ Example: assigned-clocks = <&pck0>; assigned-clock-rates = <25000000>; + ov7670,pclk-hb-disable; + port { ov7670_0: endpoint { + hsync-active = <0>; + vsync-active = <0>; + remote-endpoint = <&isi_0>; }; }; diff --git a/Documentation/devicetree/bindings/media/i2c/ov9650.txt b/Documentation/devicetree/bindings/media/i2c/ov9650.txt new file mode 100644 index 0000000..506dfc5 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ov9650.txt @@ -0,0 +1,36 @@ +* Omnivision OV9650/OV9652 CMOS sensor + +Required Properties: +- compatible: shall be one of + "ovti,ov9650" + "ovti,ov9652" +- clocks: reference to the xvclk input clock. + +Optional Properties: +- reset-gpios: reference to the GPIO connected to the resetb pin, if any. + Active is high. +- powerdown-gpios: reference to the GPIO connected to the pwdn pin, if any. + Active is high. + +The device node shall contain one 'port' child node with one child 'endpoint' +subnode for its digital output video port, in accordance with the video +interface bindings defined in Documentation/devicetree/bindings/media/ +video-interfaces.txt. + +Example: + +&i2c0 { + ov9650: camera@30 { + compatible = "ovti,ov9650"; + reg = <0x30>; + reset-gpios = <&axi_gpio_0 0 GPIO_ACTIVE_HIGH>; + powerdown-gpios = <&axi_gpio_0 1 GPIO_ACTIVE_HIGH>; + clocks = <&xclk>; + + port { + ov9650_0: endpoint { + remote-endpoint = <&vcap1_in0>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt new file mode 100644 index 0000000..e761679 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt @@ -0,0 +1,178 @@ +Device-Tree bindings for the NXP TDA1997x HDMI receiver + +The TDA19971/73 are HDMI video receivers. + +The TDA19971 Video port output pins can be used as follows: + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4] + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4] + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4] + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2] + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0] + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles) + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles) + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles) + +The TDA19973 Video port output pins can be used as follows: + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0] + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0] + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0] + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles) + +The Video port output pins are mapped via 4-bit 'pin groups' allowing +for a variety of connection possibilities including swapping pin order within +pin groups. The video_portcfg device-tree property consists of register mapping +pairs which map a chip-specific VP output register to a 4-bit pin group. If +the pin group needs to be bit-swapped you can use the *_S pin-group defines. + +Required Properties: + - compatible : + - "nxp,tda19971" for the TDA19971 + - "nxp,tda19973" for the TDA19973 + - reg : I2C slave address + - interrupts : The interrupt number + - DOVDD-supply : Digital I/O supply + - DVDD-supply : Digital Core supply + - AVDD-supply : Analog supply + - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups. + +Optional Properties: + - nxp,audout-format : DAI bus format: "i2s" or "spdif". + - nxp,audout-width : width of audio output data bus (1-4). + - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used). + - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec + mclk. + +The port node shall contain one endpoint child node for its digital +output video port, in accordance with the video interface bindings defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. + +Optional Endpoint Properties: + The following three properties are defined in video-interfaces.txt and + are valid for the output parallel bus endpoint: + - hsync-active: Horizontal synchronization polarity. Defaults to active high. + - vsync-active: Vertical synchronization polarity. Defaults to active high. + - data-active: Data polarity. Defaults to active high. + +Examples: + - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422 + 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins) + hdmi-receiver@48 { + compatible = "nxp,tda19971"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_tda1997x>; + reg = <0x48>; + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + DOVDD-supply = <®_3p3v>; + AVDD-supply = <®_1p8v>; + DVDD-supply = <®_1p8v>; + /* audio */ + #sound-dai-cells = <0>; + nxp,audout-format = "i2s"; + nxp,audout-layout = <0>; + nxp,audout-width = <16>; + nxp,audout-mclk-fs = <128>; + /* + * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4] + * and Y[11:4] across 16bits in the same pixclk cycle. + */ + nxp,vidout-portcfg = + /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */ + < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >, + /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */ + < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >, + /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */ + < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >, + /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */ + < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >; + + port { + tda1997x_to_ipu1_csi0_mux: endpoint { + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>; + bus-width = <16>; + hsync-active = <1>; + vsync-active = <1>; + data-active = <1>; + }; + }; + }; + - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656 + 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins) + hdmi-receiver@48 { + compatible = "nxp,tda19971"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_tda1997x>; + reg = <0x48>; + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + DOVDD-supply = <®_3p3v>; + AVDD-supply = <®_1p8v>; + DVDD-supply = <®_1p8v>; + /* audio */ + #sound-dai-cells = <0>; + nxp,audout-format = "i2s"; + nxp,audout-layout = <0>; + nxp,audout-width = <16>; + nxp,audout-mclk-fs = <128>; + /* + * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4] + * and Y[11:4] across 16bits in the same pixclk cycle. + */ + nxp,vidout-portcfg = + /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */ + < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >, + /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */ + < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >, + /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */ + < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >, + /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */ + < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >; + + port { + tda1997x_to_ipu1_csi0_mux: endpoint { + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>; + bus-width = <16>; + hsync-active = <1>; + vsync-active = <1>; + data-active = <1>; + }; + }; + }; + - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656 + 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins) + hdmi-receiver@48 { + compatible = "nxp,tda19971"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_tda1997x>; + reg = <0x48>; + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + DOVDD-supply = <®_3p3v>; + AVDD-supply = <®_1p8v>; + DVDD-supply = <®_1p8v>; + /* audio */ + #sound-dai-cells = <0>; + nxp,audout-format = "i2s"; + nxp,audout-layout = <0>; + nxp,audout-width = <16>; + nxp,audout-mclk-fs = <128>; + /* + * The 8bpp BT656 mode outputs YCbCr[11:4] across 8bits over + * 2 pixclk cycles. + */ + nxp,vidout-portcfg = + /* YCbCr[11:8]<->VP[15:12]<->CSI_DATA[19:16] */ + < TDA1997X_VP24_V15_12 TDA1997X_R_CR_CBCR_11_8 >, + /* YCbCr[7:4]<->VP[11:08]<->CSI_DATA[15:12] */ + < TDA1997X_VP24_V11_08 TDA1997X_R_CR_CBCR_7_4 >, + + port { + tda1997x_to_ipu1_csi0_mux: endpoint { + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>; + bus-width = <16>; + hsync-active = <1>; + vsync-active = <1>; + data-active = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index 19357d0..1ce7ff9 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -56,7 +56,7 @@ Board setup example (vin1 composite video input) ------------------------------------------------ &i2c2 { - status = "ok"; + status = "okay"; pinctrl-0 = <&i2c2_pins>; pinctrl-names = "default"; @@ -79,7 +79,7 @@ Board setup example (vin1 composite video input) pinctrl-0 = <&vin1_pins>; pinctrl-names = "default"; - status = "ok"; + status = "okay"; port { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt b/Documentation/devicetree/bindings/media/renesas,ceu.txt new file mode 100644 index 0000000..3fc66df --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt @@ -0,0 +1,81 @@ +Renesas Capture Engine Unit (CEU) +---------------------------------------------- + +The Capture Engine Unit is the image capture interface found in the Renesas +SH Mobile and RZ SoCs. + +The interface supports a single parallel input with data bus width of 8 or 16 +bits. + +Required properties: +- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1H + and RZ/A1M SoCs. +- reg: Registers address base and size. +- interrupts: The interrupt specifier. + +The CEU supports a single parallel input and should contain a single 'port' +subnode with a single 'endpoint'. Connection to input devices are modeled +according to the video interfaces OF bindings specified in: +Documentation/devicetree/bindings/media/video-interfaces.txt + +Optional endpoint properties applicable to parallel input bus described in +the above mentioned "video-interfaces.txt" file are supported. + +- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH respectively. + If property is not present, default is active high. +- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. + If property is not present, default is active high. + +Example: + +The example describes the connection between the Capture Engine Unit and an +OV7670 image sensor connected to i2c1 interface. + +ceu: ceu@e8210000 { + reg = <0xe8210000 0x209c>; + compatible = "renesas,r7s72100-ceu"; + interrupts = <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>; + + pinctrl-names = "default"; + pinctrl-0 = <&vio_pins>; + + status = "okay"; + + port { + ceu_in: endpoint { + remote-endpoint = <&ov7670_out>; + + hsync-active = <1>; + vsync-active = <0>; + }; + }; +}; + +i2c1: i2c@fcfee400 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; + + status = "okay"; + + clock-frequency = <100000>; + + ov7670: camera@21 { + compatible = "ovti,ov7670"; + reg = <0x21>; + + pinctrl-names = "default"; + pinctrl-0 = <&vio_pins>; + + reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>; + powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>; + + port { + ov7670_out: endpoint { + remote-endpoint = <&ceu_in>; + + hsync-active = <1>; + vsync-active = <0>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index d3404b5..aa54c81 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -13,6 +13,7 @@ Required properties: (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC (e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC + (f) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC - reg : Physical base address of the IP registers and length of memory mapped region. diff --git a/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt new file mode 100644 index 0000000..fc5aa26 --- /dev/null +++ b/Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt @@ -0,0 +1,14 @@ +Sony CXD2880 DVB-T2/T tuner + demodulator driver SPI adapter + +Required properties: +- compatible: Should be "sony,cxd2880". +- reg: SPI chip select number for the device. +- spi-max-frequency: Maximum bus speed, should be set to <55000000> (55MHz). + +Example: + +cxd2880@0 { + compatible = "sony,cxd2880"; + reg = <0>; /* CE0 */ + spi-max-frequency = <55000000>; /* 55MHz */ +}; diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt index 91648c5..2780989 100644 --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt @@ -11,6 +11,8 @@ Required properties: Optional properties: - linux,rc-map-name: see rc.txt file in the same directory. - resets : phandle + reset specifier pair +- clock-frequency : IR Receiver clock frequency, in Hertz. Defaults to 8 MHz + if missing. Example: @@ -18,6 +20,7 @@ ir0: ir@1c21800 { compatible = "allwinner,sun4i-a10-ir"; clocks = <&apb0_gates 6>, <&ir0_clk>; clock-names = "apb", "ir"; + clock-frequency = <3000000>; resets = <&apb0_rst 1>; interrupts = <0 5 1>; reg = <0x01C21800 0x40>; diff --git a/Documentation/devicetree/bindings/metag/meta.txt b/Documentation/devicetree/bindings/metag/meta.txt deleted file mode 100644 index f4457f5..0000000 --- a/Documentation/devicetree/bindings/metag/meta.txt +++ /dev/null @@ -1,30 +0,0 @@ -* Meta Processor Binding - -This binding specifies what properties must be available in the device tree -representation of a Meta Processor Core, which is the root node in the tree. - -Required properties: - - - compatible: Specifies the compatibility list for the Meta processor. - The type shall be <string> and the value shall include "img,meta". - -Optional properties: - - - clocks: Clock consumer specifiers as described in - Documentation/devicetree/bindings/clock/clock-bindings.txt - - - clock-names: Clock consumer names as described in - Documentation/devicetree/bindings/clock/clock-bindings.txt. - -Clocks are identified by name. Valid clocks are: - - - "core": The Meta core clock from which the Meta timers are derived. - -* Examples - -/ { - compatible = "toumaz,tz1090", "img,meta"; - - clocks = <&meta_core_clk>; - clock-names = "core"; -}; diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt index 514d82c..69aadee 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt @@ -109,9 +109,50 @@ lpc: lpc@1e789000 { }; }; +BMC Node Children +================== + + Host Node Children ================== +LPC Host Interface Controller +------------------- + +The LPC Host Interface Controller manages functions exposed to the host such as +LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART +management and bus snoop configuration. + +Required properties: + +- compatible: One of: + "aspeed,ast2400-lpc-ctrl"; + "aspeed,ast2500-lpc-ctrl"; + +- reg: contains offset/length values of the host interface controller + memory regions + +- clocks: contains a phandle to the syscon node describing the clocks. + There should then be one cell representing the clock to use + +- memory-region: A phandle to a reserved_memory region to be used for the LPC + to AHB mapping + +- flash: A phandle to the SPI flash controller containing the flash to + be exposed over the LPC to AHB mapping + +Example: + +lpc-host@80 { + lpc_ctrl: lpc-ctrl@0 { + compatible = "aspeed,ast2500-lpc-ctrl"; + reg = <0x0 0x80>; + clocks = <&syscon ASPEED_CLK_GATE_LCLK>; + memory-region = <&flash_memory>; + flash = <&spi>; + }; +}; + LPC Host Controller ------------------- diff --git a/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt new file mode 100644 index 0000000..a0693b714 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt @@ -0,0 +1,40 @@ +* Hisilicon Hi3798CV200 specific extensions to the Synopsys Designware Mobile + Storage Host Controller + +Read synopsys-dw-mshc.txt for more details + +The Synopsys designware mobile storage host controller is used to interface +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents +differences between the core Synopsys dw mshc controller properties described +by synopsys-dw-mshc.txt and the properties used by the Hisilicon Hi3798CV200 +specific extensions to the Synopsys Designware Mobile Storage Host Controller. + +Required Properties: +- compatible: Should contain "hisilicon,hi3798cv200-dw-mshc". +- clocks: A list of phandle + clock-specifier pairs for the clocks listed + in clock-names. +- clock-names: Should contain the following: + "ciu" - The ciu clock described in synopsys-dw-mshc.txt. + "biu" - The biu clock described in synopsys-dw-mshc.txt. + "ciu-sample" - Hi3798CV200 extended phase clock for ciu sampling. + "ciu-drive" - Hi3798CV200 extended phase clock for ciu driving. + +Example: + + emmc: mmc@9830000 { + compatible = "hisilicon,hi3798cv200-dw-mshc"; + reg = <0x9830000 0x10000>; + interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&crg HISTB_MMC_CIU_CLK>, + <&crg HISTB_MMC_BIU_CLK>, + <&crg HISTB_MMC_SAMPLE_CLK>, + <&crg HISTB_MMC_DRV_CLK>; + clock-names = "ciu", "biu", "ciu-sample", "ciu-drive"; + fifo-depth = <256>; + clock-frequency = <200000000>; + cap-mmc-highspeed; + mmc-ddr-1_8v; + mmc-hs200-1_8v; + non-removable; + bus-width = <8>; + }; diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt index 9b80176..f33467a 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173 "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701 "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712 + "mediatek,mt7622-mmc": for MT7622 SoC "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC - reg: physical base address of the controller and length diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt index ef3e5f1..7e5e427 100644 --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt @@ -59,15 +59,6 @@ Optional properties: is specified and the ciu clock is specified then we'll try to set the ciu clock to this at probe time. -* clock-freq-min-max (DEPRECATED): Minimum and Maximum clock frequency for card output - clock(cclk_out). If it's not specified, max is 200MHZ and min is 400KHz by default. - (Use the "max-frequency" instead of "clock-freq-min-max".) - -* num-slots (DEPRECATED): specifies the number of slots supported by the controller. - The number of physical slots actually used could be equal or less than the - value specified by num-slots. If this property is not specified, the value - of num-slot property is assumed to be 1. - * fifo-depth: The maximum size of the tx/rx fifo's. If this property is not specified, the default value of the fifo size is determined from the controller registers. diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index d8685cb..2d5287e 100644 --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -50,7 +50,6 @@ Required properties: 2: R7S72100 Optional properties: -- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable - pinctrl-names: should be "default", "state_uhs" - pinctrl-0: should contain default/high speed pin ctrl - pinctrl-1: should contain uhs mode pin ctrl diff --git a/Documentation/devicetree/bindings/nds32/andestech-boards b/Documentation/devicetree/bindings/nds32/andestech-boards new file mode 100644 index 0000000..f5d7569 --- /dev/null +++ b/Documentation/devicetree/bindings/nds32/andestech-boards @@ -0,0 +1,40 @@ +Andestech(nds32) AE3XX Platform +----------------------------------------------------------------------------- +The AE3XX prototype demonstrates the AE3XX example platform on the FPGA. It +is composed of one Andestech(nds32) processor and AE3XX. + +Required properties (in root node): +- compatible = "andestech,ae3xx"; + +Example: +/dts-v1/; +/ { + compatible = "andestech,ae3xx"; + #address-cells = <1>; + #size-cells = <1>; + interrupt-parent = <&intc>; +}; + +Andestech(nds32) AG101P Platform +----------------------------------------------------------------------------- +AG101P is a generic SoC Platform IP that works with any of Andestech(nds32) +processors to provide a cost-effective and high performance solution for +majority of embedded systems in variety of application domains. Users may +simply attach their IP on one of the system buses together with certain glue +logics to complete a SoC solution for a specific application. With +comprehensive simulation and design environments, users may evaluate the +system performance of their applications and track bugs of their designs +efficiently. The optional hardware development platform further provides real +system environment for early prototyping and software/hardware co-development. + +Required properties (in root node): + compatible = "andestech,ag101p"; + +Example: +/dts-v1/; +/ { + compatible = "andestech,ag101p"; + #address-cells = <1>; + #size-cells = <1>; + interrupt-parent = <&intc>; +}; diff --git a/Documentation/devicetree/bindings/nds32/atl2c.txt b/Documentation/devicetree/bindings/nds32/atl2c.txt new file mode 100644 index 0000000..da8ab8e --- /dev/null +++ b/Documentation/devicetree/bindings/nds32/atl2c.txt @@ -0,0 +1,28 @@ +* Andestech L2 cache Controller + +The level-2 cache controller plays an important role in reducing memory latency +for high performance systems, such as thoese designs with AndesCore processors. +Level-2 cache controller in general enhances overall system performance +signigicantly and the system power consumption might be reduced as well by +reducing DRAM accesses. + +This binding specifies what properties must be available in the device tree +representation of an Andestech L2 cache controller. + +Required properties: + - compatible: + Usage: required + Value type: <string> + Definition: "andestech,atl2c" + - reg : Physical base address and size of cache controller's memory mapped + - cache-unified : Specifies the cache is a unified cache. + - cache-level : Should be set to 2 for a level 2 cache. + +* Example + + cache-controller@e0500000 { + compatible = "andestech,atl2c"; + reg = <0xe0500000 0x1000>; + cache-unified; + cache-level = <2>; + }; diff --git a/Documentation/devicetree/bindings/nds32/cpus.txt b/Documentation/devicetree/bindings/nds32/cpus.txt new file mode 100644 index 0000000..6f9e311 --- /dev/null +++ b/Documentation/devicetree/bindings/nds32/cpus.txt @@ -0,0 +1,38 @@ +* Andestech Processor Binding + +This binding specifies what properties must be available in the device tree +representation of a Andestech Processor Core, which is the root node in the +tree. + +Required properties: + + - compatible: + Usage: required + Value type: <string> + Definition: Should be "andestech,<core_name>", "andestech,nds32v3" as fallback. + Must contain "andestech,nds32v3" as the most generic value, in addition to + one of the following identifiers for a particular CPU core: + "andestech,n13" + "andestech,n15" + "andestech,d15" + "andestech,n10" + "andestech,d10" + - device_type + Usage: required + Value type: <string> + Definition: must be "cpu" + - reg: Contains CPU index. + - clock-frequency: Contains the clock frequency for CPU, in Hz. + +* Examples + +/ { + cpus { + cpu@0 { + device_type = "cpu"; + compatible = "andestech,n13", "andestech,nds32v3"; + reg = <0x0>; + clock-frequency = <60000000> + }; + }; +}; diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt index 1d4d0f4..60d50a2 100644 --- a/Documentation/devicetree/bindings/net/dsa/marvell.txt +++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt @@ -13,9 +13,18 @@ placed as a child node of an mdio device. The properties described here are those specific to Marvell devices. Additional required and optional properties can be found in dsa.txt. +The compatibility string is used only to find an identification register, +which is at a different MDIO base address in different switch families. +- "marvell,mv88e6085" : Switch has base address 0x10. Use with models: + 6085, 6095, 6097, 6123, 6131, 6141, 6161, 6165, + 6171, 6172, 6175, 6176, 6185, 6240, 6320, 6321, + 6341, 6350, 6351, 6352 +- "marvell,mv88e6190" : Switch has base address 0x00. Use with models: + 6190, 6190X, 6191, 6290, 6390, 6390X + Required properties: - compatible : Should be one of "marvell,mv88e6085" or - "marvell,mv88e6190" + "marvell,mv88e6190" as indicated above - reg : Address on the MII bus for the switch. Optional properties: @@ -50,14 +59,15 @@ Example: compatible = "marvell,mv88e6085"; reg = <0>; reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>; - }; - mdio { - #address-cells = <1>; - #size-cells = <0>; - switch1phy0: switch1phy0@0 { - reg = <0>; - interrupt-parent = <&switch0>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + switch1phy0: switch1phy0@0 { + reg = <0>; + interrupt-parent = <&switch0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; }; }; }; @@ -74,23 +84,24 @@ Example: compatible = "marvell,mv88e6390"; reg = <0>; reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>; - }; - mdio { - #address-cells = <1>; - #size-cells = <0>; - switch1phy0: switch1phy0@0 { - reg = <0>; - interrupt-parent = <&switch0>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + switch1phy0: switch1phy0@0 { + reg = <0>; + interrupt-parent = <&switch0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; }; - }; - mdio1 { - compatible = "marvell,mv88e6xxx-mdio-external"; - #address-cells = <1>; - #size-cells = <0>; - switch1phy9: switch1phy0@9 { - reg = <9>; + mdio1 { + compatible = "marvell,mv88e6xxx-mdio-external"; + #address-cells = <1>; + #size-cells = <0>; + switch1phy9: switch1phy0@9 { + reg = <9>; + }; }; }; }; diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt index 2974e63..cfc376b 100644 --- a/Documentation/devicetree/bindings/net/ethernet.txt +++ b/Documentation/devicetree/bindings/net/ethernet.txt @@ -10,6 +10,8 @@ Documentation/devicetree/bindings/phy/phy-bindings.txt. the boot program; should be used in cases where the MAC address assigned to the device by the boot program is different from the "local-mac-address" property; +- nvmem-cells: phandle, reference to an nvmem node for the MAC address; +- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used; - max-speed: number, specifies maximum speed in Mbit/s supported by the device; - max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than the maximum frame size (there's contradiction in the Devicetree diff --git a/Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt b/Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt new file mode 100644 index 0000000..2aaef56 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt @@ -0,0 +1,23 @@ +* MCR20A IEEE 802.15.4 * + +Required properties: + - compatible: should be "nxp,mcr20a" + - spi-max-frequency: maximal bus speed, should be set to a frequency + lower than 9000000 depends sync or async operation mode + - reg: the chipselect index + - interrupts: the interrupt generated by the device. Non high-level + can occur deadlocks while handling isr. + +Optional properties: + - rst_b-gpio: GPIO spec for the RST_B pin + +Example: + + mcr20a@0 { + compatible = "nxp,mcr20a"; + spi-max-frequency = <9000000>; + reg = <0>; + interrupts = <17 2>; + interrupt-parent = <&gpio>; + rst_b-gpio = <&gpio 27 1> + }; diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 27966ae..457d5ae 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -29,6 +29,7 @@ Optional properties for PHY child node: - reset-gpios : Should specify the gpio for phy reset - magic-packet : If present, indicates that the hardware supports waking up via magic packet. +- phy-handle : see ethernet.txt file in the same directory Examples: diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt index 354dd98..61cada2 100644 --- a/Documentation/devicetree/bindings/net/meson-dwmac.txt +++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt @@ -9,6 +9,7 @@ Required properties on all platforms: - compatible: Depending on the platform this should be one of: - "amlogic,meson6-dwmac" - "amlogic,meson8b-dwmac" + - "amlogic,meson8m2-dwmac" - "amlogic,meson-gxbb-dwmac" Additionally "snps,dwmac" and any applicable more detailed version number described in net/stmmac.txt @@ -19,13 +20,13 @@ Required properties on all platforms: configuration (for example the PRG_ETHERNET register range on Meson8b and newer) -Required properties on Meson8b and newer: +Required properties on Meson8b, Meson8m2, GXBB and newer: - clock-names: Should contain the following: - "stmmaceth" - see stmmac.txt - "clkin0" - first parent clock of the internal mux - "clkin1" - second parent clock of the internal mux -Optional properties on Meson8b and newer: +Optional properties on Meson8b, Meson8m2, GXBB and newer: - amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided by this driver) in nanoseconds. Allowed values are: 0ns, 2ns, 4ns, 6ns. diff --git a/Documentation/devicetree/bindings/net/nixge.txt b/Documentation/devicetree/bindings/net/nixge.txt new file mode 100644 index 0000000..e55af7f --- /dev/null +++ b/Documentation/devicetree/bindings/net/nixge.txt @@ -0,0 +1,32 @@ +* NI XGE Ethernet controller + +Required properties: +- compatible: Should be "ni,xge-enet-2.00" +- reg: Address and length of the register set for the device +- interrupts: Should contain tx and rx interrupt +- interrupt-names: Should be "rx" and "tx" +- phy-mode: See ethernet.txt file in the same directory. +- phy-handle: See ethernet.txt file in the same directory. +- nvmem-cells: Phandle of nvmem cell containing the MAC address +- nvmem-cell-names: Should be "address" + +Examples (10G generic PHY): + nixge0: ethernet@40000000 { + compatible = "ni,xge-enet-2.00"; + reg = <0x40000000 0x6000>; + + nvmem-cells = <ð1_addr>; + nvmem-cell-names = "address"; + + interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>, <0 30 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "rx", "tx"; + interrupt-parent = <&intc>; + + phy-mode = "xgmii"; + phy-handle = <ðernet_phy1>; + + ethernet_phy1: ethernet-phy@4 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <4>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 92fd4b2..c306f55 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -7,6 +7,7 @@ Required properties: - compatible: Must contain one or more of the following: - "renesas,etheravb-r8a7743" for the R8A7743 SoC. - "renesas,etheravb-r8a7745" for the R8A7745 SoC. + - "renesas,etheravb-r8a77470" for the R8A77470 SoC. - "renesas,etheravb-r8a7790" for the R8A7790 SoC. - "renesas,etheravb-r8a7791" for the R8A7791 SoC. - "renesas,etheravb-r8a7792" for the R8A7792 SoC. @@ -27,7 +28,11 @@ Required properties: SoC-specific version corresponding to the platform first followed by the generic version. -- reg: offset and length of (1) the register block and (2) the stream buffer. +- reg: Offset and length of (1) the register block and (2) the stream buffer. + The region for the register block is mandatory. + The region for the stream buffer is optional, as it is only present on + R-Car Gen2 and RZ/G1 SoCs, and on R-Car H3 (R8A7795), M3-W (R8A7796), + and M3-N (R8A77965). - interrupts: A list of interrupt-specifiers, one for each entry in interrupt-names. If interrupt-names is not present, an interrupt specifier diff --git a/Documentation/devicetree/bindings/net/sff,sfp.txt b/Documentation/devicetree/bindings/net/sff,sfp.txt index f1c441b..929591d 100644 --- a/Documentation/devicetree/bindings/net/sff,sfp.txt +++ b/Documentation/devicetree/bindings/net/sff,sfp.txt @@ -33,6 +33,10 @@ Optional Properties: Select (AKA RS1) output gpio signal (SFP+ only), low: low Tx rate, high: high Tx rate. Must not be present for SFF modules +- maximum-power-milliwatt : Maximum module power consumption + Specifies the maximum power consumption allowable by a module in the + slot, in milli-Watts. Presently, modules can be up to 1W, 1.5W or 2W. + Example #1: Direct serdes to SFP connection sfp_eth3: sfp-eth3 { @@ -40,6 +44,7 @@ sfp_eth3: sfp-eth3 { i2c-bus = <&sfp_1g_i2c>; los-gpios = <&cpm_gpio2 22 GPIO_ACTIVE_HIGH>; mod-def0-gpios = <&cpm_gpio2 21 GPIO_ACTIVE_LOW>; + maximum-power-milliwatt = <1000>; pinctrl-names = "default"; pinctrl-0 = <&cpm_sfp_1g_pins &cps_sfp_1g_pins>; tx-disable-gpios = <&cps_gpio1 24 GPIO_ACTIVE_HIGH>; diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt index 270ea4e..96398cc 100644 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt @@ -9,6 +9,7 @@ Required properties: - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC - "socionext,uniphier-ld11-ave4" : for LD11 SoC - "socionext,uniphier-ld20-ave4" : for LD20 SoC + - "socionext,uniphier-pxs3-ave4" : for PXs3 SoC - reg: Address where registers are mapped and size of region. - interrupts: Should contain the MAC interrupt. - phy-mode: See ethernet.txt in the same directory. Allow to choose diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt index 02c4353..9ef9338 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt @@ -25,6 +25,8 @@ Optional property: software needs to take when this pin is strapped in these modes. See data manual for details. + - ti,clk-output-sel - Muxing option for CLK_OUT pin - see dt-bindings/net/ti-dp83867.h + for applicable values. Note: ti,min-output-impedance and ti,max-output-impedance are mutually exclusive. When both properties are present ti,max-output-impedance diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt index f162c72..729f674 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt @@ -11,17 +11,32 @@ Required properties: "fsl,imx6ul-ocotp" (i.MX6UL), "fsl,imx7d-ocotp" (i.MX7D/S), followed by "syscon". +- #address-cells : Should be 1 +- #size-cells : Should be 1 - reg: Should contain the register base and length. - clocks: Should contain a phandle pointing to the gated peripheral clock. Optional properties: - read-only: disable write access -Example: +Optional Child nodes: + +- Data cells of ocotp: + Detailed bindings are described in bindings/nvmem/nvmem.txt +Example: ocotp: ocotp@21bc000 { - compatible = "fsl,imx6q-ocotp", "syscon"; + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,imx6sx-ocotp", "syscon"; reg = <0x021bc000 0x4000>; - clocks = <&clks IMX6QDL_CLK_IIM>; - read-only; + clocks = <&clks IMX6SX_CLK_OCOTP>; + + tempmon_calib: calib@38 { + reg = <0x38 4>; + }; + + tempmon_temp_grade: temp-grade@20 { + reg = <0x20 4>; + }; }; diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt index 20bc49b..3cb1708 100644 --- a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt +++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt @@ -1,5 +1,5 @@ Device tree bindings for Low Power General Purpose Register found in i.MX6Q/D -Secure Non-Volatile Storage. +and i.MX7 Secure Non-Volatile Storage. This DT node should be represented as a sub-node of a "syscon", "simple-mfd" node. @@ -8,6 +8,7 @@ Required properties: - compatible: should be one of the fallowing variants: "fsl,imx6q-snvs-lpgpr" for Freescale i.MX6Q/D/DL/S "fsl,imx6ul-snvs-lpgpr" for Freescale i.MX6UL + "fsl,imx7d-snvs-lpgpr" for Freescale i.MX7D/S Example: snvs: snvs@020cc000 { diff --git a/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt index a105494..b84a02e 100644 --- a/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt +++ b/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt @@ -6,6 +6,10 @@ Required properties: - #phys-cells: must be 0 (see phy-bindings.txt in this directory) Optional properties: +- clocks: a phandle to the clock of this PHY +- clock-names: must be "phy" +- resets: a phandle to the reset line of this PHY +- reset-names: must be "phy" - phy-supply: see phy-bindings.txt in this directory diff --git a/Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt b/Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt new file mode 100644 index 0000000..114947e --- /dev/null +++ b/Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt @@ -0,0 +1,31 @@ +* Amlogic Meson GXL and GXM USB3 PHY and OTG detection binding + +Required properties: +- compatible: Should be "amlogic,meson-gxl-usb3-phy" +- #phys-cells: must be 0 (see phy-bindings.txt in this directory) +- reg: The base address and length of the registers +- interrupts: the interrupt specifier for the OTG detection +- clocks: phandles to the clocks for + - the USB3 PHY + - and peripheral mode/OTG detection +- clock-names: must contain "phy" and "peripheral" +- resets: phandle to the reset lines for: + - the USB3 PHY and + - peripheral mode/OTG detection +- reset-names: must contain "phy" and "peripheral" + +Optional properties: +- phy-supply: see phy-bindings.txt in this directory + + +Example: + usb3_phy0: phy@78080 { + compatible = "amlogic,meson-gxl-usb3-phy"; + #phy-cells = <0>; + reg = <0x0 0x78080 0x0 0x20>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clkc CLKID_USB_OTG>, <&clkc_AO CLKID_AO_CEC_32K>; + clock-names = "phy", "peripheral"; + resets = <&reset RESET_USB_OTG>, <&reset RESET_USB_OTG>; + reset-names = "phy", "peripheral"; + }; diff --git a/Documentation/devicetree/bindings/phy/phy-hi3798cv200-combphy.txt b/Documentation/devicetree/bindings/phy/phy-hi3798cv200-combphy.txt new file mode 100644 index 0000000..17b0c76 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-hi3798cv200-combphy.txt @@ -0,0 +1,59 @@ +HiSilicon STB PCIE/SATA/USB3 PHY + +Required properties: +- compatible: Should be "hisilicon,hi3798cv200-combphy" +- reg: Should be the address space for COMBPHY configuration and state + registers in peripheral controller, e.g. PERI_COMBPHY0_CFG and + PERI_COMBPHY0_STATE for COMBPHY0 Hi3798CV200 SoC. +- #phy-cells: Should be 1. The cell number is used to select the phy mode + as defined in <dt-bindings/phy/phy.h>. +- clocks: The phandle to clock provider and clock specifier pair. +- resets: The phandle to reset controller and reset specifier pair. + +Refer to phy/phy-bindings.txt for the generic PHY binding properties. + +Optional properties: +- hisilicon,fixed-mode: If the phy device doesn't support mode select + but a fixed mode setting, the property should be present to specify + the particular mode. +- hisilicon,mode-select-bits: If the phy device support mode select, + this property should be present to specify the register bits in + peripheral controller, as a 3 integers tuple: + <register_offset bit_shift bit_mask>. + +Notes: +- Between hisilicon,fixed-mode and hisilicon,mode-select-bits, one and only + one of them should be present. +- The device node should be a child of peripheral controller that contains + COMBPHY configuration/state and PERI_CTRL register used to select PHY mode. + Refer to arm/hisilicon/hisilicon.txt for the parent peripheral controller + bindings. + +Examples: + +perictrl: peripheral-controller@8a20000 { + compatible = "hisilicon,hi3798cv200-perictrl", "syscon", + "simple-mfd"; + reg = <0x8a20000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x8a20000 0x1000>; + + combphy0: phy@850 { + compatible = "hisilicon,hi3798cv200-combphy"; + reg = <0x850 0x8>; + #phy-cells = <1>; + clocks = <&crg HISTB_COMBPHY0_CLK>; + resets = <&crg 0x188 4>; + hisilicon,fixed-mode = <PHY_TYPE_USB3>; + }; + + combphy1: phy@858 { + compatible = "hisilicon,hi3798cv200-combphy"; + reg = <0x858 0x8>; + #phy-cells = <1>; + clocks = <&crg HISTB_COMBPHY1_CLK>; + resets = <&crg 0x188 12>; + hisilicon,mode-select-bits = <0x0008 11 (0x3 << 11)>; + }; +}; diff --git a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt new file mode 100644 index 0000000..0d70c83 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt @@ -0,0 +1,71 @@ +Device tree bindings for HiSilicon INNO USB2 PHY + +Required properties: +- compatible: Should be one of the following strings: + "hisilicon,inno-usb2-phy", + "hisilicon,hi3798cv200-usb2-phy". +- reg: Should be the address space for PHY configuration register in peripheral + controller, e.g. PERI_USB0 for USB 2.0 PHY01 on Hi3798CV200 SoC. +- clocks: The phandle and clock specifier pair for INNO USB2 PHY device + reference clock. +- resets: The phandle and reset specifier pair for INNO USB2 PHY device reset + signal. +- #address-cells: Must be 1. +- #size-cells: Must be 0. + +The INNO USB2 PHY device should be a child node of peripheral controller that +contains the PHY configuration register, and each device suppports up to 2 PHY +ports which are represented as child nodes of INNO USB2 PHY device. + +Required properties for PHY port node: +- reg: The PHY port instance number. +- #phy-cells: Defined by generic PHY bindings. Must be 0. +- resets: The phandle and reset specifier pair for PHY port reset signal. + +Refer to phy/phy-bindings.txt for the generic PHY binding properties + +Example: + +perictrl: peripheral-controller@8a20000 { + compatible = "hisilicon,hi3798cv200-perictrl", "simple-mfd"; + reg = <0x8a20000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x8a20000 0x1000>; + + usb2_phy1: usb2-phy@120 { + compatible = "hisilicon,hi3798cv200-usb2-phy"; + reg = <0x120 0x4>; + clocks = <&crg HISTB_USB2_PHY1_REF_CLK>; + resets = <&crg 0xbc 4>; + #address-cells = <1>; + #size-cells = <0>; + + usb2_phy1_port0: phy@0 { + reg = <0>; + #phy-cells = <0>; + resets = <&crg 0xbc 8>; + }; + + usb2_phy1_port1: phy@1 { + reg = <1>; + #phy-cells = <0>; + resets = <&crg 0xbc 9>; + }; + }; + + usb2_phy2: usb2-phy@124 { + compatible = "hisilicon,hi3798cv200-usb2-phy"; + reg = <0x124 0x4>; + clocks = <&crg HISTB_USB2_PHY2_REF_CLK>; + resets = <&crg 0xbc 6>; + #address-cells = <1>; + #size-cells = <0>; + + usb2_phy2_port0: phy@0 { + reg = <0>; + #phy-cells = <0>; + resets = <&crg 0xbc 10>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt new file mode 100644 index 0000000..29427d4 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt @@ -0,0 +1,29 @@ +Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY + +Required properties: +- compatible Must be "motorola,mapphone-mdm6600" +- enable-gpios GPIO to enable the USB PHY +- power-gpios GPIO to power on the device +- reset-gpios GPIO to reset the device +- motorola,mode-gpios Two GPIOs to configure MDM6600 USB start-up mode for + normal mode versus USB flashing mode +- motorola,cmd-gpios Three GPIOs to control the power state of the MDM6600 +- motorola,status-gpios Three GPIOs to read the power state of the MDM6600 + +Example: + +usb-phy { + compatible = "motorola,mapphone-mdm6600"; + enable-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>; + power-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio2 17 GPIO_ACTIVE_HIGH>; + motorola,mode-gpios = <&gpio5 20 GPIO_ACTIVE_HIGH>, + <&gpio5 21 GPIO_ACTIVE_HIGH>; + motorola,cmd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>, + <&gpio4 8 GPIO_ACTIVE_HIGH>, + <&gpio5 14 GPIO_ACTIVE_HIGH>; + motorola,status-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>, + <&gpio2 21 GPIO_ACTIVE_HIGH>, + <&gpio2 23 GPIO_ACTIVE_HIGH>; + #phy-cells = <0>; +}; diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt index 41e09ed..0d34b2b 100644 --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt @@ -27,6 +27,10 @@ Optional properties (controller (parent) node): - reg : offset and length of register shared by multiple ports, exclude port's private register. It is needed on mt2701 and mt8173, but not on mt2712. + - mediatek,src-ref-clk-mhz : frequency of reference clock for slew rate + calibrate + - mediatek,src-coef : coefficient for slew rate calibrate, depends on + SoC process Required properties (port (child) node): - reg : address and length of the register set for the port. diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt index 6ea867e..960da7f 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt @@ -14,25 +14,9 @@ Required properties: - resets : a list of phandle + reset specifier pairs - reset-names : string reset name, must be: "uphy", "uphy-pipe", "uphy-tcphy" - - extcon : extcon specifier for the Power Delivery -Note, there are 2 type-c phys for RK3399, and they are almost identical, except -these registers(description below), every register node contains 3 sections: -offset, enable bit, write mask bit. - - rockchip,typec-conn-dir : the register of type-c connector direction, - for type-c phy0, it must be <0xe580 0 16>; - for type-c phy1, it must be <0xe58c 0 16>; - - rockchip,usb3tousb2-en : the register of type-c force usb3 to usb2 enable - control. - for type-c phy0, it must be <0xe580 3 19>; - for type-c phy1, it must be <0xe58c 3 19>; - - rockchip,external-psm : the register of type-c phy external psm clock - selection. - for type-c phy0, it must be <0xe588 14 30>; - for type-c phy1, it must be <0xe594 14 30>; - - rockchip,pipe-status : the register of type-c phy pipe status. - for type-c phy0, it must be <0xe5c0 0 0>; - for type-c phy1, it must be <0xe5c0 16 16>; +Optional properties: + - extcon : extcon specifier for the Power Delivery Required nodes : a sub-node is required for each port the phy provides. The sub-node name is used to identify dp or usb3 port, @@ -43,6 +27,13 @@ Required nodes : a sub-node is required for each port the phy provides. Required properties (port (child) node): - #phy-cells : must be 0, See ./phy-bindings.txt for details. +Deprecated properties, do not use in new device tree sources, these +properties are determined by the compatible value: + - rockchip,typec-conn-dir + - rockchip,usb3tousb2-en + - rockchip,external-psm + - rockchip,pipe-status + Example: tcphy0: phy@ff7c0000 { compatible = "rockchip,rk3399-typec-phy"; @@ -58,10 +49,6 @@ Example: <&cru SRST_UPHY0_PIPE_L00>, <&cru SRST_P_UPHY0_TCPHY>; reset-names = "uphy", "uphy-pipe", "uphy-tcphy"; - rockchip,typec-conn-dir = <0xe580 0 16>; - rockchip,usb3tousb2-en = <0xe580 3 19>; - rockchip,external-psm = <0xe588 14 30>; - rockchip,pipe-status = <0xe5c0 0 0>; tcphy0_dp: dp-port { #phy-cells = <0>; @@ -86,10 +73,6 @@ Example: <&cru SRST_UPHY1_PIPE_L00>, <&cru SRST_P_UPHY1_TCPHY>; reset-names = "uphy", "uphy-pipe", "uphy-tcphy"; - rockchip,typec-conn-dir = <0xe58c 0 16>; - rockchip,usb3tousb2-en = <0xe58c 3 19>; - rockchip,external-psm = <0xe594 14 30>; - rockchip,pipe-status = <0xe5c0 16 16>; tcphy1_dp: dp-port { #phy-cells = <0>; diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.txt b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.txt new file mode 100644 index 0000000..725ae71 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.txt @@ -0,0 +1,73 @@ +STMicroelectronics STM32 USB HS PHY controller + +The STM32 USBPHYC block contains a dual port High Speed UTMI+ PHY and a UTMI +switch. It controls PHY configuration and status, and the UTMI+ switch that +selects either OTG or HOST controller for the second PHY port. It also sets +PLL configuration. + +USBPHYC + |_ PLL + | + |_ PHY port#1 _________________ HOST controller + | _ | + | / 1|________________| + |_ PHY port#2 ----| |________________ + | \_0| | + |_ UTMI switch_______| OTG controller + + +Phy provider node +================= + +Required properties: +- compatible: must be "st,stm32mp1-usbphyc" +- reg: address and length of the usb phy control register set +- clocks: phandle + clock specifier for the PLL phy clock +- #address-cells: number of address cells for phys sub-nodes, must be <1> +- #size-cells: number of size cells for phys sub-nodes, must be <0> + +Optional properties: +- assigned-clocks: phandle + clock specifier for the PLL phy clock +- assigned-clock-parents: the PLL phy clock parent +- resets: phandle + reset specifier + +Required nodes: one sub-node per port the controller provides. + +Phy sub-nodes +============== + +Required properties: +- reg: phy port index +- phy-supply: phandle to the regulator providing 3V3 power to the PHY, + see phy-bindings.txt in the same directory. +- vdda1v1-supply: phandle to the regulator providing 1V1 power to the PHY +- vdda1v8-supply: phandle to the regulator providing 1V8 power to the PHY +- #phy-cells: see phy-bindings.txt in the same directory, must be <0> for PHY + port#1 and must be <1> for PHY port#2, to select USB controller + + +Example: + usbphyc: usb-phy@5a006000 { + compatible = "st,stm32mp1-usbphyc"; + reg = <0x5a006000 0x1000>; + clocks = <&rcc_clk USBPHY_K>; + resets = <&rcc_rst USBPHY_R>; + #address-cells = <1>; + #size-cells = <0>; + + usbphyc_port0: usb-phy@0 { + reg = <0>; + phy-supply = <&vdd_usb>; + vdda1v1-supply = <®11>; + vdda1v8-supply = <®18> + #phy-cells = <0>; + }; + + usbphyc_port1: usb-phy@1 { + reg = <1>; + phy-supply = <&vdd_usb>; + vdda1v1-supply = <®11>; + vdda1v8-supply = <®18> + #phy-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt index b6a9f2b..dcf1b8f 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt @@ -8,7 +8,8 @@ Required properties: - compatible: compatible list, contains: "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074 "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, - "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996. + "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, + "qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy. - reg: offset and length of register set for PHY's common serdes block. @@ -25,10 +26,13 @@ Required properties: - clock-names: "cfg_ahb" for phy config clock, "aux" for phy aux clock, "ref" for 19.2 MHz ref clk, + "com_aux" for phy common block aux clock, For "qcom,msm8996-qmp-pcie-phy" must contain: "aux", "cfg_ahb", "ref". For "qcom,msm8996-qmp-usb3-phy" must contain: "aux", "cfg_ahb", "ref". + For "qcom,qmp-v3-usb3-phy" must contain: + "aux", "cfg_ahb", "ref", "com_aux". - resets: a list of phandles and reset controller specifier pairs, one for each entry in reset-names. diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt index aa0fcb0..42c9742 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt @@ -4,7 +4,10 @@ Qualcomm QUSB2 phy controller QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets. Required properties: - - compatible: compatible list, contains "qcom,msm8996-qusb2-phy". + - compatible: compatible list, contains + "qcom,msm8996-qusb2-phy" for 14nm PHY on msm8996, + "qcom,qusb2-v2-phy" for QUSB2 V2 PHY. + - reg: offset and length of the PHY register set. - #phy-cells: must be 0. diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt index 99b651b..dbd137c 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt @@ -8,6 +8,8 @@ Required properties: SoC. "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796 SoC. + "renesas,usb2-phy-r8a77965" if the device is a part of an + R8A77965 SoC. "renesas,usb2-phy-r8a77995" if the device is a part of an R8A77995 SoC. "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible device. diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt index f94cea4..47dd296 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt @@ -11,6 +11,8 @@ Required properties: SoC. "renesas,r8a7796-usb3-phy" if the device is a part of an R8A7796 SoC. + "renesas,r8a77965-usb3-phy" if the device is a part of an + R8A77965 SoC. "renesas,rcar-gen3-usb3-phy" for a generic R-Car Gen3 compatible device. diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt index c1ce5a0..07ca4ec 100644 --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt @@ -11,6 +11,7 @@ Required properties: * allwinner,sun8i-a33-usb-phy * allwinner,sun8i-a83t-usb-phy * allwinner,sun8i-h3-usb-phy + * allwinner,sun8i-r40-usb-phy * allwinner,sun8i-v3s-usb-phy * allwinner,sun50i-a64-usb-phy - reg : a list of offset + length pairs diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt new file mode 100644 index 0000000..fb87c7d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt @@ -0,0 +1,178 @@ +Actions Semi S900 Pin Controller + +This binding describes the pin controller found in the S900 SoC. + +Required Properties: + +- compatible: Should be "actions,s900-pinctrl" +- reg: Should contain the register base address and size of + the pin controller. +- clocks: phandle of the clock feeding the pin controller + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +Pinmux functions are available only for the pin groups while pinconf +parameters are available for both pin groups and individual pins. + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +Required Properties: + +- pins: An array of strings, each string containing the name of a pin. + These pins are used for selecting the pull control and schmitt + trigger parameters. The following are the list of pins + available: + + eth_txd0, eth_txd1, eth_txen, eth_rxer, eth_crs_dv, + eth_rxd1, eth_rxd0, eth_ref_clk, eth_mdc, eth_mdio, + sirq0, sirq1, sirq2, i2s_d0, i2s_bclk0, i2s_lrclk0, + i2s_mclk0, i2s_d1, i2s_bclk1, i2s_lrclk1, i2s_mclk1, + pcm1_in, pcm1_clk, pcm1_sync, pcm1_out, eram_a5, + eram_a6, eram_a7, eram_a8, eram_a9, eram_a10, eram_a11, + lvds_oep, lvds_oen, lvds_odp, lvds_odn, lvds_ocp, + lvds_ocn, lvds_obp, lvds_obn, lvds_oap, lvds_oan, + lvds_eep, lvds_een, lvds_edp, lvds_edn, lvds_ecp, + lvds_ecn, lvds_ebp, lvds_ebn, lvds_eap, lvds_ean, + sd0_d0, sd0_d1, sd0_d2, sd0_d3, sd1_d0, sd1_d1, + sd1_d2, sd1_d3, sd0_cmd, sd0_clk, sd1_cmd, sd1_clk, + spi0_sclk, spi0_ss, spi0_miso, spi0_mosi, uart0_rx, + uart0_tx, uart2_rx, uart2_tx, uart2_rtsb, uart2_ctsb, + uart3_rx, uart3_tx, uart3_rtsb, uart3_ctsb, uart4_rx, + uart4_tx, i2c0_sclk, i2c0_sdata, i2c1_sclk, i2c1_sdata, + i2c2_sclk, i2c2_sdata, csi0_dn0, csi0_dp0, csi0_dn1, + csi0_dp1, csi0_cn, csi0_cp, csi0_dn2, csi0_dp2, csi0_dn3, + csi0_dp3, dsi_dp3, dsi_dn3, dsi_dp1, dsi_dn1, dsi_cp, + dsi_cn, dsi_dp0, dsi_dn0, dsi_dp2, dsi_dn2, sensor0_pclk, + csi1_dn0,csi1_dp0,csi1_dn1, csi1_dp1, csi1_cn, csi1_cp, + sensor0_ckout, nand0_d0, nand0_d1, nand0_d2, nand0_d3, + nand0_d4, nand0_d5, nand0_d6, nand0_d7, nand0_dqs, + nand0_dqsn, nand0_ale, nand0_cle, nand0_ceb0, nand0_ceb1, + nand0_ceb2, nand0_ceb3, nand1_d0, nand1_d1, nand1_d2, + nand1_d3, nand1_d4, nand1_d5, nand1_d6, nand1_d7, nand1_dqs, + nand1_dqsn, nand1_ale, nand1_cle, nand1_ceb0, nand1_ceb1, + nand1_ceb2, nand1_ceb3, sgpio0, sgpio1, sgpio2, sgpio3 + +- groups: An array of strings, each string containing the name of a pin + group. These pin groups are used for selecting the pinmux + functions. + + lvds_oxx_uart4_mfp, rmii_mdc_mfp, rmii_mdio_mfp, sirq0_mfp, + sirq1_mfp, rmii_txd0_mfp, rmii_txd1_mfp, rmii_txen_mfp, + rmii_rxer_mfp, rmii_crs_dv_mfp, rmii_rxd1_mfp, rmii_rxd0_mfp, + rmii_ref_clk_mfp, i2s_d0_mfp, i2s_d1_mfp, i2s_lr_m_clk0_mfp, + i2s_bclk0_mfp, i2s_bclk1_mclk1_mfp, pcm1_in_out_mfp, + pcm1_clk_mfp, pcm1_sync_mfp, eram_a5_mfp, eram_a6_mfp, + eram_a7_mfp, eram_a8_mfp, eram_a9_mfp, eram_a10_mfp, + eram_a11_mfp, lvds_oep_odn_mfp, lvds_ocp_obn_mfp, + lvds_oap_oan_mfp, lvds_e_mfp, spi0_sclk_mosi_mfp, spi0_ss_mfp, + spi0_miso_mfp, uart2_rtsb_mfp, uart2_ctsb_mfp, uart3_rtsb_mfp, + uart3_ctsb_mfp, sd0_d0_mfp, sd0_d1_mfp, sd0_d2_d3_mfp, + sd1_d0_d3_mfp, sd0_cmd_mfp, sd0_clk_mfp, sd1_cmd_clk_mfp, + uart0_rx_mfp, nand0_d0_ceb3_mfp, uart0_tx_mfp, i2c0_mfp, + csi0_cn_cp_mfp, csi0_dn0_dp3_mfp, csi1_dn0_cp_mfp, + dsi_dp3_dn1_mfp, dsi_cp_dn0_mfp, dsi_dp2_dn2_mfp, + nand1_d0_ceb1_mfp, nand1_ceb3_mfp, nand1_ceb0_mfp, + csi1_dn0_dp0_mfp, uart4_rx_tx_mfp + + + These pin groups are used for selecting the drive strength + parameters. + + sgpio3_drv, sgpio2_drv, sgpio1_drv, sgpio0_drv, + rmii_tx_d0_d1_drv, rmii_txen_rxer_drv, rmii_crs_dv_drv, + rmii_rx_d1_d0_drv, rmii_ref_clk_drv, rmii_mdc_mdio_drv, + sirq_0_1_drv, sirq2_drv, i2s_d0_d1_drv, i2s_lr_m_clk0_drv, + i2s_blk1_mclk1_drv, pcm1_in_out_drv, lvds_oap_oan_drv, + lvds_oep_odn_drv, lvds_ocp_obn_drv, lvds_e_drv, sd0_d3_d0_drv, + sd1_d3_d0_drv, sd0_sd1_cmd_clk_drv, spi0_sclk_mosi_drv, + spi0_ss_miso_drv, uart0_rx_tx_drv, uart4_rx_tx_drv, uart2_drv, + uart3_drv, i2c0_drv, i2c1_drv, i2c2_drv, sensor0_drv + + These pin groups are used for selecting the slew rate + parameters. + + sgpio3_sr, sgpio2_sr, sgpio1_sr, sgpio0_sr, rmii_tx_d0_d1_sr, + rmii_txen_rxer_sr, rmii_crs_dv_sr, rmii_rx_d1_d0_sr, + rmii_ref_clk_sr, rmii_mdc_mdio_sr, sirq_0_1_sr, sirq2_sr, + i2s_do_d1_sr, i2s_lr_m_clk0_sr, i2s_bclk0_mclk1_sr, + pcm1_in_out_sr, sd1_d3_d0_sr, sd0_sd1_clk_cmd_sr, + spi0_sclk_mosi_sr, spi0_ss_miso_sr, uart0_rx_tx_sr, + uart4_rx_tx_sr, uart2_sr, uart3_sr, i2c0_sr, i2c1_sr, i2c2_sr, + sensor0_sr + +- function: An array of strings, each string containing the name of the + pinmux functions. These functions can only be selected by + the corresponding pin groups. The following are the list of + pinmux functions available: + + eram, eth_rmii, eth_smii, spi0, spi1, spi2, spi3, sens0, + uart0, uart1, uart2, uart3, uart4, uart5, uart6, i2s0, i2s1, + pcm0, pcm1, jtag, pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, sd0, + sd1, sd2, sd3, i2c0, i2c1, i2c2, i2c3, i2c4, i2c5, lvds, + usb30, usb20, gpu, mipi_csi0, mipi_csi1, mipi_dsi, nand0, + nand1, spdif, sirq0, sirq1, sirq2 + +Optional Properties: + +- bias-bus-hold: No arguments. The specified pins should retain the previous + state value. +- bias-high-impedance: No arguments. The specified pins should be configured + as high impedance. +- bias-pull-down: No arguments. The specified pins should be configured as + pull down. +- bias-pull-up: No arguments. The specified pins should be configured as + pull up. +- input-schmitt-enable: No arguments: Enable schmitt trigger for the specified + pins +- input-schmitt-disable: No arguments: Disable schmitt trigger for the specified + pins +- slew-rate: Integer. Sets slew rate for the specified pins. + Valid values are: + <0> - Slow + <1> - Fast +- drive-strength: Integer. Selects the drive strength for the specified + pins in mA. + Valid values are: + <2> + <4> + <8> + <12> + +Example: + + pinctrl: pinctrl@e01b0000 { + compatible = "actions,s900-pinctrl"; + reg = <0x0 0xe01b0000 0x0 0x1000>; + clocks = <&cmu CLK_GPIO>; + + uart2-default: uart2-default { + pinmux { + groups = "lvds_oep_odn_mfp"; + function = "uart2"; + }; + pinconf { + groups = "lvds_oep_odn_drv"; + drive-strength = <12>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt index 09789fd..ed5eb54 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt @@ -27,6 +27,7 @@ Required properties: "allwinner,sun50i-a64-pinctrl" "allwinner,sun50i-a64-r-pinctrl" "allwinner,sun50i-h5-pinctrl" + "allwinner,sun50i-h6-pinctrl" "nextthing,gr8-pinctrl" - reg: Should contain the register physical address and length for the diff --git a/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt index 47284f8..678f509 100644 --- a/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt @@ -19,8 +19,10 @@ Required subnode-properties: Available functions and groups (function: group0, group1...): gpio: cpuclkoutgrp0, udlclkoutgrp0, i2c1grp0, i2c2grp0, i2c3grp0, i2s0grp0, i2s1grp0, i2srefclkgrp0, spi0grp0, - spi1grp0, pciedebuggrp0, uart0grp0, uart0grp1, uart1grp0, - uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0 + spi1grp0, pciedebuggrp0, uart0grp0, uart0grp1, uart0grp2, + uart1grp0, uart1grp1, uart2grp0, uart2grp1, uart2grp2, + uart3grp0, uart4grp0, uart4grp1, uart5grp0, uart5grp1, + uart5nocts cpuclkout: cpuclkoutgrp0 udlclkout: udlclkoutgrp0 i2c1: i2c1grp0 @@ -32,12 +34,12 @@ Required subnode-properties: spi0: spi0grp0 spi1: spi1grp0 pciedebug: pciedebuggrp0 - uart0: uart0grp0, uart0grp1 - uart1: uart1grp0 - uart2: uart2grp0, uart2grp1 + uart0: uart0grp0, uart0grp1, uart0grp2 + uart1: uart1grp0, uart1grp1 + uart2: uart2grp0, uart2grp1, uart2grp2 uart3: uart3grp0 - uart4: uart4grp0 - uart5: uart5grp0 + uart4: uart4grp0, uart4grp1 + uart5: uart5grp0, uart5grp1, uart5nocts nand: nandgrp0 sdio0: sdio0grp0 sdio1: sdio1grp0 diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt new file mode 100644 index 0000000..175e893 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt @@ -0,0 +1,40 @@ +* Freescale i.MX6 SLL IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,imx6sll-iomuxc" +- fsl,pins: each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val + input_val> are specified using a PIN_FUNC_ID macro, which can be found in + imx6sll-pinfunc.h under device tree source folder. The last integer CONFIG is + the pad setting value like pull-up on this pin. Please refer to i.MX6SLL + Reference Manual for detailed CONFIG settings. + +CONFIG bits definition: +PAD_CTL_LVE (1 << 22) +PAD_CTL_HYS (1 << 16) +PAD_CTL_PUS_100K_DOWN (0 << 14) +PAD_CTL_PUS_47K_UP (1 << 14) +PAD_CTL_PUS_100K_UP (2 << 14) +PAD_CTL_PUS_22K_UP (3 << 14) +PAD_CTL_PUE (1 << 13) +PAD_CTL_PKE (1 << 12) +PAD_CTL_ODE (1 << 11) +PAD_CTL_SPEED_LOW (0 << 6) +PAD_CTL_SPEED_MED (1 << 6) +PAD_CTL_SPEED_HIGH (3 << 6) +PAD_CTL_DSE_DISABLE (0 << 3) +PAD_CTL_DSE_260ohm (1 << 3) +PAD_CTL_DSE_130ohm (2 << 3) +PAD_CTL_DSE_87ohm (3 << 3) +PAD_CTL_DSE_65ohm (4 << 3) +PAD_CTL_DSE_52ohm (5 << 3) +PAD_CTL_DSE_43ohm (6 << 3) +PAD_CTL_DSE_37ohm (7 << 3) +PAD_CTL_SRE_FAST (1 << 0) +PAD_CTL_SRE_SLOW (0 << 0) + +Refer to imx6sll-pinfunc.h in device tree source folder for all available +imx6sll PIN_FUNC_ID. diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt deleted file mode 100644 index cf9ccdf..0000000 --- a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt +++ /dev/null @@ -1,127 +0,0 @@ -ImgTec TZ1090 PDC pin controller - -Required properties: -- compatible: "img,tz1090-pdc-pinctrl" -- reg: Should contain the register physical address and length of the - SOC_GPIO_CONTROL registers in the PDC register region. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -TZ1090-PDC's pin configuration nodes act as a container for an arbitrary number -of subnodes. Each of these subnodes represents some desired configuration for a -pin, a group, or a list of pins or groups. This configuration can include the -mux function to select on those pin(s)/group(s), and various pin configuration -parameters, such as pull-up, drive strength, etc. - -The name of each subnode is not important; all subnodes should be enumerated -and processed purely based on their content. - -Each subnode only affects those parameters that are explicitly listed. In -other words, a subnode that lists a mux function but no pin configuration -parameters implies no information about any pin configuration parameters. -Similarly, a pin subnode that describes a pullup parameter implies no -information about e.g. the mux function. For this reason, even seemingly boolean -values are actually tristates in this binding: unspecified, off, or on. -Unspecified is represented as an absent property, and off/on are represented as -integer values 0 and 1. - -Required subnode-properties: -- tz1090,pins : An array of strings. Each string contains the name of a pin or - group. Valid values for these names are listed below. - -Optional subnode-properties: -- tz1090,function: A string containing the name of the function to mux to the - pin or group. Valid values for function names are listed below, including - which pingroups can be muxed to them. -- supported generic pinconfig properties (for further details see - Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt): - - bias-disable - - bias-high-impedance - - bias-bus-hold - - bias-pull-up - - bias-pull-down - - input-schmitt-enable - - input-schmitt-disable - - drive-strength: Integer, control drive strength of pins in mA. - 2: 2mA - 4: 4mA - 8: 8mA - 12: 12mA - - low-power-enable: Flag, power-on-start weak pull-down for invalid power. - - low-power-disable: Flag, power-on-start weak pull-down disabled. - -Note that many of these properties are only valid for certain specific pins -or groups. See the TZ1090 TRM for complete details regarding which groups -support which functionality. The Linux pinctrl driver may also be a useful -reference. - -Valid values for pin and group names are: - - pins: - - These all support bias-high-impediance, bias-pull-up, bias-pull-down, and - bias-bus-hold (which can also be provided to any of the groups below to set - it for all gpio pins in that group). - - gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data, ext_power. - - mux groups: - - These all support function. - - gpio0 - pins: gpio0. - function: ir_mod_stable_out. - gpio1 - pins: gpio1. - function: ir_mod_power_out. - - drive groups: - - These support input-schmitt-enable, input-schmitt-disable, - drive-strength, low-power-enable, and low-power-disable. - - pdc - pins: gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data, - ext_power. - -Example: - - pinctrl_pdc: pinctrl@2006500 { - #gpio-range-cells = <3>; - compatible = "img,tz1090-pdc-pinctrl"; - reg = <0x02006500 0x100>; - }; - -Example board file extracts: - - &pinctrl_pdc { - pinctrl-names = "default"; - pinctrl-0 = <&syswake_default>; - - syswake_default: syswakes { - syswake_cfg { - tz1090,pins = "sys_wake0", - "sys_wake1", - "sys_wake2"; - pull-up; - }; - }; - irmod_default: irmod { - gpio0_cfg { - tz1090,pins = "gpio0"; - tz1090,function = "ir_mod_stable_out"; - }; - gpio1_cfg { - tz1090,pins = "gpio1"; - tz1090,function = "ir_mod_power_out"; - }; - }; - }; - - ir: ir@2006200 { - pinctrl-names = "default"; - pinctrl-0 = <&irmod_default>; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt deleted file mode 100644 index 2dfd9a3..0000000 --- a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt +++ /dev/null @@ -1,227 +0,0 @@ -ImgTec TZ1090 pin controller - -Required properties: -- compatible: "img,tz1090-pinctrl" -- reg: Should contain the register physical address and length of the pad - configuration registers (CR_PADS_* and CR_IF_CTL0). - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -TZ1090's pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin, a group, or a list of pins or groups. This configuration can include the -mux function to select on those pin(s)/group(s), and various pin configuration -parameters, such as pull-up, drive strength, etc. - -The name of each subnode is not important; all subnodes should be enumerated -and processed purely based on their content. - -Each subnode only affects those parameters that are explicitly listed. In -other words, a subnode that lists a mux function but no pin configuration -parameters implies no information about any pin configuration parameters. -Similarly, a pin subnode that describes a pullup parameter implies no -information about e.g. the mux function. For this reason, even seemingly boolean -values are actually tristates in this binding: unspecified, off, or on. -Unspecified is represented as an absent property, and off/on are represented as -integer values 0 and 1. - -Required subnode-properties: -- tz1090,pins : An array of strings. Each string contains the name of a pin or - group. Valid values for these names are listed below. - -Optional subnode-properties: -- tz1090,function: A string containing the name of the function to mux to the - pin or group. Valid values for function names are listed below, including - which pingroups can be muxed to them. -- supported generic pinconfig properties (for further details see - Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt): - - bias-disable - - bias-high-impedance - - bias-bus-hold - - bias-pull-up - - bias-pull-down - - input-schmitt-enable - - input-schmitt-disable - - drive-strength: Integer, control drive strength of pins in mA. - 2: 2mA - 4: 4mA - 8: 8mA - 12: 12mA - - -Note that many of these properties are only valid for certain specific pins -or groups. See the TZ1090 TRM for complete details regarding which groups -support which functionality. The Linux pinctrl driver may also be a useful -reference. - -Valid values for pin and group names are: - - gpio pins: - - These all support bias-high-impediance, bias-pull-up, bias-pull-down, and - bias-bus-hold (which can also be provided to any of the groups below to set - it for all pins in that group). - - They also all support the some form of muxing. Any pins which are contained - in one of the mux groups (see below) can be muxed only to the functions - supported by the mux group. All other pins can be muxed to the "perip" - function which enables them with their intended peripheral. - - Different pins in the same mux group cannot be muxed to different functions, - however it is possible to mux only a subset of the pins in a mux group to a - particular function and leave the remaining pins unmuxed. This is useful if - the board connects certain pins in a group to other devices to be controlled - by GPIO, and you don't want the usual peripheral to have any control of the - pin. - - ant_sel0, ant_sel1, gain0, gain1, gain2, gain3, gain4, gain5, gain6, gain7, - i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, i2s_lrclk_out, - i2s_mclk, pa_on, pdm_a, pdm_b, pdm_c, pdm_d, pll_on, rx_hp, rx_on, - scb0_sclk, scb0_sdat, scb1_sclk, scb1_sdat, scb2_sclk, scb2_sdat, sdh_cd, - sdh_clk_in, sdh_wp, sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3, - spi0_cs0, spi0_cs1, spi0_cs2, spi0_din, spi0_dout, spi0_mclk, spi1_cs0, - spi1_cs1, spi1_cs2, spi1_din, spi1_dout, spi1_mclk, tft_blank_ls, tft_blue0, - tft_blue1, tft_blue2, tft_blue3, tft_blue4, tft_blue5, tft_blue6, tft_blue7, - tft_green0, tft_green1, tft_green2, tft_green3, tft_green4, tft_green5, - tft_green6, tft_green7, tft_hsync_nr, tft_panelclk, tft_pwrsave, tft_red0, - tft_red1, tft_red2, tft_red3, tft_red4, tft_red5, tft_red6, tft_red7, - tft_vd12acb, tft_vdden_gd, tft_vsync_ns, tx_on, uart0_cts, uart0_rts, - uart0_rxd, uart0_txd, uart1_rxd, uart1_txd. - - bias-high-impediance: supported. - bias-pull-up: supported. - bias-pull-down: supported. - bias-bus-hold: supported. - function: perip or those supported by pin's mux group. - - other pins: - - These other pins are part of various pin groups below, but can't be - controlled as GPIOs. They do however support bias-high-impediance, - bias-pull-up, bias-pull-down, and bias-bus-hold (which can also be provided - to any of the groups below to set it for all pins in that group). - - clk_out0, clk_out1, tck, tdi, tdo, tms, trst. - - bias-high-impediance: supported. - bias-pull-up: supported. - bias-pull-down: supported. - bias-bus-hold: supported. - - mux groups: - - These all support function, and some support drive configs. - - afe - pins: tx_on, rx_on, pll_on, pa_on, rx_hp, ant_sel0, - ant_sel1, gain0, gain1, gain2, gain3, gain4, - gain5, gain6, gain7. - function: afe, ts_out_0. - input-schmitt-enable: supported. - input-schmitt-disable: supported. - drive-strength: supported. - pdm_d - pins: pdm_d. - function: pdm_dac, usb_vbus. - sdh - pins: sdh_cd, sdh_wp, sdh_clk_in. - function: sdh, sdio. - sdio - pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, - sdio_d3. - function: sdio, sdh. - spi1_cs2 - pins: spi1_cs2. - function: spi1_cs2, usb_vbus. - tft - pins: tft_red0, tft_red1, tft_red2, tft_red3, - tft_red4, tft_red5, tft_red6, tft_red7, - tft_green0, tft_green1, tft_green2, tft_green3, - tft_green4, tft_green5, tft_green6, tft_green7, - tft_blue0, tft_blue1, tft_blue2, tft_blue3, - tft_blue4, tft_blue5, tft_blue6, tft_blue7, - tft_vdden_gd, tft_panelclk, tft_blank_ls, - tft_vsync_ns, tft_hsync_nr, tft_vd12acb, - tft_pwrsave. - function: tft, ext_dac, not_iqadc_stb, iqdac_stb, ts_out_1, - lcd_trace, phy_ringosc. - input-schmitt-enable: supported. - input-schmitt-disable: supported. - drive-strength: supported. - - drive groups: - - These all support input-schmitt-enable, input-schmitt-disable, - and drive-strength. - - jtag - pins: tck, trst, tdi, tdo, tms. - scb1 - pins: scb1_sdat, scb1_sclk. - scb2 - pins: scb2_sdat, scb2_sclk. - spi0 - pins: spi0_mclk, spi0_cs0, spi0_cs1, spi0_cs2, spi0_dout, spi0_din. - spi1 - pins: spi1_mclk, spi1_cs0, spi1_cs1, spi1_cs2, spi1_dout, spi1_din. - uart - pins: uart0_txd, uart0_rxd, uart0_rts, uart0_cts, - uart1_txd, uart1_rxd. - drive_i2s - pins: clk_out1, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, - i2s_lrclk_out, i2s_bclk_out, i2s_mclk. - drive_pdm - pins: clk_out0, pdm_b, pdm_a. - drive_scb0 - pins: scb0_sclk, scb0_sdat, pdm_d, pdm_c. - drive_sdio - pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3, - sdh_wp, sdh_cd, sdh_clk_in. - - convenience groups: - - These are just convenient groupings of pins and don't support any drive - configs. - - uart0 - pins: uart0_cts, uart0_rts, uart0_rxd, uart0_txd. - uart1 - pins: uart1_rxd, uart1_txd. - scb0 - pins: scb0_sclk, scb0_sdat. - i2s - pins: i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, - i2s_lrclk_out, i2s_mclk. - -Example: - - pinctrl: pinctrl@2005800 { - #gpio-range-cells = <3>; - compatible = "img,tz1090-pinctrl"; - reg = <0x02005800 0xe4>; - }; - -Example board file extract: - - &pinctrl { - uart0_default: uart0 { - uart0_cfg { - tz1090,pins = "uart0_rxd", - "uart0_txd"; - tz1090,function = "perip"; - }; - }; - tft_default: tft { - tft_cfg { - tz1090,pins = "tft"; - tz1090,function = "tft"; - }; - }; - }; - - uart@2004b00 { - pinctrl-names = "default"; - pinctrl-0 = <&uart0_default>; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt index 9c451c2..a5a8322 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt @@ -45,6 +45,8 @@ Optional properties: - first cell is the pin number - second cell is used to specify flags. - interrupt-controller: Marks the device node as a interrupt controller. +- drive-open-drain: Sets the ODR flag in the IOCON register. This configures + the IRQ output as open drain active low. Optional device specific properties: - microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt index afa8a18..e7d6f81 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt @@ -76,12 +76,12 @@ Examples: ... { - syscfg_pctl_a: syscfg_pctl_a@10005000 { + syscfg_pctl_a: syscfg-pctl-a@10005000 { compatible = "mediatek,mt8135-pctl-a-syscfg", "syscon"; reg = <0 0x10005000 0 0x1000>; }; - syscfg_pctl_b: syscfg_pctl_b@1020c020 { + syscfg_pctl_b: syscfg-pctl-b@1020c020 { compatible = "mediatek,mt8135-pctl-b-syscfg", "syscon"; reg = <0 0x1020C020 0 0x1000>; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt new file mode 100644 index 0000000..665aadb --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt @@ -0,0 +1,176 @@ +Qualcomm SDM845 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +SDM845 platform. + +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,sdm845-pinctrl" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: <none> + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/interrupt-controller/irq.h> + +- gpio-controller: + Usage: required + Value type: <none> + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/gpio/gpio.h> + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. + + Valid pins are: + gpio0-gpio149 + Supports mux, bias and drive-strength + + sdc2_clk, sdc2_cmd, sdc2_data + Supports bias and drive-strength + +- function: + Usage: required + Value type: <string> + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + gpio, adsp_ext, agera_pll, atest_char, atest_tsens, + atest_tsens2, atest_usb1, atest_usb10, atest_usb11, + atest_usb12, atest_usb13, atest_usb2, atest_usb20, + atest_usb21, atest_usb22, atest_usb23, audio_ref, + btfm_slimbus, cam_mclk, cci_async, cci_i2c, cci_timer0, + cci_timer1, cci_timer2, cci_timer3, cci_timer4, cri_trng, + cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, + ddr_pxi1, ddr_pxi2, ddr_pxi3, edp_hot, edp_lcd, gcc_gp1, + gcc_gp2, gcc_gp3, jitter_bist, ldo_en, ldo_update, + lpass_slimbus, m_voc, mdp_vsync, mdp_vsync0, mdp_vsync1, + mdp_vsync2, mdp_vsync3, mss_lte, nav_pps, pa_indicator, + pci_e0, pci_e1, phase_flag, pll_bist, pll_bypassnl, + pll_reset, pri_mi2s, pri_mi2s_ws, prng_rosc, qdss_cti, + qdss, qlink_enable, qlink_request, qua_mi2s, qup0, qup1, + qup10, qup11, qup12, qup13, qup14, qup15, qup2, qup3, qup4, + qup5, qup6, qup7, qup8, qup9, qup_l4, qup_l5, qup_l6, + qspi_clk, qspi_cs, qspi_data, sd_write, sdc4_clk, sdc4_cmd, + sdc4_data, sec_mi2s, sp_cmu, spkr_i2s, ter_mi2s, tgu_ch0, + tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1, tsense_pwm2, + tsif1_clk, tsif1_data, tsif1_en, tsif1_error, tsif1_sync, + tsif2_clk, tsif2_data, tsif2_en, tsif2_error, tsif2_sync, + uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, + uim2_data, uim2_present, uim2_reset, uim_batt, usb_phy, + vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, + wlan2_adc1, + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull down. + +- bias-pull-up: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull up. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + Not valid for sdc pins. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + Not valid for sdc pins. + +- drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins, in mA. + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 + +Example: + + tlmm: pinctrl@3400000 { + compatible = "qcom,sdm845-pinctrl"; + reg = <0x03400000 0xc00000>; + interrupts = <GIC_SPI 208 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + + qup9_active: qup9-active { + mux { + pins = "gpio4", "gpio5"; + function = "qup9"; + }; + + config { + pins = "gpio4", "gpio5"; + drive-strength = <2>; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt index bb1790e..892d8fd 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt @@ -15,7 +15,7 @@ Required Properties: - "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller. - "renesas,pfc-r8a7743": for R8A7743 (RZ/G1M) compatible pin-controller. - "renesas,pfc-r8a7745": for R8A7745 (RZ/G1E) compatible pin-controller. - - "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller. + - "renesas,pfc-r8a7778": for R8A7778 (R-Car M1) compatible pin-controller. - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller. - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller. - "renesas,pfc-r8a7791": for R8A7791 (R-Car M2-W) compatible pin-controller. @@ -24,7 +24,9 @@ Required Properties: - "renesas,pfc-r8a7794": for R8A7794 (R-Car E2) compatible pin-controller. - "renesas,pfc-r8a7795": for R8A7795 (R-Car H3) compatible pin-controller. - "renesas,pfc-r8a7796": for R8A7796 (R-Car M3-W) compatible pin-controller. + - "renesas,pfc-r8a77965": for R8A77965 (R-Car M3-N) compatible pin-controller. - "renesas,pfc-r8a77970": for R8A77970 (R-Car V3M) compatible pin-controller. + - "renesas,pfc-r8a77980": for R8A77980 (R-Car V3H) compatible pin-controller. - "renesas,pfc-r8a77995": for R8A77995 (R-Car D3) compatible pin-controller. - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. diff --git a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt index e62d53d..6d8980c 100644 --- a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt +++ b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt @@ -27,10 +27,13 @@ Optional properties: it to an output when the power-off handler is called. If this optional property is not specified, the GPIO is initialized as an output in its inactive state. +- timeout-ms: Time to wait before asserting a WARN_ON(1). If nothing is + specified, 3000 ms is used. Examples: gpio-poweroff { compatible = "gpio-poweroff"; gpios = <&gpio 4 0>; + timeout-ms = <3000>; }; diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt new file mode 100644 index 0000000..1b4213e --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt @@ -0,0 +1,14 @@ +Microsemi Ocelot reset controller + +The DEVCPU_GCB:CHIP_REGS have a SOFT_RST register that can be used to reset the +SoC MIPS core. + +Required Properties: + - compatible: "mscc,ocelot-chip-reset" + +Example: + reset@1070008 { + compatible = "mscc,ocelot-chip-reset"; + reg = <0x1070008 0x4>; + }; + diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt index c248866..41916f6 100644 --- a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt +++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt @@ -4,12 +4,12 @@ Required Properties: - compatible, one of: "x-powers,axp209-battery-power-supply" "x-powers,axp221-battery-power-supply" + "x-powers,axp813-battery-power-supply" -This node is a subnode of the axp20x/axp22x PMIC. +This node is a subnode of its respective PMIC DT node. -The AXP20X and AXP22X can read the battery voltage, charge and discharge -currents of the battery by reading ADC channels from the AXP20X/AXP22X -ADC. +The supported devices can read the battery voltage, charge and discharge +currents of the battery by reading ADC channels from the ADC. Example: diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt index 36afa32..a3dc4b9 100644 --- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt +++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt @@ -152,14 +152,7 @@ Nintendo Wii device tree 1.l) The General Purpose I/O (GPIO) controller node - Represents the dual access 32 GPIO controller interface. - - Required properties: - - - #gpio-cells : <2> - - compatible : should be "nintendo,hollywood-gpio" - - reg : should contain the IPC registers location and length - - gpio-controller + see Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt 1.m) The control node diff --git a/Documentation/devicetree/bindings/regulator/88pg86x.txt b/Documentation/devicetree/bindings/regulator/88pg86x.txt new file mode 100644 index 0000000..13b7f49 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/88pg86x.txt @@ -0,0 +1,22 @@ +Marvell 88PG867/88PG868 voltage regulators + +Required properties: +- compatible: one of "marvell,88pg867", "marvell,88pg868"; +- reg: I2C slave address. + +Optional subnodes for regulators: "buck1", "buck2", using common regulator +bindings given in <Documentation/devicetree/bindings/regulator/regulator.txt>. + +Example: + + pg868@19 { + compatible = "marvell,88pg868"; + reg = <0x19>; + + vcpu: buck1 { + regulator-boot-on; + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1350000>; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt index 4fae41d..0c2a6c8 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt @@ -2,6 +2,7 @@ Fixed Voltage regulators Required properties: - compatible: Must be "regulator-fixed"; +- regulator-name: Defined in regulator.txt as optional, but required here. Optional properties: - gpio: gpio to use for enable control diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt index dd1ed78..1f49615 100644 --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt @@ -2,6 +2,8 @@ GPIO controlled regulators Required properties: - compatible : Must be "regulator-gpio". +- regulator-name : Defined in regulator.txt as optional, but required + here. - states : Selection of available voltages and GPIO configs. if there are no states, then use a fixed regulator diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt index 4e3dfb5..58a1d97 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt @@ -23,7 +23,9 @@ Regulator nodes are identified by their compatible: "qcom,rpm-pm8916-regulators" "qcom,rpm-pm8941-regulators" "qcom,rpm-pm8994-regulators" + "qcom,rpm-pm8998-regulators" "qcom,rpm-pma8084-regulators" + "qcom,rpm-pmi8998-regulators" - vdd_s1-supply: - vdd_s2-supply: @@ -131,6 +133,38 @@ Regulator nodes are identified by their compatible: - vdd_s10-supply: - vdd_s11-supply: - vdd_s12-supply: +- vdd_s13-supply: +- vdd_l1_l27-supply: +- vdd_l20_l24-supply: +- vdd_l26-supply: +- vdd_l2_l8_l17-supply: +- vdd_l3_l11-supply: +- vdd_l4_l5-supply: +- vdd_l6-supply: +- vdd_l7_l12_l14_l15-supply: +- vdd_l9-supply: +- vdd_l10_l23_l25-supply: +- vdd_l13_l19_l21-supply: +- vdd_l16_l28-supply: +- vdd_l18_l22-supply: +- vdd_lvs1_lvs2-supply: + Usage: optional (pmi8998 only) + Value type: <phandle> + Definition: reference to regulator supplying the input pin, as + described in the data sheet + +- vdd_s1-supply: +- vdd_s2-supply: +- vdd_s3-supply: +- vdd_s4-supply: +- vdd_s5-supply: +- vdd_s6-supply: +- vdd_s7-supply: +- vdd_s8-supply: +- vdd_s9-supply: +- vdd_s10-supply: +- vdd_s11-supply: +- vdd_s12-supply: - vdd_l1_l11-supply: - vdd_l2_l3_l4_l27-supply: - vdd_l5_l7-supply: @@ -148,6 +182,12 @@ Regulator nodes are identified by their compatible: Definition: reference to regulator supplying the input pin, as described in the data sheet +- vdd_bob-supply: + Usage: optional (pmi8998 only) + Value type: <phandle> + Definition: reference to regulator supplying the input pin, as + described in the data sheet + The regulator node houses sub-nodes for each regulator within the device. Each sub-node is identified using the node's name, with valid values listed for each of the pmics below. @@ -169,11 +209,19 @@ pm8994: l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, lvs1, lvs2 +pm8998: + s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, l1, l2, l3, l4, + l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, + l20, l21, l22, l23, l24, l25, l26, l27, l28, lvs1, lvs2 + pma8084: s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1 +pmi8998: + bob + The content of each sub-node is defined by the standard binding for regulators - see regulator.txt. diff --git a/Documentation/devicetree/bindings/rng/imx-rngc.txt b/Documentation/devicetree/bindings/rng/imx-rng.txt index 93c7174..405c2b0 100644 --- a/Documentation/devicetree/bindings/rng/imx-rngc.txt +++ b/Documentation/devicetree/bindings/rng/imx-rng.txt @@ -1,15 +1,14 @@ -Freescale RNGC (Random Number Generator Version C) - -The driver also supports version B, which is mostly compatible -to version C. +Freescale RNGA/RNGB/RNGC (Random Number Generator Versions A, B and C) Required properties: - compatible : should be one of + "fsl,imx21-rnga" + "fsl,imx31-rnga" (backward compatible with "fsl,imx21-rnga") "fsl,imx25-rngb" "fsl,imx35-rngc" - reg : offset and length of the register set of this block -- interrupts : the interrupt number for the RNGC block -- clocks : the RNGC clk source +- interrupts : the interrupt number for the RNG block +- clocks : the RNG clk source Example: diff --git a/Documentation/devicetree/bindings/rng/ks-sa-rng.txt b/Documentation/devicetree/bindings/rng/ks-sa-rng.txt new file mode 100644 index 0000000..b7a65b4 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/ks-sa-rng.txt @@ -0,0 +1,21 @@ +Keystone SoC Hardware Random Number Generator(HWRNG) Module + +On Keystone SoCs HWRNG module is a submodule of the Security Accelerator. + +- compatible: should be "ti,keystone-rng" +- ti,syscon-sa-cfg: phandle to syscon node of the SA configuration registers. + This registers are shared between hwrng and crypto drivers. +- clocks: phandle to the reference clocks for the subsystem +- clock-names: functional clock name. Should be set to "fck" +- reg: HWRNG module register space + +Example: +/* K2HK */ + +rng@24000 { + compatible = "ti,keystone-rng"; + ti,syscon-sa-cfg = <&sa_config>; + clocks = <&clksa>; + clock-names = "fck"; + reg = <0x24000 0x1000>; +}; diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt b/Documentation/devicetree/bindings/rng/omap_rng.txt index 9cf7876..ea434ce 100644 --- a/Documentation/devicetree/bindings/rng/omap_rng.txt +++ b/Documentation/devicetree/bindings/rng/omap_rng.txt @@ -13,7 +13,12 @@ Required properties: - interrupts : the interrupt number for the RNG module. Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76" - clocks: the trng clock source. Only mandatory for the - "inside-secure,safexcel-eip76" compatible. + "inside-secure,safexcel-eip76" compatible, the second clock is + needed for the Armada 7K/8K SoCs +- clock-names: mandatory if there is a second clock, in this case the + name must be "core" for the first clock and "reg" for the second + one + Example: /* AM335x */ diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.txt b/Documentation/devicetree/bindings/rng/st,stm32-rng.txt index 47f0417..1dfa7d5 100644 --- a/Documentation/devicetree/bindings/rng/st,stm32-rng.txt +++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.txt @@ -11,6 +11,10 @@ Required properties: - interrupts : The designated IRQ line for the RNG - clocks : The clock needed to enable the RNG +Optional properties: +- resets : The reset to properly start RNG +- clock-error-detect : Enable the clock detection management + Example: rng: rng@50060800 { diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt index dad3b2e..aeb6db4 100644 --- a/Documentation/devicetree/bindings/serial/8250.txt +++ b/Documentation/devicetree/bindings/serial/8250.txt @@ -24,6 +24,7 @@ Required properties: - "ti,da830-uart" - "aspeed,ast2400-vuart" - "aspeed,ast2500-vuart" + - "nuvoton,npcm750-uart" - "serial" if the port type is unknown. - reg : offset and length of the register set for the device. - interrupts : should contain uart interrupt. diff --git a/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt b/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt deleted file mode 100644 index 048c381..0000000 --- a/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt +++ /dev/null @@ -1,22 +0,0 @@ -ETRAX FS UART - -Required properties: -- compatible : "axis,etraxfs-uart" -- reg: offset and length of the register set for the device. -- interrupts: device interrupt - -Optional properties: -- {dtr,dsr,rng,dcd}-gpios: specify a GPIO for DTR/DSR/RI/DCD - line respectively. - -Example: - -serial@b00260000 { - compatible = "axis,etraxfs-uart"; - reg = <0xb0026000 0x1000>; - interrupts = <68>; - dtr-gpios = <&sysgpio 0 GPIO_ACTIVE_LOW>; - dsr-gpios = <&sysgpio 1 GPIO_ACTIVE_LOW>; - rng-gpios = <&sysgpio 2 GPIO_ACTIVE_LOW>; - dcd-gpios = <&sysgpio 3 GPIO_ACTIVE_LOW>; -}; diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index cf504d0..ad962f4 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -43,6 +43,8 @@ Required properties: - "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART. - "renesas,scif-r8a77970" for R8A77970 (R-Car V3M) SCIF compatible UART. - "renesas,hscif-r8a77970" for R8A77970 (R-Car V3M) HSCIF compatible UART. + - "renesas,scif-r8a77980" for R8A77980 (R-Car V3H) SCIF compatible UART. + - "renesas,hscif-r8a77980" for R8A77980 (R-Car V3H) HSCIF compatible UART. - "renesas,scif-r8a77995" for R8A77995 (R-Car D3) SCIF compatible UART. - "renesas,hscif-r8a77995" for R8A77995 (R-Car D3) HSCIF compatible UART. - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt index d150b04..9d3efed 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt @@ -15,6 +15,8 @@ Required properties: Optional properties: - pinctrl: The reference on the pins configuration - st,hw-flow-ctrl: bool flag to enable hardware flow control. +- rs485-rts-delay, rs485-rx-during-tx, rs485-rts-active-low, + linux,rs485-enabled-at-boot-time: see rs485.txt. - dmas: phandle(s) to DMA controller node(s). Refer to stm32-dma.txt - dma-names: "rx" and/or "tx" diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt new file mode 100644 index 0000000..8dd7b3a --- /dev/null +++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt @@ -0,0 +1,16 @@ +Broadcom VCHIQ firmware services + +Required properties: + +- compatible: Should be "brcm,bcm2835-vchiq" +- reg: Physical base address and length of the doorbell register pair +- interrupts: The interrupt number + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt + +Example: + +mailbox@7e00b840 { + compatible = "brcm,bcm2835-vchiq"; + reg = <0x7e00b840 0xf>; + interrupts = <0 2>; +}; diff --git a/Documentation/devicetree/bindings/sound/ak4458.txt b/Documentation/devicetree/bindings/sound/ak4458.txt new file mode 100644 index 0000000..7839be7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak4458.txt @@ -0,0 +1,23 @@ +AK4458 audio DAC + +This device supports I2C mode. + +Required properties: + +- compatible : "asahi-kasei,ak4458" +- reg : The I2C address of the device for I2C + +Optional properties: +- reset-gpios: A GPIO specifier for the power down & reset pin +- mute-gpios: A GPIO specifier for the soft mute pin + +Example: + +&i2c { + ak4458: dac@10 { + compatible = "asahi-kasei,ak4458"; + reg = <0x10>; + reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW> + mute-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH> + }; +}; diff --git a/Documentation/devicetree/bindings/sound/ak5558.txt b/Documentation/devicetree/bindings/sound/ak5558.txt new file mode 100644 index 0000000..7d67ca6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak5558.txt @@ -0,0 +1,22 @@ +AK5558 8 channel differential 32-bit delta-sigma ADC + +This device supports I2C mode only. + +Required properties: + +- compatible : "asahi-kasei,ak5558" +- reg : The I2C address of the device. + +Optional properties: + +- reset-gpios: A GPIO specifier for the power down & reset pin. + +Example: + +&i2c { + ak5558: adc@10 { + compatible = "asahi-kasei,ak5558"; + reg = <0x10>; + reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; + }; +}; diff --git a/Documentation/devicetree/bindings/sound/da7219.txt b/Documentation/devicetree/bindings/sound/da7219.txt index 5b54d2d..c3df92d 100644 --- a/Documentation/devicetree/bindings/sound/da7219.txt +++ b/Documentation/devicetree/bindings/sound/da7219.txt @@ -25,6 +25,9 @@ Optional properties: interrupt is to be used to wake system, otherwise "irq" should be used. - wakeup-source: Flag to indicate this device can wake system (suspend/resume). +- #clock-cells : Should be set to '<0>', only one clock source provided; +- clock-output-names : Name given for DAI clocks output; + - clocks : phandle and clock specifier for codec MCLK. - clock-names : Clock name string for 'clocks' attribute, should be "mclk". @@ -83,6 +86,9 @@ Example: VDDMIC-supply = <®_audio>; VDDIO-supply = <®_audio>; + #clock-cells = <0>; + clock-output-names = "dai-clks"; + clocks = <&clks 201>; clock-names = "mclk"; diff --git a/Documentation/devicetree/bindings/sound/dmic.txt b/Documentation/devicetree/bindings/sound/dmic.txt index f7bf656..e957b41 100644 --- a/Documentation/devicetree/bindings/sound/dmic.txt +++ b/Documentation/devicetree/bindings/sound/dmic.txt @@ -8,6 +8,7 @@ Required properties: Optional properties: - dmicen-gpios: GPIO specifier for dmic to control start and stop - num-channels: Number of microphones on this DAI + - wakeup-delay-ms: Delay (in ms) after enabling the DMIC Example node: @@ -15,4 +16,5 @@ Example node: compatible = "dmic-codec"; dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>; num-channels = <1>; + wakeup-delay-ms <50>; }; diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt index f749e27..c60a573 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt @@ -28,7 +28,6 @@ The compatible list for this generic sound card currently: (compatible with CS4271 and CS4272) "fsl,imx-audio-wm8962" - (compatible with Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt) "fsl,imx-audio-sgtl5000" (compatible with Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt) diff --git a/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt b/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt deleted file mode 100644 index acea71b..0000000 --- a/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt +++ /dev/null @@ -1,53 +0,0 @@ -Freescale i.MX audio complex with WM8962 codec - -Required properties: - - - compatible : "fsl,imx-audio-wm8962" - - - model : The user-visible name of this sound complex - - - ssi-controller : The phandle of the i.MX SSI controller - - - audio-codec : The phandle of the WM8962 audio codec - - - 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 could be power supplies, WM8962 - pins, and the jacks on the board: - - Power supplies: - * Mic Bias - - Board connectors: - * Mic Jack - * Headphone Jack - * Ext Spk - - - mux-int-port : The internal port of the i.MX audio muxer (AUDMUX) - - - 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 = "fsl,imx6q-sabresd-wm8962", - "fsl,imx-audio-wm8962"; - model = "wm8962-audio"; - ssi-controller = <&ssi2>; - audio-codec = <&codec>; - audio-routing = - "Headphone Jack", "HPOUTL", - "Headphone Jack", "HPOUTR", - "Ext Spk", "SPKOUTL", - "Ext Spk", "SPKOUTR", - "MICBIAS", "AMIC", - "IN3R", "MICBIAS", - "DMIC", "MICBIAS", - "DMICDAT", "DMIC"; - mux-int-port = <2>; - mux-ext-port = <3>; -}; diff --git a/Documentation/devicetree/bindings/sound/max98090.txt b/Documentation/devicetree/bindings/sound/max98090.txt index 4e3be66..7e1bbd5 100644 --- a/Documentation/devicetree/bindings/sound/max98090.txt +++ b/Documentation/devicetree/bindings/sound/max98090.txt @@ -16,6 +16,8 @@ Optional properties: - clock-names: Should be "mclk" +- #sound-dai-cells : should be 0. + - maxim,dmic-freq: Frequency at which to clock DMIC - maxim,micbias: Micbias voltage applies to the analog mic, valid voltages value are: diff --git a/Documentation/devicetree/bindings/sound/maxim,max9759.txt b/Documentation/devicetree/bindings/sound/maxim,max9759.txt new file mode 100644 index 0000000..737a996 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/maxim,max9759.txt @@ -0,0 +1,18 @@ +Maxim MAX9759 Speaker Amplifier +=============================== + +Required properties: +- compatible : "maxim,max9759" +- shutdown-gpios : the gpio connected to the shutdown pin +- mute-gpios : the gpio connected to the mute pin +- gain-gpios : the 2 gpios connected to the g1 and g2 pins + +Example: + +max9759: analog-amplifier { + compatible = "maxim,max9759"; + shutdown-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>; + mute-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>; + gain-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>, + <&gpio3 25 GPIO_ACTIVE_LOW>; +}; diff --git a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt index 6df87b9..e2f7f49 100644 --- a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt +++ b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt @@ -53,7 +53,7 @@ See ../arm/mediatek/mediatek,audsys.txt for details about the parent node. Example: audsys: audio-subsystem@11220000 { - compatible = "mediatek,mt2701-audsys", "syscon", "simple-mfd"; + compatible = "mediatek,mt2701-audsys", "syscon"; ... afe: audio-controller { diff --git a/Documentation/devicetree/bindings/sound/pcm1789.txt b/Documentation/devicetree/bindings/sound/pcm1789.txt new file mode 100644 index 0000000..3c74ed2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/pcm1789.txt @@ -0,0 +1,22 @@ +Texas Instruments pcm1789 DT bindings + +PCM1789 is a simple audio codec that can be connected via +I2C or SPI. Currently, only I2C bus is supported. + +Required properties: + + - compatible: "ti,pcm1789" + +Required properties on I2C: + + - reg: the I2C address + - reset-gpios: GPIO to control the RESET pin + +Examples: + + audio-codec@4c { + compatible = "ti,pcm1789"; + reg = <0x4c>; + reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; + #sound-dai-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 5bed9a5..b86d790 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -351,6 +351,7 @@ Required properties: - "renesas,rcar_sound-r8a7793" (R-Car M2-N) - "renesas,rcar_sound-r8a7794" (R-Car E2) - "renesas,rcar_sound-r8a7795" (R-Car H3) + - "renesas,rcar_sound-r8a7796" (R-Car M3-W) - reg : Should contain the register physical address. required register is SRU/ADG/SSI if generation1 diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt index 2539e1d..e5430d1 100644 --- a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt @@ -22,7 +22,7 @@ Optionnal properties: Example: sound { - compatible = "rockchip,rockchip-audio-es8388"; + compatible = "rockchip,rk3288-hdmi-analog"; rockchip,model = "Analog audio output"; rockchip,i2s-controller = <&i2s>; rockchip,audio-codec = <&es8388>; diff --git a/Documentation/devicetree/bindings/sound/rohm,bd28623.txt b/Documentation/devicetree/bindings/sound/rohm,bd28623.txt new file mode 100644 index 0000000..d84557c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rohm,bd28623.txt @@ -0,0 +1,29 @@ +ROHM BD28623MUV Class D speaker amplifier for digital input + +This codec does not have any control buses such as I2C, it detect format and +rate of I2S signal automatically. It has two signals that can be connected +to GPIOs: reset and mute. + +Required properties: +- compatible : should be "rohm,bd28623" +- #sound-dai-cells: should be 0. +- VCCA-supply : regulator phandle for the VCCA supply +- VCCP1-supply : regulator phandle for the VCCP1 supply +- VCCP2-supply : regulator phandle for the VCCP2 supply + +Optional properties: +- reset-gpios : GPIO specifier for the active low reset line +- mute-gpios : GPIO specifier for the active low mute line + +Example: + + codec { + compatible = "rohm,bd28623"; + #sound-dai-cells = <0>; + + VCCA-supply = <&vcc_reg>; + VCCP1-supply = <&vcc_reg>; + VCCP2-supply = <&vcc_reg>; + reset-gpios = <&gpio 0 GPIO_ACTIVE_LOW>; + mute-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/sound/rt5651.txt b/Documentation/devicetree/bindings/sound/rt5651.txt index 38752330..b852218 100644 --- a/Documentation/devicetree/bindings/sound/rt5651.txt +++ b/Documentation/devicetree/bindings/sound/rt5651.txt @@ -16,6 +16,23 @@ Optional properties: - realtek,dmic-en Boolean. true if dmic is used. +- realtek,jack-detect-source + u32. Valid values: + 1: Use JD1_1 pin for jack-detect + 2: Use JD1_2 pin for jack-detect + 3: Use JD2 pin for jack-detect + +- realtek,over-current-threshold-microamp + u32, micbias over-current detection threshold in µA, valid values are + 600, 1500 and 2000µA. + +- realtek,over-current-scale-factor + u32, micbias over-current detection scale-factor, valid values are: + 0: Scale current by 0.5 + 1: Scale current by 0.75 + 2: Scale current by 1.0 + 3: Scale current by 1.5 + Pins on the device (for linking into audio routes) for RT5651: * DMIC L1 diff --git a/Documentation/devicetree/bindings/sound/rt5665.txt b/Documentation/devicetree/bindings/sound/rt5665.txt index 419c892..8df1705 100644 --- a/Documentation/devicetree/bindings/sound/rt5665.txt +++ b/Documentation/devicetree/bindings/sound/rt5665.txt @@ -1,10 +1,10 @@ -RT5665/RT5666/RT5668 audio CODEC +RT5665/RT5666 audio CODEC This device supports I2C only. Required properties: -- compatible : One of "realtek,rt5665", "realtek,rt5666" or "realtek,rt5668". +- compatible : One of "realtek,rt5665", "realtek,rt5666". - reg : The I2C address of the device. diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt b/Documentation/devicetree/bindings/sound/samsung,odroid.txt index 625b1b1..e9da220 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.txt +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt @@ -2,8 +2,10 @@ Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec Required properties: - - compatible - "samsung,odroidxu3-audio" - for Odroid XU3 board, - "samsung,odroidxu4-audio" - for Odroid XU4 board + - compatible - "hardkernel,odroid-xu3-audio" - for Odroid XU3 board, + "hardkernel,odroid-xu4-audio" - for Odroid XU4 board (deprecated), + "samsung,odroid-xu3-audio" - for Odroid XU3 board (deprecated), + "samsung,odroid-xu4-audio" - for Odroid XU4 board (deprecated) - model - the user-visible name of this sound complex - clocks - should contain entries matching clock names in the clock-names property @@ -35,7 +37,7 @@ Required sub-nodes: Example: sound { - compatible = "samsung,odroidxu3-audio"; + compatible = "hardkernel,odroid-xu3-audio"; model = "Odroid-XU3"; samsung,audio-routing = "Headphone Jack", "HPL", diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt b/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt index 94442e5..f5ccc12 100644 --- a/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt +++ b/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt @@ -4,9 +4,13 @@ Required properties: - compatible : "samsung,tm2-audio" - model : the user-visible name of this sound complex - - audio-codec : the phandle of the wm5110 audio codec node, - as described in ../mfd/arizona.txt - - i2s-controller : the phandle of the I2S controller + - audio-codec : the first entry should be phandle of the wm5110 audio + codec node, as described in ../mfd/arizona.txt; + the second entry should be phandle of the HDMI + transmitter node + - i2s-controller : the list of phandle and argument tuples pointing to + I2S controllers, the first entry should be I2S0 and + the second one I2S1 - audio-amplifier : the phandle of the MAX98504 amplifier - samsung,audio-routing : a list of the connections between audio components; each entry is a pair of strings, the first being the @@ -22,8 +26,8 @@ Example: sound { compatible = "samsung,tm2-audio"; - audio-codec = <&wm5110>; - i2s-controller = <&i2s0>; + audio-codec = <&wm5110>, <&hdmi>; + i2s-controller = <&i2s0 0>, <&i2s1 0>; audio-amplifier = <&max98504>; mic-bias-gpios = <&gpr3 2 0>; model = "wm5110"; diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt index bf100cd..a88cb00 100644 --- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt @@ -7,7 +7,7 @@ Required SoC Specific Properties: - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with secondary fifo, s/w reset control and internal mux for root clk src. - samsung,exynos5420-i2s: for 8/16/24bit multichannel(5.1) I2S for - playback, sterio channel capture, secondary fifo using internal + playback, stereo channel capture, secondary fifo using internal or external dma, s/w reset control, internal mux for root clk src and 7.1 channel TDM support for playback. TDM (Time division multiplexing) is to allow transfer of multiple channel audio data on single data line. @@ -25,7 +25,7 @@ Required SoC Specific Properties: These strings correspond 1:1 with the ordered pairs in dmas. - clocks: Handle to iis clock and RCLK source clk. - clock-names: - i2s0 uses some base clks from CMU and some are from audio subsystem internal + i2s0 uses some base clocks from CMU and some are from audio subsystem internal clock controller. The clock names for i2s0 should be "iis", "i2s_opclk0" and "i2s_opclk1" as shown in the example below. i2s1 and i2s2 uses clocks from CMU. The clock names for i2s1 and i2s2 should @@ -36,9 +36,9 @@ Required SoC Specific Properties: - #clock-cells: should be 1, this property must be present if the I2S device is a clock provider in terms of the common clock bindings, described in ../clock/clock-bindings.txt. -- clock-output-names: from the common clock bindings, names of the CDCLK - I2S output clocks, suggested values are "i2s_cdclk0", "i2s_cdclk1", - "i2s_cdclk3" for the I2S0, I2S1, I2S2 devices recpectively. +- clock-output-names (deprecated): from the common clock bindings, names of + the CDCLK I2S output clocks, suggested values are "i2s_cdclk0", "i2s_cdclk1", + "i2s_cdclk3" for the I2S0, I2S1, I2S2 devices respectively. There are following clocks available at the I2S device nodes: CLK_I2S_CDCLK - the CDCLK (CODECLKO) gate clock, @@ -49,9 +49,10 @@ There are following clocks available at the I2S device nodes: Refer to the SoC datasheet for availability of the above clocks. The CLK_I2S_RCLK_PSR and CLK_I2S_RCLK_SRC clocks are usually only available -in the IIS Multi Audio Interface (I2S0). -Note: Old DTs may not have the #clock-cells, clock-output-names properties -and then not use the I2S node as a clock supplier. +in the IIS Multi Audio Interface. + +Note: Old DTs may not have the #clock-cells property and then not use the I2S +node as a clock supplier. Optional SoC Specific Properties: @@ -59,6 +60,7 @@ Optional SoC Specific Properties: sub system(used in secondary sound source). - pinctrl-0: Should specify pin control groups used for this controller. - pinctrl-names: Should contain only one value - "default". +- #sound-dai-cells: should be 1. Example: @@ -74,9 +76,9 @@ i2s0: i2s@3830000 { <&clock_audss EXYNOS_I2S_BUS>, <&clock_audss EXYNOS_SCLK_I2S>; clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; - #clock-cells; - clock-output-names = "i2s_cdclk0"; + #clock-cells = <1>; samsung,idma-addr = <0x03000000>; pinctrl-names = "default"; pinctrl-0 = <&i2s0_bus>; + #sound-dai-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt index 060cb4a..9a36c7e 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.txt +++ b/Documentation/devicetree/bindings/sound/sgtl5000.txt @@ -5,6 +5,8 @@ Required properties: - reg : the I2C address of the device +- #sound-dai-cells: must be equal to 0 + - clocks : the clock provider of SYS_MCLK - VDDA-supply : the regulator provider of VDDA @@ -40,6 +42,7 @@ Example: codec: sgtl5000@a { compatible = "fsl,sgtl5000"; reg = <0x0a>; + #sound-dai-cells = <0>; clocks = <&clks 150>; micbias-resistor-k-ohms = <2>; micbias-voltage-m-volts = <2250>; diff --git a/Documentation/devicetree/bindings/sound/snow.txt b/Documentation/devicetree/bindings/sound/snow.txt index 6df74f1..80fd9a8 100644 --- a/Documentation/devicetree/bindings/sound/snow.txt +++ b/Documentation/devicetree/bindings/sound/snow.txt @@ -5,8 +5,17 @@ Required properties: "google,snow-audio-max98090" or "google,snow-audio-max98091" or "google,snow-audio-max98095" -- samsung,i2s-controller: The phandle of the Samsung I2S controller -- samsung,audio-codec: The phandle of the audio codec +- samsung,i2s-controller (deprecated): The phandle of the Samsung I2S controller +- samsung,audio-codec (deprecated): The phandle of the audio codec + +Required sub-nodes: + + - 'cpu' subnode with a 'sound-dai' property containing the phandle of the I2S + controller + - 'codec' subnode with a 'sound-dai' property containing list of phandles + to the CODEC nodes, first entry must be the phandle of the MAX98090, + MAX98091 or MAX98095 CODEC (exact device type is indicated by the compatible + string) and the second entry must be the phandle of the HDMI IP block node Optional: - samsung,model: The name of the sound-card diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt index b1acc1a..f301cdf 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt @@ -45,6 +45,12 @@ SAI subnodes Optional properties: This property sets SAI sub-block as slave of another SAI sub-block. Must contain the phandle and index of the sai sub-block providing the synchronization. + - st,iec60958: support S/PDIF IEC6958 protocol for playback + IEC60958 protocol is not available for capture. + By default, custom protocol is assumed, meaning that protocol is + configured according to protocol defined in related DAI link node, + such as i2s, left justified, right justified, dsp and pdm protocols. + Note: ac97 protocol is not supported by SAI driver The device node should contain one 'port' child node with one child 'endpoint' node, according to the bindings defined in Documentation/devicetree/bindings/ diff --git a/Documentation/devicetree/bindings/sound/tda7419.txt b/Documentation/devicetree/bindings/sound/tda7419.txt new file mode 100644 index 0000000..6b85ec3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tda7419.txt @@ -0,0 +1,38 @@ +TDA7419 audio processor + +This device supports I2C only. + +Required properties: + +- compatible : "st,tda7419" +- reg : the I2C address of the device. +- vdd-supply : a regulator spec for the common power supply (8-10V) + +Optional properties: + +- st,mute-gpios : a GPIO spec for the MUTE pin. + +Pins on the device (for linking into audio routes): + + * SE3L + * SE3R + * SE2L + * SE2R + * SE1L + * SE1R + * DIFFL + * DIFFR + * MIX + * OUTLF + * OUTRF + * OUTLR + * OUTRR + * OUTSW + +Example: + +ap: tda7419@44 { + compatible = "st,tda7419"; + reg = <0x44>; + vdd-supply = <&vdd_9v0_reg>; +}; diff --git a/Documentation/devicetree/bindings/sound/uniphier,aio.txt b/Documentation/devicetree/bindings/sound/uniphier,aio.txt new file mode 100644 index 0000000..4ce68ed --- /dev/null +++ b/Documentation/devicetree/bindings/sound/uniphier,aio.txt @@ -0,0 +1,45 @@ +Socionext UniPhier SoC audio driver + +The Socionext UniPhier audio subsystem consists of I2S and S/PDIF blocks in +the same register space. + +Required properties: +- compatible : should be one of the following: + "socionext,uniphier-ld11-aio" + "socionext,uniphier-ld20-aio" + "socionext,uniphier-pxs2-aio" +- reg : offset and length of the register set for the device. +- interrupts : should contain I2S or S/PDIF interrupt. +- pinctrl-names : should be "default". +- pinctrl-0 : defined I2S signal pins for an external codec chip. +- clock-names : should include following entries: + "aio" +- clocks : a list of phandle, should contain an entry for each + entry in clock-names. +- reset-names : should include following entries: + "aio" +- resets : a list of phandle, should contain an entry for each + entry in reset-names. +- #sound-dai-cells: should be 1. + +Optional properties: +- socionext,syscon: a phandle, should contain soc-glue. + The soc-glue is used for changing mode of S/PDIF signal pin + to Output from Hi-Z. This property is optional if you use + I2S signal pins only. + +Example: + audio { + compatible = "socionext,uniphier-ld20-aio"; + reg = <0x56000000 0x80000>; + interrupts = <0 144 4>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_aout>; + clock-names = "aio"; + clocks = <&sys_clk 40>; + reset-names = "aio"; + resets = <&sys_rst 40>; + #sound-dai-cells = <1>; + + socionext,syscon = <&sg>; + }; diff --git a/Documentation/devicetree/bindings/sound/wm8524.txt b/Documentation/devicetree/bindings/sound/wm8524.txt index 20c6200..0f05535 100644 --- a/Documentation/devicetree/bindings/sound/wm8524.txt +++ b/Documentation/devicetree/bindings/sound/wm8524.txt @@ -10,7 +10,7 @@ Required properties: Example: -codec: wm8524@0 { +codec: wm8524 { compatible = "wlf,wm8524"; wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; }; diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt index 80710f0..3980632 100644 --- a/Documentation/devicetree/bindings/spi/sh-msiof.txt +++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt @@ -10,6 +10,7 @@ Required properties: "renesas,msiof-r8a7794" (R-Car E2) "renesas,msiof-r8a7795" (R-Car H3) "renesas,msiof-r8a7796" (R-Car M3-W) + "renesas,msiof-r8a77965" (R-Car M3-N) "renesas,msiof-sh73a0" (SH-Mobile AG5) "renesas,sh-mobile-msiof" (generic SH-Mobile compatibile device) "renesas,rcar-gen2-msiof" (generic R-Car Gen2 and RZ/G1 compatible device) diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.txt b/Documentation/devicetree/bindings/spi/spi-gpio.txt index a95603b..52db562 100644 --- a/Documentation/devicetree/bindings/spi/spi-gpio.txt +++ b/Documentation/devicetree/bindings/spi/spi-gpio.txt @@ -1,18 +1,30 @@ SPI-GPIO devicetree bindings +This represents a group of 3-n GPIO lines used for bit-banged SPI on dedicated +GPIO lines. + Required properties: - compatible: should be set to "spi-gpio" - #address-cells: should be set to <0x1> - ranges - - gpio-sck: GPIO spec for the SCK line to use - - gpio-miso: GPIO spec for the MISO line to use - - gpio-mosi: GPIO spec for the MOSI line to use + - sck-gpios: GPIO spec for the SCK line to use + - miso-gpios: GPIO spec for the MISO line to use + - mosi-gpios: GPIO spec for the MOSI line to use - cs-gpios: GPIOs to use for chipselect lines. Not needed if num-chipselects = <0>. - num-chipselects: Number of chipselect lines. Should be <0> if a single device with no chip select is connected. +Deprecated bindings: + +These legacy GPIO line bindings can alternatively be used to define the +GPIO lines used, they should not be used in new device trees. + + - gpio-sck: GPIO spec for the SCK line to use + - gpio-miso: GPIO spec for the MISO line to use + - gpio-mosi: GPIO spec for the MOSI line to use + Example: spi { @@ -20,9 +32,9 @@ Example: #address-cells = <0x1>; ranges; - gpio-sck = <&gpio 95 0>; - gpio-miso = <&gpio 98 0>; - gpio-mosi = <&gpio 97 0>; + sck-gpios = <&gpio 95 0>; + miso-gpios = <&gpio 98 0>; + mosi-gpios = <&gpio 97 0>; cs-gpios = <&gpio 125 0>; num-chipselects = <1>; diff --git a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt new file mode 100644 index 0000000..4c9ea59 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt @@ -0,0 +1,33 @@ +Andestech ATCPIT100 timer +------------------------------------------------------------------ +ATCPIT100 is a generic IP block from Andes Technology, embedded in +Andestech AE3XX platforms and other designs. + +This timer is a set of compact multi-function timers, which can be +used as pulse width modulators (PWM) as well as simple timers. + +It supports up to 4 PIT channels. Each PIT channel is a +multi-function timer and provide the following usage scenarios: +One 32-bit timer +Two 16-bit timers +Four 8-bit timers +One 16-bit PWM +One 16-bit timer and one 8-bit PWM +Two 8-bit timer and one 8-bit PWM + +Required properties: +- compatible : Should be "andestech,atcpit100" +- reg : Address and length of the register set +- interrupts : Reference to the timer interrupt +- clocks : a clock to provide the tick rate for "andestech,atcpit100" +- clock-names : should be "PCLK" for the peripheral clock source. + +Examples: + +timer0: timer@f0400000 { + compatible = "andestech,atcpit100"; + reg = <0xf0400000 0x1000>; + interrupts = <2>; + clocks = <&apb>; + clock-names = "PCLK"; +}; diff --git a/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt b/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt new file mode 100644 index 0000000..9a8b631 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt @@ -0,0 +1,42 @@ +Amlogic Meson GX DWC3 USB SoC controller + +Required properties: +- compatible: depending on the SoC this should contain one of: + * amlogic,meson-axg-dwc3 + * amlogic,meson-gxl-dwc3 +- clocks: a handle for the "USB general" clock +- clock-names: must be "usb_general" +- resets: a handle for the shared "USB OTG" reset line +- reset-names: must be "usb_otg" + +Required child node: +A child node must exist to represent the core DWC3 IP block. The name of +the node is not important. The content of the node is defined in dwc3.txt. + +PHY documentation is provided in the following places: +- Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt +- Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt + +Example device nodes: + usb0: usb@ff500000 { + compatible = "amlogic,meson-axg-dwc3"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + clocks = <&clkc CLKID_USB>; + clock-names = "usb_general"; + resets = <&reset RESET_USB_OTG>; + reset-names = "usb_otg"; + + dwc3: dwc3@ff500000 { + compatible = "snps,dwc3"; + reg = <0x0 0xff500000 0x0 0x100000>; + interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; + dr_mode = "host"; + maximum-speed = "high-speed"; + snps,dis_u2_susphy_quirk; + phys = <&usb3_phy>, <&usb2_phy0>; + phy-names = "usb2-phy", "usb3-phy"; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 44e8bab..0dbd308 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -57,6 +57,22 @@ Optional properties: - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ register for post-silicon frame length adjustment when the fladj_30mhz_sdbnd signal is invalid or incorrect. + - snps,rx-thr-num-pkt-prd: periodic ESS RX packet threshold count - host mode + only. Set this and rx-max-burst-prd to a valid, + non-zero value 1-16 (DWC_usb31 programming guide + section 1.2.4) to enable periodic ESS RX threshold. + - snps,rx-max-burst-prd: max periodic ESS RX burst size - host mode only. Set + this and rx-thr-num-pkt-prd to a valid, non-zero value + 1-16 (DWC_usb31 programming guide section 1.2.4) to + enable periodic ESS RX threshold. + - snps,tx-thr-num-pkt-prd: periodic ESS TX packet threshold count - host mode + only. Set this and tx-max-burst-prd to a valid, + non-zero value 1-16 (DWC_usb31 programming guide + section 1.2.3) to enable periodic ESS TX threshold. + - snps,tx-max-burst-prd: max periodic ESS TX burst size - host mode only. Set + this and tx-thr-num-pkt-prd to a valid, non-zero value + 1-16 (DWC_usb31 programming guide section 1.2.3) to + enable periodic ESS TX threshold. - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated. diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt index 88d9f4a..266c2d9 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt @@ -32,7 +32,7 @@ Required properties: "mcu_ck": mcu_bus clock for register access, "dma_ck": dma_bus clock for data transfer by DMA - - phys : a list of phandle + phy specifier pairs + - phys : see usb-hcd.txt in the current directory Optional properties: - wakeup-source : enable USB remote wakeup; @@ -52,6 +52,9 @@ Optional properties: See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - imod-interval-ns: default interrupt moderation interval is 5000ns +additionally the properties from usb-hcd.txt (in the current directory) are +supported. + Example: usb30: usb@11270000 { compatible = "mediatek,mt8173-xhci"; diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt index d589a1e..3382b5c 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt @@ -17,7 +17,7 @@ Required properties: - clock-names : must contain "sys_ck" for clock of controller, the following clocks are optional: "ref_ck", "mcu_ck" and "dam_ck"; - - phys : a list of phandle + phy specifier pairs + - phys : see usb-hcd.txt in the current directory - dr_mode : should be one of "host", "peripheral" or "otg", refer to usb/generic.txt @@ -53,6 +53,9 @@ Optional properties: - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0, bit1 for u3port1, ... etc; +additionally the properties from usb-hcd.txt (in the current directory) are +supported. + Sub-nodes: The xhci should be added as subnode to mtu3 as shown in the following example if host mode is enabled. The DT binding details of xhci can be found in: diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index 3efde12..0f1b753 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -16,10 +16,12 @@ Optional properties: - has-transaction-translator : boolean, set this if EHCI have a Transaction Translator built into the root hub. - clocks : a list of phandle + clock specifier pairs - - phys : phandle + phy specifier pair - - phy-names : "usb" + - phys : see usb-hcd.txt in the current directory - resets : phandle + reset specifier pair +additionally the properties from usb-hcd.txt (in the current directory) are +supported. + Example (Sequoia 440EPx): ehci@e0000300 { compatible = "ibm,usb-ehci-440epx", "usb-ehci"; diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.txt b/Documentation/devicetree/bindings/usb/usb-hcd.txt new file mode 100644 index 0000000..50529b8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-hcd.txt @@ -0,0 +1,9 @@ +Generic USB HCD (Host Controller Device) Properties + +Optional properties: +- phys: a list of all USB PHYs on this HCD + +Example: + &usb1 { + phys = <&usb2_phy1>, <&usb3_phy1>; + }; diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt index 09e70c8..a8d2103 100644 --- a/Documentation/devicetree/bindings/usb/usb-ohci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt @@ -13,10 +13,12 @@ Optional properties: - remote-wakeup-connected: remote wakeup is wired on the platform - num-ports : u32, to override the detected port count - clocks : a list of phandle + clock specifier pairs -- phys : phandle + phy specifier pair -- phy-names : "usb" +- phys : see usb-hcd.txt in the current directory - resets : a list of phandle + reset specifier pairs +additionally the properties from usb-hcd.txt (in the current directory) are +supported. + Example: ohci0: usb@1c14400 { diff --git a/Documentation/devicetree/bindings/usb/usb-uhci.txt b/Documentation/devicetree/bindings/usb/usb-uhci.txt index 2981334..cc2e6f7 100644 --- a/Documentation/devicetree/bindings/usb/usb-uhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-uhci.txt @@ -6,6 +6,9 @@ Required properties: - reg : Should contain 1 register ranges(address and length) - interrupts : UHCI controller interrupt +additionally the properties from usb-hcd.txt (in the current directory) are +supported. + Example: uhci@d8007b00 { diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 1651483a..c4c00df 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -33,6 +33,11 @@ Optional properties: - usb3-lpm-capable: determines if platform is USB3 LPM capable - quirk-broken-port-ped: set if the controller has broken port disable mechanism - imod-interval-ns: default interrupt moderation interval is 5000ns + - phys : see usb-hcd.txt in the current directory + +additionally the properties from usb-hcd.txt (in the current directory) are +supported. + Example: usb@f0931000 { diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ae850d6..12e8b3e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -104,6 +104,7 @@ eeti eGalax_eMPIA Technology Inc elan Elan Microelectronic Corp. embest Shenzhen Embest Technology Co., Ltd. emmicro EM Microelectronic +emtrion emtrion GmbH energymicro Silicon Laboratories (formerly Energy Micro AS) engicam Engicam S.r.l. epcos EPCOS AG diff --git a/Documentation/devicetree/bindings/x86/ce4100.txt b/Documentation/devicetree/bindings/x86/ce4100.txt index b49ae59..cd1221b 100644 --- a/Documentation/devicetree/bindings/x86/ce4100.txt +++ b/Documentation/devicetree/bindings/x86/ce4100.txt @@ -7,17 +7,36 @@ Many of the "generic" devices like HPET or IO APIC have the ce4100 name in their compatible property because they first appeared in this SoC. -The CPU node ------------- - cpu@0 { - device_type = "cpu"; - compatible = "intel,ce4100"; - reg = <0>; - lapic = <&lapic0>; +The CPU nodes +------------- + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + device_type = "cpu"; + compatible = "intel,ce4100"; + reg = <0x00>; + }; + + cpu@2 { + device_type = "cpu"; + compatible = "intel,ce4100"; + reg = <0x02>; + }; }; -The reg property describes the CPU number. The lapic property points to -the local APIC timer. +A "cpu" node describes one logical processor (hardware thread). + +Required properties: + +- device_type + Device type, must be "cpu". + +- reg + Local APIC ID, the unique number assigned to each processor by + system hardware. The SoC node ------------ diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.txt index c4aa0ad..5175a24 100644 --- a/Documentation/devicetree/overlay-notes.txt +++ b/Documentation/devicetree/overlay-notes.txt @@ -87,8 +87,8 @@ Overlay in-kernel API The API is quite easy to use. -1. Call of_overlay_apply() to create and apply an overlay changeset. The return -value is an error or a cookie identifying this overlay. +1. Call of_overlay_fdt_apply() to create and apply an overlay changeset. The +return value is an error or a cookie identifying this overlay. 2. Call of_overlay_remove() to remove and cleanup the overlay changeset previously created via the call to of_overlay_apply(). Removal of an overlay diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst index 722d452..80383b1 100644 --- a/Documentation/doc-guide/kernel-doc.rst +++ b/Documentation/doc-guide/kernel-doc.rst @@ -1,201 +1,59 @@ -Including kernel-doc comments -============================= - -The Linux kernel source files may contain structured documentation comments, or -kernel-doc comments to describe the functions and types and design of the -code. The documentation comments may be included to any of the reStructuredText -documents using a dedicated kernel-doc Sphinx directive extension. - -The kernel-doc directive is of the format:: - - .. kernel-doc:: source - :option: - -The *source* is the path to a source file, relative to the kernel source -tree. The following directive options are supported: - -export: *[source-pattern ...]* - Include documentation for all functions in *source* that have been exported - using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` either in *source* or in any - of the files specified by *source-pattern*. - - The *source-pattern* is useful when the kernel-doc comments have been placed - in header files, while ``EXPORT_SYMBOL`` and ``EXPORT_SYMBOL_GPL`` are next to - the function definitions. - - Examples:: - - .. kernel-doc:: lib/bitmap.c - :export: - - .. kernel-doc:: include/net/mac80211.h - :export: net/mac80211/*.c - -internal: *[source-pattern ...]* - Include documentation for all functions and types in *source* that have - **not** been exported using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` either - in *source* or in any of the files specified by *source-pattern*. - - Example:: - - .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c - :internal: - -doc: *title* - Include documentation for the ``DOC:`` paragraph identified by *title* in - *source*. Spaces are allowed in *title*; do not quote the *title*. The *title* - is only used as an identifier for the paragraph, and is not included in the - output. Please make sure to have an appropriate heading in the enclosing - reStructuredText document. - - Example:: - - .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c - :doc: High Definition Audio over HDMI and Display Port - -functions: *function* *[...]* - Include documentation for each *function* in *source*. - - Example:: - - .. kernel-doc:: lib/bitmap.c - :functions: bitmap_parselist bitmap_parselist_user - -Without options, the kernel-doc directive includes all documentation comments -from the source file. - -The kernel-doc extension is included in the kernel source tree, at -``Documentation/sphinx/kerneldoc.py``. Internally, it uses the -``scripts/kernel-doc`` script to extract the documentation comments from the -source. - -.. _kernel_doc: - Writing kernel-doc comments =========================== -In order to provide embedded, "C" friendly, easy to maintain, but consistent and -extractable overview, function and type documentation, the Linux kernel has -adopted a consistent style for documentation comments. The format for this -documentation is called the kernel-doc format, described below. This style -embeds the documentation within the source files, using a few simple conventions -for adding documentation paragraphs and documenting functions and their -parameters, structures and unions and their members, enumerations, and typedefs. - -.. note:: The kernel-doc format is deceptively similar to gtk-doc or Doxygen, - yet distinctively different, for historical reasons. The kernel source - contains tens of thousands of kernel-doc comments. Please stick to the style - described here. +The Linux kernel source files may contain structured documentation +comments in the kernel-doc format to describe the functions, types +and design of the code. It is easier to keep documentation up-to-date +when it is embedded in source files. -The ``scripts/kernel-doc`` script is used by the Sphinx kernel-doc extension in -the documentation build to extract this embedded documentation into the various -HTML, PDF, and other format documents. - -In order to provide good documentation of kernel functions and data structures, -please use the following conventions to format your kernel-doc comments in the -Linux kernel source. - -How to format kernel-doc comments ---------------------------------- +.. note:: The kernel-doc format is deceptively similar to javadoc, + gtk-doc or Doxygen, yet distinctively different, for historical + reasons. The kernel source contains tens of thousands of kernel-doc + comments. Please stick to the style described here. -The opening comment mark ``/**`` is reserved for kernel-doc comments. Only -comments so marked will be considered by the ``kernel-doc`` tool. Use it only -for comment blocks that contain kernel-doc formatted comments. The usual ``*/`` -should be used as the closing comment marker. The lines in between should be -prefixed by `` * `` (space star space). - -The function and type kernel-doc comments should be placed just before the -function or type being described. The overview kernel-doc comments may be freely -placed at the top indentation level. - -Example kernel-doc function comment:: - - /** - * foobar() - Brief description of foobar. - * @argument1: Description of parameter argument1 of foobar. - * @argument2: Description of parameter argument2 of foobar. - * - * Longer description of foobar. - * - * Return: Description of return value of foobar. - */ - int foobar(int argument1, char *argument2) - -The format is similar for documentation for structures, enums, paragraphs, -etc. See the sections below for specific details of each type. - -The kernel-doc structure is extracted from the comments, and proper `Sphinx C -Domain`_ function and type descriptions with anchors are generated for them. The -descriptions are filtered for special kernel-doc highlights and -cross-references. See below for details. +The kernel-doc structure is extracted from the comments, and proper +`Sphinx C Domain`_ function and type descriptions with anchors are +generated from them. The descriptions are filtered for special kernel-doc +highlights and cross-references. See below for details. .. _Sphinx C Domain: http://www.sphinx-doc.org/en/stable/domains.html +Every function that is exported to loadable modules using +``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` should have a kernel-doc +comment. Functions and data structures in header files which are intended +to be used by modules should also have kernel-doc comments. -Parameters and member arguments -------------------------------- - -The kernel-doc function comments describe each parameter to the function and -function typedefs or each member of struct/union, in order, with the -``@argument:`` descriptions. For each non-private member argument, one -``@argument`` definition is needed. - -The ``@argument:`` descriptions begin on the very next line following -the opening brief function description line, with no intervening blank -comment lines. - -The ``@argument:`` descriptions may span multiple lines. - -.. note:: - - If the ``@argument`` description has multiple lines, the continuation - of the description should be starting exactly at the same column as - the previous line, e. g.:: - - * @argument: some long description - * that continues on next lines +It is good practice to also provide kernel-doc formatted documentation +for functions externally visible to other kernel files (not marked +``static``). We also recommend providing kernel-doc formatted +documentation for private (file ``static``) routines, for consistency of +kernel source code layout. This is lower priority and at the discretion +of the maintainer of that kernel source file. - or:: - - * @argument: - * some long description - * that continues on next lines - -If a function or typedef parameter argument is ``...`` (e. g. a variable -number of arguments), its description should be listed in kernel-doc -notation as:: +How to format kernel-doc comments +--------------------------------- - * @...: description +The opening comment mark ``/**`` is used for kernel-doc comments. The +``kernel-doc`` tool will extract comments marked this way. The rest of +the comment is formatted like a normal multi-line comment with a column +of asterisks on the left side, closing with ``*/`` on a line by itself. -Private members -~~~~~~~~~~~~~~~ +The function and type kernel-doc comments should be placed just before +the function or type being described in order to maximise the chance +that somebody changing the code will also change the documentation. The +overview kernel-doc comments may be placed anywhere at the top indentation +level. -Inside a struct or union description, you can use the ``private:`` and -``public:`` comment tags. Structure fields that are inside a ``private:`` -area are not listed in the generated output documentation. +Running the ``kernel-doc`` tool with increased verbosity and without actual +output generation may be used to verify proper formatting of the +documentation comments. For example:: -The ``private:`` and ``public:`` tags must begin immediately following a -``/*`` comment marker. They may optionally include comments between the -``:`` and the ending ``*/`` marker. + scripts/kernel-doc -v -none drivers/foo/bar.c -Example:: +The documentation format is verified by the kernel build when it is +requested to perform extra gcc checks:: - /** - * struct my_struct - short description - * @a: first member - * @b: second member - * @d: fourth member - * - * Longer description - */ - struct my_struct { - int a; - int b; - /* private: internal use only */ - int c; - /* public: the next one is public */ - int d; - }; + make W=n Function documentation ---------------------- @@ -216,6 +74,9 @@ The general format of a function and function-like macro kernel-doc comment is:: * * The longer description may have multiple paragraphs. * + * Context: Describes whether the function can sleep, what locks it takes, + * releases, or expects to be held. It can extend over multiple + * lines. * Return: Describe the return value of foobar. * * The return value description can also have multiple paragraphs, and should @@ -226,6 +87,52 @@ The brief description following the function name may span multiple lines, and ends with an argument description, a blank comment line, or the end of the comment block. +Function parameters +~~~~~~~~~~~~~~~~~~~ + +Each function argument should be described in order, immediately following +the short function description. Do not leave a blank line between the +function description and the arguments, nor between the arguments. + +Each ``@argument:`` description may span multiple lines. + +.. note:: + + If the ``@argument`` description has multiple lines, the continuation + of the description should start at the same column as the previous line:: + + * @argument: some long description + * that continues on next lines + + or:: + + * @argument: + * some long description + * that continues on next lines + +If a function has a variable number of arguments, its description should +be written in kernel-doc notation as:: + + * @...: description + +Function context +~~~~~~~~~~~~~~~~ + +The context in which a function can be called should be described in a +section named ``Context``. This should include whether the function +sleeps or can be called from interrupt context, as well as what locks +it takes, releases and expects to be held by its caller. + +Examples:: + + * Context: Any context. + * Context: Any context. Takes and releases the RCU lock. + * Context: Any context. Expects <lock> to be held by caller. + * Context: Process context. May sleep if @gfp flags permit. + * Context: Process context. Takes and releases <mutex>. + * Context: Softirq or process context. Takes and releases <lock>, BH-safe. + * Context: Interrupt context. + Return values ~~~~~~~~~~~~~ @@ -255,7 +162,7 @@ named ``Return``. #) If the descriptive text you provide has lines that begin with some phrase followed by a colon, each of those phrases will be taken - as a new section heading, with probably won't produce the desired + as a new section heading, which probably won't produce the desired effect. Structure, union, and enumeration documentation @@ -265,69 +172,144 @@ The general format of a struct, union, and enum kernel-doc comment is:: /** * struct struct_name - Brief description. - * @argument: Description of member member_name. + * @member1: Description of member1. + * @member2: Description of member2. + * One can provide multiple line descriptions + * for members. * * Description of the structure. */ -On the above, ``struct`` is used to mean structs. You can also use ``union`` -and ``enum`` to describe unions and enums. ``argument`` is used -to mean struct and union member names as well as enumerations in an enum. +You can replace the ``struct`` in the above example with ``union`` or +``enum`` to describe unions or enums. ``member`` is used to mean struct +and union member names as well as enumerations in an enum. -The brief description following the structure name may span multiple lines, and -ends with a member description, a blank comment line, or the end of the -comment block. +The brief description following the structure name may span multiple +lines, and ends with a member description, a blank comment line, or the +end of the comment block. + +Members +~~~~~~~ -The kernel-doc data structure comments describe each member of the structure, -in order, with the member descriptions. +Members of structs, unions and enums should be documented the same way +as function parameters; they immediately succeed the short description +and may be multi-line. + +Inside a struct or union description, you can use the ``private:`` and +``public:`` comment tags. Structure fields that are inside a ``private:`` +area are not listed in the generated output documentation. + +The ``private:`` and ``public:`` tags must begin immediately following a +``/*`` comment marker. They may optionally include comments between the +``:`` and the ending ``*/`` marker. + +Example:: + + /** + * struct my_struct - short description + * @a: first member + * @b: second member + * @d: fourth member + * + * Longer description + */ + struct my_struct { + int a; + int b; + /* private: internal use only */ + int c; + /* public: the next one is public */ + int d; + }; Nested structs/unions ~~~~~~~~~~~~~~~~~~~~~ -It is possible to document nested structs unions, like:: +It is possible to document nested structs and unions, like:: /** * struct nested_foobar - a struct with nested unions and structs - * @arg1: - first argument of anonymous union/anonymous struct - * @arg2: - second argument of anonymous union/anonymous struct - * @arg3: - third argument of anonymous union/anonymous struct - * @arg4: - fourth argument of anonymous union/anonymous struct - * @bar.st1.arg1 - first argument of struct st1 on union bar - * @bar.st1.arg2 - second argument of struct st1 on union bar - * @bar.st2.arg1 - first argument of struct st2 on union bar - * @bar.st2.arg2 - second argument of struct st2 on union bar + * @memb1: first member of anonymous union/anonymous struct + * @memb2: second member of anonymous union/anonymous struct + * @memb3: third member of anonymous union/anonymous struct + * @memb4: fourth member of anonymous union/anonymous struct + * @bar: non-anonymous union + * @bar.st1: struct st1 inside @bar + * @bar.st2: struct st2 inside @bar + * @bar.st1.memb1: first member of struct st1 on union bar + * @bar.st1.memb2: second member of struct st1 on union bar + * @bar.st2.memb1: first member of struct st2 on union bar + * @bar.st2.memb2: second member of struct st2 on union bar + */ struct nested_foobar { /* Anonymous union/struct*/ union { struct { - int arg1; - int arg2; - } + int memb1; + int memb2; + } struct { - void *arg3; - int arg4; - } - } - union { + void *memb3; + int memb4; + } + } + union { struct { - int arg1; - int arg2; - } st1; + int memb1; + int memb2; + } st1; struct { - void *arg1; - int arg2; - } st2; - } bar; + void *memb1; + int memb2; + } st2; + } bar; }; .. note:: #) When documenting nested structs or unions, if the struct/union ``foo`` - is named, the argument ``bar`` inside it should be documented as + is named, the member ``bar`` inside it should be documented as ``@foo.bar:`` - #) When the nested struct/union is anonymous, the argument ``bar`` on it + #) When the nested struct/union is anonymous, the member ``bar`` in it should be documented as ``@bar:`` +In-line member documentation comments +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The structure members may also be documented in-line within the definition. +There are two styles, single-line comments where both the opening ``/**`` and +closing ``*/`` are on the same line, and multi-line comments where they are each +on a line of their own, like all other kernel-doc comments:: + + /** + * struct foo - Brief description. + * @foo: The Foo member. + */ + struct foo { + int foo; + /** + * @bar: The Bar member. + */ + int bar; + /** + * @baz: The Baz member. + * + * Here, the member description may contain several paragraphs. + */ + int baz; + union { + /** @foobar: Single line description. */ + int foobar; + }; + /** @bar2: Description for struct @bar2 inside @foo */ + struct { + /** + * @bar2.barbar: Description for @barbar inside @foo.bar2 + */ + int barbar; + } bar2; + }; + Typedef documentation --------------------- @@ -347,10 +329,12 @@ Typedefs with function prototypes can also be documented:: * @arg2: description of arg2 * * Description of the type. + * + * Context: Locking context. + * Return: Meaning of the return value. */ typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2); - Highlights and cross-references ------------------------------- @@ -422,37 +406,6 @@ cross-references. For further details, please refer to the `Sphinx C Domain`_ documentation. - - -In-line member documentation comments -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The structure members may also be documented in-line within the definition. -There are two styles, single-line comments where both the opening ``/**`` and -closing ``*/`` are on the same line, and multi-line comments where they are each -on a line of their own, like all other kernel-doc comments:: - - /** - * struct foo - Brief description. - * @foo: The Foo member. - */ - struct foo { - int foo; - /** - * @bar: The Bar member. - */ - int bar; - /** - * @baz: The Baz member. - * - * Here, the member description may contain several paragraphs. - */ - int baz; - /** @foobar: Single line description. */ - int foobar; - } - - Overview documentation comments ------------------------------- @@ -482,53 +435,81 @@ The title following ``DOC:`` acts as a heading within the source file, but also as an identifier for extracting the documentation comment. Thus, the title must be unique within the file. -Recommendations ---------------- +Including kernel-doc comments +============================= -We definitely need kernel-doc formatted documentation for functions that are -exported to loadable modules using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL``. +The documentation comments may be included in any of the reStructuredText +documents using a dedicated kernel-doc Sphinx directive extension. -We also look to provide kernel-doc formatted documentation for functions -externally visible to other kernel files (not marked "static"). +The kernel-doc directive is of the format:: -We also recommend providing kernel-doc formatted documentation for private (file -"static") routines, for consistency of kernel source code layout. But this is -lower priority and at the discretion of the MAINTAINER of that kernel source -file. + .. kernel-doc:: source + :option: -Data structures visible in kernel include files should also be documented using -kernel-doc formatted comments. +The *source* is the path to a source file, relative to the kernel source +tree. The following directive options are supported: -How to use kernel-doc to generate man pages -------------------------------------------- +export: *[source-pattern ...]* + Include documentation for all functions in *source* that have been exported + using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` either in *source* or in any + of the files specified by *source-pattern*. -If you just want to use kernel-doc to generate man pages you can do this -from the Kernel git tree:: + The *source-pattern* is useful when the kernel-doc comments have been placed + in header files, while ``EXPORT_SYMBOL`` and ``EXPORT_SYMBOL_GPL`` are next to + the function definitions. + + Examples:: + + .. kernel-doc:: lib/bitmap.c + :export: + + .. kernel-doc:: include/net/mac80211.h + :export: net/mac80211/*.c + +internal: *[source-pattern ...]* + Include documentation for all functions and types in *source* that have + **not** been exported using ``EXPORT_SYMBOL`` or ``EXPORT_SYMBOL_GPL`` either + in *source* or in any of the files specified by *source-pattern*. - $ scripts/kernel-doc -man $(git grep -l '/\*\*' |grep -v Documentation/) | ./split-man.pl /tmp/man + Example:: -Using the small ``split-man.pl`` script below:: + .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c + :internal: +doc: *title* + Include documentation for the ``DOC:`` paragraph identified by *title* in + *source*. Spaces are allowed in *title*; do not quote the *title*. The *title* + is only used as an identifier for the paragraph, and is not included in the + output. Please make sure to have an appropriate heading in the enclosing + reStructuredText document. - #!/usr/bin/perl + Example:: - if ($#ARGV < 0) { - die "where do I put the results?\n"; - } + .. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c + :doc: High Definition Audio over HDMI and Display Port - mkdir $ARGV[0],0777; - $state = 0; - while (<STDIN>) { - if (/^\.TH \"[^\"]*\" 9 \"([^\"]*)\"/) { - if ($state == 1) { close OUT } - $state = 1; - $fn = "$ARGV[0]/$1.9"; - print STDERR "Creating $fn\n"; - open OUT, ">$fn" or die "can't open $fn: $!\n"; - print OUT $_; - } elsif ($state != 0) { - print OUT $_; - } - } +functions: *function* *[...]* + Include documentation for each *function* in *source*. + + Example:: + + .. kernel-doc:: lib/bitmap.c + :functions: bitmap_parselist bitmap_parselist_user + +Without options, the kernel-doc directive includes all documentation comments +from the source file. + +The kernel-doc extension is included in the kernel source tree, at +``Documentation/sphinx/kerneldoc.py``. Internally, it uses the +``scripts/kernel-doc`` script to extract the documentation comments from the +source. + +.. _kernel_doc: + +How to use kernel-doc to generate man pages +------------------------------------------- + +If you just want to use kernel-doc to generate man pages you can do this +from the kernel git tree:: - close OUT; + $ scripts/kernel-doc -man $(git grep -l '/\*\*' -- :^Documentation :^tools) | scripts/split-man.pl /tmp/man diff --git a/Documentation/driver-api/device_connection.rst b/Documentation/driver-api/device_connection.rst new file mode 100644 index 0000000..affbc556 --- /dev/null +++ b/Documentation/driver-api/device_connection.rst @@ -0,0 +1,43 @@ +================== +Device connections +================== + +Introduction +------------ + +Devices often have connections to other devices that are outside of the direct +child/parent relationship. A serial or network communication controller, which +could be a PCI device, may need to be able to get a reference to its PHY +component, which could be attached for example to the I2C bus. Some device +drivers need to be able to control the clocks or the GPIOs for their devices, +and so on. + +Device connections are generic descriptions of any type of connection between +two separate devices. + +Device connections alone do not create a dependency between the two devices. +They are only descriptions which are not tied to either of the devices directly. +A dependency between the two devices exists only if one of the two endpoint +devices requests a reference to the other. The descriptions themselves can be +defined in firmware (not yet supported) or they can be built-in. + +Usage +----- + +Device connections should exist before device ``->probe`` callback is called for +either endpoint device in the description. If the connections are defined in +firmware, this is not a problem. It should be considered if the connection +descriptions are "built-in", and need to be added separately. + +The connection description consists of the names of the two devices with the +connection, i.e. the endpoints, and unique identifier for the connection which +is needed if there are multiple connections between the two devices. + +After a description exists, the devices in it can request reference to the other +endpoint device, or they can request the description itself. + +API +--- + +.. kernel-doc:: drivers/base/devcon.c + : functions: device_connection_find_match device_connection_find device_connection_add device_connection_remove diff --git a/Documentation/driver-api/dmaengine/dmatest.rst b/Documentation/driver-api/dmaengine/dmatest.rst index 3922c0a..7ce5e71 100644 --- a/Documentation/driver-api/dmaengine/dmatest.rst +++ b/Documentation/driver-api/dmaengine/dmatest.rst @@ -6,10 +6,16 @@ Andy Shevchenko <andriy.shevchenko@linux.intel.com> This small document introduces how to test DMA drivers using dmatest module. +.. note:: + The test suite works only on the channels that have at least one + capability of the following: DMA_MEMCPY (memory-to-memory), DMA_MEMSET + (const-to-memory or memory-to-memory, when emulated), DMA_XOR, DMA_PQ. + Part 1 - How to build the test module ===================================== The menuconfig contains an option that could be found by following path: + Device Drivers -> DMA Engine support -> DMA Test client In the configuration file the option called CONFIG_DMATEST. The dmatest could @@ -18,11 +24,11 @@ be built as module or inside kernel. Let's consider those cases. Part 2 - When dmatest is built as a module ========================================== -Example of usage: :: +Example of usage:: % modprobe dmatest channel=dma0chan0 timeout=2000 iterations=1 run=1 -...or: :: +...or:: % modprobe dmatest % echo dma0chan0 > /sys/module/dmatest/parameters/channel @@ -30,14 +36,12 @@ Example of usage: :: % echo 1 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run -...or on the kernel command line: :: +...or on the kernel command line:: dmatest.channel=dma0chan0 dmatest.timeout=2000 dmatest.iterations=1 dmatest.run=1 -..hint:: available channel list could be extracted by running the following - command: - -:: +.. hint:: + available channel list could be extracted by running the following command:: % ls -1 /sys/class/dma/ @@ -59,12 +63,12 @@ before returning. For example, the following scripts wait for 42 tests to complete before exiting. Note that if 'iterations' is set to 'infinite' then waiting is disabled. -Example: :: +Example:: % modprobe dmatest run=1 iterations=42 wait=1 % modprobe -r dmatest -...or: :: +...or:: % modprobe dmatest run=1 iterations=42 % cat /sys/module/dmatest/parameters/wait @@ -76,7 +80,7 @@ Part 3 - When built-in in the kernel The module parameters that is supplied to the kernel command line will be used for the first performed test. After user gets a control, the test could be re-run with the same or different parameters. For the details see the above -section "Part 2 - When dmatest is built as a module..." +section `Part 2 - When dmatest is built as a module`_. In both cases the module parameters are used as the actual values for the test case. You always could check them at run-time by running :: @@ -86,22 +90,22 @@ case. You always could check them at run-time by running :: Part 4 - Gathering the test results =================================== -Test results are printed to the kernel log buffer with the format: :: +Test results are printed to the kernel log buffer with the format:: "dmatest: result <channel>: <test id>: '<error msg>' with src_off=<val> dst_off=<val> len=<val> (<err code>)" -Example of output: :: - +Example of output:: % dmesg | tail -n 1 dmatest: result dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0) -The message format is unified across the different types of errors. A number in -the parens represents additional information, e.g. error code, error counter, -or status. A test thread also emits a summary line at completion listing the -number of tests executed, number that failed, and a result code. +The message format is unified across the different types of errors. A +number in the parentheses represents additional information, e.g. error +code, error counter, or status. A test thread also emits a summary line at +completion listing the number of tests executed, number that failed, and a +result code. -Example: :: +Example:: % dmesg | tail -n 1 dmatest: dma0chan0-copy0: summary 1 test, 0 failures 1000 iops 100000 KB/s (0) diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst index 4055ac7..f353783 100644 --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst @@ -112,7 +112,7 @@ Since a device is created for the sysfs interface to help load firmware as a fallback mechanism userspace can be informed of the addition of the device by relying on kobject uevents. The addition of the device into the device hierarchy means the fallback mechanism for firmware loading has been initiated. -For details of implementation refer to _request_firmware_load(), in particular +For details of implementation refer to fw_load_sysfs_fallback(), in particular on the use of dev_set_uevent_suppress() and kobject_uevent(). The kernel's kobject uevent mechanism is implemented in lib/kobject_uevent.c, diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst index cc0aea8..cf4516d 100644 --- a/Documentation/driver-api/firmware/request_firmware.rst +++ b/Documentation/driver-api/firmware/request_firmware.rst @@ -44,6 +44,20 @@ request_firmware_nowait .. kernel-doc:: drivers/base/firmware_class.c :functions: request_firmware_nowait +Special optimizations on reboot +=============================== + +Some devices have an optimization in place to enable the firmware to be +retained during system reboot. When such optimizations are used the driver +author must ensure the firmware is still available on resume from suspend, +this can be done with firmware_request_cache() insted of requesting for the +firmare to be loaded. + +firmware_request_cache() +----------------------- +.. kernel-doc:: drivers/base/firmware_class.c + :functions: firmware_request_cache + request firmware API expected driver use ======================================== diff --git a/Documentation/gpio/board.txt b/Documentation/driver-api/gpio/board.rst index 659bb19..25d62b2 100644 --- a/Documentation/gpio/board.txt +++ b/Documentation/driver-api/gpio/board.rst @@ -1,3 +1,4 @@ +============= GPIO Mappings ============= @@ -23,7 +24,7 @@ device tree bindings for your controller. GPIOs mappings are defined in the consumer device's node, in a property named <function>-gpios, where <function> is the function the driver will request -through gpiod_get(). For example: +through gpiod_get(). For example:: foo_device { compatible = "acme,foo"; @@ -40,7 +41,7 @@ it but are only supported for compatibility reasons and should not be used for newer bindings since it has been deprecated. This property will make GPIOs 15, 16 and 17 available to the driver under the -"led" function, and GPIO 1 as the "power" GPIO: +"led" function, and GPIO 1 as the "power" GPIO:: struct gpio_desc *red, *green, *blue, *power; @@ -60,13 +61,13 @@ looked up by the gpiod functions internally) used in the device tree. With above Internally, the GPIO subsystem prefixes the GPIO suffix ("gpios" or "gpio") with the string passed in con_id to get the resulting string -(snprintf(... "%s-%s", con_id, gpio_suffixes[]). +(``snprintf(... "%s-%s", con_id, gpio_suffixes[]``). ACPI ---- ACPI also supports function names for GPIOs in a similar fashion to DT. The above DT example can be converted to an equivalent ACPI description -with the help of _DSD (Device Specific Data), introduced in ACPI 5.1: +with the help of _DSD (Device Specific Data), introduced in ACPI 5.1:: Device (FOO) { Name (_CRS, ResourceTemplate () { @@ -105,12 +106,12 @@ Documentation/acpi/gpio-properties.txt. Platform Data ------------- Finally, GPIOs can be bound to devices and functions using platform data. Board -files that desire to do so need to include the following header: +files that desire to do so need to include the following header:: #include <linux/gpio/machine.h> GPIOs are mapped by the means of tables of lookups, containing instances of the -gpiod_lookup structure. Two macros are defined to help declaring such mappings: +gpiod_lookup structure. Two macros are defined to help declaring such mappings:: GPIO_LOOKUP(chip_label, chip_hwnum, con_id, flags) GPIO_LOOKUP_IDX(chip_label, chip_hwnum, con_id, idx, flags) @@ -141,22 +142,24 @@ end. The 'dev_id' field of the table is the identifier of the device that will make use of these GPIOs. It can be NULL, in which case it will be matched for calls to gpiod_get() with a NULL device. -struct gpiod_lookup_table gpios_table = { - .dev_id = "foo.0", - .table = { - GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0, GPIO_ACTIVE_HIGH), - GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1, GPIO_ACTIVE_HIGH), - GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2, GPIO_ACTIVE_HIGH), - GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW), - { }, - }, -}; +.. code-block:: c + + struct gpiod_lookup_table gpios_table = { + .dev_id = "foo.0", + .table = { + GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0, GPIO_ACTIVE_HIGH), + GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1, GPIO_ACTIVE_HIGH), + GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2, GPIO_ACTIVE_HIGH), + GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW), + { }, + }, + }; -And the table can be added by the board code as follows: +And the table can be added by the board code as follows:: gpiod_add_lookup_table(&gpios_table); -The driver controlling "foo.0" will then be able to obtain its GPIOs as follows: +The driver controlling "foo.0" will then be able to obtain its GPIOs as follows:: struct gpio_desc *red, *green, *blue, *power; diff --git a/Documentation/gpio/consumer.txt b/Documentation/driver-api/gpio/consumer.rst index d53e5b5..c71a50d 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/driver-api/gpio/consumer.rst @@ -1,3 +1,4 @@ +================================== GPIO Descriptor Consumer Interface ================================== @@ -30,10 +31,10 @@ warnings. These stubs are used for two use cases: be met with console warnings that may be perceived as intimidating. All the functions that work with the descriptor-based GPIO interface are -prefixed with gpiod_. The gpio_ prefix is used for the legacy interface. No -other function in the kernel should use these prefixes. The use of the legacy -functions is strongly discouraged, new code should use <linux/gpio/consumer.h> -and descriptors exclusively. +prefixed with ``gpiod_``. The ``gpio_`` prefix is used for the legacy +interface. No other function in the kernel should use these prefixes. The use +of the legacy functions is strongly discouraged, new code should use +<linux/gpio/consumer.h> and descriptors exclusively. Obtaining and Disposing GPIOs @@ -43,13 +44,13 @@ With the descriptor-based interface, GPIOs are identified with an opaque, non-forgeable handler that must be obtained through a call to one of the gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the device that will use the GPIO and the function the requested GPIO is supposed to -fulfill: +fulfill:: struct gpio_desc *gpiod_get(struct device *dev, const char *con_id, enum gpiod_flags flags) If a function is implemented by using several GPIOs together (e.g. a simple LED -device that displays digits), an additional index argument can be specified: +device that displays digits), an additional index argument can be specified:: struct gpio_desc *gpiod_get_index(struct device *dev, const char *con_id, unsigned int idx, @@ -84,7 +85,7 @@ occurred while trying to acquire it. This is useful to discriminate between mere errors and an absence of GPIO for optional GPIO parameters. For the common pattern where a GPIO is optional, the gpiod_get_optional() and gpiod_get_index_optional() functions can be used. These functions return NULL -instead of -ENOENT if no GPIO has been assigned to the requested function: +instead of -ENOENT if no GPIO has been assigned to the requested function:: struct gpio_desc *gpiod_get_optional(struct device *dev, const char *con_id, @@ -101,14 +102,14 @@ This is helpful to driver authors, since they do not need to special case -ENOSYS return codes. System integrators should however be careful to enable gpiolib on systems that need it. -For a function using multiple GPIOs all of those can be obtained with one call: +For a function using multiple GPIOs all of those can be obtained with one call:: struct gpio_descs *gpiod_get_array(struct device *dev, const char *con_id, enum gpiod_flags flags) This function returns a struct gpio_descs which contains an array of -descriptors: +descriptors:: struct gpio_descs { unsigned int ndescs; @@ -116,13 +117,13 @@ descriptors: } The following function returns NULL instead of -ENOENT if no GPIOs have been -assigned to the requested function: +assigned to the requested function:: struct gpio_descs *gpiod_get_array_optional(struct device *dev, const char *con_id, enum gpiod_flags flags) -Device-managed variants of these functions are also defined: +Device-managed variants of these functions are also defined:: struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id, enum gpiod_flags flags) @@ -149,11 +150,11 @@ Device-managed variants of these functions are also defined: const char *con_id, enum gpiod_flags flags) -A GPIO descriptor can be disposed of using the gpiod_put() function: +A GPIO descriptor can be disposed of using the gpiod_put() function:: void gpiod_put(struct gpio_desc *desc) -For an array of GPIOs this function can be used: +For an array of GPIOs this function can be used:: void gpiod_put_array(struct gpio_descs *descs) @@ -161,7 +162,7 @@ It is strictly forbidden to use a descriptor after calling these functions. It is also not allowed to individually release descriptors (using gpiod_put()) from an array acquired with gpiod_get_array(). -The device-managed variants are, unsurprisingly: +The device-managed variants are, unsurprisingly:: void devm_gpiod_put(struct device *dev, struct gpio_desc *desc) @@ -175,7 +176,7 @@ Setting Direction ----------------- The first thing a driver must do with a GPIO is setting its direction. If no direction-setting flags have been given to gpiod_get*(), this is done by -invoking one of the gpiod_direction_*() functions: +invoking one of the gpiod_direction_*() functions:: int gpiod_direction_input(struct gpio_desc *desc) int gpiod_direction_output(struct gpio_desc *desc, int value) @@ -189,7 +190,7 @@ of early board setup. For output GPIOs, the value provided becomes the initial output value. This helps avoid signal glitching during system startup. -A driver can also query the current direction of a GPIO: +A driver can also query the current direction of a GPIO:: int gpiod_get_direction(const struct gpio_desc *desc) @@ -206,7 +207,7 @@ Most GPIO controllers can be accessed with memory read/write instructions. Those don't need to sleep, and can safely be done from inside hard (non-threaded) IRQ handlers and similar contexts. -Use the following calls to access GPIOs from an atomic context: +Use the following calls to access GPIOs from an atomic context:: int gpiod_get_value(const struct gpio_desc *desc); void gpiod_set_value(struct gpio_desc *desc, int value); @@ -231,11 +232,11 @@ head of a queue to transmit a command and get its response. This requires sleeping, which can't be done from inside IRQ handlers. Platforms that support this type of GPIO distinguish them from other GPIOs by -returning nonzero from this call: +returning nonzero from this call:: int gpiod_cansleep(const struct gpio_desc *desc) -To access such GPIOs, a different set of accessors is defined: +To access such GPIOs, a different set of accessors is defined:: int gpiod_get_value_cansleep(const struct gpio_desc *desc) void gpiod_set_value_cansleep(struct gpio_desc *desc, int value) @@ -271,23 +272,23 @@ As an example, if the active low property for a dedicated GPIO is set, and the gpiod_set_(array)_value_xxx() passes "asserted" ("1"), the physical line level will be driven low. -To summarize: - -Function (example) line property physical line -gpiod_set_raw_value(desc, 0); don't care low -gpiod_set_raw_value(desc, 1); don't care high -gpiod_set_value(desc, 0); default (active high) low -gpiod_set_value(desc, 1); default (active high) high -gpiod_set_value(desc, 0); active low high -gpiod_set_value(desc, 1); active low low -gpiod_set_value(desc, 0); default (active high) low -gpiod_set_value(desc, 1); default (active high) high -gpiod_set_value(desc, 0); open drain low -gpiod_set_value(desc, 1); open drain high impedance -gpiod_set_value(desc, 0); open source high impedance -gpiod_set_value(desc, 1); open source high - -It is possible to override these semantics using the *set_raw/'get_raw functions +To summarize:: + + Function (example) line property physical line + gpiod_set_raw_value(desc, 0); don't care low + gpiod_set_raw_value(desc, 1); don't care high + gpiod_set_value(desc, 0); default (active high) low + gpiod_set_value(desc, 1); default (active high) high + gpiod_set_value(desc, 0); active low high + gpiod_set_value(desc, 1); active low low + gpiod_set_value(desc, 0); default (active high) low + gpiod_set_value(desc, 1); default (active high) high + gpiod_set_value(desc, 0); open drain low + gpiod_set_value(desc, 1); open drain high impedance + gpiod_set_value(desc, 0); open source high impedance + gpiod_set_value(desc, 1); open source high + +It is possible to override these semantics using the set_raw/get_raw functions but it should be avoided as much as possible, especially by system-agnostic drivers which should not need to care about the actual physical line level and worry about the logical value instead. @@ -300,7 +301,7 @@ their device will actually receive, no matter what lies between it and the GPIO line. The following set of calls ignore the active-low or open drain property of a GPIO and -work on the raw line value: +work on the raw line value:: int gpiod_get_raw_value(const struct gpio_desc *desc) void gpiod_set_raw_value(struct gpio_desc *desc, int value) @@ -308,7 +309,7 @@ work on the raw line value: void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) int gpiod_direction_output_raw(struct gpio_desc *desc, int value) -The active low state of a GPIO can also be queried using the following call: +The active low state of a GPIO can also be queried using the following call:: int gpiod_is_active_low(const struct gpio_desc *desc) @@ -318,7 +319,7 @@ should not have to care about the physical line level or open drain semantics. Access multiple GPIOs with a single function call ------------------------------------------------- -The following functions get or set the values of an array of GPIOs: +The following functions get or set the values of an array of GPIOs:: int gpiod_get_array_value(unsigned int array_size, struct gpio_desc **desc_array, @@ -361,7 +362,7 @@ The functions take three arguments: The descriptor array can be obtained using the gpiod_get_array() function or one of its variants. If the group of descriptors returned by that function matches the desired group of GPIOs, those GPIOs can be accessed by simply using -the struct gpio_descs returned by gpiod_get_array(): +the struct gpio_descs returned by gpiod_get_array():: struct gpio_descs *my_gpio_descs = gpiod_get_array(...); gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc, @@ -384,7 +385,7 @@ values are stored in value_array rather than passed back as return value. GPIOs mapped to IRQs -------------------- GPIO lines can quite often be used as IRQs. You can get the IRQ number -corresponding to a given GPIO using the following call: +corresponding to a given GPIO using the following call:: int gpiod_to_irq(const struct gpio_desc *desc) @@ -424,7 +425,7 @@ Interacting With the Legacy GPIO Subsystem Many kernel subsystems still handle GPIOs using the legacy integer-based interface. Although it is strongly encouraged to upgrade them to the safer descriptor-based API, the following two functions allow you to convert a GPIO -descriptor into the GPIO integer namespace and vice-versa: +descriptor into the GPIO integer namespace and vice-versa:: int desc_to_gpio(const struct gpio_desc *desc) struct gpio_desc *gpio_to_desc(unsigned gpio) diff --git a/Documentation/gpio/driver.txt b/Documentation/driver-api/gpio/driver.rst index 3392a0f..505ee90 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/driver-api/gpio/driver.rst @@ -1,3 +1,4 @@ +================================ GPIO Descriptor Driver Interface ================================ @@ -53,9 +54,9 @@ common to each controller of that type: The code implementing a gpio_chip should support multiple instances of the controller, possibly using the driver model. That code will configure each -gpio_chip and issue gpiochip_add[_data]() or devm_gpiochip_add_data(). -Removing a GPIO controller should be rare; use [devm_]gpiochip_remove() when -it is unavoidable. +gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``. +Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()`` +when it is unavoidable. Often a gpio_chip is part of an instance-specific structure with states not exposed by the GPIO interfaces, such as addressing, power management, and more. @@ -115,7 +116,7 @@ GPIOs with open drain/source support Open drain (CMOS) or open collector (TTL) means the line is not actively driven high: instead you provide the drain/collector as output, so when the transistor -is not open, it will present a high-impedance (tristate) to the external rail. +is not open, it will present a high-impedance (tristate) to the external rail:: CMOS CONFIGURATION TTL CONFIGURATION @@ -148,19 +149,19 @@ level-shift to the higher VDD. Integrated electronics often have an output driver stage in the form of a CMOS "totem-pole" with one N-MOS and one P-MOS transistor where one of them drives the line high and one of them drives the line low. This is called a push-pull -output. The "totem-pole" looks like so: - - VDD - | - OD ||--+ - +--/ ---o|| P-MOS-FET - | ||--+ -IN --+ +----- out - | ||--+ - +--/ ----|| N-MOS-FET - OS ||--+ - | - GND +output. The "totem-pole" looks like so:: + + VDD + | + OD ||--+ + +--/ ---o|| P-MOS-FET + | ||--+ + IN --+ +----- out + | ||--+ + +--/ ----|| N-MOS-FET + OS ||--+ + | + GND The desired output signal (e.g. coming directly from some GPIO output register) arrives at IN. The switches named "OD" and "OS" are normally closed, creating @@ -219,8 +220,9 @@ systems simultaneously: gpio and irq. RT_FULL: a realtime compliant GPIO driver should not use spinlock_t or any sleepable APIs (like PM runtime) as part of its irq_chip implementation. -- spinlock_t should be replaced with raw_spinlock_t [1]. -- If sleepable APIs have to be used, these can be done from the .irq_bus_lock() + +* spinlock_t should be replaced with raw_spinlock_t [1]. +* If sleepable APIs have to be used, these can be done from the .irq_bus_lock() and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks on an irqchip. Create the callbacks if needed [2]. @@ -232,12 +234,12 @@ GPIO irqchips usually fall in one of two categories: system interrupt controller. This means that the GPIO irqchip handler will be called immediately from the parent irqchip, while holding the IRQs disabled. The GPIO irqchip will then end up calling something like this - sequence in its interrupt handler: + sequence in its interrupt handler:: - static irqreturn_t foo_gpio_irq(int irq, void *data) - chained_irq_enter(...); - generic_handle_irq(...); - chained_irq_exit(...); + static irqreturn_t foo_gpio_irq(int irq, void *data) + chained_irq_enter(...); + generic_handle_irq(...); + chained_irq_exit(...); Chained GPIO irqchips typically can NOT set the .can_sleep flag on struct gpio_chip, as everything happens directly in the callbacks: no @@ -252,7 +254,7 @@ GPIO irqchips usually fall in one of two categories: (for example, see [3]). Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled, so the IRQ core will complain if it is called from an IRQ handler which is - forced to a thread. The "fake?" raw lock can be used to W/A this problem: + forced to a thread. The "fake?" raw lock can be used to W/A this problem:: raw_spinlock_t wa_lock; static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank) @@ -265,11 +267,11 @@ GPIO irqchips usually fall in one of two categories: but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is performed by generic IRQ handler which is configured using request_irq(). The GPIO irqchip will then end up calling something like this sequence in - its interrupt handler: + its interrupt handler:: - static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id) - for each detected GPIO IRQ - generic_handle_irq(...); + static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id) + for each detected GPIO IRQ + generic_handle_irq(...); RT_FULL: Such kind of handlers will be forced threaded on -RT, as result IRQ core will complain that generic_handle_irq() is called with IRQ enabled and @@ -282,11 +284,11 @@ GPIO irqchips usually fall in one of two categories: in a quick IRQ handler with IRQs disabled. Instead they need to spawn a thread and then mask the parent IRQ line until the interrupt is handled by the driver. The hallmark of this driver is to call something like - this in its interrupt handler: + this in its interrupt handler:: - static irqreturn_t foo_gpio_irq(int irq, void *data) - ... - handle_nested_irq(irq); + static irqreturn_t foo_gpio_irq(int irq, void *data) + ... + handle_nested_irq(irq); The hallmark of threaded GPIO irqchips is that they set the .can_sleep flag on struct gpio_chip to true, indicating that this chip may sleep @@ -359,12 +361,12 @@ below exists. Locking IRQ usage ----------------- Input GPIOs can be used as IRQ signals. When this happens, a driver is requested -to mark the GPIO as being used as an IRQ: +to mark the GPIO as being used as an IRQ:: int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset) This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock -is released: +is released:: void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset) @@ -408,7 +410,7 @@ Sometimes it is useful to allow a GPIO chip driver to request its own GPIO descriptors through the gpiolib API. Using gpio_request() for this purpose does not help since it pins the module to the kernel forever (it calls try_module_get()). A GPIO driver can use the following functions instead -to request and free descriptors without being pinned to the kernel forever. +to request and free descriptors without being pinned to the kernel forever:: struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc, const char *label) @@ -422,6 +424,6 @@ These functions must be used with care since they do not affect module use count. Do not use the functions to request gpio descriptors not owned by the calling driver. -[1] http://www.spinics.net/lists/linux-omap/msg120425.html -[2] https://lkml.org/lkml/2015/9/25/494 -[3] https://lkml.org/lkml/2015/9/25/495 +* [1] http://www.spinics.net/lists/linux-omap/msg120425.html +* [2] https://lkml.org/lkml/2015/9/25/494 +* [3] https://lkml.org/lkml/2015/9/25/495 diff --git a/Documentation/gpio/drivers-on-gpio.txt b/Documentation/driver-api/gpio/drivers-on-gpio.rst index a2ccbab..0194838 100644 --- a/Documentation/gpio/drivers-on-gpio.txt +++ b/Documentation/driver-api/gpio/drivers-on-gpio.rst @@ -1,3 +1,4 @@ +============================ Subsystem drivers using GPIO ============================ diff --git a/Documentation/driver-api/gpio.rst b/Documentation/driver-api/gpio/index.rst index 6dd4aa6..6a374de 100644 --- a/Documentation/driver-api/gpio.rst +++ b/Documentation/driver-api/gpio/index.rst @@ -2,6 +2,18 @@ General Purpose Input/Output (GPIO) =================================== +Contents: + +.. toctree:: + :maxdepth: 2 + + intro + driver + consumer + board + drivers-on-gpio + legacy + Core ==== @@ -11,15 +23,6 @@ Core .. kernel-doc:: drivers/gpio/gpiolib.c :export: -Legacy API -========== - -The functions listed in this section are deprecated. The GPIO descriptor based -API described above should be used in new code. - -.. kernel-doc:: drivers/gpio/gpiolib-legacy.c - :export: - ACPI support ============ diff --git a/Documentation/gpio/gpio.txt b/Documentation/driver-api/gpio/intro.rst index cd9b356..7459148 100644 --- a/Documentation/gpio/gpio.txt +++ b/Documentation/driver-api/gpio/intro.rst @@ -1,3 +1,8 @@ +============ +Introduction +============ + + GPIO Interfaces =============== @@ -9,9 +14,9 @@ Due to the history of GPIO interfaces in the kernel, there are two different ways to obtain and use GPIOs: - The descriptor-based interface is the preferred way to manipulate GPIOs, -and is described by all the files in this directory excepted gpio-legacy.txt. + and is described by all the files in this directory excepted gpio-legacy.txt. - The legacy integer-based interface which is considered deprecated (but still -usable for compatibility reasons) is documented in gpio-legacy.txt. + usable for compatibility reasons) is documented in gpio-legacy.txt. The remainder of this document applies to the new descriptor-based interface. gpio-legacy.txt contains the same information applied to the legacy diff --git a/Documentation/gpio/gpio-legacy.txt b/Documentation/driver-api/gpio/legacy.rst index 8356d0e..5e9421e 100644 --- a/Documentation/gpio/gpio-legacy.txt +++ b/Documentation/driver-api/gpio/legacy.rst @@ -1,4 +1,6 @@ -GPIO Interfaces +====================== +Legacy GPIO Interfaces +====================== This provides an overview of GPIO access conventions on Linux. @@ -129,7 +131,7 @@ The first thing a system should do with a GPIO is allocate it, using the gpio_request() call; see later. One of the next things to do with a GPIO, often in board setup code when -setting up a platform_device using the GPIO, is mark its direction: +setting up a platform_device using the GPIO, is mark its direction:: /* set as input or output, returning 0 or negative errno */ int gpio_direction_input(unsigned gpio); @@ -164,7 +166,7 @@ Those don't need to sleep, and can safely be done from inside hard (nonthreaded) IRQ handlers and similar contexts. Use the following calls to access such GPIOs, -for which gpio_cansleep() will always return false (see below): +for which gpio_cansleep() will always return false (see below):: /* GPIO INPUT: return zero or nonzero */ int gpio_get_value(unsigned gpio); @@ -201,11 +203,11 @@ This requires sleeping, which can't be done from inside IRQ handlers. Platforms that support this type of GPIO distinguish them from other GPIOs by returning nonzero from this call (which requires a valid GPIO number, -which should have been previously allocated with gpio_request): +which should have been previously allocated with gpio_request):: int gpio_cansleep(unsigned gpio); -To access such GPIOs, a different set of accessors is defined: +To access such GPIOs, a different set of accessors is defined:: /* GPIO INPUT: return zero or nonzero, might sleep */ int gpio_get_value_cansleep(unsigned gpio); @@ -222,27 +224,27 @@ Other than the fact that these accessors might sleep, and will work on GPIOs that can't be accessed from hardIRQ handlers, these calls act the same as the spinlock-safe calls. - ** IN ADDITION ** calls to setup and configure such GPIOs must be made +**IN ADDITION** calls to setup and configure such GPIOs must be made from contexts which may sleep, since they may need to access the GPIO -controller chip too: (These setup calls are usually made from board -setup or driver probe/teardown code, so this is an easy constraint.) +controller chip too (These setup calls are usually made from board +setup or driver probe/teardown code, so this is an easy constraint.):: - gpio_direction_input() - gpio_direction_output() - gpio_request() + gpio_direction_input() + gpio_direction_output() + gpio_request() -## gpio_request_one() -## gpio_request_array() -## gpio_free_array() + ## gpio_request_one() + ## gpio_request_array() + ## gpio_free_array() - gpio_free() - gpio_set_debounce() + gpio_free() + gpio_set_debounce() Claiming and Releasing GPIOs ---------------------------- -To help catch system configuration errors, two calls are defined. +To help catch system configuration errors, two calls are defined:: /* request GPIO, returning 0 or negative errno. * non-null labels may be useful for diagnostics. @@ -296,7 +298,7 @@ Also note that it's your responsibility to have stopped using a GPIO before you free it. Considering in most cases GPIOs are actually configured right after they -are claimed, three additional calls are defined: +are claimed, three additional calls are defined:: /* request a single GPIO, with initial configuration specified by * 'flags', identical to gpio_request() wrt other arguments and @@ -347,7 +349,7 @@ to make the pin LOW. The pin is make to HIGH by driving value 1 in output mode. In the future, these flags can be extended to support more properties. Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is -introduced to encapsulate all three fields as: +introduced to encapsulate all three fields as:: struct gpio { unsigned gpio; @@ -355,7 +357,7 @@ introduced to encapsulate all three fields as: const char *label; }; -A typical example of usage: +A typical example of usage:: static struct gpio leds_gpios[] = { { 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* default to ON */ @@ -380,7 +382,7 @@ GPIOs mapped to IRQs -------------------- GPIO numbers are unsigned integers; so are IRQ numbers. These make up two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can -map between them using calls like: +map between them using calls like:: /* map GPIO numbers to IRQ numbers */ int gpio_to_irq(unsigned gpio); @@ -446,12 +448,12 @@ A GPIO controller on a SOC might be tightly coupled with the pinctrl subsystem, in the sense that the pins can be used by other functions together with an optional gpio feature. We have already covered the case where e.g. a GPIO controller need to reserve a pin or set the -direction of a pin by calling any of: +direction of a pin by calling any of:: -pinctrl_gpio_request() -pinctrl_gpio_free() -pinctrl_gpio_direction_input() -pinctrl_gpio_direction_output() + pinctrl_gpio_request() + pinctrl_gpio_free() + pinctrl_gpio_direction_input() + pinctrl_gpio_direction_output() But how does the pin control subsystem cross-correlate the GPIO numbers (which are a global business) to a certain pin on a certain @@ -565,7 +567,7 @@ If neither of these options are selected, the platform does not support GPIOs through GPIO-lib and the code cannot be enabled by the user. Trivial implementations of those functions can directly use framework -code, which always dispatches through the gpio_chip: +code, which always dispatches through the gpio_chip:: #define gpio_get_value __gpio_get_value #define gpio_set_value __gpio_set_value @@ -731,7 +733,7 @@ the correct GPIO number to use for a given signal. Exporting from Kernel code -------------------------- Kernel code can explicitly manage exports of GPIOs which have already been -requested using gpio_request(): +requested using gpio_request():: /* export the GPIO to userspace */ int gpio_export(unsigned gpio, bool direction_may_change); @@ -756,3 +758,13 @@ After the GPIO has been exported, gpio_export_link() allows creating symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can use this to provide the interface under their own device in sysfs with a descriptive name. + + +API Reference +============= + +The functions listed in this section are deprecated. The GPIO descriptor based +API should be used in new code. + +.. kernel-doc:: drivers/gpio/gpiolib-legacy.c + :export: diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index e9b41b1..6d8352c 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -44,7 +44,7 @@ available subsections can be seen below. uio-howto firmware/index pinctl - gpio + gpio/index misc_devices dmaengine/index slimbus diff --git a/Documentation/driver-api/slimbus.rst b/Documentation/driver-api/slimbus.rst index 7555ecd..a97449c 100644 --- a/Documentation/driver-api/slimbus.rst +++ b/Documentation/driver-api/slimbus.rst @@ -90,7 +90,7 @@ controller resets the bus. This notification allows the driver to take necessary steps to boot the device so that it's functional after the bus has been reset. Driver and Controller APIs: --------------------------- +--------------------------- .. kernel-doc:: include/linux/slimbus.h :internal: diff --git a/Documentation/driver-api/uio-howto.rst b/Documentation/driver-api/uio-howto.rst index 693e3bd..92056c2 100644 --- a/Documentation/driver-api/uio-howto.rst +++ b/Documentation/driver-api/uio-howto.rst @@ -709,6 +709,11 @@ The vmbus device regions are mapped into uio device resources: 3) Network receive buffer region 4) Network send buffer region +If a subchannel is created by a request to host, then the uio_hv_generic +device driver will create a sysfs binary file for the per-channel ring buffer. +For example: + /sys/bus/vmbus/devices/3811fe4d-0fa0-4b62-981a-74fc1084c757/channels/21/ring + Further information =================== diff --git a/Documentation/driver-api/usb/typec.rst b/Documentation/driver-api/usb/typec.rst index 8a7249f..feb3194 100644 --- a/Documentation/driver-api/usb/typec.rst +++ b/Documentation/driver-api/usb/typec.rst @@ -61,7 +61,7 @@ Registering the ports The port drivers will describe every Type-C port they control with struct typec_capability data structure, and register them with the following API: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_register_port typec_unregister_port When registering the ports, the prefer_role member in struct typec_capability @@ -80,7 +80,7 @@ typec_partner_desc. The class copies the details of the partner during registration. The class offers the following API for registering/unregistering partners. -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_register_partner typec_unregister_partner The class will provide a handle to struct typec_partner if the registration was @@ -92,7 +92,7 @@ should include handle to struct usb_pd_identity instance. The class will then create a sysfs directory for the identity under the partner device. The result of Discover Identity command can then be reported with the following API: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_partner_set_identity Registering Cables @@ -113,7 +113,7 @@ typec_cable_desc and about a plug in struct typec_plug_desc. The class copies the details during registration. The class offers the following API for registering/unregistering cables and their plugs: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_register_cable typec_unregister_cable typec_register_plug typec_unregister_plug The class will provide a handle to struct typec_cable and struct typec_plug if @@ -125,7 +125,7 @@ include handle to struct usb_pd_identity instance. The class will then create a sysfs directory for the identity under the cable device. The result of Discover Identity command can then be reported with the following API: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_cable_set_identity Notifications @@ -135,7 +135,7 @@ When the partner has executed a role change, or when the default roles change during connection of a partner or cable, the port driver must use the following APIs to report it to the class: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_set_data_role typec_set_pwr_role typec_set_vconn_role typec_set_pwr_opmode Alternate Modes @@ -150,7 +150,7 @@ and struct typec_altmode_desc which is a container for all the supported modes. Ports that support Alternate Modes need to register each SVID they support with the following API: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_port_register_altmode If a partner or cable plug provides a list of SVIDs as response to USB Power @@ -159,12 +159,12 @@ registered. API for the partners: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_partner_register_altmode API for the Cable Plugs: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_plug_register_altmode So ports, partners and cable plugs will register the alternate modes with their @@ -172,11 +172,62 @@ own functions, but the registration will always return a handle to struct typec_altmode on success, or NULL. The unregistration will happen with the same function: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_unregister_altmode If a partner or cable plug enters or exits a mode, the port driver needs to notify the class with the following API: -.. kernel-doc:: drivers/usb/typec/typec.c +.. kernel-doc:: drivers/usb/typec/class.c :functions: typec_altmode_update_active + +Multiplexer/DeMultiplexer Switches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +USB Type-C connectors may have one or more mux/demux switches behind them. Since +the plugs can be inserted right-side-up or upside-down, a switch is needed to +route the correct data pairs from the connector to the USB controllers. If +Alternate or Accessory Modes are supported, another switch is needed that can +route the pins on the connector to some other component besides USB. USB Type-C +Connector Class supplies an API for registering those switches. + +.. kernel-doc:: drivers/usb/typec/mux.c + :functions: typec_switch_register typec_switch_unregister typec_mux_register typec_mux_unregister + +In most cases the same physical mux will handle both the orientation and mode. +However, as the port drivers will be responsible for the orientation, and the +alternate mode drivers for the mode, the two are always separated into their +own logical components: "mux" for the mode and "switch" for the orientation. + +When a port is registered, USB Type-C Connector Class requests both the mux and +the switch for the port. The drivers can then use the following API for +controlling them: + +.. kernel-doc:: drivers/usb/typec/class.c + :functions: typec_set_orientation typec_set_mode + +If the connector is dual-role capable, there may also be a switch for the data +role. USB Type-C Connector Class does not supply separate API for them. The +port drivers can use USB Role Class API with those. + +Illustration of the muxes behind a connector that supports an alternate mode: + + ------------------------ + | Connector | + ------------------------ + | | + ------------------------ + \ Orientation / + -------------------- + | + -------------------- + / Mode \ + ------------------------ + / \ + ------------------------ -------------------- + | Alt Mode | / USB Role \ + ------------------------ ------------------------ + / \ + ------------------------ ------------------------ + | USB Host | | USB Device | + ------------------------ ------------------------ diff --git a/Documentation/driver-api/usb/writing_musb_glue_layer.rst b/Documentation/driver-api/usb/writing_musb_glue_layer.rst index e90e8fa..5bf7152 100644 --- a/Documentation/driver-api/usb/writing_musb_glue_layer.rst +++ b/Documentation/driver-api/usb/writing_musb_glue_layer.rst @@ -718,6 +718,3 @@ http://www.maximintegrated.com/app-notes/index.mvp/id/1822 Texas Instruments USB Configuration Wiki Page: http://processors.wiki.ti.com/index.php/Usbgeneralpage - -Analog Devices Blackfin MUSB Configuration: -http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:musb diff --git a/Documentation/features/core/BPF-JIT/arch-support.txt b/Documentation/features/core/BPF-JIT/arch-support.txt index 5575d2d..0b96b4e 100644 --- a/Documentation/features/core/BPF-JIT/arch-support.txt +++ b/Documentation/features/core/BPF-JIT/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | TODO | | sparc: | ok | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/core/generic-idle-thread/arch-support.txt b/Documentation/features/core/generic-idle-thread/arch-support.txt index abb5f27..372a2b1 100644 --- a/Documentation/features/core/generic-idle-thread/arch-support.txt +++ b/Documentation/features/core/generic-idle-thread/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | ok | - | blackfin: | ok | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | ok | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | ok | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | ok | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt index dbdaffc..ad97217 100644 --- a/Documentation/features/core/jump-labels/arch-support.txt +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | TODO | | sparc: | ok | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/core/tracehook/arch-support.txt b/Documentation/features/core/tracehook/arch-support.txt index dfb638c..36ee7be 100644 --- a/Documentation/features/core/tracehook/arch-support.txt +++ b/Documentation/features/core/tracehook/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | ok | - | blackfin: | ok | | c6x: | ok | - | cris: | TODO | - | frv: | ok | | h8300: | TODO | | hexagon: | ok | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | ok | | microblaze: | TODO | | mips: | ok | - | mn10300: | ok | | nios2: | ok | | openrisc: | ok | | parisc: | ok | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | ok | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index 3406fae..f5c99fa 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | 64-bit only diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt b/Documentation/features/debug/gcov-profile-all/arch-support.txt index 830dbe8..5170a993 100644 --- a/Documentation/features/debug/gcov-profile-all/arch-support.txt +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | ok | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/kgdb/arch-support.txt b/Documentation/features/debug/kgdb/arch-support.txt index 0217bf6..13b6e99 100644 --- a/Documentation/features/debug/kgdb/arch-support.txt +++ b/Documentation/features/debug/kgdb/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | ok | - | blackfin: | ok | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | ok | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | ok | | mips: | ok | - | mn10300: | ok | | nios2: | ok | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | TODO | - | score: | TODO | | sh: | ok | | sparc: | ok | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index 1e84be3c..419bb38 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt index 529f66e..52b3ace 100644 --- a/Documentation/features/debug/kprobes/arch-support.txt +++ b/Documentation/features/debug/kprobes/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | ok | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt index 4335324..180d244 100644 --- a/Documentation/features/debug/kretprobes/arch-support.txt +++ b/Documentation/features/debug/kretprobes/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | ok | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/optprobes/arch-support.txt b/Documentation/features/debug/optprobes/arch-support.txt index f559f1b..0a1241f 100644 --- a/Documentation/features/debug/optprobes/arch-support.txt +++ b/Documentation/features/debug/optprobes/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt index 59a4c9f..5700195 100644 --- a/Documentation/features/debug/stackprotector/arch-support.txt +++ b/Documentation/features/debug/stackprotector/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | ok | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt index 53ed42b..0b8d922 100644 --- a/Documentation/features/debug/uprobes/arch-support.txt +++ b/Documentation/features/debug/uprobes/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/debug/user-ret-profiler/arch-support.txt b/Documentation/features/debug/user-ret-profiler/arch-support.txt index 1494439..13852ae 100644 --- a/Documentation/features/debug/user-ret-profiler/arch-support.txt +++ b/Documentation/features/debug/user-ret-profiler/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/io/dma-api-debug/arch-support.txt b/Documentation/features/io/dma-api-debug/arch-support.txt index 6be9206..e438ed6 100644 --- a/Documentation/features/io/dma-api-debug/arch-support.txt +++ b/Documentation/features/io/dma-api-debug/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | ok | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | ok | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | ok | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt index 0eb08e1..47f64a4 100644 --- a/Documentation/features/io/dma-contiguous/arch-support.txt +++ b/Documentation/features/io/dma-contiguous/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/io/sg-chain/arch-support.txt b/Documentation/features/io/sg-chain/arch-support.txt index 514ad34..07f357f 100644 --- a/Documentation/features/io/sg-chain/arch-support.txt +++ b/Documentation/features/io/sg-chain/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | TODO | | sparc: | ok | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/lib/strncasecmp/arch-support.txt b/Documentation/features/lib/strncasecmp/arch-support.txt index 532c6f0..4f3a6a0 100644 --- a/Documentation/features/lib/strncasecmp/arch-support.txt +++ b/Documentation/features/lib/strncasecmp/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | TODO | diff --git a/Documentation/features/list-arch.sh b/Documentation/features/list-arch.sh index c16b5b5..1ec47c3 100755 --- a/Documentation/features/list-arch.sh +++ b/Documentation/features/list-arch.sh @@ -17,7 +17,7 @@ for F in */*/arch-support.txt; do N=$(grep -h "^# Feature name:" $F | cut -c25-) C=$(grep -h "^# Kconfig:" $F | cut -c25-) D=$(grep -h "^# description:" $F | cut -c25-) - S=$(grep -hw $ARCH $F | cut -d\| -f3) + S=$(grep -hv "^#" $F | grep -w $ARCH | cut -d\| -f3) printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D" done diff --git a/Documentation/features/locking/cmpxchg-local/arch-support.txt b/Documentation/features/locking/cmpxchg-local/arch-support.txt index f3eec26..482a0b0 100644 --- a/Documentation/features/locking/cmpxchg-local/arch-support.txt +++ b/Documentation/features/locking/cmpxchg-local/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | ok | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt index 9756abc..bb35c5b 100644 --- a/Documentation/features/locking/lockdep/arch-support.txt +++ b/Documentation/features/locking/lockdep/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | ok | - | blackfin: | ok | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | ok | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | ok | | microblaze: | ok | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | ok | | sh: | ok | | sparc: | ok | - | tile: | ok | | um: | ok | | unicore32: | ok | | x86: | ok | diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt index 62f4ee5..627e9a6 100644 --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt index 321b32f..9edda21 100644 --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/locking/rwsem-optimized/arch-support.txt b/Documentation/features/locking/rwsem-optimized/arch-support.txt index 79bfa4d..8d9afb1 100644 --- a/Documentation/features/locking/rwsem-optimized/arch-support.txt +++ b/Documentation/features/locking/rwsem-optimized/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | ok | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt b/Documentation/features/perf/kprobes-event/arch-support.txt index 00f1606..d01239e 100644 --- a/Documentation/features/perf/kprobes-event/arch-support.txt +++ b/Documentation/features/perf/kprobes-event/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | ok | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | TODO | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/perf/perf-regs/arch-support.txt b/Documentation/features/perf/perf-regs/arch-support.txt index 7d516ea..458faba 100644 --- a/Documentation/features/perf/perf-regs/arch-support.txt +++ b/Documentation/features/perf/perf-regs/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/perf/perf-stackdump/arch-support.txt b/Documentation/features/perf/perf-stackdump/arch-support.txt index f974b8d..545d01c 100644 --- a/Documentation/features/perf/perf-stackdump/arch-support.txt +++ b/Documentation/features/perf/perf-stackdump/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt index 2c815a7..85a6c9d 100644 --- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt +++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt @@ -33,28 +33,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/sched/numa-balancing/arch-support.txt b/Documentation/features/sched/numa-balancing/arch-support.txt index 1d3c0f6..3475088 100644 --- a/Documentation/features/sched/numa-balancing/arch-support.txt +++ b/Documentation/features/sched/numa-balancing/arch-support.txt @@ -10,28 +10,20 @@ | arc: | .. | | arm: | .. | | arm64: | .. | - | blackfin: | .. | | c6x: | .. | - | cris: | .. | - | frv: | .. | | h8300: | .. | | hexagon: | .. | | ia64: | TODO | - | m32r: | .. | | m68k: | .. | - | metag: | .. | | microblaze: | .. | | mips: | TODO | - | mn10300: | .. | | nios2: | .. | | openrisc: | .. | | parisc: | .. | | powerpc: | ok | | s390: | .. | - | score: | .. | | sh: | .. | | sparc: | TODO | - | tile: | TODO | | um: | .. | | unicore32: | .. | | x86: | ok | diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt index a32d5b2..e4fad58 100644 --- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | ok | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | ok | | um: | ok | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/time/arch-tick-broadcast/arch-support.txt b/Documentation/features/time/arch-tick-broadcast/arch-support.txt index caee8f6..8052904 100644 --- a/Documentation/features/time/arch-tick-broadcast/arch-support.txt +++ b/Documentation/features/time/arch-tick-broadcast/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | TODO | diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt index 1cd87f6..7c76b94 100644 --- a/Documentation/features/time/clockevents/arch-support.txt +++ b/Documentation/features/time/clockevents/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | ok | - | blackfin: | ok | | c6x: | ok | - | cris: | ok | - | frv: | TODO | | h8300: | ok | | hexagon: | ok | | ia64: | TODO | - | m32r: | TODO | | m68k: | ok | - | metag: | ok | | microblaze: | ok | | mips: | ok | - | mn10300: | ok | | nios2: | ok | | openrisc: | ok | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | ok | | sh: | ok | | sparc: | ok | - | tile: | ok | | um: | ok | | unicore32: | ok | | x86: | ok | diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt index e6d7c7b..9433b3e 100644 --- a/Documentation/features/time/context-tracking/arch-support.txt +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | ok | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt index 15c6071..212dde0 100644 --- a/Documentation/features/time/irq-time-acct/arch-support.txt +++ b/Documentation/features/time/irq-time-acct/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | .. | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | .. | | powerpc: | .. | | s390: | .. | - | score: | TODO | | sh: | TODO | | sparc: | .. | - | tile: | .. | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/time/modern-timekeeping/arch-support.txt b/Documentation/features/time/modern-timekeeping/arch-support.txt index baee761..4074028 100644 --- a/Documentation/features/time/modern-timekeeping/arch-support.txt +++ b/Documentation/features/time/modern-timekeeping/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | TODO | | arm64: | ok | - | blackfin: | TODO | | c6x: | ok | - | cris: | TODO | - | frv: | ok | | h8300: | ok | | hexagon: | ok | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | ok | | microblaze: | ok | | mips: | ok | - | mn10300: | ok | | nios2: | ok | | openrisc: | ok | | parisc: | ok | | powerpc: | ok | | s390: | ok | - | score: | ok | | sh: | ok | | sparc: | ok | - | tile: | ok | | um: | ok | | unicore32: | ok | | x86: | ok | diff --git a/Documentation/features/time/virt-cpuacct/arch-support.txt b/Documentation/features/time/virt-cpuacct/arch-support.txt index 9129530..a394d88 100644 --- a/Documentation/features/time/virt-cpuacct/arch-support.txt +++ b/Documentation/features/time/virt-cpuacct/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | TODO | | sparc: | ok | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt index f6829af..082f93d 100644 --- a/Documentation/features/vm/ELF-ASLR/arch-support.txt +++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | ok | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/vm/PG_uncached/arch-support.txt b/Documentation/features/vm/PG_uncached/arch-support.txt index 1a09ea9..605e0ab 100644 --- a/Documentation/features/vm/PG_uncached/arch-support.txt +++ b/Documentation/features/vm/PG_uncached/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/vm/THP/arch-support.txt b/Documentation/features/vm/THP/arch-support.txt index d170e62..7a8eb0b 100644 --- a/Documentation/features/vm/THP/arch-support.txt +++ b/Documentation/features/vm/THP/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | ok | - | blackfin: | .. | | c6x: | .. | - | cris: | .. | - | frv: | .. | | h8300: | .. | | hexagon: | .. | | ia64: | TODO | - | m32r: | .. | | m68k: | .. | - | metag: | TODO | | microblaze: | .. | | mips: | ok | - | mn10300: | .. | | nios2: | .. | | openrisc: | .. | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | .. | | sh: | .. | | sparc: | ok | - | tile: | TODO | | um: | .. | | unicore32: | .. | | x86: | ok | diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt index abfab40..35fb99b 100644 --- a/Documentation/features/vm/TLB/arch-support.txt +++ b/Documentation/features/vm/TLB/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | .. | - | cris: | .. | - | frv: | .. | | h8300: | .. | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | .. | - | metag: | TODO | | microblaze: | .. | | mips: | TODO | - | mn10300: | TODO | | nios2: | .. | | openrisc: | .. | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | .. | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | .. | | unicore32: | .. | | x86: | ok | diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt index f81f09b..ed8b943 100644 --- a/Documentation/features/vm/huge-vmap/arch-support.txt +++ b/Documentation/features/vm/huge-vmap/arch-support.txt @@ -10,28 +10,20 @@ | arc: | TODO | | arm: | TODO | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | TODO | | s390: | TODO | - | score: | TODO | | sh: | TODO | | sparc: | TODO | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/vm/ioremap_prot/arch-support.txt b/Documentation/features/vm/ioremap_prot/arch-support.txt index 0cc3e11..589947b 100644 --- a/Documentation/features/vm/ioremap_prot/arch-support.txt +++ b/Documentation/features/vm/ioremap_prot/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | TODO | | arm64: | TODO | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | TODO | - | score: | TODO | | sh: | ok | | sparc: | TODO | - | tile: | ok | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/features/vm/numa-memblock/arch-support.txt b/Documentation/features/vm/numa-memblock/arch-support.txt index 9a3fdac..8b8bea0 100644 --- a/Documentation/features/vm/numa-memblock/arch-support.txt +++ b/Documentation/features/vm/numa-memblock/arch-support.txt @@ -10,28 +10,20 @@ | arc: | .. | | arm: | .. | | arm64: | .. | - | blackfin: | .. | | c6x: | .. | - | cris: | .. | - | frv: | .. | | h8300: | .. | | hexagon: | .. | | ia64: | ok | - | m32r: | TODO | | m68k: | .. | - | metag: | ok | | microblaze: | ok | | mips: | ok | - | mn10300: | TODO | | nios2: | .. | | openrisc: | .. | | parisc: | .. | | powerpc: | ok | | s390: | ok | - | score: | ok | | sh: | ok | | sparc: | ok | - | tile: | TODO | | um: | .. | | unicore32: | .. | | x86: | ok | diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt index dfaa39e..055004f 100644 --- a/Documentation/features/vm/pte_special/arch-support.txt +++ b/Documentation/features/vm/pte_special/arch-support.txt @@ -10,28 +10,20 @@ | arc: | ok | | arm: | ok | | arm64: | ok | - | blackfin: | TODO | | c6x: | TODO | - | cris: | TODO | - | frv: | TODO | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | - | m32r: | TODO | | m68k: | TODO | - | metag: | TODO | | microblaze: | TODO | | mips: | TODO | - | mn10300: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | | s390: | ok | - | score: | TODO | | sh: | ok | | sparc: | ok | - | tile: | TODO | | um: | TODO | | unicore32: | TODO | | x86: | ok | diff --git a/Documentation/filesystems/cifs/README b/Documentation/filesystems/cifs/README index a9da515..99ce3d2 100644 --- a/Documentation/filesystems/cifs/README +++ b/Documentation/filesystems/cifs/README @@ -11,13 +11,14 @@ Information Foundation. CIFS and now SMB3 has now become a defacto standard for interoperating between Macs and Windows and major NAS appliances. Please see + MS-SMB2 (for detailed SMB2/SMB3/SMB3.1.1 protocol specification) http://protocolfreedom.org/ and http://samba.org/samba/PFIF/ for more details. For questions or bug reports please contact: - sfrench@samba.org (sfrench@us.ibm.com) + smfrench@gmail.com See the project page at: https://wiki.samba.org/index.php/LinuxCIFS_utils @@ -37,15 +38,15 @@ Installation instructions: ========================= If you have built the CIFS vfs as module (successfully) simply type "make modules_install" (or if you prefer, manually copy the file to -the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.o). +the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.ko). If you have built the CIFS vfs into the kernel itself, follow the instructions for your distribution on how to install a new kernel (usually you would simply type "make install"). -If you do not have the utility mount.cifs (in the Samba 3.0 source tree and on -the CIFS VFS web site) copy it to the same directory in which mount.smbfs and -similar files reside (usually /sbin). Although the helper software is not +If you do not have the utility mount.cifs (in the Samba 4.x source tree and on +the CIFS VFS web site) copy it to the same directory in which mount helpers +reside (usually /sbin). Although the helper software is not required, mount.cifs is recommended. Most distros include a "cifs-utils" package that includes this utility so it is recommended to install this. @@ -118,10 +119,13 @@ this can become unwieldy when potential mount targets include many or unpredictable UNC names. Samba Considerations -==================== -To get the maximum benefit from the CIFS VFS, we recommend using a server that -supports the SNIA CIFS Unix Extensions standard (e.g. Samba 2.2.5 or later or -Samba 3.0) but the CIFS vfs works fine with a wide variety of CIFS servers. +==================== +Most current servers support SMB2.1 and SMB3 which are more secure, +but there are useful protocol extensions for the older less secure CIFS +dialect, so to get the maximum benefit if mounting using the older dialect +(CIFS/SMB1), we recommend using a server that supports the SNIA CIFS +Unix Extensions standard (e.g. almost any version of Samba ie version +2.2.5 or later) but the CIFS vfs works fine with a wide variety of CIFS servers. Note that uid, gid and file permissions will display default values if you do not have a server that supports the Unix extensions for CIFS (such as Samba 2.2.5 or later). To enable the Unix CIFS Extensions in the Samba server, add @@ -603,11 +607,6 @@ Stats Lists summary resource usage information as well as per in the kernel configuration. Configuration pseudo-files: -PacketSigningEnabled If set to one, cifs packet signing is enabled - and will be used if the server requires - it. If set to two, cifs packet signing is - required even if the server considers packet - signing optional. (default 1) SecurityFlags Flags which control security negotiation and also packet signing. Authentication (may/must) flags (e.g. for NTLM and/or NTLMv2) may be combined with @@ -666,8 +665,6 @@ traceSMB If set to one, debug information is logged to the LookupCacheEnable If set to one, inode information is kept cached for one second improving performance of lookups (default 1) -OplockEnabled If set to one, safe distributed caching enabled. - (default 1) LinuxExtensionsEnabled If set to one then the client will attempt to use the CIFS "UNIX" extensions which are optional protocol enhancements that allow CIFS servers diff --git a/Documentation/filesystems/cifs/TODO b/Documentation/filesystems/cifs/TODO index 396ecfd..c5adf14 100644 --- a/Documentation/filesystems/cifs/TODO +++ b/Documentation/filesystems/cifs/TODO @@ -1,4 +1,4 @@ -Version 2.04 September 13, 2017 +Version 2.11 September 13, 2017 A Partial List of Missing Features ================================== @@ -8,10 +8,10 @@ for visible, important contributions to this module. Here is a partial list of the known problems and missing features: a) SMB3 (and SMB3.02) missing optional features: - - RDMA (started) - - multichannel (started) + - multichannel (started), integration with RDMA - directory leases (improved metadata caching) - - T10 copy offload (copy chunk is only mechanism supported) + - T10 copy offload (copy chunk, and "Duplicate Extents" ioctl + currently the only two server side copy mechanisms supported) b) improved sparse file support @@ -21,9 +21,8 @@ using Directory Leases d) quota support (needs minor kernel change since quota calls to make it to network filesystems or deviceless filesystems) -e) Better optimize open to reduce redundant opens (using reference -counts more) and to improve use of compounding in SMB3 to reduce -number of roundtrips. +e) Compounding (in progress) to reduce number of roundtrips, and also +better optimize open to reduce redundant opens (using reference counts more). f) Finish inotify support so kde and gnome file list windows will autorefresh (partially complete by Asser). Needs minor kernel @@ -35,7 +34,8 @@ the CIFS statistics (started) h) implement support for security and trusted categories of xattrs (requires minor protocol extension) to enable better support for SELINUX -i) Implement O_DIRECT flag on open (already supported on mount) +i) Add support for tree connect contexts (see MS-SMB2) a new SMB3.1.1 protocol + feature (may be especially useful for virtualization). j) Create UID mapping facility so server UIDs can be mapped on a per mount or a per server basis to client UIDs or nobody if no mapping @@ -53,13 +53,16 @@ viewing them. o) mount helper GUI (to simplify the various configuration options on mount) -p) autonegotiation of dialects (offering more than one dialect ie SMB3.02, -SMB3, SMB2.1 not just SMB3). +p) Add support for witness protocol (perhaps ioctl to cifs.ko from user space + tool listening on witness protocol RPC) to allow for notification of share + move, server failover, and server adapter changes. And also improve other + failover scenarios, e.g. when client knows multiple DFS entries point to + different servers, and the server we are connected to has gone down. q) Allow mount.cifs to be more verbose in reporting errors with dialect or unsupported feature errors. -r) updating cifs documentation, and user guid. +r) updating cifs documentation, and user guide. s) Addressing bugs found by running a broader set of xfstests in standard file system xfstest suite. diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 3b9b5c1..4d9ff0a 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive use of Btrees (directories, extents, free space) to aid both performance and scalability. -Refer to the documentation at http://oss.sgi.com/projects/xfs/ +Refer to the documentation at https://xfs.wiki.kernel.org/ for further details. This implementation is on-disk compatible with the IRIX version of XFS. diff --git a/Documentation/frv/README.txt b/Documentation/frv/README.txt deleted file mode 100644 index a984faa..0000000 --- a/Documentation/frv/README.txt +++ /dev/null @@ -1,51 +0,0 @@ - ================================ - Fujitsu FR-V LINUX DOCUMENTATION - ================================ - -This directory contains documentation for the Fujitsu FR-V CPU architecture -port of Linux. - -The following documents are available: - - (*) features.txt - - A description of the basic features inherent in this architecture port. - - - (*) configuring.txt - - A summary of the configuration options particular to this architecture. - - - (*) booting.txt - - A description of how to boot the kernel image and a summary of the kernel - command line options. - - - (*) gdbstub.txt - - A description of how to debug the kernel using GDB attached by serial - port, and a summary of the services available. - - - (*) mmu-layout.txt - - A description of the virtual and physical memory layout used in the - MMU linux kernel, and the registers used to support it. - - - (*) gdbinit - - An example .gdbinit file for use with GDB. It includes macros for viewing - MMU state on the FR451. See mmu-layout.txt for more information. - - - (*) clock.txt - - A description of the CPU clock scaling interface. - - - (*) atomic-ops.txt - - A description of how the FR-V kernel's atomic operations work. diff --git a/Documentation/frv/atomic-ops.txt b/Documentation/frv/atomic-ops.txt deleted file mode 100644 index 96638e9..0000000 --- a/Documentation/frv/atomic-ops.txt +++ /dev/null @@ -1,134 +0,0 @@ - ===================================== - FUJITSU FR-V KERNEL ATOMIC OPERATIONS - ===================================== - -On the FR-V CPUs, there is only one atomic Read-Modify-Write operation: the SWAP/SWAPI -instruction. Unfortunately, this alone can't be used to implement the following operations: - - (*) Atomic add to memory - - (*) Atomic subtract from memory - - (*) Atomic bit modification (set, clear or invert) - - (*) Atomic compare and exchange - -On such CPUs, the standard way of emulating such operations in uniprocessor mode is to disable -interrupts, but on the FR-V CPUs, modifying the PSR takes a lot of clock cycles, and it has to be -done twice. This means the CPU runs for a relatively long time with interrupts disabled, -potentially having a great effect on interrupt latency. - - -============= -NEW ALGORITHM -============= - -To get around this, the following algorithm has been implemented. It operates in a way similar to -the LL/SC instruction pairs supported on a number of platforms. - - (*) The CCCR.CC3 register is reserved within the kernel to act as an atomic modify abort flag. - - (*) In the exception prologues run on kernel->kernel entry, CCCR.CC3 is set to 0 (Undefined - state). - - (*) All atomic operations can then be broken down into the following algorithm: - - (1) Set ICC3.Z to true and set CC3 to True (ORCC/CKEQ/ORCR). - - (2) Load the value currently in the memory to be modified into a register. - - (3) Make changes to the value. - - (4) If CC3 is still True, simultaneously and atomically (by VLIW packing): - - (a) Store the modified value back to memory. - - (b) Set ICC3.Z to false (CORCC on GR29 is sufficient for this - GR29 holds the current - task pointer in the kernel, and so is guaranteed to be non-zero). - - (5) If ICC3.Z is still true, go back to step (1). - -This works in a non-SMP environment because any interrupt or other exception that happens between -steps (1) and (4) will set CC3 to the Undefined, thus aborting the store in (4a), and causing the -condition in ICC3 to remain with the Z flag set, thus causing step (5) to loop back to step (1). - - -This algorithm suffers from two problems: - - (1) The condition CCCR.CC3 is cleared unconditionally by an exception, irrespective of whether or - not any changes were made to the target memory location during that exception. - - (2) The branch from step (5) back to step (1) may have to happen more than once until the store - manages to take place. In theory, this loop could cycle forever because there are too many - interrupts coming in, but it's unlikely. - - -======= -EXAMPLE -======= - -Taking an example from include/asm-frv/atomic.h: - - static inline int atomic_add_return(int i, atomic_t *v) - { - unsigned long val; - - asm("0: \n" - -It starts by setting ICC3.Z to true for later use, and also transforming that into CC3 being in the -True state. - - " orcc gr0,gr0,gr0,icc3 \n" <-- (1) - " ckeq icc3,cc7 \n" <-- (1) - -Then it does the load. Note that the final phase of step (1) is done at the same time as the -load. The VLIW packing ensures they are done simultaneously. The ".p" on the load must not be -removed without swapping the order of these two instructions. - - " ld.p %M0,%1 \n" <-- (2) - " orcr cc7,cc7,cc3 \n" <-- (1) - -Then the proposed modification is generated. Note that the old value can be retained if required -(such as in test_and_set_bit()). - - " add%I2 %1,%2,%1 \n" <-- (3) - -Then it attempts to store the value back, contingent on no exception having cleared CC3 since it -was set to True. - - " cst.p %1,%M0 ,cc3,#1 \n" <-- (4a) - -It simultaneously records the success or failure of the store in ICC3.Z. - - " corcc gr29,gr29,gr0 ,cc3,#1 \n" <-- (4b) - -Such that the branch can then be taken if the operation was aborted. - - " beq icc3,#0,0b \n" <-- (5) - : "+U"(v->counter), "=&r"(val) - : "NPr"(i) - : "memory", "cc7", "cc3", "icc3" - ); - - return val; - } - - -============= -CONFIGURATION -============= - -The atomic ops implementation can be made inline or out-of-line by changing the -CONFIG_FRV_OUTOFLINE_ATOMIC_OPS configuration variable. Making it out-of-line has a number of -advantages: - - - The resulting kernel image may be smaller - - Debugging is easier as atomic ops can just be stepped over and they can be breakpointed - -Keeping it inline also has a number of advantages: - - - The resulting kernel may be Faster - - no out-of-line function calls need to be made - - the compiler doesn't have half its registers clobbered by making a call - -The out-of-line implementations live in arch/frv/lib/atomic-ops.S. diff --git a/Documentation/frv/booting.txt b/Documentation/frv/booting.txt deleted file mode 100644 index cd9dc1d..0000000 --- a/Documentation/frv/booting.txt +++ /dev/null @@ -1,182 +0,0 @@ - ========================= - BOOTING FR-V LINUX KERNEL - ========================= - -====================== -PROVIDING A FILESYSTEM -====================== - -First of all, a root filesystem must be made available. This can be done in -one of two ways: - - (1) NFS Export - - A filesystem should be constructed in a directory on an NFS server that - the target board can reach. This directory should then be NFS exported - such that the target board can read and write into it as root. - - (2) Flash Filesystem (JFFS2 Recommended) - - In this case, the image must be stored or built up on flash before it - can be used. A complete image can be built using the mkfs.jffs2 or - similar program and then downloaded and stored into flash by RedBoot. - - -======================== -LOADING THE KERNEL IMAGE -======================== - -The kernel will need to be loaded into RAM by RedBoot (or by some alternative -boot loader) before it can be run. The kernel image (arch/frv/boot/Image) may -be loaded in one of three ways: - - (1) Load from Flash - - This is the simplest. RedBoot can store an image in the flash (see the - RedBoot documentation) and then load it back into RAM. RedBoot keeps - track of the load address, entry point and size, so the command to do - this is simply: - - fis load linux - - The image is then ready to be executed. - - (2) Load by TFTP - - The following command will download a raw binary kernel image from the - default server (as negotiated by BOOTP) and store it into RAM: - - load -b 0x00100000 -r /tftpboot/image.bin - - The image is then ready to be executed. - - (3) Load by Y-Modem - - The following command will download a raw binary kernel image across the - serial port that RedBoot is currently using: - - load -m ymodem -b 0x00100000 -r zImage - - The serial client (such as minicom) must then be told to transmit the - program by Y-Modem. - - When finished, the image will then be ready to be executed. - - -================== -BOOTING THE KERNEL -================== - -Boot the image with the following RedBoot command: - - exec -c "<CMDLINE>" 0x00100000 - -For example: - - exec -c "console=ttySM0,115200 ip=:::::dhcp root=/dev/mtdblock2 rw" - -This will start the kernel running. Note that if the GDB-stub is compiled in, -then the kernel will immediately wait for GDB to connect over serial before -doing anything else. See the section on kernel debugging with GDB. - -The kernel command line <CMDLINE> tells the kernel where its console is and -how to find its root filesystem. This is made up of the following components, -separated by spaces: - - (*) console=ttyS<x>[,<baud>[<parity>[<bits>[<flow>]]]] - - This specifies that the system console should output through on-chip - serial port <x> (which can be "0" or "1"). - - <baud> is a standard baud rate between 1200 and 115200 (default 9600). - - <parity> is a parity setting of "N", "O", "E", "M" or "S" for None, Odd, - Even, Mark or Space. "None" is the default. - - <stop> is "7" or "8" for the number of bits per character. "8" is the - default. - - <flow> is "r" to use flow control (XCTS on serial port 2 only). The - default is to not use flow control. - - For example: - - console=ttyS0,115200 - - To use the first on-chip serial port at baud rate 115200, no parity, 8 - bits, and no flow control. - - (*) root=<xxxx> - - This specifies the device upon which the root filesystem resides. It - may be specified by major and minor number, device path, or even - partition uuid, if supported. For example: - - /dev/nfs NFS root filesystem - /dev/mtdblock3 Fourth RedBoot partition on the System Flash - PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF/PARTNROFF=1 - first partition after the partition with the given UUID - 253:0 Device with major 253 and minor 0 - - Authoritative information can be found in - "Documentation/admin-guide/kernel-parameters.rst". - - (*) rw - - Start with the root filesystem mounted Read/Write. - - The remaining components are all optional: - - (*) ip=<ip>::::<host>:<iface>:<cfg> - - Configure the network interface. If <cfg> is "off" then <ip> should - specify the IP address for the network device <iface>. <host> provide - the hostname for the device. - - If <cfg> is "bootp" or "dhcp", then all of these parameters will be - discovered by consulting a BOOTP or DHCP server. - - For example, the following might be used: - - ip=192.168.73.12::::frv:eth0:off - - This sets the IP address on the VDK motherboard RTL8029 ethernet chipset - (eth0) to be 192.168.73.12, and sets the board's hostname to be "frv". - - (*) nfsroot=<server>:<dir>[,v<vers>] - - This is mandatory if "root=/dev/nfs" is given as an option. It tells the - kernel the IP address of the NFS server providing its root filesystem, - and the pathname on that server of the filesystem. - - The NFS version to use can also be specified. v2 and v3 are supported by - Linux. - - For example: - - nfsroot=192.168.73.1:/nfsroot-frv - - (*) profile=1 - - Turns on the kernel profiler (accessible through /proc/profile). - - (*) console=gdb0 - - This can be used as an alternative to the "console=ttyS..." listed - above. I tells the kernel to pass the console output to GDB if the - gdbstub is compiled in to the kernel. - - If this is used, then the gdbstub passes the text to GDB, which then - simply dumps it to its standard output. - - (*) mem=<xxx>M - - Normally the kernel will work out how much SDRAM it has by reading the - SDRAM controller registers. That can be overridden with this - option. This allows the kernel to be told that it has <xxx> megabytes of - memory available. - - (*) init=<prog> [<arg> [<arg> [<arg> ...]]] - - This tells the kernel what program to run initially. By default this is - /sbin/init, but /sbin/sash or /bin/sh are common alternatives. diff --git a/Documentation/frv/clock.txt b/Documentation/frv/clock.txt deleted file mode 100644 index c72d350..0000000 --- a/Documentation/frv/clock.txt +++ /dev/null @@ -1,65 +0,0 @@ -Clock scaling -------------- - -The kernel supports scaling of CLCK.CMODE, CLCK.CM and CLKC.P0 clock -registers. If built with CONFIG_PM and CONFIG_SYSCTL options enabled, four -extra files will appear in the directory /proc/sys/pm/. Reading these files -will show: - - p0 -- current value of the P0 bit in CLKC register. - cm -- current value of the CM bits in CLKC register. - cmode -- current value of the CMODE bits in CLKC register. - -On all boards, the 'p0' file should also be writable, and either '1' or '0' -can be rewritten, to set or clear the CLKC_P0 bit respectively, hence -controlling whether the resource bus rate clock is halved. - -The 'cm' file should also be available on all boards. '0' can be written to it -to shift the board into High-Speed mode (normal), and '1' can be written to -shift the board into Medium-Speed mode. Selecting Low-Speed mode is not -supported by this interface, even though some CPUs do support it. - -On the boards with FR405 CPU (i.e. CB60 and CB70), the 'cmode' file is also -writable, allowing the CPU core speed (and other clock speeds) to be -controlled from userspace. - - -Determining current and possible settings ------------------------------------------ - -The current state and the available masks can be found in /proc/cpuinfo. For -example, on the CB70: - - # cat /proc/cpuinfo - CPU-Series: fr400 - CPU-Core: fr405, gr0-31, BE, CCCR - CPU: mb93405 - MMU: Prot - FP-Media: fr0-31, Media - System: mb93091-cb70, mb93090-mb00 - PM-Controls: cmode=0xd31f, cm=0x3, p0=0x3, suspend=0x9 - PM-Status: cmode=3, cm=0, p0=0 - Clock-In: 50.00 MHz - Clock-Core: 300.00 MHz - Clock-SDRAM: 100.00 MHz - Clock-CBus: 100.00 MHz - Clock-Res: 50.00 MHz - Clock-Ext: 50.00 MHz - Clock-DSU: 25.00 MHz - BogoMips: 300.00 - -And on the PDK, the PM lines look like the following: - - PM-Controls: cm=0x3, p0=0x3, suspend=0x9 - PM-Status: cmode=9, cm=0, p0=0 - -The PM-Controls line, if present, will indicate which /proc/sys/pm files can -be set to what values. The specification values are bitmasks; so, for example, -"suspend=0x9" indicates that 0 and 3 can be written validly to -/proc/sys/pm/suspend. - -The PM-Controls line will only be present if CONFIG_PM is configured to Y. - -The PM-Status line indicates which clock controls are set to which value. If -the file can be read, then the suspend value must be 0, and so that's not -included. diff --git a/Documentation/frv/configuring.txt b/Documentation/frv/configuring.txt deleted file mode 100644 index 36e76a2..0000000 --- a/Documentation/frv/configuring.txt +++ /dev/null @@ -1,125 +0,0 @@ - ======================================= - FUJITSU FR-V LINUX KERNEL CONFIGURATION - ======================================= - -===================== -CONFIGURATION OPTIONS -===================== - -The most important setting is in the "MMU support options" tab (the first -presented in the configuration tools available): - - (*) "Kernel Type" - - This options allows selection of normal, MMU-requiring linux, and uClinux - (which doesn't require an MMU and doesn't have inter-process protection). - -There are a number of settings in the "Processor type and features" section of -the kernel configuration that need to be considered. - - (*) "CPU" - - The register and instruction sets at the core of the processor. This can - only be set to "FR40x/45x/55x" at the moment - but this permits usage of - the kernel with MB93091 CB10, CB11, CB30, CB41, CB60, CB70 and CB451 - CPU boards, and with the MB93093 PDK board. - - (*) "System" - - This option allows a choice of basic system. This governs the peripherals - that are expected to be available. - - (*) "Motherboard" - - This specifies the type of motherboard being used, and the peripherals - upon it. Currently only "MB93090-MB00" can be set here. - - (*) "Default cache-write mode" - - This controls the initial data cache write management mode. By default - Write-Through is selected, but Write-Back (Copy-Back) can also be - selected. This can be changed dynamically once the kernel is running (see - features.txt). - -There are some architecture specific configuration options in the "General -Setup" section of the kernel configuration too: - - (*) "Reserve memory uncached for (PCI) DMA" - - This requests that a uClinux kernel set aside some memory in an uncached - window for the use as consistent DMA memory (mainly for PCI). At least a - megabyte will be allocated in this way, possibly more. Any memory so - reserved will not be available for normal allocations. - - (*) "Kernel support for ELF-FDPIC binaries" - - This enables the binary-format driver for the new FDPIC ELF binaries that - this platform normally uses. These binaries are totally relocatable - - their separate sections can relocated independently, allowing them to be - shared on uClinux where possible. This should normally be enabled. - - (*) "Kernel image protection" - - This makes the protection register governing access to the core kernel - image prohibit access by userspace programs. This option is available on - uClinux only. - -There are also a number of settings in the "Kernel Hacking" section of the -kernel configuration especially for debugging a kernel on this -architecture. See the "gdbstub.txt" file for information about those. - - -====================== -DEFAULT CONFIGURATIONS -====================== - -The kernel sources include a number of example default configurations: - - (*) defconfig-mb93091 - - Default configuration for the MB93091-VDK with both CPU board and - MB93090-MB00 motherboard running uClinux. - - - (*) defconfig-mb93091-fb - - Default configuration for the MB93091-VDK with CPU board, - MB93090-MB00 motherboard, and DAV board running uClinux. - Includes framebuffer driver. - - - (*) defconfig-mb93093 - - Default configuration for the MB93093-PDK board running uClinux. - - - (*) defconfig-cb70-standalone - - Default configuration for the MB93091-VDK with only CB70 CPU board - running uClinux. This will use the CB70's DM9000 for network access. - - - (*) defconfig-mmu - - Default configuration for the MB93091-VDK with both CB451 CPU board and - MB93090-MB00 motherboard running MMU linux. - - (*) defconfig-mmu-audio - - Default configuration for the MB93091-VDK with CB451 CPU board, DAV - board, and MB93090-MB00 motherboard running MMU linux. Includes - audio driver. - - (*) defconfig-mmu-fb - - Default configuration for the MB93091-VDK with CB451 CPU board, DAV - board, and MB93090-MB00 motherboard running MMU linux. Includes - framebuffer driver. - - (*) defconfig-mmu-standalone - - Default configuration for the MB93091-VDK with only CB451 CPU board - running MMU linux. - - - diff --git a/Documentation/frv/features.txt b/Documentation/frv/features.txt deleted file mode 100644 index fa20c0e..0000000 --- a/Documentation/frv/features.txt +++ /dev/null @@ -1,310 +0,0 @@ - =========================== - FUJITSU FR-V LINUX FEATURES - =========================== - -This kernel port has a number of features of which the user should be aware: - - (*) Linux and uClinux - - The FR-V architecture port supports both normal MMU linux and uClinux out - of the same sources. - - - (*) CPU support - - Support for the FR401, FR403, FR405, FR451 and FR555 CPUs should work with - the same uClinux kernel configuration. - - In normal (MMU) Linux mode, only the FR451 CPU will work as that is the - only one with a suitably featured CPU. - - The kernel is written and compiled with the assumption that only the - bottom 32 GR registers and no FR registers will be used by the kernel - itself, however all extra userspace registers will be saved on context - switch. Note that since most CPUs can't support lazy switching, no attempt - is made to do lazy register saving where that would be possible (FR555 - only currently). - - - (*) Board support - - The board on which the kernel will run can be configured on the "Processor - type and features" configuration tab. - - Set the System to "MB93093-PDK" to boot from the MB93093 (FR403) PDK. - - Set the System to "MB93091-VDK" to boot from the CB11, CB30, CB41, CB60, - CB70 or CB451 VDK boards. Set the Motherboard setting to "MB93090-MB00" to - boot with the standard ATA90590B VDK motherboard, and set it to "None" to - boot without any motherboard. - - - (*) Binary Formats - - The only userspace binary format supported is FDPIC ELF. Normal ELF, FLAT - and AOUT binaries are not supported for this architecture. - - FDPIC ELF supports shared library and program interpreter facilities. - - - (*) Scheduler Speed - - The kernel scheduler runs at 100Hz irrespective of the clock speed on this - architecture. This value is set in asm/param.h (see the HZ macro defined - there). - - - (*) Normal (MMU) Linux Memory Layout. - - See mmu-layout.txt in this directory for a description of the normal linux - memory layout - - See include/asm-frv/mem-layout.h for constants pertaining to the memory - layout. - - See include/asm-frv/mb-regs.h for the constants pertaining to the I/O bus - controller configuration. - - - (*) uClinux Memory Layout - - The memory layout used by the uClinux kernel is as follows: - - 0x00000000 - 0x00000FFF Null pointer catch page - 0x20000000 - 0x200FFFFF CS2# [PDK] FPGA - 0xC0000000 - 0xCFFFFFFF SDRAM - 0xC0000000 Base of Linux kernel image - 0xE0000000 - 0xEFFFFFFF CS2# [VDK] SLBUS/PCI window - 0xF0000000 - 0xF0FFFFFF CS5# MB93493 CSC area (DAV daughter board) - 0xF1000000 - 0xF1FFFFFF CS7# [CB70/CB451] CPU-card PCMCIA port space - 0xFC000000 - 0xFC0FFFFF CS1# [VDK] MB86943 config space - 0xFC100000 - 0xFC1FFFFF CS6# [CB70/CB451] CPU-card DM9000 NIC space - 0xFC100000 - 0xFC1FFFFF CS6# [PDK] AX88796 NIC space - 0xFC200000 - 0xFC2FFFFF CS3# MB93493 CSR area (DAV daughter board) - 0xFD000000 - 0xFDFFFFFF CS4# [CB70/CB451] CPU-card extra flash space - 0xFE000000 - 0xFEFFFFFF Internal CPU peripherals - 0xFF000000 - 0xFF1FFFFF CS0# Flash 1 - 0xFF200000 - 0xFF3FFFFF CS0# Flash 2 - 0xFFC00000 - 0xFFC0001F CS0# [VDK] FPGA - - The kernel reads the size of the SDRAM from the memory bus controller - registers by default. - - The kernel initialisation code (1) adjusts the SDRAM base addresses to - move the SDRAM to desired address, (2) moves the kernel image down to the - bottom of SDRAM, (3) adjusts the bus controller registers to move I/O - windows, and (4) rearranges the protection registers to protect all of - this. - - The reasons for doing this are: (1) the page at address 0 should be - inaccessible so that NULL pointer errors can be caught; and (2) the bottom - three quarters are left unoccupied so that an FR-V CPU with an MMU can use - it for virtual userspace mappings. - - See include/asm-frv/mem-layout.h for constants pertaining to the memory - layout. - - See include/asm-frv/mb-regs.h for the constants pertaining to the I/O bus - controller configuration. - - - (*) uClinux Memory Protection - - A DAMPR register is used to cover the entire region used for I/O - (0xE0000000 - 0xFFFFFFFF). This permits the kernel to make uncached - accesses to this region. Userspace is not permitted to access it. - - The DAMPR/IAMPR protection registers not in use for any other purpose are - tiled over the top of the SDRAM such that: - - (1) The core kernel image is covered by as small a tile as possible - granting only the kernel access to the underlying data, whilst - making sure no SDRAM is actually made unavailable by this approach. - - (2) All other tiles are arranged to permit userspace access to the rest - of the SDRAM. - - Barring point (1), there is nothing to protect kernel data against - userspace damage - but this is uClinux. - - - (*) Exceptions and Fixups - - Since the FR40x and FR55x CPUs that do not have full MMUs generate - imprecise data error exceptions, there are currently no automatic fixup - services available in uClinux. This includes misaligned memory access - fixups. - - Userspace EFAULT errors can be trapped by issuing a MEMBAR instruction and - forcing the fault to happen there. - - On the FR451, however, data exceptions are mostly precise, and so - exception fixup handling is implemented as normal. - - - (*) Userspace Breakpoints - - The ptrace() system call supports the following userspace debugging - features: - - (1) Hardware assisted single step. - - (2) Breakpoint via the FR-V "BREAK" instruction. - - (3) Breakpoint via the FR-V "TIRA GR0, #1" instruction. - - (4) Syscall entry/exit trap. - - Each of the above generates a SIGTRAP. - - - (*) On-Chip Serial Ports - - The FR-V on-chip serial ports are made available as ttyS0 and ttyS1. Note - that if the GDB stub is compiled in, ttyS1 will not actually be available - as it will be being used for the GDB stub. - - These ports can be made by: - - mknod /dev/ttyS0 c 4 64 - mknod /dev/ttyS1 c 4 65 - - - (*) Maskable Interrupts - - Level 15 (Non-maskable) interrupts are dealt with by the GDB stub if - present, and cause a panic if not. If the GDB stub is present, ttyS1's - interrupts are rated at level 15. - - All other interrupts are distributed over the set of available priorities - so that no IRQs are shared where possible. The arch interrupt handling - routines attempt to disentangle the various sources available through the - CPU's own multiplexor, and those on off-CPU peripherals. - - - (*) Accessing PCI Devices - - Where PCI is available, care must be taken when dealing with drivers that - access PCI devices. PCI devices present their data in little-endian form, - but the CPU sees it in big-endian form. The macros in asm/io.h try to get - this right, but may not under all circumstances... - - - (*) Ax88796 Ethernet Driver - - The MB93093 PDK board has an Ax88796 ethernet chipset (an NE2000 clone). A - driver has been written to deal specifically with this. The driver - provides MII services for the card. - - The driver can be configured by running make xconfig, and going to: - - (*) Network device support - - turn on "Network device support" - (*) Ethernet (10 or 100Mbit) - - turn on "Ethernet (10 or 100Mbit)" - - turn on "AX88796 NE2000 compatible chipset" - - The driver can be found in: - - drivers/net/ax88796.c - include/asm/ax88796.h - - - (*) WorkRAM Driver - - This driver provides a character device that permits access to the WorkRAM - that can be found on the FR451 CPU. Each page is accessible through a - separate minor number, thereby permitting each page to have its own - filesystem permissions set on the device file. - - The device files should be: - - mknod /dev/frv/workram0 c 240 0 - mknod /dev/frv/workram1 c 240 1 - mknod /dev/frv/workram2 c 240 2 - ... - - The driver will not permit the opening of any device file that does not - correspond to at least a partial page of WorkRAM. So the first device file - is the only one available on the FR451. If any other CPU is detected, none - of the devices will be openable. - - The devices can be accessed with read, write and llseek, and can also be - mmapped. If they're mmapped, they will only map at the appropriate - 0x7e8nnnnn address on linux and at the 0xfe8nnnnn address on uClinux. If - MAP_FIXED is not specified, the appropriate address will be chosen anyway. - - The mappings must be MAP_SHARED not MAP_PRIVATE, and must not be - PROT_EXEC. They must also start at file offset 0, and must not be longer - than one page in size. - - This driver can be configured by running make xconfig, and going to: - - (*) Character devices - - turn on "Fujitsu FR-V CPU WorkRAM support" - - - (*) Dynamic data cache write mode changing - - It is possible to view and to change the data cache's write mode through - the /proc/sys/frv/cache-mode file while the kernel is running. There are - two modes available: - - NAME MEANING - ===== ========================================== - wthru Data cache is in Write-Through mode - wback Data cache is in Write-Back/Copy-Back mode - - To read the cache mode: - - # cat /proc/sys/frv/cache-mode - wthru - - To change the cache mode: - - # echo wback >/proc/sys/frv/cache-mode - # cat /proc/sys/frv/cache-mode - wback - - - (*) MMU Context IDs and Pinning - - On MMU Linux the CPU supports the concept of a context ID in its MMU to - make it more efficient (TLB entries are labelled with a context ID to link - them to specific tasks). - - Normally once a context ID is allocated, it will remain affixed to a task - or CLONE_VM'd group of tasks for as long as it exists. However, since the - kernel is capable of supporting more tasks than there are possible ID - numbers, the kernel will pass context IDs from one task to another if - there are insufficient available. - - The context ID currently in use by a task can be viewed in /proc: - - # grep CXNR /proc/1/status - CXNR: 1 - - Note that kernel threads do not have a userspace context, and so will not - show a CXNR entry in that file. - - Under some circumstances, however, it is desirable to pin a context ID on - a process such that the kernel won't pass it on. This can be done by - writing the process ID of the target process to a special file: - - # echo 17 >/proc/sys/frv/pin-cxnr - - Reading from the file will then show the context ID pinned. - - # cat /proc/sys/frv/pin-cxnr - 4 - - The context ID will remain pinned as long as any process is using that - context, i.e.: when the all the subscribing processes have exited or - exec'd; or when an unpinning request happens: - - # echo 0 >/proc/sys/frv/pin-cxnr - - When there isn't a pinned context, the file shows -1: - - # cat /proc/sys/frv/pin-cxnr - -1 diff --git a/Documentation/frv/gdbinit b/Documentation/frv/gdbinit deleted file mode 100644 index 51517b6..0000000 --- a/Documentation/frv/gdbinit +++ /dev/null @@ -1,102 +0,0 @@ -set remotebreak 1 - -define _amr - -printf "AMRx DAMR IAMR \n" -printf "==== ===================== =====================\n" -printf "amr0 : L:%08lx P:%08lx : L:%08lx P:%08lx\n",__debug_mmu.damr[0x0].L,__debug_mmu.damr[0x0].P,__debug_mmu.iamr[0x0].L,__debug_mmu.iamr[0x0].P -printf "amr1 : L:%08lx P:%08lx : L:%08lx P:%08lx\n",__debug_mmu.damr[0x1].L,__debug_mmu.damr[0x1].P,__debug_mmu.iamr[0x1].L,__debug_mmu.iamr[0x1].P -printf "amr2 : L:%08lx P:%08lx : L:%08lx P:%08lx\n",__debug_mmu.damr[0x2].L,__debug_mmu.damr[0x2].P,__debug_mmu.iamr[0x2].L,__debug_mmu.iamr[0x2].P -printf "amr3 : L:%08lx P:%08lx : L:%08lx P:%08lx\n",__debug_mmu.damr[0x3].L,__debug_mmu.damr[0x3].P,__debug_mmu.iamr[0x3].L,__debug_mmu.iamr[0x3].P -printf "amr4 : L:%08lx P:%08lx : L:%08lx P:%08lx\n",__debug_mmu.damr[0x4].L,__debug_mmu.damr[0x4].P,__debug_mmu.iamr[0x4].L,__debug_mmu.iamr[0x4].P -printf "amr5 : L:%08lx P:%08lx : L:%08lx P:%08lx\n",__debug_mmu.damr[0x5].L,__debug_mmu.damr[0x5].P,__debug_mmu.iamr[0x5].L,__debug_mmu.iamr[0x5].P -printf "amr6 : L:%08lx P:%08lx : L:%08lx P:%08lx\n",__debug_mmu.damr[0x6].L,__debug_mmu.damr[0x6].P,__debug_mmu.iamr[0x6].L,__debug_mmu.iamr[0x6].P -printf "amr7 : L:%08lx P:%08lx : L:%08lx P:%08lx\n",__debug_mmu.damr[0x7].L,__debug_mmu.damr[0x7].P,__debug_mmu.iamr[0x7].L,__debug_mmu.iamr[0x7].P - -printf "amr8 : L:%08lx P:%08lx\n",__debug_mmu.damr[0x8].L,__debug_mmu.damr[0x8].P -printf "amr9 : L:%08lx P:%08lx\n",__debug_mmu.damr[0x9].L,__debug_mmu.damr[0x9].P -printf "amr10: L:%08lx P:%08lx\n",__debug_mmu.damr[0xa].L,__debug_mmu.damr[0xa].P -printf "amr11: L:%08lx P:%08lx\n",__debug_mmu.damr[0xb].L,__debug_mmu.damr[0xb].P - -end - - -define _tlb -printf "tlb[0x00]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x0].L,__debug_mmu.tlb[0x0].P,__debug_mmu.tlb[0x40+0x0].L,__debug_mmu.tlb[0x40+0x0].P -printf "tlb[0x01]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x1].L,__debug_mmu.tlb[0x1].P,__debug_mmu.tlb[0x40+0x1].L,__debug_mmu.tlb[0x40+0x1].P -printf "tlb[0x02]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x2].L,__debug_mmu.tlb[0x2].P,__debug_mmu.tlb[0x40+0x2].L,__debug_mmu.tlb[0x40+0x2].P -printf "tlb[0x03]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x3].L,__debug_mmu.tlb[0x3].P,__debug_mmu.tlb[0x40+0x3].L,__debug_mmu.tlb[0x40+0x3].P -printf "tlb[0x04]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x4].L,__debug_mmu.tlb[0x4].P,__debug_mmu.tlb[0x40+0x4].L,__debug_mmu.tlb[0x40+0x4].P -printf "tlb[0x05]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x5].L,__debug_mmu.tlb[0x5].P,__debug_mmu.tlb[0x40+0x5].L,__debug_mmu.tlb[0x40+0x5].P -printf "tlb[0x06]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x6].L,__debug_mmu.tlb[0x6].P,__debug_mmu.tlb[0x40+0x6].L,__debug_mmu.tlb[0x40+0x6].P -printf "tlb[0x07]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x7].L,__debug_mmu.tlb[0x7].P,__debug_mmu.tlb[0x40+0x7].L,__debug_mmu.tlb[0x40+0x7].P -printf "tlb[0x08]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x8].L,__debug_mmu.tlb[0x8].P,__debug_mmu.tlb[0x40+0x8].L,__debug_mmu.tlb[0x40+0x8].P -printf "tlb[0x09]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x9].L,__debug_mmu.tlb[0x9].P,__debug_mmu.tlb[0x40+0x9].L,__debug_mmu.tlb[0x40+0x9].P -printf "tlb[0x0a]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0xa].L,__debug_mmu.tlb[0xa].P,__debug_mmu.tlb[0x40+0xa].L,__debug_mmu.tlb[0x40+0xa].P -printf "tlb[0x0b]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0xb].L,__debug_mmu.tlb[0xb].P,__debug_mmu.tlb[0x40+0xb].L,__debug_mmu.tlb[0x40+0xb].P -printf "tlb[0x0c]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0xc].L,__debug_mmu.tlb[0xc].P,__debug_mmu.tlb[0x40+0xc].L,__debug_mmu.tlb[0x40+0xc].P -printf "tlb[0x0d]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0xd].L,__debug_mmu.tlb[0xd].P,__debug_mmu.tlb[0x40+0xd].L,__debug_mmu.tlb[0x40+0xd].P -printf "tlb[0x0e]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0xe].L,__debug_mmu.tlb[0xe].P,__debug_mmu.tlb[0x40+0xe].L,__debug_mmu.tlb[0x40+0xe].P -printf "tlb[0x0f]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0xf].L,__debug_mmu.tlb[0xf].P,__debug_mmu.tlb[0x40+0xf].L,__debug_mmu.tlb[0x40+0xf].P -printf "tlb[0x10]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x10].L,__debug_mmu.tlb[0x10].P,__debug_mmu.tlb[0x40+0x10].L,__debug_mmu.tlb[0x40+0x10].P -printf "tlb[0x11]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x11].L,__debug_mmu.tlb[0x11].P,__debug_mmu.tlb[0x40+0x11].L,__debug_mmu.tlb[0x40+0x11].P -printf "tlb[0x12]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x12].L,__debug_mmu.tlb[0x12].P,__debug_mmu.tlb[0x40+0x12].L,__debug_mmu.tlb[0x40+0x12].P -printf "tlb[0x13]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x13].L,__debug_mmu.tlb[0x13].P,__debug_mmu.tlb[0x40+0x13].L,__debug_mmu.tlb[0x40+0x13].P -printf "tlb[0x14]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x14].L,__debug_mmu.tlb[0x14].P,__debug_mmu.tlb[0x40+0x14].L,__debug_mmu.tlb[0x40+0x14].P -printf "tlb[0x15]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x15].L,__debug_mmu.tlb[0x15].P,__debug_mmu.tlb[0x40+0x15].L,__debug_mmu.tlb[0x40+0x15].P -printf "tlb[0x16]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x16].L,__debug_mmu.tlb[0x16].P,__debug_mmu.tlb[0x40+0x16].L,__debug_mmu.tlb[0x40+0x16].P -printf "tlb[0x17]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x17].L,__debug_mmu.tlb[0x17].P,__debug_mmu.tlb[0x40+0x17].L,__debug_mmu.tlb[0x40+0x17].P -printf "tlb[0x18]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x18].L,__debug_mmu.tlb[0x18].P,__debug_mmu.tlb[0x40+0x18].L,__debug_mmu.tlb[0x40+0x18].P -printf "tlb[0x19]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x19].L,__debug_mmu.tlb[0x19].P,__debug_mmu.tlb[0x40+0x19].L,__debug_mmu.tlb[0x40+0x19].P -printf "tlb[0x1a]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x1a].L,__debug_mmu.tlb[0x1a].P,__debug_mmu.tlb[0x40+0x1a].L,__debug_mmu.tlb[0x40+0x1a].P -printf "tlb[0x1b]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x1b].L,__debug_mmu.tlb[0x1b].P,__debug_mmu.tlb[0x40+0x1b].L,__debug_mmu.tlb[0x40+0x1b].P -printf "tlb[0x1c]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x1c].L,__debug_mmu.tlb[0x1c].P,__debug_mmu.tlb[0x40+0x1c].L,__debug_mmu.tlb[0x40+0x1c].P -printf "tlb[0x1d]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x1d].L,__debug_mmu.tlb[0x1d].P,__debug_mmu.tlb[0x40+0x1d].L,__debug_mmu.tlb[0x40+0x1d].P -printf "tlb[0x1e]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x1e].L,__debug_mmu.tlb[0x1e].P,__debug_mmu.tlb[0x40+0x1e].L,__debug_mmu.tlb[0x40+0x1e].P -printf "tlb[0x1f]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x1f].L,__debug_mmu.tlb[0x1f].P,__debug_mmu.tlb[0x40+0x1f].L,__debug_mmu.tlb[0x40+0x1f].P -printf "tlb[0x20]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x20].L,__debug_mmu.tlb[0x20].P,__debug_mmu.tlb[0x40+0x20].L,__debug_mmu.tlb[0x40+0x20].P -printf "tlb[0x21]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x21].L,__debug_mmu.tlb[0x21].P,__debug_mmu.tlb[0x40+0x21].L,__debug_mmu.tlb[0x40+0x21].P -printf "tlb[0x22]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x22].L,__debug_mmu.tlb[0x22].P,__debug_mmu.tlb[0x40+0x22].L,__debug_mmu.tlb[0x40+0x22].P -printf "tlb[0x23]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x23].L,__debug_mmu.tlb[0x23].P,__debug_mmu.tlb[0x40+0x23].L,__debug_mmu.tlb[0x40+0x23].P -printf "tlb[0x24]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x24].L,__debug_mmu.tlb[0x24].P,__debug_mmu.tlb[0x40+0x24].L,__debug_mmu.tlb[0x40+0x24].P -printf "tlb[0x25]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x25].L,__debug_mmu.tlb[0x25].P,__debug_mmu.tlb[0x40+0x25].L,__debug_mmu.tlb[0x40+0x25].P -printf "tlb[0x26]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x26].L,__debug_mmu.tlb[0x26].P,__debug_mmu.tlb[0x40+0x26].L,__debug_mmu.tlb[0x40+0x26].P -printf "tlb[0x27]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x27].L,__debug_mmu.tlb[0x27].P,__debug_mmu.tlb[0x40+0x27].L,__debug_mmu.tlb[0x40+0x27].P -printf "tlb[0x28]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x28].L,__debug_mmu.tlb[0x28].P,__debug_mmu.tlb[0x40+0x28].L,__debug_mmu.tlb[0x40+0x28].P -printf "tlb[0x29]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x29].L,__debug_mmu.tlb[0x29].P,__debug_mmu.tlb[0x40+0x29].L,__debug_mmu.tlb[0x40+0x29].P -printf "tlb[0x2a]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x2a].L,__debug_mmu.tlb[0x2a].P,__debug_mmu.tlb[0x40+0x2a].L,__debug_mmu.tlb[0x40+0x2a].P -printf "tlb[0x2b]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x2b].L,__debug_mmu.tlb[0x2b].P,__debug_mmu.tlb[0x40+0x2b].L,__debug_mmu.tlb[0x40+0x2b].P -printf "tlb[0x2c]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x2c].L,__debug_mmu.tlb[0x2c].P,__debug_mmu.tlb[0x40+0x2c].L,__debug_mmu.tlb[0x40+0x2c].P -printf "tlb[0x2d]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x2d].L,__debug_mmu.tlb[0x2d].P,__debug_mmu.tlb[0x40+0x2d].L,__debug_mmu.tlb[0x40+0x2d].P -printf "tlb[0x2e]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x2e].L,__debug_mmu.tlb[0x2e].P,__debug_mmu.tlb[0x40+0x2e].L,__debug_mmu.tlb[0x40+0x2e].P -printf "tlb[0x2f]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x2f].L,__debug_mmu.tlb[0x2f].P,__debug_mmu.tlb[0x40+0x2f].L,__debug_mmu.tlb[0x40+0x2f].P -printf "tlb[0x30]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x30].L,__debug_mmu.tlb[0x30].P,__debug_mmu.tlb[0x40+0x30].L,__debug_mmu.tlb[0x40+0x30].P -printf "tlb[0x31]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x31].L,__debug_mmu.tlb[0x31].P,__debug_mmu.tlb[0x40+0x31].L,__debug_mmu.tlb[0x40+0x31].P -printf "tlb[0x32]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x32].L,__debug_mmu.tlb[0x32].P,__debug_mmu.tlb[0x40+0x32].L,__debug_mmu.tlb[0x40+0x32].P -printf "tlb[0x33]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x33].L,__debug_mmu.tlb[0x33].P,__debug_mmu.tlb[0x40+0x33].L,__debug_mmu.tlb[0x40+0x33].P -printf "tlb[0x34]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x34].L,__debug_mmu.tlb[0x34].P,__debug_mmu.tlb[0x40+0x34].L,__debug_mmu.tlb[0x40+0x34].P -printf "tlb[0x35]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x35].L,__debug_mmu.tlb[0x35].P,__debug_mmu.tlb[0x40+0x35].L,__debug_mmu.tlb[0x40+0x35].P -printf "tlb[0x36]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x36].L,__debug_mmu.tlb[0x36].P,__debug_mmu.tlb[0x40+0x36].L,__debug_mmu.tlb[0x40+0x36].P -printf "tlb[0x37]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x37].L,__debug_mmu.tlb[0x37].P,__debug_mmu.tlb[0x40+0x37].L,__debug_mmu.tlb[0x40+0x37].P -printf "tlb[0x38]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x38].L,__debug_mmu.tlb[0x38].P,__debug_mmu.tlb[0x40+0x38].L,__debug_mmu.tlb[0x40+0x38].P -printf "tlb[0x39]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x39].L,__debug_mmu.tlb[0x39].P,__debug_mmu.tlb[0x40+0x39].L,__debug_mmu.tlb[0x40+0x39].P -printf "tlb[0x3a]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x3a].L,__debug_mmu.tlb[0x3a].P,__debug_mmu.tlb[0x40+0x3a].L,__debug_mmu.tlb[0x40+0x3a].P -printf "tlb[0x3b]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x3b].L,__debug_mmu.tlb[0x3b].P,__debug_mmu.tlb[0x40+0x3b].L,__debug_mmu.tlb[0x40+0x3b].P -printf "tlb[0x3c]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x3c].L,__debug_mmu.tlb[0x3c].P,__debug_mmu.tlb[0x40+0x3c].L,__debug_mmu.tlb[0x40+0x3c].P -printf "tlb[0x3d]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x3d].L,__debug_mmu.tlb[0x3d].P,__debug_mmu.tlb[0x40+0x3d].L,__debug_mmu.tlb[0x40+0x3d].P -printf "tlb[0x3e]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x3e].L,__debug_mmu.tlb[0x3e].P,__debug_mmu.tlb[0x40+0x3e].L,__debug_mmu.tlb[0x40+0x3e].P -printf "tlb[0x3f]: %08lx %08lx %08lx %08lx\n",__debug_mmu.tlb[0x3f].L,__debug_mmu.tlb[0x3f].P,__debug_mmu.tlb[0x40+0x3f].L,__debug_mmu.tlb[0x40+0x3f].P -end - - -define _pgd -p (pgd_t[0x40])*(pgd_t*)(__debug_mmu.damr[0x3].L) -end - -define _ptd_i -p (pte_t[0x1000])*(pte_t*)(__debug_mmu.damr[0x4].L) -end - -define _ptd_d -p (pte_t[0x1000])*(pte_t*)(__debug_mmu.damr[0x5].L) -end diff --git a/Documentation/frv/gdbstub.txt b/Documentation/frv/gdbstub.txt deleted file mode 100644 index b92bfd9..0000000 --- a/Documentation/frv/gdbstub.txt +++ /dev/null @@ -1,130 +0,0 @@ - ==================== - DEBUGGING FR-V LINUX - ==================== - - -The kernel contains a GDB stub that talks GDB remote protocol across a serial -port. This permits GDB to single step through the kernel, set breakpoints and -trap exceptions that happen in kernel space and interrupt execution. It also -permits the NMI interrupt button or serial port events to jump the kernel into -the debugger. - -On the CPUs that have on-chip UARTs (FR400, FR403, FR405, FR555), the -GDB stub hijacks a serial port for its own purposes, and makes it -generate level 15 interrupts (NMI). The kernel proper cannot see the serial -port in question under these conditions. - -On the MB93091-VDK CPU boards, the GDB stub uses UART1, which would otherwise -be /dev/ttyS1. On the MB93093-PDK, the GDB stub uses UART0. Therefore, on the -PDK there is no externally accessible serial port and the serial port to -which the touch screen is attached becomes /dev/ttyS0. - -Note that the GDB stub runs entirely within CPU debug mode, and so should not -incur any exceptions or interrupts whilst it is active. In particular, note -that the clock will lose time since it is implemented in software. - - -================== -KERNEL PREPARATION -================== - -Firstly, a debuggable kernel must be built. To do this, unpack the kernel tree -and copy the configuration that you wish to use to .config. Then reconfigure -the following things on the "Kernel Hacking" tab: - - (*) "Include debugging information" - - Set this to "Y". This causes all C and Assembly files to be compiled - to include debugging information. - - (*) "In-kernel GDB stub" - - Set this to "Y". This causes the GDB stub to be compiled into the - kernel. - - (*) "Immediate activation" - - Set this to "Y" if you want the GDB stub to activate as soon as possible - and wait for GDB to connect. This allows you to start tracing right from - the beginning of start_kernel() in init/main.c. - - (*) "Console through GDB stub" - - Set this to "Y" if you wish to be able to use "console=gdb0" on the - command line. That tells the kernel to pass system console messages to - GDB (which then prints them on its standard output). This is useful when - debugging the serial drivers that'd otherwise be used to pass console - messages to the outside world. - -Then build as usual, download to the board and execute. Note that if -"Immediate activation" was selected, then the kernel will wait for GDB to -attach. If not, then the kernel will boot immediately and GDB will have to -interrupt it or wait for an exception to occur before doing anything with -the kernel. - - -========================= -KERNEL DEBUGGING WITH GDB -========================= - -Set the serial port on the computer that's going to run GDB to the appropriate -baud rate. Assuming the board's debug port is connected to ttyS0/COM1 on the -computer doing the debugging: - - stty -F /dev/ttyS0 115200 - -Then start GDB in the base of the kernel tree: - - frv-uclinux-gdb linux [uClinux] - -Or: - - frv-uclinux-gdb vmlinux [MMU linux] - -When the prompt appears: - - GNU gdb frv-031024 - Copyright 2003 Free Software Foundation, Inc. - GDB is free software, covered by the GNU General Public License, and you are - welcome to change it and/or distribute copies of it under certain conditions. - Type "show copying" to see the conditions. - There is absolutely no warranty for GDB. Type "show warranty" for details. - This GDB was configured as "--host=i686-pc-linux-gnu --target=frv-uclinux"... - (gdb) - -Attach to the board like this: - - (gdb) target remote /dev/ttyS0 - Remote debugging using /dev/ttyS0 - start_kernel () at init/main.c:395 - (gdb) - -This should show the appropriate lines from the source too. The kernel can -then be debugged almost as if it's any other program. - - -=============================== -INTERRUPTING THE RUNNING KERNEL -=============================== - -The kernel can be interrupted whilst it is running, causing a jump back to the -GDB stub and the debugger: - - (*) Pressing Ctrl-C in GDB. This will cause GDB to try and interrupt the - kernel by sending an RS232 BREAK over the serial line to the GDB - stub. This will (mostly) immediately interrupt the kernel and return it - to the debugger. - - (*) Pressing the NMI button on the board will also cause a jump into the - debugger. - - (*) Setting a software breakpoint. This sets a break instruction at the - desired location which the GDB stub then traps the exception for. - - (*) Setting a hardware breakpoint. The GDB stub is capable of using the IBAR - and DBAR registers to assist debugging. - -Furthermore, the GDB stub will intercept a number of exceptions automatically -if they are caused by kernel execution. It will also intercept BUG() macro -invocation. - diff --git a/Documentation/frv/kernel-ABI.txt b/Documentation/frv/kernel-ABI.txt deleted file mode 100644 index aaa1cec..0000000 --- a/Documentation/frv/kernel-ABI.txt +++ /dev/null @@ -1,262 +0,0 @@ - ================================= - INTERNAL KERNEL ABI FOR FR-V ARCH - ================================= - -The internal FRV kernel ABI is not quite the same as the userspace ABI. A -number of the registers are used for special purposed, and the ABI is not -consistent between modules vs core, and MMU vs no-MMU. - -This partly stems from the fact that FRV CPUs do not have a separate -supervisor stack pointer, and most of them do not have any scratch -registers, thus requiring at least one general purpose register to be -clobbered in such an event. Also, within the kernel core, it is possible to -simply jump or call directly between functions using a relative offset. -This cannot be extended to modules for the displacement is likely to be too -far. Thus in modules the address of a function to call must be calculated -in a register and then used, requiring two extra instructions. - -This document has the following sections: - - (*) System call register ABI - (*) CPU operating modes - (*) Internal kernel-mode register ABI - (*) Internal debug-mode register ABI - (*) Virtual interrupt handling - - -======================== -SYSTEM CALL REGISTER ABI -======================== - -When a system call is made, the following registers are effective: - - REGISTERS CALL RETURN - =============== ======================= ======================= - GR7 System call number Preserved - GR8 Syscall arg #1 Return value - GR9-GR13 Syscall arg #2-6 Preserved - - -=================== -CPU OPERATING MODES -=================== - -The FR-V CPU has three basic operating modes. In order of increasing -capability: - - (1) User mode. - - Basic userspace running mode. - - (2) Kernel mode. - - Normal kernel mode. There are many additional control registers - available that may be accessed in this mode, in addition to all the - stuff available to user mode. This has two submodes: - - (a) Exceptions enabled (PSR.T == 1). - - Exceptions will invoke the appropriate normal kernel mode - handler. On entry to the handler, the PSR.T bit will be cleared. - - (b) Exceptions disabled (PSR.T == 0). - - No exceptions or interrupts may happen. Any mandatory exceptions - will cause the CPU to halt unless the CPU is told to jump into - debug mode instead. - - (3) Debug mode. - - No exceptions may happen in this mode. Memory protection and - management exceptions will be flagged for later consideration, but - the exception handler won't be invoked. Debugging traps such as - hardware breakpoints and watchpoints will be ignored. This mode is - entered only by debugging events obtained from the other two modes. - - All kernel mode registers may be accessed, plus a few extra debugging - specific registers. - - -================================= -INTERNAL KERNEL-MODE REGISTER ABI -================================= - -There are a number of permanent register assignments that are set up by -entry.S in the exception prologue. Note that there is a complete set of -exception prologues for each of user->kernel transition and kernel->kernel -transition. There are also user->debug and kernel->debug mode transition -prologues. - - - REGISTER FLAVOUR USE - =============== ======= ============================================== - GR1 Supervisor stack pointer - GR15 Current thread info pointer - GR16 GP-Rel base register for small data - GR28 Current exception frame pointer (__frame) - GR29 Current task pointer (current) - GR30 Destroyed by kernel mode entry - GR31 NOMMU Destroyed by debug mode entry - GR31 MMU Destroyed by TLB miss kernel mode entry - CCR.ICC2 Virtual interrupt disablement tracking - CCCR.CC3 Cleared by exception prologue - (atomic op emulation) - SCR0 MMU See mmu-layout.txt. - SCR1 MMU See mmu-layout.txt. - SCR2 MMU Save for EAR0 (destroyed by icache insns - in debug mode) - SCR3 MMU Save for GR31 during debug exceptions - DAMR/IAMR NOMMU Fixed memory protection layout. - DAMR/IAMR MMU See mmu-layout.txt. - - -Certain registers are also used or modified across function calls: - - REGISTER CALL RETURN - =============== =============================== ====================== - GR0 Fixed Zero - - GR2 Function call frame pointer - GR3 Special Preserved - GR3-GR7 - Clobbered - GR8 Function call arg #1 Return value - (or clobbered) - GR9 Function call arg #2 Return value MSW - (or clobbered) - GR10-GR13 Function call arg #3-#6 Clobbered - GR14 - Clobbered - GR15-GR16 Special Preserved - GR17-GR27 - Preserved - GR28-GR31 Special Only accessed - explicitly - LR Return address after CALL Clobbered - CCR/CCCR - Mostly Clobbered - - -================================ -INTERNAL DEBUG-MODE REGISTER ABI -================================ - -This is the same as the kernel-mode register ABI for functions calls. The -difference is that in debug-mode there's a different stack and a different -exception frame. Almost all the global registers from kernel-mode -(including the stack pointer) may be changed. - - REGISTER FLAVOUR USE - =============== ======= ============================================== - GR1 Debug stack pointer - GR16 GP-Rel base register for small data - GR31 Current debug exception frame pointer - (__debug_frame) - SCR3 MMU Saved value of GR31 - - -Note that debug mode is able to interfere with the kernel's emulated atomic -ops, so it must be exceedingly careful not to do any that would interact -with the main kernel in this regard. Hence the debug mode code (gdbstub) is -almost completely self-contained. The only external code used is the -sprintf family of functions. - -Furthermore, break.S is so complicated because single-step mode does not -switch off on entry to an exception. That means unless manually disabled, -single-stepping will blithely go on stepping into things like interrupts. -See gdbstub.txt for more information. - - -========================== -VIRTUAL INTERRUPT HANDLING -========================== - -Because accesses to the PSR is so slow, and to disable interrupts we have -to access it twice (once to read and once to write), we don't actually -disable interrupts at all if we don't have to. What we do instead is use -the ICC2 condition code flags to note virtual disablement, such that if we -then do take an interrupt, we note the flag, really disable interrupts, set -another flag and resume execution at the point the interrupt happened. -Setting condition flags as a side effect of an arithmetic or logical -instruction is really fast. This use of the ICC2 only occurs within the -kernel - it does not affect userspace. - -The flags we use are: - - (*) CCR.ICC2.Z [Zero flag] - - Set to virtually disable interrupts, clear when interrupts are - virtually enabled. Can be modified by logical instructions without - affecting the Carry flag. - - (*) CCR.ICC2.C [Carry flag] - - Clear to indicate hardware interrupts are really disabled, set otherwise. - - -What happens is this: - - (1) Normal kernel-mode operation. - - ICC2.Z is 0, ICC2.C is 1. - - (2) An interrupt occurs. The exception prologue examines ICC2.Z and - determines that nothing needs doing. This is done simply with an - unlikely BEQ instruction. - - (3) The interrupts are disabled (local_irq_disable) - - ICC2.Z is set to 1. - - (4) If interrupts were then re-enabled (local_irq_enable): - - ICC2.Z would be set to 0. - - A TIHI #2 instruction (trap #2 if condition HI - Z==0 && C==0) would - be used to trap if interrupts were now virtually enabled, but - physically disabled - which they're not, so the trap isn't taken. The - kernel would then be back to state (1). - - (5) An interrupt occurs. The exception prologue examines ICC2.Z and - determines that the interrupt shouldn't actually have happened. It - jumps aside, and there disabled interrupts by setting PSR.PIL to 14 - and then it clears ICC2.C. - - (6) If interrupts were then saved and disabled again (local_irq_save): - - ICC2.Z would be shifted into the save variable and masked off - (giving a 1). - - ICC2.Z would then be set to 1 (thus unchanged), and ICC2.C would be - unaffected (ie: 0). - - (7) If interrupts were then restored from state (6) (local_irq_restore): - - ICC2.Z would be set to indicate the result of XOR'ing the saved - value (ie: 1) with 1, which gives a result of 0 - thus leaving - ICC2.Z set. - - ICC2.C would remain unaffected (ie: 0). - - A TIHI #2 instruction would be used to again assay the current state, - but this would do nothing as Z==1. - - (8) If interrupts were then enabled (local_irq_enable): - - ICC2.Z would be cleared. ICC2.C would be left unaffected. Both - flags would now be 0. - - A TIHI #2 instruction again issued to assay the current state would - then trap as both Z==0 [interrupts virtually enabled] and C==0 - [interrupts really disabled] would then be true. - - (9) The trap #2 handler would simply enable hardware interrupts - (set PSR.PIL to 0), set ICC2.C to 1 and return. - -(10) Immediately upon returning, the pending interrupt would be taken. - -(11) The interrupt handler would take the path of actually processing the - interrupt (ICC2.Z is clear, BEQ fails as per step (2)). - -(12) The interrupt handler would then set ICC2.C to 1 since hardware - interrupts are definitely enabled - or else the kernel wouldn't be here. - -(13) On return from the interrupt handler, things would be back to state (1). - -This trap (#2) is only available in kernel mode. In user mode it will -result in SIGILL. diff --git a/Documentation/frv/mmu-layout.txt b/Documentation/frv/mmu-layout.txt deleted file mode 100644 index db10250..0000000 --- a/Documentation/frv/mmu-layout.txt +++ /dev/null @@ -1,306 +0,0 @@ - ================================= - FR451 MMU LINUX MEMORY MANAGEMENT - ================================= - -============ -MMU HARDWARE -============ - -FR451 MMU Linux puts the MMU into EDAT mode whilst running. This means that it uses both the SAT -registers and the DAT TLB to perform address translation. - -There are 8 IAMLR/IAMPR register pairs and 16 DAMLR/DAMPR register pairs for SAT mode. - -In DAT mode, there is also a TLB organised in cache format as 64 lines x 2 ways. Each line spans a -16KB range of addresses, but can match a larger region. - - -=========================== -MEMORY MANAGEMENT REGISTERS -=========================== - -Certain control registers are used by the kernel memory management routines: - - REGISTERS USAGE - ====================== ================================================== - IAMR0, DAMR0 Kernel image and data mappings - IAMR1, DAMR1 First-chance TLB lookup mapping - DAMR2 Page attachment for cache flush by page - DAMR3 Current PGD mapping - SCR0, DAMR4 Instruction TLB PGE/PTD cache - SCR1, DAMR5 Data TLB PGE/PTD cache - DAMR6-10 kmap_atomic() mappings - DAMR11 I/O mapping - CXNR mm_struct context ID - TTBR Page directory (PGD) pointer (physical address) - - -===================== -GENERAL MEMORY LAYOUT -===================== - -The physical memory layout is as follows: - - PHYSICAL ADDRESS CONTROLLER DEVICE - =================== ============== ======================================= - 00000000 - BFFFFFFF SDRAM SDRAM area - E0000000 - EFFFFFFF L-BUS CS2# VDK SLBUS/PCI window - F0000000 - F0FFFFFF L-BUS CS5# MB93493 CSC area (DAV daughter board) - F1000000 - F1FFFFFF L-BUS CS7# (CB70 CPU-card PCMCIA port I/O space) - FC000000 - FC0FFFFF L-BUS CS1# VDK MB86943 config space - FC100000 - FC1FFFFF L-BUS CS6# DM9000 NIC I/O space - FC200000 - FC2FFFFF L-BUS CS3# MB93493 CSR area (DAV daughter board) - FD000000 - FDFFFFFF L-BUS CS4# (CB70 CPU-card extra flash space) - FE000000 - FEFFFFFF Internal CPU peripherals - FF000000 - FF1FFFFF L-BUS CS0# Flash 1 - FF200000 - FF3FFFFF L-BUS CS0# Flash 2 - FFC00000 - FFC0001F L-BUS CS0# FPGA - -The virtual memory layout is: - - VIRTUAL ADDRESS PHYSICAL TRANSLATOR FLAGS SIZE OCCUPATION - ================= ======== ============== ======= ======= =================================== - 00004000-BFFFFFFF various TLB,xAMR1 D-N-??V 3GB Userspace - C0000000-CFFFFFFF 00000000 xAMPR0 -L-S--V 256MB Kernel image and data - D0000000-D7FFFFFF various TLB,xAMR1 D-NS??V 128MB vmalloc area - D8000000-DBFFFFFF various TLB,xAMR1 D-NS??V 64MB kmap() area - DC000000-DCFFFFFF various TLB 1MB Secondary kmap_atomic() frame - DD000000-DD27FFFF various DAMR 160KB Primary kmap_atomic() frame - DD040000 DAMR2/IAMR2 -L-S--V page Page cache flush attachment point - DD080000 DAMR3 -L-SC-V page Page Directory (PGD) - DD0C0000 DAMR4 -L-SC-V page Cached insn TLB Page Table lookup - DD100000 DAMR5 -L-SC-V page Cached data TLB Page Table lookup - DD140000 DAMR6 -L-S--V page kmap_atomic(KM_BOUNCE_READ) - DD180000 DAMR7 -L-S--V page kmap_atomic(KM_SKB_SUNRPC_DATA) - DD1C0000 DAMR8 -L-S--V page kmap_atomic(KM_SKB_DATA_SOFTIRQ) - DD200000 DAMR9 -L-S--V page kmap_atomic(KM_USER0) - DD240000 DAMR10 -L-S--V page kmap_atomic(KM_USER1) - E0000000-FFFFFFFF E0000000 DAMR11 -L-SC-V 512MB I/O region - -IAMPR1 and DAMPR1 are used as an extension to the TLB. - - -==================== -KMAP AND KMAP_ATOMIC -==================== - -To access pages in the page cache (which may not be directly accessible if highmem is available), -the kernel calls kmap(), does the access and then calls kunmap(); or it calls kmap_atomic(), does -the access and then calls kunmap_atomic(). - -kmap() creates an attachment between an arbitrary inaccessible page and a range of virtual -addresses by installing a PTE in a special page table. The kernel can then access this page as it -wills. When it's finished, the kernel calls kunmap() to clear the PTE. - -kmap_atomic() does something slightly different. In the interests of speed, it chooses one of two -strategies: - - (1) If possible, kmap_atomic() attaches the requested page to one of DAMPR5 through DAMPR10 - register pairs; and the matching kunmap_atomic() clears the DAMPR. This makes high memory - support really fast as there's no need to flush the TLB or modify the page tables. The DAMLR - registers being used for this are preset during boot and don't change over the lifetime of the - process. There's a direct mapping between the first few kmap_atomic() types, DAMR number and - virtual address slot. - - However, there are more kmap_atomic() types defined than there are DAMR registers available, - so we fall back to: - - (2) kmap_atomic() uses a slot in the secondary frame (determined by the type parameter), and then - locks an entry in the TLB to translate that slot to the specified page. The number of slots is - obviously limited, and their positions are controlled such that each slot is matched by a - different line in the TLB. kunmap() ejects the entry from the TLB. - -Note that the first three kmap atomic types are really just declared as placeholders. The DAMPR -registers involved are actually modified directly. - -Also note that kmap() itself may sleep, kmap_atomic() may never sleep and both always succeed; -furthermore, a driver using kmap() may sleep before calling kunmap(), but may not sleep before -calling kunmap_atomic() if it had previously called kmap_atomic(). - - -=============================== -USING MORE THAN 256MB OF MEMORY -=============================== - -The kernel cannot access more than 256MB of memory directly. The physical layout, however, permits -up to 3GB of SDRAM (possibly 3.25GB) to be made available. By using CONFIG_HIGHMEM, the kernel can -allow userspace (by way of page tables) and itself (by way of kmap) to deal with the memory -allocation. - -External devices can, of course, still DMA to and from all of the SDRAM, even if the kernel can't -see it directly. The kernel translates page references into real addresses for communicating to the -devices. - - -=================== -PAGE TABLE TOPOLOGY -=================== - -The page tables are arranged in 2-layer format. There is a middle layer (PMD) that would be used in -3-layer format tables but that is folded into the top layer (PGD) and so consumes no extra memory -or processing power. - - +------+ PGD PMD - | TTBR |--->+-------------------+ - +------+ | | : STE | - | PGE0 | PME0 : STE | - | | : STE | - +-------------------+ Page Table - | | : STE -------------->+--------+ +0x0000 - | PGE1 | PME0 : STE -----------+ | PTE0 | - | | : STE -------+ | +--------+ - +-------------------+ | | | PTE63 | - | | : STE | | +-->+--------+ +0x0100 - | PGE2 | PME0 : STE | | | PTE64 | - | | : STE | | +--------+ - +-------------------+ | | PTE127 | - | | : STE | +------>+--------+ +0x0200 - | PGE3 | PME0 : STE | | PTE128 | - | | : STE | +--------+ - +-------------------+ | PTE191 | - +--------+ +0x0300 - -Each Page Directory (PGD) is 16KB (page size) in size and is divided into 64 entries (PGEs). Each -PGE contains one Page Mid Directory (PMD). - -Each PMD is 256 bytes in size and contains a single entry (PME). Each PME holds 64 FR451 MMU -segment table entries of 4 bytes apiece. Each PME "points to" a page table. In practice, each STE -points to a subset of the page table, the first to PT+0x0000, the second to PT+0x0100, the third to -PT+0x200, and so on. - -Each PGE and PME covers 64MB of the total virtual address space. - -Each Page Table (PTD) is 16KB (page size) in size, and is divided into 4096 entries (PTEs). Each -entry can point to one 16KB page. In practice, each Linux page table is subdivided into 64 FR451 -MMU page tables. But they are all grouped together to make management easier, in particular rmap -support is then trivial. - -Grouping page tables in this fashion makes PGE caching in SCR0/SCR1 more efficient because the -coverage of the cached item is greater. - -Page tables for the vmalloc area are allocated at boot time and shared between all mm_structs. - - -================= -USER SPACE LAYOUT -================= - -For MMU capable Linux, the regions userspace code are allowed to access are kept entirely separate -from those dedicated to the kernel: - - VIRTUAL ADDRESS SIZE PURPOSE - ================= ===== =================================== - 00000000-00003fff 4KB NULL pointer access trap - 00004000-01ffffff ~32MB lower mmap space (grows up) - 02000000-021fffff 2MB Stack space (grows down from top) - 02200000-nnnnnnnn Executable mapping - nnnnnnnn- brk space (grows up) - -bfffffff upper mmap space (grows down) - -This is so arranged so as to make best use of the 16KB page tables and the way in which PGEs/PMEs -are cached by the TLB handler. The lower mmap space is filled first, and then the upper mmap space -is filled. - - -=============================== -GDB-STUB MMU DEBUGGING SERVICES -=============================== - -The gdb-stub included in this kernel provides a number of services to aid in the debugging of MMU -related kernel services: - - (*) Every time the kernel stops, certain state information is dumped into __debug_mmu. This - variable is defined in arch/frv/kernel/gdb-stub.c. Note that the gdbinit file in this - directory has some useful macros for dealing with this. - - (*) __debug_mmu.tlb[] - - This receives the current TLB contents. This can be viewed with the _tlb GDB macro: - - (gdb) _tlb - tlb[0x00]: 01000005 00718203 01000002 00718203 - tlb[0x01]: 01004002 006d4201 01004005 006d4203 - tlb[0x02]: 01008002 006d0201 01008006 00004200 - tlb[0x03]: 0100c006 007f4202 0100c002 0064c202 - tlb[0x04]: 01110005 00774201 01110002 00774201 - tlb[0x05]: 01114005 00770201 01114002 00770201 - tlb[0x06]: 01118002 0076c201 01118005 0076c201 - ... - tlb[0x3d]: 010f4002 00790200 001f4002 0054ca02 - tlb[0x3e]: 010f8005 0078c201 010f8002 0078c201 - tlb[0x3f]: 001fc002 0056ca01 001fc005 00538a01 - - (*) __debug_mmu.iamr[] - (*) __debug_mmu.damr[] - - These receive the current IAMR and DAMR contents. These can be viewed with the _amr - GDB macro: - - (gdb) _amr - AMRx DAMR IAMR - ==== ===================== ===================== - amr0 : L:c0000000 P:00000cb9 : L:c0000000 P:000004b9 - amr1 : L:01070005 P:006f9203 : L:0102c005 P:006a1201 - amr2 : L:d8d00000 P:00000000 : L:d8d00000 P:00000000 - amr3 : L:d8d04000 P:00534c0d : L:00000000 P:00000000 - amr4 : L:d8d08000 P:00554c0d : L:00000000 P:00000000 - amr5 : L:d8d0c000 P:00554c0d : L:00000000 P:00000000 - amr6 : L:d8d10000 P:00000000 : L:00000000 P:00000000 - amr7 : L:d8d14000 P:00000000 : L:00000000 P:00000000 - amr8 : L:d8d18000 P:00000000 - amr9 : L:d8d1c000 P:00000000 - amr10: L:d8d20000 P:00000000 - amr11: L:e0000000 P:e0000ccd - - (*) The current task's page directory is bound to DAMR3. - - This can be viewed with the _pgd GDB macro: - - (gdb) _pgd - $3 = {{pge = {{ste = {0x554001, 0x554101, 0x554201, 0x554301, 0x554401, - 0x554501, 0x554601, 0x554701, 0x554801, 0x554901, 0x554a01, - 0x554b01, 0x554c01, 0x554d01, 0x554e01, 0x554f01, 0x555001, - 0x555101, 0x555201, 0x555301, 0x555401, 0x555501, 0x555601, - 0x555701, 0x555801, 0x555901, 0x555a01, 0x555b01, 0x555c01, - 0x555d01, 0x555e01, 0x555f01, 0x556001, 0x556101, 0x556201, - 0x556301, 0x556401, 0x556501, 0x556601, 0x556701, 0x556801, - 0x556901, 0x556a01, 0x556b01, 0x556c01, 0x556d01, 0x556e01, - 0x556f01, 0x557001, 0x557101, 0x557201, 0x557301, 0x557401, - 0x557501, 0x557601, 0x557701, 0x557801, 0x557901, 0x557a01, - 0x557b01, 0x557c01, 0x557d01, 0x557e01, 0x557f01}}}}, {pge = {{ - ste = {0x0 <repeats 64 times>}}}} <repeats 51 times>, {pge = {{ste = { - 0x248001, 0x248101, 0x248201, 0x248301, 0x248401, 0x248501, - 0x248601, 0x248701, 0x248801, 0x248901, 0x248a01, 0x248b01, - 0x248c01, 0x248d01, 0x248e01, 0x248f01, 0x249001, 0x249101, - 0x249201, 0x249301, 0x249401, 0x249501, 0x249601, 0x249701, - 0x249801, 0x249901, 0x249a01, 0x249b01, 0x249c01, 0x249d01, - 0x249e01, 0x249f01, 0x24a001, 0x24a101, 0x24a201, 0x24a301, - 0x24a401, 0x24a501, 0x24a601, 0x24a701, 0x24a801, 0x24a901, - 0x24aa01, 0x24ab01, 0x24ac01, 0x24ad01, 0x24ae01, 0x24af01, - 0x24b001, 0x24b101, 0x24b201, 0x24b301, 0x24b401, 0x24b501, - 0x24b601, 0x24b701, 0x24b801, 0x24b901, 0x24ba01, 0x24bb01, - 0x24bc01, 0x24bd01, 0x24be01, 0x24bf01}}}}, {pge = {{ste = { - 0x0 <repeats 64 times>}}}} <repeats 11 times>} - - (*) The PTD last used by the instruction TLB miss handler is attached to DAMR4. - (*) The PTD last used by the data TLB miss handler is attached to DAMR5. - - These can be viewed with the _ptd_i and _ptd_d GDB macros: - - (gdb) _ptd_d - $5 = {{pte = 0x0} <repeats 127 times>, {pte = 0x539b01}, { - pte = 0x0} <repeats 896 times>, {pte = 0x719303}, {pte = 0x6d5303}, { - pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, { - pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x6a1303}, { - pte = 0x0} <repeats 12 times>, {pte = 0x709303}, {pte = 0x0}, {pte = 0x0}, - {pte = 0x6fd303}, {pte = 0x6f9303}, {pte = 0x6f5303}, {pte = 0x0}, { - pte = 0x6ed303}, {pte = 0x531b01}, {pte = 0x50db01}, { - pte = 0x0} <repeats 13 times>, {pte = 0x5303}, {pte = 0x7f5303}, { - pte = 0x509b01}, {pte = 0x505b01}, {pte = 0x7c9303}, {pte = 0x7b9303}, { - pte = 0x7b5303}, {pte = 0x7b1303}, {pte = 0x7ad303}, {pte = 0x0}, { - pte = 0x0}, {pte = 0x7a1303}, {pte = 0x0}, {pte = 0x795303}, {pte = 0x0}, { - pte = 0x78d303}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, { - pte = 0x0}, {pte = 0x775303}, {pte = 0x771303}, {pte = 0x76d303}, { - pte = 0x0}, {pte = 0x765303}, {pte = 0x7c5303}, {pte = 0x501b01}, { - pte = 0x4f1b01}, {pte = 0x4edb01}, {pte = 0x0}, {pte = 0x4f9b01}, { - pte = 0x4fdb01}, {pte = 0x0} <repeats 2992 times>} diff --git a/Documentation/gpio/00-INDEX b/Documentation/gpio/00-INDEX index 179beb2..17e19a6 100644 --- a/Documentation/gpio/00-INDEX +++ b/Documentation/gpio/00-INDEX @@ -1,17 +1,4 @@ 00-INDEX - This file -gpio.txt - - Introduction to GPIOs and their kernel interfaces -consumer.txt - - How to obtain and use GPIOs in a driver -driver.txt - - How to write a GPIO driver -drivers-on-gpio.txt: - - Drivers in other subsystems that can use GPIO to provide more - complex functionality. -board.txt - - How to assign GPIOs to a consumer device and a function sysfs.txt - Information about the GPIO sysfs interface -gpio-legacy.txt - - Historical documentation of the deprecated GPIO integer interface diff --git a/Documentation/gpio/sysfs.txt b/Documentation/gpio/sysfs.txt index 6cdeab8..58eeab8 100644 --- a/Documentation/gpio/sysfs.txt +++ b/Documentation/gpio/sysfs.txt @@ -32,9 +32,8 @@ standard kernels won't know about. And for some tasks, simple userspace GPIO drivers could be all that the system really needs. DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. -PLEASE READ THE DOCUMENT NAMED "drivers-on-gpio.txt" IN THIS DOCUMENTATION -DIRECTORY TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. -REALLY. +PLEASE READ THE DOCUMENT AT Documentation/driver-api/gpio/drivers-on-gpio.rst +TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY. Paths in Sysfs -------------- diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst new file mode 100644 index 0000000..e8c8441 --- /dev/null +++ b/Documentation/gpu/drivers.rst @@ -0,0 +1,21 @@ +======================== +GPU Driver Documentation +======================== + +.. toctree:: + + i915 + meson + pl111 + tegra + tinydrm + tve200 + vc4 + bridge/dw-hdmi + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 2dcf5b4..1dffd1a 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -286,6 +286,9 @@ Atomic Mode Setting Function Reference .. kernel-doc:: drivers/gpu/drm/drm_atomic.c :export: +.. kernel-doc:: drivers/gpu/drm/drm_atomic.c + :internal: + CRTC Abstraction ================ @@ -547,8 +550,9 @@ Explicit Fencing Properties Existing KMS Properties ----------------------- -The following table gives description of drm properties exposed by -various modules/drivers. +The following table gives description of drm properties exposed by various +modules/drivers. Because this table is very unwieldy, do not add any new +properties here. Instead document them in a section above. .. csv-table:: :header-rows: 1 diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index c36586da..00288f3 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,16 +10,9 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi - i915 - meson - pl111 - tegra - tinydrm - tve200 - vc4 + drivers vga-switcheroo vgaarbiter - bridge/dw-hdmi todo .. only:: subproject and html diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv index 927b65e..6b28b01 100644 --- a/Documentation/gpu/kms-properties.csv +++ b/Documentation/gpu/kms-properties.csv @@ -1,5 +1,4 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,Description/Restrictions -,,“scaling mode”,ENUM,"{ ""None"", ""Full"", ""Center"", ""Full aspect"" }",Connector,"Supported by: amdgpu, gma500, i915, nouveau and radeon." ,DVI-I,“subconnector”,ENUM,"{ “Unknown”, “DVI-D”, “DVI-A” }",Connector,TBD ,,“select subconnector”,ENUM,"{ “Automatic”, “DVI-D”, “DVI-A” }",Connector,TBD ,TV,“subconnector”,ENUM,"{ ""Unknown"", ""Composite"", ""SVIDEO"", ""Component"", ""SCART"" }",Connector,TBD diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 1e59337..f4d0b34 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -212,6 +212,16 @@ probably use drm_fb_helper_fbdev_teardown(). Contact: Maintainer of the driver you plan to convert +idr_init_base() +--------------- + +DRM core&drivers uses a lot of idr (integer lookup directories) for mapping +userspace IDs to internal objects, and in most places ID=0 means NULL and hence +is never used. Switching to idr_init_base() for these would make the idr more +efficient. + +Contact: Daniel Vetter + Core refactorings ================= @@ -440,5 +450,12 @@ See drivers/gpu/drm/amd/display/TODO for tasks. Contact: Harry Wentland, Alex Deucher +i915 +---- + +- Our early/late pm callbacks could be removed in favour of using + device_link_add to model the dependency between i915 and snd_had. See + https://dri.freedesktop.org/docs/drm/driver-api/device_link.html + Outside DRM =========== diff --git a/Documentation/index.rst b/Documentation/index.rst index ef5080c..3b99ab9 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -64,6 +64,7 @@ merged much easier. dev-tools/index doc-guide/index kernel-hacking/index + trace/index maintainer/index Kernel API documentation diff --git a/Documentation/infiniband/sysfs.txt b/Documentation/infiniband/sysfs.txt index 77570d1..9fab506 100644 --- a/Documentation/infiniband/sysfs.txt +++ b/Documentation/infiniband/sysfs.txt @@ -1,129 +1,4 @@ SYSFS FILES - For each InfiniBand device, the InfiniBand drivers create the - following files under /sys/class/infiniband/<device name>: - - node_type - Node type (CA, switch or router) - node_guid - Node GUID - sys_image_guid - System image GUID - - In addition, there is a "ports" subdirectory, with one subdirectory - for each port. For example, if mthca0 is a 2-port HCA, there will - be two directories: - - /sys/class/infiniband/mthca0/ports/1 - /sys/class/infiniband/mthca0/ports/2 - - (A switch will only have a single "0" subdirectory for switch port - 0; no subdirectory is created for normal switch ports) - - In each port subdirectory, the following files are created: - - cap_mask - Port capability mask - lid - Port LID - lid_mask_count - Port LID mask count - rate - Port data rate (active width * active speed) - sm_lid - Subnet manager LID for port's subnet - sm_sl - Subnet manager SL for port's subnet - state - Port state (DOWN, INIT, ARMED, ACTIVE or ACTIVE_DEFER) - phys_state - Port physical state (Sleep, Polling, LinkUp, etc) - - There is also a "counters" subdirectory, with files - - VL15_dropped - excessive_buffer_overrun_errors - link_downed - link_error_recovery - local_link_integrity_errors - port_rcv_constraint_errors - port_rcv_data - port_rcv_errors - port_rcv_packets - port_rcv_remote_physical_errors - port_rcv_switch_relay_errors - port_xmit_constraint_errors - port_xmit_data - port_xmit_discards - port_xmit_packets - symbol_error - - Each of these files contains the corresponding value from the port's - Performance Management PortCounters attribute, as described in - section 16.1.3.5 of the InfiniBand Architecture Specification. - - The "pkeys" and "gids" subdirectories contain one file for each - entry in the port's P_Key or GID table respectively. For example, - ports/1/pkeys/10 contains the value at index 10 in port 1's P_Key - table. - - There is an optional "hw_counters" subdirectory that may be under either - the parent device or the port subdirectories or both. If present, - there are a list of counters provided by the hardware. They may match - some of the counters in the counters directory, but they often include - many other counters. In addition to the various counters, there will - be a file named "lifespan" that configures how frequently the core - should update the counters when they are being accessed (counters are - not updated if they are not being accessed). The lifespan is in milli- - seconds and defaults to 10 unless set to something else by the driver. - Users may echo a value between 0 - 10000 to the lifespan file to set - the length of time between updates in milliseconds. - -MTHCA - - The Mellanox HCA driver also creates the files: - - hw_rev - Hardware revision number - fw_ver - Firmware version - hca_type - HCA type: "MT23108", "MT25208 (MT23108 compat mode)", - or "MT25208" - -HFI1 - - The hfi1 driver also creates these additional files: - - hw_rev - hardware revision - board_id - manufacturing board id - tempsense - thermal sense information - serial - board serial number - nfreectxts - number of free user contexts - nctxts - number of allowed contexts (PSM2) - chip_reset - diagnostic (root only) - boardversion - board version - - sdma<N>/ - one directory per sdma engine (0 - 15) - sdma<N>/cpu_list - read-write, list of cpus for user-process to sdma - engine assignment. - sdma<N>/vl - read-only, vl the sdma engine maps to. - - The new interface will give the user control on the affinity settings - for the hfi1 device. - As an example, to set an sdma engine irq affinity and thread affinity - of a user processes to use the sdma engine, which is "near" in terms - of NUMA configuration, or physical cpu location, the user will do: - - echo "3" > /proc/irq/<N>/smp_affinity_list - echo "4-7" > /sys/devices/.../sdma3/cpu_list - cat /sys/devices/.../sdma3/vl - 0 - echo "8" > /proc/irq/<M>/smp_affinity_list - echo "9-12" > /sys/devices/.../sdma4/cpu_list - cat /sys/devices/.../sdma4/vl - 1 - - to make sure that when a process runs on cpus 4,5,6, or 7, - and uses vl=0, then sdma engine 3 is selected by the driver, - and also the interrupt of the sdma engine 3 is steered to cpu 3. - Similarly, when a process runs on cpus 9,10,11, or 12 and sets vl=1, - then engine 4 will be selected and the irq of the sdma engine 4 is - steered to cpu 8. - This assumes that in the above N is the irq number of "sdma3", - and M is irq number of "sdma4" in the /proc/interrupts file. - - ports/1/ - CCMgtA/ - cc_settings_bin - CCA tables used by PSM2 - cc_table_bin - cc_prescan - enable prescaning for faster BECN response - sc2v/ - 32 files (0 - 31) used to translate sl->vl - sl2sc/ - 32 files (0 - 31) used to translate sl->sc - vl2mtu/ - 16 (0 - 15) files used to determine MTU for vl +The sysfs interface has moved to +Documentation/ABI/stable/sysfs-class-infiniband. diff --git a/Documentation/input/devices/alps.rst b/Documentation/input/devices/alps.rst index 6779148..b556d6b 100644 --- a/Documentation/input/devices/alps.rst +++ b/Documentation/input/devices/alps.rst @@ -192,10 +192,13 @@ The final v3 packet type is the trackstick packet:: byte 0: 1 1 x7 y7 1 1 1 1 byte 1: 0 x6 x5 x4 x3 x2 x1 x0 byte 2: 0 y6 y5 y4 y3 y2 y1 y0 - byte 3: 0 1 0 0 1 0 0 0 - byte 4: 0 z4 z3 z2 z1 z0 ? ? + byte 3: 0 1 TP SW 1 M R L + byte 4: 0 z6 z5 z4 z3 z2 z1 z0 byte 5: 0 0 1 1 1 1 1 1 +TP means Tap SW status when tap processing is enabled or Press status when press +processing is enabled. SW means scroll up when 4 buttons are available. + ALPS Absolute Mode - Protocol Version 4 --------------------------------------- diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 6501389..84bb74d 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -305,7 +305,6 @@ Code Seq#(hex) Include File Comments 0xA0 all linux/sdp/sdp.h Industrial Device Project <mailto:kenji@bitgate.com> 0xA1 0 linux/vtpm_proxy.h TPM Emulator Proxy Driver -0xA2 00-0F arch/tile/include/asm/hardwall.h 0xA3 80-8F Port ACL in development: <mailto:tlewis@mindspring.com> 0xA3 90-9F linux/dtlk.h diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI index 1688b5a..021aa9c 100644 --- a/Documentation/isdn/INTERFACE.CAPI +++ b/Documentation/isdn/INTERFACE.CAPI @@ -18,7 +18,7 @@ corresponding hardware driver. Kernel CAPI then forwards CAPI messages in both directions between the application and the hardware driver. Format and semantics of CAPI messages are specified in the CAPI 2.0 standard. -This standard is freely available from http://www.capi.org. +This standard is freely available from https://www.capi.org. 2. Driver and Device Registration diff --git a/Documentation/isdn/README b/Documentation/isdn/README index 32d4e80..74bd2bd 100644 --- a/Documentation/isdn/README +++ b/Documentation/isdn/README @@ -33,10 +33,10 @@ README for the ISDN-subsystem de.alt.comm.isdn4linux There is also a well maintained FAQ in English available at - http://www.mhessler.de/i4lfaq/ + https://www.mhessler.de/i4lfaq/ It can be viewed online, or downloaded in sgml/text/html format. The FAQ can also be viewed online at - http://www.isdn4linux.de/faq/ + https://www.isdn4linux.de/faq/i4lfaq.html or downloaded from ftp://ftp.isdn4linux.de/pub/isdn4linux/FAQ/ diff --git a/Documentation/isdn/README.FAQ b/Documentation/isdn/README.FAQ index 356f794..e5dd1ad 100644 --- a/Documentation/isdn/README.FAQ +++ b/Documentation/isdn/README.FAQ @@ -8,9 +8,9 @@ You find it in: In case you just want to see the FAQ online, or download the newest version, you can have a look at my website: -http://www.mhessler.de/i4lfaq/ (view + download) +https://www.mhessler.de/i4lfaq/ (view + download) or: -http://www.isdn4linux.de/faq/ (view) +https://www.isdn4linux.de/faq/4lfaq.html (view) As the extension tells, the FAQ is in SGML format, and you can convert it into text/html/... format by using the sgml2txt/sgml2html/... tools. diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset index 7534c60..9b1ce27 100644 --- a/Documentation/isdn/README.gigaset +++ b/Documentation/isdn/README.gigaset @@ -29,8 +29,9 @@ GigaSet 307x Device Driver T-Com Sinus 721 data Chicago 390 USB (KPN) - See also http://www.erbze.info/sinus_gigaset.htm and - http://gigaset307x.sourceforge.net/ + See also http://www.erbze.info/sinus_gigaset.htm + (archived at https://web.archive.org/web/20100717020421/http://www.erbze.info:80/sinus_gigaset.htm ) and + http://gigaset307x.sourceforge.net/ We had also reports from users of Gigaset M105 who could use the drivers with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.5.) @@ -52,7 +53,7 @@ GigaSet 307x Device Driver to use CAPI 2.0 or ISDN4Linux for ISDN connections (voice or data). There are some user space tools available at - http://sourceforge.net/projects/gigaset307x/ + https://sourceforge.net/projects/gigaset307x/ which provide access to additional device specific functions like SMS, phonebook or call journal. @@ -202,7 +203,7 @@ GigaSet 307x Device Driver You can use some configuration tool of your distribution to configure this "modem" or configure pppd/wvdial manually. There are some example ppp configuration files and chat scripts in the gigaset-VERSION/ppp directory - in the driver packages from http://sourceforge.net/projects/gigaset307x/. + in the driver packages from https://sourceforge.net/projects/gigaset307x/. Please note that the USB drivers are not able to change the state of the control lines. This means you must use "Stupid Mode" if you are using wvdial or you should use the nocrtscts option of pppd. @@ -361,7 +362,7 @@ GigaSet 307x Device Driver --------------------------- If you can't solve problems with the driver on your own, feel free to use one of the forums, bug trackers, or mailing lists on - http://sourceforge.net/projects/gigaset307x + https://sourceforge.net/projects/gigaset307x or write an electronic mail to the maintainers. Try to provide as much information as possible, such as @@ -391,11 +392,12 @@ GigaSet 307x Device Driver 4. Links, other software --------------------- - Sourceforge project developing this driver and associated tools - http://sourceforge.net/projects/gigaset307x + https://sourceforge.net/projects/gigaset307x - Yahoo! Group on the Siemens Gigaset family of devices - http://de.groups.yahoo.com/group/Siemens-Gigaset + https://de.groups.yahoo.com/group/Siemens-Gigaset - Siemens Gigaset/T-Sinus compatibility table http://www.erbze.info/sinus_gigaset.htm + (archived at https://web.archive.org/web/20100717020421/http://www.erbze.info:80/sinus_gigaset.htm ) 5. Credits diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index ac2363e..6c9c69e 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -50,10 +50,6 @@ LDFLAGS_MODULE -------------------------------------------------- Additional options used for $(LD) when linking modules. -LDFLAGS_vmlinux --------------------------------------------------- -Additional options passed to final link of vmlinux. - KBUILD_VERBOSE -------------------------------------------------- Set the kbuild verbosity. Can be assigned same values as "V=...". diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index bbc99c0..7233118 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -119,7 +119,7 @@ Examples: 15% of tristates will be set to 'y', 15% to 'm', 70% to 'n' ______________________________________________________________________ -Environment variables for 'silentoldconfig' +Environment variables for 'syncconfig' KCONFIG_NOSILENTUPDATE -------------------------------------------------- diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 71e9fee..048fc39 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -153,12 +153,18 @@ more details, with real examples. configuration. Kbuild compiles all the $(obj-y) files. It then calls - "$(LD) -r" to merge these files into one built-in.o file. - built-in.o is later linked into vmlinux by the parent Makefile. + "$(AR) rcSTP" to merge these files into one built-in.a file. + This is a thin archive without a symbol table, which makes it + unsuitable as a linker input. + + The scripts/link-vmlinux.sh script later makes an aggregate + built-in.a with "${AR} rcsTP", which creates the thin archive + with a symbol table and an index, making it a valid input for + the final vmlinux link passes. The order of files in $(obj-y) is significant. Duplicates in the lists are allowed: the first instance will be linked into - built-in.o and succeeding instances will be ignored. + built-in.a and succeeding instances will be ignored. Link order is significant, because certain functions (module_init() / __initcall) will be called during boot in the @@ -222,7 +228,7 @@ more details, with real examples. Note: Of course, when you are building objects into the kernel, the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, kbuild will build an ext2.o file for you out of the individual - parts and then link this into built-in.o, as you would expect. + parts and then link this into built-in.a, as you would expect. --- 3.4 Objects which export symbols @@ -232,7 +238,7 @@ more details, with real examples. --- 3.5 Library file goals - lib-y Objects listed with obj-* are used for modules, or - combined in a built-in.o for that specific directory. + combined in a built-in.a for that specific directory. There is also the possibility to list objects that will be included in a library, lib.a. All objects listed with lib-y are combined in a single @@ -244,7 +250,7 @@ more details, with real examples. Note that the same kbuild makefile may list files to be built-in and to be part of a library. Therefore the same directory - may contain both a built-in.o and a lib.a file. + may contain both a built-in.a and a lib.a file. Example: #arch/x86/lib/Makefile @@ -831,12 +837,6 @@ When kbuild executes, the following steps are followed (roughly): Note: ldflags-y can be used to further customise the flags used. See chapter 3.7. - LDFLAGS_MODULE Options for $(LD) when linking modules - - LDFLAGS_MODULE is used to set specific flags for $(LD) when - linking the .ko files used for modules. - Default is "-r", for relocatable output. - LDFLAGS_vmlinux Options for $(LD) when linking vmlinux LDFLAGS_vmlinux is used to specify additional flags to pass to @@ -986,7 +986,7 @@ When kbuild executes, the following steps are followed (roughly): $(head-y) lists objects to be linked first in vmlinux. $(libs-y) lists directories where a lib.a archive can be located. - The rest list directories where a built-in.o object file can be + The rest list directories where a built-in.a object file can be located. $(init-y) objects will be located after $(head-y). @@ -1071,7 +1071,7 @@ When kbuild executes, the following steps are followed (roughly): extra-y := head.o init_task.o In this example, extra-y is used to list object files that - shall be built, but shall not be linked as part of built-in.o. + shall be built, but shall not be linked as part of built-in.a. --- 6.7 Commands useful for building a boot image diff --git a/Documentation/locking/lockdep-design.txt b/Documentation/locking/lockdep-design.txt index 9de1c15..49f58a0 100644 --- a/Documentation/locking/lockdep-design.txt +++ b/Documentation/locking/lockdep-design.txt @@ -27,7 +27,8 @@ lock-class. State ----- -The validator tracks lock-class usage history into 4n + 1 separate state bits: +The validator tracks lock-class usage history into 4 * nSTATEs + 1 separate +state bits: - 'ever held in STATE context' - 'ever held as readlock in STATE context' @@ -37,7 +38,6 @@ The validator tracks lock-class usage history into 4n + 1 separate state bits: Where STATE can be either one of (kernel/locking/lockdep_states.h) - hardirq - softirq - - reclaim_fs - 'ever used' [ == !unused ] @@ -169,6 +169,53 @@ Note: When changing code to use the _nested() primitives, be careful and check really thoroughly that the hierarchy is correctly mapped; otherwise you can get false positives or false negatives. +Annotations +----------- + +Two constructs can be used to annotate and check where and if certain locks +must be held: lockdep_assert_held*(&lock) and lockdep_*pin_lock(&lock). + +As the name suggests, lockdep_assert_held* family of macros assert that a +particular lock is held at a certain time (and generate a WARN() otherwise). +This annotation is largely used all over the kernel, e.g. kernel/sched/ +core.c + + void update_rq_clock(struct rq *rq) + { + s64 delta; + + lockdep_assert_held(&rq->lock); + [...] + } + +where holding rq->lock is required to safely update a rq's clock. + +The other family of macros is lockdep_*pin_lock(), which is admittedly only +used for rq->lock ATM. Despite their limited adoption these annotations +generate a WARN() if the lock of interest is "accidentally" unlocked. This turns +out to be especially helpful to debug code with callbacks, where an upper +layer assumes a lock remains taken, but a lower layer thinks it can maybe drop +and reacquire the lock ("unwittingly" introducing races). lockdep_pin_lock() +returns a 'struct pin_cookie' that is then used by lockdep_unpin_lock() to check +that nobody tampered with the lock, e.g. kernel/sched/sched.h + + static inline void rq_pin_lock(struct rq *rq, struct rq_flags *rf) + { + rf->cookie = lockdep_pin_lock(&rq->lock); + [...] + } + + static inline void rq_unpin_lock(struct rq *rq, struct rq_flags *rf) + { + [...] + lockdep_unpin_lock(&rq->lock, rf->cookie); + } + +While comments about locking requirements might provide useful information, +the runtime checks performed by annotations are invaluable when debugging +locking problems and they carry the same level of details when inspecting +code. Always prefer annotations when in doubt! + Proof of 100% correctness: -------------------------- diff --git a/Documentation/media/kapi/cec-core.rst b/Documentation/media/kapi/cec-core.rst index 62b9a14..a9f53f0 100644 --- a/Documentation/media/kapi/cec-core.rst +++ b/Documentation/media/kapi/cec-core.rst @@ -110,11 +110,14 @@ your driver: void (*adap_status)(struct cec_adapter *adap, struct seq_file *file); void (*adap_free)(struct cec_adapter *adap); + /* Error injection callbacks */ + ... + /* High-level callbacks */ ... }; -The five low-level ops deal with various aspects of controlling the CEC adapter +The seven low-level ops deal with various aspects of controlling the CEC adapter hardware: @@ -286,6 +289,70 @@ handling the receive interrupt. The framework expects to see the cec_transmit_do call before the cec_received_msg call, otherwise it can get confused if the received message was in reply to the transmitted message. +Optional: Implementing Error Injection Support +---------------------------------------------- + +If the CEC adapter supports Error Injection functionality, then that can +be exposed through the Error Injection callbacks: + +.. code-block:: none + + struct cec_adap_ops { + /* Low-level callbacks */ + ... + + /* Error injection callbacks */ + int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf); + bool (*error_inj_parse_line)(struct cec_adapter *adap, char *line); + + /* High-level CEC message callback */ + ... + }; + +If both callbacks are set, then an ``error-inj`` file will appear in debugfs. +The basic syntax is as follows: + +Leading spaces/tabs are ignored. If the next character is a ``#`` or the end of the +line was reached, then the whole line is ignored. Otherwise a command is expected. + +This basic parsing is done in the CEC Framework. It is up to the driver to decide +what commands to implement. The only requirement is that the command ``clear`` without +any arguments must be implemented and that it will remove all current error injection +commands. + +This ensures that you can always do ``echo clear >error-inj`` to clear any error +injections without having to know the details of the driver-specific commands. + +Note that the output of ``error-inj`` shall be valid as input to ``error-inj``. +So this must work: + +.. code-block:: none + + $ cat error-inj >einj.txt + $ cat einj.txt >error-inj + +The first callback is called when this file is read and it should show the +the current error injection state: + +.. c:function:: + int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf); + +It is recommended that it starts with a comment block with basic usage +information. It returns 0 for success and an error otherwise. + +The second callback will parse commands written to the ``error-inj`` file: + +.. c:function:: + bool (*error_inj_parse_line)(struct cec_adapter *adap, char *line); + +The ``line`` argument points to the start of the command. Any leading +spaces or tabs have already been skipped. It is a single line only (so there +are no embedded newlines) and it is 0-terminated. The callback is free to +modify the contents of the buffer. It is only called for lines containing a +command, so this callback is never called for empty lines or comment lines. + +Return true if the command was valid or false if there were syntax errors. + Implementing the High-Level CEC Adapter --------------------------------------- @@ -298,6 +365,9 @@ CEC protocol driven. The following high-level callbacks are available: /* Low-level callbacks */ ... + /* Error injection callbacks */ + ... + /* High-level CEC message callback */ int (*received)(struct cec_adapter *adap, struct cec_msg *msg); }; diff --git a/Documentation/media/lirc.h.rst.exceptions b/Documentation/media/lirc.h.rst.exceptions index c6e3a35..984b61d 100644 --- a/Documentation/media/lirc.h.rst.exceptions +++ b/Documentation/media/lirc.h.rst.exceptions @@ -57,6 +57,7 @@ ignore symbol RC_PROTO_RC6_MCE ignore symbol RC_PROTO_SHARP ignore symbol RC_PROTO_XMP ignore symbol RC_PROTO_CEC +ignore symbol RC_PROTO_IMON # Undocumented macros diff --git a/Documentation/media/uapi/cec/cec-api.rst b/Documentation/media/uapi/cec/cec-api.rst index b68ca9c..1e2cf49 100644 --- a/Documentation/media/uapi/cec/cec-api.rst +++ b/Documentation/media/uapi/cec/cec-api.rst @@ -23,6 +23,7 @@ This part describes the CEC: Consumer Electronics Control cec-intro cec-funcs + cec-pin-error-inj cec-header diff --git a/Documentation/media/uapi/cec/cec-pin-error-inj.rst b/Documentation/media/uapi/cec/cec-pin-error-inj.rst new file mode 100644 index 0000000..464b006 --- /dev/null +++ b/Documentation/media/uapi/cec/cec-pin-error-inj.rst @@ -0,0 +1,325 @@ +CEC Pin Framework Error Injection +================================= + +The CEC Pin Framework is a core CEC framework for CEC hardware that only +has low-level support for the CEC bus. Most hardware today will have +high-level CEC support where the hardware deals with driving the CEC bus, +but some older devices aren't that fancy. However, this framework also +allows you to connect the CEC pin to a GPIO on e.g. a Raspberry Pi and +you have now made a CEC adapter. + +What makes doing this so interesting is that since we have full control +over the bus it is easy to support error injection. This is ideal to +test how well CEC adapters can handle error conditions. + +Currently only the cec-gpio driver (when the CEC line is directly +connected to a pull-up GPIO line) and the AllWinner A10/A20 drm driver +support this framework. + +If ``CONFIG_CEC_PIN_ERROR_INJ`` is enabled, then error injection is available +through debugfs. Specifically, in ``/sys/kernel/debug/cec/cecX/`` there is +now an ``error-inj`` file. + +.. note:: + + The error injection commands are not a stable ABI and may change in the + future. + +With ``cat error-inj`` you can see both the possible commands and the current +error injection status:: + + $ cat /sys/kernel/debug/cec/cec0/error-inj + # Clear error injections: + # clear clear all rx and tx error injections + # rx-clear clear all rx error injections + # tx-clear clear all tx error injections + # <op> clear clear all rx and tx error injections for <op> + # <op> rx-clear clear all rx error injections for <op> + # <op> tx-clear clear all tx error injections for <op> + # + # RX error injection: + # <op>[,<mode>] rx-nack NACK the message instead of sending an ACK + # <op>[,<mode>] rx-low-drive <bit> force a low-drive condition at this bit position + # <op>[,<mode>] rx-add-byte add a spurious byte to the received CEC message + # <op>[,<mode>] rx-remove-byte remove the last byte from the received CEC message + # <op>[,<mode>] rx-arb-lost <poll> generate a POLL message to trigger an arbitration lost + # + # TX error injection settings: + # tx-ignore-nack-until-eom ignore early NACKs until EOM + # tx-custom-low-usecs <usecs> define the 'low' time for the custom pulse + # tx-custom-high-usecs <usecs> define the 'high' time for the custom pulse + # tx-custom-pulse transmit the custom pulse once the bus is idle + # + # TX error injection: + # <op>[,<mode>] tx-no-eom don't set the EOM bit + # <op>[,<mode>] tx-early-eom set the EOM bit one byte too soon + # <op>[,<mode>] tx-add-bytes <num> append <num> (1-255) spurious bytes to the message + # <op>[,<mode>] tx-remove-byte drop the last byte from the message + # <op>[,<mode>] tx-short-bit <bit> make this bit shorter than allowed + # <op>[,<mode>] tx-long-bit <bit> make this bit longer than allowed + # <op>[,<mode>] tx-custom-bit <bit> send the custom pulse instead of this bit + # <op>[,<mode>] tx-short-start send a start pulse that's too short + # <op>[,<mode>] tx-long-start send a start pulse that's too long + # <op>[,<mode>] tx-custom-start send the custom pulse instead of the start pulse + # <op>[,<mode>] tx-last-bit <bit> stop sending after this bit + # <op>[,<mode>] tx-low-drive <bit> force a low-drive condition at this bit position + # + # <op> CEC message opcode (0-255) or 'any' + # <mode> 'once' (default), 'always', 'toggle' or 'off' + # <bit> CEC message bit (0-159) + # 10 bits per 'byte': bits 0-7: data, bit 8: EOM, bit 9: ACK + # <poll> CEC poll message used to test arbitration lost (0x00-0xff, default 0x0f) + # <usecs> microseconds (0-10000000, default 1000) + + clear + +You can write error injection commands to ``error-inj`` using +``echo 'cmd' >error-inj`` or ``cat cmd.txt >error-inj``. The ``cat error-inj`` +output contains the current error commands. You can save the output to a file +and use it as an input to ``error-inj`` later. + +Basic Syntax +------------ + +Leading spaces/tabs are ignored. If the next character is a ``#`` or the end +of the line was reached, then the whole line is ignored. Otherwise a command +is expected. + +The error injection commands fall in two main groups: those relating to +receiving CEC messages and those relating to transmitting CEC messages. In +addition, there are commands to clear existing error injection commands and +to create custom pulses on the CEC bus. + +Most error injection commands can be executed for specific CEC opcodes or for +all opcodes (``any``). Each command also has a 'mode' which can be ``off`` +(can be used to turn off an existing error injection command), ``once`` +(the default) which will trigger the error injection only once for the next +received or transmitted message, ``always`` to always trigger the error +injection and ``toggle`` to toggle the error injection on or off for every +transmit or receive. + +So '``any rx-nack``' will NACK the next received CEC message, +'``any,always rx-nack``' will NACK all received CEC messages and +'``0x82,toggle rx-nack``' will only NACK if an Active Source message was +received and do that only for every other received message. + +After an error was injected with mode ``once`` the error injection command +is cleared automatically, so ``once`` is a one-time deal. + +All combinations of ``<op>`` and error injection commands can co-exist. So +this is fine:: + + 0x9e tx-add-bytes 1 + 0x9e tx-early-eom + 0x9f tx-add-bytes 2 + any rx-nack + +All four error injection commands will be active simultaneously. + +However, if the same ``<op>`` and command combination is specified, +but with different arguments:: + + 0x9e tx-add-bytes 1 + 0x9e tx-add-bytes 2 + +Then the second will overwrite the first. + +Clear Error Injections +---------------------- + +``clear`` + Clear all error injections. + +``rx-clear`` + Clear all receive error injections + +``tx-clear`` + Clear all transmit error injections + +``<op> clear`` + Clear all error injections for the given opcode. + +``<op> rx-clear`` + Clear all receive error injections for the given opcode. + +``<op> tx-clear`` + Clear all transmit error injections for the given opcode. + +Receive Messages +---------------- + +``<op>[,<mode>] rx-nack`` + NACK broadcast messages and messages directed to this CEC adapter. + Every byte of the message will be NACKed in case the transmitter + keeps transmitting after the first byte was NACKed. + +``<op>[,<mode>] rx-low-drive <bit>`` + Force a Low Drive condition at this bit position. If <op> specifies + a specific CEC opcode then the bit position must be at least 18, + otherwise the opcode hasn't been received yet. This tests if the + transmitter can handle the Low Drive condition correctly and reports + the error correctly. Note that a Low Drive in the first 4 bits can also + be interpreted as an Arbitration Lost condition by the transmitter. + This is implementation dependent. + +``<op>[,<mode>] rx-add-byte`` + Add a spurious 0x55 byte to the received CEC message, provided + the message was 15 bytes long or less. This is useful to test + the high-level protocol since spurious bytes should be ignored. + +``<op>[,<mode>] rx-remove-byte`` + Remove the last byte from the received CEC message, provided it + was at least 2 bytes long. This is useful to test the high-level + protocol since messages that are too short should be ignored. + +``<op>[,<mode>] rx-arb-lost <poll>`` + Generate a POLL message to trigger an Arbitration Lost condition. + This command is only allowed for ``<op>`` values of ``next`` or ``all``. + As soon as a start bit has been received the CEC adapter will switch + to transmit mode and it will transmit a POLL message. By default this is + 0x0f, but it can also be specified explicitly via the ``<poll>`` argument. + + This command can be used to test the Arbitration Lost condition in + the remote CEC transmitter. Arbitration happens when two CEC adapters + start sending a message at the same time. In that case the initiator + with the most leading zeroes wins and the other transmitter has to + stop transmitting ('Arbitration Lost'). This is very hard to test, + except by using this error injection command. + + This does not work if the remote CEC transmitter has logical address + 0 ('TV') since that will always win. + +Transmit Messages +----------------- + +``tx-ignore-nack-until-eom`` + This setting changes the behavior of transmitting CEC messages. Normally + as soon as the receiver NACKs a byte the transmit will stop, but the + specification also allows that the full message is transmitted and only + at the end will the transmitter look at the ACK bit. This is not + recommended behavior since there is no point in keeping the CEC bus busy + for longer than is strictly needed. Especially given how slow the bus is. + + This setting can be used to test how well a receiver deals with + transmitters that ignore NACKs until the very end of the message. + +``<op>[,<mode>] tx-no-eom`` + Don't set the EOM bit. Normally the last byte of the message has the EOM + (End-Of-Message) bit set. With this command the transmit will just stop + without ever sending an EOM. This can be used to test how a receiver + handles this case. Normally receivers have a time-out after which + they will go back to the Idle state. + +``<op>[,<mode>] tx-early-eom`` + Set the EOM bit one byte too soon. This obviously only works for messages + of two bytes or more. The EOM bit will be set for the second-to-last byte + and not for the final byte. The receiver should ignore the last byte in + this case. Since the resulting message is likely to be too short for this + same reason the whole message is typically ignored. The receiver should be + in Idle state after the last byte was transmitted. + +``<op>[,<mode>] tx-add-bytes <num>`` + Append ``<num>`` (1-255) spurious bytes to the message. The extra bytes + have the value of the byte position in the message. So if you transmit a + two byte message (e.g. a Get CEC Version message) and add 2 bytes, then + the full message received by the remote CEC adapter is + ``0x40 0x9f 0x02 0x03``. + + This command can be used to test buffer overflows in the receiver. E.g. + what does it do when it receives more than the maximum message size of 16 + bytes. + +``<op>[,<mode>] tx-remove-byte`` + Drop the last byte from the message, provided the message is at least + two bytes long. The receiver should ignore messages that are too short. + +``<op>[,<mode>] tx-short-bit <bit>`` + Make this bit period shorter than allowed. The bit position cannot be + an Ack bit. If <op> specifies a specific CEC opcode then the bit position + must be at least 18, otherwise the opcode hasn't been received yet. + Normally the period of a data bit is between 2.05 and 2.75 milliseconds. + With this command the period of this bit is 1.8 milliseconds, this is + done by reducing the time the CEC bus is high. This bit period is less + than is allowed and the receiver should respond with a Low Drive + condition. + + This command is ignored for 0 bits in bit positions 0 to 3. This is + because the receiver also looks for an Arbitration Lost condition in + those first four bits and it is undefined what will happen if it + sees a too-short 0 bit. + +``<op>[,<mode>] tx-long-bit <bit>`` + Make this bit period longer than is valid. The bit position cannot be + an Ack bit. If <op> specifies a specific CEC opcode then the bit position + must be at least 18, otherwise the opcode hasn't been received yet. + Normally the period of a data bit is between 2.05 and 2.75 milliseconds. + With this command the period of this bit is 2.9 milliseconds, this is + done by increasing the time the CEC bus is high. + + Even though this bit period is longer than is valid it is undefined what + a receiver will do. It might just accept it, or it might time out and + return to Idle state. Unfortunately the CEC specification is silent about + this. + + This command is ignored for 0 bits in bit positions 0 to 3. This is + because the receiver also looks for an Arbitration Lost condition in + those first four bits and it is undefined what will happen if it + sees a too-long 0 bit. + +``<op>[,<mode>] tx-short-start`` + Make this start bit period shorter than allowed. Normally the period of + a start bit is between 4.3 and 4.7 milliseconds. With this command the + period of the start bit is 4.1 milliseconds, this is done by reducing + the time the CEC bus is high. This start bit period is less than is + allowed and the receiver should return to Idle state when this is detected. + +``<op>[,<mode>] tx-long-start`` + Make this start bit period longer than is valid. Normally the period of + a start bit is between 4.3 and 4.7 milliseconds. With this command the + period of the start bit is 5 milliseconds, this is done by increasing + the time the CEC bus is high. This start bit period is more than is + valid and the receiver should return to Idle state when this is detected. + + Even though this start bit period is longer than is valid it is undefined + what a receiver will do. It might just accept it, or it might time out and + return to Idle state. Unfortunately the CEC specification is silent about + this. + +``<op>[,<mode>] tx-last-bit <bit>`` + Just stop transmitting after this bit. If <op> specifies a specific CEC + opcode then the bit position must be at least 18, otherwise the opcode + hasn't been received yet. This command can be used to test how the receiver + reacts when a message just suddenly stops. It should time out and go back + to Idle state. + +``<op>[,<mode>] tx-low-drive <bit>`` + Force a Low Drive condition at this bit position. If <op> specifies a + specific CEC opcode then the bit position must be at least 18, otherwise + the opcode hasn't been received yet. This can be used to test how the + receiver handles Low Drive conditions. Note that if this happens at bit + positions 0-3 the receiver can interpret this as an Arbitration Lost + condition. This is implementation dependent. + +Custom Pulses +------------- + +``tx-custom-low-usecs <usecs>`` + This defines the duration in microseconds that the custom pulse pulls + the CEC line low. The default is 1000 microseconds. + +``tx-custom-high-usecs <usecs>`` + This defines the duration in microseconds that the custom pulse keeps the + CEC line high (unless another CEC adapter pulls it low in that time). + The default is 1000 microseconds. The total period of the custom pulse is + ``tx-custom-low-usecs + tx-custom-high-usecs``. + +``<op>[,<mode>] tx-custom-bit <bit>`` + Send the custom bit instead of a regular data bit. The bit position cannot + be an Ack bit. If <op> specifies a specific CEC opcode then the bit + position must be at least 18, otherwise the opcode hasn't been received yet. + +``<op>[,<mode>] tx-custom-start`` + Send the custom bit instead of a regular start bit. + +``tx-custom-pulse`` + Transmit a single custom pulse as soon as the CEC bus is idle. diff --git a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst index b59ce14..45e76e5 100644 --- a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst +++ b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst @@ -144,10 +144,21 @@ id's until they get an error. - .. row 9 - - union + - __u32 + + - ``reserved[4]`` + + - + - + - Reserved for future extensions. Drivers and applications must set + the array to zero. - .. row 10 + - union + + - .. row 11 + - - struct @@ -156,7 +167,7 @@ id's until they get an error. - - Valid for (sub-)devices that create a single device node. - - .. row 11 + - .. row 12 - - @@ -166,7 +177,7 @@ id's until they get an error. - Device node major number. - - .. row 12 + - .. row 13 - - @@ -176,7 +187,7 @@ id's until they get an error. - Device node minor number. - - .. row 13 + - .. row 14 - - __u8 diff --git a/Documentation/media/uapi/mediactl/media-ioc-enum-links.rst b/Documentation/media/uapi/mediactl/media-ioc-enum-links.rst index d05be16..256168b 100644 --- a/Documentation/media/uapi/mediactl/media-ioc-enum-links.rst +++ b/Documentation/media/uapi/mediactl/media-ioc-enum-links.rst @@ -125,6 +125,15 @@ returned during the enumeration process. - Pad flags, see :ref:`media-pad-flag` for more details. + - .. row 4 + + - __u32 + + - ``reserved[2]`` + + - Reserved for future extensions. Drivers and applications must set + the array to zero. + .. c:type:: media_link_desc @@ -161,6 +170,15 @@ returned during the enumeration process. - Link flags, see :ref:`media-link-flag` for more details. + - .. row 4 + + - __u32 + + - ``reserved[4]`` + + - Reserved for future extensions. Drivers and applications must set + the array to zero. + Return Value ============ diff --git a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst index 997e6b1..c8f9ea3 100644 --- a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst +++ b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst @@ -68,7 +68,7 @@ desired arrays with the media graph elements. - .. row 2 - - __u64 + - __u32 - ``num_entities`` @@ -76,6 +76,14 @@ desired arrays with the media graph elements. - .. row 3 + - __u32 + + - ``reserved1`` + + - Applications and drivers shall set this to 0. + + - .. row 4 + - __u64 - ``ptr_entities`` @@ -85,15 +93,23 @@ desired arrays with the media graph elements. the ioctl won't store the entities. It will just update ``num_entities`` - - .. row 4 + - .. row 5 - - __u64 + - __u32 - ``num_interfaces`` - Number of interfaces in the graph - - .. row 5 + - .. row 6 + + - __u32 + + - ``reserved2`` + + - Applications and drivers shall set this to 0. + + - .. row 7 - __u64 @@ -104,15 +120,23 @@ desired arrays with the media graph elements. the ioctl won't store the interfaces. It will just update ``num_interfaces`` - - .. row 6 + - .. row 8 - - __u64 + - __u32 - ``num_pads`` - Total number of pads in the graph - - .. row 7 + - .. row 9 + + - __u32 + + - ``reserved3`` + + - Applications and drivers shall set this to 0. + + - .. row 10 - __u64 @@ -122,15 +146,23 @@ desired arrays with the media graph elements. converted to a 64-bits integer. It can be zero. if zero, the ioctl won't store the pads. It will just update ``num_pads`` - - .. row 8 + - .. row 11 - - __u64 + - __u32 - ``num_links`` - Total number of data and interface links in the graph - - .. row 9 + - .. row 12 + + - __u32 + + - ``reserved4`` + + - Applications and drivers shall set this to 0. + + - .. row 13 - __u64 @@ -334,7 +366,7 @@ desired arrays with the media graph elements. - On pad to pad links: unique ID for the source pad. - On interface to entity links: unique ID for the entity. + On interface to entity links: unique ID for the interface. - .. row 3 diff --git a/Documentation/media/uapi/mediactl/media-types.rst b/Documentation/media/uapi/mediactl/media-types.rst index 8d64b0c..f92f10b 100644 --- a/Documentation/media/uapi/mediactl/media-types.rst +++ b/Documentation/media/uapi/mediactl/media-types.rst @@ -26,7 +26,7 @@ Types and flags used to represent the media graph elements ``MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN`` - Unknown entity. That generally indicates that a driver didn't - initialize properly the entity, with is a Kernel bug + initialize properly the entity, which is a Kernel bug - .. row 2 @@ -293,7 +293,7 @@ Types and flags used to represent the media graph elements - ``MEDIA_ENT_F_PROC_VIDEO_STATISTICS`` - - Video statistics computation (histogram, 3A, ...). An entity + - Video statistics computation (histogram, 3A, etc.). An entity capable of statistics computation must have one sink pad and one source pad. It computes statistics over the frames received on its sink pad and outputs the statistics data on @@ -318,8 +318,19 @@ Types and flags used to represent the media graph elements - Video interface bridge. A video interface bridge entity must have at least one sink pad and at least one source pad. It receives video frames on its sink pad from an input video bus of one type (HDMI, eDP, - MIPI CSI-2, ...), and outputs them on its source pad to an output - video bus of another type (eDP, MIPI CSI-2, parallel, ...). + MIPI CSI-2, etc.), and outputs them on its source pad to an output + video bus of another type (eDP, MIPI CSI-2, parallel, etc.). + + - .. row 31 + + .. _MEDIA-ENT-F-DTV-DECODER: + + - ``MEDIA_ENT_F_DTV_DECODER`` + + - Digital video decoder. The basic function of the video decoder is + to accept digital video from a wide variety of sources + and output it in some digital video standard, with appropriate + timing signals. .. tabularcolumns:: |p{5.5cm}|p{12.0cm}| @@ -337,7 +348,7 @@ Types and flags used to represent the media graph elements - ``MEDIA_ENT_FL_DEFAULT`` - Default entity for its type. Used to discover the default audio, - VBI and video devices, the default camera sensor, ... + VBI and video devices, the default camera sensor, etc. - .. row 2 @@ -345,7 +356,7 @@ Types and flags used to represent the media graph elements - ``MEDIA_ENT_FL_CONNECTOR`` - - The entity represents a data conector + - The entity represents a connector. .. tabularcolumns:: |p{6.5cm}|p{6.0cm}|p{5.0cm}| diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst b/Documentation/media/uapi/rc/lirc-dev-intro.rst index 3a74fec..698e4f8 100644 --- a/Documentation/media/uapi/rc/lirc-dev-intro.rst +++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst @@ -18,7 +18,6 @@ Example dmesg output upon a driver registering w/LIRC: .. code-block:: none $ dmesg |grep lirc_dev - lirc_dev: IR Remote Control driver registered, major 248 rc rc0: lirc_dev: driver mceusb registered at minor = 0 What you should see for a chardev: diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index ae6ee73..e2c85dd 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -13,7 +13,7 @@ Only pointers to buffers (planes) are exchanged, the data itself is not copied. These pointers, together with meta-information like timestamps or field parity, are stored in a struct :c:type:`v4l2_buffer`, argument to the :ref:`VIDIOC_QUERYBUF`, -:ref:`VIDIOC_QBUF` and +:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. In the multi-planar API, some plane-specific members of struct :c:type:`v4l2_buffer`, such as pointers and sizes for each plane, are stored in struct diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index dfe49ae..d5f3eb6 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -1960,6 +1960,416 @@ enum v4l2_vp8_golden_frame_sel - 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3. +High Efficiency Video Coding (HEVC/H.265) Control Reference +----------------------------------------------------------- + +The HEVC/H.265 controls include controls for encoding parameters of HEVC/H.265 +video codec. + + +.. _hevc-control-id: + +HEVC/H.265 Control IDs +^^^^^^^^^^^^^^^^^^^^^^ + +``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)`` + Minimum quantization parameter for HEVC. + Valid range: from 0 to 51. + +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)`` + Maximum quantization parameter for HEVC. + Valid range: from 0 to 51. + +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)`` + Quantization parameter for an I frame for HEVC. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (integer)`` + Quantization parameter for a P frame for HEVC. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (integer)`` + Quantization parameter for a B frame for HEVC. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)`` + HIERARCHICAL_QP allows the host to specify the quantization parameter + values for each temporal layer through HIERARCHICAL_QP_LAYER. This is + valid only if HIERARCHICAL_CODING_LAYER is greater than 1. Setting the + control value to 1 enables setting of the QP values for the layers. + +.. _v4l2-hevc-hier-coding-type: + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE`` + (enum) + +enum v4l2_mpeg_video_hevc_hier_coding_type - + Selects the hierarchical coding type for encoding. Possible values are: + +.. raw:: latex + + \footnotesize + +.. tabularcolumns:: |p{9.0cm}|p{8.0cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B`` + - Use the B frame for hierarchical coding. + * - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P`` + - Use the P frame for hierarchical coding. + +.. raw:: latex + + \normalsize + + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)`` + Selects the hierarchical coding layer. In normal encoding + (non-hierarchial coding), it should be zero. Possible values are [0, 6]. + 0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL CODING + LAYER 1 and so on. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP (integer)`` + Indicates quantization parameter for hierarchical coding layer 0. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP (integer)`` + Indicates quantization parameter for hierarchical coding layer 1. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP (integer)`` + Indicates quantization parameter for hierarchical coding layer 2. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP (integer)`` + Indicates quantization parameter for hierarchical coding layer 3. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_QP (integer)`` + Indicates quantization parameter for hierarchical coding layer 4. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_QP (integer)`` + Indicates quantization parameter for hierarchical coding layer 5. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP (integer)`` + Indicates quantization parameter for hierarchical coding layer 6. + Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, + V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. + +.. _v4l2-hevc-profile: + +``V4L2_CID_MPEG_VIDEO_HEVC_PROFILE`` + (enum) + +enum v4l2_mpeg_video_hevc_profile - + Select the desired profile for HEVC encoder. + +.. raw:: latex + + \footnotesize + +.. tabularcolumns:: |p{9.0cm}|p{8.0cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN`` + - Main profile. + * - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE`` + - Main still picture profile. + * - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10`` + - Main 10 profile. + +.. raw:: latex + + \normalsize + + +.. _v4l2-hevc-level: + +``V4L2_CID_MPEG_VIDEO_HEVC_LEVEL`` + (enum) + +enum v4l2_mpeg_video_hevc_level - + Selects the desired level for HEVC encoder. + +.. raw:: latex + + \footnotesize + +.. tabularcolumns:: |p{9.0cm}|p{8.0cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_1`` + - Level 1.0 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_2`` + - Level 2.0 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_2_1`` + - Level 2.1 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_3`` + - Level 3.0 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_3_1`` + - Level 3.1 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_4`` + - Level 4.0 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_4_1`` + - Level 4.1 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_5`` + - Level 5.0 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1`` + - Level 5.1 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_5_2`` + - Level 5.2 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_6`` + - Level 6.0 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_6_1`` + - Level 6.1 + * - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_6_2`` + - Level 6.2 + +.. raw:: latex + + \normalsize + + +``V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION (integer)`` + Indicates the number of evenly spaced subintervals, called ticks, within + one second. This is a 16 bit unsigned integer and has a maximum value up to + 0xffff and a minimum value of 1. + +.. _v4l2-hevc-tier: + +``V4L2_CID_MPEG_VIDEO_HEVC_TIER`` + (enum) + +enum v4l2_mpeg_video_hevc_tier - + TIER_FLAG specifies tiers information of the HEVC encoded picture. Tier + were made to deal with applications that differ in terms of maximum bit + rate. Setting the flag to 0 selects HEVC tier as Main tier and setting + this flag to 1 indicates High tier. High tier is for applications requiring + high bit rates. + +.. raw:: latex + + \footnotesize + +.. tabularcolumns:: |p{9.0cm}|p{8.0cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_MPEG_VIDEO_HEVC_TIER_MAIN`` + - Main tier. + * - ``V4L2_MPEG_VIDEO_HEVC_TIER_HIGH`` + - High tier. + +.. raw:: latex + + \normalsize + + +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH (integer)`` + Selects HEVC maximum coding unit depth. + +.. _v4l2-hevc-loop-filter-mode: + +``V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE`` + (enum) + +enum v4l2_mpeg_video_hevc_loop_filter_mode - + Loop filter mode for HEVC encoder. Possible values are: + +.. raw:: latex + + \footnotesize + +.. tabularcolumns:: |p{10.7cm}|p{6.3cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE_DISABLED`` + - Loop filter is disabled. + * - ``V4L2_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE_ENABLED`` + - Loop filter is enabled. + * - ``V4L2_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE_DISABLED_AT_SLICE_BOUNDARY`` + - Loop filter is disabled at the slice boundary. + +.. raw:: latex + + \normalsize + + +``V4L2_CID_MPEG_VIDEO_HEVC_LF_BETA_OFFSET_DIV2 (integer)`` + Selects HEVC loop filter beta offset. The valid range is [-6, +6]. + +``V4L2_CID_MPEG_VIDEO_HEVC_LF_TC_OFFSET_DIV2 (integer)`` + Selects HEVC loop filter tc offset. The valid range is [-6, +6]. + +.. _v4l2-hevc-refresh-type: + +``V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE`` + (enum) + +enum v4l2_mpeg_video_hevc_hier_refresh_type - + Selects refresh type for HEVC encoder. + Host has to specify the period into + V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_PERIOD. + +.. raw:: latex + + \footnotesize + +.. tabularcolumns:: |p{8.0cm}|p{9.0cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_MPEG_VIDEO_HEVC_REFRESH_NONE`` + - Use the B frame for hierarchical coding. + * - ``V4L2_MPEG_VIDEO_HEVC_REFRESH_CRA`` + - Use CRA (Clean Random Access Unit) picture encoding. + * - ``V4L2_MPEG_VIDEO_HEVC_REFRESH_IDR`` + - Use IDR (Instantaneous Decoding Refresh) picture encoding. + +.. raw:: latex + + \normalsize + + +``V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_PERIOD (integer)`` + Selects the refresh period for HEVC encoder. + This specifies the number of I pictures between two CRA/IDR pictures. + This is valid only if REFRESH_TYPE is not 0. + +``V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU (boolean)`` + Indicates HEVC lossless encoding. Setting it to 0 disables lossless + encoding. Setting it to 1 enables lossless encoding. + +``V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED (boolean)`` + Indicates constant intra prediction for HEVC encoder. Specifies the + constrained intra prediction in which intra largest coding unit (LCU) + prediction is performed by using residual data and decoded samples of + neighboring intra LCU only. Setting the value to 1 enables constant intra + prediction and setting the value to 0 disables constant intra prediction. + +``V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT (boolean)`` + Indicates wavefront parallel processing for HEVC encoder. Setting it to 0 + disables the feature and setting it to 1 enables the wavefront parallel + processing. + +``V4L2_CID_MPEG_VIDEO_HEVC_GENERAL_PB (boolean)`` + Setting the value to 1 enables combination of P and B frame for HEVC + encoder. + +``V4L2_CID_MPEG_VIDEO_HEVC_TEMPORAL_ID (boolean)`` + Indicates temporal identifier for HEVC encoder which is enabled by + setting the value to 1. + +``V4L2_CID_MPEG_VIDEO_HEVC_STRONG_SMOOTHING (boolean)`` + Indicates bi-linear interpolation is conditionally used in the intra + prediction filtering process in the CVS when set to 1. Indicates bi-linear + interpolation is not used in the CVS when set to 0. + +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_NUM_MERGE_MV_MINUS1 (integer)`` + Indicates maximum number of merge candidate motion vectors. + Values are from 0 to 4. + +``V4L2_CID_MPEG_VIDEO_HEVC_TMV_PREDICTION (boolean)`` + Indicates temporal motion vector prediction for HEVC encoder. Setting it to + 1 enables the prediction. Setting it to 0 disables the prediction. + +``V4L2_CID_MPEG_VIDEO_HEVC_WITHOUT_STARTCODE (boolean)`` + Specifies if HEVC generates a stream with a size of the length field + instead of start code pattern. The size of the length field is configurable + through the V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD control. Setting + the value to 0 disables encoding without startcode pattern. Setting the + value to 1 will enables encoding without startcode pattern. + +.. _v4l2-hevc-size-of-length-field: + +``V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD`` +(enum) + +enum v4l2_mpeg_video_hevc_size_of_length_field - + Indicates the size of length field. + This is valid when encoding WITHOUT_STARTCODE_ENABLE is enabled. + +.. raw:: latex + + \footnotesize + +.. tabularcolumns:: |p{6.0cm}|p{11.0cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_MPEG_VIDEO_HEVC_SIZE_0`` + - Generate start code pattern (Normal). + * - ``V4L2_MPEG_VIDEO_HEVC_SIZE_1`` + - Generate size of length field instead of start code pattern and length is 1. + * - ``V4L2_MPEG_VIDEO_HEVC_SIZE_2`` + - Generate size of length field instead of start code pattern and length is 2. + * - ``V4L2_MPEG_VIDEO_HEVC_SIZE_4`` + - Generate size of length field instead of start code pattern and length is 4. + +.. raw:: latex + + \normalsize + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_BR (integer)`` + Indicates bit rate for hierarchical coding layer 0 for HEVC encoder. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_BR (integer)`` + Indicates bit rate for hierarchical coding layer 1 for HEVC encoder. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_BR (integer)`` + Indicates bit rate for hierarchical coding layer 2 for HEVC encoder. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_BR (integer)`` + Indicates bit rate for hierarchical coding layer 3 for HEVC encoder. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_BR (integer)`` + Indicates bit rate for hierarchical coding layer 4 for HEVC encoder. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_BR (integer)`` + Indicates bit rate for hierarchical coding layer 5 for HEVC encoder. + +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR (integer)`` + Indicates bit rate for hierarchical coding layer 6 for HEVC encoder. + +``V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES (integer)`` + Selects number of P reference pictures required for HEVC encoder. + P-Frame can use 1 or 2 frames for reference. + +``V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR (integer)`` + Indicates whether to generate SPS and PPS at every IDR. Setting it to 0 + disables generating SPS and PPS at every IDR. Setting it to one enables + generating SPS and PPS at every IDR. + + .. _camera-controls: Camera Control Reference diff --git a/Documentation/media/uapi/v4l/func-poll.rst b/Documentation/media/uapi/v4l/func-poll.rst index d0432dc..360bc65 100644 --- a/Documentation/media/uapi/v4l/func-poll.rst +++ b/Documentation/media/uapi/v4l/func-poll.rst @@ -39,7 +39,7 @@ When streaming I/O has been negotiated this function waits until a buffer has been filled by the capture device and can be dequeued with the :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. For output devices this function waits until the device is ready to accept a new buffer to be -queued up with the :ref:`VIDIOC_QBUF` ioctl for +queued up with the :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl for display. When buffers are already in the outgoing queue of the driver (capture) or the incoming queue isn't full (display) the function returns immediately. @@ -52,11 +52,11 @@ flags in the ``revents`` field, output devices the ``POLLOUT`` and ``POLLWRNORM`` flags. When the function timed out it returns a value of zero, on failure it returns -1 and the ``errno`` variable is set appropriately. When the application did not call -:ref:`VIDIOC_STREAMON` the :ref:`poll() <func-poll>` +:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` the :ref:`poll() <func-poll>` function succeeds, but sets the ``POLLERR`` flag in the ``revents`` field. When the application has called -:ref:`VIDIOC_STREAMON` for a capture device but -hasn't yet called :ref:`VIDIOC_QBUF`, the +:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` for a capture device but +hasn't yet called :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`, the :ref:`poll() <func-poll>` function succeeds and sets the ``POLLERR`` flag in the ``revents`` field. For output devices this same situation will cause :ref:`poll() <func-poll>` to succeed as well, but it sets the ``POLLOUT`` and diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst b/Documentation/media/uapi/v4l/pixfmt-compressed.rst index 728d7ed..abec039 100644 --- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst +++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst @@ -90,3 +90,8 @@ Compressed Formats - ``V4L2_PIX_FMT_VP9`` - 'VP90' - VP9 video elementary stream. + * .. _V4L2-PIX-FMT-HEVC: + + - ``V4L2_PIX_FMT_HEVC`` + - 'HEVC' + - HEVC/H.265 video elementary stream. diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst index 2ee164c..6622938 100644 --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst @@ -40,7 +40,7 @@ Single-planar format structure RGB formats in :ref:`rgb-formats`, YUV formats in :ref:`yuv-formats`, and reserved codes in :ref:`reserved-formats` - * - enum :c:type::`v4l2_field` + * - enum :c:type:`v4l2_field` - ``field`` - Video images are typically interlaced. Applications can request to capture or output only the top or bottom field, or both fields diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst b/Documentation/media/uapi/v4l/subdev-formats.rst index b1eea44..9fcabe7 100644 --- a/Documentation/media/uapi/v4l/subdev-formats.rst +++ b/Documentation/media/uapi/v4l/subdev-formats.rst @@ -16,10 +16,14 @@ Media Bus Formats * - __u32 - ``width`` - - Image width, in pixels. + - Image width in pixels. * - __u32 - ``height`` - - Image height, in pixels. + - Image height in pixels. If ``field`` is one of ``V4L2_FIELD_TOP``, + ``V4L2_FIELD_BOTTOM`` or ``V4L2_FIELD_ALTERNATE`` then height + refers to the number of lines in the field, otherwise it refers to + the number of lines in the frame (which is twice the field height + for interlaced formats). * - __u32 - ``code`` - Format code, from enum diff --git a/Documentation/media/uapi/v4l/vidioc-g-parm.rst b/Documentation/media/uapi/v4l/vidioc-g-parm.rst index 616a5ea..e831fa5 100644 --- a/Documentation/media/uapi/v4l/vidioc-g-parm.rst +++ b/Documentation/media/uapi/v4l/vidioc-g-parm.rst @@ -66,7 +66,7 @@ union holding separate parameters for input and output devices. - - The buffer (stream) type, same as struct :c:type:`v4l2_format` ``type``, set by the - application. See :c:type:`v4l2_buf_type` + application. See :c:type:`v4l2_buf_type`. * - union - ``parm`` - @@ -75,12 +75,13 @@ union holding separate parameters for input and output devices. - struct :c:type:`v4l2_captureparm` - ``capture`` - Parameters for capture devices, used when ``type`` is - ``V4L2_BUF_TYPE_VIDEO_CAPTURE``. + ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` or + ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``. * - - struct :c:type:`v4l2_outputparm` - ``output`` - Parameters for output devices, used when ``type`` is - ``V4L2_BUF_TYPE_VIDEO_OUTPUT``. + ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` or ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``. * - - __u8 - ``raw_data``\ [200] diff --git a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst index 70687a8..49f9f4c 100644 --- a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst +++ b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst @@ -34,7 +34,7 @@ Description Applications can optionally call the :ref:`VIDIOC_PREPARE_BUF` ioctl to pass ownership of the buffer to the driver before actually enqueuing it, -using the :ref:`VIDIOC_QBUF` ioctl, and to prepare it for future I/O. Such +using the :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl, and to prepare it for future I/O. Such preparations may include cache invalidation or cleaning. Performing them in advance saves time during the actual I/O. In case such cache operations are not required, the application can use one of diff --git a/Documentation/media/v4l-drivers/imx.rst b/Documentation/media/v4l-drivers/imx.rst index 3c4f58b..65d3d15 100644 --- a/Documentation/media/v4l-drivers/imx.rst +++ b/Documentation/media/v4l-drivers/imx.rst @@ -109,7 +109,7 @@ imx6-mipi-csi2 This is the MIPI CSI-2 receiver entity. It has one sink pad to receive the MIPI CSI-2 stream (usually from a MIPI CSI-2 camera sensor). It has four source pads, corresponding to the four MIPI CSI-2 demuxed virtual -channel outputs. Multpiple source pads can be enabled to independently +channel outputs. Multiple source pads can be enabled to independently stream from multiple virtual channels. This entity actually consists of two sub-blocks. One is the MIPI CSI-2 @@ -213,9 +213,11 @@ To give an example of crop and /2 downscale, this will crop a 1280x960 input frame to 640x480, and then /2 downscale in both dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux): -media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]" -media-ctl -V "'ipu1_csi0':0[crop:(0,0)/640x480]" -media-ctl -V "'ipu1_csi0':0[compose:(0,0)/320x240]" +.. code-block:: none + + media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]" + media-ctl -V "'ipu1_csi0':0[crop:(0,0)/640x480]" + media-ctl -V "'ipu1_csi0':0[compose:(0,0)/320x240]" Frame Skipping in ipuX_csiY --------------------------- @@ -229,8 +231,10 @@ at the source pad. The following example reduces an assumed incoming 60 Hz frame rate by half at the IDMAC output source pad: -media-ctl -V "'ipu1_csi0':0[fmt:UYVY2X8/640x480@1/60]" -media-ctl -V "'ipu1_csi0':2[fmt:UYVY2X8/640x480@1/30]" +.. code-block:: none + + media-ctl -V "'ipu1_csi0':0[fmt:UYVY2X8/640x480@1/60]" + media-ctl -V "'ipu1_csi0':2[fmt:UYVY2X8/640x480@1/30]" Frame Interval Monitor in ipuX_csiY ----------------------------------- @@ -422,8 +426,7 @@ This pipeline uses the preprocess encode entity to route frames directly from the CSI to the IC, to carry out scaling up to 1024x1024 resolution, CSC, flipping, and image rotation: --> ipuX_csiY:1 -> 0:ipuX_ic_prp:1 -> 0:ipuX_ic_prpenc:1 -> - ipuX_ic_prpenc capture +-> ipuX_csiY:1 -> 0:ipuX_ic_prp:1 -> 0:ipuX_ic_prpenc:1 -> ipuX_ic_prpenc capture Motion Compensated De-interlace: -------------------------------- @@ -432,8 +435,7 @@ This pipeline routes frames from the CSI direct pad to the VDIC entity to support motion-compensated de-interlacing (high motion mode only), scaling up to 1024x1024, CSC, flip, and rotation: --> ipuX_csiY:1 -> 0:ipuX_vdic:2 -> 0:ipuX_ic_prp:2 -> - 0:ipuX_ic_prpvf:1 -> ipuX_ic_prpvf capture +-> ipuX_csiY:1 -> 0:ipuX_vdic:2 -> 0:ipuX_ic_prp:2 -> 0:ipuX_ic_prpvf:1 -> ipuX_ic_prpvf capture Usage Notes @@ -458,8 +460,8 @@ This platform requires the OmniVision OV5642 module with a parallel camera interface, and the OV5640 module with a MIPI CSI-2 interface. Both modules are available from Boundary Devices: -https://boundarydevices.com/product/nit6x_5mp -https://boundarydevices.com/product/nit6x_5mp_mipi +- https://boundarydevices.com/product/nit6x_5mp +- https://boundarydevices.com/product/nit6x_5mp_mipi Note that if only one camera module is available, the other sensor node can be disabled in the device tree. diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index a863009..6dafc80 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -14,7 +14,11 @@ DISCLAIMER This document is not a specification; it is intentionally (for the sake of brevity) and unintentionally (due to being human) incomplete. This document is meant as a guide to using the various memory barriers provided by Linux, but -in case of any doubt (and there are many) please ask. +in case of any doubt (and there are many) please ask. Some doubts may be +resolved by referring to the formal memory consistency model and related +documentation at tools/memory-model/. Nevertheless, even this memory +model should be viewed as the collective opinion of its maintainers rather +than as an infallible oracle. To repeat, this document is not a specification of what Linux expects from hardware. @@ -48,7 +52,7 @@ CONTENTS - Varieties of memory barrier. - What may not be assumed about memory barriers? - - Data dependency barriers. + - Data dependency barriers (historical). - Control dependencies. - SMP barrier pairing. - Examples of memory barrier sequences. @@ -399,7 +403,7 @@ Memory barriers come in four basic varieties: where two loads are performed such that the second depends on the result of the first (eg: the first load retrieves the address to which the second load will be directed), a data dependency barrier would be required to - make sure that the target of the second load is updated before the address + make sure that the target of the second load is updated after the address obtained by the first load is accessed. A data dependency barrier is a partial ordering on interdependent loads @@ -550,8 +554,15 @@ There are certain things that the Linux kernel memory barriers do not guarantee: Documentation/DMA-API.txt -DATA DEPENDENCY BARRIERS ------------------------- +DATA DEPENDENCY BARRIERS (HISTORICAL) +------------------------------------- + +As of v4.15 of the Linux kernel, an smp_read_barrier_depends() was +added to READ_ONCE(), which means that about the only people who +need to pay attention to this section are those working on DEC Alpha +architecture-specific code and those working on READ_ONCE() itself. +For those who need it, and for those who are interested in the history, +here is the story of data-dependency barriers. The usage requirements of data dependency barriers are a little subtle, and it's not always obvious that they're needed. To illustrate, consider the @@ -2839,8 +2850,9 @@ as that committed on CPU 1. To intervene, we need to interpolate a data dependency barrier or a read -barrier between the loads. This will force the cache to commit its coherency -queue before processing any further requests: +barrier between the loads (which as of v4.15 is supplied unconditionally +by the READ_ONCE() macro). This will force the cache to commit its +coherency queue before processing any further requests: CPU 1 CPU 2 COMMENT =============== =============== ======================================= @@ -2869,8 +2881,8 @@ Other CPUs may also have split caches, but must coordinate between the various cachelets for normal memory accesses. The semantics of the Alpha removes the need for hardware coordination in the absence of memory barriers, which permitted Alpha to sport higher CPU clock rates back in the day. However, -please note that smp_read_barrier_depends() should not be used except in -Alpha arch-specific code and within the READ_ONCE() macro. +please note that (again, as of v4.15) smp_read_barrier_depends() should not +be used except in Alpha arch-specific code and within the READ_ONCE() macro. CACHE COHERENCY VS DMA @@ -3035,7 +3047,9 @@ the data dependency barrier really becomes necessary as this synchronises both caches with the memory coherence system, thus making it seem like pointer changes vs new data occur in the right order. -The Alpha defines the Linux kernel's memory barrier model. +The Alpha defines the Linux kernel's memory model, although as of v4.15 +the Linux kernel's addition of smp_read_barrier_depends() to READ_ONCE() +greatly reduced Alpha's impact on the memory model. See the subsection on "Cache Coherency" above. diff --git a/Documentation/metag/00-INDEX b/Documentation/metag/00-INDEX deleted file mode 100644 index db11c51..0000000 --- a/Documentation/metag/00-INDEX +++ /dev/null @@ -1,4 +0,0 @@ -00-INDEX - - this file -kernel-ABI.txt - - Documents metag ABI details diff --git a/Documentation/metag/kernel-ABI.txt b/Documentation/metag/kernel-ABI.txt deleted file mode 100644 index 6282166..0000000 --- a/Documentation/metag/kernel-ABI.txt +++ /dev/null @@ -1,256 +0,0 @@ - ========================== - KERNEL ABIS FOR METAG ARCH - ========================== - -This document describes the Linux ABIs for the metag architecture, and has the -following sections: - - (*) Outline of registers - (*) Userland registers - (*) Kernel registers - (*) System call ABI - (*) Calling conventions - - -==================== -OUTLINE OF REGISTERS -==================== - -The main Meta core registers are arranged in units: - - UNIT Type DESCRIPTION GP EXT PRIV GLOBAL - ======= ======= =============== ======= ======= ======= ======= - CT Special Control unit - D0 General Data unit 0 0-7 8-15 16-31 16-31 - D1 General Data unit 1 0-7 8-15 16-31 16-31 - A0 General Address unit 0 0-3 4-7 8-15 8-15 - A1 General Address unit 1 0-3 4-7 8-15 8-15 - PC Special PC unit 0 1 - PORT Special Ports - TR Special Trigger unit 0-7 - TT Special Trace unit 0-5 - FX General FP unit 0-15 - -GP registers form part of the main context. - -Extended context registers (EXT) may not be present on all hardware threads and -can be context switched if support is enabled and the appropriate bits are set -in e.g. the D0.8 register to indicate what extended state to preserve. - -Global registers are shared between threads and are privilege protected. - -See arch/metag/include/asm/metag_regs.h for definitions relating to core -registers and the fields and bits they contain. See the TRMs for further details -about special registers. - -Several special registers are preserved in the main context, these are the -interesting ones: - - REG (ALIAS) PURPOSE - ======================= =============================================== - CT.1 (TXMODE) Processor mode bits (particularly for DSP) - CT.2 (TXSTATUS) Condition flags and LSM_STEP (MGET/MSET step) - CT.3 (TXRPT) Branch repeat counter - PC.0 (PC) Program counter - -Some of the general registers have special purposes in the ABI and therefore -have aliases: - - D0 REG (ALIAS) PURPOSE D1 REG (ALIAS) PURPOSE - =============== =============== =============== ======================= - D0.0 (D0Re0) 32bit result D1.0 (D1Re0) Top half of 64bit result - D0.1 (D0Ar6) Argument 6 D1.1 (D1Ar5) Argument 5 - D0.2 (D0Ar4) Argument 4 D1.2 (D1Ar3) Argument 3 - D0.3 (D0Ar2) Argument 2 D1.3 (D1Ar1) Argument 1 - D0.4 (D0FrT) Frame temp D1.4 (D1RtP) Return pointer - D0.5 Call preserved D1.5 Call preserved - D0.6 Call preserved D1.6 Call preserved - D0.7 Call preserved D1.7 Call preserved - - A0 REG (ALIAS) PURPOSE A1 REG (ALIAS) PURPOSE - =============== =============== =============== ======================= - A0.0 (A0StP) Stack pointer A1.0 (A1GbP) Global base pointer - A0.1 (A0FrP) Frame pointer A1.1 (A1LbP) Local base pointer - A0.2 A1.2 - A0.3 A1.3 - - -================== -USERLAND REGISTERS -================== - -All the general purpose D0, D1, A0, A1 registers are preserved when entering the -kernel (including asynchronous events such as interrupts and timer ticks) except -the following which have special purposes in the ABI: - - REGISTERS WHEN STATUS PURPOSE - =============== ======= =============== =============================== - D0.8 DSP Preserved ECH, determines what extended - DSP state to preserve. - A0.0 (A0StP) ALWAYS Preserved Stack >= A0StP may be clobbered - at any time by the creation of a - signal frame. - A1.0 (A1GbP) SMP Clobbered Used as temporary for loading - kernel stack pointer and saving - core context. - A0.15 !SMP Protected Stores kernel stack pointer. - A1.15 ALWAYS Protected Stores kernel base pointer. - -On UP A0.15 is used to store the kernel stack pointer for storing the userland -context. A0.15 is global between hardware threads though which means it cannot -be used on SMP for this purpose. Since no protected local registers are -available A1GbP is reserved for use as a temporary to allow a percpu stack -pointer to be loaded for storing the rest of the context. - - -================ -KERNEL REGISTERS -================ - -When in the kernel the following registers have special purposes in the ABI: - - REGISTERS WHEN STATUS PURPOSE - =============== ======= =============== =============================== - A0.0 (A0StP) ALWAYS Preserved Stack >= A0StP may be clobbered - at any time by the creation of - an irq signal frame. - A1.0 (A1GbP) ALWAYS Preserved Reserved (kernel base pointer). - - -=============== -SYSTEM CALL ABI -=============== - -When a system call is made, the following registers are effective: - - REGISTERS CALL RETURN - =============== ======================= =============================== - D0.0 (D0Re0) Return value (or -errno) - D1.0 (D1Re0) System call number Clobbered - D0.1 (D0Ar6) Syscall arg #6 Preserved - D1.1 (D1Ar5) Syscall arg #5 Preserved - D0.2 (D0Ar4) Syscall arg #4 Preserved - D1.2 (D1Ar3) Syscall arg #3 Preserved - D0.3 (D0Ar2) Syscall arg #2 Preserved - D1.3 (D1Ar1) Syscall arg #1 Preserved - -Due to the limited number of argument registers and some system calls with badly -aligned 64-bit arguments, 64-bit values are always packed in consecutive -arguments, even if this is contrary to the normal calling conventions (where the -two halves would go in a matching pair of data registers). - -For example fadvise64_64 usually has the signature: - - long sys_fadvise64_64(i32 fd, i64 offs, i64 len, i32 advice); - -But for metag fadvise64_64 is wrapped so that the 64-bit arguments are packed: - - long sys_fadvise64_64_metag(i32 fd, i32 offs_lo, - i32 offs_hi, i32 len_lo, - i32 len_hi, i32 advice) - -So the arguments are packed in the registers like this: - - D0 REG (ALIAS) VALUE D1 REG (ALIAS) VALUE - =============== =============== =============== ======================= - D0.1 (D0Ar6) advice D1.1 (D1Ar5) hi(len) - D0.2 (D0Ar4) lo(len) D1.2 (D1Ar3) hi(offs) - D0.3 (D0Ar2) lo(offs) D1.3 (D1Ar1) fd - - -=================== -CALLING CONVENTIONS -=================== - -These calling conventions apply to both user and kernel code. The stack grows -from low addresses to high addresses in the metag ABI. The stack pointer (A0StP) -should always point to the next free address on the stack and should at all -times be 64-bit aligned. The following registers are effective at the point of a -call: - - REGISTERS CALL RETURN - =============== ======================= =============================== - D0.0 (D0Re0) 32bit return value - D1.0 (D1Re0) Upper half of 64bit return value - D0.1 (D0Ar6) 32bit argument #6 Clobbered - D1.1 (D1Ar5) 32bit argument #5 Clobbered - D0.2 (D0Ar4) 32bit argument #4 Clobbered - D1.2 (D1Ar3) 32bit argument #3 Clobbered - D0.3 (D0Ar2) 32bit argument #2 Clobbered - D1.3 (D1Ar1) 32bit argument #1 Clobbered - D0.4 (D0FrT) Clobbered - D1.4 (D1RtP) Return pointer Clobbered - D{0-1}.{5-7} Preserved - A0.0 (A0StP) Stack pointer Preserved - A1.0 (A0GbP) Preserved - A0.1 (A0FrP) Frame pointer Preserved - A1.1 (A0LbP) Preserved - A{0-1},{2-3} Clobbered - -64-bit arguments are placed in matching pairs of registers (i.e. the same -register number in both D0 and D1 units), with the least significant half in D0 -and the most significant half in D1, leaving a gap where necessary. Further -arguments are stored on the stack in reverse order (earlier arguments at higher -addresses): - - ADDRESS 0 1 2 3 4 5 6 7 - =============== ===== ===== ===== ===== ===== ===== ===== ===== - A0StP --> - A0StP-0x08 32bit argument #8 32bit argument #7 - A0StP-0x10 32bit argument #10 32bit argument #9 - -Function prologues tend to look a bit like this: - - /* If frame pointer in use, move it to frame temp register so it can be - easily pushed onto stack */ - MOV D0FrT,A0FrP - - /* If frame pointer in use, set it to stack pointer */ - ADD A0FrP,A0StP,#0 - - /* Preserve D0FrT, D1RtP, D{0-1}.{5-7} on stack, incrementing A0StP */ - MSETL [A0StP++],D0FrT,D0.5,D0.6,D0.7 - - /* Allocate some stack space for local variables */ - ADD A0StP,A0StP,#0x10 - -At this point the stack would look like this: - - ADDRESS 0 1 2 3 4 5 6 7 - =============== ===== ===== ===== ===== ===== ===== ===== ===== - A0StP --> - A0StP-0x08 - A0StP-0x10 - A0StP-0x18 Old D0.7 Old D1.7 - A0StP-0x20 Old D0.6 Old D1.6 - A0StP-0x28 Old D0.5 Old D1.5 - A0FrP --> Old A0FrP (frame ptr) Old D1RtP (return ptr) - A0FrP-0x08 32bit argument #8 32bit argument #7 - A0FrP-0x10 32bit argument #10 32bit argument #9 - -Function epilogues tend to differ depending on the use of a frame pointer. An -example of a frame pointer epilogue: - - /* Restore D0FrT, D1RtP, D{0-1}.{5-7} from stack, incrementing A0FrP */ - MGETL D0FrT,D0.5,D0.6,D0.7,[A0FrP++] - /* Restore stack pointer to where frame pointer was before increment */ - SUB A0StP,A0FrP,#0x20 - /* Restore frame pointer from frame temp */ - MOV A0FrP,D0FrT - /* Return to caller via restored return pointer */ - MOV PC,D1RtP - -If the function hasn't touched the frame pointer, MGETL cannot be safely used -with A0StP as it always increments and that would expose the stack to clobbering -by interrupts (kernel) or signals (user). Therefore it's common to see the MGETL -split into separate GETL instructions: - - /* Restore D0FrT, D1RtP, D{0-1}.{5-7} from stack */ - GETL D0FrT,D1RtP,[A0StP+#-0x30] - GETL D0.5,D1.5,[A0StP+#-0x28] - GETL D0.6,D1.6,[A0StP+#-0x20] - GETL D0.7,D1.7,[A0StP+#-0x18] - /* Restore stack pointer */ - SUB A0StP,A0StP,#0x30 - /* Return to caller via restored return pointer */ - MOV PC,D1RtP diff --git a/Documentation/mn10300/ABI.txt b/Documentation/mn10300/ABI.txt deleted file mode 100644 index d3507ba..0000000 --- a/Documentation/mn10300/ABI.txt +++ /dev/null @@ -1,149 +0,0 @@ - ========================= - MN10300 FUNCTION CALL ABI - ========================= - -======= -GENERAL -======= - -The MN10300/AM33 kernel runs in little-endian mode; big-endian mode is not -supported. - -The stack grows downwards, and should always be 32-bit aligned. There are -separate stack pointer registers for userspace and the kernel. - - -================ -ARGUMENT PASSING -================ - -The first two arguments (assuming up to 32-bits per argument) to a function are -passed in the D0 and D1 registers respectively; all other arguments are passed -on the stack. - -If 64-bit arguments are being passed, then they are never split between -registers and the stack. If the first argument is a 64-bit value, it will be -passed in D0:D1. If the first argument is not a 64-bit value, but the second -is, the second will be passed entirely on the stack and D1 will be unused. - -Arguments smaller than 32-bits are not coalesced within a register or a stack -word. For example, two byte-sized arguments will always be passed in separate -registers or word-sized stack slots. - - -================= -CALLING FUNCTIONS -================= - -The caller must allocate twelve bytes on the stack for the callee's use before -it inserts a CALL instruction. The CALL instruction will write into the TOS -word, but won't actually modify the stack pointer; similarly, the RET -instruction reads from the TOS word of the stack, but doesn't move the stack -pointer beyond it. - - - Stack: - | | - | | - |---------------| SP+20 - | 4th Arg | - |---------------| SP+16 - | 3rd Arg | - |---------------| SP+12 - | D1 Save Slot | - |---------------| SP+8 - | D0 Save Slot | - |---------------| SP+4 - | Return Addr | - |---------------| SP - | | - | | - - -The caller must leave space on the stack (hence an allocation of twelve bytes) -in which the callee may store the first two arguments. - - -============ -RETURN VALUE -============ - -The return value is passed in D0 for an integer (or D0:D1 for a 64-bit value), -or A0 for a pointer. - -If the return value is a value larger than 64-bits, or is a structure or an -array, then a hidden first argument will be passed to the callee by the caller: -this will point to a piece of memory large enough to hold the result of the -function. In this case, the callee will return the value in that piece of -memory, and no value will be returned in D0 or A0. - - -=================== -REGISTER CLOBBERING -=================== - -The values in certain registers may be clobbered by the callee, and other -values must be saved: - - Clobber: D0-D1, A0-A1, E0-E3 - Save: D2-D3, A2-A3, E4-E7, SP - -All other non-supervisor-only registers are clobberable (such as MDR, MCRL, -MCRH). - - -================= -SPECIAL REGISTERS -================= - -Certain ordinary registers may carry special usage for the compiler: - - A3: Frame pointer - E2: TLS pointer - - -========== -KERNEL ABI -========== - -The kernel may use a slightly different ABI internally. - - (*) E2 - - If CONFIG_MN10300_CURRENT_IN_E2 is defined, then the current task pointer - will be kept in the E2 register, and that register will be marked - unavailable for the compiler to use as a scratch register. - - Normally the kernel uses something like: - - MOV SP,An - AND 0xFFFFE000,An - MOV (An),Rm // Rm holds current - MOV (yyy,Rm) // Access current->yyy - - To find the address of current; but since this option permits current to - be carried globally in an register, it can use: - - MOV (yyy,E2) // Access current->yyy - - instead. - - -=============== -SYSTEM CALL ABI -=============== - -System calls are called with the following convention: - - REGISTER ENTRY EXIT - =============== ======================= ======================= - D0 Syscall number Return value - A0 1st syscall argument Saved - D1 2nd syscall argument Saved - A3 3rd syscall argument Saved - A2 4th syscall argument Saved - D3 5th syscall argument Saved - D2 6th syscall argument Saved - -All other registers are saved. The layout is a consequence of the way the MOVM -instruction stores registers onto the stack. diff --git a/Documentation/mn10300/compartmentalisation.txt b/Documentation/mn10300/compartmentalisation.txt deleted file mode 100644 index 8958b51..0000000 --- a/Documentation/mn10300/compartmentalisation.txt +++ /dev/null @@ -1,60 +0,0 @@ - ========================================= - PART-SPECIFIC SOURCE COMPARTMENTALISATION - ========================================= - -The sources for various parts are compartmentalised at two different levels: - - (1) Processor level - - The "processor level" is a CPU core plus the other on-silicon - peripherals. - - Processor-specific header files are divided among directories in a similar - way to the CPU level: - - (*) include/asm-mn10300/proc-mn103e010/ - - Support for the AM33v2 CPU core. - - The appropriate processor is selected by a CONFIG_MN10300_PROC_YYYY option - from the "Processor support" choice menu in the arch/mn10300/Kconfig file. - - - (2) Unit level - - The "unit level" is a processor plus all the external peripherals - controlled by that processor. - - Unit-specific header files are divided among directories in a similar way - to the CPU level; not only that, but specific sources may also be - segregated into separate directories under the arch directory: - - (*) include/asm-mn10300/unit-asb2303/ - (*) arch/mn10300/unit-asb2303/ - - Support for the ASB2303 board with an ASB2308 daughter board. - - (*) include/asm-mn10300/unit-asb2305/ - (*) arch/mn10300/unit-asb2305/ - - Support for the ASB2305 board. - - The appropriate processor is selected by a CONFIG_MN10300_UNIT_ZZZZ option - from the "Unit type" choice menu in the arch/mn10300/Kconfig file. - - -============ -COMPILE TIME -============ - -When the kernel is compiled, symbolic links will be made in the asm header file -directory for this arch: - - include/asm-mn10300/proc => include/asm-mn10300/proc-YYYY/ - include/asm-mn10300/unit => include/asm-mn10300/unit-ZZZZ/ - -So that the header files contained in those directories can be accessed without -lots of #ifdef-age. - -The appropriate arch/mn10300/unit-ZZZZ directory will also be entered by the -compilation process; all other unit-specific directories will be ignored. diff --git a/Documentation/networking/dpaa2/index.rst b/Documentation/networking/dpaa2/index.rst new file mode 100644 index 0000000..4c6586c --- /dev/null +++ b/Documentation/networking/dpaa2/index.rst @@ -0,0 +1,8 @@ +=================== +DPAA2 Documentation +=================== + +.. toctree:: + :maxdepth: 1 + + overview diff --git a/Documentation/networking/dpaa2/overview.rst b/Documentation/networking/dpaa2/overview.rst new file mode 100644 index 0000000..79fede4 --- /dev/null +++ b/Documentation/networking/dpaa2/overview.rst @@ -0,0 +1,404 @@ +.. include:: <isonum.txt> + +DPAA2 (Data Path Acceleration Architecture Gen2) Overview +========================================================= + +:Copyright: |copy| 2015 Freescale Semiconductor Inc. +:Copyright: |copy| 2018 NXP + +This document provides an overview of the Freescale DPAA2 architecture +and how it is integrated into the Linux kernel. + +Introduction +============ + +DPAA2 is a hardware architecture designed for high-speeed network +packet processing. DPAA2 consists of sophisticated mechanisms for +processing Ethernet packets, queue management, buffer management, +autonomous L2 switching, virtual Ethernet bridging, and accelerator +(e.g. crypto) sharing. + +A DPAA2 hardware component called the Management Complex (or MC) manages the +DPAA2 hardware resources. The MC provides an object-based abstraction for +software drivers to use the DPAA2 hardware. +The MC uses DPAA2 hardware resources such as queues, buffer pools, and +network ports to create functional objects/devices such as network +interfaces, an L2 switch, or accelerator instances. +The MC provides memory-mapped I/O command interfaces (MC portals) +which DPAA2 software drivers use to operate on DPAA2 objects. + +The diagram below shows an overview of the DPAA2 resource management +architecture:: + + +--------------------------------------+ + | OS | + | DPAA2 drivers | + | | | + +-----------------------------|--------+ + | + | (create,discover,connect + | config,use,destroy) + | + DPAA2 | + +------------------------| mc portal |-+ + | | | + | +- - - - - - - - - - - - -V- - -+ | + | | | | + | | Management Complex (MC) | | + | | | | + | +- - - - - - - - - - - - - - - -+ | + | | + | Hardware Hardware | + | Resources Objects | + | --------- ------- | + | -queues -DPRC | + | -buffer pools -DPMCP | + | -Eth MACs/ports -DPIO | + | -network interface -DPNI | + | profiles -DPMAC | + | -queue portals -DPBP | + | -MC portals ... | + | ... | + | | + +--------------------------------------+ + + +The MC mediates operations such as create, discover, +connect, configuration, and destroy. Fast-path operations +on data, such as packet transmit/receive, are not mediated by +the MC and are done directly using memory mapped regions in +DPIO objects. + +Overview of DPAA2 Objects +========================= + +The section provides a brief overview of some key DPAA2 objects. +A simple scenario is described illustrating the objects involved +in creating a network interfaces. + +DPRC (Datapath Resource Container) +---------------------------------- + +A DPRC is a container object that holds all the other +types of DPAA2 objects. In the example diagram below there +are 8 objects of 5 types (DPMCP, DPIO, DPBP, DPNI, and DPMAC) +in the container. + +:: + + +---------------------------------------------------------+ + | DPRC | + | | + | +-------+ +-------+ +-------+ +-------+ +-------+ | + | | DPMCP | | DPIO | | DPBP | | DPNI | | DPMAC | | + | +-------+ +-------+ +-------+ +---+---+ +---+---+ | + | | DPMCP | | DPIO | | + | +-------+ +-------+ | + | | DPMCP | | + | +-------+ | + | | + +---------------------------------------------------------+ + +From the point of view of an OS, a DPRC behaves similar to a plug and +play bus, like PCI. DPRC commands can be used to enumerate the contents +of the DPRC, discover the hardware objects present (including mappable +regions and interrupts). + +:: + + DPRC.1 (bus) + | + +--+--------+-------+-------+-------+ + | | | | | + DPMCP.1 DPIO.1 DPBP.1 DPNI.1 DPMAC.1 + DPMCP.2 DPIO.2 + DPMCP.3 + +Hardware objects can be created and destroyed dynamically, providing +the ability to hot plug/unplug objects in and out of the DPRC. + +A DPRC has a mappable MMIO region (an MC portal) that can be used +to send MC commands. It has an interrupt for status events (like +hotplug). +All objects in a container share the same hardware "isolation context". +This means that with respect to an IOMMU the isolation granularity +is at the DPRC (container) level, not at the individual object +level. + +DPRCs can be defined statically and populated with objects +via a config file passed to the MC when firmware starts it. + +DPAA2 Objects for an Ethernet Network Interface +----------------------------------------------- + +A typical Ethernet NIC is monolithic-- the NIC device contains TX/RX +queuing mechanisms, configuration mechanisms, buffer management, +physical ports, and interrupts. DPAA2 uses a more granular approach +utilizing multiple hardware objects. Each object provides specialized +functions. Groups of these objects are used by software to provide +Ethernet network interface functionality. This approach provides +efficient use of finite hardware resources, flexibility, and +performance advantages. + +The diagram below shows the objects needed for a simple +network interface configuration on a system with 2 CPUs. + +:: + + +---+---+ +---+---+ + CPU0 CPU1 + +---+---+ +---+---+ + | | + +---+---+ +---+---+ + DPIO DPIO + +---+---+ +---+---+ + \ / + \ / + \ / + +---+---+ + DPNI --- DPBP,DPMCP + +---+---+ + | + | + +---+---+ + DPMAC + +---+---+ + | + port/PHY + +Below the objects are described. For each object a brief description +is provided along with a summary of the kinds of operations the object +supports and a summary of key resources of the object (MMIO regions +and IRQs). + +DPMAC (Datapath Ethernet MAC) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Represents an Ethernet MAC, a hardware device that connects to an Ethernet +PHY and allows physical transmission and reception of Ethernet frames. + +- MMIO regions: none +- IRQs: DPNI link change +- commands: set link up/down, link config, get stats, + IRQ config, enable, reset + +DPNI (Datapath Network Interface) +Contains TX/RX queues, network interface configuration, and RX buffer pool +configuration mechanisms. The TX/RX queues are in memory and are identified +by queue number. + +- MMIO regions: none +- IRQs: link state +- commands: port config, offload config, queue config, + parse/classify config, IRQ config, enable, reset + +DPIO (Datapath I/O) +~~~~~~~~~~~~~~~~~~~ +Provides interfaces to enqueue and dequeue +packets and do hardware buffer pool management operations. The DPAA2 +architecture separates the mechanism to access queues (the DPIO object) +from the queues themselves. The DPIO provides an MMIO interface to +enqueue/dequeue packets. To enqueue something a descriptor is written +to the DPIO MMIO region, which includes the target queue number. +There will typically be one DPIO assigned to each CPU. This allows all +CPUs to simultaneously perform enqueue/dequeued operations. DPIOs are +expected to be shared by different DPAA2 drivers. + +- MMIO regions: queue operations, buffer management +- IRQs: data availability, congestion notification, buffer + pool depletion +- commands: IRQ config, enable, reset + +DPBP (Datapath Buffer Pool) +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Represents a hardware buffer pool. + +- MMIO regions: none +- IRQs: none +- commands: enable, reset + +DPMCP (Datapath MC Portal) +~~~~~~~~~~~~~~~~~~~~~~~~~~ +Provides an MC command portal. +Used by drivers to send commands to the MC to manage +objects. + +- MMIO regions: MC command portal +- IRQs: command completion +- commands: IRQ config, enable, reset + +Object Connections +================== +Some objects have explicit relationships that must +be configured: + +- DPNI <--> DPMAC +- DPNI <--> DPNI +- DPNI <--> L2-switch-port + + A DPNI must be connected to something such as a DPMAC, + another DPNI, or L2 switch port. The DPNI connection + is made via a DPRC command. + +:: + + +-------+ +-------+ + | DPNI | | DPMAC | + +---+---+ +---+---+ + | | + +==========+ + +- DPNI <--> DPBP + + A network interface requires a 'buffer pool' (DPBP + object) which provides a list of pointers to memory + where received Ethernet data is to be copied. The + Ethernet driver configures the DPBPs associated with + the network interface. + +Interrupts +========== +All interrupts generated by DPAA2 objects are message +interrupts. At the hardware level message interrupts +generated by devices will normally have 3 components-- +1) a non-spoofable 'device-id' expressed on the hardware +bus, 2) an address, 3) a data value. + +In the case of DPAA2 devices/objects, all objects in the +same container/DPRC share the same 'device-id'. +For ARM-based SoC this is the same as the stream ID. + + +DPAA2 Linux Drivers Overview +============================ + +This section provides an overview of the Linux kernel drivers for +DPAA2-- 1) the bus driver and associated "DPAA2 infrastructure" +drivers and 2) functional object drivers (such as Ethernet). + +As described previously, a DPRC is a container that holds the other +types of DPAA2 objects. It is functionally similar to a plug-and-play +bus controller. +Each object in the DPRC is a Linux "device" and is bound to a driver. +The diagram below shows the Linux drivers involved in a networking +scenario and the objects bound to each driver. A brief description +of each driver follows. + +:: + + +------------+ + | OS Network | + | Stack | + +------------+ +------------+ + | Allocator |. . . . . . . | Ethernet | + |(DPMCP,DPBP)| | (DPNI) | + +-.----------+ +---+---+----+ + . . ^ | + . . <data avail, | | <enqueue, + . . tx confirm> | | dequeue> + +-------------+ . | | + | DPRC driver | . +---+---V----+ +---------+ + | (DPRC) | . . . . . .| DPIO driver| | MAC | + +----------+--+ | (DPIO) | | (DPMAC) | + | +------+-----+ +-----+---+ + |<dev add/remove> | | + | | | + +--------+----------+ | +--+---+ + | MC-bus driver | | | PHY | + | | | |driver| + | /bus/fsl-mc | | +--+---+ + +-------------------+ | | + | | + ========================= HARDWARE =========|=================|====== + DPIO | + | | + DPNI---DPBP | + | | + DPMAC | + | | + PHY ---------------+ + ============================================|======================== + +A brief description of each driver is provided below. + +MC-bus driver +------------- +The MC-bus driver is a platform driver and is probed from a +node in the device tree (compatible "fsl,qoriq-mc") passed in by boot +firmware. It is responsible for bootstrapping the DPAA2 kernel +infrastructure. +Key functions include: + +- registering a new bus type named "fsl-mc" with the kernel, + and implementing bus call-backs (e.g. match/uevent/dev_groups) +- implementing APIs for DPAA2 driver registration and for device + add/remove +- creates an MSI IRQ domain +- doing a 'device add' to expose the 'root' DPRC, in turn triggering + a bind of the root DPRC to the DPRC driver + +The binding for the MC-bus device-tree node can be consulted at +*Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt*. +The sysfs bind/unbind interfaces for the MC-bus can be consulted at +*Documentation/ABI/testing/sysfs-bus-fsl-mc*. + +DPRC driver +----------- +The DPRC driver is bound to DPRC objects and does runtime management +of a bus instance. It performs the initial bus scan of the DPRC +and handles interrupts for container events such as hot plug by +re-scanning the DPRC. + +Allocator +--------- +Certain objects such as DPMCP and DPBP are generic and fungible, +and are intended to be used by other drivers. For example, +the DPAA2 Ethernet driver needs: + +- DPMCPs to send MC commands, to configure network interfaces +- DPBPs for network buffer pools + +The allocator driver registers for these allocatable object types +and those objects are bound to the allocator when the bus is probed. +The allocator maintains a pool of objects that are available for +allocation by other DPAA2 drivers. + +DPIO driver +----------- +The DPIO driver is bound to DPIO objects and provides services that allow +other drivers such as the Ethernet driver to enqueue and dequeue data for +their respective objects. +Key services include: + +- data availability notifications +- hardware queuing operations (enqueue and dequeue of data) +- hardware buffer pool management + +To transmit a packet the Ethernet driver puts data on a queue and +invokes a DPIO API. For receive, the Ethernet driver registers +a data availability notification callback. To dequeue a packet +a DPIO API is used. +There is typically one DPIO object per physical CPU for optimum +performance, allowing different CPUs to simultaneously enqueue +and dequeue data. + +The DPIO driver operates on behalf of all DPAA2 drivers +active in the kernel-- Ethernet, crypto, compression, +etc. + +Ethernet driver +--------------- +The Ethernet driver is bound to a DPNI and implements the kernel +interfaces needed to connect the DPAA2 network interface to +the network stack. +Each DPNI corresponds to a Linux network interface. + +MAC driver +---------- +An Ethernet PHY is an off-chip, board specific component and is managed +by the appropriate PHY driver via an mdio bus. The MAC driver +plays a role of being a proxy between the PHY driver and the +MC. It does this proxy via the MC commands to a DPMAC object. +If the PHY driver signals a link change, the MAC driver notifies +the MC via a DPMAC command. If a network interface is brought +up or down, the MC notifies the DPMAC driver via an interrupt and +the driver can take appropriate action. diff --git a/Documentation/networking/i40e.txt b/Documentation/networking/i40e.txt index 57e616e..c2d6e18 100644 --- a/Documentation/networking/i40e.txt +++ b/Documentation/networking/i40e.txt @@ -32,7 +32,7 @@ Enabling the driver The driver is enabled via the standard kernel configuration system, using the make command: - Make oldconfig/silentoldconfig/menuconfig/etc. + make config/oldconfig/menuconfig/etc. The driver is located in the menu structure at: diff --git a/Documentation/networking/ice.txt b/Documentation/networking/ice.txt new file mode 100644 index 0000000..6261c46 --- /dev/null +++ b/Documentation/networking/ice.txt @@ -0,0 +1,39 @@ +Intel(R) Ethernet Connection E800 Series Linux Driver +=================================================================== + +Intel ice Linux driver. +Copyright(c) 2018 Intel Corporation. + +Contents +======== +- Enabling the driver +- Support + +The driver in this release supports Intel's E800 Series of products. For +more information, visit Intel's support page at http://support.intel.com. + +Enabling the driver +=================== + +The driver is enabled via the standard kernel configuration system, +using the make command: + + Make oldconfig/silentoldconfig/menuconfig/etc. + +The driver is located in the menu structure at: + + -> Device Drivers + -> Network device support (NETDEVICES [=y]) + -> Ethernet driver support + -> Intel devices + -> Intel(R) Ethernet Connection E800 Series Support + +Support +======= + +For general information, go to the Intel support website at: + + http://support.intel.com + +If an issue is identified with the released source code, please email +the maintainer listed in the MAINTAINERS file. diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 90966c2..f204eaf 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -8,6 +8,7 @@ Contents: batman-adv can + dpaa2/index kapi z8530book msg_zerocopy diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index a553d4e..5dc1a04 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -133,14 +133,11 @@ min_adv_mss - INTEGER IP Fragmentation: -ipfrag_high_thresh - INTEGER - Maximum memory used to reassemble IP fragments. When - ipfrag_high_thresh bytes of memory is allocated for this purpose, - the fragment handler will toss packets until ipfrag_low_thresh - is reached. This also serves as a maximum limit to namespaces - different from the initial one. - -ipfrag_low_thresh - INTEGER +ipfrag_high_thresh - LONG INTEGER + Maximum memory used to reassemble IP fragments. + +ipfrag_low_thresh - LONG INTEGER + (Obsolete since linux-4.17) Maximum memory used to reassemble IP fragments before the kernel begins to remove incomplete fragment queues to free up resources. The kernel still accepts new fragments for defragmentation. @@ -755,13 +752,13 @@ udp_rmem_min - INTEGER Minimal size of receive buffer used by UDP sockets in moderation. Each UDP socket is able to use the size for receiving data, even if total pages of UDP sockets exceed udp_mem pressure. The unit is byte. - Default: 1 page + Default: 4K udp_wmem_min - INTEGER Minimal size of send buffer used by UDP sockets in moderation. Each UDP socket is able to use the size for sending data, even if total pages of UDP sockets exceed udp_mem pressure. The unit is byte. - Default: 1 page + Default: 4K CIPSOv4 Variables: @@ -1363,6 +1360,13 @@ flowlabel_reflect - BOOLEAN FALSE: disabled Default: FALSE +fib_multipath_hash_policy - INTEGER + Controls which hash policy to use for multipath routes. + Default: 0 (Layer 3) + Possible values: + 0 - Layer 3 (source and destination addresses plus flow label) + 1 - Layer 4 (standard 5-tuple) + anycast_src_echo_reply - BOOLEAN Controls the use of anycast addresses as source addresses for ICMPv6 echo reply @@ -1696,7 +1700,9 @@ disable_ipv6 - BOOLEAN interface and start Duplicate Address Detection, if necessary. When this value is changed from 0 to 1 (IPv6 is being disabled), - it will dynamically delete all address on the given interface. + it will dynamically delete all addresses and routes on the given + interface. From now on it will not possible to add addresses/routes + to the selected interface. accept_dad - INTEGER Whether to accept DAD (Duplicate Address Detection). @@ -2094,7 +2100,7 @@ sctp_rmem - vector of 3 INTEGERs: min, default, max It is guaranteed to each SCTP socket (but not association) even under moderate memory pressure. - Default: 1 page + Default: 4K sctp_wmem - vector of 3 INTEGERs: min, default, max Currently this tunable has no effect. diff --git a/Documentation/networking/irda.txt b/Documentation/networking/irda.txt deleted file mode 100644 index bff26c1..0000000 --- a/Documentation/networking/irda.txt +++ /dev/null @@ -1,10 +0,0 @@ -To use the IrDA protocols within Linux you will need to get a suitable copy -of the IrDA Utilities. More detailed information about these and associated -programs can be found on http://irda.sourceforge.net/ - -For more information about how to use the IrDA protocol stack, see the -Linux Infrared HOWTO by Werner Heuser <wehe@tuxmobil.org>: -<http://www.tuxmobil.org/Infrared-HOWTO/Infrared-HOWTO.html> - -There is an active mailing list for discussing Linux-IrDA matters called - irda-users@lists.sourceforge.net diff --git a/Documentation/networking/msg_zerocopy.rst b/Documentation/networking/msg_zerocopy.rst index 291a012..fe46d48 100644 --- a/Documentation/networking/msg_zerocopy.rst +++ b/Documentation/networking/msg_zerocopy.rst @@ -72,11 +72,6 @@ this flag, a process must first signal intent by setting a socket option: if (setsockopt(fd, SOL_SOCKET, SO_ZEROCOPY, &one, sizeof(one))) error(1, errno, "setsockopt zerocopy"); -Setting the socket option only works when the socket is in its initial -(TCP_CLOSED) state. Trying to set the option for a socket returned by accept(), -for example, will lead to an EBUSY error. In this case, the option should be set -to the listening socket and it will be inherited by the accepted sockets. - Transmission ------------ diff --git a/Documentation/networking/net_dim.txt b/Documentation/networking/net_dim.txt new file mode 100644 index 0000000..9cb31c5 --- /dev/null +++ b/Documentation/networking/net_dim.txt @@ -0,0 +1,174 @@ +Net DIM - Generic Network Dynamic Interrupt Moderation +====================================================== + +Author: + Tal Gilboa <talgi@mellanox.com> + + +Contents +========= + +- Assumptions +- Introduction +- The Net DIM Algorithm +- Registering a Network Device to DIM +- Example + +Part 0: Assumptions +====================== + +This document assumes the reader has basic knowledge in network drivers +and in general interrupt moderation. + + +Part I: Introduction +====================== + +Dynamic Interrupt Moderation (DIM) (in networking) refers to changing the +interrupt moderation configuration of a channel in order to optimize packet +processing. The mechanism includes an algorithm which decides if and how to +change moderation parameters for a channel, usually by performing an analysis on +runtime data sampled from the system. Net DIM is such a mechanism. In each +iteration of the algorithm, it analyses a given sample of the data, compares it +to the previous sample and if required, it can decide to change some of the +interrupt moderation configuration fields. The data sample is composed of data +bandwidth, the number of packets and the number of events. The time between +samples is also measured. Net DIM compares the current and the previous data and +returns an adjusted interrupt moderation configuration object. In some cases, +the algorithm might decide not to change anything. The configuration fields are +the minimum duration (microseconds) allowed between events and the maximum +number of wanted packets per event. The Net DIM algorithm ascribes importance to +increase bandwidth over reducing interrupt rate. + + +Part II: The Net DIM Algorithm +=============================== + +Each iteration of the Net DIM algorithm follows these steps: +1. Calculates new data sample. +2. Compares it to previous sample. +3. Makes a decision - suggests interrupt moderation configuration fields. +4. Applies a schedule work function, which applies suggested configuration. + +The first two steps are straightforward, both the new and the previous data are +supplied by the driver registered to Net DIM. The previous data is the new data +supplied to the previous iteration. The comparison step checks the difference +between the new and previous data and decides on the result of the last step. +A step would result as "better" if bandwidth increases and as "worse" if +bandwidth reduces. If there is no change in bandwidth, the packet rate is +compared in a similar fashion - increase == "better" and decrease == "worse". +In case there is no change in the packet rate as well, the interrupt rate is +compared. Here the algorithm tries to optimize for lower interrupt rate so an +increase in the interrupt rate is considered "worse" and a decrease is +considered "better". Step #2 has an optimization for avoiding false results: it +only considers a difference between samples as valid if it is greater than a +certain percentage. Also, since Net DIM does not measure anything by itself, it +assumes the data provided by the driver is valid. + +Step #3 decides on the suggested configuration based on the result from step #2 +and the internal state of the algorithm. The states reflect the "direction" of +the algorithm: is it going left (reducing moderation), right (increasing +moderation) or standing still. Another optimization is that if a decision +to stay still is made multiple times, the interval between iterations of the +algorithm would increase in order to reduce calculation overhead. Also, after +"parking" on one of the most left or most right decisions, the algorithm may +decide to verify this decision by taking a step in the other direction. This is +done in order to avoid getting stuck in a "deep sleep" scenario. Once a +decision is made, an interrupt moderation configuration is selected from +the predefined profiles. + +The last step is to notify the registered driver that it should apply the +suggested configuration. This is done by scheduling a work function, defined by +the Net DIM API and provided by the registered driver. + +As you can see, Net DIM itself does not actively interact with the system. It +would have trouble making the correct decisions if the wrong data is supplied to +it and it would be useless if the work function would not apply the suggested +configuration. This does, however, allow the registered driver some room for +manoeuvre as it may provide partial data or ignore the algorithm suggestion +under some conditions. + + +Part III: Registering a Network Device to DIM +============================================== + +Net DIM API exposes the main function net_dim(struct net_dim *dim, +struct net_dim_sample end_sample). This function is the entry point to the Net +DIM algorithm and has to be called every time the driver would like to check if +it should change interrupt moderation parameters. The driver should provide two +data structures: struct net_dim and struct net_dim_sample. Struct net_dim +describes the state of DIM for a specific object (RX queue, TX queue, +other queues, etc.). This includes the current selected profile, previous data +samples, the callback function provided by the driver and more. +Struct net_dim_sample describes a data sample, which will be compared to the +data sample stored in struct net_dim in order to decide on the algorithm's next +step. The sample should include bytes, packets and interrupts, measured by +the driver. + +In order to use Net DIM from a networking driver, the driver needs to call the +main net_dim() function. The recommended method is to call net_dim() on each +interrupt. Since Net DIM has a built-in moderation and it might decide to skip +iterations under certain conditions, there is no need to moderate the net_dim() +calls as well. As mentioned above, the driver needs to provide an object of type +struct net_dim to the net_dim() function call. It is advised for each entity +using Net DIM to hold a struct net_dim as part of its data structure and use it +as the main Net DIM API object. The struct net_dim_sample should hold the latest +bytes, packets and interrupts count. No need to perform any calculations, just +include the raw data. + +The net_dim() call itself does not return anything. Instead Net DIM relies on +the driver to provide a callback function, which is called when the algorithm +decides to make a change in the interrupt moderation parameters. This callback +will be scheduled and run in a separate thread in order not to add overhead to +the data flow. After the work is done, Net DIM algorithm needs to be set to +the proper state in order to move to the next iteration. + + +Part IV: Example +================= + +The following code demonstrates how to register a driver to Net DIM. The actual +usage is not complete but it should make the outline of the usage clear. + +my_driver.c: + +#include <linux/net_dim.h> + +/* Callback for net DIM to schedule on a decision to change moderation */ +void my_driver_do_dim_work(struct work_struct *work) +{ + /* Get struct net_dim from struct work_struct */ + struct net_dim *dim = container_of(work, struct net_dim, + work); + /* Do interrupt moderation related stuff */ + ... + + /* Signal net DIM work is done and it should move to next iteration */ + dim->state = NET_DIM_START_MEASURE; +} + +/* My driver's interrupt handler */ +int my_driver_handle_interrupt(struct my_driver_entity *my_entity, ...) +{ + ... + /* A struct to hold current measured data */ + struct net_dim_sample dim_sample; + ... + /* Initiate data sample struct with current data */ + net_dim_sample(my_entity->events, + my_entity->packets, + my_entity->bytes, + &dim_sample); + /* Call net DIM */ + net_dim(&my_entity->dim, dim_sample); + ... +} + +/* My entity's initialization function (my_entity was already allocated) */ +int my_driver_init_my_entity(struct my_driver_entity *my_entity, ...) +{ + ... + /* Initiate struct work_struct with my driver's callback function */ + INIT_WORK(&my_entity->dim.work, my_driver_do_dim_work); + ... +} diff --git a/Documentation/networking/nf_flowtable.txt b/Documentation/networking/nf_flowtable.txt new file mode 100644 index 0000000..54128c5 --- /dev/null +++ b/Documentation/networking/nf_flowtable.txt @@ -0,0 +1,112 @@ +Netfilter's flowtable infrastructure +==================================== + +This documentation describes the software flowtable infrastructure available in +Netfilter since Linux kernel 4.16. + +Overview +-------- + +Initial packets follow the classic forwarding path, once the flow enters the +established state according to the conntrack semantics (ie. we have seen traffic +in both directions), then you can decide to offload the flow to the flowtable +from the forward chain via the 'flow offload' action available in nftables. + +Packets that find an entry in the flowtable (ie. flowtable hit) are sent to the +output netdevice via neigh_xmit(), hence, they bypass the classic forwarding +path (the visible effect is that you do not see these packets from any of the +netfilter hooks coming after the ingress). In case of flowtable miss, the packet +follows the classic forward path. + +The flowtable uses a resizable hashtable, lookups are based on the following +7-tuple selectors: source, destination, layer 3 and layer 4 protocols, source +and destination ports and the input interface (useful in case there are several +conntrack zones in place). + +Flowtables are populated via the 'flow offload' nftables action, so the user can +selectively specify what flows are placed into the flow table. Hence, packets +follow the classic forwarding path unless the user explicitly instruct packets +to use this new alternative forwarding path via nftables policy. + +This is represented in Fig.1, which describes the classic forwarding path +including the Netfilter hooks and the flowtable fastpath bypass. + + userspace process + ^ | + | | + _____|____ ____\/___ + / \ / \ + | input | | output | + \__________/ \_________/ + ^ | + | | + _________ __________ --------- _____\/_____ + / \ / \ |Routing | / \ + --> ingress ---> prerouting ---> |decision| | postrouting |--> neigh_xmit + \_________/ \__________/ ---------- \____________/ ^ + | ^ | | ^ | + flowtable | | ____\/___ | | + | | | / \ | | + __\/___ | --------->| forward |------------ | + |-----| | \_________/ | + |-----| | 'flow offload' rule | + |-----| | adds entry to | + |_____| | flowtable | + | | | + / \ | | + /hit\_no_| | + \ ? / | + \ / | + |__yes_________________fastpath bypass ____________________________| + + Fig.1 Netfilter hooks and flowtable interactions + +The flowtable entry also stores the NAT configuration, so all packets are +mangled according to the NAT policy that matches the initial packets that went +through the classic forwarding path. The TTL is decremented before calling +neigh_xmit(). Fragmented traffic is passed up to follow the classic forwarding +path given that the transport selectors are missing, therefore flowtable lookup +is not possible. + +Example configuration +--------------------- + +Enabling the flowtable bypass is relatively easy, you only need to create a +flowtable and add one rule to your forward chain. + + table inet x { + flowtable f { + hook ingress priority 0 devices = { eth0, eth1 }; + } + chain y { + type filter hook forward priority 0; policy accept; + ip protocol tcp flow offload @f + counter packets 0 bytes 0 + } + } + +This example adds the flowtable 'f' to the ingress hook of the eth0 and eth1 +netdevices. You can create as many flowtables as you want in case you need to +perform resource partitioning. The flowtable priority defines the order in which +hooks are run in the pipeline, this is convenient in case you already have a +nftables ingress chain (make sure the flowtable priority is smaller than the +nftables ingress chain hence the flowtable runs before in the pipeline). + +The 'flow offload' action from the forward chain 'y' adds an entry to the +flowtable for the TCP syn-ack packet coming in the reply direction. Once the +flow is offloaded, you will observe that the counter rule in the example above +does not get updated for the packets that are being forwarded through the +forwarding bypass. + +More reading +------------ + +This documentation is based on the LWN.net articles [1][2]. Rafal Milecki also +made a very complete and comprehensive summary called "A state of network +acceleration" that describes how things were before this infrastructure was +mailined [3] and it also makes a rough summary of this work [4]. + +[1] https://lwn.net/Articles/738214/ +[2] https://lwn.net/Articles/742164/ +[3] http://lists.infradead.org/pipermail/lede-dev/2018-January/010830.html +[4] http://lists.infradead.org/pipermail/lede-dev/2018-January/010829.html diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index bf65484..999eb41 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -7,15 +7,12 @@ socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for i) capture network traffic with utilities like tcpdump, ii) transmit network traffic, or any other that needs raw access to network interface. -You can find the latest version of this document at: - http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap - Howto can be found at: - http://wiki.gnu-log.net (packet_mmap) + https://sites.google.com/site/packetmmap/ Please send your comments to Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es> - Johann Baudy <johann.baudy@gnu-log.net> + Johann Baudy ------------------------------------------------------------------------------- + Why use PACKET_MMAP @@ -51,17 +48,8 @@ From the user standpoint, you should use the higher level libpcap library, which is a de facto standard, portable across nearly all operating systems including Win32. -Said that, at time of this writing, official libpcap 0.8.1 is out and doesn't include -support for PACKET_MMAP, and also probably the libpcap included in your distribution. - -I'm aware of two implementations of PACKET_MMAP in libpcap: - - http://wiki.ipxwarzone.com/ (by Simon Patarin, based on libpcap 0.6.2) - http://public.lanl.gov/cpw/ (by Phil Wood, based on lastest libpcap) - -The rest of this document is intended for people who want to understand -the low level details or want to improve libpcap by including PACKET_MMAP -support. +Packet MMAP support was integrated into libpcap around the time of version 1.3.0; +TPACKET_V3 support was added in version 1.5.0 -------------------------------------------------------------------------------- + How to use mmap() directly to improve capture process @@ -174,7 +162,7 @@ As capture, each frame contains two parts: /* bind socket to eth0 */ bind(this->socket, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_ll)); - A complete tutorial is available at: http://wiki.gnu-log.net/ + A complete tutorial is available at: https://sites.google.com/site/packetmmap/ By default, the user should put data at : frame base + TPACKET_HDRLEN - sizeof(struct sockaddr_ll) diff --git a/Documentation/networking/segmentation-offloads.txt b/Documentation/networking/segmentation-offloads.txt index d47480b..aca542e 100644 --- a/Documentation/networking/segmentation-offloads.txt +++ b/Documentation/networking/segmentation-offloads.txt @@ -20,8 +20,8 @@ TCP Segmentation Offload TCP segmentation allows a device to segment a single frame into multiple frames with a data payload size specified in skb_shinfo()->gso_size. -When TCP segmentation requested the bit for either SKB_GSO_TCP or -SKB_GSO_TCP6 should be set in skb_shinfo()->gso_type and +When TCP segmentation requested the bit for either SKB_GSO_TCPV4 or +SKB_GSO_TCPV6 should be set in skb_shinfo()->gso_type and skb_shinfo()->gso_size should be set to a non-zero value. TCP segmentation is dependent on support for the use of partial checksum @@ -153,8 +153,18 @@ To signal this, gso_size is set to the special value GSO_BY_FRAGS. Therefore, any code in the core networking stack must be aware of the possibility that gso_size will be GSO_BY_FRAGS and handle that case -appropriately. (For size checks, the skb_gso_validate_*_len family of -helpers do this automatically.) +appropriately. + +There are some helpers to make this easier: + + - skb_is_gso(skb) && skb_is_gso_sctp(skb) is the best way to see if + an skb is an SCTP GSO skb. + + - For size checks, the skb_gso_validate_*_len family of helpers correctly + considers GSO_BY_FRAGS. + + - For manipulating packets, skb_increase_gso_size and skb_decrease_gso_size + will check for GSO_BY_FRAGS and WARN if asked to manipulate these skbs. This also affects drivers with the NETIF_F_FRAGLIST & NETIF_F_GSO_SCTP bits set. Note also that NETIF_F_GSO_SCTP is included in NETIF_F_GSO_SOFTWARE. diff --git a/Documentation/networking/tls.txt b/Documentation/networking/tls.txt index 77ed006..58b5ef7 100644 --- a/Documentation/networking/tls.txt +++ b/Documentation/networking/tls.txt @@ -48,6 +48,9 @@ the transmit and the receive into the kernel. setsockopt(sock, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info)); +Transmit and receive are set separately, but the setup is the same, using either +TLS_TX or TLS_RX. + Sending TLS application data ---------------------------- @@ -79,6 +82,28 @@ for memory), or the encryption will always succeed. If send() returns -ENOMEM and some data was left on the socket buffer from a previous call using MSG_MORE, the MSG_MORE data is left on the socket buffer. +Receiving TLS application data +------------------------------ + +After setting the TLS_RX socket option, all recv family socket calls +are decrypted using TLS parameters provided. A full TLS record must +be received before decryption can happen. + + char buffer[16384]; + recv(sock, buffer, 16384); + +Received data is decrypted directly in to the user buffer if it is +large enough, and no additional allocations occur. If the userspace +buffer is too small, data is decrypted in the kernel and copied to +userspace. + +EINVAL is returned if the TLS version in the received message does not +match the version passed in setsockopt. + +EMSGSIZE is returned if the received message is too big. + +EBADMSG is returned if decryption failed for any other reason. + Send TLS control messages ------------------------- @@ -118,6 +143,43 @@ using a record of type @record_type. Control message data should be provided unencrypted, and will be encrypted by the kernel. +Receiving TLS control messages +------------------------------ + +TLS control messages are passed in the userspace buffer, with message +type passed via cmsg. If no cmsg buffer is provided, an error is +returned if a control message is received. Data messages may be +received without a cmsg buffer set. + + char buffer[16384]; + char cmsg[CMSG_SPACE(sizeof(unsigned char))]; + struct msghdr msg = {0}; + msg.msg_control = cmsg; + msg.msg_controllen = sizeof(cmsg); + + struct iovec msg_iov; + msg_iov.iov_base = buffer; + msg_iov.iov_len = 16384; + + msg.msg_iov = &msg_iov; + msg.msg_iovlen = 1; + + int ret = recvmsg(sock, &msg, 0 /* flags */); + + struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg); + if (cmsg->cmsg_level == SOL_TLS && + cmsg->cmsg_type == TLS_GET_RECORD_TYPE) { + int record_type = *((unsigned char *)CMSG_DATA(cmsg)); + // Do something with record_type, and control message data in + // buffer. + // + // Note that record_type may be == to application data (23). + } else { + // Buffer contains application data. + } + +recv will never return data from mixed types of TLS records. + Integrating in to userspace TLS library --------------------------------------- @@ -126,10 +188,10 @@ layer of a userspace TLS library. A patchset to OpenSSL to use ktls as the record layer is here: -https://github.com/Mellanox/tls-openssl +https://github.com/Mellanox/openssl/commits/tls_rx2 An example of calling send directly after a handshake using gnutls. Since it doesn't implement a full record layer, control messages are not supported: -https://github.com/Mellanox/tls-af_ktls_tool +https://github.com/ktls/af_ktls-tool/commits/RX diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index 9f2f942..cc87adf 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -24,8 +24,16 @@ Some warnings, first. * see the FAQ below for details. (This is not true for more traditional * power states like "standby", which normally don't turn USB off.) +Swap partition: You need to append resume=/dev/your_swap_partition to kernel command -line. Then you suspend by +line or specify it using /sys/power/resume. + +Swap file: +If using a swapfile you can also specify a resume offset using +resume_offset=<number> on the kernel command line or specify it +in /sys/power/resume_offset. + +After preparing then you suspend by echo shutdown > /sys/power/disk; echo disk > /sys/power/state diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index 645fa9c..c209d70 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -213,7 +213,7 @@ The tags in common use are: which can be found in Documentation/process/submitting-patches.rst. Code without a proper signoff cannot be merged into the mainline. - - Co-Developed-by: states that the patch was also created by another developer + - Co-developed-by: states that the patch was also created by another developer along with the original author. This is useful at times when multiple people work on a single patch. Note, this person also needs to have a Signed-off-by: line in the patch as well. diff --git a/Documentation/process/adding-syscalls.rst b/Documentation/process/adding-syscalls.rst index 8cc25a0..314c8bf 100644 --- a/Documentation/process/adding-syscalls.rst +++ b/Documentation/process/adding-syscalls.rst @@ -222,7 +222,7 @@ your new syscall number may get adjusted to resolve conflicts. The file ``kernel/sys_ni.c`` provides a fallback stub implementation of each system call, returning ``-ENOSYS``. Add your new system call here too:: - cond_syscall(sys_xyzzy); + COND_SYSCALL(xyzzy); Your new kernel functionality, and the system call that controls it, should normally be optional, so add a ``CONFIG`` option (typically to @@ -487,6 +487,38 @@ patchset, for the convenience of reviewers. The man page should be cc'ed to linux-man@vger.kernel.org For more details, see https://www.kernel.org/doc/man-pages/patches.html + +Do not call System Calls in the Kernel +-------------------------------------- + +System calls are, as stated above, interaction points between userspace and +the kernel. Therefore, system call functions such as ``sys_xyzzy()`` or +``compat_sys_xyzzy()`` should only be called from userspace via the syscall +table, but not from elsewhere in the kernel. If the syscall functionality is +useful to be used within the kernel, needs to be shared between an old and a +new syscall, or needs to be shared between a syscall and its compatibility +variant, it should be implemented by means of a "helper" function (such as +``kern_xyzzy()``). This kernel function may then be called within the +syscall stub (``sys_xyzzy()``), the compatibility syscall stub +(``compat_sys_xyzzy()``), and/or other kernel code. + +At least on 64-bit x86, it will be a hard requirement from v4.17 onwards to not +call system call functions in the kernel. It uses a different calling +convention for system calls where ``struct pt_regs`` is decoded on-the-fly in a +syscall wrapper which then hands processing over to the actual syscall function. +This means that only those parameters which are actually needed for a specific +syscall are passed on during syscall entry, instead of filling in six CPU +registers with random user space content all the time (which may cause serious +trouble down the call chain). + +Moreover, rules on how data may be accessed may differ between kernel data and +user data. This is another reason why calling ``sys_xyzzy()`` is generally a +bad idea. + +Exceptions to this rule are only allowed in architecture-specific overrides, +architecture-specific compatibility wrappers, or other code in arch/. + + References and Sources ---------------------- diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 81cdb528..ddc0297 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -78,7 +78,7 @@ Binutils -------- The build system has, as of 4.13, switched to using thin archives (`ar T`) -rather than incremental linking (`ld -r`) for built-in.o intermediate steps. +rather than incremental linking (`ld -r`) for built-in.a intermediate steps. This requires binutils 2.20 or newer. Flex @@ -430,7 +430,7 @@ udev FUSE ---- -- <http://sourceforge.net/projects/fuse> +- <https://github.com/libfuse/libfuse/releases> mcelog ------ diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index a20b44a..d98deb6 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -200,6 +200,15 @@ statement; in the latter case use braces in both branches: otherwise(); } +Also, use braces when a loop contains more than a single simple statement: + +.. code-block:: c + + while (condition) { + if (test) + do_something(); + } + 3.1) Spaces *********** diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index c6875b1..3df5581 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -213,13 +213,6 @@ will learn the basics of getting your patch into the Linux kernel tree, and possibly be pointed in the direction of what to go work on next, if you do not already have an idea. -If you already have a chunk of code that you want to put into the kernel -tree, but need some help getting it in the proper form, the -kernel-mentors project was created to help you out with this. It is a -mailing list, and can be found at: - - https://selenic.com/mailman/listinfo/kernel-mentors - Before making any actual modifications to the Linux kernel code, it is imperative to understand how the code in question works. For this purpose, nothing is better than reading through it directly (most tricky @@ -381,14 +374,6 @@ bugs is one of the best ways to get merits among other developers, because not many people like wasting time fixing other people's bugs. To work in the already reported bug reports, go to https://bugzilla.kernel.org. -If you want to be advised of the future bug reports, you can subscribe to the -bugme-new mailing list (only new bug reports are mailed here) or to the -bugme-janitor mailing list (every change in the bugzilla is mailed here) - - https://lists.linux-foundation.org/mailman/listinfo/bugme-new - - https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors - Mailing lists diff --git a/Documentation/process/kernel-driver-statement.rst b/Documentation/process/kernel-driver-statement.rst index 60d9d86..e78452c2 100644 --- a/Documentation/process/kernel-driver-statement.rst +++ b/Documentation/process/kernel-driver-statement.rst @@ -103,6 +103,7 @@ today, have in the past, or will in the future. - Auke Kok - Peter Korsgaard - Jiri Kosina + - Aaro Koskinen - Mariusz Kozlowski - Greg Kroah-Hartman - Michael Krufky diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst index 408f77d..8ea2632 100644 --- a/Documentation/process/license-rules.rst +++ b/Documentation/process/license-rules.rst @@ -4,15 +4,17 @@ Linux kernel licensing rules ============================ The Linux Kernel is provided under the terms of the GNU General Public -License version 2 only (GPL-2.0), as published by the Free Software -Foundation, and provided in the COPYING file. This documentation file is -not meant to replace the COPYING file, but provides a description of how -each source file should be annotated to make the licensing it is governed -under clear and unambiguous. - -The license in the COPYING file applies to the kernel source as a whole, -though individual source files can have a different license which is -required to be compatible with the GPL-2.0:: +License version 2 only (GPL-2.0), as provided in LICENSES/preferred/GPL-2.0, +with an explicit syscall exception described in +LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file. + +This documentation file provides a description of how each source file +should be annotated to make its license clear and unambiguous. +It doesn't replace the Kernel's license. + +The license described in the COPYING file applies to the kernel source +as a whole, though individual source files can have a different license +which is required to be compatible with the GPL-2.0:: GPL-1.0+ : GNU General Public License v1.0 or later GPL-2.0+ : GNU General Public License v2.0 or later diff --git a/Documentation/process/magic-number.rst b/Documentation/process/magic-number.rst index c74199f..00cecf1f 100644 --- a/Documentation/process/magic-number.rst +++ b/Documentation/process/magic-number.rst @@ -14,7 +14,7 @@ passing pointers to structures via a void * pointer. The tty code, for example, does this frequently to pass driver-specific and line discipline-specific structures back and forth. -The way to use magic numbers is to declare then at the beginning of +The way to use magic numbers is to declare them at the beginning of the structure, like so:: struct tty_ldisc { diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 1ef19d3..f7152ed 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -510,8 +510,8 @@ tracking your trees, and to people trying to troubleshoot bugs in your tree. -12) When to use Acked-by: and Cc: ---------------------------------- +12) When to use Acked-by:, Cc:, and Co-Developed-by: +------------------------------------------------------- The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. @@ -543,6 +543,11 @@ person it names - but it should indicate that this person was copied on the patch. This tag documents that potentially interested parties have been included in the discussion. +A Co-Developed-by: states that the patch was also created by another developer +along with the original author. This is useful at times when multiple people +work on a single patch. Note, this person also needs to have a Signed-off-by: +line in the patch as well. + 13) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: -------------------------------------------------------------------------- diff --git a/Documentation/ptp/ptp.txt b/Documentation/ptp/ptp.txt index ae8fef8..11e904e 100644 --- a/Documentation/ptp/ptp.txt +++ b/Documentation/ptp/ptp.txt @@ -18,7 +18,6 @@ - Adjust clock frequency + Ancillary clock features - - One short or periodic alarms, with signal delivery to user program - Time stamp external events - Period output signals configurable from user space - Synchronization of the Linux system time via the PPS subsystem @@ -48,9 +47,7 @@ User space programs may control the clock using standardized ioctls. A program may query, enable, configure, and disable the ancillary clock features. User space can receive time stamped - events via blocking read() and poll(). One shot and periodic - signals may be configured via the POSIX timer_settime() system - call. + events via blocking read() and poll(). ** Writing clock drivers diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt index 47ce9a5..a1adac8 100644 --- a/Documentation/rapidio/sysfs.txt +++ b/Documentation/rapidio/sysfs.txt @@ -1,158 +1,3 @@ - RapidIO sysfs Files - -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -1. RapidIO Device Subdirectories --------------------------------- - -For each RapidIO device, the RapidIO subsystem creates files in an individual -subdirectory with the following name, /sys/bus/rapidio/devices/<device_name>. - -The format of device_name is "nn:d:iiii", where: - -nn - two-digit hexadecimal ID of RapidIO network where the device resides -d - device typr: 'e' - for endpoint or 's' - for switch -iiii - four-digit device destID for endpoints, or switchID for switches - -For example, below is a list of device directories that represents a typical -RapidIO network with one switch, one host, and two agent endpoints, as it is -seen by the enumerating host (destID = 1): - -/sys/bus/rapidio/devices/00:e:0000 -/sys/bus/rapidio/devices/00:e:0002 -/sys/bus/rapidio/devices/00:s:0001 - -NOTE: An enumerating or discovering endpoint does not create a sysfs entry for -itself, this is why an endpoint with destID=1 is not shown in the list. - -2. Attributes Common for All RapidIO Devices --------------------------------------------- - -Each device subdirectory contains the following informational read-only files: - - did - returns the device identifier - vid - returns the device vendor identifier -device_rev - returns the device revision level - asm_did - returns identifier for the assembly containing the device - asm_rev - returns revision level of the assembly containing the device - asm_vid - returns vendor identifier of the assembly containing the device - destid - returns device destination ID assigned by the enumeration routine - (see 4.1 for switch specific details) - lprev - returns name of previous device (switch) on the path to the device - that that owns this attribute - modalias - returns the device modalias - -In addition to the files listed above, each device has a binary attribute file -that allows read/write access to the device configuration registers using -the RapidIO maintenance transactions: - - config - reads from and writes to the device configuration registers. - -This attribute is similar in behavior to the "config" attribute of PCI devices -and provides an access to the RapidIO device registers using standard file read -and write operations. - -3. RapidIO Endpoint Device Attributes -------------------------------------- - -Currently Linux RapidIO subsystem does not create any endpoint specific sysfs -attributes. It is possible that RapidIO master port drivers and endpoint device -drivers will add their device-specific sysfs attributes but such attributes are -outside the scope of this document. - -4. RapidIO Switch Device Attributes ------------------------------------ - -RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports -common and device-specific sysfs attributes for switches. Because switches are -integrated into the RapidIO subsystem, it offers a method to create -device-specific sysfs attributes by specifying a callback function that may be -set by the switch initialization routine during enumeration or discovery process. - -4.1 Common Switch Attributes - - routes - reports switch routing information in "destID port" format. This - attribute reports only valid routing table entries, one line for - each entry. - destid - device destination ID that defines a route to the switch - hopcount - number of hops on the path to the switch - lnext - returns names of devices linked to the switch except one of a device - linked to the ingress port (reported as "lprev"). This is an array - names with number of lines equal to number of ports in switch. If - a switch port has no attached device, returns "null" instead of - a device name. - -4.2 Device-specific Switch Attributes - -Device-specific switch attributes are listed for each RapidIO switch driver -that exports additional attributes. - -IDT_GEN2: - errlog - reads contents of device error log until it is empty. - - -5. RapidIO Bus Attributes -------------------------- - -RapidIO bus subdirectory /sys/bus/rapidio implements the following bus-specific -attribute: - - scan - allows to trigger enumeration discovery process from user space. This - is a write-only attribute. To initiate an enumeration or discovery - process on specific mport device, a user needs to write mport_ID (not - RapidIO destination ID) into this file. The mport_ID is a sequential - number (0 ... RIO_MAX_MPORTS) assigned to the mport device. - For example, for a machine with a single RapidIO controller, mport_ID - for that controller always will be 0. - To initiate RapidIO enumeration/discovery on all available mports - a user must write '-1' (or RIO_MPORT_ANY) into this attribute file. - - -6. RapidIO Bus Controllers/Ports --------------------------------- - -On-chip RapidIO controllers and PCIe-to-RapidIO bridges (referenced as -"Master Port" or "mport") are presented in sysfs as the special class of -devices: "rapidio_port". - -The /sys/class/rapidio_port subdirectory contains individual subdirectories -named as "rapidioN" where N = mport ID registered with RapidIO subsystem. - -NOTE: An mport ID is not a RapidIO destination ID assigned to a given local -mport device. - -Each mport device subdirectory in addition to standard entries contains the -following device-specific attributes: - - port_destid - reports RapidIO destination ID assigned to the given RapidIO - mport device. If value 0xFFFFFFFF is returned this means that - no valid destination ID have been assigned to the mport (yet). - Normally, before enumeration/discovery have been executed only - fabric enumerating mports have a valid destination ID assigned - to them using "hdid=..." rapidio module parameter. - sys_size - reports RapidIO common transport system size: - 0 = small (8-bit destination ID, max. 256 devices), - 1 = large (16-bit destination ID, max. 65536 devices). - -After enumeration or discovery was performed for a given mport device, -the corresponding subdirectory will also contain subdirectories for each -child RapidIO device connected to the mport. Naming conventions for RapidIO -devices are described in Section 1 above. - -The example below shows mport device subdirectory with several child RapidIO -devices attached to it. - -[rio@rapidio ~]$ ls /sys/class/rapidio_port/rapidio0/ -l -total 0 -drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0001 -drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0004 -drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0007 -drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0002 -drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0003 -drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0005 -lrwxrwxrwx 1 root root 0 Feb 11 15:11 device -> ../../../0000:01:00.0 --r--r--r-- 1 root root 4096 Feb 11 15:11 port_destid -drwxr-xr-x 2 root root 0 Feb 11 15:11 power -lrwxrwxrwx 1 root root 0 Feb 11 15:04 subsystem -> ../../../../../../class/rapidio_port --r--r--r-- 1 root root 4096 Feb 11 15:11 sys_size --rw-r--r-- 1 root root 4096 Feb 11 15:04 uevent +The RapidIO sysfs files have moved to: +Documentation/ABI/testing/sysfs-bus-rapidio and +Documentation/ABI/testing/sysfs-class-rapidio diff --git a/Documentation/sparc/adi.txt b/Documentation/sparc/adi.txt new file mode 100644 index 0000000..e1aed15 --- /dev/null +++ b/Documentation/sparc/adi.txt @@ -0,0 +1,278 @@ +Application Data Integrity (ADI) +================================ + +SPARC M7 processor adds the Application Data Integrity (ADI) feature. +ADI allows a task to set version tags on any subset of its address +space. Once ADI is enabled and version tags are set for ranges of +address space of a task, the processor will compare the tag in pointers +to memory in these ranges to the version set by the application +previously. Access to memory is granted only if the tag in given pointer +matches the tag set by the application. In case of mismatch, processor +raises an exception. + +Following steps must be taken by a task to enable ADI fully: + +1. Set the user mode PSTATE.mcde bit. This acts as master switch for + the task's entire address space to enable/disable ADI for the task. + +2. Set TTE.mcd bit on any TLB entries that correspond to the range of + addresses ADI is being enabled on. MMU checks the version tag only + on the pages that have TTE.mcd bit set. + +3. Set the version tag for virtual addresses using stxa instruction + and one of the MCD specific ASIs. Each stxa instruction sets the + given tag for one ADI block size number of bytes. This step must + be repeated for entire page to set tags for entire page. + +ADI block size for the platform is provided by the hypervisor to kernel +in machine description tables. Hypervisor also provides the number of +top bits in the virtual address that specify the version tag. Once +version tag has been set for a memory location, the tag is stored in the +physical memory and the same tag must be present in the ADI version tag +bits of the virtual address being presented to the MMU. For example on +SPARC M7 processor, MMU uses bits 63-60 for version tags and ADI block +size is same as cacheline size which is 64 bytes. A task that sets ADI +version to, say 10, on a range of memory, must access that memory using +virtual addresses that contain 0xa in bits 63-60. + +ADI is enabled on a set of pages using mprotect() with PROT_ADI flag. +When ADI is enabled on a set of pages by a task for the first time, +kernel sets the PSTATE.mcde bit fot the task. Version tags for memory +addresses are set with an stxa instruction on the addresses using +ASI_MCD_PRIMARY or ASI_MCD_ST_BLKINIT_PRIMARY. ADI block size is +provided by the hypervisor to the kernel. Kernel returns the value of +ADI block size to userspace using auxiliary vector along with other ADI +info. Following auxiliary vectors are provided by the kernel: + + AT_ADI_BLKSZ ADI block size. This is the granularity and + alignment, in bytes, of ADI versioning. + AT_ADI_NBITS Number of ADI version bits in the VA + + +IMPORTANT NOTES: + +- Version tag values of 0x0 and 0xf are reserved. These values match any + tag in virtual address and never generate a mismatch exception. + +- Version tags are set on virtual addresses from userspace even though + tags are stored in physical memory. Tags are set on a physical page + after it has been allocated to a task and a pte has been created for + it. + +- When a task frees a memory page it had set version tags on, the page + goes back to free page pool. When this page is re-allocated to a task, + kernel clears the page using block initialization ASI which clears the + version tags as well for the page. If a page allocated to a task is + freed and allocated back to the same task, old version tags set by the + task on that page will no longer be present. + +- ADI tag mismatches are not detected for non-faulting loads. + +- Kernel does not set any tags for user pages and it is entirely a + task's responsibility to set any version tags. Kernel does ensure the + version tags are preserved if a page is swapped out to the disk and + swapped back in. It also preserves that version tags if a page is + migrated. + +- ADI works for any size pages. A userspace task need not be aware of + page size when using ADI. It can simply select a virtual address + range, enable ADI on the range using mprotect() and set version tags + for the entire range. mprotect() ensures range is aligned to page size + and is a multiple of page size. + +- ADI tags can only be set on writable memory. For example, ADI tags can + not be set on read-only mappings. + + + +ADI related traps +----------------- + +With ADI enabled, following new traps may occur: + +Disrupting memory corruption + + When a store accesses a memory localtion that has TTE.mcd=1, + the task is running with ADI enabled (PSTATE.mcde=1), and the ADI + tag in the address used (bits 63:60) does not match the tag set on + the corresponding cacheline, a memory corruption trap occurs. By + default, it is a disrupting trap and is sent to the hypervisor + first. Hypervisor creates a sun4v error report and sends a + resumable error (TT=0x7e) trap to the kernel. The kernel sends + a SIGSEGV to the task that resulted in this trap with the following + info: + + siginfo.si_signo = SIGSEGV; + siginfo.errno = 0; + siginfo.si_code = SEGV_ADIDERR; + siginfo.si_addr = addr; /* PC where first mismatch occurred */ + siginfo.si_trapno = 0; + + +Precise memory corruption + + When a store accesses a memory location that has TTE.mcd=1, + the task is running with ADI enabled (PSTATE.mcde=1), and the ADI + tag in the address used (bits 63:60) does not match the tag set on + the corresponding cacheline, a memory corruption trap occurs. If + MCD precise exception is enabled (MCDPERR=1), a precise + exception is sent to the kernel with TT=0x1a. The kernel sends + a SIGSEGV to the task that resulted in this trap with the following + info: + + siginfo.si_signo = SIGSEGV; + siginfo.errno = 0; + siginfo.si_code = SEGV_ADIPERR; + siginfo.si_addr = addr; /* address that caused trap */ + siginfo.si_trapno = 0; + + NOTE: ADI tag mismatch on a load always results in precise trap. + + +MCD disabled + + When a task has not enabled ADI and attempts to set ADI version + on a memory address, processor sends an MCD disabled trap. This + trap is handled by hypervisor first and the hypervisor vectors this + trap through to the kernel as Data Access Exception trap with + fault type set to 0xa (invalid ASI). When this occurs, the kernel + sends the task SIGSEGV signal with following info: + + siginfo.si_signo = SIGSEGV; + siginfo.errno = 0; + siginfo.si_code = SEGV_ACCADI; + siginfo.si_addr = addr; /* address that caused trap */ + siginfo.si_trapno = 0; + + +Sample program to use ADI +------------------------- + +Following sample program is meant to illustrate how to use the ADI +functionality. + +#include <unistd.h> +#include <stdio.h> +#include <stdlib.h> +#include <elf.h> +#include <sys/ipc.h> +#include <sys/shm.h> +#include <sys/mman.h> +#include <asm/asi.h> + +#ifndef AT_ADI_BLKSZ +#define AT_ADI_BLKSZ 48 +#endif +#ifndef AT_ADI_NBITS +#define AT_ADI_NBITS 49 +#endif + +#ifndef PROT_ADI +#define PROT_ADI 0x10 +#endif + +#define BUFFER_SIZE 32*1024*1024UL + +main(int argc, char* argv[], char* envp[]) +{ + unsigned long i, mcde, adi_blksz, adi_nbits; + char *shmaddr, *tmp_addr, *end, *veraddr, *clraddr; + int shmid, version; + Elf64_auxv_t *auxv; + + adi_blksz = 0; + + while(*envp++ != NULL); + for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++) { + switch (auxv->a_type) { + case AT_ADI_BLKSZ: + adi_blksz = auxv->a_un.a_val; + break; + case AT_ADI_NBITS: + adi_nbits = auxv->a_un.a_val; + break; + } + } + if (adi_blksz == 0) { + fprintf(stderr, "Oops! ADI is not supported\n"); + exit(1); + } + + printf("ADI capabilities:\n"); + printf("\tBlock size = %ld\n", adi_blksz); + printf("\tNumber of bits = %ld\n", adi_nbits); + + if ((shmid = shmget(2, BUFFER_SIZE, + IPC_CREAT | SHM_R | SHM_W)) < 0) { + perror("shmget failed"); + exit(1); + } + + shmaddr = shmat(shmid, NULL, 0); + if (shmaddr == (char *)-1) { + perror("shm attach failed"); + shmctl(shmid, IPC_RMID, NULL); + exit(1); + } + + if (mprotect(shmaddr, BUFFER_SIZE, PROT_READ|PROT_WRITE|PROT_ADI)) { + perror("mprotect failed"); + goto err_out; + } + + /* Set the ADI version tag on the shm segment + */ + version = 10; + tmp_addr = shmaddr; + end = shmaddr + BUFFER_SIZE; + while (tmp_addr < end) { + asm volatile( + "stxa %1, [%0]0x90\n\t" + : + : "r" (tmp_addr), "r" (version)); + tmp_addr += adi_blksz; + } + asm volatile("membar #Sync\n\t"); + + /* Create a versioned address from the normal address by placing + * version tag in the upper adi_nbits bits + */ + tmp_addr = (void *) ((unsigned long)shmaddr << adi_nbits); + tmp_addr = (void *) ((unsigned long)tmp_addr >> adi_nbits); + veraddr = (void *) (((unsigned long)version << (64-adi_nbits)) + | (unsigned long)tmp_addr); + + printf("Starting the writes:\n"); + for (i = 0; i < BUFFER_SIZE; i++) { + veraddr[i] = (char)(i); + if (!(i % (1024 * 1024))) + printf("."); + } + printf("\n"); + + printf("Verifying data..."); + fflush(stdout); + for (i = 0; i < BUFFER_SIZE; i++) + if (veraddr[i] != (char)i) + printf("\nIndex %lu mismatched\n", i); + printf("Done.\n"); + + /* Disable ADI and clean up + */ + if (mprotect(shmaddr, BUFFER_SIZE, PROT_READ|PROT_WRITE)) { + perror("mprotect failed"); + goto err_out; + } + + if (shmdt((const void *)shmaddr) != 0) + perror("Detach failure"); + shmctl(shmid, IPC_RMID, NULL); + + exit(0); + +err_out: + if (shmdt((const void *)shmaddr) != 0) + perror("Detach failure"); + shmctl(shmid, IPC_RMID, NULL); + exit(1); +} diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index 35c62f5..5992602 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -270,6 +270,18 @@ optmem_max Maximum ancillary buffer size allowed per socket. Ancillary data is a sequence of struct cmsghdr structures with appended data. +fb_tunnels_only_for_init_net +---------------------------- + +Controls if fallback tunnels (like tunl0, gre0, gretap0, erspan0, +sit0, ip6tnl0, ip6gre0) are automatically created when a new +network namespace is created, if corresponding tunnel is present +in initial network namespace. +If set to 1, these devices are not automatically created, and +user space is responsible for creating them if needed. + +Default : 0 (for compatibility reasons) + 2. /proc/sys/net/unix - Parameters for Unix domain sockets ------------------------------------------------------- diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt index 2dcaf9a..9591092 100644 --- a/Documentation/timers/NO_HZ.txt +++ b/Documentation/timers/NO_HZ.txt @@ -131,13 +131,6 @@ error message, and the boot CPU will be removed from the mask. Note that this means that your system must have at least two CPUs in order for CONFIG_NO_HZ_FULL=y to do anything for you. -Alternatively, the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies -that all CPUs other than the boot CPU are adaptive-ticks CPUs. This -Kconfig parameter will be overridden by the "nohz_full=" boot parameter, -so that if both the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter and -the "nohz_full=1" boot parameter is specified, the boot parameter will -prevail so that only CPU 1 will be an adaptive-ticks CPU. - Finally, adaptive-ticks CPUs must have their RCU callbacks offloaded. This is covered in the "RCU IMPLICATIONS" section below. diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt index a33c88c..6f0120c 100644 --- a/Documentation/trace/coresight.txt +++ b/Documentation/trace/coresight.txt @@ -330,3 +330,54 @@ Details on how to use the generic STM API can be found here [2]. [1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm [2]. Documentation/trace/stm.txt + + +Using perf tools +---------------- + +perf can be used to record and analyze trace of programs. + +Execution can be recorded using 'perf record' with the cs_etm event, +specifying the name of the sink to record to, e.g: + + perf record -e cs_etm/@20070000.etr/u --per-thread + +The 'perf report' and 'perf script' commands can be used to analyze execution, +synthesizing instruction and branch events from the instruction trace. +'perf inject' can be used to replace the trace data with the synthesized events. +The --itrace option controls the type and frequency of synthesized events +(see perf documentation). + +Note that only 64-bit programs are currently supported - further work is +required to support instruction decode of 32-bit Arm programs. + + +Generating coverage files for Feedback Directed Optimization: AutoFDO +--------------------------------------------------------------------- + +'perf inject' accepts the --itrace option in which case tracing data is +removed and replaced with the synthesized events. e.g. + + perf inject --itrace --strip -i perf.data -o perf.data.new + +Below is an example of using ARM ETM for autoFDO. It requires autofdo +(https://github.com/google/autofdo) and gcc version 5. The bubble +sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial). + + $ gcc-5 -O3 sort.c -o sort + $ taskset -c 2 ./sort + Bubble sorting array of 30000 elements + 5910 ms + + $ perf record -e cs_etm/@20070000.etr/u --per-thread taskset -c 2 ./sort + Bubble sorting array of 30000 elements + 12543 ms + [ perf record: Woken up 35 times to write data ] + [ perf record: Captured and wrote 69.640 MB perf.data ] + + $ perf inject -i perf.data -o inj.data --itrace=il64 --strip + $ create_gcov --binary=./sort --profile=inj.data --gcov=sort.gcov -gcov_version=1 + $ gcc-5 -O3 -fauto-profile=sort.gcov sort.c -o sort_autofdo + $ taskset -c 2 ./sort_autofdo + Bubble sorting array of 30000 elements + 5806 ms diff --git a/Documentation/trace/events-kmem.txt b/Documentation/trace/events-kmem.rst index 1948004..5554841 100644 --- a/Documentation/trace/events-kmem.txt +++ b/Documentation/trace/events-kmem.rst @@ -1,22 +1,26 @@ - Subsystem Trace Points: kmem +============================ +Subsystem Trace Points: kmem +============================ The kmem tracing system captures events related to object and page allocation within the kernel. Broadly speaking there are five major subheadings. - o Slab allocation of small objects of unknown type (kmalloc) - o Slab allocation of small objects of known type - o Page allocation - o Per-CPU Allocator Activity - o External Fragmentation + - Slab allocation of small objects of unknown type (kmalloc) + - Slab allocation of small objects of known type + - Page allocation + - Per-CPU Allocator Activity + - External Fragmentation This document describes what each of the tracepoints is and why they might be useful. 1. Slab allocation of small objects of unknown type =================================================== -kmalloc call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s -kmalloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d -kfree call_site=%lx ptr=%p +:: + + kmalloc call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s + kmalloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d + kfree call_site=%lx ptr=%p Heavy activity for these events may indicate that a specific cache is justified, particularly if kmalloc slab pages are getting significantly @@ -27,9 +31,11 @@ the allocation sites were. 2. Slab allocation of small objects of known type ================================================= -kmem_cache_alloc call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s -kmem_cache_alloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d -kmem_cache_free call_site=%lx ptr=%p +:: + + kmem_cache_alloc call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s + kmem_cache_alloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d + kmem_cache_free call_site=%lx ptr=%p These events are similar in usage to the kmalloc-related events except that it is likely easier to pin the event down to a specific cache. At the time @@ -38,10 +44,12 @@ but the call_site can usually be used to extrapolate that information. 3. Page allocation ================== -mm_page_alloc page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s -mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d -mm_page_free page=%p pfn=%lu order=%d -mm_page_free_batched page=%p pfn=%lu order=%d cold=%d +:: + + mm_page_alloc page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s + mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d + mm_page_free page=%p pfn=%lu order=%d + mm_page_free_batched page=%p pfn=%lu order=%d cold=%d These four events deal with page allocation and freeing. mm_page_alloc is a simple indicator of page allocator activity. Pages may be allocated from @@ -65,8 +73,10 @@ contention on the zone->lru_lock. 4. Per-CPU Allocator Activity ============================= -mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d -mm_page_pcpu_drain page=%p pfn=%lu order=%d cpu=%d migratetype=%d +:: + + mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d + mm_page_pcpu_drain page=%p pfn=%lu order=%d cpu=%d migratetype=%d In front of the page allocator is a per-cpu page allocator. It exists only for order-0 pages, reduces contention on the zone->lock and reduces the @@ -92,7 +102,9 @@ can be allocated and freed on the same CPU through some algorithm change. 5. External Fragmentation ========================= -mm_page_alloc_extfrag page=%p pfn=%lu alloc_order=%d fallback_order=%d pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d fragmenting=%d change_ownership=%d +:: + + mm_page_alloc_extfrag page=%p pfn=%lu alloc_order=%d fallback_order=%d pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d fragmenting=%d change_ownership=%d External fragmentation affects whether a high-order allocation will be successful or not. For some types of hardware, this is important although diff --git a/Documentation/trace/events-msr.rst b/Documentation/trace/events-msr.rst new file mode 100644 index 0000000..e938aa0 --- /dev/null +++ b/Documentation/trace/events-msr.rst @@ -0,0 +1,40 @@ +================ +MSR Trace Events +================ + +The x86 kernel supports tracing most MSR (Model Specific Register) accesses. +To see the definition of the MSRs on Intel systems please see the SDM +at http://www.intel.com/sdm (Volume 3) + +Available trace points: + +/sys/kernel/debug/tracing/events/msr/ + +Trace MSR reads: + +read_msr + + - msr: MSR number + - val: Value written + - failed: 1 if the access failed, otherwise 0 + + +Trace MSR writes: + +write_msr + + - msr: MSR number + - val: Value written + - failed: 1 if the access failed, otherwise 0 + + +Trace RDPMC in kernel: + +rdpmc + +The trace data can be post processed with the postprocess/decode_msr.py script:: + + cat /sys/kernel/debug/tracing/trace | decode_msr.py /usr/src/linux/include/asm/msr-index.h + +to add symbolic MSR names. + diff --git a/Documentation/trace/events-msr.txt b/Documentation/trace/events-msr.txt deleted file mode 100644 index 78c383b..0000000 --- a/Documentation/trace/events-msr.txt +++ /dev/null @@ -1,37 +0,0 @@ - -The x86 kernel supports tracing most MSR (Model Specific Register) accesses. -To see the definition of the MSRs on Intel systems please see the SDM -at http://www.intel.com/sdm (Volume 3) - -Available trace points: - -/sys/kernel/debug/tracing/events/msr/ - -Trace MSR reads - -read_msr - -msr: MSR number -val: Value written -failed: 1 if the access failed, otherwise 0 - - -Trace MSR writes - -write_msr - -msr: MSR number -val: Value written -failed: 1 if the access failed, otherwise 0 - - -Trace RDPMC in kernel - -rdpmc - -The trace data can be post processed with the postprocess/decode_msr.py script - -cat /sys/kernel/debug/tracing/trace | decode_msr.py /usr/src/linux/include/asm/msr-index.h - -to add symbolic MSR names. - diff --git a/Documentation/trace/events-nmi.rst b/Documentation/trace/events-nmi.rst new file mode 100644 index 0000000..9e0a728 --- /dev/null +++ b/Documentation/trace/events-nmi.rst @@ -0,0 +1,45 @@ +================ +NMI Trace Events +================ + +These events normally show up here: + + /sys/kernel/debug/tracing/events/nmi + + +nmi_handler +----------- + +You might want to use this tracepoint if you suspect that your +NMI handlers are hogging large amounts of CPU time. The kernel +will warn if it sees long-running handlers:: + + INFO: NMI handler took too long to run: 9.207 msecs + +and this tracepoint will allow you to drill down and get some +more details. + +Let's say you suspect that perf_event_nmi_handler() is causing +you some problems and you only want to trace that handler +specifically. You need to find its address:: + + $ grep perf_event_nmi_handler /proc/kallsyms + ffffffff81625600 t perf_event_nmi_handler + +Let's also say you are only interested in when that function is +really hogging a lot of CPU time, like a millisecond at a time. +Note that the kernel's output is in milliseconds, but the input +to the filter is in nanoseconds! You can filter on 'delta_ns':: + + cd /sys/kernel/debug/tracing/events/nmi/nmi_handler + echo 'handler==0xffffffff81625600 && delta_ns>1000000' > filter + echo 1 > enable + +Your output would then look like:: + + $ cat /sys/kernel/debug/tracing/trace_pipe + <idle>-0 [000] d.h3 505.397558: nmi_handler: perf_event_nmi_handler() delta_ns: 3236765 handled: 1 + <idle>-0 [000] d.h3 505.805893: nmi_handler: perf_event_nmi_handler() delta_ns: 3174234 handled: 1 + <idle>-0 [000] d.h3 506.158206: nmi_handler: perf_event_nmi_handler() delta_ns: 3084642 handled: 1 + <idle>-0 [000] d.h3 506.334346: nmi_handler: perf_event_nmi_handler() delta_ns: 3080351 handled: 1 + diff --git a/Documentation/trace/events-nmi.txt b/Documentation/trace/events-nmi.txt deleted file mode 100644 index c03c8c8..0000000 --- a/Documentation/trace/events-nmi.txt +++ /dev/null @@ -1,43 +0,0 @@ -NMI Trace Events - -These events normally show up here: - - /sys/kernel/debug/tracing/events/nmi - --- - -nmi_handler: - -You might want to use this tracepoint if you suspect that your -NMI handlers are hogging large amounts of CPU time. The kernel -will warn if it sees long-running handlers: - - INFO: NMI handler took too long to run: 9.207 msecs - -and this tracepoint will allow you to drill down and get some -more details. - -Let's say you suspect that perf_event_nmi_handler() is causing -you some problems and you only want to trace that handler -specifically. You need to find its address: - - $ grep perf_event_nmi_handler /proc/kallsyms - ffffffff81625600 t perf_event_nmi_handler - -Let's also say you are only interested in when that function is -really hogging a lot of CPU time, like a millisecond at a time. -Note that the kernel's output is in milliseconds, but the input -to the filter is in nanoseconds! You can filter on 'delta_ns': - -cd /sys/kernel/debug/tracing/events/nmi/nmi_handler -echo 'handler==0xffffffff81625600 && delta_ns>1000000' > filter -echo 1 > enable - -Your output would then look like: - -$ cat /sys/kernel/debug/tracing/trace_pipe -<idle>-0 [000] d.h3 505.397558: nmi_handler: perf_event_nmi_handler() delta_ns: 3236765 handled: 1 -<idle>-0 [000] d.h3 505.805893: nmi_handler: perf_event_nmi_handler() delta_ns: 3174234 handled: 1 -<idle>-0 [000] d.h3 506.158206: nmi_handler: perf_event_nmi_handler() delta_ns: 3084642 handled: 1 -<idle>-0 [000] d.h3 506.334346: nmi_handler: perf_event_nmi_handler() delta_ns: 3080351 handled: 1 - diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.rst index 21d514c..a77daca 100644 --- a/Documentation/trace/events-power.txt +++ b/Documentation/trace/events-power.rst @@ -1,13 +1,14 @@ - - Subsystem Trace Points: power +============================= +Subsystem Trace Points: power +============================= The power tracing system captures events related to power transitions within the kernel. Broadly speaking there are three major subheadings: - o Power state switch which reports events related to suspend (S-states), - cpuidle (C-states) and cpufreq (P-states) - o System clock related changes - o Power domains related changes and transitions + - Power state switch which reports events related to suspend (S-states), + cpuidle (C-states) and cpufreq (P-states) + - System clock related changes + - Power domains related changes and transitions This document describes what each of the tracepoints is and why they might be useful. @@ -22,14 +23,16 @@ Cf. include/trace/events/power.h for the events definitions. A 'cpu' event class gathers the CPU-related events: cpuidle and cpufreq. +:: -cpu_idle "state=%lu cpu_id=%lu" -cpu_frequency "state=%lu cpu_id=%lu" + cpu_idle "state=%lu cpu_id=%lu" + cpu_frequency "state=%lu cpu_id=%lu" A suspend event is used to indicate the system going in and out of the suspend mode: +:: -machine_suspend "state=%lu" + machine_suspend "state=%lu" Note: the value of '-1' or '4294967295' for state means an exit from the current state, @@ -45,10 +48,11 @@ correctly draw the states diagrams and to calculate accurate statistics etc. ================ The clock events are used for clock enable/disable and for clock rate change. +:: -clock_enable "%s state=%lu cpu_id=%lu" -clock_disable "%s state=%lu cpu_id=%lu" -clock_set_rate "%s state=%lu cpu_id=%lu" + clock_enable "%s state=%lu cpu_id=%lu" + clock_disable "%s state=%lu cpu_id=%lu" + clock_set_rate "%s state=%lu cpu_id=%lu" The first parameter gives the clock name (e.g. "gpio1_iclk"). The second parameter is '1' for enable, '0' for disable, the target @@ -57,8 +61,9 @@ clock rate for set_rate. 3. Power domains events ======================= The power domain events are used for power domains transitions +:: -power_domain_target "%s state=%lu cpu_id=%lu" + power_domain_target "%s state=%lu cpu_id=%lu" The first parameter gives the power domain name (e.g. "mpu_pwrdm"). The second parameter is the power domain target state. @@ -67,28 +72,31 @@ The second parameter is the power domain target state. ================ The PM QoS events are used for QoS add/update/remove request and for target/flags update. +:: -pm_qos_add_request "pm_qos_class=%s value=%d" -pm_qos_update_request "pm_qos_class=%s value=%d" -pm_qos_remove_request "pm_qos_class=%s value=%d" -pm_qos_update_request_timeout "pm_qos_class=%s value=%d, timeout_us=%ld" + pm_qos_add_request "pm_qos_class=%s value=%d" + pm_qos_update_request "pm_qos_class=%s value=%d" + pm_qos_remove_request "pm_qos_class=%s value=%d" + pm_qos_update_request_timeout "pm_qos_class=%s value=%d, timeout_us=%ld" The first parameter gives the QoS class name (e.g. "CPU_DMA_LATENCY"). The second parameter is value to be added/updated/removed. The third parameter is timeout value in usec. +:: -pm_qos_update_target "action=%s prev_value=%d curr_value=%d" -pm_qos_update_flags "action=%s prev_value=0x%x curr_value=0x%x" + pm_qos_update_target "action=%s prev_value=%d curr_value=%d" + pm_qos_update_flags "action=%s prev_value=0x%x curr_value=0x%x" The first parameter gives the QoS action name (e.g. "ADD_REQ"). The second parameter is the previous QoS value. The third parameter is the current QoS value to update. And, there are also events used for device PM QoS add/update/remove request. +:: -dev_pm_qos_add_request "device=%s type=%s new_value=%d" -dev_pm_qos_update_request "device=%s type=%s new_value=%d" -dev_pm_qos_remove_request "device=%s type=%s new_value=%d" + dev_pm_qos_add_request "device=%s type=%s new_value=%d" + dev_pm_qos_update_request "device=%s type=%s new_value=%d" + 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. diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.rst index 2cc08d4..bdf1963 100644 --- a/Documentation/trace/events.txt +++ b/Documentation/trace/events.rst @@ -1,7 +1,9 @@ - Event Tracing +============= +Event Tracing +============= - Documentation written by Theodore Ts'o - Updated by Li Zefan and Tom Zanussi +:Author: Theodore Ts'o +:Updated: Li Zefan and Tom Zanussi 1. Introduction =============== @@ -25,23 +27,22 @@ The events which are available for tracing can be found in the file /sys/kernel/debug/tracing/available_events. To enable a particular event, such as 'sched_wakeup', simply echo it -to /sys/kernel/debug/tracing/set_event. For example: +to /sys/kernel/debug/tracing/set_event. For example:: # echo sched_wakeup >> /sys/kernel/debug/tracing/set_event -[ Note: '>>' is necessary, otherwise it will firstly disable - all the events. ] +.. Note:: '>>' is necessary, otherwise it will firstly disable all the events. To disable an event, echo the event name to the set_event file prefixed -with an exclamation point: +with an exclamation point:: # echo '!sched_wakeup' >> /sys/kernel/debug/tracing/set_event -To disable all events, echo an empty line to the set_event file: +To disable all events, echo an empty line to the set_event file:: # echo > /sys/kernel/debug/tracing/set_event -To enable all events, echo '*:*' or '*:' to the set_event file: +To enable all events, echo ``*:*`` or ``*:`` to the set_event file:: # echo *:* > /sys/kernel/debug/tracing/set_event @@ -49,8 +50,8 @@ The events are organized into subsystems, such as ext4, irq, sched, etc., and a full event name looks like this: <subsystem>:<event>. The subsystem name is optional, but it is displayed in the available_events file. All of the events in a subsystem can be specified via the syntax -"<subsystem>:*"; for example, to enable all irq events, you can use the -command: +``<subsystem>:*``; for example, to enable all irq events, you can use the +command:: # echo 'irq:*' > /sys/kernel/debug/tracing/set_event @@ -60,33 +61,33 @@ command: The events available are also listed in /sys/kernel/debug/tracing/events/ hierarchy of directories. -To enable event 'sched_wakeup': +To enable event 'sched_wakeup':: # echo 1 > /sys/kernel/debug/tracing/events/sched/sched_wakeup/enable -To disable it: +To disable it:: # echo 0 > /sys/kernel/debug/tracing/events/sched/sched_wakeup/enable -To enable all events in sched subsystem: +To enable all events in sched subsystem:: # echo 1 > /sys/kernel/debug/tracing/events/sched/enable -To enable all events: +To enable all events:: # echo 1 > /sys/kernel/debug/tracing/events/enable When reading one of these enable files, there are four results: - 0 - all events this file affects are disabled - 1 - all events this file affects are enabled - X - there is a mixture of events enabled and disabled - ? - this file does not affect any event + - 0 - all events this file affects are disabled + - 1 - all events this file affects are enabled + - X - there is a mixture of events enabled and disabled + - ? - this file does not affect any event 2.3 Boot option --------------- -In order to facilitate early boot debugging, use boot option: +In order to facilitate early boot debugging, use boot option:: trace_event=[event-list] @@ -110,12 +111,12 @@ It also displays the format string that will be used to print the event in text mode, along with the event name and ID used for profiling. -Every event has a set of 'common' fields associated with it; these are -the fields prefixed with 'common_'. The other fields vary between +Every event has a set of ``common`` fields associated with it; these are +the fields prefixed with ``common_``. The other fields vary between events and correspond to the fields defined in the TRACE_EVENT definition for that event. -Each field in the format has the form: +Each field in the format has the form:: field:field-type field-name; offset:N; size:N; @@ -123,27 +124,27 @@ where offset is the offset of the field in the trace record and size is the size of the data item, in bytes. For example, here's the information displayed for the 'sched_wakeup' -event: +event:: -# cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/format + # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/format -name: sched_wakeup -ID: 60 -format: - field:unsigned short common_type; offset:0; size:2; - field:unsigned char common_flags; offset:2; size:1; - field:unsigned char common_preempt_count; offset:3; size:1; - field:int common_pid; offset:4; size:4; - field:int common_tgid; offset:8; size:4; + name: sched_wakeup + ID: 60 + format: + field:unsigned short common_type; offset:0; size:2; + field:unsigned char common_flags; offset:2; size:1; + field:unsigned char common_preempt_count; offset:3; size:1; + field:int common_pid; offset:4; size:4; + field:int common_tgid; offset:8; size:4; - field:char comm[TASK_COMM_LEN]; offset:12; size:16; - field:pid_t pid; offset:28; size:4; - field:int prio; offset:32; size:4; - field:int success; offset:36; size:4; - field:int cpu; offset:40; size:4; + field:char comm[TASK_COMM_LEN]; offset:12; size:16; + field:pid_t pid; offset:28; size:4; + field:int prio; offset:32; size:4; + field:int success; offset:36; size:4; + field:int cpu; offset:40; size:4; -print fmt: "task %s:%d [%d] success=%d [%03d]", REC->comm, REC->pid, - REC->prio, REC->success, REC->cpu + print fmt: "task %s:%d [%d] success=%d [%03d]", REC->comm, REC->pid, + REC->prio, REC->success, REC->cpu This event contains 10 fields, the first 5 common and the remaining 5 event-specific. All the fields for this event are numeric, except for @@ -168,7 +169,7 @@ A filter expression consists of one or more 'predicates' that can be combined using the logical operators '&&' and '||'. A predicate is simply a clause that compares the value of a field contained within a logged event with a constant value and returns either 0 or 1 depending -on whether the field value matched (1) or didn't match (0): +on whether the field value matched (1) or didn't match (0):: field-name relational-operator value @@ -189,8 +190,8 @@ And for string fields they are: ==, !=, ~ -The glob (~) accepts a wild card character (*,?) and character classes -([). For example: +The glob (~) accepts a wild card character (\*,?) and character classes +([). For example:: prev_comm ~ "*sh" prev_comm ~ "sh*" @@ -203,27 +204,27 @@ The glob (~) accepts a wild card character (*,?) and character classes A filter for an individual event is set by writing a filter expression to the 'filter' file for the given event. -For example: +For example:: -# cd /sys/kernel/debug/tracing/events/sched/sched_wakeup -# echo "common_preempt_count > 4" > filter + # cd /sys/kernel/debug/tracing/events/sched/sched_wakeup + # echo "common_preempt_count > 4" > filter -A slightly more involved example: +A slightly more involved example:: -# cd /sys/kernel/debug/tracing/events/signal/signal_generate -# echo "((sig >= 10 && sig < 15) || sig == 17) && comm != bash" > filter + # cd /sys/kernel/debug/tracing/events/signal/signal_generate + # echo "((sig >= 10 && sig < 15) || sig == 17) && comm != bash" > filter If there is an error in the expression, you'll get an 'Invalid argument' error when setting it, and the erroneous string along with -an error message can be seen by looking at the filter e.g.: +an error message can be seen by looking at the filter e.g.:: -# cd /sys/kernel/debug/tracing/events/signal/signal_generate -# echo "((sig >= 10 && sig < 15) || dsig == 17) && comm != bash" > filter --bash: echo: write error: Invalid argument -# cat filter -((sig >= 10 && sig < 15) || dsig == 17) && comm != bash -^ -parse_error: Field not found + # cd /sys/kernel/debug/tracing/events/signal/signal_generate + # echo "((sig >= 10 && sig < 15) || dsig == 17) && comm != bash" > filter + -bash: echo: write error: Invalid argument + # cat filter + ((sig >= 10 && sig < 15) || dsig == 17) && comm != bash + ^ + parse_error: Field not found Currently the caret ('^') for an error always appears at the beginning of the filter string; the error message should still be useful though @@ -255,35 +256,35 @@ fields can be guaranteed to propagate successfully to all events. Here are a few subsystem filter examples that also illustrate the above points: -Clear the filters on all events in the sched subsystem: +Clear the filters on all events in the sched subsystem:: -# cd /sys/kernel/debug/tracing/events/sched -# echo 0 > filter -# cat sched_switch/filter -none -# cat sched_wakeup/filter -none + # cd /sys/kernel/debug/tracing/events/sched + # echo 0 > filter + # cat sched_switch/filter + none + # cat sched_wakeup/filter + none Set a filter using only common fields for all events in the sched -subsystem (all events end up with the same filter): +subsystem (all events end up with the same filter):: -# cd /sys/kernel/debug/tracing/events/sched -# echo common_pid == 0 > filter -# cat sched_switch/filter -common_pid == 0 -# cat sched_wakeup/filter -common_pid == 0 + # cd /sys/kernel/debug/tracing/events/sched + # echo common_pid == 0 > filter + # cat sched_switch/filter + common_pid == 0 + # cat sched_wakeup/filter + common_pid == 0 Attempt to set a filter using a non-common field for all events in the sched subsystem (all events but those that have a prev_pid field retain -their old filters): +their old filters):: -# cd /sys/kernel/debug/tracing/events/sched -# echo prev_pid == 0 > filter -# cat sched_switch/filter -prev_pid == 0 -# cat sched_wakeup/filter -common_pid == 0 + # cd /sys/kernel/debug/tracing/events/sched + # echo prev_pid == 0 > filter + # cat sched_switch/filter + prev_pid == 0 + # cat sched_wakeup/filter + common_pid == 0 5.4 PID filtering ----------------- @@ -291,16 +292,18 @@ common_pid == 0 The set_event_pid file in the same directory as the top events directory exists, will filter all events from tracing any task that does not have the PID listed in the set_event_pid file. +:: -# cd /sys/kernel/debug/tracing -# echo $$ > set_event_pid -# echo 1 > events/enabled + # cd /sys/kernel/debug/tracing + # echo $$ > set_event_pid + # echo 1 > events/enable Will only trace events for the current task. To add more PIDs without losing the PIDs already included, use '>>'. +:: -# echo 123 244 1 >> set_event_pid + # echo 123 244 1 >> set_event_pid 6. Event triggers @@ -342,12 +345,12 @@ way, so beware about making generalizations between the two. 6.1 Expression syntax --------------------- -Triggers are added by echoing the command to the 'trigger' file: +Triggers are added by echoing the command to the 'trigger' file:: # echo 'command[:count] [if filter]' > trigger Triggers are removed by echoing the same command but starting with '!' -to the 'trigger' file: +to the 'trigger' file:: # echo '!command[:count] [if filter]' > trigger @@ -379,30 +382,30 @@ The following commands are supported: For example, the following trigger causes kmalloc events to be traced when a read system call is entered, and the :1 at the end - specifies that this enablement happens only once: + specifies that this enablement happens only once:: - # echo 'enable_event:kmem:kmalloc:1' > \ - /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger + # echo 'enable_event:kmem:kmalloc:1' > \ + /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger The following trigger causes kmalloc events to stop being traced when a read system call exits. This disablement happens on every - read system call exit: + read system call exit:: - # echo 'disable_event:kmem:kmalloc' > \ - /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger + # echo 'disable_event:kmem:kmalloc' > \ + /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger - The format is: + The format is:: enable_event:<system>:<event>[:count] disable_event:<system>:<event>[:count] - To remove the above commands: + To remove the above commands:: - # echo '!enable_event:kmem:kmalloc:1' > \ - /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger + # echo '!enable_event:kmem:kmalloc:1' > \ + /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger - # echo '!disable_event:kmem:kmalloc' > \ - /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger + # echo '!disable_event:kmem:kmalloc' > \ + /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger Note that there can be any number of enable/disable_event triggers per triggering event, but there can only be one trigger per @@ -418,34 +421,34 @@ The following commands are supported: triggering event occurs. For example, the following trigger dumps a stacktrace every time the - kmalloc tracepoint is hit: + kmalloc tracepoint is hit:: - # echo 'stacktrace' > \ - /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + # echo 'stacktrace' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger The following trigger dumps a stacktrace the first 5 times a kmalloc - request happens with a size >= 64K + request happens with a size >= 64K:: - # echo 'stacktrace:5 if bytes_req >= 65536' > \ - /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + # echo 'stacktrace:5 if bytes_req >= 65536' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger - The format is: + The format is:: stacktrace[:count] - To remove the above commands: + To remove the above commands:: - # echo '!stacktrace' > \ - /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + # echo '!stacktrace' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger - # echo '!stacktrace:5 if bytes_req >= 65536' > \ - /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + # echo '!stacktrace:5 if bytes_req >= 65536' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger The latter can also be removed more simply by the following (without - the filter): + the filter):: - # echo '!stacktrace:5' > \ - /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger + # echo '!stacktrace:5' > \ + /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Note that there can be only one stacktrace trigger per triggering event. @@ -458,23 +461,23 @@ The following commands are supported: The following command creates a snapshot every time a block request queue is unplugged with a depth > 1. If you were tracing a set of events or functions at the time, the snapshot trace buffer would - capture those events when the trigger event occurred: + capture those events when the trigger event occurred:: - # echo 'snapshot if nr_rq > 1' > \ - /sys/kernel/debug/tracing/events/block/block_unplug/trigger + # echo 'snapshot if nr_rq > 1' > \ + /sys/kernel/debug/tracing/events/block/block_unplug/trigger - To only snapshot once: + To only snapshot once:: - # echo 'snapshot:1 if nr_rq > 1' > \ - /sys/kernel/debug/tracing/events/block/block_unplug/trigger + # echo 'snapshot:1 if nr_rq > 1' > \ + /sys/kernel/debug/tracing/events/block/block_unplug/trigger - To remove the above commands: + To remove the above commands:: - # echo '!snapshot if nr_rq > 1' > \ - /sys/kernel/debug/tracing/events/block/block_unplug/trigger + # echo '!snapshot if nr_rq > 1' > \ + /sys/kernel/debug/tracing/events/block/block_unplug/trigger - # echo '!snapshot:1 if nr_rq > 1' > \ - /sys/kernel/debug/tracing/events/block/block_unplug/trigger + # echo '!snapshot:1 if nr_rq > 1' > \ + /sys/kernel/debug/tracing/events/block/block_unplug/trigger Note that there can be only one snapshot trigger per triggering event. @@ -489,23 +492,23 @@ The following commands are supported: request queue is unplugged with a depth > 1. If you were tracing a set of events or functions at the time, you could then examine the trace buffer to see the sequence of events that led up to the - trigger event: + trigger event:: - # echo 'traceoff:1 if nr_rq > 1' > \ - /sys/kernel/debug/tracing/events/block/block_unplug/trigger + # echo 'traceoff:1 if nr_rq > 1' > \ + /sys/kernel/debug/tracing/events/block/block_unplug/trigger - To always disable tracing when nr_rq > 1 : + To always disable tracing when nr_rq > 1:: - # echo 'traceoff if nr_rq > 1' > \ - /sys/kernel/debug/tracing/events/block/block_unplug/trigger + # echo 'traceoff if nr_rq > 1' > \ + /sys/kernel/debug/tracing/events/block/block_unplug/trigger - To remove the above commands: + To remove the above commands:: - # echo '!traceoff:1 if nr_rq > 1' > \ - /sys/kernel/debug/tracing/events/block/block_unplug/trigger + # echo '!traceoff:1 if nr_rq > 1' > \ + /sys/kernel/debug/tracing/events/block/block_unplug/trigger - # echo '!traceoff if nr_rq > 1' > \ - /sys/kernel/debug/tracing/events/block/block_unplug/trigger + # echo '!traceoff if nr_rq > 1' > \ + /sys/kernel/debug/tracing/events/block/block_unplug/trigger Note that there can be only one traceon or traceoff trigger per triggering event. @@ -517,7 +520,7 @@ The following commands are supported: totals derived from one or more trace event format fields and/or event counts (hitcount). - The format of a hist trigger is as follows: + The format of a hist trigger is as follows:: hist:keys=<field1[,field2,...]>[:values=<field1[,field2,...]>] [:sort=<field1[,field2,...]>][:size=#entries][:pause][:continue] @@ -566,11 +569,11 @@ The following commands are supported: modified by appending any of the following modifiers to the field name: - .hex display a number as a hex value - .sym display an address as a symbol - .sym-offset display an address as a symbol and offset - .syscall display a syscall id as a system call name - .execname display a common_pid as a program name + - .hex display a number as a hex value + - .sym display an address as a symbol + - .sym-offset display an address as a symbol and offset + - .syscall display a syscall id as a system call name + - .execname display a common_pid as a program name Note that in general the semantics of a given field aren't interpreted when applying a modifier to it, but there are some @@ -588,15 +591,15 @@ The following commands are supported: pid-specific comm fields in the event itself. A typical usage scenario would be the following to enable a hist - trigger, read its current contents, and then turn it off: + trigger, read its current contents, and then turn it off:: - # echo 'hist:keys=skbaddr.hex:vals=len' > \ - /sys/kernel/debug/tracing/events/net/netif_rx/trigger + # echo 'hist:keys=skbaddr.hex:vals=len' > \ + /sys/kernel/debug/tracing/events/net/netif_rx/trigger - # cat /sys/kernel/debug/tracing/events/net/netif_rx/hist + # cat /sys/kernel/debug/tracing/events/net/netif_rx/hist - # echo '!hist:keys=skbaddr.hex:vals=len' > \ - /sys/kernel/debug/tracing/events/net/netif_rx/trigger + # echo '!hist:keys=skbaddr.hex:vals=len' > \ + /sys/kernel/debug/tracing/events/net/netif_rx/trigger The trigger file itself can be read to show the details of the currently attached hist trigger. This information is also displayed @@ -636,7 +639,7 @@ The following commands are supported: can be attached to a given event, allowing that event to kick off and stop aggregations on a host of other events. - The format is very similar to the enable/disable_event triggers: + The format is very similar to the enable/disable_event triggers:: enable_hist:<system>:<event>[:count] disable_hist:<system>:<event>[:count] @@ -649,16 +652,16 @@ The following commands are supported: A typical usage scenario for the enable_hist/disable_hist triggers would be to first set up a paused hist trigger on some event, followed by an enable_hist/disable_hist pair that turns the hist - aggregation on and off when conditions of interest are hit: + aggregation on and off when conditions of interest are hit:: - # echo 'hist:keys=skbaddr.hex:vals=len:pause' > \ - /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger + # echo 'hist:keys=skbaddr.hex:vals=len:pause' > \ + /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger - # echo 'enable_hist:net:netif_receive_skb if filename==/usr/bin/wget' > \ - /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger + # echo 'enable_hist:net:netif_receive_skb if filename==/usr/bin/wget' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger - # echo 'disable_hist:net:netif_receive_skb if comm==wget' > \ - /sys/kernel/debug/tracing/events/sched/sched_process_exit/trigger + # echo 'disable_hist:net:netif_receive_skb if comm==wget' > \ + /sys/kernel/debug/tracing/events/sched/sched_process_exit/trigger The above sets up an initially paused hist trigger which is unpaused and starts aggregating events when a given program is executed, and @@ -674,7 +677,7 @@ The following commands are supported: The first set of examples creates aggregations using the kmalloc event. The fields that can be used for the hist trigger are listed - in the kmalloc event's format file: + in the kmalloc event's format file:: # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/format name: kmalloc @@ -693,7 +696,7 @@ The following commands are supported: We'll start by creating a hist trigger that generates a simple table that lists the total number of bytes requested for each function in - the kernel that made one or more calls to kmalloc: + the kernel that made one or more calls to kmalloc:: # echo 'hist:key=call_site:val=bytes_req' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger @@ -708,7 +711,7 @@ The following commands are supported: We'll let it run for awhile and then dump the contents of the 'hist' file in the kmalloc event's subdirectory (for readability, a number - of entries have been omitted): + of entries have been omitted):: # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/hist # trigger info: hist:keys=call_site:vals=bytes_req:sort=hitcount:size=2048 [active] @@ -748,7 +751,7 @@ The following commands are supported: specified in the trigger, followed by the value(s) also specified in the trigger. At the beginning of the output is a line that displays the trigger info, which can also be displayed by reading the - 'trigger' file: + 'trigger' file:: # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger hist:keys=call_site:vals=bytes_req:sort=hitcount:size=2048 [active] @@ -778,7 +781,7 @@ The following commands are supported: frequencies. To turn the hist trigger off, simply call up the trigger in the - command history and re-execute it with a '!' prepended: + command history and re-execute it with a '!' prepended:: # echo '!hist:key=call_site:val=bytes_req' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger @@ -786,7 +789,7 @@ The following commands are supported: Finally, notice that the call_site as displayed in the output above isn't really very useful. It's an address, but normally addresses are displayed in hex. To have a numeric field displayed as a hex - value, simply append '.hex' to the field name in the trigger: + value, simply append '.hex' to the field name in the trigger:: # echo 'hist:key=call_site.hex:val=bytes_req' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger @@ -831,7 +834,7 @@ The following commands are supported: when looking at text addresses are the corresponding symbols instead. To have an address displayed as symbolic value instead, simply append '.sym' or '.sym-offset' to the field name in the - trigger: + trigger:: # echo 'hist:key=call_site.sym:val=bytes_req' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger @@ -881,7 +884,7 @@ The following commands are supported: run. If instead we we wanted to see the top kmalloc callers in terms of the number of bytes requested rather than the number of calls, and we wanted the top caller to appear at the top, we can use - the 'sort' parameter, along with the 'descending' modifier: + the 'sort' parameter, along with the 'descending' modifier:: # echo 'hist:key=call_site.sym:val=bytes_req:sort=bytes_req.descending' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger @@ -922,7 +925,7 @@ The following commands are supported: Dropped: 0 To display the offset and size information in addition to the symbol - name, just use 'sym-offset' instead: + name, just use 'sym-offset' instead:: # echo 'hist:key=call_site.sym-offset:val=bytes_req:sort=bytes_req.descending' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger @@ -961,7 +964,7 @@ The following commands are supported: We can also add multiple fields to the 'values' parameter. For example, we might want to see the total number of bytes allocated alongside bytes requested, and display the result sorted by bytes - allocated in a descending order: + allocated in a descending order:: # echo 'hist:keys=call_site.sym:values=bytes_req,bytes_alloc:sort=bytes_alloc.descending' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger @@ -1004,7 +1007,7 @@ The following commands are supported: the hist trigger display symbolic call_sites, we can have the hist trigger additionally display the complete set of kernel stack traces that led to each call_site. To do that, we simply use the special - value 'stacktrace' for the key parameter: + value 'stacktrace' for the key parameter:: # echo 'hist:keys=stacktrace:values=bytes_req,bytes_alloc:sort=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger @@ -1015,7 +1018,7 @@ The following commands are supported: event, along with a running total of any of the event fields for that event. Here we tally bytes requested and bytes allocated for every callpath in the system that led up to a kmalloc (in this case - every callpath to a kmalloc for a kernel compile): + every callpath to a kmalloc for a kernel compile):: # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/hist # trigger info: hist:keys=stacktrace:vals=bytes_req,bytes_alloc:sort=bytes_alloc:size=2048 [active] @@ -1113,7 +1116,7 @@ The following commands are supported: gather and display sorted totals for each process, you can use the special .execname modifier to display the executable names for the processes in the table rather than raw pids. The example below - keeps a per-process sum of total bytes read: + keeps a per-process sum of total bytes read:: # echo 'hist:key=common_pid.execname:val=count:sort=count.descending' > \ /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger @@ -1154,7 +1157,7 @@ The following commands are supported: gather and display a list of systemwide syscall hits, you can use the special .syscall modifier to display the syscall names rather than raw ids. The example below keeps a running total of syscall - counts for the system during the run: + counts for the system during the run:: # echo 'hist:key=id.syscall:val=hitcount' > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger @@ -1196,155 +1199,155 @@ The following commands are supported: Entries: 72 Dropped: 0 - The syscall counts above provide a rough overall picture of system - call activity on the system; we can see for example that the most - popular system call on this system was the 'sys_ioctl' system call. - - We can use 'compound' keys to refine that number and provide some - further insight as to which processes exactly contribute to the - overall ioctl count. - - The command below keeps a hitcount for every unique combination of - system call id and pid - the end result is essentially a table - that keeps a per-pid sum of system call hits. The results are - sorted using the system call id as the primary key, and the - hitcount sum as the secondary key: - - # echo 'hist:key=id.syscall,common_pid.execname:val=hitcount:sort=id,hitcount' > \ - /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger - - # cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist - # trigger info: hist:keys=id.syscall,common_pid.execname:vals=hitcount:sort=id.syscall,hitcount:size=2048 [active] - - { id: sys_read [ 0], common_pid: rtkit-daemon [ 1877] } hitcount: 1 - { id: sys_read [ 0], common_pid: gdbus [ 2976] } hitcount: 1 - { id: sys_read [ 0], common_pid: console-kit-dae [ 3400] } hitcount: 1 - { id: sys_read [ 0], common_pid: postgres [ 1865] } hitcount: 1 - { id: sys_read [ 0], common_pid: deja-dup-monito [ 3543] } hitcount: 2 - { id: sys_read [ 0], common_pid: NetworkManager [ 890] } hitcount: 2 - { id: sys_read [ 0], common_pid: evolution-calen [ 3048] } hitcount: 2 - { id: sys_read [ 0], common_pid: postgres [ 1864] } hitcount: 2 - { id: sys_read [ 0], common_pid: nm-applet [ 3022] } hitcount: 2 - { id: sys_read [ 0], common_pid: whoopsie [ 1212] } hitcount: 2 - . - . - . - { id: sys_ioctl [ 16], common_pid: bash [ 8479] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: bash [ 3472] } hitcount: 12 - { id: sys_ioctl [ 16], common_pid: gnome-terminal [ 3199] } hitcount: 16 - { id: sys_ioctl [ 16], common_pid: Xorg [ 1267] } hitcount: 1808 - { id: sys_ioctl [ 16], common_pid: compiz [ 2994] } hitcount: 5580 - . - . - . - { id: sys_waitid [247], common_pid: upstart-dbus-br [ 2690] } hitcount: 3 - { id: sys_waitid [247], common_pid: upstart-dbus-br [ 2688] } hitcount: 16 - { id: sys_inotify_add_watch [254], common_pid: gmain [ 975] } hitcount: 2 - { id: sys_inotify_add_watch [254], common_pid: gmain [ 3204] } hitcount: 4 - { id: sys_inotify_add_watch [254], common_pid: gmain [ 2888] } hitcount: 4 - { id: sys_inotify_add_watch [254], common_pid: gmain [ 3003] } hitcount: 4 - { id: sys_inotify_add_watch [254], common_pid: gmain [ 2873] } hitcount: 4 - { id: sys_inotify_add_watch [254], common_pid: gmain [ 3196] } hitcount: 6 - { id: sys_openat [257], common_pid: java [ 2623] } hitcount: 2 - { id: sys_eventfd2 [290], common_pid: ibus-ui-gtk3 [ 2760] } hitcount: 4 - { id: sys_eventfd2 [290], common_pid: compiz [ 2994] } hitcount: 6 - - Totals: - Hits: 31536 - Entries: 323 - Dropped: 0 - - The above list does give us a breakdown of the ioctl syscall by - pid, but it also gives us quite a bit more than that, which we - don't really care about at the moment. Since we know the syscall - id for sys_ioctl (16, displayed next to the sys_ioctl name), we - can use that to filter out all the other syscalls: - - # echo 'hist:key=id.syscall,common_pid.execname:val=hitcount:sort=id,hitcount if id == 16' > \ - /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger - - # cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist - # trigger info: hist:keys=id.syscall,common_pid.execname:vals=hitcount:sort=id.syscall,hitcount:size=2048 if id == 16 [active] - - { id: sys_ioctl [ 16], common_pid: gmain [ 2769] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: evolution-addre [ 8571] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: gmain [ 3003] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: gmain [ 2781] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: gmain [ 2829] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: bash [ 8726] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: bash [ 8508] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: gmain [ 2970] } hitcount: 1 - { id: sys_ioctl [ 16], common_pid: gmain [ 2768] } hitcount: 1 - . - . - . - { id: sys_ioctl [ 16], common_pid: pool [ 8559] } hitcount: 45 - { id: sys_ioctl [ 16], common_pid: pool [ 8555] } hitcount: 48 - { id: sys_ioctl [ 16], common_pid: pool [ 8551] } hitcount: 48 - { id: sys_ioctl [ 16], common_pid: avahi-daemon [ 896] } hitcount: 66 - { id: sys_ioctl [ 16], common_pid: Xorg [ 1267] } hitcount: 26674 - { id: sys_ioctl [ 16], common_pid: compiz [ 2994] } hitcount: 73443 - - Totals: - Hits: 101162 - Entries: 103 - Dropped: 0 - - The above output shows that 'compiz' and 'Xorg' are far and away - the heaviest ioctl callers (which might lead to questions about - whether they really need to be making all those calls and to - possible avenues for further investigation.) - - The compound key examples used a key and a sum value (hitcount) to - sort the output, but we can just as easily use two keys instead. - Here's an example where we use a compound key composed of the the - common_pid and size event fields. Sorting with pid as the primary - key and 'size' as the secondary key allows us to display an - ordered summary of the recvfrom sizes, with counts, received by - each process: - - # echo 'hist:key=common_pid.execname,size:val=hitcount:sort=common_pid,size' > \ - /sys/kernel/debug/tracing/events/syscalls/sys_enter_recvfrom/trigger - - # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_recvfrom/hist - # trigger info: hist:keys=common_pid.execname,size:vals=hitcount:sort=common_pid.execname,size:size=2048 [active] - - { common_pid: smbd [ 784], size: 4 } hitcount: 1 - { common_pid: dnsmasq [ 1412], size: 4096 } hitcount: 672 - { common_pid: postgres [ 1796], size: 1000 } hitcount: 6 - { common_pid: postgres [ 1867], size: 1000 } hitcount: 10 - { common_pid: bamfdaemon [ 2787], size: 28 } hitcount: 2 - { common_pid: bamfdaemon [ 2787], size: 14360 } hitcount: 1 - { common_pid: compiz [ 2994], size: 8 } hitcount: 1 - { common_pid: compiz [ 2994], size: 20 } hitcount: 11 - { common_pid: gnome-terminal [ 3199], size: 4 } hitcount: 2 - { common_pid: firefox [ 8817], size: 4 } hitcount: 1 - { common_pid: firefox [ 8817], size: 8 } hitcount: 5 - { common_pid: firefox [ 8817], size: 588 } hitcount: 2 - { common_pid: firefox [ 8817], size: 628 } hitcount: 1 - { common_pid: firefox [ 8817], size: 6944 } hitcount: 1 - { common_pid: firefox [ 8817], size: 408880 } hitcount: 2 - { common_pid: firefox [ 8822], size: 8 } hitcount: 2 - { common_pid: firefox [ 8822], size: 160 } hitcount: 2 - { common_pid: firefox [ 8822], size: 320 } hitcount: 2 - { common_pid: firefox [ 8822], size: 352 } hitcount: 1 - . - . - . - { common_pid: pool [ 8923], size: 1960 } hitcount: 10 - { common_pid: pool [ 8923], size: 2048 } hitcount: 10 - { common_pid: pool [ 8924], size: 1960 } hitcount: 10 - { common_pid: pool [ 8924], size: 2048 } hitcount: 10 - { common_pid: pool [ 8928], size: 1964 } hitcount: 4 - { common_pid: pool [ 8928], size: 1965 } hitcount: 2 - { common_pid: pool [ 8928], size: 2048 } hitcount: 6 - { common_pid: pool [ 8929], size: 1982 } hitcount: 1 - { common_pid: pool [ 8929], size: 2048 } hitcount: 1 - - Totals: - Hits: 2016 - Entries: 224 - Dropped: 0 + The syscall counts above provide a rough overall picture of system + call activity on the system; we can see for example that the most + popular system call on this system was the 'sys_ioctl' system call. + + We can use 'compound' keys to refine that number and provide some + further insight as to which processes exactly contribute to the + overall ioctl count. + + The command below keeps a hitcount for every unique combination of + system call id and pid - the end result is essentially a table + that keeps a per-pid sum of system call hits. The results are + sorted using the system call id as the primary key, and the + hitcount sum as the secondary key:: + + # echo 'hist:key=id.syscall,common_pid.execname:val=hitcount:sort=id,hitcount' > \ + /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger + + # cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist + # trigger info: hist:keys=id.syscall,common_pid.execname:vals=hitcount:sort=id.syscall,hitcount:size=2048 [active] + + { id: sys_read [ 0], common_pid: rtkit-daemon [ 1877] } hitcount: 1 + { id: sys_read [ 0], common_pid: gdbus [ 2976] } hitcount: 1 + { id: sys_read [ 0], common_pid: console-kit-dae [ 3400] } hitcount: 1 + { id: sys_read [ 0], common_pid: postgres [ 1865] } hitcount: 1 + { id: sys_read [ 0], common_pid: deja-dup-monito [ 3543] } hitcount: 2 + { id: sys_read [ 0], common_pid: NetworkManager [ 890] } hitcount: 2 + { id: sys_read [ 0], common_pid: evolution-calen [ 3048] } hitcount: 2 + { id: sys_read [ 0], common_pid: postgres [ 1864] } hitcount: 2 + { id: sys_read [ 0], common_pid: nm-applet [ 3022] } hitcount: 2 + { id: sys_read [ 0], common_pid: whoopsie [ 1212] } hitcount: 2 + . + . + . + { id: sys_ioctl [ 16], common_pid: bash [ 8479] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: bash [ 3472] } hitcount: 12 + { id: sys_ioctl [ 16], common_pid: gnome-terminal [ 3199] } hitcount: 16 + { id: sys_ioctl [ 16], common_pid: Xorg [ 1267] } hitcount: 1808 + { id: sys_ioctl [ 16], common_pid: compiz [ 2994] } hitcount: 5580 + . + . + . + { id: sys_waitid [247], common_pid: upstart-dbus-br [ 2690] } hitcount: 3 + { id: sys_waitid [247], common_pid: upstart-dbus-br [ 2688] } hitcount: 16 + { id: sys_inotify_add_watch [254], common_pid: gmain [ 975] } hitcount: 2 + { id: sys_inotify_add_watch [254], common_pid: gmain [ 3204] } hitcount: 4 + { id: sys_inotify_add_watch [254], common_pid: gmain [ 2888] } hitcount: 4 + { id: sys_inotify_add_watch [254], common_pid: gmain [ 3003] } hitcount: 4 + { id: sys_inotify_add_watch [254], common_pid: gmain [ 2873] } hitcount: 4 + { id: sys_inotify_add_watch [254], common_pid: gmain [ 3196] } hitcount: 6 + { id: sys_openat [257], common_pid: java [ 2623] } hitcount: 2 + { id: sys_eventfd2 [290], common_pid: ibus-ui-gtk3 [ 2760] } hitcount: 4 + { id: sys_eventfd2 [290], common_pid: compiz [ 2994] } hitcount: 6 + + Totals: + Hits: 31536 + Entries: 323 + Dropped: 0 + + The above list does give us a breakdown of the ioctl syscall by + pid, but it also gives us quite a bit more than that, which we + don't really care about at the moment. Since we know the syscall + id for sys_ioctl (16, displayed next to the sys_ioctl name), we + can use that to filter out all the other syscalls:: + + # echo 'hist:key=id.syscall,common_pid.execname:val=hitcount:sort=id,hitcount if id == 16' > \ + /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger + + # cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist + # trigger info: hist:keys=id.syscall,common_pid.execname:vals=hitcount:sort=id.syscall,hitcount:size=2048 if id == 16 [active] + + { id: sys_ioctl [ 16], common_pid: gmain [ 2769] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: evolution-addre [ 8571] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: gmain [ 3003] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: gmain [ 2781] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: gmain [ 2829] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: bash [ 8726] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: bash [ 8508] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: gmain [ 2970] } hitcount: 1 + { id: sys_ioctl [ 16], common_pid: gmain [ 2768] } hitcount: 1 + . + . + . + { id: sys_ioctl [ 16], common_pid: pool [ 8559] } hitcount: 45 + { id: sys_ioctl [ 16], common_pid: pool [ 8555] } hitcount: 48 + { id: sys_ioctl [ 16], common_pid: pool [ 8551] } hitcount: 48 + { id: sys_ioctl [ 16], common_pid: avahi-daemon [ 896] } hitcount: 66 + { id: sys_ioctl [ 16], common_pid: Xorg [ 1267] } hitcount: 26674 + { id: sys_ioctl [ 16], common_pid: compiz [ 2994] } hitcount: 73443 + + Totals: + Hits: 101162 + Entries: 103 + Dropped: 0 + + The above output shows that 'compiz' and 'Xorg' are far and away + the heaviest ioctl callers (which might lead to questions about + whether they really need to be making all those calls and to + possible avenues for further investigation.) + + The compound key examples used a key and a sum value (hitcount) to + sort the output, but we can just as easily use two keys instead. + Here's an example where we use a compound key composed of the the + common_pid and size event fields. Sorting with pid as the primary + key and 'size' as the secondary key allows us to display an + ordered summary of the recvfrom sizes, with counts, received by + each process:: + + # echo 'hist:key=common_pid.execname,size:val=hitcount:sort=common_pid,size' > \ + /sys/kernel/debug/tracing/events/syscalls/sys_enter_recvfrom/trigger + + # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_recvfrom/hist + # trigger info: hist:keys=common_pid.execname,size:vals=hitcount:sort=common_pid.execname,size:size=2048 [active] + + { common_pid: smbd [ 784], size: 4 } hitcount: 1 + { common_pid: dnsmasq [ 1412], size: 4096 } hitcount: 672 + { common_pid: postgres [ 1796], size: 1000 } hitcount: 6 + { common_pid: postgres [ 1867], size: 1000 } hitcount: 10 + { common_pid: bamfdaemon [ 2787], size: 28 } hitcount: 2 + { common_pid: bamfdaemon [ 2787], size: 14360 } hitcount: 1 + { common_pid: compiz [ 2994], size: 8 } hitcount: 1 + { common_pid: compiz [ 2994], size: 20 } hitcount: 11 + { common_pid: gnome-terminal [ 3199], size: 4 } hitcount: 2 + { common_pid: firefox [ 8817], size: 4 } hitcount: 1 + { common_pid: firefox [ 8817], size: 8 } hitcount: 5 + { common_pid: firefox [ 8817], size: 588 } hitcount: 2 + { common_pid: firefox [ 8817], size: 628 } hitcount: 1 + { common_pid: firefox [ 8817], size: 6944 } hitcount: 1 + { common_pid: firefox [ 8817], size: 408880 } hitcount: 2 + { common_pid: firefox [ 8822], size: 8 } hitcount: 2 + { common_pid: firefox [ 8822], size: 160 } hitcount: 2 + { common_pid: firefox [ 8822], size: 320 } hitcount: 2 + { common_pid: firefox [ 8822], size: 352 } hitcount: 1 + . + . + . + { common_pid: pool [ 8923], size: 1960 } hitcount: 10 + { common_pid: pool [ 8923], size: 2048 } hitcount: 10 + { common_pid: pool [ 8924], size: 1960 } hitcount: 10 + { common_pid: pool [ 8924], size: 2048 } hitcount: 10 + { common_pid: pool [ 8928], size: 1964 } hitcount: 4 + { common_pid: pool [ 8928], size: 1965 } hitcount: 2 + { common_pid: pool [ 8928], size: 2048 } hitcount: 6 + { common_pid: pool [ 8929], size: 1982 } hitcount: 1 + { common_pid: pool [ 8929], size: 2048 } hitcount: 1 + + Totals: + Hits: 2016 + Entries: 224 + Dropped: 0 The above example also illustrates the fact that although a compound key is treated as a single entity for hashing purposes, the sub-keys @@ -1354,7 +1357,7 @@ The following commands are supported: demonstrates how you can manually pause and continue a hist trigger. In this example, we'll aggregate fork counts and don't expect a large number of entries in the hash table, so we'll drop it to a - much smaller number, say 256: + much smaller number, say 256:: # echo 'hist:key=child_comm:val=hitcount:size=256' > \ /sys/kernel/debug/tracing/events/sched/sched_process_fork/trigger @@ -1390,7 +1393,7 @@ The following commands are supported: If we want to pause the hist trigger, we can simply append :pause to the command that started the trigger. Notice that the trigger info - displays as [paused]: + displays as [paused]:: # echo 'hist:key=child_comm:val=hitcount:size=256:pause' >> \ /sys/kernel/debug/tracing/events/sched/sched_process_fork/trigger @@ -1427,7 +1430,7 @@ The following commands are supported: To manually continue having the trigger aggregate events, append :cont instead. Notice that the trigger info displays as [active] - again, and the data has changed: + again, and the data has changed:: # echo 'hist:key=child_comm:val=hitcount:size=256:cont' >> \ /sys/kernel/debug/tracing/events/sched/sched_process_fork/trigger @@ -1481,7 +1484,7 @@ The following commands are supported: wget. First we set up an initially paused stacktrace trigger on the - netif_receive_skb event: + netif_receive_skb event:: # echo 'hist:key=stacktrace:vals=len:pause' > \ /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger @@ -1492,7 +1495,7 @@ The following commands are supported: set up on netif_receive_skb if and only if it sees a sched_process_exec event with a filename of '/usr/bin/wget'. When that happens, all netif_receive_skb events are aggregated into a - hash table keyed on stacktrace: + hash table keyed on stacktrace:: # echo 'enable_hist:net:netif_receive_skb if filename==/usr/bin/wget' > \ /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger @@ -1500,7 +1503,7 @@ The following commands are supported: The aggregation continues until the netif_receive_skb is paused again, which is what the following disable_hist event does by creating a similar setup on the sched_process_exit event, using the - filter 'comm==wget': + filter 'comm==wget':: # echo 'disable_hist:net:netif_receive_skb if comm==wget' > \ /sys/kernel/debug/tracing/events/sched/sched_process_exit/trigger @@ -1512,7 +1515,7 @@ The following commands are supported: The overall effect is that netif_receive_skb events are aggregated into the hash table for only the duration of the wget. Executing a wget command and then listing the 'hist' file will display the - output generated by the wget command: + output generated by the wget command:: $ wget https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.19.xz @@ -1597,13 +1600,13 @@ The following commands are supported: Suppose we wanted to try another run of the previous example but this time also wanted to see the complete list of events that went into the histogram. In order to avoid having to set everything up - again, we can just clear the histogram first: + again, we can just clear the histogram first:: # echo 'hist:key=stacktrace:vals=len:clear' >> \ /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger Just to verify that it is in fact cleared, here's what we now see in - the hist file: + the hist file:: # cat /sys/kernel/debug/tracing/events/net/netif_receive_skb/hist # trigger info: hist:keys=stacktrace:vals=len:sort=hitcount:size=2048 [paused] @@ -1617,7 +1620,7 @@ The following commands are supported: event occurring during the new run, which are in fact the same events being aggregated into the hash table, we add some additional 'enable_event' events to the triggering sched_process_exec and - sched_process_exit events as such: + sched_process_exit events as such:: # echo 'enable_event:net:netif_receive_skb if filename==/usr/bin/wget' > \ /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger @@ -1628,7 +1631,7 @@ The following commands are supported: If you read the trigger files for the sched_process_exec and sched_process_exit triggers, you should see two triggers for each: one enabling/disabling the hist aggregation and the other - enabling/disabling the logging of events: + enabling/disabling the logging of events:: # cat /sys/kernel/debug/tracing/events/sched/sched_process_exec/trigger enable_event:net:netif_receive_skb:unlimited if filename==/usr/bin/wget @@ -1642,13 +1645,13 @@ The following commands are supported: sched_process_exit events is hit and matches 'wget', it enables or disables both the histogram and the event log, and what you end up with is a hash table and set of events just covering the specified - duration. Run the wget command again: + duration. Run the wget command again:: $ wget https://www.kernel.org/pub/linux/kernel/v3.x/patch-3.19.xz Displaying the 'hist' file should show something similar to what you saw in the last run, but this time you should also see the - individual events in the trace file: + individual events in the trace file:: # cat /sys/kernel/debug/tracing/trace @@ -1673,15 +1676,15 @@ The following commands are supported: irq/29-iwlwifi-559 [002] ..s. 31772.032196: netif_receive_skb: dev=wlan0 skbaddr=ffff88009d433100 len=2948 irq/29-iwlwifi-559 [002] ..s. 31772.032761: netif_receive_skb: dev=wlan0 skbaddr=ffff88009d433000 len=2948 irq/29-iwlwifi-559 [002] ..s. 31772.033220: netif_receive_skb: dev=wlan0 skbaddr=ffff88009d432e00 len=1500 - . - . - . + .... + The following example demonstrates how multiple hist triggers can be attached to a given event. This capability can be useful for creating a set of different summaries derived from the same set of events, or for comparing the effects of different filters, among other things. + :: # echo 'hist:keys=skbaddr.hex:vals=len if len < 0' >> \ /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger @@ -1702,7 +1705,7 @@ The following commands are supported: any existing hist triggers beforehand). Displaying the contents of the 'hist' file for the event shows the - contents of all five histograms: + contents of all five histograms:: # cat /sys/kernel/debug/tracing/events/net/netif_receive_skb/hist @@ -1822,7 +1825,7 @@ The following commands are supported: output of events generated by tracepoints contained inside inline functions, but names can be used in a hist trigger on any event. For example, these two triggers when hit will update the same 'len' - field in the shared 'foo' histogram data: + field in the shared 'foo' histogram data:: # echo 'hist:name=foo:keys=skbaddr.hex:vals=len' > \ /sys/kernel/debug/tracing/events/net/netif_receive_skb/trigger @@ -1830,7 +1833,7 @@ The following commands are supported: /sys/kernel/debug/tracing/events/net/netif_rx/trigger You can see that they're updating common histogram data by reading - each event's hist files at the same time: + each event's hist files at the same time:: # cat /sys/kernel/debug/tracing/events/net/netif_receive_skb/hist; cat /sys/kernel/debug/tracing/events/net/netif_rx/hist @@ -1943,7 +1946,7 @@ The following commands are supported: And here's an example that shows how to combine histogram data from any two events even if they don't share any 'compatible' fields other than 'hitcount' and 'stacktrace'. These commands create a - couple of triggers named 'bar' using those fields: + couple of triggers named 'bar' using those fields:: # echo 'hist:name=bar:key=stacktrace:val=hitcount' > \ /sys/kernel/debug/tracing/events/sched/sched_process_fork/trigger @@ -1951,7 +1954,7 @@ The following commands are supported: /sys/kernel/debug/tracing/events/net/netif_rx/trigger And displaying the output of either shows some interesting if - somewhat confusing output: + somewhat confusing output:: # cat /sys/kernel/debug/tracing/events/sched/sched_process_fork/hist # cat /sys/kernel/debug/tracing/events/net/netif_rx/hist diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.rst index a273dd0..a8e22e0 100644 --- a/Documentation/trace/ftrace-design.txt +++ b/Documentation/trace/ftrace-design.rst @@ -1,6 +1,12 @@ - function tracer guts - ==================== - By Mike Frysinger +====================== +Function Tracer Design +====================== + +:Author: Mike Frysinger + +.. caution:: + This document is out of date. Some of the description below doesn't + match current implementation now. Introduction ------------ @@ -21,8 +27,8 @@ Prerequisites ------------- Ftrace relies on these features being implemented: - STACKTRACE_SUPPORT - implement save_stack_trace() - TRACE_IRQFLAGS_SUPPORT - implement include/asm/irqflags.h + - STACKTRACE_SUPPORT - implement save_stack_trace() + - TRACE_IRQFLAGS_SUPPORT - implement include/asm/irqflags.h HAVE_FUNCTION_TRACER @@ -32,9 +38,11 @@ You will need to implement the mcount and the ftrace_stub functions. The exact mcount symbol name will depend on your toolchain. Some call it "mcount", "_mcount", or even "__mcount". You can probably figure it out by -running something like: +running something like:: + $ echo 'main(){}' | gcc -x c -S -o - - -pg | grep mcount call mcount + We'll make the assumption below that the symbol is "mcount" just to keep things nice and simple in the examples. @@ -56,8 +64,9 @@ size of the mcount call that is embedded in the function). For example, if the function foo() calls bar(), when the bar() function calls mcount(), the arguments mcount() will pass to the tracer are: - "frompc" - the address bar() will use to return to foo() - "selfpc" - the address bar() (with mcount() size adjustment) + + - "frompc" - the address bar() will use to return to foo() + - "selfpc" - the address bar() (with mcount() size adjustment) Also keep in mind that this mcount function will be called *a lot*, so optimizing for the default case of no tracer will help the smooth running of @@ -67,39 +76,41 @@ means the code flow should usually be kept linear (i.e. no branching in the nop case). This is of course an optimization and not a hard requirement. Here is some pseudo code that should help (these functions should actually be -implemented in assembly): +implemented in assembly):: -void ftrace_stub(void) -{ - return; -} + void ftrace_stub(void) + { + return; + } -void mcount(void) -{ - /* save any bare state needed in order to do initial checking */ + void mcount(void) + { + /* save any bare state needed in order to do initial checking */ - extern void (*ftrace_trace_function)(unsigned long, unsigned long); - if (ftrace_trace_function != ftrace_stub) - goto do_trace; + extern void (*ftrace_trace_function)(unsigned long, unsigned long); + if (ftrace_trace_function != ftrace_stub) + goto do_trace; - /* restore any bare state */ + /* restore any bare state */ - return; + return; -do_trace: + do_trace: - /* save all state needed by the ABI (see paragraph above) */ + /* save all state needed by the ABI (see paragraph above) */ - unsigned long frompc = ...; - unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; - ftrace_trace_function(frompc, selfpc); + unsigned long frompc = ...; + unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; + ftrace_trace_function(frompc, selfpc); - /* restore all state needed by the ABI */ -} + /* restore all state needed by the ABI */ + } Don't forget to export mcount for modules ! -extern void mcount(void); -EXPORT_SYMBOL(mcount); +:: + + extern void mcount(void); + EXPORT_SYMBOL(mcount); HAVE_FUNCTION_GRAPH_TRACER @@ -127,38 +138,40 @@ That function will simply call the common ftrace_return_to_handler function and that will return the original return address with which you can return to the original call site. -Here is the updated mcount pseudo code: -void mcount(void) -{ -... - if (ftrace_trace_function != ftrace_stub) - goto do_trace; - -+#ifdef CONFIG_FUNCTION_GRAPH_TRACER -+ extern void (*ftrace_graph_return)(...); -+ extern void (*ftrace_graph_entry)(...); -+ if (ftrace_graph_return != ftrace_stub || -+ ftrace_graph_entry != ftrace_graph_entry_stub) -+ ftrace_graph_caller(); -+#endif - - /* restore any bare state */ -... - -Here is the pseudo code for the new ftrace_graph_caller assembly function: -#ifdef CONFIG_FUNCTION_GRAPH_TRACER -void ftrace_graph_caller(void) -{ - /* save all state needed by the ABI */ - - unsigned long *frompc = &...; - unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; - /* passing frame pointer up is optional -- see below */ - prepare_ftrace_return(frompc, selfpc, frame_pointer); - - /* restore all state needed by the ABI */ -} -#endif +Here is the updated mcount pseudo code:: + + void mcount(void) + { + ... + if (ftrace_trace_function != ftrace_stub) + goto do_trace; + + +#ifdef CONFIG_FUNCTION_GRAPH_TRACER + + extern void (*ftrace_graph_return)(...); + + extern void (*ftrace_graph_entry)(...); + + if (ftrace_graph_return != ftrace_stub || + + ftrace_graph_entry != ftrace_graph_entry_stub) + + ftrace_graph_caller(); + +#endif + + /* restore any bare state */ + ... + +Here is the pseudo code for the new ftrace_graph_caller assembly function:: + + #ifdef CONFIG_FUNCTION_GRAPH_TRACER + void ftrace_graph_caller(void) + { + /* save all state needed by the ABI */ + + unsigned long *frompc = &...; + unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; + /* passing frame pointer up is optional -- see below */ + prepare_ftrace_return(frompc, selfpc, frame_pointer); + + /* restore all state needed by the ABI */ + } + #endif For information on how to implement prepare_ftrace_return(), simply look at the x86 version (the frame pointer passing is optional; see the next section for @@ -171,20 +184,21 @@ that the ABI that applies here is different from what applies to the mcount code. Since you are returning from a function (after the epilogue), you might be able to skimp on things saved/restored (usually just registers used to pass return values). +:: -#ifdef CONFIG_FUNCTION_GRAPH_TRACER -void return_to_handler(void) -{ - /* save all state needed by the ABI (see paragraph above) */ + #ifdef CONFIG_FUNCTION_GRAPH_TRACER + void return_to_handler(void) + { + /* save all state needed by the ABI (see paragraph above) */ - void (*original_return_point)(void) = ftrace_return_to_handler(); + void (*original_return_point)(void) = ftrace_return_to_handler(); - /* restore all state needed by the ABI */ + /* restore all state needed by the ABI */ - /* this is usually either a return or a jump */ - original_return_point(); -} -#endif + /* this is usually either a return or a jump */ + original_return_point(); + } + #endif HAVE_FUNCTION_GRAPH_FP_TEST @@ -228,20 +242,20 @@ HAVE_SYSCALL_TRACEPOINTS You need very few things to get the syscalls tracing in an arch. -- Support HAVE_ARCH_TRACEHOOK (see arch/Kconfig). -- Have a NR_syscalls variable in <asm/unistd.h> that provides the number - of syscalls supported by the arch. -- Support the TIF_SYSCALL_TRACEPOINT thread flags. -- Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace - in the ptrace syscalls tracing path. -- If the system call table on this arch is more complicated than a simple array - of addresses of the system calls, implement an arch_syscall_addr to return - the address of a given system call. -- If the symbol names of the system calls do not match the function names on - this arch, define ARCH_HAS_SYSCALL_MATCH_SYM_NAME in asm/ftrace.h and - implement arch_syscall_match_sym_name with the appropriate logic to return - true if the function name corresponds with the symbol name. -- Tag this arch as HAVE_SYSCALL_TRACEPOINTS. + - Support HAVE_ARCH_TRACEHOOK (see arch/Kconfig). + - Have a NR_syscalls variable in <asm/unistd.h> that provides the number + of syscalls supported by the arch. + - Support the TIF_SYSCALL_TRACEPOINT thread flags. + - Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace + in the ptrace syscalls tracing path. + - If the system call table on this arch is more complicated than a simple array + of addresses of the system calls, implement an arch_syscall_addr to return + the address of a given system call. + - If the symbol names of the system calls do not match the function names on + this arch, define ARCH_HAS_SYSCALL_MATCH_SYM_NAME in asm/ftrace.h and + implement arch_syscall_match_sym_name with the appropriate logic to return + true if the function name corresponds with the symbol name. + - Tag this arch as HAVE_SYSCALL_TRACEPOINTS. HAVE_FTRACE_MCOUNT_RECORD @@ -276,22 +290,28 @@ Once those are out of the way, you will need to implement: First you will need to fill out some arch details in your asm/ftrace.h. -Define MCOUNT_ADDR as the address of your mcount symbol similar to: +Define MCOUNT_ADDR as the address of your mcount symbol similar to:: + #define MCOUNT_ADDR ((unsigned long)mcount) -Since no one else will have a decl for that function, you will need to: + +Since no one else will have a decl for that function, you will need to:: + extern void mcount(void); You will also need the helper function ftrace_call_adjust(). Most people -will be able to stub it out like so: +will be able to stub it out like so:: + static inline unsigned long ftrace_call_adjust(unsigned long addr) { return addr; } + <details to be filled> Lastly you will need the custom dyn_arch_ftrace structure. If you need some extra state when runtime patching arbitrary call sites, this is the -place. For now though, create an empty struct: +place. For now though, create an empty struct:: + struct dyn_arch_ftrace { /* No extra data needed */ }; @@ -306,28 +326,28 @@ easier to have two separate definitions split up by #ifdefs. Same goes for the ftrace_stub() as that will now be inlined in ftrace_caller(). Before we get confused anymore, let's check out some pseudo code so you can -implement your own stuff in assembly: +implement your own stuff in assembly:: -void mcount(void) -{ - return; -} + void mcount(void) + { + return; + } -void ftrace_caller(void) -{ - /* save all state needed by the ABI (see paragraph above) */ + void ftrace_caller(void) + { + /* save all state needed by the ABI (see paragraph above) */ - unsigned long frompc = ...; - unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; + unsigned long frompc = ...; + unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; -ftrace_call: - ftrace_stub(frompc, selfpc); + ftrace_call: + ftrace_stub(frompc, selfpc); - /* restore all state needed by the ABI */ + /* restore all state needed by the ABI */ -ftrace_stub: - return; -} + ftrace_stub: + return; + } This might look a little odd at first, but keep in mind that we will be runtime patching multiple things. First, only functions that we actually want to trace @@ -341,21 +361,23 @@ order to make it through the next section. Every arch has an init callback function. If you need to do something early on to initialize some state, this is the time to do that. Otherwise, this simple -function below should be sufficient for most people: +function below should be sufficient for most people:: -int __init ftrace_dyn_arch_init(void) -{ - return 0; -} + int __init ftrace_dyn_arch_init(void) + { + return 0; + } There are two functions that are used to do runtime patching of arbitrary functions. The first is used to turn the mcount call site into a nop (which is what helps us retain runtime performance when not tracing). The second is used to turn the mcount call site into a call to an arbitrary location (but typically that is ftracer_caller()). See the general function definition in -linux/ftrace.h for the functions: +linux/ftrace.h for the functions:: + ftrace_make_nop() ftrace_make_call() + The rec->ip value is the address of the mcount call site that was collected by the scripts/recordmcount.pl during build time. @@ -364,7 +386,8 @@ will be modifying the assembly code at the location of the ftrace_call symbol inside of the ftrace_caller() function. So you should have sufficient padding at that location to support the new function calls you'll be inserting. Some people will be using a "call" type instruction while others will be using a -"branch" type instruction. Specifically, the function is: +"branch" type instruction. Specifically, the function is:: + ftrace_update_ftrace_func() @@ -373,6 +396,7 @@ HAVE_DYNAMIC_FTRACE + HAVE_FUNCTION_GRAPH_TRACER The function grapher needs a few tweaks in order to work with dynamic ftrace. Basically, you will need to: + - update: - ftrace_caller() - ftrace_graph_call() @@ -382,7 +406,9 @@ Basically, you will need to: - ftrace_disable_ftrace_graph_caller() <details to be filled> + Quick notes: + - add a nop stub after the ftrace_call location named ftrace_graph_call; stub needs to be large enough to support a call to ftrace_graph_caller() - update ftrace_graph_caller() to work with being called by the new diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst index 3aed560..998a60a 100644 --- a/Documentation/trace/ftrace-uses.rst +++ b/Documentation/trace/ftrace-uses.rst @@ -21,13 +21,14 @@ how to use ftrace to implement your own function callbacks. The ftrace context ================== +.. warning:: -WARNING: The ability to add a callback to almost any function within the -kernel comes with risks. A callback can be called from any context -(normal, softirq, irq, and NMI). Callbacks can also be called just before -going to idle, during CPU bring up and takedown, or going to user space. -This requires extra care to what can be done inside a callback. A callback -can be called outside the protective scope of RCU. + The ability to add a callback to almost any function within the + kernel comes with risks. A callback can be called from any context + (normal, softirq, irq, and NMI). Callbacks can also be called just before + going to idle, during CPU bring up and takedown, or going to user space. + This requires extra care to what can be done inside a callback. A callback + can be called outside the protective scope of RCU. The ftrace infrastructure has some protections agains recursions and RCU but one must still be very careful how they use the callbacks. @@ -54,15 +55,15 @@ an ftrace_ops with ftrace: Both .flags and .private are optional. Only .func is required. -To enable tracing call:: +To enable tracing call: .. c:function:: register_ftrace_function(&ops); -To disable tracing call:: +To disable tracing call: .. c:function:: unregister_ftrace_function(&ops); -The above is defined by including the header:: +The above is defined by including the header: .. c:function:: #include <linux/ftrace.h> @@ -200,7 +201,7 @@ match a specific pattern. See Filter Commands in :file:`Documentation/trace/ftrace.txt`. -To just trace the schedule function:: +To just trace the schedule function: .. code-block:: c @@ -210,7 +211,7 @@ To add more functions, call the ftrace_set_filter() more than once with the @reset parameter set to zero. To remove the current filter set and replace it with new functions defined by @buf, have @reset be non-zero. -To remove all the filtered functions and trace all functions:: +To remove all the filtered functions and trace all functions: .. code-block:: c diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst new file mode 100644 index 0000000..fdf5fb5 --- /dev/null +++ b/Documentation/trace/ftrace.rst @@ -0,0 +1,3324 @@ +======================== +ftrace - Function Tracer +======================== + +Copyright 2008 Red Hat Inc. + +:Author: Steven Rostedt <srostedt@redhat.com> +:License: The GNU Free Documentation License, Version 1.2 + (dual licensed under the GPL v2) +:Original Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton, + John Kacur, and David Teigland. + +- Written for: 2.6.28-rc2 +- Updated for: 3.10 +- Updated for: 4.13 - Copyright 2017 VMware Inc. Steven Rostedt +- Converted to rst format - Changbin Du <changbin.du@intel.com> + +Introduction +------------ + +Ftrace is an internal tracer designed to help out developers and +designers of systems to find what is going on inside the kernel. +It can be used for debugging or analyzing latencies and +performance issues that take place outside of user-space. + +Although ftrace is typically considered the function tracer, it +is really a frame work of several assorted tracing utilities. +There's latency tracing to examine what occurs between interrupts +disabled and enabled, as well as for preemption and from a time +a task is woken to the task is actually scheduled in. + +One of the most common uses of ftrace is the event tracing. +Through out the kernel is hundreds of static event points that +can be enabled via the tracefs file system to see what is +going on in certain parts of the kernel. + +See events.txt for more information. + + +Implementation Details +---------------------- + +See :doc:`ftrace-design` for details for arch porters and such. + + +The File System +--------------- + +Ftrace uses the tracefs file system to hold the control files as +well as the files to display output. + +When tracefs is configured into the kernel (which selecting any ftrace +option will do) the directory /sys/kernel/tracing will be created. To mount +this directory, you can add to your /etc/fstab file:: + + tracefs /sys/kernel/tracing tracefs defaults 0 0 + +Or you can mount it at run time with:: + + mount -t tracefs nodev /sys/kernel/tracing + +For quicker access to that directory you may want to make a soft link to +it:: + + ln -s /sys/kernel/tracing /tracing + +.. attention:: + + Before 4.1, all ftrace tracing control files were within the debugfs + file system, which is typically located at /sys/kernel/debug/tracing. + For backward compatibility, when mounting the debugfs file system, + the tracefs file system will be automatically mounted at: + + /sys/kernel/debug/tracing + + All files located in the tracefs file system will be located in that + debugfs file system directory as well. + +.. attention:: + + Any selected ftrace option will also create the tracefs file system. + The rest of the document will assume that you are in the ftrace directory + (cd /sys/kernel/tracing) and will only concentrate on the files within that + directory and not distract from the content with the extended + "/sys/kernel/tracing" path name. + +That's it! (assuming that you have ftrace configured into your kernel) + +After mounting tracefs you will have access to the control and output files +of ftrace. Here is a list of some of the key files: + + + Note: all time values are in microseconds. + + current_tracer: + + This is used to set or display the current tracer + that is configured. + + available_tracers: + + This holds the different types of tracers that + have been compiled into the kernel. The + tracers listed here can be configured by + echoing their name into current_tracer. + + tracing_on: + + This sets or displays whether writing to the trace + ring buffer is enabled. Echo 0 into this file to disable + the tracer or 1 to enable it. Note, this only disables + writing to the ring buffer, the tracing overhead may + still be occurring. + + The kernel function tracing_off() can be used within the + kernel to disable writing to the ring buffer, which will + set this file to "0". User space can re-enable tracing by + echoing "1" into the file. + + Note, the function and event trigger "traceoff" will also + set this file to zero and stop tracing. Which can also + be re-enabled by user space using this file. + + trace: + + This file holds the output of the trace in a human + readable format (described below). Note, tracing is temporarily + disabled while this file is being read (opened). + + trace_pipe: + + The output is the same as the "trace" file but this + file is meant to be streamed with live tracing. + Reads from this file will block until new data is + retrieved. Unlike the "trace" file, this file is a + consumer. This means reading from this file causes + sequential reads to display more current data. Once + data is read from this file, it is consumed, and + will not be read again with a sequential read. The + "trace" file is static, and if the tracer is not + adding more data, it will display the same + information every time it is read. This file will not + disable tracing while being read. + + trace_options: + + This file lets the user control the amount of data + that is displayed in one of the above output + files. Options also exist to modify how a tracer + or events work (stack traces, timestamps, etc). + + options: + + This is a directory that has a file for every available + trace option (also in trace_options). Options may also be set + or cleared by writing a "1" or "0" respectively into the + corresponding file with the option name. + + tracing_max_latency: + + Some of the tracers record the max latency. + For example, the maximum time that interrupts are disabled. + The maximum time is saved in this file. The max trace will also be + stored, and displayed by "trace". A new max trace will only be + recorded if the latency is greater than the value in this file + (in microseconds). + + By echoing in a time into this file, no latency will be recorded + unless it is greater than the time in this file. + + tracing_thresh: + + Some latency tracers will record a trace whenever the + latency is greater than the number in this file. + Only active when the file contains a number greater than 0. + (in microseconds) + + buffer_size_kb: + + This sets or displays the number of kilobytes each CPU + buffer holds. By default, the trace buffers are the same size + for each CPU. The displayed number is the size of the + CPU buffer and not total size of all buffers. The + trace buffers are allocated in pages (blocks of memory + that the kernel uses for allocation, usually 4 KB in size). + If the last page allocated has room for more bytes + than requested, the rest of the page will be used, + making the actual allocation bigger than requested or shown. + ( Note, the size may not be a multiple of the page size + due to buffer management meta-data. ) + + Buffer sizes for individual CPUs may vary + (see "per_cpu/cpu0/buffer_size_kb" below), and if they do + this file will show "X". + + buffer_total_size_kb: + + This displays the total combined size of all the trace buffers. + + free_buffer: + + If a process is performing tracing, and the ring buffer should be + shrunk "freed" when the process is finished, even if it were to be + killed by a signal, this file can be used for that purpose. On close + of this file, the ring buffer will be resized to its minimum size. + Having a process that is tracing also open this file, when the process + exits its file descriptor for this file will be closed, and in doing so, + the ring buffer will be "freed". + + It may also stop tracing if disable_on_free option is set. + + tracing_cpumask: + + This is a mask that lets the user only trace on specified CPUs. + The format is a hex string representing the CPUs. + + set_ftrace_filter: + + When dynamic ftrace is configured in (see the + section below "dynamic ftrace"), the code is dynamically + modified (code text rewrite) to disable calling of the + function profiler (mcount). This lets tracing be configured + in with practically no overhead in performance. This also + has a side effect of enabling or disabling specific functions + to be traced. Echoing names of functions into this file + will limit the trace to only those functions. + + The functions listed in "available_filter_functions" are what + can be written into this file. + + This interface also allows for commands to be used. See the + "Filter commands" section for more details. + + set_ftrace_notrace: + + This has an effect opposite to that of + set_ftrace_filter. Any function that is added here will not + be traced. If a function exists in both set_ftrace_filter + and set_ftrace_notrace, the function will _not_ be traced. + + set_ftrace_pid: + + Have the function tracer only trace the threads whose PID are + listed in this file. + + If the "function-fork" option is set, then when a task whose + PID is listed in this file forks, the child's PID will + automatically be added to this file, and the child will be + traced by the function tracer as well. This option will also + cause PIDs of tasks that exit to be removed from the file. + + set_event_pid: + + Have the events only trace a task with a PID listed in this file. + Note, sched_switch and sched_wake_up will also trace events + listed in this file. + + To have the PIDs of children of tasks with their PID in this file + added on fork, enable the "event-fork" option. That option will also + cause the PIDs of tasks to be removed from this file when the task + exits. + + set_graph_function: + + Functions listed in this file will cause the function graph + tracer to only trace these functions and the functions that + they call. (See the section "dynamic ftrace" for more details). + + set_graph_notrace: + + Similar to set_graph_function, but will disable function graph + tracing when the function is hit until it exits the function. + This makes it possible to ignore tracing functions that are called + by a specific function. + + available_filter_functions: + + This lists the functions that ftrace has processed and can trace. + These are the function names that you can pass to + "set_ftrace_filter" or "set_ftrace_notrace". + (See the section "dynamic ftrace" below for more details.) + + dyn_ftrace_total_info: + + This file is for debugging purposes. The number of functions that + have been converted to nops and are available to be traced. + + enabled_functions: + + This file is more for debugging ftrace, but can also be useful + in seeing if any function has a callback attached to it. + Not only does the trace infrastructure use ftrace function + trace utility, but other subsystems might too. This file + displays all functions that have a callback attached to them + as well as the number of callbacks that have been attached. + Note, a callback may also call multiple functions which will + not be listed in this count. + + If the callback registered to be traced by a function with + the "save regs" attribute (thus even more overhead), a 'R' + will be displayed on the same line as the function that + is returning registers. + + If the callback registered to be traced by a function with + the "ip modify" attribute (thus the regs->ip can be changed), + an 'I' will be displayed on the same line as the function that + can be overridden. + + If the architecture supports it, it will also show what callback + is being directly called by the function. If the count is greater + than 1 it most likely will be ftrace_ops_list_func(). + + If the callback of the function jumps to a trampoline that is + specific to a the callback and not the standard trampoline, + its address will be printed as well as the function that the + trampoline calls. + + function_profile_enabled: + + When set it will enable all functions with either the function + tracer, or if configured, the function graph tracer. It will + keep a histogram of the number of functions that were called + and if the function graph tracer was configured, it will also keep + track of the time spent in those functions. The histogram + content can be displayed in the files: + + trace_stats/function<cpu> ( function0, function1, etc). + + trace_stats: + + A directory that holds different tracing stats. + + kprobe_events: + + Enable dynamic trace points. See kprobetrace.txt. + + kprobe_profile: + + Dynamic trace points stats. See kprobetrace.txt. + + max_graph_depth: + + Used with the function graph tracer. This is the max depth + it will trace into a function. Setting this to a value of + one will show only the first kernel function that is called + from user space. + + printk_formats: + + This is for tools that read the raw format files. If an event in + the ring buffer references a string, only a pointer to the string + is recorded into the buffer and not the string itself. This prevents + tools from knowing what that string was. This file displays the string + and address for the string allowing tools to map the pointers to what + the strings were. + + saved_cmdlines: + + Only the pid of the task is recorded in a trace event unless + the event specifically saves the task comm as well. Ftrace + makes a cache of pid mappings to comms to try to display + comms for events. If a pid for a comm is not listed, then + "<...>" is displayed in the output. + + If the option "record-cmd" is set to "0", then comms of tasks + will not be saved during recording. By default, it is enabled. + + saved_cmdlines_size: + + By default, 128 comms are saved (see "saved_cmdlines" above). To + increase or decrease the amount of comms that are cached, echo + in a the number of comms to cache, into this file. + + saved_tgids: + + If the option "record-tgid" is set, on each scheduling context switch + the Task Group ID of a task is saved in a table mapping the PID of + the thread to its TGID. By default, the "record-tgid" option is + disabled. + + snapshot: + + This displays the "snapshot" buffer and also lets the user + take a snapshot of the current running trace. + See the "Snapshot" section below for more details. + + stack_max_size: + + When the stack tracer is activated, this will display the + maximum stack size it has encountered. + See the "Stack Trace" section below. + + stack_trace: + + This displays the stack back trace of the largest stack + that was encountered when the stack tracer is activated. + See the "Stack Trace" section below. + + stack_trace_filter: + + This is similar to "set_ftrace_filter" but it limits what + functions the stack tracer will check. + + trace_clock: + + Whenever an event is recorded into the ring buffer, a + "timestamp" is added. This stamp comes from a specified + clock. By default, ftrace uses the "local" clock. This + clock is very fast and strictly per cpu, but on some + systems it may not be monotonic with respect to other + CPUs. In other words, the local clocks may not be in sync + with local clocks on other CPUs. + + Usual clocks for tracing:: + + # cat trace_clock + [local] global counter x86-tsc + + The clock with the square brackets around it is the one in effect. + + local: + Default clock, but may not be in sync across CPUs + + global: + This clock is in sync with all CPUs but may + be a bit slower than the local clock. + + counter: + This is not a clock at all, but literally an atomic + counter. It counts up one by one, but is in sync + with all CPUs. This is useful when you need to + know exactly the order events occurred with respect to + each other on different CPUs. + + uptime: + This uses the jiffies counter and the time stamp + is relative to the time since boot up. + + perf: + This makes ftrace use the same clock that perf uses. + Eventually perf will be able to read ftrace buffers + and this will help out in interleaving the data. + + x86-tsc: + Architectures may define their own clocks. For + example, x86 uses its own TSC cycle clock here. + + ppc-tb: + This uses the powerpc timebase register value. + This is in sync across CPUs and can also be used + to correlate events across hypervisor/guest if + tb_offset is known. + + mono: + This uses the fast monotonic clock (CLOCK_MONOTONIC) + which is monotonic and is subject to NTP rate adjustments. + + mono_raw: + This is the raw monotonic clock (CLOCK_MONOTONIC_RAW) + which is montonic but is not subject to any rate adjustments + and ticks at the same rate as the hardware clocksource. + + boot: + Same as mono. Used to be a separate clock which accounted + for the time spent in suspend while CLOCK_MONOTONIC did + not. + + To set a clock, simply echo the clock name into this file:: + + # echo global > trace_clock + + trace_marker: + + This is a very useful file for synchronizing user space + with events happening in the kernel. Writing strings into + this file will be written into the ftrace buffer. + + It is useful in applications to open this file at the start + of the application and just reference the file descriptor + for the file:: + + void trace_write(const char *fmt, ...) + { + va_list ap; + char buf[256]; + int n; + + if (trace_fd < 0) + return; + + va_start(ap, fmt); + n = vsnprintf(buf, 256, fmt, ap); + va_end(ap); + + write(trace_fd, buf, n); + } + + start:: + + trace_fd = open("trace_marker", WR_ONLY); + + trace_marker_raw: + + This is similar to trace_marker above, but is meant for for binary data + to be written to it, where a tool can be used to parse the data + from trace_pipe_raw. + + uprobe_events: + + Add dynamic tracepoints in programs. + See uprobetracer.txt + + uprobe_profile: + + Uprobe statistics. See uprobetrace.txt + + instances: + + This is a way to make multiple trace buffers where different + events can be recorded in different buffers. + See "Instances" section below. + + events: + + This is the trace event directory. It holds event tracepoints + (also known as static tracepoints) that have been compiled + into the kernel. It shows what event tracepoints exist + and how they are grouped by system. There are "enable" + files at various levels that can enable the tracepoints + when a "1" is written to them. + + See events.txt for more information. + + set_event: + + By echoing in the event into this file, will enable that event. + + See events.txt for more information. + + available_events: + + A list of events that can be enabled in tracing. + + See events.txt for more information. + + hwlat_detector: + + Directory for the Hardware Latency Detector. + See "Hardware Latency Detector" section below. + + per_cpu: + + This is a directory that contains the trace per_cpu information. + + per_cpu/cpu0/buffer_size_kb: + + The ftrace buffer is defined per_cpu. That is, there's a separate + buffer for each CPU to allow writes to be done atomically, + and free from cache bouncing. These buffers may have different + size buffers. This file is similar to the buffer_size_kb + file, but it only displays or sets the buffer size for the + specific CPU. (here cpu0). + + per_cpu/cpu0/trace: + + This is similar to the "trace" file, but it will only display + the data specific for the CPU. If written to, it only clears + the specific CPU buffer. + + per_cpu/cpu0/trace_pipe + + This is similar to the "trace_pipe" file, and is a consuming + read, but it will only display (and consume) the data specific + for the CPU. + + per_cpu/cpu0/trace_pipe_raw + + For tools that can parse the ftrace ring buffer binary format, + the trace_pipe_raw file can be used to extract the data + from the ring buffer directly. With the use of the splice() + system call, the buffer data can be quickly transferred to + a file or to the network where a server is collecting the + data. + + Like trace_pipe, this is a consuming reader, where multiple + reads will always produce different data. + + per_cpu/cpu0/snapshot: + + This is similar to the main "snapshot" file, but will only + snapshot the current CPU (if supported). It only displays + the content of the snapshot for a given CPU, and if + written to, only clears this CPU buffer. + + per_cpu/cpu0/snapshot_raw: + + Similar to the trace_pipe_raw, but will read the binary format + from the snapshot buffer for the given CPU. + + per_cpu/cpu0/stats: + + This displays certain stats about the ring buffer: + + entries: + The number of events that are still in the buffer. + + overrun: + The number of lost events due to overwriting when + the buffer was full. + + commit overrun: + Should always be zero. + This gets set if so many events happened within a nested + event (ring buffer is re-entrant), that it fills the + buffer and starts dropping events. + + bytes: + Bytes actually read (not overwritten). + + oldest event ts: + The oldest timestamp in the buffer + + now ts: + The current timestamp + + dropped events: + Events lost due to overwrite option being off. + + read events: + The number of events read. + +The Tracers +----------- + +Here is the list of current tracers that may be configured. + + "function" + + Function call tracer to trace all kernel functions. + + "function_graph" + + Similar to the function tracer except that the + function tracer probes the functions on their entry + whereas the function graph tracer traces on both entry + and exit of the functions. It then provides the ability + to draw a graph of function calls similar to C code + source. + + "blk" + + The block tracer. The tracer used by the blktrace user + application. + + "hwlat" + + The Hardware Latency tracer is used to detect if the hardware + produces any latency. See "Hardware Latency Detector" section + below. + + "irqsoff" + + Traces the areas that disable interrupts and saves + the trace with the longest max latency. + See tracing_max_latency. When a new max is recorded, + it replaces the old trace. It is best to view this + trace with the latency-format option enabled, which + happens automatically when the tracer is selected. + + "preemptoff" + + Similar to irqsoff but traces and records the amount of + time for which preemption is disabled. + + "preemptirqsoff" + + Similar to irqsoff and preemptoff, but traces and + records the largest time for which irqs and/or preemption + is disabled. + + "wakeup" + + Traces and records the max latency that it takes for + the highest priority task to get scheduled after + it has been woken up. + Traces all tasks as an average developer would expect. + + "wakeup_rt" + + Traces and records the max latency that it takes for just + RT tasks (as the current "wakeup" does). This is useful + for those interested in wake up timings of RT tasks. + + "wakeup_dl" + + Traces and records the max latency that it takes for + a SCHED_DEADLINE task to be woken (as the "wakeup" and + "wakeup_rt" does). + + "mmiotrace" + + A special tracer that is used to trace binary module. + It will trace all the calls that a module makes to the + hardware. Everything it writes and reads from the I/O + as well. + + "branch" + + This tracer can be configured when tracing likely/unlikely + calls within the kernel. It will trace when a likely and + unlikely branch is hit and if it was correct in its prediction + of being correct. + + "nop" + + This is the "trace nothing" tracer. To remove all + tracers from tracing simply echo "nop" into + current_tracer. + + +Examples of using the tracer +---------------------------- + +Here are typical examples of using the tracers when controlling +them only with the tracefs interface (without using any +user-land utilities). + +Output format: +-------------- + +Here is an example of the output format of the file "trace":: + + # tracer: function + # + # entries-in-buffer/entries-written: 140080/250280 #P:4 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + bash-1977 [000] .... 17284.993652: sys_close <-system_call_fastpath + bash-1977 [000] .... 17284.993653: __close_fd <-sys_close + bash-1977 [000] .... 17284.993653: _raw_spin_lock <-__close_fd + sshd-1974 [003] .... 17284.993653: __srcu_read_unlock <-fsnotify + bash-1977 [000] .... 17284.993654: add_preempt_count <-_raw_spin_lock + bash-1977 [000] ...1 17284.993655: _raw_spin_unlock <-__close_fd + bash-1977 [000] ...1 17284.993656: sub_preempt_count <-_raw_spin_unlock + bash-1977 [000] .... 17284.993657: filp_close <-__close_fd + bash-1977 [000] .... 17284.993657: dnotify_flush <-filp_close + sshd-1974 [003] .... 17284.993658: sys_select <-system_call_fastpath + .... + +A header is printed with the tracer name that is represented by +the trace. In this case the tracer is "function". Then it shows the +number of events in the buffer as well as the total number of entries +that were written. The difference is the number of entries that were +lost due to the buffer filling up (250280 - 140080 = 110200 events +lost). + +The header explains the content of the events. Task name "bash", the task +PID "1977", the CPU that it was running on "000", the latency format +(explained below), the timestamp in <secs>.<usecs> format, the +function name that was traced "sys_close" and the parent function that +called this function "system_call_fastpath". The timestamp is the time +at which the function was entered. + +Latency trace format +-------------------- + +When the latency-format option is enabled or when one of the latency +tracers is set, the trace file gives somewhat more information to see +why a latency happened. Here is a typical trace:: + + # tracer: irqsoff + # + # irqsoff latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 259 us, #4/4, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: ps-6143 (uid:0 nice:0 policy:0 rt_prio:0) + # ----------------- + # => started at: __lock_task_sighand + # => ended at: _raw_spin_unlock_irqrestore + # + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + ps-6143 2d... 0us!: trace_hardirqs_off <-__lock_task_sighand + ps-6143 2d..1 259us+: trace_hardirqs_on <-_raw_spin_unlock_irqrestore + ps-6143 2d..1 263us+: time_hardirqs_on <-_raw_spin_unlock_irqrestore + ps-6143 2d..1 306us : <stack trace> + => trace_hardirqs_on_caller + => trace_hardirqs_on + => _raw_spin_unlock_irqrestore + => do_task_stat + => proc_tgid_stat + => proc_single_show + => seq_read + => vfs_read + => sys_read + => system_call_fastpath + + +This shows that the current tracer is "irqsoff" tracing the time +for which interrupts were disabled. It gives the trace version (which +never changes) and the version of the kernel upon which this was executed on +(3.8). Then it displays the max latency in microseconds (259 us). The number +of trace entries displayed and the total number (both are four: #4/4). +VP, KP, SP, and HP are always zero and are reserved for later use. +#P is the number of online CPUs (#P:4). + +The task is the process that was running when the latency +occurred. (ps pid: 6143). + +The start and stop (the functions in which the interrupts were +disabled and enabled respectively) that caused the latencies: + + - __lock_task_sighand is where the interrupts were disabled. + - _raw_spin_unlock_irqrestore is where they were enabled again. + +The next lines after the header are the trace itself. The header +explains which is which. + + cmd: The name of the process in the trace. + + pid: The PID of that process. + + CPU#: The CPU which the process was running on. + + irqs-off: 'd' interrupts are disabled. '.' otherwise. + .. caution:: If the architecture does not support a way to + read the irq flags variable, an 'X' will always + be printed here. + + need-resched: + - 'N' both TIF_NEED_RESCHED and PREEMPT_NEED_RESCHED is set, + - 'n' only TIF_NEED_RESCHED is set, + - 'p' only PREEMPT_NEED_RESCHED is set, + - '.' otherwise. + + hardirq/softirq: + - 'Z' - NMI occurred inside a hardirq + - 'z' - NMI is running + - 'H' - hard irq occurred inside a softirq. + - 'h' - hard irq is running + - 's' - soft irq is running + - '.' - normal context. + + preempt-depth: The level of preempt_disabled + +The above is mostly meaningful for kernel developers. + + time: + When the latency-format option is enabled, the trace file + output includes a timestamp relative to the start of the + trace. This differs from the output when latency-format + is disabled, which includes an absolute timestamp. + + delay: + This is just to help catch your eye a bit better. And + needs to be fixed to be only relative to the same CPU. + The marks are determined by the difference between this + current trace and the next trace. + + - '$' - greater than 1 second + - '@' - greater than 100 milisecond + - '*' - greater than 10 milisecond + - '#' - greater than 1000 microsecond + - '!' - greater than 100 microsecond + - '+' - greater than 10 microsecond + - ' ' - less than or equal to 10 microsecond. + + The rest is the same as the 'trace' file. + + Note, the latency tracers will usually end with a back trace + to easily find where the latency occurred. + +trace_options +------------- + +The trace_options file (or the options directory) is used to control +what gets printed in the trace output, or manipulate the tracers. +To see what is available, simply cat the file:: + + cat trace_options + print-parent + nosym-offset + nosym-addr + noverbose + noraw + nohex + nobin + noblock + trace_printk + annotate + nouserstacktrace + nosym-userobj + noprintk-msg-only + context-info + nolatency-format + record-cmd + norecord-tgid + overwrite + nodisable_on_free + irq-info + markers + noevent-fork + function-trace + nofunction-fork + nodisplay-graph + nostacktrace + nobranch + +To disable one of the options, echo in the option prepended with +"no":: + + echo noprint-parent > trace_options + +To enable an option, leave off the "no":: + + echo sym-offset > trace_options + +Here are the available options: + + print-parent + On function traces, display the calling (parent) + function as well as the function being traced. + :: + + print-parent: + bash-4000 [01] 1477.606694: simple_strtoul <-kstrtoul + + noprint-parent: + bash-4000 [01] 1477.606694: simple_strtoul + + + sym-offset + Display not only the function name, but also the + offset in the function. For example, instead of + seeing just "ktime_get", you will see + "ktime_get+0xb/0x20". + :: + + sym-offset: + bash-4000 [01] 1477.606694: simple_strtoul+0x6/0xa0 + + sym-addr + This will also display the function address as well + as the function name. + :: + + sym-addr: + bash-4000 [01] 1477.606694: simple_strtoul <c0339346> + + verbose + This deals with the trace file when the + latency-format option is enabled. + :: + + bash 4000 1 0 00000000 00010a95 [58127d26] 1720.415ms \ + (+0.000ms): simple_strtoul (kstrtoul) + + raw + This will display raw numbers. This option is best for + use with user applications that can translate the raw + numbers better than having it done in the kernel. + + hex + Similar to raw, but the numbers will be in a hexadecimal format. + + bin + This will print out the formats in raw binary. + + block + When set, reading trace_pipe will not block when polled. + + trace_printk + Can disable trace_printk() from writing into the buffer. + + annotate + It is sometimes confusing when the CPU buffers are full + and one CPU buffer had a lot of events recently, thus + a shorter time frame, were another CPU may have only had + a few events, which lets it have older events. When + the trace is reported, it shows the oldest events first, + and it may look like only one CPU ran (the one with the + oldest events). When the annotate option is set, it will + display when a new CPU buffer started:: + + <idle>-0 [001] dNs4 21169.031481: wake_up_idle_cpu <-add_timer_on + <idle>-0 [001] dNs4 21169.031482: _raw_spin_unlock_irqrestore <-add_timer_on + <idle>-0 [001] .Ns4 21169.031484: sub_preempt_count <-_raw_spin_unlock_irqrestore + ##### CPU 2 buffer started #### + <idle>-0 [002] .N.1 21169.031484: rcu_idle_exit <-cpu_idle + <idle>-0 [001] .Ns3 21169.031484: _raw_spin_unlock <-clocksource_watchdog + <idle>-0 [001] .Ns3 21169.031485: sub_preempt_count <-_raw_spin_unlock + + userstacktrace + This option changes the trace. It records a + stacktrace of the current user space thread after + each trace event. + + sym-userobj + when user stacktrace are enabled, look up which + object the address belongs to, and print a + relative address. This is especially useful when + ASLR is on, otherwise you don't get a chance to + resolve the address to object/file/line after + the app is no longer running + + The lookup is performed when you read + trace,trace_pipe. Example:: + + a.out-1623 [000] 40874.465068: /root/a.out[+0x480] <-/root/a.out[+0 + x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6] + + + printk-msg-only + When set, trace_printk()s will only show the format + and not their parameters (if trace_bprintk() or + trace_bputs() was used to save the trace_printk()). + + context-info + Show only the event data. Hides the comm, PID, + timestamp, CPU, and other useful data. + + latency-format + This option changes the trace output. When it is enabled, + the trace displays additional information about the + latency, as described in "Latency trace format". + + record-cmd + When any event or tracer is enabled, a hook is enabled + in the sched_switch trace point to fill comm cache + with mapped pids and comms. But this may cause some + overhead, and if you only care about pids, and not the + name of the task, disabling this option can lower the + impact of tracing. See "saved_cmdlines". + + record-tgid + When any event or tracer is enabled, a hook is enabled + in the sched_switch trace point to fill the cache of + mapped Thread Group IDs (TGID) mapping to pids. See + "saved_tgids". + + overwrite + This controls what happens when the trace buffer is + full. If "1" (default), the oldest events are + discarded and overwritten. If "0", then the newest + events are discarded. + (see per_cpu/cpu0/stats for overrun and dropped) + + disable_on_free + When the free_buffer is closed, tracing will + stop (tracing_on set to 0). + + irq-info + Shows the interrupt, preempt count, need resched data. + When disabled, the trace looks like:: + + # tracer: function + # + # entries-in-buffer/entries-written: 144405/9452052 #P:4 + # + # TASK-PID CPU# TIMESTAMP FUNCTION + # | | | | | + <idle>-0 [002] 23636.756054: ttwu_do_activate.constprop.89 <-try_to_wake_up + <idle>-0 [002] 23636.756054: activate_task <-ttwu_do_activate.constprop.89 + <idle>-0 [002] 23636.756055: enqueue_task <-activate_task + + + markers + When set, the trace_marker is writable (only by root). + When disabled, the trace_marker will error with EINVAL + on write. + + event-fork + When set, tasks with PIDs listed in set_event_pid will have + the PIDs of their children added to set_event_pid when those + tasks fork. Also, when tasks with PIDs in set_event_pid exit, + their PIDs will be removed from the file. + + function-trace + The latency tracers will enable function tracing + if this option is enabled (default it is). When + it is disabled, the latency tracers do not trace + functions. This keeps the overhead of the tracer down + when performing latency tests. + + function-fork + When set, tasks with PIDs listed in set_ftrace_pid will + have the PIDs of their children added to set_ftrace_pid + when those tasks fork. Also, when tasks with PIDs in + set_ftrace_pid exit, their PIDs will be removed from the + file. + + display-graph + When set, the latency tracers (irqsoff, wakeup, etc) will + use function graph tracing instead of function tracing. + + stacktrace + When set, a stack trace is recorded after any trace event + is recorded. + + branch + Enable branch tracing with the tracer. This enables branch + tracer along with the currently set tracer. Enabling this + with the "nop" tracer is the same as just enabling the + "branch" tracer. + +.. tip:: Some tracers have their own options. They only appear in this + file when the tracer is active. They always appear in the + options directory. + + +Here are the per tracer options: + +Options for function tracer: + + func_stack_trace + When set, a stack trace is recorded after every + function that is recorded. NOTE! Limit the functions + that are recorded before enabling this, with + "set_ftrace_filter" otherwise the system performance + will be critically degraded. Remember to disable + this option before clearing the function filter. + +Options for function_graph tracer: + + Since the function_graph tracer has a slightly different output + it has its own options to control what is displayed. + + funcgraph-overrun + When set, the "overrun" of the graph stack is + displayed after each function traced. The + overrun, is when the stack depth of the calls + is greater than what is reserved for each task. + Each task has a fixed array of functions to + trace in the call graph. If the depth of the + calls exceeds that, the function is not traced. + The overrun is the number of functions missed + due to exceeding this array. + + funcgraph-cpu + When set, the CPU number of the CPU where the trace + occurred is displayed. + + funcgraph-overhead + When set, if the function takes longer than + A certain amount, then a delay marker is + displayed. See "delay" above, under the + header description. + + funcgraph-proc + Unlike other tracers, the process' command line + is not displayed by default, but instead only + when a task is traced in and out during a context + switch. Enabling this options has the command + of each process displayed at every line. + + funcgraph-duration + At the end of each function (the return) + the duration of the amount of time in the + function is displayed in microseconds. + + funcgraph-abstime + When set, the timestamp is displayed at each line. + + funcgraph-irqs + When disabled, functions that happen inside an + interrupt will not be traced. + + funcgraph-tail + When set, the return event will include the function + that it represents. By default this is off, and + only a closing curly bracket "}" is displayed for + the return of a function. + + sleep-time + When running function graph tracer, to include + the time a task schedules out in its function. + When enabled, it will account time the task has been + scheduled out as part of the function call. + + graph-time + When running function profiler with function graph tracer, + to include the time to call nested functions. When this is + not set, the time reported for the function will only + include the time the function itself executed for, not the + time for functions that it called. + +Options for blk tracer: + + blk_classic + Shows a more minimalistic output. + + +irqsoff +------- + +When interrupts are disabled, the CPU can not react to any other +external event (besides NMIs and SMIs). This prevents the timer +interrupt from triggering or the mouse interrupt from letting +the kernel know of a new mouse event. The result is a latency +with the reaction time. + +The irqsoff tracer tracks the time for which interrupts are +disabled. When a new maximum latency is hit, the tracer saves +the trace leading up to that latency point so that every time a +new maximum is reached, the old saved trace is discarded and the +new trace is saved. + +To reset the maximum, echo 0 into tracing_max_latency. Here is +an example:: + + # echo 0 > options/function-trace + # echo irqsoff > current_tracer + # echo 1 > tracing_on + # echo 0 > tracing_max_latency + # ls -ltr + [...] + # echo 0 > tracing_on + # cat trace + # tracer: irqsoff + # + # irqsoff latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 16 us, #4/4, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: swapper/0-0 (uid:0 nice:0 policy:0 rt_prio:0) + # ----------------- + # => started at: run_timer_softirq + # => ended at: run_timer_softirq + # + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + <idle>-0 0d.s2 0us+: _raw_spin_lock_irq <-run_timer_softirq + <idle>-0 0dNs3 17us : _raw_spin_unlock_irq <-run_timer_softirq + <idle>-0 0dNs3 17us+: trace_hardirqs_on <-run_timer_softirq + <idle>-0 0dNs3 25us : <stack trace> + => _raw_spin_unlock_irq + => run_timer_softirq + => __do_softirq + => call_softirq + => do_softirq + => irq_exit + => smp_apic_timer_interrupt + => apic_timer_interrupt + => rcu_idle_exit + => cpu_idle + => rest_init + => start_kernel + => x86_64_start_reservations + => x86_64_start_kernel + +Here we see that that we had a latency of 16 microseconds (which is +very good). The _raw_spin_lock_irq in run_timer_softirq disabled +interrupts. The difference between the 16 and the displayed +timestamp 25us occurred because the clock was incremented +between the time of recording the max latency and the time of +recording the function that had that latency. + +Note the above example had function-trace not set. If we set +function-trace, we get a much larger output:: + + with echo 1 > options/function-trace + + # tracer: irqsoff + # + # irqsoff latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 71 us, #168/168, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: bash-2042 (uid:0 nice:0 policy:0 rt_prio:0) + # ----------------- + # => started at: ata_scsi_queuecmd + # => ended at: ata_scsi_queuecmd + # + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + bash-2042 3d... 0us : _raw_spin_lock_irqsave <-ata_scsi_queuecmd + bash-2042 3d... 0us : add_preempt_count <-_raw_spin_lock_irqsave + bash-2042 3d..1 1us : ata_scsi_find_dev <-ata_scsi_queuecmd + bash-2042 3d..1 1us : __ata_scsi_find_dev <-ata_scsi_find_dev + bash-2042 3d..1 2us : ata_find_dev.part.14 <-__ata_scsi_find_dev + bash-2042 3d..1 2us : ata_qc_new_init <-__ata_scsi_queuecmd + bash-2042 3d..1 3us : ata_sg_init <-__ata_scsi_queuecmd + bash-2042 3d..1 4us : ata_scsi_rw_xlat <-__ata_scsi_queuecmd + bash-2042 3d..1 4us : ata_build_rw_tf <-ata_scsi_rw_xlat + [...] + bash-2042 3d..1 67us : delay_tsc <-__delay + bash-2042 3d..1 67us : add_preempt_count <-delay_tsc + bash-2042 3d..2 67us : sub_preempt_count <-delay_tsc + bash-2042 3d..1 67us : add_preempt_count <-delay_tsc + bash-2042 3d..2 68us : sub_preempt_count <-delay_tsc + bash-2042 3d..1 68us+: ata_bmdma_start <-ata_bmdma_qc_issue + bash-2042 3d..1 71us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd + bash-2042 3d..1 71us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd + bash-2042 3d..1 72us+: trace_hardirqs_on <-ata_scsi_queuecmd + bash-2042 3d..1 120us : <stack trace> + => _raw_spin_unlock_irqrestore + => ata_scsi_queuecmd + => scsi_dispatch_cmd + => scsi_request_fn + => __blk_run_queue_uncond + => __blk_run_queue + => blk_queue_bio + => generic_make_request + => submit_bio + => submit_bh + => __ext3_get_inode_loc + => ext3_iget + => ext3_lookup + => lookup_real + => __lookup_hash + => walk_component + => lookup_last + => path_lookupat + => filename_lookup + => user_path_at_empty + => user_path_at + => vfs_fstatat + => vfs_stat + => sys_newstat + => system_call_fastpath + + +Here we traced a 71 microsecond latency. But we also see all the +functions that were called during that time. Note that by +enabling function tracing, we incur an added overhead. This +overhead may extend the latency times. But nevertheless, this +trace has provided some very helpful debugging information. + + +preemptoff +---------- + +When preemption is disabled, we may be able to receive +interrupts but the task cannot be preempted and a higher +priority task must wait for preemption to be enabled again +before it can preempt a lower priority task. + +The preemptoff tracer traces the places that disable preemption. +Like the irqsoff tracer, it records the maximum latency for +which preemption was disabled. The control of preemptoff tracer +is much like the irqsoff tracer. +:: + + # echo 0 > options/function-trace + # echo preemptoff > current_tracer + # echo 1 > tracing_on + # echo 0 > tracing_max_latency + # ls -ltr + [...] + # echo 0 > tracing_on + # cat trace + # tracer: preemptoff + # + # preemptoff latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 46 us, #4/4, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: sshd-1991 (uid:0 nice:0 policy:0 rt_prio:0) + # ----------------- + # => started at: do_IRQ + # => ended at: do_IRQ + # + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + sshd-1991 1d.h. 0us+: irq_enter <-do_IRQ + sshd-1991 1d..1 46us : irq_exit <-do_IRQ + sshd-1991 1d..1 47us+: trace_preempt_on <-do_IRQ + sshd-1991 1d..1 52us : <stack trace> + => sub_preempt_count + => irq_exit + => do_IRQ + => ret_from_intr + + +This has some more changes. Preemption was disabled when an +interrupt came in (notice the 'h'), and was enabled on exit. +But we also see that interrupts have been disabled when entering +the preempt off section and leaving it (the 'd'). We do not know if +interrupts were enabled in the mean time or shortly after this +was over. +:: + + # tracer: preemptoff + # + # preemptoff latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 83 us, #241/241, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: bash-1994 (uid:0 nice:0 policy:0 rt_prio:0) + # ----------------- + # => started at: wake_up_new_task + # => ended at: task_rq_unlock + # + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + bash-1994 1d..1 0us : _raw_spin_lock_irqsave <-wake_up_new_task + bash-1994 1d..1 0us : select_task_rq_fair <-select_task_rq + bash-1994 1d..1 1us : __rcu_read_lock <-select_task_rq_fair + bash-1994 1d..1 1us : source_load <-select_task_rq_fair + bash-1994 1d..1 1us : source_load <-select_task_rq_fair + [...] + bash-1994 1d..1 12us : irq_enter <-smp_apic_timer_interrupt + bash-1994 1d..1 12us : rcu_irq_enter <-irq_enter + bash-1994 1d..1 13us : add_preempt_count <-irq_enter + bash-1994 1d.h1 13us : exit_idle <-smp_apic_timer_interrupt + bash-1994 1d.h1 13us : hrtimer_interrupt <-smp_apic_timer_interrupt + bash-1994 1d.h1 13us : _raw_spin_lock <-hrtimer_interrupt + bash-1994 1d.h1 14us : add_preempt_count <-_raw_spin_lock + bash-1994 1d.h2 14us : ktime_get_update_offsets <-hrtimer_interrupt + [...] + bash-1994 1d.h1 35us : lapic_next_event <-clockevents_program_event + bash-1994 1d.h1 35us : irq_exit <-smp_apic_timer_interrupt + bash-1994 1d.h1 36us : sub_preempt_count <-irq_exit + bash-1994 1d..2 36us : do_softirq <-irq_exit + bash-1994 1d..2 36us : __do_softirq <-call_softirq + bash-1994 1d..2 36us : __local_bh_disable <-__do_softirq + bash-1994 1d.s2 37us : add_preempt_count <-_raw_spin_lock_irq + bash-1994 1d.s3 38us : _raw_spin_unlock <-run_timer_softirq + bash-1994 1d.s3 39us : sub_preempt_count <-_raw_spin_unlock + bash-1994 1d.s2 39us : call_timer_fn <-run_timer_softirq + [...] + bash-1994 1dNs2 81us : cpu_needs_another_gp <-rcu_process_callbacks + bash-1994 1dNs2 82us : __local_bh_enable <-__do_softirq + bash-1994 1dNs2 82us : sub_preempt_count <-__local_bh_enable + bash-1994 1dN.2 82us : idle_cpu <-irq_exit + bash-1994 1dN.2 83us : rcu_irq_exit <-irq_exit + bash-1994 1dN.2 83us : sub_preempt_count <-irq_exit + bash-1994 1.N.1 84us : _raw_spin_unlock_irqrestore <-task_rq_unlock + bash-1994 1.N.1 84us+: trace_preempt_on <-task_rq_unlock + bash-1994 1.N.1 104us : <stack trace> + => sub_preempt_count + => _raw_spin_unlock_irqrestore + => task_rq_unlock + => wake_up_new_task + => do_fork + => sys_clone + => stub_clone + + +The above is an example of the preemptoff trace with +function-trace set. Here we see that interrupts were not disabled +the entire time. The irq_enter code lets us know that we entered +an interrupt 'h'. Before that, the functions being traced still +show that it is not in an interrupt, but we can see from the +functions themselves that this is not the case. + +preemptirqsoff +-------------- + +Knowing the locations that have interrupts disabled or +preemption disabled for the longest times is helpful. But +sometimes we would like to know when either preemption and/or +interrupts are disabled. + +Consider the following code:: + + local_irq_disable(); + call_function_with_irqs_off(); + preempt_disable(); + call_function_with_irqs_and_preemption_off(); + local_irq_enable(); + call_function_with_preemption_off(); + preempt_enable(); + +The irqsoff tracer will record the total length of +call_function_with_irqs_off() and +call_function_with_irqs_and_preemption_off(). + +The preemptoff tracer will record the total length of +call_function_with_irqs_and_preemption_off() and +call_function_with_preemption_off(). + +But neither will trace the time that interrupts and/or +preemption is disabled. This total time is the time that we can +not schedule. To record this time, use the preemptirqsoff +tracer. + +Again, using this trace is much like the irqsoff and preemptoff +tracers. +:: + + # echo 0 > options/function-trace + # echo preemptirqsoff > current_tracer + # echo 1 > tracing_on + # echo 0 > tracing_max_latency + # ls -ltr + [...] + # echo 0 > tracing_on + # cat trace + # tracer: preemptirqsoff + # + # preemptirqsoff latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 100 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: ls-2230 (uid:0 nice:0 policy:0 rt_prio:0) + # ----------------- + # => started at: ata_scsi_queuecmd + # => ended at: ata_scsi_queuecmd + # + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + ls-2230 3d... 0us+: _raw_spin_lock_irqsave <-ata_scsi_queuecmd + ls-2230 3...1 100us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd + ls-2230 3...1 101us+: trace_preempt_on <-ata_scsi_queuecmd + ls-2230 3...1 111us : <stack trace> + => sub_preempt_count + => _raw_spin_unlock_irqrestore + => ata_scsi_queuecmd + => scsi_dispatch_cmd + => scsi_request_fn + => __blk_run_queue_uncond + => __blk_run_queue + => blk_queue_bio + => generic_make_request + => submit_bio + => submit_bh + => ext3_bread + => ext3_dir_bread + => htree_dirblock_to_tree + => ext3_htree_fill_tree + => ext3_readdir + => vfs_readdir + => sys_getdents + => system_call_fastpath + + +The trace_hardirqs_off_thunk is called from assembly on x86 when +interrupts are disabled in the assembly code. Without the +function tracing, we do not know if interrupts were enabled +within the preemption points. We do see that it started with +preemption enabled. + +Here is a trace with function-trace set:: + + # tracer: preemptirqsoff + # + # preemptirqsoff latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 161 us, #339/339, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: ls-2269 (uid:0 nice:0 policy:0 rt_prio:0) + # ----------------- + # => started at: schedule + # => ended at: mutex_unlock + # + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + kworker/-59 3...1 0us : __schedule <-schedule + kworker/-59 3d..1 0us : rcu_preempt_qs <-rcu_note_context_switch + kworker/-59 3d..1 1us : add_preempt_count <-_raw_spin_lock_irq + kworker/-59 3d..2 1us : deactivate_task <-__schedule + kworker/-59 3d..2 1us : dequeue_task <-deactivate_task + kworker/-59 3d..2 2us : update_rq_clock <-dequeue_task + kworker/-59 3d..2 2us : dequeue_task_fair <-dequeue_task + kworker/-59 3d..2 2us : update_curr <-dequeue_task_fair + kworker/-59 3d..2 2us : update_min_vruntime <-update_curr + kworker/-59 3d..2 3us : cpuacct_charge <-update_curr + kworker/-59 3d..2 3us : __rcu_read_lock <-cpuacct_charge + kworker/-59 3d..2 3us : __rcu_read_unlock <-cpuacct_charge + kworker/-59 3d..2 3us : update_cfs_rq_blocked_load <-dequeue_task_fair + kworker/-59 3d..2 4us : clear_buddies <-dequeue_task_fair + kworker/-59 3d..2 4us : account_entity_dequeue <-dequeue_task_fair + kworker/-59 3d..2 4us : update_min_vruntime <-dequeue_task_fair + kworker/-59 3d..2 4us : update_cfs_shares <-dequeue_task_fair + kworker/-59 3d..2 5us : hrtick_update <-dequeue_task_fair + kworker/-59 3d..2 5us : wq_worker_sleeping <-__schedule + kworker/-59 3d..2 5us : kthread_data <-wq_worker_sleeping + kworker/-59 3d..2 5us : put_prev_task_fair <-__schedule + kworker/-59 3d..2 6us : pick_next_task_fair <-pick_next_task + kworker/-59 3d..2 6us : clear_buddies <-pick_next_task_fair + kworker/-59 3d..2 6us : set_next_entity <-pick_next_task_fair + kworker/-59 3d..2 6us : update_stats_wait_end <-set_next_entity + ls-2269 3d..2 7us : finish_task_switch <-__schedule + ls-2269 3d..2 7us : _raw_spin_unlock_irq <-finish_task_switch + ls-2269 3d..2 8us : do_IRQ <-ret_from_intr + ls-2269 3d..2 8us : irq_enter <-do_IRQ + ls-2269 3d..2 8us : rcu_irq_enter <-irq_enter + ls-2269 3d..2 9us : add_preempt_count <-irq_enter + ls-2269 3d.h2 9us : exit_idle <-do_IRQ + [...] + ls-2269 3d.h3 20us : sub_preempt_count <-_raw_spin_unlock + ls-2269 3d.h2 20us : irq_exit <-do_IRQ + ls-2269 3d.h2 21us : sub_preempt_count <-irq_exit + ls-2269 3d..3 21us : do_softirq <-irq_exit + ls-2269 3d..3 21us : __do_softirq <-call_softirq + ls-2269 3d..3 21us+: __local_bh_disable <-__do_softirq + ls-2269 3d.s4 29us : sub_preempt_count <-_local_bh_enable_ip + ls-2269 3d.s5 29us : sub_preempt_count <-_local_bh_enable_ip + ls-2269 3d.s5 31us : do_IRQ <-ret_from_intr + ls-2269 3d.s5 31us : irq_enter <-do_IRQ + ls-2269 3d.s5 31us : rcu_irq_enter <-irq_enter + [...] + ls-2269 3d.s5 31us : rcu_irq_enter <-irq_enter + ls-2269 3d.s5 32us : add_preempt_count <-irq_enter + ls-2269 3d.H5 32us : exit_idle <-do_IRQ + ls-2269 3d.H5 32us : handle_irq <-do_IRQ + ls-2269 3d.H5 32us : irq_to_desc <-handle_irq + ls-2269 3d.H5 33us : handle_fasteoi_irq <-handle_irq + [...] + ls-2269 3d.s5 158us : _raw_spin_unlock_irqrestore <-rtl8139_poll + ls-2269 3d.s3 158us : net_rps_action_and_irq_enable.isra.65 <-net_rx_action + ls-2269 3d.s3 159us : __local_bh_enable <-__do_softirq + ls-2269 3d.s3 159us : sub_preempt_count <-__local_bh_enable + ls-2269 3d..3 159us : idle_cpu <-irq_exit + ls-2269 3d..3 159us : rcu_irq_exit <-irq_exit + ls-2269 3d..3 160us : sub_preempt_count <-irq_exit + ls-2269 3d... 161us : __mutex_unlock_slowpath <-mutex_unlock + ls-2269 3d... 162us+: trace_hardirqs_on <-mutex_unlock + ls-2269 3d... 186us : <stack trace> + => __mutex_unlock_slowpath + => mutex_unlock + => process_output + => n_tty_write + => tty_write + => vfs_write + => sys_write + => system_call_fastpath + +This is an interesting trace. It started with kworker running and +scheduling out and ls taking over. But as soon as ls released the +rq lock and enabled interrupts (but not preemption) an interrupt +triggered. When the interrupt finished, it started running softirqs. +But while the softirq was running, another interrupt triggered. +When an interrupt is running inside a softirq, the annotation is 'H'. + + +wakeup +------ + +One common case that people are interested in tracing is the +time it takes for a task that is woken to actually wake up. +Now for non Real-Time tasks, this can be arbitrary. But tracing +it none the less can be interesting. + +Without function tracing:: + + # echo 0 > options/function-trace + # echo wakeup > current_tracer + # echo 1 > tracing_on + # echo 0 > tracing_max_latency + # chrt -f 5 sleep 1 + # echo 0 > tracing_on + # cat trace + # tracer: wakeup + # + # wakeup latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 15 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: kworker/3:1H-312 (uid:0 nice:-20 policy:0 rt_prio:0) + # ----------------- + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + <idle>-0 3dNs7 0us : 0:120:R + [003] 312:100:R kworker/3:1H + <idle>-0 3dNs7 1us+: ttwu_do_activate.constprop.87 <-try_to_wake_up + <idle>-0 3d..3 15us : __schedule <-schedule + <idle>-0 3d..3 15us : 0:120:R ==> [003] 312:100:R kworker/3:1H + +The tracer only traces the highest priority task in the system +to avoid tracing the normal circumstances. Here we see that +the kworker with a nice priority of -20 (not very nice), took +just 15 microseconds from the time it woke up, to the time it +ran. + +Non Real-Time tasks are not that interesting. A more interesting +trace is to concentrate only on Real-Time tasks. + +wakeup_rt +--------- + +In a Real-Time environment it is very important to know the +wakeup time it takes for the highest priority task that is woken +up to the time that it executes. This is also known as "schedule +latency". I stress the point that this is about RT tasks. It is +also important to know the scheduling latency of non-RT tasks, +but the average schedule latency is better for non-RT tasks. +Tools like LatencyTop are more appropriate for such +measurements. + +Real-Time environments are interested in the worst case latency. +That is the longest latency it takes for something to happen, +and not the average. We can have a very fast scheduler that may +only have a large latency once in a while, but that would not +work well with Real-Time tasks. The wakeup_rt tracer was designed +to record the worst case wakeups of RT tasks. Non-RT tasks are +not recorded because the tracer only records one worst case and +tracing non-RT tasks that are unpredictable will overwrite the +worst case latency of RT tasks (just run the normal wakeup +tracer for a while to see that effect). + +Since this tracer only deals with RT tasks, we will run this +slightly differently than we did with the previous tracers. +Instead of performing an 'ls', we will run 'sleep 1' under +'chrt' which changes the priority of the task. +:: + + # echo 0 > options/function-trace + # echo wakeup_rt > current_tracer + # echo 1 > tracing_on + # echo 0 > tracing_max_latency + # chrt -f 5 sleep 1 + # echo 0 > tracing_on + # cat trace + # tracer: wakeup + # + # tracer: wakeup_rt + # + # wakeup_rt latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 5 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: sleep-2389 (uid:0 nice:0 policy:1 rt_prio:5) + # ----------------- + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + <idle>-0 3d.h4 0us : 0:120:R + [003] 2389: 94:R sleep + <idle>-0 3d.h4 1us+: ttwu_do_activate.constprop.87 <-try_to_wake_up + <idle>-0 3d..3 5us : __schedule <-schedule + <idle>-0 3d..3 5us : 0:120:R ==> [003] 2389: 94:R sleep + + +Running this on an idle system, we see that it only took 5 microseconds +to perform the task switch. Note, since the trace point in the schedule +is before the actual "switch", we stop the tracing when the recorded task +is about to schedule in. This may change if we add a new marker at the +end of the scheduler. + +Notice that the recorded task is 'sleep' with the PID of 2389 +and it has an rt_prio of 5. This priority is user-space priority +and not the internal kernel priority. The policy is 1 for +SCHED_FIFO and 2 for SCHED_RR. + +Note, that the trace data shows the internal priority (99 - rtprio). +:: + + <idle>-0 3d..3 5us : 0:120:R ==> [003] 2389: 94:R sleep + +The 0:120:R means idle was running with a nice priority of 0 (120 - 120) +and in the running state 'R'. The sleep task was scheduled in with +2389: 94:R. That is the priority is the kernel rtprio (99 - 5 = 94) +and it too is in the running state. + +Doing the same with chrt -r 5 and function-trace set. +:: + + echo 1 > options/function-trace + + # tracer: wakeup_rt + # + # wakeup_rt latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 29 us, #85/85, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: sleep-2448 (uid:0 nice:0 policy:1 rt_prio:5) + # ----------------- + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + <idle>-0 3d.h4 1us+: 0:120:R + [003] 2448: 94:R sleep + <idle>-0 3d.h4 2us : ttwu_do_activate.constprop.87 <-try_to_wake_up + <idle>-0 3d.h3 3us : check_preempt_curr <-ttwu_do_wakeup + <idle>-0 3d.h3 3us : resched_curr <-check_preempt_curr + <idle>-0 3dNh3 4us : task_woken_rt <-ttwu_do_wakeup + <idle>-0 3dNh3 4us : _raw_spin_unlock <-try_to_wake_up + <idle>-0 3dNh3 4us : sub_preempt_count <-_raw_spin_unlock + <idle>-0 3dNh2 5us : ttwu_stat <-try_to_wake_up + <idle>-0 3dNh2 5us : _raw_spin_unlock_irqrestore <-try_to_wake_up + <idle>-0 3dNh2 6us : sub_preempt_count <-_raw_spin_unlock_irqrestore + <idle>-0 3dNh1 6us : _raw_spin_lock <-__run_hrtimer + <idle>-0 3dNh1 6us : add_preempt_count <-_raw_spin_lock + <idle>-0 3dNh2 7us : _raw_spin_unlock <-hrtimer_interrupt + <idle>-0 3dNh2 7us : sub_preempt_count <-_raw_spin_unlock + <idle>-0 3dNh1 7us : tick_program_event <-hrtimer_interrupt + <idle>-0 3dNh1 7us : clockevents_program_event <-tick_program_event + <idle>-0 3dNh1 8us : ktime_get <-clockevents_program_event + <idle>-0 3dNh1 8us : lapic_next_event <-clockevents_program_event + <idle>-0 3dNh1 8us : irq_exit <-smp_apic_timer_interrupt + <idle>-0 3dNh1 9us : sub_preempt_count <-irq_exit + <idle>-0 3dN.2 9us : idle_cpu <-irq_exit + <idle>-0 3dN.2 9us : rcu_irq_exit <-irq_exit + <idle>-0 3dN.2 10us : rcu_eqs_enter_common.isra.45 <-rcu_irq_exit + <idle>-0 3dN.2 10us : sub_preempt_count <-irq_exit + <idle>-0 3.N.1 11us : rcu_idle_exit <-cpu_idle + <idle>-0 3dN.1 11us : rcu_eqs_exit_common.isra.43 <-rcu_idle_exit + <idle>-0 3.N.1 11us : tick_nohz_idle_exit <-cpu_idle + <idle>-0 3dN.1 12us : menu_hrtimer_cancel <-tick_nohz_idle_exit + <idle>-0 3dN.1 12us : ktime_get <-tick_nohz_idle_exit + <idle>-0 3dN.1 12us : tick_do_update_jiffies64 <-tick_nohz_idle_exit + <idle>-0 3dN.1 13us : cpu_load_update_nohz <-tick_nohz_idle_exit + <idle>-0 3dN.1 13us : _raw_spin_lock <-cpu_load_update_nohz + <idle>-0 3dN.1 13us : add_preempt_count <-_raw_spin_lock + <idle>-0 3dN.2 13us : __cpu_load_update <-cpu_load_update_nohz + <idle>-0 3dN.2 14us : sched_avg_update <-__cpu_load_update + <idle>-0 3dN.2 14us : _raw_spin_unlock <-cpu_load_update_nohz + <idle>-0 3dN.2 14us : sub_preempt_count <-_raw_spin_unlock + <idle>-0 3dN.1 15us : calc_load_nohz_stop <-tick_nohz_idle_exit + <idle>-0 3dN.1 15us : touch_softlockup_watchdog <-tick_nohz_idle_exit + <idle>-0 3dN.1 15us : hrtimer_cancel <-tick_nohz_idle_exit + <idle>-0 3dN.1 15us : hrtimer_try_to_cancel <-hrtimer_cancel + <idle>-0 3dN.1 16us : lock_hrtimer_base.isra.18 <-hrtimer_try_to_cancel + <idle>-0 3dN.1 16us : _raw_spin_lock_irqsave <-lock_hrtimer_base.isra.18 + <idle>-0 3dN.1 16us : add_preempt_count <-_raw_spin_lock_irqsave + <idle>-0 3dN.2 17us : __remove_hrtimer <-remove_hrtimer.part.16 + <idle>-0 3dN.2 17us : hrtimer_force_reprogram <-__remove_hrtimer + <idle>-0 3dN.2 17us : tick_program_event <-hrtimer_force_reprogram + <idle>-0 3dN.2 18us : clockevents_program_event <-tick_program_event + <idle>-0 3dN.2 18us : ktime_get <-clockevents_program_event + <idle>-0 3dN.2 18us : lapic_next_event <-clockevents_program_event + <idle>-0 3dN.2 19us : _raw_spin_unlock_irqrestore <-hrtimer_try_to_cancel + <idle>-0 3dN.2 19us : sub_preempt_count <-_raw_spin_unlock_irqrestore + <idle>-0 3dN.1 19us : hrtimer_forward <-tick_nohz_idle_exit + <idle>-0 3dN.1 20us : ktime_add_safe <-hrtimer_forward + <idle>-0 3dN.1 20us : ktime_add_safe <-hrtimer_forward + <idle>-0 3dN.1 20us : hrtimer_start_range_ns <-hrtimer_start_expires.constprop.11 + <idle>-0 3dN.1 20us : __hrtimer_start_range_ns <-hrtimer_start_range_ns + <idle>-0 3dN.1 21us : lock_hrtimer_base.isra.18 <-__hrtimer_start_range_ns + <idle>-0 3dN.1 21us : _raw_spin_lock_irqsave <-lock_hrtimer_base.isra.18 + <idle>-0 3dN.1 21us : add_preempt_count <-_raw_spin_lock_irqsave + <idle>-0 3dN.2 22us : ktime_add_safe <-__hrtimer_start_range_ns + <idle>-0 3dN.2 22us : enqueue_hrtimer <-__hrtimer_start_range_ns + <idle>-0 3dN.2 22us : tick_program_event <-__hrtimer_start_range_ns + <idle>-0 3dN.2 23us : clockevents_program_event <-tick_program_event + <idle>-0 3dN.2 23us : ktime_get <-clockevents_program_event + <idle>-0 3dN.2 23us : lapic_next_event <-clockevents_program_event + <idle>-0 3dN.2 24us : _raw_spin_unlock_irqrestore <-__hrtimer_start_range_ns + <idle>-0 3dN.2 24us : sub_preempt_count <-_raw_spin_unlock_irqrestore + <idle>-0 3dN.1 24us : account_idle_ticks <-tick_nohz_idle_exit + <idle>-0 3dN.1 24us : account_idle_time <-account_idle_ticks + <idle>-0 3.N.1 25us : sub_preempt_count <-cpu_idle + <idle>-0 3.N.. 25us : schedule <-cpu_idle + <idle>-0 3.N.. 25us : __schedule <-preempt_schedule + <idle>-0 3.N.. 26us : add_preempt_count <-__schedule + <idle>-0 3.N.1 26us : rcu_note_context_switch <-__schedule + <idle>-0 3.N.1 26us : rcu_sched_qs <-rcu_note_context_switch + <idle>-0 3dN.1 27us : rcu_preempt_qs <-rcu_note_context_switch + <idle>-0 3.N.1 27us : _raw_spin_lock_irq <-__schedule + <idle>-0 3dN.1 27us : add_preempt_count <-_raw_spin_lock_irq + <idle>-0 3dN.2 28us : put_prev_task_idle <-__schedule + <idle>-0 3dN.2 28us : pick_next_task_stop <-pick_next_task + <idle>-0 3dN.2 28us : pick_next_task_rt <-pick_next_task + <idle>-0 3dN.2 29us : dequeue_pushable_task <-pick_next_task_rt + <idle>-0 3d..3 29us : __schedule <-preempt_schedule + <idle>-0 3d..3 30us : 0:120:R ==> [003] 2448: 94:R sleep + +This isn't that big of a trace, even with function tracing enabled, +so I included the entire trace. + +The interrupt went off while when the system was idle. Somewhere +before task_woken_rt() was called, the NEED_RESCHED flag was set, +this is indicated by the first occurrence of the 'N' flag. + +Latency tracing and events +-------------------------- +As function tracing can induce a much larger latency, but without +seeing what happens within the latency it is hard to know what +caused it. There is a middle ground, and that is with enabling +events. +:: + + # echo 0 > options/function-trace + # echo wakeup_rt > current_tracer + # echo 1 > events/enable + # echo 1 > tracing_on + # echo 0 > tracing_max_latency + # chrt -f 5 sleep 1 + # echo 0 > tracing_on + # cat trace + # tracer: wakeup_rt + # + # wakeup_rt latency trace v1.1.5 on 3.8.0-test+ + # -------------------------------------------------------------------- + # latency: 6 us, #12/12, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) + # ----------------- + # | task: sleep-5882 (uid:0 nice:0 policy:1 rt_prio:5) + # ----------------- + # + # _------=> CPU# + # / _-----=> irqs-off + # | / _----=> need-resched + # || / _---=> hardirq/softirq + # ||| / _--=> preempt-depth + # |||| / delay + # cmd pid ||||| time | caller + # \ / ||||| \ | / + <idle>-0 2d.h4 0us : 0:120:R + [002] 5882: 94:R sleep + <idle>-0 2d.h4 0us : ttwu_do_activate.constprop.87 <-try_to_wake_up + <idle>-0 2d.h4 1us : sched_wakeup: comm=sleep pid=5882 prio=94 success=1 target_cpu=002 + <idle>-0 2dNh2 1us : hrtimer_expire_exit: hrtimer=ffff88007796feb8 + <idle>-0 2.N.2 2us : power_end: cpu_id=2 + <idle>-0 2.N.2 3us : cpu_idle: state=4294967295 cpu_id=2 + <idle>-0 2dN.3 4us : hrtimer_cancel: hrtimer=ffff88007d50d5e0 + <idle>-0 2dN.3 4us : hrtimer_start: hrtimer=ffff88007d50d5e0 function=tick_sched_timer expires=34311211000000 softexpires=34311211000000 + <idle>-0 2.N.2 5us : rcu_utilization: Start context switch + <idle>-0 2.N.2 5us : rcu_utilization: End context switch + <idle>-0 2d..3 6us : __schedule <-schedule + <idle>-0 2d..3 6us : 0:120:R ==> [002] 5882: 94:R sleep + + +Hardware Latency Detector +------------------------- + +The hardware latency detector is executed by enabling the "hwlat" tracer. + +NOTE, this tracer will affect the performance of the system as it will +periodically make a CPU constantly busy with interrupts disabled. +:: + + # echo hwlat > current_tracer + # sleep 100 + # cat trace + # tracer: hwlat + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + <...>-3638 [001] d... 19452.055471: #1 inner/outer(us): 12/14 ts:1499801089.066141940 + <...>-3638 [003] d... 19454.071354: #2 inner/outer(us): 11/9 ts:1499801091.082164365 + <...>-3638 [002] dn.. 19461.126852: #3 inner/outer(us): 12/9 ts:1499801098.138150062 + <...>-3638 [001] d... 19488.340960: #4 inner/outer(us): 8/12 ts:1499801125.354139633 + <...>-3638 [003] d... 19494.388553: #5 inner/outer(us): 8/12 ts:1499801131.402150961 + <...>-3638 [003] d... 19501.283419: #6 inner/outer(us): 0/12 ts:1499801138.297435289 nmi-total:4 nmi-count:1 + + +The above output is somewhat the same in the header. All events will have +interrupts disabled 'd'. Under the FUNCTION title there is: + + #1 + This is the count of events recorded that were greater than the + tracing_threshold (See below). + + inner/outer(us): 12/14 + + This shows two numbers as "inner latency" and "outer latency". The test + runs in a loop checking a timestamp twice. The latency detected within + the two timestamps is the "inner latency" and the latency detected + after the previous timestamp and the next timestamp in the loop is + the "outer latency". + + ts:1499801089.066141940 + + The absolute timestamp that the event happened. + + nmi-total:4 nmi-count:1 + + On architectures that support it, if an NMI comes in during the + test, the time spent in NMI is reported in "nmi-total" (in + microseconds). + + All architectures that have NMIs will show the "nmi-count" if an + NMI comes in during the test. + +hwlat files: + + tracing_threshold + This gets automatically set to "10" to represent 10 + microseconds. This is the threshold of latency that + needs to be detected before the trace will be recorded. + + Note, when hwlat tracer is finished (another tracer is + written into "current_tracer"), the original value for + tracing_threshold is placed back into this file. + + hwlat_detector/width + The length of time the test runs with interrupts disabled. + + hwlat_detector/window + The length of time of the window which the test + runs. That is, the test will run for "width" + microseconds per "window" microseconds + + tracing_cpumask + When the test is started. A kernel thread is created that + runs the test. This thread will alternate between CPUs + listed in the tracing_cpumask between each period + (one "window"). To limit the test to specific CPUs + set the mask in this file to only the CPUs that the test + should run on. + +function +-------- + +This tracer is the function tracer. Enabling the function tracer +can be done from the debug file system. Make sure the +ftrace_enabled is set; otherwise this tracer is a nop. +See the "ftrace_enabled" section below. +:: + + # sysctl kernel.ftrace_enabled=1 + # echo function > current_tracer + # echo 1 > tracing_on + # usleep 1 + # echo 0 > tracing_on + # cat trace + # tracer: function + # + # entries-in-buffer/entries-written: 24799/24799 #P:4 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + bash-1994 [002] .... 3082.063030: mutex_unlock <-rb_simple_write + bash-1994 [002] .... 3082.063031: __mutex_unlock_slowpath <-mutex_unlock + bash-1994 [002] .... 3082.063031: __fsnotify_parent <-fsnotify_modify + bash-1994 [002] .... 3082.063032: fsnotify <-fsnotify_modify + bash-1994 [002] .... 3082.063032: __srcu_read_lock <-fsnotify + bash-1994 [002] .... 3082.063032: add_preempt_count <-__srcu_read_lock + bash-1994 [002] ...1 3082.063032: sub_preempt_count <-__srcu_read_lock + bash-1994 [002] .... 3082.063033: __srcu_read_unlock <-fsnotify + [...] + + +Note: function tracer uses ring buffers to store the above +entries. The newest data may overwrite the oldest data. +Sometimes using echo to stop the trace is not sufficient because +the tracing could have overwritten the data that you wanted to +record. For this reason, it is sometimes better to disable +tracing directly from a program. This allows you to stop the +tracing at the point that you hit the part that you are +interested in. To disable the tracing directly from a C program, +something like following code snippet can be used:: + + int trace_fd; + [...] + int main(int argc, char *argv[]) { + [...] + trace_fd = open(tracing_file("tracing_on"), O_WRONLY); + [...] + if (condition_hit()) { + write(trace_fd, "0", 1); + } + [...] + } + + +Single thread tracing +--------------------- + +By writing into set_ftrace_pid you can trace a +single thread. For example:: + + # cat set_ftrace_pid + no pid + # echo 3111 > set_ftrace_pid + # cat set_ftrace_pid + 3111 + # echo function > current_tracer + # cat trace | head + # tracer: function + # + # TASK-PID CPU# TIMESTAMP FUNCTION + # | | | | | + yum-updatesd-3111 [003] 1637.254676: finish_task_switch <-thread_return + yum-updatesd-3111 [003] 1637.254681: hrtimer_cancel <-schedule_hrtimeout_range + yum-updatesd-3111 [003] 1637.254682: hrtimer_try_to_cancel <-hrtimer_cancel + yum-updatesd-3111 [003] 1637.254683: lock_hrtimer_base <-hrtimer_try_to_cancel + yum-updatesd-3111 [003] 1637.254685: fget_light <-do_sys_poll + yum-updatesd-3111 [003] 1637.254686: pipe_poll <-do_sys_poll + # echo > set_ftrace_pid + # cat trace |head + # tracer: function + # + # TASK-PID CPU# TIMESTAMP FUNCTION + # | | | | | + ##### CPU 3 buffer started #### + yum-updatesd-3111 [003] 1701.957688: free_poll_entry <-poll_freewait + yum-updatesd-3111 [003] 1701.957689: remove_wait_queue <-free_poll_entry + yum-updatesd-3111 [003] 1701.957691: fput <-free_poll_entry + yum-updatesd-3111 [003] 1701.957692: audit_syscall_exit <-sysret_audit + yum-updatesd-3111 [003] 1701.957693: path_put <-audit_syscall_exit + +If you want to trace a function when executing, you could use +something like this simple program. +:: + + #include <stdio.h> + #include <stdlib.h> + #include <sys/types.h> + #include <sys/stat.h> + #include <fcntl.h> + #include <unistd.h> + #include <string.h> + + #define _STR(x) #x + #define STR(x) _STR(x) + #define MAX_PATH 256 + + const char *find_tracefs(void) + { + static char tracefs[MAX_PATH+1]; + static int tracefs_found; + char type[100]; + FILE *fp; + + if (tracefs_found) + return tracefs; + + if ((fp = fopen("/proc/mounts","r")) == NULL) { + perror("/proc/mounts"); + return NULL; + } + + while (fscanf(fp, "%*s %" + STR(MAX_PATH) + "s %99s %*s %*d %*d\n", + tracefs, type) == 2) { + if (strcmp(type, "tracefs") == 0) + break; + } + fclose(fp); + + if (strcmp(type, "tracefs") != 0) { + fprintf(stderr, "tracefs not mounted"); + return NULL; + } + + strcat(tracefs, "/tracing/"); + tracefs_found = 1; + + return tracefs; + } + + const char *tracing_file(const char *file_name) + { + static char trace_file[MAX_PATH+1]; + snprintf(trace_file, MAX_PATH, "%s/%s", find_tracefs(), file_name); + return trace_file; + } + + int main (int argc, char **argv) + { + if (argc < 1) + exit(-1); + + if (fork() > 0) { + int fd, ffd; + char line[64]; + int s; + + ffd = open(tracing_file("current_tracer"), O_WRONLY); + if (ffd < 0) + exit(-1); + write(ffd, "nop", 3); + + fd = open(tracing_file("set_ftrace_pid"), O_WRONLY); + s = sprintf(line, "%d\n", getpid()); + write(fd, line, s); + + write(ffd, "function", 8); + + close(fd); + close(ffd); + + execvp(argv[1], argv+1); + } + + return 0; + } + +Or this simple script! +:: + + #!/bin/bash + + tracefs=`sed -ne 's/^tracefs \(.*\) tracefs.*/\1/p' /proc/mounts` + echo nop > $tracefs/tracing/current_tracer + echo 0 > $tracefs/tracing/tracing_on + echo $$ > $tracefs/tracing/set_ftrace_pid + echo function > $tracefs/tracing/current_tracer + echo 1 > $tracefs/tracing/tracing_on + exec "$@" + + +function graph tracer +--------------------------- + +This tracer is similar to the function tracer except that it +probes a function on its entry and its exit. This is done by +using a dynamically allocated stack of return addresses in each +task_struct. On function entry the tracer overwrites the return +address of each function traced to set a custom probe. Thus the +original return address is stored on the stack of return address +in the task_struct. + +Probing on both ends of a function leads to special features +such as: + +- measure of a function's time execution +- having a reliable call stack to draw function calls graph + +This tracer is useful in several situations: + +- you want to find the reason of a strange kernel behavior and + need to see what happens in detail on any areas (or specific + ones). + +- you are experiencing weird latencies but it's difficult to + find its origin. + +- you want to find quickly which path is taken by a specific + function + +- you just want to peek inside a working kernel and want to see + what happens there. + +:: + + # tracer: function_graph + # + # CPU DURATION FUNCTION CALLS + # | | | | | | | + + 0) | sys_open() { + 0) | do_sys_open() { + 0) | getname() { + 0) | kmem_cache_alloc() { + 0) 1.382 us | __might_sleep(); + 0) 2.478 us | } + 0) | strncpy_from_user() { + 0) | might_fault() { + 0) 1.389 us | __might_sleep(); + 0) 2.553 us | } + 0) 3.807 us | } + 0) 7.876 us | } + 0) | alloc_fd() { + 0) 0.668 us | _spin_lock(); + 0) 0.570 us | expand_files(); + 0) 0.586 us | _spin_unlock(); + + +There are several columns that can be dynamically +enabled/disabled. You can use every combination of options you +want, depending on your needs. + +- The cpu number on which the function executed is default + enabled. It is sometimes better to only trace one cpu (see + tracing_cpu_mask file) or you might sometimes see unordered + function calls while cpu tracing switch. + + - hide: echo nofuncgraph-cpu > trace_options + - show: echo funcgraph-cpu > trace_options + +- The duration (function's time of execution) is displayed on + the closing bracket line of a function or on the same line + than the current function in case of a leaf one. It is default + enabled. + + - hide: echo nofuncgraph-duration > trace_options + - show: echo funcgraph-duration > trace_options + +- The overhead field precedes the duration field in case of + reached duration thresholds. + + - hide: echo nofuncgraph-overhead > trace_options + - show: echo funcgraph-overhead > trace_options + - depends on: funcgraph-duration + + ie:: + + 3) # 1837.709 us | } /* __switch_to */ + 3) | finish_task_switch() { + 3) 0.313 us | _raw_spin_unlock_irq(); + 3) 3.177 us | } + 3) # 1889.063 us | } /* __schedule */ + 3) ! 140.417 us | } /* __schedule */ + 3) # 2034.948 us | } /* schedule */ + 3) * 33998.59 us | } /* schedule_preempt_disabled */ + + [...] + + 1) 0.260 us | msecs_to_jiffies(); + 1) 0.313 us | __rcu_read_unlock(); + 1) + 61.770 us | } + 1) + 64.479 us | } + 1) 0.313 us | rcu_bh_qs(); + 1) 0.313 us | __local_bh_enable(); + 1) ! 217.240 us | } + 1) 0.365 us | idle_cpu(); + 1) | rcu_irq_exit() { + 1) 0.417 us | rcu_eqs_enter_common.isra.47(); + 1) 3.125 us | } + 1) ! 227.812 us | } + 1) ! 457.395 us | } + 1) @ 119760.2 us | } + + [...] + + 2) | handle_IPI() { + 1) 6.979 us | } + 2) 0.417 us | scheduler_ipi(); + 1) 9.791 us | } + 1) + 12.917 us | } + 2) 3.490 us | } + 1) + 15.729 us | } + 1) + 18.542 us | } + 2) $ 3594274 us | } + +Flags:: + + + means that the function exceeded 10 usecs. + ! means that the function exceeded 100 usecs. + # means that the function exceeded 1000 usecs. + * means that the function exceeded 10 msecs. + @ means that the function exceeded 100 msecs. + $ means that the function exceeded 1 sec. + + +- The task/pid field displays the thread cmdline and pid which + executed the function. It is default disabled. + + - hide: echo nofuncgraph-proc > trace_options + - show: echo funcgraph-proc > trace_options + + ie:: + + # tracer: function_graph + # + # CPU TASK/PID DURATION FUNCTION CALLS + # | | | | | | | | | + 0) sh-4802 | | d_free() { + 0) sh-4802 | | call_rcu() { + 0) sh-4802 | | __call_rcu() { + 0) sh-4802 | 0.616 us | rcu_process_gp_end(); + 0) sh-4802 | 0.586 us | check_for_new_grace_period(); + 0) sh-4802 | 2.899 us | } + 0) sh-4802 | 4.040 us | } + 0) sh-4802 | 5.151 us | } + 0) sh-4802 | + 49.370 us | } + + +- The absolute time field is an absolute timestamp given by the + system clock since it started. A snapshot of this time is + given on each entry/exit of functions + + - hide: echo nofuncgraph-abstime > trace_options + - show: echo funcgraph-abstime > trace_options + + ie:: + + # + # TIME CPU DURATION FUNCTION CALLS + # | | | | | | | | + 360.774522 | 1) 0.541 us | } + 360.774522 | 1) 4.663 us | } + 360.774523 | 1) 0.541 us | __wake_up_bit(); + 360.774524 | 1) 6.796 us | } + 360.774524 | 1) 7.952 us | } + 360.774525 | 1) 9.063 us | } + 360.774525 | 1) 0.615 us | journal_mark_dirty(); + 360.774527 | 1) 0.578 us | __brelse(); + 360.774528 | 1) | reiserfs_prepare_for_journal() { + 360.774528 | 1) | unlock_buffer() { + 360.774529 | 1) | wake_up_bit() { + 360.774529 | 1) | bit_waitqueue() { + 360.774530 | 1) 0.594 us | __phys_addr(); + + +The function name is always displayed after the closing bracket +for a function if the start of that function is not in the +trace buffer. + +Display of the function name after the closing bracket may be +enabled for functions whose start is in the trace buffer, +allowing easier searching with grep for function durations. +It is default disabled. + + - hide: echo nofuncgraph-tail > trace_options + - show: echo funcgraph-tail > trace_options + + Example with nofuncgraph-tail (default):: + + 0) | putname() { + 0) | kmem_cache_free() { + 0) 0.518 us | __phys_addr(); + 0) 1.757 us | } + 0) 2.861 us | } + + Example with funcgraph-tail:: + + 0) | putname() { + 0) | kmem_cache_free() { + 0) 0.518 us | __phys_addr(); + 0) 1.757 us | } /* kmem_cache_free() */ + 0) 2.861 us | } /* putname() */ + +You can put some comments on specific functions by using +trace_printk() For example, if you want to put a comment inside +the __might_sleep() function, you just have to include +<linux/ftrace.h> and call trace_printk() inside __might_sleep():: + + trace_printk("I'm a comment!\n") + +will produce:: + + 1) | __might_sleep() { + 1) | /* I'm a comment! */ + 1) 1.449 us | } + + +You might find other useful features for this tracer in the +following "dynamic ftrace" section such as tracing only specific +functions or tasks. + +dynamic ftrace +-------------- + +If CONFIG_DYNAMIC_FTRACE is set, the system will run with +virtually no overhead when function tracing is disabled. The way +this works is the mcount function call (placed at the start of +every kernel function, produced by the -pg switch in gcc), +starts of pointing to a simple return. (Enabling FTRACE will +include the -pg switch in the compiling of the kernel.) + +At compile time every C file object is run through the +recordmcount program (located in the scripts directory). This +program will parse the ELF headers in the C object to find all +the locations in the .text section that call mcount. Starting +with gcc verson 4.6, the -mfentry has been added for x86, which +calls "__fentry__" instead of "mcount". Which is called before +the creation of the stack frame. + +Note, not all sections are traced. They may be prevented by either +a notrace, or blocked another way and all inline functions are not +traced. Check the "available_filter_functions" file to see what functions +can be traced. + +A section called "__mcount_loc" is created that holds +references to all the mcount/fentry call sites in the .text section. +The recordmcount program re-links this section back into the +original object. The final linking stage of the kernel will add all these +references into a single table. + +On boot up, before SMP is initialized, the dynamic ftrace code +scans this table and updates all the locations into nops. It +also records the locations, which are added to the +available_filter_functions list. Modules are processed as they +are loaded and before they are executed. When a module is +unloaded, it also removes its functions from the ftrace function +list. This is automatic in the module unload code, and the +module author does not need to worry about it. + +When tracing is enabled, the process of modifying the function +tracepoints is dependent on architecture. The old method is to use +kstop_machine to prevent races with the CPUs executing code being +modified (which can cause the CPU to do undesirable things, especially +if the modified code crosses cache (or page) boundaries), and the nops are +patched back to calls. But this time, they do not call mcount +(which is just a function stub). They now call into the ftrace +infrastructure. + +The new method of modifying the function tracepoints is to place +a breakpoint at the location to be modified, sync all CPUs, modify +the rest of the instruction not covered by the breakpoint. Sync +all CPUs again, and then remove the breakpoint with the finished +version to the ftrace call site. + +Some archs do not even need to monkey around with the synchronization, +and can just slap the new code on top of the old without any +problems with other CPUs executing it at the same time. + +One special side-effect to the recording of the functions being +traced is that we can now selectively choose which functions we +wish to trace and which ones we want the mcount calls to remain +as nops. + +Two files are used, one for enabling and one for disabling the +tracing of specified functions. They are: + + set_ftrace_filter + +and + + set_ftrace_notrace + +A list of available functions that you can add to these files is +listed in: + + available_filter_functions + +:: + + # cat available_filter_functions + put_prev_task_idle + kmem_cache_create + pick_next_task_rt + get_online_cpus + pick_next_task_fair + mutex_lock + [...] + +If I am only interested in sys_nanosleep and hrtimer_interrupt:: + + # echo sys_nanosleep hrtimer_interrupt > set_ftrace_filter + # echo function > current_tracer + # echo 1 > tracing_on + # usleep 1 + # echo 0 > tracing_on + # cat trace + # tracer: function + # + # entries-in-buffer/entries-written: 5/5 #P:4 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + usleep-2665 [001] .... 4186.475355: sys_nanosleep <-system_call_fastpath + <idle>-0 [001] d.h1 4186.475409: hrtimer_interrupt <-smp_apic_timer_interrupt + usleep-2665 [001] d.h1 4186.475426: hrtimer_interrupt <-smp_apic_timer_interrupt + <idle>-0 [003] d.h1 4186.475426: hrtimer_interrupt <-smp_apic_timer_interrupt + <idle>-0 [002] d.h1 4186.475427: hrtimer_interrupt <-smp_apic_timer_interrupt + +To see which functions are being traced, you can cat the file: +:: + + # cat set_ftrace_filter + hrtimer_interrupt + sys_nanosleep + + +Perhaps this is not enough. The filters also allow glob(7) matching. + + ``<match>*`` + will match functions that begin with <match> + ``*<match>`` + will match functions that end with <match> + ``*<match>*`` + will match functions that have <match> in it + ``<match1>*<match2>`` + will match functions that begin with <match1> and end with <match2> + +.. note:: + It is better to use quotes to enclose the wild cards, + otherwise the shell may expand the parameters into names + of files in the local directory. + +:: + + # echo 'hrtimer_*' > set_ftrace_filter + +Produces:: + + # tracer: function + # + # entries-in-buffer/entries-written: 897/897 #P:4 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + <idle>-0 [003] dN.1 4228.547803: hrtimer_cancel <-tick_nohz_idle_exit + <idle>-0 [003] dN.1 4228.547804: hrtimer_try_to_cancel <-hrtimer_cancel + <idle>-0 [003] dN.2 4228.547805: hrtimer_force_reprogram <-__remove_hrtimer + <idle>-0 [003] dN.1 4228.547805: hrtimer_forward <-tick_nohz_idle_exit + <idle>-0 [003] dN.1 4228.547805: hrtimer_start_range_ns <-hrtimer_start_expires.constprop.11 + <idle>-0 [003] d..1 4228.547858: hrtimer_get_next_event <-get_next_timer_interrupt + <idle>-0 [003] d..1 4228.547859: hrtimer_start <-__tick_nohz_idle_enter + <idle>-0 [003] d..2 4228.547860: hrtimer_force_reprogram <-__rem + +Notice that we lost the sys_nanosleep. +:: + + # cat set_ftrace_filter + hrtimer_run_queues + hrtimer_run_pending + hrtimer_init + hrtimer_cancel + hrtimer_try_to_cancel + hrtimer_forward + hrtimer_start + hrtimer_reprogram + hrtimer_force_reprogram + hrtimer_get_next_event + hrtimer_interrupt + hrtimer_nanosleep + hrtimer_wakeup + hrtimer_get_remaining + hrtimer_get_res + hrtimer_init_sleeper + + +This is because the '>' and '>>' act just like they do in bash. +To rewrite the filters, use '>' +To append to the filters, use '>>' + +To clear out a filter so that all functions will be recorded +again:: + + # echo > set_ftrace_filter + # cat set_ftrace_filter + # + +Again, now we want to append. + +:: + + # echo sys_nanosleep > set_ftrace_filter + # cat set_ftrace_filter + sys_nanosleep + # echo 'hrtimer_*' >> set_ftrace_filter + # cat set_ftrace_filter + hrtimer_run_queues + hrtimer_run_pending + hrtimer_init + hrtimer_cancel + hrtimer_try_to_cancel + hrtimer_forward + hrtimer_start + hrtimer_reprogram + hrtimer_force_reprogram + hrtimer_get_next_event + hrtimer_interrupt + sys_nanosleep + hrtimer_nanosleep + hrtimer_wakeup + hrtimer_get_remaining + hrtimer_get_res + hrtimer_init_sleeper + + +The set_ftrace_notrace prevents those functions from being +traced. +:: + + # echo '*preempt*' '*lock*' > set_ftrace_notrace + +Produces:: + + # tracer: function + # + # entries-in-buffer/entries-written: 39608/39608 #P:4 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + bash-1994 [000] .... 4342.324896: file_ra_state_init <-do_dentry_open + bash-1994 [000] .... 4342.324897: open_check_o_direct <-do_last + bash-1994 [000] .... 4342.324897: ima_file_check <-do_last + bash-1994 [000] .... 4342.324898: process_measurement <-ima_file_check + bash-1994 [000] .... 4342.324898: ima_get_action <-process_measurement + bash-1994 [000] .... 4342.324898: ima_match_policy <-ima_get_action + bash-1994 [000] .... 4342.324899: do_truncate <-do_last + bash-1994 [000] .... 4342.324899: should_remove_suid <-do_truncate + bash-1994 [000] .... 4342.324899: notify_change <-do_truncate + bash-1994 [000] .... 4342.324900: current_fs_time <-notify_change + bash-1994 [000] .... 4342.324900: current_kernel_time <-current_fs_time + bash-1994 [000] .... 4342.324900: timespec_trunc <-current_fs_time + +We can see that there's no more lock or preempt tracing. + + +Dynamic ftrace with the function graph tracer +--------------------------------------------- + +Although what has been explained above concerns both the +function tracer and the function-graph-tracer, there are some +special features only available in the function-graph tracer. + +If you want to trace only one function and all of its children, +you just have to echo its name into set_graph_function:: + + echo __do_fault > set_graph_function + +will produce the following "expanded" trace of the __do_fault() +function:: + + 0) | __do_fault() { + 0) | filemap_fault() { + 0) | find_lock_page() { + 0) 0.804 us | find_get_page(); + 0) | __might_sleep() { + 0) 1.329 us | } + 0) 3.904 us | } + 0) 4.979 us | } + 0) 0.653 us | _spin_lock(); + 0) 0.578 us | page_add_file_rmap(); + 0) 0.525 us | native_set_pte_at(); + 0) 0.585 us | _spin_unlock(); + 0) | unlock_page() { + 0) 0.541 us | page_waitqueue(); + 0) 0.639 us | __wake_up_bit(); + 0) 2.786 us | } + 0) + 14.237 us | } + 0) | __do_fault() { + 0) | filemap_fault() { + 0) | find_lock_page() { + 0) 0.698 us | find_get_page(); + 0) | __might_sleep() { + 0) 1.412 us | } + 0) 3.950 us | } + 0) 5.098 us | } + 0) 0.631 us | _spin_lock(); + 0) 0.571 us | page_add_file_rmap(); + 0) 0.526 us | native_set_pte_at(); + 0) 0.586 us | _spin_unlock(); + 0) | unlock_page() { + 0) 0.533 us | page_waitqueue(); + 0) 0.638 us | __wake_up_bit(); + 0) 2.793 us | } + 0) + 14.012 us | } + +You can also expand several functions at once:: + + echo sys_open > set_graph_function + echo sys_close >> set_graph_function + +Now if you want to go back to trace all functions you can clear +this special filter via:: + + echo > set_graph_function + + +ftrace_enabled +-------------- + +Note, the proc sysctl ftrace_enable is a big on/off switch for the +function tracer. By default it is enabled (when function tracing is +enabled in the kernel). If it is disabled, all function tracing is +disabled. This includes not only the function tracers for ftrace, but +also for any other uses (perf, kprobes, stack tracing, profiling, etc). + +Please disable this with care. + +This can be disable (and enabled) with:: + + sysctl kernel.ftrace_enabled=0 + sysctl kernel.ftrace_enabled=1 + + or + + echo 0 > /proc/sys/kernel/ftrace_enabled + echo 1 > /proc/sys/kernel/ftrace_enabled + + +Filter commands +--------------- + +A few commands are supported by the set_ftrace_filter interface. +Trace commands have the following format:: + + <function>:<command>:<parameter> + +The following commands are supported: + +- mod: + This command enables function filtering per module. The + parameter defines the module. For example, if only the write* + functions in the ext3 module are desired, run: + + echo 'write*:mod:ext3' > set_ftrace_filter + + This command interacts with the filter in the same way as + filtering based on function names. Thus, adding more functions + in a different module is accomplished by appending (>>) to the + filter file. Remove specific module functions by prepending + '!':: + + echo '!writeback*:mod:ext3' >> set_ftrace_filter + + Mod command supports module globbing. Disable tracing for all + functions except a specific module:: + + echo '!*:mod:!ext3' >> set_ftrace_filter + + Disable tracing for all modules, but still trace kernel:: + + echo '!*:mod:*' >> set_ftrace_filter + + Enable filter only for kernel:: + + echo '*write*:mod:!*' >> set_ftrace_filter + + Enable filter for module globbing:: + + echo '*write*:mod:*snd*' >> set_ftrace_filter + +- traceon/traceoff: + These commands turn tracing on and off when the specified + functions are hit. The parameter determines how many times the + tracing system is turned on and off. If unspecified, there is + no limit. For example, to disable tracing when a schedule bug + is hit the first 5 times, run:: + + echo '__schedule_bug:traceoff:5' > set_ftrace_filter + + To always disable tracing when __schedule_bug is hit:: + + echo '__schedule_bug:traceoff' > set_ftrace_filter + + These commands are cumulative whether or not they are appended + to set_ftrace_filter. To remove a command, prepend it by '!' + and drop the parameter:: + + echo '!__schedule_bug:traceoff:0' > set_ftrace_filter + + The above removes the traceoff command for __schedule_bug + that have a counter. To remove commands without counters:: + + echo '!__schedule_bug:traceoff' > set_ftrace_filter + +- snapshot: + Will cause a snapshot to be triggered when the function is hit. + :: + + echo 'native_flush_tlb_others:snapshot' > set_ftrace_filter + + To only snapshot once: + :: + + echo 'native_flush_tlb_others:snapshot:1' > set_ftrace_filter + + To remove the above commands:: + + echo '!native_flush_tlb_others:snapshot' > set_ftrace_filter + echo '!native_flush_tlb_others:snapshot:0' > set_ftrace_filter + +- enable_event/disable_event: + These commands can enable or disable a trace event. Note, because + function tracing callbacks are very sensitive, when these commands + are registered, the trace point is activated, but disabled in + a "soft" mode. That is, the tracepoint will be called, but + just will not be traced. The event tracepoint stays in this mode + as long as there's a command that triggers it. + :: + + echo 'try_to_wake_up:enable_event:sched:sched_switch:2' > \ + set_ftrace_filter + + The format is:: + + <function>:enable_event:<system>:<event>[:count] + <function>:disable_event:<system>:<event>[:count] + + To remove the events commands:: + + echo '!try_to_wake_up:enable_event:sched:sched_switch:0' > \ + set_ftrace_filter + echo '!schedule:disable_event:sched:sched_switch' > \ + set_ftrace_filter + +- dump: + When the function is hit, it will dump the contents of the ftrace + ring buffer to the console. This is useful if you need to debug + something, and want to dump the trace when a certain function + is hit. Perhaps its a function that is called before a tripple + fault happens and does not allow you to get a regular dump. + +- cpudump: + When the function is hit, it will dump the contents of the ftrace + ring buffer for the current CPU to the console. Unlike the "dump" + command, it only prints out the contents of the ring buffer for the + CPU that executed the function that triggered the dump. + +trace_pipe +---------- + +The trace_pipe outputs the same content as the trace file, but +the effect on the tracing is different. Every read from +trace_pipe is consumed. This means that subsequent reads will be +different. The trace is live. +:: + + # echo function > current_tracer + # cat trace_pipe > /tmp/trace.out & + [1] 4153 + # echo 1 > tracing_on + # usleep 1 + # echo 0 > tracing_on + # cat trace + # tracer: function + # + # entries-in-buffer/entries-written: 0/0 #P:4 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + + # + # cat /tmp/trace.out + bash-1994 [000] .... 5281.568961: mutex_unlock <-rb_simple_write + bash-1994 [000] .... 5281.568963: __mutex_unlock_slowpath <-mutex_unlock + bash-1994 [000] .... 5281.568963: __fsnotify_parent <-fsnotify_modify + bash-1994 [000] .... 5281.568964: fsnotify <-fsnotify_modify + bash-1994 [000] .... 5281.568964: __srcu_read_lock <-fsnotify + bash-1994 [000] .... 5281.568964: add_preempt_count <-__srcu_read_lock + bash-1994 [000] ...1 5281.568965: sub_preempt_count <-__srcu_read_lock + bash-1994 [000] .... 5281.568965: __srcu_read_unlock <-fsnotify + bash-1994 [000] .... 5281.568967: sys_dup2 <-system_call_fastpath + + +Note, reading the trace_pipe file will block until more input is +added. + +trace entries +------------- + +Having too much or not enough data can be troublesome in +diagnosing an issue in the kernel. The file buffer_size_kb is +used to modify the size of the internal trace buffers. The +number listed is the number of entries that can be recorded per +CPU. To know the full size, multiply the number of possible CPUs +with the number of entries. +:: + + # cat buffer_size_kb + 1408 (units kilobytes) + +Or simply read buffer_total_size_kb +:: + + # cat buffer_total_size_kb + 5632 + +To modify the buffer, simple echo in a number (in 1024 byte segments). +:: + + # echo 10000 > buffer_size_kb + # cat buffer_size_kb + 10000 (units kilobytes) + +It will try to allocate as much as possible. If you allocate too +much, it can cause Out-Of-Memory to trigger. +:: + + # echo 1000000000000 > buffer_size_kb + -bash: echo: write error: Cannot allocate memory + # cat buffer_size_kb + 85 + +The per_cpu buffers can be changed individually as well: +:: + + # echo 10000 > per_cpu/cpu0/buffer_size_kb + # echo 100 > per_cpu/cpu1/buffer_size_kb + +When the per_cpu buffers are not the same, the buffer_size_kb +at the top level will just show an X +:: + + # cat buffer_size_kb + X + +This is where the buffer_total_size_kb is useful: +:: + + # cat buffer_total_size_kb + 12916 + +Writing to the top level buffer_size_kb will reset all the buffers +to be the same again. + +Snapshot +-------- +CONFIG_TRACER_SNAPSHOT makes a generic snapshot feature +available to all non latency tracers. (Latency tracers which +record max latency, such as "irqsoff" or "wakeup", can't use +this feature, since those are already using the snapshot +mechanism internally.) + +Snapshot preserves a current trace buffer at a particular point +in time without stopping tracing. Ftrace swaps the current +buffer with a spare buffer, and tracing continues in the new +current (=previous spare) buffer. + +The following tracefs files in "tracing" are related to this +feature: + + snapshot: + + This is used to take a snapshot and to read the output + of the snapshot. Echo 1 into this file to allocate a + spare buffer and to take a snapshot (swap), then read + the snapshot from this file in the same format as + "trace" (described above in the section "The File + System"). Both reads snapshot and tracing are executable + in parallel. When the spare buffer is allocated, echoing + 0 frees it, and echoing else (positive) values clear the + snapshot contents. + More details are shown in the table below. + + +--------------+------------+------------+------------+ + |status\\input | 0 | 1 | else | + +==============+============+============+============+ + |not allocated |(do nothing)| alloc+swap |(do nothing)| + +--------------+------------+------------+------------+ + |allocated | free | swap | clear | + +--------------+------------+------------+------------+ + +Here is an example of using the snapshot feature. +:: + + # echo 1 > events/sched/enable + # echo 1 > snapshot + # cat snapshot + # tracer: nop + # + # entries-in-buffer/entries-written: 71/71 #P:8 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + <idle>-0 [005] d... 2440.603828: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2242 next_prio=120 + sleep-2242 [005] d... 2440.603846: sched_switch: prev_comm=snapshot-test-2 prev_pid=2242 prev_prio=120 prev_state=R ==> next_comm=kworker/5:1 next_pid=60 next_prio=120 + [...] + <idle>-0 [002] d... 2440.707230: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2229 next_prio=120 + + # cat trace + # tracer: nop + # + # entries-in-buffer/entries-written: 77/77 #P:8 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + <idle>-0 [007] d... 2440.707395: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2243 next_prio=120 + snapshot-test-2-2229 [002] d... 2440.707438: sched_switch: prev_comm=snapshot-test-2 prev_pid=2229 prev_prio=120 prev_state=S ==> next_comm=swapper/2 next_pid=0 next_prio=120 + [...] + + +If you try to use this snapshot feature when current tracer is +one of the latency tracers, you will get the following results. +:: + + # echo wakeup > current_tracer + # echo 1 > snapshot + bash: echo: write error: Device or resource busy + # cat snapshot + cat: snapshot: Device or resource busy + + +Instances +--------- +In the tracefs tracing directory is a directory called "instances". +This directory can have new directories created inside of it using +mkdir, and removing directories with rmdir. The directory created +with mkdir in this directory will already contain files and other +directories after it is created. +:: + + # mkdir instances/foo + # ls instances/foo + buffer_size_kb buffer_total_size_kb events free_buffer per_cpu + set_event snapshot trace trace_clock trace_marker trace_options + trace_pipe tracing_on + +As you can see, the new directory looks similar to the tracing directory +itself. In fact, it is very similar, except that the buffer and +events are agnostic from the main director, or from any other +instances that are created. + +The files in the new directory work just like the files with the +same name in the tracing directory except the buffer that is used +is a separate and new buffer. The files affect that buffer but do not +affect the main buffer with the exception of trace_options. Currently, +the trace_options affect all instances and the top level buffer +the same, but this may change in future releases. That is, options +may become specific to the instance they reside in. + +Notice that none of the function tracer files are there, nor is +current_tracer and available_tracers. This is because the buffers +can currently only have events enabled for them. +:: + + # mkdir instances/foo + # mkdir instances/bar + # mkdir instances/zoot + # echo 100000 > buffer_size_kb + # echo 1000 > instances/foo/buffer_size_kb + # echo 5000 > instances/bar/per_cpu/cpu1/buffer_size_kb + # echo function > current_trace + # echo 1 > instances/foo/events/sched/sched_wakeup/enable + # echo 1 > instances/foo/events/sched/sched_wakeup_new/enable + # echo 1 > instances/foo/events/sched/sched_switch/enable + # echo 1 > instances/bar/events/irq/enable + # echo 1 > instances/zoot/events/syscalls/enable + # cat trace_pipe + CPU:2 [LOST 11745 EVENTS] + bash-2044 [002] .... 10594.481032: _raw_spin_lock_irqsave <-get_page_from_freelist + bash-2044 [002] d... 10594.481032: add_preempt_count <-_raw_spin_lock_irqsave + bash-2044 [002] d..1 10594.481032: __rmqueue <-get_page_from_freelist + bash-2044 [002] d..1 10594.481033: _raw_spin_unlock <-get_page_from_freelist + bash-2044 [002] d..1 10594.481033: sub_preempt_count <-_raw_spin_unlock + bash-2044 [002] d... 10594.481033: get_pageblock_flags_group <-get_pageblock_migratetype + bash-2044 [002] d... 10594.481034: __mod_zone_page_state <-get_page_from_freelist + bash-2044 [002] d... 10594.481034: zone_statistics <-get_page_from_freelist + bash-2044 [002] d... 10594.481034: __inc_zone_state <-zone_statistics + bash-2044 [002] d... 10594.481034: __inc_zone_state <-zone_statistics + bash-2044 [002] .... 10594.481035: arch_dup_task_struct <-copy_process + [...] + + # cat instances/foo/trace_pipe + bash-1998 [000] d..4 136.676759: sched_wakeup: comm=kworker/0:1 pid=59 prio=120 success=1 target_cpu=000 + bash-1998 [000] dN.4 136.676760: sched_wakeup: comm=bash pid=1998 prio=120 success=1 target_cpu=000 + <idle>-0 [003] d.h3 136.676906: sched_wakeup: comm=rcu_preempt pid=9 prio=120 success=1 target_cpu=003 + <idle>-0 [003] d..3 136.676909: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=9 next_prio=120 + rcu_preempt-9 [003] d..3 136.676916: sched_switch: prev_comm=rcu_preempt prev_pid=9 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120 + bash-1998 [000] d..4 136.677014: sched_wakeup: comm=kworker/0:1 pid=59 prio=120 success=1 target_cpu=000 + bash-1998 [000] dN.4 136.677016: sched_wakeup: comm=bash pid=1998 prio=120 success=1 target_cpu=000 + bash-1998 [000] d..3 136.677018: sched_switch: prev_comm=bash prev_pid=1998 prev_prio=120 prev_state=R+ ==> next_comm=kworker/0:1 next_pid=59 next_prio=120 + kworker/0:1-59 [000] d..4 136.677022: sched_wakeup: comm=sshd pid=1995 prio=120 success=1 target_cpu=001 + kworker/0:1-59 [000] d..3 136.677025: sched_switch: prev_comm=kworker/0:1 prev_pid=59 prev_prio=120 prev_state=S ==> next_comm=bash next_pid=1998 next_prio=120 + [...] + + # cat instances/bar/trace_pipe + migration/1-14 [001] d.h3 138.732674: softirq_raise: vec=3 [action=NET_RX] + <idle>-0 [001] dNh3 138.732725: softirq_raise: vec=3 [action=NET_RX] + bash-1998 [000] d.h1 138.733101: softirq_raise: vec=1 [action=TIMER] + bash-1998 [000] d.h1 138.733102: softirq_raise: vec=9 [action=RCU] + bash-1998 [000] ..s2 138.733105: softirq_entry: vec=1 [action=TIMER] + bash-1998 [000] ..s2 138.733106: softirq_exit: vec=1 [action=TIMER] + bash-1998 [000] ..s2 138.733106: softirq_entry: vec=9 [action=RCU] + bash-1998 [000] ..s2 138.733109: softirq_exit: vec=9 [action=RCU] + sshd-1995 [001] d.h1 138.733278: irq_handler_entry: irq=21 name=uhci_hcd:usb4 + sshd-1995 [001] d.h1 138.733280: irq_handler_exit: irq=21 ret=unhandled + sshd-1995 [001] d.h1 138.733281: irq_handler_entry: irq=21 name=eth0 + sshd-1995 [001] d.h1 138.733283: irq_handler_exit: irq=21 ret=handled + [...] + + # cat instances/zoot/trace + # tracer: nop + # + # entries-in-buffer/entries-written: 18996/18996 #P:4 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + bash-1998 [000] d... 140.733501: sys_write -> 0x2 + bash-1998 [000] d... 140.733504: sys_dup2(oldfd: a, newfd: 1) + bash-1998 [000] d... 140.733506: sys_dup2 -> 0x1 + bash-1998 [000] d... 140.733508: sys_fcntl(fd: a, cmd: 1, arg: 0) + bash-1998 [000] d... 140.733509: sys_fcntl -> 0x1 + bash-1998 [000] d... 140.733510: sys_close(fd: a) + bash-1998 [000] d... 140.733510: sys_close -> 0x0 + bash-1998 [000] d... 140.733514: sys_rt_sigprocmask(how: 0, nset: 0, oset: 6e2768, sigsetsize: 8) + bash-1998 [000] d... 140.733515: sys_rt_sigprocmask -> 0x0 + bash-1998 [000] d... 140.733516: sys_rt_sigaction(sig: 2, act: 7fff718846f0, oact: 7fff71884650, sigsetsize: 8) + bash-1998 [000] d... 140.733516: sys_rt_sigaction -> 0x0 + +You can see that the trace of the top most trace buffer shows only +the function tracing. The foo instance displays wakeups and task +switches. + +To remove the instances, simply delete their directories: +:: + + # rmdir instances/foo + # rmdir instances/bar + # rmdir instances/zoot + +Note, if a process has a trace file open in one of the instance +directories, the rmdir will fail with EBUSY. + + +Stack trace +----------- +Since the kernel has a fixed sized stack, it is important not to +waste it in functions. A kernel developer must be conscience of +what they allocate on the stack. If they add too much, the system +can be in danger of a stack overflow, and corruption will occur, +usually leading to a system panic. + +There are some tools that check this, usually with interrupts +periodically checking usage. But if you can perform a check +at every function call that will become very useful. As ftrace provides +a function tracer, it makes it convenient to check the stack size +at every function call. This is enabled via the stack tracer. + +CONFIG_STACK_TRACER enables the ftrace stack tracing functionality. +To enable it, write a '1' into /proc/sys/kernel/stack_tracer_enabled. +:: + + # echo 1 > /proc/sys/kernel/stack_tracer_enabled + +You can also enable it from the kernel command line to trace +the stack size of the kernel during boot up, by adding "stacktrace" +to the kernel command line parameter. + +After running it for a few minutes, the output looks like: +:: + + # cat stack_max_size + 2928 + + # cat stack_trace + Depth Size Location (18 entries) + ----- ---- -------- + 0) 2928 224 update_sd_lb_stats+0xbc/0x4ac + 1) 2704 160 find_busiest_group+0x31/0x1f1 + 2) 2544 256 load_balance+0xd9/0x662 + 3) 2288 80 idle_balance+0xbb/0x130 + 4) 2208 128 __schedule+0x26e/0x5b9 + 5) 2080 16 schedule+0x64/0x66 + 6) 2064 128 schedule_timeout+0x34/0xe0 + 7) 1936 112 wait_for_common+0x97/0xf1 + 8) 1824 16 wait_for_completion+0x1d/0x1f + 9) 1808 128 flush_work+0xfe/0x119 + 10) 1680 16 tty_flush_to_ldisc+0x1e/0x20 + 11) 1664 48 input_available_p+0x1d/0x5c + 12) 1616 48 n_tty_poll+0x6d/0x134 + 13) 1568 64 tty_poll+0x64/0x7f + 14) 1504 880 do_select+0x31e/0x511 + 15) 624 400 core_sys_select+0x177/0x216 + 16) 224 96 sys_select+0x91/0xb9 + 17) 128 128 system_call_fastpath+0x16/0x1b + +Note, if -mfentry is being used by gcc, functions get traced before +they set up the stack frame. This means that leaf level functions +are not tested by the stack tracer when -mfentry is used. + +Currently, -mfentry is used by gcc 4.6.0 and above on x86 only. + +More +---- +More details can be found in the source code, in the `kernel/trace/*.c` files. diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt deleted file mode 100644 index d4601df..0000000 --- a/Documentation/trace/ftrace.txt +++ /dev/null @@ -1,3220 +0,0 @@ - ftrace - Function Tracer - ======================== - -Copyright 2008 Red Hat Inc. - Author: Steven Rostedt <srostedt@redhat.com> - License: The GNU Free Documentation License, Version 1.2 - (dual licensed under the GPL v2) -Original Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton, - John Kacur, and David Teigland. -Written for: 2.6.28-rc2 -Updated for: 3.10 -Updated for: 4.13 - Copyright 2017 VMware Inc. Steven Rostedt - -Introduction ------------- - -Ftrace is an internal tracer designed to help out developers and -designers of systems to find what is going on inside the kernel. -It can be used for debugging or analyzing latencies and -performance issues that take place outside of user-space. - -Although ftrace is typically considered the function tracer, it -is really a frame work of several assorted tracing utilities. -There's latency tracing to examine what occurs between interrupts -disabled and enabled, as well as for preemption and from a time -a task is woken to the task is actually scheduled in. - -One of the most common uses of ftrace is the event tracing. -Through out the kernel is hundreds of static event points that -can be enabled via the tracefs file system to see what is -going on in certain parts of the kernel. - -See events.txt for more information. - - -Implementation Details ----------------------- - -See ftrace-design.txt for details for arch porters and such. - - -The File System ---------------- - -Ftrace uses the tracefs file system to hold the control files as -well as the files to display output. - -When tracefs is configured into the kernel (which selecting any ftrace -option will do) the directory /sys/kernel/tracing will be created. To mount -this directory, you can add to your /etc/fstab file: - - tracefs /sys/kernel/tracing tracefs defaults 0 0 - -Or you can mount it at run time with: - - mount -t tracefs nodev /sys/kernel/tracing - -For quicker access to that directory you may want to make a soft link to -it: - - ln -s /sys/kernel/tracing /tracing - - *** NOTICE *** - -Before 4.1, all ftrace tracing control files were within the debugfs -file system, which is typically located at /sys/kernel/debug/tracing. -For backward compatibility, when mounting the debugfs file system, -the tracefs file system will be automatically mounted at: - - /sys/kernel/debug/tracing - -All files located in the tracefs file system will be located in that -debugfs file system directory as well. - - *** NOTICE *** - -Any selected ftrace option will also create the tracefs file system. -The rest of the document will assume that you are in the ftrace directory -(cd /sys/kernel/tracing) and will only concentrate on the files within that -directory and not distract from the content with the extended -"/sys/kernel/tracing" path name. - -That's it! (assuming that you have ftrace configured into your kernel) - -After mounting tracefs you will have access to the control and output files -of ftrace. Here is a list of some of the key files: - - - Note: all time values are in microseconds. - - current_tracer: - - This is used to set or display the current tracer - that is configured. - - available_tracers: - - This holds the different types of tracers that - have been compiled into the kernel. The - tracers listed here can be configured by - echoing their name into current_tracer. - - tracing_on: - - This sets or displays whether writing to the trace - ring buffer is enabled. Echo 0 into this file to disable - the tracer or 1 to enable it. Note, this only disables - writing to the ring buffer, the tracing overhead may - still be occurring. - - The kernel function tracing_off() can be used within the - kernel to disable writing to the ring buffer, which will - set this file to "0". User space can re-enable tracing by - echoing "1" into the file. - - Note, the function and event trigger "traceoff" will also - set this file to zero and stop tracing. Which can also - be re-enabled by user space using this file. - - trace: - - This file holds the output of the trace in a human - readable format (described below). Note, tracing is temporarily - disabled while this file is being read (opened). - - trace_pipe: - - The output is the same as the "trace" file but this - file is meant to be streamed with live tracing. - Reads from this file will block until new data is - retrieved. Unlike the "trace" file, this file is a - consumer. This means reading from this file causes - sequential reads to display more current data. Once - data is read from this file, it is consumed, and - will not be read again with a sequential read. The - "trace" file is static, and if the tracer is not - adding more data, it will display the same - information every time it is read. This file will not - disable tracing while being read. - - trace_options: - - This file lets the user control the amount of data - that is displayed in one of the above output - files. Options also exist to modify how a tracer - or events work (stack traces, timestamps, etc). - - options: - - This is a directory that has a file for every available - trace option (also in trace_options). Options may also be set - or cleared by writing a "1" or "0" respectively into the - corresponding file with the option name. - - tracing_max_latency: - - Some of the tracers record the max latency. - For example, the maximum time that interrupts are disabled. - The maximum time is saved in this file. The max trace will also be - stored, and displayed by "trace". A new max trace will only be - recorded if the latency is greater than the value in this file - (in microseconds). - - By echoing in a time into this file, no latency will be recorded - unless it is greater than the time in this file. - - tracing_thresh: - - Some latency tracers will record a trace whenever the - latency is greater than the number in this file. - Only active when the file contains a number greater than 0. - (in microseconds) - - buffer_size_kb: - - This sets or displays the number of kilobytes each CPU - buffer holds. By default, the trace buffers are the same size - for each CPU. The displayed number is the size of the - CPU buffer and not total size of all buffers. The - trace buffers are allocated in pages (blocks of memory - that the kernel uses for allocation, usually 4 KB in size). - If the last page allocated has room for more bytes - than requested, the rest of the page will be used, - making the actual allocation bigger than requested or shown. - ( Note, the size may not be a multiple of the page size - due to buffer management meta-data. ) - - Buffer sizes for individual CPUs may vary - (see "per_cpu/cpu0/buffer_size_kb" below), and if they do - this file will show "X". - - buffer_total_size_kb: - - This displays the total combined size of all the trace buffers. - - free_buffer: - - If a process is performing tracing, and the ring buffer should be - shrunk "freed" when the process is finished, even if it were to be - killed by a signal, this file can be used for that purpose. On close - of this file, the ring buffer will be resized to its minimum size. - Having a process that is tracing also open this file, when the process - exits its file descriptor for this file will be closed, and in doing so, - the ring buffer will be "freed". - - It may also stop tracing if disable_on_free option is set. - - tracing_cpumask: - - This is a mask that lets the user only trace on specified CPUs. - The format is a hex string representing the CPUs. - - set_ftrace_filter: - - When dynamic ftrace is configured in (see the - section below "dynamic ftrace"), the code is dynamically - modified (code text rewrite) to disable calling of the - function profiler (mcount). This lets tracing be configured - in with practically no overhead in performance. This also - has a side effect of enabling or disabling specific functions - to be traced. Echoing names of functions into this file - will limit the trace to only those functions. - - The functions listed in "available_filter_functions" are what - can be written into this file. - - This interface also allows for commands to be used. See the - "Filter commands" section for more details. - - set_ftrace_notrace: - - This has an effect opposite to that of - set_ftrace_filter. Any function that is added here will not - be traced. If a function exists in both set_ftrace_filter - and set_ftrace_notrace, the function will _not_ be traced. - - set_ftrace_pid: - - Have the function tracer only trace the threads whose PID are - listed in this file. - - If the "function-fork" option is set, then when a task whose - PID is listed in this file forks, the child's PID will - automatically be added to this file, and the child will be - traced by the function tracer as well. This option will also - cause PIDs of tasks that exit to be removed from the file. - - set_event_pid: - - Have the events only trace a task with a PID listed in this file. - Note, sched_switch and sched_wake_up will also trace events - listed in this file. - - To have the PIDs of children of tasks with their PID in this file - added on fork, enable the "event-fork" option. That option will also - cause the PIDs of tasks to be removed from this file when the task - exits. - - set_graph_function: - - Functions listed in this file will cause the function graph - tracer to only trace these functions and the functions that - they call. (See the section "dynamic ftrace" for more details). - - set_graph_notrace: - - Similar to set_graph_function, but will disable function graph - tracing when the function is hit until it exits the function. - This makes it possible to ignore tracing functions that are called - by a specific function. - - available_filter_functions: - - This lists the functions that ftrace has processed and can trace. - These are the function names that you can pass to - "set_ftrace_filter" or "set_ftrace_notrace". - (See the section "dynamic ftrace" below for more details.) - - dyn_ftrace_total_info: - - This file is for debugging purposes. The number of functions that - have been converted to nops and are available to be traced. - - enabled_functions: - - This file is more for debugging ftrace, but can also be useful - in seeing if any function has a callback attached to it. - Not only does the trace infrastructure use ftrace function - trace utility, but other subsystems might too. This file - displays all functions that have a callback attached to them - as well as the number of callbacks that have been attached. - Note, a callback may also call multiple functions which will - not be listed in this count. - - If the callback registered to be traced by a function with - the "save regs" attribute (thus even more overhead), a 'R' - will be displayed on the same line as the function that - is returning registers. - - If the callback registered to be traced by a function with - the "ip modify" attribute (thus the regs->ip can be changed), - an 'I' will be displayed on the same line as the function that - can be overridden. - - If the architecture supports it, it will also show what callback - is being directly called by the function. If the count is greater - than 1 it most likely will be ftrace_ops_list_func(). - - If the callback of the function jumps to a trampoline that is - specific to a the callback and not the standard trampoline, - its address will be printed as well as the function that the - trampoline calls. - - function_profile_enabled: - - When set it will enable all functions with either the function - tracer, or if configured, the function graph tracer. It will - keep a histogram of the number of functions that were called - and if the function graph tracer was configured, it will also keep - track of the time spent in those functions. The histogram - content can be displayed in the files: - - trace_stats/function<cpu> ( function0, function1, etc). - - trace_stats: - - A directory that holds different tracing stats. - - kprobe_events: - - Enable dynamic trace points. See kprobetrace.txt. - - kprobe_profile: - - Dynamic trace points stats. See kprobetrace.txt. - - max_graph_depth: - - Used with the function graph tracer. This is the max depth - it will trace into a function. Setting this to a value of - one will show only the first kernel function that is called - from user space. - - printk_formats: - - This is for tools that read the raw format files. If an event in - the ring buffer references a string, only a pointer to the string - is recorded into the buffer and not the string itself. This prevents - tools from knowing what that string was. This file displays the string - and address for the string allowing tools to map the pointers to what - the strings were. - - saved_cmdlines: - - Only the pid of the task is recorded in a trace event unless - the event specifically saves the task comm as well. Ftrace - makes a cache of pid mappings to comms to try to display - comms for events. If a pid for a comm is not listed, then - "<...>" is displayed in the output. - - If the option "record-cmd" is set to "0", then comms of tasks - will not be saved during recording. By default, it is enabled. - - saved_cmdlines_size: - - By default, 128 comms are saved (see "saved_cmdlines" above). To - increase or decrease the amount of comms that are cached, echo - in a the number of comms to cache, into this file. - - saved_tgids: - - If the option "record-tgid" is set, on each scheduling context switch - the Task Group ID of a task is saved in a table mapping the PID of - the thread to its TGID. By default, the "record-tgid" option is - disabled. - - snapshot: - - This displays the "snapshot" buffer and also lets the user - take a snapshot of the current running trace. - See the "Snapshot" section below for more details. - - stack_max_size: - - When the stack tracer is activated, this will display the - maximum stack size it has encountered. - See the "Stack Trace" section below. - - stack_trace: - - This displays the stack back trace of the largest stack - that was encountered when the stack tracer is activated. - See the "Stack Trace" section below. - - stack_trace_filter: - - This is similar to "set_ftrace_filter" but it limits what - functions the stack tracer will check. - - trace_clock: - - Whenever an event is recorded into the ring buffer, a - "timestamp" is added. This stamp comes from a specified - clock. By default, ftrace uses the "local" clock. This - clock is very fast and strictly per cpu, but on some - systems it may not be monotonic with respect to other - CPUs. In other words, the local clocks may not be in sync - with local clocks on other CPUs. - - Usual clocks for tracing: - - # cat trace_clock - [local] global counter x86-tsc - - The clock with the square brackets around it is the one - in effect. - - local: Default clock, but may not be in sync across CPUs - - global: This clock is in sync with all CPUs but may - be a bit slower than the local clock. - - counter: This is not a clock at all, but literally an atomic - counter. It counts up one by one, but is in sync - with all CPUs. This is useful when you need to - know exactly the order events occurred with respect to - each other on different CPUs. - - uptime: This uses the jiffies counter and the time stamp - is relative to the time since boot up. - - perf: This makes ftrace use the same clock that perf uses. - Eventually perf will be able to read ftrace buffers - and this will help out in interleaving the data. - - x86-tsc: Architectures may define their own clocks. For - example, x86 uses its own TSC cycle clock here. - - ppc-tb: This uses the powerpc timebase register value. - This is in sync across CPUs and can also be used - to correlate events across hypervisor/guest if - tb_offset is known. - - mono: This uses the fast monotonic clock (CLOCK_MONOTONIC) - which is monotonic and is subject to NTP rate adjustments. - - mono_raw: - This is the raw monotonic clock (CLOCK_MONOTONIC_RAW) - which is montonic but is not subject to any rate adjustments - and ticks at the same rate as the hardware clocksource. - - boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the - fast monotonic clock, but also accounts for time spent in - suspend. Since the clock access is designed for use in - tracing in the suspend path, some side effects are possible - if clock is accessed after the suspend time is accounted before - the fast mono clock is updated. In this case, the clock update - appears to happen slightly sooner than it normally would have. - Also on 32-bit systems, it's possible that the 64-bit boot offset - sees a partial update. These effects are rare and post - processing should be able to handle them. See comments in the - ktime_get_boot_fast_ns() function for more information. - - To set a clock, simply echo the clock name into this file. - - echo global > trace_clock - - trace_marker: - - This is a very useful file for synchronizing user space - with events happening in the kernel. Writing strings into - this file will be written into the ftrace buffer. - - It is useful in applications to open this file at the start - of the application and just reference the file descriptor - for the file. - - void trace_write(const char *fmt, ...) - { - va_list ap; - char buf[256]; - int n; - - if (trace_fd < 0) - return; - - va_start(ap, fmt); - n = vsnprintf(buf, 256, fmt, ap); - va_end(ap); - - write(trace_fd, buf, n); - } - - start: - - trace_fd = open("trace_marker", WR_ONLY); - - trace_marker_raw: - - This is similar to trace_marker above, but is meant for for binary data - to be written to it, where a tool can be used to parse the data - from trace_pipe_raw. - - uprobe_events: - - Add dynamic tracepoints in programs. - See uprobetracer.txt - - uprobe_profile: - - Uprobe statistics. See uprobetrace.txt - - instances: - - This is a way to make multiple trace buffers where different - events can be recorded in different buffers. - See "Instances" section below. - - events: - - This is the trace event directory. It holds event tracepoints - (also known as static tracepoints) that have been compiled - into the kernel. It shows what event tracepoints exist - and how they are grouped by system. There are "enable" - files at various levels that can enable the tracepoints - when a "1" is written to them. - - See events.txt for more information. - - set_event: - - By echoing in the event into this file, will enable that event. - - See events.txt for more information. - - available_events: - - A list of events that can be enabled in tracing. - - See events.txt for more information. - - hwlat_detector: - - Directory for the Hardware Latency Detector. - See "Hardware Latency Detector" section below. - - per_cpu: - - This is a directory that contains the trace per_cpu information. - - per_cpu/cpu0/buffer_size_kb: - - The ftrace buffer is defined per_cpu. That is, there's a separate - buffer for each CPU to allow writes to be done atomically, - and free from cache bouncing. These buffers may have different - size buffers. This file is similar to the buffer_size_kb - file, but it only displays or sets the buffer size for the - specific CPU. (here cpu0). - - per_cpu/cpu0/trace: - - This is similar to the "trace" file, but it will only display - the data specific for the CPU. If written to, it only clears - the specific CPU buffer. - - per_cpu/cpu0/trace_pipe - - This is similar to the "trace_pipe" file, and is a consuming - read, but it will only display (and consume) the data specific - for the CPU. - - per_cpu/cpu0/trace_pipe_raw - - For tools that can parse the ftrace ring buffer binary format, - the trace_pipe_raw file can be used to extract the data - from the ring buffer directly. With the use of the splice() - system call, the buffer data can be quickly transferred to - a file or to the network where a server is collecting the - data. - - Like trace_pipe, this is a consuming reader, where multiple - reads will always produce different data. - - per_cpu/cpu0/snapshot: - - This is similar to the main "snapshot" file, but will only - snapshot the current CPU (if supported). It only displays - the content of the snapshot for a given CPU, and if - written to, only clears this CPU buffer. - - per_cpu/cpu0/snapshot_raw: - - Similar to the trace_pipe_raw, but will read the binary format - from the snapshot buffer for the given CPU. - - per_cpu/cpu0/stats: - - This displays certain stats about the ring buffer: - - entries: The number of events that are still in the buffer. - - overrun: The number of lost events due to overwriting when - the buffer was full. - - commit overrun: Should always be zero. - This gets set if so many events happened within a nested - event (ring buffer is re-entrant), that it fills the - buffer and starts dropping events. - - bytes: Bytes actually read (not overwritten). - - oldest event ts: The oldest timestamp in the buffer - - now ts: The current timestamp - - dropped events: Events lost due to overwrite option being off. - - read events: The number of events read. - -The Tracers ------------ - -Here is the list of current tracers that may be configured. - - "function" - - Function call tracer to trace all kernel functions. - - "function_graph" - - Similar to the function tracer except that the - function tracer probes the functions on their entry - whereas the function graph tracer traces on both entry - and exit of the functions. It then provides the ability - to draw a graph of function calls similar to C code - source. - - "blk" - - The block tracer. The tracer used by the blktrace user - application. - - "hwlat" - - The Hardware Latency tracer is used to detect if the hardware - produces any latency. See "Hardware Latency Detector" section - below. - - "irqsoff" - - Traces the areas that disable interrupts and saves - the trace with the longest max latency. - See tracing_max_latency. When a new max is recorded, - it replaces the old trace. It is best to view this - trace with the latency-format option enabled, which - happens automatically when the tracer is selected. - - "preemptoff" - - Similar to irqsoff but traces and records the amount of - time for which preemption is disabled. - - "preemptirqsoff" - - Similar to irqsoff and preemptoff, but traces and - records the largest time for which irqs and/or preemption - is disabled. - - "wakeup" - - Traces and records the max latency that it takes for - the highest priority task to get scheduled after - it has been woken up. - Traces all tasks as an average developer would expect. - - "wakeup_rt" - - Traces and records the max latency that it takes for just - RT tasks (as the current "wakeup" does). This is useful - for those interested in wake up timings of RT tasks. - - "wakeup_dl" - - Traces and records the max latency that it takes for - a SCHED_DEADLINE task to be woken (as the "wakeup" and - "wakeup_rt" does). - - "mmiotrace" - - A special tracer that is used to trace binary module. - It will trace all the calls that a module makes to the - hardware. Everything it writes and reads from the I/O - as well. - - "branch" - - This tracer can be configured when tracing likely/unlikely - calls within the kernel. It will trace when a likely and - unlikely branch is hit and if it was correct in its prediction - of being correct. - - "nop" - - This is the "trace nothing" tracer. To remove all - tracers from tracing simply echo "nop" into - current_tracer. - - -Examples of using the tracer ----------------------------- - -Here are typical examples of using the tracers when controlling -them only with the tracefs interface (without using any -user-land utilities). - -Output format: --------------- - -Here is an example of the output format of the file "trace" - - -------- -# tracer: function -# -# entries-in-buffer/entries-written: 140080/250280 #P:4 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - bash-1977 [000] .... 17284.993652: sys_close <-system_call_fastpath - bash-1977 [000] .... 17284.993653: __close_fd <-sys_close - bash-1977 [000] .... 17284.993653: _raw_spin_lock <-__close_fd - sshd-1974 [003] .... 17284.993653: __srcu_read_unlock <-fsnotify - bash-1977 [000] .... 17284.993654: add_preempt_count <-_raw_spin_lock - bash-1977 [000] ...1 17284.993655: _raw_spin_unlock <-__close_fd - bash-1977 [000] ...1 17284.993656: sub_preempt_count <-_raw_spin_unlock - bash-1977 [000] .... 17284.993657: filp_close <-__close_fd - bash-1977 [000] .... 17284.993657: dnotify_flush <-filp_close - sshd-1974 [003] .... 17284.993658: sys_select <-system_call_fastpath - -------- - -A header is printed with the tracer name that is represented by -the trace. In this case the tracer is "function". Then it shows the -number of events in the buffer as well as the total number of entries -that were written. The difference is the number of entries that were -lost due to the buffer filling up (250280 - 140080 = 110200 events -lost). - -The header explains the content of the events. Task name "bash", the task -PID "1977", the CPU that it was running on "000", the latency format -(explained below), the timestamp in <secs>.<usecs> format, the -function name that was traced "sys_close" and the parent function that -called this function "system_call_fastpath". The timestamp is the time -at which the function was entered. - -Latency trace format --------------------- - -When the latency-format option is enabled or when one of the latency -tracers is set, the trace file gives somewhat more information to see -why a latency happened. Here is a typical trace. - -# tracer: irqsoff -# -# irqsoff latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 259 us, #4/4, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: ps-6143 (uid:0 nice:0 policy:0 rt_prio:0) -# ----------------- -# => started at: __lock_task_sighand -# => ended at: _raw_spin_unlock_irqrestore -# -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - ps-6143 2d... 0us!: trace_hardirqs_off <-__lock_task_sighand - ps-6143 2d..1 259us+: trace_hardirqs_on <-_raw_spin_unlock_irqrestore - ps-6143 2d..1 263us+: time_hardirqs_on <-_raw_spin_unlock_irqrestore - ps-6143 2d..1 306us : <stack trace> - => trace_hardirqs_on_caller - => trace_hardirqs_on - => _raw_spin_unlock_irqrestore - => do_task_stat - => proc_tgid_stat - => proc_single_show - => seq_read - => vfs_read - => sys_read - => system_call_fastpath - - -This shows that the current tracer is "irqsoff" tracing the time -for which interrupts were disabled. It gives the trace version (which -never changes) and the version of the kernel upon which this was executed on -(3.8). Then it displays the max latency in microseconds (259 us). The number -of trace entries displayed and the total number (both are four: #4/4). -VP, KP, SP, and HP are always zero and are reserved for later use. -#P is the number of online CPUs (#P:4). - -The task is the process that was running when the latency -occurred. (ps pid: 6143). - -The start and stop (the functions in which the interrupts were -disabled and enabled respectively) that caused the latencies: - - __lock_task_sighand is where the interrupts were disabled. - _raw_spin_unlock_irqrestore is where they were enabled again. - -The next lines after the header are the trace itself. The header -explains which is which. - - cmd: The name of the process in the trace. - - pid: The PID of that process. - - CPU#: The CPU which the process was running on. - - irqs-off: 'd' interrupts are disabled. '.' otherwise. - Note: If the architecture does not support a way to - read the irq flags variable, an 'X' will always - be printed here. - - need-resched: - 'N' both TIF_NEED_RESCHED and PREEMPT_NEED_RESCHED is set, - 'n' only TIF_NEED_RESCHED is set, - 'p' only PREEMPT_NEED_RESCHED is set, - '.' otherwise. - - hardirq/softirq: - 'Z' - NMI occurred inside a hardirq - 'z' - NMI is running - 'H' - hard irq occurred inside a softirq. - 'h' - hard irq is running - 's' - soft irq is running - '.' - normal context. - - preempt-depth: The level of preempt_disabled - -The above is mostly meaningful for kernel developers. - - time: When the latency-format option is enabled, the trace file - output includes a timestamp relative to the start of the - trace. This differs from the output when latency-format - is disabled, which includes an absolute timestamp. - - delay: This is just to help catch your eye a bit better. And - needs to be fixed to be only relative to the same CPU. - The marks are determined by the difference between this - current trace and the next trace. - '$' - greater than 1 second - '@' - greater than 100 milisecond - '*' - greater than 10 milisecond - '#' - greater than 1000 microsecond - '!' - greater than 100 microsecond - '+' - greater than 10 microsecond - ' ' - less than or equal to 10 microsecond. - - The rest is the same as the 'trace' file. - - Note, the latency tracers will usually end with a back trace - to easily find where the latency occurred. - -trace_options -------------- - -The trace_options file (or the options directory) is used to control -what gets printed in the trace output, or manipulate the tracers. -To see what is available, simply cat the file: - - cat trace_options -print-parent -nosym-offset -nosym-addr -noverbose -noraw -nohex -nobin -noblock -trace_printk -annotate -nouserstacktrace -nosym-userobj -noprintk-msg-only -context-info -nolatency-format -record-cmd -norecord-tgid -overwrite -nodisable_on_free -irq-info -markers -noevent-fork -function-trace -nofunction-fork -nodisplay-graph -nostacktrace -nobranch - -To disable one of the options, echo in the option prepended with -"no". - - echo noprint-parent > trace_options - -To enable an option, leave off the "no". - - echo sym-offset > trace_options - -Here are the available options: - - print-parent - On function traces, display the calling (parent) - function as well as the function being traced. - - print-parent: - bash-4000 [01] 1477.606694: simple_strtoul <-kstrtoul - - noprint-parent: - bash-4000 [01] 1477.606694: simple_strtoul - - - sym-offset - Display not only the function name, but also the - offset in the function. For example, instead of - seeing just "ktime_get", you will see - "ktime_get+0xb/0x20". - - sym-offset: - bash-4000 [01] 1477.606694: simple_strtoul+0x6/0xa0 - - sym-addr - this will also display the function address as well - as the function name. - - sym-addr: - bash-4000 [01] 1477.606694: simple_strtoul <c0339346> - - verbose - This deals with the trace file when the - latency-format option is enabled. - - bash 4000 1 0 00000000 00010a95 [58127d26] 1720.415ms \ - (+0.000ms): simple_strtoul (kstrtoul) - - raw - This will display raw numbers. This option is best for - use with user applications that can translate the raw - numbers better than having it done in the kernel. - - hex - Similar to raw, but the numbers will be in a hexadecimal - format. - - bin - This will print out the formats in raw binary. - - block - When set, reading trace_pipe will not block when polled. - - trace_printk - Can disable trace_printk() from writing into the buffer. - - annotate - It is sometimes confusing when the CPU buffers are full - and one CPU buffer had a lot of events recently, thus - a shorter time frame, were another CPU may have only had - a few events, which lets it have older events. When - the trace is reported, it shows the oldest events first, - and it may look like only one CPU ran (the one with the - oldest events). When the annotate option is set, it will - display when a new CPU buffer started: - - <idle>-0 [001] dNs4 21169.031481: wake_up_idle_cpu <-add_timer_on - <idle>-0 [001] dNs4 21169.031482: _raw_spin_unlock_irqrestore <-add_timer_on - <idle>-0 [001] .Ns4 21169.031484: sub_preempt_count <-_raw_spin_unlock_irqrestore -##### CPU 2 buffer started #### - <idle>-0 [002] .N.1 21169.031484: rcu_idle_exit <-cpu_idle - <idle>-0 [001] .Ns3 21169.031484: _raw_spin_unlock <-clocksource_watchdog - <idle>-0 [001] .Ns3 21169.031485: sub_preempt_count <-_raw_spin_unlock - - userstacktrace - This option changes the trace. It records a - stacktrace of the current user space thread after - each trace event. - - sym-userobj - when user stacktrace are enabled, look up which - object the address belongs to, and print a - relative address. This is especially useful when - ASLR is on, otherwise you don't get a chance to - resolve the address to object/file/line after - the app is no longer running - - The lookup is performed when you read - trace,trace_pipe. Example: - - a.out-1623 [000] 40874.465068: /root/a.out[+0x480] <-/root/a.out[+0 -x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6] - - - printk-msg-only - When set, trace_printk()s will only show the format - and not their parameters (if trace_bprintk() or - trace_bputs() was used to save the trace_printk()). - - context-info - Show only the event data. Hides the comm, PID, - timestamp, CPU, and other useful data. - - latency-format - This option changes the trace output. When it is enabled, - the trace displays additional information about the - latency, as described in "Latency trace format". - - record-cmd - When any event or tracer is enabled, a hook is enabled - in the sched_switch trace point to fill comm cache - with mapped pids and comms. But this may cause some - overhead, and if you only care about pids, and not the - name of the task, disabling this option can lower the - impact of tracing. See "saved_cmdlines". - - record-tgid - When any event or tracer is enabled, a hook is enabled - in the sched_switch trace point to fill the cache of - mapped Thread Group IDs (TGID) mapping to pids. See - "saved_tgids". - - overwrite - This controls what happens when the trace buffer is - full. If "1" (default), the oldest events are - discarded and overwritten. If "0", then the newest - events are discarded. - (see per_cpu/cpu0/stats for overrun and dropped) - - disable_on_free - When the free_buffer is closed, tracing will - stop (tracing_on set to 0). - - irq-info - Shows the interrupt, preempt count, need resched data. - When disabled, the trace looks like: - -# tracer: function -# -# entries-in-buffer/entries-written: 144405/9452052 #P:4 -# -# TASK-PID CPU# TIMESTAMP FUNCTION -# | | | | | - <idle>-0 [002] 23636.756054: ttwu_do_activate.constprop.89 <-try_to_wake_up - <idle>-0 [002] 23636.756054: activate_task <-ttwu_do_activate.constprop.89 - <idle>-0 [002] 23636.756055: enqueue_task <-activate_task - - - markers - When set, the trace_marker is writable (only by root). - When disabled, the trace_marker will error with EINVAL - on write. - - event-fork - When set, tasks with PIDs listed in set_event_pid will have - the PIDs of their children added to set_event_pid when those - tasks fork. Also, when tasks with PIDs in set_event_pid exit, - their PIDs will be removed from the file. - - function-trace - The latency tracers will enable function tracing - if this option is enabled (default it is). When - it is disabled, the latency tracers do not trace - functions. This keeps the overhead of the tracer down - when performing latency tests. - - function-fork - When set, tasks with PIDs listed in set_ftrace_pid will - have the PIDs of their children added to set_ftrace_pid - when those tasks fork. Also, when tasks with PIDs in - set_ftrace_pid exit, their PIDs will be removed from the - file. - - display-graph - When set, the latency tracers (irqsoff, wakeup, etc) will - use function graph tracing instead of function tracing. - - stacktrace - When set, a stack trace is recorded after any trace event - is recorded. - - branch - Enable branch tracing with the tracer. This enables branch - tracer along with the currently set tracer. Enabling this - with the "nop" tracer is the same as just enabling the - "branch" tracer. - - Note: Some tracers have their own options. They only appear in this - file when the tracer is active. They always appear in the - options directory. - - -Here are the per tracer options: - -Options for function tracer: - - func_stack_trace - When set, a stack trace is recorded after every - function that is recorded. NOTE! Limit the functions - that are recorded before enabling this, with - "set_ftrace_filter" otherwise the system performance - will be critically degraded. Remember to disable - this option before clearing the function filter. - -Options for function_graph tracer: - - Since the function_graph tracer has a slightly different output - it has its own options to control what is displayed. - - funcgraph-overrun - When set, the "overrun" of the graph stack is - displayed after each function traced. The - overrun, is when the stack depth of the calls - is greater than what is reserved for each task. - Each task has a fixed array of functions to - trace in the call graph. If the depth of the - calls exceeds that, the function is not traced. - The overrun is the number of functions missed - due to exceeding this array. - - funcgraph-cpu - When set, the CPU number of the CPU where the trace - occurred is displayed. - - funcgraph-overhead - When set, if the function takes longer than - A certain amount, then a delay marker is - displayed. See "delay" above, under the - header description. - - funcgraph-proc - Unlike other tracers, the process' command line - is not displayed by default, but instead only - when a task is traced in and out during a context - switch. Enabling this options has the command - of each process displayed at every line. - - funcgraph-duration - At the end of each function (the return) - the duration of the amount of time in the - function is displayed in microseconds. - - funcgraph-abstime - When set, the timestamp is displayed at each - line. - - funcgraph-irqs - When disabled, functions that happen inside an - interrupt will not be traced. - - funcgraph-tail - When set, the return event will include the function - that it represents. By default this is off, and - only a closing curly bracket "}" is displayed for - the return of a function. - - sleep-time - When running function graph tracer, to include - the time a task schedules out in its function. - When enabled, it will account time the task has been - scheduled out as part of the function call. - - graph-time - When running function profiler with function graph tracer, - to include the time to call nested functions. When this is - not set, the time reported for the function will only - include the time the function itself executed for, not the - time for functions that it called. - -Options for blk tracer: - - blk_classic - Shows a more minimalistic output. - - -irqsoff -------- - -When interrupts are disabled, the CPU can not react to any other -external event (besides NMIs and SMIs). This prevents the timer -interrupt from triggering or the mouse interrupt from letting -the kernel know of a new mouse event. The result is a latency -with the reaction time. - -The irqsoff tracer tracks the time for which interrupts are -disabled. When a new maximum latency is hit, the tracer saves -the trace leading up to that latency point so that every time a -new maximum is reached, the old saved trace is discarded and the -new trace is saved. - -To reset the maximum, echo 0 into tracing_max_latency. Here is -an example: - - # echo 0 > options/function-trace - # echo irqsoff > current_tracer - # echo 1 > tracing_on - # echo 0 > tracing_max_latency - # ls -ltr - [...] - # echo 0 > tracing_on - # cat trace -# tracer: irqsoff -# -# irqsoff latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 16 us, #4/4, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: swapper/0-0 (uid:0 nice:0 policy:0 rt_prio:0) -# ----------------- -# => started at: run_timer_softirq -# => ended at: run_timer_softirq -# -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - <idle>-0 0d.s2 0us+: _raw_spin_lock_irq <-run_timer_softirq - <idle>-0 0dNs3 17us : _raw_spin_unlock_irq <-run_timer_softirq - <idle>-0 0dNs3 17us+: trace_hardirqs_on <-run_timer_softirq - <idle>-0 0dNs3 25us : <stack trace> - => _raw_spin_unlock_irq - => run_timer_softirq - => __do_softirq - => call_softirq - => do_softirq - => irq_exit - => smp_apic_timer_interrupt - => apic_timer_interrupt - => rcu_idle_exit - => cpu_idle - => rest_init - => start_kernel - => x86_64_start_reservations - => x86_64_start_kernel - -Here we see that that we had a latency of 16 microseconds (which is -very good). The _raw_spin_lock_irq in run_timer_softirq disabled -interrupts. The difference between the 16 and the displayed -timestamp 25us occurred because the clock was incremented -between the time of recording the max latency and the time of -recording the function that had that latency. - -Note the above example had function-trace not set. If we set -function-trace, we get a much larger output: - - with echo 1 > options/function-trace - -# tracer: irqsoff -# -# irqsoff latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 71 us, #168/168, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: bash-2042 (uid:0 nice:0 policy:0 rt_prio:0) -# ----------------- -# => started at: ata_scsi_queuecmd -# => ended at: ata_scsi_queuecmd -# -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - bash-2042 3d... 0us : _raw_spin_lock_irqsave <-ata_scsi_queuecmd - bash-2042 3d... 0us : add_preempt_count <-_raw_spin_lock_irqsave - bash-2042 3d..1 1us : ata_scsi_find_dev <-ata_scsi_queuecmd - bash-2042 3d..1 1us : __ata_scsi_find_dev <-ata_scsi_find_dev - bash-2042 3d..1 2us : ata_find_dev.part.14 <-__ata_scsi_find_dev - bash-2042 3d..1 2us : ata_qc_new_init <-__ata_scsi_queuecmd - bash-2042 3d..1 3us : ata_sg_init <-__ata_scsi_queuecmd - bash-2042 3d..1 4us : ata_scsi_rw_xlat <-__ata_scsi_queuecmd - bash-2042 3d..1 4us : ata_build_rw_tf <-ata_scsi_rw_xlat -[...] - bash-2042 3d..1 67us : delay_tsc <-__delay - bash-2042 3d..1 67us : add_preempt_count <-delay_tsc - bash-2042 3d..2 67us : sub_preempt_count <-delay_tsc - bash-2042 3d..1 67us : add_preempt_count <-delay_tsc - bash-2042 3d..2 68us : sub_preempt_count <-delay_tsc - bash-2042 3d..1 68us+: ata_bmdma_start <-ata_bmdma_qc_issue - bash-2042 3d..1 71us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd - bash-2042 3d..1 71us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd - bash-2042 3d..1 72us+: trace_hardirqs_on <-ata_scsi_queuecmd - bash-2042 3d..1 120us : <stack trace> - => _raw_spin_unlock_irqrestore - => ata_scsi_queuecmd - => scsi_dispatch_cmd - => scsi_request_fn - => __blk_run_queue_uncond - => __blk_run_queue - => blk_queue_bio - => generic_make_request - => submit_bio - => submit_bh - => __ext3_get_inode_loc - => ext3_iget - => ext3_lookup - => lookup_real - => __lookup_hash - => walk_component - => lookup_last - => path_lookupat - => filename_lookup - => user_path_at_empty - => user_path_at - => vfs_fstatat - => vfs_stat - => sys_newstat - => system_call_fastpath - - -Here we traced a 71 microsecond latency. But we also see all the -functions that were called during that time. Note that by -enabling function tracing, we incur an added overhead. This -overhead may extend the latency times. But nevertheless, this -trace has provided some very helpful debugging information. - - -preemptoff ----------- - -When preemption is disabled, we may be able to receive -interrupts but the task cannot be preempted and a higher -priority task must wait for preemption to be enabled again -before it can preempt a lower priority task. - -The preemptoff tracer traces the places that disable preemption. -Like the irqsoff tracer, it records the maximum latency for -which preemption was disabled. The control of preemptoff tracer -is much like the irqsoff tracer. - - # echo 0 > options/function-trace - # echo preemptoff > current_tracer - # echo 1 > tracing_on - # echo 0 > tracing_max_latency - # ls -ltr - [...] - # echo 0 > tracing_on - # cat trace -# tracer: preemptoff -# -# preemptoff latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 46 us, #4/4, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: sshd-1991 (uid:0 nice:0 policy:0 rt_prio:0) -# ----------------- -# => started at: do_IRQ -# => ended at: do_IRQ -# -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - sshd-1991 1d.h. 0us+: irq_enter <-do_IRQ - sshd-1991 1d..1 46us : irq_exit <-do_IRQ - sshd-1991 1d..1 47us+: trace_preempt_on <-do_IRQ - sshd-1991 1d..1 52us : <stack trace> - => sub_preempt_count - => irq_exit - => do_IRQ - => ret_from_intr - - -This has some more changes. Preemption was disabled when an -interrupt came in (notice the 'h'), and was enabled on exit. -But we also see that interrupts have been disabled when entering -the preempt off section and leaving it (the 'd'). We do not know if -interrupts were enabled in the mean time or shortly after this -was over. - -# tracer: preemptoff -# -# preemptoff latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 83 us, #241/241, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: bash-1994 (uid:0 nice:0 policy:0 rt_prio:0) -# ----------------- -# => started at: wake_up_new_task -# => ended at: task_rq_unlock -# -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - bash-1994 1d..1 0us : _raw_spin_lock_irqsave <-wake_up_new_task - bash-1994 1d..1 0us : select_task_rq_fair <-select_task_rq - bash-1994 1d..1 1us : __rcu_read_lock <-select_task_rq_fair - bash-1994 1d..1 1us : source_load <-select_task_rq_fair - bash-1994 1d..1 1us : source_load <-select_task_rq_fair -[...] - bash-1994 1d..1 12us : irq_enter <-smp_apic_timer_interrupt - bash-1994 1d..1 12us : rcu_irq_enter <-irq_enter - bash-1994 1d..1 13us : add_preempt_count <-irq_enter - bash-1994 1d.h1 13us : exit_idle <-smp_apic_timer_interrupt - bash-1994 1d.h1 13us : hrtimer_interrupt <-smp_apic_timer_interrupt - bash-1994 1d.h1 13us : _raw_spin_lock <-hrtimer_interrupt - bash-1994 1d.h1 14us : add_preempt_count <-_raw_spin_lock - bash-1994 1d.h2 14us : ktime_get_update_offsets <-hrtimer_interrupt -[...] - bash-1994 1d.h1 35us : lapic_next_event <-clockevents_program_event - bash-1994 1d.h1 35us : irq_exit <-smp_apic_timer_interrupt - bash-1994 1d.h1 36us : sub_preempt_count <-irq_exit - bash-1994 1d..2 36us : do_softirq <-irq_exit - bash-1994 1d..2 36us : __do_softirq <-call_softirq - bash-1994 1d..2 36us : __local_bh_disable <-__do_softirq - bash-1994 1d.s2 37us : add_preempt_count <-_raw_spin_lock_irq - bash-1994 1d.s3 38us : _raw_spin_unlock <-run_timer_softirq - bash-1994 1d.s3 39us : sub_preempt_count <-_raw_spin_unlock - bash-1994 1d.s2 39us : call_timer_fn <-run_timer_softirq -[...] - bash-1994 1dNs2 81us : cpu_needs_another_gp <-rcu_process_callbacks - bash-1994 1dNs2 82us : __local_bh_enable <-__do_softirq - bash-1994 1dNs2 82us : sub_preempt_count <-__local_bh_enable - bash-1994 1dN.2 82us : idle_cpu <-irq_exit - bash-1994 1dN.2 83us : rcu_irq_exit <-irq_exit - bash-1994 1dN.2 83us : sub_preempt_count <-irq_exit - bash-1994 1.N.1 84us : _raw_spin_unlock_irqrestore <-task_rq_unlock - bash-1994 1.N.1 84us+: trace_preempt_on <-task_rq_unlock - bash-1994 1.N.1 104us : <stack trace> - => sub_preempt_count - => _raw_spin_unlock_irqrestore - => task_rq_unlock - => wake_up_new_task - => do_fork - => sys_clone - => stub_clone - - -The above is an example of the preemptoff trace with -function-trace set. Here we see that interrupts were not disabled -the entire time. The irq_enter code lets us know that we entered -an interrupt 'h'. Before that, the functions being traced still -show that it is not in an interrupt, but we can see from the -functions themselves that this is not the case. - -preemptirqsoff --------------- - -Knowing the locations that have interrupts disabled or -preemption disabled for the longest times is helpful. But -sometimes we would like to know when either preemption and/or -interrupts are disabled. - -Consider the following code: - - local_irq_disable(); - call_function_with_irqs_off(); - preempt_disable(); - call_function_with_irqs_and_preemption_off(); - local_irq_enable(); - call_function_with_preemption_off(); - preempt_enable(); - -The irqsoff tracer will record the total length of -call_function_with_irqs_off() and -call_function_with_irqs_and_preemption_off(). - -The preemptoff tracer will record the total length of -call_function_with_irqs_and_preemption_off() and -call_function_with_preemption_off(). - -But neither will trace the time that interrupts and/or -preemption is disabled. This total time is the time that we can -not schedule. To record this time, use the preemptirqsoff -tracer. - -Again, using this trace is much like the irqsoff and preemptoff -tracers. - - # echo 0 > options/function-trace - # echo preemptirqsoff > current_tracer - # echo 1 > tracing_on - # echo 0 > tracing_max_latency - # ls -ltr - [...] - # echo 0 > tracing_on - # cat trace -# tracer: preemptirqsoff -# -# preemptirqsoff latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 100 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: ls-2230 (uid:0 nice:0 policy:0 rt_prio:0) -# ----------------- -# => started at: ata_scsi_queuecmd -# => ended at: ata_scsi_queuecmd -# -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - ls-2230 3d... 0us+: _raw_spin_lock_irqsave <-ata_scsi_queuecmd - ls-2230 3...1 100us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd - ls-2230 3...1 101us+: trace_preempt_on <-ata_scsi_queuecmd - ls-2230 3...1 111us : <stack trace> - => sub_preempt_count - => _raw_spin_unlock_irqrestore - => ata_scsi_queuecmd - => scsi_dispatch_cmd - => scsi_request_fn - => __blk_run_queue_uncond - => __blk_run_queue - => blk_queue_bio - => generic_make_request - => submit_bio - => submit_bh - => ext3_bread - => ext3_dir_bread - => htree_dirblock_to_tree - => ext3_htree_fill_tree - => ext3_readdir - => vfs_readdir - => sys_getdents - => system_call_fastpath - - -The trace_hardirqs_off_thunk is called from assembly on x86 when -interrupts are disabled in the assembly code. Without the -function tracing, we do not know if interrupts were enabled -within the preemption points. We do see that it started with -preemption enabled. - -Here is a trace with function-trace set: - -# tracer: preemptirqsoff -# -# preemptirqsoff latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 161 us, #339/339, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: ls-2269 (uid:0 nice:0 policy:0 rt_prio:0) -# ----------------- -# => started at: schedule -# => ended at: mutex_unlock -# -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / -kworker/-59 3...1 0us : __schedule <-schedule -kworker/-59 3d..1 0us : rcu_preempt_qs <-rcu_note_context_switch -kworker/-59 3d..1 1us : add_preempt_count <-_raw_spin_lock_irq -kworker/-59 3d..2 1us : deactivate_task <-__schedule -kworker/-59 3d..2 1us : dequeue_task <-deactivate_task -kworker/-59 3d..2 2us : update_rq_clock <-dequeue_task -kworker/-59 3d..2 2us : dequeue_task_fair <-dequeue_task -kworker/-59 3d..2 2us : update_curr <-dequeue_task_fair -kworker/-59 3d..2 2us : update_min_vruntime <-update_curr -kworker/-59 3d..2 3us : cpuacct_charge <-update_curr -kworker/-59 3d..2 3us : __rcu_read_lock <-cpuacct_charge -kworker/-59 3d..2 3us : __rcu_read_unlock <-cpuacct_charge -kworker/-59 3d..2 3us : update_cfs_rq_blocked_load <-dequeue_task_fair -kworker/-59 3d..2 4us : clear_buddies <-dequeue_task_fair -kworker/-59 3d..2 4us : account_entity_dequeue <-dequeue_task_fair -kworker/-59 3d..2 4us : update_min_vruntime <-dequeue_task_fair -kworker/-59 3d..2 4us : update_cfs_shares <-dequeue_task_fair -kworker/-59 3d..2 5us : hrtick_update <-dequeue_task_fair -kworker/-59 3d..2 5us : wq_worker_sleeping <-__schedule -kworker/-59 3d..2 5us : kthread_data <-wq_worker_sleeping -kworker/-59 3d..2 5us : put_prev_task_fair <-__schedule -kworker/-59 3d..2 6us : pick_next_task_fair <-pick_next_task -kworker/-59 3d..2 6us : clear_buddies <-pick_next_task_fair -kworker/-59 3d..2 6us : set_next_entity <-pick_next_task_fair -kworker/-59 3d..2 6us : update_stats_wait_end <-set_next_entity - ls-2269 3d..2 7us : finish_task_switch <-__schedule - ls-2269 3d..2 7us : _raw_spin_unlock_irq <-finish_task_switch - ls-2269 3d..2 8us : do_IRQ <-ret_from_intr - ls-2269 3d..2 8us : irq_enter <-do_IRQ - ls-2269 3d..2 8us : rcu_irq_enter <-irq_enter - ls-2269 3d..2 9us : add_preempt_count <-irq_enter - ls-2269 3d.h2 9us : exit_idle <-do_IRQ -[...] - ls-2269 3d.h3 20us : sub_preempt_count <-_raw_spin_unlock - ls-2269 3d.h2 20us : irq_exit <-do_IRQ - ls-2269 3d.h2 21us : sub_preempt_count <-irq_exit - ls-2269 3d..3 21us : do_softirq <-irq_exit - ls-2269 3d..3 21us : __do_softirq <-call_softirq - ls-2269 3d..3 21us+: __local_bh_disable <-__do_softirq - ls-2269 3d.s4 29us : sub_preempt_count <-_local_bh_enable_ip - ls-2269 3d.s5 29us : sub_preempt_count <-_local_bh_enable_ip - ls-2269 3d.s5 31us : do_IRQ <-ret_from_intr - ls-2269 3d.s5 31us : irq_enter <-do_IRQ - ls-2269 3d.s5 31us : rcu_irq_enter <-irq_enter -[...] - ls-2269 3d.s5 31us : rcu_irq_enter <-irq_enter - ls-2269 3d.s5 32us : add_preempt_count <-irq_enter - ls-2269 3d.H5 32us : exit_idle <-do_IRQ - ls-2269 3d.H5 32us : handle_irq <-do_IRQ - ls-2269 3d.H5 32us : irq_to_desc <-handle_irq - ls-2269 3d.H5 33us : handle_fasteoi_irq <-handle_irq -[...] - ls-2269 3d.s5 158us : _raw_spin_unlock_irqrestore <-rtl8139_poll - ls-2269 3d.s3 158us : net_rps_action_and_irq_enable.isra.65 <-net_rx_action - ls-2269 3d.s3 159us : __local_bh_enable <-__do_softirq - ls-2269 3d.s3 159us : sub_preempt_count <-__local_bh_enable - ls-2269 3d..3 159us : idle_cpu <-irq_exit - ls-2269 3d..3 159us : rcu_irq_exit <-irq_exit - ls-2269 3d..3 160us : sub_preempt_count <-irq_exit - ls-2269 3d... 161us : __mutex_unlock_slowpath <-mutex_unlock - ls-2269 3d... 162us+: trace_hardirqs_on <-mutex_unlock - ls-2269 3d... 186us : <stack trace> - => __mutex_unlock_slowpath - => mutex_unlock - => process_output - => n_tty_write - => tty_write - => vfs_write - => sys_write - => system_call_fastpath - -This is an interesting trace. It started with kworker running and -scheduling out and ls taking over. But as soon as ls released the -rq lock and enabled interrupts (but not preemption) an interrupt -triggered. When the interrupt finished, it started running softirqs. -But while the softirq was running, another interrupt triggered. -When an interrupt is running inside a softirq, the annotation is 'H'. - - -wakeup ------- - -One common case that people are interested in tracing is the -time it takes for a task that is woken to actually wake up. -Now for non Real-Time tasks, this can be arbitrary. But tracing -it none the less can be interesting. - -Without function tracing: - - # echo 0 > options/function-trace - # echo wakeup > current_tracer - # echo 1 > tracing_on - # echo 0 > tracing_max_latency - # chrt -f 5 sleep 1 - # echo 0 > tracing_on - # cat trace -# tracer: wakeup -# -# wakeup latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 15 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: kworker/3:1H-312 (uid:0 nice:-20 policy:0 rt_prio:0) -# ----------------- -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - <idle>-0 3dNs7 0us : 0:120:R + [003] 312:100:R kworker/3:1H - <idle>-0 3dNs7 1us+: ttwu_do_activate.constprop.87 <-try_to_wake_up - <idle>-0 3d..3 15us : __schedule <-schedule - <idle>-0 3d..3 15us : 0:120:R ==> [003] 312:100:R kworker/3:1H - -The tracer only traces the highest priority task in the system -to avoid tracing the normal circumstances. Here we see that -the kworker with a nice priority of -20 (not very nice), took -just 15 microseconds from the time it woke up, to the time it -ran. - -Non Real-Time tasks are not that interesting. A more interesting -trace is to concentrate only on Real-Time tasks. - -wakeup_rt ---------- - -In a Real-Time environment it is very important to know the -wakeup time it takes for the highest priority task that is woken -up to the time that it executes. This is also known as "schedule -latency". I stress the point that this is about RT tasks. It is -also important to know the scheduling latency of non-RT tasks, -but the average schedule latency is better for non-RT tasks. -Tools like LatencyTop are more appropriate for such -measurements. - -Real-Time environments are interested in the worst case latency. -That is the longest latency it takes for something to happen, -and not the average. We can have a very fast scheduler that may -only have a large latency once in a while, but that would not -work well with Real-Time tasks. The wakeup_rt tracer was designed -to record the worst case wakeups of RT tasks. Non-RT tasks are -not recorded because the tracer only records one worst case and -tracing non-RT tasks that are unpredictable will overwrite the -worst case latency of RT tasks (just run the normal wakeup -tracer for a while to see that effect). - -Since this tracer only deals with RT tasks, we will run this -slightly differently than we did with the previous tracers. -Instead of performing an 'ls', we will run 'sleep 1' under -'chrt' which changes the priority of the task. - - # echo 0 > options/function-trace - # echo wakeup_rt > current_tracer - # echo 1 > tracing_on - # echo 0 > tracing_max_latency - # chrt -f 5 sleep 1 - # echo 0 > tracing_on - # cat trace -# tracer: wakeup -# -# tracer: wakeup_rt -# -# wakeup_rt latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 5 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: sleep-2389 (uid:0 nice:0 policy:1 rt_prio:5) -# ----------------- -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - <idle>-0 3d.h4 0us : 0:120:R + [003] 2389: 94:R sleep - <idle>-0 3d.h4 1us+: ttwu_do_activate.constprop.87 <-try_to_wake_up - <idle>-0 3d..3 5us : __schedule <-schedule - <idle>-0 3d..3 5us : 0:120:R ==> [003] 2389: 94:R sleep - - -Running this on an idle system, we see that it only took 5 microseconds -to perform the task switch. Note, since the trace point in the schedule -is before the actual "switch", we stop the tracing when the recorded task -is about to schedule in. This may change if we add a new marker at the -end of the scheduler. - -Notice that the recorded task is 'sleep' with the PID of 2389 -and it has an rt_prio of 5. This priority is user-space priority -and not the internal kernel priority. The policy is 1 for -SCHED_FIFO and 2 for SCHED_RR. - -Note, that the trace data shows the internal priority (99 - rtprio). - - <idle>-0 3d..3 5us : 0:120:R ==> [003] 2389: 94:R sleep - -The 0:120:R means idle was running with a nice priority of 0 (120 - 120) -and in the running state 'R'. The sleep task was scheduled in with -2389: 94:R. That is the priority is the kernel rtprio (99 - 5 = 94) -and it too is in the running state. - -Doing the same with chrt -r 5 and function-trace set. - - echo 1 > options/function-trace - -# tracer: wakeup_rt -# -# wakeup_rt latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 29 us, #85/85, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: sleep-2448 (uid:0 nice:0 policy:1 rt_prio:5) -# ----------------- -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - <idle>-0 3d.h4 1us+: 0:120:R + [003] 2448: 94:R sleep - <idle>-0 3d.h4 2us : ttwu_do_activate.constprop.87 <-try_to_wake_up - <idle>-0 3d.h3 3us : check_preempt_curr <-ttwu_do_wakeup - <idle>-0 3d.h3 3us : resched_curr <-check_preempt_curr - <idle>-0 3dNh3 4us : task_woken_rt <-ttwu_do_wakeup - <idle>-0 3dNh3 4us : _raw_spin_unlock <-try_to_wake_up - <idle>-0 3dNh3 4us : sub_preempt_count <-_raw_spin_unlock - <idle>-0 3dNh2 5us : ttwu_stat <-try_to_wake_up - <idle>-0 3dNh2 5us : _raw_spin_unlock_irqrestore <-try_to_wake_up - <idle>-0 3dNh2 6us : sub_preempt_count <-_raw_spin_unlock_irqrestore - <idle>-0 3dNh1 6us : _raw_spin_lock <-__run_hrtimer - <idle>-0 3dNh1 6us : add_preempt_count <-_raw_spin_lock - <idle>-0 3dNh2 7us : _raw_spin_unlock <-hrtimer_interrupt - <idle>-0 3dNh2 7us : sub_preempt_count <-_raw_spin_unlock - <idle>-0 3dNh1 7us : tick_program_event <-hrtimer_interrupt - <idle>-0 3dNh1 7us : clockevents_program_event <-tick_program_event - <idle>-0 3dNh1 8us : ktime_get <-clockevents_program_event - <idle>-0 3dNh1 8us : lapic_next_event <-clockevents_program_event - <idle>-0 3dNh1 8us : irq_exit <-smp_apic_timer_interrupt - <idle>-0 3dNh1 9us : sub_preempt_count <-irq_exit - <idle>-0 3dN.2 9us : idle_cpu <-irq_exit - <idle>-0 3dN.2 9us : rcu_irq_exit <-irq_exit - <idle>-0 3dN.2 10us : rcu_eqs_enter_common.isra.45 <-rcu_irq_exit - <idle>-0 3dN.2 10us : sub_preempt_count <-irq_exit - <idle>-0 3.N.1 11us : rcu_idle_exit <-cpu_idle - <idle>-0 3dN.1 11us : rcu_eqs_exit_common.isra.43 <-rcu_idle_exit - <idle>-0 3.N.1 11us : tick_nohz_idle_exit <-cpu_idle - <idle>-0 3dN.1 12us : menu_hrtimer_cancel <-tick_nohz_idle_exit - <idle>-0 3dN.1 12us : ktime_get <-tick_nohz_idle_exit - <idle>-0 3dN.1 12us : tick_do_update_jiffies64 <-tick_nohz_idle_exit - <idle>-0 3dN.1 13us : cpu_load_update_nohz <-tick_nohz_idle_exit - <idle>-0 3dN.1 13us : _raw_spin_lock <-cpu_load_update_nohz - <idle>-0 3dN.1 13us : add_preempt_count <-_raw_spin_lock - <idle>-0 3dN.2 13us : __cpu_load_update <-cpu_load_update_nohz - <idle>-0 3dN.2 14us : sched_avg_update <-__cpu_load_update - <idle>-0 3dN.2 14us : _raw_spin_unlock <-cpu_load_update_nohz - <idle>-0 3dN.2 14us : sub_preempt_count <-_raw_spin_unlock - <idle>-0 3dN.1 15us : calc_load_nohz_stop <-tick_nohz_idle_exit - <idle>-0 3dN.1 15us : touch_softlockup_watchdog <-tick_nohz_idle_exit - <idle>-0 3dN.1 15us : hrtimer_cancel <-tick_nohz_idle_exit - <idle>-0 3dN.1 15us : hrtimer_try_to_cancel <-hrtimer_cancel - <idle>-0 3dN.1 16us : lock_hrtimer_base.isra.18 <-hrtimer_try_to_cancel - <idle>-0 3dN.1 16us : _raw_spin_lock_irqsave <-lock_hrtimer_base.isra.18 - <idle>-0 3dN.1 16us : add_preempt_count <-_raw_spin_lock_irqsave - <idle>-0 3dN.2 17us : __remove_hrtimer <-remove_hrtimer.part.16 - <idle>-0 3dN.2 17us : hrtimer_force_reprogram <-__remove_hrtimer - <idle>-0 3dN.2 17us : tick_program_event <-hrtimer_force_reprogram - <idle>-0 3dN.2 18us : clockevents_program_event <-tick_program_event - <idle>-0 3dN.2 18us : ktime_get <-clockevents_program_event - <idle>-0 3dN.2 18us : lapic_next_event <-clockevents_program_event - <idle>-0 3dN.2 19us : _raw_spin_unlock_irqrestore <-hrtimer_try_to_cancel - <idle>-0 3dN.2 19us : sub_preempt_count <-_raw_spin_unlock_irqrestore - <idle>-0 3dN.1 19us : hrtimer_forward <-tick_nohz_idle_exit - <idle>-0 3dN.1 20us : ktime_add_safe <-hrtimer_forward - <idle>-0 3dN.1 20us : ktime_add_safe <-hrtimer_forward - <idle>-0 3dN.1 20us : hrtimer_start_range_ns <-hrtimer_start_expires.constprop.11 - <idle>-0 3dN.1 20us : __hrtimer_start_range_ns <-hrtimer_start_range_ns - <idle>-0 3dN.1 21us : lock_hrtimer_base.isra.18 <-__hrtimer_start_range_ns - <idle>-0 3dN.1 21us : _raw_spin_lock_irqsave <-lock_hrtimer_base.isra.18 - <idle>-0 3dN.1 21us : add_preempt_count <-_raw_spin_lock_irqsave - <idle>-0 3dN.2 22us : ktime_add_safe <-__hrtimer_start_range_ns - <idle>-0 3dN.2 22us : enqueue_hrtimer <-__hrtimer_start_range_ns - <idle>-0 3dN.2 22us : tick_program_event <-__hrtimer_start_range_ns - <idle>-0 3dN.2 23us : clockevents_program_event <-tick_program_event - <idle>-0 3dN.2 23us : ktime_get <-clockevents_program_event - <idle>-0 3dN.2 23us : lapic_next_event <-clockevents_program_event - <idle>-0 3dN.2 24us : _raw_spin_unlock_irqrestore <-__hrtimer_start_range_ns - <idle>-0 3dN.2 24us : sub_preempt_count <-_raw_spin_unlock_irqrestore - <idle>-0 3dN.1 24us : account_idle_ticks <-tick_nohz_idle_exit - <idle>-0 3dN.1 24us : account_idle_time <-account_idle_ticks - <idle>-0 3.N.1 25us : sub_preempt_count <-cpu_idle - <idle>-0 3.N.. 25us : schedule <-cpu_idle - <idle>-0 3.N.. 25us : __schedule <-preempt_schedule - <idle>-0 3.N.. 26us : add_preempt_count <-__schedule - <idle>-0 3.N.1 26us : rcu_note_context_switch <-__schedule - <idle>-0 3.N.1 26us : rcu_sched_qs <-rcu_note_context_switch - <idle>-0 3dN.1 27us : rcu_preempt_qs <-rcu_note_context_switch - <idle>-0 3.N.1 27us : _raw_spin_lock_irq <-__schedule - <idle>-0 3dN.1 27us : add_preempt_count <-_raw_spin_lock_irq - <idle>-0 3dN.2 28us : put_prev_task_idle <-__schedule - <idle>-0 3dN.2 28us : pick_next_task_stop <-pick_next_task - <idle>-0 3dN.2 28us : pick_next_task_rt <-pick_next_task - <idle>-0 3dN.2 29us : dequeue_pushable_task <-pick_next_task_rt - <idle>-0 3d..3 29us : __schedule <-preempt_schedule - <idle>-0 3d..3 30us : 0:120:R ==> [003] 2448: 94:R sleep - -This isn't that big of a trace, even with function tracing enabled, -so I included the entire trace. - -The interrupt went off while when the system was idle. Somewhere -before task_woken_rt() was called, the NEED_RESCHED flag was set, -this is indicated by the first occurrence of the 'N' flag. - -Latency tracing and events --------------------------- -As function tracing can induce a much larger latency, but without -seeing what happens within the latency it is hard to know what -caused it. There is a middle ground, and that is with enabling -events. - - # echo 0 > options/function-trace - # echo wakeup_rt > current_tracer - # echo 1 > events/enable - # echo 1 > tracing_on - # echo 0 > tracing_max_latency - # chrt -f 5 sleep 1 - # echo 0 > tracing_on - # cat trace -# tracer: wakeup_rt -# -# wakeup_rt latency trace v1.1.5 on 3.8.0-test+ -# -------------------------------------------------------------------- -# latency: 6 us, #12/12, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4) -# ----------------- -# | task: sleep-5882 (uid:0 nice:0 policy:1 rt_prio:5) -# ----------------- -# -# _------=> CPU# -# / _-----=> irqs-off -# | / _----=> need-resched -# || / _---=> hardirq/softirq -# ||| / _--=> preempt-depth -# |||| / delay -# cmd pid ||||| time | caller -# \ / ||||| \ | / - <idle>-0 2d.h4 0us : 0:120:R + [002] 5882: 94:R sleep - <idle>-0 2d.h4 0us : ttwu_do_activate.constprop.87 <-try_to_wake_up - <idle>-0 2d.h4 1us : sched_wakeup: comm=sleep pid=5882 prio=94 success=1 target_cpu=002 - <idle>-0 2dNh2 1us : hrtimer_expire_exit: hrtimer=ffff88007796feb8 - <idle>-0 2.N.2 2us : power_end: cpu_id=2 - <idle>-0 2.N.2 3us : cpu_idle: state=4294967295 cpu_id=2 - <idle>-0 2dN.3 4us : hrtimer_cancel: hrtimer=ffff88007d50d5e0 - <idle>-0 2dN.3 4us : hrtimer_start: hrtimer=ffff88007d50d5e0 function=tick_sched_timer expires=34311211000000 softexpires=34311211000000 - <idle>-0 2.N.2 5us : rcu_utilization: Start context switch - <idle>-0 2.N.2 5us : rcu_utilization: End context switch - <idle>-0 2d..3 6us : __schedule <-schedule - <idle>-0 2d..3 6us : 0:120:R ==> [002] 5882: 94:R sleep - - -Hardware Latency Detector -------------------------- - -The hardware latency detector is executed by enabling the "hwlat" tracer. - -NOTE, this tracer will affect the performance of the system as it will -periodically make a CPU constantly busy with interrupts disabled. - - # echo hwlat > current_tracer - # sleep 100 - # cat trace -# tracer: hwlat -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - <...>-3638 [001] d... 19452.055471: #1 inner/outer(us): 12/14 ts:1499801089.066141940 - <...>-3638 [003] d... 19454.071354: #2 inner/outer(us): 11/9 ts:1499801091.082164365 - <...>-3638 [002] dn.. 19461.126852: #3 inner/outer(us): 12/9 ts:1499801098.138150062 - <...>-3638 [001] d... 19488.340960: #4 inner/outer(us): 8/12 ts:1499801125.354139633 - <...>-3638 [003] d... 19494.388553: #5 inner/outer(us): 8/12 ts:1499801131.402150961 - <...>-3638 [003] d... 19501.283419: #6 inner/outer(us): 0/12 ts:1499801138.297435289 nmi-total:4 nmi-count:1 - - -The above output is somewhat the same in the header. All events will have -interrupts disabled 'd'. Under the FUNCTION title there is: - - #1 - This is the count of events recorded that were greater than the - tracing_threshold (See below). - - inner/outer(us): 12/14 - - This shows two numbers as "inner latency" and "outer latency". The test - runs in a loop checking a timestamp twice. The latency detected within - the two timestamps is the "inner latency" and the latency detected - after the previous timestamp and the next timestamp in the loop is - the "outer latency". - - ts:1499801089.066141940 - - The absolute timestamp that the event happened. - - nmi-total:4 nmi-count:1 - - On architectures that support it, if an NMI comes in during the - test, the time spent in NMI is reported in "nmi-total" (in - microseconds). - - All architectures that have NMIs will show the "nmi-count" if an - NMI comes in during the test. - -hwlat files: - - tracing_threshold - This gets automatically set to "10" to represent 10 - microseconds. This is the threshold of latency that - needs to be detected before the trace will be recorded. - - Note, when hwlat tracer is finished (another tracer is - written into "current_tracer"), the original value for - tracing_threshold is placed back into this file. - - hwlat_detector/width - The length of time the test runs with interrupts - disabled. - - hwlat_detector/window - The length of time of the window which the test - runs. That is, the test will run for "width" - microseconds per "window" microseconds - - tracing_cpumask - When the test is started. A kernel thread is created that - runs the test. This thread will alternate between CPUs - listed in the tracing_cpumask between each period - (one "window"). To limit the test to specific CPUs - set the mask in this file to only the CPUs that the test - should run on. - -function --------- - -This tracer is the function tracer. Enabling the function tracer -can be done from the debug file system. Make sure the -ftrace_enabled is set; otherwise this tracer is a nop. -See the "ftrace_enabled" section below. - - # sysctl kernel.ftrace_enabled=1 - # echo function > current_tracer - # echo 1 > tracing_on - # usleep 1 - # echo 0 > tracing_on - # cat trace -# tracer: function -# -# entries-in-buffer/entries-written: 24799/24799 #P:4 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - bash-1994 [002] .... 3082.063030: mutex_unlock <-rb_simple_write - bash-1994 [002] .... 3082.063031: __mutex_unlock_slowpath <-mutex_unlock - bash-1994 [002] .... 3082.063031: __fsnotify_parent <-fsnotify_modify - bash-1994 [002] .... 3082.063032: fsnotify <-fsnotify_modify - bash-1994 [002] .... 3082.063032: __srcu_read_lock <-fsnotify - bash-1994 [002] .... 3082.063032: add_preempt_count <-__srcu_read_lock - bash-1994 [002] ...1 3082.063032: sub_preempt_count <-__srcu_read_lock - bash-1994 [002] .... 3082.063033: __srcu_read_unlock <-fsnotify -[...] - - -Note: function tracer uses ring buffers to store the above -entries. The newest data may overwrite the oldest data. -Sometimes using echo to stop the trace is not sufficient because -the tracing could have overwritten the data that you wanted to -record. For this reason, it is sometimes better to disable -tracing directly from a program. This allows you to stop the -tracing at the point that you hit the part that you are -interested in. To disable the tracing directly from a C program, -something like following code snippet can be used: - -int trace_fd; -[...] -int main(int argc, char *argv[]) { - [...] - trace_fd = open(tracing_file("tracing_on"), O_WRONLY); - [...] - if (condition_hit()) { - write(trace_fd, "0", 1); - } - [...] -} - - -Single thread tracing ---------------------- - -By writing into set_ftrace_pid you can trace a -single thread. For example: - -# cat set_ftrace_pid -no pid -# echo 3111 > set_ftrace_pid -# cat set_ftrace_pid -3111 -# echo function > current_tracer -# cat trace | head - # tracer: function - # - # TASK-PID CPU# TIMESTAMP FUNCTION - # | | | | | - yum-updatesd-3111 [003] 1637.254676: finish_task_switch <-thread_return - yum-updatesd-3111 [003] 1637.254681: hrtimer_cancel <-schedule_hrtimeout_range - yum-updatesd-3111 [003] 1637.254682: hrtimer_try_to_cancel <-hrtimer_cancel - yum-updatesd-3111 [003] 1637.254683: lock_hrtimer_base <-hrtimer_try_to_cancel - yum-updatesd-3111 [003] 1637.254685: fget_light <-do_sys_poll - yum-updatesd-3111 [003] 1637.254686: pipe_poll <-do_sys_poll -# echo > set_ftrace_pid -# cat trace |head - # tracer: function - # - # TASK-PID CPU# TIMESTAMP FUNCTION - # | | | | | - ##### CPU 3 buffer started #### - yum-updatesd-3111 [003] 1701.957688: free_poll_entry <-poll_freewait - yum-updatesd-3111 [003] 1701.957689: remove_wait_queue <-free_poll_entry - yum-updatesd-3111 [003] 1701.957691: fput <-free_poll_entry - yum-updatesd-3111 [003] 1701.957692: audit_syscall_exit <-sysret_audit - yum-updatesd-3111 [003] 1701.957693: path_put <-audit_syscall_exit - -If you want to trace a function when executing, you could use -something like this simple program: - -#include <stdio.h> -#include <stdlib.h> -#include <sys/types.h> -#include <sys/stat.h> -#include <fcntl.h> -#include <unistd.h> -#include <string.h> - -#define _STR(x) #x -#define STR(x) _STR(x) -#define MAX_PATH 256 - -const char *find_tracefs(void) -{ - static char tracefs[MAX_PATH+1]; - static int tracefs_found; - char type[100]; - FILE *fp; - - if (tracefs_found) - return tracefs; - - if ((fp = fopen("/proc/mounts","r")) == NULL) { - perror("/proc/mounts"); - return NULL; - } - - while (fscanf(fp, "%*s %" - STR(MAX_PATH) - "s %99s %*s %*d %*d\n", - tracefs, type) == 2) { - if (strcmp(type, "tracefs") == 0) - break; - } - fclose(fp); - - if (strcmp(type, "tracefs") != 0) { - fprintf(stderr, "tracefs not mounted"); - return NULL; - } - - strcat(tracefs, "/tracing/"); - tracefs_found = 1; - - return tracefs; -} - -const char *tracing_file(const char *file_name) -{ - static char trace_file[MAX_PATH+1]; - snprintf(trace_file, MAX_PATH, "%s/%s", find_tracefs(), file_name); - return trace_file; -} - -int main (int argc, char **argv) -{ - if (argc < 1) - exit(-1); - - if (fork() > 0) { - int fd, ffd; - char line[64]; - int s; - - ffd = open(tracing_file("current_tracer"), O_WRONLY); - if (ffd < 0) - exit(-1); - write(ffd, "nop", 3); - - fd = open(tracing_file("set_ftrace_pid"), O_WRONLY); - s = sprintf(line, "%d\n", getpid()); - write(fd, line, s); - - write(ffd, "function", 8); - - close(fd); - close(ffd); - - execvp(argv[1], argv+1); - } - - return 0; -} - -Or this simple script! - ------- -#!/bin/bash - -tracefs=`sed -ne 's/^tracefs \(.*\) tracefs.*/\1/p' /proc/mounts` -echo nop > $tracefs/tracing/current_tracer -echo 0 > $tracefs/tracing/tracing_on -echo $$ > $tracefs/tracing/set_ftrace_pid -echo function > $tracefs/tracing/current_tracer -echo 1 > $tracefs/tracing/tracing_on -exec "$@" ------- - - -function graph tracer ---------------------------- - -This tracer is similar to the function tracer except that it -probes a function on its entry and its exit. This is done by -using a dynamically allocated stack of return addresses in each -task_struct. On function entry the tracer overwrites the return -address of each function traced to set a custom probe. Thus the -original return address is stored on the stack of return address -in the task_struct. - -Probing on both ends of a function leads to special features -such as: - -- measure of a function's time execution -- having a reliable call stack to draw function calls graph - -This tracer is useful in several situations: - -- you want to find the reason of a strange kernel behavior and - need to see what happens in detail on any areas (or specific - ones). - -- you are experiencing weird latencies but it's difficult to - find its origin. - -- you want to find quickly which path is taken by a specific - function - -- you just want to peek inside a working kernel and want to see - what happens there. - -# tracer: function_graph -# -# CPU DURATION FUNCTION CALLS -# | | | | | | | - - 0) | sys_open() { - 0) | do_sys_open() { - 0) | getname() { - 0) | kmem_cache_alloc() { - 0) 1.382 us | __might_sleep(); - 0) 2.478 us | } - 0) | strncpy_from_user() { - 0) | might_fault() { - 0) 1.389 us | __might_sleep(); - 0) 2.553 us | } - 0) 3.807 us | } - 0) 7.876 us | } - 0) | alloc_fd() { - 0) 0.668 us | _spin_lock(); - 0) 0.570 us | expand_files(); - 0) 0.586 us | _spin_unlock(); - - -There are several columns that can be dynamically -enabled/disabled. You can use every combination of options you -want, depending on your needs. - -- The cpu number on which the function executed is default - enabled. It is sometimes better to only trace one cpu (see - tracing_cpu_mask file) or you might sometimes see unordered - function calls while cpu tracing switch. - - hide: echo nofuncgraph-cpu > trace_options - show: echo funcgraph-cpu > trace_options - -- The duration (function's time of execution) is displayed on - the closing bracket line of a function or on the same line - than the current function in case of a leaf one. It is default - enabled. - - hide: echo nofuncgraph-duration > trace_options - show: echo funcgraph-duration > trace_options - -- The overhead field precedes the duration field in case of - reached duration thresholds. - - hide: echo nofuncgraph-overhead > trace_options - show: echo funcgraph-overhead > trace_options - depends on: funcgraph-duration - - ie: - - 3) # 1837.709 us | } /* __switch_to */ - 3) | finish_task_switch() { - 3) 0.313 us | _raw_spin_unlock_irq(); - 3) 3.177 us | } - 3) # 1889.063 us | } /* __schedule */ - 3) ! 140.417 us | } /* __schedule */ - 3) # 2034.948 us | } /* schedule */ - 3) * 33998.59 us | } /* schedule_preempt_disabled */ - - [...] - - 1) 0.260 us | msecs_to_jiffies(); - 1) 0.313 us | __rcu_read_unlock(); - 1) + 61.770 us | } - 1) + 64.479 us | } - 1) 0.313 us | rcu_bh_qs(); - 1) 0.313 us | __local_bh_enable(); - 1) ! 217.240 us | } - 1) 0.365 us | idle_cpu(); - 1) | rcu_irq_exit() { - 1) 0.417 us | rcu_eqs_enter_common.isra.47(); - 1) 3.125 us | } - 1) ! 227.812 us | } - 1) ! 457.395 us | } - 1) @ 119760.2 us | } - - [...] - - 2) | handle_IPI() { - 1) 6.979 us | } - 2) 0.417 us | scheduler_ipi(); - 1) 9.791 us | } - 1) + 12.917 us | } - 2) 3.490 us | } - 1) + 15.729 us | } - 1) + 18.542 us | } - 2) $ 3594274 us | } - - + means that the function exceeded 10 usecs. - ! means that the function exceeded 100 usecs. - # means that the function exceeded 1000 usecs. - * means that the function exceeded 10 msecs. - @ means that the function exceeded 100 msecs. - $ means that the function exceeded 1 sec. - - -- The task/pid field displays the thread cmdline and pid which - executed the function. It is default disabled. - - hide: echo nofuncgraph-proc > trace_options - show: echo funcgraph-proc > trace_options - - ie: - - # tracer: function_graph - # - # CPU TASK/PID DURATION FUNCTION CALLS - # | | | | | | | | | - 0) sh-4802 | | d_free() { - 0) sh-4802 | | call_rcu() { - 0) sh-4802 | | __call_rcu() { - 0) sh-4802 | 0.616 us | rcu_process_gp_end(); - 0) sh-4802 | 0.586 us | check_for_new_grace_period(); - 0) sh-4802 | 2.899 us | } - 0) sh-4802 | 4.040 us | } - 0) sh-4802 | 5.151 us | } - 0) sh-4802 | + 49.370 us | } - - -- The absolute time field is an absolute timestamp given by the - system clock since it started. A snapshot of this time is - given on each entry/exit of functions - - hide: echo nofuncgraph-abstime > trace_options - show: echo funcgraph-abstime > trace_options - - ie: - - # - # TIME CPU DURATION FUNCTION CALLS - # | | | | | | | | - 360.774522 | 1) 0.541 us | } - 360.774522 | 1) 4.663 us | } - 360.774523 | 1) 0.541 us | __wake_up_bit(); - 360.774524 | 1) 6.796 us | } - 360.774524 | 1) 7.952 us | } - 360.774525 | 1) 9.063 us | } - 360.774525 | 1) 0.615 us | journal_mark_dirty(); - 360.774527 | 1) 0.578 us | __brelse(); - 360.774528 | 1) | reiserfs_prepare_for_journal() { - 360.774528 | 1) | unlock_buffer() { - 360.774529 | 1) | wake_up_bit() { - 360.774529 | 1) | bit_waitqueue() { - 360.774530 | 1) 0.594 us | __phys_addr(); - - -The function name is always displayed after the closing bracket -for a function if the start of that function is not in the -trace buffer. - -Display of the function name after the closing bracket may be -enabled for functions whose start is in the trace buffer, -allowing easier searching with grep for function durations. -It is default disabled. - - hide: echo nofuncgraph-tail > trace_options - show: echo funcgraph-tail > trace_options - - Example with nofuncgraph-tail (default): - 0) | putname() { - 0) | kmem_cache_free() { - 0) 0.518 us | __phys_addr(); - 0) 1.757 us | } - 0) 2.861 us | } - - Example with funcgraph-tail: - 0) | putname() { - 0) | kmem_cache_free() { - 0) 0.518 us | __phys_addr(); - 0) 1.757 us | } /* kmem_cache_free() */ - 0) 2.861 us | } /* putname() */ - -You can put some comments on specific functions by using -trace_printk() For example, if you want to put a comment inside -the __might_sleep() function, you just have to include -<linux/ftrace.h> and call trace_printk() inside __might_sleep() - -trace_printk("I'm a comment!\n") - -will produce: - - 1) | __might_sleep() { - 1) | /* I'm a comment! */ - 1) 1.449 us | } - - -You might find other useful features for this tracer in the -following "dynamic ftrace" section such as tracing only specific -functions or tasks. - -dynamic ftrace --------------- - -If CONFIG_DYNAMIC_FTRACE is set, the system will run with -virtually no overhead when function tracing is disabled. The way -this works is the mcount function call (placed at the start of -every kernel function, produced by the -pg switch in gcc), -starts of pointing to a simple return. (Enabling FTRACE will -include the -pg switch in the compiling of the kernel.) - -At compile time every C file object is run through the -recordmcount program (located in the scripts directory). This -program will parse the ELF headers in the C object to find all -the locations in the .text section that call mcount. Starting -with gcc verson 4.6, the -mfentry has been added for x86, which -calls "__fentry__" instead of "mcount". Which is called before -the creation of the stack frame. - -Note, not all sections are traced. They may be prevented by either -a notrace, or blocked another way and all inline functions are not -traced. Check the "available_filter_functions" file to see what functions -can be traced. - -A section called "__mcount_loc" is created that holds -references to all the mcount/fentry call sites in the .text section. -The recordmcount program re-links this section back into the -original object. The final linking stage of the kernel will add all these -references into a single table. - -On boot up, before SMP is initialized, the dynamic ftrace code -scans this table and updates all the locations into nops. It -also records the locations, which are added to the -available_filter_functions list. Modules are processed as they -are loaded and before they are executed. When a module is -unloaded, it also removes its functions from the ftrace function -list. This is automatic in the module unload code, and the -module author does not need to worry about it. - -When tracing is enabled, the process of modifying the function -tracepoints is dependent on architecture. The old method is to use -kstop_machine to prevent races with the CPUs executing code being -modified (which can cause the CPU to do undesirable things, especially -if the modified code crosses cache (or page) boundaries), and the nops are -patched back to calls. But this time, they do not call mcount -(which is just a function stub). They now call into the ftrace -infrastructure. - -The new method of modifying the function tracepoints is to place -a breakpoint at the location to be modified, sync all CPUs, modify -the rest of the instruction not covered by the breakpoint. Sync -all CPUs again, and then remove the breakpoint with the finished -version to the ftrace call site. - -Some archs do not even need to monkey around with the synchronization, -and can just slap the new code on top of the old without any -problems with other CPUs executing it at the same time. - -One special side-effect to the recording of the functions being -traced is that we can now selectively choose which functions we -wish to trace and which ones we want the mcount calls to remain -as nops. - -Two files are used, one for enabling and one for disabling the -tracing of specified functions. They are: - - set_ftrace_filter - -and - - set_ftrace_notrace - -A list of available functions that you can add to these files is -listed in: - - available_filter_functions - - # cat available_filter_functions -put_prev_task_idle -kmem_cache_create -pick_next_task_rt -get_online_cpus -pick_next_task_fair -mutex_lock -[...] - -If I am only interested in sys_nanosleep and hrtimer_interrupt: - - # echo sys_nanosleep hrtimer_interrupt > set_ftrace_filter - # echo function > current_tracer - # echo 1 > tracing_on - # usleep 1 - # echo 0 > tracing_on - # cat trace -# tracer: function -# -# entries-in-buffer/entries-written: 5/5 #P:4 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - usleep-2665 [001] .... 4186.475355: sys_nanosleep <-system_call_fastpath - <idle>-0 [001] d.h1 4186.475409: hrtimer_interrupt <-smp_apic_timer_interrupt - usleep-2665 [001] d.h1 4186.475426: hrtimer_interrupt <-smp_apic_timer_interrupt - <idle>-0 [003] d.h1 4186.475426: hrtimer_interrupt <-smp_apic_timer_interrupt - <idle>-0 [002] d.h1 4186.475427: hrtimer_interrupt <-smp_apic_timer_interrupt - -To see which functions are being traced, you can cat the file: - - # cat set_ftrace_filter -hrtimer_interrupt -sys_nanosleep - - -Perhaps this is not enough. The filters also allow glob(7) matching. - - <match>* - will match functions that begin with <match> - *<match> - will match functions that end with <match> - *<match>* - will match functions that have <match> in it - <match1>*<match2> - will match functions that begin with - <match1> and end with <match2> - -Note: It is better to use quotes to enclose the wild cards, - otherwise the shell may expand the parameters into names - of files in the local directory. - - # echo 'hrtimer_*' > set_ftrace_filter - -Produces: - -# tracer: function -# -# entries-in-buffer/entries-written: 897/897 #P:4 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - <idle>-0 [003] dN.1 4228.547803: hrtimer_cancel <-tick_nohz_idle_exit - <idle>-0 [003] dN.1 4228.547804: hrtimer_try_to_cancel <-hrtimer_cancel - <idle>-0 [003] dN.2 4228.547805: hrtimer_force_reprogram <-__remove_hrtimer - <idle>-0 [003] dN.1 4228.547805: hrtimer_forward <-tick_nohz_idle_exit - <idle>-0 [003] dN.1 4228.547805: hrtimer_start_range_ns <-hrtimer_start_expires.constprop.11 - <idle>-0 [003] d..1 4228.547858: hrtimer_get_next_event <-get_next_timer_interrupt - <idle>-0 [003] d..1 4228.547859: hrtimer_start <-__tick_nohz_idle_enter - <idle>-0 [003] d..2 4228.547860: hrtimer_force_reprogram <-__rem - -Notice that we lost the sys_nanosleep. - - # cat set_ftrace_filter -hrtimer_run_queues -hrtimer_run_pending -hrtimer_init -hrtimer_cancel -hrtimer_try_to_cancel -hrtimer_forward -hrtimer_start -hrtimer_reprogram -hrtimer_force_reprogram -hrtimer_get_next_event -hrtimer_interrupt -hrtimer_nanosleep -hrtimer_wakeup -hrtimer_get_remaining -hrtimer_get_res -hrtimer_init_sleeper - - -This is because the '>' and '>>' act just like they do in bash. -To rewrite the filters, use '>' -To append to the filters, use '>>' - -To clear out a filter so that all functions will be recorded -again: - - # echo > set_ftrace_filter - # cat set_ftrace_filter - # - -Again, now we want to append. - - # echo sys_nanosleep > set_ftrace_filter - # cat set_ftrace_filter -sys_nanosleep - # echo 'hrtimer_*' >> set_ftrace_filter - # cat set_ftrace_filter -hrtimer_run_queues -hrtimer_run_pending -hrtimer_init -hrtimer_cancel -hrtimer_try_to_cancel -hrtimer_forward -hrtimer_start -hrtimer_reprogram -hrtimer_force_reprogram -hrtimer_get_next_event -hrtimer_interrupt -sys_nanosleep -hrtimer_nanosleep -hrtimer_wakeup -hrtimer_get_remaining -hrtimer_get_res -hrtimer_init_sleeper - - -The set_ftrace_notrace prevents those functions from being -traced. - - # echo '*preempt*' '*lock*' > set_ftrace_notrace - -Produces: - -# tracer: function -# -# entries-in-buffer/entries-written: 39608/39608 #P:4 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - bash-1994 [000] .... 4342.324896: file_ra_state_init <-do_dentry_open - bash-1994 [000] .... 4342.324897: open_check_o_direct <-do_last - bash-1994 [000] .... 4342.324897: ima_file_check <-do_last - bash-1994 [000] .... 4342.324898: process_measurement <-ima_file_check - bash-1994 [000] .... 4342.324898: ima_get_action <-process_measurement - bash-1994 [000] .... 4342.324898: ima_match_policy <-ima_get_action - bash-1994 [000] .... 4342.324899: do_truncate <-do_last - bash-1994 [000] .... 4342.324899: should_remove_suid <-do_truncate - bash-1994 [000] .... 4342.324899: notify_change <-do_truncate - bash-1994 [000] .... 4342.324900: current_fs_time <-notify_change - bash-1994 [000] .... 4342.324900: current_kernel_time <-current_fs_time - bash-1994 [000] .... 4342.324900: timespec_trunc <-current_fs_time - -We can see that there's no more lock or preempt tracing. - - -Dynamic ftrace with the function graph tracer ---------------------------------------------- - -Although what has been explained above concerns both the -function tracer and the function-graph-tracer, there are some -special features only available in the function-graph tracer. - -If you want to trace only one function and all of its children, -you just have to echo its name into set_graph_function: - - echo __do_fault > set_graph_function - -will produce the following "expanded" trace of the __do_fault() -function: - - 0) | __do_fault() { - 0) | filemap_fault() { - 0) | find_lock_page() { - 0) 0.804 us | find_get_page(); - 0) | __might_sleep() { - 0) 1.329 us | } - 0) 3.904 us | } - 0) 4.979 us | } - 0) 0.653 us | _spin_lock(); - 0) 0.578 us | page_add_file_rmap(); - 0) 0.525 us | native_set_pte_at(); - 0) 0.585 us | _spin_unlock(); - 0) | unlock_page() { - 0) 0.541 us | page_waitqueue(); - 0) 0.639 us | __wake_up_bit(); - 0) 2.786 us | } - 0) + 14.237 us | } - 0) | __do_fault() { - 0) | filemap_fault() { - 0) | find_lock_page() { - 0) 0.698 us | find_get_page(); - 0) | __might_sleep() { - 0) 1.412 us | } - 0) 3.950 us | } - 0) 5.098 us | } - 0) 0.631 us | _spin_lock(); - 0) 0.571 us | page_add_file_rmap(); - 0) 0.526 us | native_set_pte_at(); - 0) 0.586 us | _spin_unlock(); - 0) | unlock_page() { - 0) 0.533 us | page_waitqueue(); - 0) 0.638 us | __wake_up_bit(); - 0) 2.793 us | } - 0) + 14.012 us | } - -You can also expand several functions at once: - - echo sys_open > set_graph_function - echo sys_close >> set_graph_function - -Now if you want to go back to trace all functions you can clear -this special filter via: - - echo > set_graph_function - - -ftrace_enabled --------------- - -Note, the proc sysctl ftrace_enable is a big on/off switch for the -function tracer. By default it is enabled (when function tracing is -enabled in the kernel). If it is disabled, all function tracing is -disabled. This includes not only the function tracers for ftrace, but -also for any other uses (perf, kprobes, stack tracing, profiling, etc). - -Please disable this with care. - -This can be disable (and enabled) with: - - sysctl kernel.ftrace_enabled=0 - sysctl kernel.ftrace_enabled=1 - - or - - echo 0 > /proc/sys/kernel/ftrace_enabled - echo 1 > /proc/sys/kernel/ftrace_enabled - - -Filter commands ---------------- - -A few commands are supported by the set_ftrace_filter interface. -Trace commands have the following format: - -<function>:<command>:<parameter> - -The following commands are supported: - -- mod - This command enables function filtering per module. The - parameter defines the module. For example, if only the write* - functions in the ext3 module are desired, run: - - echo 'write*:mod:ext3' > set_ftrace_filter - - This command interacts with the filter in the same way as - filtering based on function names. Thus, adding more functions - in a different module is accomplished by appending (>>) to the - filter file. Remove specific module functions by prepending - '!': - - echo '!writeback*:mod:ext3' >> set_ftrace_filter - - Mod command supports module globbing. Disable tracing for all - functions except a specific module: - - echo '!*:mod:!ext3' >> set_ftrace_filter - - Disable tracing for all modules, but still trace kernel: - - echo '!*:mod:*' >> set_ftrace_filter - - Enable filter only for kernel: - - echo '*write*:mod:!*' >> set_ftrace_filter - - Enable filter for module globbing: - - echo '*write*:mod:*snd*' >> set_ftrace_filter - -- traceon/traceoff - These commands turn tracing on and off when the specified - functions are hit. The parameter determines how many times the - tracing system is turned on and off. If unspecified, there is - no limit. For example, to disable tracing when a schedule bug - is hit the first 5 times, run: - - echo '__schedule_bug:traceoff:5' > set_ftrace_filter - - To always disable tracing when __schedule_bug is hit: - - echo '__schedule_bug:traceoff' > set_ftrace_filter - - These commands are cumulative whether or not they are appended - to set_ftrace_filter. To remove a command, prepend it by '!' - and drop the parameter: - - echo '!__schedule_bug:traceoff:0' > set_ftrace_filter - - The above removes the traceoff command for __schedule_bug - that have a counter. To remove commands without counters: - - echo '!__schedule_bug:traceoff' > set_ftrace_filter - -- snapshot - Will cause a snapshot to be triggered when the function is hit. - - echo 'native_flush_tlb_others:snapshot' > set_ftrace_filter - - To only snapshot once: - - echo 'native_flush_tlb_others:snapshot:1' > set_ftrace_filter - - To remove the above commands: - - echo '!native_flush_tlb_others:snapshot' > set_ftrace_filter - echo '!native_flush_tlb_others:snapshot:0' > set_ftrace_filter - -- enable_event/disable_event - These commands can enable or disable a trace event. Note, because - function tracing callbacks are very sensitive, when these commands - are registered, the trace point is activated, but disabled in - a "soft" mode. That is, the tracepoint will be called, but - just will not be traced. The event tracepoint stays in this mode - as long as there's a command that triggers it. - - echo 'try_to_wake_up:enable_event:sched:sched_switch:2' > \ - set_ftrace_filter - - The format is: - - <function>:enable_event:<system>:<event>[:count] - <function>:disable_event:<system>:<event>[:count] - - To remove the events commands: - - - echo '!try_to_wake_up:enable_event:sched:sched_switch:0' > \ - set_ftrace_filter - echo '!schedule:disable_event:sched:sched_switch' > \ - set_ftrace_filter - -- dump - When the function is hit, it will dump the contents of the ftrace - ring buffer to the console. This is useful if you need to debug - something, and want to dump the trace when a certain function - is hit. Perhaps its a function that is called before a tripple - fault happens and does not allow you to get a regular dump. - -- cpudump - When the function is hit, it will dump the contents of the ftrace - ring buffer for the current CPU to the console. Unlike the "dump" - command, it only prints out the contents of the ring buffer for the - CPU that executed the function that triggered the dump. - -trace_pipe ----------- - -The trace_pipe outputs the same content as the trace file, but -the effect on the tracing is different. Every read from -trace_pipe is consumed. This means that subsequent reads will be -different. The trace is live. - - # echo function > current_tracer - # cat trace_pipe > /tmp/trace.out & -[1] 4153 - # echo 1 > tracing_on - # usleep 1 - # echo 0 > tracing_on - # cat trace -# tracer: function -# -# entries-in-buffer/entries-written: 0/0 #P:4 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - - # - # cat /tmp/trace.out - bash-1994 [000] .... 5281.568961: mutex_unlock <-rb_simple_write - bash-1994 [000] .... 5281.568963: __mutex_unlock_slowpath <-mutex_unlock - bash-1994 [000] .... 5281.568963: __fsnotify_parent <-fsnotify_modify - bash-1994 [000] .... 5281.568964: fsnotify <-fsnotify_modify - bash-1994 [000] .... 5281.568964: __srcu_read_lock <-fsnotify - bash-1994 [000] .... 5281.568964: add_preempt_count <-__srcu_read_lock - bash-1994 [000] ...1 5281.568965: sub_preempt_count <-__srcu_read_lock - bash-1994 [000] .... 5281.568965: __srcu_read_unlock <-fsnotify - bash-1994 [000] .... 5281.568967: sys_dup2 <-system_call_fastpath - - -Note, reading the trace_pipe file will block until more input is -added. - -trace entries -------------- - -Having too much or not enough data can be troublesome in -diagnosing an issue in the kernel. The file buffer_size_kb is -used to modify the size of the internal trace buffers. The -number listed is the number of entries that can be recorded per -CPU. To know the full size, multiply the number of possible CPUs -with the number of entries. - - # cat buffer_size_kb -1408 (units kilobytes) - -Or simply read buffer_total_size_kb - - # cat buffer_total_size_kb -5632 - -To modify the buffer, simple echo in a number (in 1024 byte segments). - - # echo 10000 > buffer_size_kb - # cat buffer_size_kb -10000 (units kilobytes) - -It will try to allocate as much as possible. If you allocate too -much, it can cause Out-Of-Memory to trigger. - - # echo 1000000000000 > buffer_size_kb --bash: echo: write error: Cannot allocate memory - # cat buffer_size_kb -85 - -The per_cpu buffers can be changed individually as well: - - # echo 10000 > per_cpu/cpu0/buffer_size_kb - # echo 100 > per_cpu/cpu1/buffer_size_kb - -When the per_cpu buffers are not the same, the buffer_size_kb -at the top level will just show an X - - # cat buffer_size_kb -X - -This is where the buffer_total_size_kb is useful: - - # cat buffer_total_size_kb -12916 - -Writing to the top level buffer_size_kb will reset all the buffers -to be the same again. - -Snapshot --------- -CONFIG_TRACER_SNAPSHOT makes a generic snapshot feature -available to all non latency tracers. (Latency tracers which -record max latency, such as "irqsoff" or "wakeup", can't use -this feature, since those are already using the snapshot -mechanism internally.) - -Snapshot preserves a current trace buffer at a particular point -in time without stopping tracing. Ftrace swaps the current -buffer with a spare buffer, and tracing continues in the new -current (=previous spare) buffer. - -The following tracefs files in "tracing" are related to this -feature: - - snapshot: - - This is used to take a snapshot and to read the output - of the snapshot. Echo 1 into this file to allocate a - spare buffer and to take a snapshot (swap), then read - the snapshot from this file in the same format as - "trace" (described above in the section "The File - System"). Both reads snapshot and tracing are executable - in parallel. When the spare buffer is allocated, echoing - 0 frees it, and echoing else (positive) values clear the - snapshot contents. - More details are shown in the table below. - - status\input | 0 | 1 | else | - --------------+------------+------------+------------+ - not allocated |(do nothing)| alloc+swap |(do nothing)| - --------------+------------+------------+------------+ - allocated | free | swap | clear | - --------------+------------+------------+------------+ - -Here is an example of using the snapshot feature. - - # echo 1 > events/sched/enable - # echo 1 > snapshot - # cat snapshot -# tracer: nop -# -# entries-in-buffer/entries-written: 71/71 #P:8 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - <idle>-0 [005] d... 2440.603828: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2242 next_prio=120 - sleep-2242 [005] d... 2440.603846: sched_switch: prev_comm=snapshot-test-2 prev_pid=2242 prev_prio=120 prev_state=R ==> next_comm=kworker/5:1 next_pid=60 next_prio=120 -[...] - <idle>-0 [002] d... 2440.707230: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2229 next_prio=120 - - # cat trace -# tracer: nop -# -# entries-in-buffer/entries-written: 77/77 #P:8 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - <idle>-0 [007] d... 2440.707395: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2243 next_prio=120 - snapshot-test-2-2229 [002] d... 2440.707438: sched_switch: prev_comm=snapshot-test-2 prev_pid=2229 prev_prio=120 prev_state=S ==> next_comm=swapper/2 next_pid=0 next_prio=120 -[...] - - -If you try to use this snapshot feature when current tracer is -one of the latency tracers, you will get the following results. - - # echo wakeup > current_tracer - # echo 1 > snapshot -bash: echo: write error: Device or resource busy - # cat snapshot -cat: snapshot: Device or resource busy - - -Instances ---------- -In the tracefs tracing directory is a directory called "instances". -This directory can have new directories created inside of it using -mkdir, and removing directories with rmdir. The directory created -with mkdir in this directory will already contain files and other -directories after it is created. - - # mkdir instances/foo - # ls instances/foo -buffer_size_kb buffer_total_size_kb events free_buffer per_cpu -set_event snapshot trace trace_clock trace_marker trace_options -trace_pipe tracing_on - -As you can see, the new directory looks similar to the tracing directory -itself. In fact, it is very similar, except that the buffer and -events are agnostic from the main director, or from any other -instances that are created. - -The files in the new directory work just like the files with the -same name in the tracing directory except the buffer that is used -is a separate and new buffer. The files affect that buffer but do not -affect the main buffer with the exception of trace_options. Currently, -the trace_options affect all instances and the top level buffer -the same, but this may change in future releases. That is, options -may become specific to the instance they reside in. - -Notice that none of the function tracer files are there, nor is -current_tracer and available_tracers. This is because the buffers -can currently only have events enabled for them. - - # mkdir instances/foo - # mkdir instances/bar - # mkdir instances/zoot - # echo 100000 > buffer_size_kb - # echo 1000 > instances/foo/buffer_size_kb - # echo 5000 > instances/bar/per_cpu/cpu1/buffer_size_kb - # echo function > current_trace - # echo 1 > instances/foo/events/sched/sched_wakeup/enable - # echo 1 > instances/foo/events/sched/sched_wakeup_new/enable - # echo 1 > instances/foo/events/sched/sched_switch/enable - # echo 1 > instances/bar/events/irq/enable - # echo 1 > instances/zoot/events/syscalls/enable - # cat trace_pipe -CPU:2 [LOST 11745 EVENTS] - bash-2044 [002] .... 10594.481032: _raw_spin_lock_irqsave <-get_page_from_freelist - bash-2044 [002] d... 10594.481032: add_preempt_count <-_raw_spin_lock_irqsave - bash-2044 [002] d..1 10594.481032: __rmqueue <-get_page_from_freelist - bash-2044 [002] d..1 10594.481033: _raw_spin_unlock <-get_page_from_freelist - bash-2044 [002] d..1 10594.481033: sub_preempt_count <-_raw_spin_unlock - bash-2044 [002] d... 10594.481033: get_pageblock_flags_group <-get_pageblock_migratetype - bash-2044 [002] d... 10594.481034: __mod_zone_page_state <-get_page_from_freelist - bash-2044 [002] d... 10594.481034: zone_statistics <-get_page_from_freelist - bash-2044 [002] d... 10594.481034: __inc_zone_state <-zone_statistics - bash-2044 [002] d... 10594.481034: __inc_zone_state <-zone_statistics - bash-2044 [002] .... 10594.481035: arch_dup_task_struct <-copy_process -[...] - - # cat instances/foo/trace_pipe - bash-1998 [000] d..4 136.676759: sched_wakeup: comm=kworker/0:1 pid=59 prio=120 success=1 target_cpu=000 - bash-1998 [000] dN.4 136.676760: sched_wakeup: comm=bash pid=1998 prio=120 success=1 target_cpu=000 - <idle>-0 [003] d.h3 136.676906: sched_wakeup: comm=rcu_preempt pid=9 prio=120 success=1 target_cpu=003 - <idle>-0 [003] d..3 136.676909: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=9 next_prio=120 - rcu_preempt-9 [003] d..3 136.676916: sched_switch: prev_comm=rcu_preempt prev_pid=9 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120 - bash-1998 [000] d..4 136.677014: sched_wakeup: comm=kworker/0:1 pid=59 prio=120 success=1 target_cpu=000 - bash-1998 [000] dN.4 136.677016: sched_wakeup: comm=bash pid=1998 prio=120 success=1 target_cpu=000 - bash-1998 [000] d..3 136.677018: sched_switch: prev_comm=bash prev_pid=1998 prev_prio=120 prev_state=R+ ==> next_comm=kworker/0:1 next_pid=59 next_prio=120 - kworker/0:1-59 [000] d..4 136.677022: sched_wakeup: comm=sshd pid=1995 prio=120 success=1 target_cpu=001 - kworker/0:1-59 [000] d..3 136.677025: sched_switch: prev_comm=kworker/0:1 prev_pid=59 prev_prio=120 prev_state=S ==> next_comm=bash next_pid=1998 next_prio=120 -[...] - - # cat instances/bar/trace_pipe - migration/1-14 [001] d.h3 138.732674: softirq_raise: vec=3 [action=NET_RX] - <idle>-0 [001] dNh3 138.732725: softirq_raise: vec=3 [action=NET_RX] - bash-1998 [000] d.h1 138.733101: softirq_raise: vec=1 [action=TIMER] - bash-1998 [000] d.h1 138.733102: softirq_raise: vec=9 [action=RCU] - bash-1998 [000] ..s2 138.733105: softirq_entry: vec=1 [action=TIMER] - bash-1998 [000] ..s2 138.733106: softirq_exit: vec=1 [action=TIMER] - bash-1998 [000] ..s2 138.733106: softirq_entry: vec=9 [action=RCU] - bash-1998 [000] ..s2 138.733109: softirq_exit: vec=9 [action=RCU] - sshd-1995 [001] d.h1 138.733278: irq_handler_entry: irq=21 name=uhci_hcd:usb4 - sshd-1995 [001] d.h1 138.733280: irq_handler_exit: irq=21 ret=unhandled - sshd-1995 [001] d.h1 138.733281: irq_handler_entry: irq=21 name=eth0 - sshd-1995 [001] d.h1 138.733283: irq_handler_exit: irq=21 ret=handled -[...] - - # cat instances/zoot/trace -# tracer: nop -# -# entries-in-buffer/entries-written: 18996/18996 #P:4 -# -# _-----=> irqs-off -# / _----=> need-resched -# | / _---=> hardirq/softirq -# || / _--=> preempt-depth -# ||| / delay -# TASK-PID CPU# |||| TIMESTAMP FUNCTION -# | | | |||| | | - bash-1998 [000] d... 140.733501: sys_write -> 0x2 - bash-1998 [000] d... 140.733504: sys_dup2(oldfd: a, newfd: 1) - bash-1998 [000] d... 140.733506: sys_dup2 -> 0x1 - bash-1998 [000] d... 140.733508: sys_fcntl(fd: a, cmd: 1, arg: 0) - bash-1998 [000] d... 140.733509: sys_fcntl -> 0x1 - bash-1998 [000] d... 140.733510: sys_close(fd: a) - bash-1998 [000] d... 140.733510: sys_close -> 0x0 - bash-1998 [000] d... 140.733514: sys_rt_sigprocmask(how: 0, nset: 0, oset: 6e2768, sigsetsize: 8) - bash-1998 [000] d... 140.733515: sys_rt_sigprocmask -> 0x0 - bash-1998 [000] d... 140.733516: sys_rt_sigaction(sig: 2, act: 7fff718846f0, oact: 7fff71884650, sigsetsize: 8) - bash-1998 [000] d... 140.733516: sys_rt_sigaction -> 0x0 - -You can see that the trace of the top most trace buffer shows only -the function tracing. The foo instance displays wakeups and task -switches. - -To remove the instances, simply delete their directories: - - # rmdir instances/foo - # rmdir instances/bar - # rmdir instances/zoot - -Note, if a process has a trace file open in one of the instance -directories, the rmdir will fail with EBUSY. - - -Stack trace ------------ -Since the kernel has a fixed sized stack, it is important not to -waste it in functions. A kernel developer must be conscience of -what they allocate on the stack. If they add too much, the system -can be in danger of a stack overflow, and corruption will occur, -usually leading to a system panic. - -There are some tools that check this, usually with interrupts -periodically checking usage. But if you can perform a check -at every function call that will become very useful. As ftrace provides -a function tracer, it makes it convenient to check the stack size -at every function call. This is enabled via the stack tracer. - -CONFIG_STACK_TRACER enables the ftrace stack tracing functionality. -To enable it, write a '1' into /proc/sys/kernel/stack_tracer_enabled. - - # echo 1 > /proc/sys/kernel/stack_tracer_enabled - -You can also enable it from the kernel command line to trace -the stack size of the kernel during boot up, by adding "stacktrace" -to the kernel command line parameter. - -After running it for a few minutes, the output looks like: - - # cat stack_max_size -2928 - - # cat stack_trace - Depth Size Location (18 entries) - ----- ---- -------- - 0) 2928 224 update_sd_lb_stats+0xbc/0x4ac - 1) 2704 160 find_busiest_group+0x31/0x1f1 - 2) 2544 256 load_balance+0xd9/0x662 - 3) 2288 80 idle_balance+0xbb/0x130 - 4) 2208 128 __schedule+0x26e/0x5b9 - 5) 2080 16 schedule+0x64/0x66 - 6) 2064 128 schedule_timeout+0x34/0xe0 - 7) 1936 112 wait_for_common+0x97/0xf1 - 8) 1824 16 wait_for_completion+0x1d/0x1f - 9) 1808 128 flush_work+0xfe/0x119 - 10) 1680 16 tty_flush_to_ldisc+0x1e/0x20 - 11) 1664 48 input_available_p+0x1d/0x5c - 12) 1616 48 n_tty_poll+0x6d/0x134 - 13) 1568 64 tty_poll+0x64/0x7f - 14) 1504 880 do_select+0x31e/0x511 - 15) 624 400 core_sys_select+0x177/0x216 - 16) 224 96 sys_select+0x91/0xb9 - 17) 128 128 system_call_fastpath+0x16/0x1b - -Note, if -mfentry is being used by gcc, functions get traced before -they set up the stack frame. This means that leaf level functions -are not tested by the stack tracer when -mfentry is used. - -Currently, -mfentry is used by gcc 4.6.0 and above on x86 only. - ---------- - -More details can be found in the source code, in the -kernel/trace/*.c files. diff --git a/Documentation/trace/hwlat_detector.txt b/Documentation/trace/hwlat_detector.rst index 3207717..5739349 100644 --- a/Documentation/trace/hwlat_detector.txt +++ b/Documentation/trace/hwlat_detector.rst @@ -1,4 +1,8 @@ -Introduction: +========================= +Hardware Latency Detector +========================= + +Introduction ------------- The tracer hwlat_detector is a special purpose tracer that is used to @@ -28,7 +32,7 @@ Note that the hwlat detector should *NEVER* be used in a production environment. It is intended to be run manually to determine if the hardware platform has a problem with long system firmware service routines. -Usage: +Usage ------ Write the ASCII text "hwlat" into the current_tracer file of the tracing system @@ -36,16 +40,16 @@ Write the ASCII text "hwlat" into the current_tracer file of the tracing system redefine the threshold in microseconds (us) above which latency spikes will be taken into account. -Example: +Example:: # echo hwlat > /sys/kernel/tracing/current_tracer # echo 100 > /sys/kernel/tracing/tracing_thresh The /sys/kernel/tracing/hwlat_detector interface contains the following files: -width - time period to sample with CPUs held (usecs) - must be less than the total window size (enforced) -window - total period of sampling, width being inside (usecs) + - width - time period to sample with CPUs held (usecs) + must be less than the total window size (enforced) + - window - total period of sampling, width being inside (usecs) By default the width is set to 500,000 and window to 1,000,000, meaning that for every 1,000,000 usecs (1s) the hwlat detector will spin for 500,000 usecs @@ -67,11 +71,11 @@ The following tracing directory files are used by the hwlat_detector: in /sys/kernel/tracing: - tracing_threshold - minimum latency value to be considered (usecs) - tracing_max_latency - maximum hardware latency actually observed (usecs) - tracing_cpumask - the CPUs to move the hwlat thread across - hwlat_detector/width - specified amount of time to spin within window (usecs) - hwlat_detector/window - amount of time between (width) runs (usecs) + - tracing_threshold - minimum latency value to be considered (usecs) + - tracing_max_latency - maximum hardware latency actually observed (usecs) + - tracing_cpumask - the CPUs to move the hwlat thread across + - hwlat_detector/width - specified amount of time to spin within window (usecs) + - hwlat_detector/window - amount of time between (width) runs (usecs) The hwlat detector's kernel thread will migrate across each CPU specified in tracing_cpumask between each window. To limit the migration, either modify diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst new file mode 100644 index 0000000..b58c10b --- /dev/null +++ b/Documentation/trace/index.rst @@ -0,0 +1,23 @@ +========================== +Linux Tracing Technologies +========================== + +.. toctree:: + :maxdepth: 2 + + ftrace-design + tracepoint-analysis + ftrace + ftrace-uses + kprobetrace + uprobetracer + tracepoints + events + events-kmem + events-power + events-nmi + events-msr + mmiotrace + hwlat_detector + intel_th + stm diff --git a/Documentation/trace/intel_th.txt b/Documentation/trace/intel_th.rst index 7a57165..990f132 100644 --- a/Documentation/trace/intel_th.txt +++ b/Documentation/trace/intel_th.rst @@ -1,3 +1,4 @@ +======================= Intel(R) Trace Hub (TH) ======================= @@ -18,13 +19,13 @@ via sysfs attributes. Currently, the following Intel TH subdevices (blocks) are supported: - Software Trace Hub (STH), trace source, which is a System Trace - Module (STM) device, + Module (STM) device, - Memory Storage Unit (MSU), trace output, which allows storing - trace hub output in system memory, + trace hub output in system memory, - Parallel Trace Interface output (PTI), trace output to an external - debug host via a PTI port, + debug host via a PTI port, - Global Trace Hub (GTH), which is a switch and a central component - of Intel(R) Trace Hub architecture. + of Intel(R) Trace Hub architecture. Common attributes for output devices are described in Documentation/ABI/testing/sysfs-bus-intel_th-output-devices, the most @@ -65,41 +66,41 @@ allocated, are accessible via /dev/intel_th0/msc{0,1}. Quick example ------------- -# figure out which GTH port is the first memory controller: +# figure out which GTH port is the first memory controller:: -$ cat /sys/bus/intel_th/devices/0-msc0/port -0 + $ cat /sys/bus/intel_th/devices/0-msc0/port + 0 -# looks like it's port 0, configure master 33 to send data to port 0: +# looks like it's port 0, configure master 33 to send data to port 0:: -$ echo 0 > /sys/bus/intel_th/devices/0-gth/masters/33 + $ echo 0 > /sys/bus/intel_th/devices/0-gth/masters/33 # allocate a 2-windowed multiblock buffer on the first memory -# controller, each with 64 pages: +# controller, each with 64 pages:: -$ echo multi > /sys/bus/intel_th/devices/0-msc0/mode -$ echo 64,64 > /sys/bus/intel_th/devices/0-msc0/nr_pages + $ echo multi > /sys/bus/intel_th/devices/0-msc0/mode + $ echo 64,64 > /sys/bus/intel_th/devices/0-msc0/nr_pages -# enable wrapping for this controller, too: +# enable wrapping for this controller, too:: -$ echo 1 > /sys/bus/intel_th/devices/0-msc0/wrap + $ echo 1 > /sys/bus/intel_th/devices/0-msc0/wrap -# and enable tracing into this port: +# and enable tracing into this port:: -$ echo 1 > /sys/bus/intel_th/devices/0-msc0/active + $ echo 1 > /sys/bus/intel_th/devices/0-msc0/active # .. send data to master 33, see stm.txt for more details .. # .. wait for traces to pile up .. -# .. and stop the trace: +# .. and stop the trace:: -$ echo 0 > /sys/bus/intel_th/devices/0-msc0/active + $ echo 0 > /sys/bus/intel_th/devices/0-msc0/active -# and now you can collect the trace from the device node: +# and now you can collect the trace from the device node:: -$ cat /dev/intel_th0/msc0 > my_stp_trace + $ cat /dev/intel_th0/msc0 > my_stp_trace Host Debugger Mode -================== +------------------ It is possible to configure the Trace Hub and control its trace capture from a remote debug host, which should be connected via one of diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.rst index 1a3a3d6..3e0f971 100644 --- a/Documentation/trace/kprobetrace.txt +++ b/Documentation/trace/kprobetrace.rst @@ -1,8 +1,8 @@ - Kprobe-based Event Tracing - ========================== - - Documentation is written by Masami Hiramatsu +========================== +Kprobe-based Event Tracing +========================== +:Author: Masami Hiramatsu Overview -------- @@ -23,6 +23,8 @@ current_tracer. Instead of that, add probe points via Synopsis of kprobe_events ------------------------- +:: + p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe -:[GRP/]EVENT : Clear a probe @@ -66,7 +68,7 @@ String type is a special type, which fetches a "null-terminated" string from kernel space. This means it will fail and store NULL if the string container has been paged out. Bitfield is another special type, which takes 3 parameters, bit-width, bit- -offset, and container-size (usually 32). The syntax is; +offset, and container-size (usually 32). The syntax is:: b<bit-width>@<bit-offset>/<container-size> @@ -75,7 +77,7 @@ For $comm, the default type is "string"; any other type is invalid. Per-Probe Event Filtering ------------------------- - Per-probe event filtering feature allows you to set different filter on each +Per-probe event filtering feature allows you to set different filter on each probe and gives you what arguments will be shown in trace buffer. If an event name is specified right after 'p:' or 'r:' in kprobe_events, it adds an event under tracing/events/kprobes/<EVENT>, at the directory you can see 'id', @@ -96,87 +98,93 @@ id: Event Profiling --------------- - You can check the total number of probe hits and probe miss-hits via +You can check the total number of probe hits and probe miss-hits via /sys/kernel/debug/tracing/kprobe_profile. - The first column is event name, the second is the number of probe hits, +The first column is event name, the second is the number of probe hits, the third is the number of probe miss-hits. Usage examples -------------- To add a probe as a new event, write a new definition to kprobe_events -as below. +as below:: echo 'p:myprobe do_sys_open dfd=%ax filename=%dx flags=%cx mode=+4($stack)' > /sys/kernel/debug/tracing/kprobe_events - This sets a kprobe on the top of do_sys_open() function with recording +This sets a kprobe on the top of do_sys_open() function with recording 1st to 4th arguments as "myprobe" event. Note, which register/stack entry is assigned to each function argument depends on arch-specific ABI. If you unsure the ABI, please try to use probe subcommand of perf-tools (you can find it under tools/perf/). As this example shows, users can choose more familiar names for each arguments. +:: echo 'r:myretprobe do_sys_open $retval' >> /sys/kernel/debug/tracing/kprobe_events - This sets a kretprobe on the return point of do_sys_open() function with +This sets a kretprobe on the return point of do_sys_open() function with recording return value as "myretprobe" event. - You can see the format of these events via +You can see the format of these events via /sys/kernel/debug/tracing/events/kprobes/<EVENT>/format. +:: cat /sys/kernel/debug/tracing/events/kprobes/myprobe/format -name: myprobe -ID: 780 -format: - field:unsigned short common_type; offset:0; size:2; signed:0; - field:unsigned char common_flags; offset:2; size:1; signed:0; - field:unsigned char common_preempt_count; offset:3; size:1;signed:0; - field:int common_pid; offset:4; size:4; signed:1; + name: myprobe + ID: 780 + format: + field:unsigned short common_type; offset:0; size:2; signed:0; + field:unsigned char common_flags; offset:2; size:1; signed:0; + field:unsigned char common_preempt_count; offset:3; size:1;signed:0; + field:int common_pid; offset:4; size:4; signed:1; - field:unsigned long __probe_ip; offset:12; size:4; signed:0; - field:int __probe_nargs; offset:16; size:4; signed:1; - field:unsigned long dfd; offset:20; size:4; signed:0; - field:unsigned long filename; offset:24; size:4; signed:0; - field:unsigned long flags; offset:28; size:4; signed:0; - field:unsigned long mode; offset:32; size:4; signed:0; + field:unsigned long __probe_ip; offset:12; size:4; signed:0; + field:int __probe_nargs; offset:16; size:4; signed:1; + field:unsigned long dfd; offset:20; size:4; signed:0; + field:unsigned long filename; offset:24; size:4; signed:0; + field:unsigned long flags; offset:28; size:4; signed:0; + field:unsigned long mode; offset:32; size:4; signed:0; -print fmt: "(%lx) dfd=%lx filename=%lx flags=%lx mode=%lx", REC->__probe_ip, -REC->dfd, REC->filename, REC->flags, REC->mode + print fmt: "(%lx) dfd=%lx filename=%lx flags=%lx mode=%lx", REC->__probe_ip, + REC->dfd, REC->filename, REC->flags, REC->mode - You can see that the event has 4 arguments as in the expressions you specified. +You can see that the event has 4 arguments as in the expressions you specified. +:: echo > /sys/kernel/debug/tracing/kprobe_events - This clears all probe points. +This clears all probe points. - Or, +Or, +:: echo -:myprobe >> kprobe_events - This clears probe points selectively. +This clears probe points selectively. - Right after definition, each event is disabled by default. For tracing these +Right after definition, each event is disabled by default. For tracing these events, you need to enable it. +:: echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable echo 1 > /sys/kernel/debug/tracing/events/kprobes/myretprobe/enable - And you can see the traced information via /sys/kernel/debug/tracing/trace. +And you can see the traced information via /sys/kernel/debug/tracing/trace. +:: cat /sys/kernel/debug/tracing/trace -# tracer: nop -# -# TASK-PID CPU# TIMESTAMP FUNCTION -# | | | | | - <...>-1447 [001] 1038282.286875: myprobe: (do_sys_open+0x0/0xd6) dfd=3 filename=7fffd1ec4440 flags=8000 mode=0 - <...>-1447 [001] 1038282.286878: myretprobe: (sys_openat+0xc/0xe <- do_sys_open) $retval=fffffffffffffffe - <...>-1447 [001] 1038282.286885: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=40413c flags=8000 mode=1b6 - <...>-1447 [001] 1038282.286915: myretprobe: (sys_open+0x1b/0x1d <- do_sys_open) $retval=3 - <...>-1447 [001] 1038282.286969: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=4041c6 flags=98800 mode=10 - <...>-1447 [001] 1038282.286976: myretprobe: (sys_open+0x1b/0x1d <- do_sys_open) $retval=3 - - - Each line shows when the kernel hits an event, and <- SYMBOL means kernel + # tracer: nop + # + # TASK-PID CPU# TIMESTAMP FUNCTION + # | | | | | + <...>-1447 [001] 1038282.286875: myprobe: (do_sys_open+0x0/0xd6) dfd=3 filename=7fffd1ec4440 flags=8000 mode=0 + <...>-1447 [001] 1038282.286878: myretprobe: (sys_openat+0xc/0xe <- do_sys_open) $retval=fffffffffffffffe + <...>-1447 [001] 1038282.286885: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=40413c flags=8000 mode=1b6 + <...>-1447 [001] 1038282.286915: myretprobe: (sys_open+0x1b/0x1d <- do_sys_open) $retval=3 + <...>-1447 [001] 1038282.286969: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=4041c6 flags=98800 mode=10 + <...>-1447 [001] 1038282.286976: myretprobe: (sys_open+0x1b/0x1d <- do_sys_open) $retval=3 + + +Each line shows when the kernel hits an event, and <- SYMBOL means kernel returns from SYMBOL(e.g. "sys_open+0x1b/0x1d <- do_sys_open" means kernel returns from do_sys_open to sys_open+0x1b). diff --git a/Documentation/trace/mmiotrace.txt b/Documentation/trace/mmiotrace.rst index 664e738..5116e8c 100644 --- a/Documentation/trace/mmiotrace.txt +++ b/Documentation/trace/mmiotrace.rst @@ -1,4 +1,6 @@ - In-kernel memory-mapped I/O tracing +=================================== +In-kernel memory-mapped I/O tracing +=================================== Home page and links to optional user space tools: @@ -31,30 +33,35 @@ is no way to automatically detect if you are losing events due to CPUs racing. Usage Quick Reference --------------------- +:: -$ mount -t debugfs debugfs /sys/kernel/debug -$ echo mmiotrace > /sys/kernel/debug/tracing/current_tracer -$ cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt & -Start X or whatever. -$ echo "X is up" > /sys/kernel/debug/tracing/trace_marker -$ echo nop > /sys/kernel/debug/tracing/current_tracer -Check for lost events. + $ mount -t debugfs debugfs /sys/kernel/debug + $ echo mmiotrace > /sys/kernel/debug/tracing/current_tracer + $ cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt & + Start X or whatever. + $ echo "X is up" > /sys/kernel/debug/tracing/trace_marker + $ echo nop > /sys/kernel/debug/tracing/current_tracer + Check for lost events. Usage ----- Make sure debugfs is mounted to /sys/kernel/debug. -If not (requires root privileges): -$ mount -t debugfs debugfs /sys/kernel/debug +If not (requires root privileges):: + + $ mount -t debugfs debugfs /sys/kernel/debug Check that the driver you are about to trace is not loaded. -Activate mmiotrace (requires root privileges): -$ echo mmiotrace > /sys/kernel/debug/tracing/current_tracer +Activate mmiotrace (requires root privileges):: + + $ echo mmiotrace > /sys/kernel/debug/tracing/current_tracer + +Start storing the trace:: + + $ cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt & -Start storing the trace: -$ cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt & The 'cat' process should stay running (sleeping) in the background. Load the driver you want to trace and use it. Mmiotrace will only catch MMIO @@ -66,30 +73,42 @@ This makes it easier to see which part of the (huge) trace corresponds to which action. It is recommended to place descriptive markers about what you do. -Shut down mmiotrace (requires root privileges): -$ echo nop > /sys/kernel/debug/tracing/current_tracer +Shut down mmiotrace (requires root privileges):: + + $ echo nop > /sys/kernel/debug/tracing/current_tracer + The 'cat' process exits. If it does not, kill it by issuing 'fg' command and pressing ctrl+c. -Check that mmiotrace did not lose events due to a buffer filling up. Either -$ grep -i lost mydump.txt -which tells you exactly how many events were lost, or use -$ dmesg +Check that mmiotrace did not lose events due to a buffer filling up. Either:: + + $ grep -i lost mydump.txt + +which tells you exactly how many events were lost, or use:: + + $ dmesg + to view your kernel log and look for "mmiotrace has lost events" warning. If events were lost, the trace is incomplete. You should enlarge the buffers and try again. Buffers are enlarged by first seeing how large the current buffers -are: -$ cat /sys/kernel/debug/tracing/buffer_size_kb +are:: + + $ cat /sys/kernel/debug/tracing/buffer_size_kb + gives you a number. Approximately double this number and write it back, for -instance: -$ echo 128000 > /sys/kernel/debug/tracing/buffer_size_kb +instance:: + + $ echo 128000 > /sys/kernel/debug/tracing/buffer_size_kb + Then start again from the top. If you are doing a trace for a driver project, e.g. Nouveau, you should also -do the following before sending your results: -$ lspci -vvv > lspci.txt -$ dmesg > dmesg.txt -$ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt +do the following before sending your results:: + + $ lspci -vvv > lspci.txt + $ dmesg > dmesg.txt + $ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt + and then send the .tar.gz file. The trace compresses considerably. Replace "pciid" and "nick" with the PCI ID or model name of your piece of hardware under investigation and your nickname. @@ -148,17 +167,18 @@ zero if it is not recorded. PID is always zero as tracing MMIO accesses originating in user space memory is not yet supported. For instance, the following awk filter will pass all 32-bit writes that target -physical addresses in the range [0xfb73ce40, 0xfb800000[ +physical addresses in the range [0xfb73ce40, 0xfb800000] +:: -$ awk '/W 4 / { adr=strtonum($5); if (adr >= 0xfb73ce40 && -adr < 0xfb800000) print; }' + $ awk '/W 4 / { adr=strtonum($5); if (adr >= 0xfb73ce40 && + adr < 0xfb800000) print; }' Tools for Developers -------------------- The user space tools include utilities for: -- replacing numeric addresses and values with hardware register names -- replaying MMIO logs, i.e., re-executing the recorded writes + - replacing numeric addresses and values with hardware register names + - replaying MMIO logs, i.e., re-executing the recorded writes diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.rst index 0376575..2c22ddb 100644 --- a/Documentation/trace/stm.txt +++ b/Documentation/trace/stm.rst @@ -1,3 +1,4 @@ +=================== System Trace Module =================== @@ -32,14 +33,14 @@ associated with it, located in "stp-policy" subsystem directory in configfs. The topmost directory's name (the policy) is formatted as the STM device name to which this policy applies and and arbitrary string identifier separated by a stop. From the examle above, a rule -may look like this: +may look like this:: -$ ls /config/stp-policy/dummy_stm.my-policy/user -channels masters -$ cat /config/stp-policy/dummy_stm.my-policy/user/masters -48 63 -$ cat /config/stp-policy/dummy_stm.my-policy/user/channels -0 127 + $ ls /config/stp-policy/dummy_stm.my-policy/user + channels masters + $ cat /config/stp-policy/dummy_stm.my-policy/user/masters + 48 63 + $ cat /config/stp-policy/dummy_stm.my-policy/user/channels + 0 127 which means that the master allocation pool for this rule consists of masters 48 through 63 and channel allocation pool has channels 0 @@ -78,9 +79,9 @@ stm_source For kernel-based trace sources, there is "stm_source" device class. Devices of this class can be connected and disconnected to/from stm devices at runtime via a sysfs attribute called "stm_source_link" -by writing the name of the desired stm device there, for example: +by writing the name of the desired stm device there, for example:: -$ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link + $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link For examples on how to use stm_source interface in the kernel, refer to stm_console, stm_heartbeat or stm_ftrace drivers. @@ -118,5 +119,5 @@ the same time. Currently only Ftrace "function" tracer is supported. -[1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf -[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html +* [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf +* [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html diff --git a/Documentation/trace/tracepoint-analysis.txt b/Documentation/trace/tracepoint-analysis.rst index 058cc6c..a4d3ff2 100644 --- a/Documentation/trace/tracepoint-analysis.txt +++ b/Documentation/trace/tracepoint-analysis.rst @@ -1,7 +1,7 @@ - Notes on Analysing Behaviour Using Events and Tracepoints - - Documentation written by Mel Gorman - PCL information heavily based on email from Ingo Molnar +========================================================= +Notes on Analysing Behaviour Using Events and Tracepoints +========================================================= +:Author: Mel Gorman (PCL information heavily based on email from Ingo Molnar) 1. Introduction =============== @@ -27,18 +27,18 @@ assumed that the PCL tool tools/perf has been installed and is in your path. ---------------------- All possible events are visible from /sys/kernel/debug/tracing/events. Simply -calling +calling:: $ find /sys/kernel/debug/tracing/events -type d will give a fair indication of the number of events available. 2.2 PCL (Performance Counters for Linux) -------- +---------------------------------------- Discovery and enumeration of all counters and events, including tracepoints, are available with the perf tool. Getting a list of available events is a -simple case of: +simple case of:: $ perf list 2>&1 | grep Tracepoint ext4:ext4_free_inode [Tracepoint event] @@ -57,7 +57,7 @@ simple case of: See Documentation/trace/events.txt for a proper description on how events can be enabled system-wide. A short example of enabling all events related -to page allocation would look something like: +to page allocation would look something like:: $ for i in `find /sys/kernel/debug/tracing/events -name "enable" | grep mm_`; do echo 1 > $i; done @@ -67,6 +67,7 @@ to page allocation would look something like: In SystemTap, tracepoints are accessible using the kernel.trace() function call. The following is an example that reports every 5 seconds what processes were allocating the pages. +:: global page_allocs @@ -91,6 +92,7 @@ were allocating the pages. By specifying the -a switch and analysing sleep, the system-wide events for a duration of time can be examined. +:: $ perf stat -a \ -e kmem:mm_page_alloc -e kmem:mm_page_free \ @@ -118,6 +120,7 @@ basis using set_ftrace_pid. Events can be activated and tracked for the duration of a process on a local basis using PCL such as follows. +:: $ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free \ -e kmem:mm_page_free_batched ./hackbench 10 @@ -145,6 +148,7 @@ Any workload can exhibit variances between runs and it can be important to know what the standard deviation is. By and large, this is left to the performance analyst to do it by hand. In the event that the discrete event occurrences are useful to the performance analyst, then perf can be used. +:: $ perf stat --repeat 5 -e kmem:mm_page_alloc -e kmem:mm_page_free -e kmem:mm_page_free_batched ./hackbench 10 @@ -167,6 +171,7 @@ aggregation of discrete events, then a script would need to be developed. Using --repeat, it is also possible to view how events are fluctuating over time on a system-wide basis using -a and sleep. +:: $ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free \ -e kmem:mm_page_free_batched \ @@ -188,9 +193,9 @@ When events are enabled the events that are triggering can be read from options exist as well. By post-processing the output, further information can be gathered on-line as appropriate. Examples of post-processing might include - o Reading information from /proc for the PID that triggered the event - o Deriving a higher-level event from a series of lower-level events. - o Calculating latencies between two events + - Reading information from /proc for the PID that triggered the event + - Deriving a higher-level event from a series of lower-level events. + - Calculating latencies between two events Documentation/trace/postprocess/trace-pagealloc-postprocess.pl is an example script that can read trace_pipe from STDIN or a copy of a trace. When used @@ -200,14 +205,14 @@ and twice to exit. Simplistically, the script just reads STDIN and counts up events but it also can do more such as - o Derive high-level events from many low-level events. If a number of pages + - Derive high-level events from many low-level events. If a number of pages are freed to the main allocator from the per-CPU lists, it recognises that as one per-CPU drain even though there is no specific tracepoint for that event - o It can aggregate based on PID or individual process number - o In the event memory is getting externally fragmented, it reports + - It can aggregate based on PID or individual process number + - In the event memory is getting externally fragmented, it reports on whether the fragmentation event was severe or moderate. - o When receiving an event about a PID, it can record who the parent was so + - When receiving an event about a PID, it can record who the parent was so that if large numbers of events are coming from very short-lived processes, the parent process responsible for creating all the helpers can be identified @@ -218,6 +223,7 @@ also can do more such as There may also be a requirement to identify what functions within a program were generating events within the kernel. To begin this sort of analysis, the data must be recorded. At the time of writing, this required root: +:: $ perf record -c 1 \ -e kmem:mm_page_alloc -e kmem:mm_page_free \ @@ -232,6 +238,7 @@ very coarse as a result. This record outputted a file called perf.data which can be analysed using perf report. +:: $ perf report # Samples: 30922 @@ -258,6 +265,7 @@ within the VDSO. With simple binaries, this will often be the case so let's take a slightly different example. In the course of writing this, it was noticed that X was generating an insane amount of page allocations so let's look at it: +:: $ perf record -c 1 -f \ -e kmem:mm_page_alloc -e kmem:mm_page_free \ @@ -265,6 +273,7 @@ at it: -p `pidof X` This was interrupted after a few seconds and +:: $ perf report # Samples: 27666 @@ -282,6 +291,7 @@ This was interrupted after a few seconds and So, almost half of the events are occurring in a library. To get an idea which symbol: +:: $ perf report --sort comm,dso,symbol # Samples: 27666 @@ -298,6 +308,7 @@ symbol: 0.00% Xorg [kernel] [k] ftrace_trace_userstack To see where within the function pixmanFillsse2 things are going wrong: +:: $ perf annotate pixmanFillsse2 [ ... ] diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.rst index a3efac6..6e3ce3b 100644 --- a/Documentation/trace/tracepoints.txt +++ b/Documentation/trace/tracepoints.rst @@ -1,6 +1,8 @@ - Using the Linux Kernel Tracepoints +================================== +Using the Linux Kernel Tracepoints +================================== - Mathieu Desnoyers +:Author: Mathieu Desnoyers This document introduces Linux Kernel Tracepoints and their use. It @@ -9,8 +11,8 @@ connect probe functions to them and provides some examples of probe functions. -* Purpose of tracepoints - +Purpose of tracepoints +---------------------- A tracepoint placed in code provides a hook to call a function (probe) that you can provide at runtime. A tracepoint can be "on" (a probe is connected to it) or "off" (no probe is attached). When a tracepoint is @@ -31,8 +33,8 @@ header file. They can be used for tracing and performance accounting. -* Usage - +Usage +----- Two elements are required for tracepoints : - A tracepoint definition, placed in a header file. @@ -40,52 +42,53 @@ Two elements are required for tracepoints : In order to use tracepoints, you should include linux/tracepoint.h. -In include/trace/events/subsys.h : +In include/trace/events/subsys.h:: -#undef TRACE_SYSTEM -#define TRACE_SYSTEM subsys + #undef TRACE_SYSTEM + #define TRACE_SYSTEM subsys -#if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ) -#define _TRACE_SUBSYS_H + #if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ) + #define _TRACE_SUBSYS_H -#include <linux/tracepoint.h> + #include <linux/tracepoint.h> -DECLARE_TRACE(subsys_eventname, - TP_PROTO(int firstarg, struct task_struct *p), - TP_ARGS(firstarg, p)); + DECLARE_TRACE(subsys_eventname, + TP_PROTO(int firstarg, struct task_struct *p), + TP_ARGS(firstarg, p)); -#endif /* _TRACE_SUBSYS_H */ + #endif /* _TRACE_SUBSYS_H */ -/* This part must be outside protection */ -#include <trace/define_trace.h> + /* This part must be outside protection */ + #include <trace/define_trace.h> -In subsys/file.c (where the tracing statement must be added) : +In subsys/file.c (where the tracing statement must be added):: -#include <trace/events/subsys.h> + #include <trace/events/subsys.h> -#define CREATE_TRACE_POINTS -DEFINE_TRACE(subsys_eventname); + #define CREATE_TRACE_POINTS + DEFINE_TRACE(subsys_eventname); -void somefct(void) -{ - ... - trace_subsys_eventname(arg, task); - ... -} + void somefct(void) + { + ... + trace_subsys_eventname(arg, task); + ... + } Where : -- subsys_eventname is an identifier unique to your event + - subsys_eventname is an identifier unique to your event + - subsys is the name of your subsystem. - eventname is the name of the event to trace. -- TP_PROTO(int firstarg, struct task_struct *p) is the prototype of the - function called by this tracepoint. + - `TP_PROTO(int firstarg, struct task_struct *p)` is the prototype of the + function called by this tracepoint. -- TP_ARGS(firstarg, p) are the parameters names, same as found in the - prototype. + - `TP_ARGS(firstarg, p)` are the parameters names, same as found in the + prototype. -- if you use the header in multiple source files, #define CREATE_TRACE_POINTS - should appear only in one source file. + - if you use the header in multiple source files, `#define CREATE_TRACE_POINTS` + should appear only in one source file. Connecting a function (probe) to a tracepoint is done by providing a probe (function to call) for the specific tracepoint through @@ -117,7 +120,7 @@ used to export the defined tracepoints. If you need to do a bit of work for a tracepoint parameter, and that work is only used for the tracepoint, that work can be encapsulated -within an if statement with the following: +within an if statement with the following:: if (trace_foo_bar_enabled()) { int i; @@ -139,7 +142,7 @@ The advantage of using the trace_<tracepoint>_enabled() is that it uses the static_key of the tracepoint to allow the if statement to be implemented with jump labels and avoid conditional branches. -Note: The convenience macro TRACE_EVENT provides an alternative way to +.. note:: The convenience macro TRACE_EVENT provides an alternative way to define tracepoints. Check http://lwn.net/Articles/379903, http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362 for a series of articles with more details. diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.rst index bf526a7c..98d3f69 100644 --- a/Documentation/trace/uprobetracer.txt +++ b/Documentation/trace/uprobetracer.rst @@ -1,7 +1,8 @@ - Uprobe-tracer: Uprobe-based Event Tracing - ========================================= +========================================= +Uprobe-tracer: Uprobe-based Event Tracing +========================================= - Documentation written by Srikar Dronamraju +:Author: Srikar Dronamraju Overview @@ -19,6 +20,8 @@ user to calculate the offset of the probepoint in the object. Synopsis of uprobe_tracer ------------------------- +:: + p[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a uprobe r[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a return uprobe (uretprobe) -:[GRP/]EVENT : Clear uprobe or uretprobe event @@ -57,7 +60,7 @@ x86-64 uses x64). String type is a special type, which fetches a "null-terminated" string from user space. Bitfield is another special type, which takes 3 parameters, bit-width, bit- -offset, and container-size (usually 32). The syntax is; +offset, and container-size (usually 32). The syntax is:: b<bit-width>@<bit-offset>/<container-size> @@ -74,28 +77,28 @@ the third is the number of probe miss-hits. Usage examples -------------- * Add a probe as a new uprobe event, write a new definition to uprobe_events -as below: (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash) + as below (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash):: echo 'p /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events - * Add a probe as a new uretprobe event: + * Add a probe as a new uretprobe event:: echo 'r /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events - * Unset registered event: + * Unset registered event:: echo '-:p_bash_0x4245c0' >> /sys/kernel/debug/tracing/uprobe_events - * Print out the events that are registered: + * Print out the events that are registered:: cat /sys/kernel/debug/tracing/uprobe_events - * Clear all events: + * Clear all events:: echo > /sys/kernel/debug/tracing/uprobe_events Following example shows how to dump the instruction pointer and %ax register -at the probed text address. Probe zfree function in /bin/zsh: +at the probed text address. Probe zfree function in /bin/zsh:: # cd /sys/kernel/debug/tracing/ # cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp @@ -103,24 +106,27 @@ at the probed text address. Probe zfree function in /bin/zsh: # objdump -T /bin/zsh | grep -w zfree 0000000000446420 g DF .text 0000000000000012 Base zfree - 0x46420 is the offset of zfree in object /bin/zsh that is loaded at - 0x00400000. Hence the command to uprobe would be: +0x46420 is the offset of zfree in object /bin/zsh that is loaded at +0x00400000. Hence the command to uprobe would be:: # echo 'p:zfree_entry /bin/zsh:0x46420 %ip %ax' > uprobe_events - And the same for the uretprobe would be: +And the same for the uretprobe would be:: # echo 'r:zfree_exit /bin/zsh:0x46420 %ip %ax' >> uprobe_events -Please note: User has to explicitly calculate the offset of the probe-point -in the object. We can see the events that are registered by looking at the -uprobe_events file. +.. note:: User has to explicitly calculate the offset of the probe-point + in the object. + +We can see the events that are registered by looking at the uprobe_events file. +:: # cat uprobe_events p:uprobes/zfree_entry /bin/zsh:0x00046420 arg1=%ip arg2=%ax r:uprobes/zfree_exit /bin/zsh:0x00046420 arg1=%ip arg2=%ax -Format of events can be seen by viewing the file events/uprobes/zfree_entry/format +Format of events can be seen by viewing the file events/uprobes/zfree_entry/format. +:: # cat events/uprobes/zfree_entry/format name: zfree_entry @@ -139,16 +145,18 @@ Format of events can be seen by viewing the file events/uprobes/zfree_entry/form print fmt: "(%lx) arg1=%lx arg2=%lx", REC->__probe_ip, REC->arg1, REC->arg2 Right after definition, each event is disabled by default. For tracing these -events, you need to enable it by: +events, you need to enable it by:: # echo 1 > events/uprobes/enable Lets disable the event after sleeping for some time. +:: # sleep 20 # echo 0 > events/uprobes/enable And you can see the traced information via /sys/kernel/debug/tracing/trace. +:: # cat trace # tracer: nop diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX index 11d3d8d..0278f2c 100644 --- a/Documentation/vm/00-INDEX +++ b/Documentation/vm/00-INDEX @@ -10,6 +10,8 @@ frontswap.txt - Outline frontswap, part of the transcendent memory frontend. highmem.txt - Outline of highmem and common issues. +hmm.txt + - Documentation of heterogeneous memory management hugetlbpage.txt - a brief summary of hugetlbpage support in the Linux kernel. hugetlbfs_reserv.txt @@ -20,25 +22,41 @@ idle_page_tracking.txt - description of the idle page tracking feature. ksm.txt - how to use the Kernel Samepage Merging feature. +mmu_notifier.txt + - a note about clearing pte/pmd and mmu notifications numa - information about NUMA specific code in the Linux vm. numa_memory_policy.txt - documentation of concepts and APIs of the 2.6 memory policy support. overcommit-accounting - description of the Linux kernels overcommit handling modes. +page_frags + - description of page fragments allocator page_migration - description of page migration in NUMA systems. pagemap.txt - pagemap, from the userspace perspective +page_owner.txt + - tracking about who allocated each page +remap_file_pages.txt + - a note about remap_file_pages() system call slub.txt - a short users guide for SLUB. soft-dirty.txt - short explanation for soft-dirty PTEs split_page_table_lock - Separate per-table lock to improve scalability of the old page_table_lock. +swap_numa.txt + - automatic binding of swap device to numa node transhuge.txt - Transparent Hugepage Support, alternative way of using hugepages. unevictable-lru.txt - Unevictable LRU infrastructure +userfaultfd.txt + - description of userfaultfd system call +z3fold.txt + - outline of z3fold allocator for storing compressed pages +zsmalloc.txt + - outline of zsmalloc allocator for storing compressed pages zswap.txt - Intro to compressed cache for swap pages diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt index beea975..6d6200ea 100644 --- a/Documentation/watchdog/watchdog-parameters.txt +++ b/Documentation/watchdog/watchdog-parameters.txt @@ -55,11 +55,6 @@ wdt_time: Watchdog time in seconds. (default=30) nowayout: Watchdog cannot be stopped once started (default=kernel config parameter) ------------------------------------------------- -bfin_wdt: -timeout: Watchdog timeout in seconds. (1<=timeout<=((2^32)/SCLK), default=20) -nowayout: Watchdog cannot be stopped once started - (default=kernel config parameter) -------------------------------------------------- coh901327_wdt: margin: Watchdog margin in seconds (default 60s) ------------------------------------------------- diff --git a/Documentation/x86/x86_64/5level-paging.txt b/Documentation/x86/x86_64/5level-paging.txt index 087251a..2432a5e 100644 --- a/Documentation/x86/x86_64/5level-paging.txt +++ b/Documentation/x86/x86_64/5level-paging.txt @@ -20,12 +20,9 @@ Documentation/x86/x86_64/mm.txt CONFIG_X86_5LEVEL=y enables the feature. -So far, a kernel compiled with the option enabled will be able to boot -only on machines that supports the feature -- see for 'la57' flag in -/proc/cpuinfo. - -The plan is to implement boot-time switching between 4- and 5-level paging -in the future. +Kernel with CONFIG_X86_5LEVEL=y still able to boot on 4-level hardware. +In this case additional page table level -- p4d -- will be folded at +runtime. == User-space and large virtual address space == |
