Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
On Mon, Jul 24, 2023 at 08:16:18PM +0800, suijingfeng wrote: > On 2023/7/20 03:32, Bjorn Helgaas wrote: > > > 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? > > > This version do allow the arbitration service works on non-x86 arch, > which also allow me remove a arch-specific workaround. > I will give more detail at the next version. Yes. This part I think we want. > But I want to provide one more drawback of vgaarb here: > > (6) It does not works for non VGA-compatible PCI(e) display controllers. > > Because, currently, vgaarb deal with PCI VGA compatible devices only. > > See another my patch set [1] for more elaborate discussion. > > It also ignore PCI_CLASS_NOT_DEFINED_VGA as Maciej puts it[2]. > > While my approach do not required the display controller to be > VGA-compatible to enjoy the arbitration service. I think vgaarb is really only for dealing with the problem of the legacy VGA address space routing. For example, there may be VGA devices that require the [pci 0xa-0xb] range but they don't describe that via a BAR. There may also be VGA option ROMs that depend on that range so they can initialize the device. The [pci 0xa-0xb] range can only be routed to one device at a time, and vgaarb is what takes care of that by manipulating the VGA Enable bits in bridges. I don't think we should extend vgaarb to deal with non-VGA GPUs in general, i.e., I don't think it should be concerned with devices and option ROMs that do not require the [pci 0xa-0xb] range. I think a strict reading of the PCI Class Code spec would be that only devices with Programming Interface b can depend on that legacy range. If that's what vgaarb currently enforces, great. If it currently deals with more than just b devices, and there's some value in restricting it to only b, we could try that, but I would suggest doing that in a tiny patch all by itself. Then if we trip over a problem, it's easy to bisect and revert it. > [1] https://patchwork.freedesktop.org/patch/546690/?series=120548=1 > > [2] https://lkml.org/lkml/2023/6/18/315 >
Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
Hi,
Thanks for you noticed my change.
On 2023/7/20 03:32, Bjorn Helgaas wrote:
@@ -1509,13 +1543,24 @@ static int pci_notify(struct notifier_block *nb,
unsigned long action,
* cases of hotplugable vga cards.
*/
- if (action == BUS_NOTIFY_ADD_DEVICE)
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
notify = vga_arbiter_add_pci_device(pdev);
- else if (action == BUS_NOTIFY_DEL_DEVICE)
+ if (notify)
+ vga_arbiter_notify_clients();
+ break;
+ case BUS_NOTIFY_DEL_DEVICE:
notify = vga_arbiter_del_pci_device(pdev);
+ if (notify)
+ vga_arbiter_notify_clients();
+ break;
+ case BUS_NOTIFY_BOUND_DRIVER:
+ vga_arbiter_do_arbitration(pdev);
+ break;
+ default:
+ break;
+ }
Changing from if/else to switch makes the patch bigger than necessary
for no real benefit and obscures what is really changing.
Actually, the logic become more clear after this patch applied.
```
switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
notify = vga_arbiter_add_pci_device(pdev);
if (notify)
vga_arbiter_notify_clients();
break;
case BUS_NOTIFY_DEL_DEVICE:
notify = vga_arbiter_del_pci_device(pdev);
if (notify)
vga_arbiter_notify_clients();
break;
case BUS_NOTIFY_BOUND_DRIVER:
vga_arbiter_do_arbitration(pdev);
break;
default:
break;
}
```
Because we only need call vga_arbiter_notify_clients() when action ==
BUS_NOTIFY_ADD_DEVICE or action == BUS_NOTIFY_DEL_DEVICE,
But *NOT* when the action equals to BUS_NOTIFY_BOUND_DRIVER.
Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
Hi, On 2023/7/20 03:32, Bjorn Helgaas wrote: 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? This version do allow the arbitration service works on non-x86 arch, which also allow me remove a arch-specific workaround. I will give more detail at the next version. But I want to provide one more drawback of vgaarb here: (6) It does not works for non VGA-compatible PCI(e) display controllers. Because, currently, vgaarb deal with PCI VGA compatible devices only. See another my patch set [1] for more elaborate discussion. It also ignore PCI_CLASS_NOT_DEFINED_VGA as Maciej puts it[2]. While my approach do not required the display controller to be VGA-compatible to enjoy the arbitration service. What do you think then? [1] https://patchwork.freedesktop.org/patch/546690/?series=120548=1 [2] https://lkml.org/lkml/2023/6/18/315
Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
Hi, I was too hurry reply to you. I'm may miss the point for part of your reviews, Sorry. On 2023/7/20 03:32, Bjorn Helgaas wrote: CONFIG_DRM_AST is a tristate. We're talking about identifying the boot-time console device. Yes, my patch will only works *after* the module gets loaded successfully. But generally, vgaarb will select a default boot device before my patch taking into effect. I means that vgaarb will select a default boot device by calling vga_arbiter_add_pci_device() function. In practice, I still not notice any obvious problems. I'm lack the knowledge about the boot-time console, what is the potential problems with such a condition? So if CONFIG_DRM_AST=m, I guess we don't get the benefit of the new callback unless the module gets loaded? Yes, my approach will not works until the device driver kernel module gets loaded successfully. So what's the problem with such a situation, do you see something weird ?
Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
On 2023/7/20 03:32, Bjorn Helgaas wrote: but I think it's just confusing to mention this in the commit log, so I would just remove it. Ok, will be done at the next version.
Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
On 2023/7/20 06:32, suijingfeng wrote: it will be works no matter CONFIG_DRM_AST=m or CONFIG_DRM_AST=y It will be works regardless of CONFIG_DRM_AST=m or CONFIG_DRM_AST=y. When vgaarb call to the device driver, device driver already loaded successfully. and the PCI(e) device emulation already finished. So the last change the vgaarb gave us to override is actually happen very late. But it will be happen as long as the device driver get loaded successfully.
Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
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 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.
Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
[+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
>
> 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?
> 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?
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?
> Also honor the comment: "Clients have *TWO* callback mechanisms they
> can use"
This refers to the existing vga_client_register() function comment:
* vga_client_register - register or unregister a VGA arbitration client
* @pdev: pci device of the VGA client
* @set_decode: vga decode change callback
*
* Clients have two callback mechanisms they can use.
*
* @set_decode callback: If a client can disable its GPU VGA resource, it
* will get a callback from this to set the encode/decode state.
and the fact that struct vga_device currently only contains *one*
callback function pointer:
unsigned int (*set_decode)(struct pci_dev *pdev, bool decode);
Adding the .is_primary_gpu() callback does mean there will now be two
callbacks, as the comment says, but I think it's just confusing to
mention this in the commit log, so I would just remove it.
> @@ -1509,13 +1543,24 @@ static int pci_notify(struct notifier_block *nb,
> unsigned long action,
>* cases of hotplugable vga cards.
>*/
>
> - if (action == BUS_NOTIFY_ADD_DEVICE)
> + switch (action) {
> + case BUS_NOTIFY_ADD_DEVICE:
> notify = vga_arbiter_add_pci_device(pdev);
> - else if (action == BUS_NOTIFY_DEL_DEVICE)
> + if (notify)
> + vga_arbiter_notify_clients();
> + break;
> + case BUS_NOTIFY_DEL_DEVICE:
> notify = vga_arbiter_del_pci_device(pdev);
> + if (notify)
> + vga_arbiter_notify_clients();
> + break;
> + case BUS_NOTIFY_BOUND_DRIVER:
> + vga_arbiter_do_arbitration(pdev);
> + break;
> + default:
> + break;
> + }
Changing from if/else to switch makes the patch bigger than necessary
for no real benefit and obscures what is really changing.
Bjorn
Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
Hi,
Fixes: f6b1772b2555 ('vgaarb: remove the unused irq_set_state argument
to vga_client_register')
Because after applied that patch, there have only one callback mechanism
we can use, not two anymore.
On 2023/7/12 00:43, Sui Jingfeng wrote:
From: Sui Jingfeng
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.
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.
With the observation that device drivers may have better knowledge about
which PCI bar contains the firmware FB. This patch tries to solve the above
problems by introducing a function callback to the vga_client_register()
function interface. DRM device drivers for the PCI device could provide
a xx_vga_is_primary_gpu() function callback during the driver loading time.
Once the driver binds the device successfully, VRAARB will call back to
the driver. This gives the device drivers a chance to provide accurate
boot device identification. Which in turn unlock the abitration service
to non-x86 architectures. A device driver can also just pass a NULL pointer
to keep the original behavior.
This patch is intended to introducing the mechanism only, the specific
implementation is left to the authors of various device driver. Also honor
the comment: "Clients have *TWO* callback mechanisms they can use"
Cc: Alex Deucher
Cc: Christian Konig
Cc: Pan Xinhui
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Bjorn Helgaas
Cc: Alex Williamson
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Hawking Zhang
Cc: Mario Limonciello
Cc: Lijo Lazar
Cc: YiPeng Chai
Cc: Bokun Zhang
Cc: Likun Gao
Cc: Ville Syrjala
Cc: Jason Gunthorpe
CC: Kevin Tian
Cc: Cornelia Huck
Cc: Yishai Hadas
Cc: Abhishek Sahu
Cc: Yi Liu
Acked-by: Jani Nikula # i915
Reviewed-by: Lyude Paul # nouveau
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 3 +-
drivers/gpu/drm/loongson/lsdc_drv.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_vga.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
drivers/pci/vgaarb.c | 55 --
drivers/vfio/pci/vfio_pci_core.c | 2 +-
include/linux/vgaarb.h | 8 ++--
8 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a92c6189b4b6..d98f0801ac77 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4103,7 +4103,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* this will fail for cards that aren't VGA class devices, just
* ignore it */
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
- vga_client_register(adev->pdev, amdgpu_device_vga_set_decode);
+ vga_client_register(adev->pdev, amdgpu_device_vga_set_decode,
NULL);
px = amdgpu_device_supports_px(ddev);
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c
index 286a0bdd28c6..98d7d4dffe9f 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -115,7 +115,6 @@ intel_vga_set_decode(struct pci_dev *pdev, bool
enable_decode)
int intel_vga_register(struct drm_i915_private *i915)
{
-
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
int ret;
@@ -127,7 +126,7 @@ int intel_vga_register(struct drm_i915_private *i915)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- ret = vga_client_register(pdev, intel_vga_set_decode);
+ ret = vga_client_register(pdev, intel_vga_set_decode, NULL);
if (ret && ret != -ENODEV)
return ret;
diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c b/drivers/gpu/drm/loongson/lsdc_drv.c
index 188ec82afcfb..d10a28c2c494 100644
--- a/drivers/gpu/drm/loongson/lsdc_drv.c
+++ b/drivers/gpu/drm/loongson/lsdc_drv.c
@@ -289,7 +289,7 @@ static int lsdc_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
pci_set_drvdata(pdev, ddev);
- vga_client_register(pdev, lsdc_vga_set_decode);
+ vga_client_register(pdev, lsdc_vga_set_decode, NULL);
[PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
From: Sui Jingfeng
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.
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.
With the observation that device drivers may have better knowledge about
which PCI bar contains the firmware FB. This patch tries to solve the above
problems by introducing a function callback to the vga_client_register()
function interface. DRM device drivers for the PCI device could provide
a xx_vga_is_primary_gpu() function callback during the driver loading time.
Once the driver binds the device successfully, VRAARB will call back to
the driver. This gives the device drivers a chance to provide accurate
boot device identification. Which in turn unlock the abitration service
to non-x86 architectures. A device driver can also just pass a NULL pointer
to keep the original behavior.
This patch is intended to introducing the mechanism only, the specific
implementation is left to the authors of various device driver. Also honor
the comment: "Clients have *TWO* callback mechanisms they can use"
Cc: Alex Deucher
Cc: Christian Konig
Cc: Pan Xinhui
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Bjorn Helgaas
Cc: Alex Williamson
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Hawking Zhang
Cc: Mario Limonciello
Cc: Lijo Lazar
Cc: YiPeng Chai
Cc: Bokun Zhang
Cc: Likun Gao
Cc: Ville Syrjala
Cc: Jason Gunthorpe
CC: Kevin Tian
Cc: Cornelia Huck
Cc: Yishai Hadas
Cc: Abhishek Sahu
Cc: Yi Liu
Acked-by: Jani Nikula # i915
Reviewed-by: Lyude Paul # nouveau
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 3 +-
drivers/gpu/drm/loongson/lsdc_drv.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_vga.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
drivers/pci/vgaarb.c | 55 --
drivers/vfio/pci/vfio_pci_core.c | 2 +-
include/linux/vgaarb.h | 8 ++--
8 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a92c6189b4b6..d98f0801ac77 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4103,7 +4103,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* this will fail for cards that aren't VGA class devices, just
* ignore it */
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
- vga_client_register(adev->pdev, amdgpu_device_vga_set_decode);
+ vga_client_register(adev->pdev, amdgpu_device_vga_set_decode,
NULL);
px = amdgpu_device_supports_px(ddev);
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c
b/drivers/gpu/drm/i915/display/intel_vga.c
index 286a0bdd28c6..98d7d4dffe9f 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -115,7 +115,6 @@ intel_vga_set_decode(struct pci_dev *pdev, bool
enable_decode)
int intel_vga_register(struct drm_i915_private *i915)
{
-
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
int ret;
@@ -127,7 +126,7 @@ int intel_vga_register(struct drm_i915_private *i915)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- ret = vga_client_register(pdev, intel_vga_set_decode);
+ ret = vga_client_register(pdev, intel_vga_set_decode, NULL);
if (ret && ret != -ENODEV)
return ret;
diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c
b/drivers/gpu/drm/loongson/lsdc_drv.c
index 188ec82afcfb..d10a28c2c494 100644
--- a/drivers/gpu/drm/loongson/lsdc_drv.c
+++ b/drivers/gpu/drm/loongson/lsdc_drv.c
@@ -289,7 +289,7 @@ static int lsdc_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
pci_set_drvdata(pdev, ddev);
- vga_client_register(pdev, lsdc_vga_set_decode);
+ vga_client_register(pdev, lsdc_vga_set_decode, NULL);
drm_kms_helper_poll_init(ddev);
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index f8bf0ec26844..162b4f4676c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -92,7 +92,7 @@
[PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
From: Sui Jingfeng
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.
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.
With the observation that device drivers may have better knowledge about
which PCI bar contains the firmware FB. This patch tries to solve the above
problems by introducing a function callback to the vga_client_register()
function interface. DRM device drivers for the PCI device could provide
a xx_vga_is_primary_gpu() function callback during the driver loading time.
Once the driver binds the device successfully, VRAARB will call back to
the driver. This gives the device drivers a chance to provide accurate
boot device identification. Which in turn unlock the abitration service
to non-x86 architectures. A device driver can also just pass a NULL pointer
to keep the original behavior.
This patch is intended to introducing the mechanism only, the specific
implementation is left to the authors of various device driver. Also honor
the comment: "Clients have *TWO* callback mechanisms they can use"
Cc: Alex Deucher
Cc: Christian Konig
Cc: Pan Xinhui
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Bjorn Helgaas
Cc: Alex Williamson
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Hawking Zhang
Cc: Mario Limonciello
Cc: Lijo Lazar
Cc: YiPeng Chai
Cc: Bokun Zhang
Cc: Likun Gao
Cc: Ville Syrjala
Cc: Jason Gunthorpe
CC: Kevin Tian
Cc: Cornelia Huck
Cc: Yishai Hadas
Cc: Abhishek Sahu
Cc: Yi Liu
Acked-by: Jani Nikula # i915
Reviewed-by: Lyude Paul # nouveau
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 3 +-
drivers/gpu/drm/loongson/lsdc_drv.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_vga.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
drivers/pci/vgaarb.c | 55 --
drivers/vfio/pci/vfio_pci_core.c | 2 +-
include/linux/vgaarb.h | 8 ++--
8 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a92c6189b4b6..d98f0801ac77 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4103,7 +4103,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* this will fail for cards that aren't VGA class devices, just
* ignore it */
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
- vga_client_register(adev->pdev, amdgpu_device_vga_set_decode);
+ vga_client_register(adev->pdev, amdgpu_device_vga_set_decode,
NULL);
px = amdgpu_device_supports_px(ddev);
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c
b/drivers/gpu/drm/i915/display/intel_vga.c
index 286a0bdd28c6..98d7d4dffe9f 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -115,7 +115,6 @@ intel_vga_set_decode(struct pci_dev *pdev, bool
enable_decode)
int intel_vga_register(struct drm_i915_private *i915)
{
-
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
int ret;
@@ -127,7 +126,7 @@ int intel_vga_register(struct drm_i915_private *i915)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- ret = vga_client_register(pdev, intel_vga_set_decode);
+ ret = vga_client_register(pdev, intel_vga_set_decode, NULL);
if (ret && ret != -ENODEV)
return ret;
diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c
b/drivers/gpu/drm/loongson/lsdc_drv.c
index 188ec82afcfb..d10a28c2c494 100644
--- a/drivers/gpu/drm/loongson/lsdc_drv.c
+++ b/drivers/gpu/drm/loongson/lsdc_drv.c
@@ -289,7 +289,7 @@ static int lsdc_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
pci_set_drvdata(pdev, ddev);
- vga_client_register(pdev, lsdc_vga_set_decode);
+ vga_client_register(pdev, lsdc_vga_set_decode, NULL);
drm_kms_helper_poll_init(ddev);
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index f8bf0ec26844..162b4f4676c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -92,7 +92,7 @@
