Messages in this thread | | | Date | Thu, 20 Jul 2023 06:32:19 +0800 | Subject | Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection | From | suijingfeng <> |
| |
Hi,
On 2023/7/20 03:32, Bjorn Helgaas wrote: > [+cc linux-pci (please cc in the future since the bulk of this patch > is in drivers/pci/)] > > On Wed, Jul 12, 2023 at 12:43:05AM +0800, Sui Jingfeng wrote: >> From: Sui Jingfeng <suijingfeng@loongson.cn> >> >> Currently, the strategy of selecting the default boot on a multiple video >> card coexistence system is not perfect. Potential problems are: >> >> 1) This function is a no-op on non-x86 architectures. > Which function in particular is a no-op for non-x86?
I refer to the vga_is_firmware_default() function,
I will improve the commit message at the next version. (To make it more human readable).
Thanks you point it out.
>> 2) It does not take the PCI Bar may get relocated into consideration. >> 3) It is not effective for the PCI device without a dedicated VRAM Bar. >> 4) It is device-agnostic, thus it has to waste the effort to iterate all >> of the PCI Bar to find the VRAM aperture. >> 5) It has invented lots of methods to determine which one is the default >> boot device, but this is still a policy because it doesn't give the >> user a choice to override. > I don't think we need a list of *potential* problems. We need an > example of the specific problem this will solve, i.e., what currently > does not work?
1) The selection of primary GPU on Non-x86 platform. (Arm64, risc-v, powerpc etc)
Mostly server platforms have equipped with aspeed bmc, and such hardware platforms have a lot PCIe slot.
So I think, aspeed bmc V.S (P.K) radeon(or amdgpu) is very common.
2) The ability to pass the control back to the end user.
Convert the *device driven* to the "driver driven" or "human driven".
Currently, it is the machine making the decision.
Emm, I probably will be able to give some examples at the next version.
> The drm/ast and maybe drm/loongson patches are the only ones that use > the new callback, so I assume there are real problems with those > drivers. > > CONFIG_DRM_AST is a tristate. We're talking about identifying the > boot-time console device. So if CONFIG_DRM_AST=m, I guess we don't > get the benefit of the new callback unless the module gets loaded? > Since, this patch set is mostly for the user of X server.
It is actually okey if CONFIG_DRM_AST=m. (it will be works no matter CONFIG_DRM_AST=m or CONFIG_DRM_AST=y)
As the device and the driver bound at a latter time.
So we are lucky, we need this behavior to implement the override.
| |