From: "Nuno Sá" <noname.nuno@gmail.com>
To: Olivier MOYSAN <olivier.moysan@foss.st.com>,
Jonathan Cameron <jic23@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH 7/8] iio: add sd modulator generic iio backend
Date: Mon, 24 Jun 2024 17:22:54 +0200 [thread overview]
Message-ID: <1ef85cdcffefee6b6a68927816f3d26c074a5331.camel@gmail.com> (raw)
In-Reply-To: <2dbd160b-135e-4882-9fd3-9d921742f49d@foss.st.com>
Hi Olivier,
On Mon, 2024-06-24 at 14:43 +0200, Olivier MOYSAN wrote:
> Hi Jonathan,
>
> On 6/23/24 17:11, Jonathan Cameron wrote:
> > On Tue, 18 Jun 2024 18:08:33 +0200
> > Olivier Moysan <olivier.moysan@foss.st.com> wrote:
> >
> > > Add a generic driver to support sigma delta modulators.
> > > Typically, this device is a hardware connected to an IIO device
> > > in charge of the conversion. The device is exposed as an IIO backend
> > > device. This backend device and the associated conversion device
> > > can be seen as an aggregate device from IIO framework.
> > >
> > > Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
> >
> > Trivial comments inline.
> >
> > > diff --git a/drivers/iio/adc/sd_adc_backend.c
> > > b/drivers/iio/adc/sd_adc_backend.c
> > > new file mode 100644
> > > index 000000000000..556a49dc537b
> > > --- /dev/null
> > > +++ b/drivers/iio/adc/sd_adc_backend.c
> > > @@ -0,0 +1,110 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Generic sigma delta modulator IIO backend
> > > + *
> > > + * Copyright (C) 2024, STMicroelectronics - All Rights Reserved
> > > + */
> > > +
> > > +#include <linux/iio/backend.h>
> > > +#include <linux/iio/iio.h>
> > > +#include <linux/module.h>
> > > +#include <linux/mod_devicetable.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/regulator/consumer.h>
> > > +
> > > +struct iio_sd_backend_priv {
> > > + struct regulator *vref;
> > > + int vref_mv;
> > > +};
> > > +
> > > +static int sd_backend_enable(struct iio_backend *backend)
> > > +{
> > > + struct iio_sd_backend_priv *priv = iio_backend_get_priv(backend);
> > > +
> > > + return regulator_enable(priv->vref);
> > > +};
> > > +
> > > +static void sd_backend_disable(struct iio_backend *backend)
> > > +{
> > > + struct iio_sd_backend_priv *priv = iio_backend_get_priv(backend);
> > > +
> > > + regulator_disable(priv->vref);
> > > +};
> > > +
> > > +static int sd_backend_read(struct iio_backend *backend, int *val, int *val2,
> > > long mask)
> > Nothing to do with this patch as such:
> >
> > One day I'm going to bit the bullet and fix that naming.
> > Long long ago when the Earth was young it actually was a bitmap which
> > I miscalled a mask - it only had one bit ever set, which was a dumb
> > bit of API. It's not been true for a long time.
> > Anyhow, one more instances isn't too much of a problem I guess.
> >
>
> I changed the callback .read_raw to .ext_info_get to take Nuno's comment
> about iio_backend_read_raw() API, into account.
> So, I changed this function to
> static int sd_backend_ext_info_get(struct iio_backend *back, uintptr_t
> private, const struct iio_chan_spec *chan, char *buf)
> for v2 version.
>
Maybe I'm missing something but I think I did not explained myself very well. What I
had in mind was that since you're calling .read_raw() from IIO_CHAN_INFO_SCALE and
IIO_CHAN_INFO_OFFSET, it could make sense to have more dedicated API's. Meaning:
iio_backend_read_scale(...)
iio_backend_read_offset(...)
The iio_backend_read_raw() may make sense when frontends call
iio_backend_extend_chan_spec() and have no idea what the backend may have added to
the channel. So, in those cases something like this could make sense:
switch (mask)
IIO_CHAN_INFO_RAW:
...
default:
return iio_backend_read_raw();
but like I said maybe this is me over-complicating and a simple
iio_backend_read_raw() is sufficient. But I think I never mentioned something like
.read_raw -> .ext_info_get.
The other thing I mentioned was to instead of having:
if (child) {
ch->info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_OFFSET);
}
You could use iio_backend_extend_chan_spec() and have the backend set the SCALE and
OFFSET bits for you as it seems these functionality depends on the backend.
But none of the above were critical or things that I feel to strong about.
Anyways, just wanted to give some clarification as it seems there were some
misunderstandings (I think).
- Nuno Sá
> >
next prev parent reply other threads:[~2024-06-24 15:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 16:08 [PATCH 0/8] iio: adc: dfsdm: add scaling support Olivier Moysan
2024-06-18 16:08 ` [PATCH 1/8] iio: add read raw service to iio backend framework Olivier Moysan
2024-06-19 5:25 ` Nuno Sá
2024-06-18 16:08 ` [PATCH 2/8] iio: add enable and disable services " Olivier Moysan
2024-06-19 5:21 ` Nuno Sá
2024-06-19 15:59 ` Olivier MOYSAN
2024-06-20 10:07 ` Nuno Sá
2024-06-23 13:56 ` Jonathan Cameron
2024-06-24 8:13 ` Nuno Sá
2024-06-18 16:08 ` [PATCH 3/8] iio: add child nodes support in " Olivier Moysan
2024-06-19 5:31 ` Nuno Sá
2024-06-19 16:00 ` Olivier MOYSAN
2024-06-23 13:59 ` Jonathan Cameron
2024-06-18 16:08 ` [PATCH 4/8] dt-bindings: iio: dfsdm: move to " Olivier Moysan
2024-06-18 18:10 ` Conor Dooley
2024-06-20 8:03 ` Olivier MOYSAN
2024-06-20 8:51 ` Conor Dooley
2024-06-23 15:01 ` Jonathan Cameron
2024-06-18 16:08 ` [PATCH 5/8] dt-bindings: iio: add sigma delta modulator backend Olivier Moysan
2024-06-18 18:13 ` Conor Dooley
2024-06-25 9:26 ` Olivier MOYSAN
2024-06-18 16:08 ` [PATCH 6/8] iio: adc: stm32-dfsdm: adopt generic channels bindings Olivier Moysan
2024-06-23 15:01 ` Jonathan Cameron
2024-06-18 16:08 ` [PATCH 7/8] iio: add sd modulator generic iio backend Olivier Moysan
2024-06-23 15:11 ` Jonathan Cameron
2024-06-24 12:43 ` Olivier MOYSAN
2024-06-24 15:22 ` Nuno Sá [this message]
2024-06-24 16:26 ` Olivier MOYSAN
2024-06-25 12:14 ` Nuno Sá
2024-06-24 17:41 ` Jonathan Cameron
2024-06-18 16:08 ` [PATCH 8/8] iio: adc: stm32-dfsdm: add scaling support to dfsdm Olivier Moysan
2024-06-19 5:47 ` Nuno Sá
2024-06-20 14:15 ` Olivier MOYSAN
2024-06-23 15:21 ` Jonathan Cameron
2024-06-25 9:39 ` Olivier MOYSAN
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=1ef85cdcffefee6b6a68927816f3d26c074a5331.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=broonie@kernel.org \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olivier.moysan@foss.st.com \
/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;
as well as URLs for NNTP newsgroup(s).