All of lore.kernel.org
 help / color / mirror / Atom feed
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


WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
Cc: linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Brian Becker
	<brian.johnathan.b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 2014/7/4 11:30, Ilia Mirkin wrote:
> On Thu, Jul 3, 2014 at 11:09 PM, Yijing Wang <wangyijing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
>> On 2014/7/4 10:43, Ilia Mirkin wrote:
>>> On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang <wangyijing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> 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

  reply	other threads:[~2014-07-04  3:56 UTC|newest]

Thread overview: 27+ 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  3:20 ` Ilia Mirkin
2014-07-03  5:58 ` Yijing Wang
2014-07-03  5:58   ` Yijing Wang
     [not found]   ` <53B4F0F7.9020403-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2014-07-04  0:35     ` Brian Becker
2014-07-04  2:35       ` Yijing Wang
2014-07-04  2:35         ` Yijing Wang
2014-07-04  2:43         ` Ilia Mirkin
2014-07-04  2:43           ` Ilia Mirkin
2014-07-04  3:09           ` Yijing Wang
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  3:56                 ` Yijing Wang
2014-07-04  4:32                 ` Ilia Mirkin
2014-07-04  5:59                   ` Yijing Wang
2014-07-04  5:59                     ` Yijing Wang
2014-07-04  6:26                     ` Brian Becker
2014-07-04  7:01                       ` Yijing Wang
2014-07-04  7:01                         ` Yijing Wang
2014-07-05 22:21                   ` Bjorn Helgaas
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
2014-07-04  3:13             ` Yijing Wang
2014-07-04  0:40   ` Brian Becker

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 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.