Re: IIO channel type for status/error flag indicators

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 20 Mar 2019 14:53:50 +0000
"Popa, Stefan Serban" <StefanSerban.Popa@analog.com> wrote:

> Hello,
> 
> We are currently working on a new adis16495 IMU driver which is an upgrade
> from the adis16480 family: https://www.analog.com/media/en/technical-docume
> ntation/data-sheets/ADIS16495.pdf.
> 
> This new chip supports a feature called "Burst Read Function" (page 13 in
> the datasheet). The burst read function (BRF) provides a method for reading
> a batch of data (status, temperature, gyroscopes, accelerometers, time
> stamp/data counter, and CRC code), which does not require a stall
> time between each 16-bit segment and only requires one command
> on the DIN line to initiate.
> 
> Most of the data read in this way can be attributed to a type of channel: 
> IIO_TEMP, IIO_ANGL_VEL, IIO_ACCEL, etc. However, there is no equivalent for
> the status and CRC. The status register provides various error flags such
> as spi communication error, sensor failure, sync error, etc (Table 18 in
> the datasheet). This information together with the CRC error should be
> exposed to the user space. What is the best way to do it? 

Ok, So this is not exactly unusual.  The issue has always been defining
a remotely generic userspace ABI.

> 
> The most obvious way, but not necessarily the correct one, would be to add
> a new channel type called something like IIO_STATUS or IIO_FLAG. Is this
> acceptable?

No unfortunately. What does generic userspace do with it?

Part of the problem is we don't have a channel type to cover flags in
general (if we had digital inputs packed into bytes we would at least
be slightly better off).

> 
> A more or less similar burst read function has been previously implemented
> as part of the adis16400 driver. Although a burst read will also produce
> diagnostic status data, it was ignored in the driver implementation.
Yup :)  Couldn't figure out how to do it at the time.

Normally these flags represent error conditions (if they map to events
in IIO then put them out like that).  The problem has always been that
Linux doesn't actually have generic simple error event handling.
There is RAS handling for servers, but who runs it on embedded boards
except possibly for some form of EDAC.

> 
> Looking forward to any suggestion.

I'm not against us having meta data channels, but they pretty much need
to be as tightly defined as any other channel.  The other side issue
here is it's a new 'huge' space.  However, I'm not sure you are in
that territory here.  Looks to me like status really means error.
If you get an error, mostly it's game over.  If you get a CRC error
and want to check it, then drop the record and spit out a message.

So I'm a little unconvinced as yet that there is anything we actually
can use in this status message.

Jonathan


> 
> -Stefan