| Message ID | 1457360997-29179-2-git-send-email-ludovic.desroches@atmel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 03/07/2016 03:29 PM, Ludovic Desroches wrote: > The same channel can be used to perform a signed or an unsigned > conversion. Add a new infomask element to be able to select the type of > conversion wanted: a raw one or a signed raw one. If this is the difference between offset binary and two's complement then it makes no sense to expose this at this level. Both are the same number just in a different representation and converting between them is cheap. A few magnitudes cheaper than reading the result over sysfs. So, if your device supports both, just pick one. For the buffered interface it may make sense to expose this, since the per sample overhead is a lot lower. But still doing the conversion should be cheap enough that it does not really matter. Before this is implemented I'd like to see hard performance numbers that this actually makes a difference. - Lars
On 07/03/16 20:09, Lars-Peter Clausen wrote: > On 03/07/2016 03:29 PM, Ludovic Desroches wrote: >> The same channel can be used to perform a signed or an unsigned >> conversion. Add a new infomask element to be able to select the type of >> conversion wanted: a raw one or a signed raw one. > > If this is the difference between offset binary and two's complement then it > makes no sense to expose this at this level. Both are the same number just > in a different representation and converting between them is cheap. A few > magnitudes cheaper than reading the result over sysfs. So, if your device > supports both, just pick one. > > For the buffered interface it may make sense to expose this, since the per > sample overhead is a lot lower. But still doing the conversion should be > cheap enough that it does not really matter. Before this is implemented I'd > like to see hard performance numbers that this actually makes a difference. > > - Lars > Definitely looking for more detail on this. I'd missed we were talking simply about representation (which is also how I read 62.6.6 Conversion Results Format in the datasheet). Not entirely sure what I imagined the difference between signed and unsigned output would be! Jonathan
On Wed, Mar 09, 2016 at 09:04:21PM +0000, Jonathan Cameron wrote: > On 07/03/16 20:09, Lars-Peter Clausen wrote: > > On 03/07/2016 03:29 PM, Ludovic Desroches wrote: > >> The same channel can be used to perform a signed or an unsigned > >> conversion. Add a new infomask element to be able to select the type of > >> conversion wanted: a raw one or a signed raw one. > > > > If this is the difference between offset binary and two's complement then it > > makes no sense to expose this at this level. Both are the same number just > > in a different representation and converting between them is cheap. A few > > magnitudes cheaper than reading the result over sysfs. So, if your device > > supports both, just pick one. > > > > For the buffered interface it may make sense to expose this, since the per > > sample overhead is a lot lower. But still doing the conversion should be > > cheap enough that it does not really matter. Before this is implemented I'd > > like to see hard performance numbers that this actually makes a difference. > > > > - Lars > > > Definitely looking for more detail on this. I'd missed we were talking simply > about representation (which is also how I read 62.6.6 Conversion Results Format > in the datasheet). Not entirely sure what I imagined the difference between > signed and unsigned output would be! You are both right, it is only about representation. I have asked hardware guys why they add this feature. They told me it is for convenience and because some librairies need signed results. Regards Ludovic
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 3c66248..161733c 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1501,3 +1501,13 @@ Contact: linux-iio@vger.kernel.org Description: Raw (unscaled no offset etc.) pH reading of a substance as a negative base-10 logarithm of hydrodium ions in a litre of water. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_signed +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_signed +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_signed +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_signed +KernelVersion: 4.7 +Contact: linux-iio@vger.kernel.org +Description: + Signed (unscaled no bias removal etc.) voltage measurement from + channel Y. diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index 70cb7eb..fb2ca27 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -147,6 +147,7 @@ static const char * const iio_chan_info_postfix[] = { [IIO_CHAN_INFO_DEBOUNCE_TIME] = "debounce_time", [IIO_CHAN_INFO_CALIBEMISSIVITY] = "calibemissivity", [IIO_CHAN_INFO_OVERSAMPLING_RATIO] = "oversampling_ratio", + [IIO_CHAN_INFO_SIGNED] = "signed", }; /** diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h index b2b1677..6f5eb24 100644 --- a/include/linux/iio/iio.h +++ b/include/linux/iio/iio.h @@ -46,6 +46,7 @@ enum iio_chan_info_enum { IIO_CHAN_INFO_DEBOUNCE_TIME, IIO_CHAN_INFO_CALIBEMISSIVITY, IIO_CHAN_INFO_OVERSAMPLING_RATIO, + IIO_CHAN_INFO_SIGNED, }; enum iio_shared_by {
The same channel can be used to perform a signed or an unsigned conversion. Add a new infomask element to be able to select the type of conversion wanted: a raw one or a signed raw one. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> --- Documentation/ABI/testing/sysfs-bus-iio | 10 ++++++++++ drivers/iio/industrialio-core.c | 1 + include/linux/iio/iio.h | 1 + 3 files changed, 12 insertions(+)