linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] IIO: Add basic MXS LRADC driver
Date: Fri, 20 Jul 2012 04:18:41 +0200	[thread overview]
Message-ID: <201207200418.41554.marex@denx.de> (raw)
In-Reply-To: <201207192126.31772.marex@denx.de>

Dear Lars-Peter Clausen,

> > On 07/19/2012 04:23 PM, Marek Vasut wrote:
> > > Dear Lars-Peter Clausen,
> > > 
> > > Sorry for my late reply, got busy with other crazy stuff.
> > > 
> > > [...]
> > > 
> > >>>> Is there any reason not to use the mxs_lradc struct directly has the
> > >>>> iio data?
> > >>> 
> > >>> I explained it below in the patch. I hope we'll eventually support
> > >>> the delay triggers, which will need 4 separate IIO devices. And this
> > >>> is where this structure will be augmented by other components.
> > >> 
> > >> Ok I saw the comment, but it wasn't obvious to me that delay channels
> > >> will require multiple IIO devices. Might make sense to state this
> > >> explicitly.
> > > 
> > > Fixed.
> > > 
> > >>>>> [...]
> > >>>>> 
> > >>>>> +
> > >>>>> +/*
> > >>>>> + * Channel management
> > >>>>> + *
> > >>>>> + * This involves crazy mapping between 8 virtual channels the
> > >>>>> CTRL4 register + * can harbor and 16 channels total this hardware
> > >>>>> supports. + */
> > >>>> 
> > >>>> I suppose this means only a maximum 8 channels can be active at a
> > >>>> time. I've recently posted a patch which makes it easy to implement
> > >>>> such a restriction.
> > >>>> http://www.spinics.net/lists/linux-iio/msg05936.html and
> > >>>> http://www.spinics.net/lists/linux-iio/msg05935.html for an example
> > >>>> validate callback implementation. In your case you'd check for
> > >>>> bitmap_weight(...) <= 8. Those patches are not yet in IIO though.
> > >>> 
> > >>> This is good. When do you expect this to hit linux-next possibly? Or
> > >>> at least linux-iio?
> > >> 
> > >> soon, hopefully.
> > > 
> > > So I checked this, not sure how it'll help me though.
> > 
> > Right now with your driver you can enable any combination of channels. If
> > more than 8 channels are enabled and you start sampling it will fail,
> > since not all channels can be mapped. With those patch you can implement
> > a validate callback and check for bitmap_weight(scan_mask) <= 8. This
> > will ensure that it is not possible to select more than 8 channels at
> > once, which again means that starting sampling can't fail of this.
> 
> Ok, I fixed this one. One last thing that I don't really understand is
> this. I run generic_buffer.c to source samples from the LRADC. Is there
> any way to continuously sample them? Because right now, I get one sample
> and that's it, no more samples happen later on (I can 0 data in subsequent
> read() call).

One more thing I'm curious about. There's another ADC block on the CPU, called 
HSADC (high-speed ADC). It can sample even up to 2Msamples/s. If I were to, say 
-- sample at 100kHz and be able to DMA the results into memory -- is there any 
way to push such results into userland somehow? Or how to operate such fast 
beast?

Best regards,
Marek Vasut

  reply	other threads:[~2012-07-20  2:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04  2:15 [PATCH] IIO: Add basic MXS LRADC driver Marek Vasut
2012-07-04  4:30 ` Wolfgang Denk
2012-07-04  8:35 ` Lars-Peter Clausen
2012-07-04 23:48   ` Marek Vasut
2012-07-05  8:33     ` Lars-Peter Clausen
2012-07-05 19:53       ` Marek Vasut
2012-07-19 14:23       ` Marek Vasut
2012-07-19 14:33         ` Lars-Peter Clausen
2012-07-19 15:15           ` Marek Vasut
2012-07-19 19:26           ` Marek Vasut
2012-07-20  2:18             ` Marek Vasut [this message]
2012-07-20  8:39               ` Robert Schwebel
2012-07-20 11:32                 ` Marek Vasut
2012-07-20 14:09               ` Lars-Peter Clausen
2012-07-22 19:48                 ` Jonathan Cameron
2012-07-20 14:11             ` Lars-Peter Clausen
2012-07-20 15:12               ` Marek Vasut
2012-07-09  9:19 ` Juergen Beisert
2012-07-09  9:52   ` Lars-Peter Clausen
2012-07-09 10:03   ` Marek Vasut
2012-07-10  9:20     ` Juergen Beisert
2012-07-10  9:26       ` Marek Vasut
2012-07-10  9:49         ` Juergen Beisert
2012-07-10 10:08           ` Marek Vasut
2012-07-10 10:26             ` Juergen Beisert
2012-07-10 10:35               ` Lars-Peter Clausen
2012-07-10 10:41                 ` Juergen Beisert
2012-07-10 10:45                   ` Marek Vasut

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=201207200418.41554.marex@denx.de \
    --to=marex@denx.de \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).