From: Yijing Wang <wangyijing@huawei.com>
To: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Brian Becker <brian.johnathan.b@gmail.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 11:56:09 +0800 [thread overview]
Message-ID: <53B625D9.9080500@huawei.com> (raw)
In-Reply-To: <CAKb7UvjFuu4Hm1pfmY-NMFORfv-+fx4oYeJicRoE8UTL_4Wp4A@mail.gmail.com>
On 2014/7/4 11:30, Ilia Mirkin wrote:
> On Thu, Jul 3, 2014 at 11:09 PM, Yijing Wang <wangyijing@huawei.com> wrote:
>> On 2014/7/4 10:43, Ilia Mirkin wrote:
>>> On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang <wangyijing@huawei.com> wrote:
>>>> Hi Brian,
>>>> From your 01:00.0 VGA compatible controller PCI config register, it supports 1 MSI vector, so I think this
>>>> card has no problem. But you didn't answer what's the pci_enable_msi() return during it enable MSI fail.
>>>>
>>>> You can check PCI bus whether support MSI like:
>>>>
>>>> cat /sys/bus/pci/devices/00:0e.0/msi_bus
>>>>
>>>> Other, do you call pci_enable_device() before pci_enable_msi() ?
>>>
>>> Yes, the device is enabled. nouveau does generally work for most
>>> people :) And it works fine here if MSI is forced off.
>>>
>>> The problem here is that pci_enable_msi() succeeds, but it probably
>>
>> It's some strange, pci_enable_msi() succeeds, but there is nothing in MSI address and data register
>>
>> Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
>> Address: 0000000000000000 Data: 0000
>> Because the address and data is invalid, so MSI can not work.
>>
>> Because you said pci_enable_msi() return 0 which indicates success, so I guess the device
>> current power state is not D0, because checking code in __write_msi_msi.
>>
>> void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
>> {
>> if (entry->dev->current_state != PCI_D0) {
>> /* Don't touch the hardware now */
>> } else if (entry->msi_attrib.is_msix) {
>> void __iomem *base;
>> base = entry->mask_base +
>> entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
>>
>> writel(msg->address_lo, base + PCI_MSIX_ENTRY_LOWER_ADDR);
>> writel(msg->address_hi, base + PCI_MSIX_ENTRY_UPPER_ADDR);
>> writel(msg->data, base + PCI_MSIX_ENTRY_DATA);
>> ......
>>
>>> shouldn't. I don't know all the details about MSI, but doesn't the CPU
>>> or (L)APIC have to support it? In this case, it's a P200MMX on a 430FX
>>> chipset board. Both quite ancient...
>>
>> MSI in x86 always send to specific interrupt address(0xfeexxxx), most x86 CPU
>> should support MSI, but I am not sure, I don't know hardware much.
>
> To put things in perspective, P200MMX was released in early 1997. It
> looks like the PCI 2.2 spec, which defines MSI, was released in late
> 1998. The 430FX chipset only supports PCI 2.0.
Maybe you are right, the chipset can not support MSI...
But why after your call pci_enable_msi(), the MSI address and data register is nothing initialized.
>
>>
>>>
>>> So given that the PCI device itself supports MSI, how do we tell that
>>> it shouldn't actually get turned on?
>>
>> Generally, some message in dmesg like:
>> [ 17.322311] ahci 0000:00:1f.2: irq 119 for MSI/MSI-X
>> [ 17.322319] ahci 0000:00:1f.2: irq 120 for MSI/MSI-X
>> [ 17.322326] ahci 0000:00:1f.2: irq 121 for MSI/MSI-X
>> [ 17.322333] ahci 0000:00:1f.2: irq 122 for MSI/MSI-X
>> [ 17.322339] ahci 0000:00:1f.2: irq 123 for MSI/MSI-X
>>
>> Also you can check /proc/interrupts I think.
>
> I must not have made my question clear. Let me try again:
>
> 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.
>
> Thanks,
>
> -ilia
>
> .
>
--
Thanks!
Yijing
next prev parent reply other threads:[~2014-07-04 3:56 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 [this message]
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
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=53B625D9.9080500@huawei.com \
--to=wangyijing@huawei.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).