.
This series only did compile test, we will test it in x86 and arm platform
later.
Any comments are welcome.
Thanks!
Yijing.
Yijing Wang (11):
PCI/MSI: Use pci_dev-msi_cap instead of msi_desc-msi_attrib.pos
PCI/MSI: Use new MSI type macro instead of PCI MSI flags
PCI/MSI: Refactor
PCI devices save the msi and msix capability offset in pci_dev-msi_cap
and pci_dev-msix_cap. When we access PCI device MSI and MSIX
registers, we can use msi_cap and msix_cap in pci_dev directly.
Remove the pos member in msi_attrib.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips
Save MSI irq in PCI MSI layer, this is preparation
for generic MSI.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/pci/msi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 21b16e0..f96dd38 100644
MSI drvier.
Suggested-by: Yun Wu wuyun...@huawei.com
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/pci/msi.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d5c8e56..116383c 100644
Because some Non-PCI devices don't need to create sysfs object,
so move populate_msi_sysfs() out of generic MSI function
msi/x_capability_init().
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/pci/msi.c | 31 ++-
1 files changed, 18 insertions(+), 13
Add new MSI type marco(MSI_TYPE and MSIX_TYPE) to support
the future generic MSI driver. The coming generic MSI driver
will be used by PCI and Non-PCI devices that have MSI capability.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/pci/msi-octeon.c |4 ++--
arch
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/x86/include/asm/io_apic.h |2 +-
arch/x86/include/asm/irq_remapping.h |4 +-
arch/x86/include/asm/pci.h |6 ++--
arch/x86/include/asm/x86_init.h | 10 +++---
arch/x86/kernel/apic/io_apic.c | 23
Pci_dev_msi_enabled() is used to check whether device
MSI/MSIX enabled. Refactor this function to suuport
checking only device MSI or MSIX enabled.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/cris/arch-v32/drivers/pci/bios.c |2 +-
arch/frv/mb93090-mb00/pci-vdk.c
Save the MSI-X entry initial mask status in
msix_setup_entries(), also mask the entry.
This is preparation for generic MSI.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/pci/msi.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git
-by: Yijing Wang wangyij...@huawei.com
---
include/linux/msi.h | 30 +-
include/linux/pci.h |7 +--
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 3ad8416..5a672d3 100644
--- a/include/linux/msi.h
and used to translate
legacy interrupt to MSI. So for support Non-PCI MSI
device, generic MSI driver is needed. Split the generic
MSI code into new location, drivers/msi/msi.c. Then
MSI driver does not depend PCI anymore.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/Kconfig
Use struct msi_ops to hook PCI MSI operations,
and use struct msi_irqs to refactor PCI MSI drvier.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/pci/msi.c | 351 ++-
include/linux/msi.h | 14 +-
include/linux/pci.h | 11 +-
3
On 2014/7/29 22:08, Arnd Bergmann wrote:
On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
The series is a draft of generic MSI driver that supports PCI
and Non-PCI device which have MSI capability. If you're not interested
it, sorry for the noise.
I've finally managed to take
On 2014/7/30 14:47, Jiang Liu wrote:
On 2014/7/30 10:45, Yijing Wang wrote:
On 2014/7/29 22:08, Arnd Bergmann wrote:
On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
The series is a draft of generic MSI driver that supports PCI
and Non-PCI device which have MSI capability
MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes
are bonding with PCI device. Because MSI has a lot advantages in design.
More and more non-PCI devices want to use MSI as their default interrupt.
The existing MSI device include HPET. HPET driver provide its own MSI
code
On 2014/8/1 21:16, Arnd Bergmann wrote:
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
On 2014/8/1 21:52, Arnd Bergmann wrote:
On Wednesday 30 July 2014, Yijing Wang wrote:
On 2014/7/29 22:08, Arnd Bergmann wrote:
On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
The new data struct for generic MSI driver.
struct msi_irqs {
u8 msi_enabled:1; /* Enable flag
The method you describe here makes sense for PCI devices that are required
to support
legacy interrupts and may or may not support MSI on a given system, but not
so much
for platform devices for which we know exactly whether we want to use MSI
or legacy interrupts.
In particular if you
On 2014/8/4 22:45, Arnd Bergmann wrote:
On Monday 04 August 2014, Yijing Wang wrote:
I have another question is some drivers will request more than one
MSI/MSI-X IRQ, and the driver will use them to process different things.
Eg. network driver generally uses one of them to process trivial
On 2014/8/6 6:35, Stuart Yoder wrote:
On Fri, Jul 25, 2014 at 10:08 PM, Yijing Wang wangyij...@huawei.com wrote:
Pci_dev_msi_enabled() is used to check whether device
MSI/MSIX enabled. Refactor this function to suuport
checking only device MSI or MSIX enabled.
Signed-off-by: Yijing Wang
The key difference between PCI device and Non-PCI MSI is the interfaces to
access hardware MSI registers.
for instance, currently, msi_chip-setup_irq() to setup MSI irq and configure
the MSI address/data registers, so we need to provide device specific
write_msi_msg() interface, then when we
On 2014/8/20 13:57, bharat.bhus...@freescale.com wrote:
-Original Message-
From: linux-pci-ow...@vger.kernel.org
[mailto:linux-pci-ow...@vger.kernel.org]
On Behalf Of Yijing Wang
Sent: Saturday, July 26, 2014 8:39 AM
To: linux-ker...@vger.kernel.org
Cc: Xinwei Hu; Wuyun; Bjorn
@@ -1025,21 +1059,52 @@ int pci_msi_enabled(void)
}
EXPORT_SYMBOL(pci_msi_enabled);
-void pci_msi_init_pci_dev(struct pci_dev *dev)
+static struct msi_ops pci_msi = {
+.msi_set_enable = msi_set_enable,
+.msi_setup_entry = msi_setup_entry,
+.msix_setup_entries =
+int msi_capability_init(struct msi_irqs *msi, int nvec)
+{
+struct msi_desc *entry;
+int ret;
+unsigned mask;
+
+msi_set_enable(msi, 0, MSI_TYPE); /* Disable MSI during set up */
+
+/* MSI Entry Initialization */
+entry = msi_setup_entry(msi);
+if
On 2014/8/20 14:20, bharat.bhus...@freescale.com wrote:
-Original Message-
From: linux-pci-ow...@vger.kernel.org
[mailto:linux-pci-ow...@vger.kernel.org]
On Behalf Of Yijing Wang
Sent: Saturday, July 26, 2014 8:39 AM
To: linux-ker...@vger.kernel.org
Cc: Xinwei Hu; Wuyun; Bjorn
We in Freescale will be using MSI for the devices behind a new-bus (which is
not PCI based), We have a separate bus driver for same. And this new bus
driver
register/provide its own address/data write function which is based on that
specific bus protocol.
Hi Bharat, I'm glad to know your
Provide the private MSI setup functions in bus-driver layer can't apply to
all
Non-PCI MSI devices, because we can not guarantee Non-PCI MSI devices are
always
on a bus. The existing HPET, DMAR device both have no bus bind.
Yes, that's why I was not sure of bus-driver or device-driver
27 matches
Mail list logo
