>
> > +static struct iio_chan_spec_ext_info ad4858_ext_info[] = {
> > + IIO_ENUM("packet_format", IIO_SHARED_BY_ALL, &ad4858_packet_fmt),
> > + IIO_ENUM_AVAILABLE("packet_format",
> > + IIO_SHARED_BY_ALL, &ad4858_packet_fmt),
> > + {},
> > +};
> > +
> > +static struct iio_chan_spec_ext_info ad4857_ext_info[] = {
> > + IIO_ENUM("packet_format", IIO_SHARED_BY_ALL, &ad4857_packet_fmt),
> > + IIO_ENUM_AVAILABLE("packet_format",
> > + IIO_SHARED_BY_ALL, &ad4857_packet_fmt),
> > + {},
> > +};
>
> Usually, something like this packet format would be automatically
> selected when buffered reads are enabled based on what other features
> it provides are needed, i.e only enable the status bits when events
> are enabled.
>
> (For those that didn't read the datasheet, the different packet
> formats basically enable extra status bits per sample. And in the case
> of oversampling, one of the formats also selects a reduced number of
> sample bits.)
>
> We have quite a few parts in the pipline right like this one that have
> per-sample status bits. In the past, these were generally handled with
> IIO events, but this doesn't really work for these high-speed backends
> since the data is being piped directly to DMA and we don't look at
> each sample in the ADC driver. So it would be worthwhile to try to
> find some general solution here for handling this sort of thing.
We have previously talked about schemes to describe metadata
alongside channels. I guess maybe it's time to actually look at how
that works. I'm not sure dynamic control of that metadata
is going to be easy to do though or if we even want to
(as opposed to always on or off for a particular device).
