On 29/09/15 07:21, Matt Ranostay wrote: > Would it just be clearer to use a IIO_CONST for the offset than using > this kinda not clear IIO_CHAN_INFO_OFFSET hacking? Clearer, but less functional. The IIO_CHAN_INFO stuff is available in kernel IIO_CONST attributes are not. That is why the fractional type is preferred. Other in kernel users can elect to do maths with it with minimal loss of precision whereas a floating point number is a PITA. Over time the aim is to get rid of all the attributes in favour of supporting them through the core. All part of a drive to separate the front and backends of IIO so the backend can act as a more generic layer. > > On Mon, Sep 28, 2015 at 9:19 PM, Matt Ranostay <mranostay@xxxxxxxxx> wrote: >> On Mon, Sep 28, 2015 at 2:08 AM, Jonathan Cameron >> <jic23@xxxxxxxxxxxxxxxxxxxxx> wrote: >>> >>> >>> On 27 September 2015 23:35:29 BST, Matt Ranostay <mranostay@xxxxxxxxx> wrote: >>>> On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@xxxxxxxxxx> >>>> wrote: >>>>> On 27/09/15 07:18, Matt Ranostay wrote: >>>>>> Previous offset wasn't applied in the correct order and invalid. >>>>>> This patchset fixes this issue, and also has the correct scale value >>>>>> applied to the offset. >>>>>> >>>>>> Signed-off-by: Matt Ranostay <mranostay@xxxxxxxxx> >>>>> Oops, missed that. >>>>> >>>>> Given it's provided in the datasheet as effectively a fractional >>>> value >>>>> would val = -40000, val2 = 65536 and type = IIO_FRACTIONAL not be >>>> cleaner >>>>> and give the same answer? >>>>> >>>> Actually not because the way the datasheet states it ((value / 2**16) >>>> * 165) - 40, so the scale value needs to be applied to the -40 >>>> offset (165/65536) >>> Good point. Can't we do (-40*165)/65536 ? >> >> Nope. >> >> scale = 165<<2 / 65536 >> offset = 40 / scale >> >> Maybe we should add a new IIO_CHAN_INFO_SCALED_OFFSET that uses the >> scale value and a divisor that returns an IIO_FRACTIONAL? >> >> >>>> >>>>> Speaking of which, for the scale are we loosing any precision by >>>> shifting >>>>> the bottom of the fraction right 2 rather than the top left 2 which >>>> would have >>>>> the same result? >>>> >>>> Ah possibly. But I suspect isn't anything measurable... >>>> >>>>> >>>>> Jonathan >>>>>> --- >>>>>> drivers/iio/humidity/hdc100x.c | 5 +++-- >>>>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/drivers/iio/humidity/hdc100x.c >>>> b/drivers/iio/humidity/hdc100x.c >>>>>> index 2824578..a7f61e8 100644 >>>>>> --- a/drivers/iio/humidity/hdc100x.c >>>>>> +++ b/drivers/iio/humidity/hdc100x.c >>>>>> @@ -221,8 +221,9 @@ static int hdc100x_read_raw(struct iio_dev >>>> *indio_dev, >>>>>> } >>>>>> break; >>>>>> case IIO_CHAN_INFO_OFFSET: >>>>>> - *val = -40; >>>>>> - return IIO_VAL_INT; >>>>>> + *val = -3971; >>>>>> + *val2 = 879096; >>>>>> + return IIO_VAL_INT_PLUS_MICRO; >>>>>> default: >>>>>> return -EINVAL; >>>>>> } >>>>>> >>>>> >>> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- > 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 > -- 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
