[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51C5A68F.3000300@free-electrons.com>
Date: Sat, 22 Jun 2013 15:28:47 +0200
From: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To: Lars-Peter Clausen <lars@...afoo.de>
CC: Jonathan Cameron <jic23@...nel.org>,
Shawn Guo <shawn.guo@...aro.org>,
Grant Likely <grant.likely@...retlab.ca>, jimwall@...om,
brian@...stalfontz.com,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree-discuss@...ts.ozlabs.org,
Jonathan Cameron <jic23@....ac.uk>,
Rob Landley <rob@...dley.net>,
Rob Herring <rob.herring@...xeda.com>
Subject: Re: [PATCHv2 1/3] iio: Add Nuvoton NAU7802 ADC driver
On 22/06/2013 15:20, Lars-Peter Clausen wrote:
> On 06/22/2013 03:07 PM, Alexandre Belloni wrote:
>> On 22/06/2013 14:02, Lars-Peter Clausen wrote:
>>> On 06/22/2013 01:55 PM, Jonathan Cameron wrote:
>>>> On 06/20/2013 07:57 PM, Alexandre Belloni wrote:
>>>>> The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
>>>>> gain and sampling rates.
>>>>>
>>>> Sorry, somewhat low on time today so only a quick review.
>>>>
>>>> 1) Missing userspace ABI documentation. Also, perhaps min_conversions is
>>>> a little vague? Not that I have a better idea!
>>> I really don't like the name min_conversions either. Isn't this effectively
>>> a decimation filter?
>> Yeah, it could be seen like that but it is only relevant and only
>> happens when switching between channels. I'm open to any ideas.
>>
> I see. Is there anything about this in the datasheet on how many conversions
> you usually need? Is this really something you need to change at runtime or
> does moving this to platform data work?
>
>
There is actually nothing in the datasheet. The default value (6
conversions) was found experimentally. What I did was saturating the ADC
with the higher value on one channel and the lower value on the other
one and I tried to find when reading both channel sequentially was
resulting in a correct value.
You may not need to change it at runtime. And that value mainly depend
on the precision versus speed balance you want to achieve. If you know
that the values on both channels will not be to far apart, then you may
not need to wait at all.
Would you think that is something I should hide in the DT ? Or maybe I
can drop that knob for now and see if it is needed in the future.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists