From: adharmap@codeaurora.org (Abhijeet Dharmapurikar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts
Date: Sun, 25 Sep 2011 18:31:41 -0700 [thread overview]
Message-ID: <4E7FD5FD.5070103@codeaurora.org> (raw)
In-Reply-To: <4E770B3E.9040401@arm.com>
On 09/19/2011 02:28 AM, Marc Zyngier wrote:
> On 19/09/11 00:20, Abhijeet Dharmapurikar wrote:
>> On 09/15/2011 09:52 AM, Marc Zyngier 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).
Yes, you are exactly right, Qualcomm's GIC has configurable PPIs. The
default configuration for PPI's is level triggered, but we change the
timer PPI to edge trigger. Without this we wont even boot (no timer
interrupts). We do this trigger type setting in board specific code.
Although I agree with your concern, I would still request to provide a
facility to set the trigger flags. All the PPI's request will have that
argument set to zero, except for msm timer (and few other msm
interrupts). Additionally we can add that concern as a comment in
request_percpu_irq so the user of request_percpu_irq is aware of it.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2011-09-26 1:31 UTC|newest]
Thread overview: 19+ 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 ` [RFC PATCH 1/3] genirq: add support for per-cpu dev_id interrupts Marc Zyngier
2011-09-15 21:36 ` Michał Mirosław
2011-09-16 8:20 ` Marc Zyngier
2011-09-16 9:37 ` Thomas Gleixner
2011-09-15 22:49 ` Thomas Gleixner
2011-09-15 23:29 ` Russell King - ARM Linux
2011-09-15 23:41 ` Thomas Gleixner
2011-09-16 9:37 ` Marc Zyngier
2011-09-16 9:41 ` Thomas Gleixner
2011-09-18 23:20 ` Abhijeet Dharmapurikar
2011-09-19 9:28 ` Marc Zyngier
2011-09-19 15:00 ` Marc Zyngier
2011-09-19 15:05 ` Russell King - ARM Linux
2011-09-19 15:24 ` Marc Zyngier
2011-09-26 1:31 ` Abhijeet Dharmapurikar [this message]
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 ` [RFC PATCH 3/3] ARM: gic, local timers: use the request_percpu_irq() interface 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=4E7FD5FD.5070103@codeaurora.org \
--to=adharmap@codeaurora.org \
--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 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).