[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+GgBR99R=PEyTR_KZO6M_YiRepa5ZFhXcRRq=AtD65rn5MCZg@mail.gmail.com>
Date: Sat, 7 Sep 2024 21:10:10 +0300
From: Alexandru Ardelean <aardelean@...libre.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, krzk+dt@...nel.org, robh@...nel.org,
lars@...afoo.de, michael.hennerich@...log.com, gstols@...libre.com
Subject: Re: [PATCH v5 6/9] iio: adc: ad7606: rework available attributes for
SW channels
On Sat, Sep 7, 2024 at 6:04 PM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Sat, 7 Sep 2024 09:50:39 +0300
> Alexandru Ardelean <aardelean@...libre.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@...libre.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.
>
> > const unsigned int *scale_avail;
> > + int scale_avail_show[AD760X_MAX_SCALE_SHOW];
> > unsigned int num_scales;
> > unsigned int range;
> > };
>
Powered by blists - more mailing lists