Home
last modified time | relevance | path

Searched +full:non +full:- +full:descriptive (Results 1 – 13 of 13) sorted by relevance

/Documentation/devicetree/bindings/display/panel/
Dpanel-common.yaml1 # SPDX-License-Identifier: GPL-2.0
3 ---
4 $id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Thierry Reding <thierry.reding@gmail.com>
11 - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
23 # Descriptive Properties
24 width-mm:
29 height-mm:
43 non-descriptive information. For instance an LCD panel in a system that
[all …]
/Documentation/sound/cards/
Dpcmtest.rst1 .. SPDX-License-Identifier: GPL-2.0
16 * Generate random or pattern-based capturing data
21 non-interleaved access modes.
24 which is used in the corresponding selftest (alsa/pcmtest-test.sh) to check the PCM middle
29 -------------
33 * fill_mode (bool) - Buffer fill mode (see below)
41 -----------------------
44 means random data generation, the second (1 in the fill_mode) - pattern-based
51 * /sys/kernel/debug/pcmtest/fill_pattern[0-3]
52 * /sys/kernel/debug/pcmtest/fill_pattern[0-3]_len
[all …]
/Documentation/doc-guide/
Dkernel-doc.rst1 .. title:: Kernel-doc comments
4 Writing kernel-doc comments
8 comments in the kernel-doc format to describe the functions, types
9 and design of the code. It is easier to keep documentation up-to-date
12 .. note:: The kernel-doc format is deceptively similar to javadoc,
13 gtk-doc or Doxygen, yet distinctively different, for historical
14 reasons. The kernel source contains tens of thousands of kernel-doc
17 .. note:: kernel-doc does not cover Rust code: please see
18 Documentation/rust/general-information.rst instead.
20 The kernel-doc structure is extracted from the comments, and proper
[all …]
/Documentation/process/
Dmaintainer-tip.rst1 .. SPDX-License-Identifier: GPL-2.0
7 ---------------------
11 aggregation tree for several sub-maintainer trees. The tip tree gitweb URL
16 - **x86 architecture**
22 x86-specific KVM and XEN patches.
30 mail alias which distributes mails to the x86 top-level maintainer
32 ``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in
35 - **Scheduler**
37 Scheduler development takes place in the -tip tree, in the
38 sched/core branch - with occasional sub-topic trees for
[all …]
Dcoding-style.rst19 --------------
31 Now, some people will claim that having 8-character indentations makes
33 80-character terminal screen. The answer to that is that if you need
37 In short, 8-char indents make things easier to read, and have the added
43 instead of ``double-indenting`` the ``case`` labels. E.g.:
45 .. code-block:: c
67 .. code-block:: c
74 .. code-block:: c
81 .. code-block:: c
99 ----------------------------------
[all …]
Dsubmitting-patches.rst13 works, see Documentation/process/development-process.rst. Also, read
14 Documentation/process/submit-checklist.rst
17 Documentation/devicetree/bindings/submitting-patches.rst.
20 If you're unfamiliar with ``git``, you would be well-advised to learn how to
26 :ref:`Documentation/process/maintainer-handbooks.rst <maintainer_handbooks_main>`.
29 ----------------------------
46 ---------------------
48 Describe your problem. Whether your patch is a one-line bug fix or
54 Describe user-visible impact. Straight up crashes and lockups are
59 vendor/product-specific trees that cherry-pick only specific patches
[all …]
/Documentation/devicetree/bindings/regulator/
Dregulator.yaml1 # SPDX-License-Identifier: GPL-2.0
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Liam Girdwood <lgirdwood@gmail.com>
11 - Mark Brown <broonie@kernel.org>
14 regulator-name:
15 description: A string used as a descriptive name for regulator outputs
18 regulator-min-microvolt:
21 regulator-max-microvolt:
24 regulator-microvolt-offset:
[all …]
/Documentation/admin-guide/
Dcgroup-v2.rst1 .. _cgroup-v2:
11 conventions of cgroup v2. It describes all userland-visible aspects
14 v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgroup-v1>`.
19 1-1. Terminology
20 1-2. What is cgroup?
22 2-1. Mounting
23 2-2. Organizing Processes and Threads
24 2-2-1. Processes
25 2-2-2. Threads
26 2-3. [Un]populated Notification
[all …]
Dreporting-issues.rst1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
36 ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
44 to pin-point the culprit with a bisection; if you succeed, include its
45 commit-id and CC everyone in the sign-off-by chain.
51 Step-by-step guide how to report issues to the kernel maintainers
58 step-by-step approach. It still tries to be brief for readability and leaves
59 out a lot of details; those are described below the step-by-step guide in a
89 kernel modules on-the-fly, which solutions like DKMS might be doing locally
154 thing a descriptive title or subject that yet again is shorter. Then you're
169 --------------------------------------------------------------
[all …]
/Documentation/driver-api/media/
Dv4l2-dev.rst1 .. SPDX-License-Identifier: GPL-2.0
7 :c:type:`video_device` struct (``v4l2-dev.h``). This struct can either be
12 .. code-block:: c
17 return -ENOMEM;
19 vdev->release = video_device_release;
24 .. code-block:: c
26 struct video_device *vdev = &my_vdev->vdev;
28 vdev->release = my_vdev_release;
42 - :c:type:`video_device`->v4l2_dev: must be set to the :c:type:`v4l2_device`
45 - :c:type:`video_device`->name: set to something descriptive and unique.
[all …]
/Documentation/hwmon/
Dsysfs-interface.rst5 through the sysfs interface. Since lm-sensors 3.0.0, libsensors is
6 completely chip-independent. It assumes that all the kernel drivers
10 This is a major improvement compared to lm-sensors 2.
22 For this reason, even if we aim at a chip-independent libsensors, it will
37 Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes
38 in the "physical" device directory. Since lm-sensors 3.0.1, attributes found
61 to cause an alarm) is chip-dependent.
69 ----------------
76 -------------------------------------------------------------------------
79 `[0-*]` denotes any positive number starting from 0
[all …]
/Documentation/devicetree/bindings/cpu/
Didle-states.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/cpu/idle-states.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
11 - Anup Patel <anup@brainfault.org>
15 1 - Introduction
18 ARM and RISC-V systems contain HW capable of managing power consumption
19 dynamically, where cores can be put in different low-power states (ranging
22 run-time, can be specified through device tree bindings representing the
[all …]
/Documentation/driver-api/
Dpin-control.rst9 - Enumerating and naming controllable pins
11 - Multiplexing of pins, pads, fingers (etc) see below for details
13 - Configuration of pins, pads, fingers (etc), such as software-controlled
14 biasing and driving mode specific pins, such as pull-up, pull-down, open drain,
17 Top-level interface
22 - A PIN CONTROLLER is a piece of hardware, usually a set of registers, that
26 - PINS are equal to pads, fingers, balls or whatever packaging input or
30 be sparse - i.e. there may be gaps in the space with numbers where no
60 .. code-block:: c
97 See ``arch/arm/mach-ux500/Kconfig`` for an example.
[all …]