* [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value @ 2015-09-27 6:18 Matt Ranostay 2015-09-27 13:29 ` Jonathan Cameron 0 siblings, 1 reply; 10+ messages in thread From: Matt Ranostay @ 2015-09-27 6:18 UTC (permalink / raw) To: jic23; +Cc: linux-iio, Matt Ranostay 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@gmail.com> --- 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; } -- 1.9.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-09-27 6:18 [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value Matt Ranostay @ 2015-09-27 13:29 ` Jonathan Cameron 2015-09-27 22:35 ` Matt Ranostay 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Cameron @ 2015-09-27 13:29 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-iio 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@gmail.com> 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? 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? 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; > } > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-09-27 13:29 ` Jonathan Cameron @ 2015-09-27 22:35 ` Matt Ranostay 2015-09-28 9:08 ` Jonathan Cameron 0 siblings, 1 reply; 10+ messages in thread From: Matt Ranostay @ 2015-09-27 22:35 UTC (permalink / raw) To: Jonathan Cameron; +Cc: linux-iio@vger.kernel.org On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@kernel.org> 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@gmail.com> > 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) > 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; >> } >> > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-09-27 22:35 ` Matt Ranostay @ 2015-09-28 9:08 ` Jonathan Cameron 2015-09-29 4:19 ` Matt Ranostay 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Cameron @ 2015-09-28 9:08 UTC (permalink / raw) To: Matt Ranostay, Jonathan Cameron; +Cc: linux-iio@vger.kernel.org On 27 September 2015 23:35:29 BST, Matt Ranostay <mranostay@gmail.com> wrote: >On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@kernel.org> >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@gmail.com> >> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-09-28 9:08 ` Jonathan Cameron @ 2015-09-29 4:19 ` Matt Ranostay 2015-09-29 6:21 ` Matt Ranostay 2015-09-29 17:33 ` Jonathan Cameron 0 siblings, 2 replies; 10+ messages in thread From: Matt Ranostay @ 2015-09-29 4:19 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio@vger.kernel.org On Mon, Sep 28, 2015 at 2:08 AM, Jonathan Cameron <jic23@jic23.retrosnub.co.uk> wrote: > > > On 27 September 2015 23:35:29 BST, Matt Ranostay <mranostay@gmail.com> wrote: >>On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@kernel.org> >>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@gmail.com> >>> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-09-29 4:19 ` Matt Ranostay @ 2015-09-29 6:21 ` Matt Ranostay 2015-09-29 17:30 ` Jonathan Cameron 2015-09-29 17:33 ` Jonathan Cameron 1 sibling, 1 reply; 10+ messages in thread From: Matt Ranostay @ 2015-09-29 6:21 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio@vger.kernel.org Would it just be clearer to use a IIO_CONST for the offset than using this kinda not clear IIO_CHAN_INFO_OFFSET hacking? On Mon, Sep 28, 2015 at 9:19 PM, Matt Ranostay <mranostay@gmail.com> wrote: > On Mon, Sep 28, 2015 at 2:08 AM, Jonathan Cameron > <jic23@jic23.retrosnub.co.uk> wrote: >> >> >> On 27 September 2015 23:35:29 BST, Matt Ranostay <mranostay@gmail.com> wrote: >>>On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@kernel.org> >>>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@gmail.com> >>>> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-09-29 6:21 ` Matt Ranostay @ 2015-09-29 17:30 ` Jonathan Cameron 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Cameron @ 2015-09-29 17:30 UTC (permalink / raw) To: Matt Ranostay, Jonathan Cameron; +Cc: linux-iio@vger.kernel.org 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@gmail.com> wrote: >> On Mon, Sep 28, 2015 at 2:08 AM, Jonathan Cameron >> <jic23@jic23.retrosnub.co.uk> wrote: >>> >>> >>> On 27 September 2015 23:35:29 BST, Matt Ranostay <mranostay@gmail.com> wrote: >>>> On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@kernel.org> >>>> 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@gmail.com> >>>>> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-09-29 4:19 ` Matt Ranostay 2015-09-29 6:21 ` Matt Ranostay @ 2015-09-29 17:33 ` Jonathan Cameron 2015-10-05 5:57 ` Matt Ranostay 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Cameron @ 2015-09-29 17:33 UTC (permalink / raw) To: Matt Ranostay, Jonathan Cameron; +Cc: linux-iio@vger.kernel.org On 29/09/15 05:19, Matt Ranostay wrote: > On Mon, Sep 28, 2015 at 2:08 AM, Jonathan Cameron > <jic23@jic23.retrosnub.co.uk> wrote: >> >> >> On 27 September 2015 23:35:29 BST, Matt Ranostay <mranostay@gmail.com> wrote: >>> On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@kernel.org> >>> 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@gmail.com> >>>> 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? Hmm. Would get messy fast. Lets just go with your original fixed point option below. If someone later figures out a neater way of doing it, good for them ;) J > > >>> >>>> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-09-29 17:33 ` Jonathan Cameron @ 2015-10-05 5:57 ` Matt Ranostay 2015-10-11 12:53 ` Jonathan Cameron 0 siblings, 1 reply; 10+ messages in thread From: Matt Ranostay @ 2015-10-05 5:57 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio@vger.kernel.org On Tue, Sep 29, 2015 at 10:33 AM, Jonathan Cameron <jic23@kernel.org> wrote: > On 29/09/15 05:19, Matt Ranostay wrote: >> On Mon, Sep 28, 2015 at 2:08 AM, Jonathan Cameron >> <jic23@jic23.retrosnub.co.uk> wrote: >>> >>> >>> On 27 September 2015 23:35:29 BST, Matt Ranostay <mranostay@gmail.com> wrote: >>>> On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@kernel.org> >>>> 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@gmail.com> >>>>> 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? > Hmm. Would get messy fast. > > Lets just go with your original fixed point option below. If someone later figures > out a neater way of doing it, good for them ;) Ok that works. > > J >> >> >>>> >>>>> 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. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value 2015-10-05 5:57 ` Matt Ranostay @ 2015-10-11 12:53 ` Jonathan Cameron 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Cameron @ 2015-10-11 12:53 UTC (permalink / raw) To: Matt Ranostay; +Cc: Jonathan Cameron, linux-iio@vger.kernel.org On 05/10/15 06:57, Matt Ranostay wrote: > On Tue, Sep 29, 2015 at 10:33 AM, Jonathan Cameron <jic23@kernel.org> wrote: >> On 29/09/15 05:19, Matt Ranostay wrote: >>> On Mon, Sep 28, 2015 at 2:08 AM, Jonathan Cameron >>> <jic23@jic23.retrosnub.co.uk> wrote: >>>> >>>> >>>> On 27 September 2015 23:35:29 BST, Matt Ranostay <mranostay@gmail.com> wrote: >>>>> On Sun, Sep 27, 2015 at 6:29 AM, Jonathan Cameron <jic23@kernel.org> >>>>> 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@gmail.com> >>>>>> 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? >> Hmm. Would get messy fast. >> >> Lets just go with your original fixed point option below. If someone later figures >> out a neater way of doing it, good for them ;) > > Ok that works. Applied to the togreg branch of iio.git - initially pushed out as testing for the autobuilders to play with it. Thanks, Jonathan >> >> J >>> >>> >>>>> >>>>>> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-10-11 12:53 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-09-27 6:18 [PATCH] iio: hdc100x: correct IIO_CHAN_INFO_OFFSET value Matt Ranostay 2015-09-27 13:29 ` Jonathan Cameron 2015-09-27 22:35 ` Matt Ranostay 2015-09-28 9:08 ` Jonathan Cameron 2015-09-29 4:19 ` Matt Ranostay 2015-09-29 6:21 ` Matt Ranostay 2015-09-29 17:30 ` Jonathan Cameron 2015-09-29 17:33 ` Jonathan Cameron 2015-10-05 5:57 ` Matt Ranostay 2015-10-11 12:53 ` Jonathan Cameron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).