linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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-fbdev@vger.kernel.org,
	Sui Jingfeng <suijingfeng@loongson.cn>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 0/9] PCI/VGA: Improve the default VGA device selection
Date: Wed, 19 Jul 2023 14:32:41 -0500	[thread overview]
Message-ID: <20230719193241.GA510805@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-1-sui.jingfeng@linux.dev>

[+cc linux-pci]

On Wed, Jul 12, 2023 at 12:43:01AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng <suijingfeng@loongson.cn>
> 
> Currently, the default VGA device selection 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 on a multiple video card coexistence system. But this is
>    still a policy because it doesn't give the user a choice to override.
> 
> With the observation that device drivers or video aperture helpers 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 need to register the is_boot_device() 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 pass a NULL pointer to keep the original behavior.

I skimmed all these patches, but the only one that seems to mention an
actual problem being solved, i.e., something that doesn't work for an
end user, is "drm/ast: Register as a vga client ..."  Maybe
"drm/loongson: Add an implement for ..." also solves a problem, but it
lacks a commit log, so I don't know what the problem is.

In the future, can you please cc: linux-pci with the entire series?
In this posting, only the patches that touched drivers/pci/vgaarb.c
went to linux-pci, but those aren't enough to make sense of the series
as a whole.

>   video/aperture: Add a helper to detect if an aperture contains
>     firmware FB
>   video/aperture: Add a helper for determining if an unmoved aperture
>     contain FB
>   PCI/VGA: Switch to aperture_contain_firmware_fb_nonreloc()

Since this subject includes the function name (which is nice!), it
would also be helpful if the "Add a helper ..." subject included the
same function name.

>   PCI/VGA: Improve the default VGA device selection

If you can make this subject any more specific, that would be useful.
There's more to say about that patch, so I'll respond there.

>   drm/amdgpu: Implement the is_primary_gpu callback of
>     vga_client_register()
>   drm/radeon: Add an implement for the is_primary_gpu function callback
>   drm/i915: Add an implement for the is_primary_gpu hook
>   drm/ast: Register as a vga client to vgaarb by calling
>     vga_client_register()
>   drm/loongson: Add an implement for the is_primary_gpu function
>     callback

There's unnecessary variation in the subject lines (and the commit
logs) of these patches.  If they all do the same thing but in
different drivers, it's useful if the patches all *look* the same.

You might be able to write these subjects as
"Implement .is_primary_gpu() callback" for brevity.

Bjorn

  parent reply	other threads:[~2023-07-19 19:33 UTC|newest]

Thread overview: 28+ 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 ` [PATCH v3 1/9] video/aperture: Add a helper to detect if an aperture contains firmware FB Sui Jingfeng
2023-07-19 20:43   ` Bjorn Helgaas
2023-07-19 21:18     ` 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 ` [PATCH v3 3/9] PCI/VGA: Switch to aperture_contain_firmware_fb_nonreloc() Sui Jingfeng
2023-07-19 20:43   ` [Intel-gfx] " Bjorn Helgaas
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-17 14:07   ` suijingfeng
2023-07-19 19:32   ` Bjorn Helgaas
2023-07-19 22:32     ` suijingfeng
2023-07-19 22:44       ` Sui Jingfeng
2023-07-19 22:51     ` suijingfeng
2023-07-24 11:56     ` suijingfeng
2023-07-24 12:16     ` suijingfeng
2023-07-25 21:30       ` Bjorn Helgaas
2023-07-24 12:28     ` 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 ` [PATCH v3 6/9] drm/radeon: Add an implement for the is_primary_gpu function callback 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 ` [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 ` [PATCH v3 9/9] drm/loongson: Add an implement for the is_primary_gpu function callback Sui Jingfeng
2023-07-19 19:32 ` Bjorn Helgaas [this message]
2023-07-20  9:17   ` [PATCH v3 0/9] PCI/VGA: Improve the default VGA device selection Sui Jingfeng
2023-07-24 12:47   ` suijingfeng
2023-07-25 21:32     ` Bjorn Helgaas
  -- strict thread matches above, loose matches on Subject: below --
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=20230719193241.GA510805@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=airlied@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sui.jingfeng@linux.dev \
    --cc=suijingfeng@loongson.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).