From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
Mark Rutland <mark.rutland@arm.com>, <jason@lakedaemon.net>,
<Catalin.Marinas@arm.com>, <Will.Deacon@arm.com>,
<liviu.dudau@arm.com>, <Harish.Kasiviswanathan@amd.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <devicetree@vger.kernel.org>
Subject: Re: [V10 PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)
Date: Tue, 4 Nov 2014 08:20:46 -0600 [thread overview]
Message-ID: <5458E0BE.2090803@amd.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1411040903340.5308@nanos>
On 11/4/14 04:06, Thomas Gleixner wrote:
> On Mon, 3 Nov 2014, Suravee Suthikulanit wrote:
>> On 11/3/2014 4:51 PM, Thomas Gleixner wrote:
>>> On Mon, 3 Nov 2014, suravee.suthikulpanit@amd.com wrote:
>>>> + irq_domain_set_hwirq_and_chip(v2m->domain, virq, hwirq,
>>>> + &v2m_chip, v2m);
>>>> +
>>>> + irq_set_msi_desc(hwirq, desc);
>>>> + irq_set_irq_type(hwirq, IRQ_TYPE_EDGE_RISING);
>>>
>>> Sure both calls work perfectly fine as long as virq == hwirq, right?
>>
>> I was running into an issue when calling the irq_domain_alloc_irq_parent(), it
>> requires of_phandle_args pointer to be passed in. However, this does not work
>> for GICv2m since it does not have interrupt information in the device tree.
>> So, I decided at first to use direct (virq == hwirq) mapping, which simplifies
>> the code a bit, but might not be ideal solution, as you pointed out.
>
> It's not only far from ideal. It's not a solution at all. Simply
> because there is no guarantee for virq == hwirq.
>
>> An alternative would be to create a temporary struct of_phandle_args, and
>> populate it with the interrupt information for the requested MSI. Then pass it
>> to:
>> --> irq_domain_alloc_irq_parent
>> |--> gic_irq_domain_alloc
>> |--> gic_irq_domain_xlate
>> |--> gic_irq_domain_map
>>
>> However, this would still not be ideal if we want to support ACPI. Another
>
> Neither device tree nor ACPI has anything to do with MSI interrupts at
> runtime.
>
> All they do is to tell that there is a MSI controller and where the
> registers are and in the worst case fixups for a borked MSI_TYPER
> register.
>
> So either the TYPER reg or DT/ACPI gives you a fixed hwirq range which
> is reserved for MSI. And that's all you need, right?
>
Right, I get that part. Figuring out the fixed hwirq range for MSI is
not the point I am trying to make here.
> [...]
> All you need is to pick one hwirq out of the existing fixed range and
> associate it to a newly allocated virq. That's the only information
> the underlying gic domain has to know about, because it needs to
> translate from the hwirq to the virq in the low level entry handler
> gic_handle_irq().
And that's what I am trying to do here except that GIC is expecting that
information to be passed to it via irq_domain_alloc_irqs(..., args)
where args is struct of_phandle_args (e.g. in the kernel/irqdomain.c:
irq_create_of_mapping). This works fine when specifying interrupt from
DT, but that is not always the case.
Currently, I can just create a fake of_phandle_args just to pass the
hwirq information to GIC.
--> gicv2m_setup_msi_irq()
| struct of_phandle_args phan;
| phan.np = NULL;
| phan.args_count = 3;
| phan.args[0] = 0;
| phan.args[1] = hwirq - 32;
| phan.args[2] = IRQ_TYPE_EDGE_RISING;
|--> irq_domain_alloc_irqs(d, 1, NUMA_NO_NODE, &phan);
|--> gicv2m_domain_alloc(d, virq, nr_irqs, arg)
|--> irq_domain_alloc_irqs_parent(d, virq, nr_irqs, arg);
I am trying to figure out what would be a common data structure for this
purpose that would work for both Dt and non-DT case (e.g. GICv2m MSI).
Unless you think this is ok.
Thanks,
Suravee
WARNING: multiple messages have this Message-ID (diff)
From: Suravee.Suthikulpanit@amd.com (Suravee Suthikulpanit)
To: linux-arm-kernel@lists.infradead.org
Subject: [V10 PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)
Date: Tue, 4 Nov 2014 08:20:46 -0600 [thread overview]
Message-ID: <5458E0BE.2090803@amd.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1411040903340.5308@nanos>
On 11/4/14 04:06, Thomas Gleixner wrote:
> On Mon, 3 Nov 2014, Suravee Suthikulanit wrote:
>> On 11/3/2014 4:51 PM, Thomas Gleixner wrote:
>>> On Mon, 3 Nov 2014, suravee.suthikulpanit at amd.com wrote:
>>>> + irq_domain_set_hwirq_and_chip(v2m->domain, virq, hwirq,
>>>> + &v2m_chip, v2m);
>>>> +
>>>> + irq_set_msi_desc(hwirq, desc);
>>>> + irq_set_irq_type(hwirq, IRQ_TYPE_EDGE_RISING);
>>>
>>> Sure both calls work perfectly fine as long as virq == hwirq, right?
>>
>> I was running into an issue when calling the irq_domain_alloc_irq_parent(), it
>> requires of_phandle_args pointer to be passed in. However, this does not work
>> for GICv2m since it does not have interrupt information in the device tree.
>> So, I decided at first to use direct (virq == hwirq) mapping, which simplifies
>> the code a bit, but might not be ideal solution, as you pointed out.
>
> It's not only far from ideal. It's not a solution at all. Simply
> because there is no guarantee for virq == hwirq.
>
>> An alternative would be to create a temporary struct of_phandle_args, and
>> populate it with the interrupt information for the requested MSI. Then pass it
>> to:
>> --> irq_domain_alloc_irq_parent
>> |--> gic_irq_domain_alloc
>> |--> gic_irq_domain_xlate
>> |--> gic_irq_domain_map
>>
>> However, this would still not be ideal if we want to support ACPI. Another
>
> Neither device tree nor ACPI has anything to do with MSI interrupts at
> runtime.
>
> All they do is to tell that there is a MSI controller and where the
> registers are and in the worst case fixups for a borked MSI_TYPER
> register.
>
> So either the TYPER reg or DT/ACPI gives you a fixed hwirq range which
> is reserved for MSI. And that's all you need, right?
>
Right, I get that part. Figuring out the fixed hwirq range for MSI is
not the point I am trying to make here.
> [...]
> All you need is to pick one hwirq out of the existing fixed range and
> associate it to a newly allocated virq. That's the only information
> the underlying gic domain has to know about, because it needs to
> translate from the hwirq to the virq in the low level entry handler
> gic_handle_irq().
And that's what I am trying to do here except that GIC is expecting that
information to be passed to it via irq_domain_alloc_irqs(..., args)
where args is struct of_phandle_args (e.g. in the kernel/irqdomain.c:
irq_create_of_mapping). This works fine when specifying interrupt from
DT, but that is not always the case.
Currently, I can just create a fake of_phandle_args just to pass the
hwirq information to GIC.
--> gicv2m_setup_msi_irq()
| struct of_phandle_args phan;
| phan.np = NULL;
| phan.args_count = 3;
| phan.args[0] = 0;
| phan.args[1] = hwirq - 32;
| phan.args[2] = IRQ_TYPE_EDGE_RISING;
|--> irq_domain_alloc_irqs(d, 1, NUMA_NO_NODE, &phan);
|--> gicv2m_domain_alloc(d, virq, nr_irqs, arg)
|--> irq_domain_alloc_irqs_parent(d, virq, nr_irqs, arg);
I am trying to figure out what would be a common data structure for this
purpose that would work for both Dt and non-DT case (e.g. GICv2m MSI).
Unless you think this is ok.
Thanks,
Suravee
WARNING: multiple messages have this Message-ID (diff)
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
jason@lakedaemon.net, Catalin.Marinas@arm.com,
Will.Deacon@arm.com, liviu.dudau@arm.com,
Harish.Kasiviswanathan@amd.com,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [V10 PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)
Date: Tue, 4 Nov 2014 08:20:46 -0600 [thread overview]
Message-ID: <5458E0BE.2090803@amd.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1411040903340.5308@nanos>
On 11/4/14 04:06, Thomas Gleixner wrote:
> On Mon, 3 Nov 2014, Suravee Suthikulanit wrote:
>> On 11/3/2014 4:51 PM, Thomas Gleixner wrote:
>>> On Mon, 3 Nov 2014, suravee.suthikulpanit@amd.com wrote:
>>>> + irq_domain_set_hwirq_and_chip(v2m->domain, virq, hwirq,
>>>> + &v2m_chip, v2m);
>>>> +
>>>> + irq_set_msi_desc(hwirq, desc);
>>>> + irq_set_irq_type(hwirq, IRQ_TYPE_EDGE_RISING);
>>>
>>> Sure both calls work perfectly fine as long as virq == hwirq, right?
>>
>> I was running into an issue when calling the irq_domain_alloc_irq_parent(), it
>> requires of_phandle_args pointer to be passed in. However, this does not work
>> for GICv2m since it does not have interrupt information in the device tree.
>> So, I decided at first to use direct (virq == hwirq) mapping, which simplifies
>> the code a bit, but might not be ideal solution, as you pointed out.
>
> It's not only far from ideal. It's not a solution at all. Simply
> because there is no guarantee for virq == hwirq.
>
>> An alternative would be to create a temporary struct of_phandle_args, and
>> populate it with the interrupt information for the requested MSI. Then pass it
>> to:
>> --> irq_domain_alloc_irq_parent
>> |--> gic_irq_domain_alloc
>> |--> gic_irq_domain_xlate
>> |--> gic_irq_domain_map
>>
>> However, this would still not be ideal if we want to support ACPI. Another
>
> Neither device tree nor ACPI has anything to do with MSI interrupts at
> runtime.
>
> All they do is to tell that there is a MSI controller and where the
> registers are and in the worst case fixups for a borked MSI_TYPER
> register.
>
> So either the TYPER reg or DT/ACPI gives you a fixed hwirq range which
> is reserved for MSI. And that's all you need, right?
>
Right, I get that part. Figuring out the fixed hwirq range for MSI is
not the point I am trying to make here.
> [...]
> All you need is to pick one hwirq out of the existing fixed range and
> associate it to a newly allocated virq. That's the only information
> the underlying gic domain has to know about, because it needs to
> translate from the hwirq to the virq in the low level entry handler
> gic_handle_irq().
And that's what I am trying to do here except that GIC is expecting that
information to be passed to it via irq_domain_alloc_irqs(..., args)
where args is struct of_phandle_args (e.g. in the kernel/irqdomain.c:
irq_create_of_mapping). This works fine when specifying interrupt from
DT, but that is not always the case.
Currently, I can just create a fake of_phandle_args just to pass the
hwirq information to GIC.
--> gicv2m_setup_msi_irq()
| struct of_phandle_args phan;
| phan.np = NULL;
| phan.args_count = 3;
| phan.args[0] = 0;
| phan.args[1] = hwirq - 32;
| phan.args[2] = IRQ_TYPE_EDGE_RISING;
|--> irq_domain_alloc_irqs(d, 1, NUMA_NO_NODE, &phan);
|--> gicv2m_domain_alloc(d, virq, nr_irqs, arg)
|--> irq_domain_alloc_irqs_parent(d, virq, nr_irqs, arg);
I am trying to figure out what would be a common data structure for this
purpose that would work for both Dt and non-DT case (e.g. GICv2m MSI).
Unless you think this is ok.
Thanks,
Suravee
next prev parent reply other threads:[~2014-11-04 14:21 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-03 22:16 [V10 PATCH 0/2] irqchip: gic: Introduce ARM GICv2m MSI(-X) support suravee.suthikulpanit
2014-11-03 22:16 ` suravee.suthikulpanit
2014-11-03 22:16 ` suravee.suthikulpanit at amd.com
2014-11-03 22:16 ` [V10 PATCH 1/2] genirq: Add irq_chip_set_type_parent function suravee.suthikulpanit
2014-11-03 22:16 ` suravee.suthikulpanit-5C7GfCeVMHo
2014-11-03 22:16 ` suravee.suthikulpanit at amd.com
2014-11-03 22:16 ` [V10 PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X) suravee.suthikulpanit
2014-11-03 22:16 ` suravee.suthikulpanit
2014-11-03 22:16 ` suravee.suthikulpanit at amd.com
2014-11-03 22:51 ` Thomas Gleixner
2014-11-03 22:51 ` Thomas Gleixner
2014-11-04 3:22 ` Suravee Suthikulanit
2014-11-04 3:22 ` Suravee Suthikulanit
2014-11-04 3:22 ` Suravee Suthikulanit
2014-11-04 10:06 ` Thomas Gleixner
2014-11-04 10:06 ` Thomas Gleixner
2014-11-04 14:20 ` Suravee Suthikulpanit [this message]
2014-11-04 14:20 ` Suravee Suthikulpanit
2014-11-04 14:20 ` Suravee Suthikulpanit
2014-11-04 14:28 ` Thomas Gleixner
2014-11-04 14:28 ` Thomas Gleixner
2014-11-04 17:46 ` Marc Zyngier
2014-11-04 17:46 ` Marc Zyngier
2014-11-04 17:46 ` Marc Zyngier
2014-11-04 13:01 ` Jiang Liu
2014-11-04 13:01 ` Jiang Liu
2014-11-04 17:00 ` Suravee Suthikulpanit
2014-11-04 17:00 ` Suravee Suthikulpanit
2014-11-04 17:00 ` Suravee Suthikulpanit
2014-11-06 0:05 ` Suravee Suthikulanit
2014-11-06 0:05 ` Suravee Suthikulanit
2014-11-06 0:05 ` Suravee Suthikulanit
2014-11-06 0:23 ` Suravee Suthikulanit
2014-11-06 0:23 ` Suravee Suthikulanit
2014-11-06 0:23 ` Suravee Suthikulanit
2014-11-06 0:49 ` Thomas Gleixner
2014-11-06 0:49 ` Thomas Gleixner
2014-11-06 10:42 ` Thomas Gleixner
2014-11-06 10:42 ` Thomas Gleixner
2014-11-06 16:34 ` Marc Zyngier
2014-11-06 16:34 ` Marc Zyngier
2014-11-07 1:00 ` Jiang Liu
2014-11-07 1:00 ` Jiang Liu
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=5458E0BE.2090803@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=Catalin.Marinas@arm.com \
--cc=Harish.Kasiviswanathan@amd.com \
--cc=Will.Deacon@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.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.