docs updates for v5.10-rc1
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAl+JNGYACgkQCF8+vY7k
4RV/TA//ZoRoMQE5B6zwO4kOGILMbmW2uepjoEysLgus2ctkTUoRkpNLWS3SozcU
6c/eW1rC4Fji24te6lwusciZa5zQgbGMjFYk1LhnJ65lJA+kQ+kV1DGz/ZWtklMM
gLX20+tQADqGl+u2dmFCvmRhPWJ9nzt1C0auN7dGeu+9g97GnhKG6o2Kv/nVCb68
qMmAs9UrfN24DO5G1ixkdY08nSNJPrpgQnIR2ruUysUII/yTTtcnmHDbH3WWL6+9
2P87AZ6zsa3FdBhAjmG5YJklQgPkLFWEykHMTqq/Mkcpff/JB/AayrL6XNB2QoZb
YXLHJp3Na6iBmdmHhecg+VQDgz28UfMk+p+HFoJh8RTtJa9/qJvYdJmIE/mUPrnY
gL4jNgMVwkptGHXh7IRuSLysT5heJPMQss6TfZ6yYadeOIpx7W8MCAYnGffiElLQ
hmKdmyCszS3SERJz40EOBdr2NQYcDEUt2NtEhdVfium21A4PFOdJlCejifGhJyzP
n1QcyMXHnh/d4zecA6fcD0LVyxBgngeKEvdtOLZJ1ubxWwHhgWTN8R4HedoN2Nb9
cLEUK8Td+9n2RVS8UED4BBI+6vfN3Y6Syjvy8qD3pCs4SBcu3k790mf47t2QhkEq
+Ho06gdrGJdEcSDO8zVY7qjZX/GX/dbRHCb5CRokL5FmNWhXd/Y=
=26wi
-----END PGP SIGNATURE-----
Merge tag 'docs/v5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull documentation updates from Mauro Carvalho Chehab:
"A series of patches addressing warnings produced by make htmldocs.
This includes:
- kernel-doc markup fixes
- ReST fixes
- Updates at the build system in order to support newer versions of
the docs build toolchain (Sphinx)
After this series, the number of html build warnings should reduce
significantly, and building with Sphinx 3.1 or later should now be
supported (although it is still recommended to use Sphinx 2.4.4).
As agreed with Jon, I should be sending you a late pull request by the
end of the merge window addressing remaining issues with docs build,
as there are a number of warning fixes that depends on pull requests
that should be happening along the merge window.
The end goal is to have a clean htmldocs build on Kernel 5.10.
PS. It should be noticed that Sphinx 3.0 is not currently supported,
as it lacks support for C domain namespaces. Such feature, needed in
order to document uAPI system calls with Sphinx 3.x, was added only on
Sphinx 3.1"
* tag 'docs/v5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (75 commits)
PM / devfreq: remove a duplicated kernel-doc markup
mm/doc: fix a literal block markup
workqueue: fix a kernel-doc warning
docs: virt: user_mode_linux_howto_v2.rst: fix a literal block markup
Input: sparse-keymap: add a description for @sw
rcu/tree: docs: document bkvcache new members at struct kfree_rcu_cpu
nl80211: docs: add a description for s1g_cap parameter
usb: docs: document altmode register/unregister functions
kunit: test.h: fix a bad kernel-doc markup
drivers: core: fix kernel-doc markup for dev_err_probe()
docs: bio: fix a kerneldoc markup
kunit: test.h: solve kernel-doc warnings
block: bio: fix a warning at the kernel-doc markups
docs: powerpc: syscall64-abi.rst: fix a malformed table
drivers: net: hamradio: fix document location
net: appletalk: Kconfig: Fix docs location
dt-bindings: fix references to files converted to yaml
memblock: get rid of a :c:type leftover
math64.h: kernel-docs: Convert some markups into normal comments
media: uAPI: buffer.rst: remove a left-over documentation
...
zero-sugar-mainline-defconfig
Linus Torvalds
commit
54a4c789ca
|
|
@ -1,7 +1,6 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
.. |struct cpufreq_policy| replace:: :c:type:`struct cpufreq_policy <cpufreq_policy>`
|
||||
.. |intel_pstate| replace:: :doc:`intel_pstate <intel_pstate>`
|
||||
|
||||
=======================
|
||||
|
|
@ -92,16 +91,16 @@ control the P-state of multiple CPUs at the same time and writing to it affects
|
|||
all of those CPUs simultaneously.
|
||||
|
||||
Sets of CPUs sharing hardware P-state control interfaces are represented by
|
||||
``CPUFreq`` as |struct cpufreq_policy| objects. For consistency,
|
||||
|struct cpufreq_policy| is also used when there is only one CPU in the given
|
||||
``CPUFreq`` as struct cpufreq_policy objects. For consistency,
|
||||
struct cpufreq_policy is also used when there is only one CPU in the given
|
||||
set.
|
||||
|
||||
The ``CPUFreq`` core maintains a pointer to a |struct cpufreq_policy| object for
|
||||
The ``CPUFreq`` core maintains a pointer to a struct cpufreq_policy object for
|
||||
every CPU in the system, including CPUs that are currently offline. If multiple
|
||||
CPUs share the same hardware P-state control interface, all of the pointers
|
||||
corresponding to them point to the same |struct cpufreq_policy| object.
|
||||
corresponding to them point to the same struct cpufreq_policy object.
|
||||
|
||||
``CPUFreq`` uses |struct cpufreq_policy| as its basic data type and the design
|
||||
``CPUFreq`` uses struct cpufreq_policy as its basic data type and the design
|
||||
of its user space interface is based on the policy concept.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -154,17 +154,11 @@ Configurations for driver
|
|||
Only a block device driver cares about these configurations. A block device
|
||||
driver uses ``register_pstore_blk`` to register to pstore/blk.
|
||||
|
||||
.. kernel-doc:: fs/pstore/blk.c
|
||||
:identifiers: register_pstore_blk
|
||||
|
||||
A non-block device driver uses ``register_pstore_device`` with
|
||||
``struct pstore_device_info`` to register to pstore/blk.
|
||||
|
||||
.. kernel-doc:: fs/pstore/blk.c
|
||||
:identifiers: register_pstore_device
|
||||
|
||||
.. kernel-doc:: include/linux/pstore_blk.h
|
||||
:identifiers: pstore_device_info
|
||||
:export:
|
||||
|
||||
Compression and header
|
||||
----------------------
|
||||
|
|
@ -237,7 +231,7 @@ For developer reference, here are all the important structures and APIs:
|
|||
:internal:
|
||||
|
||||
.. kernel-doc:: fs/pstore/blk.c
|
||||
:export:
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: include/linux/pstore_blk.h
|
||||
:internal:
|
||||
|
|
|
|||
|
|
@ -63,10 +63,10 @@ Software staging queues
|
|||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The block IO subsystem adds requests in the software staging queues
|
||||
(represented by struct :c:type:`blk_mq_ctx`) in case that they weren't sent
|
||||
(represented by struct blk_mq_ctx) in case that they weren't sent
|
||||
directly to the driver. A request is one or more BIOs. They arrived at the
|
||||
block layer through the data structure struct :c:type:`bio`. The block layer
|
||||
will then build a new structure from it, the struct :c:type:`request` that will
|
||||
block layer through the data structure struct bio. The block layer
|
||||
will then build a new structure from it, the struct request that will
|
||||
be used to communicate with the device driver. Each queue has its own lock and
|
||||
the number of queues is defined by a per-CPU or per-node basis.
|
||||
|
||||
|
|
@ -102,7 +102,7 @@ hardware queue will be drained in sequence according to their mapping.
|
|||
Hardware dispatch queues
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The hardware queue (represented by struct :c:type:`blk_mq_hw_ctx`) is a struct
|
||||
The hardware queue (represented by struct blk_mq_hw_ctx) is a struct
|
||||
used by device drivers to map the device submission queues (or device DMA ring
|
||||
buffer), and are the last step of the block layer submission code before the
|
||||
low level device driver taking ownership of the request. To run this queue, the
|
||||
|
|
@ -110,9 +110,9 @@ block layer removes requests from the associated software queues and tries to
|
|||
dispatch to the hardware.
|
||||
|
||||
If it's not possible to send the requests directly to hardware, they will be
|
||||
added to a linked list (:c:type:`hctx->dispatch`) of requests. Then,
|
||||
added to a linked list (``hctx->dispatch``) of requests. Then,
|
||||
next time the block layer runs a queue, it will send the requests laying at the
|
||||
:c:type:`dispatch` list first, to ensure a fairness dispatch with those
|
||||
``dispatch`` list first, to ensure a fairness dispatch with those
|
||||
requests that were ready to be sent first. The number of hardware queues
|
||||
depends on the number of hardware contexts supported by the hardware and its
|
||||
device driver, but it will not be more than the number of cores of the system.
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Constraints and notes
|
|||
Design
|
||||
======
|
||||
|
||||
We add a :c:type:`struct bio_crypt_ctx` to :c:type:`struct bio` that can
|
||||
We add a struct bio_crypt_ctx to struct bio that can
|
||||
represent an encryption context, because we need to be able to pass this
|
||||
encryption context from the upper layers (like the fs layer) to the
|
||||
device driver to act upon.
|
||||
|
|
@ -85,7 +85,7 @@ blk-mq changes, other block layer changes and blk-crypto-fallback
|
|||
=================================================================
|
||||
|
||||
We add a pointer to a ``bi_crypt_context`` and ``keyslot`` to
|
||||
:c:type:`struct request`. These will be referred to as the ``crypto fields``
|
||||
struct request. These will be referred to as the ``crypto fields``
|
||||
for the request. This ``keyslot`` is the keyslot into which the
|
||||
``bi_crypt_context`` has been programmed in the KSM of the ``request_queue``
|
||||
that this request is being sent to.
|
||||
|
|
@ -118,7 +118,7 @@ of the algorithm being used adheres to spec and functions correctly).
|
|||
If a ``request queue``'s inline encryption hardware claimed to support the
|
||||
encryption context specified with a bio, then it will not be handled by the
|
||||
``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a
|
||||
:c:type:`struct request` needs to be allocated for that bio. At that point,
|
||||
struct request needs to be allocated for that bio. At that point,
|
||||
blk-mq tries to program the encryption context into the ``request_queue``'s
|
||||
keyslot_manager, and obtain a keyslot, which it stores in its newly added
|
||||
``keyslot`` field. This keyslot is released when the request is completed.
|
||||
|
|
@ -188,7 +188,7 @@ keyslots supported by the hardware.
|
|||
The device driver also needs to tell the KSM how to actually manipulate the
|
||||
IE hardware in the device to do things like programming the crypto key into
|
||||
the IE hardware into a particular keyslot. All this is achieved through the
|
||||
:c:type:`struct blk_ksm_ll_ops` field in the KSM that the device driver
|
||||
struct blk_ksm_ll_ops field in the KSM that the device driver
|
||||
must fill up after initing the ``blk_keyslot_manager``.
|
||||
|
||||
The KSM also handles runtime power management for the device when applicable
|
||||
|
|
|
|||
|
|
@ -47,9 +47,68 @@ extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
|
|||
#
|
||||
if major >= 3:
|
||||
sys.stderr.write('''WARNING: The kernel documentation build process
|
||||
does not work correctly with Sphinx v3.0 and above. Expect errors
|
||||
in the generated output.
|
||||
''')
|
||||
support for Sphinx v3.0 and above is brand new. Be prepared for
|
||||
possible issues in the generated output.
|
||||
''')
|
||||
if minor > 0 or patch >= 2:
|
||||
# Sphinx c function parser is more pedantic with regards to type
|
||||
# checking. Due to that, having macros at c:function cause problems.
|
||||
# Those needed to be scaped by using c_id_attributes[] array
|
||||
c_id_attributes = [
|
||||
# GCC Compiler types not parsed by Sphinx:
|
||||
"__restrict__",
|
||||
|
||||
# include/linux/compiler_types.h:
|
||||
"__iomem",
|
||||
"__kernel",
|
||||
"noinstr",
|
||||
"notrace",
|
||||
"__percpu",
|
||||
"__rcu",
|
||||
"__user",
|
||||
|
||||
# include/linux/compiler_attributes.h:
|
||||
"__alias",
|
||||
"__aligned",
|
||||
"__aligned_largest",
|
||||
"__always_inline",
|
||||
"__assume_aligned",
|
||||
"__cold",
|
||||
"__attribute_const__",
|
||||
"__copy",
|
||||
"__pure",
|
||||
"__designated_init",
|
||||
"__visible",
|
||||
"__printf",
|
||||
"__scanf",
|
||||
"__gnu_inline",
|
||||
"__malloc",
|
||||
"__mode",
|
||||
"__no_caller_saved_registers",
|
||||
"__noclone",
|
||||
"__nonstring",
|
||||
"__noreturn",
|
||||
"__packed",
|
||||
"__pure",
|
||||
"__section",
|
||||
"__always_unused",
|
||||
"__maybe_unused",
|
||||
"__used",
|
||||
"__weak",
|
||||
"noinline",
|
||||
|
||||
# include/linux/memblock.h:
|
||||
"__init_memblock",
|
||||
"__meminit",
|
||||
|
||||
# include/linux/init.h:
|
||||
"__init",
|
||||
"__ref",
|
||||
|
||||
# include/linux/linkage.h:
|
||||
"asmlinkage",
|
||||
]
|
||||
|
||||
else:
|
||||
extensions.append('cdomain')
|
||||
|
||||
|
|
|
|||
|
|
@ -419,6 +419,7 @@ functions which are exported.
|
|||
.. kernel-doc:: kernel/irq/manage.c
|
||||
|
||||
.. kernel-doc:: kernel/irq/chip.c
|
||||
:export:
|
||||
|
||||
Internal Functions Provided
|
||||
===========================
|
||||
|
|
@ -431,6 +432,7 @@ functions.
|
|||
.. kernel-doc:: kernel/irq/handle.c
|
||||
|
||||
.. kernel-doc:: kernel/irq/chip.c
|
||||
:internal:
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
|
|
|||
|
|
@ -231,12 +231,6 @@ Refer to the file kernel/module.c for more information.
|
|||
Hardware Interfaces
|
||||
===================
|
||||
|
||||
Interrupt Handling
|
||||
------------------
|
||||
|
||||
.. kernel-doc:: kernel/irq/manage.c
|
||||
:export:
|
||||
|
||||
DMA Channels
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -396,3 +396,5 @@ Kernel Inline Documentations Reference
|
|||
======================================
|
||||
|
||||
.. kernel-doc:: include/linux/workqueue.h
|
||||
|
||||
.. kernel-doc:: kernel/workqueue.c
|
||||
|
|
|
|||
|
|
@ -726,7 +726,7 @@ The kernel debugger is organized into a number of components:
|
|||
- contains an arch-specific trap catcher which invokes
|
||||
kgdb_handle_exception() to start kgdb about doing its work
|
||||
|
||||
- translation to and from gdb specific packet format to :c:type:`pt_regs`
|
||||
- translation to and from gdb specific packet format to struct pt_regs
|
||||
|
||||
- Registration and unregistration of architecture specific trap
|
||||
hooks
|
||||
|
|
@ -846,7 +846,7 @@ invokes a callback in the serial core which in turn uses the callback in
|
|||
the UART driver.
|
||||
|
||||
When using kgdboc with a UART, the UART driver must implement two
|
||||
callbacks in the :c:type:`struct uart_ops <uart_ops>`.
|
||||
callbacks in the struct uart_ops.
|
||||
Example from ``drivers/8250.c``::
|
||||
|
||||
|
||||
|
|
@ -875,7 +875,7 @@ kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration.
|
|||
The core polled keyboard driver for PS/2 type keyboards is in
|
||||
``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core
|
||||
when kgdboc populates the callback in the array called
|
||||
:c:type:`kdb_poll_funcs[]`. The kdb_get_kbd_char() is the top-level
|
||||
:c:expr:`kdb_poll_funcs[]`. The kdb_get_kbd_char() is the top-level
|
||||
function which polls hardware for single character input.
|
||||
|
||||
kgdboc and kms
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Optional nodes:
|
|||
supports a single port with a single endpoint.
|
||||
|
||||
- See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
|
||||
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt for connecting
|
||||
Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml for connecting
|
||||
tfp410 DVI encoder or lcd panel to lcdc
|
||||
|
||||
[1] There is an errata about AM335x color wiring. For 16-bit color mode
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ The following are mandatory properties for the K3 AM65x and J721E SoCs only:
|
|||
the interrupt routes between the IP and the main GIC
|
||||
controllers. See the following binding for additional
|
||||
details,
|
||||
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
|
||||
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
|
||||
|
||||
Child Nodes:
|
||||
============
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ Optional Connector Properties:
|
|||
instead of using the autodetection mechnism. Please look at
|
||||
[1] for more information.
|
||||
|
||||
[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt.
|
||||
[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml.
|
||||
|
||||
Example - three input sources:
|
||||
#include <dt-bindings/display/sdtv-standards.h>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ description: |
|
|||
Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller
|
||||
(EC) and controlled via a host-command interface.
|
||||
An EC PWM node should be only found as a sub-node of the EC node (see
|
||||
Documentation/devicetree/bindings/mfd/cros-ec.txt).
|
||||
Documentation/devicetree/bindings/mfd/google,cros-ec.yaml).
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ description: |
|
|||
present and this subnode may contain children that designate regulator
|
||||
resources.
|
||||
|
||||
Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
|
||||
Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
|
||||
for information on the regulator subnodes that can exist under the
|
||||
rpm_requests.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ description: |
|
|||
Google's ChromeOS EC codec is a digital mic codec provided by the
|
||||
Embedded Controller (EC) and is controlled via a host-command interface.
|
||||
An EC codec node should only be found as a sub-node of the EC node (see
|
||||
Documentation/devicetree/bindings/mfd/cros-ec.txt).
|
||||
Documentation/devicetree/bindings/mfd/google,cros-ec.yaml).
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -490,6 +490,14 @@ identifiers: *[ function/type ...]*
|
|||
.. kernel-doc:: lib/idr.c
|
||||
:identifiers:
|
||||
|
||||
no-identifiers: *[ function/type ...]*
|
||||
Exclude documentation for each *function* and *type* in *source*.
|
||||
|
||||
Example::
|
||||
|
||||
.. kernel-doc:: lib/bitmap.c
|
||||
:no-identifiers: bitmap_parselist
|
||||
|
||||
functions: *[ function/type ...]*
|
||||
This is an alias of the 'identifiers' directive and deprecated.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,6 +12,8 @@ Driver device table
|
|||
|
||||
.. kernel-doc:: include/linux/mod_devicetable.h
|
||||
:internal:
|
||||
:no-identifiers: pci_device_id
|
||||
|
||||
|
||||
Delaying, scheduling, and timer routines
|
||||
----------------------------------------
|
||||
|
|
@ -55,15 +57,6 @@ High-resolution timers
|
|||
.. kernel-doc:: kernel/time/hrtimer.c
|
||||
:export:
|
||||
|
||||
Workqueues and Kevents
|
||||
----------------------
|
||||
|
||||
.. kernel-doc:: include/linux/workqueue.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: kernel/workqueue.c
|
||||
:export:
|
||||
|
||||
Internal Functions
|
||||
------------------
|
||||
|
||||
|
|
@ -105,19 +98,15 @@ Kernel utility functions
|
|||
|
||||
.. kernel-doc:: include/linux/kernel.h
|
||||
:internal:
|
||||
:no-identifiers: kstrtol kstrtoul
|
||||
|
||||
.. kernel-doc:: kernel/printk/printk.c
|
||||
:export:
|
||||
:no-identifiers: printk
|
||||
|
||||
.. kernel-doc:: kernel/panic.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: kernel/rcu/tree.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: kernel/rcu/update.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/linux/overflow.h
|
||||
:internal:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,3 @@
|
|||
.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain <dev_pm_domain>`
|
||||
.. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain <generic_pm_domain>`
|
||||
|
||||
|
||||
.. _device_link:
|
||||
|
||||
============
|
||||
|
|
@ -166,7 +162,7 @@ Examples
|
|||
is the same as if the MMU was the parent of the master device.
|
||||
|
||||
The fact that both devices share the same power domain would normally
|
||||
suggest usage of a |struct dev_pm_domain| or |struct generic_pm_domain|,
|
||||
suggest usage of a struct dev_pm_domain or struct generic_pm_domain,
|
||||
however these are not independent devices that happen to share a power
|
||||
switch, but rather the MMU device serves the busmaster device and is
|
||||
useless without it. A device link creates a synthetic hierarchical
|
||||
|
|
@ -202,7 +198,7 @@ Examples
|
|||
Alternatives
|
||||
============
|
||||
|
||||
* A |struct dev_pm_domain| can be used to override the bus,
|
||||
* A struct dev_pm_domain can be used to override the bus,
|
||||
class or device type callbacks. It is intended for devices sharing
|
||||
a single on/off switch, however it does not guarantee a specific
|
||||
suspend/resume ordering, this needs to be implemented separately.
|
||||
|
|
@ -211,7 +207,7 @@ Alternatives
|
|||
suspended. Furthermore it cannot be used to enforce a specific shutdown
|
||||
ordering or a driver presence dependency.
|
||||
|
||||
* A |struct generic_pm_domain| is a lot more heavyweight than a
|
||||
* A struct generic_pm_domain is a lot more heavyweight than a
|
||||
device link and does not allow for shutdown ordering or driver presence
|
||||
dependencies. It also cannot be used on ACPI systems.
|
||||
|
||||
|
|
@ -321,5 +317,4 @@ State machine
|
|||
API
|
||||
===
|
||||
|
||||
.. kernel-doc:: drivers/base/core.c
|
||||
:functions: device_link_add device_link_del device_link_remove
|
||||
See device_link_add(), device_link_del() and device_link_remove().
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@ FPGA Bridge
|
|||
API to implement a new FPGA bridge
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* struct :c:type:`fpga_bridge` — The FPGA Bridge structure
|
||||
* struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops
|
||||
* struct fpga_bridge — The FPGA Bridge structure
|
||||
* struct fpga_bridge_ops — Low level Bridge driver ops
|
||||
* devm_fpga_bridge_create() — Allocate and init a bridge struct
|
||||
* fpga_bridge_register() — Register a bridge
|
||||
* fpga_bridge_unregister() — Unregister a bridge
|
||||
|
|
|
|||
|
|
@ -101,9 +101,9 @@ in state.
|
|||
API for implementing a new FPGA Manager driver
|
||||
----------------------------------------------
|
||||
|
||||
* ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`.
|
||||
* struct :c:type:`fpga_manager` — the FPGA manager struct
|
||||
* struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops
|
||||
* ``fpga_mgr_states`` — Values for :c:expr:`fpga_manager->state`.
|
||||
* struct fpga_manager — the FPGA manager struct
|
||||
* struct fpga_manager_ops — Low level FPGA manager driver ops
|
||||
* devm_fpga_mgr_create() — Allocate and init a manager struct
|
||||
* fpga_mgr_register() — Register an FPGA manager
|
||||
* fpga_mgr_unregister() — Unregister an FPGA manager
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ the FPGA manager and bridges. It will:
|
|||
* lock the mutex of the region's FPGA manager
|
||||
* build a list of FPGA bridges if a method has been specified to do so
|
||||
* disable the bridges
|
||||
* program the FPGA using info passed in :c:member:`fpga_region->info`.
|
||||
* program the FPGA using info passed in :c:expr:`fpga_region->info`.
|
||||
* re-enable the bridges
|
||||
* release the locks
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ An example of usage can be seen in the probe function of [#f2]_.
|
|||
API to add a new FPGA region
|
||||
----------------------------
|
||||
|
||||
* struct :c:type:`fpga_region` — The FPGA region struct
|
||||
* struct fpga_region — The FPGA region struct
|
||||
* devm_fpga_region_create() — Allocate and init a region struct
|
||||
* fpga_region_register() — Register an FPGA region
|
||||
* fpga_region_unregister() — Unregister an FPGA region
|
||||
|
|
@ -61,9 +61,9 @@ during the region's probe function.
|
|||
|
||||
The FPGA region will need to specify which bridges to control while programming
|
||||
the FPGA. The region driver can build a list of bridges during probe time
|
||||
(:c:member:`fpga_region->bridge_list`) or it can have a function that creates
|
||||
(:c:expr:`fpga_region->bridge_list`) or it can have a function that creates
|
||||
the list of bridges to program just before programming
|
||||
(:c:member:`fpga_region->get_bridges`). The FPGA bridge framework supplies the
|
||||
(:c:expr:`fpga_region->get_bridges`). The FPGA bridge framework supplies the
|
||||
following APIs to handle building or tearing down that list.
|
||||
|
||||
* fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
Buffers
|
||||
=======
|
||||
|
||||
* struct :c:type:`iio_buffer` — general buffer structure
|
||||
* struct iio_buffer — general buffer structure
|
||||
* :c:func:`iio_validate_scan_mask_onehot` — Validates that exactly one channel
|
||||
is selected
|
||||
* :c:func:`iio_buffer_get` — Grab a reference to the buffer
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ applications manipulating sensors. The implementation can be found under
|
|||
Industrial I/O Devices
|
||||
----------------------
|
||||
|
||||
* struct :c:type:`iio_dev` - industrial I/O device
|
||||
* struct iio_dev - industrial I/O device
|
||||
* iio_device_alloc() - allocate an :c:type:`iio_dev` from a driver
|
||||
* iio_device_free() - free an :c:type:`iio_dev` from a driver
|
||||
* iio_device_register() - register a device with the IIO subsystem
|
||||
|
|
@ -66,7 +66,7 @@ Common attributes are:
|
|||
IIO device channels
|
||||
===================
|
||||
|
||||
struct :c:type:`iio_chan_spec` - specification of a single channel
|
||||
struct iio_chan_spec - specification of a single channel
|
||||
|
||||
An IIO device channel is a representation of a data channel. An IIO device can
|
||||
have one or multiple channels. For example:
|
||||
|
|
@ -77,7 +77,7 @@ have one or multiple channels. For example:
|
|||
* an accelerometer can have up to 3 channels representing acceleration on X, Y
|
||||
and Z axes.
|
||||
|
||||
An IIO channel is described by the struct :c:type:`iio_chan_spec`.
|
||||
An IIO channel is described by the struct iio_chan_spec.
|
||||
A thermometer driver for the temperature sensor in the example above would
|
||||
have to describe its channel as follows::
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ software buffer for data. The implementation can be found under
|
|||
:file:`drivers/iio/buffer/hw-consumer.c`
|
||||
|
||||
|
||||
* struct :c:type:`iio_hw_consumer` — Hardware consumer structure
|
||||
* struct iio_hw_consumer — Hardware consumer structure
|
||||
* :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer
|
||||
* :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer
|
||||
* :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ IIO triggered buffer setup
|
|||
* :c:func:`iio_triggered_buffer_setup` — Setup triggered buffer and pollfunc
|
||||
* :c:func:`iio_triggered_buffer_cleanup` — Free resources allocated by
|
||||
:c:func:`iio_triggered_buffer_setup`
|
||||
* struct :c:type:`iio_buffer_setup_ops` — buffer setup related callbacks
|
||||
* struct iio_buffer_setup_ops — buffer setup related callbacks
|
||||
|
||||
A typical triggered buffer setup looks like this::
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
Triggers
|
||||
========
|
||||
|
||||
* struct :c:type:`iio_trigger` — industrial I/O trigger device
|
||||
* struct iio_trigger — industrial I/O trigger device
|
||||
* :c:func:`devm_iio_trigger_alloc` — Resource-managed iio_trigger_alloc
|
||||
* :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register
|
||||
iio_trigger_unregister
|
||||
|
|
@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
|
|||
IIO trigger ops
|
||||
===============
|
||||
|
||||
* struct :c:type:`iio_trigger_ops` — operations structure for an iio_trigger.
|
||||
* struct iio_trigger_ops — operations structure for an iio_trigger.
|
||||
|
||||
Notice that a trigger has a set of operations attached:
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,6 @@ available subsections can be seen below.
|
|||
component
|
||||
message-based
|
||||
infiniband
|
||||
sound
|
||||
frame-buffer
|
||||
regulator
|
||||
iio/index
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ The Basic Device Driver-Model Structures
|
|||
|
||||
.. kernel-doc:: include/linux/device.h
|
||||
:internal:
|
||||
:no-identifiers: device_link_state
|
||||
|
||||
Device Drivers Base
|
||||
-------------------
|
||||
|
|
@ -28,9 +29,6 @@ Device Drivers Base
|
|||
.. kernel-doc:: drivers/base/node.c
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/base/transport_class.c
|
||||
:export:
|
||||
|
||||
|
|
|
|||
|
|
@ -508,7 +508,7 @@ also complete commands.
|
|||
|
||||
2. ATA_QCFLAG_ACTIVE is cleared from qc->flags.
|
||||
|
||||
3. :c:func:`qc->complete_fn` callback is invoked. If the return value of the
|
||||
3. :c:expr:`qc->complete_fn` callback is invoked. If the return value of the
|
||||
callback is not zero. Completion is short circuited and
|
||||
:c:func:`ata_qc_complete` returns.
|
||||
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ Implementing the Low-Level CEC Adapter
|
|||
The following low-level adapter operations have to be implemented in
|
||||
your driver:
|
||||
|
||||
.. c:type:: struct cec_adap_ops
|
||||
.. c:struct:: cec_adap_ops
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ responsible for tuning the device. It supports multiple algorithms to
|
|||
detect a channel, as defined at enum :c:func:`dvbfe_algo`.
|
||||
|
||||
The algorithm to be used is obtained via ``.get_frontend_algo``. If the driver
|
||||
doesn't fill its field at struct :c:type:`dvb_frontend_ops`, it will default to
|
||||
doesn't fill its field at struct dvb_frontend_ops, it will default to
|
||||
``DVBFE_ALGO_SW``, meaning that the dvb-core will do a zigzag when tuning,
|
||||
e. g. it will try first to use the specified center frequency ``f``,
|
||||
then, it will do ``f`` + |delta|, ``f`` - |delta|, ``f`` + 2 x |delta|,
|
||||
|
|
@ -140,7 +140,7 @@ define a ``.get_frontend_algo`` function that would return ``DVBFE_ALGO_HW``.
|
|||
a third type (``DVBFE_ALGO_CUSTOM``), in order to allow the driver to
|
||||
define its own hardware-assisted algorithm. Very few hardware need to
|
||||
use it nowadays. Using ``DVBFE_ALGO_CUSTOM`` require to provide other
|
||||
function callbacks at struct :c:type:`dvb_frontend_ops`.
|
||||
function callbacks at struct dvb_frontend_ops.
|
||||
|
||||
Attaching frontend driver to the bridge driver
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ pad to a sink pad.
|
|||
Media device
|
||||
^^^^^^^^^^^^
|
||||
|
||||
A media device is represented by a struct :c:type:`media_device`
|
||||
A media device is represented by a struct media_device
|
||||
instance, defined in ``include/media/media-device.h``.
|
||||
Allocation of the structure is handled by the media device driver, usually by
|
||||
embedding the :c:type:`media_device` instance in a larger driver-specific
|
||||
|
|
@ -49,7 +49,7 @@ and unregistered by calling :c:func:`media_device_unregister()`.
|
|||
Entities
|
||||
^^^^^^^^
|
||||
|
||||
Entities are represented by a struct :c:type:`media_entity`
|
||||
Entities are represented by a struct media_entity
|
||||
instance, defined in ``include/media/media-entity.h``. The structure is usually
|
||||
embedded into a higher-level structure, such as
|
||||
:c:type:`v4l2_subdev` or :c:type:`video_device`
|
||||
|
|
@ -67,10 +67,10 @@ Interfaces
|
|||
^^^^^^^^^^
|
||||
|
||||
Interfaces are represented by a
|
||||
struct :c:type:`media_interface` instance, defined in
|
||||
struct media_interface instance, defined in
|
||||
``include/media/media-entity.h``. Currently, only one type of interface is
|
||||
defined: a device node. Such interfaces are represented by a
|
||||
struct :c:type:`media_intf_devnode`.
|
||||
struct media_intf_devnode.
|
||||
|
||||
Drivers initialize and create device node interfaces by calling
|
||||
:c:func:`media_devnode_create()`
|
||||
|
|
@ -79,7 +79,7 @@ and remove them by calling:
|
|||
|
||||
Pads
|
||||
^^^^
|
||||
Pads are represented by a struct :c:type:`media_pad` instance,
|
||||
Pads are represented by a struct media_pad instance,
|
||||
defined in ``include/media/media-entity.h``. Each entity stores its pads in
|
||||
a pads array managed by the entity driver. Drivers usually embed the array in
|
||||
a driver-specific structure.
|
||||
|
|
@ -87,8 +87,8 @@ a driver-specific structure.
|
|||
Pads are identified by their entity and their 0-based index in the pads
|
||||
array.
|
||||
|
||||
Both information are stored in the struct :c:type:`media_pad`,
|
||||
making the struct :c:type:`media_pad` pointer the canonical way
|
||||
Both information are stored in the struct media_pad,
|
||||
making the struct media_pad pointer the canonical way
|
||||
to store and pass link references.
|
||||
|
||||
Pads have flags that describe the pad capabilities and state.
|
||||
|
|
@ -104,7 +104,7 @@ Pads have flags that describe the pad capabilities and state.
|
|||
Links
|
||||
^^^^^
|
||||
|
||||
Links are represented by a struct :c:type:`media_link` instance,
|
||||
Links are represented by a struct media_link instance,
|
||||
defined in ``include/media/media-entity.h``. There are two types of links:
|
||||
|
||||
**1. pad to pad links**:
|
||||
|
|
@ -187,7 +187,7 @@ Use count and power handling
|
|||
|
||||
Due to the wide differences between drivers regarding power management
|
||||
needs, the media controller does not implement power management. However,
|
||||
the struct :c:type:`media_entity` includes a ``use_count``
|
||||
the struct media_entity includes a ``use_count``
|
||||
field that media drivers
|
||||
can use to track the number of users of every entity for power management
|
||||
needs.
|
||||
|
|
@ -213,11 +213,11 @@ prevent link states from being modified during streaming by calling
|
|||
The function will mark all entities connected to the given entity through
|
||||
enabled links, either directly or indirectly, as streaming.
|
||||
|
||||
The struct :c:type:`media_pipeline` instance pointed to by
|
||||
The struct media_pipeline instance pointed to by
|
||||
the pipe argument will be stored in every entity in the pipeline.
|
||||
Drivers should embed the struct :c:type:`media_pipeline`
|
||||
Drivers should embed the struct media_pipeline
|
||||
in higher-level pipeline structures and can then access the
|
||||
pipeline through the struct :c:type:`media_entity`
|
||||
pipeline through the struct media_entity
|
||||
pipe field.
|
||||
|
||||
Calls to :c:func:`media_pipeline_start()` can be nested.
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ V4L2 specification with respect to controls in a central place. And to make
|
|||
life as easy as possible for the driver developer.
|
||||
|
||||
Note that the control framework relies on the presence of a struct
|
||||
:c:type:`v4l2_device` for V4L2 drivers and struct :c:type:`v4l2_subdev` for
|
||||
:c:type:`v4l2_device` for V4L2 drivers and struct v4l2_subdev for
|
||||
sub-device drivers.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ You should also set these fields of :c:type:`video_device`:
|
|||
file operation is called this lock will be taken by the core and released
|
||||
afterwards. See the next section for more details.
|
||||
|
||||
- :c:type:`video_device`->queue: a pointer to the struct :c:type:`vb2_queue`
|
||||
- :c:type:`video_device`->queue: a pointer to the struct vb2_queue
|
||||
associated with this device node.
|
||||
If queue is not ``NULL``, and queue->lock is not ``NULL``, then queue->lock
|
||||
is used for the queuing ioctls (``VIDIOC_REQBUFS``, ``CREATE_BUFS``,
|
||||
|
|
@ -81,7 +81,7 @@ You should also set these fields of :c:type:`video_device`:
|
|||
|
||||
- :c:type:`video_device`->prio: keeps track of the priorities. Used to
|
||||
implement ``VIDIOC_G_PRIORITY`` and ``VIDIOC_S_PRIORITY``.
|
||||
If left to ``NULL``, then it will use the struct :c:type:`v4l2_prio_state`
|
||||
If left to ``NULL``, then it will use the struct v4l2_prio_state
|
||||
in :c:type:`v4l2_device`. If you want to have a separate priority state per
|
||||
(group of) device node(s), then you can point it to your own struct
|
||||
:c:type:`v4l2_prio_state`.
|
||||
|
|
@ -95,7 +95,7 @@ You should also set these fields of :c:type:`video_device`:
|
|||
but it is used by both a raw video PCI device (cx8800) and a MPEG PCI device
|
||||
(cx8802). Since the :c:type:`v4l2_device` cannot be associated with two PCI
|
||||
devices at the same time it is setup without a parent device. But when the
|
||||
struct :c:type:`video_device` is initialized you **do** know which parent
|
||||
struct video_device is initialized you **do** know which parent
|
||||
PCI device to use and so you set ``dev_device`` to the correct PCI device.
|
||||
|
||||
If you use :c:type:`v4l2_ioctl_ops`, then you should set
|
||||
|
|
@ -138,7 +138,7 @@ ioctls and locking
|
|||
------------------
|
||||
|
||||
The V4L core provides optional locking services. The main service is the
|
||||
lock field in struct :c:type:`video_device`, which is a pointer to a mutex.
|
||||
lock field in struct video_device, which is a pointer to a mutex.
|
||||
If you set this pointer, then that will be used by unlocked_ioctl to
|
||||
serialize all ioctls.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
V4L2 device instance
|
||||
--------------------
|
||||
|
||||
Each device instance is represented by a struct :c:type:`v4l2_device`.
|
||||
Each device instance is represented by a struct v4l2_device.
|
||||
Very simple devices can just allocate this struct, but most of the time you
|
||||
would embed this struct inside a larger struct.
|
||||
|
||||
|
|
@ -18,9 +18,9 @@ dev->driver_data field is ``NULL``, it will be linked to
|
|||
|
||||
Drivers that want integration with the media device framework need to set
|
||||
dev->driver_data manually to point to the driver-specific device structure
|
||||
that embed the struct :c:type:`v4l2_device` instance. This is achieved by a
|
||||
that embed the struct v4l2_device instance. This is achieved by a
|
||||
``dev_set_drvdata()`` call before registering the V4L2 device instance.
|
||||
They must also set the struct :c:type:`v4l2_device` mdev field to point to a
|
||||
They must also set the struct v4l2_device mdev field to point to a
|
||||
properly initialized and registered :c:type:`media_device` instance.
|
||||
|
||||
If :c:type:`v4l2_dev <v4l2_device>`\ ->name is empty then it will be set to a
|
||||
|
|
|
|||
|
|
@ -44,18 +44,18 @@ such objects.
|
|||
|
||||
So to summarize:
|
||||
|
||||
- struct :c:type:`v4l2_fh` has two lists: one of the ``subscribed`` events,
|
||||
- struct v4l2_fh has two lists: one of the ``subscribed`` events,
|
||||
and one of the ``available`` events.
|
||||
|
||||
- struct :c:type:`v4l2_subscribed_event` has a ringbuffer of raised
|
||||
- struct v4l2_subscribed_event has a ringbuffer of raised
|
||||
(pending) events of that particular type.
|
||||
|
||||
- If struct :c:type:`v4l2_subscribed_event` is associated with a specific
|
||||
- If struct v4l2_subscribed_event is associated with a specific
|
||||
object, then that object will have an internal list of
|
||||
struct :c:type:`v4l2_subscribed_event` so it knows who subscribed an
|
||||
struct v4l2_subscribed_event so it knows who subscribed an
|
||||
event to that object.
|
||||
|
||||
Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has
|
||||
Furthermore, the internal struct v4l2_subscribed_event has
|
||||
``merge()`` and ``replace()`` callbacks which drivers can set. These
|
||||
callbacks are called when a new event is raised and there is no more room.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,11 +3,11 @@
|
|||
V4L2 File handlers
|
||||
------------------
|
||||
|
||||
struct :c:type:`v4l2_fh` provides a way to easily keep file handle specific
|
||||
struct v4l2_fh provides a way to easily keep file handle specific
|
||||
data that is used by the V4L2 framework.
|
||||
|
||||
.. attention::
|
||||
New drivers must use struct :c:type:`v4l2_fh`
|
||||
New drivers must use struct v4l2_fh
|
||||
since it is also used to implement priority handling
|
||||
(:ref:`VIDIOC_G_PRIORITY`).
|
||||
|
||||
|
|
@ -16,11 +16,11 @@ whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer
|
|||
by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags.
|
||||
This bit is set whenever :c:func:`v4l2_fh_init` is called.
|
||||
|
||||
struct :c:type:`v4l2_fh` is allocated as a part of the driver's own file handle
|
||||
struct v4l2_fh is allocated as a part of the driver's own file handle
|
||||
structure and ``file->private_data`` is set to it in the driver's ``open()``
|
||||
function by the driver.
|
||||
|
||||
In many cases the struct :c:type:`v4l2_fh` will be embedded in a larger
|
||||
In many cases the struct v4l2_fh will be embedded in a larger
|
||||
structure. In that case you should call:
|
||||
|
||||
#) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()``
|
||||
|
|
@ -102,18 +102,18 @@ Below is a short description of the :c:type:`v4l2_fh` functions used:
|
|||
memory can be freed.
|
||||
|
||||
|
||||
If struct :c:type:`v4l2_fh` is not embedded, then you can use these helper functions:
|
||||
If struct v4l2_fh is not embedded, then you can use these helper functions:
|
||||
|
||||
:c:func:`v4l2_fh_open <v4l2_fh_open>`
|
||||
(struct file \*filp)
|
||||
|
||||
- This allocates a struct :c:type:`v4l2_fh`, initializes it and adds it to
|
||||
the struct :c:type:`video_device` associated with the file struct.
|
||||
- This allocates a struct v4l2_fh, initializes it and adds it to
|
||||
the struct video_device associated with the file struct.
|
||||
|
||||
:c:func:`v4l2_fh_release <v4l2_fh_release>`
|
||||
(struct file \*filp)
|
||||
|
||||
- This deletes it from the struct :c:type:`video_device` associated with the
|
||||
- This deletes it from the struct video_device associated with the
|
||||
file struct, uninitialised the :c:type:`v4l2_fh` and frees it.
|
||||
|
||||
These two functions can be plugged into the v4l2_file_operation's ``open()``
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ pads:
|
|||
err = media_entity_pads_init(&sd->entity, npads, pads);
|
||||
|
||||
The pads array must have been previously initialized. There is no need to
|
||||
manually set the struct :c:type:`media_entity` function and name fields, but the
|
||||
manually set the struct media_entity function and name fields, but the
|
||||
revision field must be initialized if needed.
|
||||
|
||||
A reference to the entity will be automatically acquired/released when the
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Because some of the Intel ME features can change the system
|
|||
configuration, the driver by default allows only a privileged
|
||||
user to access it.
|
||||
|
||||
The session is terminated calling :c:func:`close(int fd)`.
|
||||
The session is terminated calling :c:expr:`close(fd)`.
|
||||
|
||||
A code snippet for an application communicating with Intel AMTHI client:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,6 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
.. |struct cpuidle_governor| replace:: :c:type:`struct cpuidle_governor <cpuidle_governor>`
|
||||
.. |struct cpuidle_device| replace:: :c:type:`struct cpuidle_device <cpuidle_device>`
|
||||
.. |struct cpuidle_driver| replace:: :c:type:`struct cpuidle_driver <cpuidle_driver>`
|
||||
.. |struct cpuidle_state| replace:: :c:type:`struct cpuidle_state <cpuidle_state>`
|
||||
|
||||
========================
|
||||
CPU Idle Time Management
|
||||
========================
|
||||
|
|
@ -54,7 +49,7 @@ platform that the Linux kernel can run on. For this reason, data structures
|
|||
operated on by them cannot depend on any hardware architecture or platform
|
||||
design details as well.
|
||||
|
||||
The governor itself is represented by a |struct cpuidle_governor| object
|
||||
The governor itself is represented by a struct cpuidle_governor object
|
||||
containing four callback pointers, :c:member:`enable`, :c:member:`disable`,
|
||||
:c:member:`select`, :c:member:`reflect`, a :c:member:`rating` field described
|
||||
below, and a name (string) used for identifying it.
|
||||
|
|
@ -83,11 +78,11 @@ callbacks:
|
|||
int (*enable) (struct cpuidle_driver *drv, struct cpuidle_device *dev);
|
||||
|
||||
The role of this callback is to prepare the governor for handling the
|
||||
(logical) CPU represented by the |struct cpuidle_device| object pointed
|
||||
to by the ``dev`` argument. The |struct cpuidle_driver| object pointed
|
||||
(logical) CPU represented by the struct cpuidle_device object pointed
|
||||
to by the ``dev`` argument. The struct cpuidle_driver object pointed
|
||||
to by the ``drv`` argument represents the ``CPUIdle`` driver to be used
|
||||
with that CPU (among other things, it should contain the list of
|
||||
|struct cpuidle_state| objects representing idle states that the
|
||||
struct cpuidle_state objects representing idle states that the
|
||||
processor holding the given CPU can be asked to enter).
|
||||
|
||||
It may fail, in which case it is expected to return a negative error
|
||||
|
|
@ -102,7 +97,7 @@ callbacks:
|
|||
void (*disable) (struct cpuidle_driver *drv, struct cpuidle_device *dev);
|
||||
|
||||
Called to make the governor stop handling the (logical) CPU represented
|
||||
by the |struct cpuidle_device| object pointed to by the ``dev``
|
||||
by the struct cpuidle_device object pointed to by the ``dev``
|
||||
argument.
|
||||
|
||||
It is expected to reverse any changes made by the ``->enable()``
|
||||
|
|
@ -116,12 +111,12 @@ callbacks:
|
|||
bool *stop_tick);
|
||||
|
||||
Called to select an idle state for the processor holding the (logical)
|
||||
CPU represented by the |struct cpuidle_device| object pointed to by the
|
||||
CPU represented by the struct cpuidle_device object pointed to by the
|
||||
``dev`` argument.
|
||||
|
||||
The list of idle states to take into consideration is represented by the
|
||||
:c:member:`states` array of |struct cpuidle_state| objects held by the
|
||||
|struct cpuidle_driver| object pointed to by the ``drv`` argument (which
|
||||
:c:member:`states` array of struct cpuidle_state objects held by the
|
||||
struct cpuidle_driver object pointed to by the ``drv`` argument (which
|
||||
represents the ``CPUIdle`` driver to be used with the CPU at hand). The
|
||||
value returned by this callback is interpreted as an index into that
|
||||
array (unless it is a negative error code).
|
||||
|
|
@ -136,7 +131,7 @@ callbacks:
|
|||
asking the processor to enter the idle state).
|
||||
|
||||
This callback is mandatory (i.e. the :c:member:`select` callback pointer
|
||||
in |struct cpuidle_governor| must not be ``NULL`` for the registration
|
||||
in struct cpuidle_governor must not be ``NULL`` for the registration
|
||||
of the governor to succeed).
|
||||
|
||||
:c:member:`reflect`
|
||||
|
|
@ -167,21 +162,21 @@ CPU idle time management (``CPUIdle``) drivers provide an interface between the
|
|||
other parts of ``CPUIdle`` and the hardware.
|
||||
|
||||
First of all, a ``CPUIdle`` driver has to populate the :c:member:`states` array
|
||||
of |struct cpuidle_state| objects included in the |struct cpuidle_driver| object
|
||||
of struct cpuidle_state objects included in the struct cpuidle_driver object
|
||||
representing it. Going forward this array will represent the list of available
|
||||
idle states that the processor hardware can be asked to enter shared by all of
|
||||
the logical CPUs handled by the given driver.
|
||||
|
||||
The entries in the :c:member:`states` array are expected to be sorted by the
|
||||
value of the :c:member:`target_residency` field in |struct cpuidle_state| in
|
||||
value of the :c:member:`target_residency` field in struct cpuidle_state in
|
||||
the ascending order (that is, index 0 should correspond to the idle state with
|
||||
the minimum value of :c:member:`target_residency`). [Since the
|
||||
:c:member:`target_residency` value is expected to reflect the "depth" of the
|
||||
idle state represented by the |struct cpuidle_state| object holding it, this
|
||||
idle state represented by the struct cpuidle_state object holding it, this
|
||||
sorting order should be the same as the ascending sorting order by the idle
|
||||
state "depth".]
|
||||
|
||||
Three fields in |struct cpuidle_state| are used by the existing ``CPUIdle``
|
||||
Three fields in struct cpuidle_state are used by the existing ``CPUIdle``
|
||||
governors for computations related to idle state selection:
|
||||
|
||||
:c:member:`target_residency`
|
||||
|
|
@ -203,7 +198,7 @@ governors for computations related to idle state selection:
|
|||
any idle state at all. [There are other flags used by the ``CPUIdle``
|
||||
core in special situations.]
|
||||
|
||||
The :c:member:`enter` callback pointer in |struct cpuidle_state|, which must not
|
||||
The :c:member:`enter` callback pointer in struct cpuidle_state, which must not
|
||||
be ``NULL``, points to the routine to execute in order to ask the processor to
|
||||
enter this particular idle state:
|
||||
|
||||
|
|
@ -212,14 +207,14 @@ enter this particular idle state:
|
|||
void (*enter) (struct cpuidle_device *dev, struct cpuidle_driver *drv,
|
||||
int index);
|
||||
|
||||
The first two arguments of it point to the |struct cpuidle_device| object
|
||||
The first two arguments of it point to the struct cpuidle_device object
|
||||
representing the logical CPU running this callback and the
|
||||
|struct cpuidle_driver| object representing the driver itself, respectively,
|
||||
and the last one is an index of the |struct cpuidle_state| entry in the driver's
|
||||
struct cpuidle_driver object representing the driver itself, respectively,
|
||||
and the last one is an index of the struct cpuidle_state entry in the driver's
|
||||
:c:member:`states` array representing the idle state to ask the processor to
|
||||
enter.
|
||||
|
||||
The analogous ``->enter_s2idle()`` callback in |struct cpuidle_state| is used
|
||||
The analogous ``->enter_s2idle()`` callback in struct cpuidle_state is used
|
||||
only for implementing the suspend-to-idle system-wide power management feature.
|
||||
The difference between in and ``->enter()`` is that it must not re-enable
|
||||
interrupts at any point (even temporarily) or attempt to change the states of
|
||||
|
|
@ -227,48 +222,48 @@ clock event devices, which the ``->enter()`` callback may do sometimes.
|
|||
|
||||
Once the :c:member:`states` array has been populated, the number of valid
|
||||
entries in it has to be stored in the :c:member:`state_count` field of the
|
||||
|struct cpuidle_driver| object representing the driver. Moreover, if any
|
||||
struct cpuidle_driver object representing the driver. Moreover, if any
|
||||
entries in the :c:member:`states` array represent "coupled" idle states (that
|
||||
is, idle states that can only be asked for if multiple related logical CPUs are
|
||||
idle), the :c:member:`safe_state_index` field in |struct cpuidle_driver| needs
|
||||
idle), the :c:member:`safe_state_index` field in struct cpuidle_driver needs
|
||||
to be the index of an idle state that is not "coupled" (that is, one that can be
|
||||
asked for if only one logical CPU is idle).
|
||||
|
||||
In addition to that, if the given ``CPUIdle`` driver is only going to handle a
|
||||
subset of logical CPUs in the system, the :c:member:`cpumask` field in its
|
||||
|struct cpuidle_driver| object must point to the set (mask) of CPUs that will be
|
||||
struct cpuidle_driver object must point to the set (mask) of CPUs that will be
|
||||
handled by it.
|
||||
|
||||
A ``CPUIdle`` driver can only be used after it has been registered. If there
|
||||
are no "coupled" idle state entries in the driver's :c:member:`states` array,
|
||||
that can be accomplished by passing the driver's |struct cpuidle_driver| object
|
||||
that can be accomplished by passing the driver's struct cpuidle_driver object
|
||||
to :c:func:`cpuidle_register_driver()`. Otherwise, :c:func:`cpuidle_register()`
|
||||
should be used for this purpose.
|
||||
|
||||
However, it also is necessary to register |struct cpuidle_device| objects for
|
||||
However, it also is necessary to register struct cpuidle_device objects for
|
||||
all of the logical CPUs to be handled by the given ``CPUIdle`` driver with the
|
||||
help of :c:func:`cpuidle_register_device()` after the driver has been registered
|
||||
and :c:func:`cpuidle_register_driver()`, unlike :c:func:`cpuidle_register()`,
|
||||
does not do that automatically. For this reason, the drivers that use
|
||||
:c:func:`cpuidle_register_driver()` to register themselves must also take care
|
||||
of registering the |struct cpuidle_device| objects as needed, so it is generally
|
||||
of registering the struct cpuidle_device objects as needed, so it is generally
|
||||
recommended to use :c:func:`cpuidle_register()` for ``CPUIdle`` driver
|
||||
registration in all cases.
|
||||
|
||||
The registration of a |struct cpuidle_device| object causes the ``CPUIdle``
|
||||
The registration of a struct cpuidle_device object causes the ``CPUIdle``
|
||||
``sysfs`` interface to be created and the governor's ``->enable()`` callback to
|
||||
be invoked for the logical CPU represented by it, so it must take place after
|
||||
registering the driver that will handle the CPU in question.
|
||||
|
||||
``CPUIdle`` drivers and |struct cpuidle_device| objects can be unregistered
|
||||
``CPUIdle`` drivers and struct cpuidle_device objects can be unregistered
|
||||
when they are not necessary any more which allows some resources associated with
|
||||
them to be released. Due to dependencies between them, all of the
|
||||
|struct cpuidle_device| objects representing CPUs handled by the given
|
||||
struct cpuidle_device objects representing CPUs handled by the given
|
||||
``CPUIdle`` driver must be unregistered, with the help of
|
||||
:c:func:`cpuidle_unregister_device()`, before calling
|
||||
:c:func:`cpuidle_unregister_driver()` to unregister the driver. Alternatively,
|
||||
:c:func:`cpuidle_unregister()` can be called to unregister a ``CPUIdle`` driver
|
||||
along with all of the |struct cpuidle_device| objects representing CPUs handled
|
||||
along with all of the struct cpuidle_device objects representing CPUs handled
|
||||
by it.
|
||||
|
||||
``CPUIdle`` drivers can respond to runtime system configuration changes that
|
||||
|
|
@ -277,8 +272,8 @@ happen, for example, when the system's power source is switched from AC to
|
|||
battery or the other way around). Upon a notification of such a change,
|
||||
a ``CPUIdle`` driver is expected to call :c:func:`cpuidle_pause_and_lock()` to
|
||||
turn ``CPUIdle`` off temporarily and then :c:func:`cpuidle_disable_device()` for
|
||||
all of the |struct cpuidle_device| objects representing CPUs affected by that
|
||||
all of the struct cpuidle_device objects representing CPUs affected by that
|
||||
change. Next, it can update its :c:member:`states` array in accordance with
|
||||
the new configuration of the system, call :c:func:`cpuidle_enable_device()` for
|
||||
all of the relevant |struct cpuidle_device| objects and invoke
|
||||
all of the relevant struct cpuidle_device objects and invoke
|
||||
:c:func:`cpuidle_resume_and_unlock()` to allow ``CPUIdle`` to be used again.
|
||||
|
|
|
|||
|
|
@ -1,14 +1,6 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
.. |struct dev_pm_ops| replace:: :c:type:`struct dev_pm_ops <dev_pm_ops>`
|
||||
.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain <dev_pm_domain>`
|
||||
.. |struct bus_type| replace:: :c:type:`struct bus_type <bus_type>`
|
||||
.. |struct device_type| replace:: :c:type:`struct device_type <device_type>`
|
||||
.. |struct class| replace:: :c:type:`struct class <class>`
|
||||
.. |struct wakeup_source| replace:: :c:type:`struct wakeup_source <wakeup_source>`
|
||||
.. |struct device| replace:: :c:type:`struct device <device>`
|
||||
|
||||
.. _driverapi_pm_devices:
|
||||
|
||||
==============================
|
||||
|
|
@ -107,7 +99,7 @@ Device Power Management Operations
|
|||
|
||||
Device power management operations, at the subsystem level as well as at the
|
||||
device driver level, are implemented by defining and populating objects of type
|
||||
|struct dev_pm_ops| defined in :file:`include/linux/pm.h`. The roles of the
|
||||
struct dev_pm_ops defined in :file:`include/linux/pm.h`. The roles of the
|
||||
methods included in it will be explained in what follows. For now, it should be
|
||||
sufficient to remember that the last three methods are specific to runtime power
|
||||
management while the remaining ones are used during system-wide power
|
||||
|
|
@ -115,7 +107,7 @@ transitions.
|
|||
|
||||
There also is a deprecated "old" or "legacy" interface for power management
|
||||
operations available at least for some subsystems. This approach does not use
|
||||
|struct dev_pm_ops| objects and it is suitable only for implementing system
|
||||
struct dev_pm_ops objects and it is suitable only for implementing system
|
||||
sleep power management methods in a limited way. Therefore it is not described
|
||||
in this document, so please refer directly to the source code for more
|
||||
information about it.
|
||||
|
|
@ -125,9 +117,9 @@ Subsystem-Level Methods
|
|||
-----------------------
|
||||
|
||||
The core methods to suspend and resume devices reside in
|
||||
|struct dev_pm_ops| pointed to by the :c:member:`ops` member of
|
||||
|struct dev_pm_domain|, or by the :c:member:`pm` member of |struct bus_type|,
|
||||
|struct device_type| and |struct class|. They are mostly of interest to the
|
||||
struct dev_pm_ops pointed to by the :c:member:`ops` member of
|
||||
struct dev_pm_domain, or by the :c:member:`pm` member of struct bus_type,
|
||||
struct device_type and struct class. They are mostly of interest to the
|
||||
people writing infrastructure for platforms and buses, like PCI or USB, or
|
||||
device type and device class drivers. They also are relevant to the writers of
|
||||
device drivers whose subsystems (PM domains, device types, device classes and
|
||||
|
|
@ -156,7 +148,7 @@ The :c:member:`power.can_wakeup` flag just records whether the device (and its
|
|||
driver) can physically support wakeup events. The
|
||||
:c:func:`device_set_wakeup_capable()` routine affects this flag. The
|
||||
:c:member:`power.wakeup` field is a pointer to an object of type
|
||||
|struct wakeup_source| used for controlling whether or not the device should use
|
||||
struct wakeup_source used for controlling whether or not the device should use
|
||||
its system wakeup mechanism and for notifying the PM core of system wakeup
|
||||
events signaled by the device. This object is only present for wakeup-capable
|
||||
devices (i.e. devices whose :c:member:`can_wakeup` flags are set) and is created
|
||||
|
|
@ -418,7 +410,7 @@ On many platforms they will gate off one or more clock sources; sometimes they
|
|||
will also switch off power supplies or reduce voltages. [Drivers supporting
|
||||
runtime PM may already have performed some or all of these steps.]
|
||||
|
||||
If :c:func:`device_may_wakeup(dev)` returns ``true``, the device should be
|
||||
If :c:func:`device_may_wakeup()` returns ``true``, the device should be
|
||||
prepared for generating hardware wakeup signals to trigger a system wakeup event
|
||||
when the system is in the sleep state. For example, :c:func:`enable_irq_wake()`
|
||||
might identify GPIO signals hooked up to a switch or other external hardware,
|
||||
|
|
@ -713,8 +705,8 @@ nested inside another power domain. The nested domain is referred to as the
|
|||
sub-domain of the parent domain.
|
||||
|
||||
Support for power domains is provided through the :c:member:`pm_domain` field of
|
||||
|struct device|. This field is a pointer to an object of type
|
||||
|struct dev_pm_domain|, defined in :file:`include/linux/pm.h`, providing a set
|
||||
struct device. This field is a pointer to an object of type
|
||||
struct dev_pm_domain, defined in :file:`include/linux/pm.h`, providing a set
|
||||
of power management callbacks analogous to the subsystem-level and device driver
|
||||
callbacks that are executed for the given device during all power transitions,
|
||||
instead of the respective subsystem-level callbacks. Specifically, if a
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ core, providing operations structures to the core. A notifier interface
|
|||
allows error conditions to be reported to the core.
|
||||
|
||||
Registration should be triggered by explicit setup done by the platform,
|
||||
supplying a struct :c:type:`regulator_init_data` for the regulator
|
||||
supplying a struct regulator_init_data for the regulator
|
||||
containing constraint and supply information.
|
||||
|
||||
Machine interface
|
||||
|
|
@ -144,7 +144,7 @@ a given system, for example supporting higher supply voltages than the
|
|||
consumers are rated for.
|
||||
|
||||
This is done at driver registration time` by providing a
|
||||
struct :c:type:`regulation_constraints`.
|
||||
struct regulation_constraints.
|
||||
|
||||
The constraints may also specify an initial configuration for the
|
||||
regulator in the constraints, which is particularly useful for use with
|
||||
|
|
|
|||
|
|
@ -1,54 +0,0 @@
|
|||
Sound Devices
|
||||
=============
|
||||
|
||||
.. kernel-doc:: include/sound/core.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: sound/sound_core.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/sound/pcm.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: sound/core/pcm.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/device.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/info.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/rawmidi.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/sound.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/memory.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/pcm_memory.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/init.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/isadma.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/control.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/pcm_lib.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/hwdep.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/pcm_native.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: sound/core/memalloc.c
|
||||
:export:
|
||||
|
||||
|
|
@ -41,18 +41,6 @@ iSCSI boot information
|
|||
.. kernel-doc:: drivers/scsi/iscsi_boot_sysfs.c
|
||||
:export:
|
||||
|
||||
|
||||
iSCSI transport class
|
||||
=====================
|
||||
|
||||
The file drivers/scsi/scsi_transport_iscsi.c defines transport
|
||||
attributes for the iSCSI class, which sends SCSI packets over TCP/IP
|
||||
connections.
|
||||
|
||||
.. kernel-doc:: drivers/scsi/scsi_transport_iscsi.c
|
||||
:export:
|
||||
|
||||
|
||||
iSCSI TCP interfaces
|
||||
====================
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ called USB Request Block, or URB for short.
|
|||
The URB structure
|
||||
=================
|
||||
|
||||
Some of the fields in struct :c:type:`urb` are::
|
||||
Some of the fields in struct urb are::
|
||||
|
||||
struct urb
|
||||
{
|
||||
|
|
|
|||
|
|
@ -176,9 +176,9 @@ Kernel Mode Gadget API
|
|||
|
||||
Gadget drivers declare themselves through a struct
|
||||
:c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration
|
||||
for a struct :c:type:`usb_gadget`. The response to a set_configuration usually
|
||||
involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by
|
||||
the gadget, and submitting one or more struct :c:type:`usb_request` buffers to
|
||||
for a struct usb_gadget. The response to a set_configuration usually
|
||||
involves enabling one or more of the struct usb_ep objects exposed by
|
||||
the gadget, and submitting one or more struct usb_request buffers to
|
||||
transfer data. Understand those four data types, and their operations,
|
||||
and you will understand how this API works.
|
||||
|
||||
|
|
@ -339,8 +339,8 @@ multi-configuration devices (also more than one function, but not
|
|||
necessarily sharing a given configuration). There is however an optional
|
||||
framework which makes it easier to reuse and combine functions.
|
||||
|
||||
Devices using this framework provide a struct :c:type:`usb_composite_driver`,
|
||||
which in turn provides one or more struct :c:type:`usb_configuration`
|
||||
Devices using this framework provide a struct usb_composite_driver,
|
||||
which in turn provides one or more struct usb_configuration
|
||||
instances. Each such configuration includes at least one struct
|
||||
:c:type:`usb_function`, which packages a user visible role such as "network
|
||||
link" or "mass storage device". Management functions may also exist,
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ and their quirks, might have a MODULE_DEVICE_TABLE like this::
|
|||
Most USB device drivers should pass these tables to the USB subsystem as
|
||||
well as to the module management subsystem. Not all, though: some driver
|
||||
frameworks connect using interfaces layered over USB, and so they won't
|
||||
need such a struct :c:type:`usb_driver`.
|
||||
need such a struct usb_driver.
|
||||
|
||||
Drivers that connect directly to the USB subsystem should be declared
|
||||
something like this::
|
||||
|
|
|
|||
|
|
@ -91,10 +91,16 @@ their control.
|
|||
Driver API
|
||||
----------
|
||||
|
||||
Alternate mode structs
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: include/linux/usb/typec_altmode.h
|
||||
:functions: typec_altmode_driver typec_altmode_ops
|
||||
|
||||
Alternate mode driver registering/unregistering
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: drivers/usb/typec/bus.c
|
||||
.. kernel-doc:: include/linux/usb/typec_altmode.h
|
||||
:functions: typec_altmode_register_driver typec_altmode_unregister_driver
|
||||
|
||||
Alternate mode driver operations
|
||||
|
|
|
|||
|
|
@ -436,9 +436,9 @@ FS_IOC_SET_ENCRYPTION_POLICY
|
|||
|
||||
The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an
|
||||
empty directory or verifies that a directory or regular file already
|
||||
has the specified encryption policy. It takes in a pointer to a
|
||||
:c:type:`struct fscrypt_policy_v1` or a :c:type:`struct
|
||||
fscrypt_policy_v2`, defined as follows::
|
||||
has the specified encryption policy. It takes in a pointer to
|
||||
struct fscrypt_policy_v1 or struct fscrypt_policy_v2, defined as
|
||||
follows::
|
||||
|
||||
#define FSCRYPT_POLICY_V1 0
|
||||
#define FSCRYPT_KEY_DESCRIPTOR_SIZE 8
|
||||
|
|
@ -464,11 +464,11 @@ fscrypt_policy_v2`, defined as follows::
|
|||
|
||||
This structure must be initialized as follows:
|
||||
|
||||
- ``version`` must be FSCRYPT_POLICY_V1 (0) if the struct is
|
||||
:c:type:`fscrypt_policy_v1` or FSCRYPT_POLICY_V2 (2) if the struct
|
||||
is :c:type:`fscrypt_policy_v2`. (Note: we refer to the original
|
||||
policy version as "v1", though its version code is really 0.) For
|
||||
new encrypted directories, use v2 policies.
|
||||
- ``version`` must be FSCRYPT_POLICY_V1 (0) if
|
||||
struct fscrypt_policy_v1 is used or FSCRYPT_POLICY_V2 (2) if
|
||||
struct fscrypt_policy_v2 is used. (Note: we refer to the original
|
||||
policy version as "v1", though its version code is really 0.)
|
||||
For new encrypted directories, use v2 policies.
|
||||
|
||||
- ``contents_encryption_mode`` and ``filenames_encryption_mode`` must
|
||||
be set to constants from ``<linux/fscrypt.h>`` which identify the
|
||||
|
|
@ -508,9 +508,9 @@ This structure must be initialized as follows:
|
|||
replaced with ``master_key_identifier``, which is longer and cannot
|
||||
be arbitrarily chosen. Instead, the key must first be added using
|
||||
`FS_IOC_ADD_ENCRYPTION_KEY`_. Then, the ``key_spec.u.identifier``
|
||||
the kernel returned in the :c:type:`struct fscrypt_add_key_arg` must
|
||||
be used as the ``master_key_identifier`` in the :c:type:`struct
|
||||
fscrypt_policy_v2`.
|
||||
the kernel returned in the struct fscrypt_add_key_arg must
|
||||
be used as the ``master_key_identifier`` in
|
||||
struct fscrypt_policy_v2.
|
||||
|
||||
If the file is not yet encrypted, then FS_IOC_SET_ENCRYPTION_POLICY
|
||||
verifies that the file is an empty directory. If so, the specified
|
||||
|
|
@ -590,7 +590,7 @@ FS_IOC_GET_ENCRYPTION_POLICY_EX
|
|||
The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption
|
||||
policy, if any, for a directory or regular file. No additional
|
||||
permissions are required beyond the ability to open the file. It
|
||||
takes in a pointer to a :c:type:`struct fscrypt_get_policy_ex_arg`,
|
||||
takes in a pointer to struct fscrypt_get_policy_ex_arg,
|
||||
defined as follows::
|
||||
|
||||
struct fscrypt_get_policy_ex_arg {
|
||||
|
|
@ -637,9 +637,8 @@ The FS_IOC_GET_ENCRYPTION_POLICY ioctl can also retrieve the
|
|||
encryption policy, if any, for a directory or regular file. However,
|
||||
unlike `FS_IOC_GET_ENCRYPTION_POLICY_EX`_,
|
||||
FS_IOC_GET_ENCRYPTION_POLICY only supports the original policy
|
||||
version. It takes in a pointer directly to a :c:type:`struct
|
||||
fscrypt_policy_v1` rather than a :c:type:`struct
|
||||
fscrypt_get_policy_ex_arg`.
|
||||
version. It takes in a pointer directly to struct fscrypt_policy_v1
|
||||
rather than struct fscrypt_get_policy_ex_arg.
|
||||
|
||||
The error codes for FS_IOC_GET_ENCRYPTION_POLICY are the same as those
|
||||
for FS_IOC_GET_ENCRYPTION_POLICY_EX, except that
|
||||
|
|
@ -680,8 +679,7 @@ the filesystem, making all files on the filesystem which were
|
|||
encrypted using that key appear "unlocked", i.e. in plaintext form.
|
||||
It can be executed on any file or directory on the target filesystem,
|
||||
but using the filesystem's root directory is recommended. It takes in
|
||||
a pointer to a :c:type:`struct fscrypt_add_key_arg`, defined as
|
||||
follows::
|
||||
a pointer to struct fscrypt_add_key_arg, defined as follows::
|
||||
|
||||
struct fscrypt_add_key_arg {
|
||||
struct fscrypt_key_specifier key_spec;
|
||||
|
|
@ -710,17 +708,16 @@ follows::
|
|||
__u8 raw[];
|
||||
};
|
||||
|
||||
:c:type:`struct fscrypt_add_key_arg` must be zeroed, then initialized
|
||||
struct fscrypt_add_key_arg must be zeroed, then initialized
|
||||
as follows:
|
||||
|
||||
- If the key is being added for use by v1 encryption policies, then
|
||||
``key_spec.type`` must contain FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR, and
|
||||
``key_spec.u.descriptor`` must contain the descriptor of the key
|
||||
being added, corresponding to the value in the
|
||||
``master_key_descriptor`` field of :c:type:`struct
|
||||
fscrypt_policy_v1`. To add this type of key, the calling process
|
||||
must have the CAP_SYS_ADMIN capability in the initial user
|
||||
namespace.
|
||||
``master_key_descriptor`` field of struct fscrypt_policy_v1.
|
||||
To add this type of key, the calling process must have the
|
||||
CAP_SYS_ADMIN capability in the initial user namespace.
|
||||
|
||||
Alternatively, if the key is being added for use by v2 encryption
|
||||
policies, then ``key_spec.type`` must contain
|
||||
|
|
@ -737,12 +734,13 @@ as follows:
|
|||
|
||||
- ``key_id`` is 0 if the raw key is given directly in the ``raw``
|
||||
field. Otherwise ``key_id`` is the ID of a Linux keyring key of
|
||||
type "fscrypt-provisioning" whose payload is a :c:type:`struct
|
||||
fscrypt_provisioning_key_payload` whose ``raw`` field contains the
|
||||
raw key and whose ``type`` field matches ``key_spec.type``. Since
|
||||
``raw`` is variable-length, the total size of this key's payload
|
||||
must be ``sizeof(struct fscrypt_provisioning_key_payload)`` plus the
|
||||
raw key size. The process must have Search permission on this key.
|
||||
type "fscrypt-provisioning" whose payload is
|
||||
struct fscrypt_provisioning_key_payload whose ``raw`` field contains
|
||||
the raw key and whose ``type`` field matches ``key_spec.type``.
|
||||
Since ``raw`` is variable-length, the total size of this key's
|
||||
payload must be ``sizeof(struct fscrypt_provisioning_key_payload)``
|
||||
plus the raw key size. The process must have Search permission on
|
||||
this key.
|
||||
|
||||
Most users should leave this 0 and specify the raw key directly.
|
||||
The support for specifying a Linux keyring key is intended mainly to
|
||||
|
|
@ -860,8 +858,8 @@ The FS_IOC_REMOVE_ENCRYPTION_KEY ioctl removes a claim to a master
|
|||
encryption key from the filesystem, and possibly removes the key
|
||||
itself. It can be executed on any file or directory on the target
|
||||
filesystem, but using the filesystem's root directory is recommended.
|
||||
It takes in a pointer to a :c:type:`struct fscrypt_remove_key_arg`,
|
||||
defined as follows::
|
||||
It takes in a pointer to struct fscrypt_remove_key_arg, defined
|
||||
as follows::
|
||||
|
||||
struct fscrypt_remove_key_arg {
|
||||
struct fscrypt_key_specifier key_spec;
|
||||
|
|
@ -956,8 +954,8 @@ FS_IOC_GET_ENCRYPTION_KEY_STATUS
|
|||
The FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl retrieves the status of a
|
||||
master encryption key. It can be executed on any file or directory on
|
||||
the target filesystem, but using the filesystem's root directory is
|
||||
recommended. It takes in a pointer to a :c:type:`struct
|
||||
fscrypt_get_key_status_arg`, defined as follows::
|
||||
recommended. It takes in a pointer to
|
||||
struct fscrypt_get_key_status_arg, defined as follows::
|
||||
|
||||
struct fscrypt_get_key_status_arg {
|
||||
/* input */
|
||||
|
|
@ -1148,10 +1146,10 @@ Implementation details
|
|||
Encryption context
|
||||
------------------
|
||||
|
||||
An encryption policy is represented on-disk by a :c:type:`struct
|
||||
fscrypt_context_v1` or a :c:type:`struct fscrypt_context_v2`. It is
|
||||
up to individual filesystems to decide where to store it, but normally
|
||||
it would be stored in a hidden extended attribute. It should *not* be
|
||||
An encryption policy is represented on-disk by
|
||||
struct fscrypt_context_v1 or struct fscrypt_context_v2. It is up to
|
||||
individual filesystems to decide where to store it, but normally it
|
||||
would be stored in a hidden extended attribute. It should *not* be
|
||||
exposed by the xattr-related system calls such as getxattr() and
|
||||
setxattr() because of the special semantics of the encryption xattr.
|
||||
(In particular, there would be much confusion if an encryption policy
|
||||
|
|
@ -1249,8 +1247,8 @@ a strong "hash" of the ciphertext filename, along with the optional
|
|||
filesystem-specific hash(es) needed for directory lookups. This
|
||||
allows the filesystem to still, with a high degree of confidence, map
|
||||
the filename given in ->lookup() back to a particular directory entry
|
||||
that was previously listed by readdir(). See :c:type:`struct
|
||||
fscrypt_nokey_name` in the source for more details.
|
||||
that was previously listed by readdir(). See
|
||||
struct fscrypt_nokey_name in the source for more details.
|
||||
|
||||
Note that the precise way that filenames are presented to userspace
|
||||
without the key is subject to change in the future. It is only meant
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ FS_IOC_ENABLE_VERITY
|
|||
--------------------
|
||||
|
||||
The FS_IOC_ENABLE_VERITY ioctl enables fs-verity on a file. It takes
|
||||
in a pointer to a :c:type:`struct fsverity_enable_arg`, defined as
|
||||
in a pointer to a struct fsverity_enable_arg, defined as
|
||||
follows::
|
||||
|
||||
struct fsverity_enable_arg {
|
||||
|
|
|
|||
|
|
@ -636,15 +636,36 @@ i915 Perf Observation Architecture Stream
|
|||
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
||||
:functions: i915_oa_poll_wait
|
||||
|
||||
All i915 Perf Internals
|
||||
-----------------------
|
||||
Other i915 Perf Internals
|
||||
-------------------------
|
||||
|
||||
This section simply includes all currently documented i915 perf internals, in
|
||||
no particular order, but may include some more minor utilities or platform
|
||||
This section simply includes all other currently documented i915 perf internals,
|
||||
in no particular order, but may include some more minor utilities or platform
|
||||
specific details than found in the more high-level sections.
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
||||
:internal:
|
||||
:no-identifiers:
|
||||
i915_perf_init
|
||||
i915_perf_fini
|
||||
i915_perf_register
|
||||
i915_perf_unregister
|
||||
i915_perf_open_ioctl
|
||||
i915_perf_release
|
||||
i915_perf_add_config_ioctl
|
||||
i915_perf_remove_config_ioctl
|
||||
read_properties_unlocked
|
||||
i915_perf_open_ioctl_locked
|
||||
i915_perf_destroy_locked
|
||||
i915_perf_read i915_perf_ioctl
|
||||
i915_perf_enable_locked
|
||||
i915_perf_disable_locked
|
||||
i915_perf_poll i915_perf_poll_locked
|
||||
i915_oa_stream_init i915_oa_read
|
||||
i915_oa_stream_enable
|
||||
i915_oa_stream_disable
|
||||
i915_oa_wait_unlocked
|
||||
i915_oa_poll_wait
|
||||
|
||||
Style
|
||||
=====
|
||||
|
|
|
|||
|
|
@ -26,7 +26,9 @@ The stack is composed of three main parts:
|
|||
Socket API
|
||||
==========
|
||||
|
||||
.. c:function:: int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
|
||||
::
|
||||
|
||||
int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
|
||||
|
||||
The address family, socket addresses etc. are defined in the
|
||||
include/net/af_ieee802154.h header or in the special header
|
||||
|
|
@ -131,12 +133,12 @@ Register PHY in the system.
|
|||
|
||||
Freeing registered PHY.
|
||||
|
||||
.. c:function:: void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb, u8 lqi):
|
||||
.. c:function:: void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb, u8 lqi)
|
||||
|
||||
Telling 802.15.4 module there is a new received frame in the skb with
|
||||
the RF Link Quality Indicator (LQI) from the hardware device.
|
||||
|
||||
.. c:function:: void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb, bool ifs_handling):
|
||||
.. c:function:: void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb, bool ifs_handling)
|
||||
|
||||
Telling 802.15.4 module the frame in the skb is or going to be
|
||||
transmitted through the hardware device
|
||||
|
|
@ -155,25 +157,25 @@ operations structure at least::
|
|||
...
|
||||
};
|
||||
|
||||
.. c:function:: int start(struct ieee802154_hw *hw):
|
||||
.. c:function:: int start(struct ieee802154_hw *hw)
|
||||
|
||||
Handler that 802.15.4 module calls for the hardware device initialization.
|
||||
|
||||
.. c:function:: void stop(struct ieee802154_hw *hw):
|
||||
.. c:function:: void stop(struct ieee802154_hw *hw)
|
||||
|
||||
Handler that 802.15.4 module calls for the hardware device cleanup.
|
||||
|
||||
.. c:function:: int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
|
||||
.. c:function:: int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb)
|
||||
|
||||
Handler that 802.15.4 module calls for each frame in the skb going to be
|
||||
transmitted through the hardware device.
|
||||
|
||||
.. c:function:: int ed(struct ieee802154_hw *hw, u8 *level):
|
||||
.. c:function:: int ed(struct ieee802154_hw *hw, u8 *level)
|
||||
|
||||
Handler that 802.15.4 module calls for Energy Detection from the hardware
|
||||
device.
|
||||
|
||||
.. c:function:: int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
|
||||
.. c:function:: int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel)
|
||||
|
||||
Set radio for listening on specific channel of the hardware device.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,22 +49,22 @@ Register preservation rules
|
|||
Register preservation rules match the ELF ABI calling sequence with the
|
||||
following differences:
|
||||
|
||||
--- For the sc instruction, differences with the ELF ABI ---
|
||||
=========== ============= ========================================
|
||||
r0 Volatile (System call number.)
|
||||
r3 Volatile (Parameter 1, and return value.)
|
||||
r4-r8 Volatile (Parameters 2-6.)
|
||||
cr0 Volatile (cr0.SO is the return error condition.)
|
||||
cr1, cr5-7 Nonvolatile
|
||||
lr Nonvolatile
|
||||
=========== ============= ========================================
|
||||
|
||||
--- For the scv 0 instruction, differences with the ELF ABI ---
|
||||
=========== ============= ========================================
|
||||
r0 Volatile (System call number.)
|
||||
r3 Volatile (Parameter 1, and return value.)
|
||||
r4-r8 Volatile (Parameters 2-6.)
|
||||
=========== ============= ========================================
|
||||
+------------------------------------------------------------------------+
|
||||
| For the sc instruction, differences with the ELF ABI |
|
||||
+--------------+--------------+------------------------------------------+
|
||||
| r0 | Volatile | (System call number.) |
|
||||
| rr3 | Volatile | (Parameter 1, and return value.) |
|
||||
| rr4-r8 | Volatile | (Parameters 2-6.) |
|
||||
| rcr0 | Volatile | (cr0.SO is the return error condition.) |
|
||||
| rcr1, cr5-7 | Nonvolatile | |
|
||||
| rlr | Nonvolatile | |
|
||||
+--------------+--------------+------------------------------------------+
|
||||
| For the scv 0 instruction, differences with the ELF ABI |
|
||||
+--------------+--------------+------------------------------------------+
|
||||
| r0 | Volatile | (System call number.) |
|
||||
| r3 | Volatile | (Parameter 1, and return value.) |
|
||||
| r4-r8 | Volatile | (Parameters 2-6.) |
|
||||
+--------------+--------------+------------------------------------------+
|
||||
|
||||
All floating point and vector data registers as well as control and status
|
||||
registers are nonvolatile.
|
||||
|
|
|
|||
|
|
@ -34,20 +34,20 @@ substream. In this procedure, PCM hardware parameters are decided by
|
|||
interaction between applications and ALSA PCM core. Once decided, runtime of
|
||||
the PCM substream keeps the parameters.
|
||||
|
||||
The parameters are described in :c:type:`struct snd_pcm_hw_params`. This
|
||||
The parameters are described in struct snd_pcm_hw_params. This
|
||||
structure includes several types of parameters. Applications set preferable
|
||||
value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE
|
||||
or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available
|
||||
set of parameters. The latter is used for an actual decision of the parameters.
|
||||
|
||||
The :c:type:`struct snd_pcm_hw_params` structure has below members:
|
||||
The struct snd_pcm_hw_params structure has below members:
|
||||
|
||||
``flags``
|
||||
Configurable. ALSA PCM core and some drivers handle this flag to select
|
||||
convenient parameters or change their behaviour.
|
||||
``masks``
|
||||
Configurable. This type of parameter is described in
|
||||
:c:type:`struct snd_mask` and represent mask values. As of PCM protocol
|
||||
struct snd_mask and represent mask values. As of PCM protocol
|
||||
v2.0.13, three types are defined.
|
||||
|
||||
- SNDRV_PCM_HW_PARAM_ACCESS
|
||||
|
|
@ -55,7 +55,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members:
|
|||
- SNDRV_PCM_HW_PARAM_SUBFORMAT
|
||||
``intervals``
|
||||
Configurable. This type of parameter is described in
|
||||
:c:type:`struct snd_interval` and represent values with a range. As of
|
||||
struct snd_interval and represent values with a range. As of
|
||||
PCM protocol v2.0.13, twelve types are defined.
|
||||
|
||||
- SNDRV_PCM_HW_PARAM_SAMPLE_BITS
|
||||
|
|
@ -78,7 +78,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members:
|
|||
are going to be changed.
|
||||
``cmask``
|
||||
Read-only. After returning from ioctl(2), buffer in user space for
|
||||
:c:type:`struct snd_pcm_hw_params` includes result of each operation.
|
||||
struct snd_pcm_hw_params includes result of each operation.
|
||||
This mask represents which mask/interval parameter is actually changed.
|
||||
``info``
|
||||
Read-only. This represents hardware/driver capabilities as bit flags
|
||||
|
|
@ -110,10 +110,10 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members:
|
|||
value to this parameter but some drivers intentionally set zero with
|
||||
a care of hardware design or data transmission protocol.
|
||||
|
||||
ALSA PCM core handles buffer of :c:type:`struct snd_pcm_hw_params` when
|
||||
ALSA PCM core handles buffer of struct snd_pcm_hw_params when
|
||||
applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS.
|
||||
Parameters in the buffer are changed according to
|
||||
:c:type:`struct snd_pcm_hardware` and rules of constraints in the runtime. The
|
||||
struct snd_pcm_hardware and rules of constraints in the runtime. The
|
||||
structure describes capabilities of handled hardware. The rules describes
|
||||
dependencies on which a parameter is decided according to several parameters.
|
||||
A rule has a callback function, and drivers can register arbitrary functions
|
||||
|
|
@ -121,17 +121,17 @@ to compute the target parameter. ALSA PCM core registers some rules to the
|
|||
runtime as a default.
|
||||
|
||||
Each driver can join in the interaction as long as it prepared for two stuffs
|
||||
in a callback of :c:type:`struct snd_pcm_ops.open`.
|
||||
in a callback of struct snd_pcm_ops.open.
|
||||
|
||||
1. In the callback, drivers are expected to change a member of
|
||||
:c:type:`struct snd_pcm_hardware` type in the runtime, according to
|
||||
struct snd_pcm_hardware type in the runtime, according to
|
||||
capacities of corresponding hardware.
|
||||
2. In the same callback, drivers are also expected to register additional rules
|
||||
of constraints into the runtime when several parameters have dependencies
|
||||
due to hardware design.
|
||||
|
||||
The driver can refers to result of the interaction in a callback of
|
||||
:c:type:`struct snd_pcm_ops.hw_params`, however it should not change the
|
||||
struct snd_pcm_ops.hw_params, however it should not change the
|
||||
content.
|
||||
|
||||
Tracepoints in this category are designed to trace changes of the
|
||||
|
|
@ -163,7 +163,7 @@ fields are different according to type of the parameter. For parameters of mask
|
|||
type, the fields represent hexadecimal dump of content of the parameter. For
|
||||
parameters of interval type, the fields represent values of each member of
|
||||
``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in
|
||||
:c:type:`struct snd_interval` in this order.
|
||||
struct snd_interval in this order.
|
||||
|
||||
Tracepoints in drivers
|
||||
======================
|
||||
|
|
|
|||
|
|
@ -132,3 +132,4 @@ ISA DMA Helpers
|
|||
Other Helper Macros
|
||||
-------------------
|
||||
.. kernel-doc:: include/sound/core.h
|
||||
.. kernel-doc:: sound/sound_core.c
|
||||
|
|
|
|||
|
|
@ -194,7 +194,7 @@ The minimum flow for PCI soundcards is as follows:
|
|||
|
||||
- create ``remove`` callback.
|
||||
|
||||
- create a :c:type:`struct pci_driver <pci_driver>` structure
|
||||
- create a struct pci_driver structure
|
||||
containing the three pointers above.
|
||||
|
||||
- create an ``init`` function just calling the
|
||||
|
|
@ -487,7 +487,7 @@ The destructor, remove callback, simply releases the card instance. Then
|
|||
the ALSA middle layer will release all the attached components
|
||||
automatically.
|
||||
|
||||
It would be typically just :c:func:`calling snd_card_free()`:
|
||||
It would be typically just calling :c:func:`snd_card_free()`:
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -560,16 +560,15 @@ return the card instance. The extra_size argument is used to allocate
|
|||
card->private_data for the chip-specific data. Note that these data are
|
||||
allocated by :c:func:`snd_card_new()`.
|
||||
|
||||
The first argument, the pointer of struct :c:type:`struct device
|
||||
<device>`, specifies the parent device. For PCI devices, typically
|
||||
``&pci->`` is passed there.
|
||||
The first argument, the pointer of struct device, specifies the parent
|
||||
device. For PCI devices, typically ``&pci->`` is passed there.
|
||||
|
||||
Components
|
||||
----------
|
||||
|
||||
After the card is created, you can attach the components (devices) to
|
||||
the card instance. In an ALSA driver, a component is represented as a
|
||||
:c:type:`struct snd_device <snd_device>` object. A component
|
||||
struct snd_device object. A component
|
||||
can be a PCM instance, a control interface, a raw MIDI interface, etc.
|
||||
Each such instance has one component entry.
|
||||
|
||||
|
|
@ -628,7 +627,7 @@ argument of :c:func:`snd_card_new()`, i.e.
|
|||
err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE,
|
||||
sizeof(struct mychip), &card);
|
||||
|
||||
:c:type:`struct mychip <mychip>` is the type of the chip record.
|
||||
struct mychip is the type of the chip record.
|
||||
|
||||
In return, the allocated record can be accessed as
|
||||
|
||||
|
|
@ -890,7 +889,7 @@ functions. These resources must be released in the destructor
|
|||
function (see below).
|
||||
|
||||
Now assume that the PCI device has an I/O port with 8 bytes and an
|
||||
interrupt. Then :c:type:`struct mychip <mychip>` will have the
|
||||
interrupt. Then struct mychip will have the
|
||||
following fields:
|
||||
|
||||
::
|
||||
|
|
@ -1094,7 +1093,7 @@ PCI Entries
|
|||
-----------
|
||||
|
||||
So far, so good. Let's finish the missing PCI stuff. At first, we need a
|
||||
:c:type:`struct pci_device_id <pci_device_id>` table for
|
||||
struct pci_device_id table for
|
||||
this chipset. It's a table of PCI vendor/device ID number, and some
|
||||
masks.
|
||||
|
||||
|
|
@ -1110,19 +1109,17 @@ For example,
|
|||
};
|
||||
MODULE_DEVICE_TABLE(pci, snd_mychip_ids);
|
||||
|
||||
The first and second fields of the :c:type:`struct pci_device_id
|
||||
<pci_device_id>` structure are the vendor and device IDs. If you
|
||||
have no reason to filter the matching devices, you can leave the
|
||||
remaining fields as above. The last field of the :c:type:`struct
|
||||
pci_device_id <pci_device_id>` struct contains private data
|
||||
for this entry. You can specify any value here, for example, to define
|
||||
specific operations for supported device IDs. Such an example is found
|
||||
in the intel8x0 driver.
|
||||
The first and second fields of the struct pci_device_id are the vendor
|
||||
and device IDs. If you have no reason to filter the matching devices, you can
|
||||
leave the remaining fields as above. The last field of the
|
||||
struct pci_device_id contains private data for this entry. You can specify
|
||||
any value here, for example, to define specific operations for supported
|
||||
device IDs. Such an example is found in the intel8x0 driver.
|
||||
|
||||
The last entry of this list is the terminator. You must specify this
|
||||
all-zero entry.
|
||||
|
||||
Then, prepare the :c:type:`struct pci_driver <pci_driver>`
|
||||
Then, prepare the struct pci_driver
|
||||
record:
|
||||
|
||||
::
|
||||
|
|
@ -1439,8 +1436,8 @@ corresponding argument.
|
|||
If a chip supports multiple playbacks or captures, you can specify more
|
||||
numbers, but they must be handled properly in open/close, etc.
|
||||
callbacks. When you need to know which substream you are referring to,
|
||||
then it can be obtained from :c:type:`struct snd_pcm_substream
|
||||
<snd_pcm_substream>` data passed to each callback as follows:
|
||||
then it can be obtained from struct snd_pcm_substream data passed to each
|
||||
callback as follows:
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -1639,10 +1636,9 @@ In the sections below, important records are explained.
|
|||
Hardware Description
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The hardware descriptor (:c:type:`struct snd_pcm_hardware
|
||||
<snd_pcm_hardware>`) contains the definitions of the fundamental
|
||||
hardware configuration. Above all, you'll need to define this in the
|
||||
`PCM open callback`_. Note that the runtime instance holds the copy of
|
||||
The hardware descriptor (struct snd_pcm_hardware) contains the definitions of
|
||||
the fundamental hardware configuration. Above all, you'll need to define this
|
||||
in the `PCM open callback`_. Note that the runtime instance holds the copy of
|
||||
the descriptor, not the pointer to the existing descriptor. That is,
|
||||
in the open callback, you can modify the copied descriptor
|
||||
(``runtime->hw``) as you need. For example, if the maximum number of
|
||||
|
|
@ -1800,14 +1796,13 @@ Running Status
|
|||
~~~~~~~~~~~~~~
|
||||
|
||||
The running status can be referred via ``runtime->status``. This is
|
||||
the pointer to the :c:type:`struct snd_pcm_mmap_status
|
||||
<snd_pcm_mmap_status>` record. For example, you can get the current
|
||||
the pointer to the struct snd_pcm_mmap_status record.
|
||||
For example, you can get the current
|
||||
DMA hardware pointer via ``runtime->status->hw_ptr``.
|
||||
|
||||
The DMA application pointer can be referred via ``runtime->control``,
|
||||
which points to the :c:type:`struct snd_pcm_mmap_control
|
||||
<snd_pcm_mmap_control>` record. However, accessing directly to
|
||||
this value is not recommended.
|
||||
which points to the struct snd_pcm_mmap_control record.
|
||||
However, accessing directly to this value is not recommended.
|
||||
|
||||
Private Data
|
||||
~~~~~~~~~~~~
|
||||
|
|
@ -1843,8 +1838,8 @@ error number such as ``-EINVAL``. To choose an appropriate error
|
|||
number, it is advised to check what value other parts of the kernel
|
||||
return when the same kind of request fails.
|
||||
|
||||
The callback function takes at least the argument with :c:type:`struct
|
||||
snd_pcm_substream <snd_pcm_substream>` pointer. To retrieve the chip
|
||||
The callback function takes at least the argument with
|
||||
struct snd_pcm_substream pointer. To retrieve the chip
|
||||
record from the given substream instance, you can use the following
|
||||
macro.
|
||||
|
||||
|
|
@ -2313,10 +2308,10 @@ non-atomic contexts. For example, the function
|
|||
:c:func:`snd_pcm_period_elapsed()` is called typically from the
|
||||
interrupt handler. But, if you set up the driver to use a threaded
|
||||
interrupt handler, this call can be in non-atomic context, too. In such
|
||||
a case, you can set ``nonatomic`` filed of :c:type:`struct snd_pcm
|
||||
<snd_pcm>` object after creating it. When this flag is set, mutex
|
||||
and rwsem are used internally in the PCM core instead of spin and
|
||||
rwlocks, so that you can call all PCM functions safely in a non-atomic
|
||||
a case, you can set ``nonatomic`` filed of struct snd_pcm object
|
||||
after creating it. When this flag is set, mutex and rwsem are used internally
|
||||
in the PCM core instead of spin and rwlocks, so that you can call all PCM
|
||||
functions safely in a non-atomic
|
||||
context.
|
||||
|
||||
Constraints
|
||||
|
|
@ -2357,8 +2352,7 @@ There are many different constraints. Look at ``sound/pcm.h`` for a
|
|||
complete list. You can even define your own constraint rules. For
|
||||
example, let's suppose my_chip can manage a substream of 1 channel if
|
||||
and only if the format is ``S16_LE``, otherwise it supports any format
|
||||
specified in the :c:type:`struct snd_pcm_hardware
|
||||
<snd_pcm_hardware>` structure (or in any other
|
||||
specified in struct snd_pcm_hardware> (or in any other
|
||||
constraint_list). You can build a rule like this:
|
||||
|
||||
::
|
||||
|
|
@ -2467,7 +2461,7 @@ Definition of Controls
|
|||
|
||||
To create a new control, you need to define the following three
|
||||
callbacks: ``info``, ``get`` and ``put``. Then, define a
|
||||
:c:type:`struct snd_kcontrol_new <snd_kcontrol_new>` record, such as:
|
||||
struct snd_kcontrol_new record, such as:
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -2602,8 +2596,8 @@ info callback
|
|||
~~~~~~~~~~~~~
|
||||
|
||||
The ``info`` callback is used to get detailed information on this
|
||||
control. This must store the values of the given :c:type:`struct
|
||||
snd_ctl_elem_info <snd_ctl_elem_info>` object. For example,
|
||||
control. This must store the values of the given
|
||||
struct snd_ctl_elem_info object. For example,
|
||||
for a boolean control with a single element:
|
||||
|
||||
::
|
||||
|
|
@ -2774,13 +2768,11 @@ In the simplest way, you can do like this:
|
|||
if (err < 0)
|
||||
return err;
|
||||
|
||||
where ``my_control`` is the :c:type:`struct snd_kcontrol_new
|
||||
<snd_kcontrol_new>` object defined above, and chip is the object
|
||||
pointer to be passed to kcontrol->private_data which can be referred
|
||||
to in callbacks.
|
||||
where ``my_control`` is the struct snd_kcontrol_new object defined above,
|
||||
and chip is the object pointer to be passed to kcontrol->private_data which
|
||||
can be referred to in callbacks.
|
||||
|
||||
:c:func:`snd_ctl_new1()` allocates a new :c:type:`struct
|
||||
snd_kcontrol <snd_kcontrol>` instance, and
|
||||
:c:func:`snd_ctl_new1()` allocates a new struct snd_kcontrol instance, and
|
||||
:c:func:`snd_ctl_add()` assigns the given control component to the
|
||||
card.
|
||||
|
||||
|
|
@ -2797,10 +2789,9 @@ can call :c:func:`snd_ctl_notify()`. For example,
|
|||
This function takes the card pointer, the event-mask, and the control id
|
||||
pointer for the notification. The event-mask specifies the types of
|
||||
notification, for example, in the above example, the change of control
|
||||
values is notified. The id pointer is the pointer of :c:type:`struct
|
||||
snd_ctl_elem_id <snd_ctl_elem_id>` to be notified. You can
|
||||
find some examples in ``es1938.c`` or ``es1968.c`` for hardware volume
|
||||
interrupts.
|
||||
values is notified. The id pointer is the pointer of struct snd_ctl_elem_id
|
||||
to be notified. You can find some examples in ``es1938.c`` or ``es1968.c``
|
||||
for hardware volume interrupts.
|
||||
|
||||
Metadata
|
||||
--------
|
||||
|
|
@ -2915,9 +2906,8 @@ with an ``ac97_bus_ops_t`` record with callback functions.
|
|||
|
||||
The bus record is shared among all belonging ac97 instances.
|
||||
|
||||
And then call :c:func:`snd_ac97_mixer()` with an :c:type:`struct
|
||||
snd_ac97_template <snd_ac97_template>` record together with
|
||||
the bus pointer created above.
|
||||
And then call :c:func:`snd_ac97_mixer()` with an struct snd_ac97_template
|
||||
record together with the bus pointer created above.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -3118,11 +3108,10 @@ devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see
|
|||
|
||||
Usually, the port address corresponds to the command port and port + 1
|
||||
corresponds to the data port. If not, you may change the ``cport``
|
||||
field of :c:type:`struct snd_mpu401 <snd_mpu401>` manually afterward.
|
||||
However, :c:type:`struct snd_mpu401 <snd_mpu401>` pointer is
|
||||
field of struct snd_mpu401 manually afterward.
|
||||
However, struct snd_mpu401 pointer is
|
||||
not returned explicitly by :c:func:`snd_mpu401_uart_new()`. You
|
||||
need to cast ``rmidi->private_data`` to :c:type:`struct snd_mpu401
|
||||
<snd_mpu401>` explicitly,
|
||||
need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly,
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -3326,8 +3315,7 @@ data and removes them from the buffer at once:
|
|||
}
|
||||
|
||||
If you know beforehand how many bytes you can accept, you can use a
|
||||
buffer size greater than one with the
|
||||
:c:func:`snd_rawmidi_transmit\*()` functions.
|
||||
buffer size greater than one with the ``snd_rawmidi_transmit*()`` functions.
|
||||
|
||||
The ``trigger`` callback must not sleep. If the hardware FIFO is full
|
||||
before the substream buffer has been emptied, you have to continue
|
||||
|
|
@ -3772,7 +3760,7 @@ For creating the SG-buffer handler, call
|
|||
:c:func:`snd_pcm_set_managed_buffer_all()` with
|
||||
``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like other PCI
|
||||
pre-allocator. You need to pass ``&pci->dev``, where pci is
|
||||
the :c:type:`struct pci_dev <pci_dev>` pointer of the chip as
|
||||
the struct pci_dev pointer of the chip as
|
||||
well.
|
||||
|
||||
::
|
||||
|
|
@ -3927,7 +3915,7 @@ the maximum size of the proc file access.
|
|||
|
||||
The read/write callbacks of raw mode are more direct than the text mode.
|
||||
You need to use a low-level I/O functions such as
|
||||
:c:func:`copy_from/to_user()` to transfer the data.
|
||||
:c:func:`copy_from_user()` and :c:func:`copy_to_user()` to transfer the data.
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -22,13 +22,34 @@ from itertools import chain
|
|||
# :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last
|
||||
# bit tries to restrict matches to things that won't create trouble.
|
||||
#
|
||||
RE_function = re.compile(r'(([\w_][\w\d_]+)\(\))')
|
||||
RE_type = re.compile(r'(struct|union|enum|typedef)\s+([\w_][\w\d_]+)')
|
||||
RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII)
|
||||
|
||||
#
|
||||
# Sphinx 2 uses the same :c:type role for struct, union, enum and typedef
|
||||
#
|
||||
RE_generic_type = re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)',
|
||||
flags=re.ASCII)
|
||||
|
||||
#
|
||||
# Sphinx 3 uses a different C role for each one of struct, union, enum and
|
||||
# typedef
|
||||
#
|
||||
RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
|
||||
RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
|
||||
RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
|
||||
RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
|
||||
|
||||
#
|
||||
# Detects a reference to a documentation page of the form Documentation/... with
|
||||
# an optional extension
|
||||
#
|
||||
RE_doc = re.compile(r'Documentation(/[\w\-_/]+)(\.\w+)*')
|
||||
RE_doc = re.compile(r'\bDocumentation(/[\w\-_/]+)(\.\w+)*')
|
||||
|
||||
#
|
||||
# Reserved C words that we should skip when cross-referencing
|
||||
#
|
||||
Skipnames = [ 'for', 'if', 'register', 'sizeof', 'struct', 'unsigned' ]
|
||||
|
||||
|
||||
#
|
||||
# Many places in the docs refer to common system calls. It is
|
||||
|
|
@ -48,9 +69,22 @@ def markup_refs(docname, app, node):
|
|||
#
|
||||
# Associate each regex with the function that will markup its matches
|
||||
#
|
||||
markup_func = {RE_type: markup_c_ref,
|
||||
RE_function: markup_c_ref,
|
||||
RE_doc: markup_doc_ref}
|
||||
markup_func_sphinx2 = {RE_doc: markup_doc_ref,
|
||||
RE_function: markup_c_ref,
|
||||
RE_generic_type: markup_c_ref}
|
||||
|
||||
markup_func_sphinx3 = {RE_doc: markup_doc_ref,
|
||||
RE_function: markup_func_ref_sphinx3,
|
||||
RE_struct: markup_c_ref,
|
||||
RE_union: markup_c_ref,
|
||||
RE_enum: markup_c_ref,
|
||||
RE_typedef: markup_c_ref}
|
||||
|
||||
if sphinx.version_info[0] >= 3:
|
||||
markup_func = markup_func_sphinx3
|
||||
else:
|
||||
markup_func = markup_func_sphinx2
|
||||
|
||||
match_iterators = [regex.finditer(t) for regex in markup_func]
|
||||
#
|
||||
# Sort all references by the starting position in text
|
||||
|
|
@ -75,12 +109,12 @@ def markup_refs(docname, app, node):
|
|||
return repl
|
||||
|
||||
#
|
||||
# Try to replace a C reference (function() or struct/union/enum/typedef
|
||||
# type_name) with an appropriate cross reference.
|
||||
# In sphinx3 we can cross-reference to C macro and function, each one with its
|
||||
# own C role, but both match the same regex, so we try both.
|
||||
#
|
||||
def markup_c_ref(docname, app, match):
|
||||
class_str = {RE_function: 'c-func', RE_type: 'c-type'}
|
||||
reftype_str = {RE_function: 'function', RE_type: 'type'}
|
||||
def markup_func_ref_sphinx3(docname, app, match):
|
||||
class_str = ['c-func', 'c-macro']
|
||||
reftype_str = ['function', 'macro']
|
||||
|
||||
cdom = app.env.domains['c']
|
||||
#
|
||||
|
|
@ -89,7 +123,59 @@ def markup_c_ref(docname, app, match):
|
|||
target = match.group(2)
|
||||
target_text = nodes.Text(match.group(0))
|
||||
xref = None
|
||||
if not (match.re == RE_function and target in Skipfuncs):
|
||||
if not (target in Skipfuncs or target in Skipnames):
|
||||
for class_s, reftype_s in zip(class_str, reftype_str):
|
||||
lit_text = nodes.literal(classes=['xref', 'c', class_s])
|
||||
lit_text += target_text
|
||||
pxref = addnodes.pending_xref('', refdomain = 'c',
|
||||
reftype = reftype_s,
|
||||
reftarget = target, modname = None,
|
||||
classname = None)
|
||||
#
|
||||
# XXX The Latex builder will throw NoUri exceptions here,
|
||||
# work around that by ignoring them.
|
||||
#
|
||||
try:
|
||||
xref = cdom.resolve_xref(app.env, docname, app.builder,
|
||||
reftype_s, target, pxref,
|
||||
lit_text)
|
||||
except NoUri:
|
||||
xref = None
|
||||
|
||||
if xref:
|
||||
return xref
|
||||
|
||||
return target_text
|
||||
|
||||
def markup_c_ref(docname, app, match):
|
||||
class_str = {# Sphinx 2 only
|
||||
RE_function: 'c-func',
|
||||
RE_generic_type: 'c-type',
|
||||
# Sphinx 3+ only
|
||||
RE_struct: 'c-struct',
|
||||
RE_union: 'c-union',
|
||||
RE_enum: 'c-enum',
|
||||
RE_typedef: 'c-type',
|
||||
}
|
||||
reftype_str = {# Sphinx 2 only
|
||||
RE_function: 'function',
|
||||
RE_generic_type: 'type',
|
||||
# Sphinx 3+ only
|
||||
RE_struct: 'struct',
|
||||
RE_union: 'union',
|
||||
RE_enum: 'enum',
|
||||
RE_typedef: 'type',
|
||||
}
|
||||
|
||||
cdom = app.env.domains['c']
|
||||
#
|
||||
# Go through the dance of getting an xref out of the C domain
|
||||
#
|
||||
target = match.group(2)
|
||||
target_text = nodes.Text(match.group(0))
|
||||
xref = None
|
||||
if not ((match.re == RE_function and target in Skipfuncs)
|
||||
or (target in Skipnames)):
|
||||
lit_text = nodes.literal(classes=['xref', 'c', class_str[match.re]])
|
||||
lit_text += target_text
|
||||
pxref = addnodes.pending_xref('', refdomain = 'c',
|
||||
|
|
|
|||
|
|
@ -40,14 +40,94 @@ from sphinx import addnodes
|
|||
from sphinx.domains.c import c_funcptr_sig_re, c_sig_re
|
||||
from sphinx.domains.c import CObject as Base_CObject
|
||||
from sphinx.domains.c import CDomain as Base_CDomain
|
||||
from itertools import chain
|
||||
import re
|
||||
|
||||
__version__ = '1.0'
|
||||
__version__ = '1.1'
|
||||
|
||||
# Get Sphinx version
|
||||
major, minor, patch = sphinx.version_info[:3]
|
||||
|
||||
# Namespace to be prepended to the full name
|
||||
namespace = None
|
||||
|
||||
#
|
||||
# Handle trivial newer c domain tags that are part of Sphinx 3.1 c domain tags
|
||||
# - Store the namespace if ".. c:namespace::" tag is found
|
||||
#
|
||||
RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$')
|
||||
|
||||
def markup_namespace(match):
|
||||
global namespace
|
||||
|
||||
namespace = match.group(1)
|
||||
|
||||
return ""
|
||||
|
||||
#
|
||||
# Handle c:macro for function-style declaration
|
||||
#
|
||||
RE_macro = re.compile(r'^\s*..\s*c:macro::\s*(\S+)\s+(\S.*)\s*$')
|
||||
def markup_macro(match):
|
||||
return ".. c:function:: " + match.group(1) + ' ' + match.group(2)
|
||||
|
||||
#
|
||||
# Handle newer c domain tags that are evaluated as .. c:type: for
|
||||
# backward-compatibility with Sphinx < 3.0
|
||||
#
|
||||
RE_ctype = re.compile(r'^\s*..\s*c:(struct|union|enum|enumerator|alias)::\s*(.*)$')
|
||||
|
||||
def markup_ctype(match):
|
||||
return ".. c:type:: " + match.group(2)
|
||||
|
||||
#
|
||||
# Handle newer c domain tags that are evaluated as :c:type: for
|
||||
# backward-compatibility with Sphinx < 3.0
|
||||
#
|
||||
RE_ctype_refs = re.compile(r':c:(var|struct|union|enum|enumerator)::`([^\`]+)`')
|
||||
def markup_ctype_refs(match):
|
||||
return ":c:type:`" + match.group(2) + '`'
|
||||
|
||||
#
|
||||
# Simply convert :c:expr: and :c:texpr: into a literal block.
|
||||
#
|
||||
RE_expr = re.compile(r':c:(expr|texpr):`([^\`]+)`')
|
||||
def markup_c_expr(match):
|
||||
return '\ ``' + match.group(2) + '``\ '
|
||||
|
||||
#
|
||||
# Parse Sphinx 3.x C markups, replacing them by backward-compatible ones
|
||||
#
|
||||
def c_markups(app, docname, source):
|
||||
result = ""
|
||||
markup_func = {
|
||||
RE_namespace: markup_namespace,
|
||||
RE_expr: markup_c_expr,
|
||||
RE_macro: markup_macro,
|
||||
RE_ctype: markup_ctype,
|
||||
RE_ctype_refs: markup_ctype_refs,
|
||||
}
|
||||
|
||||
lines = iter(source[0].splitlines(True))
|
||||
for n in lines:
|
||||
match_iterators = [regex.finditer(n) for regex in markup_func]
|
||||
matches = sorted(chain(*match_iterators), key=lambda m: m.start())
|
||||
for m in matches:
|
||||
n = n[:m.start()] + markup_func[m.re](m) + n[m.end():]
|
||||
|
||||
result = result + n
|
||||
|
||||
source[0] = result
|
||||
|
||||
#
|
||||
# Now implements support for the cdomain namespacing logic
|
||||
#
|
||||
|
||||
def setup(app):
|
||||
|
||||
# Handle easy Sphinx 3.1+ simple new tags: :c:expr and .. c:namespace::
|
||||
app.connect('source-read', c_markups)
|
||||
|
||||
if (major == 1 and minor < 8):
|
||||
app.override_domain(CDomain)
|
||||
else:
|
||||
|
|
@ -75,6 +155,8 @@ class CObject(Base_CObject):
|
|||
function-like macro, the name of the macro is returned. Otherwise
|
||||
``False`` is returned. """
|
||||
|
||||
global namespace
|
||||
|
||||
if not self.objtype == 'function':
|
||||
return False
|
||||
|
||||
|
|
@ -107,11 +189,16 @@ class CObject(Base_CObject):
|
|||
param += nodes.emphasis(argname, argname)
|
||||
paramlist += param
|
||||
|
||||
if namespace:
|
||||
fullname = namespace + "." + fullname
|
||||
|
||||
return fullname
|
||||
|
||||
def handle_signature(self, sig, signode):
|
||||
"""Transform a C signature into RST nodes."""
|
||||
|
||||
global namespace
|
||||
|
||||
fullname = self.handle_func_like_macro(sig, signode)
|
||||
if not fullname:
|
||||
fullname = super(CObject, self).handle_signature(sig, signode)
|
||||
|
|
@ -122,6 +209,10 @@ class CObject(Base_CObject):
|
|||
else:
|
||||
# FIXME: handle :name: value of other declaration types?
|
||||
pass
|
||||
else:
|
||||
if namespace:
|
||||
fullname = namespace + "." + fullname
|
||||
|
||||
return fullname
|
||||
|
||||
def add_target_and_index(self, name, sig, signode):
|
||||
|
|
|
|||
|
|
@ -62,6 +62,7 @@ class KernelDocDirective(Directive):
|
|||
'export': directives.unchanged,
|
||||
'internal': directives.unchanged,
|
||||
'identifiers': directives.unchanged,
|
||||
'no-identifiers': directives.unchanged,
|
||||
'functions': directives.unchanged,
|
||||
}
|
||||
has_content = False
|
||||
|
|
@ -70,6 +71,11 @@ class KernelDocDirective(Directive):
|
|||
env = self.state.document.settings.env
|
||||
cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno']
|
||||
|
||||
# Pass the version string to kernel-doc, as it needs to use a different
|
||||
# dialect, depending what the C domain supports for each specific
|
||||
# Sphinx versions
|
||||
cmd += ['-sphinx-version', sphinx.__version__]
|
||||
|
||||
filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
|
||||
export_file_patterns = []
|
||||
|
||||
|
|
@ -99,6 +105,12 @@ class KernelDocDirective(Directive):
|
|||
else:
|
||||
cmd += ['-no-doc-sections']
|
||||
|
||||
if 'no-identifiers' in self.options:
|
||||
no_identifiers = self.options.get('no-identifiers').split()
|
||||
if no_identifiers:
|
||||
for i in no_identifiers:
|
||||
cmd += ['-nosymbol', i]
|
||||
|
||||
for pattern in export_file_patterns:
|
||||
for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern):
|
||||
env.note_dependency(os.path.abspath(f))
|
||||
|
|
@ -136,7 +148,8 @@ class KernelDocDirective(Directive):
|
|||
lineoffset = int(match.group(1)) - 1
|
||||
# we must eat our comments since the upset the markup
|
||||
else:
|
||||
result.append(line, filename, lineoffset)
|
||||
doc = env.srcdir + "/" + env.docname + ":" + str(self.lineno)
|
||||
result.append(line, doc + ": " + filename, lineoffset)
|
||||
lineoffset += 1
|
||||
|
||||
node = nodes.section()
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ while (<IN>) {
|
|||
) {
|
||||
my $s = $1;
|
||||
|
||||
$structs{$s} = "struct :c:type:`$s`\\ ";
|
||||
$structs{$s} = "struct $s\\ ";
|
||||
next;
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -55,17 +55,17 @@ 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);
|
||||
register_ftrace_function(&ops);
|
||||
|
||||
To disable tracing call:
|
||||
To disable tracing call::
|
||||
|
||||
.. c:function:: unregister_ftrace_function(&ops);
|
||||
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>
|
||||
#include <linux/ftrace.h>
|
||||
|
||||
The registered callback will start being called some time after the
|
||||
register_ftrace_function() is called and before it returns. The exact time
|
||||
|
|
|
|||
|
|
@ -402,7 +402,7 @@ il valore convertito. Tutte le varianti supportano anche il processo inverso:
|
|||
:c:func:`be32_to_cpu()`, eccetera.
|
||||
|
||||
Queste funzioni hanno principalmente due varianti: la variante per
|
||||
puntatori, come :c:func:`cpu_to_be32p(), che prende un puntatore
|
||||
puntatori, come :c:func:`cpu_to_be32p()`, che prende un puntatore
|
||||
ad un tipo, e ritorna il valore convertito. L'altra variante per
|
||||
la famiglia di conversioni "in-situ", come :c:func:`cpu_to_be32s()`,
|
||||
che convertono il valore puntato da un puntatore, e ritornano void.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
.. c:namespace:: it_IT
|
||||
|
||||
:Original: :ref:`Documentation/kernel-hacking/locking.rst <kernel_hacking_lock>`
|
||||
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
|
||||
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@
|
|||
|
||||
Translator: Bailu Lin <bailu.lin@vivo.com>
|
||||
|
||||
=================================
|
||||
==================================
|
||||
AArch64 Linux 中扩展的活动监控单元
|
||||
=================================
|
||||
==================================
|
||||
|
||||
作者: Ionela Voinescu <ionela.voinescu@arm.com>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _cec-func-close:
|
||||
|
||||
|
|
@ -11,7 +12,6 @@ Name
|
|||
|
||||
cec-close - Close a cec device
|
||||
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
|
|
@ -19,16 +19,13 @@ Synopsis
|
|||
|
||||
#include <unistd.h>
|
||||
|
||||
|
||||
.. c:function:: int close( int fd )
|
||||
:name: cec-close
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
Description
|
||||
===========
|
||||
|
|
@ -36,11 +33,10 @@ Description
|
|||
Closes the cec device. Resources associated with the file descriptor are
|
||||
freed. The device configuration remain unchanged.
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
:c:func:`close() <cec-close>` returns 0 on success. On error, -1 is returned, and
|
||||
:c:func:`close()` returns 0 on success. On error, -1 is returned, and
|
||||
``errno`` is set appropriately. Possible error codes are:
|
||||
|
||||
``EBADF``
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _cec-func-ioctl:
|
||||
|
||||
|
|
@ -18,15 +19,13 @@ Synopsis
|
|||
|
||||
#include <sys/ioctl.h>
|
||||
|
||||
|
||||
.. c:function:: int ioctl( int fd, int request, void *argp )
|
||||
:name: cec-ioctl
|
||||
``int ioctl(int fd, int request, void *argp)``
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
``request``
|
||||
CEC ioctl request code as defined in the cec.h header file, for
|
||||
|
|
@ -35,11 +34,10 @@ Arguments
|
|||
``argp``
|
||||
Pointer to a request-specific structure.
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
The :c:func:`ioctl() <cec-ioctl>` function manipulates cec device parameters. The
|
||||
The :c:func:`ioctl()` function manipulates cec device parameters. The
|
||||
argument ``fd`` must be an open file descriptor.
|
||||
|
||||
The ioctl ``request`` code specifies the cec function to be called. It
|
||||
|
|
@ -51,7 +49,6 @@ their parameters are located in the cec.h header file. All cec ioctl
|
|||
requests, their respective function and parameters are specified in
|
||||
:ref:`cec-user-func`.
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _cec-func-open:
|
||||
|
||||
|
|
@ -18,10 +19,7 @@ Synopsis
|
|||
|
||||
#include <fcntl.h>
|
||||
|
||||
|
||||
.. c:function:: int open( const char *device_name, int flags )
|
||||
:name: cec-open
|
||||
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
|
@ -42,11 +40,10 @@ Arguments
|
|||
|
||||
Other flags have no effect.
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
To open a cec device applications call :c:func:`open() <cec-open>` with the
|
||||
To open a cec device applications call :c:func:`open()` with the
|
||||
desired device name. The function has no side effects; the device
|
||||
configuration remain unchanged.
|
||||
|
||||
|
|
@ -54,11 +51,10 @@ When the device is opened in read-only mode, attempts to modify its
|
|||
configuration will result in an error, and ``errno`` will be set to
|
||||
EBADF.
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
:c:func:`open() <cec-open>` returns the new file descriptor on success. On error,
|
||||
:c:func:`open()` returns the new file descriptor on success. On error,
|
||||
-1 is returned, and ``errno`` is set appropriately. Possible error codes
|
||||
include:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _cec-func-poll:
|
||||
|
||||
|
|
@ -11,7 +12,6 @@ Name
|
|||
|
||||
cec-poll - Wait for some event on a file descriptor
|
||||
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
|
|
@ -19,9 +19,7 @@ Synopsis
|
|||
|
||||
#include <sys/poll.h>
|
||||
|
||||
|
||||
.. c:function:: int poll( struct pollfd *ufds, unsigned int nfds, int timeout )
|
||||
:name: cec-poll
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
|
@ -35,14 +33,13 @@ Arguments
|
|||
``timeout``
|
||||
Timeout to wait for events
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
With the :c:func:`poll() <cec-poll>` function applications can wait for CEC
|
||||
With the :c:func:`poll()` function applications can wait for CEC
|
||||
events.
|
||||
|
||||
On success :c:func:`poll() <cec-poll>` returns the number of file descriptors
|
||||
On success :c:func:`poll()` returns the number of file descriptors
|
||||
that have been selected (that is, file descriptors for which the
|
||||
``revents`` field of the respective struct :c:type:`pollfd`
|
||||
is non-zero). CEC devices set the ``POLLIN`` and ``POLLRDNORM`` flags in
|
||||
|
|
@ -53,13 +50,12 @@ then the ``POLLPRI`` flag is set. When the function times out it returns
|
|||
a value of zero, on failure it returns -1 and the ``errno`` variable is
|
||||
set appropriately.
|
||||
|
||||
For more details see the :c:func:`poll() <cec-poll>` manual page.
|
||||
|
||||
For more details see the :c:func:`poll()` manual page.
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
On success, :c:func:`poll() <cec-poll>` returns the number structures which have
|
||||
On success, :c:func:`poll()` returns the number structures which have
|
||||
non-zero ``revents`` fields, or zero if the call timed out. On error -1
|
||||
is returned, and the ``errno`` variable is set appropriately:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _CEC_ADAP_G_CAPS:
|
||||
|
||||
|
|
@ -14,18 +15,18 @@ CEC_ADAP_G_CAPS - Query device capabilities
|
|||
Synopsis
|
||||
========
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_ADAP_G_CAPS, struct cec_caps *argp )
|
||||
:name: CEC_ADAP_G_CAPS
|
||||
.. c:macro:: CEC_ADAP_G_CAPS
|
||||
|
||||
``int ioctl(int fd, CEC_ADAP_G_CAPS, struct cec_caps *argp)``
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
``argp``
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
|
|
@ -62,7 +63,6 @@ returns the information to the application. The ioctl never fails.
|
|||
- CEC Framework API version, formatted with the ``KERNEL_VERSION()``
|
||||
macro.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}|
|
||||
|
||||
.. _cec-capabilities:
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
..
|
||||
.. Copyright 2019 Google LLC
|
||||
..
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _CEC_ADAP_G_CONNECTOR_INFO:
|
||||
|
||||
*******************************
|
||||
|
|
@ -16,18 +18,18 @@ CEC_ADAP_G_CONNECTOR_INFO - Query HDMI connector information
|
|||
Synopsis
|
||||
========
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_ADAP_G_CONNECTOR_INFO, struct cec_connector_info *argp )
|
||||
:name: CEC_ADAP_G_CONNECTOR_INFO
|
||||
.. c:macro:: CEC_ADAP_G_CONNECTOR_INFO
|
||||
|
||||
``int ioctl(int fd, CEC_ADAP_G_CONNECTOR_INFO, struct cec_connector_info *argp)``
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
``argp``
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
|
|
@ -57,7 +59,6 @@ is only available if the ``CEC_CAP_CONNECTOR_INFO`` capability is set.
|
|||
* - }
|
||||
-
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{4.4cm}|p{2.5cm}|p{10.6cm}|
|
||||
|
||||
.. _connector-type:
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _CEC_ADAP_LOG_ADDRS:
|
||||
.. _CEC_ADAP_G_LOG_ADDRS:
|
||||
|
|
@ -13,21 +14,22 @@ Name
|
|||
|
||||
CEC_ADAP_G_LOG_ADDRS, CEC_ADAP_S_LOG_ADDRS - Get or set the logical addresses
|
||||
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_ADAP_G_LOG_ADDRS, struct cec_log_addrs *argp )
|
||||
:name: CEC_ADAP_G_LOG_ADDRS
|
||||
.. c:macro:: CEC_ADAP_G_LOG_ADDRS
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_ADAP_S_LOG_ADDRS, struct cec_log_addrs *argp )
|
||||
:name: CEC_ADAP_S_LOG_ADDRS
|
||||
``int ioctl(int fd, CEC_ADAP_G_LOG_ADDRS, struct cec_log_addrs *argp)``
|
||||
|
||||
.. c:macro:: CEC_ADAP_S_LOG_ADDRS
|
||||
|
||||
``int ioctl(int fd, CEC_ADAP_S_LOG_ADDRS, struct cec_log_addrs *argp)``
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
``argp``
|
||||
Pointer to struct :c:type:`cec_log_addrs`.
|
||||
|
|
@ -148,7 +150,6 @@ logical address types are already defined will return with error ``EBUSY``.
|
|||
give the CEC framework more information about the device type, even
|
||||
though the framework won't use it directly in the CEC message.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.7cm}|
|
||||
|
||||
.. _cec-log-addrs-flags:
|
||||
|
|
@ -185,7 +186,6 @@ logical address types are already defined will return with error ``EBUSY``.
|
|||
|
||||
All other messages are ignored.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{7.8cm}|p{1.0cm}|p{8.7cm}|
|
||||
|
||||
.. _cec-versions:
|
||||
|
|
@ -211,7 +211,6 @@ logical address types are already defined will return with error ``EBUSY``.
|
|||
- 6
|
||||
- CEC version according to the HDMI 2.0 standard.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
|
||||
|
||||
.. _cec-prim-dev-types:
|
||||
|
|
@ -257,7 +256,6 @@ logical address types are already defined will return with error ``EBUSY``.
|
|||
- 7
|
||||
- Use for a video processor device.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
|
||||
|
||||
.. _cec-log-addr-types:
|
||||
|
|
@ -306,7 +304,6 @@ logical address types are already defined will return with error ``EBUSY``.
|
|||
Control).
|
||||
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
|
||||
|
||||
.. _cec-all-dev-types-flags:
|
||||
|
|
@ -348,7 +345,6 @@ logical address types are already defined will return with error ``EBUSY``.
|
|||
- This supports the CEC Switch or Video Processing type.
|
||||
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _CEC_ADAP_PHYS_ADDR:
|
||||
.. _CEC_ADAP_G_PHYS_ADDR:
|
||||
|
|
@ -13,21 +14,22 @@ Name
|
|||
|
||||
CEC_ADAP_G_PHYS_ADDR, CEC_ADAP_S_PHYS_ADDR - Get or set the physical address
|
||||
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_ADAP_G_PHYS_ADDR, __u16 *argp )
|
||||
:name: CEC_ADAP_G_PHYS_ADDR
|
||||
.. c:macro:: CEC_ADAP_G_PHYS_ADDR
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_ADAP_S_PHYS_ADDR, __u16 *argp )
|
||||
:name: CEC_ADAP_S_PHYS_ADDR
|
||||
``int ioctl(int fd, CEC_ADAP_G_PHYS_ADDR, __u16 *argp)``
|
||||
|
||||
.. c:macro:: CEC_ADAP_S_PHYS_ADDR
|
||||
|
||||
``int ioctl(int fd, CEC_ADAP_S_PHYS_ADDR, __u16 *argp)``
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
``argp``
|
||||
Pointer to the CEC address.
|
||||
|
|
@ -71,7 +73,6 @@ For example, the EDID for each HDMI input of the TV will have a
|
|||
different physical address of the form a.0.0.0 that the sources will
|
||||
read out and use as their physical address.
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _CEC_DQEVENT:
|
||||
|
||||
|
|
@ -11,22 +12,21 @@ Name
|
|||
|
||||
CEC_DQEVENT - Dequeue a CEC event
|
||||
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_DQEVENT, struct cec_event *argp )
|
||||
:name: CEC_DQEVENT
|
||||
.. c:macro:: CEC_DQEVENT
|
||||
|
||||
``int ioctl(int fd, CEC_DQEVENT, struct cec_event *argp)``
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
``argp``
|
||||
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
|
|
@ -72,7 +72,6 @@ it is guaranteed that the state did change in between the two events.
|
|||
the HDMI driver is still configuring the device or because the HDMI
|
||||
device was unbound.
|
||||
|
||||
|
||||
.. c:type:: cec_event_lost_msgs
|
||||
|
||||
.. tabularcolumns:: |p{1.0cm}|p{2.0cm}|p{14.5cm}|
|
||||
|
|
@ -94,7 +93,6 @@ it is guaranteed that the state did change in between the two events.
|
|||
replied to within a second according to the CEC specification,
|
||||
this is more than enough.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{1.0cm}|p{4.4cm}|p{2.5cm}|p{9.6cm}|
|
||||
|
||||
.. c:type:: cec_event
|
||||
|
|
@ -130,7 +128,6 @@ it is guaranteed that the state did change in between the two events.
|
|||
* - }
|
||||
-
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
|
||||
|
||||
.. _cec-events:
|
||||
|
|
@ -204,7 +201,6 @@ it is guaranteed that the state did change in between the two events.
|
|||
if the 5V is high, then an initial event will be generated for that
|
||||
filehandle.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
|
||||
|
||||
.. _cec-event-flags:
|
||||
|
|
@ -230,7 +226,6 @@ it is guaranteed that the state did change in between the two events.
|
|||
This is an indication that the application cannot keep up.
|
||||
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _CEC_MODE:
|
||||
.. _CEC_G_MODE:
|
||||
|
|
@ -13,17 +14,19 @@ CEC_G_MODE, CEC_S_MODE - Get or set exclusive use of the CEC adapter
|
|||
Synopsis
|
||||
========
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_G_MODE, __u32 *argp )
|
||||
:name: CEC_G_MODE
|
||||
.. c:macro:: CEC_G_MODE
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_S_MODE, __u32 *argp )
|
||||
:name: CEC_S_MODE
|
||||
``int ioctl(int fd, CEC_G_MODE, __u32 *argp)``
|
||||
|
||||
.. c:macro:: CEC_S_MODE
|
||||
|
||||
``int ioctl(int fd, CEC_S_MODE, __u32 *argp)``
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
``argp``
|
||||
Pointer to CEC mode.
|
||||
|
|
@ -101,7 +104,6 @@ Available initiator modes are:
|
|||
then an attempt to become one will return the ``EBUSY`` error code
|
||||
error.
|
||||
|
||||
|
||||
Available follower modes are:
|
||||
|
||||
.. tabularcolumns:: |p{6.6cm}|p{0.9cm}|p{10.0cm}|
|
||||
|
|
@ -193,7 +195,6 @@ Available follower modes are:
|
|||
the process has the ``CAP_NET_ADMIN`` capability. If that is not
|
||||
set, then the ``EPERM`` error code is returned.
|
||||
|
||||
|
||||
Core message processing details:
|
||||
|
||||
.. tabularcolumns:: |p{6.6cm}|p{10.9cm}|
|
||||
|
|
@ -272,7 +273,6 @@ Core message processing details:
|
|||
and then just pass the message on to the follower(s).
|
||||
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: CEC
|
||||
|
||||
.. _CEC_TRANSMIT:
|
||||
.. _CEC_RECEIVE:
|
||||
|
|
@ -12,21 +13,22 @@ Name
|
|||
|
||||
CEC_RECEIVE, CEC_TRANSMIT - Receive or transmit a CEC message
|
||||
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_RECEIVE, struct cec_msg \*argp )
|
||||
:name: CEC_RECEIVE
|
||||
.. c:macro:: CEC_RECEIVE
|
||||
|
||||
.. c:function:: int ioctl( int fd, CEC_TRANSMIT, struct cec_msg \*argp )
|
||||
:name: CEC_TRANSMIT
|
||||
``int ioctl(int fd, CEC_RECEIVE, struct cec_msg *argp)``
|
||||
|
||||
.. c:macro:: CEC_TRANSMIT
|
||||
|
||||
``int ioctl(int fd, CEC_TRANSMIT, struct cec_msg *argp)``
|
||||
|
||||
Arguments
|
||||
=========
|
||||
|
||||
``fd``
|
||||
File descriptor returned by :c:func:`open() <cec-open>`.
|
||||
File descriptor returned by :c:func:`open()`.
|
||||
|
||||
``argp``
|
||||
Pointer to struct cec_msg.
|
||||
|
|
@ -194,7 +196,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
|
|||
supports this, otherwise it is always 0. This counter is only
|
||||
valid if the :ref:`CEC_TX_STATUS_ERROR <CEC-TX-STATUS-ERROR>` status bit is set.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{6.2cm}|p{1.0cm}|p{10.3cm}|
|
||||
|
||||
.. _cec-msg-flags:
|
||||
|
|
@ -228,7 +229,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
|
|||
capability. If that is not set, then the ``EPERM`` error code is
|
||||
returned.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
|
||||
|
||||
.. _cec-tx-status:
|
||||
|
|
@ -298,7 +298,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
|
|||
- The transmit timed out. This should not normally happen and this
|
||||
indicates a driver problem.
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}|
|
||||
|
||||
.. _cec-rx-status:
|
||||
|
|
@ -335,7 +334,6 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV').
|
|||
reply was interrupted.
|
||||
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_BILINGUAL_CHANNEL_SELECT:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_BILINGUAL_CHANNEL_SELECT
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_BILINGUAL_CHANNEL_SELECT, struct *audio_channel_select)
|
||||
:name: AUDIO_BILINGUAL_CHANNEL_SELECT
|
||||
.. c:macro:: AUDIO_BILINGUAL_CHANNEL_SELECT
|
||||
|
||||
``int ioctl(int fd, AUDIO_BILINGUAL_CHANNEL_SELECT, struct audio_channel_select *select)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -39,7 +40,6 @@ Arguments
|
|||
|
||||
- Select the output format of the audio (mono left/right, stereo).
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -50,7 +50,6 @@ for MPEG decoders controlled through V4L2.
|
|||
This ioctl call asks the Audio Device to select the requested channel
|
||||
for bilingual streams if possible.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_CHANNEL_SELECT:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_CHANNEL_SELECT
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_CHANNEL_SELECT, struct *audio_channel_select)
|
||||
:name: AUDIO_CHANNEL_SELECT
|
||||
.. c:macro:: AUDIO_CHANNEL_SELECT
|
||||
|
||||
``int ioctl(int fd, AUDIO_CHANNEL_SELECT, struct audio_channel_select *select)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -40,7 +40,6 @@ Arguments
|
|||
|
||||
- Select the output format of the audio (mono left/right, stereo).
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -50,7 +49,6 @@ V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK`` control instead.
|
|||
This ioctl call asks the Audio Device to select the requested channel if
|
||||
possible.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_CLEAR_BUFFER:
|
||||
|
||||
|
|
@ -16,8 +17,9 @@ AUDIO_CLEAR_BUFFER
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_CLEAR_BUFFER)
|
||||
:name: AUDIO_CLEAR_BUFFER
|
||||
.. c:macro:: AUDIO_CLEAR_BUFFER
|
||||
|
||||
``int ioctl(int fd, AUDIO_CLEAR_BUFFER)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -26,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- int fd
|
||||
|
|
@ -39,7 +40,6 @@ Description
|
|||
This ioctl call asks the Audio Device to clear all software and hardware
|
||||
buffers of the audio decoder device.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_CONTINUE:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_CONTINUE
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_CONTINUE)
|
||||
:name: AUDIO_CONTINUE
|
||||
.. c:macro:: AUDIO_CONTINUE
|
||||
|
||||
``int ioctl(int fd, AUDIO_CONTINUE)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- int fd
|
||||
|
|
@ -40,7 +40,6 @@ Description
|
|||
This ioctl restarts the decoding and playing process previously paused
|
||||
with AUDIO_PAUSE command.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _audio_fclose:
|
||||
|
||||
|
|
@ -17,8 +18,6 @@ Synopsis
|
|||
--------
|
||||
|
||||
.. c:function:: int close(int fd)
|
||||
:name: dvb-audio-close
|
||||
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,20 +26,17 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- int fd
|
||||
|
||||
- File descriptor returned by a previous call to open().
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This system call closes a previously opened audio device.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
@ -48,7 +44,6 @@ Return Value
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- ``EBADF``
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _audio_fopen:
|
||||
|
||||
|
|
@ -17,8 +18,6 @@ Synopsis
|
|||
--------
|
||||
|
||||
.. c:function:: int open(const char *deviceName, int flags)
|
||||
:name: dvb-audio-open
|
||||
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +26,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- const char \*deviceName
|
||||
|
|
@ -60,7 +58,6 @@ Arguments
|
|||
-
|
||||
- (blocking mode is the default)
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -78,7 +75,6 @@ fail, and an error code will be returned. If the Audio Device is opened
|
|||
in O_RDONLY mode, the only ioctl call that can be used is
|
||||
AUDIO_GET_STATUS. All other call will return with an error code.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
@ -88,7 +84,6 @@ Return Value
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- ``ENODEV``
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _audio_fwrite:
|
||||
|
||||
|
|
@ -17,8 +18,6 @@ Synopsis
|
|||
--------
|
||||
|
||||
.. c:function:: size_t write(int fd, const void *buf, size_t count)
|
||||
:name: dvb-audio-write
|
||||
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +26,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- int fd
|
||||
|
|
@ -46,7 +44,6 @@ Arguments
|
|||
|
||||
- Size of buf.
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -56,7 +53,6 @@ PES format. If O_NONBLOCK is not specified the function will block
|
|||
until buffer space is available. The amount of data to be transferred is
|
||||
implied by count.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
@ -64,7 +60,6 @@ Return Value
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- ``EPERM``
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_GET_CAPABILITIES:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_GET_CAPABILITIES
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_GET_CAPABILITIES, unsigned int *cap)
|
||||
:name: AUDIO_GET_CAPABILITIES
|
||||
.. c:macro:: AUDIO_GET_CAPABILITIES
|
||||
|
||||
``int ioctl(int fd, AUDIO_GET_CAPABILITIES, unsigned int *cap)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -40,14 +40,12 @@ Arguments
|
|||
|
||||
- Returns a bit array of supported sound formats.
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This ioctl call asks the Audio Device to tell us about the decoding
|
||||
capabilities of the audio hardware.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_GET_STATUS:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_GET_STATUS
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_GET_STATUS, struct audio_status *status)
|
||||
:name: AUDIO_GET_STATUS
|
||||
.. c:macro:: AUDIO_GET_STATUS
|
||||
|
||||
``int ioctl(int fd, AUDIO_GET_STATUS, struct audio_status *status)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -40,14 +40,12 @@ Arguments
|
|||
|
||||
- Returns the current state of Audio Device.
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This ioctl call asks the Audio Device to return the current state of the
|
||||
Audio Device.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_PAUSE:
|
||||
|
||||
|
|
@ -16,8 +17,9 @@ AUDIO_PAUSE
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_PAUSE)
|
||||
:name: AUDIO_PAUSE
|
||||
.. c:macro:: AUDIO_PAUSE
|
||||
|
||||
``int ioctl(int fd, AUDIO_PAUSE)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -26,14 +28,12 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- int fd
|
||||
|
||||
- File descriptor returned by a previous call to open().
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -41,7 +41,6 @@ This ioctl call suspends the audio stream being played. Decoding and
|
|||
playing are paused. It is then possible to restart again decoding and
|
||||
playing process of the audio stream using AUDIO_CONTINUE command.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_PLAY:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_PLAY
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_PLAY)
|
||||
:name: AUDIO_PLAY
|
||||
.. c:macro:: AUDIO_PLAY
|
||||
|
||||
``int ioctl(int fd, AUDIO_PLAY)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- int fd
|
||||
|
|
@ -40,7 +40,6 @@ Description
|
|||
This ioctl call asks the Audio Device to start playing an audio stream
|
||||
from the selected source.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_SELECT_SOURCE:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_SELECT_SOURCE
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_SELECT_SOURCE, struct audio_stream_source *source)
|
||||
:name: AUDIO_SELECT_SOURCE
|
||||
.. c:macro:: AUDIO_SELECT_SOURCE
|
||||
|
||||
``int ioctl(int fd, AUDIO_SELECT_SOURCE, struct audio_stream_source *source)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -40,7 +40,6 @@ Arguments
|
|||
|
||||
- Indicates the source that shall be used for the Audio stream.
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -49,7 +48,6 @@ the input data. The possible sources are demux or memory. If
|
|||
AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device
|
||||
through the write command.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_SET_AV_SYNC:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_SET_AV_SYNC
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_SET_AV_SYNC, boolean state)
|
||||
:name: AUDIO_SET_AV_SYNC
|
||||
.. c:macro:: AUDIO_SET_AV_SYNC
|
||||
|
||||
``int ioctl(int fd, AUDIO_SET_AV_SYNC, boolean state)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -44,14 +44,12 @@ Arguments
|
|||
|
||||
FALSE: AV-sync OFF
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This ioctl call asks the Audio Device to turn ON or OFF A/V
|
||||
synchronization.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_SET_BYPASS_MODE:
|
||||
|
||||
|
|
@ -16,8 +17,9 @@ AUDIO_SET_BYPASS_MODE
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_SET_BYPASS_MODE, boolean mode)
|
||||
:name: AUDIO_SET_BYPASS_MODE
|
||||
.. c:macro:: AUDIO_SET_BYPASS_MODE
|
||||
|
||||
``int ioctl(int fd, AUDIO_SET_BYPASS_MODE, boolean mode)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -26,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -44,7 +45,6 @@ Arguments
|
|||
|
||||
FALSE: Bypass is enabled
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -54,7 +54,6 @@ that can’t be handled by the Digital TV system shall be decoded. Dolby
|
|||
DigitalTM streams are automatically forwarded by the Digital TV subsystem if
|
||||
the hardware can handle it.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_SET_ID:
|
||||
|
||||
|
|
@ -16,8 +17,9 @@ AUDIO_SET_ID
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_SET_ID, int id)
|
||||
:name: AUDIO_SET_ID
|
||||
.. c:macro:: AUDIO_SET_ID
|
||||
|
||||
``int ioctl(int fd, AUDIO_SET_ID, int id)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -26,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -39,7 +40,6 @@ Arguments
|
|||
|
||||
- audio sub-stream id
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -51,7 +51,6 @@ other stream types. If the stream type is set the id just specifies the
|
|||
substream id of the audio stream and only the first 5 bits are
|
||||
recognized.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_SET_MIXER:
|
||||
|
||||
|
|
@ -16,8 +17,9 @@ AUDIO_SET_MIXER
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_SET_MIXER, struct audio_mixer *mix)
|
||||
:name: AUDIO_SET_MIXER
|
||||
.. c:macro:: AUDIO_SET_MIXER
|
||||
|
||||
``int ioctl(int fd, AUDIO_SET_MIXER, struct audio_mixer *mix)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -26,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -39,13 +40,11 @@ Arguments
|
|||
|
||||
- mixer settings.
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This ioctl lets you adjust the mixer settings of the audio decoder.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_SET_MUTE:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_SET_MUTE
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_SET_MUTE, boolean state)
|
||||
:name: AUDIO_SET_MUTE
|
||||
.. c:macro:: AUDIO_SET_MUTE
|
||||
|
||||
``int ioctl(int fd, AUDIO_SET_MUTE, boolean state)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -44,7 +44,6 @@ Arguments
|
|||
|
||||
FALSE: Audio Un-mute
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -55,7 +54,6 @@ V4L2 :ref:`VIDIOC_DECODER_CMD` with the
|
|||
This ioctl call asks the audio device to mute the stream that is
|
||||
currently being played.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_SET_STREAMTYPE:
|
||||
|
||||
|
|
@ -16,9 +17,9 @@ AUDIO_SET_STREAMTYPE
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(fd, AUDIO_SET_STREAMTYPE, int type)
|
||||
:name: AUDIO_SET_STREAMTYPE
|
||||
.. c:macro:: AUDIO_SET_STREAMTYPE
|
||||
|
||||
``int ioctl(fd, AUDIO_SET_STREAMTYPE, int type)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -27,7 +28,6 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
-
|
||||
|
||||
- int fd
|
||||
|
|
@ -40,7 +40,6 @@ Arguments
|
|||
|
||||
- stream type
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -48,7 +47,6 @@ This ioctl tells the driver which kind of audio stream to expect. This
|
|||
is useful if the stream offers several audio sub-streams like LPCM and
|
||||
AC3.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
@ -57,12 +55,10 @@ appropriately. The generic error codes are described at the
|
|||
:ref:`Generic Error Codes <gen-errors>` chapter.
|
||||
|
||||
|
||||
|
||||
.. flat-table::
|
||||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- ``EINVAL``
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.audio
|
||||
|
||||
.. _AUDIO_STOP:
|
||||
|
||||
|
|
@ -16,8 +17,9 @@ AUDIO_STOP
|
|||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(int fd, AUDIO_STOP)
|
||||
:name: AUDIO_STOP
|
||||
.. c:macro:: AUDIO_STOP
|
||||
|
||||
``int ioctl(int fd, AUDIO_STOP)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -26,21 +28,18 @@ Arguments
|
|||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
|
||||
|
||||
- .. row 1
|
||||
|
||||
- int fd
|
||||
|
||||
- File descriptor returned by a previous call to open().
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This ioctl call asks the Audio Device to stop playing the current
|
||||
stream.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.ca
|
||||
|
||||
.. _ca_fclose:
|
||||
|
||||
|
|
@ -11,26 +12,22 @@ Name
|
|||
|
||||
Digital TV CA close()
|
||||
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int close(int fd)
|
||||
:name: dvb-ca-close
|
||||
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
||||
``fd``
|
||||
File descriptor returned by a previous call to :c:func:`open() <dvb-ca-open>`.
|
||||
File descriptor returned by a previous call to :c:func:`open()`.
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This system call closes a previously opened CA device.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.ca
|
||||
|
||||
.. _ca_fopen:
|
||||
|
||||
|
|
@ -11,13 +12,10 @@ Name
|
|||
|
||||
Digital TV CA open()
|
||||
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int open(const char *name, int flags)
|
||||
:name: dvb-ca-open
|
||||
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
|
@ -45,7 +43,6 @@ Arguments
|
|||
- open in non-blocking mode
|
||||
(blocking mode is the default)
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
@ -63,11 +60,9 @@ Only one user can open the CA Device in ``O_RDWR`` mode. All other
|
|||
attempts to open the device in this mode will fail, and an error code
|
||||
will be returned.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
||||
On success 0 is returned.
|
||||
|
||||
On error -1 is returned, and the ``errno`` variable is set
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.ca
|
||||
|
||||
.. _CA_GET_CAP:
|
||||
|
||||
|
|
@ -11,19 +12,18 @@ Name
|
|||
|
||||
CA_GET_CAP
|
||||
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(fd, CA_GET_CAP, struct ca_caps *caps)
|
||||
:name: CA_GET_CAP
|
||||
.. c:macro:: CA_GET_CAP
|
||||
|
||||
``int ioctl(fd, CA_GET_CAP, struct ca_caps *caps)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
||||
``fd``
|
||||
File descriptor returned by a previous call to :c:func:`open() <dvb-ca-open>`.
|
||||
File descriptor returned by a previous call to :c:func:`open()`.
|
||||
|
||||
``caps``
|
||||
Pointer to struct :c:type:`ca_caps`.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.ca
|
||||
|
||||
.. _CA_GET_DESCR_INFO:
|
||||
|
||||
|
|
@ -11,18 +12,18 @@ Name
|
|||
|
||||
CA_GET_DESCR_INFO
|
||||
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(fd, CA_GET_DESCR_INFO, struct ca_descr_info *desc)
|
||||
:name: CA_GET_DESCR_INFO
|
||||
.. c:macro:: CA_GET_DESCR_INFO
|
||||
|
||||
``int ioctl(fd, CA_GET_DESCR_INFO, struct ca_descr_info *desc)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
||||
``fd``
|
||||
File descriptor returned by a previous call to :c:func:`open() <dvb-ca-open>`.
|
||||
File descriptor returned by a previous call to :c:func:`open()`.
|
||||
|
||||
``desc``
|
||||
Pointer to struct :c:type:`ca_descr_info`.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
|
||||
.. c:namespace:: DTV.ca
|
||||
|
||||
.. _CA_GET_MSG:
|
||||
|
||||
|
|
@ -11,19 +12,18 @@ Name
|
|||
|
||||
CA_GET_MSG
|
||||
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
.. c:function:: int ioctl(fd, CA_GET_MSG, struct ca_msg *msg)
|
||||
:name: CA_GET_MSG
|
||||
.. c:macro:: CA_GET_MSG
|
||||
|
||||
``int ioctl(fd, CA_GET_MSG, struct ca_msg *msg)``
|
||||
|
||||
Arguments
|
||||
---------
|
||||
|
||||
``fd``
|
||||
File descriptor returned by a previous call to :c:func:`open() <dvb-ca-open>`.
|
||||
File descriptor returned by a previous call to :c:func:`open()`.
|
||||
|
||||
``msg``
|
||||
Pointer to struct :c:type:`ca_msg`.
|
||||
|
|
@ -38,11 +38,9 @@ Receives a message via a CI CA module.
|
|||
Please notice that, on most drivers, this is done by reading from
|
||||
the /dev/adapter?/ca? device node.
|
||||
|
||||
|
||||
Return Value
|
||||
------------
|
||||
|
||||
|
||||
On success 0 is returned.
|
||||
|
||||
On error -1 is returned, and the ``errno`` variable is set
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue