* [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).