All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Kaplan <michael_kaplan@inode.at>
To: linux-gpio@vger.kernel.org
Subject: gpio-mcp23s08 irq issue
Date: Sun, 22 Mar 2015 00:04:34 +0100	[thread overview]
Message-ID: <1426979074.14991.7.camel@netghost.ehp.lan> (raw)

Hi!

I am using an MCP23017 on a raspberry pi as GPIO expander.
I am using  this to switch relais on the output side, and for reading
the states of some switches on the input side.

I created a device-tree overlay from the example in
Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt which is
working fine for reading/writing via the sysfs interface.

The problem occurs when I try to enable the interrupt via the edge file.
As soon as I change the state of one of the irq-enabled gpio pins, I get
following in the syslog:

[  214.975538] irq 398: nobody cared (try booting with the "irqpoll"
option)
< many lines of stack trace>
[  215.739630] Disabling IRQ #398

I realize that such an 'IRQ #: nobody cared' message occurs when there
are 100.000 unhandled interrupts.

>From /proc/interrupts I can see that one single interrupt out of 100.001
was handled by the mcp23s08 driver:

398:     100001  pinctrl-bcm2835   4  1-0020
457:          1  gpio-mcp23xxx   9  gpiolib

I could confirm that by adding a printk() into the mcp23s08_irq()
function.

Now when I change my device tree overlay to use IRQ_TYPE_LEVEL_FALLING
instead of IRQ_TYPE_LEVEL_LOW, and additionally use IRQF_TRIGGER_FALLING
instead of IRQF_TRIGGER_LOW in the devm_request_threaded_irq() call
within the function mcp23s08_irq_setup(), it works as expected - one
interrupt for each state change on the gpio pin.

I am using a self built 3.18.9+ kernel from the raspberry pi kernel
repository because the gpio-mcp23s08 driver is not included in the
standard kernel images.

I am aware of some changes that happened to the driver in the kernel
repository since 3.18, but even the newest version is still using
IRQF_TRIGGER_LOW, so I guess it won't work on my side with a newer
driver version either.

So my questions are:

1.) Why exactly is level triggering used instead of edge triggering?

2.) Would it be reasonable to add two more options via the device-tree
interface to make it possible to define IRQ_TYPE_LEVEL_FALLING and
IRQ_TYPE_LEVEL_RISING in an overlay?

3.) Are there any suggestions what I could do to avoid the problem
without patching the driver?


Any help would be appreciated ;-)

regards
Michael Kaplan



                 reply	other threads:[~2015-03-21 23:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1426979074.14991.7.camel@netghost.ehp.lan \
    --to=michael_kaplan@inode.at \
    --cc=linux-gpio@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 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.