This is intended to be a quick list of event attributes by device. Used to verify if proposed naming scheme works. Far from all of these have been implemented as yet.
Unusual elements are in italics.
Note we include several devices in this list that are from other areas of the kernel.
- accel_x&y&z_mag_falling_en (free fall, _value is unknown, clarification to be sought from VTI).
- accel_mag_value This value applies to all of the above events. Hence no direction as it covers both.
Not support currently but in theory this part can do...
and really awkwardly... For now I'm just going to ignore these special features.
Similar to lis3l02dq but with _period and 2 separate alarms... Intended I would imagine to support a motion detector and a free fall detector. Also has a 6D position and a 6d motion detector event. Neither is described in the datasheet. All other recent ST parts look similar.
- accel_x|y|z_mag_rising_available (small and discrete set)
A few complexities around the ability to switch mode based on these events.
bma150 This is a bit speculative. It is a somewhat hard to read datasheet. I think the any_motion stuff is a ROC detector and the HG and LG detectors are rather complex threshold detectors.
for adis16201 <channel> = in0_supply|accel_x|accel_y|in1|temp|incli_x|incli_y
for adis16203 <channel> = in0_supply|in1|temp|incli0|incli1 (oddity is that the two inclinations are just the same thing represented subtly differently)
for adis16209 <channel> = in0_supply|accel_x|accel_y|in1|temp|incli_x|incli_y|rot
The interaction between the alarms and triggering of data capture is complex on these parts. Naming however is not a problem, just whether it is the job of the associated trigger to handle these or the device. The adis16220 can do alarms as normal if the device is in a manual, or a period based sampling mode.
- accel_single_tap_en (naming not at all fixed for this yet)
- accel_double_tap (these are tricky as they also have axis combinations to cover)
Any combination of the following (have to be separate as single bit to describe what is happening.) Note only the first one to happen will trigger an interrupt. This naming only works for DC coupling. What do we do for AC coupling (remove value from when motion detection was initialized before doing the threshold comparison?)
- accel_mag_rising_value (covers all of the 'activity' detector combinations, so all the mag_rising events).
- accel_x&y&z_falling_en (free fall detector)
Inertial Measurement Units
ADIS16300, ADIS1635x, ADIS1636x, ADIS16400
Where (some not for all parts) <channel> = in0_supply, gyro_x, gyro_y, gyro_z, accel_x, accel_y, accel_z, magn_x, magn_y, magn_z, temp, temp_x, temp_y, temp_z, in1
tsl2550 no interrupts.
tsl256x, tsl258x(I think)
Not implemented, but there is period support.
tmd2711x from Donggeun Kim's proposed driver. tsl2771 looks very similar.
max1363 etc (only channel 0 related attrs specified here)
(some of the above actually correspond to the same thing)
ad7993/4/7/8, ad7992 (for selected channels) Can enable / disable, by switching these to max and min storage. ad7291 (similar I think, but with a temp channel that has mean period and straight value versions).
- in0_thresh_hysteresis This is reset of the interrupt. Not certain how we want to handle this.
ad7291 similar to ad7993, but
- temp_thresh_rising_en (not actually sure these can be disabled)
Also a difference from mean temp based version (on same input channel)
- temp_trackingthresh_filter... (information about the filter used to do the value tracking. May need to have type
defined then relevant parameters.
Firstly conventional linear thresholds
Now relative to low pass filtered version
- in0_trackingthresh_value (sensitivity on datasheet)
- in0_trackingthresh_offset_filter_... Parameters related to the value tracking filter. (Data average, time out)