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>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v2 2/8] PCI/MSI: Add hooks to populate the msi_domain field
Date: Wed, 14 Jan 2015 10:04:14 +0800	[thread overview]
Message-ID: <54B5CE9E.4030801@huawei.com> (raw)
In-Reply-To: <54B52168.3080600@arm.com>

>>> +static void pci_set_msi_domain(struct pci_dev *dev)
>>> +{
>>> +	/*
>>> +	 * If no domain has been set through the pcibios callback,
>>> +	 * inherit the default from the bus device.
>>> +	 */
>>> +	if (!dev_get_msi_domain(&dev->dev))
>>> +		dev_set_msi_domain(&dev->dev,
>>> +				   dev_get_msi_domain(&dev->bus->dev));
>>> +}
>>
>> Hi Marc, now we have two ways to associate the pci_dev and msi_domain, right ?
>>
>> 1. associate pci_dev and msi_domain in pcibios_add_device() like x86.
>>
>> 2. Inherit msi_domain from pci_dev->bus.
>>
>> My question is if all pci devices inherit msi_domain from the pci_bus,
>> so all pci devices under same pci host bridge have the same msi_domain assigned by
>> weak pcibios_set_phb_msi_domain(). So why not save the pci host bridge specific
>> msi_domain in pci_host_bridge. Then pci devices could inherit the msi_domain from
>> its pci host bridge directly, no need to involve pci bus in the assignment.
> 
> But then, you would end-up maintaining another msi_domain field inside
> the pci_host bridge structure. What do you gain by doing so?

My original thought is holding msi_domain field inside the pci_host_bridge is
more simple than every bus maintaining the msi_domain, but this proposal has a
disadvantage that sometimes we must setup for every device. I checked x86 DMAR code,
and found most DMAR would report PCIe root port device associating the msi_domain, not the EP device.
So pcibios_add_device could only associate these bridge device msi_domain, and its children
devices will propagate from their parent bus(get msi_domain from its bridge).

So now I agree your idea, please forgive my nagging :)

Thanks!
Yijing.

> 
> With this series, msi_domain has the nice property of always being tied
> to a device (and struct pci_bus always has a device). We always have
> phb->bus->dev.msi_domain within reach, and architecture code can decide
> to override it on a per-device basis.
> 
> What else do you need? What am I missing from your proposal?
> 
> 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 v2 2/8] PCI/MSI: Add hooks to populate the msi_domain field
Date: Wed, 14 Jan 2015 10:04:14 +0800	[thread overview]
Message-ID: <54B5CE9E.4030801@huawei.com> (raw)
In-Reply-To: <54B52168.3080600@arm.com>

>>> +static void pci_set_msi_domain(struct pci_dev *dev)
>>> +{
>>> +	/*
>>> +	 * If no domain has been set through the pcibios callback,
>>> +	 * inherit the default from the bus device.
>>> +	 */
>>> +	if (!dev_get_msi_domain(&dev->dev))
>>> +		dev_set_msi_domain(&dev->dev,
>>> +				   dev_get_msi_domain(&dev->bus->dev));
>>> +}
>>
>> Hi Marc, now we have two ways to associate the pci_dev and msi_domain, right ?
>>
>> 1. associate pci_dev and msi_domain in pcibios_add_device() like x86.
>>
>> 2. Inherit msi_domain from pci_dev->bus.
>>
>> My question is if all pci devices inherit msi_domain from the pci_bus,
>> so all pci devices under same pci host bridge have the same msi_domain assigned by
>> weak pcibios_set_phb_msi_domain(). So why not save the pci host bridge specific
>> msi_domain in pci_host_bridge. Then pci devices could inherit the msi_domain from
>> its pci host bridge directly, no need to involve pci bus in the assignment.
> 
> But then, you would end-up maintaining another msi_domain field inside
> the pci_host bridge structure. What do you gain by doing so?

My original thought is holding msi_domain field inside the pci_host_bridge is
more simple than every bus maintaining the msi_domain, but this proposal has a
disadvantage that sometimes we must setup for every device. I checked x86 DMAR code,
and found most DMAR would report PCIe root port device associating the msi_domain, not the EP device.
So pcibios_add_device could only associate these bridge device msi_domain, and its children
devices will propagate from their parent bus(get msi_domain from its bridge).

So now I agree your idea, please forgive my nagging :)

Thanks!
Yijing.

> 
> With this series, msi_domain has the nice property of always being tied
> to a device (and struct pci_bus always has a device). We always have
> phb->bus->dev.msi_domain within reach, and architecture code can decide
> to override it on a per-device basis.
> 
> What else do you need? What am I missing from your proposal?
> 
> Thanks,
> 
> 	M.
> 


-- 
Thanks!
Yijing

  reply	other threads:[~2015-01-14  2:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-08 17:06 [PATCH v2 0/8] Introducing per-device MSI domain Marc Zyngier
2015-01-08 17:06 ` Marc Zyngier
2015-01-08 17:06 ` [PATCH v2 1/8] device core: Introduce per-device MSI domain pointer Marc Zyngier
2015-01-08 17:06   ` Marc Zyngier
2015-01-15 20:35   ` Stuart Yoder
2015-01-15 20:35     ` Stuart Yoder
2015-01-16 19:10     ` Marc Zyngier
2015-01-16 19:10       ` Marc Zyngier
2015-01-19  2:10     ` Jiang Liu
2015-01-19  2:10       ` Jiang Liu
2015-01-20 17:17       ` Stuart Yoder
2015-01-20 17:17         ` Stuart Yoder
2015-01-21  1:34         ` Jiang Liu
2015-01-21  1:34           ` Jiang Liu
2015-01-08 17:06 ` [PATCH v2 2/8] PCI/MSI: Add hooks to populate the msi_domain field Marc Zyngier
2015-01-08 17:06   ` Marc Zyngier
2015-01-13 12:34   ` Yijing Wang
2015-01-13 12:34     ` Yijing Wang
2015-01-13 13:45     ` Marc Zyngier
2015-01-13 13:45       ` Marc Zyngier
2015-01-14  2:04       ` Yijing Wang [this message]
2015-01-14  2:04         ` Yijing Wang
2015-01-14  2:06   ` Yijing Wang
2015-01-14  2:06     ` Yijing Wang
2015-01-08 17:06 ` [PATCH v2 3/8] PCI/MSI: of: Add support for OF-provided msi_domain Marc Zyngier
2015-01-08 17:06   ` Marc Zyngier
2015-01-14  8:17   ` Yun Wu (Abel)
2015-01-14  8:17     ` Yun Wu (Abel)
2015-01-14 10:19     ` Marc Zyngier
2015-01-14 10:19       ` Marc Zyngier
2015-01-08 17:06 ` [PATCH v2 4/8] PCI/MSI: of: Allow msi_domain lookup using the PHB node Marc Zyngier
2015-01-08 17:06   ` Marc Zyngier
2015-01-08 17:06 ` [PATCH v2 5/8] PCI/MSI: Let pci_msi_get_domain use struct device's msi_domain Marc Zyngier
2015-01-08 17:06   ` Marc Zyngier
2015-01-08 17:06 ` [PATCH v2 6/8] irqchip: GICv2m: Get rid of struct msi_controller Marc Zyngier
2015-01-08 17:06   ` Marc Zyngier
2015-01-08 17:06 ` [PATCH v2 7/8] irqchip: gicv3-its: " Marc Zyngier
2015-01-08 17:06   ` Marc Zyngier
2015-01-08 17:06 ` [PATCH v2 8/8] PCI/MSI: Drop domain field from msi_controller Marc Zyngier
2015-01-08 17:06   ` Marc Zyngier
2015-01-27  0:45 ` [PATCH v2 0/8] Introducing per-device MSI domain Bjorn Helgaas
2015-01-27  0:45   ` Bjorn Helgaas

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=54B5CE9E.4030801@huawei.com \
    --to=wangyijing@huawei.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.