Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Lothar Rubusch <l.rubusch@gmail.com>
Cc: lars@metafoo.de, Michael.Hennerich@analog.com,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	eraretuya@gmail.com
Subject: Re: [PATCH v2 07/22] iio: accel: adxl345: initialize IRQ number
Date: Tue, 26 Nov 2024 17:49:32 +0000	[thread overview]
Message-ID: <20241126174932.7987df3e@jic23-huawei> (raw)
In-Reply-To: <CAFXKEHbLg9COcKkv2AX-TfdW+-RO7CpJjMLQ3YJtcNbnXcs9xA@mail.gmail.com>

On Tue, 26 Nov 2024 17:16:07 +0100
Lothar Rubusch <l.rubusch@gmail.com> wrote:

> On Sun, Nov 24, 2024 at 7:14 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Sun, 17 Nov 2024 18:26:36 +0000
> > Lothar Rubusch <l.rubusch@gmail.com> wrote:
> >  
> > > Add the possibility to claim an interrupt and init the state structure
> > > with interrupt number and interrupt line to use. The adxl345 can use
> > > two different interrupt lines, mainly to signal FIFO watermark events,
> > > single or double tap, activity, etc. Hence, having the interrupt line
> > > available is crucial to implement such features.  
> >
> > If there are two interrupt lines, you need to be more clever.
> > Imagine only one of them is wired. How do you know which one it is?
> >
> > The query needs to be done by name.  When there are multiple interrupts
> > the ones found in spi and i2c structures could be anything, so don't use
> > those.
> >
> > See fwnode_irq_get_by_name()  
> 
> One of my bigger question marks is this here: The sensor has two
> possible interrupt lines, INT1 or INT2, on which it will notify. But,
> only one is connected. Hence, the irq passed e.g. by SPI will
> automatically refer to the used one. Only this one is going to be
> configured as irq. Or, am I getting this wrong? Alternatively, no
> interrupt line is connected. This was the initial driver setup. In
> this case, it's generally BYPASS-mode for the FIFO and any further
> feature is not possible due to a lack of notification.
> 
> My questions now arise, when it comes to configure the IRQ line in the
> sensor registers. The sensor needs to be configured, that the used
> interrupt line for notifiction is INT1 or INT2. In the later patch of
> this series - "set interrupt line to INT1" - I init it with "INT1".
> But, this actually then can be configured. I can think of yet another
> /sysfs handle (could be dynamically changed at runtime, I'm not sure
> if this makes sense); by an additional devicetree binding (currently
> my preferred idea, I'd default to INT1, but let it configure to INT1
> or INT2 - or better default to bypass mode?), or is there an IIO way
> of configuring it to INT1/2, or a better way? I rather tend to DT. But
> this is still not part of this patch set.

> 
> Do I miss a point here and should still apply the
> fwnode_irq_get_by_name()? This looks a bit like the DT approach, isn't
> it?

Yes - this function does exactly what you need here (it is a very common
situation! Try grepping for INT2 and you should see examples)

To fill in the information you need:
1. Try getting INT1 by name. If succeeds use that and set config on basis INT1 is wired.
2. If not try getting INT2. If that succeeds then use INT2. 
3. If that fails no interrupts.

The binding should 'require' interrupt-names so that you always know
which one is which in the interrupt properties.

If the binding just had one interrupt before, then we add some text to say that
it is only valid if the provided interrupt is INT1.

Jonathan

  reply	other threads:[~2024-11-26 17:49 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-17 18:26 [PATCH v2 00/22] iio: accel: adxl345: add FIFO operating with IRQ triggered watermark events Lothar Rubusch
2024-11-17 18:26 ` [PATCH v2 01/22] iio: accel: adxl345: fix comment on probe Lothar Rubusch
2024-11-24 17:57   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 02/22] iio: accel: adxl345: rename variable data to st Lothar Rubusch
2024-11-17 18:26 ` [PATCH v2 03/22] iio: accel: adxl345: rename struct adxl34x_state Lothar Rubusch
2024-11-24 18:01   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 04/22] iio: accel: adxl345: rename to adxl34x_channels Lothar Rubusch
2024-11-24 18:02   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 05/22] iio: accel: adxl345: measure right-justified Lothar Rubusch
2024-11-24 18:07   ` Jonathan Cameron
2024-11-26 13:51     ` Lothar Rubusch
2024-11-26 17:44       ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 06/22] iio: accel: adxl345: add function to switch measuring Lothar Rubusch
2024-11-24 18:10   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 07/22] iio: accel: adxl345: initialize IRQ number Lothar Rubusch
2024-11-24 18:14   ` Jonathan Cameron
2024-11-26 16:16     ` Lothar Rubusch
2024-11-26 17:49       ` Jonathan Cameron [this message]
2024-11-17 18:26 ` [PATCH v2 08/22] iio: accel: adxl345: initialize FIFO delay value for SPI Lothar Rubusch
2024-11-24 18:16   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 09/22] iio: accel: adxl345: unexpose private defines Lothar Rubusch
2024-11-24 18:22   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 10/22] iio: accel: adxl345: set interrupt line to INT1 Lothar Rubusch
2024-11-24 18:23   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 11/22] iio: accel: adxl345: import adxl345 general data Lothar Rubusch
2024-11-24 18:31   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 12/22] iio: accel: adxl345: elaborate iio channel definition Lothar Rubusch
2024-11-24 18:34   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 13/22] iio: accel: adxl345: add trigger handler Lothar Rubusch
2024-11-24 18:46   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 14/22] iio: accel: adxl345: read FIFO entries Lothar Rubusch
2024-11-24 18:49   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 15/22] iio: accel: adxl345: reset the FIFO on error Lothar Rubusch
2024-11-24 18:54   ` Jonathan Cameron
2024-11-26 21:53     ` Lothar Rubusch
2024-11-17 18:26 ` [PATCH v2 16/22] iio: accel: adxl345: register trigger ops Lothar Rubusch
2024-11-24 18:56   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 17/22] iio: accel: adxl345: push FIFO data to iio Lothar Rubusch
2024-11-24 18:58   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 18/22] iio: accel: adxl345: start measure at buffer en/disable Lothar Rubusch
2024-11-24 19:00   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 19/22] iio: accel: adxl345: prepare FIFO watermark handling Lothar Rubusch
2024-11-24 19:05   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 20/22] iio: accel: adxl345: use FIFO with watermark IRQ Lothar Rubusch
2024-11-24 19:08   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 21/22] iio: accel: adxl345: sync FIFO reading with sensor Lothar Rubusch
2024-11-24 19:09   ` Jonathan Cameron
2024-11-17 18:26 ` [PATCH v2 22/22] iio: accel: adxl345: add debug printout Lothar Rubusch
2024-11-24 19:11   ` 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=20241126174932.7987df3e@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=eraretuya@gmail.com \
    --cc=l.rubusch@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@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