From: Marek Vasut <marex@denx.de>
To: "Lars-Peter Clausen" <lars@metafoo.de>
Cc: linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Jonathan Cameron <jic23@kernel.org>, Wolfgang Denk <wd@denx.de>,
Juergen Beisert <jbe@pengutronix.de>
Subject: Re: [PATCH] IIO: Add basic MXS LRADC driver
Date: Fri, 20 Jul 2012 17:12:52 +0200 [thread overview]
Message-ID: <201207201712.52745.marex@denx.de> (raw)
In-Reply-To: <50096723.2070409@metafoo.de>
Dear Lars-Peter Clausen,
> On 07/19/2012 09:26 PM, Marek Vasut wrote:
> > 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).
>
> I'd consider that a bug in your driver ;)
> The intend with IIO is that once you start sampling by enabling the buffer
> you get a continuous data stream until sampling is stopped and this works
> fine with other drivers.
Ah! Thanks, I'll poke into this.
> - Lars
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
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 17:12:52 +0200 [thread overview]
Message-ID: <201207201712.52745.marex@denx.de> (raw)
In-Reply-To: <50096723.2070409@metafoo.de>
Dear Lars-Peter Clausen,
> On 07/19/2012 09:26 PM, Marek Vasut wrote:
> > 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).
>
> I'd consider that a bug in your driver ;)
> The intend with IIO is that once you start sampling by enabling the buffer
> you get a continuous data stream until sampling is stopped and this works
> fine with other drivers.
Ah! Thanks, I'll poke into this.
> - Lars
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-07-20 15:12 UTC|newest]
Thread overview: 55+ 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 2:15 ` Marek Vasut
2012-07-04 4:30 ` Wolfgang Denk
2012-07-04 4:30 ` Wolfgang Denk
2012-07-04 8:35 ` Lars-Peter Clausen
2012-07-04 8:35 ` Lars-Peter Clausen
2012-07-04 23:48 ` Marek Vasut
2012-07-04 23:48 ` Marek Vasut
2012-07-05 8:33 ` Lars-Peter Clausen
2012-07-05 8:33 ` Lars-Peter Clausen
2012-07-05 19:53 ` Marek Vasut
2012-07-05 19:53 ` Marek Vasut
2012-07-19 14:23 ` Marek Vasut
2012-07-19 14:23 ` Marek Vasut
2012-07-19 14:33 ` Lars-Peter Clausen
2012-07-19 14:33 ` Lars-Peter Clausen
2012-07-19 15:15 ` Marek Vasut
2012-07-19 15:15 ` Marek Vasut
2012-07-19 19:26 ` Marek Vasut
2012-07-19 19:26 ` Marek Vasut
2012-07-20 2:18 ` Marek Vasut
2012-07-20 2:18 ` Marek Vasut
2012-07-20 8:39 ` Robert Schwebel
2012-07-20 8:39 ` Robert Schwebel
2012-07-20 11:32 ` Marek Vasut
2012-07-20 11:32 ` Marek Vasut
2012-07-20 14:09 ` Lars-Peter Clausen
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 14:11 ` Lars-Peter Clausen
2012-07-20 15:12 ` Marek Vasut [this message]
2012-07-20 15:12 ` Marek Vasut
2012-07-09 9:19 ` Juergen Beisert
2012-07-09 9:19 ` Juergen Beisert
2012-07-09 9:52 ` Lars-Peter Clausen
2012-07-09 9:52 ` Lars-Peter Clausen
2012-07-09 10:03 ` Marek Vasut
2012-07-09 10:03 ` Marek Vasut
2012-07-10 9:20 ` Juergen Beisert
2012-07-10 9:20 ` Juergen Beisert
2012-07-10 9:26 ` Marek Vasut
2012-07-10 9:26 ` Marek Vasut
2012-07-10 9:49 ` Juergen Beisert
2012-07-10 9:49 ` Juergen Beisert
2012-07-10 10:08 ` Marek Vasut
2012-07-10 10:08 ` Marek Vasut
2012-07-10 10:26 ` Juergen Beisert
2012-07-10 10:26 ` Juergen Beisert
2012-07-10 10:35 ` Lars-Peter Clausen
2012-07-10 10:35 ` Lars-Peter Clausen
2012-07-10 10:41 ` Juergen Beisert
2012-07-10 10:41 ` Juergen Beisert
2012-07-10 10:45 ` Marek Vasut
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=201207201712.52745.marex@denx.de \
--to=marex@denx.de \
--cc=jbe@pengutronix.de \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=wd@denx.de \
/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.