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 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.