IIO interrupt mask access

IIO interrupt mask access

[Hegbeli, Ciprian]

Hi,

I'm currently writing a driver for the ADE9078 (High Performance, Polyphase Energy Metering IC) which has two interrupts with over 30 configurations modes in two 32 bit registers. Some of these flags can also be active at the same time within the same register for the same interrupt. While handling the interrupts is fairly straight forward, the challenge is to dynamical configure them within the IIO framework.
I want to offer the user the possibility to enable/disable these interrupts from within the IIO framework without having to create custom attributes specifically for interrupt configuration. Is there a recommended method to do this?

Regards, 
Ciprian Hegbeli

Re: IIO interrupt mask access

[Jonathan Cameron]

On Mon, 8 Nov 2021 14:29:10 +0000
"Hegbeli, Ciprian" <Ciprian.Hegbeli@analog.com> wrote:

>  for the ADE9078 (High Performance, Polyphase Energy Metering IC)
> which has two interrupts with over 30 configurations modes in two 32
> bit registers. Some of these flags can also be active at the same
> time within the same register for the same interrupt. While handling
> the interrupts is fairly straight forward, the challenge is to
> dynamical configure them within the IIO framework.

The answer to this is very dependent on what those interrupts mean.

I've taken a very quick look at STATUS0 and STATUS1 definitions to
see what we have.

Some of them look like they will map to triggers or possibly internal
data capture events that we don't expose to userspace as they reflect
periodic data updates (e.g. PWRRDY, DREADY)

Others look like they would be just about internal management of data
flow, eg. COH_WFBB_FULL.  You 'might' be able to map the start of
a waveform capture to the trigger interface. A little bit tricky to tell
without reading a lot more of the datasheet than I have time for today.
PAGE_FULL is something you'd probably not expose to userspace, but
handle as a signal to retrieve data from the device and push it to
a buffer or similar.

Others are what we'd map to the IIO events interface, 
MISMTC, REVRPA, RXIC etc Probably the timeout ones as well, though they
need some thought.

CF1-4 are something related to calibration frequency.  I'm not sure
if you would expose these as anything at all from this register.

ERRORX tend to be things you'd leave on and wire up to some logging or similar,
probably rate limited.  CRC stuff is driver internal, userspace doesn't care.

RSTDONE is part of startup sequence, don't expose that to userspace.

So it is very much case by case.   If you want more detailed answers
you should write a short description of the individual interrupt source
and how it is used in data capture etc.

Hope that helps a little.

Jonathan

RE: IIO interrupt mask access

[Hegbeli, Ciprian]

Thank you Jonathan, it helped.

I was not aware of the IIO event interface, those(ZXI*, ZXV* etc.) were the ones I was worried about.

Regards,
Ciprian 

-----Original Message-----
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com> 
Sent: Monday, November 8, 2021 5:27 PM
To: Hegbeli, Ciprian <Ciprian.Hegbeli@analog.com>
Cc: linux-iio@vger.kernel.org; jic23@kernel.org
Subject: Re: IIO interrupt mask access

[External]

On Mon, 8 Nov 2021 14:29:10 +0000
"Hegbeli, Ciprian" <Ciprian.Hegbeli@analog.com> wrote:

>  for the ADE9078 (High Performance, Polyphase Energy Metering IC) 
> which has two interrupts with over 30 configurations modes in two 32 
> bit registers. Some of these flags can also be active at the same time 
> within the same register for the same interrupt. While handling the 
> interrupts is fairly straight forward, the challenge is to dynamical 
> configure them within the IIO framework.

The answer to this is very dependent on what those interrupts mean.

I've taken a very quick look at STATUS0 and STATUS1 definitions to see what we have.

Some of them look like they will map to triggers or possibly internal data capture events that we don't expose to userspace as they reflect periodic data updates (e.g. PWRRDY, DREADY)

Others look like they would be just about internal management of data flow, eg. COH_WFBB_FULL.  You 'might' be able to map the start of a waveform capture to the trigger interface. A little bit tricky to tell without reading a lot more of the datasheet than I have time for today.
PAGE_FULL is something you'd probably not expose to userspace, but handle as a signal to retrieve data from the device and push it to a buffer or similar.

Others are what we'd map to the IIO events interface, MISMTC, REVRPA, RXIC etc Probably the timeout ones as well, though they need some thought.

CF1-4 are something related to calibration frequency.  I'm not sure if you would expose these as anything at all from this register.

ERRORX tend to be things you'd leave on and wire up to some logging or similar, probably rate limited.  CRC stuff is driver internal, userspace doesn't care.

RSTDONE is part of startup sequence, don't expose that to userspace.

So it is very much case by case.   If you want more detailed answers
you should write a short description of the individual interrupt source and how it is used in data capture etc.

Hope that helps a little.

Jonathan