LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Phil Edworthy <phil.edworthy@renesas.com>
To: Marc Zyngier <marc.zyngier@arm.com>, Rob Herring <robh@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 2/2] irqchip: Add support for Renesas RZ/N1 GPIO interrupt multiplexer
Date: Tue, 6 Nov 2018 13:15:35 +0000	[thread overview]
Message-ID: <TY1PR01MB17696E2B10CA447CD3508ADAF5CB0@TY1PR01MB1769.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <TY1PR01MB1769D6F84F7BCD91C1018922F5CD0@TY1PR01MB1769.jpnprd01.prod.outlook.com>

Hi Marc,

On 31 October 2018 15:39, Phil Edworthy wrote
> On 31 October 2018 15:31, Marc Zyngier wrote:
> > On 31/10/18 15:09, Phil Edworthy wrote:
> > > On 31 October 2018 08:02, Marc Zyngier wote:
> > >> On Tue, 30 Oct 2018 10:44:38 +0000, Phil Edworthy wrote:
> > >>>
> > >>> On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks each
> > >>> configured to have 32 interrupt outputs, so we have a total of 96
> > >>> GPIO interrupts. All of these are passed to the GPIO IRQ Muxer,
> > >>> which selects
> > >>> 8 of the GPIO interrupts to pass onto the GIC. The interrupt
> > >>> signals aren't latched, so there is nothing to do in this driver
> > >>> when an interrupt is received, other than tell the corresponding GPIO
> block.
<snip>

> > There are two cases:
> > 1) there is 1:1 mapping between a used input and an output, leaving
> > some input unused
> > 2) there is an n:1 mapping between input and output, and all the input
> > can be used at any given time
> >
> > If what you have is (1), you need to implement an hierarchy.
> > If what you have is (2), you need to implement a chained controller.
> >
> > (1) requires you to revisit this driver, making it a lot more like
> > ti's irq-crossbar
> > (2) requires you to actually do some decoding in the chained handler
> >
> > I believe you're in configuration (1). Am I right?
> Right, it's a 1:1 mapping. The information about which input to be used needs
> to be specified in dt.
> I didn’t think I could implement a hierarchy that didn’t mask the interrupts,
> so I need to go back over that and look again...

Ok, I have changed the driver to implement a hierarchy, i.e.
call irq_domain_create_hierarchy() in probe,
call irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent()
in the irq_domain_ops.alloc function.

I've got a couple of issues that I hope you can provide some input on.

First is what to do with irqs that are input to this mux but not selected.
If I don't call irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent(),
it causes the driver for the hardware that generates these interrupts (in
this case, Synopsys dwapb_gpio) to throw an exception in
irq_set_chained_handler_and_data().
As a hack, I have simply used an unused output irq.

Second is specifying the output irqs. Currently, I specify them like this:
	interrupts =
		<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
		<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
		...
		<GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
However, I am only reading the property so I can pass the fwspec to
irq_domain_alloc_irqs_parent(). I am not using anything that ends up
in of_irq_parse_raw().

Rob H has previously said that I should use interrupt-map to describe the
relationship between the input and output irqs. Unfortunately, irq
hierarchy seems to be somewhat at odds with using interrupt-map.
Or at least, I can’t see how the two can be combined.

Your feedback on this is greatly appreciated!
Thanks
Phil

  reply	other threads:[~2018-11-06 13:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-30 10:44 [PATCH v2 0/2] " Phil Edworthy
2018-10-30 10:44 ` [PATCH v2 1/2] dt-bindings/interrupt-controller: rzn1: Add RZ/N1 gpio irq mux binding Phil Edworthy
2018-10-30 23:04   ` Rob Herring
2018-10-31 13:43     ` Phil Edworthy
2018-10-30 10:44 ` [PATCH v2 2/2] irqchip: Add support for Renesas RZ/N1 GPIO interrupt multiplexer Phil Edworthy
2018-10-31  8:02   ` Marc Zyngier
2018-10-31 15:09     ` Phil Edworthy
2018-10-31 15:30       ` Marc Zyngier
2018-10-31 15:38         ` Phil Edworthy
2018-11-06 13:15           ` Phil Edworthy [this message]
2018-11-08 15:37             ` Phil Edworthy

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=TY1PR01MB17696E2B10CA447CD3508ADAF5CB0@TY1PR01MB1769.jpnprd01.prod.outlook.com \
    --to=phil.edworthy@renesas.com \
    --cc=geert@linux-m68k.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=robh@kernel.org \
    --cc=tglx@linutronix.de \
    --subject='RE: [PATCH v2 2/2] irqchip: Add support for Renesas RZ/N1 GPIO interrupt multiplexer' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).