All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yijing Wang <wangyijing@huawei.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jiang Liu <jiang.liu@linux.intel.com>
Cc: "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>,
	Will Deacon <Will.Deacon@arm.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH 2/6] PCI/MSI: add hooks to populate the msi_domain field
Date: Tue, 9 Dec 2014 20:24:32 +0800	[thread overview]
Message-ID: <5486EA00.6080901@huawei.com> (raw)
In-Reply-To: <5486E747.4010804@arm.com>

>>> Well, this is not supposed to be a perfect solution yet, but instead a
>>> basis for discussion. What I'd like to find out is:
>>>
>>> - What is the minimum granularity for associating a device with its MSI
>>> domain in existing platforms?
>>
>> PCI device, after Gerry's msi irq domain patchset which now in linux-next,
>> in x86, we will find msi irq domain by pci_dev.
> 
> Are you *really* associating the MSI domain on a per pci-device basis?
> That is, you have devices on the same PCI bus talking to different MSI hw?

Yes.

> 
>> I generally agree your first patch which associate basic device with msi irq domain.
>>
>>> - What topology data structures do you use to find out what MSI
>>> controller a device should be matched with?
>>
>> Now only arm and arm64 use msi controller to setup/teardown msi irqs,
>> in arm, now msi controller saved in pci_sys_data, and for arm64, it seems
>> to be saved in pci_bus. For a more common method to find msi controller/irq domain,
>> I prefer pci_dev/device.
> 
> Forget about msi_controller, the whole goal of this series is to make it
> obsolete. On your x86 platform, what how do you identify which MSI
> domain should be associated with a given PCI device? Surely you must
> have a set of data structures or ACPI tables which give you that
> information.

Yes, by ACPI DMAR table.

> 
>>> - What in-tree platform already has this requirements?
>>
>> As mentioned above, x86 does.
> 
> Let me rephrase that in a non-ambiguous manner: can you point me to a
> file implementing this in mainline?

Please refer to arch/x86/kernel/apic/msi.c  native_setup_msi_irqs()  in linux-next tree.

Thanks!
Yijing.

> 
> Thanks,
> 
> 	M.
> 


-- 
Thanks!
Yijing


WARNING: multiple messages have this Message-ID (diff)
From: wangyijing@huawei.com (Yijing Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] PCI/MSI: add hooks to populate the msi_domain field
Date: Tue, 9 Dec 2014 20:24:32 +0800	[thread overview]
Message-ID: <5486EA00.6080901@huawei.com> (raw)
In-Reply-To: <5486E747.4010804@arm.com>

>>> Well, this is not supposed to be a perfect solution yet, but instead a
>>> basis for discussion. What I'd like to find out is:
>>>
>>> - What is the minimum granularity for associating a device with its MSI
>>> domain in existing platforms?
>>
>> PCI device, after Gerry's msi irq domain patchset which now in linux-next,
>> in x86, we will find msi irq domain by pci_dev.
> 
> Are you *really* associating the MSI domain on a per pci-device basis?
> That is, you have devices on the same PCI bus talking to different MSI hw?

Yes.

> 
>> I generally agree your first patch which associate basic device with msi irq domain.
>>
>>> - What topology data structures do you use to find out what MSI
>>> controller a device should be matched with?
>>
>> Now only arm and arm64 use msi controller to setup/teardown msi irqs,
>> in arm, now msi controller saved in pci_sys_data, and for arm64, it seems
>> to be saved in pci_bus. For a more common method to find msi controller/irq domain,
>> I prefer pci_dev/device.
> 
> Forget about msi_controller, the whole goal of this series is to make it
> obsolete. On your x86 platform, what how do you identify which MSI
> domain should be associated with a given PCI device? Surely you must
> have a set of data structures or ACPI tables which give you that
> information.

Yes, by ACPI DMAR table.

> 
>>> - What in-tree platform already has this requirements?
>>
>> As mentioned above, x86 does.
> 
> Let me rephrase that in a non-ambiguous manner: can you point me to a
> file implementing this in mainline?

Please refer to arch/x86/kernel/apic/msi.c  native_setup_msi_irqs()  in linux-next tree.

Thanks!
Yijing.

> 
> Thanks,
> 
> 	M.
> 


-- 
Thanks!
Yijing

  reply	other threads:[~2014-12-09 12:24 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08 20:12 [PATCH 0/6] Introducing per-device MSI domain Marc Zyngier
2014-12-08 20:12 ` Marc Zyngier
2014-12-08 20:12 ` [PATCH 1/6] device core: Introduce per-device MSI domain pointer Marc Zyngier
2014-12-08 20:12   ` Marc Zyngier
2014-12-08 20:12 ` [PATCH 2/6] PCI/MSI: add hooks to populate the msi_domain field Marc Zyngier
2014-12-08 20:12   ` Marc Zyngier
2014-12-09  2:03   ` Yijing Wang
2014-12-09  2:03     ` Yijing Wang
2014-12-09 10:02     ` Marc Zyngier
2014-12-09 10:02       ` Marc Zyngier
2014-12-09 11:57       ` Yijing Wang
2014-12-09 11:57         ` Yijing Wang
2014-12-09 12:12         ` Marc Zyngier
2014-12-09 12:12           ` Marc Zyngier
2014-12-09 12:24           ` Yijing Wang [this message]
2014-12-09 12:24             ` Yijing Wang
2014-12-09 12:47           ` Jiang Liu
2014-12-09 12:47             ` Jiang Liu
2014-12-09 14:03             ` Marc Zyngier
2014-12-09 14:03               ` Marc Zyngier
2014-12-09 14:11               ` Jiang Liu
2014-12-09 14:11                 ` Jiang Liu
2014-12-09 14:27                 ` Marc Zyngier
2014-12-09 14:27                   ` Marc Zyngier
2014-12-09 14:35                   ` Jiang Liu
2014-12-09 14:35                     ` Jiang Liu
2014-12-09 14:59                     ` Marc Zyngier
2014-12-09 14:59                       ` Marc Zyngier
2014-12-09 15:42                       ` Jiang Liu
2014-12-09 15:42                         ` Jiang Liu
2014-12-09 12:57   ` Jiang Liu
2014-12-09 12:57     ` Jiang Liu
2015-01-27  0:40   ` Bjorn Helgaas
2015-01-27  0:40     ` Bjorn Helgaas
2015-01-27  0:43     ` Bjorn Helgaas
2015-01-27  0:43       ` Bjorn Helgaas
2014-12-08 20:12 ` [PATCH 3/6] PCI/MSI: of: add support for OF-provided msi_domain Marc Zyngier
2014-12-08 20:12   ` Marc Zyngier
2015-01-27  0:41   ` Bjorn Helgaas
2015-01-27  0:41     ` Bjorn Helgaas
2014-12-08 20:12 ` [PATCH 4/6] PCI/MSI: Let pci_msi_get_domain use struct device's msi_domain Marc Zyngier
2014-12-08 20:12   ` Marc Zyngier
2014-12-08 20:12 ` [PATCH 5/6] irqchip: GICv2m: Get rid of struct msi_controller Marc Zyngier
2014-12-08 20:12   ` Marc Zyngier
2014-12-08 20:12 ` [PATCH 6/6] irqchip: gicv3-its: " Marc Zyngier
2014-12-08 20:12   ` 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=5486EA00.6080901@huawei.com \
    --to=wangyijing@huawei.com \
    --cc=Will.Deacon@arm.com \
    --cc=bhelgaas@google.com \
    --cc=jiang.liu@linux.intel.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 \
    --cc=suravee.suthikulpanit@amd.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.