Re: [PATCH 1/4] iio: mxs-lradc: change the realbits to 12

[Marek Vasut <marex@denx.de>]

Hi Jonathan,

> On 07/05/2013 06:17 PM, Lars-Peter Clausen wrote:
> > On 07/05/2013 04:35 PM, Hector Palacios wrote:
> >> On 07/05/2013 03:10 PM, Marek Vasut wrote:
> >>> Dear Hector Palacios,
> >>> 
> >>>> Dear Marek,
> >>>> 
> >>>> On 07/05/2013 01:37 PM, Marek Vasut wrote:
> >>>>> Dear Hector Palacios,
> >>>>> 
> >>>>>> The LRADC virtual channels have an 18 bit field to store the sum of
> >>>>>> up to 2^5 accumulated samples. The read_raw function however only
> >>>>>> operates over a single sample (12 bit resolution).
> >>>>>> In order to use this field for scaling operations, we need it to be
> >>>>>> the exact resolution value of the LRADC.
> >>>>> 
> >>>>> How would this work once the accumulation is supported?
> >>>> 
> >>>> As I see it, when you read a channel the driver should give you the
> >>>> 12-bit value either of one single sample or of N samples.
> >>> 
> >>> The hardware will always give you 18 bit value, let's call it A of N
> >>> accumulated samples, each 12 bit long. N is in range of 1 to 32 .
> >>> 
> >>> The driver currently supports N = 1.
> >>> 
> >>> Do I understand it correctly that if we want to support N > 1, we have
> >>> to do the division of A / N in the driver and therefore we will again
> >>> report only a 12-bit value to the userland ?
> >>> 
> >>> If so,
> >>> 
> >>> Acked-by: Marek Vasut <marex@denx.de>
> >> 
> >> That's what I would expect. I mean, what is A worth for? It's just a
> >> sum, it tells nothing. The value that really carries information is A /
> >> N, which is the average value.
> >> 
> >> @Lars: is there any driver that allows to read N samples? Does the IIO
> >> subsystem supply such interface (i.e. a file called n_samples that you
> >> can program from userland to trigger a read of that N samples in order
> >> to get the average value when you read that channel)?
> > 
> > The ad7606 has the 'oversampling_ratio' attribute. On the other hand the
> > ad7606 is not the best example either and this is a custom API. But well
> > that's what it is and since it's not the only device that supports
> > oversampling we should try and standardize a property name for this. The
> > ad7606 does the averaging in hardware though.
> 
> There is some 'filtering' abi defined and arguably this is just a mean
> filter with a particular width window, perhaps treating it like that is
> the cleanest abi wise. The intent was always to extend this filtering ABI
> to describe common filter types but it hasn't happened yet :)  (that
> oversampling_ratio is horrible and doesn't generalize nicely at all).
> 
> Propose an ABI addition for what you need....
> Just to start things off, my gut feeling would be somethign along the lines
> of
> 
> in_voltageX_filter_mean_width
> 
> with appropriate additions to info_mask as there are plenty of devices that
> do this (though usually with on board division as Lars suggested - though
> often for short widths they just fill the last few bits with 0's).
> 
> On this note, one of the more 'interesting' uses of the buffering
> infrastructure is that you can do software implementations of simple
> filters to cut down on the data flow to userspace. If only there was more
> time in the day ;)

... and a stronger coffee.

Best regards,
Marek Vasut