From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [PATCH v3 -tip 5/5] AHCI: Support multiple MSIs Date: Tue, 02 Oct 2012 00:48:59 -0400 Message-ID: <506A723B.6040504@pobox.com> References: <506A59A4.7060907@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-qc0-f174.google.com ([209.85.216.174]:49276 "EHLO mail-qc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750753Ab2JBEtD (ORCPT ); Tue, 2 Oct 2012 00:49:03 -0400 In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Bjorn Helgaas Cc: Alexander Gordeev , linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner , Suresh Siddha , Yinghai Lu , Matthew Wilcox , x86@kernel.org, linux-pci@vger.kernel.org, linux-ide@vger.kernel.org On 10/02/2012 12:21 AM, Bjorn Helgaas wrote: > On Mon, Oct 1, 2012 at 9:04 PM, Jeff Garzik 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 >>> --- >>> 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 >> >> 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