From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
Date: Mon, 19 Sep 2011 16:00:34 +0100 [thread overview]
Message-ID: <4E775912.3060502@arm.com> (raw)
In-Reply-To: <4E770B3E.9040401@arm.com>
On 19/09/11 10:28, Marc Zyngier wrote:
> On 19/09/11 00:20, Abhijeet Dharmapurikar wrote:
>> > + * @devname: An ascii name for the claiming device
>> > + * @dev_id: A percpu cookie passed back to the handler function
>> > + *
>> > + * This call allocates interrupt resources, but doesn't
>> > + * automatically enable the interrupt. It has to be done on each
>> > + * CPU using enable_percpu_irq().
>> > + *
>> > + * Dev_id must be globally unique. It is a per-cpu variable, and
>> > + * the handler gets called with the interrupted CPU's instance of
>> > + * that variable.
>> > + */
>> > +int request_percpu_irq(unsigned int irq, irq_handler_t handler,
>> > + const char *devname, void __percpu *dev_id)
>>
>> Can we add irqflags argument. I think it will be useful to pass flags,
>> at least the IRQF_TRIGGER_MASK since it ends up calling __setup_irq().
>> The chip could use a set_type callback for ppi's too.
>
> We're entering dangerous territory here. While this would work with the
> GIC (the interrupt type is at the distributor level), you could easily
> imagine an interrupt controller with the PPI configuration at the CPU
> interface level... In that case, calling set_type from __setup_irq()
> would end up doing the wrong thing, and I'd hate the API to give the
> idea it can do things it may not do in the end...
>
> Furthermore, do we actually have a GIC implementation where PPI
> configuration isn't read-only? I only know about the ARM implementation,
> and the Qualcomm may well be different (the spec says it's
> implementation defined).
Replying to myself after a quick investigation... Looks like the Qualcomm
implementation does exactly what is mentioned above:
arch/arm/mach-msm/platsmp.c:
void __cpuinit platform_secondary_init(unsigned int cpu)
{
/* Configure edge-triggered PPIs */
writel(GIC_PPI_EDGE_MASK, MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4);
[...]
The way I understand it, this "MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4"
is a banked register (otherwise we would not do it in platform_secondary_init(),
right?) So doing a set_type() from __setup_irq() would be just wrong. It really
needs to be done on a per-CPU basis.
Do you agree?
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
Date: Mon, 19 Sep 2011 16:00:34 +0100 [thread overview]
Message-ID: <4E775912.3060502@arm.com> (raw)
In-Reply-To: <4E770B3E.9040401@arm.com>
On 19/09/11 10:28, Marc Zyngier wrote:
> On 19/09/11 00:20, Abhijeet Dharmapurikar wrote:
>> > + * @devname: An ascii name for the claiming device
>> > + * @dev_id: A percpu cookie passed back to the handler function
>> > + *
>> > + * This call allocates interrupt resources, but doesn't
>> > + * automatically enable the interrupt. It has to be done on each
>> > + * CPU using enable_percpu_irq().
>> > + *
>> > + * Dev_id must be globally unique. It is a per-cpu variable, and
>> > + * the handler gets called with the interrupted CPU's instance of
>> > + * that variable.
>> > + */
>> > +int request_percpu_irq(unsigned int irq, irq_handler_t handler,
>> > + const char *devname, void __percpu *dev_id)
>>
>> Can we add irqflags argument. I think it will be useful to pass flags,
>> at least the IRQF_TRIGGER_MASK since it ends up calling __setup_irq().
>> The chip could use a set_type callback for ppi's too.
>
> We're entering dangerous territory here. While this would work with the
> GIC (the interrupt type is at the distributor level), you could easily
> imagine an interrupt controller with the PPI configuration at the CPU
> interface level... In that case, calling set_type from __setup_irq()
> would end up doing the wrong thing, and I'd hate the API to give the
> idea it can do things it may not do in the end...
>
> Furthermore, do we actually have a GIC implementation where PPI
> configuration isn't read-only? I only know about the ARM implementation,
> and the Qualcomm may well be different (the spec says it's
> implementation defined).
Replying to myself after a quick investigation... Looks like the Qualcomm
implementation does exactly what is mentioned above:
arch/arm/mach-msm/platsmp.c:
void __cpuinit platform_secondary_init(unsigned int cpu)
{
/* Configure edge-triggered PPIs */
writel(GIC_PPI_EDGE_MASK, MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4);
[...]
The way I understand it, this "MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4"
is a banked register (otherwise we would not do it in platform_secondary_init(),
right?) So doing a set_type() from __setup_irq() would be just wrong. It really
needs to be done on a per-CPU basis.
Do you agree?
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2011-09-19 15:00 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 16:52 [RFC PATCH 0/3] genirq: handling GIC per-cpu interrupts Marc Zyngier
2011-09-15 16:52 ` Marc Zyngier
2011-09-15 16:52 ` [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts Marc Zyngier
2011-09-15 16:52 ` Marc Zyngier
2011-09-15 21:36 ` Michał Mirosław
2011-09-15 21:36 ` Michał Mirosław
2011-09-16 8:20 ` Marc Zyngier
2011-09-16 8:20 ` Marc Zyngier
2011-09-16 9:37 ` Thomas Gleixner
2011-09-16 9:37 ` Thomas Gleixner
2011-09-15 22:49 ` Thomas Gleixner
2011-09-15 22:49 ` Thomas Gleixner
2011-09-15 23:29 ` Russell King - ARM Linux
2011-09-15 23:29 ` Russell King - ARM Linux
2011-09-15 23:41 ` Thomas Gleixner
2011-09-15 23:41 ` Thomas Gleixner
2011-09-16 9:37 ` Marc Zyngier
2011-09-16 9:37 ` Marc Zyngier
2011-09-16 9:41 ` Thomas Gleixner
2011-09-16 9:41 ` Thomas Gleixner
2011-09-18 23:20 ` Abhijeet Dharmapurikar
2011-09-18 23:20 ` Abhijeet Dharmapurikar
2011-09-19 9:28 ` Marc Zyngier
2011-09-19 9:28 ` Marc Zyngier
2011-09-19 15:00 ` Marc Zyngier [this message]
2011-09-19 15:00 ` Marc Zyngier
2011-09-19 15:05 ` Russell King - ARM Linux
2011-09-19 15:05 ` Russell King - ARM Linux
2011-09-19 15:24 ` Marc Zyngier
2011-09-19 15:24 ` Marc Zyngier
2011-09-26 1:31 ` Abhijeet Dharmapurikar
2011-09-26 1:31 ` Abhijeet Dharmapurikar
2011-09-26 1:58 ` Abhijeet Dharmapurikar
2011-09-26 1:58 ` Abhijeet Dharmapurikar
2011-09-15 16:52 ` [RFC PATCH 2/3] ARM: gic: consolidate PPI handling Marc Zyngier
2011-09-15 16:52 ` Marc Zyngier
2011-09-15 16:52 ` [RFC PATCH 3/3] ARM: gic, local timers: use the request_percpu_irq() interface Marc Zyngier
2011-09-15 16:52 ` Marc Zyngier
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=4E775912.3060502@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.