All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Alexander Gordeev <agordeev@redhat.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	Yinghai Lu <yinghai@kernel.org>,
	Matthew Wilcox <willy@linux.intel.com>,
	x86@kernel.org, linux-pci@vger.kernel.org,
	linux-ide@vger.kernel.org
Subject: Re: [PATCH v3 -tip 5/5] AHCI: Support multiple MSIs
Date: Tue, 02 Oct 2012 00:48:59 -0400	[thread overview]
Message-ID: <506A723B.6040504@pobox.com> (raw)
In-Reply-To: <CAErSpo5okRNxzRUj1Q8KEJi4WE_e5Aiq7B8Z-beJP=BikxU+6g@mail.gmail.com>

On 10/02/2012 12:21 AM, Bjorn Helgaas wrote:
> On Mon, Oct 1, 2012 at 9:04 PM, Jeff Garzik <jgarzik@pobox.com> 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@redhat.com>
>>> ---
>>>    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@redhat.com>
>>
>> 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





  reply	other threads:[~2012-10-02  4:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-01  8:08 [PATCH v3 -tip 0/5] x86, MSI, AHCI: Support multiple MSIs Alexander Gordeev
2012-10-01  8:09 ` [PATCH v3 -tip 1/5] x86, MSI: Support multiple MSIs in presense of IRQ remapping Alexander Gordeev
2012-10-02  4:55   ` Ingo Molnar
2012-10-02 11:06     ` Alexander Gordeev
2012-10-02 11:25       ` Ingo Molnar
2012-10-04  7:54         ` Alexander Gordeev
2012-10-04  9:17           ` Ingo Molnar
2012-10-01  8:10 ` [PATCH v3 -tip 2/5] x86, MSI: Allocate as many multiple IRQs as requested Alexander Gordeev
2012-10-02  4:58   ` Ingo Molnar
2012-10-01  8:11 ` [PATCH v3 -tip 3/5] x86, MSI: Minor readability fixes Alexander Gordeev
2012-10-02  4:57   ` Ingo Molnar
2012-10-01  8:12 ` [PATCH v3 -tip 4/5] PCI, MSI: Enable multiple MSIs with pci_enable_msi_block_auto() Alexander Gordeev
2012-10-01  8:13 ` [PATCH v3 -tip 5/5] AHCI: Support multiple MSIs Alexander Gordeev
2012-10-02  3:04   ` Jeff Garzik
2012-10-02  4:21     ` Bjorn Helgaas
2012-10-02  4:48       ` Jeff Garzik [this message]
2012-10-02  5:09   ` Ingo Molnar
2012-10-02 16:42     ` Alexander Gordeev
2012-10-02 16:45       ` Jeff Garzik
2012-10-04 14:35         ` Alexander Gordeev

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=506A723B.6040504@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=agordeev@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=willy@linux.intel.com \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /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.