From: Yijing Wang <wangyijing@huawei.com>
To: Brian Becker <brian.johnathan.b@gmail.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>,
Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>
Subject: Re: How to check for proper MSI support?
Date: Fri, 4 Jul 2014 15:01:21 +0800 [thread overview]
Message-ID: <53B65141.5080002@huawei.com> (raw)
In-Reply-To: <CALhae2iz0aC0qOJfg2utiwokO42b-Qn+qSUp2pWykZe0jpXp5Q@mail.gmail.com>
On 2014/7/4 14:26, Brian Becker wrote:
> I am booting a kernel with CONFIG_ACPI=n on a platform which does not
> support ACPI.
Hmmm, so my suggestion is
1. Add quirk to detect 430FX chipset, if detected, disable MSI in this platform.
or
2. Append boot argument pci=nomsi in OS command line when the OS running on your old platform.
Maybe other guys has some advices. :)
>
> On Fri, Jul 4, 2014 at 1:59 AM, Yijing Wang <wangyijing@huawei.com> wrote:
>>>>> There is a NVIDIA G96 GPU (which is PCIe only) hanging off of a PCIe
>>>>> <-> PCI bridge (all on one card), which is plugged into a motherboard
>>>>> with the 430FX chipset (PCI 2.0 supported).
>>>>>
>>>>> The GPU PCI device, of course, has full support for MSI. However my
>>>>> understanding is that MSI won't actually work here. This is confirmed
>>>>> by the fact that if we let nouveau enable MSI, the device doesn't work
>>>>> (presumably due to lack of interrupt delivery, although I admit to not
>>>>> having debugged it that far). How do I, as a nouveau driver developer,
>>>>> know not to call pci_enable_msi? Or alternatively how can
>>>>> pci_enable_msi be taught not to succeed in this case?
>>>>
>>>> You can set bus_flags or global pci_msi_enable flag by add quirk function.
>>>> You can refer to examples in drivers/pci/quirk.c
>>>>
>>>> Linux support some broken chipsets or devices to disable msi during device initialization by add quirk.
>>>
>>> So let me get this straight -- you're suggesting I add a quirk for
>>> every PCI chipset that doesn't support MSI? There are probably
>>> hundreds of these... anything made before 1999 or so, and probably a
>>> bunch since then too. There _has_ to be a way to do this generically.
>>> Is the PCI spec version anywhere in the root hub?
>>
>> There is no register to identify PCI spec version in PCI config space registers.
>> If your platform boot up with ACPI, you can setting ACPI FADT boot flag to disable MSI,
>> you can refer to this in ACPI 5.2.9.3 chapter "Fixed ACPI Description Table Boot Architecture Flags"
>>
>>
>>>
>>> Perhaps we can check if every bridge on the way to the CPU has the MSI
>>> capability (including the root hub)? (And naturally _that_ won't
>>> work... on my sandybridge laptop, the host bridge doesn't have the MSI
>>> cap but the system most definitely supports MSI.)
>>>
>>> Adding Bjorn... perhaps you know? Some of the info has been stripped
>>> out by now, you can see the full lspci -vvvxxx at
>>> http://marc.info/?l=linux-pci&m=140443441730503&w=2
>>>
>>> -ilia
>>>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>
> .
>
--
Thanks!
Yijing
next prev parent reply other threads:[~2014-07-04 7:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 3:20 How to check for proper MSI support? Ilia Mirkin
2014-07-03 5:58 ` Yijing Wang
2014-07-04 0:40 ` Brian Becker
[not found] ` <CALhae2jRz8hL0bwySAbP7r+vJGOG5aif4GA_Yjp0inGAwz5JEA@mail.gmail.com>
2014-07-04 2:35 ` Yijing Wang
2014-07-04 2:43 ` Ilia Mirkin
2014-07-04 3:09 ` Yijing Wang
2014-07-04 3:30 ` Ilia Mirkin
2014-07-04 3:56 ` Yijing Wang
2014-07-04 4:32 ` Ilia Mirkin
2014-07-04 5:59 ` Yijing Wang
2014-07-04 6:26 ` Brian Becker
2014-07-04 7:01 ` Yijing Wang [this message]
2014-07-05 22:21 ` Bjorn Helgaas
2014-07-05 23:04 ` Brian Becker
2014-07-04 2:45 ` Brian Becker
2014-07-04 3:13 ` Yijing Wang
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=53B65141.5080002@huawei.com \
--to=wangyijing@huawei.com \
--cc=bhelgaas@google.com \
--cc=brian.johnathan.b@gmail.com \
--cc=imirkin@alum.mit.edu \
--cc=linux-pci@vger.kernel.org \
--cc=nouveau@lists.freedesktop.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).