Cc: Sean Paul
Cc: Marijn Suijten
Signed-off-by: Jani Nikula
Acked-by: Thomas Zimmermann
Acked-by: Javier Martinez Canillas
Acked-by: Sui Jingfeng
---
With my admittedly limited and very much x86 focused kernel config, I
get some -Wunused-but-set-variable and -Wformat-truncation= warnings
Hi,
For coding style and wording part, this version looks fine for me after a brief
skim.
Thanks for the patch. :-)
On 2023/9/26 16:23, Mitul Golani wrote:
This patch series adds support for DSC fractional compressed bpp
for MTL+. The series starts with some fixes, followed by patches that
Hi,
On 2023/9/13 14:06, Mitul Golani wrote:
From: Swati Sharma
DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show
to depict sink's precision.
Also, new debugfs entry is created to enforce fractional bpp.
If Force_DSC_Fractional_BPP_en is set then while iterating over
output
Hi,
On 2023/9/13 14:06, Mitul Golani wrote:
From: Ankit Nautiyal
DSC parameter bits_per_pixel is stored in U6.4 format.
The 4 bits represent the fractional part of the bpp.
Currently we use compressed_bpp member of dsc structure to store
only the integral part of the bits_per_pixel.
To store
Hi,
On 2023/9/13 14:06, Mitul Golani wrote:
From: Ankit Nautiyal
MTL+ supports fractional compressed bits_per_pixel, with precision of
1/16. This compressed bpp is stored in U6.4 format.
Accommodate this precision while computing m_n values.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Suraj
Hi,
The word 'prescision' in the commit title is a typo,
perhaps it's more better correct it as 'precision' when merge.
On 2023/9/13 14:05, Mitul Golani wrote:
From: Ankit Nautiyal
Add helper to get the DSC bits_per_pixel precision for the DP sink.
Signed-off-by: Ankit Nautiyal
Hi,
On 2023/9/6 17:40, Christian König wrote:
Am 06.09.23 um 11:08 schrieb suijingfeng:
Well, welcome to correct me if I'm wrong.
You seem to have some very basic misunderstandings here.
The term framebuffer describes some VRAM memory used for scanout.
This framebuffer is exposed to
On 2023/9/7 00:00, Alex Deucher wrote:
On Tue, Sep 5, 2023 at 1:25 PM suijingfeng wrote:
Hi,
On 2023/9/5 13:50, Christian König wrote:
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which one
is primary
Hi,
On 2023/9/6 14:45, Christian König wrote:
Firmware framebuffer device already get killed by the
drm_aperture_remove_conflicting_pci_framebuffers()
function (or its siblings). So, this series is definitely not to
interact with the firmware framebuffer
(or more intelligent framebuffer
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
You might have found a bug in the ast driver. Ast has means to detect
if the device has been POSTed and maybe do that. If this doesn't work
correctly, it needs a fix.
That sounds fine.
The bug is not a big deal, I'm just take it as an example
Hi,
On 2023/9/5 22:52, Alex Williamson wrote:
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced
Hi,
On 2023/9/5 21:28, Christian König wrote:
2) Typically, those non-86 machines don't have a good UEFI firmware
support, which doesn't support select primary GPU as firmware
stage.
Even on x86, there are old UEFI firmwares which already made
undesired
decision for you.
3)
From: Sui Jingfeng
Becasuse the display controller in the ASpeed BMC chip is a VGA-compatible
device, the software programming guide of AST2400 say that it is fully
IBM VGA compliant. Thus, it should also participate in the arbitration.
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Signed-off
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass radeon.modeset=10 on the
kernel cmd line if you really want the device bound
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() function stub. The specific
device drivers can provide an implementation to hook
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() function stub. The specific
device drivers can provide an implementation to hook
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass amdgpu.modeset=10 on the
kernel cmd line if you really want the device bound
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass loongson.modeset=10 on the
kernel cmd line if you really want the device bound
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass i915.modeset=10 on the kernel
cmd line if you really want the device bound
From: Sui Jingfeng
Because the display controller in the Hibmc chip is a VGA compatible
display controller. Because ARM64 doesn't need the VGA console. It does not
need to worry about the side effects that come with the VGA compatible.
However, the real problem is that some ARM64 PCs and servers
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. VGAARB will call back to Nouveau
when the drm/nouveau gets loaded successfully
From: Sui Jingfeng
Because the display controller in N2000/D2000 series can be VGA-compatible,
so let's register gma500 as a VGA client, despite the firmware may alter
the PCI class code of IGD on a multiple GPU co-exist configuration. But
this commit no crime, because VGAARB only cares about
Hi,
On 2023/7/20 03:32, Bjorn Helgaas wrote:
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
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
From: Sui Jingfeng
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/loongson/lsdc_drv.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c
b/drivers/gpu/drm/loongson/lsdc_drv.c
index d10a28c2c494..92ef07d6a534 100644
--- a/drivers
From: Sui Jingfeng
Becasuse the VGA Display Controller in the ASpeed BMC chip is also a PCIe
device, the Software Programming guide of AST2400 say that it is Fully
IBM VGA compliant, thus, it should also particiate in the arbitration.
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: David Airlie
From: Sui Jingfeng
This patch add a function to identify if a device is the default boot
selected by the firmware, it require the GPU has firmware framebuffer
driver support (such as efifb). If a specific hardware doesn't have
firmware framebuffer support, then the introduced function will just
From: Sui Jingfeng
[why]
The vga_is_firmware_default() function defined in drivers/pci/vgaarb.c is
arch-dependent, it's no-op on non-x86 architectures. The arbitration is
not usabe on non-x86 platform.
[how]
The device that owns the firmware framebuffer should be the default boot
device
From: Sui Jingfeng
[why]
The vga_is_firmware_default() function defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures. This made VGAARB
lost an important condition for the arbitration on non-x86 platform. The
rules about which GPU is (or should be) the primary
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
From: Sui Jingfeng
The observation behind this is that we should avoid accessing the global
screen_info directly. Call the aperture_contain_firmware_fb_nonreloc()
function to implement the detection of whether an aperture contains the
firmware FB.
This patch helps to decouple the determination
From: Sui Jingfeng
This patch is intended to form a uniform approach to determining if an
unmoved aperture contains the firmware FB. I believe that the global
screen_info is more about video-specific things.
Putting it in video/aperture.c helps form a uniform approach.
Cc: Thomas Zimmermann
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately, due to the fact that the apertures list
will be freed dynamically, the location and size information of the
firmware FB will be lost after dedicated drivers call
From: Sui Jingfeng
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
From: Sui Jingfeng
[why]
The vga_is_firmware_default() function defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures. This made VGAARB
lost an important condition for the arbitration on non-x86 platform. The
rules about which GPU is (or should be) the primary
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
From: Sui Jingfeng
The observation behind this is that we should avoid accessing the global
screen_info directly. Call the aperture_contain_firmware_fb_nonreloc()
function to implement the detection of whether an aperture contains the
firmware FB.
This patch helps to decouple the determination
From: Sui Jingfeng
This patch is intended to form a uniform approach to determining if an
unmoved aperture contains the firmware FB. I believe that the global
screen_info is more about video-specific things.
Putting it in video/aperture.c helps form a uniform approach.
Cc: Thomas Zimmermann
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately, due to the fact that the apertures list
will be freed dynamically, the location and size information of the
firmware FB will be lost after dedicated drivers call
From: Sui Jingfeng
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
Hi,
This patch set could only be applied if a prerequisite patch[1] set applied
[1] https://patchwork.freedesktop.org/series/120053/
Sorry, its my bad, I will respin my patch.
On 2023/7/7 03:34, Patchwork wrote:
== Series Details ==
Series: PCI/VGA: Improve the default VGA device
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
will be lost after dedicated drivers call
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards
From: Sui Jingfeng
Becasuse the VGA Display Controller in the ASpeed BMC chip is also a PCIe
device, the Software Programming guide of AST2400 say that it is Fully
IBM VGA compliant, thus, it should also particiate in the arbitration.
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: David Airlie
From: Sui Jingfeng
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
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards
From: Sui Jingfeng
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
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
will be lost after dedicated drivers call
From: Sui Jingfeng
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
From: Sui Jingfeng
This patch add a function to identify if a device is the default boot
selected by the firmware, it require the GPU has firmware framebuffer
driver support (such as efifb). If a specific hardware doesn't have
firmware framebuffer support, then the introduced function will just
From: Sui Jingfeng
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
Hi,
On 2023/6/16 22:34, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 10:22 AM Sui Jingfeng wrote:
On 2023/6/16 21:41, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng wrote:
Hi,
On 2023/6/16 05:11, Alex Deucher wrote:
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote
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/nouveau/nouveau_vga.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
drivers/pc
unlock the abitration service to non-x86 architectures. A device
driver can also pass a NULL pointer to the keep the original behavior.
Sui Jingfeng (4):
video/aperture: Add a helper to detect if an aperture contains
firmware FB
PCI/VGA: Improve the default VGA device selection
drm/amdgpu
: Helge Deller
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_aperture.c | 16
drivers/video/aperture.c | 29 +
include/drm/drm_aperture.h | 2 ++
include/linux/aperture.h | 7 +++
4 files changed, 54 insertions(+)
diff --git
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
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
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
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
PING ?
On 2023/6/13 11:01, Sui Jingfeng wrote:
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
PING ?
On 2023/6/13 11:01, Sui Jingfeng wrote:
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still
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
Hi
On 2023/6/22 06:11, Lyude Paul wrote:
For the nouveau bits:
Reviewed-by: Lyude Paul
Thanks a lot
On Tue, 2023-06-13 at 03:25 +0800, 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
Hi,
On 2023/6/16 22:34, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 10:22 AM Sui Jingfeng wrote:
On 2023/6/16 21:41, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng wrote:
Hi,
On 2023/6/16 05:11, Alex Deucher wrote:
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote
Hi,
On 2023/6/20 02:12, Limonciello, Mario wrote:
On 6/12/2023 2:25 PM, Sui Jingfeng wrote:
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI
display
device(pdev->class != 0x030
Hi,
On 2023/6/19 11:02, Maciej W. Rozycki wrote:
On Tue, 13 Jun 2023, Sui Jingfeng wrote:
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
Typo here: s/devcie/device/.
Thanks a lot,
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(p
On 2023/6/18 20:11, Sui Jingfeng wrote:
And screen_info is more about video specifci thing.
screen_info is something more about video specific thing.
Hi,
On 2023/6/18 20:11, Sui Jingfeng wrote:
call back to use if successful
Call back to us if the drm device driver bound to the PCI GPU successfully
Hi,
On 2023/6/16 22:34, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 10:22 AM Sui Jingfeng wrote:
On 2023/6/16 21:41, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng wrote:
Hi,
On 2023/6/16 05:11, Alex Deucher wrote:
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote
Hi,
On 2023/6/16 22:34, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 10:22 AM Sui Jingfeng wrote:
On 2023/6/16 21:41, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng wrote:
Hi,
On 2023/6/16 05:11, Alex Deucher wrote:
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote
On 2023/6/16 21:41, Alex Deucher wrote:
On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng wrote:
Hi,
On 2023/6/16 05:11, Alex Deucher wrote:
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote:
Hi,
On 2023/6/13 11:01, Sui Jingfeng wrote:
From: Sui Jingfeng
Deal only with the VGA devcie
Hi,
On 2023/6/16 05:11, Alex Deucher wrote:
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote:
Hi,
On 2023/6/13 11:01, Sui Jingfeng wrote:
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Fil
vgaarb is loaded too early, even before efifb.
so that we can only relay on the pci_notifier call back to us.
On 2023/6/13 11:01, Sui Jingfeng wrote:
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 arc
Hi,
On 2023/6/13 11:01, Sui Jingfeng wrote:
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards
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
From: Sui Jingfeng
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
will be lost after dedicated drivers call
From: Sui Jingfeng
This patch replaces the leading space with a tab and removes the double
blank line, no functional change.
Cc: Bjorn Helgaas
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
Cc: Bjorn Helgaas
Signed-off-b
From: Sui Jingfeng
The io_state variable in the vga_arb_write() function is declared with
unsigned int type, while the vga_str_to_iostate() function takes int *
type. To keep them consistent, replace the third argument of
vga_str_to_iostate() function with the unsigned int * type.
Cc: Bjorn
introduces a callback that allows the device driver
to tell the VGAARB if the device is the default boot device. Also honor
the comment: "Clients have two callback mechanisms they can use"
Sui Jingfeng (8):
PCI/VGA: Use unsigned type for the io_state variable
PCI/VGA: Deal only with
-by: Sui Jingfeng
Reviewed-by: Andi Shyti
---
drivers/pci/vgaarb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
index 5a696078b382..c1bc6c983932 100644
--- a/drivers/pci/vgaarb.c
+++ b/drivers/pci/vgaarb.c
@@ -77,7 +77,7 @@ static
Cc: Thomas Zimmermann
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi Shyti
---
include/linux/vgaarb.h | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index 6d5465f8c3f2..97129a1bbb7d 100644
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
Cc: Bjorn Helgaas
Signed-off-by: Sui Jingfeng
---
drive
This patch replaces the leading space with a tab and removes the double
blank line, no functional change.
Cc: Bjorn Helgaas
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi Shyti
---
drivers/pci
From: Sui Jingfeng <15330273...@189.cn>
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
introduces a callback that allows the device driver
to tell the VGAARB if the device is the default boot device. Also honor
the comment: "Clients have two callback mechanisms they can use"
Sui Jingfeng (8):
PCI/VGA: Use unsigned type for the io_state variable
PCI/VGA: Deal only with
From: Sui Jingfeng
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi Shyti
From: Sui Jingfeng
Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
device(pdev->class != 0x0300) out. There no need to process the non-display
PCI device.
Signed-off-by: Sui Jingfeng
---
d
From: Sui Jingfeng
This patch replaces the leading space with a tab and removes the double
blank line, no functional change.
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi Shyti
---
drivers/pci/vgaarb.c | 108 -
include/linux/vgaarb.h | 4 +-
2
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
From: Sui Jingfeng
The io_state variable in the vga_arb_write() function is declared with
unsigned int type, while the vga_str_to_iostate() function takes int *
type. To keep them consistent, replace the third argument of
vga_str_to_iostate() function with the unsigned int * type.
Signed-off
On 2023/6/10 00:48, Bjorn Helgaas wrote:
On Fri, Jun 09, 2023 at 10:27:39AM +0800, Sui Jingfeng wrote:
On 2023/6/9 03:19, Bjorn Helgaas wrote:
On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
The vga_is_firmware_default() function is arch-dependent, which
Hi,
On 2023/6/9 03:12, Bjorn Helgaas wrote:
Start with verb and capitalize to match ("Deal only with ...")
On Thu, Jun 08, 2023 at 07:43:21PM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
vgaarb only deal with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subs
Hi,
On 2023/6/9 03:19, Bjorn Helgaas wrote:
On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
The vga_is_firmware_default() function is arch-dependent, which doesn't
sound right. At least, it also works on the Mips and LoongArch platforms.
Tested with the drm
Hi,
On 2023/6/9 03:12, Bjorn Helgaas wrote:
Start with verb and capitalize to match ("Deal only with ...")
On Thu, Jun 08, 2023 at 07:43:21PM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
vgaarb only deal with the VGA devcie(pdev->class == 0x0300), so replace the
pci_get_subs
1 - 100 of 125 matches
Mail list logo
