From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] IIO: Add basic MXS LRADC driver
Date: Fri, 20 Jul 2012 16:11:47 +0200 [thread overview]
Message-ID: <50096723.2070409@metafoo.de> (raw)
In-Reply-To: <201207192126.31772.marex@denx.de>
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.
- Lars
next prev parent reply other threads:[~2012-07-20 14:11 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
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 [this message]
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=50096723.2070409@metafoo.de \
--to=lars@metafoo.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).