From: Jonathan Cameron <jic23@kernel.org>
To: Lothar Rubusch <l.rubusch@gmail.com>
Cc: lars@metafoo.de, Michael.Hennerich@analog.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, eraretuya@gmail.com
Subject: Re: [PATCH v5 03/10] iio: accel: adxl345: measure right-justified
Date: Wed, 11 Dec 2024 18:55:30 +0000 [thread overview]
Message-ID: <20241211185530.16abfb25@jic23-huawei> (raw)
In-Reply-To: <CAFXKEHbPmFc8DNZW=Ww39j+XkAfLOyFY2qgvz+uEUaBYri_3hA@mail.gmail.com>
On Mon, 9 Dec 2024 23:18:45 +0100
Lothar Rubusch <l.rubusch@gmail.com> wrote:
> Dear IIO-ML, Hi Jonathan!
>
> On Sun, Dec 8, 2024 at 2:35 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Thu, 5 Dec 2024 17:13:36 +0000
> > Lothar Rubusch <l.rubusch@gmail.com> wrote:
> >
> > > Make measurements right-justified, since it is the default for the
> > > driver and sensor. By not setting the ADXL345_DATA_FORMAT_JUSTIFY bit,
> > > the data becomes right-judstified. This was the original setting, there
> > > is no reason to change it to left-justified, where right-justified
> > > simplifies working on the registers.
> > >
> > > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> >
> > I'm still confused by this one. Does this change affect the data output
> > to userspace? If seems like it definitely should. If it does we have
> > an ABI regression somewhere. Is it currently broken and wasn't at some
> > earlier stage, or is this the patch breaking things?
>
> No, it should not affect the userspace.
>
> This setting opens the mask for regmap/update bits to allow for
> changing the data format.
> My point is rather, does it actually makes sense to allow to change
> the data format, since
> the driver will use just one format. The bit was never applied, it's
> just the mask here.
Ah. Got it.
>
> May I ask you, if you could also could give me a brief feedback to the
> three questions in
> the cover letter to this series?
Reading cover letters? Never! :)
Thanks for the heads up. I tend to skip straight past them unless
I am looking for something specific... oops.
>
> I would really appreciate, since I'm still unsure if I actually
> verified everything correctly.
> From what I did about this bit, I removed and set the justified bit in
> STREAM and in
> BYPASSED mode (current mode), without any difference in the results in
> iio_info or
> iio_readdev. The numbers look generally odd to me, though. And, I'd
> rather like to ask
> to still wait with applying the patches, if this is ok for you? But,
> perhaps with the answers
> of the cover letter items, it could become clearer to me. I'm still
> about to measure and
> verify against the old and the input driver results as comparison.
I'd use the tools/iio tooling. It pretty prints channel data. I suspect
there are tools in the set you are using that do that but I'm not the
person to ask.
Jonathan
>
> Best,
> L
>
>
> > If it worked and currently doesn't send a fix. If this changes a previously
> > working ABI then drop this patch. Alternative being to fix up the scale
> > handling to incorporate this justification change.
> >
> > Jonathan
> >
> > > ---
> > > drivers/iio/accel/adxl345_core.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> > > index 88df9547bd6..98ff37271f1 100644
> > > --- a/drivers/iio/accel/adxl345_core.c
> > > +++ b/drivers/iio/accel/adxl345_core.c
> > > @@ -184,7 +184,6 @@ int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> > > struct iio_dev *indio_dev;
> > > u32 regval;
> > > unsigned int data_format_mask = (ADXL345_DATA_FORMAT_RANGE |
> > > - ADXL345_DATA_FORMAT_JUSTIFY |
> > > ADXL345_DATA_FORMAT_FULL_RES |
> > > ADXL345_DATA_FORMAT_SELF_TEST);
> > > int ret;
> >
next prev parent reply other threads:[~2024-12-11 18:55 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 17:13 [PATCH v5 00/10] iio: accel: adxl345: add FIFO operating with IRQ triggered watermark events Lothar Rubusch
2024-12-05 17:13 ` [PATCH v5 01/10] iio: accel: adxl345: refrase comment on probe Lothar Rubusch
2024-12-08 13:26 ` Jonathan Cameron
2024-12-05 17:13 ` [PATCH v5 02/10] iio: accel: adxl345: rename variable data to st Lothar Rubusch
2024-12-08 13:27 ` Jonathan Cameron
2024-12-10 17:31 ` Lothar Rubusch
2024-12-11 18:42 ` Jonathan Cameron
2024-12-05 17:13 ` [PATCH v5 03/10] iio: accel: adxl345: measure right-justified Lothar Rubusch
2024-12-08 13:34 ` Jonathan Cameron
2024-12-09 22:18 ` Lothar Rubusch
2024-12-11 18:55 ` Jonathan Cameron [this message]
2024-12-05 17:13 ` [PATCH v5 04/10] iio: accel: adxl345: add function to switch measuring mode Lothar Rubusch
2024-12-08 13:42 ` Jonathan Cameron
2024-12-10 17:49 ` Lothar Rubusch
2024-12-05 17:13 ` [PATCH v5 05/10] iio: accel: adxl345: complete list of defines Lothar Rubusch
2024-12-08 16:11 ` Jonathan Cameron
2024-12-05 17:13 ` [PATCH v5 06/10] dt-bindings: iio: accel: add interrupt-names Lothar Rubusch
2024-12-05 17:53 ` Conor Dooley
2024-12-05 19:41 ` Lothar Rubusch
2024-12-06 17:07 ` Conor Dooley
2024-12-06 17:29 ` Lothar Rubusch
2024-12-07 12:10 ` Lothar Rubusch
2024-12-08 13:21 ` Jonathan Cameron
2024-12-08 13:14 ` Jonathan Cameron
2024-12-05 17:13 ` [PATCH v5 07/10] iio: accel: adxl345: introduce interrupt handling Lothar Rubusch
2024-12-08 16:14 ` Jonathan Cameron
2024-12-05 17:13 ` [PATCH v5 08/10] iio: accel: adxl345: initialize FIFO delay value for SPI Lothar Rubusch
2024-12-08 16:16 ` Jonathan Cameron
2024-12-05 17:13 ` [PATCH v5 09/10] iio: accel: adxl345: prepare channel for scan_index Lothar Rubusch
2024-12-08 16:17 ` Jonathan Cameron
2024-12-05 17:13 ` [PATCH v5 10/10] iio: accel: adxl345: add FIFO with watermark events Lothar Rubusch
2024-12-08 16:34 ` Jonathan Cameron
2024-12-10 21:54 ` Lothar Rubusch
2024-12-11 19:14 ` Jonathan Cameron
2024-12-11 22:32 ` Lothar Rubusch
2024-12-10 8:47 ` Dan Carpenter
2024-12-11 19:15 ` Jonathan Cameron
2024-12-11 18:53 ` [PATCH v5 00/10] iio: accel: adxl345: add FIFO operating with IRQ triggered " Jonathan Cameron
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=20241211185530.16abfb25@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=eraretuya@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=l.rubusch@gmail.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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