From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm/gic: Add supports for GICv2m MSI(-X)
Date: Fri, 27 Jun 2014 10:43:24 -0500 [thread overview]
Message-ID: <53AD911C.6040301@amd.com> (raw)
In-Reply-To: <53A94A46.1010801@arm.com>
Hi Marc,
After looking at the GICv3 implementation and trying to understand how
you architect the driver, I have a couple questions below.
> On 06/24/2014 04:52 AM, Marc Zyngier wrote:
> Hi Suravee,
>
> On 24/06/14 01:33, suravee.suthikulpanit@amd.com wrote:
>> + pr_info("GICv2m: SPI range [%d:%d]\n",
>> + msi->spi_start, (msi->spi_start + msi->max_spi_cnt));
>> +
>> + gic_arch_extn.irq_mask = gicv2m_mask_msi;
>> + gic_arch_extn.irq_unmask = gicv2m_unmask_msi;
>
> Right, I now see why you need to test on the MSI descriptor. Don't do
> that. The gic_arch_extn crap should *never* *be* *used*.
Hm, sounds like this should be removed all together then? In that case,
this would require changes in the irq-gic.c to call these functions
directly.
>
> What you want to do is do assign a different irq_chip to your MSI
> interrupts. This will require a different integration with the main GIC
> code though. For the GICv3 ITS, I do it when the interrupt gets mapped.
Ah, that's what I was trying to avoid. Why should we need a whole
different irq_chip just to add the MSI register frame support on top of
the GICv2 which is already supported by the current irq-gic.c?
>
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(gicv2m_msi_init);
>> +
>> +
>> +
>> +/**
>> + * Override arch_setup_msi_irq in drivers/pci/msi.c
>> + * since we don't want to change the chip_data
>> + */
>> +int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
>> +{
>> + struct msi_chip *chip = pdev->bus->msi;
>> +
>> + if (!chip || !chip->setup_irq)
>> + return -EINVAL;
>> +
>> + return chip->setup_irq(chip, pdev, desc);
>> +}
>> +
>> +/**
>> + * Override arch_teardown_msi_irq in drivers/pci/msi.c
>> + */
>> +void arch_teardown_msi_irq(unsigned int irq)
>> +{
>> + struct msi_desc *desc;
>> + struct msi_chip *chip;
>> +
>> + desc = irq_get_msi_desc(irq);
>> + if (!desc)
>> + return;a
>> +
>> + chip = desc->dev->bus->msi;
>> + if (!chip)
>> + return;
>> +
>> + chip->teardown_irq(chip, irq);
>> +}
>
> Please don't overtide those. There shouldn't be any reason for a
> *driver* to do so. Only architecture code should do it. And nothing in
> your code requires it (at least once you've stopped playing with the
> silly gic extension...).
The reason I need these because the __weak version of arch_setup_msi_irq
function in driver/pci/msi.c calls irq_set_chip_data and replace the
chip_data with msi_chip (originally was pointing to the gic_chip_data
structure). This ended up breaking the GIC.
Looking at the GICv3 ITS implementation, this seems to also have similar
implementation. So, this was not an issue for you?
Thanks,
Suravee
next prev parent reply other threads:[~2014-06-27 15:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 0:32 [PATCH 0/2] Introduce ARM GICv2m MSI(-X) support suravee.suthikulpanit
2014-06-24 0:32 ` [PATCH 1/2] arm/gic: Add binding probe for GIC400 suravee.suthikulpanit
2014-06-24 12:22 ` Jason Cooper
2014-06-24 0:33 ` [PATCH 2/2] arm/gic: Add supports for GICv2m MSI(-X) suravee.suthikulpanit
2014-06-24 9:52 ` Marc Zyngier
2014-06-25 3:04 ` Suravee Suthikulanit
2014-06-27 15:43 ` Suravee Suthikulpanit [this message]
2014-06-27 17:35 ` Marc Zyngier
2014-06-24 10:11 ` Mark Rutland
2014-06-25 2:55 ` Suravee Suthikulanit
2014-06-25 8:57 ` Mark Rutland
2014-06-24 12:19 ` [PATCH 0/2] Introduce ARM GICv2m MSI(-X) support Jason Cooper
2014-06-24 12:26 ` Jason Cooper
2014-06-25 0:19 ` Suravee Suthikulanit
2014-06-30 18:27 ` Jason Cooper
2014-06-24 14:09 ` Joel Schopp
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=53AD911C.6040301@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=Catalin.Marinas@arm.com \
--cc=Will.Deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marc.zyngier@arm.com \
/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