From: Yijing Wang <wangyijing0307@gmail.com>
To: Jiang Liu <jiang.liu@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Yijing Wang <wangyijing@huawei.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Ingo Molnar <mingo@redhat.com>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
Yingjoe Chen <yingjoe.chen@mediatek.com>,
Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Tony Luck <tony.luck@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Patch V1 0/6] Refine generic/PCI MSI irqodmian interfaces
Date: Fri, 14 Nov 2014 22:11:11 +0800 [thread overview]
Message-ID: <54660D7F.70702@gmail.com> (raw)
In-Reply-To: <54655D44.1070703@linux.intel.com>
在 2014/11/14 9:39, Jiang Liu 写道:
> On 2014/11/14 9:31, Thomas Gleixner wrote:
>> On Fri, 14 Nov 2014, Yijing Wang wrote:
>>
>> Could you please use a mail client which does proper line wraps or
>> configure yours to do so?
>>
>>> Associate the irq domain and PCI bus is not necessary, because all
>>> PCI buses under same host bridge always share same MSI chip/irq
>>> domain, we only need associate them and pci host bridge.
>>>
>>> I'm refactoring the pci_host_bridge, make it be a generic one, rip
>>> out of the pci root bus creation, so we could put the irq domain and
>>> pci domain etc.. in it. Finally, we could eliminate lots platform
>>> arch functions. I will post it out within one week.
>> That's a completely orthogonal problem. From the MSI/interrupt
>> handling POV it does not matter at all where that information is
>> stored. All we care about is that it is retrievable via the (pci)
>> device which tries to setup MSI[X].
>>
>> So we can store/retrieve it via generic functions into/from whatever
>> is available right now. If the irq side has generic interfaces to do
>> so then this wont conflict with your decisions to change the final
>> storage point because all it takes is to tweak the storage/retrieve
>> functions.
>>
>> So all we need at the moment is an agreed on way to store/retrieve
>> that information which is based on the current shared infrastructure,
>> aka. Linus tree. If we can utilize that you are completely free to
>> change the association mechanism underneath.
> Hi Thomas,
> So we need something like:
> struct msi_chip *pci_get_msi_chip(struct pci_dev *);
> or:
> struct irq_domain *pci_get_msi_domain(struct pci_dev *);
Hi Gerry,
what about associate the platform specific struct msi_chip
*pci_get_msi_chip(struct pci_dev *)
with struct pci_host_bridge. we could provide the private
"pci_get_msi_chip()" in the PCI
host drivers.
Thanks!
Yijing.
>
> BTW, there's a conflict when merging tip/irq/irqdomain into
> tip/x86/apic. It's my first time to deal with merging conflicts,
> what's the preferred way? Is it working like this?
> 1) I merge the two branch
> 2) I rebase my x86 irqdomain patch sets and send them to you
> 3) You merge the two branch and apply my patch set.
> Regards!
> Gerry
>> Thanks,
>>
>> tglx
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
WARNING: multiple messages have this Message-ID (diff)
From: wangyijing0307@gmail.com (Yijing Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [Patch V1 0/6] Refine generic/PCI MSI irqodmian interfaces
Date: Fri, 14 Nov 2014 22:11:11 +0800 [thread overview]
Message-ID: <54660D7F.70702@gmail.com> (raw)
In-Reply-To: <54655D44.1070703@linux.intel.com>
? 2014/11/14 9:39, Jiang Liu ??:
> On 2014/11/14 9:31, Thomas Gleixner wrote:
>> On Fri, 14 Nov 2014, Yijing Wang wrote:
>>
>> Could you please use a mail client which does proper line wraps or
>> configure yours to do so?
>>
>>> Associate the irq domain and PCI bus is not necessary, because all
>>> PCI buses under same host bridge always share same MSI chip/irq
>>> domain, we only need associate them and pci host bridge.
>>>
>>> I'm refactoring the pci_host_bridge, make it be a generic one, rip
>>> out of the pci root bus creation, so we could put the irq domain and
>>> pci domain etc.. in it. Finally, we could eliminate lots platform
>>> arch functions. I will post it out within one week.
>> That's a completely orthogonal problem. From the MSI/interrupt
>> handling POV it does not matter at all where that information is
>> stored. All we care about is that it is retrievable via the (pci)
>> device which tries to setup MSI[X].
>>
>> So we can store/retrieve it via generic functions into/from whatever
>> is available right now. If the irq side has generic interfaces to do
>> so then this wont conflict with your decisions to change the final
>> storage point because all it takes is to tweak the storage/retrieve
>> functions.
>>
>> So all we need at the moment is an agreed on way to store/retrieve
>> that information which is based on the current shared infrastructure,
>> aka. Linus tree. If we can utilize that you are completely free to
>> change the association mechanism underneath.
> Hi Thomas,
> So we need something like:
> struct msi_chip *pci_get_msi_chip(struct pci_dev *);
> or:
> struct irq_domain *pci_get_msi_domain(struct pci_dev *);
Hi Gerry,
what about associate the platform specific struct msi_chip
*pci_get_msi_chip(struct pci_dev *)
with struct pci_host_bridge. we could provide the private
"pci_get_msi_chip()" in the PCI
host drivers.
Thanks!
Yijing.
>
> BTW, there's a conflict when merging tip/irq/irqdomain into
> tip/x86/apic. It's my first time to deal with merging conflicts,
> what's the preferred way? Is it working like this?
> 1) I merge the two branch
> 2) I rebase my x86 irqdomain patch sets and send them to you
> 3) You merge the two branch and apply my patch set.
> Regards!
> Gerry
>> Thanks,
>>
>> tglx
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-11-14 14:11 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 11:43 [Patch V1 0/6] Refine generic/PCI MSI irqodmian interfaces Jiang Liu
2014-11-13 11:43 ` Jiang Liu
2014-11-13 11:43 ` [Patch V1 1/6] PCI, MSI: Fix errors caused by commit e5f1a59c4e12 Jiang Liu
2014-11-13 11:43 ` Jiang Liu
2014-11-13 11:43 ` [Patch V1 2/6] PCI, MSI: Introduce helpers to hide struct msi_desc implemenation details Jiang Liu
2014-11-13 11:43 ` Jiang Liu
2014-11-13 11:43 ` [Patch V1 3/6] genirq: Introduce msi_domain_{alloc|free}_irqs() Jiang Liu
2014-11-13 11:43 ` Jiang Liu
2014-11-13 20:23 ` Marc Zyngier
2014-11-13 20:23 ` Marc Zyngier
2014-11-14 0:18 ` Jiang Liu
2014-11-14 0:18 ` Jiang Liu
2014-11-13 11:43 ` [Patch V1 3/6] genirq: Introduce msi_irq_domain_{alloc|free}_irqs() Jiang Liu
2014-11-13 11:43 ` Jiang Liu
2014-11-13 12:34 ` Yijing Wang
2014-11-13 12:34 ` Yijing Wang
2014-11-13 12:41 ` Jiang Liu
2014-11-13 12:41 ` Jiang Liu
2014-11-13 12:57 ` Yijing Wang
2014-11-13 12:57 ` Yijing Wang
2014-11-13 11:43 ` [Patch V1 4/6] genirq: Provide default callbacks for msi_domain_ops Jiang Liu
2014-11-13 11:43 ` Jiang Liu
2014-11-13 11:43 ` [Patch V1 5/6] PCI, MSI: Refine irqdomain interfaces to simplify its usage Jiang Liu
2014-11-13 11:43 ` Jiang Liu
2014-11-13 11:43 ` [Patch V1 6/6] PCI, MSI: Provide mechanism to alloc/free MSI/MSIX interrupt from irqdomain Jiang Liu
2014-11-13 11:43 ` Jiang Liu
2014-11-13 19:46 ` Marc Zyngier
2014-11-13 19:46 ` Marc Zyngier
2014-11-13 12:28 ` [Patch V1 0/6] Refine generic/PCI MSI irqodmian interfaces Yijing Wang
2014-11-13 12:28 ` Yijing Wang
2014-11-13 12:39 ` Jiang Liu
2014-11-13 12:39 ` Jiang Liu
2014-11-13 12:55 ` Yijing Wang
2014-11-13 12:55 ` Yijing Wang
2014-11-13 13:03 ` Jiang Liu
2014-11-13 13:03 ` Jiang Liu
2014-11-13 13:05 ` Jiang Liu
2014-11-13 13:05 ` Jiang Liu
2014-11-13 21:00 ` Marc Zyngier
2014-11-13 21:00 ` Marc Zyngier
2014-11-13 21:11 ` Thomas Gleixner
2014-11-13 21:11 ` Thomas Gleixner
2014-11-13 21:28 ` Marc Zyngier
2014-11-13 21:28 ` Marc Zyngier
2014-11-14 15:54 ` Jiang Liu
2014-11-14 15:54 ` Jiang Liu
2014-11-14 16:13 ` Marc Zyngier
2014-11-14 16:13 ` Marc Zyngier
2014-11-14 0:25 ` Jiang Liu
2014-11-14 0:25 ` Jiang Liu
2014-11-14 1:09 ` Yijing Wang
2014-11-14 1:09 ` Yijing Wang
2014-11-14 1:22 ` Jiang Liu
2014-11-14 1:22 ` Jiang Liu
2014-11-14 1:31 ` Thomas Gleixner
2014-11-14 1:31 ` Thomas Gleixner
2014-11-14 1:39 ` Jiang Liu
2014-11-14 1:39 ` Jiang Liu
2014-11-14 12:13 ` Thomas Gleixner
2014-11-14 12:13 ` Thomas Gleixner
2014-11-14 14:11 ` Yijing Wang [this message]
2014-11-14 14:11 ` Yijing Wang
2014-11-14 14:26 ` Jiang Liu
2014-11-14 14:26 ` Jiang Liu
2014-11-14 15:16 ` Marc Zyngier
2014-11-14 15:16 ` Marc Zyngier
2014-11-14 15:25 ` Jiang Liu
2014-11-14 15:25 ` Jiang Liu
2014-11-14 16:03 ` Marc Zyngier
2014-11-14 16:03 ` Marc Zyngier
2014-11-14 17:11 ` Lucas Stach
2014-11-14 17:11 ` Lucas Stach
2014-11-14 2:16 ` Yijing Wang
2014-11-14 2:16 ` Yijing Wang
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=54660D7F.70702@gmail.com \
--to=wangyijing0307@gmail.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=grant.likely@linaro.org \
--cc=hpa@zytor.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=matthias.bgg@gmail.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=wangyijing@huawei.com \
--cc=yingjoe.chen@mediatek.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 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.