From: Bjorn Helgaas <helgaas@kernel.org>
To: suijingfeng <suijingfeng@loongson.cn>
Cc: Sui Jingfeng <sui.jingfeng@linux.dev>,
Thomas Zimmermann <tzimmermann@suse.de>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Maxime Ripard <mripard@kernel.org>,
loongson-kernel@lists.loongnix.cn,
dri-devel@lists.freedesktop.org,
Bjorn Helgaas <bhelgaas@google.com>,
Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH 2/6] PCI/VGA: Deal with PCI VGA compatible devices only
Date: Tue, 25 Jul 2023 16:49:28 -0500 [thread overview]
Message-ID: <20230725214928.GA666846@bhelgaas> (raw)
In-Reply-To: <ee44ec4e-df97-c327-b83b-fe56eb2c120b@loongson.cn>
On Sat, Jul 22, 2023 at 04:11:07PM +0800, suijingfeng wrote:
> ...
> In the future, we may want to expand VGAARB to deal all PCI display class
> devices, with another patch.
>
> if (pdev->class >> 16 == PCI_BASE_CLASS_DISPLAY)
>
> // accept
>
> else
>
> // return immediately.
>
>
> Then, we will have a more good chance to clarify the programmer interface.
I would prefer not to expand vgaarb to deal with all display devices
unless they actually need the legacy resources like [pci 0xa0000-0xbffff].
But maybe the consumer of these interfaces relies on vgaarb even for
devices that don't need those resources? If so, please mention
examples of where they depend on vgaarb.
I expect the vgaarb interfaces are used by things that need to emulate
the option ROM to initialize the device. If the device has a
programming interface other than 0000 0000b, the option ROM should not
be using the [pci 0xa0000-0xbffff] resource, so vgaarb should not be
needed.
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: suijingfeng <suijingfeng@loongson.cn>
Cc: Sui Jingfeng <sui.jingfeng@linux.dev>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Maxime Ripard <mripard@kernel.org>,
loongson-kernel@lists.loongnix.cn,
dri-devel@lists.freedesktop.org,
Thomas Zimmermann <tzimmermann@suse.de>,
Bjorn Helgaas <bhelgaas@google.com>,
Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH 2/6] PCI/VGA: Deal with PCI VGA compatible devices only
Date: Tue, 25 Jul 2023 16:49:28 -0500 [thread overview]
Message-ID: <20230725214928.GA666846@bhelgaas> (raw)
In-Reply-To: <ee44ec4e-df97-c327-b83b-fe56eb2c120b@loongson.cn>
On Sat, Jul 22, 2023 at 04:11:07PM +0800, suijingfeng wrote:
> ...
> In the future, we may want to expand VGAARB to deal all PCI display class
> devices, with another patch.
>
> if (pdev->class >> 16 == PCI_BASE_CLASS_DISPLAY)
>
> // accept
>
> else
>
> // return immediately.
>
>
> Then, we will have a more good chance to clarify the programmer interface.
I would prefer not to expand vgaarb to deal with all display devices
unless they actually need the legacy resources like [pci 0xa0000-0xbffff].
But maybe the consumer of these interfaces relies on vgaarb even for
devices that don't need those resources? If so, please mention
examples of where they depend on vgaarb.
I expect the vgaarb interfaces are used by things that need to emulate
the option ROM to initialize the device. If the device has a
programming interface other than 0000 0000b, the option ROM should not
be using the [pci 0xa0000-0xbffff] resource, so vgaarb should not be
needed.
Bjorn
next prev parent reply other threads:[~2023-07-25 21:49 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 13:43 [PATCH 0/6] PCI/VGA: Fix typos, comments and copyright Sui Jingfeng
2023-07-11 13:43 ` Sui Jingfeng
2023-07-11 13:43 ` [PATCH 1/6] PCI/VGA: Use unsigned type for the io_state variable Sui Jingfeng
2023-07-11 13:43 ` Sui Jingfeng
2023-07-11 13:43 ` [PATCH 2/6] PCI/VGA: Deal with PCI VGA compatible devices only Sui Jingfeng
2023-07-11 13:43 ` Sui Jingfeng
2023-07-17 9:51 ` suijingfeng
2023-07-17 13:17 ` Sui Jingfeng
2023-07-17 13:28 ` suijingfeng
2023-07-19 18:26 ` Bjorn Helgaas
2023-07-19 18:26 ` Bjorn Helgaas
2023-07-19 19:58 ` Sui Jingfeng
2023-07-19 19:58 ` Sui Jingfeng
2023-07-19 20:06 ` suijingfeng
2023-07-19 20:06 ` suijingfeng
2023-07-19 20:08 ` suijingfeng
2023-07-19 20:08 ` suijingfeng
2023-07-19 20:16 ` suijingfeng
2023-07-19 20:16 ` suijingfeng
2023-07-19 21:13 ` Sui Jingfeng
2023-07-19 21:13 ` Sui Jingfeng
2023-07-19 21:27 ` suijingfeng
2023-07-19 21:27 ` suijingfeng
2023-07-22 8:11 ` suijingfeng
2023-07-22 8:11 ` suijingfeng
2023-07-25 21:49 ` Bjorn Helgaas [this message]
2023-07-25 21:49 ` Bjorn Helgaas
2023-08-01 7:17 ` Sui Jingfeng
2023-08-01 7:17 ` Sui Jingfeng
2023-07-11 13:43 ` [PATCH 3/6] PCI/VGA: drop the inline of vga_update_device_decodes() function Sui Jingfeng
2023-07-11 13:43 ` Sui Jingfeng
2023-07-24 13:02 ` suijingfeng
2023-07-24 13:02 ` suijingfeng
2023-07-11 13:43 ` [PATCH 4/6] PCI/VGA: Move the new_state assignment out the loop Sui Jingfeng
2023-07-11 13:43 ` Sui Jingfeng
2023-07-24 13:02 ` suijingfeng
2023-07-24 13:02 ` suijingfeng
2023-07-25 21:51 ` Bjorn Helgaas
2023-07-25 21:51 ` Bjorn Helgaas
2023-07-11 13:43 ` [PATCH 5/6] PCI/VGA: Tidy up the code and comment format Sui Jingfeng
2023-07-11 13:43 ` Sui Jingfeng
2023-07-11 13:43 ` [PATCH 6/6] PCI/VGA: Replace full MIT license text with SPDX identifier Sui Jingfeng
2023-07-11 13:43 ` 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=20230725214928.GA666846@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=loongson-kernel@lists.loongnix.cn \
--cc=mario.limonciello@amd.com \
--cc=mripard@kernel.org \
--cc=sui.jingfeng@linux.dev \
--cc=suijingfeng@loongson.cn \
--cc=tzimmermann@suse.de \
/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.