> Ok. Thanks for clearing it up. So the idea would be that if
> pci_enable_msix() for "n" number of messages failed, then
> settle down for 1 message, which is equivalent to MSI mode
And if that fails to acquire the one vector for whatever reason (MSI
isn't enabled, or something is buggy in
Manu Abraham [mailto:[EMAIL PROTECTED]
>
>Ok. Thanks for clearing it up. So the idea would be that if
>pci_enable_msix() for "n" number of messages failed, then settle down
>for 1 message, which is equivalent to MSI mode
>
yep
-
To unsubscribe from this list: send the line "unsubscribe
On 7/21/07, Nelson, Shannon <[EMAIL PROTECTED]> wrote:
Manu Abraham [mailto:[EMAIL PROTECTED]
>Sorry for being not clear. What i was asking is thus:
>
>A device that has legacy interrupts and MSI-X. I was thinking that if
>MSI-X failed one should fall back to MSI mode (single message), that's
Manu Abraham [mailto:[EMAIL PROTECTED]
>Sorry for being not clear. What i was asking is thus:
>
>A device that has legacy interrupts and MSI-X. I was thinking that if
>MSI-X failed one should fall back to MSI mode (single message), that's
>what i was assuming.
>
>In such a case, i do enable MSI-X
On 7/21/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
> In a case where you have a device that which supports MSI-X (multiple
> interrupts) but the device in default is in MSI mode, ie some
> configuration change is needed on the device. In such a case, how
> would one handle between MSI-X
> In a case where you have a device that which supports MSI-X (multiple
> interrupts) but the device in default is in MSI mode, ie some
> configuration change is needed on the device. In such a case, how
> would one handle between MSI-X and MSI ?
>
> ie the device initially doesn't support
On 7/21/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
> This driver supports some chipsets that do MSI, and some that do MSI-X,
> but none that can do both.
Thanks, that's the simple answer I was hoping for. Obviously if some
chipsets only do MSI then you need the MSI code in addition to the
> This driver supports some chipsets that do MSI, and some that do MSI-X,
> but none that can do both.
Thanks, that's the simple answer I was hoping for. Obviously if some
chipsets only do MSI then you need the MSI code in addition to the
MSI-X code.
-
To unsubscribe from this list: send the
Roland Dreier [mailto:[EMAIL PROTECTED]
>
>OK, let's try to avoid going off into the weeds here. In the context
>of the specific patch that this thread started with, is there any
>point in having both "msix-single-vector" and "msi" interrupt support?
Some versions of this hardware support MSI-X
Roland Dreier wrote:
> OK, let's try to avoid going off into the weeds here. In the context
> of the specific patch that this thread started with, is there any
> point in having both "msix-single-vector" and "msi" interrupt support?
This driver supports some chipsets that do MSI, and some that
> > Hmm, I see I don't understand what this driver is doing.
> > What is a "struct ioatdma_device"? Is this driver requesting
> > interrupts that come from the NIC or the IOAT DMA engine?
>
> I might have caused some confusion. You had asked if any drivers
> support MSI but not MSI-X,
> Hmm, I see I don't understand what this driver is doing.
> What is a "struct ioatdma_device"? Is this driver requesting
> interrupts that come from the NIC or the IOAT DMA engine?
I might have caused some confusion. You had asked if any drivers
support MSI but not MSI-X, so I threw 2
> Both igb (recently posted) and ixgbe (also recently posted) support both
> MSI and MSI-X. Right now when we try to request MSI-X vectors, if we
> fail to acquire what we've asked for, we fall back to MSI support. If
> MSI fails to initialize, we fall back to legacy interrupts. So it needs
askiewicz Jr, Peter P
> Subject: Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
>
> are there any devices that support MSI but not MSI-X? If
> not, is there any point in having code to support both?
>
> - R.
>
Both igb (recently posted) and ixgbe (also recently post
are there any devices that support MSI but not MSI-X? If not, is
there any point in having code to support both?
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
are there any devices that support MSI but not MSI-X? If not, is
there any point in having code to support both?
- R.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Subject: Re: [PATCH 5/7] I/OAT: Add support for MSI and MSI-X
are there any devices that support MSI but not MSI-X? If
not, is there any point in having code to support both?
- R.
Both igb (recently posted) and ixgbe (also recently posted) support both
MSI and MSI-X. Right now when we try
Both igb (recently posted) and ixgbe (also recently posted) support both
MSI and MSI-X. Right now when we try to request MSI-X vectors, if we
fail to acquire what we've asked for, we fall back to MSI support. If
MSI fails to initialize, we fall back to legacy interrupts. So it needs
Hmm, I see I don't understand what this driver is doing.
What is a struct ioatdma_device? Is this driver requesting
interrupts that come from the NIC or the IOAT DMA engine?
I might have caused some confusion. You had asked if any drivers
support MSI but not MSI-X, so I threw 2 drivers
Hmm, I see I don't understand what this driver is doing.
What is a struct ioatdma_device? Is this driver requesting
interrupts that come from the NIC or the IOAT DMA engine?
I might have caused some confusion. You had asked if any drivers
support MSI but not MSI-X, so I threw
Roland Dreier wrote:
OK, let's try to avoid going off into the weeds here. In the context
of the specific patch that this thread started with, is there any
point in having both msix-single-vector and msi interrupt support?
This driver supports some chipsets that do MSI, and some that do
Roland Dreier [mailto:[EMAIL PROTECTED]
OK, let's try to avoid going off into the weeds here. In the context
of the specific patch that this thread started with, is there any
point in having both msix-single-vector and msi interrupt support?
Some versions of this hardware support MSI-X and not
This driver supports some chipsets that do MSI, and some that do MSI-X,
but none that can do both.
Thanks, that's the simple answer I was hoping for. Obviously if some
chipsets only do MSI then you need the MSI code in addition to the
MSI-X code.
-
To unsubscribe from this list: send the
On 7/21/07, Roland Dreier [EMAIL PROTECTED] wrote:
This driver supports some chipsets that do MSI, and some that do MSI-X,
but none that can do both.
Thanks, that's the simple answer I was hoping for. Obviously if some
chipsets only do MSI then you need the MSI code in addition to the
In a case where you have a device that which supports MSI-X (multiple
interrupts) but the device in default is in MSI mode, ie some
configuration change is needed on the device. In such a case, how
would one handle between MSI-X and MSI ?
ie the device initially doesn't support MSI-X
On 7/21/07, Roland Dreier [EMAIL PROTECTED] wrote:
In a case where you have a device that which supports MSI-X (multiple
interrupts) but the device in default is in MSI mode, ie some
configuration change is needed on the device. In such a case, how
would one handle between MSI-X and MSI
Manu Abraham [mailto:[EMAIL PROTECTED]
Sorry for being not clear. What i was asking is thus:
A device that has legacy interrupts and MSI-X. I was thinking that if
MSI-X failed one should fall back to MSI mode (single message), that's
what i was assuming.
In such a case, i do enable MSI-X mode
On 7/21/07, Nelson, Shannon [EMAIL PROTECTED] wrote:
Manu Abraham [mailto:[EMAIL PROTECTED]
Sorry for being not clear. What i was asking is thus:
A device that has legacy interrupts and MSI-X. I was thinking that if
MSI-X failed one should fall back to MSI mode (single message), that's
what i
Manu Abraham [mailto:[EMAIL PROTECTED]
Ok. Thanks for clearing it up. So the idea would be that if
pci_enable_msix() for n number of messages failed, then settle down
for 1 message, which is equivalent to MSI mode
yep
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Ok. Thanks for clearing it up. So the idea would be that if
pci_enable_msix() for n number of messages failed, then
settle down for 1 message, which is equivalent to MSI mode
And if that fails to acquire the one vector for whatever reason (MSI
isn't enabled, or something is buggy in your
From: Shannon Nelson <[EMAIL PROTECTED]>
Date: Thu, 19 Jul 2007 17:45:12 -0700
> Add support for MSI and MSI-X interrupt handling, including the ability
> to choose the desired interrupt method.
>
> Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
Add support for MSI and MSI-X interrupt handling, including the ability
to choose the desired interrupt method.
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
---
drivers/dma/ioat_dma.c | 353 ---
drivers/dma/ioatdma.h | 12 +
Add support for MSI and MSI-X interrupt handling, including the ability
to choose the desired interrupt method.
Signed-off-by: Shannon Nelson [EMAIL PROTECTED]
---
drivers/dma/ioat_dma.c | 353 ---
drivers/dma/ioatdma.h | 12 +
From: Shannon Nelson [EMAIL PROTECTED]
Date: Thu, 19 Jul 2007 17:45:12 -0700
Add support for MSI and MSI-X interrupt handling, including the ability
to choose the desired interrupt method.
Signed-off-by: Shannon Nelson [EMAIL PROTECTED]
Acked-by: David S. Miller [EMAIL PROTECTED]
But:
34 matches
Mail list logo
