All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: "Grant Likely (grant.likely@secretlab.ca)"
	<grant.likely@secretlab.ca>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"Thomas Gleixner (tglx@linutronix.de)" <tglx@linutronix.de>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>
Subject: Re: How to represent active low ARM GIC interrupts, enabled by external inverter?
Date: Mon, 23 Jan 2012 17:48:27 -0600	[thread overview]
Message-ID: <4F1DF1CB.20707@gmail.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF178CB81BA2@HQMAIL01.nvidia.com>

On 01/23/2012 03:18 PM, Stephen Warren wrote:
> I'd like guidance on how to model one aspect of Tegra's interrupt
> structure.
> 
> Tegra has an interrupt input pin for use by a PMU chip.
> 
> The PMC HW module within Tegra can optionally invert this signal, but
> otherwise has no control over it; no interrupt status bits, no masking,
> etc.
> 
> The (potentially inverted) signal is then fed into the ARM GIC, which
> supports level high or rising edge interrupts only.
> 
> So my question is: How to model this.
> 
> I assume the best thing to do is have the PMC be an explicit irq_chip,
> and have its .set_type op configure the inversion based on whether
> its interrupt source requests low or high, and allow either level or
> edge.
> 
> However, the irq_chip for the PMC couldn't implement any mask or shutdown
> operation. Is it acceptable to simple provide dummy/no-op functions in
> that case? I see that kernel/irq/dummychip.c does exactly that, but I'm
> not sure what use-cases that file is supposed to cover.
> 
> That'd result in something like this for device tree:
> 
> / {
>     intc: interrupt-controller@50041000 {
>         compatible = "arm,cortex-a9-gic";
>         /* reg and other properties omitted for brevity throughout */
>         interrupt-controller;
>         /* 
>          * cell 0, 1: interrupt type/ID
>          * cell 2: Linux IRQ flags
>          */
>         #interrupt-cells = <3>;
>     };
>     interrupt-parent = <&intc>;
> 
>     pmc: interrupt-controller@7000e400 {
>         compatible = "nvidia,tegra20-pmc";
>         interrupt-controller;
>         /* 
>          * cell 0: interrupt ID (always 0; should we omit this field?)
>          * cell 1: 0=no invert, 1=invert
>          */
>         #interrupt-cells = <2>;
>         /*
>          * Always high. Level or edge of the PMU interrupt output must be
>          * configured here. Or, should it somehow be passed through from
>          * the PMU's client's interrupt specifier?
>          */
>         interrupts = <0 88 0x04>;
>     };
> 
>     i2c@7000c000 {
>         compatible = "nvidia,tegra20-i2c";
> 
>         pmu@xxx {
>             interrupt-parent = <&pmc>;
>             interrupts = <0 1>;
>         }
>     };
> };
> 
> Does that look reasonable?
> 
> Other alternatives:
> 
> 1) Don't hook the PMC driver and binding into the interrupt tree, but
> simply have a property that controls the inversion of the signal.
> The disadvantage is that the PMU's interrupt specifier would need to
> always specify active high even if it was really active low with inversion
> activated in the PMC.

I think i would go this route considering it's only a single interrupt
line and probably just a couple of lines of code to set a bit if a
property is present.

Rob

> 2) Modify the ARM GIC's driver to allow active low interrupts, and call
> some plugin code to request any required inversion. Most platforms
> wouldn't provide such a plugin, and hence would still disallow such
> requests. The disadvantage here is that it complicates the cross-SoC
> GIC driver with something that may only be useful for Tegra.
> 
> Thanks.
> 

WARNING: multiple messages have this Message-ID (diff)
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: How to represent active low ARM GIC interrupts, enabled by external inverter?
Date: Mon, 23 Jan 2012 17:48:27 -0600	[thread overview]
Message-ID: <4F1DF1CB.20707@gmail.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF178CB81BA2@HQMAIL01.nvidia.com>

On 01/23/2012 03:18 PM, Stephen Warren wrote:
> I'd like guidance on how to model one aspect of Tegra's interrupt
> structure.
> 
> Tegra has an interrupt input pin for use by a PMU chip.
> 
> The PMC HW module within Tegra can optionally invert this signal, but
> otherwise has no control over it; no interrupt status bits, no masking,
> etc.
> 
> The (potentially inverted) signal is then fed into the ARM GIC, which
> supports level high or rising edge interrupts only.
> 
> So my question is: How to model this.
> 
> I assume the best thing to do is have the PMC be an explicit irq_chip,
> and have its .set_type op configure the inversion based on whether
> its interrupt source requests low or high, and allow either level or
> edge.
> 
> However, the irq_chip for the PMC couldn't implement any mask or shutdown
> operation. Is it acceptable to simple provide dummy/no-op functions in
> that case? I see that kernel/irq/dummychip.c does exactly that, but I'm
> not sure what use-cases that file is supposed to cover.
> 
> That'd result in something like this for device tree:
> 
> / {
>     intc: interrupt-controller at 50041000 {
>         compatible = "arm,cortex-a9-gic";
>         /* reg and other properties omitted for brevity throughout */
>         interrupt-controller;
>         /* 
>          * cell 0, 1: interrupt type/ID
>          * cell 2: Linux IRQ flags
>          */
>         #interrupt-cells = <3>;
>     };
>     interrupt-parent = <&intc>;
> 
>     pmc: interrupt-controller at 7000e400 {
>         compatible = "nvidia,tegra20-pmc";
>         interrupt-controller;
>         /* 
>          * cell 0: interrupt ID (always 0; should we omit this field?)
>          * cell 1: 0=no invert, 1=invert
>          */
>         #interrupt-cells = <2>;
>         /*
>          * Always high. Level or edge of the PMU interrupt output must be
>          * configured here. Or, should it somehow be passed through from
>          * the PMU's client's interrupt specifier?
>          */
>         interrupts = <0 88 0x04>;
>     };
> 
>     i2c at 7000c000 {
>         compatible = "nvidia,tegra20-i2c";
> 
>         pmu at xxx {
>             interrupt-parent = <&pmc>;
>             interrupts = <0 1>;
>         }
>     };
> };
> 
> Does that look reasonable?
> 
> Other alternatives:
> 
> 1) Don't hook the PMC driver and binding into the interrupt tree, but
> simply have a property that controls the inversion of the signal.
> The disadvantage is that the PMU's interrupt specifier would need to
> always specify active high even if it was really active low with inversion
> activated in the PMC.

I think i would go this route considering it's only a single interrupt
line and probably just a couple of lines of code to set a bit if a
property is present.

Rob

> 2) Modify the ARM GIC's driver to allow active low interrupts, and call
> some plugin code to request any required inversion. Most platforms
> wouldn't provide such a plugin, and hence would still disallow such
> requests. The disadvantage here is that it complicates the cross-SoC
> GIC driver with something that may only be useful for Tegra.
> 
> Thanks.
> 

  parent reply	other threads:[~2012-01-23 23:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23 21:18 How to represent active low ARM GIC interrupts, enabled by external inverter? Stephen Warren
2012-01-23 21:18 ` Stephen Warren
     [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF178CB81BA2-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-01-23 22:33   ` Russell King - ARM Linux
2012-01-23 22:33     ` Russell King - ARM Linux
     [not found]     ` <20120123223315.GB1068-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2012-01-23 23:12       ` Rob Herring
2012-01-23 23:12         ` Rob Herring
     [not found]         ` <4F1DE962.6030906-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-01-23 23:24           ` Stephen Warren
2012-01-23 23:24             ` Stephen Warren
2012-01-23 23:19       ` Stephen Warren
2012-01-23 23:19         ` Stephen Warren
2012-01-23 23:48 ` Rob Herring [this message]
2012-01-23 23:48   ` Rob Herring
     [not found]   ` <4F1DF1CB.20707-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-01-25 17:34     ` Stephen Warren
2012-01-25 17:34       ` Stephen Warren
     [not found]       ` <74CDBE0F657A3D45AFBB94109FB122FF178CB8204C-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-01-25 19:30         ` Grant Likely
2012-01-25 19:30           ` Grant Likely

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=4F1DF1CB.20707@gmail.com \
    --to=robherring2@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rob.herring@calxeda.com \
    --cc=swarren@nvidia.com \
    --cc=tglx@linutronix.de \
    /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.