Documentation/driver-api/generic-counter.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/generic-counter.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/generic-counter.rst- Extension
.rst- Size
- 24879 bytes
- Lines
- 574
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
=========================
Generic Counter Interface
=========================
Introduction
============
Counter devices are prevalent among a diverse spectrum of industries.
The ubiquitous presence of these devices necessitates a common interface
and standard of interaction and exposure. This driver API attempts to
resolve the issue of duplicate code found among existing counter device
drivers by introducing a generic counter interface for consumption. The
Generic Counter interface enables drivers to support and expose a common
set of components and functionality present in counter devices.
Theory
======
Counter devices can vary greatly in design, but regardless of whether
some devices are quadrature encoder counters or tally counters, all
counter devices consist of a core set of components. This core set of
components, shared by all counter devices, is what forms the essence of
the Generic Counter interface.
There are three core components to a counter:
* Signal:
Stream of data to be evaluated by the counter.
* Synapse:
Association of a Signal, and evaluation trigger, with a Count.
* Count:
Accumulation of the effects of connected Synapses.
SIGNAL
------
A Signal represents a stream of data. This is the input data that is
evaluated by the counter to determine the count data; e.g. a quadrature
signal output line of a rotary encoder. Not all counter devices provide
user access to the Signal data, so exposure is optional for drivers.
When the Signal data is available for user access, the Generic Counter
interface provides the following available signal values:
* SIGNAL_LOW:
Signal line is in a low state.
* SIGNAL_HIGH:
Signal line is in a high state.
A Signal may be associated with one or more Counts.
SYNAPSE
-------
A Synapse represents the association of a Signal with a Count. Signal
data affects respective Count data, and the Synapse represents this
relationship.
The Synapse action mode specifies the Signal data condition that
triggers the respective Count's count function evaluation to update the
count data. The Generic Counter interface provides the following
available action modes:
* None:
Signal does not trigger the count function. In Pulse-Direction count
function mode, this Signal is evaluated as Direction.
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.