From: Arnd Bergmann <arnd@arndb.de>
To: Yijing Wang <wangyijing@huawei.com>
Cc: linux-arch@vger.kernel.org, Wuyun <wuyun.wu@huawei.com>,
Russell King <linux@arm.linux.org.uk>,
Paul.Mundt@huawei.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Xinwei Hu <huxinwei@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>,
Bjorn Helgaas <bhelgaas@google.com>,
virtualization@lists.linux-foundation.org,
Jiang Liu <jiang.liu@linux.intel.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device
Date: Fri, 1 Aug 2014 15:16:26 +0200 [thread overview]
Message-ID: <201408011516.26253.arnd@arndb.de> (raw)
In-Reply-To: <53D89CA1.7000501@huawei.com>
On Wednesday 30 July 2014, Yijing Wang wrote:
> >>>
> >>> The other part I'm not completely sure about is how you want to
> >>> have MSIs map into normal IRQ descriptors. At the moment, all
> >>> MSI users are based on IRQ numbers, but this has known scalability problems.
> >>
> >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description.
> >> I'm sorry, I don't understand you meaning.
> >> What are the scalability problems you mentioned ?
> > We have soft limitation of nr_irqs or hard limitation NR_IRQS,
> > we couldn't allocate as much irq number as we need in some cases,
> > such as to support MSI-x.
>
> Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :)
This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ
and the number of interrupts is not limited in any form.
My point was more that the device driver should not need to care about
the interrupt number: it gets made up on the spot when the MSI is
needed, and then it is only used to request the IRQ. This can be
simplified into one interface at the device driver level, even though
the internal still use numbers somewhere. If we ever remove IRQ numbers
from the driver API, this part doesn't need to get touched again.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Yijing Wang <wangyijing@huawei.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Russell King <linux@arm.linux.org.uk>,
Paul.Mundt@huawei.com, Marc Zyngier <marc.zyngier@arm.com>,
linux-pci@vger.kernel.org,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
virtualization@lists.linux-foundation.org,
Xinwei Hu <huxinwei@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>,
Bjorn Helgaas <bhelgaas@google.com>, Wuyun <wuyun.wu@huawei.com>
Subject: Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device
Date: Fri, 1 Aug 2014 15:16:26 +0200 [thread overview]
Message-ID: <201408011516.26253.arnd@arndb.de> (raw)
Message-ID: <20140801131626.o3m3ys-VWDgwRb1OSmcm7EsQdL__WqqZBFoDyM9PxTE@z> (raw)
In-Reply-To: <53D89CA1.7000501@huawei.com>
On Wednesday 30 July 2014, Yijing Wang wrote:
> >>>
> >>> The other part I'm not completely sure about is how you want to
> >>> have MSIs map into normal IRQ descriptors. At the moment, all
> >>> MSI users are based on IRQ numbers, but this has known scalability problems.
> >>
> >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description.
> >> I'm sorry, I don't understand you meaning.
> >> What are the scalability problems you mentioned ?
> > We have soft limitation of nr_irqs or hard limitation NR_IRQS,
> > we couldn't allocate as much irq number as we need in some cases,
> > such as to support MSI-x.
>
> Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :)
This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ
and the number of interrupts is not limited in any form.
My point was more that the device driver should not need to care about
the interrupt number: it gets made up on the spot when the MSI is
needed, and then it is only used to request the IRQ. This can be
simplified into one interface at the device driver level, even though
the internal still use numbers somewhere. If we ever remove IRQ numbers
from the driver API, this part doesn't need to get touched again.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device
Date: Fri, 1 Aug 2014 15:16:26 +0200 [thread overview]
Message-ID: <201408011516.26253.arnd@arndb.de> (raw)
In-Reply-To: <53D89CA1.7000501@huawei.com>
On Wednesday 30 July 2014, Yijing Wang wrote:
> >>>
> >>> The other part I'm not completely sure about is how you want to
> >>> have MSIs map into normal IRQ descriptors. At the moment, all
> >>> MSI users are based on IRQ numbers, but this has known scalability problems.
> >>
> >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description.
> >> I'm sorry, I don't understand you meaning.
> >> What are the scalability problems you mentioned ?
> > We have soft limitation of nr_irqs or hard limitation NR_IRQS,
> > we couldn't allocate as much irq number as we need in some cases,
> > such as to support MSI-x.
>
> Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :)
This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ
and the number of interrupts is not limited in any form.
My point was more that the device driver should not need to care about
the interrupt number: it gets made up on the spot when the MSI is
needed, and then it is only used to request the IRQ. This can be
simplified into one interface at the device driver level, even though
the internal still use numbers somewhere. If we ever remove IRQ numbers
from the driver API, this part doesn't need to get touched again.
Arnd
next prev parent reply other threads:[~2014-08-01 13:16 UTC|newest]
Thread overview: 146+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-26 3:08 [RFC PATCH 00/11] Refactor MSI to support Non-PCI device Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 01/11] PCI/MSI: Use pci_dev->msi_cap instead of msi_desc->msi_attrib.pos Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 02/11] PCI/MSI: Use new MSI type macro instead of PCI MSI flags Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 03/11] PCI/MSI: Refactor pci_dev_msi_enabled() Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-08-05 22:35 ` Stuart Yoder
2014-08-05 22:35 ` Stuart Yoder
2014-08-05 22:35 ` Stuart Yoder
2014-08-06 1:23 ` Yijing Wang
2014-08-06 1:23 ` Yijing Wang
2014-08-06 1:23 ` Yijing Wang
2014-08-06 1:23 ` Yijing Wang
2014-08-20 5:57 ` Bharat.Bhushan
2014-08-20 5:57 ` Bharat.Bhushan at freescale.com
2014-08-20 5:57 ` Bharat.Bhushan
2014-08-20 5:57 ` Bharat.Bhushan
2014-08-20 6:30 ` Yijing Wang
2014-08-20 6:30 ` Yijing Wang
2014-08-20 6:30 ` Yijing Wang
2014-08-20 5:57 ` Bharat.Bhushan
2014-07-26 3:08 ` [RFC PATCH 04/11] PCI/MSI: Move MSIX table address mapping out of msix_capability_init Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 05/11] PCI/MSI: Move populate_msi_sysfs() out of msi_capability_init() Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 06/11] PCI/MSI: Save MSI irq in PCI MSI layer Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 07/11] PCI/MSI: Mask MSI-X entry in msix_setup_entries() Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 08/11] PCI/MSI: Introduce new struct msi_irqs and struct msi_ops Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 09/11] PCI/MSI: refactor PCI MSI driver Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-08-20 6:06 ` Bharat.Bhushan
2014-08-20 6:06 ` Bharat.Bhushan at freescale.com
2014-08-20 6:06 ` Bharat.Bhushan
2014-08-20 6:34 ` Yijing Wang
2014-08-20 6:34 ` Yijing Wang
2014-08-20 6:34 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 10/11] PCI/MSI: Split the generic MSI code into new file Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-08-20 6:18 ` Bharat.Bhushan
2014-08-20 6:18 ` Bharat.Bhushan at freescale.com
2014-08-20 6:18 ` Bharat.Bhushan
2014-08-20 6:43 ` Yijing Wang
2014-08-20 6:43 ` Yijing Wang
2014-08-20 6:43 ` Yijing Wang
2014-07-26 3:08 ` [RFC PATCH 11/11] x86/MSI: Refactor x86 MSI code Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-07-26 3:08 ` Yijing Wang
2014-08-20 6:20 ` Bharat.Bhushan
2014-08-20 6:20 ` Bharat.Bhushan at freescale.com
2014-08-20 6:20 ` Bharat.Bhushan
2014-08-20 7:01 ` Yijing Wang
2014-08-20 7:01 ` Yijing Wang
2014-08-20 7:01 ` Yijing Wang
2014-07-29 14:08 ` [RFC PATCH 00/11] Refactor MSI to support Non-PCI device Arnd Bergmann
2014-07-29 14:08 ` Arnd Bergmann
2014-07-29 14:08 ` Arnd Bergmann
2014-07-30 2:45 ` Yijing Wang
2014-07-30 2:45 ` Yijing Wang
2014-07-30 2:45 ` Yijing Wang
2014-07-30 2:45 ` Yijing Wang
2014-07-30 6:47 ` Jiang Liu
2014-07-30 6:47 ` Jiang Liu
2014-07-30 7:20 ` Yijing Wang
2014-07-30 7:20 ` Yijing Wang
2014-07-30 7:20 ` Yijing Wang
2014-08-01 13:16 ` Arnd Bergmann [this message]
2014-08-01 13:16 ` Arnd Bergmann
2014-08-01 13:16 ` Arnd Bergmann
2014-08-04 3:32 ` Yijing Wang
2014-08-04 3:32 ` Yijing Wang
2014-08-04 3:32 ` Yijing Wang
2014-08-04 14:45 ` Arnd Bergmann
2014-08-04 14:45 ` Arnd Bergmann
2014-08-05 2:20 ` Yijing Wang
2014-08-05 2:20 ` Yijing Wang
2014-08-05 2:20 ` Yijing Wang
2014-08-05 2:20 ` Yijing Wang
2014-08-04 14:45 ` Arnd Bergmann
2014-08-04 3:32 ` Yijing Wang
2014-07-30 7:20 ` Yijing Wang
2014-07-30 6:47 ` Jiang Liu
2014-08-01 13:52 ` Arnd Bergmann
2014-08-01 13:52 ` Arnd Bergmann
2014-08-01 13:52 ` Arnd Bergmann
2014-08-04 6:43 ` Yijing Wang
2014-08-04 6:43 ` Yijing Wang
2014-08-04 6:43 ` Yijing Wang
2014-08-04 6:43 ` Yijing Wang
2014-08-04 14:59 ` Arnd Bergmann
2014-08-04 14:59 ` Arnd Bergmann
2014-08-04 14:59 ` Arnd Bergmann
2014-08-05 2:12 ` Yijing Wang
2014-08-05 2:12 ` Yijing Wang
2014-08-05 2:12 ` Yijing Wang
2014-08-05 2:12 ` Yijing Wang
2014-08-01 10:27 ` arnab.basu
2014-08-01 10:27 ` arnab.basu at freescale.com
2014-08-04 3:03 ` Yijing Wang
2014-08-04 3:03 ` Yijing Wang
2014-08-04 3:03 ` Yijing Wang
2014-08-20 5:44 ` Bharat.Bhushan
2014-08-20 5:44 ` Bharat.Bhushan at freescale.com
2014-08-20 5:44 ` Bharat.Bhushan
2014-08-20 6:28 ` Yijing Wang
2014-08-20 6:28 ` Yijing Wang
2014-08-20 6:28 ` Yijing Wang
2014-08-20 7:41 ` Bharat.Bhushan
2014-08-20 7:41 ` Bharat.Bhushan
2014-08-20 7:41 ` Bharat.Bhushan at freescale.com
2014-08-20 7:55 ` Yijing Wang
2014-08-20 7:55 ` Yijing Wang
2014-08-20 7:55 ` Yijing Wang
2014-09-03 7:15 ` Yijing Wang
2014-09-03 7:15 ` Yijing Wang
2014-09-03 7:15 ` Yijing Wang
2014-08-01 10:27 ` arnab.basu
-- strict thread matches above, loose matches on Subject: below --
2014-07-26 3:08 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=201408011516.26253.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=Paul.Mundt@huawei.com \
--cc=bhelgaas@google.com \
--cc=guohanjun@huawei.com \
--cc=huxinwei@huawei.com \
--cc=jejb@parisc-linux.org \
--cc=jiang.liu@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=virtualization@lists.linux-foundation.org \
--cc=wangyijing@huawei.com \
--cc=wuyun.wu@huawei.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.