From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Segher Boessenkool <segher@kernel•crashing.org>
Cc: Greg Kroah-Hartman <greg@kroah•com>,
linuxppc-dev@ozlabs•org,
"Eric W. Biederman" <ebiederm@xmission•com>,
linux-pci@atrey•karlin.mff.cuni.cz,
"David S. Miller" <davem@davemloft•net>
Subject: Re: [RFC/PATCH 6/7] MPIC MSI backend
Date: Tue, 07 Nov 2006 19:42:43 +1100 [thread overview]
Message-ID: <1162888963.28571.459.camel@localhost.localdomain> (raw)
In-Reply-To: <93F89F52-7ED9-48F3-AE7A-15CDF5AB8E25@kernel.crashing.org>
> It would be nice to have a generic find_ht_capability(pdev, type).
Agreed, though I prefer the naming to be ht_find_capability().
> If msi_mpic_alloc() changes the sense/polarity, msi_mpic_free()
> should set it back. This doesn't actually matter on CPC925/945,
> as LSI interrupts are rising edge as well (on the MPIC); maybe
> the sense/polarity should be configurable per MPIC controller
> somewhere (or just mark the code as "FIXME: only correct for
> some MPICs").
Yes, I will do a cleanup pass on the MPIC code there. I think it should
only program the chip for polarity/sense in startup() and thus can
"override" the native LSI setting of that vector when the interrupt is
flagged as MSI without actually losing the original information.
Right now, as you noticed, it's a non-issue for MSIs coming off HT, as
both HT interrupts and MSIs are programmed to be edge in the MPIC
itself, however, this is not ok with interrupts from the PCIe slot fow
which, according to the device-tree on my Quad G5, the LSI is level low.
Something else I'd like to do is add a generic IRQF_MSI purely for the
sake of displaying "MSI" instead of "Edge" in /proc/interrupts :-)
Though it might be useful for some backends to track what interrupts
have been configured as MSI too.
> > ++static int msi_mpic_setup_msi_msg(struct pci_dev *pdev,
> > + struct msix_entry *entry, struct msi_msg *msg, int type)
> > +{
> > + u64 addr;
> > +
> > + addr = find_ht_magic_addr(pdev);
> > + msg->address_lo = addr & 0xFFFFFFFF;
> > + msg->address_hi = addr >> 32;
>
> You don't seem the check whether the "magic address" is outside
> of 32-bit range and the device can do 32-bit only?
Good point. It happens not to be on our chipset / firmware but we should
probably check in the check() callback. If it's the case, then we refuse
to enable MSI for that device.
Cheers,
Ben.
next prev parent reply other threads:[~2006-11-07 8:43 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-07 7:21 [RFC/PATCH 0/7] Powerpc MSI Implementation Michael Ellerman
2006-11-07 7:21 ` [RFC/PATCH 2/7] Make some MSI-X #defines generic Michael Ellerman
2006-11-13 18:31 ` patch pci-make-some-msi-x-defines-generic.patch added to gregkh-2.6 tree gregkh
2006-11-07 7:21 ` [RFC/PATCH 1/7] Add #defines for Hypertransport MSI fields Michael Ellerman
2006-11-07 8:01 ` Segher Boessenkool
2006-11-07 7:21 ` [RFC/PATCH 3/7] Rip out the existing powerpc msi stubs Michael Ellerman
2006-11-07 7:21 ` [RFC/PATCH 5/7] RTAS MSI implementation Michael Ellerman
2006-11-08 20:16 ` Jake Moilanen
2006-11-08 23:35 ` Michael Ellerman
2006-11-07 7:21 ` [RFC/PATCH 4/7] Powerpc " Michael Ellerman
2006-11-07 20:07 ` Matthew Wilcox
2006-11-07 20:14 ` Russell King
2006-11-07 20:40 ` Benjamin Herrenschmidt
2006-11-07 20:44 ` Matthew Wilcox
2006-11-07 20:48 ` Russell King
2006-11-07 21:02 ` Matthew Wilcox
2006-11-07 22:25 ` Russell King
2006-11-07 22:29 ` Benjamin Herrenschmidt
2006-11-07 23:11 ` Eric W. Biederman
2006-11-08 0:15 ` Benjamin Herrenschmidt
2006-11-08 1:33 ` Eric W. Biederman
2006-11-08 2:08 ` Benjamin Herrenschmidt
2006-11-08 2:43 ` Eric W. Biederman
2006-11-08 3:02 ` Benjamin Herrenschmidt
2006-11-07 20:39 ` Benjamin Herrenschmidt
2006-11-07 7:21 ` [RFC/PATCH 6/7] MPIC MSI backend Michael Ellerman
2006-11-07 8:27 ` Segher Boessenkool
2006-11-07 8:42 ` Benjamin Herrenschmidt [this message]
2006-11-07 9:04 ` Segher Boessenkool
2006-11-07 9:16 ` Benjamin Herrenschmidt
2006-11-07 11:12 ` Segher Boessenkool
2006-11-07 7:21 ` [RFC/PATCH 7/7] Enable MSI on Powerpc Michael Ellerman
2006-11-07 7:41 ` [RFC/PATCH 0/7] Powerpc MSI Implementation Benjamin Herrenschmidt
2006-11-07 8:02 ` Greg KH
2006-11-08 5:18 ` Michael Ellerman
2006-11-08 10:26 ` Eric W. Biederman
2006-11-08 23:33 ` Michael Ellerman
2006-11-09 7:36 ` Segher Boessenkool
2006-11-13 6:05 ` Michael Ellerman
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=1162888963.28571.459.camel@localhost.localdomain \
--to=benh@kernel$(echo .)crashing.org \
--cc=davem@davemloft$(echo .)net \
--cc=ebiederm@xmission$(echo .)com \
--cc=greg@kroah$(echo .)com \
--cc=linux-pci@atrey$(echo .)karlin.mff.cuni.cz \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=segher@kernel$(echo .)crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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