drivers/staging/iio/Documentation/inkernel.txt
Source file repositories/reference/linux-study-clean/drivers/staging/iio/Documentation/inkernel.txt
File Facts
- System
- Linux kernel
- Corpus path
drivers/staging/iio/Documentation/inkernel.txt- Extension
.txt- Size
- 2184 bytes
- Lines
- 59
- Domain
- Driver Families
- Bucket
- drivers/staging
- Inferred role
- Driver Families: documentation
- Status
- atlas-only
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- 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
struct iio_map
Annotated Snippet
struct iio_map {
const char *adc_channel_label;
const char *consumer_dev_name;
const char *consumer_channel;
};
adc_channel_label identifies the channel on the IIO device by being
matched against the datasheet_name field of the iio_chan_spec.
consumer_dev_name allows identification of the consumer device.
This are then used to find the channel mapping from the consumer device (see
below).
Finally consumer_channel is a string identifying the channel to the consumer.
(Perhaps 'battery_voltage' or similar).
An array of these structures is then passed to the IIO driver.
Supporting in kernel interfaces in the driver (driver.h)
The driver must provide datasheet_name values for its channels and
must pass the iio_map structures and a pointer to its own iio_dev structure
on to the core via a call to iio_map_array_register. On removal,
iio_map_array_unregister reverses this process.
The result of this is that the IIO core now has all the information needed
to associate a given channel with the consumer requesting it.
Acting as an IIO consumer (consumer.h)
The consumer first has to obtain an iio_channel structure from the core
by calling iio_channel_get(). The correct channel is identified by:
* matching dev or dev_name against consumer_dev and consumer_dev_name
* matching consumer_channel against consumer_channel in the map
There are then a number of functions that can be used to get information
about this channel such as it's current reading.
e.g.
iio_read_channel_raw() - get a reading
iio_get_channel_type() - get the type of channel
There is also provision for retrieving all of the channels associated
with a given consumer. This is useful for generic drivers such as
iio_hwmon where the number and naming of channels is not known by the
consumer driver. To do this, use iio_channel_get_all.
Annotation
- Detected declarations: `struct iio_map`.
- Atlas domain: Driver Families / drivers/staging.
- 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.