Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Hegbeli, Ciprian" <Ciprian.Hegbeli@analog.com>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"jic23@kernel.org" <jic23@kernel.org>
Subject: Re: IIO interrupt mask access
Date: Mon, 8 Nov 2021 15:26:46 +0000	[thread overview]
Message-ID: <20211108152646.00004ecb@Huawei.com> (raw)
In-Reply-To: <BYAPR03MB4647767659DA0E143F9C919A97919@BYAPR03MB4647.namprd03.prod.outlook.com>

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

  reply	other threads:[~2021-11-08 15:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-08 14:29 IIO interrupt mask access Hegbeli, Ciprian
2021-11-08 15:26 ` Jonathan Cameron [this message]
2021-11-09  9:32   ` Hegbeli, Ciprian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211108152646.00004ecb@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Ciprian.Hegbeli@analog.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox