On Fri, Jun 09, 2023 at 10:27:39AM +0800, Sui Jingfeng wrote:
On 2023/6/9 03:19, Bjorn Helgaas wrote:The way we usually handle this is to include the new callback in the
On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:This is chicken and egg question.
From: Sui Jingfeng <suijingfeng@xxxxxxxxxxx>s/bar/BAR/ (several)
The vga_is_firmware_default() function is arch-dependent, which doesn't
sound right. At least, it also works on the Mips and LoongArch platforms.
Tested with the drm/amdgpu and drm/radeon drivers. However, it's difficult
to enumerate all arch-driver combinations. I'm wrong if there is only one
exception.
With the observation that device drivers typically have better knowledge
about which PCI bar contains the firmware framebuffer, which could avoid
the need to iterate all of the PCI BARs.
But as a PCI function at pci/vgaarb.c, vga_is_firmware_default() is
probably not suitable to make such an optimization for a specific device.
There are PCI display controllers that don't have a dedicated VRAM bar,
this function will lose its effectiveness in such a case. Luckily, the
device driver can provide an accurate workaround.
Therefore, this patch introduces a callback that allows the device driver
to tell the VGAARB if the device is the default boot device. This patch
only intends to introduce the mechanism, while the implementation is left
to the device driver authors. Also honor the comment: "Clients have two
callback mechanisms they can use"
Nothing here uses the callback. I don't want to merge this until we
have a user.
If you could help get this merge first, I will show you the first user.
I'm not sure why the device driver should know whether its device isIt's not that the device driver should know,
the default boot device.
but it's about that the device driver has the right to override.
Device driver may have better approach to identify the default boot
device.
same series as the first user of it. That has two benefits:
(1) everybody can review the whole picture and possibly suggest
different approaches, and (2) when we merge the infrastructure,
we also merge a user of it at the same time, so the whole thing can be
tested and we don't end up with unused code.
Bjorn