All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: linux-fbdev@vger.kernel.org,
	Sui Jingfeng <suijingfeng@loongson.cn>,
	kvm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Javier Martinez Canillas <javierm@redhat.com>,
	amd-gfx@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Bjorn Helgaas <bhelgaas@google.com>,
	David Airlie <airlied@gmail.com>, Helge Deller <deller@gmx.de>
Subject: Re: [PATCH v3 1/9] video/aperture: Add a helper to detect if an aperture contains firmware FB
Date: Wed, 19 Jul 2023 15:43:43 -0500	[thread overview]
Message-ID: <20230719204343.GA513226@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-2-sui.jingfeng@linux.dev>

On Wed, Jul 12, 2023 at 12:43:02AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng <suijingfeng@loongson.cn>
> 
> 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
> aperture_remove_conflicting_devices(),
> aperture_remove_conflicting_pci_devices() or
> aperture_remove_all_conflicting_devices() functions

> We solve this problem by introducing two static variables that record the
> firmware framebuffer's start addrness and end addrness. It assumes that the
> system has only one active firmware framebuffer driver at a time. We don't
> use the global structure screen_info here, because PCI resources may get
> reallocated (the VRAM BAR could be moved) during the kernel boot stage.

s/addrness/address/ (twice)

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,
	Sui Jingfeng <suijingfeng@loongson.cn>,
	kvm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Javier Martinez Canillas <javierm@redhat.com>,
	amd-gfx@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Bjorn Helgaas <bhelgaas@google.com>,
	David Airlie <airlied@gmail.com>, Helge Deller <deller@gmx.de>
Subject: Re: [Intel-gfx] [PATCH v3 1/9] video/aperture: Add a helper to detect if an aperture contains firmware FB
Date: Wed, 19 Jul 2023 15:43:43 -0500	[thread overview]
Message-ID: <20230719204343.GA513226@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-2-sui.jingfeng@linux.dev>

On Wed, Jul 12, 2023 at 12:43:02AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng <suijingfeng@loongson.cn>
> 
> 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
> aperture_remove_conflicting_devices(),
> aperture_remove_conflicting_pci_devices() or
> aperture_remove_all_conflicting_devices() functions

> We solve this problem by introducing two static variables that record the
> firmware framebuffer's start addrness and end addrness. It assumes that the
> system has only one active firmware framebuffer driver at a time. We don't
> use the global structure screen_info here, because PCI resources may get
> reallocated (the VRAM BAR could be moved) during the kernel boot stage.

s/addrness/address/ (twice)

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-fbdev@vger.kernel.org,
	Sui Jingfeng <suijingfeng@loongson.cn>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Javier Martinez Canillas <javierm@redhat.com>,
	Bjorn Helgaas <bhelgaas@google.com>, Helge Deller <deller@gmx.de>
Subject: Re: [PATCH v3 1/9] video/aperture: Add a helper to detect if an aperture contains firmware FB
Date: Wed, 19 Jul 2023 15:43:43 -0500	[thread overview]
Message-ID: <20230719204343.GA513226@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-2-sui.jingfeng@linux.dev>

On Wed, Jul 12, 2023 at 12:43:02AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng <suijingfeng@loongson.cn>
> 
> 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
> aperture_remove_conflicting_devices(),
> aperture_remove_conflicting_pci_devices() or
> aperture_remove_all_conflicting_devices() functions

> We solve this problem by introducing two static variables that record the
> firmware framebuffer's start addrness and end addrness. It assumes that the
> system has only one active firmware framebuffer driver at a time. We don't
> use the global structure screen_info here, because PCI resources may get
> reallocated (the VRAM BAR could be moved) during the kernel boot stage.

s/addrness/address/ (twice)

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,
	Sui Jingfeng <suijingfeng@loongson.cn>,
	kvm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Javier Martinez Canillas <javierm@redhat.com>,
	amd-gfx@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Bjorn Helgaas <bhelgaas@google.com>, Helge Deller <deller@gmx.de>
Subject: Re: [PATCH v3 1/9] video/aperture: Add a helper to detect if an aperture contains firmware FB
Date: Wed, 19 Jul 2023 15:43:43 -0500	[thread overview]
Message-ID: <20230719204343.GA513226@bhelgaas> (raw)
In-Reply-To: <20230711164310.791756-2-sui.jingfeng@linux.dev>

On Wed, Jul 12, 2023 at 12:43:02AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng <suijingfeng@loongson.cn>
> 
> 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
> aperture_remove_conflicting_devices(),
> aperture_remove_conflicting_pci_devices() or
> aperture_remove_all_conflicting_devices() functions

> We solve this problem by introducing two static variables that record the
> firmware framebuffer's start addrness and end addrness. It assumes that the
> system has only one active firmware framebuffer driver at a time. We don't
> use the global structure screen_info here, because PCI resources may get
> reallocated (the VRAM BAR could be moved) during the kernel boot stage.

s/addrness/address/ (twice)

  reply	other threads:[~2023-07-19 20:43 UTC|newest]

Thread overview: 103+ 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 [this message]
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
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 1/9] video/aperture: Add a helper to detect if an aperture contains firmware FB 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=20230719204343.GA513226@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=airlied@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bhelgaas@google.com \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.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.