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@xxxxxxx> > >> > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
