Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: "Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Julien Stephan" <jstephan@baylibre.com>,
	"Esteban Blanc" <eblanc@baylibre.com>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/5] iio: add support for multiple scan types
Date: Sun, 2 Jun 2024 10:37:27 +0100	[thread overview]
Message-ID: <20240602103727.007e34d6@jic23-huawei> (raw)
In-Reply-To: <20240602102726.35120347@jic23-huawei>

On Sun, 2 Jun 2024 10:27:26 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> On Sun, 2 Jun 2024 10:25:17 +0100
> Jonathan Cameron <jic23@kernel.org> wrote:
> 
> > On Thu, 30 May 2024 10:14:07 -0500
> > David Lechner <dlechner@baylibre.com> 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/CAMknhBHOXaff__QyU-wFSNNENvs23vDX5n_ddH-Dw3s6-sQ9sg@mail.gmail.com/    
> > 
> > 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
> > 
> > 
> >   
> 
> 


  reply	other threads:[~2024-06-02  9:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-30 15:14 [PATCH v3 0/5] iio: add support for multiple scan types David Lechner
2024-05-30 15:14 ` [PATCH v3 1/5] iio: introduce struct iio_scan_type David Lechner
2024-05-30 15:14 ` [PATCH v3 2/5] iio: buffer: use struct iio_scan_type to simplify code David Lechner
2024-05-30 15:14 ` [PATCH v3 3/5] iio: add support for multiple scan types per channel David Lechner
2024-05-30 15:14 ` [PATCH v3 4/5] iio: adc: ad7380: use spi_optimize_message() David Lechner
2024-05-30 15:14 ` [PATCH v3 5/5] iio: adc: ad7380: add oversampling support David Lechner
2024-06-02  9:25 ` [PATCH v3 0/5] iio: add support for multiple scan types Jonathan Cameron
2024-06-02  9:27   ` Jonathan Cameron
2024-06-02  9:37     ` Jonathan Cameron [this message]
2024-06-03 10:25   ` Nuno Sá
2024-06-03 19:55     ` 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=20240602103727.007e34d6@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=dlechner@baylibre.com \
    --cc=eblanc@baylibre.com \
    --cc=jstephan@baylibre.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.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