From: Jonathan Cameron <jic23@cam.ac.uk>
To: Manuel Stahl <manuel.stahl@iis.fraunhofer.de>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH 1/3] staging:iio update documentation
Date: Mon, 30 Aug 2010 15:49:00 +0100 [thread overview]
Message-ID: <4C7BC4DC.50900@cam.ac.uk> (raw)
In-Reply-To: <4C7BBF16.1060502@iis.fraunhofer.de>
Hi Manel
>>>
>>> +What: /sys/.../device[n]/buffer/scan_elements
>> Is this not /sys/.../device[n]/buffer[m]/scan_elements? I think we allow
>> for multiple buffers per device.
>>> +KernelVersion: 2.6.37
>>> +Contact: linux-iio@vger.kernel.org
>>> +Description:
>>> + Directory containing interfaces for elements that will be captured
>>> + for a single triggered sample set in the buffer.
>>> +
>>> +What: /sys/.../device[n]/buffer/scan_elements/[m]_accel_x0_en
>> This needs some brackets... [_x0]
>
> Depends on what we accord for the next version, there should be a patch removing the [m] and creating all the new files.
As I said in the other discussion. That m (or direct equivalent) is vital. Otherwise userspace has no way of knowing
the parameter ordering in what comes out of the buffer. As things stand I haven't yet seen
any reason (beyond ls putting them in a nice order) for changing that element of the interface.
The brackets issue here is completely separate. We have always allowed single dimension accelerometers
to not specify a direction. And there are dual parallel accelerometer chips out there hence the need for
the optional number.
>
>>> +KernelVersion: 2.6.37
>>> +Contact: linux-iio@vger.kernel.org
>>> +Description:
>>> + Scan element control for triggered data capture. m implies the
>>> + ordering within the buffer. Next the type is specified with
>>> + modifier and channel number as per the sysfs single channel
>>> + access above.
>>> +
>> Obviously the next two will get eaten up by your suggestion of 'type' the other
>> day, but best to keep the documentation matching what is actually in place so
>> I'm glad to see you updated them.
>>> +What: /sys/.../device[n]/buffer/scan_elements/accel[_x0]_precision
>>> +KernelVersion: 2.6.37
>>> +Contact: linux-iio@vger.kernel.org
>>> +Description:
>>> + Scan element precision within the buffer. Note that the
>>> + data alignment must restrictions must be read from within
>>> + buffer to work out full data alignment for data read
>>> + via buffer_access chrdev. _x0 dropped if shared across all
>>> + acceleration channels.
>>> +
>>> +What: /sys/.../device[n]/buffer/scan_elements/accel[_x0]_shift
>>> +KernelVersion: 2.6.37
>>> +Contact: linux-iio@vger.kernel.org
>>> +Description:
>>> + A bit shift (to right) that must be applied prior to
>>> + extracting the bits specified by accel[_x0]_precision.
>>> +
>>> diff --git a/drivers/staging/iio/Documentation/userspace.txt b/drivers/staging/iio/Documentation/userspace.txt
>>> index 4838818..8bba2fa 100644
>>> --- a/drivers/staging/iio/Documentation/userspace.txt
>>> +++ b/drivers/staging/iio/Documentation/userspace.txt
>>> @@ -7,17 +7,14 @@ Typical sysfs entries (pruned for clarity)
>>> /sys/class/iio
>>> device0 - iio_dev related elements
>>> name - driver specific identifier (here lis3l02dq)
>>> - accel_x - polled (or from ring) raw readout of acceleration
>>> - accel_x_gain - hardware gain (calibration)
>>> - accel_x_offset - hardware offset (calibration)
>>> - available_sampling_frequency
>>> + accel_x_raw - polled (or from ring) raw readout of acceleration
>>> + accel_x_offset - offset to be applied to the raw reading
>>> + accel_x_scale - scale to be applied to the raw reading and offset
>>> + accel_x_calibbias - hardware offset (calibration)
>>> + accel_x_calibscale - hardware gain (calibration)
>> youch, Hadn't realised how out of date some of this has gotten.
>>
>> Actually we can probably drop most of this file. It just replicates
>> the abi documentation (and predates it). Shall I do that once
>> your changes have merged, or do you want to loose everything down
>> to the Udev will create line? Perhaps add something saying the sysfs
>> stuff is documented in the abi file?
>
> Would be great if you do another docu review patch afterwards.
Cool, will do. Then send this patch on as is with my
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Perhaps naming it staging:iio partial documentation update
just to stop anyone pointing out that the documentation isn't perfect
after your patch!
Jonathan
next prev parent reply other threads:[~2010-08-30 14:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-27 8:57 [IIO] Cleanup userspace Manuel Stahl
[not found] ` <4C77AC01.3090204@cam.ac.uk>
[not found] ` <4C77B68B.4060805@iis.fraunhofer.de>
2010-08-27 14:24 ` Jonathan Cameron
2010-08-27 14:31 ` Manuel Stahl
2010-08-27 15:09 ` Jonathan Cameron
2010-08-30 10:55 ` [PATCH 1/2] staging:iio rename ring attributes Manuel Stahl
2010-08-30 12:28 ` Jonathan Cameron
2010-08-30 10:55 ` [PATCH 2/2] staging:iio move scan_elements into ring buffer Manuel Stahl
2010-08-30 12:58 ` Jonathan Cameron
2010-08-30 13:37 ` Manuel Stahl
2010-08-30 14:09 ` Jonathan Cameron
[not found] ` <4C7BD886.3060109@cam.ac.uk>
2010-08-30 16:31 ` Manuel Stahl
2010-08-30 16:48 ` Jonathan Cameron
2010-08-30 14:03 ` [PATCH 1/3] staging:iio update documentation Manuel Stahl
2010-08-30 14:23 ` Jonathan Cameron
2010-08-30 14:24 ` Manuel Stahl
2010-08-30 14:49 ` Jonathan Cameron [this message]
2010-08-30 14:03 ` [PATCH 2/3] staging:iio sync drivers with current ABI Manuel Stahl
2010-08-30 14:44 ` Jonathan Cameron
2010-08-30 15:00 ` Manuel Stahl
2010-08-30 15:42 ` Jonathan Cameron
2010-08-30 15:48 ` Manuel Stahl
2010-08-30 16:07 ` Jonathan Cameron
2010-08-30 16:28 ` Manuel Stahl
2010-08-30 16:43 ` Jonathan Cameron
2010-08-30 14:03 ` [PATCH 3/3] staging:iio:hmc5843 change ABI to comply with documentation Manuel Stahl
2010-08-30 14:58 ` Jonathan Cameron
2010-08-31 12:16 ` Datta, Shubhrajyoti
2010-09-04 17:26 ` [IIO] Cleanup userspace Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C7BC4DC.50900@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=linux-iio@vger.kernel.org \
--cc=manuel.stahl@iis.fraunhofer.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.