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 ? > >> 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
