From: Sui Jingfeng <suijingfeng@loongson.cn>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH pci-next v6 1/2] PCI/VGA: Make the vga_is_firmware_default() less arch-dependent
Date: Wed, 4 Oct 2023 21:38:01 +0800 [thread overview]
Message-ID: <59d609eb-e52c-7e81-073c-3e2f61e04583@loongson.cn> (raw)
In-Reply-To: <20231003155420.GA674372@bhelgaas>
Hi,
On 2023/10/3 23:54, Bjorn Helgaas wrote:
> PCI/VGA: Match firmware framebuffer before BAR reassignment
>
> vga_is_firmware_default() decides a device is the firmware default VGA
> device if it has a BAR that contains the framebuffer described by
> screen_info.
>
> Previously this was unreliable because the screen_info framebuffer address
> comes from firmware, and the Linux PCI core may reassign device BARs before
> vga_is_firmware_default() runs. This reassignment means the BAR may not
> match the screen_info values, but we still want to select the device as the
> firmware default.
>
> Make vga_is_firmware_default() more reliable by running it as a quirk so it
> happens before any BAR reassignment.
On a specific architecture, the kernel have its own copy of screen_info.
We may choose to rely on the global screen_info, but I don't hope vgaarb
should completely depend on the firmware which without any flexibility.
After all, there are always have the old BIOS with the newer Kernel or
new graphics card combinations. That is to say that the BIOS(firmware)
is released first, then the new graphics comes after. So, we can't rely
on the BIOS know all of the graphics card in the world at the time of
BIOS release. If a BIOS don't know a specific video card, then then BIOS
is unlikely initialize a firmware framebuffer(UEFI GOP or something like
that) on it successfully.
I hope vgaarb can work without fully rely on the firmware, don't mention
the word 'firmware' as less as possible. Because, we can even modify the
kernel's screen_info by hardcode or fill it by parsing DT. We are only
rely on the global screen_info here. while how does the global screen_info
being filled is a kernel side and arch specific thing. The global screen_info
may rely on the BIOS, but this is a thing of the kernel side, vgaarb belong
to drivers directory.
Beside, the word 'firmware' have multiple meanings, for the patch at here,
it refer to the UEFI or uboot or something similar. But for the GPU domain,
it may refer to any binary executable on the macro-controller embedded in
the GPU IP. So I think the names 'is_firmware_default' and 'vga_is_firmware_default'
are putting *too much emphasis* the firmware. So I want to remove it.
vgaarb already have been exposed to userspace via sysfs interface (/sys/class/misc/vga_arbiter).
So the original spirit is actually allow user to tune or control. I hope vgaarb become more
standalone and more flexible so that there are some ways to rescue even in the worse case.
If someone (who have a better background or have better understanding toward a specific case only)
don't see this as a problem, then it is not my problem. I'm not good at debating with English.
next prev parent reply other threads:[~2023-10-04 13:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-02 12:05 [PATCH pci-next v6 0/2] PCI/VGA: Make the vga_is_firmware_default() less arch-dependent Sui Jingfeng
2023-10-02 12:05 ` [PATCH pci-next v6 1/2] " Sui Jingfeng
2023-10-03 15:54 ` Bjorn Helgaas
2023-10-04 12:55 ` Sui Jingfeng
2023-10-04 14:01 ` Bjorn Helgaas
2023-10-04 13:38 ` Sui Jingfeng [this message]
2023-10-02 12:05 ` [PATCH pci-next v6 2/2] PCI/VGA: Remove vga_is_firmware_default() function Sui Jingfeng
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=59d609eb-e52c-7e81-073c-3e2f61e04583@loongson.cn \
--to=suijingfeng@loongson.cn \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.