In the great tradition of replying to ones own patches... ... > + > +What: /sys/.../device[n]/device[n]:event[m] > +KernelVersion: 2.6.35 > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + Configuration of which hardware generated events are passed up to > + userspace. Some of these are a bit complex to generalize so this > + section is a work in progress. > + > +What: /sys/.../device[n]:event[m]/dev > +KernelVersion: 2.6.35 > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + major:minor character device numbers for the event line. > + > +Taking accel_x0 as an example > + > +What: /sys/.../device[n]:event[m]/accel_x0_thresh[_high|_low] > +KernelVersion: 2.6.35 > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + Event generated when accel_x0 passes a threshold in correction direction > + (or stays beyond one). If direction isn't specified, either triggers it. > + Note driver will assume last p events requested are enabled where p is > + however many it supports. So if you want to be sure you have > + set what you think you have, check the contents of these. Drivers > + may have to buffer any parameters so that they are consistent when a > + given event type is enabled a future point (and not those for whatever > + alarm was previously enabled). > + > +What: /sys/.../device[n]:event[m]/accel_x0_roc[_high|_low] > +KernelVersion: 2.6.35 > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + Same as above but based on the first differential of the value. > + > + > +What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_period > +KernelVersion: 2.6.35 > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + A period of time (microsecs) for which the condition must be broken > + before an interrupt is triggered. Applies to all alarms if type is not > + specified. > + > +What: /sys/.../device[n]:event[m]/accel_x0[_thresh|_roc][_high|_low]_value > +KernelVersion: 2.6.35 > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + The actual value of the threshold in raw device units obtained by > + reverse application of scale and offfset to the acceleration in m/s^2. > + These names don't actually conform to those I sent out out in the RFC following the the main ABI posting and just for a complete inconsistency the naming in lis3l02dq doesn't conform to either version. I haven't yet checked the other drivers, but I would guess they are a random mix of the various options as well. Oops. I'll fix this up for V2. Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
