From: Lars-Peter Clausen <lars@metafoo.de>
To: Marek Vasut <marex@denx.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: Thu, 19 Jul 2012 16:33:36 +0200 [thread overview]
Message-ID: <50081AC0.10703@metafoo.de> (raw)
In-Reply-To: <201207191623.14492.marex@denx.de>
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.
- Lars
WARNING: multiple messages have this Message-ID (diff)
From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] IIO: Add basic MXS LRADC driver
Date: Thu, 19 Jul 2012 16:33:36 +0200 [thread overview]
Message-ID: <50081AC0.10703@metafoo.de> (raw)
In-Reply-To: <201207191623.14492.marex@denx.de>
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@once, which
again means that starting sampling can't fail of this.
- Lars
next prev parent reply other threads:[~2012-07-19 14:33 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 [this message]
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
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=50081AC0.10703@metafoo.de \
--to=lars@metafoo.de \
--cc=jbe@pengutronix.de \
--cc=jic23@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=marex@denx.de \
--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.