All of lore.kernel.org
 help / color / mirror / Atom feed
From: suijingfeng <suijingfeng@loongson.cn>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Huacai Chen <chenhuacai@gmail.com>,
	Huacai Chen <chenhuacai@loongson.cn>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>
Subject: Re: [PATCH 5/5] PCI: Support ASpeed VGA cards behind a misbehaving bridge
Date: Tue, 18 May 2021 17:30:38 +0800	[thread overview]
Message-ID: <1ebc8c3d-f5dd-55fb-22a3-15fd0449d149@loongson.cn> (raw)
In-Reply-To: <20210518030917.GA72161@bjorn-Precision-5520>



On 2021/5/18 上午11:09, Bjorn Helgaas wrote:

> If VGA Enable is 0 and cannot be set to 1, the bridge should *never*
> forward VGA accesses to its secondary bus.  The generic VGA driver
> that uses the legacy [mem 0xa0000-0xbffff] range should not work with
> the VGA device at 05:00.0, and that device cannot participate in the
> VGA arbitration scheme, which relies on the VGA Enable bit.
> 
> If you have a driver for 05:00.0 that doesn't need the legacy memory
> range, it's possible that it may work.  But VGA arbitration will be
> broken, and if 05:00.0 needs to be initialized by an option ROM, that
> probably won't work either.

We are not using a "generic VGA driver", in user space, we are using the 
modesetting driver come with X server, and it seems work normally. The 
real problems is VGA arbitration will not set 05:00.0 as the default VGA 
which means that when X server read 
/sys/devices/pci0000:00/0000:00:0c.0/0000:04:00.0/0000:05:00.0/boot_vga 
will get a "0". This break Xorg auto-detection. We want the boot_vga 
sysfs file be "1".

> If the 04:00.0 bridge *always* forwards VGA accesses, even though its
> VGA Enable bit is always zero, then the bridge is broken.  In that
> case, the generic VGA driver should work with the 05:00.0 device, but
> VGA arbitration will be limited.  I'm not sure, but the arbiter
> *might* be able to use the VGA Enable bit in the 00:0c.0 bridge to
> control VGA access to 05:00.0.  You wouldn't be able to have more than
> one VGA device below 00:0c.0, and you may not be able have more than
> one in the entire system.

We have only one VGA device(05:00.0) below 00:0c.0, but we do able to 
have more than one in the entire system. We could even mount a AMDGPU
on this server. But in reality, there is a render only GPU and a 
self-designed display controller integrated in LS7A1000 bridge. Both the 
render only GPU and the display controller is PCI device, they are 
located at PCI root bus directly without a PCI-to-PCI bridge in the 
middle. The display controller is blocked by the firmware if ASPEED BMC 
card is present, it can't be accessed under linux kernel. Let me show 
you a updated version of the PCI topology of our server(machine):

        /sys/devices/pci0000:00
        |-- 0000:00:06.0
        |   | -- class (0x040000)
        |   | -- vendor (0x0014)
        |   | -- device (0x7a15)
        |   | -- drm
        |   | -- ...
        |-- 0000:00:0c.0
        |   |-- class (0x060400)
        |   |-- vendor (0x0014)
        |   |-- device (0x7a09)
        |   |-- ...
        |   |-- 0000:04:00.0
        |   |   | -- class (0x060400)
        |   |   | -- device (0x1150)
        |   |   | -- vendor (0x1a03)
        |   |   | -- revision (0x04)
        |   |   | -- ...
        |   |   | -- 0000:05:00.0
        |   |   |    | -- class  (0x030000)
        |   |   |    | -- device (0x2000)
        |   |   |    | -- vendor (0x1a03)
        |   |   |    | -- boot_vga
        |   |   |    | -- i2c-6
        |   |   |    | -- drm
        |   |   |    | -- graphics
        |   |   |    | -- ...
        |   `-- uevent
        `-- ...

Even through the render only GPU(00:06.0) is not a VGA device, it still 
can disturb X server choose a primary device to use. But the root cause 
is the kernel side does not set 05:00.0 as default VGA. In this case X 
server will fallback to the first device found to use. and 00:06.0 is 
always found before 05:00.0. If kernel side set 05:00.0 as default VGA,
all other problems is secondary.


  reply	other threads:[~2021-05-18  9:30 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14  8:00 [PATCH 0/5] PCI: Loongson-related pci quirks Huacai Chen
2021-05-14  8:00 ` [PATCH 1/5] PCI/portdrv: Don't disable pci device during shutdown Huacai Chen
2021-05-14 14:20   ` Krzysztof Wilczyński
2021-05-14 16:09   ` Bjorn Helgaas
2021-05-15  3:38     ` Huacai Chen
2021-05-14  8:00 ` [PATCH 2/5] PCI: Move loongson pci quirks to quirks.c Huacai Chen
2021-05-14  8:00 ` [PATCH 3/5] PCI: Improve the mrrs quirk for LS7A Huacai Chen
2021-05-14 14:03   ` Krzysztof Wilczyński
2021-05-14 15:39   ` Bjorn Helgaas
2021-05-15  3:49     ` Huacai Chen
2021-05-15  6:22       ` Jiaxun Yang
2021-05-14  8:00 ` [PATCH 4/5] PCI: Add quirk for multifunction devices of LS7A Huacai Chen
2021-05-14 13:22   ` Krzysztof Wilczyński
2021-05-14 14:52   ` Jiaxun Yang
2021-05-15  3:52     ` Huacai Chen
2021-05-18 13:59       ` Bjorn Helgaas
2021-05-19  2:26         ` Huacai Chen
2021-05-19  3:05           ` Jiaxun Yang
2021-05-14 15:51   ` Bjorn Helgaas
2021-05-15  3:56     ` Huacai Chen
2021-05-14  8:00 ` [PATCH 5/5] PCI: Support ASpeed VGA cards behind a misbehaving bridge Huacai Chen
2021-05-14 13:56   ` Krzysztof Wilczyński
2021-05-14 15:10   ` Bjorn Helgaas
2021-05-15  9:09     ` Huacai Chen
2021-05-17 12:53       ` Huacai Chen
2021-05-17 18:28         ` Bjorn Helgaas
2021-05-18  2:31           ` 隋景峰
2021-05-18  3:09             ` Bjorn Helgaas
2021-05-18  9:30               ` suijingfeng [this message]
2021-05-18 19:31                 ` Bjorn Helgaas
2021-05-18  7:13           ` Huacai Chen
2021-05-18 19:35             ` Bjorn Helgaas
2021-05-19  2:17               ` Huacai Chen
2021-05-19 19:33                 ` Bjorn Helgaas
2021-05-25 11:03                   ` Huacai Chen
2021-05-25 13:55                     ` Bjorn Helgaas
2021-05-26  2:33                       ` Huacai Chen
2021-05-26  2:33                         ` Huacai Chen
2021-05-26  3:00                         ` Dave Airlie
2021-05-26  3:00                           ` Dave Airlie
2021-05-26 18:29                           ` Bjorn Helgaas
2021-05-26 18:29                             ` Bjorn Helgaas

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=1ebc8c3d-f5dd-55fb-22a3-15fd0449d149@loongson.cn \
    --to=suijingfeng@loongson.cn \
    --cc=bhelgaas@google.com \
    --cc=chenhuacai@gmail.com \
    --cc=chenhuacai@loongson.cn \
    --cc=helgaas@kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-pci@vger.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 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.