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@xxxxxxxxxx> Sent: Monday, November 8, 2021 5:27 PM To: Hegbeli, Ciprian <Ciprian.Hegbeli@xxxxxxxxxx> Cc: linux-iio@xxxxxxxxxxxxxxx; jic23@xxxxxxxxxx Subject: Re: IIO interrupt mask access [External] On Mon, 8 Nov 2021 14:29:10 +0000 "Hegbeli, Ciprian" <Ciprian.Hegbeli@xxxxxxxxxx> 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
