From: Alexander Gordeev <agordeev@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
linux-pci@vger.kernel.org, linux-ide@vger.kernel.org,
Ingo Molnar <mingo@kernel.org>, Joerg Roedel <joro@8bytes.org>,
Jan Beulich <JBeulich@suse.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 3/4] AHCI: Conserve interrupts with pci_enable_msi_block_part() interface
Date: Wed, 4 Sep 2013 18:14:43 +0200 [thread overview]
Message-ID: <20130904161442.GE8726@dhcp-26-207.brq.redhat.com> (raw)
In-Reply-To: <20130904145559.GB25788@mtj.dyndns.org>
On Wed, Sep 04, 2013 at 10:55:59AM -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 04, 2013 at 09:22:57AM +0200, Alexander Gordeev wrote:
> > I think a general approach that will cover it all (including ICH and undesired
> > sharing of interrupt vectors) - start MME from roundup_pow_of_two(n_ports) and
> > ensure MRSM bit is unset. If not - double MME and retry. If still not and the
> > limit is reached - fall back to single MSI.
> >
> > Makes sense?
>
> Ugh... I really don't want this sort of retry loop. I'm still a bit
> lost on why this is necessary. Can you please elaborate?
Sure.
1. We do not support sharing MSI messages since there is no appropriate
interrupt handling for it. I am not sure if any hardware supports it at
all. This assumption is just for clarity here.
2. We can not just read out MMC value and try to write it to MME, because
we are not sure the hardware honours the specification. I.e. in case of 6
ports and MMC value of 16 the value of 8 in MME could enable multiple MSIs
while the value of 16 could enforce MRSM. Contradicts to the AHCI
specification, but look how weird ICH is [4].
3. Enabling more MSIs than needed (MME == MMC instead of MME < MMC) could
lead to unnecessary allocation of internal device resources. Bit lame, but
still true.
4. We can not derive the value of MME needed from the number of ports, at
least in case of ICH. I.e. with 6 ports and MMC value of 16 the value of 8
in MME is what would be expected according to the AHCI specification. But
the ICH reserves it and MRSMs in case 8 is written to MME.
So to cover all the above assumptions we need to scan from lowest possible
and watch the MRSM bit is unset.
> Thanks.
>
> --
> tejun
--
Regards,
Alexander Gordeev
agordeev@redhat.com
next prev parent reply other threads:[~2013-09-04 16:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-02 8:59 [PATCH 0/4] AHCI: Conserve interrupts with pci_enable_msi_block_part() interface Alexander Gordeev
2013-09-02 8:59 ` [PATCH 1/4] PCI/MSI: Introduce " Alexander Gordeev
2013-09-03 14:19 ` Tejun Heo
2013-09-02 9:00 ` [PATCH 2/4] MSI/x86: Support " Alexander Gordeev
2013-09-03 13:32 ` Tejun Heo
2013-09-02 9:00 ` [PATCH 3/4] AHCI: Conserve interrupts with " Alexander Gordeev
2013-09-03 14:18 ` Tejun Heo
2013-09-03 16:19 ` Alexander Gordeev
2013-09-03 18:27 ` Tejun Heo
2013-09-04 7:22 ` Alexander Gordeev
2013-09-04 14:17 ` [PATCH v2 " Alexander Gordeev
2013-09-04 14:55 ` [PATCH " Tejun Heo
2013-09-04 16:14 ` Alexander Gordeev [this message]
2013-09-04 18:06 ` Tejun Heo
2013-09-04 18:47 ` Alexander Gordeev
2013-09-04 18:51 ` Tejun Heo
2013-09-02 9:00 ` [PATCH 4/4] PCI/MSI: Get rid of pci_enable_msi_block_auto() interface Alexander Gordeev
2013-09-03 7:58 ` [PATCH v2 " Alexander Gordeev
2013-09-03 13:55 ` [PATCH 0/4] AHCI: Conserve interrupts with pci_enable_msi_block_part() interface Tejun Heo
2013-09-03 14:09 ` Tejun Heo
2013-09-04 12:32 ` Alexander Gordeev
2013-09-04 14:57 ` Tejun Heo
2013-09-03 14:57 ` Alexander Gordeev
2013-09-03 16:24 ` Tejun Heo
2013-09-04 8:06 ` Alexander Gordeev
2013-09-04 15:02 ` Tejun Heo
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=20130904161442.GE8726@dhcp-26-207.brq.redhat.com \
--to=agordeev@redhat.com \
--cc=JBeulich@suse.com \
--cc=bhelgaas@google.com \
--cc=joro@8bytes.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tj@kernel.org \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).