Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
On Fri, 30 Jun 2023, Bjorn Helgaas wrote: > On Fri, Jun 30, 2023 at 10:14:11AM +0800, suijingfeng wrote: >> On 2023/6/30 01:44, Limonciello, Mario wrote: >> > > On 2023/6/29 23:54, Bjorn Helgaas wrote: >> > > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote: > >> > > > 4) Right now we're in the middle of the v6.5 merge window, so new >> > > > content, e.g., this series, is too late for v6.5. Most >> > > > maintainers, including me, wait to merge new content until the >> > > > merge window closes and a new -rc1 is tagged. This merge window >> > > > should close on July 9, and people will start merging content for >> > > > v6.6, typically based on v6.5-rc1. >> > > >> > > Would you will merge all of the patches in this series (e.g. including >> > > the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ? >> > > >> > > Or just part of them? > > The bulk of this series is drivers/pci changes, so typically I would > merge all the patches after getting Acked-by tags from the other > subsystems (DRM and VFIO). For the (negligible) i915 parts, Acked-by: Jani Nikula >> Is it possible to merge the PCI/VGA part as fast as possible, >> especially the PATCH-0006 PCI/VGA: Introduce is_boot_device function >> callback to vga_client_register > > We're in the middle of the v6.5 merge window, so it's too late to add > things to v6.5-rc1. The most likely path for new material like this > would be to queue it for v6.6, which means I would merge it after > v6.5-rc1 is tagged (that tag will probably happen on July 9). Perhaps the part that causes confusion here is that the drm-misc-next and drm-intel-next branches, for example, are always open for new patches; it's just that there's a cutoff at around rc5/rc6 after which they start targeting the next+1 release. We basically hide the merge window from a lot of drm developers. > It would then be in -next until the v6.6 merge window opens (likely in > September), when it would be merged into Linus' tree. > > If the series fixes a regression or other major defect, it's > *possible* to merge things earlier, so they appear in v6.5. But this > series doesn't seem to fall in that category, so I think v6.6 is a > more realistic target. > > Merging for v6.6 would include both the PCI parts and the DRM parts at > the same time, so hopefully that addresses your dependency concerns. I guess the main question is whether Sui Jingfeng has follow-up work planned in drm that depends on these being merged. This would set that back by a full release. (But it happens.) BR, Jani. > > I suggest that you wait until v6.5-rc1, rebase your patches so they > apply cleanly on that tag, collect all the Reviewed-by and Acked-by > tags, include them in your commit logs, and then repost them. > > Bjorn -- Jani Nikula, Intel Open Source Graphics Center
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
On Fri, Jun 30, 2023 at 10:14:11AM +0800, suijingfeng wrote: > On 2023/6/30 01:44, Limonciello, Mario wrote: > > > On 2023/6/29 23:54, Bjorn Helgaas wrote: > > > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote: > > > > 4) Right now we're in the middle of the v6.5 merge window, so new > > > > content, e.g., this series, is too late for v6.5. Most > > > > maintainers, including me, wait to merge new content until the > > > > merge window closes and a new -rc1 is tagged. This merge window > > > > should close on July 9, and people will start merging content for > > > > v6.6, typically based on v6.5-rc1. > > > > > > Would you will merge all of the patches in this series (e.g. including > > > the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ? > > > > > > Or just part of them? The bulk of this series is drivers/pci changes, so typically I would merge all the patches after getting Acked-by tags from the other subsystems (DRM and VFIO). > Is it possible to merge the PCI/VGA part as fast as possible, > especially the PATCH-0006 PCI/VGA: Introduce is_boot_device function > callback to vga_client_register We're in the middle of the v6.5 merge window, so it's too late to add things to v6.5-rc1. The most likely path for new material like this would be to queue it for v6.6, which means I would merge it after v6.5-rc1 is tagged (that tag will probably happen on July 9). It would then be in -next until the v6.6 merge window opens (likely in September), when it would be merged into Linus' tree. If the series fixes a regression or other major defect, it's *possible* to merge things earlier, so they appear in v6.5. But this series doesn't seem to fall in that category, so I think v6.6 is a more realistic target. Merging for v6.6 would include both the PCI parts and the DRM parts at the same time, so hopefully that addresses your dependency concerns. I suggest that you wait until v6.5-rc1, rebase your patches so they apply cleanly on that tag, collect all the Reviewed-by and Acked-by tags, include them in your commit logs, and then repost them. Bjorn
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
Hi, On 2023/6/30 01:44, Limonciello, Mario wrote: I think what you can do is pick up all the tags in your next version. Once the whole series has tags we can discuss how it merges. Yes, you are right. I will prepare the next version. But I think, I should only gather the reverent part together. I means that I probably should divide the 8 patches in V7 into 4 + 4. The first four patch form a group, and the last four patch form another group. Certainly, I will pick up the precious tags I got in the next version. Thanks you!
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
Hi, On 2023/6/30 01:44, Limonciello, Mario wrote: [Public] -Original Message- From: 15330273...@189.cn <15330273...@189.cn> Sent: Thursday, June 29, 2023 12:00 PM To: Bjorn Helgaas ; Sui Jingfeng Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org; Cornelia Huck ; Karol Herbst ; nouveau@lists.freedesktop.org; Joonas Lahtinen ; dri-de...@lists.freedesktop.org; Chai, Thomas ; Limonciello, Mario ; Gao, Likun ; David Airlie ; Ville Syrjala ; Yi Liu ; k...@vger.kernel.org; amd-...@lists.freedesktop.org; Jason Gunthorpe ; Ben Skeggs ; linux- p...@vger.kernel.org; Kevin Tian ; Lazar, Lijo ; Thomas Zimmermann ; Zhang, Bokun ; intel-...@lists.freedesktop.org; Maarten Lankhorst ; Jani Nikula ; Alex Williamson ; Abhishek Sahu ; Maxime Ripard ; Rodrigo Vivi ; Tvrtko Ursulin ; Yishai Hadas ; Pan, Xinhui ; linux- ker...@vger.kernel.org; Daniel Vetter ; Deucher, Alexander ; Koenig, Christian ; Zhang, Hawking Subject: Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register Hi, On 2023/6/29 23:54, Bjorn Helgaas wrote: On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote: Hi, A nouveau developer(Lyude) from redhat send me a R-B, Thanks for the developers of nouveau project. Please allow me add a link[1] here. [1] https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca m...@redhat.com/ 1) Thanks for this. If you post another version of this series, please pick up Lyude's Reviewed-by and include it in the relevant patches (as long as you haven't made significant changes to the code Lyude reviewed). Yes, no significant changes. Just fix typo. I also would like to add support for other DRM drivers. But I think this deserve another patch. Whoever applies this should automatically pick up Reviewed-by/Ack/etc that are replies to the version being applied, but they won't go through previous revisions to find them. 2) Please mention the commit to which the series applies. I tried to apply this on v6.4-rc1, but it doesn't apply cleanly. Since I'm a graphic driver developer, I'm using drm-tip. I just have already pulled, it still apply cleanly on drm-tip. 3) Thanks for including cover letters in your postings. Please include a little changelog in the cover letter so we know what changed between v6 and v7, etc. No change between v6 and v7, it seems that it is because the mailbox don't allow me to sending too many mails a day. so some of the patch is failed to delivery because out of quota. 4) Right now we're in the middle of the v6.5 merge window, so new content, e.g., this series, is too late for v6.5. Most maintainers, including me, wait to merge new content until the merge window closes and a new -rc1 is tagged. This merge window should close on July 9, and people will start merging content for v6.6, typically based on v6.5-rc1. I'm wondering Would you will merge all of the patches in this series (e.g. including the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ? Or just part of them? Emm, I don't know because my patch seems across different subsystem of Linux kernel. There is also a developer for AMDGPU (Mario) give me a R-B for the patch-0002 of this series. So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH- 0006 are already OK(got reviewed by). Those 5 patch are already qualified to be merged, I think. I think what you can do is pick up all the tags in your next version. Once the whole series has tags we can discuss how it merges. Thanks a lot, Mario. Is it possible to merge the PCI/VGA part as fast as possible, especially the PATCH-0006 PCI/VGA: Introduce is_boot_device function callback to vga_client_register As this patch is fundamental, it introduce no functional change, as long as the drm driver side don't introduce a callback. I'm not hurry, but drm driver-side's patch have a dependency on this patch, I think it is better the PCI/VGA-side's patch got merge first. At least for get the first four cleanup(0001 ~ 0004) patch merged first, so that I don't have to send so much on the next version on one series. Being exposed so far, there no obvious objection. It saying that other people also want it got merged. Bjorn, is this OK ? I means that if you could merge those 5 patch first, then there no need to send another version again. I will refine the rest patch with more details and description. I'm fear of making too much noise. Bjorn
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
[Public] > -Original Message- > From: 15330273...@189.cn <15330273...@189.cn> > Sent: Thursday, June 29, 2023 12:00 PM > To: Bjorn Helgaas ; Sui Jingfeng > > Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org; > Cornelia Huck ; Karol Herbst ; > nouveau@lists.freedesktop.org; Joonas Lahtinen > ; dri-de...@lists.freedesktop.org; Chai, > Thomas ; Limonciello, Mario > ; Gao, Likun ; David > Airlie ; Ville Syrjala ; Yi > Liu > ; k...@vger.kernel.org; amd-...@lists.freedesktop.org; > Jason Gunthorpe ; Ben Skeggs ; linux- > p...@vger.kernel.org; Kevin Tian ; Lazar, Lijo > ; Thomas Zimmermann ; > Zhang, Bokun ; intel-...@lists.freedesktop.org; > Maarten Lankhorst ; Jani Nikula > ; Alex Williamson > ; Abhishek Sahu ; > Maxime Ripard ; Rodrigo Vivi ; > Tvrtko Ursulin ; Yishai Hadas > ; Pan, Xinhui ; linux- > ker...@vger.kernel.org; Daniel Vetter ; Deucher, Alexander > ; Koenig, Christian > ; Zhang, Hawking > Subject: Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function > callback to vga_client_register > > Hi, > > On 2023/6/29 23:54, Bjorn Helgaas wrote: > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote: > >> Hi, > >> > >> > >> A nouveau developer(Lyude) from redhat send me a R-B, > >> > >> Thanks for the developers of nouveau project. > >> > >> > >> Please allow me add a link[1] here. > >> > >> > >> [1] > https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca > m...@redhat.com/ > > 1) Thanks for this. If you post another version of this series, > > please pick up Lyude's Reviewed-by and include it in the relevant > > patches (as long as you haven't made significant changes to the > > code Lyude reviewed). > > Yes, no significant changes. Just fix typo. > > I also would like to add support for other DRM drivers. > > But I think this deserve another patch. > > > Whoever applies this should automatically > > pick up Reviewed-by/Ack/etc that are replies to the version being > > applied, but they won't go through previous revisions to find them. > > > > 2) Please mention the commit to which the series applies. I tried to > > apply this on v6.4-rc1, but it doesn't apply cleanly. > > Since I'm a graphic driver developer, I'm using drm-tip. > > I just have already pulled, it still apply cleanly on drm-tip. > > > 3) Thanks for including cover letters in your postings. Please > > include a little changelog in the cover letter so we know what > > changed between v6 and v7, etc. > > No change between v6 and v7, > > it seems that it is because the mailbox don't allow me to sending too > many mails a day. > > so some of the patch is failed to delivery because out of quota. > > > > 4) Right now we're in the middle of the v6.5 merge window, so new > > content, e.g., this series, is too late for v6.5. Most > > maintainers, including me, wait to merge new content until the > > merge window closes and a new -rc1 is tagged. This merge window > > should close on July 9, and people will start merging content for > > v6.6, typically based on v6.5-rc1. > > I'm wondering > > Would you will merge all of the patches in this series (e.g. including > the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ? > > Or just part of them? > > Emm, I don't know because my patch seems across different subsystem of > Linux kernel. > > There is also a developer for AMDGPU (Mario) give me a R-B for the > patch-0002 of this series. > > So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH- > 0006 > are already OK(got reviewed by). > > Those 5 patch are already qualified to be merged, I think. I think what you can do is pick up all the tags in your next version. Once the whole series has tags we can discuss how it merges. > > I means that if you could merge those 5 patch first, then there no need > to send another version again. > > I will refine the rest patch with more details and description. > > I'm fear of making too much noise. > > > Bjorn
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
Hi, On 2023/6/29 23:54, Bjorn Helgaas wrote: On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote: Hi, A nouveau developer(Lyude) from redhat send me a R-B, Thanks for the developers of nouveau project. Please allow me add a link[1] here. [1] https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/ 1) Thanks for this. If you post another version of this series, please pick up Lyude's Reviewed-by and include it in the relevant patches (as long as you haven't made significant changes to the code Lyude reviewed). Yes, no significant changes. Just fix typo. I also would like to add support for other DRM drivers. But I think this deserve another patch. Whoever applies this should automatically pick up Reviewed-by/Ack/etc that are replies to the version being applied, but they won't go through previous revisions to find them. 2) Please mention the commit to which the series applies. I tried to apply this on v6.4-rc1, but it doesn't apply cleanly. Since I'm a graphic driver developer, I'm using drm-tip. I just have already pulled, it still apply cleanly on drm-tip. 3) Thanks for including cover letters in your postings. Please include a little changelog in the cover letter so we know what changed between v6 and v7, etc. No change between v6 and v7, it seems that it is because the mailbox don't allow me to sending too many mails a day. so some of the patch is failed to delivery because out of quota. 4) Right now we're in the middle of the v6.5 merge window, so new content, e.g., this series, is too late for v6.5. Most maintainers, including me, wait to merge new content until the merge window closes and a new -rc1 is tagged. This merge window should close on July 9, and people will start merging content for v6.6, typically based on v6.5-rc1. I'm wondering Would you will merge all of the patches in this series (e.g. including the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ? Or just part of them? Emm, I don't know because my patch seems across different subsystem of Linux kernel. There is also a developer for AMDGPU (Mario) give me a R-B for the patch-0002 of this series. So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-0006 are already OK(got reviewed by). Those 5 patch are already qualified to be merged, I think. I means that if you could merge those 5 patch first, then there no need to send another version again. I will refine the rest patch with more details and description. I'm fear of making too much noise. Bjorn
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote: > Hi, > > > A nouveau developer(Lyude) from redhat send me a R-B, > > Thanks for the developers of nouveau project. > > > Please allow me add a link[1] here. > > > [1] > https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/ 1) Thanks for this. If you post another version of this series, please pick up Lyude's Reviewed-by and include it in the relevant patches (as long as you haven't made significant changes to the code Lyude reviewed). Whoever applies this should automatically pick up Reviewed-by/Ack/etc that are replies to the version being applied, but they won't go through previous revisions to find them. 2) Please mention the commit to which the series applies. I tried to apply this on v6.4-rc1, but it doesn't apply cleanly. 3) Thanks for including cover letters in your postings. Please include a little changelog in the cover letter so we know what changed between v6 and v7, etc. 4) Right now we're in the middle of the v6.5 merge window, so new content, e.g., this series, is too late for v6.5. Most maintainers, including me, wait to merge new content until the merge window closes and a new -rc1 is tagged. This merge window should close on July 9, and people will start merging content for v6.6, typically based on v6.5-rc1. Bjorn
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
Hi, Humble ping ! Please share some bandwidth to help reviewing this series, OK ? As this series is useful for all architecture, I have tested on my X86, mips and LoongArch computer. Questions and comments is also welcome. If no one response within three days, I'm going to send a updated version with another trivial improvement, OK? On 2023/6/13 11:01, Sui Jingfeng wrote: From: Sui Jingfeng The vga_is_firmware_default() function is arch-dependent, it's probably wrong if we simply remove the arch guard. As the VRAM BAR which contains firmware framebuffer may move, while the lfb_base and lfb_size members of the screen_info does not change accordingly. In short, it should take the re-allocation of the PCI BAR into consideration. With the observation that device drivers or video aperture helpers may have better knowledge about which PCI bar contains the firmware fb, 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 not suitable to make such an optimization since it is loaded too early. 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" 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 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/nouveau/nouveau_vga.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/pci/vgaarb.c | 21 - drivers/vfio/pci/vfio_pci_core.c | 2 +- include/linux/vgaarb.h | 8 +--- 7 files changed, 30 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5c7d40873ee2..7a096f2d5c16 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3960,7 +3960,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/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 @@ nouveau_vga_init(struct nouveau_drm *drm) return; pdev = to_pci_dev(dev->dev); - vga_client_register(pdev, nouveau_vga_set_decode); + vga_client_register(pdev, nouveau_vga_set_decode, NULL); /* don't register Thunderbolt eGPU with vga_switcheroo */ if (pci_is_thunderbolt_attached(pdev)) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index afbb3a80c0c6..71f2ff39d6a1 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
PING ? On 2023/6/13 11:01, Sui Jingfeng wrote: From: Sui Jingfeng The vga_is_firmware_default() function is arch-dependent, it's probably wrong if we simply remove the arch guard. As the VRAM BAR which contains firmware framebuffer may move, while the lfb_base and lfb_size members of the screen_info does not change accordingly. In short, it should take the re-allocation of the PCI BAR into consideration. With the observation that device drivers or video aperture helpers may have better knowledge about which PCI bar contains the firmware fb, 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 not suitable to make such an optimization since it is loaded too early. 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" 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 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/nouveau/nouveau_vga.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/pci/vgaarb.c | 21 - drivers/vfio/pci/vfio_pci_core.c | 2 +- include/linux/vgaarb.h | 8 +--- 7 files changed, 30 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5c7d40873ee2..7a096f2d5c16 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3960,7 +3960,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/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 @@ nouveau_vga_init(struct nouveau_drm *drm) return; pdev = to_pci_dev(dev->dev); - vga_client_register(pdev, nouveau_vga_set_decode); + vga_client_register(pdev, nouveau_vga_set_decode, NULL); /* don't register Thunderbolt eGPU with vga_switcheroo */ if (pci_is_thunderbolt_attached(pdev)) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index afbb3a80c0c6..71f2ff39d6a1 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1425,7 +1425,7 @@ int radeon_device_init(struct radeon_device *rdev, /* if we have > 1 VGA cards, then disable the radeon VGA resources */ /* this will fail for cards that aren't VGA class devices, just * ignore it */ - vga_client_register(rdev->pdev, radeon_vga_set_decode); +
Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
Hi, A nouveau developer(Lyude) from redhat send me a R-B, Thanks for the developers of nouveau project. Please allow me add a link[1] here. [1] https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/ On 2023/6/13 11:01, Sui Jingfeng wrote: From: Sui Jingfeng The vga_is_firmware_default() function is arch-dependent, it's probably wrong if we simply remove the arch guard. As the VRAM BAR which contains firmware framebuffer may move, while the lfb_base and lfb_size members of the screen_info does not change accordingly. In short, it should take the re-allocation of the PCI BAR into consideration. With the observation that device drivers or video aperture helpers may have better knowledge about which PCI bar contains the firmware fb, 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 not suitable to make such an optimization since it is loaded too early. 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" 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 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/nouveau/nouveau_vga.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/pci/vgaarb.c | 21 - drivers/vfio/pci/vfio_pci_core.c | 2 +- include/linux/vgaarb.h | 8 +--- 7 files changed, 30 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5c7d40873ee2..7a096f2d5c16 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3960,7 +3960,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/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 @@ nouveau_vga_init(struct nouveau_drm *drm) return; pdev = to_pci_dev(dev->dev); - vga_client_register(pdev, nouveau_vga_set_decode); + vga_client_register(pdev, nouveau_vga_set_decode, NULL); /* don't register Thunderbolt eGPU with vga_switcheroo */ if (pci_is_thunderbolt_attached(pdev)) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index afbb3a80c0c6..71f2ff39d6a1 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1425,7 +1425,7 @@ int radeon_device_init(struct radeon_device *rdev, /* if we have > 1 VGA
[Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register
From: Sui Jingfeng The vga_is_firmware_default() function is arch-dependent, it's probably wrong if we simply remove the arch guard. As the VRAM BAR which contains firmware framebuffer may move, while the lfb_base and lfb_size members of the screen_info does not change accordingly. In short, it should take the re-allocation of the PCI BAR into consideration. With the observation that device drivers or video aperture helpers may have better knowledge about which PCI bar contains the firmware fb, 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 not suitable to make such an optimization since it is loaded too early. 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" 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 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/nouveau/nouveau_vga.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/pci/vgaarb.c | 21 - drivers/vfio/pci/vfio_pci_core.c | 2 +- include/linux/vgaarb.h | 8 +--- 7 files changed, 30 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5c7d40873ee2..7a096f2d5c16 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3960,7 +3960,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/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 @@ nouveau_vga_init(struct nouveau_drm *drm) return; pdev = to_pci_dev(dev->dev); - vga_client_register(pdev, nouveau_vga_set_decode); + vga_client_register(pdev, nouveau_vga_set_decode, NULL); /* don't register Thunderbolt eGPU with vga_switcheroo */ if (pci_is_thunderbolt_attached(pdev)) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index afbb3a80c0c6..71f2ff39d6a1 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1425,7 +1425,7 @@ int radeon_device_init(struct radeon_device *rdev, /* if we have > 1 VGA cards, then disable the radeon VGA resources */ /* this will fail for cards that aren't VGA class devices, just * ignore it */ - vga_client_register(rdev->pdev, radeon_vga_set_decode); + vga_client_register(rdev->pdev, radeon_vga_set_decode, NULL); if