From: robert.jarzmik@free.fr (Robert Jarzmik)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: pxa: fix lubbock interrupts handling
Date: Fri, 28 Nov 2014 14:30:05 +0100 [thread overview]
Message-ID: <87r3wn1mhu.fsf@free.fr> (raw)
In-Reply-To: <alpine.DEB.2.11.1411272258010.3961@nanos> (Thomas Gleixner's message of "Thu, 27 Nov 2014 23:03:10 +0100 (CET)")
Thomas Gleixner <tglx@linutronix.de> writes:
> So what is the relationship between installing that chained handler
> and that gpio-pxa probe stuff?
The relation is in gpio-pxa probe, look at the extract of pxa_gpio_probe() :
pxa_gpio_probe()
irq = gpio_to_irq(0);
irq_set_chip_and_handler(irq, &pxa_muxed_gpio_chip,
handle_edge_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
irq_set_chained_handler(IRQ_GPIO0, pxa_gpio_demux_handler);
Now look at the extract from the former lubbock_init_irq() :
lubbock_init_irq()
irq = PXA_GPIO_TO_IRQ(0);
irq_set_chained_handler(irq, lubbock_irq_handler);
irq_set_irq_type(irq, IRQ_TYPE_EDGE_FALLING);
Given that gpio_to_irq(0) = PXA_GPIO_TO_IRQ(0), see how these 2 are fighting to
install the handler, and how the resulting installed handler depends on the
order of execution of pxa_gpio_to_irq() wrt lubbock_init_irq().
> And why is the GPIO0 interrupt handled from arch code rather than from
> a regular driver setup, which depends on the availablity of the GPIO
> driver?
Ah that's a good question. Maybe the answer is that there is no driver in this
case.
When I say "no driver", it's because this interrupt is a consequence of the
IO-Board (or motherboard) wiring topology.
I think I need to add a bit of context, so pardon my crude ascii-art style, and
see in the lubbock case, we have this wiring (list of IPs not exhaustive, and
gates to mask each XXX irq not added) :
IPs on Motherboard Gates on motherboard SoC
+-------------+ +-------+
| SMC Lan | --lan irq--- | Latch | -
+-------------+ | | \ +------PXA-----+
| | \ | |
+-------------+ | | |+----------+ |
| UDC Vbus | --vbus irq-- | Latch | -- NOR gate -- GPIO0 -- ||GPIO block| |
+-------------+ | | line |+----------+ |
| | / | |
+-------------+ | | / +--------------+
| SA1111 | --sa11x irq--| Latch | -
+-------------+ +-------+
The "gates on motherboard" is what lubbock.c is describing, ie. the
interconnection on the motherboard. I don't see the device/driver model fitting
to describe these gates, do you ?
Cheers.
--
Robert
WARNING: multiple messages have this Message-ID (diff)
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Mack <daniel@zonque.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: pxa: fix lubbock interrupts handling
Date: Fri, 28 Nov 2014 14:30:05 +0100 [thread overview]
Message-ID: <87r3wn1mhu.fsf@free.fr> (raw)
In-Reply-To: <alpine.DEB.2.11.1411272258010.3961@nanos> (Thomas Gleixner's message of "Thu, 27 Nov 2014 23:03:10 +0100 (CET)")
Thomas Gleixner <tglx@linutronix.de> writes:
> So what is the relationship between installing that chained handler
> and that gpio-pxa probe stuff?
The relation is in gpio-pxa probe, look at the extract of pxa_gpio_probe() :
pxa_gpio_probe()
irq = gpio_to_irq(0);
irq_set_chip_and_handler(irq, &pxa_muxed_gpio_chip,
handle_edge_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
irq_set_chained_handler(IRQ_GPIO0, pxa_gpio_demux_handler);
Now look at the extract from the former lubbock_init_irq() :
lubbock_init_irq()
irq = PXA_GPIO_TO_IRQ(0);
irq_set_chained_handler(irq, lubbock_irq_handler);
irq_set_irq_type(irq, IRQ_TYPE_EDGE_FALLING);
Given that gpio_to_irq(0) = PXA_GPIO_TO_IRQ(0), see how these 2 are fighting to
install the handler, and how the resulting installed handler depends on the
order of execution of pxa_gpio_to_irq() wrt lubbock_init_irq().
> And why is the GPIO0 interrupt handled from arch code rather than from
> a regular driver setup, which depends on the availablity of the GPIO
> driver?
Ah that's a good question. Maybe the answer is that there is no driver in this
case.
When I say "no driver", it's because this interrupt is a consequence of the
IO-Board (or motherboard) wiring topology.
I think I need to add a bit of context, so pardon my crude ascii-art style, and
see in the lubbock case, we have this wiring (list of IPs not exhaustive, and
gates to mask each XXX irq not added) :
IPs on Motherboard Gates on motherboard SoC
+-------------+ +-------+
| SMC Lan | --lan irq--- | Latch | -
+-------------+ | | \ +------PXA-----+
| | \ | |
+-------------+ | | |+----------+ |
| UDC Vbus | --vbus irq-- | Latch | -- NOR gate -- GPIO0 -- ||GPIO block| |
+-------------+ | | line |+----------+ |
| | / | |
+-------------+ | | / +--------------+
| SA1111 | --sa11x irq--| Latch | -
+-------------+ +-------+
The "gates on motherboard" is what lubbock.c is describing, ie. the
interconnection on the motherboard. I don't see the device/driver model fitting
to describe these gates, do you ?
Cheers.
--
Robert
next prev parent reply other threads:[~2014-11-28 13:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 18:42 [PATCH] ARM: pxa: fix lubbock interrupts handling Robert Jarzmik
2014-11-27 18:42 ` Robert Jarzmik
2014-11-27 21:26 ` Dmitry Eremin-Solenikov
2014-11-27 22:03 ` Thomas Gleixner
2014-11-27 22:03 ` Thomas Gleixner
2014-11-28 13:30 ` Robert Jarzmik [this message]
2014-11-28 13:30 ` Robert Jarzmik
2014-11-28 16:02 ` Haojian Zhuang
2014-11-28 16:02 ` Haojian Zhuang
2014-12-03 20:24 ` Robert Jarzmik
2014-12-03 20:24 ` Robert Jarzmik
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=87r3wn1mhu.fsf@free.fr \
--to=robert.jarzmik@free.fr \
--cc=linux-arm-kernel@lists.infradead.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.