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