drivers/iio/magnetometer/yamaha-yas530.c
Source file repositories/reference/linux-study-clean/drivers/iio/magnetometer/yamaha-yas530.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/iio/magnetometer/yamaha-yas530.c- Extension
.c- Size
- 46503 bytes
- Lines
- 1614
- Domain
- Driver Families
- Bucket
- drivers/iio
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/bitfield.hlinux/bitops.hlinux/delay.hlinux/err.hlinux/gpio/consumer.hlinux/i2c.hlinux/module.hlinux/mod_devicetable.hlinux/mutex.hlinux/pm_runtime.hlinux/property.hlinux/regmap.hlinux/regulator/consumer.hlinux/random.hlinux/units.hlinux/iio/buffer.hlinux/iio/iio.hlinux/iio/trigger_consumer.hlinux/iio/triggered_buffer.hlinux/unaligned.h
Detected Declarations
struct yas5xx_calibrationstruct yas5xxstruct yas5xx_chip_infostruct yas5xxenum chip_idsfunction yas530_extract_axisfunction yas532_extract_axisfunction yas530_measurefunction yas537_measurefunction yas530_linearizefunction yas5xx_calc_temperaturefunction yas530_get_measurefunction yas537_get_measurefunction yas5xx_read_rawfunction yas5xx_fill_bufferfunction yas5xx_handle_triggerfunction yas5xx_get_mount_matrixfunction yas5xx_volatile_regfunction yas530_extract_calibrationfunction yas530_get_calibration_datafunction yas532_get_calibration_datafunction yas537_get_calibration_datafunction yas530_dump_calibrationfunction yas537_dump_calibrationfunction yas530_set_offsetsfunction yas530_adjust_offsetfunction yas530_measure_offsetsfunction yas530_power_onfunction yas537_power_onfunction yas5xx_probefunction yas5xx_removefunction yas5xx_runtime_suspendfunction yas5xx_runtime_resume
Annotated Snippet
struct yas5xx_calibration {
/* Linearization calibration x, y1, y2 */
s32 r[3];
u32 f[3];
/* Temperature compensation calibration */
s16 Cx, Cy1, Cy2;
/* Misc calibration coefficients */
s8 a2, a3, a4, a6, a7, a8;
s16 a5, a9;
u8 k;
/* clock divider */
u8 dck;
};
struct yas5xx;
/**
* struct yas5xx_chip_info - device-specific data and function pointers
* @devid: device ID number
* @product_name: product name of the YAS variant
* @version_names: version letters or namings
* @volatile_reg: device-specific volatile registers
* @volatile_reg_qty: quantity of device-specific volatile registers
* @scaling_val2: scaling value for IIO_CHAN_INFO_SCALE
* @t_ref: number of counts at reference temperature 20 °C
* @min_temp_x10: starting point of temperature counting in 1/10:s degrees Celsius
* @get_measure: function pointer to get a measurement
* @get_calibration_data: function pointer to get calibration data
* @dump_calibration: function pointer to dump calibration for debugging
* @measure_offsets: function pointer to measure the offsets
* @power_on: function pointer to power-on procedure
*
* The "t_ref" value for YAS532/533 is known from the Android driver.
* For YAS530 and YAS537 it was approximately measured.
*
* The temperatures "min_temp_x10" are derived from the temperature resolutions
* given in the data sheets.
*/
struct yas5xx_chip_info {
unsigned int devid;
const char *product_name;
const char *version_names[2];
const int *volatile_reg;
int volatile_reg_qty;
u32 scaling_val2;
u16 t_ref;
s16 min_temp_x10;
int (*get_measure)(struct yas5xx *yas5xx, s32 *to, s32 *xo, s32 *yo, s32 *zo);
int (*get_calibration_data)(struct yas5xx *yas5xx);
void (*dump_calibration)(struct yas5xx *yas5xx);
int (*measure_offsets)(struct yas5xx *yas5xx);
int (*power_on)(struct yas5xx *yas5xx);
};
/**
* struct yas5xx - state container for the YAS5xx driver
* @dev: parent device pointer
* @chip_info: device-specific data and function pointers
* @version: device version
* @calibration: calibration settings from the OTP storage
* @hard_offsets: offsets for each axis measured with initcoil actuated
* @orientation: mounting matrix, flipped axis etc
* @map: regmap to access the YAX5xx registers over I2C
* @regs: the vdd and vddio power regulators
* @reset: optional GPIO line used for handling RESET
* @lock: locks the magnetometer for exclusive use during a measurement (which
* involves several register transactions so the regmap lock is not enough)
* so that measurements get serialized in a first-come-first serve manner
* @scan: naturally aligned measurements
*/
struct yas5xx {
struct device *dev;
const struct yas5xx_chip_info *chip_info;
unsigned int version;
struct yas5xx_calibration calibration;
s8 hard_offsets[3];
struct iio_mount_matrix orientation;
struct regmap *map;
struct regulator_bulk_data regs[2];
struct gpio_desc *reset;
struct mutex lock;
/*
* The scanout is 4 x 32 bits in CPU endianness.
* Ensure timestamp is naturally aligned
*/
struct {
s32 channels[4];
aligned_s64 ts;
} scan;
};
Annotation
- Immediate include surface: `linux/bitfield.h`, `linux/bitops.h`, `linux/delay.h`, `linux/err.h`, `linux/gpio/consumer.h`, `linux/i2c.h`, `linux/module.h`, `linux/mod_devicetable.h`.
- Detected declarations: `struct yas5xx_calibration`, `struct yas5xx`, `struct yas5xx_chip_info`, `struct yas5xx`, `enum chip_ids`, `function yas530_extract_axis`, `function yas532_extract_axis`, `function yas530_measure`, `function yas537_measure`, `function yas530_linearize`.
- Atlas domain: Driver Families / drivers/iio.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.