On Mon, 6 May 2024 09:44:25 -0500 David Lechner <dlechner@xxxxxxxxxxxx> wrote: > FYI, Julien is AFK for a bit so I'll try to respond to the non-trivial comments. > > On Mon, May 6, 2024 at 8:46 AM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > > > On Mon, 06 May 2024 10:55:46 +0200 > > Nuno Sá <noname.nuno@xxxxxxxxx> wrote: > > > > > On Wed, 2024-05-01 at 16:55 +0200, Julien Stephan wrote: > > > > ad738x chips are able to use an additional 2 bits of resolution when > > > > using oversampling. The 14-bits chips can have up to 16 bits of > > > > resolution and the 16-bits chips can have up to 18 bits of resolution. > > > > > > > > In order to dynamically allow to enable/disable the resolution boost > > > > feature, we have to set iio realbits/storagebits to the maximum per chips. > > > > This means that for iio, data will always be on the higher resolution > > > > available, and to cope with that we adjust the iio scale and iio offset > > > > depending on the resolution boost status. > > > > > > > > The available scales can be displayed using the regular _scale_available > > > > attributes and can be set by writing the regular _scale attribute. > > > > The available scales depend on the oversampling status. > > > > > > > > Signed-off-by: Julien Stephan <jstephan@xxxxxxxxxxxx> > > > > > > > > --- > > > > > > > > In order to support the resolution boost (additional 2 bits of resolution) > > > > we need to set realbits/storagebits to the maximum value i.e : > > > > - realbits = 16 + 2 = 18, and storagebits = 32 for 16-bits chips > > > > - realbits = 14 + 2 = 16, and storagebits = 16 for 14-bits chips > > > > > > > > For 14-bits chips this does not have a major impact, but this > > > > has the drawback of forcing 16-bits chip users to always use 32-bits > > > > words in buffers even if they are not using oversampling and resolution > > > > boost. Is there a better way of implementing this? For example > > > > implementing dynamic scan_type? > > > > > > > > > > Yeah, I don't think it's that bad in this case. But maybe dynamic scan types is > > > something we may need at some point yes (or IOW that I would like to see supported > > > :)). We do some ADCs (eg: ad4630) where we use questionably use FW properties to set > > > a specific operating mode exactly because we have a different data layout (scan > > > elements) depending on the mode. > > > > Yeah. Fixed scan modes were somewhat of a bad design decision a long time back. > > However, the big advantage is that it got people to think hard about whether it is > > worth supporting low precision modes. For slow devices it very rarely is and > > forcing people to make a decision and the advantage we never supported > > low precision on those parts. > > > > Having said that there are good reasons for dynamic resolution changing > > (the main one being the storage case you have here) so I'd be happy to > > see some patches adding it. It might be easier than I've always thought > > to bolt on. > > > > This and inkernel event consumers have been the two significant features > > where I keep expecting it to happen, but every time people decide they really > > don't care enough to make them work :( > > > > Supposing we knew someone willing and able :-) ... > > Do you have any specific requirements for how dynamic resolution > changing should work? Any particular sticky points we should watch out > for? > > I'm assuming this would just affect the bufferY/*_type attributes, > i.e. if you write a channel scale attribute to change the resolution, > then the scan_type info may change and the bufferY/*_type would need > to be read again. I think you'd use those sysfs files for the control as well. So write to the *_type for a channel. That might well effect a bunch of other channels. Another interface would perhaps be more confusing than anything and something simple won't be specific enough as we are sure to get a device with multiple channels only some of which have variable scale. Definitely don't allow such a write when buffered capture is going on as that would be chaos. Also for this one we'd want control over the file attributes for those files so they are only writeable if we support changing this (which is rare). Also need a way of knowing what values are available so probably *_type_available - the presence of that also indicating if the scale can be changed. J >
