From: Bjorn Helgaas <helgaas@kernel.org>
To: Dave Airlie <airlied@gmail.com>
Cc: Huacai Chen <chenhuacai@kernel.org>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci <linux-pci@vger.kernel.org>,
Jingfeng Sui <suijingfeng@loongson.cn>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Huacai Chen <chenhuacai@loongson.cn>
Subject: Re: [PATCH 5/5] PCI: Support ASpeed VGA cards behind a misbehaving bridge
Date: Wed, 26 May 2021 13:29:40 -0500 [thread overview]
Message-ID: <20210526182940.GA1303599@bjorn-Precision-5520> (raw)
In-Reply-To: <CAPM=9tx0kr7xdA8eB2+u6Xg0C7FSMbZEKGVKOTZEkdA7Kay42A@mail.gmail.com>
On Wed, May 26, 2021 at 01:00:33PM +1000, Dave Airlie wrote:
> > > > > I think I would see if it's possible to call
> > > > > vga_arb_select_default_device() from vga_arbiter_add_pci_device()
> > > > > instead of from vga_arb_device_init().
> > > > >
> > > > > I would also (as a separate patch) try to get rid of this loop in
> > > > > vga_arb_device_init():
> > > > >
> > > > > list_for_each_entry(vgadev, &vga_list, list) {
> > > > > struct device *dev = &vgadev->pdev->dev;
> > > > >
> > > > > if (vgadev->bridge_has_one_vga)
> > > > > vgaarb_info(dev, "bridge control possible\n");
> > > > > else
> > > > > vgaarb_info(dev, "no bridge control possible\n");
> > > > > }
> > > > >
> > > > > and do the vgaarb_info() in vga_arbiter_check_bridge_sharing(), where
> > > > > the loop would not be needed.
> > > >
> > > > Any updates?
> > >
> > > Are you waiting for me to do something else?
> > >
> > > I suggested an approach above, but I don't have time to actually do
> > > the work for you.
> >
> > Yes, I am really waiting... but I am also investigating history
> > and thinking.
Well, don't wait for me because this work is not on my to-do list :)
> > If I haven't missed something (correct me if I'm wrong). For the
> > original HiSilicon problem, the first attempt is to modify
> > vga_arbiter_add_pci_device() and remove the VGA_RSRC_LEGACY_MASK
> > check. But vga_arbiter_add_pci_device() is called for each PCI device,
> > so removing that check will cause the first VGA device to be the
> > default VGA device. This breaks some x86 platforms, so after that you
> > don't touch vga_arbiter_add_pci_device(), but add
> > vga_arb_select_default_device() in vga_arb_device_init().
> >
> > If the above history is correct, then we cannot add
> > vga_arb_select_default_device() in vga_arbiter_add_pci_device()
> > directly. So it seems we can only add vga_arb_select_default_device()
> > in pci_notify(). And if we don't care about hotplug, we can simply use
> > subsys_initcall_sync() to wrap vga_arb_device_init().
> >
> > And DRM developers, please let me know what do you think about?
>
> I'm not 100% following what is going on here.
>
> Do you need call vga_arb_select_default_device after hotplug for some
> reason, or it this just a race with subsys_init?
>
> I think just adding subsys_initcall_sync should be fine
Doing subsys_initcall_sync(vga_arb_device_init) is probably "OK". I
don't think it's *great* because initcalls don't make dependencies
explicit so it won't be obvious *why* it's subsys_initcall_sync, and
it feels a little like a band-aid.
> I don't see why you'd want to care about making a hotplug VGA device
> the default at this point.
I don't think hotplug per se is relevant for this ASpeed case.
But I think the current design is slightly broken in that we set up
the machinery to call vga_arbiter_add_pci_device() for hot-added
devices, but a hot-added device can never be set as the default VGA
device.
Imagine a system with a single VGA device. If that device is plugged
in before boot, it becomes the default VGA device. If it is hot-added
after boot, it does not. That inconsistency feels wrong to me.
If it were possible to set the default VGA device in
vga_arbiter_add_pci_device(), it would fix that inconsistency and
solve the ASpeed case. But maybe that's not practical.
Bjorn
prev parent reply other threads:[~2021-05-26 18:29 UTC|newest]
Thread overview: 39+ 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
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 3:00 ` Dave Airlie
2021-05-26 18:29 ` Bjorn Helgaas [this message]
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=20210526182940.GA1303599@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=bhelgaas@google.com \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-pci@vger.kernel.org \
--cc=suijingfeng@loongson.cn \
/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