From: "Sricharan" <sricharan@codeaurora.org>
To: "'Phani A, Rama Krishna'" <rphani@codeaurora.org>,
linux-iio@vger.kernel.org, jic23@kernel.org
Cc: linux-arm-msm@vger.kernel.org, smohanad@codeaurora.org,
mgautam@codeaurora.org, 'Hartmut Knaack' <knaack.h@gmx.de>,
'Lars-Peter Clausen' <lars@metafoo.de>,
'Peter Meerwald-Stadler' <pmeerw@pmeerw.net>,
'Julia Lawall' <Julia.Lawall@lip6.fr>,
'open list' <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH V1]iio: adc: spmi-vadc: Changes to support different scaling
Date: Wed, 26 Oct 2016 15:47:17 +0530 [thread overview]
Message-ID: <001c01d22f72$25990c10$70cb2430$@codeaurora.org> (raw)
In-Reply-To: <241f4520-92da-5aff-7f4f-9487d6082906@codeaurora.org>
Hi Ramakrishna,
[snip..]
>>> + u32 i = 0;
>>> +
>>> + if (!pts)
>>> + return -EINVAL;
>>> +
>>> + /* Check if table is descending or ascending */
>>> + if (tablesize > 1) {
>>> + if (pts[0].x < pts[1].x)
>>> + descending = 0;
>>> + }
>>> +
>>> + while (i < tablesize) {
>>> + if ((descending == 1) && (pts[i].x < input)) {
>>
>> Just if (descending) instead of (descending == 1) and so on for the below as well
>
> Will change in next patch.
>
>>
>>> + /* table entry is less than measured*/
>>> + /* value and table is descending, stop */
>>> + break;
>>> + } else if ((descending == 0) &&
>>> + (pts[i].x > input)) {
>>> + /* table entry is greater than measured*/
>>> + /*value and table is ascending, stop */
>>> + break;
>>> + }
>>> + i++;
>>> + }
>>> +
>>> + if (i == 0) {
>>> + *output = pts[0].y;
>>> + } else if (i == tablesize) {
>>> + *output = pts[tablesize - 1].y;
>>> + } else {
>>> + /* result is between search_index and search_index-1 */
>>> + /* interpolate linearly */
>>> + *output = (((s32)((pts[i].y - pts[i - 1].y) *
>>> + (input - pts[i - 1].x)) /
>>> + (pts[i].x - pts[i - 1].x)) +
>>> + pts[i - 1].y);
>>> + }
>>
>> hmm, so for descending, input - pts[i -1].x is negative and
>> we are adding that to pts[i-1].y, is that correct ?
>
> The formula used is to interpolate between two points using linear
>interpolation.
Right, agree. my question can be ignored.
[snip..]
>>> #define VADC_CHAN_TEMP(_dname, _pre) \
>>> - VADC_CHAN(_dname, IIO_TEMP, BIT(IIO_CHAN_INFO_PROCESSED), _pre) \
>>> + VADC_CHAN(_dname, IIO_TEMP, \
>>> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_PROCESSED), \
>>> + _pre) \
>>>
>>> #define VADC_CHAN_VOLT(_dname, _pre) \
>>> - VADC_CHAN(_dname, IIO_VOLTAGE, \
>>> - BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE), \
>>> + VADC_CHAN(_dname, IIO_VOLTAGE, \
>>> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_PROCESSED),\
>>> _pre) \
>>>
>> For this and the below changes to VADC_CHAN_VOLT to TEMP, why is that done ?
>> Now both macros are setting the same flags.
>
> For Voltage channels IIO_VOLTAGE is needed where as for Temperature
>channels IIO_TEMP is needed.
>
>>
>>> /*
>>> @@ -637,12 +811,11 @@ struct vadc_channels {
>>> VADC_CHAN_TEMP(DIE_TEMP, 0)
>>> VADC_CHAN_VOLT(REF_625MV, 0)
>>> VADC_CHAN_VOLT(REF_1250MV, 0)
>>> - VADC_CHAN_VOLT(CHG_TEMP, 0)
>>> + VADC_CHAN_TEMP(CHG_TEMP, 0)
>>> VADC_CHAN_VOLT(SPARE1, 0)
>>> VADC_CHAN_VOLT(SPARE2, 0)
>>> VADC_CHAN_VOLT(GND_REF, 0)
>>> VADC_CHAN_VOLT(VDD_VADC, 0)
>>> -
And also looks like the deletion of these and below
new lines are unnecessary ?
Regards,
Sricharan
WARNING: multiple messages have this Message-ID (diff)
From: "Sricharan" <sricharan@codeaurora.org>
To: "'Phani A, Rama Krishna'" <rphani@codeaurora.org>,
<linux-iio@vger.kernel.org>, <jic23@kernel.org>
Cc: <linux-arm-msm@vger.kernel.org>, <smohanad@codeaurora.org>,
<mgautam@codeaurora.org>, "'Hartmut Knaack'" <knaack.h@gmx.de>,
"'Lars-Peter Clausen'" <lars@metafoo.de>,
"'Peter Meerwald-Stadler'" <pmeerw@pmeerw.net>,
"'Julia Lawall'" <Julia.Lawall@lip6.fr>,
"'open list'" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH V1]iio: adc: spmi-vadc: Changes to support different scaling
Date: Wed, 26 Oct 2016 15:47:17 +0530 [thread overview]
Message-ID: <001c01d22f72$25990c10$70cb2430$@codeaurora.org> (raw)
In-Reply-To: <241f4520-92da-5aff-7f4f-9487d6082906@codeaurora.org>
Hi Ramakrishna,
[snip..]
>>> + u32 i = 0;
>>> +
>>> + if (!pts)
>>> + return -EINVAL;
>>> +
>>> + /* Check if table is descending or ascending */
>>> + if (tablesize > 1) {
>>> + if (pts[0].x < pts[1].x)
>>> + descending = 0;
>>> + }
>>> +
>>> + while (i < tablesize) {
>>> + if ((descending == 1) && (pts[i].x < input)) {
>>
>> Just if (descending) instead of (descending == 1) and so on for the below as well
>
> Will change in next patch.
>
>>
>>> + /* table entry is less than measured*/
>>> + /* value and table is descending, stop */
>>> + break;
>>> + } else if ((descending == 0) &&
>>> + (pts[i].x > input)) {
>>> + /* table entry is greater than measured*/
>>> + /*value and table is ascending, stop */
>>> + break;
>>> + }
>>> + i++;
>>> + }
>>> +
>>> + if (i == 0) {
>>> + *output = pts[0].y;
>>> + } else if (i == tablesize) {
>>> + *output = pts[tablesize - 1].y;
>>> + } else {
>>> + /* result is between search_index and search_index-1 */
>>> + /* interpolate linearly */
>>> + *output = (((s32)((pts[i].y - pts[i - 1].y) *
>>> + (input - pts[i - 1].x)) /
>>> + (pts[i].x - pts[i - 1].x)) +
>>> + pts[i - 1].y);
>>> + }
>>
>> hmm, so for descending, input - pts[i -1].x is negative and
>> we are adding that to pts[i-1].y, is that correct ?
>
> The formula used is to interpolate between two points using linear
>interpolation.
Right, agree. my question can be ignored.
[snip..]
>>> #define VADC_CHAN_TEMP(_dname, _pre) \
>>> - VADC_CHAN(_dname, IIO_TEMP, BIT(IIO_CHAN_INFO_PROCESSED), _pre) \
>>> + VADC_CHAN(_dname, IIO_TEMP, \
>>> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_PROCESSED), \
>>> + _pre) \
>>>
>>> #define VADC_CHAN_VOLT(_dname, _pre) \
>>> - VADC_CHAN(_dname, IIO_VOLTAGE, \
>>> - BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE), \
>>> + VADC_CHAN(_dname, IIO_VOLTAGE, \
>>> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_PROCESSED),\
>>> _pre) \
>>>
>> For this and the below changes to VADC_CHAN_VOLT to TEMP, why is that done ?
>> Now both macros are setting the same flags.
>
> For Voltage channels IIO_VOLTAGE is needed where as for Temperature
>channels IIO_TEMP is needed.
>
>>
>>> /*
>>> @@ -637,12 +811,11 @@ struct vadc_channels {
>>> VADC_CHAN_TEMP(DIE_TEMP, 0)
>>> VADC_CHAN_VOLT(REF_625MV, 0)
>>> VADC_CHAN_VOLT(REF_1250MV, 0)
>>> - VADC_CHAN_VOLT(CHG_TEMP, 0)
>>> + VADC_CHAN_TEMP(CHG_TEMP, 0)
>>> VADC_CHAN_VOLT(SPARE1, 0)
>>> VADC_CHAN_VOLT(SPARE2, 0)
>>> VADC_CHAN_VOLT(GND_REF, 0)
>>> VADC_CHAN_VOLT(VDD_VADC, 0)
>>> -
And also looks like the deletion of these and below
new lines are unnecessary ?
Regards,
Sricharan
next prev parent reply other threads:[~2016-10-26 10:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 5:27 [PATCH V1]iio: adc: spmi-vadc: Changes to support different scaling Rama Krishna Phani A
2016-10-25 5:27 ` Rama Krishna Phani A
2016-10-25 13:09 ` Sricharan
2016-10-25 13:09 ` Sricharan
2016-10-26 9:27 ` Phani A, Rama Krishna
2016-10-26 9:27 ` Phani A, Rama Krishna
2016-10-26 10:17 ` Sricharan [this message]
2016-10-26 10:17 ` Sricharan
2016-10-26 10:45 ` Phani A, Rama Krishna
2016-10-26 10:45 ` Phani A, Rama Krishna
2016-11-02 7:25 ` kbuild test robot
2016-11-02 7:25 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001c01d22f72$25990c10$70cb2430$@codeaurora.org' \
--to=sricharan@codeaurora.org \
--cc=Julia.Lawall@lip6.fr \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgautam@codeaurora.org \
--cc=pmeerw@pmeerw.net \
--cc=rphani@codeaurora.org \
--cc=smohanad@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.