All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Hennerich <michael.hennerich@analog.com>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: Variable accuracy devices.
Date: Tue, 28 Jun 2011 15:16:36 +0200	[thread overview]
Message-ID: <4E09D434.9030504@analog.com> (raw)
In-Reply-To: <4E09A5E0.7030300@cam.ac.uk>

On 06/28/2011 11:58 AM, Jonathan Cameron wrote:
> Hi All,
>
> There are a couple of different types of variable accuracy drivers in three.
>
> 1) Devices with variable gain - these are well handled
>
> 2) Devices with variable number of bits per sample. Typically they will
>     do higher accuracy at a slower rate.
>
> 3) Variable bit depths in hardware ring buffers (sca3000 only - currently
> glossed over).
>
>
> In case 2 we have for example the adis16130 gyro driver (a very simple driver).
> This one doesn't currently implement buffered capture, so our only read route
> is through the sysfs attributes.   So my question here is whether there is
> a use case for sampling at anything other than maximum accuracy if we are
> reading via a slow path anyway?
I don't think so.
>    Basically I'd like to drop the non standard
> interface that this driver has.
ACK

> Case 3 is one I've been avoiding mainly because it only exists in one driver
> right now and that one is for a long deprecated part.   It is however similar
> to a controllable nbit adc or indeed the adis16130 gyro.  In those cases we
> want to be able to control the accuracy of data that is captured into a
> software buffer.  Right now we don't have an easy way of doing this.
>
> The solution that comes to mind is:
> Additional optional callback within ring_setup_ops (it kind of fits in there
> if we broaden the term setup somewhat), checked by equivalent replacement
> of iio_show_fixed_type.  If it's present, the driver is queried, if not then
> we use the fixed type stuff from the iio_chan_spec structure.  Clearly
> we will also need a write function.  The matching _available attribute
> could be done by a second callback.
>
> What do people think?
Sounds good to me.

-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif

      reply	other threads:[~2011-06-28 13:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-28  9:58 Variable accuracy devices Jonathan Cameron
2011-06-28 13:16 ` Michael Hennerich [this message]

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=4E09D434.9030504@analog.com \
    --to=michael.hennerich@analog.com \
    --cc=jic23@cam.ac.uk \
    --cc=linux-iio@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.