From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Angel Iglesias <ang.iglesiasg@gmail.com>,
Andreas Klinger <ak@it-klinger.de>,
"Christophe JAILLET" <christophe.jaillet@wanadoo.fr>,
Benjamin Bara <bbara93@gmail.com>, <linux-iio@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/6] tools: iio: iio_generic_buffer ensure alignment
Date: Mon, 25 Sep 2023 14:16:29 +0100 [thread overview]
Message-ID: <20230925141629.00004522@Huawei.com> (raw)
In-Reply-To: <7ff22aa4-475c-b524-9f7a-f47ad02e940b@gmail.com>
On Mon, 25 Sep 2023 10:01:09 +0300
Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> On 9/24/23 18:57, Jonathan Cameron wrote:
> > On Fri, 22 Sep 2023 14:16:08 +0300
> > Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> >
> >> The iio_generic_buffer can return garbage values when the total size of
> >> scan data is not a multiple of largest element in the scan. This can be
> >> demonstrated by reading a scan consisting for example of one 4 byte and
> >> one 2 byte element, where the 4 byte elemnt is first in the buffer.
> >>
> >> The IIO generic buffert code does not take into accunt the last two
> >> padding bytes that are needed to ensure that the 4byte data for next
> >> scan is correctly aligned.
> >>
> >> Add padding bytes required to align the next sample into the scan size.
> >>
> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> >> ---
> >> Please note, This one could have RFC in subject.:
> >> I attempted to write the fix so that the alignment is done based on the
> >> biggest channel data. This may be wrong. Maybe a fixed 8 byte alignment
> >> should be used instead? This patch can be dropped from the series if the
> >> fix is not correct / agreed.
> >>
> >> tools/iio/iio_generic_buffer.c | 15 ++++++++++++++-
> >> 1 file changed, 14 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c
> >> index 44bbf80f0cfd..fc562799a109 100644
> >> --- a/tools/iio/iio_generic_buffer.c
> >> +++ b/tools/iio/iio_generic_buffer.c
> >> @@ -54,9 +54,12 @@ enum autochan {
> >> static unsigned int size_from_channelarray(struct iio_channel_info *channels, int num_channels)
> >> {
> >> unsigned int bytes = 0;
> >> - int i = 0;
> >> + int i = 0, max = 0;
> >> + unsigned int misalignment;
> >>
> >> while (i < num_channels) {
> >> + if (channels[i].bytes > max)
> >> + max = channels[i].bytes;
> >> if (bytes % channels[i].bytes == 0)
> >> channels[i].location = bytes;
> >> else
> >> @@ -66,6 +69,16 @@ static unsigned int size_from_channelarray(struct iio_channel_info *channels, in
> >> bytes = channels[i].location + channels[i].bytes;
> >> i++;
> >> }
> >> + /*
> >> + * We wan't the data in next sample to also be properly aligned so
> >> + * we'll add padding at the end if needed. TODO: should we use fixed
> >> + * 8 byte alignment instead of the size of the biggest samnple?
> >> + */
> >
> > Should be aligned to max size seen in the scan.
>
> Or, maybe it should be
> min(max_size_in_scan, 8);
> ?
Definitely not. If you are grabbing just one channel of 8 bit data,
we want it to be tightly packed.
If we have a bug that already made that true then we might be stuck
with it, but I'm fairly sure we don't.
>
> I think my suggestion above may yield undesirable effects should the
> scan elements be greater than 8 bytes. (Don't know if this is supported
> though)
It is supported in theory, in practice not seen one yet.
>
> >
> >> + misalignment = bytes % max;
> >> + if (misalignment) {
> >> + printf("Misalignment %u. Adding Padding %u\n", misalignment, max - misalignment);
> >
> > No print statement as this is correct behaviour (well the tool is buggy but the kernel generates it
> > correctly I believe). Fine to add a comment though!
>
> Oh, indeed. The print was forgotten from my test runs. Thanks for
> pointing it out!
>
> >
> >> + bytes += max - misalignment;
> >> + }
> >>
> >> return bytes;
> >> }
> >
>
> Yours,
> -- Matti
>
next prev parent reply other threads:[~2023-09-25 13:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 11:14 [PATCH v3 0/6] Support ROHM BM1390 pressure sensor Matti Vaittinen
2023-09-22 11:16 ` [PATCH v3 1/6] tools: iio: iio_generic_buffer ensure alignment Matti Vaittinen
2023-09-24 15:57 ` Jonathan Cameron
2023-09-25 7:01 ` Matti Vaittinen
2023-09-25 13:16 ` Jonathan Cameron [this message]
2023-09-26 10:29 ` Matti Vaittinen
2023-09-30 16:27 ` Jonathan Cameron
2023-09-22 11:16 ` [PATCH v3 2/6] iio: improve doc for available_scan_mask Matti Vaittinen
2023-09-24 15:59 ` Jonathan Cameron
2023-09-25 9:50 ` Matti Vaittinen
2023-09-25 13:17 ` Jonathan Cameron
2023-09-22 11:17 ` [PATCH v3 3/6] iio: try searching for exact scan_mask Matti Vaittinen
2023-09-24 16:07 ` Jonathan Cameron
2023-09-24 16:10 ` Jonathan Cameron
2023-09-25 10:06 ` Matti Vaittinen
2023-09-25 10:00 ` Matti Vaittinen
2023-09-22 11:18 ` [PATCH v3 4/6] dt-bindings: Add ROHM BM1390 pressure sensor Matti Vaittinen
2023-09-22 11:19 ` [PATCH v3 5/6] iio: pressure: Support ROHM BU1390 Matti Vaittinen
2023-09-24 16:29 ` Jonathan Cameron
2023-09-25 10:29 ` Matti Vaittinen
2023-09-22 11:19 ` [PATCH v3 6/6] MAINTAINERS: Add ROHM BM1390 Matti Vaittinen
2023-09-24 15:53 ` [PATCH v3 0/6] Support ROHM BM1390 pressure sensor Jonathan Cameron
2023-09-25 6:35 ` Matti Vaittinen
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=20230925141629.00004522@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=ak@it-klinger.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ang.iglesiasg@gmail.com \
--cc=bbara93@gmail.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=mazziesaccount@gmail.com \
--cc=robh+dt@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