| /linux/tools/perf/Documentation/ |
| H A D | perf-script-perl.txt | 17 built-in Perl interpreter. It reads and processes the input file and
18 displays the results of the trace analysis implemented in the given
24 You can avoid reading the rest of this document by running 'perf script
25 -g perl' in the same directory as an existing perf.data trace file.
27 the event types in the trace file; it simply prints every available
28 field for each event in the trace file.
30 You can also look at the existing scripts in
33 the check-perf-script.pl script, while not interesting for its results,
34 attempts to exercise all of the main scripting features.
40 'handler function' is called for each event in the trace. If there's
[all …]
|
| H A D | perf-report.txt | 6 perf-report - Read perf.data (created by perf record) and display the profile
15 This command displays the performance counter profile information recorded
34 Show the number of samples for each symbol
41 Show per-thread event counters. The input data file should be recorded
46 file://filename entries. This option will affect the percentage of
47 the overhead and latency columns. See --percentage for more info.
56 file://filename entries. This option will affect the percentage of
57 the overhead and latency columns. See --percentage for more info.
61 file://filename entries. This option will affect the percentage of
62 the overhead and latency columns. See --percentage for more info.
[all …]
|
| /linux/Documentation/leds/ |
| H A D | leds-class.rst | 5 In its simplest form, the LED class just allows control of LEDs from
6 userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the
7 LED is defined in max_brightness file. The brightness file will set the brightness
8 of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
11 The class also introduces the optional concept of an LED trigger. A trigger
14 existing subsystems with minimal additional code. Examples are the disk-activity,
15 nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
19 parameters and work on a per LED basis. The timer trigger is an example.
20 The timer trigger will periodically change the LED brightness between
21 LED_OFF and the current brightness setting. The "on" and "off" time can
[all …]
|
| /linux/Documentation/filesystems/ |
| H A D | romfs.rst | 8 disks of installation disks. It has grown up by the need of having
10 similar feature, and even the possibility of a small kernel, with a
11 file system which doesn't take up useful memory from the router
12 functions in the basement of your office.
14 For comparison, both the older minix and xiafs (the latter is now
17 code). Under the same conditions, the msdos filesystem would need
18 about 30K (and does not support device nodes or symlinks), while the
26 As the name suggests, romfs could be also used (space-efficiently) on
27 various read-only media, like (E)EPROM disks if someone will have the
30 However, the main purpose of romfs is to have a very small kernel,
[all …]
|
| /linux/lib/ |
| H A D | rcuref.c | 8 * be visible even after the last reference has been dropped and the object
30 * rcuref uses atomic_add_negative_relaxed() for the fast path, which scales
36 * In principle it should be possible to make refcount use the rcuref
37 * scheme, but the destruction race described below cannot be prevented
38 * unless the protected object is RCU managed.
43 * rcuref uses an unsigned integer reference counter. As long as the
45 * than RCUREF_MAXREF the reference is alive:
51 * The get() and put() operations do unconditional increments and
52 * decrements. The result is checked after the operation. This optimizes
53 * for the fast path.
[all …]
|
| /linux/Documentation/admin-guide/media/ |
| H A D | philips.rst | 6 This file contains some additional information for the Philips and OEM webcams.
10 As of this moment, the following cameras are supported:
37 The main webpage for the Philips driver is at the address above. It contains
38 a lot of extra information, a FAQ, and the binary plugin 'PWCX'. This plugin
40 framerates; in addition the webcam uses less bandwidth on the USB bus (handy
46 the latter, since it makes troubleshooting a lot easier. The built-in
47 microphone is supported through the USB Audio class.
49 When you load the module you can set some default settings for the
51 don't know how to set it properly in the driver. The options are:
60 Specifies the desired framerate. Is an integer in the range of 4-30.
[all …]
|
| /linux/drivers/staging/media/atomisp/pci/base/circbuf/interface/ |
| H A D | ia_css_circbuf.h | 24 * @brief Data structure for the circular buffer.
28 ia_css_circbuf_desc_t *desc; /* Pointer to the descriptor of the circbuf */
33 * @brief Create the circular buffer.
35 * @param cb The pointer to the circular buffer.
37 * @param desc The descriptor set to the size using ia_css_circbuf_desc_init().
45 * @brief Destroy the circular buffer.
47 * @param cb The pointer to the circular buffer.
53 * @brief Pop a value out of the circular buffer.
54 * Get a value at the head of the circular buffer.
55 * The user should call "ia_css_circbuf_is_empty()"
[all …]
|
| /linux/Documentation/userspace-api/media/v4l/ |
| H A D | crop.rst | 6 Image Cropping, Insertion and Scaling -- the CROP API
11 The CROP API is mostly superseded by the newer :ref:`SELECTION API
12 <selection-api>`. The new API should be preferred in most cases,
13 with the exception of pixel aspect ratio detection, which is
15 equivalent in the SELECTION API. See :ref:`selection-vs-crop` for a
16 comparison of the two APIs.
18 Some video capture devices can sample a subsection of the picture and
24 Applications can use the following API to select an area in the video
25 signal, query the default area and the hardware limits.
29 Despite their name, the :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>`,
[all …]
|
| /linux/Documentation/devicetree/bindings/fpga/ |
| H A D | fpga-region.yaml | 26 the Device Tree. FPGA Regions provide a way to program FPGAs under device tree
29 The documentation hits some of the high points of FPGA usage and
39 * The entire FPGA is programmed.
42 * A section of an FPGA is reprogrammed while the rest of the FPGA is not
51 * The size and specific location of each PRR is fixed.
52 * The connections at the edge of each PRR are fixed. The image that is loaded
53 into a PRR must fit and must use a subset of the region's connections.
54 * The busses within the FPGA are split such that each region gets its own
66 * FPGA Bridges should be disabled while the FPGA is being programmed to
67 prevent spurious signals on the cpu bus and to the soft logic.
[all …]
|
| /linux/crypto/krb5/ |
| H A D | krb5_api.c | 29 * crypto_krb5_find_enctype - Find the handler for a Kerberos5 encryption type
30 * @enctype: The standard Kerberos encryption type number
33 * pointer to the type tables; returns NULL otherwise.
52 * @krb5: The encoding to use.
53 * @mode: The mode in which to operated (checksum/encrypt)
55 * @_offset: Where to place the offset into the buffer
58 * This allows for a confounder, padding and checksum as appropriate. The
59 * amount of buffer required is returned and the offset into the buffer at
60 * which the data will start is placed in *_offset.
85 * @krb5: The encoding to use.
[all …]
|
| /linux/drivers/i2c/busses/ |
| H A D | Kconfig | 23 If you say yes to this option, support will be included for the SMB
24 Host controller on Acer Labs Inc. (ALI) M1535 South Bridges. The SMB
25 controller is part of the 7101 device, which is an ACPI-compliant
28 This driver can also be built as a module. If so, the module
35 If you say yes to this option, support will be included for the SMB
36 Host controller on Acer Labs Inc. (ALI) M1563 South Bridges. The SMB
37 controller is part of the 7101 device, which is an ACPI-compliant
40 This driver can also be built as a module. If so, the module
47 If you say yes to this option, support will be included for the
50 This driver can also be built as a module. If so, the module
[all …]
|
| /linux/arch/powerpc/xmon/ |
| H A D | ppc.h | 5 This file is part of GDB, GAS, and the GNU binutils.
7 GDB, GAS, and the GNU binutils are free software; you can redistribute
8 them and/or modify them under the terms of the GNU General Public
9 License as published by the Free Software Foundation; either version
12 GDB, GAS, and the GNU binutils are distributed in the hope that they
13 will be useful, but WITHOUT ANY WARRANTY; without even the implied
15 the GNU General Public License for more details.
17 You should have received a copy of the GNU General Public License
18 along with this file; see the file COPYING. If not, write to the Free
30 /* The opcode table is an array of struct powerpc_opcode. */
[all …]
|
| /linux/Documentation/scheduler/ |
| H A D | sched-domains.rst | 5 Each CPU has a "base" scheduling domain (struct sched_domain). The domain
6 hierarchy is built from these base domains via the ->parent pointer. ->parent
10 Each scheduling domain spans a number of CPUs (stored in the ->span field).
12 be relaxed if the need arises), and a base domain for CPU i MUST span at least
13 i. The top domain for each CPU will generally span all CPUs in the system
15 CPUs will never be given tasks to run unless the CPUs allowed mask is
20 which are organised as a circular one way linked list from the ->groups
21 pointer. The union of cpumasks of these groups MUST be the same as the
22 domain's span. The group pointed to by the ->groups pointer MUST contain the CPU
23 to which the domain belongs. Groups may be shared among CPUs as they contain
[all …]
|
| H A D | sched-ext.rst | 8 programs - the BPF scheduler.
13 * The BPF scheduler can group CPUs however it sees fit and schedule them
14 together, as tasks aren't tied to specific CPUs at the time of wakeup.
16 * The BPF scheduler can be turned on and off dynamically anytime.
18 * The system integrity is maintained no matter what the BPF scheduler does.
19 The default scheduling behavior is restored anytime an error is detected,
20 a runnable task stalls, or on invoking the SysRq key sequence
23 * When the BPF scheduler triggers an error, debug information is dumped to
24 aid debugging. The debug dump is passed to and printed out by the
25 scheduler binary. The debug dump can also be accessed through the
[all …]
|
| /linux/Documentation/process/ |
| H A D | maintainer-netdev.rst | 13 - for fixes the ``Fixes:`` tag is required, regardless of the tree
23 drivers/net (i.e. hardware specific drivers) in the Linux source tree.
28 Like many other Linux mailing lists, the netdev list is hosted at
39 the cadence of Linux development. Each new release starts off with a
40 two week "merge window" where the main maintainers feed their new stuff
41 to Linus for merging into the mainline tree. After the two weeks, the
43 features get mainlined after this -- only fixes to the rc1 content are
44 expected. After roughly a week of collecting fixes to the rc1 content,
47 state of churn), and a week after the last vX.Y-rcN was done, the
50 To find out where we are now in the cycle - load the mainline (Linus)
[all …]
|
| /linux/Documentation/gpu/ |
| H A D | vgaarbiter.rst | 7 implemented on PCI will typically have the same "hard-decoded" addresses as
12 The Resource Access Control (RAC) module inside the X server [0] existed for
13 the legacy VGA arbitration task (besides other bus management tasks) when more
14 than one legacy device co-exist on the same machine. But the problem happens
17 ideally, being a userspace application, it is not the role of the X server to
18 control bus resources. Therefore an arbitration scheme outside of the X server
19 is needed to control the sharing of these resources. This document introduces
20 the operation of the VGA arbiter implemented for the Linux kernel.
25 The vgaarb is a module of the Linux Kernel. When it is initially loaded, it
26 scans all PCI devices and adds the VGA ones inside the arbitration. The
[all …]
|
| /linux/kernel/trace/ |
| H A D | tracing_map.h | 19 * This is an overview of the tracing_map data structures and how they
20 * relate to the tracing_map API. The details of the algorithms
21 * aren't discussed here - this is just a general overview of the data
22 * structures and how they interact with the API.
24 * The central data structure of the tracing_map is an initially
25 * zeroed array of struct tracing_map_entry (stored in the map field
31 * be traversed and read by a user at any time (though the user does
32 * this indirectly via an array of tracing_map_sort_entry - see the
33 * explanation of that data structure in the discussion of the
36 * The central function of the tracing_map API is
[all …]
|
| /linux/Documentation/driver-api/driver-model/ |
| H A D | overview.rst | 2 The Linux Kernel Device Model
14 The Linux Kernel Driver Model is a unification of all the disparate driver
15 models that were previously used in the kernel. It is intended to augment the
20 (sometimes just a list) for the devices they control. There wasn't any
21 uniformity across the different bus types.
23 The current driver model provides a common, uniform data model for describing
24 a bus and the devices that can appear under the bus. The unified bus
29 The common device and bridge interface reflects the goals of the modern
30 computer: namely the ability to do seamless device "plug and play", power
31 management, and hot plug. In particular, the model dictated by Intel and
[all …]
|
| /linux/include/linux/surface_aggregator/ |
| H A D | serial_hub.h | 5 * Lower-level communication layers and SSH protocol definitions for the
6 * Surface System Aggregator Module (SSAM). Provides the interface for basic
7 * packet- and request-based communication with the SSAM EC via SSH.
28 * Indicates a data frame, followed by a payload with the length specified
29 * in the ``struct ssh_frame.len`` field. This frame is sequenced, meaning
33 * Same as %SSH_FRAME_TYPE_DATA_SEQ, but unsequenced, meaning that the
41 * means that the frame and/or payload is malformed, e.g. a CRC is wrong.
42 * For command-type payloads, this can also mean that the command is
54 * @type: The type of the frame. See &enum ssh_frame_type.
55 * @len: The length of the frame payload directly following the CRC for this
[all …]
|
| /linux/Documentation/networking/devlink/ |
| H A D | ice.rst | 7 This document describes the devlink features implemented by the ``ice``
27 - The ice hardware uses hierarchical scheduling for Tx with a fixed
28 number of layers in the scheduling tree. Each of them are decision
29 points. Root node represents a port, while all the leaves represent
30 the queues. This way of configuring the Tx scheduler allows features
34 at any given layer of the tree.
36 The default 9-layer tree topology was deemed best for most workloads,
40 of 8. Because the maximum radix is limited to 8 in 9-layer topology,
41 the 9th queue has a different parent than the rest, and it's given
42 more bandwidth credits. This causes a problem when the system is
[all …]
|
| /linux/Documentation/arch/s390/ |
| H A D | vfio-ccw.rst | 2 vfio-ccw: the basic infrastructure
8 Here we describe the vfio support for I/O subchannel devices for
10 virtual machine, while vfio is the means.
17 - The channel subsystem will access any memory designated by the caller
18 in the channel program directly, i.e. there is no iommu involved.
21 with a mediated device (mdev) implementation. The vfio mdev will be
22 added to an iommu group, so as to make itself able to be managed by the
24 regions to pass the channel programs from the mdev to its parent device
25 (the real I/O subchannel device) to do further address translation and
28 This document does not intend to explain the s390 I/O architecture in
[all …]
|
| /linux/Documentation/networking/ |
| H A D | napi.rst | 9 NAPI is the event handling mechanism used by the Linux networking stack.
10 The name NAPI no longer stands for anything in particular [#]_.
12 In basic operation the device notifies the host about new events
14 The host then schedules a NAPI instance to process the events.
15 The device may also be polled for events via NAPI without receiving
18 NAPI processing usually happens in the software interrupt context,
22 All in all NAPI abstracts away from the drivers the context and configuration
28 The two most important elements of NAPI are the struct napi_struct
29 and the associated poll method. struct napi_struct holds the state
30 of the NAPI instance while the method is the driver-specific event
[all …]
|
| /linux/Documentation/usb/ |
| H A D | usbmon.rst | 8 The name "usbmon" in lowercase refers to a facility in kernel which is
9 used to collect traces of I/O on the USB bus. This function is analogous
15 The usbmon reports requests made by peripheral-specific drivers to Host
16 Controller Drivers (HCD). So, if HCD is buggy, the traces reported by
17 usbmon may not correspond to bus transactions precisely. This is the same
20 Two APIs are currently implemented: "text" and "binary". The binary API
22 The text API is deprecated since 2.6.35, but available for convenience.
27 Unlike the packet socket, usbmon has an interface which provides traces
38 load the usbmon module (if built as module). The second step is skipped
39 if usbmon is built into the kernel::
[all …]
|
| H A D | gadget_serial.rst | 13 modify it under the terms of the GNU General Public License as
14 published by the Free Software Foundation; either version 2 of
15 the License, or (at your option) any later version.
17 This program is distributed in the hope that it will be useful,
18 but WITHOUT ANY WARRANTY; without even the implied warranty of
19 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
22 You should have received a copy of the GNU General Public
23 License along with this program; if not, write to the Free
27 This document and the gadget serial driver itself are
36 Versions of the gadget serial driver are available for the
[all …]
|
| /linux/drivers/acpi/ |
| H A D | Kconfig | 20 and assumes the presence of OS-directed configuration and power
26 the Plug-and-Play BIOS specification (PnP BIOS), the
27 MultiProcessor Specification (MPS), and the Advanced Power
32 Component Architecture (ACPI CA). For more information on the
38 it is developed by the ACPI Specification Working Group (ASWG) under
39 the UEFI Forum and any UEFI member can join the ASWG and contribute
40 to the ACPI specification.
41 The specification is available at:
75 results in the compilation of the ACPICA debugger files.
84 to access the debugger functionalities.
[all …]
|