lkml.org 
[lkml]   [2010]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [IIO] Proposal for sysfs attributes
    On 09/06/10 09:41, Manuel Stahl wrote:
    > Hi all,
    >
    > there were some sysfs userspace questions on linux-iio where we would like to get some more comments on.
    >
    > First thing, there are some attributes describing the layout of a
    > ring buffer that can be read out via a char device. The buffer
    > contains several entries with each containing so called scan
    > elements. All entries have the same layout. It is described in a
    > directory scan_elements (see below) that contains three attributes
    > per scan element.
    >
    >> OK, no packed buffers for now, but we should implement variable
    >> sample sizes for standard types. Indeed we already have this for
    >> the timestamp, which is always 64 bit.
    >>
    >> To be compatible with future extensions we could have:
    >> |- /sys/bus/iio/device0/buffer0/scan_elements/
    >> |- accel_x_en (0 or 1)
    >> |- accel_x_type (i.e. s14/16, see *)
    >> |- accel_x_index (position inside the buffer entry)
    >>
    >> * s14/16 means signed 14 bits, stored in 16 bits, right aligned.
    >> If it's left aligned we can just modify the scale attribute and
    >> give the 16 bit interpretation in <channel>_raw.
    >
    > Is the 's14/16' self explaining or should we use some other format?
    > Is 'type' a good postfix for the attribute?

    One additional point here. What we currently have that the enable
    parameters are currently [m]_accel_x_en etc with m being an indicator
    of the position of a parameter within the buffer. Note not all channels
    are enabled at a time. For all devices we have so far, the ordering
    is fixed, so this naming is constant. Basically we roll the accel_x_index
    attribute into the naming of the enable attribute. Manuel, could you summarize
    what you have against that approach? (I'm not particularly tied to it, but
    it is in place and it does work).
    >
    >
    > Next question: how strictly we want to resamble the hwmon ABI?
    >
    > To sum up the discussion:
    > Hwmon has files with the postfix _input to read values scaled to
    > reasonable units for fixed point representation. So the units are
    > sometimes scaled down to 'millis' e.g. millivolt, millidegree Celsius.
    > We agreed that we want to keep this, whenever we use the _input postfix.
    > For IIO there is also the postfix triple _raw, _scale and _offset,
    > where the final value is calculated by (_raw + _offset) * _scale.
    > Floating point values are allowed for any of these files.
    (other than _raw obviously!)
    >
    > The question in place was:
    > Do we want to resemble the 'milli' units or should we stick to
    > standard SI units (radians, kelvin, etc.) as floating point math is
    > necessary anyway.
    I've cc'd a few people who have contributed to previous abi discussions
    for IIO in ways that make me think they may have opinions on this.



    \
     
     \ /
      Last update: 2010-09-06 14:59    [W:2.880 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site