From: Julien Grall <julien.grall@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Keir Fraser <keir@xen.org>,
Ian Campbell <Ian.Campbell@citrix.com>,
patches@linaro.org, tim@xen.org, stefano.stabellini@citrix.com,
Jan Beulich <JBeulich@suse.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-4.5 7/8] xen/irq: Handle multiple action per IRQ
Date: Tue, 18 Mar 2014 14:54:00 +0000 [thread overview]
Message-ID: <53285E08.1040508@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1403181402030.30819@kaball.uk.xensource.com>
Hi Stefano,
On 03/18/2014 02:06 PM, Stefano Stabellini wrote:
>> On 03/18/2014 09:33 AM, Ian Campbell wrote:
>>> On Mon, 2014-03-17 at 21:05 +0000, Julien Grall wrote:
>>>> For instance for the SMMU on midway, the device tree bindings is:
>>>>
>>>> smmu_sata: smmu@9,20180000 {
>>>> compatible = "arm,mmu-400";
>>>> reg = <0x9 0x20180000 0x10000>;
>>>> mmu-masters = <&sata 0 1 2 3 4 5 6 7 8 9>;
>>>> #global-interrupts = <1>;
>>>> interrupts = <0 114 4 0 114 4>;
>>>> calxeda,smmu-secure-config-access;
>>>> arm,smmu-isolate-devices;
>>>> };
>>>>
>>>> As you can see the same interrupts is used twice:
>>>
>>> Is that actually valid in device tree? Or is this a quirk of the midway
>>> DT?
>>
>> Yes it's valid. The interrupts property for the SMMU is described as:
>>
>> "Interrupt list, with the first #global-irqs entries corresponding to
>> the global interrupts and any following entries corresponding to context
>> interrupts, specified in order of their indexing by the SMMU.
>>
>> For SMMUv2 implementations, there must be exactly one interrupt per
>> context bank. In the case of a single, combined interrupt, it must be
>> listed multiple times."
>>
>> On midway there is only one IRQ with is used for both context interrupt
>> and global interrupt. As it's the only platform on Linux with SMMU
>> support in the device tree, we don't know if every platform will have
>> the same behavior.
>
> I understand that the SMMU might reuse the same IRQ for multiple
> purposes. I would still handle the scenario entirely within the SMMU
> driver. Can't we register a single handler for each of the IRQ listed
> under the SMMU node and then figure out what was the notification for in
> the handler?
>
We will have to check in the SMMU drivers, if the IRQ was already
registered or not (because we don't know in advance if the IRQ is
re-used). If not, Xen will register it with a new handler.
The code to register the IRQ handler will looks like:
int num_irqs = dt_number_of_irq(smmu->node);
dt_irqs irqs[*];
dt_irq *irq;
for ( i = 0; i < num_irqs; i++ )
{
irq = dt_device_get_irq(smmu->node, i);
foreach ( a in irqs )
if ( irq == a )
continue;
request_dt_irq();
irqs <= irq;
}
I understand the point that people can badly use multiple action in the
future, but is it a good reason to make the code more difficult to
understand?
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-03-18 14:54 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 16:43 [PATCH for-4.5 0/8] Interrupt management reworking Julien Grall
2014-01-24 16:43 ` [PATCH for-4.5 1/8] xen/arm: irq: move gic {, un}lock in gic_set_irq_properties Julien Grall
2014-02-19 11:23 ` Ian Campbell
2014-02-19 13:38 ` Julien Grall
2014-01-24 16:43 ` [PATCH for-4.5 2/8] xen/arm: setup_dt_irq: don't enable the IRQ if the creation has failed Julien Grall
2014-02-19 11:24 ` Ian Campbell
2014-03-12 14:48 ` Ian Campbell
2014-01-24 16:43 ` [PATCH for-4.5 3/8] xen/arm: IRQ: Protect IRQ to be shared between domains and XEN Julien Grall
2014-02-19 11:35 ` Ian Campbell
2014-02-19 13:59 ` Julien Grall
2014-01-24 16:43 ` [PATCH for-4.5 4/8] xen/arm: irq: Don't need to have a specific function to route IRQ to Xen Julien Grall
2014-02-19 11:45 ` Ian Campbell
2014-02-19 14:16 ` Julien Grall
2014-01-24 16:43 ` [PATCH for-4.5 5/8] xen/arm: IRQ: rename release_irq in release_dt_irq Julien Grall
2014-02-19 11:47 ` Ian Campbell
2014-02-19 14:23 ` Julien Grall
2014-01-24 16:43 ` [PATCH for-4.5 6/8] xen/arm: IRQ: Add lock contrainst for gic_irq_{startup, shutdown} Julien Grall
2014-02-19 11:51 ` Ian Campbell
2014-02-19 14:35 ` Julien Grall
2014-02-19 14:38 ` Ian Campbell
2014-02-19 14:51 ` Julien Grall
2014-02-19 15:07 ` Jan Beulich
2014-02-19 17:26 ` Julien Grall
2014-02-20 20:48 ` Julien Grall
2014-02-21 8:55 ` Jan Beulich
2014-02-21 13:19 ` Julien Grall
2014-01-24 16:43 ` [PATCH for-4.5 7/8] xen/irq: Handle multiple action per IRQ Julien Grall
2014-02-19 11:55 ` Ian Campbell
2014-02-19 14:41 ` Julien Grall
2014-02-20 21:29 ` Julien Grall
2014-02-24 14:08 ` Julien Grall
2014-02-24 14:12 ` Ian Campbell
2014-02-24 14:32 ` Jan Beulich
2014-02-24 14:48 ` Julien Grall
2014-03-11 15:16 ` Julien Grall
2014-03-11 16:08 ` Jan Beulich
2014-03-17 19:06 ` Stefano Stabellini
2014-03-17 21:05 ` Julien Grall
2014-03-18 9:33 ` Ian Campbell
2014-03-18 12:26 ` Julien Grall
2014-03-18 14:06 ` Stefano Stabellini
2014-03-18 14:54 ` Julien Grall [this message]
2014-03-18 15:01 ` Stefano Stabellini
2014-03-18 15:21 ` Julien Grall
2014-03-18 15:39 ` Stefano Stabellini
2014-03-18 15:55 ` Julien Grall
2014-03-18 15:02 ` Ian Campbell
2014-03-18 15:08 ` Julien Grall
2014-03-18 15:10 ` Ian Campbell
2014-03-18 15:12 ` Julien Grall
2014-03-18 15:26 ` Ian Campbell
2014-03-19 17:18 ` Julien Grall
2014-03-21 14:06 ` Ian Campbell
2014-03-31 15:45 ` Julien Grall
2014-03-31 15:53 ` Ian Campbell
2014-03-31 16:02 ` Julien Grall
2014-04-01 12:29 ` Ian Campbell
2014-04-01 13:13 ` Julien Grall
2014-04-01 13:23 ` Ian Campbell
2014-04-01 13:52 ` Julien Grall
2014-04-01 14:31 ` Ian Campbell
2014-04-02 14:01 ` Julien Grall
2014-01-24 16:43 ` [PATCH for-4.5 8/8] xen/serial: remove serial_dt_irq Julien Grall
2014-02-19 11:55 ` Ian Campbell
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=53285E08.1040508@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=patches@linaro.org \
--cc=stefano.stabellini@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.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.