From: Jonathan Cameron <jic23@kernel.org>
To: Alexandru Ardelean <aardelean@baylibre.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, krzk+dt@kernel.org, robh@kernel.org,
lars@metafoo.de, michael.hennerich@analog.com,
gstols@baylibre.com
Subject: Re: [PATCH v5 6/9] iio: adc: ad7606: rework available attributes for SW channels
Date: Sun, 8 Sep 2024 11:47:11 +0100 [thread overview]
Message-ID: <20240908114711.0f350072@jic23-huawei> (raw)
In-Reply-To: <CA+GgBR99R=PEyTR_KZO6M_YiRepa5ZFhXcRRq=AtD65rn5MCZg@mail.gmail.com>
On Sat, 7 Sep 2024 21:10:10 +0300
Alexandru Ardelean <aardelean@baylibre.com> wrote:
> On Sat, Sep 7, 2024 at 6:04 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Sat, 7 Sep 2024 09:50:39 +0300
> > Alexandru Ardelean <aardelean@baylibre.com> wrote:
> >
> > > For SW mode, the oversampling and scales attributes are always present.
> > > So, they can be implemented via a 'read_avail' hook in iio_info.
> > >
> > > For HW mode, it's a bit tricky, as these attributes get assigned based on
> > > GPIO definitions.
> > >
> > > So, for SW mode, we define a separate AD7606_SW_CHANNEL() macro, and use
> > > that for the SW channels.
> > > And 'ad7606_info_os_range_and_debug' can be renamed to
> > > 'ad7606_info_sw_mode' as it is only used for SW mode.
> > >
> > > For the 'read_avail' hook, we'll need to allocate the SW scales, so that
> > > they are just returned userspace without any extra processing.
> > > The allocation will happen when then ad7606_state struct is allocated.
> > > The oversampling available parameters don't need any extra processing; they
> > > can just be passed back to userspace (as they are).
> > >
> > > Signed-off-by: Alexandru Ardelean <aardelean@baylibre.com>
> >
> > One question inline.
> >
> > >
> > > int ad7606_probe(struct device *dev, int irq, void __iomem *base_address,
> > > diff --git a/drivers/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h
> > > index 635407c2acc0..fa175cff256c 100644
> > > --- a/drivers/iio/adc/ad7606.h
> > > +++ b/drivers/iio/adc/ad7606.h
> >
> > > #define AD7616_CHANNEL(num) AD7606_SW_CHANNEL(num, 16)
> > >
> > > /**
> > > @@ -65,11 +84,15 @@ struct ad7606_chip_info {
> > > /**
> > > * struct ad7606_chan_scale - channel scale configuration
> > > * @scale_avail pointer to the array which stores the available scales
> > > + * @scale_avail_show a duplicate of 'scale_avail' which is readily formatted
> > > + * such that it can be read via the 'read_avail' hook
> > > * @num_scales number of elements stored in the scale_avail array
> > > * @range voltage range selection, selects which scale to apply
> > > */
> > > struct ad7606_chan_scale {
> > > +#define AD760X_MAX_SCALE_SHOW (AD760X_MAX_CHANNELS * 2)
> >
> > Why is the number of scales dependent on the number of channels?
>
> Well, that was just a lazy implementation.
> I doubt there would be 16 scales (channel range values) for any newer part.
> A value for a channel-range is 4-bits (for 0 to 15).
>
> In IIO the current highest scale-count is 5; I guess I can update this
> to a macro, and use that.
Indeed defining this as 16 would make more sense than basing it on random
unconnected thing!
Jonathan
>
>
> >
> > > const unsigned int *scale_avail;
> > > + int scale_avail_show[AD760X_MAX_SCALE_SHOW];
> > > unsigned int num_scales;
> > > unsigned int range;
> > > };
> >
next prev parent reply other threads:[~2024-09-08 10:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-07 6:50 [PATCH v5 0/9] iio: adc: ad7606: add support for AD7606C-{16,18} parts Alexandru Ardelean
2024-09-07 6:50 ` [PATCH v5 1/9] iio: adc: ad7606: remove frstdata check for serial mode Alexandru Ardelean
2024-09-07 14:51 ` Jonathan Cameron
2024-09-07 17:58 ` Alexandru Ardelean
2024-09-07 6:50 ` [PATCH v5 2/9] iio: adc: ad7606: add 'bits' parameter to channels macros Alexandru Ardelean
2024-09-07 14:53 ` Jonathan Cameron
2024-09-07 6:50 ` [PATCH v5 3/9] iio: adc: ad7606: move 'val' pointer to ad7606_scan_direct() Alexandru Ardelean
2024-09-07 6:50 ` [PATCH v5 4/9] iio: adc: ad7606: split a 'ad7606_sw_mode_setup()' from probe Alexandru Ardelean
2024-09-07 6:50 ` [PATCH v5 5/9] iio: adc: ad7606: wrap channel ranges & scales into struct Alexandru Ardelean
2024-09-07 6:50 ` [PATCH v5 6/9] iio: adc: ad7606: rework available attributes for SW channels Alexandru Ardelean
2024-09-07 15:03 ` Jonathan Cameron
2024-09-07 18:10 ` Alexandru Ardelean
2024-09-08 10:47 ` Jonathan Cameron [this message]
2024-09-07 6:50 ` [PATCH v5 7/9] dt-bindings: iio: adc: document diff-channels corner case for some ADCs Alexandru Ardelean
2024-09-07 6:50 ` [PATCH v5 8/9] dt-bindings: iio: adc: add docs for AD7606C-{16,18} parts Alexandru Ardelean
2024-09-07 6:50 ` [PATCH v5 9/9] iio: adc: ad7606: add support " Alexandru Ardelean
2024-09-07 15:20 ` Jonathan Cameron
2024-09-07 14:50 ` [PATCH v5 0/9] " Jonathan Cameron
2024-09-07 18:16 ` Alexandru Ardelean
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=20240908114711.0f350072@jic23-huawei \
--to=jic23@kernel.org \
--cc=aardelean@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=gstols@baylibre.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--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