[v3,0/5] iio: add support for multiple scan types

Message

David Lechner May 30, 2024, 3:14 p.m. UTC

Up to now, the IIO subsystem has only supported a single scan type per
channel. This scan type determines the binary format of the data in the
buffer when doing buffered reads.

For simple devices, there is only one scan type and all is well. But
for more complex devices, there may be multiple scan types. For example,
ADCs with a resolution boost feature that adds more bits to the raw
sample data. Traditionally, for slow devices, we've just always used the
highest resolution mode, but for high performance ADCs, this may not be
always practical. Manipulating data after every read can hurt performance
and in the case of hardware buffers, it may not be possible to change the
format of the data in the buffer at all. There are also ADCs where
enabling the higher resolution can only be done if oversampling is also
enabled which may not be desireable.

To allow for more flexibility, we would like to add support for multiple
scan types per channel.

To avoid having to touch every driver, we implemented this in a way that
preserves the existing scan_type field. See the "iio: add support for
multiple scan types per channel" the details. The first couple of patches
are just preparation for this.

[1]: https://lore.kernel.org/linux-iio/[e-mail]/

---
Changes in v3:
* Changed return type of get_current_scan_type callback to int.
* Brought back updated ad7380 patches.
* Link to v2: https://lore.kernel.org/r/20[e-mail]

Changes in v2:
* Use union for scan_type and scan_type_ext.
* Dropped ad7380 patch - those changed will be squashed into the next
  revision of the series adding the driver for ad7380.
* Temporary updated ad7380 patch for reference: https://github.com/dlech/linux/commit/64be3de241e73b43c5a5daa44b6b97f35f0743bf
* Link to v1: https://lore.kernel.org/r/20[e-mail]

---
David Lechner (4):
      iio: introduce struct iio_scan_type
      iio: buffer: use struct iio_scan_type to simplify code
      iio: add support for multiple scan types per channel
      iio: adc: ad7380: use spi_optimize_message()

Julien Stephan (1):
      iio: adc: ad7380: add oversampling support

 drivers/iio/adc/ad7380.c          | 335 +++++++++++++++++++++++++++++++-------
 drivers/iio/industrialio-buffer.c | 129 +++++++++++----
 include/linux/iio/iio.h           |  94 ++++++++---
 3 files changed, 450 insertions(+), 108 deletions(-)
---
base-commit: b4bfc5f52090336f5f5b65bbdac394ac1001952d
change-id: 20240507-iio-add-support-for-multiple-scan-types-f4dbcf4c2cb8

Comments

Jonathan Cameron June 2, 2024, 9:25 a.m. UTC | #1

On Thu, 30 May 2024 10:14:07 -0500
David Lechner <[e-mail]> wrote:

> Up to now, the IIO subsystem has only supported a single scan type per
> channel. This scan type determines the binary format of the data in the
> buffer when doing buffered reads.
> 
> For simple devices, there is only one scan type and all is well. But
> for more complex devices, there may be multiple scan types. For example,
> ADCs with a resolution boost feature that adds more bits to the raw
> sample data. Traditionally, for slow devices, we've just always used the
> highest resolution mode, but for high performance ADCs, this may not be
> always practical. Manipulating data after every read can hurt performance
> and in the case of hardware buffers, it may not be possible to change the
> format of the data in the buffer at all. There are also ADCs where
> enabling the higher resolution can only be done if oversampling is also
> enabled which may not be desireable.
> 
> To allow for more flexibility, we would like to add support for multiple
> scan types per channel.
> 
> To avoid having to touch every driver, we implemented this in a way that
> preserves the existing scan_type field. See the "iio: add support for
> multiple scan types per channel" the details. The first couple of patches
> are just preparation for this.
> 
> [1]: https://lore.kernel.org/linux-iio/[e-mail]/

Nice series. Applied to the togreg branch of iio.git and pushed out as
testing for 0-day to poke at it.

Obviously this v3 hasn't been on list that long, but there is still time
as I doubt I'll push out a non rebasing tree for a week or so.
This week is looking too busy!

Thanks,

Jonathan

Jonathan Cameron June 2, 2024, 9:27 a.m. UTC | #2

On Sun, 2 Jun 2024 10:25:17 +0100
Jonathan Cameron <[e-mail]> wrote:

> On Thu, 30 May 2024 10:14:07 -0500
> David Lechner <[e-mail]> wrote:
> 
> > Up to now, the IIO subsystem has only supported a single scan type per
> > channel. This scan type determines the binary format of the data in the
> > buffer when doing buffered reads.
> > 
> > For simple devices, there is only one scan type and all is well. But
> > for more complex devices, there may be multiple scan types. For example,
> > ADCs with a resolution boost feature that adds more bits to the raw
> > sample data. Traditionally, for slow devices, we've just always used the
> > highest resolution mode, but for high performance ADCs, this may not be
> > always practical. Manipulating data after every read can hurt performance
> > and in the case of hardware buffers, it may not be possible to change the
> > format of the data in the buffer at all. There are also ADCs where
> > enabling the higher resolution can only be done if oversampling is also
> > enabled which may not be desireable.
> > 
> > To allow for more flexibility, we would like to add support for multiple
> > scan types per channel.
> > 
> > To avoid having to touch every driver, we implemented this in a way that
> > preserves the existing scan_type field. See the "iio: add support for
> > multiple scan types per channel" the details. The first couple of patches
> > are just preparation for this.
> > 
> > [1]: https://lore.kernel.org/linux-iio/[e-mail]/  
> 
> Nice series. Applied to the togreg branch of iio.git and pushed out as
> testing for 0-day to poke at it.
> 
> Obviously this v3 hasn't been on list that long, but there is still time
> as I doubt I'll push out a non rebasing tree for a week or so.
> This week is looking too busy!

oops. Goes to show I'm not keeping track of things very well today.
I haven't applied the driver this updates yet.

I'll look at that now and hopefully I can pick them both up.

Jonathan

> 
> Thanks,
> 
> Jonathan
> 
> 
>

Jonathan Cameron June 2, 2024, 9:37 a.m. UTC | #3

On Sun, 2 Jun 2024 10:27:26 +0100
Jonathan Cameron <[e-mail]> wrote:

> On Sun, 2 Jun 2024 10:25:17 +0100
> Jonathan Cameron <[e-mail]> wrote:
> 
> > On Thu, 30 May 2024 10:14:07 -0500
> > David Lechner <[e-mail]> wrote:
> >   
> > > Up to now, the IIO subsystem has only supported a single scan type per
> > > channel. This scan type determines the binary format of the data in the
> > > buffer when doing buffered reads.
> > > 
> > > For simple devices, there is only one scan type and all is well. But
> > > for more complex devices, there may be multiple scan types. For example,
> > > ADCs with a resolution boost feature that adds more bits to the raw
> > > sample data. Traditionally, for slow devices, we've just always used the
> > > highest resolution mode, but for high performance ADCs, this may not be
> > > always practical. Manipulating data after every read can hurt performance
> > > and in the case of hardware buffers, it may not be possible to change the
> > > format of the data in the buffer at all. There are also ADCs where
> > > enabling the higher resolution can only be done if oversampling is also
> > > enabled which may not be desireable.
> > > 
> > > To allow for more flexibility, we would like to add support for multiple
> > > scan types per channel.
> > > 
> > > To avoid having to touch every driver, we implemented this in a way that
> > > preserves the existing scan_type field. See the "iio: add support for
> > > multiple scan types per channel" the details. The first couple of patches
> > > are just preparation for this.
> > > 
> > > [1]: https://lore.kernel.org/linux-iio/[e-mail]/    
> > 
> > Nice series. Applied to the togreg branch of iio.git and pushed out as
> > testing for 0-day to poke at it.
> > 
> > Obviously this v3 hasn't been on list that long, but there is still time
> > as I doubt I'll push out a non rebasing tree for a week or so.
> > This week is looking too busy!  
> 
> oops. Goes to show I'm not keeping track of things very well today.
> I haven't applied the driver this updates yet.
> 
> I'll look at that now and hopefully I can pick them both up.
> 
That was fine, so both now applied.
> Jonathan
> 
> > 
> > Thanks,
> > 
> > Jonathan
> > 
> > 
> >   
> 
>

Nuno Sá June 3, 2024, 10:25 a.m. UTC | #4

On Sun, 2024-06-02 at 10:25 +0100, Jonathan Cameron wrote:
> On Thu, 30 May 2024 10:14:07 -0500
> David Lechner <[e-mail]> wrote:
> 
> > Up to now, the IIO subsystem has only supported a single scan type per
> > channel. This scan type determines the binary format of the data in the
> > buffer when doing buffered reads.
> > 
> > For simple devices, there is only one scan type and all is well. But
> > for more complex devices, there may be multiple scan types. For example,
> > ADCs with a resolution boost feature that adds more bits to the raw
> > sample data. Traditionally, for slow devices, we've just always used the
> > highest resolution mode, but for high performance ADCs, this may not be
> > always practical. Manipulating data after every read can hurt performance
> > and in the case of hardware buffers, it may not be possible to change the
> > format of the data in the buffer at all. There are also ADCs where
> > enabling the higher resolution can only be done if oversampling is also
> > enabled which may not be desireable.
> > 
> > To allow for more flexibility, we would like to add support for multiple
> > scan types per channel.
> > 
> > To avoid having to touch every driver, we implemented this in a way that
> > preserves the existing scan_type field. See the "iio: add support for
> > multiple scan types per channel" the details. The first couple of patches
> > are just preparation for this.
> > 
> > [1]:
> > https://lore.kernel.org/linux-iio/[e-mail]/
> 
> Nice series. Applied to the togreg branch of iio.git and pushed out as
> testing for 0-day to poke at it.
> 
> Obviously this v3 hasn't been on list that long, but there is still time
> as I doubt I'll push out a non rebasing tree for a week or so.
> This week is looking too busy!

If there's still time, feel free to add my tag:

Reviewed-by: Nuno Sa <[e-mail]>

Jonathan Cameron June 3, 2024, 7:55 p.m. UTC | #5

On Mon, 03 Jun 2024 12:25:55 +0200
Nuno Sá <[e-mail]> wrote:

> On Sun, 2024-06-02 at 10:25 +0100, Jonathan Cameron wrote:
> > On Thu, 30 May 2024 10:14:07 -0500
> > David Lechner <[e-mail]> wrote:
> >   
> > > Up to now, the IIO subsystem has only supported a single scan type per
> > > channel. This scan type determines the binary format of the data in the
> > > buffer when doing buffered reads.
> > > 
> > > For simple devices, there is only one scan type and all is well. But
> > > for more complex devices, there may be multiple scan types. For example,
> > > ADCs with a resolution boost feature that adds more bits to the raw
> > > sample data. Traditionally, for slow devices, we've just always used the
> > > highest resolution mode, but for high performance ADCs, this may not be
> > > always practical. Manipulating data after every read can hurt performance
> > > and in the case of hardware buffers, it may not be possible to change the
> > > format of the data in the buffer at all. There are also ADCs where
> > > enabling the higher resolution can only be done if oversampling is also
> > > enabled which may not be desireable.
> > > 
> > > To allow for more flexibility, we would like to add support for multiple
> > > scan types per channel.
> > > 
> > > To avoid having to touch every driver, we implemented this in a way that
> > > preserves the existing scan_type field. See the "iio: add support for
> > > multiple scan types per channel" the details. The first couple of patches
> > > are just preparation for this.
> > > 
> > > [1]:
> > > https://lore.kernel.org/linux-iio/[e-mail]/  
> > 
> > Nice series. Applied to the togreg branch of iio.git and pushed out as
> > testing for 0-day to poke at it.
> > 
> > Obviously this v3 hasn't been on list that long, but there is still time
> > as I doubt I'll push out a non rebasing tree for a week or so.
> > This week is looking too busy!  
> 
> If there's still time, feel free to add my tag:
> 
> Reviewed-by: Nuno Sa <[e-mail]>
> 
Done