Re: [PATCH v3 -tip 5/5] AHCI: Support multiple MSIs

From: Jeff Garzik
Date: Tue Oct 02 2012 - 00:49:37 EST


On 10/02/2012 12:21 AM, Bjorn Helgaas wrote:
On Mon, Oct 1, 2012 at 9:04 PM, Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
On 10/01/2012 04:13 AM, Alexander Gordeev wrote:

Take advantage of multiple MSIs implementation on x86 - on systems with
IRQ remapping AHCI ports not only get assigned separate MSI vectors -
but also separate IRQs. As result, interrupts generated by different
ports could be serviced on different CPUs rather than on a single one.

In cases when number of allocated MSIs is less than requested the Sharing
Last MSI mode does not get used, no matter implemented in hardware or not.
Instead, the driver assumes the advantage of multiple MSIs is negated and
falls back to the single MSI mode as if MRSM bit was set (some Intel chips
implement this strategy anyway - MRSM bit gets set even if the number of
allocated MSIs exceeds the number of implemented ports).

Signed-off-by: Alexander Gordeev <agordeev@xxxxxxxxxx>
---
drivers/ata/ahci.c | 91 ++++++++++++++++++++++++++++++++++++--
drivers/ata/ahci.h | 6 +++
drivers/ata/libahci.c | 118
++++++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 205 insertions(+), 10 deletions(-)


Acked-by: Jeff Garzik <jgarzik@xxxxxxxxxx>

Normally, this amount of changes would -really- need to go through the
libata tree. However, given the amount of dependencies, it either needs a
merge tree or to go through the PCI tree...?

Any maintainer comments on disposition?

For what it's worth, the bulk of this change is outside PCI, so it
doesn't seem to me like it should go through the PCI tree. I think I
did ack the part that touched PCI, and there's not much activity in
the PCI MSI area right now, so I'm fine with it going through libata
or whatever people think makes sense.

That works for me, too. I'm ready to queue it, if libata tree is fine with people.

Jeff




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/