All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Bastien Nocera <hadess@hadess.net>,
	linux-iio <linux-iio@vger.kernel.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Subject: Re: [PATCH] iio: event_monitor: Enable events before monitoring
Date: Sat, 6 Mar 2021 15:39:29 +0000	[thread overview]
Message-ID: <20210306153929.51b053bc@archlinux> (raw)
In-Reply-To: <CACRpkdZcyWPUtJbjYMS=mWZW48ZkKe=arAydJbXK6E8jyQT=hA@mail.gmail.com>

On Thu, 4 Mar 2021 21:48:25 +0100
Linus Walleij <linus.walleij@linaro.org> wrote:

> On Thu, Mar 4, 2021 at 5:00 PM Bastien Nocera <hadess@hadess.net> wrote:
> 
> > If I'm not mistaken, "-a" does that for the iio_generic_buffer tool.  
> 
> Yeah I implemented that, and I thought about doing the same here
> but ... the name of the tool sort of announce that one want to
> listen to all events so I thought it should just default-enable
> all of them in this case.
> 
> > Maybe moving enable_disable_all_channels() to a common location and
> > using that would cut down on the duplicated code?  
> 
> The event enablement is slightly different, the generic buffer
> turns on various channels, which is conceptually different
> from various events, but let's see what Jonathan says.
> 
> We are sharing most of the code already in the iio-utils.c
> but I can try to break out more if it doesn't get to abstract.

Sadly this doesn't work for many devices.
It is a common thing for hardware to only support a much smaller
set of event monitoring registers / threshold detectors than the
number of channels.  In many cases we handle that by working on
a fifo basis.  So what this will do is enable a bunch of events
which will then be replaced by later events - end result some
random event will be enabled (or maybe 2 of them across N channels)

Not intuitive at all :(

I'm fine with it being controlled by a parameter though if
that works for you.  Docs should explain it doesn't always
result in all events being enabled however if the hardware
is not capable of doing that.

Jonathan


> 
> Thanks Bastien,
> Linus Walleij


  reply	other threads:[~2021-03-06 15:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-04 15:42 [PATCH] iio: event_monitor: Enable events before monitoring Linus Walleij
2021-03-04 15:59 ` Bastien Nocera
2021-03-04 20:48   ` Linus Walleij
2021-03-06 15:39     ` Jonathan Cameron [this message]
2021-03-06 21:29       ` Linus Walleij
2021-03-07 11:54         ` Jonathan Cameron

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=20210306153929.51b053bc@archlinux \
    --to=jic23@kernel.org \
    --cc=hadess@hadess.net \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.