Re: IIO channel type for status/error flag indicators

["Popa, Stefan Serban" <StefanSerban.Popa@analog.com>]

Hi Jonathan,

We'll come back with an interface proposal.
Thank you!

-Stefan

On Du, 2019-03-31 at 12:11 +0100, Jonathan Cameron wrote:
> On Thu, 28 Mar 2019 18:38:21 +0000
> "Popa, Stefan Serban" <StefanSerban.Popa@analog.com> wrote:
> 
> > 
> > Hi Jonathan,
> > 
> > Thank you for taking the time to answer.
> > 
> > These devices are mostly used in automotive/aerospace industries where
> > they
> > usually require a continuous stream of data even if an error occurs.
> > This
> > is why we cannot just "drop the record" :).
> > So, should we maybe think of a way of covering flags channel types?
> Propose an interface and we can certainly talk about it :)  Keep in mind
> that it needs to be lightweight for anything not making use of it and
> that I can see this absorbing a lot of namespace / id space (particularly
> in potential event codes) so keep that in mind as well.
> 
> I'd argue that those automotive / aerospace devices should certainly
> cope with missing data, but perhaps that's wishful thinking.
> 
> Anyhow, I'm not against this in principle but think it's a non trivial
> exercise so prepare yourself for a big job and quite a few rounds of
> interface descriptions!
> 
> Jonathan
> 
> > 
> > 
> > Regards,
> > -Stefan
> > 
> > On Du, 2019-03-24 at 18:00 +0000, Jonathan Cameron wrote:
> > > 
> > > 
> > > 
> > > 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/technica
> > > > l-do
> > > > cume
> > > > 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
> > > 
> > > 
> > > > 
> > > > 
> > > > 
> > > > -Stefa