From: Bjorn Helgaas <helgaas@kernel.org>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: linux-fbdev@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
Karol Herbst <kherbst@redhat.com>,
linux-pci@vger.kernel.org,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
dri-devel@lists.freedesktop.org,
YiPeng Chai <YiPeng.Chai@amd.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Likun Gao <Likun.Gao@amd.com>, David Airlie <airlied@gmail.com>,
Ville Syrjala <ville.syrjala@linux.intel.com>,
Yi Liu <yi.l.liu@intel.com>,
kvm@vger.kernel.org, amd-gfx@lists.freedesktop.org,
Jason Gunthorpe <jgg@ziepe.ca>, Ben Skeggs <bskeggs@redhat.com>,
Kevin Tian <kevin.tian@intel.com>,
Lijo Lazar <lijo.lazar@amd.com>,
Sui Jingfeng <suijingfeng@loongson.cn>,
Thomas Zimmermann <tzimmermann@suse.de>,
Jani Nikula <jani.nikula@intel.com>,
Bokun Zhang <Bokun.Zhang@amd.com>,
intel-gfx@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
Abhishek Sahu <abhsahu@nvidia.com>,
Maxime Ripard <mripard@kernel.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Yishai Hadas <yishaih@nvidia.com>,
Pan Xinhui <Xinhui.Pan@amd.com>,
linux-kernel@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>,
Alex Deucher <alexander.deucher@amd.com>,
Christian Konig <christian.koenig@amd.com>,
Hawking Zhang <Hawking.Zhang@amd.com>
Subject: Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
Date: Wed, 19 Jul 2023 14:32:33 -0500 [thread overview]
Message-ID: <20230719193233.GA511659@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-5-sui.jingfeng@linux.dev>
[+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?
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: linux-fbdev@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
Karol Herbst <kherbst@redhat.com>,
linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org,
YiPeng Chai <YiPeng.Chai@amd.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Likun Gao <Likun.Gao@amd.com>, David Airlie <airlied@gmail.com>,
Yi Liu <yi.l.liu@intel.com>,
kvm@vger.kernel.org, amd-gfx@lists.freedesktop.org,
Jason Gunthorpe <jgg@ziepe.ca>, Ben Skeggs <bskeggs@redhat.com>,
Kevin Tian <kevin.tian@intel.com>,
Lijo Lazar <lijo.lazar@amd.com>,
Sui Jingfeng <suijingfeng@loongson.cn>,
Thomas Zimmermann <tzimmermann@suse.de>,
Jani Nikula <jani.nikula@intel.com>,
Bokun Zhang <Bokun.Zhang@amd.com>,
intel-gfx@lists.freedesktop.org,
Abhishek Sahu <abhsahu@nvidia.com>,
Maxime Ripard <mripard@kernel.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Yishai Hadas <yishaih@nvidia.com>,
Pan Xinhui <Xinhui.Pan@amd.com>,
linux-kernel@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>,
Alex Deucher <alexander.deucher@amd.com>,
Christian Konig <christian.koenig@amd.com>,
Hawking Zhang <Hawking.Zhang@amd.com>
Subject: Re: [Intel-gfx] [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
Date: Wed, 19 Jul 2023 14:32:33 -0500 [thread overview]
Message-ID: <20230719193233.GA511659@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-5-sui.jingfeng@linux.dev>
[+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?
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: David Airlie <airlied@gmail.com>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org,
linux-fbdev@vger.kernel.org,
Sui Jingfeng <suijingfeng@loongson.cn>,
Alex Deucher <alexander.deucher@amd.com>,
Christian Konig <christian.koenig@amd.com>,
Pan Xinhui <Xinhui.Pan@amd.com>, Daniel Vetter <daniel@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Ben Skeggs <bskeggs@redhat.com>,
Karol Herbst <kherbst@redhat.com>, Lyude Paul <lyude@redhat.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Alex Williamson <alex.williamson@redhat.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Hawking Zhang <Hawking.Zhang@amd.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Lijo Lazar <lijo.lazar@amd.com>,
YiPeng Chai <YiPeng.Chai@amd.com>,
Bokun Zhang <Bokun.Zhang@amd.com>, Likun Gao <Likun.Gao@amd.com>,
Ville Syrjala <ville.syrjala@linux.intel.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>,
Cornelia Huck <cohuck@redhat.com>,
Yishai Hadas <yishaih@nvidia.com>,
Abhishek Sahu <abhsahu@nvidia.com>, Yi Liu <yi.l.liu@intel.com>,
Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
Date: Wed, 19 Jul 2023 14:32:33 -0500 [thread overview]
Message-ID: <20230719193233.GA511659@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-5-sui.jingfeng@linux.dev>
[+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?
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: linux-fbdev@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
Karol Herbst <kherbst@redhat.com>,
linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org,
YiPeng Chai <YiPeng.Chai@amd.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Likun Gao <Likun.Gao@amd.com>, Yi Liu <yi.l.liu@intel.com>,
kvm@vger.kernel.org, amd-gfx@lists.freedesktop.org,
Jason Gunthorpe <jgg@ziepe.ca>, Ben Skeggs <bskeggs@redhat.com>,
Kevin Tian <kevin.tian@intel.com>,
Lijo Lazar <lijo.lazar@amd.com>,
Sui Jingfeng <suijingfeng@loongson.cn>,
Thomas Zimmermann <tzimmermann@suse.de>,
Jani Nikula <jani.nikula@intel.com>,
Bokun Zhang <Bokun.Zhang@amd.com>,
intel-gfx@lists.freedesktop.org,
Alex Williamson <alex.williamson@redhat.com>,
Abhishek Sahu <abhsahu@nvidia.com>,
Maxime Ripard <mripard@kernel.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Yishai Hadas <yishaih@nvidia.com>,
Pan Xinhui <Xinhui.Pan@amd.com>,
linux-kernel@vger.kernel.org,
Alex Deucher <alexander.deucher@amd.com>,
Christian Konig <christian.koenig@amd.com>,
Hawking Zhang <Hawking.Zhang@amd.com>
Subject: Re: [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection
Date: Wed, 19 Jul 2023 14:32:33 -0500 [thread overview]
Message-ID: <20230719193233.GA511659@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-5-sui.jingfeng@linux.dev>
[+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?
> 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
next prev parent reply other threads:[~2023-07-19 19:32 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 16:43 [PATCH v3 0/9] PCI/VGA: Improve the default VGA device selection Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-11 16:43 ` [PATCH v3 1/9] video/aperture: Add a helper to detect if an aperture contains firmware FB Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-19 20:43 ` Bjorn Helgaas
2023-07-19 20:43 ` Bjorn Helgaas
2023-07-19 20:43 ` Bjorn Helgaas
2023-07-19 20:43 ` [Intel-gfx] " Bjorn Helgaas
2023-07-19 21:18 ` suijingfeng
2023-07-19 21:18 ` suijingfeng
2023-07-19 21:18 ` suijingfeng
2023-07-19 21:18 ` [Intel-gfx] " suijingfeng
2023-07-11 16:43 ` [PATCH v3 2/9] video/aperture: Add a helper for determining if an unmoved aperture contain FB Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-11 16:43 ` [PATCH v3 3/9] PCI/VGA: Switch to aperture_contain_firmware_fb_nonreloc() Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-19 20:43 ` Bjorn Helgaas
2023-07-19 20:43 ` Bjorn Helgaas
2023-07-19 20:43 ` Bjorn Helgaas
2023-07-19 22:04 ` suijingfeng
2023-07-19 22:04 ` suijingfeng
2023-07-19 22:04 ` suijingfeng
2023-07-11 16:43 ` [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-17 14:07 ` suijingfeng
2023-07-17 14:07 ` suijingfeng
2023-07-17 14:07 ` suijingfeng
2023-07-17 14:07 ` [Intel-gfx] " suijingfeng
2023-07-19 19:32 ` Bjorn Helgaas [this message]
2023-07-19 19:32 ` Bjorn Helgaas
2023-07-19 19:32 ` Bjorn Helgaas
2023-07-19 19:32 ` [Intel-gfx] " Bjorn Helgaas
2023-07-19 22:32 ` suijingfeng
2023-07-19 22:32 ` suijingfeng
2023-07-19 22:32 ` suijingfeng
2023-07-19 22:32 ` [Intel-gfx] " suijingfeng
2023-07-19 22:44 ` Sui Jingfeng
2023-07-19 22:44 ` Sui Jingfeng
2023-07-19 22:44 ` Sui Jingfeng
2023-07-19 22:44 ` [Intel-gfx] " Sui Jingfeng
2023-07-19 22:51 ` suijingfeng
2023-07-19 22:51 ` suijingfeng
2023-07-19 22:51 ` suijingfeng
2023-07-19 22:51 ` [Intel-gfx] " suijingfeng
2023-07-24 11:56 ` suijingfeng
2023-07-24 11:56 ` suijingfeng
2023-07-24 11:56 ` suijingfeng
2023-07-24 11:56 ` [Intel-gfx] " suijingfeng
2023-07-24 12:16 ` suijingfeng
2023-07-24 12:16 ` suijingfeng
2023-07-24 12:16 ` suijingfeng
2023-07-24 12:16 ` [Intel-gfx] " suijingfeng
2023-07-25 21:30 ` Bjorn Helgaas
2023-07-25 21:30 ` Bjorn Helgaas
2023-07-25 21:30 ` Bjorn Helgaas
2023-07-25 21:30 ` [Intel-gfx] " Bjorn Helgaas
2023-07-24 12:28 ` suijingfeng
2023-07-24 12:28 ` suijingfeng
2023-07-24 12:28 ` suijingfeng
2023-07-24 12:28 ` [Intel-gfx] " suijingfeng
2023-07-11 16:43 ` [PATCH v3 5/9] drm/amdgpu: Implement the is_primary_gpu callback of vga_client_register() Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-11 16:43 ` [PATCH v3 6/9] drm/radeon: Add an implement for the is_primary_gpu function callback Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-11 16:43 ` [PATCH v3 7/9] drm/i915: Add an implement for the is_primary_gpu hook Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-11 16:43 ` [PATCH v3 8/9] drm/ast: Register as a vga client to vgaarb by calling vga_client_register() Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-11 16:43 ` [PATCH v3 9/9] drm/loongson: Add an implement for the is_primary_gpu function callback Sui Jingfeng
2023-07-11 16:43 ` Sui Jingfeng
2023-07-11 16:43 ` [Intel-gfx] " Sui Jingfeng
2023-07-11 18:24 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for PCI/VGA: Improve the default VGA device selection Patchwork
2023-07-19 19:32 ` [PATCH v3 0/9] " Bjorn Helgaas
2023-07-19 19:32 ` Bjorn Helgaas
2023-07-19 19:32 ` Bjorn Helgaas
2023-07-19 19:32 ` [Intel-gfx] " Bjorn Helgaas
2023-07-20 9:17 ` Sui Jingfeng
2023-07-20 9:17 ` Sui Jingfeng
2023-07-20 9:17 ` Sui Jingfeng
2023-07-20 9:17 ` [Intel-gfx] " Sui Jingfeng
2023-07-24 12:47 ` suijingfeng
2023-07-24 12:47 ` suijingfeng
2023-07-24 12:47 ` suijingfeng
2023-07-24 12:47 ` [Intel-gfx] " suijingfeng
2023-07-25 21:32 ` Bjorn Helgaas
2023-07-25 21:32 ` Bjorn Helgaas
2023-07-25 21:32 ` Bjorn Helgaas
2023-07-25 21:32 ` [Intel-gfx] " Bjorn Helgaas
-- strict thread matches above, loose matches on Subject: below --
2023-07-11 16:31 Sui Jingfeng
2023-07-11 16:31 ` [PATCH v3 4/9] " Sui Jingfeng
2023-07-11 16:31 ` Sui Jingfeng
2023-07-11 16:31 ` 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=20230719193233.GA511659@bhelgaas \
--to=helgaas@kernel.org \
--cc=Bokun.Zhang@amd.com \
--cc=Hawking.Zhang@amd.com \
--cc=Likun.Gao@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=YiPeng.Chai@amd.com \
--cc=abhsahu@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bhelgaas@google.com \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=cohuck@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jani.nikula@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kevin.tian@intel.com \
--cc=kherbst@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lijo.lazar@amd.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mario.limonciello@amd.com \
--cc=mripard@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=sui.jingfeng@linux.dev \
--cc=suijingfeng@loongson.cn \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=tzimmermann@suse.de \
--cc=ville.syrjala@linux.intel.com \
--cc=yi.l.liu@intel.com \
--cc=yishaih@nvidia.com \
/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.