From: David Lechner <dlechner@baylibre.com>
To: Alexandru Ardelean <aardelean@baylibre.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, jic23@kernel.org, krzk+dt@kernel.org,
robh@kernel.org, lars@metafoo.de, michael.hennerich@analog.com,
gstols@baylibre.com
Subject: Re: [PATCH v4 8/8] iio: adc: ad7606: add support for AD7606C-{16,18} parts
Date: Fri, 6 Sep 2024 08:33:21 -0500 [thread overview]
Message-ID: <52eb0187-056b-413a-a64a-6fd001c27132@baylibre.com> (raw)
In-Reply-To: <CA+GgBR9=unTe5WVq0G2zowbL9FnLfCwoAuZp=7VD=xZOt9Gn5w@mail.gmail.com>
On 9/6/24 12:34 AM, Alexandru Ardelean wrote:
> On Fri, Sep 6, 2024 at 2:30 AM David Lechner <dlechner@baylibre.com> wrote:
>>
>> On 9/5/24 3:24 AM, Alexandru Ardelean wrote:
>>> -static int ad7606_read_samples(struct ad7606_state *st)
>>> +static int ad7606_read_samples(struct ad7606_state *st, bool sign_extend_samples)
>>> {
>>> + unsigned int storagebits = st->chip_info->channels[1].scan_type.storagebits;
>>
>> Why [1]? Sure, they are all the same, but [0] would seem less arbitrary.
>
> [0] is the timestamp channel.
Oh, that's weird. First channel but last scan index!?
>>
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (storagebits == 16 || !sign_extend_samples)
>>> + return 0;
>>> +
>>> + /* For 18 bit samples, we need to sign-extend samples to 32 bits */
>>> + for (i = 0; i < num; i++)
>>> + data32[i] = sign_extend32(data32[i], 17);> +
>>> + return 0;
>>> }
>>>
>>> static irqreturn_t ad7606_trigger_handler(int irq, void *p)
>>> @@ -124,11 +176,11 @@ static irqreturn_t ad7606_trigger_handler(int irq, void *p)
>>>
>>> guard(mutex)(&st->lock);
>>>
>>> - ret = ad7606_read_samples(st);
>>> + ret = ad7606_read_samples(st, true);
>>
>> Shouldn't the sign_extend parameter depend on if the data is unipolar or bipolar?
>
> [c1]
> Sign-extension is only needed for 18-bit samples.
> 16-bit samples are already properly sign(ed), but to 16-bits.
>
> It's a slight performance improvement, that may look quirky here.
> The idea here, is that for ad7606_scan_direct() we only need to
> sign-extend 1 sample of the 8 samples we get.
> And we need to sign-extend it to 32 bits regardless of it being 16-bit
> or 18-bit.
>
> In ad7606_trigger_handler(), the 16-bit samples were pushed as-is.
> Which means that we need to sign-extend the samples at least for
> 18-bits (as it is a new part)
> The question now becomes if we should sign-extend to 32-bits, 16-bit
> samples in ad7606_trigger_handler(), as that may break some ABI.
>
Sign extension should not be needed at all for buffered reads (that is
what scan_type is for). So sign extension should only be needed for
the direct read when returning a raw value via sysfs (raw read).
next prev parent reply other threads:[~2024-09-06 13:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 8:23 [PATCH v4 0/8] " Alexandru Ardelean
2024-09-05 8:23 ` [PATCH v4 1/8] iio: adc: ad7606: add 'bits' parameter to channels macros Alexandru Ardelean
2024-09-05 21:25 ` David Lechner
2024-09-06 5:10 ` Alexandru Ardelean
2024-09-05 8:23 ` [PATCH v4 2/8] iio: adc: ad7606: move 'val' pointer to ad7606_scan_direct() Alexandru Ardelean
2024-09-05 21:37 ` David Lechner
2024-09-05 8:23 ` [PATCH v4 3/8] iio: adc: ad7606: split a 'ad7606_sw_mode_setup()' from probe Alexandru Ardelean
2024-09-05 8:23 ` [PATCH v4 4/8] iio: adc: ad7606: wrap channel ranges & scales into struct Alexandru Ardelean
2024-09-05 8:23 ` [PATCH v4 5/8] iio: adc: ad7606: rework available attributes for SW channels Alexandru Ardelean
2024-09-05 8:24 ` [PATCH v4 6/8] dt-bindings: iio: adc: document diff-channels corner case for some ADCs Alexandru Ardelean
2024-09-05 8:24 ` [PATCH v4 7/8] dt-bindings: iio: adc: add docs for AD7606C-{16,18} parts Alexandru Ardelean
2024-09-05 8:27 ` Krzysztof Kozlowski
2024-09-05 21:54 ` David Lechner
2024-09-07 4:59 ` Alexandru Ardelean
2024-09-07 14:09 ` David Lechner
2024-09-07 17:57 ` Alexandru Ardelean
2024-09-05 22:02 ` David Lechner
2024-09-07 5:01 ` Alexandru Ardelean
2024-09-05 8:24 ` [PATCH v4 8/8] iio: adc: ad7606: add support " Alexandru Ardelean
2024-09-05 23:30 ` David Lechner
2024-09-06 5:34 ` Alexandru Ardelean
2024-09-06 13:33 ` David Lechner [this message]
2024-09-06 14:03 ` Alexandru Ardelean
2024-09-07 6:02 ` Alexandru Ardelean
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=52eb0187-056b-413a-a64a-6fd001c27132@baylibre.com \
--to=dlechner@baylibre.com \
--cc=aardelean@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=gstols@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--cc=robh@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®