All of lore.kernel.org
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-meson] Re: [PATCH v2 3/5] pinctrl: meson: enable GPIO IRQs
Date: Thu, 26 Nov 2015 16:27:22 +0000	[thread overview]
Message-ID: <20151126162722.1146b220@arm.com> (raw)
In-Reply-To: <CAOQ7t2ZUAefL2xuEzAwoQWi3tpu7N7y6krMv1UUzaBT4BYZv4A@mail.gmail.com>

On Tue, 24 Nov 2015 10:04:50 +0100
Carlo Caione <carlo@caione.org> wrote:

> On Tue, Nov 24, 2015 at 9:28 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On Mon, 23 Nov 2015 11:16:54 +0100
> > Carlo Caione <carlo@caione.org> wrote:
> >
> >> From: Carlo Caione <carlo@endlessm.com>
> >>
> >> On Meson8 and Meson8b SoCs there are 8 independent filtered GPIO
> >> interrupt modules that can be programmed to use any of the GPIOs in the
> >> chip as an interrupt source.
> >>
> >> For each GPIO IRQ we have:
> >>
> >> GPIOs --> [mux]--> [polarity]--> [filter]--> [edge select]--> GIC
> >>
> >> The eight GPIO interrupts respond to mask/unmask/clear/etc.. just like
> >> any other interrupt in the chip. The difference for the GPIO interrupts
> >> is that they can be filtered and conditioned.
> >>
> >> This patch adds support for the external GPIOs interrupts and enables
> >> them for Meson8 and Meson8b SoCs.
> >>
> >> Signed-off-by: Carlo Caione <carlo@endlessm.com>
> >> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
> >>
> >> ---
> >
> > [...]
> >
> >> +     for (i = 0; i < pc->num_gic_irqs; i++) {
> >> +             struct of_phandle_args oirq;
> >> +
> >> +             of_irq_parse_one(node, i, &oirq);
> >> +             irq_of_phandle_args_to_fwspec(&oirq, &pc->gic_irqs[i]);
> >> +
> >> +             pc->irq_map[i] = IRQ_FREE;
> >> +     }
> >
> > The whole thing feels weird. Why do you need to keep a set of fwspecs?
> 
> We only have 8 IRQs on the GIC side that we can use for the GPIOs. The
> set of fwspec is used to track these IRQs.
> At probe time we read from the DTS how many and which IRQs are
> reserved on the GIC for the GPIOs. Every time a GPIO IRQ is installed,
> we use one of these IRQ lines.

That doesn't answer my question. Having the raw IRQ numbers, why not.
Storing a whole fwspec (16 u32 + 1 int + 1 pointer) seems completely
overkill.

> > All you need is a range of interrupts that would be conveniently
> > represented by a bitmap (assuming your interrupts space is a mostly
> > contiguous range).
> 
> I could do that but it feels to me like we end up hiding from the DTS
> some information that naturally should be in there: a pinctrl device
> that is using 8 interrupt lines of its interrupt controller. IMO this
> is not a special case that requires some special treatment.

Well, it is also arguable that these interrupts are not the pinctrl's,
but those of the device that actually uses them (or we'd be describing
interrupts in all interrupt controller bindings, which doesn't make any
sense).

See for example the TI crossbar, which has similar functionalities. I'm
not going to take a hard line here, but the argument you have so far
doesn't seem to hold much water for me. Or there is something obvious
that I have missed, which is entirely possible.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
To: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Cc: "robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
	<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	Linus Walleij
	<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Beniamino Galvani
	<b.galvani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-arm-kernel
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	linux-meson-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
	Daniel Drake <drake-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>,
	Jerry Cao <jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>,
	Victor Wan <victor.wan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>,
	Carlo Caione <carlo-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>
Subject: Re: [linux-meson] Re: [PATCH v2 3/5] pinctrl: meson: enable GPIO IRQs
Date: Thu, 26 Nov 2015 16:27:22 +0000	[thread overview]
Message-ID: <20151126162722.1146b220@arm.com> (raw)
In-Reply-To: <CAOQ7t2ZUAefL2xuEzAwoQWi3tpu7N7y6krMv1UUzaBT4BYZv4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Tue, 24 Nov 2015 10:04:50 +0100
Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org> wrote:

> On Tue, Nov 24, 2015 at 9:28 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Mon, 23 Nov 2015 11:16:54 +0100
> > Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org> wrote:
> >
> >> From: Carlo Caione <carlo-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>
> >>
> >> On Meson8 and Meson8b SoCs there are 8 independent filtered GPIO
> >> interrupt modules that can be programmed to use any of the GPIOs in the
> >> chip as an interrupt source.
> >>
> >> For each GPIO IRQ we have:
> >>
> >> GPIOs --> [mux]--> [polarity]--> [filter]--> [edge select]--> GIC
> >>
> >> The eight GPIO interrupts respond to mask/unmask/clear/etc.. just like
> >> any other interrupt in the chip. The difference for the GPIO interrupts
> >> is that they can be filtered and conditioned.
> >>
> >> This patch adds support for the external GPIOs interrupts and enables
> >> them for Meson8 and Meson8b SoCs.
> >>
> >> Signed-off-by: Carlo Caione <carlo-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>
> >> Signed-off-by: Beniamino Galvani <b.galvani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>
> >> ---
> >
> > [...]
> >
> >> +     for (i = 0; i < pc->num_gic_irqs; i++) {
> >> +             struct of_phandle_args oirq;
> >> +
> >> +             of_irq_parse_one(node, i, &oirq);
> >> +             irq_of_phandle_args_to_fwspec(&oirq, &pc->gic_irqs[i]);
> >> +
> >> +             pc->irq_map[i] = IRQ_FREE;
> >> +     }
> >
> > The whole thing feels weird. Why do you need to keep a set of fwspecs?
> 
> We only have 8 IRQs on the GIC side that we can use for the GPIOs. The
> set of fwspec is used to track these IRQs.
> At probe time we read from the DTS how many and which IRQs are
> reserved on the GIC for the GPIOs. Every time a GPIO IRQ is installed,
> we use one of these IRQ lines.

That doesn't answer my question. Having the raw IRQ numbers, why not.
Storing a whole fwspec (16 u32 + 1 int + 1 pointer) seems completely
overkill.

> > All you need is a range of interrupts that would be conveniently
> > represented by a bitmap (assuming your interrupts space is a mostly
> > contiguous range).
> 
> I could do that but it feels to me like we end up hiding from the DTS
> some information that naturally should be in there: a pinctrl device
> that is using 8 interrupt lines of its interrupt controller. IMO this
> is not a special case that requires some special treatment.

Well, it is also arguable that these interrupts are not the pinctrl's,
but those of the device that actually uses them (or we'd be describing
interrupts in all interrupt controller bindings, which doesn't make any
sense).

See for example the TI crossbar, which has similar functionalities. I'm
not going to take a hard line here, but the argument you have so far
doesn't seem to hold much water for me. Or there is something obvious
that I have missed, which is entirely possible.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-11-26 16:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 10:16 [PATCH v2 0/5] pinctrl: meson: enable support for external GPIO interrupts Carlo Caione
2015-11-23 10:16 ` Carlo Caione
2015-11-23 10:16 ` [PATCH v2 1/5] of/irq: export of_irq_find_parent again Carlo Caione
2015-11-23 10:16   ` Carlo Caione
2015-11-30 13:47   ` Linus Walleij
2015-11-30 13:47     ` Linus Walleij
2015-11-23 10:16 ` [PATCH v2 2/5] irqdomain: introduce irq_of_phandle_args_to_fwspec Carlo Caione
2015-11-23 10:16   ` Carlo Caione
2015-11-26 17:25   ` Marc Zyngier
2015-11-26 17:25     ` Marc Zyngier
2015-11-23 10:16 ` [PATCH v2 3/5] pinctrl: meson: enable GPIO IRQs Carlo Caione
2015-11-23 10:16   ` Carlo Caione
2015-11-24  8:28   ` Marc Zyngier
2015-11-24  8:28     ` Marc Zyngier
2015-11-24  9:04     ` [linux-meson] " Carlo Caione
2015-11-24  9:04       ` Carlo Caione
2015-11-26 16:09       ` Carlo Caione
2015-11-26 16:09         ` Carlo Caione
2015-11-26 16:27       ` Marc Zyngier [this message]
2015-11-26 16:27         ` Marc Zyngier
2015-11-26 17:56         ` Carlo Caione
2015-11-26 17:56           ` Carlo Caione
2015-11-23 10:16 ` [PATCH v2 4/5] pinctrl: dt-binding: Extend meson documentation with GPIO IRQs support Carlo Caione
2015-11-23 10:16   ` Carlo Caione
2015-11-23 23:47   ` Rob Herring
2015-11-23 23:47     ` Rob Herring
2015-12-01 16:02     ` [linux-meson] " Carlo Caione
2015-12-01 16:02       ` Carlo Caione
2015-11-23 10:16 ` [PATCH v2 5/5] ARM: meson: DTS: Enable GPIO IRQs Carlo Caione
2015-11-23 10:16   ` Carlo Caione
2015-11-30 13:53 ` [PATCH v2 0/5] pinctrl: meson: enable support for external GPIO interrupts Linus Walleij
2015-11-30 13:53   ` Linus Walleij

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=20151126162722.1146b220@arm.com \
    --to=marc.zyngier@arm.com \
    --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.